From nobody Mon Jan 4 19:19:45 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 517201ACEE7; Mon, 4 Jan 2016 19:19:42 -0800 (PST) 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.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160105031942.29862.7390.idtracker@ietfa.amsl.com> Date: Mon, 04 Jan 2016 19:19:42 -0800 Archived-At: Cc: pals@ietf.org Subject: [Pals] I-D Action: draft-ietf-pals-mc-pon-02.txt 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: Tue, 05 Jan 2016 03:19:42 -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 Working Group 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-02.txt Pages : 16 Date : 2016-01-04 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-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-mc-pon-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 Tue Jan 5 08:41:03 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 024931A8A0C; Tue, 5 Jan 2016 08:41:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160105164101.26114.16077.idtracker@ietfa.amsl.com> Date: Tue, 05 Jan 2016 08:41:01 -0800 Archived-At: Cc: pals-chairs@ietf.org, agmalis@gmail.com, db3546@att.com, pals@ietf.org Subject: [Pals] pals - New Meeting Session Request for IETF 95 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: Tue, 05 Jan 2016 16:41:02 -0000 A new meeting session request has just been submitted by Andrew G. Malis, a Chair of the pals working group. --------------------------------------------------------- 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. --------------------------------------------------------- From nobody Tue Jan 5 17:29:27 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 7E09E1A88E7 for ; Tue, 5 Jan 2016 17:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 p8rtEyfwevVo for ; Tue, 5 Jan 2016 17:29:23 -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 D27CA1A88E1 for ; Tue, 5 Jan 2016 17:29:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGJ91309; Wed, 06 Jan 2016 01:29:20 +0000 (GMT) Received: from LHREML701-CAH.china.huawei.com (10.201.5.93) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 6 Jan 2016 01:29:17 +0000 Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 6 Jan 2016 01:29:16 +0000 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.102]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Wed, 6 Jan 2016 09:29:03 +0800 From: Jiangyuanlong To: "pals@ietf.org" Thread-Topic: [Pals] I-D Action: draft-ietf-pals-mc-pon-02.txt Thread-Index: AQHRR2f/EvbbKApBBkaWJzA1mSty5J7tr4fw Date: Wed, 6 Jan 2016 01:29:03 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B91606F93@szxema506-mbs.china.huawei.com> References: <20160105031942.29862.7390.idtracker@ietfa.amsl.com> In-Reply-To: <20160105031942.29862.7390.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.118] 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.0A020201.568C6DF0.013C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: dc9c35fdc5bc9046865741822ef35a0e Archived-At: Subject: Re: [Pals] I-D Action: draft-ietf-pals-mc-pon-02.txt 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, 06 Jan 2016 01:29:25 -0000 Hi PALSers, Hope all of you have had a great holiday! We updated the document to a new version, and the main changes are editoria= l. Your reviews and comments are welcome. Thanks, Yuanlong on behalf of authors > -----Original Message----- > From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of internet-drafts@ie= tf.org > Sent: Tuesday, January 05, 2016 11:20 AM > To: i-d-announce@ietf.org > Cc: pals@ietf.org > Subject: [Pals] I-D Action: draft-ietf-pals-mc-pon-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Pseudowire And LDP-enabled Services Wor= king > Group of the IETF. >=20 > 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-02.txt > Pages : 16 > Date : 2016-01-04 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pals-mc-pon/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-pals-mc-pon-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pals-mc-pon-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals From nobody Wed Jan 6 02:34:11 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 C64E01ACE67 for ; Wed, 6 Jan 2016 02:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 sK7LzpBwqv0m for ; Wed, 6 Jan 2016 02:34:08 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 331971ACE66 for ; Wed, 6 Jan 2016 02:34:08 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id f206so69028264wmf.0 for ; Wed, 06 Jan 2016 02:34:08 -0800 (PST) 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-type:content-transfer-encoding; bh=Hh6F8z1zN+vxb5aoQj3Q/JVyiD1zLXbEzOSQk9MkEKc=; b=jHRrdPOmY5clrdghGf2/OUwYyN9A37yc2nR91x8LqinI3/y/yhp9T6VGJAbrCIfs5D EMA3hpYJ3Hf7X8XOlW7HDrevPOjr9id92335DiEia/X+SBaQ3IhwH59diOg876l7SMMi cFVmDMEOzd4EgXqu/I6Q1dXv879mGyxc/P59m7FuOE5YNlIiIf4du3KYNB9Q9zmJ9B1V 1bodKZdD3LXPQ5OisI52q25VIPS04CS7yx71RgbUZCitpCES8LQZ63Y3LOxbym2C/nz8 v08XUL/psoEjX5gaLGeQVuHUH+OxM5qwMQd4CdobybeOIBJsmqejbNWtOZnfGQP0Desj /JQQ== X-Received: by 10.194.204.232 with SMTP id lb8mr127770671wjc.112.1452076446795; Wed, 06 Jan 2016 02:34:06 -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 jo6sm95522257wjb.48.2016.01.06.02.34.04 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jan 2016 02:34:05 -0800 (PST) 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 References: <56683703.9040101@gmail.com> <567A9B08.5030001@gmail.com> From: Stewart Bryant Message-ID: <568CED9B.5000701@gmail.com> Date: Wed, 6 Jan 2016 10:34:03 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <567A9B08.5030001@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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: Wed, 06 Jan 2016 10:34:09 -0000 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 > From nobody Wed Jan 6 02:38:08 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 EB8591ACE70 for ; Wed, 6 Jan 2016 02:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 tCnYEYQ4JJiR for ; Wed, 6 Jan 2016 02:38:05 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 92C771ACE77 for ; Wed, 6 Jan 2016 02:38:05 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id b14so69132206wmb.1 for ; Wed, 06 Jan 2016 02:38:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=gMv1L0mk4CTnFEtp0l96nAxg5z20Q0mDn38mOoeKX9E=; b=OLqumv42XegPOsA/MobJPs+y8BxZo0EQ9aWyqNkKEvb8V04wt5T4cn/MlU8QkeuoFK lezg+mbUpu2Cn0a7BdreD+fwg8Kx5Q1MgtKgoNj5/uu7KUWLapqXdh6MYuy7bwEAELub +RWyi7B9OZwWvvJBKImqBOeJFfwcMB/aHTWO08qm6GUDOGvR5wmgalhgVuHeBw6Z/2U4 x6cpYT1GLKI+Bi6tjCJ7NmuZ2HfBChxi1OvvH5rA6vgNkhjzqZsS65QqepHfh4qYn+H6 2FabLH54FEXtokKC+P/yyfMuQsGlVxos6rzagVKAdEl0mSi+qjMnFtSBACQSDlBWm0Tn fN9w== X-Received: by 10.194.178.135 with SMTP id cy7mr105681860wjc.61.1452076684198; Wed, 06 Jan 2016 02:38:04 -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 75sm8026807wmo.22.2016.01.06.02.38.02 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jan 2016 02:38:03 -0800 (PST) From: Stewart Bryant To: "pals@ietf.org" , "pals-chairs@tools.ietf.org" Message-ID: <568CEE89.2050902@gmail.com> Date: Wed, 6 Jan 2016 10:38:01 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Pals] Pals work items that are not moving forward 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, 06 Jan 2016 10:38:07 -0000 Hi Folks I hope that everyone had a great break. I would just like to draw everyone attention to the following four work items that as far as I can see we have no drafts for; Dec 2016 Submit YANG data model for SS-PWs and MS-PWs to the IESG Jun 2016 Submit S-PE resilience for statically provisioned MS-PWs to the IESG Jun 2016 Submit L2VPN applicability statement for data center applications to the IESG I don't mind helping with S-PE resilience but would like someone else to take point. Any takers for these three work items? Stewart From nobody Wed Jan 6 05:35:41 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 71AC11B2B8D for ; Wed, 6 Jan 2016 05:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, 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 xrG7pOt80f-k for ; Wed, 6 Jan 2016 05:35:36 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0781.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::781]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 595951B2B8C for ; Wed, 6 Jan 2016 05:35:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IxQAS7fBMX+2HLDqCEJv39fgGSRISu/1qbX2GvyAOlo=; b=Nk/PbTYk4xOT8a69jF/lJWqCCTGLGCFl0K3R0PKFgd1xuME5Co6QdjMr5c2VXcxDUtQVt/JdHHSq0ON0/gygasdBDWQfnjGokmEgDAoad2/UCdOG3IxQtCN2WvI+LDimqCAoRVOJSGuWck4JCQ/fFj2N5gfarJ1I3J+5X28ZUGA= Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) with Microsoft SMTP Server (TLS) id 15.1.361.13; Wed, 6 Jan 2016 13:35:13 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0361.006; Wed, 6 Jan 2016 13:35:13 +0000 From: Alexander Vainshtein To: Stewart Bryant Thread-Topic: [Pals] WG Last call draft-ietf-pals-tp-oam-config Thread-Index: AQHRSG3NHZiTw/L3RESrSeke3gT7+57ufB6Q Date: Wed, 6 Jan 2016 13:35:12 +0000 Message-ID: References: <56683703.9040101@gmail.com> <567A9B08.5030001@gmail.com> <568CED9B.5000701@gmail.com> In-Reply-To: <568CED9B.5000701@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; x-originating-ip: [147.234.241.1] x-microsoft-exchange-diagnostics: 1; DB3PR03MB0780; 5:zHnhHVugHGzlWAAPNxlkCEAsmAp1wBMu9t7MMXssqdxGDaXCJIY19mblf9rJfw9uTtdrU7Ctk4XQV9DfJWoF3q1xCoYDSY0dYxMISsivIx4KtXRNRvI1AWnMNrbtmiZWeaugeWm+M4cxnuJRVg/Pwg==; 24:I0FMDHUobCCW/nTF3aow1b1sjDs+mRla4rvXCoMjrOBs/60W9TTK1lODKrvZEF1BGUeZT4R9KT/OHw9oet0MVa1lrtCgy6WID96OqcmNpKE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0780; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:DB3PR03MB0780; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0780; x-forefront-prvs: 0813C68E65 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(252514010)(24454002)(189002)(13464003)(199003)(377454003)(479174004)(74316001)(11100500001)(92566002)(40100003)(4326007)(1220700001)(1096002)(19617315012)(5004730100002)(19580395003)(19625215002)(97736004)(5003600100002)(76176999)(189998001)(105586002)(54356999)(5002640100001)(5008740100001)(10400500002)(790700001)(106356001)(16236675004)(3846002)(33656002)(19300405004)(66066001)(50986999)(230783001)(586003)(110136002)(2950100001)(102836003)(77096005)(101416001)(19580405001)(76576001)(5001960100002)(86362001)(87936001)(106116001)(15975445007)(6116002)(122556002)(2900100001)(81156007); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0780; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR03MB078019F05A1F4708459EB29E9DF40DB3PR03MB0780eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2016 13:35:12.9368 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0780 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: Wed, 06 Jan 2016 13:35:38 -0000 --_000_DB3PR03MB078019F05A1F4708459EB29E9DF40DB3PR03MB0780eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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.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 --_000_DB3PR03MB078019F05A1F4708459EB29E9DF40DB3PR03MB0780eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stewart,

I will try to read the draft and provide some fee= dback 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 refe= rence 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-5492= 66302

Email:   Alexander.Vainshtein@ecitele.c= om

 

 

-----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 holi= day period.

 

I really need some indication on the list that th= e 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.i= etf.org/doc/draft-ietf-pals-mpls-tp-oam-config/

>> 

>> Please respond to this thread with subst= antive comments and an

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

>> think it is ready for publication.<= /o:p>

>> 

>> 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 pr= esent to the IESG  that

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

> 

> Has anyone besides the chairs and authors re= ad it?

> 

> Should we publish it, and why?

> 

> - Stewart

> 

 

_______________________________________________

Pals mailing list

Pals@ietf.org

https://www.iet= f.org/mailman/listinfo/pals

