From nobody Sun Jul 5 08:21:05 2015 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 A34001A8F46; Sun, 5 Jul 2015 08:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 xxE9wrd84SkU; Sun, 5 Jul 2015 08:21:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA77A1A8BBF; Sun, 5 Jul 2015 08:21:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150705152103.10568.64318.idtracker@ietfa.amsl.com> Date: Sun, 05 Jul 2015 08:21:03 -0700 Archived-At: Cc: pals@ietf.org Subject: [Pals] I-D Action: draft-ietf-pals-mpls-tp-mac-wd-01.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: Sun, 05 Jul 2015 15:21:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire And LDP-enabled Services Working Group of the IETF. Title : MAC Address Withdrawal over Static Pseudowire Authors : Siva Sivabalan Sami Boutros Himanshu Shah Sam Aldrin Mannan Venkatesan Filename : draft-ietf-pals-mpls-tp-mac-wd-01.txt Pages : 10 Date : 2015-07-05 Abstract: This document specifies a mechanism to signal MAC address withdrawal notification using PW Associated Channel (ACH). Such notification is useful when statically provisioned PWs are deployed in VPLS/H-VPLS environment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-mac-wd/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pals-mpls-tp-mac-wd-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-mpls-tp-mac-wd-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 01:24:53 2015 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 2EE351A908C; Mon, 6 Jul 2015 01:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 rCyxa4GvqOGe; Mon, 6 Jul 2015 01:24:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E7D1A9087; Mon, 6 Jul 2015 01:24:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706082450.2547.92483.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 01:24:50 -0700 Archived-At: Cc: pals@ietf.org Subject: [Pals] I-D Action: draft-ietf-pals-mc-pon-01.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: Mon, 06 Jul 2015 08:24:52 -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 PON Protection in MPLS Authors : Yuanlong Jiang Yong Luo Edwin Mallette Yimin Shen Guangtao Zhou Filename : draft-ietf-pals-mc-pon-01.txt Pages : 16 Date : 2015-07-06 Abstract: MPLS is being deployed deeper into operator networks, often to or past the access network node. Separately network access nodes such as PON 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 proposes the 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-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-mc-pon-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 03:10:31 2015 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 1A0FE1ACCE7; Mon, 6 Jul 2015 03:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 oFX7q5Kuo7bF; Mon, 6 Jul 2015 03:10:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC43D1AC42B; Mon, 6 Jul 2015 03:10:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706101026.29386.47606.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 03:10:26 -0700 Archived-At: Cc: pals@ietf.org Subject: [Pals] I-D Action: draft-ietf-pals-mpls-tp-oam-config-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: Mon, 06 Jul 2015 10:10:28 -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 : LDP Extensions for Proactive Operations, Administration and Maintenance Configuration of Dynamic MPLS Transport Profile PseudoWire Authors : Fei Zhang Bo Wu Elisa Bellagamba Mach(Guoyi) Chen Filename : draft-ietf-pals-mpls-tp-oam-config-02.txt Pages : 19 Date : 2015-07-06 Abstract: This document defines extensions to LDP to configure proactive OAM functions for both SS-PW and MS-PW when the PW control plane is used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-oam-config/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pals-mpls-tp-oam-config-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-mpls-tp-oam-config-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 Fri Jul 10 09:02:23 2015 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 A09B11B2CA3 for ; Fri, 10 Jul 2015 09:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Li-iWH-yQuzZ for ; Fri, 10 Jul 2015 09:02:20 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A3371B29D4 for ; Fri, 10 Jul 2015 09:02:20 -0700 (PDT) X-AuditID: c618062d-f799e6d00000329e-8f-559f9140e364 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id B8.73.12958.0419F955; Fri, 10 Jul 2015 11:32:48 +0200 (CEST) Received: from EUSAAMB108.ericsson.se ([147.117.188.125]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0210.002; Fri, 10 Jul 2015 12:02:18 -0400 From: David Sinicrope To: "pals@ietf.org" Thread-Topic: [Pals] PALS IETF 93 Slot Requests - Prague Thread-Index: AQHQuynLlB5nvL+wg0ilpY5nC/QKdg== Date: Fri, 10 Jul 2015 16:02:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_D1C5649018C47Cdavidsinicropeericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZXLonStdh4vxQg/2HZSxOPz/FZrHm3zom i3NP5zA6MHtM+b2R1WPnrLvsHkuW/GQKYI7isklJzcksSy3St0vgyjix+TN7wbqsip6O3YwN jFtjuxg5OSQETCRu3/nBDmGLSVy4t56ti5GLQ0jgKKNEy5QmdghnOaPEtH89LCBVbEAd6zbu AbNFBJQldp2fwghiMwt4Sky608sKYgsLmEt0HLvIClFjIXF1ymp2CFtP4vXWzWC9LAKqEmu3 ngCq4eDgFbCS+LtRAiTMCHTE91NrmCBGikvcejKfCeI4AYkle84zQ9iiEi8f/wMbLwo0cnLH EagHFCX29U9nh+iNl1g96zhYL6+AoMTJmU9YJjCKzEIydhaSsllIyiDiBhLvz81nhrC1JZYt fA1l60ts/HKWEcK2ljg5vZEdWc0CRo5VjBylxalluelGBpsYgZF2TIJNdwfjnpeWhxgFOBiV eHgXbJsXKsSaWFZcmXuIUZqDRUmc1zEqL1RIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY9by G5MTm48urV96cfXOAP+6+3NvJdpYcm19VyG846qY+jXTpvzLmsL8JyI2ml+pPvlRSeais2XU o/Q3rIVHYjvEToecsHnym3nnlJ89d74cPBQ3L+msuvZbwwaP7YkfF/0qv6S7+lhGU+1Nua4V hXxVvqtX31ojePr26tcbGzWVHoiZe81dHqrEUpyRaKjFXFScCACbW8oblQIAAA== Archived-At: Cc: Andrew Malis , Stewart Bryant Subject: Re: [Pals] PALS IETF 93 Slot Requests - Prague 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, 10 Jul 2015 16:02:22 -0000 --_000_D1C5649018C47Cdavidsinicropeericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi All, The PALS agenda is posted at the link below. https://www.ietf.org/proceedings/93/agenda/agenda-93-pals If you requested a slot and I haven=92t allocated one, my apologies, please= complete the form below and send it in reply to this email. Those that have slots allocated, please send me your slides as soon as you = complete them. I will need your slides no later than Tuesday 21 July 2015 23:59:59 Prague = time. If I don=92t have your slides by that time, you risk losing your slot. Thanks! Dave Thanks! Dave From: David A Sinicrope > Date: Monday, June 1, 2015 at 5:47 PM To: "pals@ietf.org" > Cc: Andrew Malis >, Stewart Bry= ant > Subject: [Pals] PALS IETF 93 Slot Requests - Prague Hi All, It=B9s that time again. If you need a presentation slot for the IETF 93 PALS session, please reply = to this email (subject intact) completing the form below. Please use this form and please reply to this email with the subject intact= . (Not doing so probably means your request will not trigger the filter I = use to identify PALS slot requests and be lost in my email, never to be fou= nd. :-) Form: 1. topic (e.g., MPLS and Ethernet OAM Interworking): 2. URL to your draft on Datatracker =96 you only need to provide the file n= ame to the example URL (e.g., http://datatracker.ietf.org/doc/draft-ietf-pw= e3-mpls-eth-oam-iwk/): 3. brief statement of objectives and issues to be discussed and resolved vi= a the presentation during the meeting (e.g., need to address security issu= es and get direction from the WG): 4. requested duration (norm/default is 10 min): 5. speaker Given-name FAMILY-NAME (e.g., Dave SINICROPE): Thanks! Dave --_000_D1C5649018C47Cdavidsinicropeericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <035B42EB23E0134C8404DB9750A0C0D4@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi = All,

The= PALS agenda is posted at the link below.

 

If = you requested a slot and I haven=92t allocated one, my apologies, please co= mplete the form below and send it in reply to this email.

 

Tho= se that have slots allocated, please send me your slides as soon as you com= plete them.

= I will need your slides no later than Tuesday 21 July 2015 23:59:59 Prague time.

 

If = I don=92t have your slides by that time, you risk losing your slot.

Tha= nks!

Dav= e

Thanks!
Dave

From: David A Sinicrope <david.sinicrope@ericsson.com&g= t;
Date: Monday, June 1, 2015 at 5:47 = PM
To: "pals@ietf.org" <pals@i= etf.org>
Cc: Andrew Malis <agmalis@gmail.com>, Stewart Bryant <stbryant@cisco.com>
Subject: [Pals] PALS IETF 93 Slot R= equests - Prague


Hi All,

It=B9s that time again. 

 

If you need a presentation slot for the IETF 93 PALS session, ple= ase reply to this email (subject intact) completing the fo= rm below.   

 

Please use this form and please reply to this email wit= h the subject intact.  (Not doing so probably means your request will = not trigger the filter I use to identify PALS slot requests and be los= t in my email, never to be found. :-)

 

Form:

--_000_D1C5649018C47Cdavidsinicropeericssoncom_-- From nobody Mon Jul 13 11:18:40 2015 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 017951B2D08 for ; Mon, 13 Jul 2015 11:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DP76pnY5Mikd for ; Mon, 13 Jul 2015 11:18:37 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23EB91B2D04 for ; Mon, 13 Jul 2015 11:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2045; q=dns/txt; s=iport; t=1436811517; x=1438021117; h=message-id:date:from:reply-to:mime-version:to:cc:subject; bh=9phYHKvwuNiq8hYpHkN0bm8OCrJ1qDqBv7h6DZvao9s=; b=msRuB/gAhwMi1BPo9zxRqwRgTup+ouZZb+O8SbBZXiuIXffeQOQVbEL3 QjmSQ+OCBoy90iSr/PvCvW8pQt3QrFEZdC9WOKXk2jJbXhmCTxrG/n6rj Pur9UpYf49ooRD41UsoNuGOX3MxbRfq+XBwS8pfiN/gRhR80zVfBM6ghL U=; X-IronPort-AV: E=Sophos;i="5.15,464,1432598400"; d="scan'208,217";a="582943666" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 13 Jul 2015 18:18:35 +0000 Received: from [10.55.98.184] (ams-stbryant-8817.cisco.com [10.55.98.184]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t6DIIY6r024833; Mon, 13 Jul 2015 18:18:34 GMT Message-ID: <55A400FC.6070700@cisco.com> Date: Mon, 13 Jul 2015 19:18:36 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "pals@ietf.org" , draft-ietf-pals-rfc4447bis@tools.ietf.org Content-Type: multipart/alternative; boundary="------------080403050701030007010802" Archived-At: Cc: "pals-chairs@tools.ietf.org" Subject: [Pals] draft-ietf-pals-rfc4447bis IPR poll and WG Last Call X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 18:18:39 -0000 This is a multi-part message in MIME format. --------------080403050701030007010802 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit This email is to initiate both an IPR poll and a WG last call on draft-ietf-pals-rfc4447bis. This draft can be found at https://datatracker.ietf.org/doc/draft-ietf-pals-rfc4447bis/ Please can each of the authors reply to this email confirming that they do not know of any undisclosed IPR related to this draft. Additionally please can any recipient of this email that knows of any undisclosed IPR make that IPR known to the IETF. In view of the impending IETF meeting I propose to run a WG Last Call on this draft until 17th August, i.e. closing two weeks after IETF. - Stewart --------------080403050701030007010802 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
This email is to initiate both an IPR poll and a WG last call
on draft-ietf-pals-rfc4447bis.

This draft can be found at

https://datatracker.ietf.org/doc/draft-ietf-pals-rfc4447bis/

Please can each of the authors reply to this email confirming
that they do not know of any undisclosed IPR related to
this draft. Additionally please can any recipient of this
email that knows of any undisclosed IPR make that IPR
known to the IETF.

In view of the impending IETF meeting I propose to run
a WG Last Call on this draft until 17th August, i.e. closing
two weeks after IETF.

- Stewart
--------------080403050701030007010802-- From nobody Mon Jul 13 11:21:11 2015 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 13DF41B2D0B for ; Mon, 13 Jul 2015 11:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=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 B1YZgKfWEwZM for ; Mon, 13 Jul 2015 11:20:56 -0700 (PDT) Received: from layerfree.net (heronab1.miniserver.com [77.73.2.174]) (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 394AB1B2D1E for ; Mon, 13 Jul 2015 11:20:56 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=173.38.220.57; Received: from ams-giheron-8912.cisco.com (unverified [173.38.220.57]) by layerfree.net (SurgeMail 6.5a) with ESMTP (TLS) id 21169-1293857 for multiple; Mon, 13 Jul 2015 18:17:41 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_3EBCF153-D3AB-4737-BF4A-BE036F87BC31" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Giles Heron In-Reply-To: <55A400FC.6070700@cisco.com> Date: Mon, 13 Jul 2015 19:20:36 +0100 Message-Id: References: <55A400FC.6070700@cisco.com> To: stbryant@cisco.com X-Mailer: Apple Mail (2.2098) X-Authenticated-User: giles@layerfree.net Archived-At: Cc: draft-ietf-pals-rfc4447bis@tools.ietf.org, "pals-chairs@tools.ietf.org" , "pals@ietf.org" Subject: Re: [Pals] draft-ietf-pals-rfc4447bis IPR poll and WG Last Call 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, 13 Jul 2015 18:20:58 -0000 --Apple-Mail=_3EBCF153-D3AB-4737-BF4A-BE036F87BC31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii support, and unaware of any undisclosed IPR. > On 13 Jul 2015, at 19:18, Stewart Bryant wrote: >=20 >=20 > This email is to initiate both an IPR poll and a WG last call=20 > on draft-ietf-pals-rfc4447bis. >=20 > This draft can be found at >=20 > https://datatracker.ietf.org/doc/draft-ietf-pals-rfc4447bis/ = >=20 > Please can each of the authors reply to this email confirming > that they do not know of any undisclosed IPR related to > this draft. Additionally please can any recipient of this=20 > email that knows of any undisclosed IPR make that IPR=20 > known to the IETF. >=20 > In view of the impending IETF meeting I propose to run=20 > a WG Last Call on this draft until 17th August, i.e. closing > two weeks after IETF. >=20 > - Stewart > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals --Apple-Mail=_3EBCF153-D3AB-4737-BF4A-BE036F87BC31 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii support, and unaware of any undisclosed IPR.

On 13 Jul 2015, at 19:18, Stewart Bryant <stbryant@cisco.com> wrote:


This email is to initiate both an IPR poll and a WG last call
on draft-ietf-pals-rfc4447bis.

This draft can be found at

https://datatracker.ietf.org/doc/draft-ietf-pals-rfc4447bis/

Please can each of the authors reply to this email confirming
that they do not know of any undisclosed IPR related to
this draft. Additionally please can any recipient of this
email that knows of any undisclosed IPR make that IPR
known to the IETF.

In view of the impending IETF meeting I propose to run
a WG Last Call on this draft until 17th August, i.e. closing
two weeks after IETF.

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

--Apple-Mail=_3EBCF153-D3AB-4737-BF4A-BE036F87BC31-- From nobody Tue Jul 14 10:55:02 2015 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 96A311A6FEE for ; Tue, 14 Jul 2015 10:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cv8iqmx1kgqn for ; Tue, 14 Jul 2015 10:54:59 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 150E61AD0BA for ; Tue, 14 Jul 2015 10:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8437; q=dns/txt; s=iport; t=1436896466; x=1438106066; h=message-id:date:from:reply-to:mime-version:to:cc:subject; bh=SnAGcL78R3PfeK5tVrBGWL1N8mRiaAkzhooW5grVzA0=; b=C2OHUizHZIl43lABWEYi9eP12ExctqZaNZIB4QMq6UN0ei+U1qVT7yhY RauJ9ShKEehVyevNbdk73i72jEiiJdfLksjK4I3H9PCRPZAYvYJMXBG6b vGz8lxTRYvfUCTR6xJtd+X28xX9Pfe6iFdRhxky8Ka90OS2PCBSgW/5K8 c=; X-IronPort-AV: E=Sophos;i="5.15,473,1432598400"; d="scan'208,217";a="584077766" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 14 Jul 2015 17:54:24 +0000 Received: from [64.103.106.124] (dhcp-bdlk10-data-vlan300-64-103-106-124.cisco.com [64.103.106.124]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t6EHsOMO028580; Tue, 14 Jul 2015 17:54:24 GMT Message-ID: <55A54CDB.3040805@cisco.com> Date: Tue, 14 Jul 2015 18:54:35 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: draft-ietf-pals-rfc4447bis@tools.ietf.org, "pals@ietf.org" Content-Type: multipart/alternative; boundary="------------050201070407070909010204" Archived-At: Cc: "pals-chairs@tools.ietf.org" Subject: [Pals] WGLC comments on draft-ietf-pals-rfc4447bis X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 17:55:01 -0000 This is a multi-part message in MIME format. --------------050201070407070909010204 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Here are my WGLC comments on draft-ietf-pals-rfc4447bis-01.txt SB> You should note in the metadata, abstract and intro that this SB> obsoletes RFC4777 Abstract SB> You have a CW change that should be noted here. 1. Introduction SB> This is the original intro. A number of things have moved SB> on and people are more familiar with the technology SB> than when you first wrote this. SB> It is worth reflecting on whether this is still the SB> right introduction to use 10 years after publication SB> and 13 years since the first WG draft. QoS-related issues are not discussed in this document. SB> QOS needs to be expanded. For the purpose of this document, PE1 will be defined as the ingress router, and PE2 as the egress router. A layer 2 PDU will be received at PE1, encapsulated at PE1, transported and decapsulated at PE2, and transmitted out of PE2. SB> Of course it's not just L2 packets - since you have IP PWs SB> and I am not sure that TDM is really L2. Note that this document was written to address errata in [RFC4447]. 4. Details Specific to Particular Emulated Services 4.1. IP Layer 2 Transport This mode carries IP packets over a pseudowire. The encapsulation used is according to [RFC3032]. The PW control word MAY be inserted between the MPLS label stack and the IP payload. The encapsulation of the IP packets for forwarding on the attachment circuit is implementation specific, is part of the native service processing (NSP) function [RFC3985], and is outside the scope of this document. SB> You might consider just having section 4, rather than empty SB> 4 followed by small section 4.1 6.2. PW Types for which the Control Word is NOT mandatory SB> NOT mandatory is not correct RFC2119 - I think you mean NOT REQUIRED If a system is capable of sending and receiving the control word on PW types for which the control word is not mandatory, then each such PW endpoint MUST be configurable with a parameter that specifies whether the use of the control word is PREFERRED or NOT PREFERRED. SB> (NOT) PREFERRED are not RFC2119 complaint, we need to either use SB> RFC2119 terms of remove the capitals or put them in quotes SB> if the capitalization is formal notation. For each PW, there MUST be a default value of this parameter. This specification does NOT state what the default value should be. SB> I don't think NOT should be capitalised (same below) If a system is NOT capable of sending and receiving the control word on PW types for which the control word is not mandatory, then it behaves exactly as if it were configured for the use of the control word to be NOT PREFERRED. SB> 2119 again with NOT PREFERRED 9. Changes from RFC4447 The changes in this document are mostly minor fixes to spelling and grammar, or clarifications to the text, which were either noted as errata to RFC4447 or found by the editors. However a new section (6.3) on control-word renegotiation by label request message has been added, referencing RFC 6723. The diagram of C-bit handling procedures has also been removed, as the updated diagram in RFC 6723 is now definitive. SB> This should be reflected in the Abstract, and probably moved up to SB> the introduction, or at least a pointer placed in the introduction. 14. Additional Historical Contributing Authors SB> It is convention to put additional names before the authors/editors SB> so that that the authors are at the end of the document. SB> SB> In many cases we know that the original authors have changed SB> their details, and I wonder whether it would not be appropriate SB> to at least say "now at foo corp, email address bar" - Stewart --------------050201070407070909010204 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 
Here are my WGLC comments on draft-ietf-pals-rfc4447bis-01.txt


SB> You should note in the metadata, abstract and intro that this
SB> obsoletes RFC4777

 Abstract


SB> You have a CW change that should be noted here.


1. Introduction

SB> This is the original intro. A number of things have moved
SB> on and people are more familiar with the technology
SB> than when you first wrote this.
SB> It is worth reflecting on whether this is still the 
SB> right introduction to use 10 years after publication
SB> and 13 years since the first WG draft.


   QoS-related issues are not discussed in this document.

SB> QOS needs to be expanded.


   For the purpose of this document, PE1 will be defined as the ingress
   router, and PE2 as the egress router.  A layer 2 PDU will be received
   at PE1, encapsulated at PE1, transported and decapsulated at PE2, and
   transmitted out of PE2.

SB> Of course it's not just L2 packets - since you have IP PWs
SB> and I am not sure that TDM is really L2.

 Note that this document was written to address errata in [RFC4447].



4. Details Specific to Particular Emulated Services

4.1. IP Layer 2 Transport

   This mode carries IP packets over a pseudowire.  The encapsulation
   used is according to [RFC3032].  The PW control word MAY be inserted
   between the MPLS label stack and the IP payload.  The encapsulation
   of the IP packets for forwarding on the attachment circuit is
   implementation specific, is part of the native service processing
   (NSP) function [RFC3985], and is outside the scope of this document.

SB> You might consider just having section 4, rather than empty
SB> 4 followed by small section 4.1



6.2. PW Types for which the Control Word is NOT mandatory

SB> NOT mandatory is not correct RFC2119 - I think you mean NOT REQUIRED

   If a system is capable of sending and receiving the control word on
   PW types for which the control word is not mandatory, then each such
   PW endpoint MUST be configurable with a parameter that specifies
   whether the use of the control word is PREFERRED or NOT PREFERRED.

SB> (NOT) PREFERRED are not RFC2119 complaint, we need to either use
SB> RFC2119 terms of remove the capitals or put them in quotes
SB> if the capitalization is formal notation. 

   For each PW, there MUST be a default value of this parameter.  This
   specification does NOT state what the default value should be.

SB> I don't think NOT should be capitalised (same below)

   If a system is NOT capable of sending and receiving the control word
   on PW types for which the control word is not mandatory, then it
   behaves exactly as if it were configured for the use of the control
   word to be NOT PREFERRED.

SB> 2119 again with NOT PREFERRED








9. Changes from RFC4447

   The changes in this document are mostly minor fixes to spelling and
   grammar, or clarifications to the text, which were either noted as
   errata to RFC4447 or found by the editors.

   However a new section (6.3) on control-word renegotiation by label
   request message has been added, referencing RFC 6723.   The diagram
   of C-bit handling procedures has also been removed, as the updated
   diagram in RFC 6723 is now definitive.

SB> This should be reflected in the Abstract, and probably moved up to
SB> the introduction, or at least a pointer placed in the introduction.





14. Additional Historical Contributing Authors


SB> It is convention to put additional names before the authors/editors
SB> so that that the authors are at the end of the document.
SB>
SB> In many cases we know that the original authors have changed
SB> their details, and I wonder whether it would not be appropriate
SB> to at least say "now at foo corp, email address bar"

- Stewart
--------------050201070407070909010204-- From nobody Sun Jul 19 23:32:28 2015 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 E26EC1A0026 for ; Sun, 19 Jul 2015 23:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 7Zib1LERsCwf for ; Sun, 19 Jul 2015 23:32:24 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCBD01A0025 for ; Sun, 19 Jul 2015 23:32:23 -0700 (PDT) Received: from seven.monoski.com ([31.30.2.5]) (authenticated bits=0) by napoleon.monoski.com (8.14.7/8.14.7) with ESMTP id t6K6WOfs010597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 20 Jul 2015 00:32:26 -0600 (MDT) To: stbryant@cisco.com, "pals@ietf.org" , draft-ietf-pals-rfc4447bis@tools.ietf.org References: <55A400FC.6070700@cisco.com> From: Luca Martini Message-ID: <55AC95EB.1050601@cisco.com> Date: Mon, 20 Jul 2015 00:32:11 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55A400FC.6070700@cisco.com> Content-Type: multipart/alternative; boundary="------------080601090704040404010809" Archived-At: Cc: "pals-chairs@tools.ietf.org" Subject: Re: [Pals] draft-ietf-pals-rfc4447bis IPR poll and WG Last Call 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, 20 Jul 2015 06:32:27 -0000 This is a multi-part message in MIME format. --------------080601090704040404010809 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 07/13/2015 12:18 PM, Stewart Bryant wrote: > This email is to initiate both an IPR poll and a WG last call > on draft-ietf-pals-rfc4447bis. Thanks Stewart. I do not know of any undisclosed IPR. Luca > This draft can be found at > > https://datatracker.ietf.org/doc/draft-ietf-pals-rfc4447bis/ > > Please can each of the authors reply to this email confirming > that they do not know of any undisclosed IPR related to > this draft. Additionally please can any recipient of this > email that knows of any undisclosed IPR make that IPR > known to the IETF. > > In view of the impending IETF meeting I propose to run > a WG Last Call on this draft until 17th August, i.e. closing > two weeks after IETF. > > - Stewart > > > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals --------------080601090704040404010809 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 07/13/2015 12:18 PM, Stewart Bryant wrote:
This email is to initiate both an IPR poll and a WG last call
on draft-ietf-pals-rfc4447bis.
Thanks Stewart.
I do not know of any undisclosed IPR.
Luca

This draft can be found at

https://datatracker.ietf.org/doc/draft-ietf-pals-rfc4447bis/

Please can each of the authors reply to this email confirming
that they do not know of any undisclosed IPR related to
this draft. Additionally please can any recipient of this
email that knows of any undisclosed IPR make that IPR
known to the IETF.

In view of the impending IETF meeting I propose to run
a WG Last Call on this draft until 17th August, i.e. closing
two weeks after IETF.

- Stewart



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

--------------080601090704040404010809-- From nobody Mon Jul 20 06:00:09 2015 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 9D9181A8784 for ; Mon, 20 Jul 2015 06:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 8MYgY7gRcEaq for ; Mon, 20 Jul 2015 06:00:04 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AFA81A876E for ; Mon, 20 Jul 2015 06:00:04 -0700 (PDT) X-AuditID: c6180641-f794d6d000001dfb-1b-55ac88e2a784 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 19.59.07675.2E88CA55; Mon, 20 Jul 2015 07:36:34 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0210.002; Mon, 20 Jul 2015 09:00:02 -0400 From: David Sinicrope To: "pals@ietf.org" Thread-Topic: [Pals] PALS IETF 93 Slot Requests - Prague Thread-Index: AQHQuynLlB5nvL+wg0ilpY5nC/QKdp3kYvIA Date: Mon, 20 Jul 2015 13:00:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_D1D2678C190A01davidsinicropeericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyuXRPlO6jjjWhBp1npS1OPz/FZrHm3zom i3NP5zA6MHtM+b2R1WPnrLvsHkuW/GQKYI7isklJzcksSy3St0vgyrhwm7NgXn3Fl599TA2M V/O7GDk5JARMJF6se8wIYYtJXLi3nq2LkYtDSOAoo8TMFUsYIZzljBLnb/1iAaliA+pYt3EP mC0ioCyx6/wUsG5mAU+JSXd6WUFsYQFziY5jF1khaiwkrk5ZzQ5hG0nMXXEfLM4ioCpx42Mb UC8HB6+AlcTejkqQsBCQ+fXQB2aQMKeAtcSf9UIgYUag276fWsMEsUlc4taT+UwQNwtILNlz nhnCFpV4+fgf2HRRAT2JTyc+skDElSQmLT3HCtEbL3H8/VMwm1dAUOLkzCcsExjFZiEZOwtJ 2SwkZRBxA4n35+YzQ9jaEssWvoay9SU2fjnLOAvoamagq7+ucEJWsoCRYxUjR2lxalluupHh JkZgTB6TYHPcwbjgk+UhRgEORiUe3oS1q0OFWBPLiitzDzFKc7AoifNK++WFCgmkJ5akZqem FqQWxReV5qQWH2Jk4uCUamCcbP1MpXrBp+vsqzZdNF++s7tTWdTd/8+VglSFW7b3Zp7xnKPh Er6ooGYCh9EciY3Besuff/FzOLdq1fVZtw+ssnqx+2fhyq+6tWtsZj03nKTNNdew096qteP3 IsWqTyy77z67UTtTfEbE33B7hxk/v9w+VsxU4rb841q788HTZ0aek1+4yTnBVomlOCPRUIu5 qDgRAEmiB5OqAgAA Archived-At: Cc: Andrew Malis , Stewart Bryant Subject: Re: [Pals] PALS IETF 93 Slot Requests - Prague 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, 20 Jul 2015 13:00:06 -0000 --_000_D1D2678C190A01davidsinicropeericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi All, The final PALS agenda and all slides are posted now. Thanks to the presenters for getting me their slides well in advance of the= deadline. See the agenda at: https://datatracker.ietf.org/meeting/93/materials.html (Give the tools pages time to update.) Please let me know if I missed something or you see an error. Thanks! Dave From: David A Sinicrope > Date: Friday, July 10, 2015 at 12:02 PM To: "pals@ietf.org" > Cc: Andrew Malis >, Stewart Bry= ant > Subject: Re: [Pals] PALS IETF 93 Slot Requests - Prague Hi All, The PALS agenda is posted at the link below. https://www.ietf.org/proceedings/93/agenda/agenda-93-pals If you requested a slot and I haven=92t allocated one, my apologies, please= complete the form below and send it in reply to this email. Those that have slots allocated, please send me your slides as soon as you = complete them. I will need your slides no later than Tuesday 21 July 2015 23:59:59 Prague = time. If I don=92t have your slides by that time, you risk losing your slot. Thanks! Dave Thanks! Dave From: David A Sinicrope > Date: Monday, June 1, 2015 at 5:47 PM To: "pals@ietf.org" > Cc: Andrew Malis >, Stewart Bry= ant > Subject: [Pals] PALS IETF 93 Slot Requests - Prague Hi All, It=B9s that time again. If you need a presentation slot for the IETF 93 PALS session, please reply = to this email (subject intact) completing the form below. Please use this form and please reply to this email with the subject intact= . (Not doing so probably means your request will not trigger the filter I = use to identify PALS slot requests and be lost in my email, never to be fou= nd. :-) Form: 1. topic (e.g., MPLS and Ethernet OAM Interworking): 2. URL to your draft on Datatracker =96 you only need to provide the file n= ame to the example URL (e.g., http://datatracker.ietf.org/doc/draft-ietf-pw= e3-mpls-eth-oam-iwk/): 3. brief statement of objectives and issues to be discussed and resolved vi= a the presentation during the meeting (e.g., need to address security issu= es and get direction from the WG): 4. requested duration (norm/default is 10 min): 5. speaker Given-name FAMILY-NAME (e.g., Dave SINICROPE): Thanks! Dave --_000_D1D2678C190A01davidsinicropeericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi All,
The final PALS agenda and all slides are posted now. 
Thanks to the presenters for getting me their slides well in advance o= f the deadline.

(Give the tools pages time to update.)

Please let me know if I missed something or you see an error.

Thanks!
Dave

From: David A Sinicrope <david.sinicrope@ericsson.com&g= t;
Date: Friday, July 10, 2015 at 12:0= 2 PM
To: "pals@ietf.org" <pals@i= etf.org>
Cc: Andrew Malis <agmalis@gmail.com>, Stewart Bryant <stbryant@cisco.com>
Subject: Re: [Pals] PALS IETF 93 Sl= ot Requests - Prague


Hi = All,

The= PALS agenda is posted at the link below.

 

If = you requested a slot and I haven=92t allocated one, my apologies, please co= mplete the form below and send it in reply to this email.

 

Tho= se that have slots allocated, please send me your slides as soon as you com= plete them.

= I will need your slides no later than Tuesday 21 July 2015 23:59:59 Prague time.

 

If = I don=92t have your slides by that time, you risk losing your slot.

Tha= nks!

Dav= e

Thanks!
Dave

From: David A Sinicrope <david.sinicrope@ericsson.com&g= t;
Date: Monday, June 1, 2015 at 5:47 = PM
To: "pals@ietf.org" <pals@i= etf.org>
Cc: Andrew Malis <agmalis@gmail.com>, Stewart Bryant <stbryant@cisco.com>
Subject: [Pals] PALS IETF 93 Slot R= equests - Prague


Hi All,

It=B9s that time again. 

 

If you need a presentation slot for the IETF 93 PALS session, ple= ase reply to this email (subject intact) completing the fo= rm below.   

 

Please use this form and please reply to this email wit= h the subject intact.  (Not doing so probably means your request will = not trigger the filter I use to identify PALS slot requests and be los= t in my email, never to be found. :-)

 

Form:

--_000_D1D2678C190A01davidsinicropeericssoncom_-- From nobody Mon Jul 20 07:28:29 2015 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 D96591A8902; Mon, 20 Jul 2015 07:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ytejOiPYK41P; Mon, 20 Jul 2015 07:28:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42DAE1A88A4; Mon, 20 Jul 2015 07:28:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150720142825.18598.24985.idtracker@ietfa.amsl.com> Date: Mon, 20 Jul 2015 07:28:25 -0700 Archived-At: Cc: pals@ietf.org Subject: [Pals] I-D Action: draft-ietf-pals-mpls-tp-oam-config-03.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: Mon, 20 Jul 2015 14:28:27 -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 : LDP Extensions for Proactive Operations, Administration and Maintenance Configuration of Dynamic MPLS Transport Profile PseudoWire Authors : Fei Zhang Bo Wu Elisa Bellagamba Mach(Guoyi) Chen Filename : draft-ietf-pals-mpls-tp-oam-config-03.txt Pages : 30 Date : 2015-07-20 Abstract: This document defines extensions to LDP to configure proactive OAM functions for both SS-PW and MS-PW when the PW control plane is used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-oam-config/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pals-mpls-tp-oam-config-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-mpls-tp-oam-config-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 21 01:36:57 2015 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 AF2891B2AF8 for ; Tue, 21 Jul 2015 01:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2j4Ov6BU0TBn for ; Tue, 21 Jul 2015 01:36:54 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127D61B2AF3 for ; Tue, 21 Jul 2015 01:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1786; q=dns/txt; s=iport; t=1437467814; x=1438677414; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=scU2tROpOVABbWlkETp0nQUSDg0u0qj5HS8GvQhtMP4=; b=WmP5yM9flV2S3IYEU3o+Z3ehzrux6J5otfClcTIsjuen1/nxL0UB1h+4 91iTzJwM4BY08NSWW6Z1KWRERj7M4fT1Wvlcxd+Lny3BV/n5dMI8Irlyx oSu5nqte6wjZBO5GGfiIZbCowlf6uS0BwjkVgqYPN6wmFUor5Eow9WzYn w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BBAwCMA65V/4UNJK1cgxNUaQaDHLhiCYF1hh+BFzgUAQEBAQEBAYEKhCojEVcBBhwCJgIEMBUSBIhBDZYFjTqPX5ZTAQEBAQEBAQMBAQEBAQEBARYEgSKSHy+BFAWUUwGMKYFDhyyQHyaCEheBU28BgUaBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,514,1432598400"; d="scan'208";a="170662682" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP; 21 Jul 2015 08:36:54 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t6L8araR013566 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 21 Jul 2015 08:36:53 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.83]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 03:36:53 -0500 From: "Carl Moberg (camoberg)" To: "pals@ietf.org" Thread-Topic: Suggested draft edits related to classifications Thread-Index: AQHQw5BkCaj3ZEHZyUuPa8NT3EL4mA== Date: Tue, 21 Jul 2015 08:36:52 +0000 Message-ID: <206B5183-DC79-4C35-810F-40D942DD370E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.205.232] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Pals] Suggested draft edits related to classifications 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: Tue, 21 Jul 2015 08:36:55 -0000 DQogSGF2aW5nIHJlYWQgdGhyb3VnaCB0aGUgTDJWUE4gYW5kIE1QTFMtYmFzZWQgTVBMUyBWUE4g ZHJhZnRzLCBJIGhhdmUgc29tZSBzdWdnZXN0ZWQgZWRpdHMuDQoNCiBJbiB0aGUgbGlnaHQgb2Yg dGhlIHdvcmsgd2XigJlyZSBkb2luZyBpbiB0aGUgWUFORyBtb2RlbCBjbGFzc2lmaWNhdGlvbiBk cmFmdCAoZHJhZnQtYm9nZGFub3ZpYy1uZXRtb2QteWFuZy1tb2RlbC1jbGFzc2lmaWNhdGlvbikg SSB3b3VsZCBzdWdnZXN0IHRoZSBlZGl0ZWQgd29yZGluZyBiZWxvdyB0byBtYWtlIGl0IGNsZWFy IGVhcmx5IGluIHRoZSBkb2N1bWVudHMgdGhhdCB0aGUgbW9kZWxzIGFyZSBpbnRlbmRlZCBmb3Ig ZGV2aWNlLWxheWVyIGltcGxlbWVudGF0aW9ucyAodnMgY29udHJvbGxlciBvciBvcmNoZXN0cmF0 b3IgbW9kZWxzKS4NCg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC16aHVhbmctcGFs cy1sMnZwbi15YW5nLTAwLnR4dA0KT0xEOg0K4oCc4oCdIg0KVGhpcyBkb2N1bWVudCBkZWZpbmVz IGEgWUFORyBkYXRhIG1vZGVsIHRoYXQgY2FuIGJlIHVzZWQgdG8gY29uZmlndXJlDQphbmQgbWFu YWdlIEwyVlBOLiAgQm90aCBWUFdTIGFuZCBWUExTIGFyZSBzdXBwb3J0ZWQuDQrigJzigJ3igJ0N Cg0KTkVXOg0K4oCc4oCd4oCdDQpUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXR3b3JrIGVsZW1l bnQgWUFORyBNb2RlbCB0aGF0IGRlZmluZSB0aGUNCmRldmljZS1jZW50cmljIGRhdGEgZGVmaW5p dGlvbnMgZm9yIEwyVlBOLiBCb3RoIFZQV1MgYW5kDQpWUExTIGFyZSBzdXBwb3J0ZWQuDQrigJzi gJ0iDQoNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtc2hhaC1wYWxzLW1wbHMtbDJ2 cG4teWFuZy0wMC50eHQNCk9MRDoNCuKAnOKAneKAnQ0KVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2Vz IGEgWUFORyBkYXRhIG1vZGVsIGZvciBNUExTIGJhc2VkIExheWVyIDIgVlBODQpzZXJ2aWNlcyAo TDJWUE4pIFtSRkM0NjY0XSBhcyB3ZWxsIGFzIHN3aXRjaGluZyBiZXR3ZWVuIHRoZSBsb2NhbA0K YXR0YWNobWVudCBjaXJjdWl0cy4NCuKAnOKAneKAnQ0KDQpORVc6DQrigJzigJ0iDQpUaGlzIGRv Y3VtZW50IGludHJvZHVjZXMgYSBuZXR3b3JrIGVsZW1lbnQgWUFORyBNb2RlbCB0aGF0IGRlZmlu ZSB0aGUNCmRldmljZS1jZW50cmljIGRhdGEgZGVmaW5pdGlvbnMgZm9yIE1QTFMgYmFzZWQgTGF5 ZXIgMiBWUE4NCnNlcnZpY2VzIChMMlZQTikgW1JGQzQ2NjRdIGFzIHdlbGwgYXMgc3dpdGNoaW5n IGJldHdlZW4gdGhlIGxvY2FsDQphdHRhY2htZW50IGNpcmN1aXRzLg0K4oCc4oCdIg== From nobody Tue Jul 21 01:51:09 2015 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 7E6C81B2BCD for ; Tue, 21 Jul 2015 01:51:08 -0700 (PDT) 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 zQdUzCBieqyo for ; Tue, 21 Jul 2015 01:51:06 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::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 B47B51B2B03 for ; Tue, 21 Jul 2015 01:51:02 -0700 (PDT) Received: by wgkl9 with SMTP id l9so149967514wgk.1 for ; Tue, 21 Jul 2015 01:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TaZPBjscJffoJ56aHLIBUeGw4bhrrcY5yPNtZ9IfIPo=; b=PpVCGDs2io1o7YFWZusaKW1vTni1w5hduDjTMKAi2HwZ0J9ZkE5xBpoJcrKcfU8PeB TZMA4H54bD7U/yiioAPI45KEGjaw9C8G0mpW/7zHc08n5D09oBEua3AUooTbgCscuuKI i9v0BtKB7X6BoYDUDJVxyPpE8GcIxxvQG+KzQba0c6qs1ohrAkCwR3q+r3+NWpEH2wH8 lrzHOZEvjHiaBIbOa51w43DnN2vumBQXM9vn+HGtGoMkAuXggA0gmpeZIJVwsxaJ+DWi BVpMZKq2zrsppduHLTyRQsaiNRCdETqbQRSOrwYkqVZwhnPCWyWIyroxi9dt5xdeBjVx uHNA== X-Received: by 10.194.89.72 with SMTP id bm8mr65803930wjb.116.1437468661489; Tue, 21 Jul 2015 01:51:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.154.5 with HTTP; Tue, 21 Jul 2015 01:50:42 -0700 (PDT) In-Reply-To: <206B5183-DC79-4C35-810F-40D942DD370E@cisco.com> References: <206B5183-DC79-4C35-810F-40D942DD370E@cisco.com> From: "Andrew G. Malis" Date: Tue, 21 Jul 2015 10:50:42 +0200 Message-ID: To: "Carl Moberg (camoberg)" Content-Type: multipart/alternative; boundary=089e010d868cf1a638051b5ec00c Archived-At: Cc: "pals@ietf.org" Subject: Re: [Pals] Suggested draft edits related to classifications 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: Tue, 21 Jul 2015 08:51:08 -0000 --089e010d868cf1a638051b5ec00c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Carl, Thanks for the comments! draft-shah-pals-mpls-l2vpn-yang is on the PALS agenda on Thursday, so that will be a great opportunity to bring up these comments if you can make ti to the meeting. If not, I'll just make a comment to alert people to read your email. Cheers, Andy On Tue, Jul 21, 2015 at 10:36 AM, Carl Moberg (camoberg) wrote: > > Having read through the L2VPN and MPLS-based MPLS VPN drafts, I have som= e > suggested edits. > > In the light of the work we=E2=80=99re doing in the YANG model classific= ation > draft (draft-bogdanovic-netmod-yang-model-classification) I would suggest > the edited wording below to make it clear early in the documents that the > models are intended for device-layer implementations (vs controller or > orchestrator models). > > > https://www.ietf.org/id/draft-zhuang-pals-l2vpn-yang-00.txt > OLD: > =E2=80=9C=E2=80=9D" > This document defines a YANG data model that can be used to configure > and manage L2VPN. Both VPWS and VPLS are supported. > =E2=80=9C=E2=80=9D=E2=80=9D > > NEW: > =E2=80=9C=E2=80=9D=E2=80=9D > This document defines a network element YANG Model that define the > device-centric data definitions for L2VPN. Both VPWS and > VPLS are supported. > =E2=80=9C=E2=80=9D" > > > https://www.ietf.org/id/draft-shah-pals-mpls-l2vpn-yang-00.txt > OLD: > =E2=80=9C=E2=80=9D=E2=80=9D > This document introduces a YANG data model for MPLS based Layer 2 VPN > services (L2VPN) [RFC4664] as well as switching between the local > attachment circuits. > =E2=80=9C=E2=80=9D=E2=80=9D > > NEW: > =E2=80=9C=E2=80=9D" > This document introduces a network element YANG Model that define the > device-centric data definitions for MPLS based Layer 2 VPN > services (L2VPN) [RFC4664] as well as switching between the local > attachment circuits. > =E2=80=9C=E2=80=9D" > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals > --089e010d868cf1a638051b5ec00c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Carl,

Thanks for the comments!

draft-shah-pals-mpls-l2vpn-yang is on the PALS agenda on T= hursday, so that will be a great opportunity to bring up these comments if = you can make ti to the meeting. If not, I'll just make a comment to ale= rt people to read your email.

Cheers,
An= dy

 --089e010d868cf1a638051b5ec00c-- From nobody Wed Jul 22 02:25:08 2015 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 A0F121AD0B5 for ; Wed, 22 Jul 2015 02:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 qnQK30AZUTHW for ; Wed, 22 Jul 2015 02:25:00 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8361AD0A3 for ; Wed, 22 Jul 2015 02:25:00 -0700 (PDT) Received: from seven.monoski.com (dhcp-b06a.meeting.ietf.org [31.133.176.106]) (authenticated bits=0) by napoleon.monoski.com (8.14.7/8.14.7) with ESMTP id t6M9OcGn013114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 22 Jul 2015 03:24:55 -0600 (MDT) To: stbryant@cisco.com, draft-ietf-pals-rfc4447bis@tools.ietf.org, "pals@ietf.org" References: <55A54CDB.3040805@cisco.com> From: Luca Martini X-Enigmail-Draft-Status: N1110 Message-ID: <55AF614E.1090002@cisco.com> Date: Wed, 22 Jul 2015 03:24:30 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55A54CDB.3040805@cisco.com> Content-Type: multipart/alternative; boundary="------------050406060107010307080903" Archived-At: Cc: "pals-chairs@tools.ietf.org" Subject: Re: [Pals] WGLC comments on draft-ietf-pals-rfc4447bis 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, 22 Jul 2015 09:25:04 -0000 This is a multi-part message in MIME format. --------------050406060107010307080903 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 07/14/2015 11:54 AM, Stewart Bryant wrote: > Here are my WGLC comments on draft-ietf-pals-rfc4447bis-01.txt > > > SB> You should note in the metadata, abstract and intro that this > SB> obsoletes RFC4777 That should be there , if it did not work it's just a bug in the nroff script. The RFC editor will fix this if I rev it , i'll fix it. > Abstract > > > SB> You have a CW change that should be noted here. We should note that this obsoletes 6723. it did not make the header. we'll fix it. > > > 1. Introduction > > SB> This is the original intro. A number of things have moved > SB> on and people are more familiar with the technology > SB> than when you first wrote this. > SB> It is worth reflecting on whether this is still the > SB> right introduction to use 10 years after publication > SB> and 13 years since the first WG draft. > > > QoS-related issues are not discussed in this document. > > SB> QOS needs to be expanded. No, I believe this is one of the terms that does not need expansion. I'll leave it to the RFC editor's judgment. > > For the purpose of this document, PE1 will be defined as the ingress > router, and PE2 as the egress router. A layer 2 PDU will be received > at PE1, encapsulated at PE1, transported and decapsulated at PE2, and > transmitted out of PE2. > > SB> Of course it's not just L2 packets - since you have IP PWs > SB> and I am not sure that TDM is really L2. this is a nit. I do not think that changing this makes it better. In fact i believe it makes it worse. > Note that this document was written to address errata in [RFC4447]. > > > > 4. Details Specific to Particular Emulated Services > > 4.1. IP Layer 2 Transport > > This mode carries IP packets over a pseudowire. The encapsulation > used is according to [RFC3032]. The PW control word MAY be inserted > between the MPLS label stack and the IP payload. The encapsulation > of the IP packets for forwarding on the attachment circuit is > implementation specific, is part of the native service processing > (NSP) function [RFC3985], and is outside the scope of this document. > > SB> You might consider just having section 4, rather than empty > SB> 4 followed by small section 4.1 I like it this way. > > > 6.2. PW Types for which the Control Word is NOT mandatory > > SB> NOT mandatory is not correct RFC2119 - I think you mean NOT REQUIRED RFC2119 does not apply here. > If a system is capable of sending and receiving the control word on > PW types for which the control word is not mandatory, then each such > PW endpoint MUST be configurable with a parameter that specifies > whether the use of the control word is PREFERRED or NOT PREFERRED. > > SB> (NOT) PREFERRED are not RFC2119 complaint, we need to either use > SB> RFC2119 terms of remove the capitals or put them in quotes > SB> if the capitalization is formal notation. We had a very long discussion on these terms 10 years ago, and I am not about to change them or have another discussion now. > For each PW, there MUST be a default value of this parameter. This > specification does NOT state what the default value should be. > > SB> I don't think NOT should be capitalised (same below) > > If a system is NOT capable of sending and receiving the control word > on PW types for which the control word is not mandatory, then it > behaves exactly as if it were configured for the use of the control > word to be NOT PREFERRED. > > SB> 2119 again with NOT PREFERRED > rfc2119 does not apply here. The rule of this document is to highlight the words PREFERRED, and NOT PREFERRED. if you invent bold asci font i'll use it .... otherwise it's capital. > > > > > > > 9. Changes from RFC4447 > > The changes in this document are mostly minor fixes to spelling and > grammar, or clarifications to the text, which were either noted as > errata to RFC4447 or found by the editors. > > However a new section (6.3) on control-word renegotiation by label > request message has been added, referencing RFC 6723. The diagram > of C-bit handling procedures has also been removed, as the updated > diagram in RFC 6723 is now definitive. > > SB> This should be reflected in the Abstract, and probably moved up to > SB> the introduction, or at least a pointer placed in the introduction. > I believe that this should be removed by the RFC editor , so there is no point in moving it. This section was to point out to the WG what the changes where , not for the RFC reader later... > > > > 14. Additional Historical Contributing Authors > > > SB> It is convention to put additional names before the authors/editors > SB> so that that the authors are at the end of the document. > SB> > SB> In many cases we know that the original authors have changed > SB> their details, and I wonder whether it would not be appropriate > SB> to at least say "now at foo corp, email address bar" Maybe I should make this as an historical note ? it's might be quite a task to track down the current addresses, and the current affiliations might not be relevant. Thanks. Luca > - Stewart > > > > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals --------------050406060107010307080903 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 07/14/2015 11:54 AM, Stewart Bryant wrote:
Here are my WGLC comments on draft-ietf-pals-rfc4447bis-01.txt


SB> You should note in the metadata, abstract and intro that this
SB> obsoletes RFC4777
That should be there , if it did not work it's just a bug in the nroff script. The RFC editor will fix this if I rev it , i'll fix it.

  Abstract


SB> You have a CW change that should be noted here.
We should note that this obsoletes 6723. it did not make the header. we'll fix it.

 
 

1. Introduction

SB> This is the original intro. A number of things have moved
SB> on and people are more familiar with the technology
SB> than when you first wrote this.
SB> It is worth reflecting on whether this is still the
SB> right introduction to use 10 years after publication
SB> and 13 years since the first WG draft.


    QoS-related issues are not discussed in this document.

SB> QOS needs to be expanded.
No, I believe this is one of the terms that does not need expansion. I'll leave it to the RFC editor's judgment.


    For the purpose of this document, PE1 will be defined as the ingress
    router, and PE2 as the egress router.  A layer 2 PDU will be received
    at PE1, encapsulated at PE1, transported and decapsulated at PE2, and
    transmitted out of PE2.

SB> Of course it's not just L2 packets - since you have IP PWs
SB> and I am not sure that TDM is really L2.
this is a nit. I do not think that changing this makes it better. In fact i believe it makes it worse.
  Note that this document was written to address errata in [RFC4447].



4. Details Specific to Particular Emulated Services

4.1. IP Layer 2 Transport

    This mode carries IP packets over a pseudowire.  The encapsulation
    used is according to [RFC3032].  The PW control word MAY be inserted
    between the MPLS label stack and the IP payload.  The encapsulation
    of the IP packets for forwarding on the attachment circuit is
    implementation specific, is part of the native service processing
    (NSP) function [RFC3985], and is outside the scope of this document.

SB> You might consider just having section 4, rather than empty
SB> 4 followed by small section 4.1
I like it this way.


6.2. PW Types for which the Control Word is NOT mandatory

SB> NOT mandatory is not correct RFC2119 - I think you mean NOT REQUIRED


RFC2119 does not apply here.
    If a system is capable of sending and receiving the control word on
    PW types for which the control word is not mandatory, then each such
    PW endpoint MUST be configurable with a parameter that specifies
    whether the use of the control word is PREFERRED or NOT PREFERRED.

SB> (NOT) PREFERRED are not RFC2119 complaint, we need to either use
SB> RFC2119 terms of remove the capitals or put them in quotes
SB> if the capitalization is formal notation.
We had a very long discussion on these terms 10 years ago, and I am not about to change them or have another discussion now.
    For each PW, there MUST be a default value of this parameter.  This
    specification does NOT state what the default value should be.

SB> I don't think NOT should be capitalised (same below)

    If a system is NOT capable of sending and receiving the control word
    on PW types for which the control word is not mandatory, then it
    behaves exactly as if it were configured for the use of the control
    word to be NOT PREFERRED.

SB> 2119 again with NOT PREFERRED
rfc2119 does not apply here. The rule of this document is to highlight the words PREFERRED, and NOT PREFERRED.
if you invent bold asci font i'll use it .... otherwise it's capital.






9. Changes from RFC4447

    The changes in this document are mostly minor fixes to spelling and
    grammar, or clarifications to the text, which were either noted as
    errata to RFC4447 or found by the editors.

    However a new section (6.3) on control-word renegotiation by label
    request message has been added, referencing RFC 6723.   The diagram
    of C-bit handling procedures has also been removed, as the updated
    diagram in RFC 6723 is now definitive.

SB> This should be reflected in the Abstract, and probably moved up to
SB> the introduction, or at least a pointer placed in the introduction.
I believe that this should be removed by the RFC editor , so there is no point in moving it.
This section was to point out to the WG what the changes where , not for the RFC reader later...




14. Additional Historical Contributing Authors


SB> It is convention to put additional names before the authors/editors
SB> so that that the authors are at the end of the document.
SB>
SB> In many cases we know that the original authors have changed
SB> their details, and I wonder whether it would not be appropriate
SB> to at least say "now at foo corp, email address bar"
Maybe I should make this as an historical note ?
it's might be quite a task to track down the current addresses, and the current affiliations might not be relevant.

Thanks.
Luca

- Stewart




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

--------------050406060107010307080903-- From nobody Thu Jul 23 03:25:52 2015 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 269C31A0126 for ; Thu, 23 Jul 2015 03:25:51 -0700 (PDT) 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 TBB6yPP4Ry3o for ; Thu, 23 Jul 2015 03:25:49 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (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 CD0691A000E for ; Thu, 23 Jul 2015 03:25:47 -0700 (PDT) Received: by wibud3 with SMTP id ud3so211856682wib.0 for ; Thu, 23 Jul 2015 03:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=75X29EOTk5FF/O0mSywWHwOruEoH3ttuEQnv5o0a+V8=; b=YmlZh3coEz5YRq2D9vQMyU2XYT9pBBO3IsQhj6hDm/mdFNVqnMK2/P2Kj7vPPibtTw A4DapqjjpyLZA5Gu6812vYWlwNLsl0NMT+TWlLmWzQQJg0F+ywTzPGMGXxzl3JBnYdPS bu4lcOqXs7/iOq77zBVSRatnJW8HlPTnw6zr7dG7upGTcvbv2gzgvV9z/NvV5RNZzeuC CCKapg6KtHBnxpGTDhXSDfpsZcYoWuLW1ko5qE4KhaYclu9B3jahFaaR2t1ASua5IWCD V+uby/GweXUDampHGTO6UsvZbmgiLCIZ8K57cBZBscSv9RNWYJ3S2td5e8ASCwrbuZer 8fow== X-Received: by 10.180.80.9 with SMTP id n9mr50077977wix.87.1437647146317; Thu, 23 Jul 2015 03:25:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.87.18 with HTTP; Thu, 23 Jul 2015 03:25:25 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Thu, 23 Jul 2015 12:25:25 +0200 Message-ID: To: "pals@ietf.org" Content-Type: multipart/alternative; boundary=f46d0418254477fb9d051b884fe0 Archived-At: Subject: [Pals] Fwd: Routing Area YANG Coordinators Wiki 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, 23 Jul 2015 10:25:51 -0000 --f46d0418254477fb9d051b884fe0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Palsers, Dave's email below is timely as we have a YANG discussion on the agenda today. If you're doing any work with YANG, or just curious with what's going on with YANG in the routing area, please read and follow. Thanks, Andy ---------- Forwarded message ---------- From: David Sinicrope Date: Tue, Jul 21, 2015 at 4:21 PM Subject: Routing Area YANG Coordinators Wiki To: "routing-discussion@ietf.org" Hi All, http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgYangCoord Above is a link to the Routing Area YANG Coordinators area that was established earlier this year to help track the YANG models being developed in the iETF Routing Area. There are a number of resources on the wiki pages, but the coordinators would like to draw attention specifically to the =E2=80=9CSummary of Routin= g Area YANG Drafts=E2=80=9D (The section with the big red text "** =3D=3D YANG MODEL AUTHORS LOOK HERE = =3D=3D ** *=E2=80=9D* These tables are intended to help summarize and track the YANG drafts in the Routing Area. Draft authors and WG Chairs are requested to keep the wiki table updated as drafts are created and progressed through the document development process. Instructions for completing a table row for a YANG model draft are provided. Questions on the instructions should be directed to the Routing Area YANG Coordinators (Qin Wu=E2=80=8Bbill.wu@huawei.com and David Sinicrope david.sinicrope@ericsson.com ) Thanks for your help and support keeping this information up to date. Thanks, Dave and Qin _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --f46d0418254477fb9d051b884fe0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Palsers,

Dave's email below is time= ly as we have a YANG discussion on the agenda today. If you're doing an= y work with YANG, or just curious with what's going on with YANG in the= routing area, please read and follow.

Thanks,
Andy

---------- Forwarded m= essage ----------
From: David Sinicrope <dav= id.sinicrope@ericsson.com>
Date: Tue, Jul 21, 2015 at 4:21= PM
Subject: Routing Area YANG Coordinators Wiki
To: "routing-discussion@ietf.org" = <routing-discussion@ietf.= org>


Hi All,
Above is a link to the Routing Area YANG Coordinators area that was establi= shed earlier this year to help track the YANG models being developed in the= iETF Routing Area.
There are a number of resources on the= wiki pages, but the coordinators would like to draw attention specifically= to the =E2=80=9CSummary of Routing Area YANG Drafts=E2=80=9D=C2=A0<= /div>
(The section with the big red text &qu= ot;* =3D=3D YANG MODEL AUTHORS LO= OK HERE =3D=3D=C2=A0*=E2=80=9D

These tables are intended to help summarize and track the YANG drafts in th= e Routing Area. =C2=A0 =C2=A0Draft authors and WG Chairs are requested to k= eep the wiki table updated as drafts are created and progressed through the= document development process.=C2=A0 Instructions for completing a table row for a YANG model draft are provided. =C2=A0


Thanks for your help and support keeping this information up to date.<= /div>

Thanks,
Dave and Qin

_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/routin= g-discussion


--f46d0418254477fb9d051b884fe0-- From nobody Fri Jul 24 00:34:31 2015 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 928B91B2FC1 for ; Fri, 24 Jul 2015 00:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0CVw20R-Z97 for ; Fri, 24 Jul 2015 00:34:27 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19CE21B2FB0 for ; Fri, 24 Jul 2015 00:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10456; q=dns/txt; s=iport; t=1437723267; x=1438932867; h=from:to:subject:date:message-id:references:mime-version; bh=dlAgwxbhnK8SwLdY8NcH/ZO8Uusp8C/H5lMr6TTjGDk=; b=elVLxYUshoPb1OiAYNR66VugAB5pmo131vu3RFfC5F75EYOcIcwC7EiR rAZ23bJj0KO01CvsVBFsX7jwtQCZglWTtvOakCoFi1lOt/+spEoks7Rwa ysqLNetjrvWShmhA36ujaeauahT72oWiHT15iT3IrR23MdJe8LZ4T1Dmc g=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A5BQA46rFV/4ENJK1cgxVUaQaDHakzjwAqCYFrAQmFN0oCgUM4FAEBAQEBAQF/C4QjAQEBAwEBAQEgSxALAgEZAwECKwICJwsbAggCBBMOiBgIDbQnlg0BAQEBAQEBAQEBAQEBAQEBAQEBAQEXi02Edg0RgmMvgRQFlGMBgjaBV2iHRoFFRoNXk0IRFYN9b4FHgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,537,1432598400"; d="asc'?scan'208,217";a="18324092" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP; 24 Jul 2015 07:34:25 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t6O7YPXb002824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 24 Jul 2015 07:34:25 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.220]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Fri, 24 Jul 2015 02:34:25 -0500 From: "Carlos Pignataro (cpignata)" To: "pals@ietf.org" Thread-Topic: [L2tpext] I-D Action: draft-ietf-l2tpext-sbfd-discriminator-00.txt Thread-Index: AQHQxaF+yJa+JOxvaU6cSgUwDuY/aw== Date: Fri, 24 Jul 2015 07:34:24 +0000 Message-ID: References: <20150723234352.25359.68074.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.95.167] Content-Type: multipart/signed; boundary="Apple-Mail=_9838BD71-B82A-4C81-BBA3-A997D5BE8E21"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: [Pals] Fwd: [L2tpext] I-D Action: draft-ietf-l2tpext-sbfd-discriminator-00.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: Fri, 24 Jul 2015 07:34:30 -0000 --Apple-Mail=_9838BD71-B82A-4C81-BBA3-A997D5BE8E21 Content-Type: multipart/alternative; boundary="Apple-Mail=_2CCD7C59-B86B-4D5D-A215-A5EEF9CBFFBE" --Apple-Mail=_2CCD7C59-B86B-4D5D-A215-A5EEF9CBFFBE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Regarding one question yesterday when I presented this slot: 5. 10 min - Seamless-BFD for VCCV - Carlos PIGNATARO = http://datatracker.ietf.org/doc/draft-gp-l2tpext-sbfd-discriminator/ and http://datatracker.ietf.org/doc/draft-gp-pals-seamless-vccv/ Objective: Present-01 version of SBFD for VCCV, get feedback = from WG and request WG adoption Please see below as draft-ietf-l2tpext-sbfd-discriminator-00.txt posted. Thanks, =E2=80=94 Carlos. > Begin forwarded message: >=20 > From: > Subject: [L2tpext] I-D Action: = draft-ietf-l2tpext-sbfd-discriminator-00.txt > Date: July 23, 2015 at 6:43:52 PM CDT > To: > Cc: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Layer Two Tunneling Protocol = Extensions Working Group of the IETF. >=20 > Title : Advertising S-BFD Discriminators in L2TPv3 > Authors : Vengada Prasad Govindan > Carlos Pignataro > Filename : draft-ietf-l2tpext-sbfd-discriminator-00.txt > Pages : 5 > Date : 2015-07-23 >=20 > Abstract: > This document defines a new AVP for advertising one or more S-BFD > Discriminators using the L2TPv3 Control Protocol AVP. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-l2tpext-sbfd-discriminator/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-l2tpext-sbfd-discriminator-00 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > L2tpext mailing list > L2tpext@ietf.org > https://www.ietf.org/mailman/listinfo/l2tpext --Apple-Mail=_2CCD7C59-B86B-4D5D-A215-A5EEF9CBFFBE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Regarding one question yesterday when I presented this = slot:

  =         5. 10 min - Seamless-BFD for VCCV - = Carlos PIGNATARO
          http://datatracker.ietf.org/doc/draft-gp-l2tpext-sbfd-discrimin= ator/
          = and
          http://datatracker.ietf.org/doc/draft-gp-pals-seamless-vccv/
          Objective: = Present-01 version of SBFD for VCCV, get feedback from WG and = request
          WG = adoption




Begin = forwarded message:

From: = <internet-drafts@ietf.org>
Subject: = [L2tpext] I-D = Action: draft-ietf-l2tpext-sbfd-discriminator-00.txt
Date: = July 23, 2015 at 6:43:52 PM = CDT
To: = <i-d-announce@ietf.org>
Cc: <l2tpext@ietf.org>


A New Internet-Draft is = available from the on-line Internet-Drafts directories.
= This draft is a work item of the Layer Two Tunneling Protocol Extensions = Working Group of the IETF.

=        Title =           : = Advertising S-BFD Discriminators in L2TPv3
=        Authors =         : Vengada Prasad = Govindan
=             &n= bsp;           &nbs= p;Carlos Pignataro
Filename =        : = draft-ietf-l2tpext-sbfd-discriminator-00.txt
Pages =           : 5
= Date =            : = 2015-07-23

Abstract:
=   This document defines a new AVP for advertising one or more = S-BFD
  Discriminators using the L2TPv3 Control = Protocol AVP.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-l2tpext-sbfd-discri= minator/

There's also a htmlized = version available at:
https://tools.ietf.org/html/draft-ietf-l2tpext-sbfd-discriminat= or-00


Please note that it = may take a couple of minutes from the time of submission
until the htmlized version and diff are available at = tools.ietf.org.

Internet-Drafts are also = available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
L2tpext mailing list
L2tpext@ietf.org
https://www.ietf.org/mailman/listinfo/l2tpext

= --Apple-Mail=_2CCD7C59-B86B-4D5D-A215-A5EEF9CBFFBE-- --Apple-Mail=_9838BD71-B82A-4C81-BBA3-A997D5BE8E21 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVseqJAAoJEIXgpQGOZny9qO0QAJp4idzc70nSvjD/eML7i3/v I+Al+uhyldqzw2wAdhnpvG1Zd7e1neDzgFe1XOHg2agd0QR/Qn+ZoPKGWbuRVzY6 mK7b1OFaub+VEMOS6jV24+ohgPkNODJf0vOMHiMvGXl5wajfIHNuKHZc+xor0pJk 4LtKiXELQUkkebIV7+RBHH/CsugftbmQG5cfcd1BvuEFzN2Ucqx1xQrlKJ6dhrWV fkd2Jezi/IBdyPRhEFduRuF+l7o7kDVXzFL2VsGMxwNy086jjZtDmvdl04/r0cCj moRk6+zISJ6YZhztLxSnYnL8JwkltY+xad7Aqilc3xBZiua44bTzX/ELix/0cCtf a+WS+8m0pL42eGR7wC9SlPwEXpftMweBwMXw+QGVAvmNsud+5G3XKE5Iu+vv1rAs Pa441XRaggPvPCOOTsPi2cekOdzarbGz3La3dMKndjarpUodBLsIUNOcu9oHayWc g8JQ2kt4pYoajkjQLcHoBQ0ht61YxAKXOYfpA0RhhnhcvJSKR+dJnG1LtrxeHF4f vhtkeqbF5OZFkKQ281BxZvQox05U5YvcZSG0B6vPn9lSjlwis5AOAjLL1ZqKgJ3T wYn/OvDsh+wnjGOT/Y+/zCtv+H9hq8otJfL3mtfs+g3/2PM89UR6/+2UqYAtZUAI i6mT1VWXPqvfePM85xZ8 =QLwG -----END PGP SIGNATURE----- --Apple-Mail=_9838BD71-B82A-4C81-BBA3-A997D5BE8E21-- From nobody Fri Jul 24 04:17:37 2015 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 1A1271A905B for ; Fri, 24 Jul 2015 04:17:36 -0700 (PDT) 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 p6nFsYZizZh5 for ; Fri, 24 Jul 2015 04:17:34 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 9B3701A9064 for ; Fri, 24 Jul 2015 04:17:31 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so24215567wib.0 for ; Fri, 24 Jul 2015 04:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gsySzta1pjIWGf+VDZr61zeO1X7Um41NBnM3i/xoL+Y=; b=kvG31LWIX6v3I+9fpx7JIJ90iAtLaCaiEpcbTlOoI0KVlU0A16yRDwW81QRPqMJf09 wKaR5+HmfvlY4ySveebjtoA3vYLbAmtOk8pTN/zE67TBHnrH+CgdaCcjvQTOQllbnLJl ihhzQ1nazv2pbM7i1bAKqcbrHDszoXF1WT7cllp0mNyomL/jf5iRGwNB9/MXnlsmHqo7 yipYLed2Yewz4F+2FuYr+o54ZB8Ecb+FFHfHT7B8IHa6apMQC/qKchRaaicUJiT2G3ov vFFeIjGjBWxpMmWOp1aOUwkjSCA2BmmsVvV1b0f9mShaLn4kwheYIp69+Utcx78/R9La LiUw== X-Received: by 10.180.100.74 with SMTP id ew10mr6528516wib.12.1437736650383; Fri, 24 Jul 2015 04:17:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.87.18 with HTTP; Fri, 24 Jul 2015 04:17:10 -0700 (PDT) In-Reply-To: References: <20150723234352.25359.68074.idtracker@ietfa.amsl.com> From: "Andrew G. Malis" Date: Fri, 24 Jul 2015 13:17:10 +0200 Message-ID: To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=14dae9cc9c5a53b891051b9d2658 Archived-At: Cc: "pals@ietf.org" Subject: Re: [Pals] Fwd: [L2tpext] I-D Action: draft-ietf-l2tpext-sbfd-discriminator-00.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: Fri, 24 Jul 2015 11:17:36 -0000 --14dae9cc9c5a53b891051b9d2658 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Carlos, Thanks for the update! Cheers, Andy On Fri, Jul 24, 2015 at 9:34 AM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hi, > > Regarding one question yesterday when I presented this slot: > > 5. 10 min - Seamless-BFD for VCCV - Carlos PIGNATARO > > http://datatracker.ietf.org/doc/draft-gp-l2tpext-sbfd-discriminator/ > and > http://datatracker.ietf.org/doc/draft-gp-pals-seamless-vccv/ > Objective: Present-01 version of SBFD for VCCV, get feedback > from WG and request > WG adoption > > Please see below as draft-ietf-l2tpext-sbfd-discriminator-00.txt posted. > > Thanks, > > =E2=80=94 Carlos. > > Begin forwarded message: > > *From: * > *Subject: **[L2tpext] I-D Action: > draft-ietf-l2tpext-sbfd-discriminator-00.txt* > *Date: *July 23, 2015 at 6:43:52 PM CDT > *To: * > *Cc: * > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Layer Two Tunneling Protocol Extensions > Working Group of the IETF. > > Title : Advertising S-BFD Discriminators in L2TPv3 > Authors : Vengada Prasad Govindan > Carlos Pignataro > Filename : draft-ietf-l2tpext-sbfd-discriminator-00.txt > Pages : 5 > Date : 2015-07-23 > > Abstract: > This document defines a new AVP for advertising one or more S-BFD > Discriminators using the L2TPv3 Control Protocol AVP. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-l2tpext-sbfd-discriminator/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-l2tpext-sbfd-discriminator-00 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > L2tpext mailing list > L2tpext@ietf.org > https://www.ietf.org/mailman/listinfo/l2tpext > > > > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals > > --14dae9cc9c5a53b891051b9d2658 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Carlos,

Thanks for the update!

Cheers,
Andy

On Fri, Jul 24, 2015 at 9:34 AM, Carlos P= ignataro (cpignata) <cpignata@cisco.com> wrote:
Hi,

Regarding one question yesterday when I presented this slot:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A05. 10 min - Seaml= ess-BFD for VCCV - Carlos PIGNATARO
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Objective: Present-01 version of SBFD for VCCV, get feedb= ack from WG and request
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 WG ado= ption

Please see below as=C2=A0draft-ietf-l2tpext-= sbfd-discriminator-00.txt posted.

Thanks,

=E2=80=94 Carlos.

=
Begin forwarded message:

Subject: [L2tpext= ] I-D Action: draft-ietf-l2tpext-sbfd-discriminator-00.txt
Date: July = 23, 2015 at 6:43:52 PM CDT
Cc: <l2tpext@ietf.org>


A New Internet-Draft is available from th= e on-line Internet-Drafts directories.
This draft is a work item of the= Layer Two Tunneling Protocol Extensions Working Group of the IETF.

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Title =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Advertising S-BFD Discriminators in L= 2TPv3
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Authors =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Vengada Prasad Govindan
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Carlos Pigna= taro
Filename =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: draft-ietf-l2tpext-sbfd-discriminator-00.tx= t
Pages =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 5
Date =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0: 2015-07-23

Abstract:
=C2=A0=C2=A0This document = defines a new AVP for advertising one or more S-BFD
=C2=A0=C2=A0Discrim= inators using the L2TPv3 Control Protocol AVP.



The IETF data= tracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-l2tpext-sbfd-discriminator/

There's also a htmlized version available at:=
https://tools.ietf.org/html/draft-ietf-l= 2tpext-sbfd-discriminator-00


Please note th= at it may take a couple of minutes from the time of submission
un= til the htmlized version and diff are available at tools.ietf.org.

Int= ernet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/in= ternet-drafts/

_______________________________________________L2tpext mailing list
L2tpext@ietf.org
https://www.ietf.org/mailman/listinfo/l2tpext=


______________________= _________________________
Pals mailing list
Pals@ietf.org
https://www.ietf.org/mailman/listinfo/pals


--14dae9cc9c5a53b891051b9d2658-- From nobody Fri Jul 24 05:35:39 2015 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 40B751A0149 for ; Fri, 24 Jul 2015 05:35:38 -0700 (PDT) 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 6jEEYnpR6-1C for ; Fri, 24 Jul 2015 05:35:36 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (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 65C241A0117 for ; Fri, 24 Jul 2015 05:35:36 -0700 (PDT) Received: by wibud3 with SMTP id ud3so63610536wib.1 for ; Fri, 24 Jul 2015 05:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=4nsN3UO7iMJPCemRcNd3X0tEcBsxxg5QFNt2MsSVWO0=; b=TSyEyJuktOWvHwFCn0yxP4KFMmjR+aLgyxnpNnVrr8L5cHfc0GLd/0Ed3RdhqNigIV hpXf5SP1BFgftz0WsDRJUFY/L+7joHkrtXqtm0PkHI8e2iRwnm03xLsWfzMjwkzjbOpD 4CJuChVmUauWLM1PJmGtxmeyj8Jpg0l2JpTcRXEq39lsOD39eB11Mn483DY+BDcNNiAc 84BrxBzNOz9anPEKbuGi76AiZcFtUEx+5zls1s/E/7jOMibOzIXEsntarAKj+xK8NUVi Eq7IN4iczF6PYoz1KvoZ3Ke4Mx+xmrSLaJxuObg79wRsT6BsbpOLCcAvSJfg99VmBR40 DQWw== X-Received: by 10.194.22.105 with SMTP id c9mr28216239wjf.120.1437741335162; Fri, 24 Jul 2015 05:35:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.87.18 with HTTP; Fri, 24 Jul 2015 05:35:15 -0700 (PDT) From: "Andrew G. Malis" Date: Fri, 24 Jul 2015 14:35:15 +0200 Message-ID: To: "pals@ietf.org" Content-Type: multipart/alternative; boundary=047d7b5d978f8fb662051b9e3d02 Archived-At: Subject: [Pals] Draft PALS minutes posted 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, 24 Jul 2015 12:35:38 -0000 --047d7b5d978f8fb662051b9e3d02 Content-Type: text/plain; charset=UTF-8 Draft minutes from yesterday's meeting were posted immediately following the meeting (thanks to Dave Sinicrope!). Please read and post comments, if any, to the list. You can find them at http://tools.ietf.org/wg/pals/minutes?item=minutes-93-pals.html . Cheers, Andy --047d7b5d978f8fb662051b9e3d02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Draft minutes from yesterday's meeting were posted imm= ediately following the meeting (thanks to Dave Sinicrope!). Please read and= post comments, if any, to the list. You can find them at=C2=A0http://to= ols.ietf.org/wg/pals/minutes?item=3Dminutes-93-pals.html .

Cheers,
Andy

--047d7b5d978f8fb662051b9e3d02-- From nobody Mon Jul 27 05:38:48 2015 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 DFED11B2D20 for ; Mon, 27 Jul 2015 05:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 valXB18DkN8v for ; Mon, 27 Jul 2015 05:38:45 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 46FB91B2CFA for ; Mon, 27 Jul 2015 05:38:03 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 97A22798EF68F; Mon, 27 Jul 2015 12:37:59 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6RCc04u023949 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jul 2015 14:38:01 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.213]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 27 Jul 2015 14:38:00 +0200 From: "Bocci, Matthew (Matthew)" To: "draft-ietf-pals-redundancy-spe@tools.ietf.org" Thread-Topic: Shepherd's review of draft-ietf-pals-redundancy-spe-01 Thread-Index: AQHQyGkSWnL2Ul9uLUCHdSjrzhW9lQ== Date: Mon, 27 Jul 2015 12:37:59 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_D1DBE4A27EEEBmatthewboccialcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "pals@ietf.org" Subject: [Pals] Shepherd's review of draft-ietf-pals-redundancy-spe-01 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, 27 Jul 2015 12:38:47 -0000 --_000_D1DBE4A27EEEBmatthewboccialcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Authors I am the document shepherd for draft-ietf-pals-redundancy-spe-01. I have r= eviewed the draft, and I think it is mostly ready to go. However, I have a = few suggestions that I think would improve the clarity of the draft. Please= treat these suggestions as last call comments. Introduction: "In some MS-PW scenarios, there are benefits to provide PW redundancy on S= -PEs, such as reducing the burden on the access T-PE nodes, and faster prot= ection switching. =93 I think you are assuming that it is faster because PW status messages have = to propagate through less hops, but I am not sure that makes a huge differe= nce because most deployments are only 2 or 3 hops. Please can you be more e= xplicit. Section 3, S-PE Operations: - I think you need to be more explicit about the mode that each T-PE operat= es in. It looks like T-PE1 has to operate as a master, and T-PE2 and T-PE3 = always act in independent mode. However, the draft doesn=92t explicitly mak= e that statement anywhere (at least not for T-PE2 and T-PE3). Please can yo= u add such a statement? Section 6: Security Considerations. I think you will need to be more explicit. It might help to add an explicit= statement that the requirements that apply to those RFCs apply here. You s= hould also add a reference to RFC6073 here as S-PE security is relevant. Regards Matthew --_000_D1DBE4A27EEEBmatthewboccialcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2A881DF425FAF3428619D3499D2DEF62@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
Authors

I am the document shepherd for draft-ietf-pals-redundancy-spe-01.  I h= ave reviewed the draft, and I think it is mostly ready to go. However, I ha= ve a few suggestions that I think would improve the clarity of the draft. P= lease treat these suggestions as last call comments.

Introduction:
"In some MS= -PW scenarios, there are benefits to provide PW redundancy  on S-PEs, such as reducing the burden on the access T-PE nodes, and faster protection switching. =93
I think you are assuming that it is faster because PW status messag= es have to propagate through less hops, but I am not sure that makes a huge difference because most deployments are only= 2 or 3 hops. Please can you be more explicit.
Sec= tion 3, S-PE Operations:
-&n= bsp;I think you need to be more explicit about the mode that each T-PE = ;operates in. It looks like T-PE1 has to operate as a master, and T-PE= 2 and T-PE3 always act in independent mode. However, the draft doesn=92t explicitly make that statement anywhere (at least not = for T-PE2 and T-PE3). Please can you add such a statement?
Sec= tion 6: Security Considerations.
I think you will need to be more explicit. It might help to add an = explicit statement that the requirements that apply to those RFCs apply here. You should also add a reference to RFC6073= here as S-PE security is relevant.
Reg= ards
Mat= thew
--_000_D1DBE4A27EEEBmatthewboccialcatellucentcom_-- From nobody Mon Jul 27 07:18:49 2015 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 F1A9E1B2E36 for ; Mon, 27 Jul 2015 07:18:47 -0700 (PDT) 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 wSwn-ykW6j0l for ; Mon, 27 Jul 2015 07:18:46 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D2951B2E26 for ; Mon, 27 Jul 2015 07:18:40 -0700 (PDT) Received: by wibud3 with SMTP id ud3so118141028wib.0 for ; Mon, 27 Jul 2015 07:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=m6mmJK+6DO9lKBnRdqpPKk9yokpiJAkSbcyAgWIrTO4=; b=CNUwsQ29eCwF1SSSprQOGJJg0flksHrBFq0IB+EDWYJKNckV6875S6cUxlsbZlIWZh /Qhp+MfrZlw3XPlIrElP8vval0CYqotouWMvxf94bbnMuFgd+dasN6cN9VnTutgviIKs LkGU5M0/DEqDvX+vKqYYNhnes/u0aswfxPvCQGhQ7Vcuq05O2e+uu73KKRuXNQzvqTbG HqPgZbj+y19D4Y45rDArQ0jANZPEFNL04fkzTMkIy457VARkJWMngC7x2YQcXGxffiIg uSKlotqEeP1RdQxDWT+kJptFuIpNeFUgrC552UDX2nvSSG7sq1tr2iclk3k8eaGWCe9f Q7WA== X-Received: by 10.181.13.230 with SMTP id fb6mr23114045wid.47.1438006719265; Mon, 27 Jul 2015 07:18:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.87.18 with HTTP; Mon, 27 Jul 2015 07:18:19 -0700 (PDT) From: "Andrew G. Malis" Date: Mon, 27 Jul 2015 10:18:19 -0400 Message-ID: To: "pals@ietf.org" , draft-gp-pals-seamless-vccv@tools.ietf.org Content-Type: multipart/alternative; boundary=f46d043c05bcafc3b0051bdc0793 Archived-At: Subject: [Pals] draft-gp-pals-seamless-vccv IPR poll and WG adoption poll X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 14:18:48 -0000 --f46d043c05bcafc3b0051bdc0793 Content-Type: text/plain; charset=UTF-8 This email is to initiate both an IPR poll and a WG adoption poll on draft-gp-pals-seamless-vccv. This draft can be found at https://tools.ietf.org/html/draft-gp-pals-seamless-vccv-01 Please can each of the authors reply to this email confirming whether or not they are aware of any undisclosed IPR related to this draft. Additionally, please can any recipient of this email that knows of any undisclosed IPR make that IPR known to the IETF. This WG adoption poll will end in two weeks, on August 10. Thanks, Andy --f46d043c05bcafc3b0051bdc0793 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This email is to initiate both an IPR poll and a WG adopti= on poll on draft-gp-pals-seamless-vccv.

This draft can be found at

https://= tools.ietf.org/html/draft-gp-pals-seamless-vccv-01

Please can ea= ch of the authors reply to this email confirming=C2=A0whether or not they a= re aware of any undisclosed IPR related to=C2=A0this draft. Additionally, p= lease can any recipient of this=C2=A0email that knows of any undisclosed IP= R make that IPR=C2=A0known to the IETF.

This WG adoption poll will end in two weeks, on August = 10.

Thanks,
Andy

--f46d043c05bcafc3b0051bdc0793-- From nobody Mon Jul 27 07:27:48 2015 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 BDCED1B2E5C for ; Mon, 27 Jul 2015 07:27:46 -0700 (PDT) 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 Lw08_3Pg_MH9 for ; Mon, 27 Jul 2015 07:27:44 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (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 C2E921B2E5A for ; Mon, 27 Jul 2015 07:27:43 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so119420368wib.1 for ; Mon, 27 Jul 2015 07:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PVIOrJe3ExHwRLEGckmqTxYuhRZgek9VvzIM9ndiRjo=; b=WMOMkBf4UAWBOs518Mb4VEIxGxqF9RtcOdHBns0r4MZCpHMOvgfa9turnJwDoOsnwA 8JKW0u6qI9gL7Yi/nYjkDYPj5Mzfza0X5hSghB2PH1SQaQ9jfbgxEIPJ5fiH6ln+MOUC xRjc5+Fkkhtjnf7A8zwh0dcH98vWwOuDIeIDSMbeEDOfs3fPM7uteCbifyFx+uJk9u+P IOaPCBJt5WyW8qS0YeAJ1O5vNSMZwICTbow0EftCeA424qW52iVs5QwmTbLIY7mb3iWR gDgIzfkZMW9vAtF52niaE+jRaDYua8B4YHjy1eLYJlZyfrShdKH0yEPZ0GlGHrXPQ1/2 ds7Q== X-Received: by 10.194.23.167 with SMTP id n7mr53166387wjf.112.1438007262545; Mon, 27 Jul 2015 07:27:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.87.18 with HTTP; Mon, 27 Jul 2015 07:27:23 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Mon, 27 Jul 2015 10:27:23 -0400 Message-ID: To: "Bocci, Matthew (Matthew)" Content-Type: multipart/alternative; boundary=047d7b5d33ee118c12051bdc2849 Archived-At: Cc: "draft-ietf-pals-redundancy-spe@tools.ietf.org" , "pals@ietf.org" Subject: Re: [Pals] Shepherd's review of draft-ietf-pals-redundancy-spe-01 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, 27 Jul 2015 14:27:46 -0000 --047d7b5d33ee118c12051bdc2849 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just a note on process for this draft ... The draft completed WG last call in early May, and was updated at that time to reflect last call comments. Matthew, as the Document Shepherd, has just completed his review and had some additional comments. Authors, please update the draft to address these comments. Once we have a final revision, Matthew will complete the Shepherd's writeup to the IESG and Stewart and I submit the draft for publication. I'll update the datatracker to reflect this status. Thanks, Andy On Mon, Jul 27, 2015 at 8:37 AM, Bocci, Matthew (Matthew) < matthew.bocci@alcatel-lucent.com> wrote: > Authors > > I am the document shepherd for draft-ietf-pals-redundancy-spe-01. I > have reviewed the draft, and I think it is mostly ready to go. However, I > have a few suggestions that I think would improve the clarity of the draf= t. > Please treat these suggestions as last call comments. > > Introduction: > "In some MS-PW scenarios, there are benefits to provide PW redundancy on > S-PEs, such as reducing the burden on the access T-PE nodes, and faster > protection switching. =E2=80=9C > I think you are assuming that it is faster because PW status messages > have to propagate through less hops, but I am not sure that makes a huge > difference because most deployments are only 2 or 3 hops. Please can you = be > more explicit. > > Section 3, S-PE Operations: > - I think you need to be more explicit about the mode that each > T-PE operates in. It looks like T-PE1 has to operate as a master, and T-P= E2 > and T-PE3 always act in independent mode. However, the draft doesn=E2=80= =99t > explicitly make that statement anywhere (at least not for T-PE2 and T-PE3= ). > Please can you add such a statement? > > > Section 6: Security Considerations. > I think you will need to be more explicit. It might help to add an > explicit statement that the requirements that apply to those RFCs apply > here. You should also add a reference to RFC6073 here as S-PE security is > relevant. > > Regards > > Matthew > > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals > > --047d7b5d33ee118c12051bdc2849 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just a note on process for this draft ...

The draft completed WG last call in early May, and was updated at that t= ime to reflect last call comments. Matthew, as the Document Shepherd, has j= ust completed his review and had some additional comments.

Authors, please update the draft to address these comments.
<= div>
Once we have a final revision, Matthew will complete the= Shepherd's writeup to the IESG and Stewart and I submit the draft for = publication.

I'll update the datatracker to re= flect this status.

Thanks,
Andy


On Mon, Jul 27, 2015 at 8:37 AM, Bocci, Matthew (Matthew) <matthew.bocci@alcatel-lucent.com> wrote:
Authors

I am the document shepherd for draft-ietf-pals-redundancy-spe-01.=C2=A0 I h= ave reviewed the draft, and I think it is mostly ready to go. However, I ha= ve a few suggestions that I think would improve the clarity of the draft. P= lease treat these suggestions as last call comments.

Introduction:
"In some MS-PW scena= rios, there are benefits to provide PW redundancy =C2=A0on S-PEs, such as reducing the burden on the access T-PE nodes, and=C2=A0faster protection switching.=C2=A0=E2=80=9C
I= =C2=A0think you are assuming that it is faster because PW status messages h= ave to=C2=A0propagate=C2=A0through less hops, but=C2=A0I am not sure that makes a huge difference because most deployments are only= 2 or 3 hops. Please can you be more explicit.

Secti= on 3, S-PE Operations:
-=C2= =A0I think you need to be more explicit about the mode that each T-PE=C2=A0= operates=C2=A0in. It looks like T-PE1 has to operate as a master, and T-PE2= and T-PE3 always act in independent mode. However, the draft doesn=E2=80=99t explicitly make that statement anywhere (at leas= t not for T-PE2 and T-PE3). Please can you add such a statement?


Secti= on 6: Security Considerations.
I= =C2=A0think you will need to be more explicit. It might help to add an expl= icit statement that the requirements that apply to those RFCs apply here. You should also add a reference to RFC6073= here as S-PE security is relevant.

Regar= ds

Matth= ew

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


--047d7b5d33ee118c12051bdc2849-- From nobody Mon Jul 27 08:56:22 2015 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 C03731A8AD0 for ; Mon, 27 Jul 2015 08:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-9XYwNARATd for ; Mon, 27 Jul 2015 08:56:20 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ADD91A8AF6 for ; Mon, 27 Jul 2015 08:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7018; q=dns/txt; s=iport; t=1438012580; x=1439222180; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=qLIiZ0lZVl0pgcW5xI+MQ84B+bq4TVa87a/85X8NCSs=; b=cKi+pLYRi8Z2cPK5fqS3RhWaiZy2mmmfAhTKBiNal35/v6Ii1u3L2T37 eM8DEz0BuGOUwnD8v7NU0cDy2AM+y4FtyRvEifjHw1QGLgkQg9NMkWU4A xoF61sqSEtPoHpMsRLhSzSCsAaxC6PNcPMj4GyUELB9vs0OYb+ycbI+Ju U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CqBQBwU7ZV/5RdJa1bgkhNVGkGgx24foF3hXkCHIEmORMBAQEBAQEBgQqEIwEBAQQjClwCAQgRBAEBCx0DAgICMBQJCAIEARIIiCUBDbtClXcBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItOhCQRASAtCgGCaS+BFAWUaQGEd4kOhB2TRCZkgxlvgQ46gQQBAQE X-IronPort-AV: E=Sophos; i="5.15,555,1432598400"; d="scan'208,217"; a="13474408" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-9.cisco.com with ESMTP; 27 Jul 2015 15:56:19 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t6RFuJvQ002324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jul 2015 15:56:19 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.77]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Mon, 27 Jul 2015 10:56:19 -0500 From: "Vengada Prasad Govindan (venggovi)" To: "Andrew G. Malis" , "pals@ietf.org" , "draft-gp-pals-seamless-vccv@tools.ietf.org" Thread-Topic: [Pals] draft-gp-pals-seamless-vccv IPR poll and WG adoption poll Thread-Index: AQHQyHcrKSNnTLaIwkS7DNOexqrAVZ3veHtQ Date: Mon, 27 Jul 2015 15:56:18 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D545EDCAC@xmb-rcd-x15.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.70.232.63] Content-Type: multipart/alternative; boundary="_000_315041E4211CB84E86EF7C25A2AB583D545EDCACxmbrcdx15ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [Pals] draft-gp-pals-seamless-vccv IPR poll and WG adoption poll X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 15:56:21 -0000 --_000_315041E4211CB84E86EF7C25A2AB583D545EDCACxmbrcdx15ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQW5keS8gV0csDQogIEFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhp cyBkcmFmdC4NClRoYW5rcw0KUHJhc2FkDQoNCkZyb206IFBhbHMgW21haWx0bzpwYWxzLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmRyZXcgRy4gTWFsaXMNClNlbnQ6IE1vbmRheSwg SnVseSAyNywgMjAxNSA3OjE4IEFNDQpUbzogcGFsc0BpZXRmLm9yZzsgZHJhZnQtZ3AtcGFscy1z ZWFtbGVzcy12Y2N2QHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBbUGFsc10gZHJhZnQtZ3AtcGFs cy1zZWFtbGVzcy12Y2N2IElQUiBwb2xsIGFuZCBXRyBhZG9wdGlvbiBwb2xsDQoNClRoaXMgZW1h aWwgaXMgdG8gaW5pdGlhdGUgYm90aCBhbiBJUFIgcG9sbCBhbmQgYSBXRyBhZG9wdGlvbiBwb2xs IG9uIGRyYWZ0LWdwLXBhbHMtc2VhbWxlc3MtdmNjdi4NCg0KVGhpcyBkcmFmdCBjYW4gYmUgZm91 bmQgYXQNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdwLXBhbHMtc2VhbWxl c3MtdmNjdi0wMQ0KDQpQbGVhc2UgY2FuIGVhY2ggb2YgdGhlIGF1dGhvcnMgcmVwbHkgdG8gdGhp cyBlbWFpbCBjb25maXJtaW5nIHdoZXRoZXIgb3Igbm90IHRoZXkgYXJlIGF3YXJlIG9mIGFueSB1 bmRpc2Nsb3NlZCBJUFIgcmVsYXRlZCB0byB0aGlzIGRyYWZ0LiBBZGRpdGlvbmFsbHksIHBsZWFz ZSBjYW4gYW55IHJlY2lwaWVudCBvZiB0aGlzIGVtYWlsIHRoYXQga25vd3Mgb2YgYW55IHVuZGlz Y2xvc2VkIElQUiBtYWtlIHRoYXQgSVBSIGtub3duIHRvIHRoZSBJRVRGLg0KVGhpcyBXRyBhZG9w dGlvbiBwb2xsIHdpbGwgZW5kIGluIHR3byB3ZWVrcywgb24gQXVndXN0IDEwLg0KDQpUaGFua3Ms DQpBbmR5DQoNCg== --_000_315041E4211CB84E86EF7C25A2AB583D545EDCACxmbrcdx15ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IZWxsbyBBbmR5LyBXRyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7IEFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhpcyBkcmFmdC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlByYXNhZDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBQ YWxzIFttYWlsdG86cGFscy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5B bmRyZXcgRy4gTWFsaXM8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKdWx5IDI3LCAyMDE1IDc6 MTggQU08YnI+DQo8Yj5Ubzo8L2I+IHBhbHNAaWV0Zi5vcmc7IGRyYWZ0LWdwLXBhbHMtc2VhbWxl c3MtdmNjdkB0b29scy5pZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbUGFsc10gZHJhZnQt Z3AtcGFscy1zZWFtbGVzcy12Y2N2IElQUiBwb2xsIGFuZCBXRyBhZG9wdGlvbiBwb2xsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBlbWFpbCBpcyB0byBpbml0aWF0 ZSBib3RoIGFuIElQUiBwb2xsIGFuZCBhIFdHIGFkb3B0aW9uIHBvbGwgb24gZHJhZnQtZ3AtcGFs cy1zZWFtbGVzcy12Y2N2LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NClRoaXMgZHJhZnQg Y2FuIGJlIGZvdW5kIGF0PGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWdwLXBhbHMtc2VhbWxlc3MtdmNjdi0wMSI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWdwLXBhbHMtc2VhbWxlc3MtdmNjdi0wMTwvYT48YnI+DQo8YnI+DQpQ bGVhc2UgY2FuIGVhY2ggb2YgdGhlIGF1dGhvcnMgcmVwbHkgdG8gdGhpcyBlbWFpbCBjb25maXJt aW5nJm5ic3A7d2hldGhlciBvciBub3QgdGhleSBhcmUgYXdhcmUgb2YgYW55IHVuZGlzY2xvc2Vk IElQUiByZWxhdGVkIHRvJm5ic3A7dGhpcyBkcmFmdC4gQWRkaXRpb25hbGx5LCBwbGVhc2UgY2Fu IGFueSByZWNpcGllbnQgb2YgdGhpcyZuYnNwO2VtYWlsIHRoYXQga25vd3Mgb2YgYW55IHVuZGlz Y2xvc2VkIElQUiBtYWtlIHRoYXQgSVBSJm5ic3A7a25vd24gdG8gdGhlIElFVEYuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIFdHIGFkb3B0 aW9uIHBvbGwgd2lsbCBlbmQgaW4gdHdvIHdlZWtzLCBvbiBBdWd1c3QgMTAuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_315041E4211CB84E86EF7C25A2AB583D545EDCACxmbrcdx15ciscoc_-- From nobody Mon Jul 27 12:08:55 2015 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 432411B328D for ; Mon, 27 Jul 2015 12:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_SOFTFAIL=0.665] 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 EczwkjFtQ_rc for ; Mon, 27 Jul 2015 12:08:51 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B9E71B328A for ; Mon, 27 Jul 2015 12:08:51 -0700 (PDT) Received: from seven.monoski.com (printer-sj-20-2-128-107-130-163.cisco.com [128.107.130.163]) (authenticated bits=0) by napoleon.monoski.com (8.14.7/8.14.7) with ESMTP id t6RJ8nK5003151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 27 Jul 2015 13:08:50 -0600 (MDT) To: "pals@ietf.org" From: Luca Martini X-Enigmail-Draft-Status: N1110 Message-ID: <55B681BC.20508@cisco.com> Date: Mon, 27 Jul 2015 13:08:44 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Pals] RFC4447bis LC and label request/response discussion in Prague 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, 27 Jul 2015 19:08:54 -0000 Folks, Some of you brought up the fact the in the current rfc4447bis update document it is not clear that we require a full implementation of the LDP protocol specified in rfc5036. In particular the part that is assumed, thought rfc4447bis is that any implementation of this protocol MUST implement responding to remote label mapping request messages. I propose the following update to the text : OLD: LDP MUST exchange PW FEC label bindings in downstream unsolicited manner, independent of the negotiated label advertisement mode of the LDP session according to the specifications in specified in [RFC7358]. LDP's "liberal label retention" mode SHOULD be used. NEW: LDP MUST exchange PW FEC label bindings in downstream unsolicited manner, independent of the negotiated label advertisement mode of the LDP session according to the specifications in specified in [RFC7358]. LDP's "liberal label retention" mode SHOULD be used. However all the LDP procedures specified in [RFC5036] MUST be implemented, and specifically the procedures in section 3.5.7. "Label Mapping Message", and 3.5.8. "Label Request Message". Does this work ? Any other suggestions ? Thanks. Luca From nobody Mon Jul 27 12:59:51 2015 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 B7C9A1B3362 for ; Mon, 27 Jul 2015 12:59:50 -0700 (PDT) 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 ES1nPZ4HVsNX for ; Mon, 27 Jul 2015 12:59:48 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674431B3364 for ; Mon, 27 Jul 2015 12:59:48 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so127746929wib.0 for ; Mon, 27 Jul 2015 12:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dWMyUY+LB7kqAexnkXzeFxzF+qM9WxK5uoF4t7G9cyI=; b=sE0h/H9T+l8FYr11RmW/69HnsUjJvy9kneumzswF5vVlUsqZeSzd+0FVmQbD5LG2mA q1qajk25MrUk7c0VHY9DgxWFCfgwp/vCnGhuyCsdxtxCYoSWWBsyka9w9Jx+Ui0wjycH hGlbEvLm67Psopyqe/gDKn9GBR5oFeiCQo1V5f0IyUhwYQlFBbn9jmJBt1yssLePFOJs KcqphSmFGmgz1QlW0GHfACDkEzIemX1ro4YuXCiHOB18oKFXc16+HQ7L7Qaxt1PTUAAH VI9X7JaCKzZ55aC9yaZDtb3L38FgqhUgODp3wOuV1DFj/KuW20iR5Bh5Tpvioo80gGME Zl9A== X-Received: by 10.180.230.199 with SMTP id ta7mr11723915wic.1.1438027187153; Mon, 27 Jul 2015 12:59:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.87.18 with HTTP; Mon, 27 Jul 2015 12:59:27 -0700 (PDT) In-Reply-To: <55B681BC.20508@cisco.com> References: <55B681BC.20508@cisco.com> From: "Andrew G. Malis" Date: Mon, 27 Jul 2015 15:59:27 -0400 Message-ID: To: Luca Martini Content-Type: multipart/alternative; boundary=001a1134dc1caaf8e4051be0cb09 Archived-At: Cc: "pals@ietf.org" Subject: Re: [Pals] RFC4447bis LC and label request/response discussion in Prague 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, 27 Jul 2015 19:59:50 -0000 --001a1134dc1caaf8e4051be0cb09 Content-Type: text/plain; charset=UTF-8 Luca, RFC 5036 uses "Downstream Unsolicited mode" rather than "downstream unsolicited manner", so you should change "manner" to "mode" and capitalize Downstream Unsolicited. It also uses "Liberal Label retention mode" (note the capital L's and small r and m). Regarding your new text "However all the LDP procedures specified in [RFC5036] MUST be implemented, and specifically the procedures in section 3.5.7. "Label Mapping Message", and 3.5.8. "Label Request Message".", I would just shorten it to say: "However, all the LDP procedures specified in [RFC5036] MUST be implemented." I don't know if it's necessary to call special attention to those two sections if you have to implement everything anyway. Cheers, Andy On Mon, Jul 27, 2015 at 3:08 PM, Luca Martini wrote: > Folks, > > Some of you brought up the fact the in the current rfc4447bis update > document it is not clear that we require a full implementation of the > LDP protocol specified in rfc5036. > > In particular the part that is assumed, thought rfc4447bis is that any > implementation of this protocol MUST implement responding to remote > label mapping request messages. > > I propose the following update to the text : > > OLD: > > LDP MUST exchange PW FEC label bindings in downstream unsolicited > manner, independent of the negotiated label advertisement mode of the > LDP session according to the specifications in specified in [RFC7358]. > LDP's "liberal label retention" mode SHOULD be used. > > NEW: > > LDP MUST exchange PW FEC label bindings in downstream unsolicited > manner, independent of the negotiated label advertisement mode of the > LDP session according to the specifications in specified in [RFC7358]. > LDP's "liberal label retention" mode SHOULD be used. However all the LDP > procedures specified in [RFC5036] MUST be implemented, and specifically > the procedures in section 3.5.7. "Label Mapping Message", and 3.5.8. > "Label Request Message". > > > Does this work ? > > Any other suggestions ? > > > Thanks. > > Luca > > > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals > --001a1134dc1caaf8e4051be0cb09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Luca,

RFC 5036 uses "Downstream Unsolicited m= ode" rather than "downstrea= m unsolicited=C2=A0manner", so you should change "manner" to "= ;mode" and capitalize=C2=A0Downstream Unsolicited. It also uses "Liberal Label retention mode&quo= t; (note the capital L's and small r and m).=C2=A0

Regardi= ng your new text "However all th= e LDP=C2=A0procedures specified in [R= FC5036] MUST be implemented, and specifically=C2=A0the procedures in section=C2=A0 3.5.7. "Label Mapping Me= ssage", and=C2=A0 =C2=A03.5.8.=C2=A0"Label Request Message".", I would just shorten it to sa= y: "However, all the LDP=C2=A0procedures specified in [RFC5036] MUST = be implemented." I don't know if it's necessary to call specia= l attention to those two sections if you have to implement everything anywa= y.

Cheers,
Andy

On Mon, Jul 27, 2015 at 3:08 PM, Luca Martini <lmartini@= cisco.com> wrote:
Folks,
Some of you brought up the fact the in the current rfc4447bis update
document it is not clear that we require a full implementation of the
LDP protocol specified in rfc5036.

In particular the part that is assumed, thought rfc4447bis is that any
implementation of this protocol MUST implement responding to remote
label mapping request messages.

I propose the following update to the text :

OLD:

LDP MUST exchange PW FEC label bindings in downstream unsolicited
manner, independent of the negotiated label advertisement mode of the
LDP session according to the specifications in specified in [RFC7358].
LDP's "liberal label retention" mode SHOULD be used.

NEW:

LDP MUST exchange PW FEC label bindings in downstream unsolicited
manner, independent of the negotiated label advertisement mode of the
LDP session according to the specifications in specified in [RFC7358].
LDP's "liberal label retention" mode SHOULD be used. However = all the LDP
procedures specified in [RFC5036] MUST be implemented, and specifically
the procedures in section=C2=A0 3.5.7. "Label Mapping Message", a= nd=C2=A0 =C2=A03.5.8.
"Label Request Message".


Does this work ?

Any other suggestions ?


Thanks.

Luca


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

--001a1134dc1caaf8e4051be0cb09-- From nobody Mon Jul 27 13:35:10 2015 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 7C5A61B33A2 for ; Mon, 27 Jul 2015 13:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 866IO2PW9Y5z for ; Mon, 27 Jul 2015 13:35:08 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21E21A88DA for ; Mon, 27 Jul 2015 13:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3936; q=dns/txt; s=iport; t=1438029307; x=1439238907; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fFoHcYnwSlqfh1H53gB9TnRu9GEsy/iDwTTyxwRXAP0=; b=bTJ2rfNdOuZ/+PsZlBkDVWrhb4/WPeD/pzaC/V4h3mBm2wHw7HT10/vZ y7m0zNKx9MJG+Q1KQOFcBk95BUACsyfUZtWEHULXrGmKX6zzRlbrwcAIc W4Z7HcPeexX1VZF17+hVfNUoDeXLRZcs8FrGu5gTUoSGBKs6wQdxL5cc9 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BBAwCglLZV/5pdJa1bgxVUabwbCYFtAQmFeQKBRzgUAQEBAQEBAYEKhCQBAQQBAQFrCxACAQgEOwchBgsUEQIEDgWIGQMSDctwDYUvAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLToJOgVYRAU0EB4MYgRQFkWyCfQGEd4VfgWqBRYQdjBmHKyZkgxlvgQ6BPgEBAQ X-IronPort-AV: E=Sophos;i="5.15,557,1432598400"; d="scan'208,217";a="172942005" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP; 27 Jul 2015 20:35:07 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t6RKZ6wb021168 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jul 2015 20:35:07 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.220]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Mon, 27 Jul 2015 15:35:06 -0500 From: "Carlos Pignataro (cpignata)" To: "Andrew G. Malis" Thread-Topic: [Pals] draft-gp-pals-seamless-vccv IPR poll and WG adoption poll Thread-Index: AQHQyHct26aror+qmk27dE0yOfY2BJ3vxoPT Date: Mon, 27 Jul 2015 20:35:05 +0000 Message-ID: <7E5BEFC4-0651-4E94-AA76-AE1590A53BB7@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7E5BEFC406514E94AA76AE1590A53BB7ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-gp-pals-seamless-vccv@tools.ietf.org" , "pals@ietf.org" Subject: Re: [Pals] draft-gp-pals-seamless-vccv IPR poll and WG adoption poll X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 20:35:09 -0000 --_000_7E5BEFC406514E94AA76AE1590A53BB7ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andy, As a co-author, I am not aware of any undisclosed IPR related to this docum= ent. (I also support adoption of this draft by PALS). Thanks! Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Jul 27, 2015, at 16:18, Andrew G. Malis > wrote: This email is to initiate both an IPR poll and a WG adoption poll on draft-= gp-pals-seamless-vccv. This draft can be found at https://tools.ietf.org/html/draft-gp-pals-seamless-vccv-01 Please can each of the authors reply to this email confirming whether or no= t they are aware of any undisclosed IPR related to this draft. Additionally= , please can any recipient of this email that knows of any undisclosed IPR = make that IPR known to the IETF. This WG adoption poll will end in two weeks, on August 10. Thanks, Andy _______________________________________________ Pals mailing list Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals --_000_7E5BEFC406514E94AA76AE1590A53BB7ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Andy,

As a co-author, I am not aware of any undisclosed IPR related to this = document. 

(I also support adoption of this draft by PALS). 

Thanks!

Excuze typofraphicak errows

On Jul 27, 2015, at 16:18, Andrew G. Malis <agmalis@gmail.com> wrote:

This email is to initiate both an IPR poll and a WG adopti= on poll on draft-gp-pals-seamless-vccv.

This draft can be found at

http= s://tools.ietf.org/html/draft-gp-pals-seamless-vccv-01

Please can each of the authors reply to this email confirming whether = or not they are aware of any undisclosed IPR related to this draft. Ad= ditionally, please can any recipient of this email that knows of any u= ndisclosed IPR make that IPR known to the IETF.

This WG adoption poll will end in= two weeks, on August 10.

Thanks,
Andy

_______________________________________________
Pals mailing list
Pals@ietf.org
https://www.ie= tf.org/mailman/listinfo/pals
--_000_7E5BEFC406514E94AA76AE1590A53BB7ciscocom_-- From nobody Mon Jul 27 16:55:29 2015 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 D55DD1A1A07 for ; Mon, 27 Jul 2015 16:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 cRp2JziE7uIj for ; Mon, 27 Jul 2015 16:55:26 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F031A19E3 for ; Mon, 27 Jul 2015 16:55:26 -0700 (PDT) Received: from seven.monoski.com (ip-64-134-234-84.public.wayport.net [64.134.234.84]) (authenticated bits=0) by napoleon.monoski.com (8.14.7/8.14.7) with ESMTP id t6RNtLBj001746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 27 Jul 2015 17:55:22 -0600 (MDT) To: "Andrew G. Malis" References: <55B681BC.20508@cisco.com> From: Luca Martini Message-ID: <55B6C4DC.5020205@cisco.com> Date: Mon, 27 Jul 2015 17:55:08 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "pals@ietf.org" Subject: Re: [Pals] RFC4447bis LC and label request/response discussion in Prague 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, 27 Jul 2015 23:55:28 -0000 On 07/27/2015 01:59 PM, Andrew G. Malis wrote: > Luca, > > RFC 5036 uses "Downstream Unsolicited mode" rather than "downstream unsolicited > manner", so you should change "manner" to "mode" and capitalize Downstream > Unsolicited. It also uses "Liberal Label retention mode" (note the capital L's > and small r and m). yes - Agreed. > Regarding your new text "However all the LDP procedures specified in [RFC5036] > MUST be implemented, and specifically the procedures in section 3.5.7. "Label > Mapping Message", and 3.5.8. "Label Request Message".", I would just shorten > it to say: "However, all the LDP procedures specified in [RFC5036] MUST be > implemented." I don't know if it's necessary to call special attention to those > two sections if you have to implement everything anyway. I agree, but people in the meeting insisted on an explicit mention of those sections. Above text is driven by the comments in the meeting. Let's see if other speak up. Thanks. Luca > Cheers, > Andy > > On Mon, Jul 27, 2015 at 3:08 PM, Luca Martini > wrote: > > Folks, > > Some of you brought up the fact the in the current rfc4447bis update > document it is not clear that we require a full implementation of the > LDP protocol specified in rfc5036. > > In particular the part that is assumed, thought rfc4447bis is that any > implementation of this protocol MUST implement responding to remote > label mapping request messages. > > I propose the following update to the text : > > OLD: > > LDP MUST exchange PW FEC label bindings in downstream unsolicited > manner, independent of the negotiated label advertisement mode of the > LDP session according to the specifications in specified in [RFC7358]. > LDP's "liberal label retention" mode SHOULD be used. > > NEW: > > LDP MUST exchange PW FEC label bindings in downstream unsolicited > manner, independent of the negotiated label advertisement mode of the > LDP session according to the specifications in specified in [RFC7358]. > LDP's "liberal label retention" mode SHOULD be used. However all the LDP > procedures specified in [RFC5036] MUST be implemented, and specifically > the procedures in section 3.5.7. "Label Mapping Message", and 3.5.8. > "Label Request Message". > > > Does this work ? > > Any other suggestions ? > > > Thanks. > > Luca > > > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals > > From nobody Wed Jul 29 00:01:22 2015 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 5E81E1B3106 for ; Wed, 29 Jul 2015 00:01:21 -0700 (PDT) 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 hcgfyhvmqqNf for ; Wed, 29 Jul 2015 00:01:18 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 210E51B2E66 for ; Wed, 29 Jul 2015 00:01:18 -0700 (PDT) Received: from 172.18.9.243 (EHLO lhreml406-hub.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPM60971; Wed, 29 Jul 2015 02:01:16 -0500 (CDT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 29 Jul 2015 08:00:22 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.227]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Wed, 29 Jul 2015 15:00:15 +0800 From: "Dongjie (Jimmy)" To: "Bocci, Matthew (Matthew)" , "draft-ietf-pals-redundancy-spe@tools.ietf.org" Thread-Topic: Shepherd's review of draft-ietf-pals-redundancy-spe-01 Thread-Index: AQHQyGkSWnL2Ul9uLUCHdSjrzhW9lZ3yAH+A Date: Wed, 29 Jul 2015 07:00:13 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927742F0435@nkgeml512-mbx.china.huawei.com> References: 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.97.131] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927742F0435nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "pals@ietf.org" Subject: Re: [Pals] Shepherd's review of draft-ietf-pals-redundancy-spe-01 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, 29 Jul 2015 07:01:21 -0000 --_000_76CD132C3ADEF848BD84D028D243C927742F0435nkgeml512mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Matthew, Thanks a lot for your comments, please see my replies inline with [Jie]: Best regards, Jie From: Bocci, Matthew (Matthew) [mailto:matthew.bocci@alcatel-lucent.com] Sent: Monday, July 27, 2015 8:38 PM To: draft-ietf-pals-redundancy-spe@tools.ietf.org Cc: pals@ietf.org Subject: Shepherd's review of draft-ietf-pals-redundancy-spe-01 Authors I am the document shepherd for draft-ietf-pals-redundancy-spe-01. I have r= eviewed the draft, and I think it is mostly ready to go. However, I have a = few suggestions that I think would improve the clarity of the draft. Please= treat these suggestions as last call comments. Introduction: "In some MS-PW scenarios, there are benefits to provide PW redundancy on S= -PEs, such as reducing the burden on the access T-PE nodes, and faster prot= ection switching. " I think you are assuming that it is faster because PW status messages have = to propagate through less hops, but I am not sure that makes a huge differe= nce because most deployments are only 2 or 3 hops. Please can you be more e= xplicit. [Jie] Since the switchover is performed on S-PE, this mechanism is segment = protection of MS-PW, which means it could be faster than end-to-end protect= ion. I agree in most scenarios there are only a few hops, while since the P= W status message is processed by the control plane of each S-PE hop, there = still can be some difference. We could make this more explicit by adding so= me description about segment protection vs. end-to-end protection in the in= troduction. Section 3, S-PE Operations: - I think you need to be more explicit about the mode that each T-PE operat= es in. It looks like T-PE1 has to operate as a master, and T-PE2 and T-PE3 = always act in independent mode. However, the draft doesn't explicitly make = that statement anywhere (at least not for T-PE2 and T-PE3). Please can you = add such a statement? [Jie] Will add some statement about the mode of T-PE2 and T-PE3. Section 6: Security Considerations. I think you will need to be more explicit. It might help to add an explicit= statement that the requirements that apply to those RFCs apply here. You s= hould also add a reference to RFC6073 here as S-PE security is relevant. [Jie] Will add the explicit statement and the reference to RFC6073 to the S= ecurity Considerations section. Regards Matthew --_000_76CD132C3ADEF848BD84D028D243C927742F0435nkgeml512mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Matthew= ,

 = ;

Thanks a l= ot for your comments, please see my replies inline with [Jie]:

 = ;

Best regar= ds,

Jie

 = ;

From: Bocci, Matthew (Matthew) [mailto:matthew.bocci@alcate= l-lucent.com]
Sent: Monday, July 27, 2015 8:38 PM
To: draft-ietf-pals-redundancy-spe@tools.ietf.org
Cc: pals@ietf.org
Subject: Shepherd's review of draft-ietf-pals-redundancy-spe-01=

 

Authors=

 <= /o:p>

I am the doc= ument shepherd for draft-ietf-pals-redundancy-spe-01.  I have reviewed= the draft, and I think it is mostly ready to go. However, I have a few suggestions that I think would improve the clarity of the draft. Ple= ase treat these suggestions as last call comments.

 <= /o:p>

Introduction= :

"In some MS-PW scenarios, there are benefits to provide PW red= undancy  on S-PEs, such as reducing the burden on the access T-PE nodes, and faster prot= ection switching. “

I think you are ass= uming that it is faster because PW status messages have to propagate&n= bsp;through less hops, but I am not sure that makes a huge difference = because most deployments are only 2 or 3 hops. Please can you be more explicit.

 = ;

[Jie] Sinc= e the switchover is performed on S-PE, this mechanism is segment protection= of MS-PW, which means it could be faster than end-to-end protection. I agree in most scenarios there are only a few hops, while sin= ce the PW status message is processed by the control plane of each S-PE hop= , there still can be some difference. We could make this more explicit by a= dding some description about segment protection vs. end-to-end protection in the introduction.

 

Section 3, S-PE Operatio= ns:

- I think you need = to be more explicit about the mode that each T-PE operates in. It= looks like T-PE1 has to operate as a master, and T-PE2 and T-PE3 always act in independent mode. However, the draft doesn’t explicitly make = that statement anywhere (at least not for T-PE2 and T-PE3). Please can you = add such a statement?

&n= bsp;

[Jie] Will= add some statement about the mode of T-PE2 and T-PE3.

 

Section 6: Security Cons= iderations.

I think you will ne= ed to be more explicit. It might help to add an explicit statement that the= requirements that apply to those RFCs apply here. You should also add a reference to RFC6073 here as S-PE security is relevant.

 = ;

[Jie] Will= add the explicit statement and the reference to RFC6073 to the Security Co= nsiderations section.

 

Regards

 

Matthew

--_000_76CD132C3ADEF848BD84D028D243C927742F0435nkgeml512mbxchi_-- From nobody Thu Jul 30 02:54:52 2015 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 CEABA1A6FF7 for ; Thu, 30 Jul 2015 02:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 0ogrcTD_52k7 for ; Thu, 30 Jul 2015 02:54:48 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 F32DC1A020D for ; Thu, 30 Jul 2015 02:54:47 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id DC8E33A52DBF0; Thu, 30 Jul 2015 09:54:43 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t6U9sigj014835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jul 2015 11:54:45 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.213]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 30 Jul 2015 11:54:44 +0200 From: "Bocci, Matthew (Matthew)" To: "Dongjie (Jimmy)" , "draft-ietf-pals-redundancy-spe@tools.ietf.org" Thread-Topic: Shepherd's review of draft-ietf-pals-redundancy-spe-01 Thread-Index: AQHQyGkSWnL2Ul9uLUCHdSjrzhW9lZ3yAH+AgAG5b4A= Date: Thu, 30 Jul 2015 09:54:43 +0000 Message-ID: References: <76CD132C3ADEF848BD84D028D243C927742F0435@nkgeml512-mbx.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927742F0435@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_D1DFB2437F14Dmatthewboccialcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "pals@ietf.org" Subject: Re: [Pals] Shepherd's review of draft-ietf-pals-redundancy-spe-01 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, 30 Jul 2015 09:54:51 -0000 --_000_D1DFB2437F14Dmatthewboccialcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Jie Thank you. The changes you propose below should be fine. I=92ll post the shepherds write up as soon as you post an updated draft. Best regards Matthew From: "Dongjie (Jimmy)" > Date: Wednesday, 29 July 2015 08:00 To: Matthew Bocci >, "draft-ietf-pals-redundancy-spe@tools.ietf.org" > Cc: "pals@ietf.org" > Subject: RE: Shepherd's review of draft-ietf-pals-redundancy-spe-01 Hi Matthew, Thanks a lot for your comments, please see my replies inline with [Jie]: Best regards, Jie From: Bocci, Matthew (Matthew) [mailto:matthew.bocci@alcatel-lucent.com] Sent: Monday, July 27, 2015 8:38 PM To: draft-ietf-pals-redundancy-spe@tools.ietf.org Cc: pals@ietf.org Subject: Shepherd's review of draft-ietf-pals-redundancy-spe-01 Authors I am the document shepherd for draft-ietf-pals-redundancy-spe-01. I have r= eviewed the draft, and I think it is mostly ready to go. However, I have a = few suggestions that I think would improve the clarity of the draft. Please= treat these suggestions as last call comments. Introduction: "In some MS-PW scenarios, there are benefits to provide PW redundancy on S= -PEs, such as reducing the burden on the access T-PE nodes, and faster prot= ection switching. =93 I think you are assuming that it is faster because PW status messages have = to propagate through less hops, but I am not sure that makes a huge differe= nce because most deployments are only 2 or 3 hops. Please can you be more e= xplicit. [Jie] Since the switchover is performed on S-PE, this mechanism is segment = protection of MS-PW, which means it could be faster than end-to-end protect= ion. I agree in most scenarios there are only a few hops, while since the P= W status message is processed by the control plane of each S-PE hop, there = still can be some difference. We could make this more explicit by adding so= me description about segment protection vs. end-to-end protection in the in= troduction. Section 3, S-PE Operations: - I think you need to be more explicit about the mode that each T-PE operat= es in. It looks like T-PE1 has to operate as a master, and T-PE2 and T-PE3 = always act in independent mode. However, the draft doesn=92t explicitly mak= e that statement anywhere (at least not for T-PE2 and T-PE3). Please can yo= u add such a statement? [Jie] Will add some statement about the mode of T-PE2 and T-PE3. Section 6: Security Considerations. I think you will need to be more explicit. It might help to add an explicit= statement that the requirements that apply to those RFCs apply here. You s= hould also add a reference to RFC6073 here as S-PE security is relevant. [Jie] Will add the explicit statement and the reference to RFC6073 to the S= ecurity Considerations section. Regards Matthew --_000_D1DFB2437F14Dmatthewboccialcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Jie

Thank you. The changes you propose below should be fine.

I=92ll post the shepherds write up as soon as you post an updated draf= t.

Best regards

Matthew

From: "Dongjie (Jimmy)" &= lt;jie.dong@huawei.com>
Date: Wednesday, 29 July 2015 08:00=
To: Matthew Bocci <matthew.bocci@alcatel-lucent.com= >, "draft-ietf-pals-redundancy-spe@tools.ietf.org" <draft= -ietf-pals-redundancy-spe@tools.ietf.org>
Cc: "pals@ietf.org" <pals@i= etf.org>
Subject: RE: Shepherd's review of d= raft-ietf-pals-redundancy-spe-01

Hi Matthew,

 <= /span>

Thanks a lot for y= our comments, please see my replies inline with [Jie]:

 <= /span>

Best regards,=

Jie

 <= /span>

From: Bocci, Matthew (Mat= thew) [mailto:matthew.b= occi@alcatel-lucent.com]
Sent: Monday, July 27, 2015 8:38 PM
To: draft-ietf-pals-redundancy-spe@tools.ietf.org
Cc: pals@ietf.org
Subject: Shepherd's review of draft-ietf-pals-redundancy-spe-01=

 

Authors

 

I am the document shepherd fo= r draft-ietf-pals-redundancy-spe-01.  I have reviewed the draft, and I= think it is mostly ready to go. However, I have a few suggestions that I think would improve the clarity of the draft= . Please treat these suggestions as last call comments.

 

Introduction:

"In some MS-PW scenarios, the= re are benefits to provide PW redundancy  on S-PEs, such as reducing the burden on the access T-PE nodes, and faster prot= ection switching. =93

I think you are assuming that it is fast= er because PW status messages have to propagate through less hops= , but I am not sure that makes a huge difference because most deployments are only 2 or 3 hops. Please can you be more explicit.

 <= /span>

[Jie] Since the sw= itchover is performed on S-PE, this mechanism is segment protection of MS-P= W, which means it could be faster than end-to-end protection. I agree in most scenarios there are only a few hops= , while since the PW status message is processed by the control plane of ea= ch S-PE hop, there still can be some difference. We could make this more ex= plicit by adding some description about segment protection vs. end-to-end protection in the introduction.

 

Section 3, S-PE Operations:

- I think you need to be more explicit a= bout the mode that each T-PE operates in. It looks like T-PE1 has= to operate as a master, and T-PE2 and T-PE3 always act in independent mode. However, the draft doesn=92t explicitly make that sta= tement anywhere (at least not for T-PE2 and T-PE3). Please can you add such= a statement?

&n= bsp;

[Jie] Will add som= e statement about the mode of T-PE2 and T-PE3.

 

Section 6: Security Considerations.

I think you will need to be more explici= t. It might help to add an explicit statement that the requirements that ap= ply to those RFCs apply here. You should also add a reference to RFC6073 here as S-PE security is relevant.

 <= /span>

[Jie] Will add the= explicit statement and the reference to RFC6073 to the Security Considerat= ions section.

 

Regards

 

Matthew

 --_000_D1DFB2437F14Dmatthewboccialcatellucentcom_-- From nobody Thu Jul 30 11:48:20 2015 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 644101B2F34 for ; Thu, 30 Jul 2015 11:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpar4QLuk3rm for ; Thu, 30 Jul 2015 11:48:17 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4A4A1B2F31 for ; Thu, 30 Jul 2015 11:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2341; q=dns/txt; s=iport; t=1438282097; x=1439491697; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=j7JNYqovzijvpRz1K316iCkrLmNesEaJKENsM3R2pBE=; b=J52+0UY7bzOe/4KBgtE+9T27jwu8v+P9VY/Ae2gL7UgHGQ0EHAWIJMUQ 1R+Px8zDLt+ETVJOfOqXtSTLPE0dPDWpndAjmRAa0fvcZuunZYHfUuwIS p1mo7hFWoFi2Lims0gF0aN+pPgKYvbvmKx7VLvZm1es79CeAZPS+DhDHs U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B9AwA7cLpV/51dJa1YA4MaVGkGvBgJgXkKhXkCgT84FAEBAQEBAQGBCoQkAQEEAQEBNywIGQICAQg2EBsMCyUCBAESiC4NtDuUMwEBAQEBAQEBAQEBAQEBAQEBAQEBARcEi0qBPYJnEQErFhIFEoQaBZR3AYR6h06BR0aDWocHhCqIISaCG4FibwGBBgcXI4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,578,1432598400"; d="scan'208";a="16403499" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 30 Jul 2015 18:48:16 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t6UImGv8009319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 30 Jul 2015 18:48:17 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.112]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Thu, 30 Jul 2015 13:48:16 -0500 From: "Patrice Brissette (pbrisset)" To: "Luca Martini (lmartini)" , "pals@ietf.org" Thread-Topic: [Pals] RFC4447bis LC and label request/response discussion in Prague Thread-Index: AQHQyvhLCEjHd9+nqkaBKH2+EeOenA== Date: Thu, 30 Jul 2015 18:48:16 +0000 Message-ID: References: <55B681BC.20508@cisco.com> In-Reply-To: <55B681BC.20508@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.138] Content-Type: text/plain; charset="us-ascii" Content-ID: <5EB2DE50D140D8449878F73ED3BFCFC7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Pals] RFC4447bis LC and label request/response discussion in Prague 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, 30 Jul 2015 18:48:19 -0000 Luca, This is perfect! Thanks for this change. Regards, Patrice Patrice Brissette TECHNICAL LEADER.ENGINEERING pbrisset@cisco.com Phone: +1 613 254 3336 Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE Canada Cisco.com Think before you print.This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Please click here=20 for Company Registration Information. On 2015-07-27, 3:08 PM, "Pals on behalf of Luca Martini (lmartini)" wrote: >Folks, > >Some of you brought up the fact the in the current rfc4447bis update >document it is not clear that we require a full implementation of the >LDP protocol specified in rfc5036. > >In particular the part that is assumed, thought rfc4447bis is that any >implementation of this protocol MUST implement responding to remote >label mapping request messages. > >I propose the following update to the text : > >OLD: > >LDP MUST exchange PW FEC label bindings in downstream unsolicited >manner, independent of the negotiated label advertisement mode of the >LDP session according to the specifications in specified in [RFC7358]. >LDP's "liberal label retention" mode SHOULD be used. > >NEW: > >LDP MUST exchange PW FEC label bindings in downstream unsolicited >manner, independent of the negotiated label advertisement mode of the >LDP session according to the specifications in specified in [RFC7358]. >LDP's "liberal label retention" mode SHOULD be used. However all the LDP >procedures specified in [RFC5036] MUST be implemented, and specifically >the procedures in section 3.5.7. "Label Mapping Message", and 3.5.8. >"Label Request Message". > > >Does this work ? > >Any other suggestions ? > > >Thanks. > >Luca > > >_______________________________________________ >Pals mailing list >Pals@ietf.org >https://www.ietf.org/mailman/listinfo/pals From nobody Thu Jul 30 11:51:03 2015 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 2EFCF1B2F34 for ; Thu, 30 Jul 2015 11:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmnZSHjUUKd8 for ; Thu, 30 Jul 2015 11:51:00 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F171B2F31 for ; Thu, 30 Jul 2015 11:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4002; q=dns/txt; s=iport; t=1438282260; x=1439491860; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PN7IDbmMi6r/r4SMkAbk78SsC/4/r5a2B7f0Q8WurFw=; b=DGqtr2plg6sM590MG8oftRyU462JS+CBxZkJQrsoiQLuICB3ai582cbh 6YwNjA4sXbfIcg5crjhxNeDgnviPpETSFCMJkNNyhRfjdkmtrahX2AxCy 6/ONE60ehvtLD6hJnnqqbYC4vkrGhTBkiNFKCH7ac9R29T8Ut7Wfq1Ys6 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CXBQDacbpV/5BdJa1YA4MaVGkGvCGBeQqFeQKBPzkTAQEBAQEBAYEKhCQBAQQBAQFjCAsOAgIBCBgnBxsMCxQRAgQBDQWILg20PJQxAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSLSoE9gmcRASsWEAIFEoQaBYUnh12HcwGEeoUggi6BR0aDWocHhCqEPYNkJoIbgWJvAYEGBxcjgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,578,1432598400"; d="scan'208";a="173785977" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-3.cisco.com with ESMTP; 30 Jul 2015 18:50:59 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t6UIoxua028346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jul 2015 18:50:59 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.112]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Thu, 30 Jul 2015 13:50:58 -0500 From: "Patrice Brissette (pbrisset)" To: "Luca Martini (lmartini)" , "Andrew G. Malis" Thread-Topic: [Pals] RFC4447bis LC and label request/response discussion in Prague Thread-Index: AQHQyviroQ6NJO9ttUy78iUSu+cwwQ== Date: Thu, 30 Jul 2015 18:50:58 +0000 Message-ID: References: <55B681BC.20508@cisco.com> <55B6C4DC.5020205@cisco.com> In-Reply-To: <55B6C4DC.5020205@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.138] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "pals@ietf.org" Subject: Re: [Pals] RFC4447bis LC and label request/response discussion in Prague 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, 30 Jul 2015 18:51:02 -0000 Hi, I don=B9t have a strong opinion as long it is clear to everyone that a PE MUST respond to PW FEC label request. Regards, Patrice Patrice Brissette TECHNICAL LEADER.ENGINEERING pbrisset@cisco.com Phone: +1 613 254 3336 Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE Canada Cisco.com Think before you print.This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Please click here=20 for Company Registration Information. On 2015-07-27, 7:55 PM, "Pals on behalf of Luca Martini (lmartini)" wrote: >On 07/27/2015 01:59 PM, Andrew G. Malis wrote: >> Luca, >> >> RFC 5036 uses "Downstream Unsolicited mode" rather than "downstream >>unsolicited=20 >> manner", so you should change "manner" to "mode" and capitalize >>Downstream=20 >> Unsolicited. It also uses "Liberal Label retention mode" (note the >>capital L's=20 >> and small r and m). >yes - Agreed. > >> Regarding your new text "However all the LDP procedures specified in >>[RFC5036]=20 >> MUST be implemented, and specifically the procedures in section 3.5.7. >>"Label=20 >> Mapping Message", and 3.5.8. "Label Request Message".", I would just >>shorten=20 >> it to say: "However, all the LDP procedures specified in [RFC5036] MUST >>be=20 >> implemented." I don't know if it's necessary to call special attention >>to those=20 >> two sections if you have to implement everything anyway. >I agree, but people in the meeting insisted on an explicit mention of >those sections. >Above text is driven by the comments in the meeting. >Let's see if other speak up. >Thanks. >Luca > >> Cheers, >> Andy >> >> On Mon, Jul 27, 2015 at 3:08 PM, Luca Martini > > wrote: >> >> Folks, >> >> Some of you brought up the fact the in the current rfc4447bis update >> document it is not clear that we require a full implementation of >>the >> LDP protocol specified in rfc5036. >> >> In particular the part that is assumed, thought rfc4447bis is that >>any >> implementation of this protocol MUST implement responding to remote >> label mapping request messages. >> >> I propose the following update to the text : >> >> OLD: >> >> LDP MUST exchange PW FEC label bindings in downstream unsolicited >> manner, independent of the negotiated label advertisement mode of >>the >> LDP session according to the specifications in specified in >>[RFC7358]. >> LDP's "liberal label retention" mode SHOULD be used. >> >> NEW: >> >> LDP MUST exchange PW FEC label bindings in downstream unsolicited >> manner, independent of the negotiated label advertisement mode of >>the >> LDP session according to the specifications in specified in >>[RFC7358]. >> LDP's "liberal label retention" mode SHOULD be used. However all >>the LDP >> procedures specified in [RFC5036] MUST be implemented, and >>specifically >> the procedures in section 3.5.7. "Label Mapping Message", and >>3.5.8. >> "Label Request Message". >> >> >> Does this work ? >> >> Any other suggestions ? >> >> >> Thanks. >> >> Luca >> >> >> _______________________________________________ >> 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 From nobody Thu Jul 30 12:18:26 2015 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 64A441ACC83 for ; Thu, 30 Jul 2015 12:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 jNXODxyZ-0bJ for ; Thu, 30 Jul 2015 12:18:23 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 DF5511A92BA for ; Thu, 30 Jul 2015 12:18:22 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id A5FF039510D2C; Thu, 30 Jul 2015 19:18:17 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t6UJIJLG023578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jul 2015 21:18:19 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.213]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 30 Jul 2015 21:18:18 +0200 From: "Bocci, Matthew (Matthew)" To: "Patrice Brissette (pbrisset)" , "Luca Martini (lmartini)" , "Andrew G. Malis" Thread-Topic: [Pals] RFC4447bis LC and label request/response discussion in Prague Thread-Index: AQHQyJ+zBZbvfQNMxEKa+rF+e+mx6Z3vmrWAgABB2QCABGIDAIAAGGcA Date: Thu, 30 Jul 2015 19:18:17 +0000 Message-ID: References: <55B681BC.20508@cisco.com> <55B6C4DC.5020205@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="euc-kr" Content-ID: <8D69110CDAB92E48AF047346F0F64F9A@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "pals@ietf.org" Subject: Re: [Pals] RFC4447bis LC and label request/response discussion in Prague 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, 30 Jul 2015 19:18:25 -0000 THVjYQ0KDQpJIGRvbqGvdCBvYmplY3QgdG8gdGhlIGludGVudCwgYnV0IEkgYWdyZWUgd2l0aCBB bmR5IHRoYXQgdGhlcmUgaXMNCnNvbWV0aGluZyBzdHJhbmdlIGFib3V0IGNhbGxpbmcgb3V0IHRo b3NlIHNlY3Rpb25zIHNwZWNpZmljYWxseS4gWW91IGFyZQ0KdXBncmFkaW5nIHRoZSBSRkMyMTE5 IHJlcXVpcmVtZW50IGFyb3VuZCBsYWJlbCByZXF1ZXN0IGJlY2F1c2UgcmVzcG9uZGluZw0KdG8g YSBsYWJlbCByZXF1ZXN0IGlzIGEgU0hPVUxEIGluIFJGQzUwMzYsIGJ1dCBhIE1VU1QgaGVyZS4N Cg0KQXJlIHRoZXJlIGFueSBvdGhlciBjYXNlcyB3aGVyZSB3ZSByZWFsbHkgbmVlZCBhbiBpbXBs ZW1lbnRhdGlvbiB0byBkbw0Kc29tZXRoaW5nIHRoYXQgaXMgb25seSBhIFNIT1VMRCBpbiBSRkM1 MDM2Pw0KDQpNYXR0aGV3DQoNCk9uIDMwLzA3LzIwMTUgMTk6NTAsICJQYWxzIG9uIGJlaGFsZiBv ZiBQYXRyaWNlIEJyaXNzZXR0ZSAocGJyaXNzZXQpIg0KPHBhbHMtYm91bmNlc0BpZXRmLm9yZyBv biBiZWhhbGYgb2YgcGJyaXNzZXRAY2lzY28uY29tPiB3cm90ZToNCg0KPkhpLA0KPg0KPg0KPkkg ZG9uqfZ0IGhhdmUgYSBzdHJvbmcgb3BpbmlvbiBhcyBsb25nIGl0IGlzIGNsZWFyIHRvIGV2ZXJ5 b25lIHRoYXQgYSBQRQ0KPk1VU1QgcmVzcG9uZCB0byBQVyBGRUMgbGFiZWwgcmVxdWVzdC4NCj4N Cj4NCj5SZWdhcmRzLA0KPg0KPlBhdHJpY2UNCj4NCj4gICBQYXRyaWNlIEJyaXNzZXR0ZQ0KPlRF Q0hOSUNBTCBMRUFERVIuRU5HSU5FRVJJTkcNCj4NCj5wYnJpc3NldEBjaXNjby5jb20NCj5QaG9u ZTogKzEgNjEzIDI1NCAzMzM2DQo+DQo+Q2lzY28gU3lzdGVtcyBDYW5hZGEgQ28uIC8gTGVzIFN5 c3RlbWVzIENpc2NvIENhbmFkYSBDSUUNCj5DYW5hZGENCj5DaXNjby5jb20gPGh0dHA6Ly93d3cu Y2lzY28uY29tL2dsb2JhbC9DQS8+DQo+DQo+IFRoaW5rIGJlZm9yZSB5b3UgcHJpbnQuVGhpcw0K PiBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwg Zm9yIHRoZSBzb2xlIHVzZQ0KPiBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3 LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlDQo+Ynkgb3RoZXJzIGlzIHN0cmljdGx5 IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQNCj4ob3Ig YXV0aG9yaXplZCB0byByZWNlaXZlIGZvciB0aGUgcmVjaXBpZW50KSwgcGxlYXNlIGNvbnRhY3Qg dGhlIHNlbmRlcg0KPmJ5IHJlcGx5IGVtYWlsIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGlz IG1lc3NhZ2UuDQo+UGxlYXNlIGNsaWNrIGhlcmUgDQo+PGh0dHA6Ly93d3cuY2lzY28uY29tL3dl Yi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbD4gZm9yDQo+Q29tcGFu eSBSZWdpc3RyYXRpb24gSW5mb3JtYXRpb24uDQo+DQo+DQo+DQo+DQo+DQo+DQo+T24gMjAxNS0w Ny0yNywgNzo1NSBQTSwgIlBhbHMgb24gYmVoYWxmIG9mIEx1Y2EgTWFydGluaSAobG1hcnRpbmkp Ig0KPjxwYWxzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGxtYXJ0aW5pQGNpc2NvLmNv bT4gd3JvdGU6DQo+DQo+Pk9uIDA3LzI3LzIwMTUgMDE6NTkgUE0sIEFuZHJldyBHLiBNYWxpcyB3 cm90ZToNCj4+PiBMdWNhLA0KPj4+DQo+Pj4gUkZDIDUwMzYgdXNlcyAiRG93bnN0cmVhbSBVbnNv bGljaXRlZCBtb2RlIiByYXRoZXIgdGhhbiAiZG93bnN0cmVhbQ0KPj4+dW5zb2xpY2l0ZWQgDQo+ Pj4gbWFubmVyIiwgc28geW91IHNob3VsZCBjaGFuZ2UgIm1hbm5lciIgdG8gIm1vZGUiIGFuZCBj YXBpdGFsaXplDQo+Pj5Eb3duc3RyZWFtIA0KPj4+IFVuc29saWNpdGVkLiBJdCBhbHNvIHVzZXMg IkxpYmVyYWwgTGFiZWwgcmV0ZW50aW9uIG1vZGUiIChub3RlIHRoZQ0KPj4+Y2FwaXRhbCBMJ3Mg DQo+Pj4gYW5kIHNtYWxsIHIgYW5kIG0pLg0KPj55ZXMgLSBBZ3JlZWQuDQo+Pg0KPj4+IFJlZ2Fy ZGluZyB5b3VyIG5ldyB0ZXh0ICJIb3dldmVyIGFsbCB0aGUgTERQIHByb2NlZHVyZXMgc3BlY2lm aWVkIGluDQo+Pj5bUkZDNTAzNl0gDQo+Pj4gTVVTVCBiZSBpbXBsZW1lbnRlZCwgYW5kIHNwZWNp ZmljYWxseSB0aGUgcHJvY2VkdXJlcyBpbiBzZWN0aW9uICAzLjUuNy4NCj4+PiJMYWJlbCANCj4+ PiBNYXBwaW5nIE1lc3NhZ2UiLCBhbmQgICAzLjUuOC4gIkxhYmVsIFJlcXVlc3QgTWVzc2FnZSIu IiwgSSB3b3VsZCBqdXN0DQo+Pj5zaG9ydGVuIA0KPj4+IGl0IHRvIHNheTogIkhvd2V2ZXIsIGFs bCB0aGUgTERQIHByb2NlZHVyZXMgc3BlY2lmaWVkIGluIFtSRkM1MDM2XSBNVVNUDQo+Pj5iZSAN Cj4+PiBpbXBsZW1lbnRlZC4iIEkgZG9uJ3Qga25vdyBpZiBpdCdzIG5lY2Vzc2FyeSB0byBjYWxs IHNwZWNpYWwgYXR0ZW50aW9uDQo+Pj50byB0aG9zZSANCj4+PiB0d28gc2VjdGlvbnMgaWYgeW91 IGhhdmUgdG8gaW1wbGVtZW50IGV2ZXJ5dGhpbmcgYW55d2F5Lg0KPj5JIGFncmVlLCBidXQgcGVv cGxlIGluIHRoZSBtZWV0aW5nIGluc2lzdGVkIG9uIGFuIGV4cGxpY2l0IG1lbnRpb24gb2YNCj4+ dGhvc2Ugc2VjdGlvbnMuDQo+PkFib3ZlIHRleHQgaXMgZHJpdmVuIGJ5IHRoZSBjb21tZW50cyBp biB0aGUgbWVldGluZy4NCj4+TGV0J3Mgc2VlIGlmIG90aGVyIHNwZWFrIHVwLg0KPj5UaGFua3Mu DQo+Pkx1Y2ENCj4+DQo+Pj4gQ2hlZXJzLA0KPj4+IEFuZHkNCj4+Pg0KPj4+IE9uIE1vbiwgSnVs IDI3LCAyMDE1IGF0IDM6MDggUE0sIEx1Y2EgTWFydGluaSA8bG1hcnRpbmlAY2lzY28uY29tDQo+ Pj4gPG1haWx0bzpsbWFydGluaUBjaXNjby5jb20+PiB3cm90ZToNCj4+Pg0KPj4+ICAgICBGb2xr cywNCj4+Pg0KPj4+ICAgICBTb21lIG9mIHlvdSBicm91Z2h0IHVwIHRoZSBmYWN0IHRoZSBpbiB0 aGUgY3VycmVudCByZmM0NDQ3YmlzDQo+Pj51cGRhdGUNCj4+PiAgICAgZG9jdW1lbnQgaXQgaXMg bm90IGNsZWFyIHRoYXQgd2UgcmVxdWlyZSBhIGZ1bGwgaW1wbGVtZW50YXRpb24gb2YNCj4+PnRo ZQ0KPj4+ICAgICBMRFAgcHJvdG9jb2wgc3BlY2lmaWVkIGluIHJmYzUwMzYuDQo+Pj4NCj4+PiAg ICAgSW4gcGFydGljdWxhciB0aGUgcGFydCB0aGF0IGlzIGFzc3VtZWQsIHRob3VnaHQgcmZjNDQ0 N2JpcyBpcyB0aGF0DQo+Pj5hbnkNCj4+PiAgICAgaW1wbGVtZW50YXRpb24gb2YgdGhpcyBwcm90 b2NvbCBNVVNUIGltcGxlbWVudCByZXNwb25kaW5nIHRvIHJlbW90ZQ0KPj4+ICAgICBsYWJlbCBt YXBwaW5nIHJlcXVlc3QgbWVzc2FnZXMuDQo+Pj4NCj4+PiAgICAgSSBwcm9wb3NlIHRoZSBmb2xs b3dpbmcgdXBkYXRlIHRvIHRoZSB0ZXh0IDoNCj4+Pg0KPj4+ICAgICBPTEQ6DQo+Pj4NCj4+PiAg ICAgTERQIE1VU1QgZXhjaGFuZ2UgUFcgRkVDIGxhYmVsIGJpbmRpbmdzIGluIGRvd25zdHJlYW0g dW5zb2xpY2l0ZWQNCj4+PiAgICAgbWFubmVyLCBpbmRlcGVuZGVudCBvZiB0aGUgbmVnb3RpYXRl ZCBsYWJlbCBhZHZlcnRpc2VtZW50IG1vZGUgb2YNCj4+PnRoZQ0KPj4+ICAgICBMRFAgc2Vzc2lv biBhY2NvcmRpbmcgdG8gdGhlIHNwZWNpZmljYXRpb25zIGluIHNwZWNpZmllZCBpbg0KPj4+W1JG QzczNThdLg0KPj4+ICAgICBMRFAncyAibGliZXJhbCBsYWJlbCByZXRlbnRpb24iIG1vZGUgU0hP VUxEIGJlIHVzZWQuDQo+Pj4NCj4+PiAgICAgTkVXOg0KPj4+DQo+Pj4gICAgIExEUCBNVVNUIGV4 Y2hhbmdlIFBXIEZFQyBsYWJlbCBiaW5kaW5ncyBpbiBkb3duc3RyZWFtIHVuc29saWNpdGVkDQo+ Pj4gICAgIG1hbm5lciwgaW5kZXBlbmRlbnQgb2YgdGhlIG5lZ290aWF0ZWQgbGFiZWwgYWR2ZXJ0 aXNlbWVudCBtb2RlIG9mDQo+Pj50aGUNCj4+PiAgICAgTERQIHNlc3Npb24gYWNjb3JkaW5nIHRv IHRoZSBzcGVjaWZpY2F0aW9ucyBpbiBzcGVjaWZpZWQgaW4NCj4+PltSRkM3MzU4XS4NCj4+PiAg ICAgTERQJ3MgImxpYmVyYWwgbGFiZWwgcmV0ZW50aW9uIiBtb2RlIFNIT1VMRCBiZSB1c2VkLiBI b3dldmVyIGFsbA0KPj4+dGhlIExEUA0KPj4+ICAgICBwcm9jZWR1cmVzIHNwZWNpZmllZCBpbiBb UkZDNTAzNl0gTVVTVCBiZSBpbXBsZW1lbnRlZCwgYW5kDQo+Pj5zcGVjaWZpY2FsbHkNCj4+PiAg ICAgdGhlIHByb2NlZHVyZXMgaW4gc2VjdGlvbiAgMy41LjcuICJMYWJlbCBNYXBwaW5nIE1lc3Nh Z2UiLCBhbmQNCj4+PjMuNS44Lg0KPj4+ICAgICAiTGFiZWwgUmVxdWVzdCBNZXNzYWdlIi4NCj4+ Pg0KPj4+DQo+Pj4gICAgIERvZXMgdGhpcyB3b3JrID8NCj4+Pg0KPj4+ICAgICBBbnkgb3RoZXIg c3VnZ2VzdGlvbnMgPw0KPj4+DQo+Pj4NCj4+PiAgICAgVGhhbmtzLg0KPj4+DQo+Pj4gICAgIEx1 Y2ENCj4+Pg0KPj4+DQo+Pj4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pj4gICAgIFBhbHMgbWFpbGluZyBsaXN0DQo+Pj4gICAgIFBhbHNAaWV0 Zi5vcmcgPG1haWx0bzpQYWxzQGlldGYub3JnPg0KPj4+ICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3BhbHMNCj4+Pg0KPj4+DQo+Pg0KPj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5QYWxzIG1haWxpbmcgbGlzdA0KPj5Q YWxzQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGFs cw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ UGFscyBtYWlsaW5nIGxpc3QNCj5QYWxzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wYWxzDQoNCg== From nobody Fri Jul 31 02:18:02 2015 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 633221A0020 for ; Fri, 31 Jul 2015 02:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] 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 msD8L5GURcVv for ; Fri, 31 Jul 2015 02:17:59 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499AF1A0015 for ; Fri, 31 Jul 2015 02:17:58 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id t6V9AChw031094; Fri, 31 Jul 2015 05:17:55 -0400 Received: from vawvcgsie2k1301.ciena.com (LIN1-118-36-35.ciena.com [63.118.36.35]) by mx0b-00103a01.pphosted.com with ESMTP id 1vy827ve7k-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 31 Jul 2015 05:17:55 -0400 Received: from MDWVEXCHHT02.ciena.com (10.4.156.176) by VAWVCGSIE2K1301.ciena.com (10.4.62.15) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 31 Jul 2015 05:17:54 -0400 Received: from ONWVEXCHHT03.ciena.com (10.128.6.43) by MDWVEXCHHT02.ciena.com (10.4.156.176) with Microsoft SMTP Server (TLS) id 8.3.389.2; Fri, 31 Jul 2015 05:17:53 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT03.ciena.com ([::1]) with mapi; Fri, 31 Jul 2015 05:17:53 -0400 From: "Shah, Himanshu" To: "Patrice Brissette (pbrisset)" , "Luca Martini (lmartini)" , "Andrew G. Malis" Date: Fri, 31 Jul 2015 05:17:51 -0400 Thread-Topic: [Pals] RFC4447bis LC and label request/response discussion in Prague Thread-Index: AQHQyviroQ6NJO9ttUy78iUSu+cwwZ31S6tz Message-ID: <40746B2300A8FC4AB04EE722A593182B95BDE97C@ONWVEXCHMB04.ciena.com> References: <55B681BC.20508@cisco.com> <55B6C4DC.5020205@cisco.com>, In-Reply-To: Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-21714.006 X-TM-AS-Result: No--32.791400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-31_05:2015-07-30,2015-07-31,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507310160 Archived-At: Cc: "pals@ietf.org" Subject: Re: [Pals] RFC4447bis LC and label request/response discussion in Prague 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, 31 Jul 2015 09:18:01 -0000 I am still on vacation but wanted to opine on the text Luca proposed. I agree with the proposed text and explicit call out two sections. Himanshu using iPad (so excuse the auto-corrects...) ________________________________________ From: Pals [pals-bounces@ietf.org] On Behalf Of Patrice Brissette (pbrisset= ) [pbrisset@cisco.com] Sent: Thursday, July 30, 2015 2:50 PM To: Luca Martini (lmartini); Andrew G. Malis Cc: pals@ietf.org Subject: Re: [Pals] RFC4447bis LC and label request/response discussion in = Prague Hi, I don=B9t have a strong opinion as long it is clear to everyone that a PE MUST respond to PW FEC label request. Regards, Patrice Patrice Brissette TECHNICAL LEADER.ENGINEERING pbrisset@cisco.com Phone: +1 613 254 3336 Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE Canada Cisco.com Think before you print.This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Please click here for Company Registration Information. On 2015-07-27, 7:55 PM, "Pals on behalf of Luca Martini (lmartini)" wrote: >On 07/27/2015 01:59 PM, Andrew G. Malis wrote: >> Luca, >> >> RFC 5036 uses "Downstream Unsolicited mode" rather than "downstream >>unsolicited >> manner", so you should change "manner" to "mode" and capitalize >>Downstream >> Unsolicited. It also uses "Liberal Label retention mode" (note the >>capital L's >> and small r and m). >yes - Agreed. > >> Regarding your new text "However all the LDP procedures specified in >>[RFC5036] >> MUST be implemented, and specifically the procedures in section 3.5.7. >>"Label >> Mapping Message", and 3.5.8. "Label Request Message".", I would just >>shorten >> it to say: "However, all the LDP procedures specified in [RFC5036] MUST >>be >> implemented." I don't know if it's necessary to call special attention >>to those >> two sections if you have to implement everything anyway. >I agree, but people in the meeting insisted on an explicit mention of >those sections. >Above text is driven by the comments in the meeting. >Let's see if other speak up. >Thanks. >Luca > >> Cheers, >> Andy >> >> On Mon, Jul 27, 2015 at 3:08 PM, Luca Martini > > wrote: >> >> Folks, >> >> Some of you brought up the fact the in the current rfc4447bis update >> document it is not clear that we require a full implementation of >>the >> LDP protocol specified in rfc5036. >> >> In particular the part that is assumed, thought rfc4447bis is that >>any >> implementation of this protocol MUST implement responding to remote >> label mapping request messages. >> >> I propose the following update to the text : >> >> OLD: >> >> LDP MUST exchange PW FEC label bindings in downstream unsolicited >> manner, independent of the negotiated label advertisement mode of >>the >> LDP session according to the specifications in specified in >>[RFC7358]. >> LDP's "liberal label retention" mode SHOULD be used. >> >> NEW: >> >> LDP MUST exchange PW FEC label bindings in downstream unsolicited >> manner, independent of the negotiated label advertisement mode of >>the >> LDP session according to the specifications in specified in >>[RFC7358]. >> LDP's "liberal label retention" mode SHOULD be used. However all >>the LDP >> procedures specified in [RFC5036] MUST be implemented, and >>specifically >> the procedures in section 3.5.7. "Label Mapping Message", and >>3.5.8. >> "Label Request Message". >> >> >> Does this work ? >> >> Any other suggestions ? >> >> >> Thanks. >> >> Luca >> >> >> _______________________________________________ >> 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 _______________________________________________ Pals mailing list Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals From nobody Fri Jul 31 02:40:13 2015 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 07D2C1A00AC for ; Fri, 31 Jul 2015 02:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] 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 C-cxnPZeTxkp for ; Fri, 31 Jul 2015 02:40:05 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C785F1A0093 for ; Fri, 31 Jul 2015 02:40:05 -0700 (PDT) Received: from pps.filterd (m0000419.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id t6V9e09T002158; Fri, 31 Jul 2015 05:40:00 -0400 Received: from vawvcgsie2k1301.ciena.com (LIN1-118-36-35.ciena.com [63.118.36.35]) by mx0a-00103a01.pphosted.com with ESMTP id 1vy75vw87n-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 31 Jul 2015 05:40:00 -0400 Received: from VAWVE2K13MBX01.ciena.com (10.4.156.87) by VAWVCGSIE2K1301.ciena.com (10.4.62.15) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 31 Jul 2015 05:39:58 -0400 Received: from ONWVEXCHHT04.ciena.com (10.128.6.44) by VAWVE2K13MBX01.ciena.com (10.4.156.87) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 31 Jul 2015 05:39:58 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT04.ciena.com ([::1]) with mapi; Fri, 31 Jul 2015 05:39:57 -0400 From: "Shah, Himanshu" To: "Bocci, Matthew (Matthew)" , "Patrice Brissette (pbrisset)" , "Luca Martini (lmartini)" , "Andrew G. Malis" Date: Fri, 31 Jul 2015 05:37:21 -0400 Thread-Topic: [Pals] RFC4447bis LC and label request/response discussion in Prague Thread-Index: AQHQyJ+zBZbvfQNMxEKa+rF+e+mx6Z3vmrWAgABB2QCABGIDAIAAGGcAgAEAx1A= Message-ID: <40746B2300A8FC4AB04EE722A593182B95BDE97F@ONWVEXCHMB04.ciena.com> References: <55B681BC.20508@cisco.com> <55B6C4DC.5020205@cisco.com> , In-Reply-To: Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-21714.006 x-tm-as-result: No--64.521400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-31_05:2015-07-30,2015-07-31,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507310163 Archived-At: Cc: "pals@ietf.org" Subject: Re: [Pals] RFC4447bis LC and label request/response discussion in Prague 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, 31 Jul 2015 09:40:08 -0000 Mathew has a good point as well. Did not check if 5036 says SHOULD or MUST. Himanshu using iPad (so excuse the auto-corrects...) ________________________________________ From: Pals [pals-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew) [m= atthew.bocci@alcatel-lucent.com] Sent: Thursday, July 30, 2015 3:18 PM To: Patrice Brissette (pbrisset); Luca Martini (lmartini); Andrew G. Malis Cc: pals@ietf.org Subject: Re: [Pals] RFC4447bis LC and label request/response discussion in = Prague Luca I don=92t object to the intent, but I agree with Andy that there is something strange about calling out those sections specifically. You are upgrading the RFC2119 requirement around label request because responding to a label request is a SHOULD in RFC5036, but a MUST here. Are there any other cases where we really need an implementation to do something that is only a SHOULD in RFC5036? Matthew On 30/07/2015 19:50, "Pals on behalf of Patrice Brissette (pbrisset)" wrote: >Hi, > > >I don=B9t have a strong opinion as long it is clear to everyone that a PE >MUST respond to PW FEC label request. > > >Regards, > >Patrice > > Patrice Brissette >TECHNICAL LEADER.ENGINEERING > >pbrisset@cisco.com >Phone: +1 613 254 3336 > >Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE >Canada >Cisco.com > > Think before you print.This > email may contain confidential and privileged material for the sole use > of the intended recipient. Any review, use, distribution or disclosure >by others is strictly prohibited. If you are not the intended recipient >(or authorized to receive for the recipient), please contact the sender >by reply email and delete all copies of this message. >Please click here > for >Company Registration Information. > > > > > > >On 2015-07-27, 7:55 PM, "Pals on behalf of Luca Martini (lmartini)" > wrote: > >>On 07/27/2015 01:59 PM, Andrew G. Malis wrote: >>> Luca, >>> >>> RFC 5036 uses "Downstream Unsolicited mode" rather than "downstream >>>unsolicited >>> manner", so you should change "manner" to "mode" and capitalize >>>Downstream >>> Unsolicited. It also uses "Liberal Label retention mode" (note the >>>capital L's >>> and small r and m). >>yes - Agreed. >> >>> Regarding your new text "However all the LDP procedures specified in >>>[RFC5036] >>> MUST be implemented, and specifically the procedures in section 3.5.7. >>>"Label >>> Mapping Message", and 3.5.8. "Label Request Message".", I would just >>>shorten >>> it to say: "However, all the LDP procedures specified in [RFC5036] MUST >>>be >>> implemented." I don't know if it's necessary to call special attention >>>to those >>> two sections if you have to implement everything anyway. >>I agree, but people in the meeting insisted on an explicit mention of >>those sections. >>Above text is driven by the comments in the meeting. >>Let's see if other speak up. >>Thanks. >>Luca >> >>> Cheers, >>> Andy >>> >>> On Mon, Jul 27, 2015 at 3:08 PM, Luca Martini >> > wrote: >>> >>> Folks, >>> >>> Some of you brought up the fact the in the current rfc4447bis >>>update >>> document it is not clear that we require a full implementation of >>>the >>> LDP protocol specified in rfc5036. >>> >>> In particular the part that is assumed, thought rfc4447bis is that >>>any >>> implementation of this protocol MUST implement responding to remote >>> label mapping request messages. >>> >>> I propose the following update to the text : >>> >>> OLD: >>> >>> LDP MUST exchange PW FEC label bindings in downstream unsolicited >>> manner, independent of the negotiated label advertisement mode of >>>the >>> LDP session according to the specifications in specified in >>>[RFC7358]. >>> LDP's "liberal label retention" mode SHOULD be used. >>> >>> NEW: >>> >>> LDP MUST exchange PW FEC label bindings in downstream unsolicited >>> manner, independent of the negotiated label advertisement mode of >>>the >>> LDP session according to the specifications in specified in >>>[RFC7358]. >>> LDP's "liberal label retention" mode SHOULD be used. However all >>>the LDP >>> procedures specified in [RFC5036] MUST be implemented, and >>>specifically >>> the procedures in section 3.5.7. "Label Mapping Message", and >>>3.5.8. >>> "Label Request Message". >>> >>> >>> Does this work ? >>> >>> Any other suggestions ? >>> >>> >>> Thanks. >>> >>> Luca >>> >>> >>> _______________________________________________ >>> 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 > >_______________________________________________ >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 From nobody Fri Jul 31 14:51:31 2015 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 9A0521A8A1D for ; Fri, 31 Jul 2015 14:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 5HIyyxQTnFNE for ; Fri, 31 Jul 2015 14:51:27 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4919F1A89A5 for ; Fri, 31 Jul 2015 14:51:27 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.14.7/8.14.7) with ESMTP id t6VLpKIJ005594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 31 Jul 2015 15:51:20 -0600 (MDT) To: "Bocci, Matthew (Matthew)" , "Patrice Brissette (pbrisset)" , "Andrew G. Malis" References: <55B681BC.20508@cisco.com> <55B6C4DC.5020205@cisco.com> From: Luca Martini Message-ID: <55BBEF82.8070308@cisco.com> Date: Fri, 31 Jul 2015 15:58:26 -0600 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "pals@ietf.org" Subject: Re: [Pals] RFC4447bis LC and label request/response discussion in Prague 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, 31 Jul 2015 21:51:30 -0000 Matthew, can you point out the SHOULD in rfc5036 to me ? I could not find it explicitly in the text. Are you referring to the appendix ? Thanks. Luca On 07/30/15 13:18, Bocci, Matthew (Matthew) wrote: > Luca > > I don¡¯t object to the intent, but I agree with Andy that there is > something strange about calling out those sections specifically. You are > upgrading the RFC2119 requirement around label request because responding > to a label request is a SHOULD in RFC5036, but a MUST here. > > Are there any other cases where we really need an implementation to do > something that is only a SHOULD in RFC5036? > > Matthew > > On 30/07/2015 19:50, "Pals on behalf of Patrice Brissette (pbrisset)" > wrote: > >> Hi, >> >> >> I don©öt have a strong opinion as long it is clear to everyone that a PE >> MUST respond to PW FEC label request. >> >> >> Regards, >> >> Patrice >> >> Patrice Brissette >> TECHNICAL LEADER.ENGINEERING >> >> pbrisset@cisco.com >> Phone: +1 613 254 3336 >> >> Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE >> Canada >> Cisco.com >> >> Think before you print.This >> email may contain confidential and privileged material for the sole use >> of the intended recipient. Any review, use, distribution or disclosure >> by others is strictly prohibited. If you are not the intended recipient >> (or authorized to receive for the recipient), please contact the sender >> by reply email and delete all copies of this message. >> Please click here >> for >> Company Registration Information. >> >> >> >> >> >> >> On 2015-07-27, 7:55 PM, "Pals on behalf of Luca Martini (lmartini)" >> wrote: >> >>> On 07/27/2015 01:59 PM, Andrew G. Malis wrote: >>>> Luca, >>>> >>>> RFC 5036 uses "Downstream Unsolicited mode" rather than "downstream >>>> unsolicited >>>> manner", so you should change "manner" to "mode" and capitalize >>>> Downstream >>>> Unsolicited. It also uses "Liberal Label retention mode" (note the >>>> capital L's >>>> and small r and m). >>> yes - Agreed. >>> >>>> Regarding your new text "However all the LDP procedures specified in >>>> [RFC5036] >>>> MUST be implemented, and specifically the procedures in section 3.5.7. >>>> "Label >>>> Mapping Message", and 3.5.8. "Label Request Message".", I would just >>>> shorten >>>> it to say: "However, all the LDP procedures specified in [RFC5036] MUST >>>> be >>>> implemented." I don't know if it's necessary to call special attention >>>> to those >>>> two sections if you have to implement everything anyway. >>> I agree, but people in the meeting insisted on an explicit mention of >>> those sections. >>> Above text is driven by the comments in the meeting. >>> Let's see if other speak up. >>> Thanks. >>> Luca >>> >>>> Cheers, >>>> Andy >>>> >>>> On Mon, Jul 27, 2015 at 3:08 PM, Luca Martini >>> > wrote: >>>> >>>> Folks, >>>> >>>> Some of you brought up the fact the in the current rfc4447bis >>>> update >>>> document it is not clear that we require a full implementation of >>>> the >>>> LDP protocol specified in rfc5036. >>>> >>>> In particular the part that is assumed, thought rfc4447bis is that >>>> any >>>> implementation of this protocol MUST implement responding to remote >>>> label mapping request messages. >>>> >>>> I propose the following update to the text : >>>> >>>> OLD: >>>> >>>> LDP MUST exchange PW FEC label bindings in downstream unsolicited >>>> manner, independent of the negotiated label advertisement mode of >>>> the >>>> LDP session according to the specifications in specified in >>>> [RFC7358]. >>>> LDP's "liberal label retention" mode SHOULD be used. >>>> >>>> NEW: >>>> >>>> LDP MUST exchange PW FEC label bindings in downstream unsolicited >>>> manner, independent of the negotiated label advertisement mode of >>>> the >>>> LDP session according to the specifications in specified in >>>> [RFC7358]. >>>> LDP's "liberal label retention" mode SHOULD be used. However all >>>> the LDP >>>> procedures specified in [RFC5036] MUST be implemented, and >>>> specifically >>>> the procedures in section 3.5.7. "Label Mapping Message", and >>>> 3.5.8. >>>> "Label Request Message". >>>> >>>> >>>> Does this work ? >>>> >>>> Any other suggestions ? >>>> >>>> >>>> Thanks. >>>> >>>> Luca >>>> >>>> >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> Pals mailing list >> Pals@ietf.org >> https://www.ietf.org/mailman/listinfo/pals >

On Tue, Jul 21, 2015 at 10:36 AM, Carl Moberg (camoberg) <cam= oberg@cisco.com> wrote:
=C2=A0Having read through the L2VPN and MPLS-based MPLS VPN drafts, I have = some suggested edits.

=C2=A0In the light of the work we=E2=80=99re doing in the YANG model classi= fication draft (draft-bogdanovic-netmod-yang-model-classification) I would = suggest the edited wording below to make it clear early in the documents th= at the models are intended for device-layer implementations (vs controller = or orchestrator models).


https://www.ietf.org/id/draft-zhuang-pals= -l2vpn-yang-00.txt
OLD:
=E2=80=9C=E2=80=9D"
This document defines a YANG data model that can be used to configure
and manage L2VPN.=C2=A0 Both VPWS and VPLS are supported.
=E2=80=9C=E2=80=9D=E2=80=9D

NEW:
=E2=80=9C=E2=80=9D=E2=80=9D
This document defines a network element YANG Model that define the
device-centric data definitions for L2VPN. Both VPWS and
VPLS are supported.
=E2=80=9C=E2=80=9D"


https://www.ietf.org/id/draft-shah-pal= s-mpls-l2vpn-yang-00.txt
OLD:
=E2=80=9C=E2=80=9D=E2=80=9D
This document introduces a YANG data model for MPLS based Layer 2 VPN
services (L2VPN) [RFC4664] as well as switching between the local
attachment circuits.
=E2=80=9C=E2=80=9D=E2=80=9D

NEW:
=E2=80=9C=E2=80=9D"
This document introduces a network element YANG Model that define the
device-centric data definitions for MPLS based Layer 2 VPN
services (L2VPN) [RFC4664] as well as switching between the local
attachment circuits.
=E2=80=9C=E2=80=9D"
_______________________________________________
Pals mailing list
Pals@ietf.org
https://www.ietf.org/mailman/listinfo/pals