From marc@sniff.de Sat Jun 1 13:35:09 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A88C21F9D69; Sat, 1 Jun 2013 13:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJSUnIb61GXI; Sat, 1 Jun 2013 13:35:09 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD8121F9D8A; Sat, 1 Jun 2013 13:35:08 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 48BE22AA0F; Sat, 1 Jun 2013 20:35:05 +0000 (GMT) Date: Sat, 1 Jun 2013 22:34:55 +0200 From: Marc Binderberger To: Jeffrey Haas , Sam Aldrin , Santiago Alvarez (saalvare) , Binny Jeshan Message-ID: <20130601223455119054.8703c711@sniff.de> In-Reply-To: <20130510172441.GB12732@pfrc> References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> <20130510172441.GB12732@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" , "pwe3@ietf.org" Subject: Re: [PWE3] [mpls] Commenst on draft-akiya-bfd-intervals-03 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 20:35:09 -0000 Hello everyone, my apologies for the late reply. Too many things at once :-) It looks like we agree towards an "informal" document. This may be partially due to a misunderstanding, a "standard" document would define a minimum set of to-be-supported intervals, it would not forbid to support additional timer interval values, in my view. Anyway, the goal to improve interoperability can be reached with "informal" too, so I'm fine. For the split-off of appendix B: I can write a new draft, no problem. The question is to the BFD list though: do you think we should dive deeper into the timer negotiation area? If everyone thinks the appendix B is "obvious" or "trivial" then there is no point for a new document. If implementors think we better do write down these details and discuss them - then we have a basis for a new draft :-) To quickly explain the problem again: RFC5880 and the Poll sequence described therein implicitly assume that the peer can accept any timer value. Thus the Poll sequence is a simple P-bit, F-bit sequence. With hardware-based implementations we may see a more granular timer support and the peer can _not_ accept the new interval proposed. More negotiations would be required to find a commonly supported timer value (which exists when following the draft's minimum set of values). Appendix B describes the procedure we propose. Regards, Marc On Fri, 10 May 2013 13:24:41 -0400, Jeffrey Haas wrote: > On Mon, Dec 03, 2012 at 11:53:47AM -0800, Sam Aldrin wrote: >> I echo what Santiago had said in his email. Good to have an >> informational document and do not support the idea of standardizing >> the intervals. > > Speaking as chair, while I'm not in favor of have a standardized set of > intervals (the fights such a document would create would be epic), I am > highly supportive of such a document having informational status. > > As a suggestion, there may be two actual documents in such a case: > - An informational document covering the intervals. > - A short document, potentially on the standards track, covering the > procedure by which timers can negotiate to such an interval. This may be > worth standardizing. (This is covered by Appendix B.) > > -- Jeff From nobo@cisco.com Sat Jun 1 19:27:19 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A457111E80A2; Sat, 1 Jun 2013 19:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3pgLw3WhRkd; Sat, 1 Jun 2013 19:27:14 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A468411E80EF; Sat, 1 Jun 2013 19:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3581; q=dns/txt; s=iport; t=1370140034; x=1371349634; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cN6KhN/xqsWvX1FY3eNkN8pixJJLwqmKMF3XBxLtDok=; b=UNUi1+nS1FxU4DaOI9KqEYChSQDsarYCopOAP2wO306C4HlGCezddvCS ngL5QLtvJbjO77mjnbPm/r9lb0F9Z010kAVIsPJB+Q6VX9K4Q+3B5eeIx ItV3roR3P8zA4HtTKsNI293IemeLR/62NVUlDYRj9f8UtT1SF+M/82gXF 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFADisqlGtJV2d/2dsb2JhbABZgmghML8DfxZ0giMBAQEEAQEBNzQLDAQCAQgRBAEBAQoUCQcnCxQJCAIEAQ0FCIgFAQu5JwSNWguBETEHBoJxYQOofoMPgXE2 X-IronPort-AV: E=Sophos;i="4.87,786,1363132800"; d="scan'208";a="217474187" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 02 Jun 2013 02:27:14 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r522RD3P029063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 2 Jun 2013 02:27:13 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Sat, 1 Jun 2013 21:27:13 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger , Jeffrey Haas , "Sam Aldrin" , "Santiago Alvarez (saalvare)" , Binny Jeshan Thread-Topic: [mpls] Commenst on draft-akiya-bfd-intervals-03 Thread-Index: Ac3Rh3XM5+9UcfrcQ2S8rX469rwQOQAAVMZQAAy8rAAAAN+FAAAAiuEAAAAzaYAfAr3RgARZDheAAAEjodA= Date: Sun, 2 Jun 2013 02:27:13 +0000 Message-ID: References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> <20130510172441.GB12732@pfrc> <20130601223455119054.8703c711@sniff.de> In-Reply-To: <20130601223455119054.8703c711@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.188] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" , "pwe3@ietf.org" Subject: Re: [PWE3] [mpls] Commenst on draft-akiya-bfd-intervals-03 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 02:27:19 -0000 Hello Marc, et al, Before going into "timer negotiation deep dive", it'll be beneficial to def= ine the contents of the informational draft. In addition to set of interval= s specified, the document can also describe usefulness in implementation su= pporting multiples of specified intervals. Such implementations will be abl= e to support large set of intervals, and even larger set when jitter consid= ered. I think the result will be very useful to anybody implementing/operat= ing HW BFD. Once we converge on that, then perhaps we can take up the discu= ssion of whether we need additional standard track draft or not, and with w= hat contents. Regards, Nobo > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Marc Binderberger > Sent: Saturday, June 01, 2013 4:35 PM > To: Jeffrey Haas; Sam Aldrin; Santiago Alvarez (saalvare); Binny Jeshan > Cc: mpls@ietf.org; rtg-bfd@ietf.org; pwe3@ietf.org > Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 >=20 > Hello everyone, >=20 > my apologies for the late reply. Too many things at once :-) >=20 >=20 > It looks like we agree towards an "informal" document. This may be partia= lly > due to a misunderstanding, a "standard" document would define a > minimum set of to-be-supported intervals, it would not forbid to support > additional timer interval values, in my view. Anyway, the goal to improve > interoperability can be reached with "informal" too, so I'm fine. >=20 >=20 > For the split-off of appendix B: I can write a new draft, no problem. > The question is to the BFD list though: do you think we should dive deepe= r > into the timer negotiation area? If everyone thinks the appendix B is > "obvious" or "trivial" then there is no point for a new document. If > implementors think we better do write down these details and discuss > them - then we have a basis for a new draft :-) >=20 > To quickly explain the problem again: RFC5880 and the Poll sequence > described therein implicitly assume that the peer can accept any timer > value. Thus the Poll sequence is a simple P-bit, F-bit sequence. With > hardware-based implementations we may see a more granular timer > support and the peer can _not_ accept the new interval proposed. More > negotiations would be required to find a commonly supported timer value > (which exists when following the draft's minimum set of values). > Appendix B describes the procedure we propose. >=20 >=20 > Regards, Marc >=20 >=20 >=20 > On Fri, 10 May 2013 13:24:41 -0400, Jeffrey Haas wrote: > > On Mon, Dec 03, 2012 at 11:53:47AM -0800, Sam Aldrin wrote: > >> I echo what Santiago had said in his email. Good to have an > >> informational document and do not support the idea of standardizing > >> the intervals. > > > > Speaking as chair, while I'm not in favor of have a standardized set > > of intervals (the fights such a document would create would be epic), > > I am highly supportive of such a document having informational status. > > > > As a suggestion, there may be two actual documents in such a case: > > - An informational document covering the intervals. > > - A short document, potentially on the standards track, covering the > > procedure by which timers can negotiate to such an interval. This ma= y be > > worth standardizing. (This is covered by Appendix B.) > > > > -- Jeff > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From jhaas@slice.pfrc.org Sun Jun 2 05:48:17 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1BF21F90FD; Sun, 2 Jun 2013 05:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6tqN3IObXCT; Sun, 2 Jun 2013 05:48:12 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0B84D21F8E8F; Sun, 2 Jun 2013 05:48:12 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7C8C4C21A; Sun, 2 Jun 2013 08:48:08 -0400 (EDT) Date: Sun, 2 Jun 2013 08:48:08 -0400 From: Jeffrey Haas To: Marc Binderberger Message-ID: <20130602124808.GK10807@pfrc> References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> <20130510172441.GB12732@pfrc> <20130601223455119054.8703c711@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130601223455119054.8703c711@sniff.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "mpls@ietf.org" , Santiago Alvarez , "pwe3@ietf.org" , Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: [PWE3] [mpls] Commenst on draft-akiya-bfd-intervals-03 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 12:48:18 -0000 On Sat, Jun 01, 2013 at 10:34:55PM +0200, Marc Binderberger wrote: > It looks like we agree towards an "informal" document. This may be > partially due to a misunderstanding, a "standard" document would define > a minimum set of to-be-supported intervals, it would not forbid to > support additional timer interval values, in my view. Anyway, the goal > to improve interoperability can be reached with "informal" too, so I'm > fine. An informational draft on the specific timer values may be of benefit. One thing to ponder that has standards impact would be whether we'd want to request an IANA registry to record such "well known values". > For the split-off of appendix B: I can write a new draft, no problem. > The question is to the BFD list though: do you think we should dive > deeper into the timer negotiation area? If everyone thinks the > appendix B is "obvious" or "trivial" then there is no point for a new > document. If implementors think we better do write down these details > and discuss them - then we have a basis for a new draft :-) I think, given such a document specifying the well known values, that having a known mechanism supporting converging on those values may be helpful. My biggest concern for such a proposal is that it would encourage implementations to *only* support those values rather than providing targets for scaling certain specific timers. Consider, for example, a scenario where a device going into a temporary maintenance mode may want to significantly reduce its detection interval (say > 3s) for a short period of time. If the remote device didn't have that 3s+ value as one of its "magic numbers", then it may simply drop the session depending on procedure. These, of course, are just details to consider for the draft. -- Jeff From internet-drafts@ietf.org Mon Jun 3 20:29:27 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324D221F8EC6; Mon, 3 Jun 2013 20:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.354 X-Spam-Level: X-Spam-Status: No, score=-102.354 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnPMwUowszPb; Mon, 3 Jun 2013 20:29:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBBD11E8103; Mon, 3 Jun 2013 19:38:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130604023813.10781.77085.idtracker@ietfa.amsl.com> Date: Mon, 03 Jun 2013 19:38:13 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 03:29:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Working= Group of the IETF. Title : LDP extensions for Pseudowire Binding to LSP Tunnels Author(s) : Mach(Guoyi) Chen Wei Cao Attila Takacs Ping Pan Filename : draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01.txt Pages : 15 Date : 2013-06-03 Abstract: Many transport services require that user traffic, in the forms of Pseudowires (PW), to be delivered on a single co-routed bidirectional LSP or two LSPs that share the same routes. In addition, the user traffic may traverse through multiple transport networks. This document specifies an optional extension in LDP that enable the binding between PWs and the underlying LSPs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pwe3-mpls-tp-pw-over-bidir-ls= p-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From adrian@olddog.co.uk Fri Jun 7 07:31:28 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B3121F9843; Fri, 7 Jun 2013 07:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZgvF+m97hSY; Fri, 7 Jun 2013 07:31:23 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 2548021F9920; Fri, 7 Jun 2013 07:31:10 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r57EV6D2007140; Fri, 7 Jun 2013 15:31:06 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r57EV5Kk007127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Jun 2013 15:31:06 +0100 From: "Adrian Farrel" To: , , , , Date: Fri, 7 Jun 2013 15:30:59 +0100 Message-ID: <0afa01ce638b$a2067820$e6136860$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5ji41bX64WTevZT8eVu8We0gvrYQ== Content-Language: en-gb Cc: draft-ietf-ipsecme-ad-vpn-problem.all@tools.ietf.org Subject: [PWE3] Heads up : IETF Last Call on "Auto Discovery VPN Problem Statement and Requirements" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 14:31:28 -0000 Hi VPN-related working groups, Please be aware of this document that is in IETF last call. Comments should be sent following the instructions in the email below and *not* to the mailing lists I have spammed. Thanks, Adrian > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of The IESG > Sent: 07 June 2013 15:00 > To: IETF-Announce > Cc: ipsec@ietf.org > Subject: Last Call: (Auto Discovery > VPN Problem Statement and Requirements) to Informational RFC > > > The IESG has received a request from the IP Security Maintenance and > Extensions WG (ipsecme) to consider the following document: > - 'Auto Discovery VPN Problem Statement and Requirements' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-06-21. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document describes the problem of enabling a large number of > systems to communicate directly using IPsec to protect the traffic > between them. It then expands on the requirements, for such a > solution. > > Manual configuration of all possible tunnels is too cumbersome in > many such cases. In other cases the IP address of endpoints change > or the endpoints may be behind NAT gateways, making static > configuration impossible. The Auto Discovery VPN solution will > address these requirements. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem/ballot/ > > > No IPR declarations have been submitted directly on this I-D. From prvs=987046ee83=gregory.mirsky@ericsson.com Fri Jun 7 15:19:06 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDD521F99AA; Fri, 7 Jun 2013 15:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYFkG6S9h3cq; Fri, 7 Jun 2013 15:19:00 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 388D121F99A6; Fri, 7 Jun 2013 15:18:59 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-0c-51b25c4d1d4c Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 5B.4F.17537.E4C52B15; Sat, 8 Jun 2013 00:18:54 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Fri, 7 Jun 2013 18:18:53 -0400 From: Gregory Mirsky To: Mach Chen , "wayne.caowei@huawei.com" , Attila Takacs , "ppan@infinera.com" , "mpls@ietf.org" , "pwe3@ietf.org" Thread-Topic: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 Thread-Index: Ac5jzPqpud3c0SMmSem+Bl4MHVP2Mg== Date: Fri, 7 Jun 2013 22:18:52 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B4A0E8C@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B4A0E8Ceusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyuXRPrK5fzKZAg5nrpCwurBW2uLV0JavF isfvWC36Pm1hsWg+dordgdWj5chbVo8lS34yeVx6cYgtgDmK2yYpsaQsODM9T98ugTvjeMts poItIhV/F39ga2DsE+xi5OSQEDCR+HFvKROELSZx4d56ti5GLg4hgaOMEvNudLBDOMsYJc5t WcgCUsUmYCTxYmMPWEJE4BujRNuCf2DtwgKOEp9XT2QEsUUE3CSm9i5gg7D1JFa1PmQGsVkE VCQav/9kB7F5BXwl7t8/B1bPCLT6+6k1YHOYBcQlbj2ZD3WSgMSSPeeZIWxRiZeP/7FC2MoS S57sZ4Goz5f4MG0OM8RMQYmTM5+wTGAUmoVk1CwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z 4DETsvgCRvZVjBylxalluelGBpsYgZFzTIJNdwfjnpeWhxilOViUxHnVeBcHCgmkJ5akZqem FqQWxReV5qQWH2Jk4uAEEVxSDYxFCrWz79Y+/357Dtf0ybeNJ9oKLrSZyyaxUnBqVjPzJW3T +jXtR2ac0zr3tmehdBqTwl/ZZfFqQesOTn42y3wfy5vN6+xU1/c4O+aaR4s9XFY5q7m1ufd8 yOU1bqtz589XYfY2O315ZcvX52tmmInw/ez0fmd2/u6iCv5zS4Nf50TUqFeqH3JQYinOSDTU Yi4qTgQA0Q8PKW8CAAA= Subject: [PWE3] Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 22:19:07 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B4A0E8Ceusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et al., I've prepared some questions and comments that I hope you'll kindly conside= r: * I've got confused by definition of C bit in section 2.1. That might= be in part because congruency in geometry has very certain definition and = I'm projecting that to term congruent path introduced in the document. In a= ddition I think that "same route" in the second sentence is vague. Does tha= t imply that active PE requests far-end PE to use co-routed LSP? If that is= the case, should C bit explained as request to use Co-routed path? * Last sentence of section 2.1 defines that detection of C and S bits= being simultaneously set as error. How that error being signaled in LDP St= atus Codes? Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B4A0E8Ceusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors, et al.,
I've prepared some questions and comments that I hope you'll kindly co= nsider:
  • I've got confused by definition of C bit in section 2.1. That might be = in part because congruency in geometry has very certain definition and I'm = projecting that to term congruent path introduced in the document. In addit= ion I think that "same route" in the second sentence is vague. Does that imply that active PE requests far-e= nd PE to use co-routed LSP? If that is the case, should C bit explained as = request to use Co-routed path?
  • Last sentence of section 2.1 defines= that detection of C and S bits being simultaneously set as error. How that= error being signaled in LDP Status Codes?
 
        Regards,
           &nbs= p;    Greg
 
 --_000_7347100B5761DC41A166AC17F22DF1121B4A0E8Ceusaamb103erics_-- From mach.chen@huawei.com Sat Jun 8 20:03:27 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3F921F96D9; Sat, 8 Jun 2013 20:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vD106pJfXRY; Sat, 8 Jun 2013 20:03:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 578BC21F96A9; Sat, 8 Jun 2013 20:03:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATR85650; Sun, 09 Jun 2013 03:03:17 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 9 Jun 2013 04:02:18 +0100 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 9 Jun 2013 04:03:14 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.243]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.007; Sun, 9 Jun 2013 11:03:02 +0800 From: Mach Chen To: Gregory Mirsky , "Caowei (Wayne)" , Attila Takacs , "ppan@infinera.com" , "mpls@ietf.org" , "pwe3@ietf.org" Thread-Topic: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 Thread-Index: Ac5jzPqpud3c0SMmSem+Bl4MHVP2MgA690VA Date: Sun, 9 Jun 2013 03:03:01 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B4A0E8C@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B4A0E8C@eusaamb103.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BAEAA2szxeml558mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [PWE3] Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 03:03:28 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BAEAA2szxeml558mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks for your comments! Yes, it intends to mean co-routed here. Not use the "co-routed" because the= re is definition of co-routed bidirectional LSP, where the "co-routed" mea= ns not only co-routed but signaled by a single path/resv exchange. If the W= G think co-routed is better, I am fine to change to it. For example, change the C (Congruent Path) bit to C (Co-routed path) bit, a= nd then it's definition would like this: "C (Co-routed path) bit: This informs the remote T-PE/S-PEs about the prope= rties of the underlying LSPs. When set, the remote T-PE/S-PEs need to selec= t co-routed LSP as the PSN tunnel. If there is no such tunnel available, th= e node may trigger the remote T-PE/S-PEs to establish a new LSP." How do you think? Best regards, Mach From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Saturday, June 08, 2013 6:19 AM To: Mach Chen; Caowei (Wayne); Attila Takacs; ppan@infinera.com; mpls@ietf.= org; pwe3@ietf.org Subject: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 Dear Authors, et al., I've prepared some questions and comments that I hope you'll kindly conside= r: * I've got confused by definition of C bit in section 2.1. That mig= ht be in part because congruency in geometry has very certain definition an= d I'm projecting that to term congruent path introduced in the document. In= addition I think that "same route" in the second sentence is vague. Does t= hat imply that active PE requests far-end PE to use co-routed LSP? If that = is the case, should C bit explained as request to use Co-routed path? * Last sentence of section 2.1 defines that detection of C and S bi= ts being simultaneously set as error. How that error being signaled in LDP = Status Codes? Regards, Greg --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BAEAA2szxeml558mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Greg,=