--_000_DB3PR03MB078019F05A1F4708459EB29E9DF40DB3PR03MB0780eurp_-- From nobody Wed Jan 6 14:59:08 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 B80E11A1B7D; Wed, 6 Jan 2016 14:59:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160106225907.26779.28827.idtracker@ietfa.amsl.com> Date: Wed, 06 Jan 2016 14:59:07 -0800 Archived-At: Cc: pals-chairs@ietf.org, agmalis@gmail.com, pals@ietf.org, draft-ietf-pals-congcons@ietf.org Subject: [Pals] Spencer Dawkins' Yes on draft-ietf-pals-congcons-01: (with COMMENT) 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: Wed, 06 Jan 2016 22:59:07 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-pals-congcons-01: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pals-congcons/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- So, very nice. I have one request for you to consider. In this text: The figures presented above demonstrate that TDM service quality degradation generally occurs before the TDM PW would consume more bandwidth that a comparable TCP flow. Thus while TDM PWs are unable to respond to congestion in a TCP-like manner, TDM PWs that are able to deliver acceptable TDM service do not contribute to congestion significantly more than a TCP flow. Combined with our earlier conclusion that Ethernet PWs respond in TCP-like fashion, leads to our final conclusion that no PW-specific congestion-avoidance mechanisms are required. I can't tell whether or not you're saying that a TPM PW only needs a circuit breaker as an absolute last resort, or it doesn't need a circuit breaker, or something else. If you could finish the last sentence with a word about that, I think it would be helpful. From nobody Wed Jan 6 17:59:14 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 5ED791A1A76; Wed, 6 Jan 2016 17:59:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160107015911.27258.1874.idtracker@ietfa.amsl.com> Date: Wed, 06 Jan 2016 17:59:11 -0800 Archived-At: Cc: pals-chairs@ietf.org, agmalis@gmail.com, pals@ietf.org, draft-ietf-pals-congcons@ietf.org Subject: [Pals] Barry Leiba's No Objection on draft-ietf-pals-congcons-01: (with COMMENT) 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, 07 Jan 2016 01:59:11 -0000 Barry Leiba has entered the following ballot position for draft-ietf-pals-congcons-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pals-congcons/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- Abstract -- The abstract seems to have too much detail about what the document concludes. The abstract should just be a general statement of what the document is about -- just enough that someone can determine whether this document is relevant. I think I would do something like this: NEW Pseudowires (PWs) have become a common mechanism for tunneling traffic, and may be found in unmanaged scenarios competing for network resources both with other PWs and with non-PW traffic, such as TCP/IP flows. It is thus worthwhile specifying under what conditions such competition is acceptable, where the PW traffic does not significantly harm other traffic or contribute more than it should to congestion. This document makes that analysis and provides recommendations. END The rest of the detail needs to be in the document -- perhaps in the Introduction -- but not in the abstract. From nobody Thu Jan 7 00:52:38 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 6F7BD1A87D9 for ; Thu, 7 Jan 2016 00:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 fKkg2yX9ttzB for ; Thu, 7 Jan 2016 00:52:34 -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 A7FCF1A87BB for ; Thu, 7 Jan 2016 00:52:12 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCP20603; Thu, 07 Jan 2016 08:52:08 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Jan 2016 08:52:07 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.73]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Thu, 7 Jan 2016 16:52:00 +0800 From: Mach Chen To: Alexander Vainshtein , Stewart Bryant Thread-Topic: [Pals] WG Last call draft-ietf-pals-tp-oam-config Thread-Index: AQHRMovQJO31cjsjYE+2QmNLAFoJYp7YGLgAgBXXmoCAADKcAIABwiSh Date: Thu, 7 Jan 2016 08:52:00 +0000 Message-ID: References: <56683703.9040101@gmail.com> <567A9B08.5030001@gmail.com> <568CED9B.5000701@gmail.com>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.96.255.184] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B691AECSZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.568E2739.009B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.73, 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.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, 07 Jan 2016 08:52:37 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B691AECSZXEMA510MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Shasha, Thanks for your time to read the draft! When I first saw your email, honestly, I also have no idea of what the "Dya= dic" is. I thought that it may be a typo :-). So, I read the draft again a= nd find that Dyadic mode is actually defined in https://tools.ietf.org/html= /rfc6374#section-2.7. Most of the configration definitions are align with https://tools.ietf.org/= html/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-16 and http://tools.ietf.org= /html/rfc7487. So, they should be right/wrong for those common difinitions:= -) Best regards, Mach ________________________________ From: Pals [pals-bounces@ietf.org] on behalf of Alexander Vainshtein [Alexa= nder.Vainshtein@ecitele.com] Sent: Wednesday, January 06, 2016 21:35 To: Stewart Bryant 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 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.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 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B691AECSZXEMA510MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Shasha,

 

Thanks for your time to read the draft!

 

When I first saw your email, honestly, I also have no idea of what the &= quot;Dyadic" is. I thought that it may be a typo :-).  = So, I read the draft again and find that Dyadic mode is actually defin= ed in https://tools.i= etf.org/html/rfc6374#section-2.7.

 

Most of the configration definitions are align with https://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-16 and http://tools.ietf.org/html/rfc7487. So, they should be right/wrong for = those common difinitions:-)

 

 

Best regards,

Mach

From: Pals [pals-bounces@ietf.org] on beha= lf of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com]
Sent: Wednesday, January 06, 2016 21:35
To: Stewart Bryant
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

Stewart,

I will try to read the draft and provide some fee= dback 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 refe= rence 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 ord= er 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-5492= 66302

Email:   Alexander.Vainshtein@ecitele.c= om

 

 

-----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 holi= day period.

 

I really need some indication on the list that th= e 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://datatracke= r.ietf.org/doc/draft-ietf-pals-mpls-tp-oam-config/

>> 

>> Please respond to this thread with subst= antive 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 pr= esent to the IESG  that

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

> 

> Has anyone besides the chairs and authors re= ad it?

> 

> Should we publish it, and why?

> 

> - Stewart

> 

 

_______________________________________________

Pals mailing list

Pals@ietf.org

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

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B691AECSZXEMA510MBXchi_-- From nobody Thu Jan 7 03:44:10 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 2A3611A8901 for ; Thu, 7 Jan 2016 03:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 LPTlolUA70nv for ; Thu, 7 Jan 2016 03:44:01 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0772.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::772]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1131A88FC for ; Thu, 7 Jan 2016 03:44:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kSgzKmIa+lPGAM3pZ+HHPSie3+YrjCB/EjpAUcSGJog=; b=bFh/MDmMVTn25KrWF6iYpIjUCdgTUhv6ZNtmK5bqeGH1JJ581E+b5zr5uAOPEDi0KuzfjV1y0oloaNOykpHSGZLAcHFBGvSMNY5IA8R2r/FUL4QOurxYBCbDMFiKfFhyNvoIu8w7QxbtwemvJkw1vmnQo8ThiO1hpXhc5acav20= Received: from AM3PR03MB0775.eurprd03.prod.outlook.com (2a01:111:e400:8848::11) by AM3PR03MB0774.eurprd03.prod.outlook.com (2a01:111:e400:8845::28) with Microsoft SMTP Server (TLS) id 15.1.365.19; Thu, 7 Jan 2016 11:43:41 +0000 Received: from AM3PR03MB0775.eurprd03.prod.outlook.com ([fe80::7cba:2129:cced:5563]) by AM3PR03MB0775.eurprd03.prod.outlook.com ([fe80::7cba:2129:cced:5563%15]) with mapi id 15.01.0361.006; Thu, 7 Jan 2016 11:43:41 +0000 From: Alexander Vainshtein To: Mach Chen Thread-Topic: [Pals] WG Last call draft-ietf-pals-tp-oam-config Thread-Index: AQHRSG3NHZiTw/L3RESrSeke3gT7+57ufB6QgAFEXQCAAC9AQA== Date: Thu, 7 Jan 2016 11:43:41 +0000 Message-ID: References: <56683703.9040101@gmail.com> <567A9B08.5030001@gmail.com> <568CED9B.5000701@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; x-originating-ip: [147.234.241.1] x-microsoft-exchange-diagnostics: 1; AM3PR03MB0774; 5:cZFmNVq1G0M9pheiX0/NGd0Abh47BabXavGD4soDcyvEIvkLbOb9OfLqW5ctBwQwwsq72f3yXIj3mjcLg1Ou7GcvP8T6QY3cPvYsmMkPnOGzt7U+v2KNv9v/OsaGSEXMkFAQRb86GCXoYFhqBwamKw==; 24:21f2fHOMCS1jaiAe0wIoUoTR6tMUkfGh5sC5ufzEXUYEbzMDbRLfdag7H3j8TSGIS46cjXposOO1NEk1VkTdv6XjYoo/Qgz6peqANk1LVkQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR03MB0774; x-ms-office365-filtering-correlation-id: f6c2d5e7-ac1c-4ced-e949-08d31757ca6b x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001); SRVR:AM3PR03MB0774; BCL:0; PCL:0; RULEID:; SRVR:AM3PR03MB0774; x-forefront-prvs: 0814A2C7A3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(479174004)(189002)(252514010)(377454003)(13464003)(199003)(24454002)(54356999)(76176999)(86362001)(81156007)(19617315012)(230783001)(3846002)(1096002)(6116002)(1220700001)(586003)(790700001)(92566002)(102836003)(5002640100001)(5001960100002)(110136002)(97736004)(5003600100002)(76576001)(16236675004)(106356001)(93886004)(106116001)(189998001)(105586002)(101416001)(87936001)(50986999)(19609705001)(19625215002)(19300405004)(74316001)(19580405001)(19580395003)(33656002)(66066001)(40100003)(4326007)(5008740100001)(2900100001)(5250100002)(15975445007)(11100500001)(2906002)(2950100001)(5004730100002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR03MB0774; H:AM3PR03MB0775.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM3PR03MB077514B3CF14AF87DFB0B2089DF50AM3PR03MB0775eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2016 11:43:41.3785 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR03MB0774 Archived-At: Cc: "Elisa.bellagamba@gmail.com" , "pals-chairs@tools.ietf.org" , "wu.bo@zte.com.cn" , "pals@ietf.org" , "draft-ietf-pals-mpls-tp-oam-config@tools.ietf.org" , Stewart Bryant 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, 07 Jan 2016 11:44:09 -0000 --_000_AM3PR03MB077514B3CF14AF87DFB0B2089DF50AM3PR03MB0775eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mach, Lots of thanks for a prompt response and a valid clarification. Since there seem to be at least two of us puzzled by the term "dyadic mode"= , I would suggest either to replace it with its equivalent "dual-ended meas= urement" (which, IMHO, is much better understood) or, at least, explain the= use of the term. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Mach Chen [mailto:mach.chen@huawei.com] Sent: Thursday, January 07, 2016 10:52 AM To: Alexander Vainshtein; Stewart Bryant 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 Hi Shasha, Thanks for your time to read the draft! When I first saw your email, honestly, I also have no idea of what the "Dya= dic" is. I thought that it may be a typo :-). So, I read the draft again a= nd find that Dyadic mode is actually defined in https://tools.ietf.org/html= /rfc6374#section-2.7. Most of the configration definitions are align with https://tools.ietf.org/= html/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-16 and http://tools.ietf.org= /html/rfc7487. So, they should be right/wrong for those common difinitions:= -) Best regards, Mach ________________________________ From: Pals [pals-bounces@ietf.org] on behalf of Alexander Vainshtein [Alexa= nder.Vainshtein@ecitele.com] Sent: Wednesday, January 06, 2016 21:35 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, 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_AM3PR03MB077514B3CF14AF87DFB0B2089DF50AM3PR03MB0775eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mach,

Lots of thanks for a p= rompt response and a valid clarification.

Since there seem to be= at least two of us puzzled by the term “dyadic mode”, I would = suggest either to replace it with its equivalent “dual-ended measurem= ent” (which, IMHO, is much better understood) or, at least, explain the use of the term.

 

Regards,

Sasha

 

Office: +972-39266= 302

Cell:   = ;   +972-549266302

Email:   Ale= xander.Vainshtein@ecitele.com

 

From: Mach Che= n [mailto:mach.chen@huawei.com]
Sent: Thursday, January 07, 2016 10:52 AM
To: Alexander Vainshtein; Stewart Bryant
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>

 

Hi Shasha,

 

Thanks for your time to read the draft!

 

When I first saw your email, honestly, I also ha= ve no idea of what the "Dyadic" is. I thought that it m= ay be a typo :-).  So, I read the draft again and find that Dyadi= c mode is actually defined in https://tools.ietf.org/html/rfc6374#section-2.7.

 

Most of the configration definitions are align w= ith https://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-16 and http://tools.ietf.org/html/rfc7487. So, they should be right/wrong for = those common difinitions:-)

 

 

Best regards,

Mach

From: Pals [pals-bounces@ietf.org]= on behalf of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com]
Sent: Wednesday, January 06, 2016 21:35
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

Stewart,

I will try to read th= e draft and provide some feedback by January 22nd.

 

Meanwhile, while look= ing for the total number of pages in order to understand whether I can hand= le this, I have found a reference to a "Dyadic mode of an egress LS= R". I have to admit that I do not know what this means, and a short look-up in the Internet did not return anythi= ng useful (unless somebody is going to use 2nd ord= er tensors in MPLSJ).

 

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

 

Regards,

Sasha

 

Office: +972-3926= 6302

Cell:  &nbs= p;   +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

 

-----Original Message= -----
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 everyone= has been busy over the holiday period.

 

I really need some in= dication on the list that the WG wants to publish this draft, otherwise I c= annot take it forward to the IESG.

 

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

 

So please can  h= ave 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 c= an be found at

>> 

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

>> 

>> Please respo= nd to this thread with substantive comments and an

>> indication o= f 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 t= his LC today, but I have no evidence in terms of list

> traffic in respo= nse 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 besid= es the chairs and authors read it?

> =

> Should we publis= h it, and why?

> =

> - Stewart

> =

 

_____________________= __________________________

Pals mailing list

Pals@ietf.org

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

--_000_AM3PR03MB077514B3CF14AF87DFB0B2089DF50AM3PR03MB0775eurp_-- From nobody Thu Jan 7 05:00:34 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 6BFC41A897D for ; Thu, 7 Jan 2016 05:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 RMXH9do0HUcD for ; Thu, 7 Jan 2016 05:00:30 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 50F671A8973 for ; Thu, 7 Jan 2016 05:00:30 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id f206so96810367wmf.0 for ; Thu, 07 Jan 2016 05:00:30 -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:content-type; bh=1WTGQeDApMIHRtDyJ5sznZelkb4q+CvOCqBlP63ddHk=; b=qWCyJLXH88o4jZk+042ptCm05M+dvQOWF435GYuTxzHIztRFv8nBY/R/hTPdQrQ8zH Z5N30FQBbKQilsTXEinZmNqXlUC5vEJnSz7airaEb01xHj3g0ts7e6zwWNUQ9as3iX/Q qLAlDkGAlo5P+6BqREsxUE8LuJsPJVFlXZW87mTxtzflr8zO/NSK2z0jz/vMxDSGGZSN ctWldWriHCO2bfzLfq+Wj3MdrM3iV6ahp+xVc2/9APTXzSuXYZF7vTsqWo1MCtXLRF49 /nMq+j4/XCuGWEPNlxuv8wqbutYbEDrcIm+PihELhdmT11f+VFhMmLWntoh1uzp9Djl3 fOCg== X-Received: by 10.28.145.204 with SMTP id t195mr17045725wmd.91.1452171628412; Thu, 07 Jan 2016 05:00:28 -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 w8sm57010182wjx.21.2016.01.07.05.00.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jan 2016 05:00:27 -0800 (PST) To: Alexander Vainshtein , Mach Chen References: <56683703.9040101@gmail.com> <567A9B08.5030001@gmail.com> <568CED9B.5000701@gmail.com> From: Stewart Bryant Message-ID: <568E616B.8080401@gmail.com> Date: Thu, 7 Jan 2016 13:00:27 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------080503060800010803030206" 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, 07 Jan 2016 13:00:33 -0000 This is a multi-part message in MIME format. --------------080503060800010803030206 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I would think that it's OK to use the terms provided that it is defined, and it certainly needs to be defined. Stewart On 07/01/2016 11:43, Alexander Vainshtein wrote: > > Mach, > > Lots of thanks for a prompt response and a valid clarification. > > Since there seem to be at least two of us puzzled by the term “dyadic > mode”, I would suggest either to replace it with its equivalent > “dual-ended measurement” (which, IMHO, is much better understood) or, > at least, explain the use of the term. > > Regards, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > *From:*Mach Chen [mailto:mach.chen@huawei.com] > *Sent:* Thursday, January 07, 2016 10:52 AM > *To:* Alexander Vainshtein; 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 > > Hi Shasha, > > Thanks for your time to read the draft! > > When I first saw your email, honestly, I also have no idea of what the > "Dyadic" is. I thought that it may be a typo :-). So, I read the > draft again and find that Dyadic mode is actually defined in > https://tools.ietf.org/html/rfc6374#section-2.7. > > Most of the configration definitions are align with > https://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-16 and > http://tools.ietf.org/html/rfc7487 > . So, they should be right/wrong > for those common difinitions:-) > > Best regards, > > Mach > > ------------------------------------------------------------------------ > > *From:*Pals [pals-bounces@ietf.org] on behalf of Alexander Vainshtein > [Alexander.Vainshtein@ecitele.com] > *Sent:* Wednesday, January 06, 2016 21:35 > *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, > > 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 > --------------080503060800010803030206 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I would think that it's OK to use the terms provided that it is defined, and it certainly needs to be defined.

Stewart

On 07/01/2016 11:43, Alexander Vainshtein wrote:

Mach,

Lots of thanks for a prompt response and a valid clarification.

Since there seem to be at least two of us puzzled by the term “dyadic mode”, I would suggest either to replace it with its equivalent “dual-ended measurement” (which, IMHO, is much better understood) or, at least, explain the use of the term.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

From: Mach Chen [mailto:mach.chen@huawei.com]
Sent: Thursday, January 07, 2016 10:52 AM
To: Alexander Vainshtein; 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

 

Hi Shasha,

 

Thanks for your time to read the draft!

 

When I first saw your email, honestly, I also have no idea of what the "Dyadic" is. I thought that it may be a typo :-).  So, I read the draft again and find that Dyadic mode is actually defined in https://tools.ietf.org/html/rfc6374#section-2.7.

 

Most of the configration definitions are align with https://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-16 and http://tools.ietf.org/html/rfc7487. So, they should be right/wrong for those common difinitions:-)

 

 

Best regards,

Mach

From: Pals [pals-bounces@ietf.org] on behalf of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com]
Sent: Wednesday, January 06, 2016 21:35
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,

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