=  

= Thanks for your comments!

=  

= Yes, it intends to mean co-routed here. Not use the “co-routed” because there is definition of <= span style=3D"mso-spacerun:yes">  co-routed bidirectional LSP, where the “co-routed”= means not only co-routed but signaled by a single path/resv exchange. If the WG think co-routed is better, I am fine to= change to it.

=  

= For example, change the C (Congru= ent Path) bit to C (Co-routed path) bit, and then it’s definition would = like this:

=  

= “C (Co-routed path) bit: Th= is informs the remote T-PE/S-PEs about the properties of the underlying LSPs. When se= t, the remote T-PE/S-PEs need to select co-routed LSP as the PSN tunnel. If= there is no such tunnel available, the node may trigger the remote T-PE/S-= PEs to establish a new LSP.”

=  

= How do you think?

=  

= Best regards,

= Mach

=  

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Saturday, June 08, 201= 3 6:19 AM
To: Mach Chen; Caowei (Wayne= ); Attila Takacs; ppan@infinera.com; mpls@ietf.org; pwe3@ietf.org
Subject: Comments to draft-i= etf-pwe3-mpls-tp-pw-over-bidir-lsp-01

 

Dear Authors, et = al.,

I've prepared som= e questions and comments that I hope you'll kindly consider:

·         I've got confused by definition of C bit in section 2.1. That might be in part because congruency in geometry has very certain definition and = I'm projecting that to term congruent path introduced in the document. In a= ddition I think that "same route" in the second sentence is vague= . Does that imply that active PE requests far-end PE to use co-routed LSP? If that is the case, should C bit explain= ed as request to use Co-routed path?

·         Last sentence of section 2.1 defines that detection of C and S bits being simultaneously set as error. How that error being signaled in LDP St= atus Codes?

 =

   = ;     Regards,

   = ;             G= reg

 =

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BAEAA2szxeml558mbschi_-- From prvs=7874684126=gregory.mirsky@ericsson.com Tue Jun 11 11:32:20 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354BD21F9799; Tue, 11 Jun 2013 11:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STqAcTEcFwtG; Tue, 11 Jun 2013 11:32:13 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6583C21F9811; Tue, 11 Jun 2013 11:32:12 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-bc-51b76d2b6b7d Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id B9.3B.17537.B2D67B15; Tue, 11 Jun 2013 20:32:11 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Tue, 11 Jun 2013 14:32:10 -0400 From: Gregory Mirsky To: Mach Chen , "Caowei (Wayne)" , Attila Takacs , "ppan@infinera.com" , "mpls@ietf.org" , "pwe3@ietf.org" Thread-Topic: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 Thread-Index: Ac5jzPqpud3c0SMmSem+Bl4MHVP2MgA690VAAIXnbXA= Date: Tue, 11 Jun 2013 18:32:09 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B4A14DF@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B4A0E8C@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B4A14DFeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyuXRPuK527vZAg6PrZCwurBW2uLV0JavF isfvWC36Pm1hsWg+dordgdWj5chbVo8lS34yeVx6cYgtgDmK2yYpsaQsODM9T98ugTvjyMLj 7AVHtzBVdF3dydLAeHgyUxcjB4eEgInEiS8sXYycQKaYxIV769m6GLk4hASOMkr8/vaSHcJZ zihx93MrE0gVm4CRxIuNPWAJEYG3jBK/pvaxgSSEBVwltrQ3gBWJCLhJTO1dwAZhW0msXL6Z FcRmEVCV2HtzGdg6XgFfifUPV0NtmMkosWbNPLBmToEwiRfLt4IVMQLd9P3UGrA4s4C4xK0n 85kgbhWQWLLnPDOELSrx8vE/VghbWWLJk/0sEPX5EjdO7GSDWCYocXLmE5YJjCKzkIyahaRs FpIyiLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvoqRo7Q4tSw33chgEyMw2o5JsOnuYNzz 0vIQozQHi5I4rxrv4kAhgfTEktTs1NSC1KL4otKc1OJDjEwcnCCCS6qBcerluGuXmdX3PxLs XB1SIsYd/sE/oPkmw64czzD2b/M7jU5fFJpfpCEdUfHoy8OcveaPVtxkNbt85/HLJ9bbu9a/ Wx8xjf2HUfGuWoGj1WtW5nqeEmaw2vZnxcqFDB03JFhex1xa3JTRfij17Hm3H2v/XZYvaEk6 udnb2OTDsdZN5jo1fjc+/VNiKc5INNRiLipOBAAyZepLiQIAAA== Subject: Re: [PWE3] Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 18:32:20 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B4A14DFeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mach, yes, I think I see what caused your hesitation "the remote T-PE/S-PEs to es= tablish a new (co-routed) LSP". Frankly, I need to go back to authoritive s= ources, but I think that signaling of a co-routed LSP is not mandated to be= in single Path/Resv pass. I think that if intention is to map PW onto co-r= outed LSP, then C in C-bit should stand for "co-routed". Regards, Greg ________________________________ From: Mach Chen [mailto:mach.chen@huawei.com] Sent: Saturday, June 08, 2013 8:03 PM To: Gregory Mirsky; Caowei (Wayne); Attila Takacs; ppan@infinera.com; mpls@= ietf.org; pwe3@ietf.org Subject: RE: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 Hi Greg, Thanks for your comments! Yes, it intends to mean co-routed here. Not use the "co-routed" because the= re is definition of co-routed bidirectional LSP, where the "co-routed" mea= ns not only co-routed but signaled by a single path/resv exchange. If the W= G think co-routed is better, I am fine to change to it. For example, change the C (Congruent Path) bit to C (Co-routed path) bit, a= nd then it's definition would like this: "C (Co-routed path) bit: This informs the remote T-PE/S-PEs about the prope= rties of the underlying LSPs. When set, the remote T-PE/S-PEs need to selec= t co-routed LSP as the PSN tunnel. If there is no such tunnel available, th= e node may trigger the remote T-PE/S-PEs to establish a new LSP." How do you think? Best regards, Mach From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Saturday, June 08, 2013 6:19 AM To: Mach Chen; Caowei (Wayne); Attila Takacs; ppan@infinera.com; mpls@ietf.= org; pwe3@ietf.org Subject: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 Dear Authors, et al., I've prepared some questions and comments that I hope you'll kindly conside= r: * I've got confused by definition of C bit in section 2.1. That mig= ht be in part because congruency in geometry has very certain definition an= d I'm projecting that to term congruent path introduced in the document. In= addition I think that "same route" in the second sentence is vague. Does t= hat imply that active PE requests far-end PE to use co-routed LSP? If that = is the case, should C bit explained as request to use Co-routed path? * Last sentence of section 2.1 defines that detection of C and S bi= ts being simultaneously set as error. How that error being signaled in LDP = Status Codes? Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B4A14DFeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Mach,
yes, I think I see what caused yo= ur hesitation "the remote T-PE/S-PEs to establish a new (co-routed) LS= P". Frankly, I need to go back to authoritive sources, but I think that signaling of a co-routed LSP is not mandated to be in sin= gle Path/Resv pass. I think that if intention is to map PW onto co-routed L= SP, then C in C-bit should stand for "co-routed".
 
 &n= bsp;  Regards,
 &n= bsp;      Greg

From: Mach Chen [mailto:mach.chen@h= uawei.com]
Sent: Saturday, June 08, 2013 8:03 PM
To: Gregory Mirsky; Caowei (Wayne); Attila Takacs; ppan@infinera.com= ; mpls@ietf.org; pwe3@ietf.org
Subject: RE: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-0= 1

= Hi Greg,

=  

= Thanks for your comments!

=  

= Yes, it intends to mean co-routed here. Not use the “co-routed” because there is defin= ition of  co-routed bidirectional LSP, where the “co-routed”= means not only co-routed but signaled by a single path/resv exchange. If the WG think co-routed is better, I am fine to= change to it.

=  

= For example, change the C (Congruent Path) bit to C (Co-routed path) bit, and then it’s defi= nition would like this:

=  

= “C (Co-routed path) bit: This informs the remote T-PE/S-PEs about the properties of the underlying = LSPs. When set, the remote T-PE/S-PEs need to select co-routed LSP as the P= SN tunnel. If there is no such tunnel available, the node may trigger the r= emote T-PE/S-PEs to establish a new LSP.”

=  

= How do you think?

=  

= Best regards,

= Mach

=  

From:<= /b> Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Saturday, June 08, 20= 13 6:19 AM
To: Mach Chen; Caowei (Wayn= e); Attila Takacs; ppan@infinera.com; mpls@ietf.org; pwe3@ietf.org
Subject: Comments to draft-= ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01

 

Dear Authors, et al.,

I've prepared some questions and comments th= at I hope you'll kindly consider:

·= ;         I've got confused by d= efinition of C bit in section 2.1. That might be in part because congruency in geometry has very certain definitio= n and I'm projecting that to term congruent path introduced in the document= . In addition I think that "same route" in the second sentence is= vague. Does that imply that active PE requests far-end PE to use co-routed LSP? If that is the case, should C bit explain= ed as request to use Co-routed path?

·= ;         Last sentence of secti= on 2.1 defines that detection of C and S bits being simultaneously set as error. How that error being signaled in L= DP Status Codes?

 

        R= egards,

       &n= bsp;        Greg

 