--------------080503060800010803030206-- From nobody Thu Jan 7 10:56:22 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 D45471ABB1A; Thu, 7 Jan 2016 10:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 iAPnZM5bpfrD; Thu, 7 Jan 2016 10:56:19 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 44DB81ABB19; Thu, 7 Jan 2016 10:56:19 -0800 (PST) Received: from 96.21.198.146.dyn.plus.net ([146.198.21.96]:36001 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1aHFjM-0008W3-E5; Thu, 07 Jan 2016 18:56:17 +0000 To: Spencer Dawkins , The IESG References: <20160106225907.26779.28827.idtracker@ietfa.amsl.com> From: Bob Briscoe Message-ID: <568EB4CF.9050606@bobbriscoe.net> Date: Thu, 7 Jan 2016 18:56:15 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20160106225907.26779.28827.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: pals-chairs@ietf.org, agmalis@gmail.com, pals@ietf.org, draft-ietf-pals-congcons@ietf.org Subject: Re: [Pals] Spencer Dawkins' Yes on draft-ietf-pals-congcons-01: (with COMMENT) 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, 07 Jan 2016 18:56:21 -0000 Spencer, Sounds a reasonable request. With the one proviso that we should use the term "mechanism to protect other traffic, e.g. circuit breaker in the last resort". ...given I have been arguing that there will nearly always be better mechanisms (and no less complex) that a CB, which destroys and f***'s-up as much as it protects. Bob On 06/01/16 22:59, Spencer Dawkins wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-pals-congcons-01: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-pals-congcons/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > So, very nice. I have one request for you to consider. > > In this text: > > The figures presented above demonstrate that TDM service quality > degradation generally occurs before the TDM PW would consume more > bandwidth that a comparable TCP flow. Thus while TDM PWs are unable > to respond to congestion in a TCP-like manner, TDM PWs that are able > to deliver acceptable TDM service do not contribute to congestion > significantly more than a TCP flow. Combined with our earlier > conclusion that Ethernet PWs respond in TCP-like fashion, leads to > our final conclusion that no PW-specific congestion-avoidance > mechanisms are required. > > I can't tell whether or not you're saying that a TPM PW only needs a > circuit breaker as an absolute last resort, or it doesn't need a circuit > breaker, or something else. If you could finish the last sentence with a > word about that, I think it would be helpful. > > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Thu Jan 7 11:03:14 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 7EBCB1ABD3D; Thu, 7 Jan 2016 11:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 gcC8yc-AuDxc; Thu, 7 Jan 2016 11:03:08 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 E09F81ABD3C; Thu, 7 Jan 2016 11:03:07 -0800 (PST) Received: from 96.21.198.146.dyn.plus.net ([146.198.21.96]:36022 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1aHFpx-00014Q-DZ; Thu, 07 Jan 2016 19:03:05 +0000 To: Barry Leiba , The IESG References: <20160107015911.27258.1874.idtracker@ietfa.amsl.com> From: Bob Briscoe Message-ID: <568EB668.4060108@bobbriscoe.net> Date: Thu, 7 Jan 2016 19:03:04 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20160107015911.27258.1874.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: pals-chairs@ietf.org, agmalis@gmail.com, pals@ietf.org, draft-ietf-pals-congcons@ietf.org Subject: Re: [Pals] Barry Leiba's No Objection on draft-ietf-pals-congcons-01: (with COMMENT) 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, 07 Jan 2016 19:03:09 -0000 Barry, While I agree with you in principle, I'm not convinced it harms to include conclusions in an abstract, as long the length doesn't become unreasonable. I think perhaps the more important change would be to include a conclusions section (which is the problem with the doc that underlies Spencer's comment). Then I would be less worried about removing conclusions from the abstract - altho I still wouldn't make it a priority. Not every RFC needs a conclusions section, esp. not protocol specs, but I think this one does. Bob On 07/01/16 01:59, Barry Leiba wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-pals-congcons-01: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-pals-congcons/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > -- Abstract -- > The abstract seems to have too much detail about what the document > concludes. The abstract should just be a general statement of what the > document is about -- just enough that someone can determine whether this > > document is relevant. > > I think I would do something like this: > > NEW > Pseudowires (PWs) have become a common mechanism for tunneling > traffic, and may be found in unmanaged scenarios competing for > network resources both with other PWs and with non-PW traffic, such > as TCP/IP flows. It is thus worthwhile specifying under what > conditions such competition is acceptable, where the PW traffic does > not significantly harm other traffic or contribute more than it > should to congestion. This document makes that analysis and provides > recommendations. > END > > The rest of the detail needs to be in the document -- perhaps in the > Introduction -- but not in the abstract. > > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Thu Jan 7 14:22:13 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 233CA1A0266; Thu, 7 Jan 2016 14:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 KRMzXHYdtsJv; Thu, 7 Jan 2016 14:22:11 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 6D99F1A0233; Thu, 7 Jan 2016 14:22:11 -0800 (PST) Received: by mail-ig0-x231.google.com with SMTP id z14so62953586igp.0; Thu, 07 Jan 2016 14:22:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8s9DQtTiG3julEpojv2gZTOqmAfnXNDG7FZXMFU5hLo=; b=W3xEZqz3JD4LwxoLchSAU+YBEwboxl6Drmy4CwJ8pmBMnv7Ve/2iNfTEfW5XGJztWb fLoC4QptgfZuCwh4MmAA5jLlFQWUOeCPSBhwav71v3l5m1+5ivZ1ZNvBGUMxU6se3Bo9 80dYIH14R8NjxhhZqywgzg1gOxDm0xx4qjcWRtekG+k0lPXe4JoVxaWNlhAQ4MaarZ3S NzCpHo13Oars2r2dqeoNwkQuvsbrPXnTJSHOxE3lHf9lxZAvGucwCfJtNdEjnoZyiy2E CXitCmSzD1KfvqJKgBNFatFNYH3phEIcreCs0QJ8aCRNlgNN55VvM3s/GiXrB6fgX7wq ocfA== MIME-Version: 1.0 X-Received: by 10.50.138.11 with SMTP id qm11mr19430819igb.53.1452205330708; Thu, 07 Jan 2016 14:22:10 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.36.117.83 with HTTP; Thu, 7 Jan 2016 14:22:10 -0800 (PST) In-Reply-To: <568EB668.4060108@bobbriscoe.net> References: <20160107015911.27258.1874.idtracker@ietfa.amsl.com> <568EB668.4060108@bobbriscoe.net> Date: Fri, 8 Jan 2016 06:22:10 +0800 X-Google-Sender-Auth: zVveEtl6hVZv6_ZuihC-z8XQ340 Message-ID: From: Barry Leiba To: Bob Briscoe Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-pals-congcons@ietf.org, pals-chairs@ietf.org, Andy Malis , The IESG , pals@ietf.org Subject: Re: [Pals] Barry Leiba's No Objection on draft-ietf-pals-congcons-01: (with COMMENT) 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, 07 Jan 2016 22:22:13 -0000 Hi, Bob. Yes, I think you're right about a "Conclusions" section. As to the Abstract, I'll leave it to y'all to decide that, and thanks for considering my comments. Barry On Fri, Jan 8, 2016 at 3:03 AM, Bob Briscoe wrote: > Barry, > > While I agree with you in principle, I'm not convinced it harms to include > conclusions in an abstract, as long the length doesn't become unreasonable. > > I think perhaps the more important change would be to include a conclusions > section (which is the problem with the doc that underlies Spencer's > comment). Then I would be less worried about removing conclusions from the > abstract - altho I still wouldn't make it a priority. > > Not every RFC needs a conclusions section, esp. not protocol specs, but I > think this one does. > > > Bob > > > On 07/01/16 01:59, Barry Leiba wrote: >> >> Barry Leiba has entered the following ballot position for >> draft-ietf-pals-congcons-01: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-pals-congcons/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> -- Abstract -- >> The abstract seems to have too much detail about what the document >> concludes. The abstract should just be a general statement of what the >> document is about -- just enough that someone can determine whether this >> >> document is relevant. >> >> I think I would do something like this: >> >> NEW >> Pseudowires (PWs) have become a common mechanism for tunneling >> traffic, and may be found in unmanaged scenarios competing for >> network resources both with other PWs and with non-PW traffic, such >> as TCP/IP flows. It is thus worthwhile specifying under what >> conditions such competition is acceptable, where the PW traffic does >> not significantly harm other traffic or contribute more than it >> should to congestion. This document makes that analysis and provides >> recommendations. >> END >> >> The rest of the detail needs to be in the document -- perhaps in the >> Introduction -- but not in the abstract. >> >> > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > From nobody Thu Jan 7 18:43: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 786CD1A6F6D for ; Thu, 7 Jan 2016 18:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 mKrVtpnQlkWE for ; Thu, 7 Jan 2016 18:43:13 -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 BA3A01A6EFB for ; Thu, 7 Jan 2016 18:43:12 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGM95862; Fri, 08 Jan 2016 02:43:09 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 8 Jan 2016 02:43:08 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.181]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Fri, 8 Jan 2016 10:43:03 +0800 From: "Dongjie (Jimmy)" To: Stewart Bryant , "pals@ietf.org" , "pals-chairs@tools.ietf.org" Thread-Topic: [Pals] Pals work items that are not moving forward Thread-Index: AQHRSG5m+DcACu4x30iLdKyPtf0jqJ7w6a6t Date: Fri, 8 Jan 2016 02:43:02 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927744270A1@nkgeml512-mbx.china.huawei.com> References: <568CEE89.2050902@gmail.com> In-Reply-To: <568CEE89.2050902@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.113.124] 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.0A020205.568F223E.0082, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.181, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bc1d9f314cdaf84fbd32ddc2f00ff023 Archived-At: Subject: Re: [Pals] Pals work items that are not moving forward 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, 08 Jan 2016 02:43:15 -0000 Hi Stewart,=20 For the milestone of S-PE resilience for static MS-PWs, I think the corresp= onding draft is draft-ietf-pals-ms-pw-protection-04, which is now in the RF= C Editor Queue. Or you plan to initiate some new work on S-PE resilience? Best regards, Jie ________________________________________ From: Pals [pals-bounces@ietf.org] on behalf of Stewart Bryant [stewart.bry= ant@gmail.com] Sent: Wednesday, January 06, 2016 18:38 To: pals@ietf.org; pals-chairs@tools.ietf.org Subject: [Pals] Pals work items that are not moving forward Hi Folks I hope that everyone had a great break. I would just like to draw everyone attention to the following four work items that as far as I can see we have no drafts for; Dec 2016 Submit YANG data model for SS-PWs and MS-PWs to the IESG Jun 2016 Submit S-PE resilience for statically provisioned MS-PWs to the IESG Jun 2016 Submit L2VPN applicability statement for data center applications to the IESG I don't mind helping with S-PE resilience but would like someone else to take point. Any takers for these three work items? Stewart _______________________________________________ Pals mailing list Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals= From nobody Fri Jan 8 06:10:48 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 D3DDB1B29E7 for ; Fri, 8 Jan 2016 06:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, 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 1GgcxHd96nWi for ; Fri, 8 Jan 2016 06:10:45 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 7D55B1B29EC for ; Fri, 8 Jan 2016 06:10:45 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id k206so11349478oia.1 for ; Fri, 08 Jan 2016 06:10:45 -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 :cc:content-type; bh=1dYZLZpJoPrDJwRNdt0h5TuSA6FNjF3KS8hZL91BL1c=; b=kmVQPOUEBqrw8nXNHd+eYf/ua0ifHqXSGKeduoRNJu/Q8RSxpO2j07LegavAh+Uukm ZwDKpzpoVB+cuYrEMkI1/v/6nj2O+cKxgMUlvRMkJ/TjDNImGddGeXdXN17dPmjfPxjV QOTkO2bzLelI//zGJhu+Ef5DjC3lrtkgpehiCHyD0UO20Qq0if92Va7Pmi7gqGCLnyBj 7h0U1D3ewFauIZkq6Ojen61byVvE3Rtvpd31hH8tqoh0jfWOtpYvYywkNIcWC+eShInO MGuD3//CEIDChTA+XTPpm74RWcXyzewCkUKBPP9HWWr6v6g6lxB6uq76WgBG1NhZKgB6 tGIw== X-Received: by 10.202.87.77 with SMTP id l74mr77227955oib.96.1452262244915; Fri, 08 Jan 2016 06:10:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.136.41 with HTTP; Fri, 8 Jan 2016 06:10:25 -0800 (PST) In-Reply-To: <76CD132C3ADEF848BD84D028D243C927744270A1@nkgeml512-mbx.china.huawei.com> References: <568CEE89.2050902@gmail.com> <76CD132C3ADEF848BD84D028D243C927744270A1@nkgeml512-mbx.china.huawei.com> From: "Andrew G. Malis" Date: Fri, 8 Jan 2016 09:10:25 -0500 Message-ID: To: "Dongjie (Jimmy)" Content-Type: multipart/alternative; boundary=001a113ad4343aa1030528d327cc Archived-At: Cc: Stewart Bryant , "pals-chairs@tools.ietf.org" , "pals@ietf.org" Subject: Re: [Pals] Pals work items that are not moving forward 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, 08 Jan 2016 14:10:47 -0000 --001a113ad4343aa1030528d327cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jie, You=E2=80=99re correct, that milestone will be shown as completed. Stewart = and I somehow skipped over that one while we were updating the milestones. Cheers, Andy On Thu, Jan 7, 2016 at 9:43 PM, Dongjie (Jimmy) wrote= : > Hi Stewart, > > For the milestone of S-PE resilience for static MS-PWs, I think the > corresponding draft is draft-ietf-pals-ms-pw-protection-04, which is now = in > the RFC Editor Queue. > > Or you plan to initiate some new work on S-PE resilience? > > Best regards, > Jie > ________________________________________ > From: Pals [pals-bounces@ietf.org] on behalf of Stewart Bryant [ > stewart.bryant@gmail.com] > Sent: Wednesday, January 06, 2016 18:38 > To: pals@ietf.org; pals-chairs@tools.ietf.org > Subject: [Pals] Pals work items that are not moving forward > > Hi Folks > > I hope that everyone had a great break. > > I would just like to draw everyone attention to the following > four work items that as far as I can see we have no drafts for; > > Dec 2016 Submit YANG data model for SS-PWs and MS-PWs to the IESG > Jun 2016 Submit S-PE resilience for statically provisioned MS-PWs to > the IESG > Jun 2016 Submit L2VPN applicability statement for data center > applications to the IESG > > I don't mind helping with S-PE resilience but would like someone else to > take point. > > Any takers for these three work items? > > Stewart > > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals > --001a113ad4343aa1030528d327cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jie,

You=E2=80=99re correct, that miles= tone will be shown as completed. Stewart and I somehow skipped over that on= e while we were updating the milestones.

Cheers,
Andy

On Thu, Jan 7, 2016 at 9:43 PM, Dongjie (Jimmy) &= lt;jie.dong@huawei= .com> wrote:
Hi Stewart,
For the milestone of S-PE resilience for static MS-PWs, I think the corresp= onding draft is draft-ietf-pals-ms-pw-protection-04, which is now in the RF= C Editor Queue.

Or you plan to initiate some new work on S-PE resilience?

Best regards,
Jie
________________________________________
From: Pals [pals-bounces@ietf.org<= /a>] on behalf of Stewart Bryant [stewart.bryant@gmail.com]
Sent: Wednesday, January 06, 2016 18:38
To: pals@ietf.org; pals-chairs@tools.ietf.org
Subject: [Pals] Pals work items that are not moving forward

Hi Folks

I hope that everyone had a great break.

I would just like to draw everyone attention to the following
four work items that as far as I can see we have no drafts for;

Dec 2016=C2=A0 Submit YANG data model for SS-PWs and MS-PWs to the IESG
Jun 2016=C2=A0 Submit S-PE resilience for statically provisioned MS-PWs to<= br> the IESG
Jun 2016=C2=A0 Submit L2VPN applicability statement for data center
applications to the IESG

I don't mind helping with S-PE resilience but would like someone else t= o
take point.

Any takers for these three work items?

Stewart

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

--001a113ad4343aa1030528d327cc-- From nobody Fri Jan 22 07:08:45 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 2DBB71ACEA8 for ; Fri, 22 Jan 2016 07:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 Q3M_rAbRAJ-k for ; Fri, 22 Jan 2016 07:08:37 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0769.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::769]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868251ACE9C for ; Fri, 22 Jan 2016 07:08:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=r4MS0S3EeiUcTuSsxoPhm/swBRLO2pKm3KgMVHNazkg=; b=LT6IMUho0VJGOsihhsNiYqNQotuLdstY8rJwjzaO9qVdBSYR6amrWgK61LK7sK8Mj40BFkSx7qnK9kSVu3Z/dXG44TNaascioP1nRbWgkSMbmXf35kWjM6FsdZREaLRbqS0m69L1EXAOwOumJqnTHf8eJNHhFtZTZ9FnK4EdU3M= Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0777.eurprd03.prod.outlook.com (10.161.54.27) with Microsoft SMTP Server (TLS) id 15.1.365.19; Fri, 22 Jan 2016 15:08:14 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0365.024; Fri, 22 Jan 2016 15:08:14 +0000 From: Alexander Vainshtein To: Stewart Bryant Thread-Topic: [Pals] WG Last call draft-ietf-pals-tp-oam-config Thread-Index: AQHRSG3NHZiTw/L3RESrSeke3gT7+57ufB6QgBdUjFA= Date: Fri, 22 Jan 2016 15:08:13 +0000 Message-ID: References: <56683703.9040101@gmail.com> <567A9B08.5030001@gmail.com> <568CED9B.5000701@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; x-originating-ip: [5.153.9.203] x-microsoft-exchange-diagnostics: 1; DB3PR03MB0777; 5:SKXzLQ7YSY5NaFjpfl+1FMPA6IJLccIz/5xuuf9//XYwySxdXrLjydFsqym+U/3ZPrbUTY4oajG1z6Jg6Dk9tUZze9q0Fp8DIz9rekhSFIMJDZr0+3WEgX5+TpmnWRHKurr2RYiOeehiaHtGBGXIUw==; 24:FZWSVYTuZY8GZB3YLAcjHKNlmyOFhQWtYUEPAOrNq54ih6I3K3E3jONBuNPBB6yyXpvkPXA6SEJ01AVr/fKdt4R+Lte4FrLDMg6Dl3LZRjg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0777; x-ms-office365-filtering-correlation-id: 2e3c62e5-ca44-46d4-7972-08d3233dd9b4 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046); SRVR:DB3PR03MB0777; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0777; x-forefront-prvs: 08296C9B35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(13464003)(199003)(252514010)(479174004)(377454003)(51444003)(37854004)(189002)(105586002)(76576001)(19580405001)(230783001)(16236675004)(19627405001)(33656002)(76176999)(19580395003)(110136002)(50986999)(122556002)(86362001)(106116001)(40100003)(66066001)(19625215002)(54356999)(101416001)(19617315012)(71446004)(106356001)(1096002)(5003600100002)(2900100001)(87936001)(5002640100001)(1220700001)(4326007)(5008740100001)(5001960100002)(15975445007)(6116002)(189998001)(74316001)(586003)(10400500002)(81156007)(102836003)(5004730100002)(97736004)(92566002)(11100500001)(3846002)(2906002)(77096005)(559001)(579004)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0777; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR03MB07805F19B117FD3D2A7988369DC30DB3PR03MB0780eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2016 15:08:13.9332 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0777 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: Fri, 22 Jan 2016 15:08:44 -0000 --_000_DB3PR03MB07805F19B117FD3D2A7988369DC30DB3PR03MB0780eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Stewart (and all), Following your call for volunteers I have read the draft (or, at least most= of it =96 I did not go into detail regarding the part that discusses PM fu= nctions), and I have multiple concerns regarding it. I have sent most of th= ese 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 =93Security Considerations=94 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 =93VCCV=94 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 =96 even if the PW endpoints agree about all specific OAM function= s 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. 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 = =93Establishment of OAM Entities and Functions=94: 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 =93Adjustment of OAM Paramet= ers=94. 3. Internal inconsistencies: a. BFD Identifiers sub-TLV: i. Ment= ioned twice as =93MUST be included=94 in Section 4.2.1 ii. Is no= t defined anywhere in the draft iii. This = looks like a =93copy and paste=94 notion from RFC 7487 =96 but the definiti= on of the namesake TLV in this document is not applicable as it deals with = MPLS-TP LSP identifiers only. b. Usage of the =93OAM Alarms Enabled=94 flag: i. The = text in at the end of Section 4.1 states that =93The "OAM Alarms Enabled" f= lag is used to request the received PEs to enable (when set) or disable (wh= en cleared) OAM alarms function=94. ii. In al= most all the cases considered in the draft, the =93OAM Alarms Enabled=94 fl= ag is used in accordance with the definition quoted above. iii. Howev= er, the text in Section 3.1.2 says that =93Consequently, the ingress PE nee= ds to keep its OAM sink and source functions running without any changes un= til the OAM parameters are updated. However, in order to suppress spurious= alarms, it also need to disable the alarm functions before the Label Mappi= ng message, with the "OAM Alarms Enabled" flag cleared and the updated PW O= AM Function TLV, is sent. The OAM alarm function needs to be disabled unti= l the corresponding response message is received=94. To me this reads as th= e Label Mapping message to be sent to the =93egress PE=94 in order to adjus= t the OAM parameters must have the =93OAM Alarms Enabled=94 flag cleared in= order to disable spurious OAM alarms there iv. Some of= the use case of the =93OAM Alarms Enabled=94 flag look unnecessary to me. = E.g., when the PW is being set up, I would expect it to suppress all alarm= s (OAM alarms included) until the PW setup is complete =96 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 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 = =93response Label Mapping message=94 b. However, the draft refers (in 3 different places) to a =93response = Label Mapping message=94: i. In S= ection 3.1.2 when it says that =93The OAM alarm function needs to be disabl= ed until the corresponding response message is received=94 ii. In Se= ction 3.2.2 (the same text is used) iii. In Se= ction 4.2.1 when it says that =93The BFD Configuration Sub-TLV MUST include= the following sub-TLVs in the "response" Label Mapping message=94. c. This looks to me like a probable =93copy and paste=94 error from R= FC 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 (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 =93response=94 Label Mappi= ng message has been received b. In addition, to referring (explicitly or implicitly) to the non-exi= sting =93response=94 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 =96 all zeroes =96 =93pre-shared=94 secret= =94) 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 =93inferred packet loss measurement=94 is the method that= measures loss of synthetic probe packets while =93direct packet loss measu= rement=94 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 =93inferred/direct packet delay measurement=94 whil= e, 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 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.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 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_DB3PR03MB07805F19B117FD3D2A7988369DC30DB3PR03MB0780eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Stewart (and all),