--_000_7347100B5761DC41A166AC17F22DF1121B4A14DFeusaamb103erics_-- From mach.chen@huawei.com Thu Jun 13 00:58:00 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5BC21F9A38; Thu, 13 Jun 2013 00:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jX5MPVlhrxeW; Thu, 13 Jun 2013 00:57:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1E62621F99E9; Thu, 13 Jun 2013 00:57:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASK37160; Thu, 13 Jun 2013 07:57:51 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 13 Jun 2013 08:57:27 +0100 Received: from szxeml459-hub.china.huawei.com (10.82.67.202) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 13 Jun 2013 08:57:40 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.243]) by szxeml459-hub.china.huawei.com ([10.82.67.202]) with mapi id 14.01.0323.007; Thu, 13 Jun 2013 15:56:20 +0800 From: Mach Chen To: Gregory Mirsky , "Caowei (Wayne)" , Attila Takacs , "ppan@infinera.com" , "mpls@ietf.org" , "pwe3@ietf.org" Thread-Topic: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 Thread-Index: Ac5jzPqpud3c0SMmSem+Bl4MHVP2MgA690VAAIXnbXAATjsfsA== Date: Thu, 13 Jun 2013 07:56:20 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B4A0E8C@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B4A14DF@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B4A14DF@eusaamb103.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BB03DEszxeml558mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [PWE3] Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 07:58:00 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BB03DEszxeml558mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, OK, I am fine with "co-routed". In addition, regarding to "the C and S bits being simultaneously set", ther= e should be an error code should be signaled, a new status code("The C-bit = and S-bit cannot be both set") will be added in the next revision. Best regards, Mach From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Wednesday, June 12, 2013 2:32 AM To: Mach Chen; Caowei (Wayne); Attila Takacs; ppan@infinera.com; mpls@ietf.= org; pwe3@ietf.org Subject: RE: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 Hi Mach, yes, I think I see what caused your hesitation "the remote T-PE/S-PEs to es= tablish a new (co-routed) LSP". Frankly, I need to go back to authoritive s= ources, but I think that signaling of a co-routed LSP is not mandated to be= in single Path/Resv pass. I think that if intention is to map PW onto co-r= outed LSP, then C in C-bit should stand for "co-routed". Regards, Greg ________________________________ From: Mach Chen [mailto:mach.chen@huawei.com] Sent: Saturday, June 08, 2013 8:03 PM To: Gregory Mirsky; Caowei (Wayne); Attila Takacs; ppan@infinera.com; mpls@= ietf.org; pwe3@ietf.org Subject: RE: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 Hi Greg, Thanks for your comments! Yes, it intends to mean co-routed here. Not use the "co-routed" because the= re is definition of co-routed bidirectional LSP, where the "co-routed" mea= ns not only co-routed but signaled by a single path/resv exchange. If the W= G think co-routed is better, I am fine to change to it. For example, change the C (Congruent Path) bit to C (Co-routed path) bit, a= nd then it's definition would like this: "C (Co-routed path) bit: This informs the remote T-PE/S-PEs about the prope= rties of the underlying LSPs. When set, the remote T-PE/S-PEs need to selec= t co-routed LSP as the PSN tunnel. If there is no such tunnel available, th= e node may trigger the remote T-PE/S-PEs to establish a new LSP." How do you think? Best regards, Mach From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Saturday, June 08, 2013 6:19 AM To: Mach Chen; Caowei (Wayne); Attila Takacs; ppan@infinera.com; mpls@ietf.= org; pwe3@ietf.org Subject: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01 Dear Authors, et al., I've prepared some questions and comments that I hope you'll kindly conside= r: * I've got confused by definition of C bit in section 2.1. That mig= ht be in part because congruency in geometry has very certain definition an= d I'm projecting that to term congruent path introduced in the document. In= addition I think that "same route" in the second sentence is vague. Does t= hat imply that active PE requests far-end PE to use co-routed LSP? If that = is the case, should C bit explained as request to use Co-routed path? * Last sentence of section 2.1 defines that detection of C and S bi= ts being simultaneously set as error. How that error being signaled in LDP = Status Codes? Regards, Greg --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BB03DEszxeml558mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Greg,

=  

= OK= , I am fine with “co-routed”.

=  