Following your call for volunteers I have rea= d the draft (or, at least most of it =96 I did not go into detail regarding= the part that discusses PM functions), and I have multiple concerns regard= ing 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:

        =             &nb= sp;            =             &nb= sp;            =      i.  = ;    From my POV, the draft is about some extensions to RFC= 4447, but this document is only mentions this document in Section 6 =93Sec= urity Considerations=94

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

b.      RFC 5085:

        =             &nb= sp;            =             &nb= sp;            =      i.  = ;    To the best of my understanding, all PW OAM messages r= un in VCCV, but neither RFC 5085 nor RFC 7708 are referenced in the documen= t. Actually, even the term =93VCCV=94 is not mentioned in the document.

        =             &nb= sp;            =             &nb= sp;            =    ii. &nbs= p;    In particular, the draft silently ignores the situati= on when the PW endpoints could not agree on any VCCV Type so that any attemp= ts to run OAM on the PW would fail =96 even if the PW endpoints agree about= all specific OAM functions and their parameters. From my POV if the PW end= points could not agree on the VCCV type, all OAM-related parameters should be simply silently ignored<= /p>

c.       RFC 5885 and RFC 6428 and:

        =             &nb= sp;            =             &nb= sp;            =      i.  = ;    The draft discusses setup of BFD  as pro-active OAM mechanism for PWs

        =             &nb= sp;            =             &nb= sp;            =    ii. &nbs= p;    Neither RFC 5885 (that defines BFD in VCCV) nor RFC 6= 428 (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 en= dpoints 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 =93Establishment of OAM Entities and Function= s=94:

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 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 whether it supports th= e requested OAM configuration.  If it does not support the requested OAM configuration, a Label Rele= ase 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 whe= n the PW endpoints succeed setting up a PW regardless of whether there is a 100% match between their supported O= AM functionality, and just agree on a commonly supported set of OAM functio= ns which could be empty. Such a model, if accepted, would be also consisten= t with the model for adjustment of OAM parameters as defined in Section 3.1.2 =93Adjustment of OAM Paramet= ers=94.

3.       Internal inconsistencies:

a.       BFD Identifiers sub-TLV:

        =             &nb= sp;            =             &nb= sp;            =      i.  = ;    Mentioned twice as =93MUST be included=94 in Section 4= .2.1

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

        =             &nb= sp;            =             &nb= sp;            =   iii. &nb= sp;    This looks like a =93copy and paste=94 notion from R= FC 7487 =96 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 =93OAM Alarms Enabled=94 flag:

        =             &nb= sp;            =             &nb= sp;            =      i.  = ;    The text in at the end of Section 4.1 states that =93<= /span>The "OAM Alarms Enabled" flag is used to request the = received PEs to enable (when set) or disable (when cleared) OAM alarms func= tion=94.

        =             &nb= sp;            =             &nb= sp;            =    ii. &nbs= p;    In almost all the cases considered in the draft, the = =93OAM Alarms Enabled=94 flag is used in accordance with the definition quo= ted above.

        =             &nb= sp;            =             &nb= sp;            =   iii. &nb= sp;    However, the text in Section 3.1.2 says that =93Consequently, the ingress PE needs to keep its OAM sink and source functions running wit= hout any changes until the OAM parameters are updated.&nbs= p; However, in order to suppress spurious alarms, it also need to disab= le the alarm functions before the Label Mapping message, with the "OAM= Alarms Enabled" flag cleared and the updated PW OAM Fun= ction TLV, is sent.  The OAM alarm function needs to be disabled until the corresponding = response message is received=94. To me= this reads as the Label Mapping message to be sent to the =93egress PE=94 = in order to adjust the OAM parameters must have the =93OAM Alarms Enabled=94 flag cleared in order to disable spuriou= s OAM alarms there

        =             &nb= sp;            =             &nb= sp;             iv. &nbs= p;    Some of the use case of the =93OAM Alarms Enabled=94 = flag look unnecessary to me. E.g., when the PW is  being set up, I would expect it to suppress a= ll alarms (OAM alarms included) until the PW setup is complete =96 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:

        =             &nb= sp;            =             &nb= sp;            =      i.  = ;    Each PW endpoint sends its own Label Mapping message f= or 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

        =             &nb= sp;            =             &nb= sp;            =    ii. &nbs= p;    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 =93response Label Mapping message= =94

b.      However, the draft refers (in 3 different places) to a =93response Label M= apping message=94:

        =             &nb= sp;            =             &nb= sp;            =      i.  = ;    In Section 3.1.2 when it says that =93T= he OAM alarm function needs to be disabled until the = corresponding response message is received=94

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

        =             &nb= sp;            =             &nb= sp;            =   iii. &nb= sp;    In Section 4.2.1 when it says that =93The BFD Configuration Sub-TLV MUST include the following sub-TLVs in the "response" La= bel Mapping message=94.

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

5.       Problematic use of sink/source terminology:

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

        =             &nb= sp;            =             &nb= sp;            =      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

        =             &nb= sp;            =             &nb= sp;            =    ii. &nbs= p;    The OAM source functions must be enabl= ed only after a =93response=94 Label Mapping message has been received

b.      In addition, to referring (explicitly or implicitly) to the non-existing = =93response=94 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:

        =             &nb= sp;            =             &nb= sp;            =      i.  = ;    In order to reach a MIP the transmitter must set  the TTL in the PW label to a corresponding value

        =             &nb= sp;            =             &nb= sp;            =    ii. &nbs= p;    Once the TTL in the PW label expires in some S-PE, th= e relevant packet is always trapped

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

7.       Multiple inconsistencies pertaining to use of BFD:

a.       Timer Negotiation:

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

        =             &nb= sp;            =             &nb= sp;            =    ii. &nbs= p;    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 U= P state, and then modify the timers to mutually agreed values using Poll/Fi= nal. Further, RFC 6428 specifies that the timer parameters may be used at a= ny time, and that non-supporting implementations MUST set the BFD session on which such a change is require= d to Admin Down in response to an attempt of the remote endpoint of the ses= sion to change these parameters.

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

b.      Authentication:

        =             &nb= sp;            =             &nb= sp;            =      i.  = ;    The draft defines an I flag that indicates that BFD au= thentication is required, and a BFD Authentication sub-TLV for synchronizin= g the authentication parameters.

        =             &nb= sp;            =             &nb= sp;            =    ii. &nbs= p;    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 =96 all zeroes= =96 =93pre-shared=94 secret=94) would not pass any serious review by the s= ecurity experts

        =             &nb= sp;            =             &nb= sp;            =   iii. &nb= sp;    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 ses= sion).