= In addition, regarding to “the C and S bits being simultaneously set= 221;, there should be an error code should be signaled, a new status code(&= #8220;The C-bit and S-bit cannot be both set”) will be added in the n= ext revision.

=  

= Be= st regards,

= Ma= ch

=  

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Wednesday, June 12, 20= 13 2:32 AM
To: Mach Chen; Caowei (Wayne= ); Attila Takacs; ppan@infinera.com; mpls@ietf.org; pwe3@ietf.org
Subject: RE: Comments to dra= ft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01

 

Hi Mach,

yes, I think I see what caused your hesitation "the remote T-= PE/S-PEs to establish a new (co-routed) LSP". Frankly, I need to go back to au= thoritive sources, but I think that signaling of a co-routed LSP is not man= dated to be in single Path/Resv pass. I think that if intention is to map P= W onto co-routed LSP, then C in C-bit should stand for "co-routed".

 

    = Regards,

        = Greg

 

From: Mach Chen [mailto:mach.chen@huawei.com]
Sent: Saturday, June 08, 201= 3 8:03 PM
To: Gregory Mirsky; Caowei (= Wayne); Attila Takacs; ppan@infinera.com; mpls@ietf.org; pwe3@ietf.org
Subject: RE: Comments to dra= ft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01<= /span>

= Hi Greg,=

=  

= Thanks for your comments!

=  

= Yes, it intends to mean co-routed here. Not use the “co-routed” because there is definition of  co-routed bidirectional LSP, where the “co-routed” means= not only co-routed but signaled by a single path/resv exchange. If the WG = think co-routed is better, I am fine to change to it.

=  

= For example, change the C (Congru= ent Path) bit to C (Co-routed path) bit, and then it’s definition would = like this:

=  

= “C (Co-routed path) bit: Th= is informs the remote T-PE/S-PEs about the properties of the underlying LSPs. When se= t, the remote T-PE/S-PEs need to select co-routed LSP as the PSN tunnel. If= there is no such tunnel available, the node may trigger the remote T-PE/S-= PEs to establish a new LSP.”

=  

= How do you think?

=  

= Best regards,

= Mach

=  

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Saturday, June 08, 201= 3 6:19 AM
To: Mach Chen; Caowei (Wayne= ); Attila Takacs; ppan@infinera.com; mpls@ietf.org; pwe3@ietf.org
Subject: Comments to draft-i= etf-pwe3-mpls-tp-pw-over-bidir-lsp-01

 

Dear Authors, et = al.,

I've prepared som= e questions and comments that I hope you'll kindly consider:

·    = ;     I've got confused by defin= ition of C bit in section 2.1. That might be in part because congruency in geometry has very certain definition and I'm projecting that to term co= ngruent path introduced in the document. In addition I think that "sam= e route" in the second sentence is vague. Does that imply that active = PE requests far-end PE to use co-routed LSP? If that is the case, should C bit explained as request to use Co-routed pa= th?

·    = ;     Last sentence of section 2= .1 defines that detection of C and S bits being simultaneously set as error. How that error being signaled in LDP Status Codes?

 =

   = ;     Regards,

   = ;             G= reg

 =

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BB03DEszxeml558mbschi_-- From loa@pi.nu Thu Jun 13 05:45:28 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECE821F9A58; Thu, 13 Jun 2013 05:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4S9hshWzf43c; Thu, 13 Jun 2013 05:45:22 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id B875C21F9A31; Thu, 13 Jun 2013 05:44:10 -0700 (PDT) Received: from [10.140.13.213] (109.58.145.109.bredband.tre.se [109.58.145.109]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 8E4E81800272; Thu, 13 Jun 2013 14:44:08 +0200 (CEST) Message-ID: <51B9BE97.2090103@pi.nu> Date: Thu, 13 Jun 2013 14:44:07 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "mpls@ietf.org" , "pwe3@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , "pwe3-chairs@tools.ietf.org" Subject: [PWE3] Working Group Last Call on draft-ietf-mpls-retire-ach-tlv X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 12:45:28 -0000 Working Groups, PWE3 working group, This is to start a two week working group last call on an MPLS document, but since it will be of interest to the PWE3 group also the chairs agreed to copy it to the PWE3 mailing list as well. Please keep the discussion on the mpls working group mailing list. MPLS working group, this is to start a two week Working Group last call on draft-ietf-mpls-retire-ach-tlv-01. Please send your comments to the mpls working group mailing list (mpls@ietf.org). Please send both technical comments, and if you are happy with the document as is also indications of support. There are no IPR claims against this draft. The co-authors have earlier stated that they are not aware of any IPRs applicable to this draft. If anyone else in the working group are aware of IPRs claims against this draft, the time to disclose that is now. This working group last call will end on June 27, 2013. /Loa for the wg co-chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From agmalis@gmail.com Mon Jun 17 00:27:06 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE9D21F9AC1 for ; Mon, 17 Jun 2013 00:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lx1Wg3J+z7Ak for ; Mon, 17 Jun 2013 00:27:05 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 117C721F90CC for ; Mon, 17 Jun 2013 00:27:04 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so3693059wiw.2 for ; Mon, 17 Jun 2013 00:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=uEkJ1d+uA0vD6ipK4cO7Nwf50ojW2npt3WEBimeBafQ=; b=jZ1F9caON9hl0rwQDXDjEUcYfiVXyaH9SjejbCygMpEUmJK3GtTdxzq9REK6iZO0Nt o9yCy6gufS0wRrsmLzSK3WoiJ9Yy30/KaKZ5HMQwOaZ9meSpyH5md/CgunFC3q537l3U VAntkGGQDyOzSpCqjMnC9xB9hM3UWgOL4myKOH13C+o0llq0M4Iv1NfWzYHJBIiN2L4g sPwNFQD9cOX9u0Df5BjcJ532YS6e3eucESDBbsI6+vGu8hnZiqLuymIp5Mvbi1ac2aEs V86wmGT9DNckbG59Bnbu3/5nvN1kqlYQM941kg00sPsfh0OVoI683H1TDCeRW/LiAV63 ULAg== X-Received: by 10.180.20.46 with SMTP id k14mr4137974wie.14.1371454019482; Mon, 17 Jun 2013 00:26:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.53.73 with HTTP; Mon, 17 Jun 2013 00:26:39 -0700 (PDT) From: "Andrew G. Malis" Date: Mon, 17 Jun 2013 09:26:39 +0200 Message-ID: To: "pwe3@ietf.org" Content-Type: multipart/alternative; boundary=bcaec53f34eba8387004df5485dc Subject: [PWE3] Loa Andersson as document shepherd for draft-ietf-pwe3-dynamic-ms-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 07:27:06 -0000 --bcaec53f34eba8387004df5485dc Content-Type: text/plain; charset=ISO-8859-1 PWE3ers, Loa has kindly volunteered to be the document shepherd for draft-ietf-pwe3-dynamic-ms-pw. The authors have been asked to refresh the draft, since it's currently expired, Loa will also be conducting IPR and implementation polls for the draft, so please assist him when you see his emails. Thanks, Andy --bcaec53f34eba8387004df5485dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
PWE3ers,

Loa has kindly volunteered to be the = document shepherd for draft-ietf-pwe3-dynamic-ms-pw. The authors have been = asked to refresh the draft, since it's currently expired, Loa will also= be conducting IPR and implementation polls for the draft, so please assist= him when you see his emails.

Thanks,
Andy

--bcaec53f34eba8387004df5485dc-- From wwwrun@rfc-editor.org Mon Jun 17 06:59:06 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15E621F9BFD for ; Mon, 17 Jun 2013 06:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZlxIuUNc02G for ; Mon, 17 Jun 2013 06:59:06 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 4579F21F9BB8 for ; Mon, 17 Jun 2013 06:59:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1E9C262114; Mon, 17 Jun 2013 06:57:00 -0700 (PDT) To: praveen.muley@alcatel-lucent.com, mustapha.aissaoui@alcatel-lucent.com, stbryant@cisco.com, adrian@olddog.co.uk, matthew.bocci@alcatel-lucent.com, andrew.g.malis@verizon.com From: RFC Errata System Message-Id: <20130617135700.1E9C262114@rfc-editor.org> Date: Mon, 17 Jun 2013 06:57:00 -0700 (PDT) Cc: pwe3@ietf.org, joel.repiquet@in2eps.com, rfc-editor@rfc-editor.org Subject: [PWE3] [Editorial Errata Reported] RFC6870 (3656) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 13:59:06 -0000 The following errata report has been submitted for RFC6870, "Pseudowire Preferential Forwarding Status Bit". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6870&eid=3656 -------------------------------------- Type: Editorial Reported by: Joël Repiquet Section: GLOBAL Original Text ------------- Section 15 Corrected Text -------------- Appendix A Notes ----- 8 occurences: Section 15, 15.2, 15.5, Section 15.2, Section 15.1, Section 15.1, Section 15.3, Section 15.3 Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6870 (draft-ietf-pwe3-redundancy-bit-09) -------------------------------------- Title : Pseudowire Preferential Forwarding Status Bit Publication Date : February 2013 Author(s) : P. Muley, Ed., M. Aissaoui, Ed. Category : PROPOSED STANDARD Source : Pseudowire Emulation Edge to Edge Area : Routing Stream : IETF Verifying Party : IESG From internet-drafts@ietf.org Wed Jun 19 02:56:40 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2571421F9DA6; Wed, 19 Jun 2013 02:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eezpg15j-85K; Wed, 19 Jun 2013 02:56:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2C521F9D62; Wed, 19 Jun 2013 02:56:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130619095639.9371.72423.idtracker@ietfa.amsl.com> Date: Wed, 19 Jun 2013 02:56:39 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-dynamic-ms-pw-17.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 09:56:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Working= Group of the IETF. Title : Dynamic Placement of Multi Segment Pseudowires Author(s) : Luca Martini Matthew Bocci Florin Balus Filename : draft-ietf-pwe3-dynamic-ms-pw-17.txt Pages : 22 Date : 2013-06-19 Abstract: There is a requirement for service providers to be able to extend the reach of pseudowires (PW) across multiple Packet Switched Network domains. A Multi-Segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point- to-point PW. This document describes extensions to the PW control protocol to dynamically place the segments of the multi segment pseudowire among a set of Provider Edge (PE) routers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-dynamic-ms-pw There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pwe3-dynamic-ms-pw-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pwe3-dynamic-ms-pw-17 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From loa@pi.nu Wed Jun 19 08:59:24 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43FC21F9DC3 for ; Wed, 19 Jun 2013 08:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P03CbqbLaitC for ; Wed, 19 Jun 2013 08:59:18 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF1E21F9DB1 for ; Wed, 19 Jun 2013 08:59:17 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 1DE9C1801110; Wed, 19 Jun 2013 17:59:16 +0200 (CEST) Message-ID: <51C1D555.9060204@pi.nu> Date: Wed, 19 Jun 2013 17:59:17 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "pwe3@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3-ads@tools.ietf.org, "pwe3-chairs@tools.ietf.org" , draft-ietf-pwe3-dynamic-ms-pw@tools.ietf.org Subject: [PWE3] Shepherding draft-ietf-pwe3-dynamic-ms-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 15:59:25 -0000 PWE3 Working Group, As the working group chairs earlier said on the mailing list I've been asked and accepted to shepherd draft-ietf-pwe3-dynamic-ms-pw. The reason for picking me as a shepherd and not someone with a stronger PW-profile is that a very high percentage of the folks active in the PWE3 are on the list of authors for the document. I will do a (or have done) couple of things: - run this pretty much as if it were an MPLS wg document that I'm shepherding - since the document had expired I asked the authors to re-post the document with any changes; this has been done and we now have version -17 active - start an IPR poll; a separate mail on that will be sent to PWE3 mailing shortly - run an implementation poll; look out or this mail in 3-4 days time - do a shepherd review of the document; this is very close to done, but it is in ms word format and I've promised that I will create a text version for the mailing list. Anyone that want the word-file can send a unidirectional mail to me. I will also send the word-file to the authors - once the document has been updated and the polls responded to, I will finalize the "shepherd write-up"; normally I circulate the write-up to my co-chairs, the responsible AD and the authors for comments and review before it is sent with the publication request to the IESG. I don't know the practice in the pwe3 working group, but I will follow the lead of the working group chairs if I should send it to the working group mailing list or not. /Loa document shepherd for draft-ietf-pwe3-dynamic-ms-pw -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Wed Jun 19 10:46:33 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892FE21F883B for ; Wed, 19 Jun 2013 10:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKCJfilzznpd for ; Wed, 19 Jun 2013 10:46:29 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 32C9421F8F4F for ; Wed, 19 Jun 2013 10:46:06 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 1D3A71801110; Wed, 19 Jun 2013 19:46:05 +0200 (CEST) Message-ID: <51C1EE5E.7030403@pi.nu> Date: Wed, 19 Jun 2013 19:46:06 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "pwe3@ietf.org" , draft-ietf-pwe3-dynamic-ms-pw@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3-ads@tools.ietf.org, "pwe3-chairs@tools.ietf.org" Subject: [PWE3] IPR poll on draft-ietf-pwe3-dynamic-ms-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 17:46:33 -0000 Working Group and authors; The authors of draft-ietf-pwe3-dynamic-ms-pw, the working group chairs and the document shepherd are working to prepare the publication request for this document. To prepare the shepherd write-up we need to do an IPR poll on the document to check whether there are more IPRs that needs to be disclosed before sending the document to the IESG with a request that it is published as an RFC on the standards track. This mail starts that IPR poll. There are 4 IPR disclosures against this document, ID #998, ID #1810, ID #1879 and ID #1885. It is possible to find them at https://datatracker.ietf.org/ipr/ Are you aware of any further IPR that applies to draft-ietf-pwe3-dynamic-ms-pw? If so,this IPR need to be disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed in the authors section of this document please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the PWE3 wg mailing list.* The documents will not advance to the next stage until a response has been received from each author and contributor. Since the authors section includes 20 names, could the authors please both help each other to make sure that we get all the responses. At the same time please check if the mail addresses ned to be updated. If you are on the PWE3 WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa document shepherd -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From agmalis@gmail.com Wed Jun 19 13:51:18 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C7421F93E1 for ; Wed, 19 Jun 2013 13:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.466 X-Spam-Level: X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[AWL=-1.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMIDNP5dsGQc for ; Wed, 19 Jun 2013 13:51:17 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 179E321F896D for ; Wed, 19 Jun 2013 13:51:10 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w59so4735695wes.24 for ; Wed, 19 Jun 2013 13:51:09 -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=7RS23A9DyKiiYmOz0uiKEZWgrV61hyhmqlOtqOOmCh4=; b=mm61vQy97AGFjrenlZKlM/JvKpq+j9km6FOMivRJ3FJuLOHDb8ebOw3xDZ7iXcI6ZR PaVjAhXUKTdKTAsPkwPLBJ2DKyeEbVienwJ3HZ03gJfCJS4qQlgsbkiilWFpKCPvMrDm msAS1H1tyAEhM5/Zph4NhcyGnqNEOjKaIlO6yg/XWD/sPXNaotXruZBdMMxrneto9HeY DqehA+EacQ3+CwPju8tmAEpbhdAFcZuUyFH54Sw2VjJwG0zK08BnpSdMvXvvDtXnLL97 x+yiiVLBZMxHzyA+5yV0qvwPQkm0doipjKxjS8LQbG4mu/lzLHxoTt+NFoWz+4ZBRkcu zrjQ== X-Received: by 10.180.20.46 with SMTP id k14mr3402093wie.14.1371675069072; Wed, 19 Jun 2013 13:51:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.53.73 with HTTP; Wed, 19 Jun 2013 13:50:49 -0700 (PDT) In-Reply-To: <51C1EE5E.7030403@pi.nu> References: <51C1EE5E.7030403@pi.nu> From: "Andrew G. Malis" Date: Wed, 19 Jun 2013 22:50:49 +0200 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=bcaec53f34eb3d504c04df87fd99 Cc: pwe3-ads@tools.ietf.org, "pwe3@ietf.org" , "pwe3-chairs@tools.ietf.org" , draft-ietf-pwe3-dynamic-ms-pw@tools.ietf.org Subject: Re: [PWE3] IPR poll on draft-ietf-pwe3-dynamic-ms-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 20:51:18 -0000 --bcaec53f34eb3d504c04df87fd99 Content-Type: text/plain; charset=ISO-8859-1 Loa, I am not aware of any IPR related to the draft other than those that have already been disclosed. Cheers, Andy On Wed, Jun 19, 2013 at 7:46 PM, Loa Andersson wrote: > Working Group and authors; > > The authors of draft-ietf-pwe3-dynamic-ms-pw, the working group > chairs and the document shepherd are working to prepare the > publication request for this document. > > To prepare the shepherd write-up we need to do an IPR poll on the > document to check whether there are more IPRs that needs to be > disclosed before sending the document to the IESG with a request > that it is published as an RFC on the standards track. > > This mail starts that IPR poll. > > There are 4 IPR disclosures against this document, ID #998, > ID #1810, ID #1879 and ID #1885. It is possible to find them at > https://datatracker.ietf.org/**ipr/ > > Are you aware of any further IPR that applies to > draft-ietf-pwe3-dynamic-ms-pw? > > If so,this IPR need to be disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > If you are listed in the authors section of this document please respond > to this email regardless of whether or not you are aware > of any relevant IPR. *The response needs to be sent to the PWE3 wg mailing > list.* The documents will not advance to the next stage until > a response has been received from each author and contributor. > > Since the authors section includes 20 names, could the authors please > both help each other to make sure that we get all the responses. At the > same time please check if the mail addresses ned to be updated. > > If you are on the PWE3 WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > > Thanks, Loa > document shepherd > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > ______________________________**_________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/**listinfo/pwe3 > --bcaec53f34eb3d504c04df87fd99 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Loa,

I am not aware of any IPR related to the = draft other than those that have already been disclosed.

Cheer= s,
Andy


On Wed, Jun 19, 2013 at 7:46 PM, Loa Andersson <loa@pi.nu> wrote:
Working Group and authors;

The authors of draft-ietf-pwe3-dynamic-ms-pw, the working group
chairs and the document shepherd are working to prepare the
publication request for this document.

To prepare the shepherd write-up we need to do an IPR poll on the
document to check whether there are more IPRs that needs to be
disclosed before sending the document to the IESG with a request
that it is published as an RFC on the standards track.

This mail starts that IPR poll.

There are 4 IPR disclosures against this document, ID #998,
ID #1810, ID #1879 and ID #1885. It is possible to find them at
https://dat= atracker.ietf.org/ipr/

Are you aware of any further IPR that applies to
draft-ietf-pwe3-dynamic-ms-pw?

If so,this IPR need to be disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed in the authors section of this document please respond to= this email regardless of whether or not you are aware
of any relevant IPR. *The response needs to be sent to the PWE3 wg mailing = list.* The documents will not advance to the next stage until
a response has been received from each author and contributor.

Since the authors section includes 20 names, could the authors please
both help each other to make sure that we get all the responses. At the
same time please check if the mail addresses ned to be updated.

If you are on the PWE3 WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.


Thanks, Loa
document shepherd
--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: loa@mail01.huawei.com
Senior MPLS Expert =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Huawei Technologies (consultant) =A0 =A0 phone: +46 739 81 21 64
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pwe3

--bcaec53f34eb3d504c04df87fd99-- From matthew.bocci@alcatel-lucent.com Thu Jun 20 02:51:47 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2C911E80A2 for ; Thu, 20 Jun 2013 02:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUP25IrAcGDO for ; Thu, 20 Jun 2013 02:51:41 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8F85421F9FF4 for ; Thu, 20 Jun 2013 02:51:40 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r5K9pcel022104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Jun 2013 04:51:38 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r5K9pX3u004682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Jun 2013 05:51:37 -0400 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 20 Jun 2013 05:51:28 -0400 Received: from FR711WXCHMBA06.zeu.alcatel-lucent.com ([169.254.2.171]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 20 Jun 2013 11:51:09 +0200 From: "Bocci, Matthew (Matthew)" To: Loa Andersson , "pwe3@ietf.org" , "draft-ietf-pwe3-dynamic-ms-pw@tools.ietf.org" Thread-Topic: IPR poll on draft-ietf-pwe3-dynamic-ms-pw Thread-Index: AQHObRTq7jEbHmZsMU+6Mdp0iwboWZk+THGA Date: Thu, 20 Jun 2013 09:51:09 +0000 Message-ID: In-Reply-To: <51C1EE5E.7030403@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <11649883BAA983499FE69CA9C0913149@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "pwe3-ads@tools.ietf.org" , "pwe3-chairs@tools.ietf.org" Subject: Re: [PWE3] IPR poll on draft-ietf-pwe3-dynamic-ms-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 09:51:47 -0000 Loa, I am not aware of any IPR that has not already been disclosed. Regards Matthew On 19/06/2013 18:46, "Loa Andersson" wrote: >Working Group and authors; > >The authors of draft-ietf-pwe3-dynamic-ms-pw, the working group >chairs and the document shepherd are working to prepare the >publication request for this document. > >To prepare the shepherd write-up we need to do an IPR poll on the >document to check whether there are more IPRs that needs to be >disclosed before sending the document to the IESG with a request >that it is published as an RFC on the standards track. > >This mail starts that IPR poll. > >There are 4 IPR disclosures against this document, ID #998, >ID #1810, ID #1879 and ID #1885. It is possible to find them at >https://datatracker.ietf.org/ipr/ > >Are you aware of any further IPR that applies to >draft-ietf-pwe3-dynamic-ms-pw? > >If so,this IPR need to be disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details). > >If you are listed in the authors section of this document please respond >to this email regardless of whether or not you are aware >of any relevant IPR. *The response needs to be sent to the PWE3 wg >mailing list.* The documents will not advance to the next stage until >a response has been received from each author and contributor. > >Since the authors section includes 20 names, could the authors please >both help each other to make sure that we get all the responses. At the >same time please check if the mail addresses ned to be updated. > >If you are on the PWE3 WG email list but are not listed as an author or >contributor, then please explicitly respond only if you are aware of any >IPR that has not yet been disclosed in conformance with IETF rules. > > >Thanks, Loa >document shepherd >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From andrew.dolganow@alcatel-lucent.com Thu Jun 20 06:09:37 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEC221F9C4F for ; Thu, 20 Jun 2013 06:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v775CxXN2nar for ; Thu, 20 Jun 2013 06:09:31 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 91E2C21F957B for ; Thu, 20 Jun 2013 06:09:31 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r5KD9R7Y024529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Jun 2013 08:09:28 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r5KD8rMt007546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Jun 2013 09:09:27 -0400 Received: from US70UWXCHMBA06.zam.alcatel-lucent.com ([169.254.11.177]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Thu, 20 Jun 2013 09:09:09 -0400 From: "Dolganow, Andrew (Andrew)" To: "Bocci, Matthew (Matthew)" , "Loa Andersson" , "pwe3@ietf.org" , "draft-ietf-pwe3-dynamic-ms-pw@tools.ietf.org" Thread-Topic: [PWE3] IPR poll on draft-ietf-pwe3-dynamic-ms-pw Thread-Index: AQHObZvMtxC1Ag+Pl0eGzCscu8YJRZk+k5iA Date: Thu, 20 Jun 2013 13:09:07 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-ID: <764BE6DD682BD844A6087BC0164BF773@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "pwe3-ads@tools.ietf.org" , "pwe3-chairs@tools.ietf.org" Subject: Re: [PWE3] IPR poll on draft-ietf-pwe3-dynamic-ms-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 13:09:37 -0000 Same here. Andrew On 2013-06-20 5:51 AM, "Bocci, Matthew (Matthew)" wrote: >Loa, > >I am not aware of any IPR that has not already been disclosed. > >Regards > >Matthew > >On 19/06/2013 18:46, "Loa Andersson" wrote: > >>Working Group and authors; >> >>The authors of draft-ietf-pwe3-dynamic-ms-pw, the working group >>chairs and the document shepherd are working to prepare the >>publication request for this document. >> >>To prepare the shepherd write-up we need to do an IPR poll on the >>document to check whether there are more IPRs that needs to be >>disclosed before sending the document to the IESG with a request >>that it is published as an RFC on the standards track. >> >>This mail starts that IPR poll. >> >>There are 4 IPR disclosures against this document, ID #998, >>ID #1810, ID #1879 and ID #1885. It is possible to find them at >>https://datatracker.ietf.org/ipr/ >> >>Are you aware of any further IPR that applies to >>draft-ietf-pwe3-dynamic-ms-pw? >> >>If so,this IPR need to be disclosed in compliance with IETF IPR rules >>(see RFCs 3979, 4879, 3669 and 5378 for more details). >> >>If you are listed in the authors section of this document please respond >>to this email regardless of whether or not you are aware >>of any relevant IPR. *The response needs to be sent to the PWE3 wg >>mailing list.* The documents will not advance to the next stage until >>a response has been received from each author and contributor. >> >>Since the authors section includes 20 names, could the authors please >>both help each other to make sure that we get all the responses. At the >>same time please check if the mail addresses ned to be updated. >> >>If you are on the PWE3 WG email list but are not listed as an author or >>contributor, then please explicitly respond only if you are aware of any >>IPR that has not yet been disclosed in conformance with IETF rules. >> >> >>Thanks, Loa >>document shepherd >>--=20 >> >> >>Loa Andersson email: loa@mail01.huawei.com >>Senior MPLS Expert loa@pi.nu >>Huawei Technologies (consultant) phone: +46 739 81 21 64 > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www.ietf.org/mailman/listinfo/pwe3 From dave.mcdysan@verizon.com Thu Jun 20 06:44:01 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D030C21F9C3B for ; Thu, 20 Jun 2013 06:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3JGqtAcOrhN for ; Thu, 20 Jun 2013 06:43:56 -0700 (PDT) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) by ietfa.amsl.com (Postfix) with ESMTP id 5683A21F9C09 for ; Thu, 20 Jun 2013 06:43:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe02.verizonbusiness.com with ESMTP; 20 Jun 2013 13:43:55 +0000 From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.87,905,1363132800"; d="scan'208";a="493571261" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi03.verizon.com with ESMTP; 20 Jun 2013 13:43:55 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([166.68.59.148]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Thu, 20 Jun 2013 09:43:54 -0400 To: Loa Andersson , "pwe3@ietf.org" , "draft-ietf-pwe3-dynamic-ms-pw@tools.ietf.org" Date: Thu, 20 Jun 2013 09:43:49 -0400 Thread-Topic: [PWE3] IPR poll on draft-ietf-pwe3-dynamic-ms-pw Thread-Index: Ac5tvDRN5dsAiLJMTrG3KtF5pCA2oA== Message-ID: In-Reply-To: <51C1EE5E.7030403@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pwe3-ads@tools.ietf.org" , "pwe3-chairs@tools.ietf.org" Subject: Re: [PWE3] IPR poll on draft-ietf-pwe3-dynamic-ms-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 13:44:01 -0000 I am not aware of any IPR that has not already been disclosed. Regards Dave On 6/19/13 1:46 PM, "Loa Andersson" wrote: >Working Group and authors; > >The authors of draft-ietf-pwe3-dynamic-ms-pw, the working group >chairs and the document shepherd are working to prepare the >publication request for this document. > >To prepare the shepherd write-up we need to do an IPR poll on the >document to check whether there are more IPRs that needs to be >disclosed before sending the document to the IESG with a request >that it is published as an RFC on the standards track. > >This mail starts that IPR poll. > >There are 4 IPR disclosures against this document, ID #998, >ID #1810, ID #1879 and ID #1885. It is possible to find them at >https://datatracker.ietf.org/ipr/ > >Are you aware of any further IPR that applies to >draft-ietf-pwe3-dynamic-ms-pw? > >If so,this IPR need to be disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details). > >If you are listed in the authors section of this document please respond >to this email regardless of whether or not you are aware >of any relevant IPR. *The response needs to be sent to the PWE3 wg >mailing list.* The documents will not advance to the next stage until >a response has been received from each author and contributor. > >Since the authors section includes 20 names, could the authors please >both help each other to make sure that we get all the responses. At the >same time please check if the mail addresses ned to be updated. > >If you are on the PWE3 WG email list but are not listed as an author or >contributor, then please explicitly respond only if you are aware of any >IPR that has not yet been disclosed in conformance with IETF rules. > > >Thanks, Loa >document shepherd >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www.ietf.org/mailman/listinfo/pwe3 From loa@pi.nu Thu Jun 20 09:21:53 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F46C21F9BF0 for ; Thu, 20 Jun 2013 09:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlEf4PnJnwHp for ; Thu, 20 Jun 2013 09:21:48 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id BC65221F9C54 for ; Thu, 20 Jun 2013 09:21:47 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id C224B180121E; Thu, 20 Jun 2013 18:21:46 +0200 (CEST) Message-ID: <51C32C19.6080606@pi.nu> Date: Thu, 20 Jun 2013 18:21:45 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "pwe3@ietf.org" , draft-ietf-pwe3-dynamic-ms-pw@tools.ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: pwe3-ads@tools.ietf.org, "pwe3-chairs@tools.ietf.org" Subject: [PWE3] Shepherd review of draft-ietf-pwe3-dynamic-ms-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:21:53 -0000 Shepherd review of draft-ietf-pwe3-dynamic-ms-pw-16 =================================================== Authors/Editors I've reviewed draft-ietf-pwe3-dynamic-ms-pw-16.txt. In general I think the docment is useful, well-written and about ready to be publish as an RFC on the standards track. I reviewed version -16, but the now active document version -17 contains no other changes than version number and dates. I've also set the word document I've been working on to the authors. My comments are both technical and related to the style on how RFCs should be should be written, i.e. http://www.rfc-editor.org/rfc-style-guide/rfc-style. Being this late in the wg process some of the are also a bit nitty gritty, but if we want smooth ride through AD review, IESG review and the the editing by the RFC Editor we'd better fix them now. Comments per section: Document header =============== Comment - 1: -------- Since this document updates RFC6073 this needs to be spelled out in the header (more details in the commens on the IANA section (section 10)). Titel: ===== Current text: Dynamic Placement of Multi Segment Pseudowires Comment -2: -------- There is a list kept by the RFC Editor of well-known RFC acrononyms are expanded http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt for MS-PW it says Multi-Segment Pseudowire. Section 1: ========== Current text: 1. Major Co-authors Comment-3: ---------- There is nothing to say about the content of this section, but the the structure of this document is not according to the RFC style guide. Is that motivated, or should it just be updated to meet what is said in http://www.rfc-editor.org/rfc-style-guide/rfc-style? Comment-4: ---------- The RFC Style guide says: "a) Introduction The introduction section should always be the first section following the Table of Contents (except in the case of MIBs). While we recommend "Introduction" as the title for this section, authors sometimes choose alternate titles such as "Overview" or "Background"." Section 2: ========== Current text: 2. Acknowledgements Comment -5: ----------- Again there is nothing to say about the content of the paragraph, but again it breaks the structure required by the style guide. "Acknowledgements" is normally placed just before the "Author’s Address” section and after an "Contributors" section. Section 3: ========== Current text: 3. Introduction Comment - 6: ------------ This section should be Section 1. Section 3.1. ============ First sentence of the first paragraph says: "[RFC5023] describes the service provider requirements for extending the reach of pseudowires across multiple PSN domains. This is achieved using a Multi-segment Pseudowire (MS-PW)." Comment- 7: ----------- PSN is a well know abbreviation, but since it in the RFC-Editors list of abbreviations are expanded two different ways and we here is (my opinion) within the scope of reasonable doubts of which is intended it should be expanded. Second sentence of the first paragraph says: "An MS-PW is defined as a set of two or more contiguous PW segments that behave and function as a single point-to-point PW ." Comment - 8: I can’t find any active wg docs or RFCs on P2MP PWs, there is at least one individual contribution on protection of P2MP – and there have been other discussions. The way this is written it seems that MS-PW’s are not for P2MP, if dynamic placement of P2MP PWs are thought to be possible you should add “Dynamic placement of P2MP PWs are for further study and out of scope for this document”. Section 3.3 =========== Bullet 3, 4 and 5 says: " - Forward Direction: ST-PE to TT-PE. - Reverse Direction: TT-PE to ST-PE - Forwarding Direction : Direction of control plane, signaling flow" Comment - 9: ---------- Probably not that important, but since you want to distinguish between ”Forward Direction” and ”Forwarding Direction” you not making it easy by choosing terms that close. I have no better suggestion just now. Comment - 10: ----------- This indicates that there is no CP signal flow in the reverse direction – What about talking about “Request direction” (for what is now” Forwarding Direction” and which is the direction the LDP flow is initiated and “Response direction” which is the direction of the responses go? On the other hand why bother – this is the only place “Forwarding Direction" is used in the document. Section 3.4 =========== Under the figure Current text: Figure 1: PW switching Reference Model Comment - 11: ------------- Proposed new text: Figure 1: MS-PW switching Reference Model First paragraph under the figure, first sentence. Current text: Figure 1 shows the architecture for a simple multi-segment case. Comment - 12: This confuses me a bit, I thought a reference model gave all the info you need. And I think this reference model does; it would be equally true if if there were three PSNs concatenated. Or if the S-PE1 put the PW segments 3 and 4 in one PSN each. A reference model gives you the architectural constructs, it does not describe separate cases. Propose to change the text to “Figure 1 shows the reference model for MS-PWs”. First paragraph under the figure, third sentence. Current text: These PEs reside in different PSNs. Comment/Question - 13: Is the ”different PSNs” really required couldn’t there be reasons for a operator of a single PSN to use the MS-PW technology within that PSN. Text seem to mandate “different PSNs”. First paragraph under the figure, fourth sentence. Current text: "A PSN tunnel extends from T-PE1 to S-PE1 across PSN1, and a second PSN tunnel extends from S-PE1 to T-PE2 across PSN2." Comment - 14: ------------- Propose new text: A PSN tunnel extends from T-PE1 to S-PE1 across PSN1 (supporting PW segment 1 and 2), and a second PSN tunnel extends from S-PE1 to T-PE2 (supporting PW segment 3 and 4) cross PSN2. First paragraph under the figure, last sentence. Current text: "...in case of an MPLS PSN to another MPLS PSN PW switching the operation is a standard MPLS label switch operation." Comment - 15: ------------- I think this should be ”label swap operation” according to 3031. Section 4.1 =========== Current text: "The following OPTIONAL TLVs are also defined:" Comment - 16: ------------- Yes 2119 defines OPTIONAL as part of the 2119 language, but I don’t think it is motivated here, this it just categorizing the TLV as optional, not specifying behaviour. Suggest using lower case - optional. Sectiom 5. ========== First paragraph - first sentence. Current text: "Single segment pseudowires on an MPLS PSN can use attachment circuit identifiers for a PW using FEC 129." Comment - 17: ------------- I'm not clear on what this sentence says. - I can read it as that attachment circuits are optional if FEC129 are used. - I can also read it as attachment circuit are allowed if FEC129 is used - I think there are a couple of other interpretations, can you be clearer? Could we use MAY? If there are cases when the identifiers are not necessary, otherwise just delete ”can”. First paragraph - second sentence: "...there is a requirement for the identifiers for the attachment circuits to be globally unique,... Comment - 18: ------------- Is this clearer ”...it is required that the attachment circuit identifiers (AC ID) are globally unique,...” ??? As far I can see this is the first place where Attachment Circuit Identifiers” are mention and since acronym is used later this is the place to introduce&expand the acronym. Section 5.1 =========== Figure Comment - 19: ------------- Exactly what is the Global ID. Please explain what all the fields in the TLVs are immediately below the figure. Comment - 20 ------------ In the figure and the sentence just after the figure: The LDP protocol introduced (or at least picked up) a praxis that the fields in TLV are explained just after the figures – can you please do so here also. BTW AII is not one of the well known acronyms, please expand! First paragraph on page 7; the parenthesis at the end of the paragraph. Current text: (knows the address in priori by provisioning) Comment - 21: ------------- Not sure this English :). Can we use: (the PE know the address from provisioning). Last paragraph. Comment - 22: Is ”PW domain” defined anywhere; add a reference. .pw stands for professional web in other contexts. I can’t find a definition of “Pseudowire Domain (PW Domain)”. The term is used in 5659 but not defined. Thinking about it might be that what is called PSNs in figure 1 is really PW Domains. Section 5.2 =========== Comment - 23: ------------- I'm not sure what this paragraph really says. I think you intend to say that on each S-PE each PW must be individual accessible in order to configure it. Can this be made clearer? Is AI address = AII address? Section 6.1.1 ============= Comment- 24 ----------- A general comment on AII, TAII and TAI, they are not among the well known acronyms, please expand when first used. Section 6.1.2 ============= Last part of the paragraph. Comment - 25: ------------- Exactly what is ”S-PE1” here – IP address?? Why is this specific to S-PE1, does it not apply to e.g. S-PE2?? Section 6.1.3 ============= Current text: "...Border Gateway Protocol (BGP) [RFC4760]..." Comment - 26: I’m not an BGP expert but RFC4760 is Multoprotocol Extensions for BGP. The BGP specification is RFC 4271. It is correct to reference RFC4670, but the text should be clearer point out what it is. I can imagine a couple of ways to do this, but would prefer: "...MAY choose to use Border Gateway Protocol (BGP) [RFC4721] with the Multiprotocol Extensions as defined in [RFC4760] to propagate PW address information throughout the PSN." Start of the second paragraph. Current text: "Contrary to other l2vpn signaling methods that..." Comment/Question - 27:: Do we consider PWE3 signaling to be an l2vpn method? The figure: Comment - 28: Well, yes and maybe this is sufficient, but it is a t least a bit hard to read, I’d prefer to have all 168 bits spelled out in the figure. Any reason not to? Section 6.2.1 ============= First sentence. This section is not clear about the difference about BW and QoS, it says ”BW signaling”, but claim to be able to meet QoS in general. Paragraph before the figure. Comment - 29: I still don’t think the 2119-language is need to describe the TLV, 2119-language is for requirements to be met. OPTIONAL should be optional. Section 8 ========= Second paragraph, last sentence. Current text: "In this case, the following type MUST be used in place of type 0x01 in the PW switching point TLV:" Comment - 30: ------------- Proposed text "In this case, the following sub-TLV type (0x06) MUST be used in place of type 0x01 in the PW switching point TLV:" Setion 10. ========== First paragraph: Comment - 31: ------------- The first paragraph should be promoted to section "10.1 Corrections" AND Comment - 32: ------------- As usual the devil is in the details. The IANA registry points to RFC6073 for "L2 PW address of the PW Switching Point". RFC6073 says that the length is 12 (bytes), so this is really an update of RFC6073. This needs to be captured in the Abstract, Introduction and document header. And in this document it should also be clear in section 8. (Current) Section 10.1 ====================== First paragraph, first sentence. Current text: This document uses several new LDP TLV types Comment - 33: ------------- There is only one new LDP TLV Type defined by this document. Current test: IANA already maintains a registry of name "TLV TYPE NAME SPACE" defined by RFC5036 Comment -34: ------------ The correct name of the registry is ”Type, Length, and Value (TLV) Type Name Space”. Please update; bothe here and the title of (current) section 10.1. First paragraph, first sentence: Current text: "...IANA already maintains..." Comment - 35: ------------- "Already" is unneccessary. First paragraph, last sentence. Current text: "The following values are suggested for assignment:" Comment - 36: ------------- Well – no! We should say that IANA is requested to assign on permanent basis the value (0x096E) that has been assigned to this document by early allocation. Proposed text: "The IANA is requested to assign on permanent basis the value (0x096E) that has been assigned to this document by early allocation (TEMPORARY - Expires 2008-11-21)." Comment - 37: ------------- Please change the first paragarph of the current section 10.1 to: This document defines one new LDP TLV types. IANA already maintains a registry for LDP TLV types called "Type, Length, and Value (TLV) Type Name Space" within the "Label Distribution Protocol (LDP) Parameters" as defined by RFC5036. The IANA is requested to assign on permanent basis the value (0x096E) that has been assigned to this document by early allocation (TEMPORARY - Expires 2008-11-21).: The picture of the of the IANA allocation should look like this: Value Description Reference Notes/Registration Date ------+----------------+---------------+----------------------- 0x096E Bandwidth TLV This document (current) Section 10.2 ====================== Current text: "...IANA already maintains... Comment - 38: ------------- "already" is unneccessary. Comment - 39: Based on the comments on section 101.1, section 10.2 should be changed to: "This document defines three new LDP status codes. IANA maintains a registry of called "STATUS CODE NAME SPACE" in the "Label Distribution Protocol (LDP) Parameters" as defined by RFC5036. The IANA is requested to assign on permanent basis the values that has been assigned to this document by early allocation (TEMPORARY - Expires 2008-11-21).:" The table describing the IANA allocation should look like this: Range/Value E Description Reference ------------- ----- ---------------------- --------- 0x00000037 0 Bandwidth resources unavailable This doc. 0x00000038 0 Resources Unavailable This doc. 0x00000039 0 AII Unreachable This doc. (Current) Section 10.3 ====================== Comment - 40: Folowing the comments on section 10.1 and 10.2 the last sentence in the first paragraph of section 10.3 should be changed to: "The IANA is requested to assign on permanent basis the value (6) that has been assigned to this document by early allocation (TEMPORARY - Expires 2008-11-21):" Section 13. Author's Address ============================ Comment - 41: ------------- Since this document has been in progress for at least five years can you please check if the contact info needs to be updated. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From prvs=388327daec=hshah@ciena.com Thu Jun 20 10:06:33 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4030721F9C88 for ; Thu, 20 Jun 2013 10:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.665 X-Spam-Level: X-Spam-Status: No, score=-2.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWM-fClqzxWQ for ; Thu, 20 Jun 2013 10:06:27 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id 2219621F9920 for ; Thu, 20 Jun 2013 10:06:26 -0700 (PDT) Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id r5KH0Le5002029; Thu, 20 Jun 2013 13:06:09 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0b-00103a01.pphosted.com with ESMTP id 1d45dt83ur-4 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 20 Jun 2013 13:06:09 -0400 Received: from ONWVEXCHHT04.ciena.com (10.128.6.44) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 20 Jun 2013 13:06:05 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT04.ciena.com ([::1]) with mapi; Thu, 20 Jun 2013 13:05:24 -0400 From: "Shah, Himanshu" To: "Dolganow, Andrew (Andrew)" , "Bocci, Matthew (Matthew)" , "Loa Andersson" , "pwe3@ietf.org" , "draft-ietf-pwe3-dynamic-ms-pw@tools.ietf.org" Date: Thu, 20 Jun 2013 13:05:23 -0400 Thread-Topic: [PWE3] IPR poll on draft-ietf-pwe3-dynamic-ms-pw Thread-Index: AQHObZvMtxC1Ag+Pl0eGzCscu8YJRZk+k5iAgABByFA= Message-ID: <40746B2300A8FC4AB04EE722A593182B5FE45312@ONWVEXCHMB04.ciena.com> References: 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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-19960.000 X-TM-AS-Result: No--16.870400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-06-20_07:2013-06-20, 2013-06-20, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1305240000 definitions=main-1306200138 Cc: "pwe3-ads@tools.ietf.org" , "pwe3-chairs@tools.ietf.org" Subject: Re: [PWE3] IPR poll on draft-ietf-pwe3-dynamic-ms-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:06:33 -0000 Same here too. /himanshu -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Dol= ganow, Andrew (Andrew) Sent: Thursday, June 20, 2013 9:09 AM To: Bocci, Matthew (Matthew); Loa Andersson; pwe3@ietf.org; draft-ietf-pwe3= -dynamic-ms-pw@tools.ietf.org Cc: pwe3-ads@tools.ietf.org; pwe3-chairs@tools.ietf.org Subject: Re: [PWE3] IPR poll on draft-ietf-pwe3-dynamic-ms-pw Same here. Andrew On 2013-06-20 5:51 AM, "Bocci, Matthew (Matthew)" wrote: >Loa, > >I am not aware of any IPR that has not already been disclosed. > >Regards > >Matthew > >On 19/06/2013 18:46, "Loa Andersson" wrote: > >>Working Group and authors; >> >>The authors of draft-ietf-pwe3-dynamic-ms-pw, the working group chairs=20 >>and the document shepherd are working to prepare the publication=20 >>request for this document. >> >>To prepare the shepherd write-up we need to do an IPR poll on the=20 >>document to check whether there are more IPRs that needs to be=20 >>disclosed before sending the document to the IESG with a request that=20 >>it is published as an RFC on the standards track. >> >>This mail starts that IPR poll. >> >>There are 4 IPR disclosures against this document, ID #998, ID #1810,=20 >>ID #1879 and ID #1885. It is possible to find them at=20 >>https://datatracker.ietf.org/ipr/ >> >>Are you aware of any further IPR that applies to=20 >>draft-ietf-pwe3-dynamic-ms-pw? >> >>If so,this IPR need to be disclosed in compliance with IETF IPR rules=20 >>(see RFCs 3979, 4879, 3669 and 5378 for more details). >> >>If you are listed in the authors section of this document please=20 >>respond to this email regardless of whether or not you are aware of=20 >>any relevant IPR. *The response needs to be sent to the PWE3 wg=20 >>mailing list.* The documents will not advance to the next stage until=20 >>a response has been received from each author and contributor. >> >>Since the authors section includes 20 names, could the authors please=20 >>both help each other to make sure that we get all the responses. At=20 >>the same time please check if the mail addresses ned to be updated. >> >>If you are on the PWE3 WG email list but are not listed as an author=20 >>or contributor, then please explicitly respond only if you are aware=20 >>of any IPR that has not yet been disclosed in conformance with IETF rules= . >> >> >>Thanks, Loa >>document shepherd >>-- >> >> >>Loa Andersson email: loa@mail01.huawei.com >>Senior MPLS Expert loa@pi.nu >>Huawei Technologies (consultant) phone: +46 739 81 21 64 > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From wim.henderickx@alcatel-lucent.com Thu Jun 20 10:14:25 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D0221F9E99 for ; Thu, 20 Jun 2013 10:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwZXkn+gtyvW for ; Thu, 20 Jun 2013 10:14:19 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 315D621F9E24 for ; Thu, 20 Jun 2013 10:14:19 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r5KHEGHb026590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Jun 2013 12:14:16 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r5KHEAkX022119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Jun 2013 13:14:15 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 20 Jun 2013 13:14:14 -0400 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.100]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 20 Jun 2013 19:14:09 +0200 From: "Henderickx, Wim (Wim)" To: "Shah, Himanshu" , "Dolganow, Andrew (Andrew)" , "Bocci, Matthew (Matthew)" , "Loa Andersson" , "pwe3@ietf.org" , "draft-ietf-pwe3-dynamic-ms-pw@tools.ietf.org" Thread-Topic: [PWE3] IPR poll on draft-ietf-pwe3-dynamic-ms-pw Thread-Index: AQHObZvkQWXwQpkJ4kaKPSHU3h1mGpk+cfGAgABCBICAACPugA== Date: Thu, 20 Jun 2013 17:14:08 +0000 Message-ID: In-Reply-To: <40746B2300A8FC4AB04EE722A593182B5FE45312@ONWVEXCHMB04.ciena.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-ID: <9765DC0BA9190D47B7E3B07E9766AB73@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "pwe3-ads@tools.ietf.org" , "pwe3-chairs@tools.ietf.org" Subject: Re: [PWE3] IPR poll on draft-ietf-pwe3-dynamic-ms-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:14:25 -0000 Same here, no IPR I am aware of On 20/06/13 19:05, "Shah, Himanshu" wrote: >Same here too. >/himanshu > >-----Original Message----- >From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of >Dolganow, Andrew (Andrew) >Sent: Thursday, June 20, 2013 9:09 AM >To: Bocci, Matthew (Matthew); Loa Andersson; pwe3@ietf.org; >draft-ietf-pwe3-dynamic-ms-pw@tools.ietf.org >Cc: pwe3-ads@tools.ietf.org; pwe3-chairs@tools.ietf.org >Subject: Re: [PWE3] IPR poll on draft-ietf-pwe3-dynamic-ms-pw > >Same here. > >Andrew > >On 2013-06-20 5:51 AM, "Bocci, Matthew (Matthew)" > wrote: > >>Loa, >> >>I am not aware of any IPR that has not already been disclosed. >> >>Regards >> >>Matthew >> >>On 19/06/2013 18:46, "Loa Andersson" wrote: >> >>>Working Group and authors; >>> >>>The authors of draft-ietf-pwe3-dynamic-ms-pw, the working group chairs >>>and the document shepherd are working to prepare the publication >>>request for this document. >>> >>>To prepare the shepherd write-up we need to do an IPR poll on the >>>document to check whether there are more IPRs that needs to be >>>disclosed before sending the document to the IESG with a request that >>>it is published as an RFC on the standards track. >>> >>>This mail starts that IPR poll. >>> >>>There are 4 IPR disclosures against this document, ID #998, ID #1810, >>>ID #1879 and ID #1885. It is possible to find them at >>>https://datatracker.ietf.org/ipr/ >>> >>>Are you aware of any further IPR that applies to >>>draft-ietf-pwe3-dynamic-ms-pw? >>> >>>If so,this IPR need to be disclosed in compliance with IETF IPR rules >>>(see RFCs 3979, 4879, 3669 and 5378 for more details). >>> >>>If you are listed in the authors section of this document please >>>respond to this email regardless of whether or not you are aware of >>>any relevant IPR. *The response needs to be sent to the PWE3 wg >>>mailing list.* The documents will not advance to the next stage until >>>a response has been received from each author and contributor. >>> >>>Since the authors section includes 20 names, could the authors please >>>both help each other to make sure that we get all the responses. At >>>the same time please check if the mail addresses ned to be updated. >>> >>>If you are on the PWE3 WG email list but are not listed as an author >>>or contributor, then please explicitly respond only if you are aware >>>of any IPR that has not yet been disclosed in conformance with IETF >>>rules. >>> >>> >>>Thanks, Loa >>>document shepherd >>>-- >>> >>> >>>Loa Andersson email: loa@mail01.huawei.com >>>Senior MPLS Expert loa@pi.nu >>>Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www.ietf.org/mailman/listinfo/pwe3 > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www.ietf.org/mailman/listinfo/pwe3 >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www.ietf.org/mailman/listinfo/pwe3 From internet-drafts@ietf.org Fri Jun 21 00:24:49 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F37C11E813D; Fri, 21 Jun 2013 00:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGzQxM22vPIj; Fri, 21 Jun 2013 00:24:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A9F11E80D9; Fri, 21 Jun 2013 00:24:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130621072448.28711.94433.idtracker@ietfa.amsl.com> Date: Fri, 21 Jun 2013 00:24:48 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-redundancy-spe-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 07:24:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Working= Group of the IETF. Title : Pseudowire Redundancy on S-PE Author(s) : Jie Dong Haibo Wang Filename : draft-ietf-pwe3-redundancy-spe-01.txt Pages : 8 Date : 2013-06-21 Abstract: This document describes Multi-Segment Pseudowire (MS-PW) protection scenarios in which the pseudowire redundancy is provided on the Switching-PE (S-PE). Operations of the S-PEs which provide PW redundancy are specified in this document. Signaling of the preferential forwarding status as defined in [RFC6870] is reused. This document does not require any change to the T-PEs of MS-PW. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-spe There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-spe-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pwe3-redundancy-spe-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nabil.n.bitar@verizon.com Sun Jun 23 16:08:10 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F201021F9E89 for ; Sun, 23 Jun 2013 16:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SamhKNCyAJ1s for ; Sun, 23 Jun 2013 16:07:56 -0700 (PDT) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) by ietfa.amsl.com (Postfix) with ESMTP id D9B7D21F9D86 for ; Sun, 23 Jun 2013 16:07:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by omzsmtpe02.verizonbusiness.com with ESMTP; 23 Jun 2013 23:07:45 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.87,924,1363132800"; d="scan'208";a="503065618" Received: from fldp1lumxc7hb05.verizon.com (HELO FLDP1LUMXC7HB05.us.one.verizon.com) ([166.68.75.87]) by fldsmtpi01.verizon.com with ESMTP; 23 Jun 2013 23:07:44 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([166.68.45.45]) by FLDP1LUMXC7HB05.us.one.verizon.com ([166.68.75.87]) with mapi; Sun, 23 Jun 2013 19:07:44 -0400 To: Loa Andersson , "pwe3@ietf.org" , "draft-ietf-pwe3-dynamic-ms-pw@tools.ietf.org" Date: Sun, 23 Jun 2013 19:07:31 -0400 Thread-Topic: [PWE3] IPR poll on draft-ietf-pwe3-dynamic-ms-pw Thread-Index: Ac5wZndRa4rht3O2TWqlAVIA4DaozA== Message-ID: In-Reply-To: <51C1EE5E.7030403@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pwe3-ads@tools.ietf.org" , "pwe3-chairs@tools.ietf.org" Subject: Re: [PWE3] IPR poll on draft-ietf-pwe3-dynamic-ms-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 23:08:10 -0000 Loa, I am not aware of any IPR related to this draft that has not already been disclosed. Thanks, Nabil On 6/19/13 1:46 PM, "Loa Andersson" wrote: >Working Group and authors; > >The authors of draft-ietf-pwe3-dynamic-ms-pw, the working group >chairs and the document shepherd are working to prepare the >publication request for this document. > >To prepare the shepherd write-up we need to do an IPR poll on the >document to check whether there are more IPRs that needs to be >disclosed before sending the document to the IESG with a request >that it is published as an RFC on the standards track. > >This mail starts that IPR poll. > >There are 4 IPR disclosures against this document, ID #998, >ID #1810, ID #1879 and ID #1885. It is possible to find them at >https://datatracker.ietf.org/ipr/ > >Are you aware of any further IPR that applies to >draft-ietf-pwe3-dynamic-ms-pw? > >If so,this IPR need to be disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details). > >If you are listed in the authors section of this document please respond >to this email regardless of whether or not you are aware >of any relevant IPR. *The response needs to be sent to the PWE3 wg >mailing list.* The documents will not advance to the next stage until >a response has been received from each author and contributor. > >Since the authors section includes 20 names, could the authors please >both help each other to make sure that we get all the responses. At the >same time please check if the mail addresses ned to be updated. > >If you are on the PWE3 WG email list but are not listed as an author or >contributor, then please explicitly respond only if you are aware of any >IPR that has not yet been disclosed in conformance with IETF rules. > > >Thanks, Loa >document shepherd >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www.ietf.org/mailman/listinfo/pwe3 From jie.dong@huawei.com Sun Jun 23 22:13:33 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEDA21F9FBB for ; Sun, 23 Jun 2013 22:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LDP9ZaicDDK for ; Sun, 23 Jun 2013 22:13:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7752821F9F8F for ; Sun, 23 Jun 2013 22:13:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASU01360; Mon, 24 Jun 2013 05:13:26 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 24 Jun 2013 06:12:27 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 24 Jun 2013 06:13:01 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Mon, 24 Jun 2013 13:12:57 +0800 From: Jie Dong To: "pwe3@ietf.org" Thread-Topic: [PWE3] I-D Action: draft-ietf-pwe3-redundancy-spe-01.txt Thread-Index: AQHOblCSHse+WFT/n0icYwRyHjNTGJlEU6Qg Date: Mon, 24 Jun 2013 05:12:56 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273344D3CF@nkgeml512-mbx.china.huawei.com> References: <20130621072448.28711.94433.idtracker@ietfa.amsl.com> In-Reply-To: <20130621072448.28711.94433.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.192.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [PWE3] I-D Action: draft-ietf-pwe3-redundancy-spe-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 05:13:33 -0000 Dear all,=20 A new version of draft-ietf-pwe3-redundancy-spe has been submitted to PWE3 = WG. In addition to the editorial changes, in the operation section, it is menti= oned that the SP-PE TLVs may be updated when the S-PE performs switchover o= f PW-Segments. Please take a look and any further comments are appreciated. Best regards, Jie & Haibo > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Friday, June 21, 2013 10:25 AM > To: i-d-announce@ietf.org > Cc: pwe3@ietf.org > Subject: [PWE3] I-D Action: draft-ietf-pwe3-redundancy-spe-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Pseudowire Emulation Edge to Edge Worki= ng > Group of the IETF. >=20 > Title : Pseudowire Redundancy on S-PE > Author(s) : Jie Dong > Haibo Wang > Filename : draft-ietf-pwe3-redundancy-spe-01.txt > Pages : 8 > Date : 2013-06-21 >=20 > Abstract: > This document describes Multi-Segment Pseudowire (MS-PW) protection > scenarios in which the pseudowire redundancy is provided on the > Switching-PE (S-PE). Operations of the S-PEs which provide PW > redundancy are specified in this document. Signaling of the > preferential forwarding status as defined in [RFC6870] is reused. > This document does not require any change to the T-PEs of MS-PW. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-spe >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-spe-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pwe3-redundancy-spe-01 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From internet-drafts@ietf.org Thu Jun 27 13:53:22 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2036E21F9D4D; Thu, 27 Jun 2013 13:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.295 X-Spam-Level: X-Spam-Status: No, score=-102.295 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHgJ-dfsyTcG; Thu, 27 Jun 2013 13:53:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B1121F9A90; Thu, 27 Jun 2013 13:53:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130627205318.20312.61395.idtracker@ietfa.amsl.com> Date: Thu, 27 Jun 2013 13:53:18 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-vccv-impl-survey-results-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 20:53:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Working= Group of the IETF. Title : The Pseudowire (PW) & Virtual Circuit Connectivity Verif= ication (VCCV) Implementation Survey Results Author(s) : Andrew G. Malis Filename : draft-ietf-pwe3-vccv-impl-survey-results-01.txt Pages : 37 Date : 2013-06-27 Abstract: Most pseudowire Emulation Edge-to-Edge (PWE3) encapsulations mandate the use of the Control Word (CW) to carry information essential to the emulation, to inhibit ECMP behavior, and to discriminate OAM from PW packets. However, some encapsulations treat the Control Word as optional. As a result, implementations of the CW, for encapsulations for which it is optional, vary by equipment manufacturer, equipment model and service provider network. Similarly, Virtual Circuit Connectivity Verification (VCCV) supports three Control Channel (CC) types and multiple Connectivity Verification (CV) Types. This flexibility has led to reports of interoperability issues within deployed networks and associated drafts to attempt to remedy the situation. This survey of the PW/VCCV user community was conducted to determine implementation trends. The survey and results is presented herein. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-vccv-impl-survey-results There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pwe3-vccv-impl-survey-results-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pwe3-vccv-impl-survey-results= -01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From loa@pi.nu Fri Jun 28 03:26:00 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66F221F9C33; Fri, 28 Jun 2013 03:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 241VtN9ZKmQ8; Fri, 28 Jun 2013 03:25:47 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id E64BF21F9C0A; Fri, 28 Jun 2013 03:25:37 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id C46351800272; Fri, 28 Jun 2013 12:25:36 +0200 (CEST) Message-ID: <51CD64A1.4010408@pi.nu> Date: Fri, 28 Jun 2013 12:25:37 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mpls@ietf.org" , "pwe3@ietf.org" References: <51B9BE97.2090103@pi.nu> In-Reply-To: <51B9BE97.2090103@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , "pwe3-chairs@tools.ietf.org" Subject: Re: [PWE3] Working Group Last Call on draft-ietf-mpls-retire-ach-tlv X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 10:26:00 -0000 Folks (chair hat off), I was just about to close the wg last call, but remembered that I've one nitty type of comment. The draft is about retiring the possibility to have TLVs in the GACh header, that is fine and I support that. However TLVs might be carried in the GACh messages, the disticnction is not entirely clear in the draft, can the authors please make this clear. /Loa On 2013-06-13 14:44, Loa Andersson wrote: > Working Groups, > > PWE3 working group, > > This is to start a two week working group last call on an MPLS > document, but since it will be of interest to the PWE3 group also > the chairs agreed to copy it to the PWE3 mailing list as well. > Please keep the discussion on the mpls working group mailing list. > > MPLS working group, > > this is to start a two week Working Group last call on > draft-ietf-mpls-retire-ach-tlv-01. > > Please send your comments to the mpls working group > mailing list (mpls@ietf.org). > > Please send both technical comments, and if you are happy > with the document as is also indications of support. > > There are no IPR claims against this draft. > > The co-authors have earlier stated that they are not aware > of any IPRs applicable to this draft. > > If anyone else in the working group are aware of IPRs claims against > this draft, the time to disclose that is now. > > This working group last call will end on June 27, 2013. > > /Loa > for the wg co-chairs > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Fri Jun 28 03:29:33 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7604321F9CAB; Fri, 28 Jun 2013 03:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jZJJ4ulJ4u4; Fri, 28 Jun 2013 03:29:21 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE2F21F9C4D; Fri, 28 Jun 2013 03:29:21 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2EE491800272; Fri, 28 Jun 2013 12:29:20 +0200 (CEST) Message-ID: <51CD6580.3080901@pi.nu> Date: Fri, 28 Jun 2013 12:29:20 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mpls@ietf.org" , "pwe3@ietf.org" References: <51B9BE97.2090103@pi.nu> In-Reply-To: <51B9BE97.2090103@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , "pwe3-chairs@tools.ietf.org" Subject: [PWE3] Closed - Re: Working Group Last Call on draft-ietf-mpls-retire-ach-tlv X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 10:29:33 -0000 Working Group, this working group last call, very few comments, can the authors please make the updates needed; and tell the the wg and wg chairs that the draft is ready to be sent to the IESG with a request for publication. Testing the water: We can't see that an implementation poll on this draft is necessary. Anyone that think we need to do that? /Loa for the wg chairs On 2013-06-13 14:44, Loa Andersson wrote: > Working Groups, > > PWE3 working group, > > This is to start a two week working group last call on an MPLS > document, but since it will be of interest to the PWE3 group also > the chairs agreed to copy it to the PWE3 mailing list as well. > Please keep the discussion on the mpls working group mailing list. > > MPLS working group, > > this is to start a two week Working Group last call on > draft-ietf-mpls-retire-ach-tlv-01. > > Please send your comments to the mpls working group > mailing list (mpls@ietf.org). > > Please send both technical comments, and if you are happy > with the document as is also indications of support. > > There are no IPR claims against this draft. > > The co-authors have earlier stated that they are not aware > of any IPRs applicable to this draft. > > If anyone else in the working group are aware of IPRs claims against > this draft, the time to disclose that is now. > > This working group last call will end on June 27, 2013. > > /Loa > for the wg co-chairs > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From adrian@olddog.co.uk Fri Jun 28 05:25:39 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6138921F9546; Fri, 28 Jun 2013 05:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pfy-U4e8o1Mf; Fri, 28 Jun 2013 05:25:28 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 135A421F847A; Fri, 28 Jun 2013 05:25:27 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5SCPQFv008067; Fri, 28 Jun 2013 13:25:26 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5SCPPYA008018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Jun 2013 13:25:26 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , , References: <51B9BE97.2090103@pi.nu> <51CD64A1.4010408@pi.nu> In-Reply-To: <51CD64A1.4010408@pi.nu> Date: Fri, 28 Jun 2013 13:25:21 +0100 Message-ID: <001401ce73fa$8f45d620$add18260$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHW5VCOalYSNbB9yB8pqvNYs+N7SwKMkCermSXElDA= Content-Language: en-gb Cc: mpls-chairs@tools.ietf.org, pwe3-chairs@tools.ietf.org Subject: Re: [PWE3] Working Group Last Call on draft-ietf-mpls-retire-ach-tlv X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 12:25:39 -0000 > However TLVs might be carried in the GACh messages, the disticnction > is not entirely clear in the draft, can the authors please make > this clear. Happily. The current version defines "ACH TLV" as "TLV constructs that can be carried in messages on the G-ACh by placing them in the ACH between the fixed header fields and the G-ACh message." Thus, retiring ACH TLVs, obviously means only removing this concept and not any other TLV-related concept. I would propose to change the last sentence of Section 1 as follows: OLD This document states that ACH TLVs as specified in RFC 5586 are not useful and might be harmful. It updates RFC 5586 by deprecating the ACH TLV and updating the associated IANA registries as described in Section 4 of this document. NEW This document states that ACH TLVs as specified in RFC 5586 are not useful and might be harmful. It updates RFC 5586 by deprecating the ACH TLV and updating the associated IANA registries as described in Section 4 of this document. This document makes no comment about the use of TLVs in other places. In particular, proposals to use TLVs within ACH messages, or as an appendage to ACH messages are not in scope of this document. END Does that work? Thanks, Adrian From adrian@olddog.co.uk Fri Jun 28 05:32:19 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7754021F9634; Fri, 28 Jun 2013 05:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpiS1oN8GIXW; Fri, 28 Jun 2013 05:32:08 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id E45E821F9DD4; Fri, 28 Jun 2013 05:32:03 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5SCW1vT018357; Fri, 28 Jun 2013 13:32:02 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5SCVwfM018292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Jun 2013 13:31:59 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , , References: <51B9BE97.2090103@pi.nu> <51CD6580.3080901@pi.nu> In-Reply-To: <51CD6580.3080901@pi.nu> Date: Fri, 28 Jun 2013 13:31:54 +0100 Message-ID: <001801ce73fb$7ad1d300$70757900$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHW5VCOalYSNbB9yB8pqvNYs+N7SwMSMUR2mSGZoKA= Content-Language: en-gb Cc: mpls-chairs@tools.ietf.org, pwe3-chairs@tools.ietf.org Subject: Re: [PWE3] Closed - Re: Working Group Last Call on draft-ietf-mpls-retire-ach-tlv X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 12:32:19 -0000 > Working Group, > > this working group last call, very few comments, can the authors > please make the updates needed; and tell the the wg and wg chairs > that the draft is ready to be sent to the IESG with a request for > publication. Working on this. I see comments from Loa (separate response sent). I believe all other comments came in before WG last call (e.g. review team comments) and were addressed. If anyone disagrees, please shout. > Testing the water: > > We can't see that an implementation poll on this draft is necessary. > Anyone that think we need to do that? That's amusing. I can confirm I have 237 implementations of not using the ACH TLV :-) They do not all interoperate! In particular, I am having trouble to get my refrigerator to television with my cat (people who know me well will understand why this is). Thanks, Adrian From amalis@gmail.com Fri Jun 28 05:36:44 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8D921F9D5B; Fri, 28 Jun 2013 05:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaWnEWNaYqdl; Fri, 28 Jun 2013 05:36:38 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED3221F9F08; Fri, 28 Jun 2013 05:34:48 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id xk17so1896017obc.10 for ; Fri, 28 Jun 2013 05:34: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=vwedOUcpIJdS1x5KkWVyaADfzQIweQuLgWLsrI9EV+E=; b=CkBwN6kPRItgJ9mBO+0XiCYwDsgBzvqCKSb67gMfouTBGiXeRgB/d866wYWC3R9rTf dRysr+l3JBsBwJ0xnkWc20e33NJeQwJUDQN3ug4U+KrroCcqnp9KH4Weo6UUaSGQ3Vaz IQzfVuGrYwRrugHz9crQ5INOBPzxHI1XBDLLDDKrj8anWJK3MZ10qbagisVRZwjYwh56 iw96DwVUHNIY//ma9rJlRzGRyWWCbDZM1eHmjor6peKkJJeQBYqBBTzhiJ6Ofd/LqDPI k3l3aJbTXGNwA+JtRxdVAebi8YJ9LFKpgghO8LKHUqCpMZbrdFJUspnYacOgs3HS3XjW hGlA== X-Received: by 10.182.27.102 with SMTP id s6mr6163772obg.42.1372422887795; Fri, 28 Jun 2013 05:34:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.144.65 with HTTP; Fri, 28 Jun 2013 05:34:27 -0700 (PDT) In-Reply-To: <001401ce73fa$8f45d620$add18260$@olddog.co.uk> References: <51B9BE97.2090103@pi.nu> <51CD64A1.4010408@pi.nu> <001401ce73fa$8f45d620$add18260$@olddog.co.uk> From: "Andrew G. Malis" Date: Fri, 28 Jun 2013 08:34:27 -0400 Message-ID: To: Adrian Farrel Content-Type: multipart/alternative; boundary=089e01184c8cb5773304e0361afe Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "pwe3@ietf.org" , "pwe3-chairs@tools.ietf.org" Subject: Re: [PWE3] Working Group Last Call on draft-ietf-mpls-retire-ach-tlv X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 12:36:44 -0000 --089e01184c8cb5773304e0361afe Content-Type: text/plain; charset=ISO-8859-1 Adrian, Looks good to me. Just from an English language aspect (here I am lecturing a Brit about English :-) I suggest either removing the final comma from your text or alternatively adding a comma after "ACH messages". Cheers, Andy On Fri, Jun 28, 2013 at 8:25 AM, Adrian Farrel wrote: > > However TLVs might be carried in the GACh messages, the disticnction > > is not entirely clear in the draft, can the authors please make > > this clear. > > Happily. > > The current version defines "ACH TLV" as "TLV constructs that can be > carried in > messages on the G-ACh by placing them in the ACH between the fixed header > fields > and the G-ACh message." > > Thus, retiring ACH TLVs, obviously means only removing this concept and > not any > other TLV-related concept. > > I would propose to change the last sentence of Section 1 as follows: > > OLD > This document states that ACH TLVs as specified in RFC 5586 are not > useful and might be harmful. It updates RFC 5586 by deprecating the > ACH TLV and updating the associated IANA registries as described in > Section 4 of this document. > NEW > This document states that ACH TLVs as specified in RFC 5586 are not > useful and might be harmful. It updates RFC 5586 by deprecating the > ACH TLV and updating the associated IANA registries as described in > Section 4 of this document. This document makes no comment about the > use of TLVs in other places. In particular, proposals to use TLVs > within ACH messages, or as an appendage to ACH messages are not in > scope of this document. > END > > Does that work? > > Thanks, > Adrian > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --089e01184c8cb5773304e0361afe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Adrian,

Looks good to me.= Just from an English language aspect (here I am lecturing a Brit about Eng= lish :-) I suggest either removing the final comma from your text or altern= atively adding a comma after
"ACH messages".

Cheers,
Andy


On Fri, Jun = 28, 2013 at 8:25 AM, Adrian Farrel <adrian@olddog.co.uk> w= rote:
> However TLVs might be= carried in the GACh messages, the disticnction
> is not entirely clear in the draft, can the authors please make
> this clear.

Happily.

The current version defines "ACH TLV" as "TLV constructs tha= t can be carried in
messages on the G-ACh by placing them in the ACH between the fixed header f= ields
and the G-ACh message."

Thus, retiring ACH TLVs, obviously means only removing this concept and not= any
other TLV-related concept.

I would propose to change the last sentence of Section 1 as follows:

OLD
=A0 =A0This document states that ACH TLVs as specified in RFC 5586 are not<= br> =A0 =A0useful and might be harmful. =A0It updates RFC 5586 by deprecating t= he
=A0 =A0ACH TLV and updating the associated IANA registries as described in<= br> =A0 =A0Section 4 of this document.
NEW
=A0 =A0This document states that ACH TLVs as specified in RFC 5586 are not<= br> =A0 =A0useful and might be harmful. =A0It updates RFC 5586 by deprecating t= he
=A0 =A0ACH TLV and updating the associated IANA registries as described in<= br> =A0 =A0Section 4 of this document. =A0This document makes no comment about = the
=A0 =A0use of TLVs in other places. =A0In particular, proposals to use TLVs=
=A0 =A0within ACH messages, or as an appendage to ACH messages are not in =A0 =A0scope of this document.
END

Does that work?

Thanks,
Adrian

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pwe3

--089e01184c8cb5773304e0361afe-- From loa@pi.nu Fri Jun 28 05:59:13 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798AB21F938E; Fri, 28 Jun 2013 05:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9g8ocC4hIwY; Fri, 28 Jun 2013 05:59:02 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id DF90F21F93B9; Fri, 28 Jun 2013 05:51:02 -0700 (PDT) Received: from [95.209.167.247] (95.209.167.247.mobile.tre.se [95.209.167.247]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 1F8681800272; Fri, 28 Jun 2013 14:51:02 +0200 (CEST) Message-ID: <51CD86B5.3060606@pi.nu> Date: Fri, 28 Jun 2013 14:51:01 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <51B9BE97.2090103@pi.nu> <51CD64A1.4010408@pi.nu> <001401ce73fa$8f45d620$add18260$@olddog.co.uk> In-Reply-To: <001401ce73fa$8f45d620$add18260$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, pwe3@ietf.org, pwe3-chairs@tools.ietf.org Subject: Re: [PWE3] Working Group Last Call on draft-ietf-mpls-retire-ach-tlv X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 12:59:13 -0000 Adrian, Yes this works for me. /Loa On 2013-06-28 14:25, Adrian Farrel wrote: >> However TLVs might be carried in the GACh messages, the disticnction >> is not entirely clear in the draft, can the authors please make >> this clear. > > Happily. > > The current version defines "ACH TLV" as "TLV constructs that can be carried in > messages on the G-ACh by placing them in the ACH between the fixed header fields > and the G-ACh message." > > Thus, retiring ACH TLVs, obviously means only removing this concept and not any > other TLV-related concept. > > I would propose to change the last sentence of Section 1 as follows: > > OLD > This document states that ACH TLVs as specified in RFC 5586 are not > useful and might be harmful. It updates RFC 5586 by deprecating the > ACH TLV and updating the associated IANA registries as described in > Section 4 of this document. > NEW > This document states that ACH TLVs as specified in RFC 5586 are not > useful and might be harmful. It updates RFC 5586 by deprecating the > ACH TLV and updating the associated IANA registries as described in > Section 4 of this document. This document makes no comment about the > use of TLVs in other places. In particular, proposals to use TLVs > within ACH messages, or as an appendage to ACH messages are not in > scope of this document. > END > > Does that work? > > Thanks, > Adrian > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Fri Jun 28 07:13:52 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD08F21F9B88 for ; Fri, 28 Jun 2013 07:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQC2Joh1fJ3f for ; Fri, 28 Jun 2013 07:13:46 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id A319A21F9B7C for ; Fri, 28 Jun 2013 07:13:46 -0700 (PDT) Received: from [95.209.167.247] (95.209.167.247.mobile.tre.se [95.209.167.247]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 508571801110; Fri, 28 Jun 2013 16:13:39 +0200 (CEST) Message-ID: <51CD9A13.9030005@pi.nu> Date: Fri, 28 Jun 2013 16:13:39 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "pwe3@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3-ads@tools.ietf.org, "pwe3-chairs@tools.ietf.org" Subject: [PWE3] Implementation poll for draft-ietf-pwe3-dynamic-ms-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 14:13:52 -0000 Working Group, We are in the process of preparing the publication request for draft-ietf-pwe3-dynamic-ms-pw. One part of this is writing the what is called the "shepherd write-up". One question asked by the IESG for documents intended for the standards track is if there are any existing or intended implementations of the draft. If you have an implementation or intend to implement, please send that information at least to the document shepherd. Since questions about implementations sometimes are a bit sensitive it is allowed to send unidirectional information to the shepherd; however we prefer that you send the mail to the pwe3 wg mailing list (pwe3@ietf.org). /Loa (as document shepherd) PS We have an open IPR poll on this document; and less than half of the co-authors/contributors have responded. Any help to make sure we have the responses delivered in reasonable time is appreciated. -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From wim.henderickx@alcatel-lucent.com Sat Jun 29 00:27:21 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4C221F9D28 for ; Sat, 29 Jun 2013 00:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+Hfm3SZ2JEx for ; Sat, 29 Jun 2013 00:27:15 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 91F1821F9D1D for ; Sat, 29 Jun 2013 00:27:15 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r5T7RAjk024624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 29 Jun 2013 02:27:13 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r5T7R7dD009317 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 29 Jun 2013 09:27:07 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.63]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Sat, 29 Jun 2013 09:27:07 +0200 From: "Henderickx, Wim (Wim)" To: Loa Andersson , "pwe3@ietf.org" Thread-Topic: [PWE3] Implementation poll for draft-ietf-pwe3-dynamic-ms-pw Thread-Index: AQHOdAnD3rKc4DPDrkag4C6vBMPYmJlMTAaA Date: Sat, 29 Jun 2013 07:27:06 +0000 Message-ID: In-Reply-To: <51CD9A13.9030005@pi.nu> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-ID: <49FD5ABCC1D18D459987D9E4E0045DE2@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "pwe3-ads@tools.ietf.org" , "pwe3-chairs@tools.ietf.org" Subject: Re: [PWE3] Implementation poll for draft-ietf-pwe3-dynamic-ms-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 07:27:21 -0000 We have an implementation on this. On 28/06/13 16:13, "Loa Andersson" wrote: >Working Group, > >We are in the process of preparing the publication request for >draft-ietf-pwe3-dynamic-ms-pw. One part of this is writing the >what is called the "shepherd write-up". One question asked by >the IESG for documents intended for the standards track is if there >are any existing or intended implementations of the draft. > >If you have an implementation or intend to implement, please >send that information at least to the document shepherd. > >Since questions about implementations sometimes are a bit >sensitive it is allowed to send unidirectional information to >the shepherd; however we prefer that you send the mail to the >pwe3 wg mailing list (pwe3@ietf.org). > >/Loa >(as document shepherd) > >PS > >We have an open IPR poll on this document; and less than half of >the co-authors/contributors have responded. Any help to make sure >we have the responses delivered in reasonable time is appreciated. >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www.ietf.org/mailman/listinfo/pwe3 From david.sinicrope@ericsson.com Sat Jun 29 08:04:08 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4002311E8151 for ; Sat, 29 Jun 2013 08:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzpZjTbEY7id for ; Sat, 29 Jun 2013 08:04:02 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id BAD9611E8152 for ; Sat, 29 Jun 2013 08:04:02 -0700 (PDT) X-AuditID: c618062d-b7fc36d0000032ea-3a-51cef7616687 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C9.E3.13034.167FEC15; Sat, 29 Jun 2013 17:04:02 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Sat, 29 Jun 2013 11:04:02 -0400 From: David Sinicrope To: IETF.PWE3 Thread-Topic: PWE3 IETF 87 Slot Requests - Berlin Thread-Index: AQHOdNnjrcBlgsO99E2H6EdkAurdrA== Date: Sat, 29 Jun 2013 15:04:01 +0000 Message-ID: <871EB8879748FA458598F046190628931C0622D3@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_871EB8879748FA458598F046190628931C0622D3eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyuXSPn27S93OBBq9ahS36Pm1hcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxu0bCQXnxSsOPe9na2CcIdLFyMkhIWAi0X/gEiuELSZx4d56 ti5GLg4hgaOMEtvebGMDSQgJLGeUaJ9fCmKzATWs27iHBcQWEZCVeH39HliNsICOxLe7P5gg 4oYSc89uBBrKAWTrSSxqSwcJswioSmxuXsACEuYV8JW480UXJMwItPb7qTVgncwC4hK3nsxn gjhHQGLJnvPMELaoxMvH/8DOFAWauL59N1SNssT3OY9YIHrzJb5uvwF2Da+AoMTJmU9YJjAK z0IydhaSsllIyiDiBhLvz81nhrC1JZYtfA1l60ts/HKWEcK2llj1p5UVWc0CRo5VjBylxall uelGBpsYgTFyTIJNdwfjnpeWhxilOViUxHlX6Z0JFBJITyxJzU5NLUgtii8qzUktPsTIxMEp 1cDo8/bY1KwvO5ke75OJixV971bK3rBRefmNTL7jvyYnKUWFT3WyEvptcH/fkhmpzO4n3htN /eV/SPO/Rf0V2zf2O02k+eIkBAXTP7lLPrT/urv15+ygv/GWmcwHJjeKTzkUcOnkGr/kghXP l+sv6jtntnGS7Sbp7rl31C+9fMvFlbQ6ezUnW6KXEktxRqKhFnNRcSIAlBCqfl8CAAA= Subject: [PWE3] PWE3 IETF 87 Slot Requests - Berlin X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 15:04:08 -0000 --_000_871EB8879748FA458598F046190628931C0622D3eusaamb103erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi All, It's that time again. The draft agenda for Berlin is out. https://datatracker.ietf.org/meeting/agenda/ As of today we will be meeting on Thursday August 1 from 17:00 =96 18:30. = (90 minutes) If you need a presentation slot for the IETF 87 PWE3 session, please reply = to this email (subject intact) completing the form below: - topic (e.g., MPLS and Ethernet OAM Interworking): - draft URL (e.g., http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-eth= -oam-iwk/): - brief statement of objectives and issues that need to be discussed and re= solved via the presentation (e.g., need to address security issues and get = direction from the WG): - requested duration (norm is 10 min): - speaker name (e.g., Given-name FAMILY-NAME): Thanks! Dave --_000_871EB8879748FA458598F046190628931C0622D3eusaamb103erics_ Content-Type: text/html; charset="Windows-1252" Content-ID: <02DFF760C430FC4B90CA2FD7F26ACA1E@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi All,

It's that time again.  The draft agenda for Berlin is out.

As of today we will be meeting on Thursday August 1 from 17:00 =96 18:= 30.  (90 minutes)


If you need a presentation slot for the IETF 87 PWE3 session, pleas= e reply to this email (subject intact) completing the form below:


- topic (e.g., MPLS and Ethernet OAM Interworking):


- brief statement of objectives and issues that need to be discussed a= nd resolved via the presentation (e.g., need to address security issues and= get direction from the WG):  

- requested duration (norm is 10 min):  

- speaker name (e.g., Given-name FAMILY-NAME):  



Thanks!
Dave
--_000_871EB8879748FA458598F046190628931C0622D3eusaamb103erics_--