c.       Local Discriminator sub-TLV:

        =             &nb= sp;            =             &nb= sp;            =      i.  = ;    To the best of my understanding, the draft suggests (i= n Section 4.2.1.1) to exchange the values of the local discriminators betwe= en the endpoints of the BFD session

        =             &nb= sp;            =             &nb= sp;            =    ii. &nbs= p;    I do not really understand why this is needed, becaus= e 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 MU= ST NOT be changed for an already established session.

Note: It is possible that these inconsistencies are copy-pasted from RFC 748= 7, 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 lo= ok problematic to me:

a.       Inferred vs. Direct measurement

        =             &nb= sp;            =             &nb= sp;            =      i.  = ;    According to RFC 6374 =93inferred packet loss measurem= ent=94 is the method that measures loss of synthetic probe packets while = =93direct packet loss measurement=94 counts actually transmitted and received packet= s.

        =             &nb= sp;            =             &nb= sp;            =    ii. &nbs= p;    As per the same RFC, packet delay measurements are al= ways done based on synthetic probe packets (carrying timestamps)

        =             &nb= sp;            =             &nb= sp;            =   iii. &nb= sp;    The draft, however, mentions =93inferred/direct pack= et delay measurement=94 while, AFAIK, direct delay measurement simply does = not exist

b.      Delay Variation Measurement:

        =             &nb= sp;            =             &nb= sp;            =      i.  = ;    The draft supports signaling of delay variation manage= ment function between the PW endpoints(Active/Inactive)

        =             &nb= sp;            =             &nb= sp;            =    ii. &nbs= p;    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 RF= C 7487.

 

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

 

Regards,<= /p>

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<= br> 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 d= o not know what this means, and a short look-up in the Internet did not return anything useful (unless somebody is going t= o 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@ie= tf.org] On Behalf Of St= ewart 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@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 perio= d.

 

I really need some indication on the list that the WG want= s 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-iet= f-pals-tp-oam-config.

>> 

>> This draft can be found at

>> 

>> https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-oam-co= nfig/

>> 

>> Please respond to this thread with substantive co= mments 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/ma= ilman/listinfo/pals

--_000_DB3PR03MB07805F19B117FD3D2A7988369DC30DB3PR03MB0780eurp_-- From nobody Fri Jan 22 16:26:34 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 C11F51B2DBB; Fri, 22 Jan 2016 16:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.903 X-Spam-Level: X-Spam-Status: No, score=-101.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 F0L2MxIi5CdD; Fri, 22 Jan 2016 16:26:30 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 973A41B2DBA; Fri, 22 Jan 2016 16:26:30 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 80F2918045A; Fri, 22 Jan 2016 16:25:11 -0800 (PST) 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: <20160123002511.80F2918045A@rfc-editor.org> Date: Fri, 22 Jan 2016 16:25:11 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, pals@ietf.org, rfc-editor@rfc-editor.org Subject: [Pals] RFC 7727 on Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP) 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: Sat, 23 Jan 2016 00:26:32 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7727 Title: Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP) Author: M. Zhang, H. Wen, J. Hu Status: Standards Track Stream: IETF Date: January 2016 Mailbox: zhangmingui@huawei.com, wenhuafeng@huawei.com, hujie@ctbri.com.cn Pages: 25 Characters: 48135 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pwe3-iccp-stp-05.txt URL: https://www.rfc-editor.org/info/rfc7727 DOI: http://dx.doi.org/10.17487/RFC7727 The Inter-Chassis Communication Protocol (ICCP) supports an inter-chassis redundancy mechanism that is used to support high network availability. In this document, Provider Edge (PE) devices in a Redundancy Group (RG) running ICCP are used to offer multihomed connectivity to Spanning Tree Protocol (STP) networks to improve availability of the STP networks. The ICCP TLVs and usage for the ICCP STP application are defined. 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/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sun Jan 24 18:02:45 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 196A21B3148 for ; Sun, 24 Jan 2016 18:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 MxUVLITppJGp for ; Sun, 24 Jan 2016 18:02:32 -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 1079A1B36F0 for ; Sun, 24 Jan 2016 18:02:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHJ48172; Mon, 25 Jan 2016 02:02:27 +0000 (GMT) Received: from LHREML702-CAH.china.huawei.com (10.201.5.99) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 25 Jan 2016 02:02:27 +0000 Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 25 Jan 2016 02:02:26 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.177]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Mon, 25 Jan 2016 10:02:22 +0800 From: Mach Chen To: Alexander Vainshtein , Stewart Bryant Thread-Topic: [Pals] WG Last call draft-ietf-pals-tp-oam-config Thread-Index: AQHRMovQJO31cjsjYE+2QmNLAFoJYp7ufB6QgBdUjFCABfKJ4A== Date: Mon, 25 Jan 2016 02:02:21 +0000 Message-ID: References: <56683703.9040101@gmail.com> <567A9B08.5030001@gmail.com> <568CED9B.5000701@gmail.com> In-Reply-To: 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_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B6D9DBESZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.56A58234.0191, 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: 1076fe00ce2d1847da5a991240285e2a 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: Mon, 25 Jan 2016 02:02:43 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B6D9DBESZXEMA510MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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@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 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_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B6D9DBESZXEMA510MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sasha,<= o:p>

 = ;

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.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>

 

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.

   &= 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" style=3D"font-size:11.0pt;font-family:"Calibri&quo= t;,"sans-serif";color:black">

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.<= /o:p>

 

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.<= /o:p>

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" flag is used to= request the received PEs to enable (when set) or disable (when cleared) OA= M 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 “Consequently, the ing= ress PE needs to keep its OAM sink and source functions running without any cha= nges until the OAM parameters are updated.  However, in order to suppr= ess 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<= /span>”. 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:=

   &= 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

   &= 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 alarm function needs to be disabled until the corresponding resp= onse 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 Configuration Sub-TLV M= UST include the following sub-TLVs in the "response" Label Mapping m= essage”.

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" style=3D"font-size:11.0pt;font-family:"Calibri&quo= t;,"sans-serif";color:black">

   &= 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)<= /span>

   &= 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

= 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<= /o:p>

Cel= l:      +972-549266302

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

&nb= sp;

 = ;

Stewa= rt,

I wil= l try to read the draft and provide some feedback by January 22nd.

 = ;

Meanw= hile, while looking for the total number of pages in order to understand wh= ether 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 t= his means, and a short look-up in the Internet did not return anything usef= ul (unless somebody is going to use 2nd order tensors in = MPLSJ).

 = ;

If th= e authors could explain in advance what they mean, it would simplify the re= view.

 = ;

Regar= ds,

Sasha=

 = ;

Offic= e: +972-39266302

Cell:=       +972-549266302

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

 = ;

 = ;

-----= Original Message-----
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 Fo= lks

 = ;

I gue= ss that everyone has been busy over the holiday period.

 = ;

I rea= lly need some indication on the list that the WG wants to publish this draf= t, otherwise I cannot take it forward to the IESG.

 = ;

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

 = ;

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

 = ;

Thank= s

 = ;

Stewa= rt

 = ;

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

>&= nbsp;

>&= nbsp;

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

>&= gt; This message starts the WG Last Call on draft-ietf-pals-tp-oam-config.<= o:p>

>&= gt; 

>&= gt; This draft can be found at

>&= gt; 

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

>&= gt; 

>&= gt; Please respond to this thread with substantive comments and an

>&= gt; indication of whether you have read the text and whether or not you

>&= gt; think it is ready for publication.

>&= gt; 

>&= gt; I will close WGLC on 23rd December.

>&= gt; 

>&= gt; Regards

>&= gt; 

>&= gt; - Stewart

>&= nbsp;

> = PALS WG

>&= nbsp;

> = 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.<= /span>

>&= nbsp;

> = Has anyone besides the chairs and authors read it?

>&= nbsp;

> = Should we publish it, and why?

>&= nbsp;

> = - Stewart

>&= nbsp;

 = ;

_____= __________________________________________

Pals = mailing list

Pals@ietf.org

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

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B6D9DBESZXEMA510MBXchi_-- From nobody Sun Jan 24 21:27:08 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 C94331A87D9 for ; Sun, 24 Jan 2016 21:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 Pzs4xbe-xlNE for ; Sun, 24 Jan 2016 21:26:58 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0790.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::790]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9A61A87D4 for ; Sun, 24 Jan 2016 21:26:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=K5kJZXrBPceLLmbL8zFxKNAucyPmnUwI0yY8w4Jqq0E=; b=DwYtaMTN6yKfcsuzQAQyqEG0llCcW9qOGGz1jFylzOKF49amaCbbY2wOEheLsDHuGPq7tnYpxqMUv5IWFJ+6ciKgzwDGxVic6HeNav39VkDrYR/IuhzKazzZoxHlwG5UtUyCgXRMpWph5BLVx7wYqi+uoocASiU82YsRTo1QUmI= Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0778.eurprd03.prod.outlook.com (10.161.54.28) with Microsoft SMTP Server (TLS) id 15.1.365.19; Mon, 25 Jan 2016 05:26:33 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0365.024; Mon, 25 Jan 2016 05:26:33 +0000 From: Alexander Vainshtein To: Mach Chen Thread-Topic: [Pals] WG Last call draft-ietf-pals-tp-oam-config Thread-Index: AQHRSG3NHZiTw/L3RESrSeke3gT7+57ufB6QgBdUjFCABcdUgIAAOLGg Date: Mon, 25 Jan 2016 05:26:32 +0000 Message-ID: References: <56683703.9040101@gmail.com> <567A9B08.5030001@gmail.com> <568CED9B.5000701@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; x-originating-ip: [5.153.9.206] x-microsoft-exchange-diagnostics: 1; DB3PR03MB0778; 5:yyAZ6whxnIMoMqMfdhezgYFGFrv7w0mmfcpnm155nYFkSdDtg0K6Y75IV1ISNZD5n2q9V8oTWA9A6+9I8+PKaw1Xf6fPU6b9c9k8wbLIRFjiZVqa6ZIVjF5rzbCJwJ6gLD7+ZNU+5uIi5E2xWh60HA==; 24:g71As4kIBJI+R++p2iLc56xwOvlOnPN/A8Sf3XkNAQUuZxOHm3j0JuwnE1y9l/C3nv5E2LjznlfJosdW2UpsMgzj0XGTx/jFLTh4YxLaMOw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0778; x-ms-office365-filtering-correlation-id: 9db15036-e5f6-4581-187b-08d325481680 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:DB3PR03MB0778; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0778; x-forefront-prvs: 083289FD26 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(252514010)(66654002)(37854004)(479174004)(51444003)(377454003)(24454002)(189002)(199003)(13464003)(19625215002)(77096005)(74316001)(110136002)(5001960100002)(54356999)(2950100001)(2900100001)(15975445007)(102836003)(1096002)(6116002)(19617315012)(1220700001)(76576001)(11100500001)(5003600100002)(5002640100001)(50986999)(106116001)(105586002)(76176999)(3280700002)(5008740100001)(106356001)(33656002)(97736004)(16236675004)(586003)(3846002)(81156007)(66066001)(101416001)(189998001)(19580405001)(19580395003)(122556002)(2906002)(87936001)(4326007)(10400500002)(5004730100002)(19627405001)(71446004)(230783001)(93886004)(86362001)(40100003)(92566002)(559001)(579004)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0778; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR03MB0780E9482A308C4829FED48D9DC70DB3PR03MB0780eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2016 05:26:32.9738 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0778 Archived-At: Cc: "Elisa.bellagamba@gmail.com" , "pals-chairs@tools.ietf.org" , "wu.bo@zte.com.cn" , "pals@ietf.org" , "draft-ietf-pals-mpls-tp-oam-config@tools.ietf.org" , Stewart Bryant 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: Mon, 25 Jan 2016 05:27:07 -0000 --_000_DB3PR03MB0780E9482A308C4829FED48D9DC70DB3PR03MB0780eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Mach, Lots of thanks for a prompt response. Regards, Sasha ________________________________ From: Mach Chen Sent: Monday, January 25, 2016 4:02 AM To: Alexander Vainshtein; Stewart Bryant 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 Hi Sasha, Many thanks for your detailed review and comment! We=92ll 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@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 Stewart (and all), Following your call for volunteers I have read the draft (or, at least most= of it =96 I did not go into detail regarding the part that discusses PM fu= nctions), and I have multiple concerns regarding it. I have sent most of th= ese 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 =93Security Considerations=94 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 =93VCCV=94 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 =96 even if the PW endpoints agree about all specific OAM function= s 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. 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 = =93Establishment of OAM Entities and Functions=94: 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 =93Adjustment of OAM Paramet= ers=94. 3. Internal inconsistencies: a. BFD Identifiers sub-TLV: i. Ment= ioned twice as =93MUST be included=94 in Section 4.2.1 ii. Is no= t defined anywhere in the draft iii. This = looks like a =93copy and paste=94 notion from RFC 7487 =96 but the definiti= on of the namesake TLV in this document is not applicable as it deals with = MPLS-TP LSP identifiers only. b. Usage of the =93OAM Alarms Enabled=94 flag: i. The = text in at the end of Section 4.1 states that =93The "OAM Alarms Enabled" f= lag is used to request the received PEs to enable (when set) or disable (wh= en cleared) OAM alarms function=94. ii. In al= most all the cases considered in the draft, the =93OAM Alarms Enabled=94 fl= ag is used in accordance with the definition quoted above. iii. Howev= er, the text in Section 3.1.2 says that =93Consequently, the ingress PE nee= ds to keep its OAM sink and source functions running without any changes un= til the OAM parameters are updated. However, in order to suppress spurious= alarms, it also need to disable the alarm functions before the Label Mappi= ng message, with the "OAM Alarms Enabled" flag cleared and the updated PW O= AM Function TLV, is sent. The OAM alarm function needs to be disabled unti= l the corresponding response message is received=94. To me this reads as th= e Label Mapping message to be sent to the =93egress PE=94 in order to adjus= t the OAM parameters must have the =93OAM Alarms Enabled=94 flag cleared in= order to disable spurious OAM alarms there iv. Some of= the use case of the =93OAM Alarms Enabled=94 flag look unnecessary to me. = E.g., when the PW is being set up, I would expect it to suppress all alarm= s (OAM alarms included) until the PW setup is complete =96 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 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 = =93response Label Mapping message=94 b. However, the draft refers (in 3 different places) to a =93response = Label Mapping message=94: i. In S= ection 3.1.2 when it says that =93The OAM alarm function needs to be disabl= ed until the corresponding response message is received=94 ii. In Se= ction 3.2.2 (the same text is used) iii. In Se= ction 4.2.1 when it says that =93The BFD Configuration Sub-TLV MUST include= the following sub-TLVs in the "response" Label Mapping message=94. c. This looks to me like a probable =93copy and paste=94 error from R= FC 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 (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 =93response=94 Label Mappi= ng message has been received b. In addition, to referring (explicitly or implicitly) to the non-exi= sting =93response=94 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 =96 all zeroes =96 =93pre-shared=94 secret= =94) 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 =93inferred packet loss measurement=94 is the method that= measures loss of synthetic probe packets while =93direct packet loss measu= rement=94 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 =93inferred/direct packet delay measurement=94 whil= e, 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 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_DB3PR03MB0780E9482A308C4829FED48D9DC70DB3PR03MB0780eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


Mach,
Lots of thanks for a prompt response.

Regards,
Sasha




From: Mach Chen <mach.ch= en@huawei.com>
Sent: Monday, January 25, 2016 4:02 AM
To: Alexander Vainshtein; Stewart Bryant
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
 

Hi Sasha,

 

Many thanks for your detailed r= eview and comment!

 

We=92ll address them in the nex= t revision.

 

Best regards,

Mach

 

From:  

S= tewart (and all),

F= ollowing your call for volunteers I have read the draft (or, at least most = of it =96 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:

&= nbsp;

1.       References to some ba= sic documents are missing and/or incomplete:

a.       RFC 4447:

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

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

b.      RFC 5085:

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          i.    &nbs= p; To the best of my unders= tanding, all PW OAM messages run in VCCV, but neither RFC 5085 nor RFC 7708= are referenced in the document. Actually, even the term =93VCCV=94 is not mentioned in the document.

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        ii.    &nb= sp; In particular, the draft= silently 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 =96 even if the PW endpoints agree about= all specific OAM functions and their parameters. From my POV if the PW end= points could not agree on the VCCV type, all OAM-related parameters should be simply silently ignored<= span lang=3D"EN-US" style=3D"font-size:11.0pt; font-family:"Calibri&qu= ot;,"sans-serif"; color:black">

c.       RFC 5885 and RFC 6428 an= d:

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

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

2.       Excessively strict be= havior:

a.       The draft defines that a= ny difference in the OAM capabilities of the PW endpoints would result in f= ailure to set it up. One example of this behavior can be found in the following fragment copied from Section 3.1.1 =93Establishm= ent of OAM Entities and Functions=94:

To achieve this, a Label Mapping message with the "OAM Alarms Enab= led" 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= defined in the txt above is too harsh for PWs. I have suggested to the aut= hors 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 commo= nly supported set of OAM functions which could be empty. Such a model, if a= ccepted, would be also consistent with the model for adjustment of OAM parameters as defined in Section 3.1.= 2 =93Adjustment of OAM Parameters=94.

3.       Internal inconsistenc= ies:

a.       BFD Identifiers sub-TLV:=

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          i.    &nbs= p; Mentioned twice as =93MU= ST be included=94 in Section 4.2.1

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

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;       iii.    &n= bsp; This looks like a =93cop= y and paste=94 notion from RFC 7487 =96 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 =93OAM Alar= ms Enabled=94 flag:=

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          i.    &nbs= p; The text in at the end o= f Section 4.1 states that =93The "OAM Alarms Enabled" flag is used = to request the received PEs to enable (when set) or disable (when cleared) = OAM alarms function=94.

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        ii.    &nb= sp; In almost all the cases = considered in the draft, the =93OAM Alarms Enabled=94 flag is used in accor= dance with the definition quoted above.

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;       iii.    &n= bsp; However, the text in Sec= tion 3.1.2 says that =93Consequently, 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 be= fore 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=94. To me this reads as the Label Mapping message to be sent to the =93egress = PE=94 in order to adjust the OAM parameters must have the =93OAM Alarms Ena= bled=94 flag cleared in order to disable spurious OAM alarms there

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      iv.    &nb= sp; Some of the use case of = the =93OAM Alarms Enabled=94 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 =96 and that without = the need of any additional synchronization.

4.       Poor alignment with t= he standard PW setup process:

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

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

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        ii.    &nb= sp; The PW setup is successf= ully completed when both these events are encountered. Their order does not matter, and = consequently there is no such thing as a =93response Label Mapping message= =94

b.      However, the draft refer= s (in 3 different places) to a =93response Label Mapping message=94:=

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          i.    &nbs= p; In Section 3.1.2 when it= says that =93The OAM alarm function needs to be disabled until the corresponding r= esponse message is received=94

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        ii.    &nb= sp; In Section 3.2.2 (the sa= me  text is used)

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;       iii.    &n= bsp; In Section 4.2.1 when it= says that =93The BFD Configuration Sub-TLV MUST include the following sub-TLVs in the "response" Label Mapp= ing message=94.

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

5.       Problematic use of si= nk/source terminology:

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

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

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        ii.    &nb= sp; The OAM source functions must be enabl= ed only after a =93response=94 Label Mapping message has been received

b.      In addition, to referrin= g (explicitly or implicitly) to the non-existing =93response=94 OAM Label M= apping 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:

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          i.    &nbs= p; In order to reach a MIP = the transmitter must set  the TTL in the PW label to a corresponding v= alue

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        ii.    &nb= sp; Once the TTL in the PW l= abel 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 inconsistenc= ies pertaining to use of BFD:

a.       Timer Negotiation:

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

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        ii.    &nb= sp; According to Section 3.7= .1 of RFC 6428 (which, AFAIK, equally applies to BFD in MPLS-TP Sections, L= SPs 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.

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

b.      Authentication:

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          i.    &nbs= p; The draft defines an I f= lag that indicates that BFD authentication is required, and a BFD Authentic= ation sub-TLV for synchronizing the authentication parameters.

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        ii.    &nb= sp; I am not a security expe= rt, and do not pretend to be one. But I think that the default authenticati= on mechanism defined in the draft (SHA1 cryptographic authentication using a hard-coded =96 all zeroes =96 =93pre-shared=94 secret=94) would no= t pass any serious review by the security experts

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;       iii.    &n= bsp; I also do not understand= why the BFD Authentication sub-TLV as defined in Section 4.2.1.3 carries t= he 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-= TLV:

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

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        ii.    &nb= sp; I do not really understa= nd why this is needed, because RFC 5880 defines the mechanism for announcin= g 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.

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

8.       Packet Delay Measurem= ent Issues: I did no= t review this part of the draft in detail, but several points look problematic to m= e:

a.       Inferred vs. Direct meas= urement

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

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        ii.    &nb= sp; As per the same RFC, pac= ket delay measurements are always done based on synthetic probe packets (ca= rrying timestamps)<= /p>

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;       iii.    &n= bsp; The draft, however, ment= ions =93inferred/direct packet delay measurement=94 while, AFAIK, direct de= lay measurement simply does not exist

b.      Delay Variation Measurem= ent:

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          i.    &nbs= p; The draft supports signa= ling of delay variation management function between the PW endpoints(Active= /Inactive)

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        ii.    &nb= sp; AFAIK, delay variation m= easurement is a purely local function, and there is no need to synchronize = its activation between the two PW endpoints

: It is possib= le that these inconsistencies are also copy-pasted from RFC 7487.

H= opefully these comments will be useful for the authors and for the WG.

&= nbsp;

R= egards,

S= asha

&= nbsp;

O= ffice: +972-39266302

C= ell:      +972-549266302

E= mail:   Alexander.Vainshtein@ecitele.com

&= nbsp;

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

&nb= sp;

Ste= wart,

I w= ill try to read the draft and provide some feedback by January 22nd.=

&nb= sp;

Mea= nwhile, 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 t= his means, and a short look-up in the Internet did not return anything usef= ul (unless somebody is going to use 2nd order tensors in MPLSJ).

&nb= sp;

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

&nb= sp;

Reg= ards,

Sas= ha

&nb= sp;

Off= ice: +972-39266302

Cel= l:      +972-549266302

Ema= il:   Alexander.Vainshtein@ecitele.com

&nb= sp;

&nb= sp;

---= --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

&nb= sp;

Hi = Folks

&nb= sp;

I g= uess that everyone has been busy over the holiday period.

&nb= sp;

I r= eally need some indication on the list that the WG wants to publish this dr= aft, otherwise I cannot take it forward to the IESG.

&nb= sp;

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

&nb= sp;

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

&nb= sp;

Tha= nks

&nb= sp;

Ste= wart

&nb= sp;

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

>= ; 

&nb= sp;

___= ____________________________________________

Pal= s mailing list

Pals@ietf.org<= /span>

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

--_000_DB3PR03MB0780E9482A308C4829FED48D9DC70DB3PR03MB0780eurp_-- From nobody Wed Jan 27 07:50:14 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 151931A87B9; Wed, 27 Jan 2016 07:50:14 -0800 (PST) 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.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160127155014.1946.84342.idtracker@ietfa.amsl.com> Date: Wed, 27 Jan 2016 07:50:14 -0800 Archived-At: Cc: pals@ietf.org Subject: [Pals] I-D Action: draft-ietf-pals-endpoint-fast-protection-02.txt 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: Wed, 27 Jan 2016 15:50:14 -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 Working Group of the IETF. Title : PW Endpoint Fast Failure Protection Authors : Yimin Shen Rahul Aggarwal Wim Henderickx Yuanlong Jiang Filename : draft-ietf-pals-endpoint-fast-protection-02.txt Pages : 31 Date : 2016-01-27 Abstract: This document specifies a fast mechanism for protecting pseudowires against egress endpoint failures, including egress attachment circuit failure, egress PE failure, multi-segment PW terminating PE failure, and multi-segment PW switching PE failure. Operating on the basis of multi-homed CE, redundant PWs, upstream label assignment and context specific label switching, the mechanism enables local repair to be performed by the router upstream adjacent to a failure. The router can restore a PW in the order of tens of milliseconds, by rerouting traffic around the failure to a protector through a pre-established bypass tunnel. Therefore, the mechanism can be used to reduce traffic loss before global repair reacts to the failure and the network converges on the topology changes due to the failure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-endpoint-fast-protection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pals-endpoint-fast-protection-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-endpoint-fast-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 Wed Jan 27 08:45:37 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 67D881A885B for ; Wed, 27 Jan 2016 08:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 mkkREurMCCf0 for ; Wed, 27 Jan 2016 08:45:32 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0115.outbound.protection.outlook.com [65.55.169.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 296CF1A8AF1 for ; Wed, 27 Jan 2016 08:45:31 -0800 (PST) Received: from BY2PR0501MB1813.namprd05.prod.outlook.com (10.163.155.143) by BY2PR0501MB1816.namprd05.prod.outlook.com (10.163.155.146) with Microsoft SMTP Server (TLS) id 15.1.390.13; Wed, 27 Jan 2016 16:45:29 +0000 Received: from BY2PR0501MB1813.namprd05.prod.outlook.com ([10.163.155.143]) by BY2PR0501MB1813.namprd05.prod.outlook.com ([10.163.155.143]) with mapi id 15.01.0390.013; Wed, 27 Jan 2016 16:45:29 +0000 From: Yimin Shen To: pals , "pals-chairs@tools.ietf.org" , BOCCI Matthew , "stbryant@cisco.com" , Mach Chen Thread-Topic: New Version Notification for draft-ietf-pals-endpoint-fast-protection-02.txt Thread-Index: AQHRWRprsFvKC7jlyEGRSRdilOlFHZ8PjlaQ Date: Wed, 27 Jan 2016 16:45:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=yshen@juniper.net; x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; BY2PR0501MB1816; 5:TdFLHAtAdb/9OKIWIf+4c/RBj28BMjx5Z+SzNjVqsQALorxxk492RPT+6nYL9Z+WVD+HjvkREBUEJVoWlgKXbVJb2HjrXDKhwT1+Q+xtprDa1qcB5+qK3oyXveuCMDDQvSVbT8kCFKKCM8sZwTg9bw==; 24:pPAaqzaG0Csb9ly6SqcP1iiGTNB9fUcsEBRScstkr64Uoga4r1nhWMZQ0r+nCZ3VwKQwwAX6sSWocguxMwzEIf3QCMaBnb5/HP9+94fjf2A= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0501MB1816; x-ms-office365-filtering-correlation-id: c12d870c-0a8c-4cdc-2882-08d327394413 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BY2PR0501MB1816; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB1816; x-forefront-prvs: 0834BAF534 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(43784003)(377424004)(189002)(377454003)(199003)(13464003)(5001960100002)(54356999)(74316001)(3846002)(81156007)(102836003)(76576001)(15975445007)(1096002)(1220700001)(101416001)(11100500001)(99286002)(106356001)(105586002)(97736004)(586003)(5003600100002)(2900100001)(106116001)(5001770100001)(33656002)(19580395003)(6116002)(50986999)(5002640100001)(189998001)(5008740100001)(66066001)(19580405001)(2906002)(87936001)(10400500002)(77096005)(4326007)(3470700001)(230783001)(3280700002)(5890100001)(5004730100002)(40100003)(86362001)(2501003)(122556002)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB1816; H:BY2PR0501MB1813.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2016 16:45:29.7159 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB1816 Archived-At: Cc: Rahul Aggarwal , Yuanlong Jiang , Wim Henderickx Subject: [Pals] FW: New Version Notification for draft-ietf-pals-endpoint-fast-protection-02.txt 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, 27 Jan 2016 16:45:34 -0000 RGVhciBQQUxTIFdHIGFuZCBjaGFpcnMsDQoNCkknZCBsaWtlIHRvIGluZm9ybSB5b3UgYWJvdXQg dGhpcyBuZXcgcmV2aXNpb24gKC0wMikgb2YgdGhlIGRyYWZ0LiANCg0KSW4gdGhpcyByZXZpc2lv biwgd2UgaGF2ZSBhZGRyZXNzZWQgYWxsIHRoZSBjb21tZW50cyBmcm9tIHRoZSBMQy4gU3BlY2lm aWNhbGx5LCB0aGUgc2VjdGlvbnMgNC4xLCA0LjIsIDQuMy4yLCA0LjUsIGFuZCA3IGhhdmUgYmVl biB1cGRhdGVkIHRvIHBhcnRpY3VsYXJseSBhZGRyZXNzIHRoZSBjb21tZW50cyBmcm9tIFN0ZXdh cmQgQnJ5YW50IGFuZCBNYWNoIENoZW4uIFRoYW5rcyBhZ2FpbiBmb3IgdGhlaXIgZGV0YWlsZWQg cmV2aWV3LiBXZSBiZWxpZXZlIGl0IGhhcyBoZWxwZWQgdXMgaW1wcm92ZSB0aGUgY2xhcmlmeSBv ZiB0aGUgZG9jdW1lbnQuDQoNCg0KUmVnYXJkcywNCg0KL1lpbWluIFNoZW4NCg0KDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5 IDI3LCAyMDE2IDEwOjUwIEFNDQpUbzogWWltaW4gU2hlbjsgUmFodWwgQWdnYXJ3YWw7IFdpbSBI ZW5kZXJpY2t4OyBZdWFubG9uZyBKaWFuZw0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1pZXRmLXBhbHMtZW5kcG9pbnQtZmFzdC1wcm90ZWN0aW9uLTAyLnR4dA0K DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLXBhbHMtZW5kcG9pbnQtZmFzdC1w cm90ZWN0aW9uLTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBZaW1p biBTaGVuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0 LWlldGYtcGFscy1lbmRwb2ludC1mYXN0LXByb3RlY3Rpb24NClJldmlzaW9uOgkwMg0KVGl0bGU6 CQlQVyBFbmRwb2ludCBGYXN0IEZhaWx1cmUgUHJvdGVjdGlvbg0KRG9jdW1lbnQgZGF0ZToJMjAx Ni0wMS0yNw0KR3JvdXA6CQlwYWxzDQpQYWdlczoJCTMxDQpVUkw6ICAgICAgICAgICAgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtcGFscy1lbmRwb2ludC1m YXN0LXByb3RlY3Rpb24tMDIudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1wYWxzLWVuZHBvaW50LWZhc3QtcHJvdGVjdGlvbi8N Ckh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1w YWxzLWVuZHBvaW50LWZhc3QtcHJvdGVjdGlvbi0wMg0KRGlmZjogICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXBhbHMtZW5kcG9pbnQtZmFzdC1w cm90ZWN0aW9uLTAyDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBm YXN0IG1lY2hhbmlzbSBmb3IgcHJvdGVjdGluZyBwc2V1ZG93aXJlcw0KICAgYWdhaW5zdCBlZ3Jl c3MgZW5kcG9pbnQgZmFpbHVyZXMsIGluY2x1ZGluZyBlZ3Jlc3MgYXR0YWNobWVudCBjaXJjdWl0 DQogICBmYWlsdXJlLCBlZ3Jlc3MgUEUgZmFpbHVyZSwgbXVsdGktc2VnbWVudCBQVyB0ZXJtaW5h dGluZyBQRSBmYWlsdXJlLA0KICAgYW5kIG11bHRpLXNlZ21lbnQgUFcgc3dpdGNoaW5nIFBFIGZh aWx1cmUuICBPcGVyYXRpbmcgb24gdGhlIGJhc2lzIG9mDQogICBtdWx0aS1ob21lZCBDRSwgcmVk dW5kYW50IFBXcywgdXBzdHJlYW0gbGFiZWwgYXNzaWdubWVudCBhbmQgY29udGV4dA0KICAgc3Bl Y2lmaWMgbGFiZWwgc3dpdGNoaW5nLCB0aGUgbWVjaGFuaXNtIGVuYWJsZXMgbG9jYWwgcmVwYWly IHRvIGJlDQogICBwZXJmb3JtZWQgYnkgdGhlIHJvdXRlciB1cHN0cmVhbSBhZGphY2VudCB0byBh IGZhaWx1cmUuICBUaGUgcm91dGVyDQogICBjYW4gcmVzdG9yZSBhIFBXIGluIHRoZSBvcmRlciBv ZiB0ZW5zIG9mIG1pbGxpc2Vjb25kcywgYnkgcmVyb3V0aW5nDQogICB0cmFmZmljIGFyb3VuZCB0 aGUgZmFpbHVyZSB0byBhIHByb3RlY3RvciB0aHJvdWdoIGEgcHJlLWVzdGFibGlzaGVkDQogICBi eXBhc3MgdHVubmVsLiAgVGhlcmVmb3JlLCB0aGUgbWVjaGFuaXNtIGNhbiBiZSB1c2VkIHRvIHJl ZHVjZQ0KICAgdHJhZmZpYyBsb3NzIGJlZm9yZSBnbG9iYWwgcmVwYWlyIHJlYWN0cyB0byB0aGUg ZmFpbHVyZSBhbmQgdGhlDQogICBuZXR3b3JrIGNvbnZlcmdlcyBvbiB0aGUgdG9wb2xvZ3kgY2hh bmdlcyBkdWUgdG8gdGhlIGZhaWx1cmUuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0K DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0 DQoNCg== From nobody Fri Jan 29 14:37: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 EEA3D1A8F45; Fri, 29 Jan 2016 14:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.903 X-Spam-Level: X-Spam-Status: No, score=-101.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 02yxT7iBb7nD; Fri, 29 Jan 2016 14:36:58 -0800 (PST) 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 3C9751A8BB3; Fri, 29 Jan 2016 14:36:58 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C280C180094; Fri, 29 Jan 2016 14:35:17 -0800 (PST) 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: <20160129223517.C280C180094@rfc-editor.org> Date: Fri, 29 Jan 2016 14:35:17 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, pals@ietf.org, rfc-editor@rfc-editor.org Subject: [Pals] RFC 7771 on Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires 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, 29 Jan 2016 22:37:00 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7771 Title: Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires Author: A. Malis, Ed., L. Andersson, H. van Helvoort, J. Shin, L. Wang, A. D'Alessandro Status: Standards Track Stream: IETF Date: January 2016 Mailbox: agmalis@gmail.com, loa@mail01.huawei.com, huubatwork@gmail.com, jongyoon.shin@sk.com, wangleiyj@chinamobile.com, alessandro.dalessandro@telecomitalia.it Pages: 9 Characters: 19235 Updates: RFC 6870 I-D Tag: draft-ietf-pals-ms-pw-protection-04.txt URL: https://www.rfc-editor.org/info/rfc7771 DOI: http://dx.doi.org/10.17487/RFC7771 In MPLS and MPLS Transport Profile (MPLS-TP) environments, statically provisioned Single-Segment Pseudowires (SS-PWs) are protected against tunnel failure via MPLS-level and MPLS-TP-level tunnel protection. With statically provisioned Multi-Segment Pseudowires (MS-PWs), each segment of the MS-PW is likewise protected from tunnel failures via MPLS-level and MPLS-TP-level tunnel protection. However, static MS-PWs are not protected end-to-end against failure of one of the Switching Provider Edge Routers (S-PEs) along the path of the MS-PW. This document describes how to achieve this protection via redundant MS-PWs by updating the existing procedures in RFC 6870. It also contains an optional approach based on MPLS-TP Linear Protection. 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/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC