From cpignata@cisco.com Sat Oct 1 07:03:13 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D03B21F903A for ; Sat, 1 Oct 2011 07:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AW7AP-YNk4ej for ; Sat, 1 Oct 2011 07:03:12 -0700 (PDT) Received: from av-tac-sj.cisco.com (firebird.cisco.com [171.68.227.73]) by ietfa.amsl.com (Postfix) with ESMTP id D61E221F8FC3 for ; Sat, 1 Oct 2011 07:03:12 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p91E68Zv018955 for ; Sat, 1 Oct 2011 07:06:08 -0700 (PDT) Received: from [10.82.242.252] (rtp-vpn2-764.cisco.com [10.82.242.252]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p91E61kD001038 for ; Sat, 1 Oct 2011 10:06:01 -0400 (EDT) Message-ID: <4E871E49.5090209@cisco.com> Date: Sat, 01 Oct 2011 10:06:01 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: mpls@ietf.org References: <067E6CE33034954AAC05C9EC85E2577C05F95305@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C05F95305@XMB-RCD-111.cisco.com> X-Enigmail-Version: 1.3.2 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2011 14:03:13 -0000 Hi Rajiv, Please see inline my 2¢, disclaimer I'm co-author. On 9/22/2011 4:52 PM, Rajiv Asati (rajiva) wrote: > While this document passed the WGLC without any comments, we wanted to > bring up an issue to seek your feedback. Thanks Rajiv for polling the WG! This is the last pending comment on this doc. > > The issue is that the current LDP spec rfc5036 allows an LDP peer to > advertise IPv6 bindings to an LDP IPv4 peer, even though the peer may > not have any IPv6 enabled (or IPv6 LDP), and vice versa*. See figure 3 > in section 1.1.1 of ldp-ipv6 document. > > While mpls-ldp-ipv6 section 7** addresses this issue (by checking for v6 > hello adj, in line with existing 'targeted adj check for PW binding > advertisement'), we want to pose the following questions: > > (1) is this a reasonable issue to be fixed? Yes. The problem description is that of what bindings to advertise, under which conditions (or negotiations), for different FECs. > (2) is ldp-ipv6 document the right place to fix it? No. The problem space is larger than the scope of this I-D, as per its Abstract ("LDP behavior when IPv6 network is used".) I fear that crafting a solution here would be rushed and would not do justice to a complete analysis of the problem space. See below. > (3) is the solution highlighted in section 7 a reasonable solution, if > you answered yes to both 1 and 2? I am not sure... I sense that tying label/FEC mapping exchanges to the transport Hello Adjacency is an approach that could break under some conditions, as there is no inherent relationship between bindings and hello adjacency -- should be tied to routing neighbor adjacency for the AF. This solution is targeted to IPv4 and IPv6 AF for the Prefix FEC (and BTW it would make all current IPv4 binding advertising out-of-spec), but what about other AFs for this given FEC, and what about other FEC Types. For example, what about the case of an LDP session for Pseudowires (given that there is no "Pseudowire hello adjacency"? In this case, of an LDP session for PW signaling, should LSRs advertise Prefix FECs depending on the IPv4/IPv6 hello adjacency? And multicast? And ...? I note that there are other potential solutions in documents (e.g., capability negotiation, outbound filtering), but there is no document looking at the problem space more holistically. Lack of that, I sense it's premature to include a narrow solution in an LDP-over-IPv6 document -- after all, this is not a new problem, and exists with IPv4. And moreover, some of the potential solutions to this do not need standardization (i.e., can even be a local matter). I look forward to seeing WG consensus emerge on this point. Thanks, -- Carlos. > > You may answer simple yes/no to each Q, if you like. > > Cheers, > Rajiv > > > > > > * Consequently, an LDP peer advertising IPv4 bindings to > an LDP IPv6 only peer, which doesn't have IPv4 any more > (out in the future, of course). > > > ** > 7. Label Distribution > > This document specifies that an LSR should advertise and receive > both IPv4 and IPv6 label bindings from and to the peer, only if it > has valid IPv4 and IPv6 Hello Adjacencies for that peer, as > specified in section 6.2. > > This means that the LSR must not advertise any IPv6 label bindings > to a peer over an IPv4 LDP session, if no IPv6 Hello Adjacency > existed for that peer (and vice versa). > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From skraza@cisco.com Sat Oct 1 15:22:14 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECDB21F8C31 for ; Sat, 1 Oct 2011 15:22:14 -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=[AWL=0.000, 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 X7zXB3U040LB for ; Sat, 1 Oct 2011 15:22:13 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A6F8821F8C2D for ; Sat, 1 Oct 2011 15:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=4307; q=dns/txt; s=iport; t=1317507911; x=1318717511; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=iUqC/b0X7AdJDcI/Hts4hsYqHrhvm2H79h7aGMJfLIk=; b=gk50+4oh121EsawNeRiVA/QqVKLVTo1pJr2az6UY5WtQpbrwLNEzKMI7 99ZnrZQMZhzsR30dyR7rJ2Ov6sak7rQ1eIoD9YqySQthLwdQyj40Ld3vf aruz06cB4iJv+pg3ocJfFYaXhDGGDJg0/+FW7+x6aDiBg57OPA8q+IeZc 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABKTh06tJXHB/2dsb2JhbABBqDWBBYFTAQEBAQIBAQEBDwEnAgExEA0BCG0wAQEEARIbB4dZBpozAZ0HA4ckBJNihS6MLA X-IronPort-AV: E=Sophos;i="4.68,474,1312156800"; d="scan'208";a="25424704" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 01 Oct 2011 22:25:08 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p91MP8bO013959 for ; Sat, 1 Oct 2011 22:25:08 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 1 Oct 2011 17:25:08 -0500 Received: from 10.86.254.115 ([10.86.254.115]) by XMB-RCD-103.cisco.com ([72.163.62.145]) with Microsoft Exchange Server HTTP-DAV ; Sat, 1 Oct 2011 22:25:08 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Sat, 01 Oct 2011 18:25:28 -0400 From: Kamran Raza To: "Rajiv Asati (rajiva)" , Message-ID: Thread-Topic: [mpls] mpls-ldp-ipv6 : Issue needs WG input Thread-Index: Acx5aZZnrOyzpgT0TMaTSLiOSmUK6QHH283i In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C05F95305@XMB-RCD-111.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Oct 2011 22:25:08.0365 (UTC) FILETIME=[F9E9ABD0:01CC8088] Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2011 22:22:14 -0000 Please see inline for [skraza] On 11-09-22 4:52 PM, "Rajiv Asati (rajiva)" wrote: > While this document passed the WGLC without any comments, we wanted to > bring up an issue to seek your feedback. > > The issue is that the current LDP spec rfc5036 allows an LDP peer to > advertise IPv6 bindings to an LDP IPv4 peer, even though the peer may > not have any IPv6 enabled (or IPv6 LDP), and vice versa*. See figure 3 > in section 1.1.1 of ldp-ipv6 document. > > While mpls-ldp-ipv6 section 7** addresses this issue (by checking for v6 > hello adj, in line with existing 'targeted adj check for PW binding > advertisement'), we want to pose the following questions: > > (1) is this a reasonable issue to be fixed? [skraza]: Yes. > (2) is ldp-ipv6 document the right place to fix it? [skraza]: No. This issue of "un-ncessary binding advertisement" is not ipv6 prefix FEC specific, and currently exists for other type of LDP FECs as well. For example, it is possible that an LSR may send IPv4 prefix FEC bindings on an LDP session that mainly exist for PW FEC exchanges. Neither LDP RFC5036 [nor PW RFC4447] explicitly disallow this. Similarly, this issue even exists today within a single supported AF -- i.e. Often an LSR may end up advertising LIB for entire IPV4 prefix table to its peers, though the receiver may have interest only in few/handful of bindings. There are already IETF drafts which are addressing the similar issues mentioned above using different approaches/areas: 1) "LDP IP and PW Capability": draft-ietf-mpls-ldp-ip-pw-capability-00.txt 2) "LDP Outbound Label Filtering": draft-raza-mpls-ldp-olf-00.txt So, IMHO, this draft is not the right place to address/fix it. > (3) is the solution highlighted in section 7 a reasonable solution, if > you answered yes to both 1 and 2? [skraza]: No. This changes the very core of base LDP Spec. LDP label binding advertisement are bound to an LDP session and not LDP hello adjacencies. LDP Hello adjacencies are used to maintain next-hop adjacency and MPLS forwarding (labelled/unlablled) setup accordingly on given nextop IP path. Tie-ing label advertisement decision with hello adjacency not only will change very core of LDP base spec, but also be convergence impacting as explained below: Today, when an (hello) adjacency comes while session is already up and label have already been exchanged, there is no/minimal delay in setting up (labelled) MPLS forwarding after link/adj up (as labels are readily available from nexthop peer). Also, there are features like "Session protection" which are in place to explicitly enforce this - where an LSR keeps LDP session up (and remote labels intact) by means of special targeted-adj even when its one/more link adj go down. This means that when the link adj comes back up, the forwarding convergence is fast as it is not at all dependent on label advertisement exchange/completion. By tie-ing label advertisement with adj state, we are doing the exact opposite to what session-protection like features are trying to achieve. Finally, adjacencies with repeated flaps will cause quite of a network churn due to binding advertisement/withdrawal repeatedly. This churn will be more visible and impacting in case of LSRs/network operating in "ordered" control mode. My 2 cents, -- Kamran Raza Cisco Systems, Inc. > > You may answer simple yes/no to each Q, if you like. > > Cheers, > Rajiv > > > > > > * Consequently, an LDP peer advertising IPv4 bindings to > an LDP IPv6 only peer, which doesn't have IPv4 any more > (out in the future, of course). > > > ** > 7. Label Distribution > > This document specifies that an LSR should advertise and receive > both IPv4 and IPv6 label bindings from and to the peer, only if it > has valid IPv4 and IPv6 Hello Adjacencies for that peer, as > specified in section 6.2. > > This means that the LSR must not advertise any IPv6 label bindings > to a peer over an IPv4 LDP session, if no IPv6 Hello Adjacency > existed for that peer (and vice versa). > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From daniel@olddog.co.uk Sun Oct 2 13:31:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D358121F8532 for ; Sun, 2 Oct 2011 13:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.163 X-Spam-Level: X-Spam-Status: No, score=-102.163 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, DIET_1=0.083, 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 YbM+sBWalV5M for ; Sun, 2 Oct 2011 13:31:04 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 065FC21F8520 for ; Sun, 2 Oct 2011 13:31:03 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p92KY1Mh018534 for ; Sun, 2 Oct 2011 21:34:03 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p92KY0f0018528 for ; Sun, 2 Oct 2011 21:34:00 +0100 From: "Daniel King" To: References: <4E78D844.4090809@pi.nu> In-Reply-To: <4E78D844.4090809@pi.nu> Date: Sun, 2 Oct 2011 21:33:59 +0100 Message-ID: <001e01cc8142$9dd61760$d9824620$@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: AQGuH7nPHdI1POwiQ2N5XX/2+DpqVpWmRVBA Content-Language: en-gb Subject: Re: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 20:31:04 -0000 Hi WG, Just wanted to add my support for the work/document. Authors, I have also reviewed the document. I can provide an MS word document with change modification indicators to the current editor(s). In the meantime here are a number of comments and suggestions. Assuming the document is adopted, these suggestions might be incorporated after the ID is submitted as draft-ietf. 1. Solution Comments Having spoken to various vendors and operators I believe the preferred solution is to extend MPLS for MT networks by mapping an IP address to the corresponding Multi Topology: Single topology label ~ address MT label ~ (address plus topology) This would negate the need for changes at the data plane. Then the only mapping required is at the ingress-PE of an MPLS-MT LSP, each node would be capable of identifying the MPLS-MT LSP, and traffic is switched accordingly based on the incoming label information. This solution uses minimal protocol extensions. Please find my suggested updates and fixes for the first half of the document. 1. Document editors, table of contents and formatting - ChinaMobile/China Mobile - Verison/Verizon - Unnecessary number of CRs between authors and document title/name. - FEC TLV with MT-ID Extenstion/FEC TLV with MT-ID Extension 2. Revised Abstract >> Multi-topology (MT) routing is supported in IP through extension of IGP protocols, such as OSPF and IS-IS. It would be advantageous to extend Multiprotocol Label Switching (MPLS), using Label Distribution Protocol (LDP), to support multiple topologies. These LDP extensions, known as Multiple Topology Label Distribution Protocol (MT LDP), would allow the configuration of multiple topologies within an MPLS LDP enabled network. This document describes the protocol extensions required to extend the existing MPLS LDP signalling protocol for creating and maintaining LSPs in an MT environment. << Line 34: enviroment/environment 3. The introduction, as well as other areas of the document, could do with significant weight loss. Although interesting, some of the text is redundant in this document. I would suggest the introduction is slimmed down to the following text/edits, and a new requirements section (see comment 4) is added: >> OSPF and IS-IS use MT-ID (Multi-Topology Identification) to identify different topologies. For each topology identified by a MT-ID, IGP computes a separate SPF tree independently to find the best paths to the IP prefixes associated with this topology. For FECs that are associated with a specific topology, this solution utilises the same MT-ID of this topology in LDP. Thus LSP for a certain FEC may be created and maintained along the IGP path in this topology. Maintaining multiple MTs for MPLS network in a backwards-compatible manner requires several extensions to the label signaling encoding and processing procedures. When label is associated with a FEC, the FEC includes both IP address and topology it belongs to. << Line 204: certian/certain Line 238: managment/management Line 241: forwarding/forwarding Line 251: tolology/topology Line 253: assinged/assigned Line 256: prtoco/protocol Line 260: distingushed/distinguished and assinged/assigned 4. Requirements, specifically the lack thereof. The document would benefit from a paragraph with bullets detailing the objectives/requirements for these protocol extensions. 5. Application Scenarios are useful but specific requirements can be blended into the requirements section. Thanks, Dan -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: 20 September 2011 19:16 To: mpls-chairs@tools.ietf.org; mpls@ietf.org Subject: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document Working Group, this is to start a two week poll to see if there is support to make LDP Extension for Multi Topology Support draft-zhao-mpls-ldp-multi-topology-02.txt an MPLS working group document. Send your opinions to mpls@ietf.org Please remember that it is particular important that you include a technical motivation if you don't want the ID to become a working group document. The poll ends Wednesday Oct 5, 2011. /Loa for the MPLS wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From erosen@cisco.com Mon Oct 3 06:43:50 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8CA21F8A96 for ; Mon, 3 Oct 2011 06:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.742 X-Spam-Level: X-Spam-Status: No, score=-3.742 tagged_above=-999 required=5 tests=[AWL=-1.143, 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 DR+od2mNAdc7 for ; Mon, 3 Oct 2011 06:43:45 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 66BAF21F8A58 for ; Mon, 3 Oct 2011 06:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=1131; q=dns/txt; s=iport; t=1317649608; x=1318859208; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=Iy0bZkFRx54Du5AN6AsS+ftSZOKnJBB/afnmJjS5cC8=; b=CN7J1f0K1vylyTk9Ekar6PNJiBTLBrZDKGe02s9xBMBQavD3kOnvUDeb fRV6eLQzIvGC7pidqitVeyh5ECQKPFRp89iHLy0O/+4nI3h/L5P4MIF5D 6PXO1LLPF+YFblikCmJlg3AB2ZT2Qch2N6Oens1nKECu2E0Leqm2pfmqI E=; X-IronPort-AV: E=Sophos;i="4.68,479,1312156800"; d="scan'208";a="25647553" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 03 Oct 2011 13:46:47 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p93DklND013346; Mon, 3 Oct 2011 13:46:47 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id p93Dkkwb028736; Mon, 3 Oct 2011 09:46:46 -0400 To: Kamran Raza In-reply-to: Your message of Sat, 01 Oct 2011 18:25:28 -0400. Date: Mon, 03 Oct 2011 09:46:46 -0400 Message-ID: <28735.1317649606@erosen-linux> From: Eric Rosen Cc: mpls@ietf.org Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 13:43:50 -0000 I agree with Carlos and Kamran, and would suggest the removal of section 7. Also, the last paragraph of section 3 seems dubious: Additionally, it is desirable that a packet is forwarded to an LSP of an egress router, only if LSP's address-family matches with that of the LDP hello adjacency on the next-hop interface. > The issue is that the current LDP spec rfc5036 allows an LDP peer to > advertise IPv6 bindings to an LDP IPv4 peer, even though the peer may > not have any IPv6 enabled (or IPv6 LDP), and vice versa. There is a general issue of how to prevent LDP from sending label bindings to a particular peer, if the peer doesn't need those label bindings. I don't think the set of label bindings needed by the peer can be inferred from the type of the Hello adjacency. The information needed to choose the network layer protocol used by the LDP session should not be used to infer the set of label bindings to be distributed, as these are two independent choices. I think proposals for constraining the set of advertised label bindings should be outside the scope of this document. From internet-drafts@ietf.org Mon Oct 3 09:43:32 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC9B21F8C39; Mon, 3 Oct 2011 09:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 DYbqIPkv089p; Mon, 3 Oct 2011 09:43:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F4821F8C32; Mon, 3 Oct 2011 09:43:31 -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: 3.60 Message-ID: <20111003164331.16171.19405.idtracker@ietfa.amsl.com> Date: Mon, 03 Oct 2011 09:43:31 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-li-lb-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 16:43:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : MPLS Transport Profile lock Instruct and Loopback Functi= ons Author(s) : Sami Boutros Siva Sivabalan Rahul Aggarwal Martin Vigoureux Xuehui Dai Filename : draft-ietf-mpls-tp-li-lb-07.txt Pages : 11 Date : 2011-10-03 Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are "lock" and "loopback= ". The lock function enables an operator to lock a transport path such that it does not carry client traffic, but can continue to carry OAM messages and may carry test traffic. The loopback function allows an operator to set a specific node on the transport path into loopback mode such that it returns all received data. This document specifies the lock function for MPLS networks and describes how the loopback function operates in MPLS networks. This document updates RFC 6371 section 7.1.1. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-07.txt From quintin.zhao@huawei.com Mon Oct 3 12:14:21 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B4221F8DC5 for ; Mon, 3 Oct 2011 12:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, DIET_1=0.083, 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 C16DesLgj6sO for ; Mon, 3 Oct 2011 12:14:20 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 457AA21F8DC3 for ; Mon, 3 Oct 2011 12:14:20 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSI0081688XTF@usaga04-in.huawei.com> for mpls@ietf.org; Mon, 03 Oct 2011 14:17:22 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSI00AXW88WL2@usaga04-in.huawei.com> for mpls@ietf.org; Mon, 03 Oct 2011 14:17:21 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 03 Oct 2011 12:17:18 -0700 Received: from QZHAO (10.212.244.216) by DFWEML401-HUB.china.huawei.com (10.193.5.101) with Microsoft SMTP Server id 14.1.270.1; Mon, 03 Oct 2011 12:17:11 -0700 Date: Mon, 03 Oct 2011 15:16:59 -0400 From: Quintin Zhao In-reply-to: X-Originating-IP: [10.212.244.216] To: daniel@olddog.co.uk Message-id: <000f01cc8201$07c52300$174f6900$%zhao@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcyB/4VNiEQ9VCmRRReaAgLG7UiOyQAAJLFA References: Cc: mpls@ietf.org Subject: Re: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 19:14:21 -0000 Dan, Thank you for your review and helping us create a better document. I will discuss your comments with the other authors and we will incorporate changes in a future version of our document. Thanks, Quintin. ---------------------------------------------------------------------- Message: 1 Date: Sun, 2 Oct 2011 21:33:59 +0100 From: "Daniel King" To: Subject: Re: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document Message-ID: <001e01cc8142$9dd61760$d9824620$@olddog.co.uk> Content-Type: text/plain; charset="US-ASCII" Hi WG, Just wanted to add my support for the work/document. Authors, I have also reviewed the document. I can provide an MS word document with change modification indicators to the current editor(s). In the meantime here are a number of comments and suggestions. Assuming the document is adopted, these suggestions might be incorporated after the ID is submitted as draft-ietf. 1. Solution Comments Having spoken to various vendors and operators I believe the preferred solution is to extend MPLS for MT networks by mapping an IP address to the corresponding Multi Topology: Single topology label ~ address MT label ~ (address plus topology) This would negate the need for changes at the data plane. Then the only mapping required is at the ingress-PE of an MPLS-MT LSP, each node would be capable of identifying the MPLS-MT LSP, and traffic is switched accordingly based on the incoming label information. This solution uses minimal protocol extensions. Please find my suggested updates and fixes for the first half of the document. 1. Document editors, table of contents and formatting - ChinaMobile/China Mobile - Verison/Verizon - Unnecessary number of CRs between authors and document title/name. - FEC TLV with MT-ID Extenstion/FEC TLV with MT-ID Extension 2. Revised Abstract >> Multi-topology (MT) routing is supported in IP through extension of IGP protocols, such as OSPF and IS-IS. It would be advantageous to extend Multiprotocol Label Switching (MPLS), using Label Distribution Protocol (LDP), to support multiple topologies. These LDP extensions, known as Multiple Topology Label Distribution Protocol (MT LDP), would allow the configuration of multiple topologies within an MPLS LDP enabled network. This document describes the protocol extensions required to extend the existing MPLS LDP signalling protocol for creating and maintaining LSPs in an MT environment. << Line 34: enviroment/environment 3. The introduction, as well as other areas of the document, could do with significant weight loss. Although interesting, some of the text is redundant in this document. I would suggest the introduction is slimmed down to the following text/edits, and a new requirements section (see comment 4) is added: >> OSPF and IS-IS use MT-ID (Multi-Topology Identification) to identify different topologies. For each topology identified by a MT-ID, IGP computes a separate SPF tree independently to find the best paths to the IP prefixes associated with this topology. For FECs that are associated with a specific topology, this solution utilises the same MT-ID of this topology in LDP. Thus LSP for a certain FEC may be created and maintained along the IGP path in this topology. Maintaining multiple MTs for MPLS network in a backwards-compatible manner requires several extensions to the label signaling encoding and processing procedures. When label is associated with a FEC, the FEC includes both IP address and topology it belongs to. << Line 204: certian/certain Line 238: managment/management Line 241: forwarding/forwarding Line 251: tolology/topology Line 253: assinged/assigned Line 256: prtoco/protocol Line 260: distingushed/distinguished and assinged/assigned 4. Requirements, specifically the lack thereof. The document would benefit from a paragraph with bullets detailing the objectives/requirements for these protocol extensions. 5. Application Scenarios are useful but specific requirements can be blended into the requirements section. Thanks, Dan -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: 20 September 2011 19:16 To: mpls-chairs@tools.ietf.org; mpls@ietf.org Subject: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document Working Group, this is to start a two week poll to see if there is support to make LDP Extension for Multi Topology Support draft-zhao-mpls-ldp-multi-topology-02.txt an MPLS working group document. Send your opinions to mpls@ietf.org Please remember that it is particular important that you include a technical motivation if you don't want the ID to become a working group document. The poll ends Wednesday Oct 5, 2011. /Loa for the MPLS wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ------------------------------ Message: 2 Date: Mon, 03 Oct 2011 09:46:46 -0400 From: Eric Rosen To: Kamran Raza Cc: mpls@ietf.org Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input Message-ID: <28735.1317649606@erosen-linux> I agree with Carlos and Kamran, and would suggest the removal of section 7. Also, the last paragraph of section 3 seems dubious: Additionally, it is desirable that a packet is forwarded to an LSP of an egress router, only if LSP's address-family matches with that of the LDP hello adjacency on the next-hop interface. > The issue is that the current LDP spec rfc5036 allows an LDP peer to > advertise IPv6 bindings to an LDP IPv4 peer, even though the peer may > not have any IPv6 enabled (or IPv6 LDP), and vice versa. There is a general issue of how to prevent LDP from sending label bindings to a particular peer, if the peer doesn't need those label bindings. I don't think the set of label bindings needed by the peer can be inferred from the type of the Hello adjacency. The information needed to choose the network layer protocol used by the LDP session should not be used to infer the set of label bindings to be distributed, as these are two independent choices. I think proposals for constraining the set of advertised label bindings should be outside the scope of this document. ------------------------------ Message: 3 Date: Mon, 03 Oct 2011 09:43:31 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-li-lb-07.txt Message-ID: <20111003164331.16171.19405.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8" A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Transport Profile lock Instruct and Loopback Functions Author(s) : Sami Boutros Siva Sivabalan Rahul Aggarwal Martin Vigoureux Xuehui Dai Filename : draft-ietf-mpls-tp-li-lb-07.txt Pages : 11 Date : 2011-10-03 Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are "lock" and "loopback". The lock function enables an operator to lock a transport path such that it does not carry client traffic, but can continue to carry OAM messages and may carry test traffic. The loopback function allows an operator to set a specific node on the transport path into loopback mode such that it returns all received data. This document specifies the lock function for MPLS networks and describes how the loopback function operates in MPLS networks. This document updates RFC 6371 section 7.1.1. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-07.txt ------------------------------ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls End of mpls Digest, Vol 90, Issue 3 *********************************** From adrian@olddog.co.uk Mon Oct 3 14:47:37 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E120821F8E2F for ; Mon, 3 Oct 2011 14:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 7cEV7ZdqNZk9 for ; Mon, 3 Oct 2011 14:47:37 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id DFCF821F8DC5 for ; Mon, 3 Oct 2011 14:47:36 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p93Lodox031319 for ; Mon, 3 Oct 2011 22:50:39 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p93LocX2031313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 3 Oct 2011 22:50:39 +0100 From: "Adrian Farrel" To: References: <20111003164331.16171.19405.idtracker@ietfa.amsl.com> In-Reply-To: <20111003164331.16171.19405.idtracker@ietfa.amsl.com> Date: Mon, 3 Oct 2011 22:50:36 +0100 Message-ID: <027401cc8216$7c84ef80$758ece80$@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: AQMKHQO8esnAEGZnseDFRZrxgJfY65Lv7V8w Content-Language: en-gb Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-li-lb-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 21:47:38 -0000 Hi MPLS WG, As usual, I did my AD review of this draft when I received the publication request. In this case, the changes I wanted to see were quite extensive and structural. For such a short draft, if turned out to be easier to work with Sami (as pen-holding editor) and Stewart (as one of the co-authors) to actually make the changes rather than to try to explain what I wanted to see done. However, I have promised to summarise the changes as effectively the output of my review. You can find these below. I have agreed with the MPLS Chairs that these changes are quite extensive and, although they do not make any change of substance to the simple message that the I-D defines, the WG should have a further last call period to make sure they are happy with the revised text. However, since the changes are essentially non-technical, I will also start the IETF last call at roughly the same time so that the two run in parallel. Thanks, Adrian === AD review of draft-ietf-mpls-tp-li-lb --- If you are updating RFC 6371, you need a normative reference. This will be a formal downref that needs to be called out in the shepherd write-up and in IETF last call. --- The Abstract is clumsy and needs to be rewritten to say what the functions are and what the document does. This led to the new Abstract text in the current revision. --- Don't need a ToC in such a short document. --- The Introduction (Section 1) contains too much detailed information. At the same time, the descriptions of the two functions is spread out across the document. My proposal (as implemented) was to shorten the Introduction into much more of a summary, and to create Sections 3 and 4 to provide the functional description of the two functions. Material was pulled from Sections 1, 3, 4, 5, and 6 to create the new sections 3 and 4. --- Section 2 LSR, MPLS-OAM, and NMS are not used in the document --- Section 3.1 Is Figure 1 necessary? If you include it, you must describe the fields. But since it is a direct copy, you can leave it out. We deleted it. --- Section 3.2 You need to describe the reserved field. --- Section 3.2 Refresh Timer This value MUST NOT be changed for the duration of that lock. So, you need to describe what a receiver does if the value is changed. We added text to say "MAY ignore new values" --- Section 3.2 MEP Source ID TLV: This is the "CC/CV MEP ID TLV" defined in [3]. A little more info? Added text to say that this is the ID of the MEP that sent this message. --- Section 4 didn't really add anything. Moved the text to the new Sections 3 and 4. --- Section 5.1 s/A MEP is locked either/A MEP is locked if either/ --- The descriptions of behavior for locking and unlocking was spread across {5.1, 5.5} and {5.2, 5.6} This led to some cases not being covered, and a rather unfortunate proof-by-example definition. We merged the material to new sections describing the operational procedures. Then we added explanations of the following questions... What does it mean to say a MEP is "not receiving LI messages"? How long does a MEP wait before deciding it is not receiving LI messages: - when it has received a previous LI message - when it has never received an LI message? When and how is the lock actually implemented? What constitutes a bad LI message? Is it wise to log every bad LI message? --- Section 5.2 s/A MEP would unlock transport path/A MEP unlocks a transport path/ --- NOTE WELL This is maybe a contentious change, but we could not really find any deep reason for the text, and I was pretty sure it did not say what was meant. Section 5.3 This appears to say that you cannot stop sending traffic on a transport path without locking it. i think it may have been meant to say that if you want to put the path into an administratively locked state, you must actually lock it. Hopefully this is stupifyingly obvious from the document and doesn't need any other clarification. --- Section 5.4 The somewhat detailed example scenario described in 5.4 is barely used in 5.5. and 5.6. Since 5.5 and 5.6 are folded into the operational description, 5.4 is deleted. --- Section 6 The control plane protocols utilize hop-by-hop security, and assume a "chain-of-trust" model such that end-to-end control plane security is not used. True but irrelevant. Text removed. --- Section 6 Thus, there is no simple way of preventing any traffic being carried between in the G-ACh consenting nodes. Between what? Text clarified. --- Section 7.1 s/(Section 3.1)/[This.I-D]/ --- Section 8 "D'Alessandro Alessandro Gerardo" is garbled --- Author's Addresses Pluralise! --- Please separate the authors into "Editors' Addresses" for the front- page editors, and "Contributing Authors" for everyone else. From swallow@cisco.com Mon Oct 3 15:20:27 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2F521F8DF5; Mon, 3 Oct 2011 15:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.909 X-Spam-Level: X-Spam-Status: No, score=-101.909 tagged_above=-999 required=5 tests=[AWL=-0.707, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 2XNfjo5MxaWs; Mon, 3 Oct 2011 15:20:26 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C778B21F8CD0; Mon, 3 Oct 2011 15:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=1296; q=dns/txt; s=iport; t=1317680609; x=1318890209; h=date:subject:from:to:cc:message-id:mime-version; bh=cCvsx9EN8blhmUPSvfaD7LExZA0E13oUxQTyGfjbxeo=; b=QaBTO9qDyopX/5Iyq6oCThoK08yufirZCISzq2aXjcpZ3cJC13BgLTQC 9ZnEXR0qjQ9xFa6ghRXdZnwyZSy+MvKs1pYF88iathCgFNGqHnraZGqRe zTWkgkBkHNUuOf/tRoAGXfbAAu2RsfFkXZKucMBc8//wbCRnMk75hqC1k 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMHAOQ0ik6tJV2b/2dsb2JhbABCgk2WZo1iboEFgUoFBgEEEgEqPBIBCwGBGgEEDieHUZpkAZ19hyEEk2CFLows X-IronPort-AV: E=Sophos;i="4.68,481,1312156800"; d="scan'208,217";a="25769810" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 03 Oct 2011 22:23:29 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p93MNSkc016807; Mon, 3 Oct 2011 22:23:28 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 17:23:28 -0500 Received: from 10.98.32.168 ([10.98.32.168]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Mon, 3 Oct 2011 22:23:28 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Mon, 03 Oct 2011 18:23:26 -0400 From: George Swallow To: Message-ID: Thread-Topic: Second last call on draft-ietf-mpls-tp-li-lb Thread-Index: AcyCGxG5HLX5qS1FMkKS+naA0YA0iw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3400511007_63764664" X-OriginalArrivalTime: 03 Oct 2011 22:23:28.0549 (UTC) FILETIME=[133E7550:01CC821B] Cc: pwe3@ietf.org Subject: [mpls] Second last call on draft-ietf-mpls-tp-li-lb X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 22:20:27 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3400511007_63764664 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit All - draft-ietf-mpls-tp-li-lb-07.txt has gone through an extensive rewrite. We are therefore initiating a new WG last call. Note however, the IETF last call will run nearly concurrently. The last call ends at Oct 17 at 24:00 GMT. George, Ross, & Loa --B_3400511007_63764664 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Second last call on draft-ietf-mpls-tp-li-lb All -
draft-ietf-mpls-tp-li-lb-07.txt has gone throu= gh an extensive rewrite.  We are therefore initiating a new WG last cal= l.  Note however, the IETF last call will run nearly concurrently.

The last call ends at Oct 17 at 24:00 GMT.

George, Ross, & Loa --B_3400511007_63764664-- From gregimirsky@gmail.com Mon Oct 3 18:31:32 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D215121F8D19 for ; Mon, 3 Oct 2011 18:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.502 X-Spam-Level: X-Spam-Status: No, score=-3.502 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Ao0VEPRAgzwf for ; Mon, 3 Oct 2011 18:31:32 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C7B4821F8D31 for ; Mon, 3 Oct 2011 18:31:31 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so5040935vcb.31 for ; Mon, 03 Oct 2011 18:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=m1HVmdTMlHMRfgTT5nBD6Chbz3N9QGHGNm6FW+U0irc=; b=gFIgcIQS24xkchSil/C+IILHDNPFdC6/uiTPUxia8bxcygqf0eDFNmiBo7MfXJ76uV uuVbpP+KzXbn2HxNIlZn/BIRMIdhfvGlqHSN9F5pT3T3VTDpkbAssrO2kiXm5qg0Xees 7dpq+B4QiEpPVrjjXJlu9iKozj+/17yEllzLU= MIME-Version: 1.0 Received: by 10.52.26.97 with SMTP id k1mr583846vdg.523.1317692073049; Mon, 03 Oct 2011 18:34:33 -0700 (PDT) Received: by 10.52.163.199 with HTTP; Mon, 3 Oct 2011 18:34:33 -0700 (PDT) Date: Mon, 3 Oct 2011 18:34:33 -0700 Message-ID: From: Greg Mirsky To: mpls@ietf.org Content-Type: multipart/alternative; boundary=20cf307f33eceffffb04ae6f1733 Subject: [mpls] Comments on draft-ietf-mpls-tp-li-lb-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 01:31:32 -0000 --20cf307f33eceffffb04ae6f1733 Content-Type: text/plain; charset=ISO-8859-1 Dear Authors, Editors, et al. Below are my notes and comments to the latest version of LI/LB document: - I couldn't find Table of Contents in this version. - Introduction, third para. Applicability of the Loopback is limited, comparing to previous versions, to bi-directional co-routed LSP, PW and MPLS Section. I agree that statement of applicability in previous versions was bit too cumbersome but this one excludes bi-directional associated LSP at all. I think that Loopback can be used on this construct at MIP that are on forward and reverse direction of given bi-directional associated MPLS-TP LSP. And I think that MPLS Section is not necessarily a bi-directional co-routed object. - p.3, third para though "despatch - a less common spelling of dispatch" might consider 's/despatch/dispatch/' - Section 3, last para on p.3, s/PW/PWs/ - Section 4, third para s/receiving MEP/receiving MP/ (MP - MEG Point) or consider s/receiving MEP/MP/ since text in the sentence refers to it being in the loopback state. - Section 4, p.4, second to last para. I think that management plane sets in or requests Loopback on specific MP but not performs it. - Section 4.1, first bullet s/e/be/ - Definition given in Section 4.1 is broader than one in the Introduction. Personally I like the latter better though I think that it can be expanded to include MIPs on bi-directional associated LSP that are on forward and reverse direction of it. - Section 4.1, s/LSPs, PW,/LSPs, PWs,/ - Section 6.2 I think that UnLocking implies that a management process must send Unlocked command on both MEPs. In previous version absence of LI OAM for 3.5 times of Refresh Timer would have unlocked the transport path. The old definition of UnLock procedure was missing the fact that LI messages would not be delivered past LB but the new one makes it exclusive function of NMS or management plane. Is that desired? - Section 6.2 have changed how Refresh Timer used. Previous versions based UnLocking on Refresh Timer while now it is used to schedule turning a transport path back to service after it was explicitly UnLocked. I'll note that service could not be restored faster than in 3.5 seconds according to described procedure. Is that desired behavior? Regards, Greg On Mon, Oct 3, 2011 at 9:43 AM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Multiprotocol Label Switching > Working Group of the IETF. > > Title : MPLS Transport Profile lock Instruct and Loopback > Functions > Author(s) : Sami Boutros > Siva Sivabalan > Rahul Aggarwal > Martin Vigoureux > Xuehui Dai > Filename : draft-ietf-mpls-tp-li-lb-07.txt > Pages : 11 > Date : 2011-10-03 > > Two useful Operations, Administration, and Maintenance (OAM) > functions in a transport network are "lock" and > "loopback". The lock > function enables an operator to lock a transport path such that it > does not carry client traffic, but can continue to carry OAM messages > and may carry test traffic. The loopback function allows an operator > to set a specific node on the transport path into loopback mode such > that it returns all received data. > > This document specifies the lock function for MPLS networks and > describes how the loopback function operates in MPLS networks. > > This document updates RFC 6371 section 7.1.1. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-07.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-07.txt > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --20cf307f33eceffffb04ae6f1733 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors, Editors, et al.
Below are my notes and comments to the lat= est version of LI/LB document:
  • I couldn't find Table of Cont= ents in this version.
  • Introduction, third para. Applicability = of the Loopback is limited, comparing to previous versions, to bi-direction= al co-routed LSP, PW and MPLS Section. I agree that statement of applicabil= ity in previous versions was bit too cumbersome but this one excludes bi-di= rectional associated LSP at all. I think that Loopback can be used on this = construct at MIP that are on forward and reverse direction of given bi-dire= ctional associated MPLS-TP LSP. And I think that MPLS Section is not necess= arily a bi-directional co-routed object.
  • p.3, third para though "despatch - a less commo= n spelling of dispatch" might consider 's/despatch/dispatch= /'
  • Section 3, last para on p.3, s/PW/PWs/
  • Section 4= , third para s/receiving MEP/receiving MP/ (MP - MEG Point) or consider s/r= eceiving MEP/MP/ since text in the sentence refers to it being in the loopb= ack state.
  • Section 4, p.4, second to last para. I think that management plane= sets in or requests Loopback on specific MP but not performs it.
  • S= ection 4.1, first bullet s/e/be/
  • Definition given in Section 4.1 is= broader than one in the Introduction. Personally I like the latter better = though I think that it can be expanded to include MIPs on bi-directional as= sociated LSP that are on forward and reverse direction of it.
  • Section 4.1, s/LSPs, PW,/LSPs, PWs,/
  • Section 6.2 I think that U= nLocking implies that a management process must send Unlocked command on bo= th MEPs. In previous version absence of LI OAM for 3.5 times of Refresh Tim= er would have unlocked the transport path. The old definition of UnLock pro= cedure was missing the fact that LI messages would not be delivered past LB= but the new one makes it exclusive function of NMS or management plane. Is= that desired?
  • Section 6.2 have changed how Refresh Timer used. Previous versions base= d UnLocking on Refresh Timer while now it is used to schedule turning a tra= nsport path back to service after it was explicitly UnLocked. I'll note= that service could not be restored faster than in 3.5 seconds according to= described procedure. Is that desired behavior?
Regards,
Greg


On Mon, Oct 3, = 2011 at 9:43 AM, <internet-drafts@ietf.org> wrote:
A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : MPLS Transport Profile lock Ins= truct and Loopback Functions
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Sami Boutros
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Siva Sivabalan
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Rahul Aggarwal
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Martin Vigoureux
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Xuehui Dai
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-mpls-tp-li-lb-07.txt =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 11
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-10-03

=A0 Two useful Operations, Administration, and Maintenance (OAM)
=A0 functions in a transport network are &quot;lock&quot; and &= ;quot;loopback&quot;. The lock
=A0 function enables an operator to lock a transport path such that it
=A0 does not carry client traffic, but can continue to carry OAM messages<= br> =A0 and may carry test traffic. The loopback function allows an operator =A0 to set a specific node on the transport path into loopback mode such =A0 that it returns all received data.

=A0 This document specifies the lock function for MPLS networks and
=A0 describes how the loopback function operates in MPLS networks.

=A0 This document updates RFC 6371 section 7.1.1.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-= tp-li-lb-07.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp= -li-lb-07.txt
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--20cf307f33eceffffb04ae6f1733-- From stbryant@cisco.com Tue Oct 4 00:45:49 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCAE21F8D17 for ; Tue, 4 Oct 2011 00:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.463 X-Spam-Level: X-Spam-Status: No, score=-110.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Zscj208i-se for ; Tue, 4 Oct 2011 00:45:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 53D1521F8D0A for ; Tue, 4 Oct 2011 00:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=355; q=dns/txt; s=iport; t=1317714533; x=1318924133; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=EoSzv+dhVO+kaApDPodGpCwqqu/O3ylF5izcBu5JhLU=; b=jZ2y0ICNjGdUllHpotWAzq900c+KQh9NvNZ3R55ZW19iFIPYQppnSYRV eAKGsZbRBq2orptfoh0Ss3wlrEZ87lhFtVe05G6XMiU66iEvsN6Kbrmo7 VcBrNOcWlE1p1/M6OPhDRVkxmFn5D8UgrM2a06N0xT8FEWeaZ6O/PusKm E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgGAH65ik6Q/khN/2dsb2JhbABCmSqOTYEFgVMBAQEEEgECASJAEQsYCRYPCQMCAQIBRRMIAQEFGYdgmhgBgysPAZpThyIEk2aRQw X-IronPort-AV: E=Sophos;i="4.68,483,1312156800"; d="scan'208";a="118197380" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 04 Oct 2011 07:48:51 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p947mpt7017933 for ; Tue, 4 Oct 2011 07:48:51 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p947mo0V026696; Tue, 4 Oct 2011 08:48:50 +0100 (BST) Message-ID: <4E8ABA61.5020407@cisco.com> Date: Tue, 04 Oct 2011 08:48:49 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mpls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-li-lb-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 07:45:49 -0000 On 04/10/2011 02:34, Greg Mirsky wrote: > Dear Authors, Editors, et al. > Below are my notes and comments to the latest version of LI/LB document: > > * I couldn't find Table of Contents in this version. > Hi Greg A table of contents is optional in a document less that 15 pages long. (http://www.ietf.org/id-info/guidelines.html) Stewart From loa@pi.nu Tue Oct 4 00:54:35 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383B321F8D35 for ; Tue, 4 Oct 2011 00:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.652 X-Spam-Level: X-Spam-Status: No, score=-102.652 tagged_above=-999 required=5 tests=[AWL=-0.053, 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 nqiag5AuTvd6 for ; Tue, 4 Oct 2011 00:54:34 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAFB21F8CED for ; Tue, 4 Oct 2011 00:54:34 -0700 (PDT) Received: from [192.168.1.64] (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 mail.pi.nu (Postfix) with ESMTPSA id C5F162A8002 for ; Tue, 4 Oct 2011 09:57:36 +0200 (CEST) Message-ID: <4E8ABC5B.3030307@pi.nu> Date: Tue, 04 Oct 2011 09:57:15 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mpls@ietf.org References: <4E8ABA61.5020407@cisco.com> In-Reply-To: <4E8ABA61.5020407@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-li-lb-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 07:54:35 -0000 Stewart, that is correct - it is an option not to have the a table of content. However it is also an option to have it, the fact that people asks for the toc has earlier lead to a recommendation from wg chairs to include a toc if the the authors think it is beneficial; i.e. not read the recommendation as "you can't use a toc if the ID is shorter than 15 pages". /Loa On 2011-10-04 09:48, Stewart Bryant wrote: > On 04/10/2011 02:34, Greg Mirsky wrote: >> Dear Authors, Editors, et al. >> Below are my notes and comments to the latest version of LI/LB document: >> >> * I couldn't find Table of Contents in this version. >> > Hi Greg > > A table of contents is optional in a document less that 15 pages long. > (http://www.ietf.org/id-info/guidelines.html) > > Stewart > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From iesg-secretary@ietf.org Tue Oct 4 07:04:34 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D0C21F8C17; Tue, 4 Oct 2011 07:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 QN86iI4HB2qG; Tue, 4 Oct 2011 07:04:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22F821F8BDC; Tue, 4 Oct 2011 07:04:33 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111004140433.24733.23365.idtracker@ietfa.amsl.com> Date: Tue, 04 Oct 2011 07:04:33 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: (MPLS Transport Profile lock Instruct and Loopback Functions) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 14:04:34 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS Transport Profile lock Instruct and Loopback Functions' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-10-18. 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 Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are "lock" and "loopback". The lock function enables an operator to lock a transport path such that it does not carry client traffic, but can continue to carry OAM messages and may carry test traffic. The loopback function allows an operator to set a specific node on the transport path into loopback mode such that it returns all received data. This document specifies the lock function for MPLS networks and describes how the loopback function operates in MPLS networks. This document updates RFC 6371 section 7.1.1. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-li-lb/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-li-lb/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1439/ This document contains a "downref" to RFC 6371, the Informational RFC that it updates. From adrian@olddog.co.uk Tue Oct 4 14:21:51 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB0C21F8EB5 for ; Tue, 4 Oct 2011 14:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 n+kMKG9VPqmm for ; Tue, 4 Oct 2011 14:21:50 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 9421921F8EB4 for ; Tue, 4 Oct 2011 14:21:49 -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 p94LOsTp001399; Tue, 4 Oct 2011 22:24:54 +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 p94LOqgb001387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Oct 2011 22:24:53 +0100 From: "Adrian Farrel" To: "'Greg Mirsky'" , References: In-Reply-To: Date: Tue, 4 Oct 2011 22:24:51 +0100 Message-ID: <042101cc82dc$0da49e50$28eddaf0$@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: AQJn5Gr+JLDeCP406LeaiwX/KAN2W5Q16XiA Content-Language: en-gb Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-li-lb-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 21:21:51 -0000 Hi Greg, Thanks for reading. Let me answer since a lot of the text was mine. > I couldn't find Table of Contents in this version. I guess Loa and I can disagree :-) There are about 8 pages of real text in the document, not enough for a ToC IMHO > Introduction, third para. > Applicability of the Loopback is limited, comparing to previous versions, > to bi-directional co-routed LSP, PW and MPLS Section. I agree that > statement of applicability in previous versions was bit too cumbersome > but this one excludes bi-directional associated LSP at all. I think that Loopback > can be used on this construct at MIP that are on forward and reverse direction > of given bi-directional associated MPLS-TP LSP. And I think that MPLS Section > is not necessarily a bi-directional co-routed object. Reading too fast? The bullet says... - The loopback function allows an operator to set a specific node on a transport path into loopback mode such that it returns all received data. Loopback can be applied at a Maintenance Entity Group End Point (MEP) or a Maintenance Entity Group Intermediate Point (MIP) on a co-routed bidirectional LSP, PW or MPLS Section. It can also be applied at a MEP on an associated bidirectional LSP, PW or MPLS Section. That seems to cover exactly the same cases (including associated bidir) as in the previous version. > p.3, third para though "despatch - a less common spelling of dispatch" > might consider 's/despatch/dispatch/' Shall we let the RFC Editor worry about differences between UK and US English? "despatch. Same as dispatch" - Chambers 20th Century Dictionary > Section 3, last para on p.3, s/PW/PWs/ yes > Section 4, third para s/receiving MEP/receiving MP/ (MP - MEG Point) > or consider s/receiving MEP/MP/ since text in the sentence refers to it > being in the loopback state. Good catch. Not sure if "MP" is known term. Can we say "receiving MEP or MIP" ? > Section 4, p.4, second to last para. I think that management plane > sets in or requests Loopback on specific MP but not performs it. The two sentences in this paragraph are directly copied from the precious revision with the only change to drop "MUST" to lower case. Not sure what to say here since the WG clearly agreed to this text before. I think the intention was to say that a control plane is not required in order to achieve loopback. > Section 4.1, first bullet s/e/be/ Yes > Definition given in Section 4.1 is broader than one in the Introduction. > Personally I like the latter better though I think that it can be expanded > to include MIPs on bi-directional associated LSP that are on forward and > reverse direction of it. I think it is the same definition. See the paragraph quoted above and compare with: - The node in loopback mode must be on both the forward and return paths. This possible for all MEPs and MIPs on a co-routed bidirectional LSP, PW, or MPLS Section, but is only possible on for MEPs on associated bidirectional LSPs, PW, or MPLS Sections. ...which seems to exclude the MIPs on assoc bidir as you say. > Section 4.1, s/LSPs, PW,/LSPs, PWs,/ Yes > Section 6.2 I think that UnLocking implies that a management process > must send Unlocked command on both MEPs. In previous version > absence of LI OAM for 3.5 times of Refresh Timer would have unlocked > the transport path. The old definition of UnLock procedure was missing > the fact that LI messages would not be delivered past LB but the new > one makes it exclusive function of NMS or management plane. Is that > desired? I think that you have highlighted one of the problems with the previous version. It was confusing! However, absence of LI would NOT have unlocked a MEP when a lock command had previously been issued to that MEP. >From the old section 5.2 A MEP would unlock transport path and put it back to service if and only if there is no management request to lock the path and it is not receiving in-band LI messages. A MEP is unlocked when there is no management request to Lock and no LI OAM messages are received. The old document did also mention that LI might go AWOL and said in Section 4: LI messages may be lost during looping or maintenance operations, thus locking both ends is required, before such operations occur. I don't believe the new version has made any functional change. > Section 6.2 have changed how Refresh Timer used. Previous versions > based UnLocking on Refresh Timer while now it is used to schedule > turning a transport path back to service after it was explicitly UnLocked. As above, I don't believe the new version has changed what was described, however... > I'll note that service could not be restored faster than in 3.5 seconds according > to described procedure. Is that desired behavior? That is a good question for the WG. It was my assumption (from the previous revision) that rapid unlocking and turn-up was not a requirement or it would have been included. If the WG now wants to include it, it will need to examine the use of an unlock OAM message. This could be done using a new message or a flag on the existing lock message. It could be achieved by tweaking this document or introducing a new document. Cheers, Adrian From gregimirsky@gmail.com Tue Oct 4 14:56:06 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92CA21F8E8D for ; Tue, 4 Oct 2011 14:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wqpLkog8EuS2 for ; Tue, 4 Oct 2011 14:56:05 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECA621F8E78 for ; Tue, 4 Oct 2011 14:56:05 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so1052954vcb.31 for ; Tue, 04 Oct 2011 14:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vNiNfXQC2cNF9dzRunKyNFGMhZT5Rev60V973pS08tY=; b=jW4m19UsZQS2LB8+RSNLRB0Pkd0RNFTlbKTM9Iig/gpGUdPjTkIelQk/70y/JNwKJh K/OF5GibrORE4Ic2GpHyhgeZcsVwY1+Fn3ZE/W2L2dzhCWsEpraCnmPEnkPGjpujpEn4 iYBSrZLUpndDHBejSrSBbX6AjRgxn+QFLLIw8= MIME-Version: 1.0 Received: by 10.52.99.66 with SMTP id eo2mr1615967vdb.121.1317765551070; Tue, 04 Oct 2011 14:59:11 -0700 (PDT) Received: by 10.52.163.199 with HTTP; Tue, 4 Oct 2011 14:59:11 -0700 (PDT) In-Reply-To: <042101cc82dc$0da49e50$28eddaf0$@olddog.co.uk> References: <042101cc82dc$0da49e50$28eddaf0$@olddog.co.uk> Date: Tue, 4 Oct 2011 14:59:11 -0700 Message-ID: From: Greg Mirsky To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=20cf307f37c2919f6d04ae803336 Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-li-lb-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 21:56:06 -0000 --20cf307f37c2919f6d04ae803336 Content-Type: text/plain; charset=ISO-8859-1 Hi Adrian, greatly appreciate your kind consideration of my notes. I've in-lined mine and tagged with GIM>> Regards, Greg On Tue, Oct 4, 2011 at 2:24 PM, Adrian Farrel wrote: > Hi Greg, > > Thanks for reading. Let me answer since a lot of the text was mine. > > > I couldn't find Table of Contents in this version. > > I guess Loa and I can disagree :-) > There are about 8 pages of real text in the document, not enough for a ToC > IMHO > GIM>> I'm OK either way > > > Introduction, third para. > > Applicability of the Loopback is limited, comparing to previous versions, > > to bi-directional co-routed LSP, PW and MPLS Section. I agree that > > statement of applicability in previous versions was bit too cumbersome > > but this one excludes bi-directional associated LSP at all. I think that > Loopback > > can be used on this construct at MIP that are on forward and reverse > direction > > of given bi-directional associated MPLS-TP LSP. And I think that MPLS > Section > > is not necessarily a bi-directional co-routed object. > > Reading too fast? > GIM>> Yep, sorry, cognitive filter ;) GIM>> But then PW and MPLS Section have been referred twice - after co-routed LSP, then after associated LSP. Or intention was to apply co-routed and associated to PW and MPLS Section? Would making the last sentence to "It can also be applied at a MEP on an associated bidirectional LSP" be sufficient? But still, MIPs that are on forward and reverse direction of an associated bi-directional LSP are excluded. I believe that previous versions tried to include such MIPs since these are required to be aware of directions and their correlation. Is this change intentional? > > The bullet says... > > - The loopback function allows an operator to set a specific node on > a transport path into loopback mode such that it returns all > received data. Loopback can be applied at a Maintenance Entity > Group End Point (MEP) or a Maintenance Entity Group Intermediate > Point (MIP) on a co-routed bidirectional LSP, PW or MPLS > Section. It can also be applied at a MEP on an associated > bidirectional LSP, PW or MPLS Section. > > That seems to cover exactly the same cases (including associated bidir) as > in > the previous version. > > > p.3, third para though "despatch - a less common spelling of dispatch" > > might consider 's/despatch/dispatch/' > > Shall we let the RFC Editor worry about differences between UK and US > English? > "despatch. Same as dispatch" - Chambers 20th Century Dictionary > > > Section 3, last para on p.3, s/PW/PWs/ > > yes > > > Section 4, third para s/receiving MEP/receiving MP/ (MP - MEG Point) > > or consider s/receiving MEP/MP/ since text in the sentence refers to it > > being in the loopback state. > > Good catch. > Not sure if "MP" is known term. > Can we say "receiving MEP or MIP" ? > GIM>> Works for me > > > Section 4, p.4, second to last para. I think that management plane > > sets in or requests Loopback on specific MP but not performs it. > > The two sentences in this paragraph are directly copied from the precious > revision with the only change to drop "MUST" to lower case. > > Not sure what to say here since the WG clearly agreed to this text before. > I think the intention was to say that a control plane is not required in > order > to achieve loopback. > GIM>> What if the first sentence says: A management plane can be too used to set a MEP or MIP along a transport path in Loopback. > > > Section 4.1, first bullet s/e/be/ > > Yes > > > Definition given in Section 4.1 is broader than one in the Introduction. > > Personally I like the latter better though I think that it can be > expanded > > to include MIPs on bi-directional associated LSP that are on forward and > > reverse direction of it. > > I think it is the same definition. > See the paragraph quoted above and compare with: > - The node in loopback mode must be on both the forward and return > paths. This possible for all MEPs and MIPs on a co-routed > bidirectional LSP, PW, or MPLS Section, but is only > possible on for MEPs on associated bidirectional LSPs, PW, > or MPLS Sections. > ...which seems to exclude the MIPs on assoc bidir as you say. > > > Section 4.1, s/LSPs, PW,/LSPs, PWs,/ > > Yes > > > Section 6.2 I think that UnLocking implies that a management process > > must send Unlocked command on both MEPs. In previous version > > absence of LI OAM for 3.5 times of Refresh Timer would have unlocked > > the transport path. The old definition of UnLock procedure was missing > > the fact that LI messages would not be delivered past LB but the new > > one makes it exclusive function of NMS or management plane. Is that > > desired? > > I think that you have highlighted one of the problems with the previous > version. > It was confusing! > > However, absence of LI would NOT have unlocked a MEP when a lock command > had > previously been issued to that MEP. > > From the old section 5.2 > A MEP would unlock transport path and put it back to service if and > only if there is no management request to lock the path and it is not > receiving in-band LI messages. > > A MEP is unlocked when there is no management request to Lock and no > LI OAM messages are received. > > The old document did also mention that LI might go AWOL and said in Section > 4: > LI > messages may be lost during looping or maintenance operations, thus > locking both ends is required, before such operations occur. > > I don't believe the new version has made any functional change. > > > Section 6.2 have changed how Refresh Timer used. Previous versions > > based UnLocking on Refresh Timer while now it is used to schedule > > turning a transport path back to service after it was explicitly > UnLocked. > > As above, I don't believe the new version has changed what was described, > however... > > > I'll note that service could not be restored faster than in 3.5 seconds > according > > to described procedure. Is that desired behavior? > > That is a good question for the WG. It was my assumption (from the previous > revision) that rapid unlocking and turn-up was not a requirement or it > would > have been included. > > If the WG now wants to include it, it will need to examine the use of an > unlock > OAM message. This could be done using a new message or a flag on the > existing > lock message. It could be achieved by tweaking this document or introducing > a > new document. > GIM>> I'd support explicit UnLock OAM message. I think that it is required if LI/LB expected to work in heterogeneous network (without defined UnLock message or flag request to UnLock is proprietary, in my view). > > Cheers, > Adrian > > > > --20cf307f37c2919f6d04ae803336 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Adrian,
greatly appreciate your kind consideration of my notes. I'= ;ve in-lined mine and tagged with GIM>>

Regards,
Greg
On Tue, Oct 4, 2011 at 2:24 PM, Adrian Farrel = <adrian@olddog.= co.uk> wrote:
Hi Greg,

Thanks for reading. Let me answer since a lot of the text was mine.

> I couldn't find Table of Contents in this version.

I guess Loa and I can disagree :-)
There are about 8 pages of real text in the document, not enough for a ToC = IMHO
GIM>> I'm OK either way

> Introduction, third para.
> Applicability of the Loopback is limited, comparing to previous versio= ns,
> to bi-directional co-routed LSP, PW and MPLS Section. I agree that
> statement of applicability in previous versions was bit too cumbersome=
> but this one excludes bi-directional associated LSP at all. I think th= at
Loopback
> =A0can be used on this construct at MIP that are on forward and revers= e
direction
> of given bi-directional associated MPLS-TP LSP. And I think that MPLS = Section
> is not necessarily a bi-directional co-routed object.

Reading too fast?
GIM>> Yep, sorry, cognit= ive filter ;)
GIM>> But then PW and MPLS Section have been referre= d twice - after co-routed LSP, then after associated LSP. Or intention was = to apply co-routed and associated to PW and MPLS Section? Would making the = last sentence to "It can also be applied at a MEP on an associated bid= irectional LSP" be sufficient? But still, MIPs that are on forward and= reverse direction of an associated bi-directional LSP are excluded. I beli= eve that previous versions tried to include such MIPs since these are requi= red to be aware of directions and their correlation. Is this change intenti= onal?

The bullet says...

=A0 - The loopback function allows an operator to set a specific node on
=A0 =A0 a transport path into loopback mode such t= hat it returns all
=A0 =A0 received data. Loopback can be applied at a Maintenance Enti= ty
=A0 =A0 Group End Point (MEP) or a Maintenance Entity Group Intermediate =A0 =A0 Point (MIP) on a co-routed bidirectional LSP, PW or MPLS
=A0 =A0 Section. It can also be applied at a MEP on an associated
=A0 =A0 bidirectional LSP, PW or MPLS Section.

That seems to cover exactly the same cases (including associated bidir) as = in
the previous version.

> p.3, third para though "despatch - a less common spelling of disp= atch"
> might consider 's/despatch/dispatch/'

Shall we let the RFC Editor worry about differences between UK and US= English?
"despatch. Same as dispatch" - Chambers 20th Century Dictionary

> Section 3, last para on p.3, s/PW/PWs/

yes

> Section 4, third para s/receiving MEP/receiving MP/ (MP - MEG Point) > or consider s/receiving MEP/MP/ since text in the sentence refers to i= t
> being in the loopback state.

Good catch.
Not sure if "MP" is known term.
Can we say "receiving MEP or MIP" ?
GIM>&= gt; Works for me

> Section 4, p.4, second to last para. I think that management plane
> sets in or requests Loopback on specific MP but not performs it.

The two sentences in this paragraph are directly copied from the prec= ious
revision with the only change to drop "MUST" to lower case.

Not sure what to say here since the WG clearly agreed to this text before.<= br> I think the intention was to say that a control plane is not required in or= der
to achieve loopback.
GIM>> What if the first sen= tence says:
A management plane can be too used to set a MEP or MIP along= a transport path in Loopback.

> Section 4.1, first bullet s/e/be/

Yes

> Definition given in Section 4.1 is broader than one in the Introductio= n.
> Personally I like the latter better though I think that it can be expa= nded
> to include MIPs on bi-directional associated LSP that are on forward a= nd
> reverse direction of it.

I think it is the same definition.
See the paragraph quoted above and compare with:
=A0 - The node in loopback mode must be on both the forward and return
=A0 =A0 paths. This possible for all MEPs and MIPs on a co-routed
=A0 =A0 bidirectional LSP, PW, or MPLS Section, but is only
=A0 =A0 possible on for MEPs on associated bidirectional LSPs, PW,
=A0 =A0 or MPLS Sections.
...which seems to exclude the MIPs on assoc bidir as you say.

> Section 4.1, s/LSPs, PW,/LSPs, PWs,/

Yes

> Section 6.2 I think that UnLocking implies that a management process > must send Unlocked command on both MEPs. In previous version
> absence of LI OAM for 3.5 times of Refresh Timer would have unlocked > the transport path. The old definition of UnLock procedure was missing=
> the fact that LI messages would not be delivered past LB but the new > one makes it exclusive function of NMS or management plane. Is that > desired?

I think that you have highlighted one of the problems with the previo= us version.
It was confusing!

However, absence of LI would NOT have unlocked a MEP when a lock command ha= d
previously been issued to that MEP.

>From the old section 5.2
=A0 A MEP would unlock transport path and put it back to service if and =A0 only if there is no management request to lock the path and it is not<= br> =A0 receiving in-band LI messages.

=A0 A MEP is unlocked when there is no management request to Lock and no =A0 LI OAM messages are received.

The old document did also mention that LI might go AWOL and said in Section= 4:
=A0 LI
=A0 messages may be lost during looping or maintenance operations, thus =A0 locking both ends is required, before such operations occur.

I don't believe the new version has made any functional change.

> Section 6.2 have changed how Refresh Timer used. Previous versions
> based UnLocking on Refresh Timer while now it is used to schedule
> turning a transport path back to service after it was explicitly UnLoc= ked.

As above, I don't believe the new version has changed what was de= scribed,
however...

> I'll note that service could not be restored faster than in 3.5 se= conds
according
> to described procedure. Is that desired behavior?

That is a good question for the WG. It was my assumption (from the pr= evious
revision) that rapid unlocking and turn-up was not a requirement or it woul= d
have been included.

If the WG now wants to include it, it will need to examine the use of an un= lock
OAM message. This could be done using a new message or a flag on the existi= ng
lock message. It could be achieved by tweaking this document or introducing= a
new document.
GIM>> I'd support explicit UnL= ock OAM message. I think that it is required if LI/LB expected to work in h= eterogeneous network (without defined UnLock message or flag request to UnL= ock is proprietary, in my view).

Cheers,
Adrian




--20cf307f37c2919f6d04ae803336-- From alessandro.dalessandro@telecomitalia.it Wed Oct 5 02:35:17 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0587B21F8B89; Wed, 5 Oct 2011 02:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 Q3O2sXrTpiWR; Wed, 5 Oct 2011 02:35:16 -0700 (PDT) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id C5B9721F8B80; Wed, 5 Oct 2011 02:35:15 -0700 (PDT) Received: from grfhub703rm001.griffon.local (10.19.3.10) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 5 Oct 2011 11:38:21 +0200 Received: from GRFMBX702RM001.griffon.local ([10.19.3.20]) by grfhub703rm001.griffon.local ([10.19.9.236]) with mapi; Wed, 5 Oct 2011 11:38:16 +0200 From: D'Alessandro Alessandro Gerardo To: "adrian@olddog.co.uk" , "mpls@ietf.org" , "ietf@ietf.org" Date: Wed, 5 Oct 2011 11:38:14 +0200 Thread-Topic: [mpls] FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Thread-Index: Acx8l1YYj9HbI/Z0R5SPu67gvz0yyQGo2lvA Message-ID: References: <081e01cc7c97$588726e0$099574a0$@olddog.co.uk> In-Reply-To: <081e01cc7c97$588726e0$099574a0$@olddog.co.uk> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 09:35:17 -0000 Dear all, I do not support. Basically I think it is superfluous dedicate an RFC to state it is better h= aving one standard instead of two ones or many... for sure the lower are th= e variants the better is for the industry (one is the ideal). When two or more standards or de-facto standards exist it is because the pr= oblem they solve is not exactly the same, the way they solve the problem is= optimized for different environments/boundary conditions (more efficient, = more effective, etc). Therefore a single solution does not necessarily meet= the different market requirements. It is fundamental to enter into the problem's details before making conside= ration about the best way to proceed (one solution, two solutions, multiple= solutions) whilst the document clearly declares it does not want to make a= ny technical evaluations. After more than three years of debates within the IETF and major unresolved= technical concerns risen from some transport operators, the existence of t= his draft is by itself the sure sign that MPLS-TP OAM is a case where a sin= gle solution has not be found to meet all the different market requirements= . Otherwise, why are we still discussing about it....? Therefore we must be realistic and the lessons learned from the past should= guide our decisions: if a solution cannot be found for satisfying all the = requirements it is better to have two standards and let the market decide h= ow to exploit them. Are we really sure the cost(many) / benefit (none) ana= lysis done in section 7.5 is realistic? Best regards, Alessandro ------------------------------------------------------------------ Telecom Italia Alessandro D'Alessandro Transport Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -----Messaggio originale----- Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di Adria= n Farrel Inviato: luned=EC 26 settembre 2011 23:58 A: mpls@ietf.org Oggetto: [mpls] FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Inf= ormational RFC MPLS Working Group, Please be aware of the IETF last call as shown below. The document was pres= ented for publication as an individual RFC with IETF consensus and AD spons= orship. This draft is clearly close and relevant to the work you do, but after disc= ussing with the chairs I came to the conclusion that it does not comment on= the technical or process decisions of the MPLS working groups, and it does= not attempt to make any technical evaluations or definitions within the sc= ope of the MPLS working group. It is more of a philosophical analysis of th= e way the IETF approaches the "two solutions" problem with special referenc= e to MPLS-TP OAM. Thus, I am accepting the document as AD Sponsored rather than running it th= rough the MPLS working group. My reasoning is that the working group has go= t plenty to do working on technical issues without being diverted into wide= r IETF philosophy. As an AD Sponsored I-D it is subject to a four week IETF last call. That is= plenty of opportunity for everyone to comment and express their views. Ple= ase send your comments to the IETF mailing list as described below, or (in = exceptional circumstances) direct to the IESG. Thanks, Adrian > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of The IESG > Sent: 26 September 2011 20:43 > To: IETF-Announce > Subject: Last Call: > (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to > Informational RFC > > > The IESG has received a request from an individual submitter to > consider the following document: > - 'The Reasons for Selecting a Single Solution for MPLS-TP OAM' > as an > 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 2011-10-24. 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 > > The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology > for use in transport network deployments. That is, MPLS-TP is a set > of functions and features selected from the wider MPLS toolset and > applied in a consistent way to meet the needs and requirements of > operators of packet transport networks. > > During the process of development of the profile, additions to the > MPLS toolset have been made to ensure that the tools available met > the requirements. These additions were motivated by MPLS-TP, but form > part of the wider MPLS toolset such that any of them could be used in > any MPLS deployment. > > One major set of additions provides enhanced support for Operations, > Administration, and Maintenance (OAM). This enables fault management > and performance monitoring to the level needed in a transport > network. Many solutions and protocol extensions have been proposed to > address these OAM requirements, and this document sets out the > reasons for selecting a single, coherent set of solutions for > standardization. > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerati > ons/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerati > ons/ > > > No IPR declarations have been submitted directly on this I-D. > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From stbryant@cisco.com Wed Oct 5 03:21:24 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4131521F8B6D; Wed, 5 Oct 2011 03:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.409 X-Spam-Level: X-Spam-Status: No, score=-106.409 tagged_above=-999 required=5 tests=[AWL=-3.810, 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 YDvMpLU+K5jn; Wed, 5 Oct 2011 03:21:23 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 14B9921F8B67; Wed, 5 Oct 2011 03:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1198; q=dns/txt; s=iport; t=1317810271; x=1319019871; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=xk66lul7F/9UBw5CbaLMelER7bA2fclyyRCyqavopVs=; b=iyQyD7slkZt6LnaLoZEI6opvwUO+lUtAcxEBP/qUTvbJQmSgwPKkTneN Xz0+xvyhuYzyAVvOCgwy8SrrKYOlvSW1fVTwg6RXlr+aIGQeD7vuu/f3Y kKlz/i6vTPb1Z2xYuFeVMdg5Vy0WB5MW3gkOFGe64QMVTooVoyBLzskWr U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIMvjE6Q/khM/2dsb2JhbABCqBCBBYFTAQEBBBIBAgEiPAQBEAsYCRYECwkDAgECATwJBg0BBwEBEAcHh2GZDAGDKA8BmlGHKQSTbZFF X-IronPort-AV: E=Sophos;i="4.68,490,1312156800"; d="scan'208";a="360369" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 05 Oct 2011 10:24:29 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p95AOTgO001535; Wed, 5 Oct 2011 10:24:29 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p95AORQM026936; Wed, 5 Oct 2011 11:24:28 +0100 (BST) Message-ID: <4E8C305B.6060106@cisco.com> Date: Wed, 05 Oct 2011 11:24:27 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "D'Alessandro Alessandro Gerardo" References: <081e01cc7c97$588726e0$099574a0$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ietf@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 10:21:24 -0000 On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote: > major unresolved technical concerns Alessandro Please can I suggest that you write an internet draft detailing these "major unresolved technical concerns" so that we can all understand them. Such a draft needs to be technical, and describe the actions that the network operator is unable to perform, or the fault cases that they are unable to diagnose using the OAM defined in the IETF RFCs, or late stage WG drafts. Alternatively if you are referring to a bug in the MPLS-TP OAM protocols, you need to tell the community what it is. I believe that this request has been made a number of times, in various forums, and, as far as I know, no document has yet been produced. An argument of the form "you must standardize what I want" will not fly. What is needed is a very clear technical definition of the issue(s). When we have the "major unresolved technical concerns" on the table, we will be in a position to determine the best disposition of those issues. Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From adrian@olddog.co.uk Wed Oct 5 03:40:21 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD9821F8C44 for ; Wed, 5 Oct 2011 03:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sv15LPNwrcwU for ; Wed, 5 Oct 2011 03:40:20 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 29D1F21F8AD8 for ; Wed, 5 Oct 2011 03:40:20 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p95AhNP3009828; Wed, 5 Oct 2011 11:43:25 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p95AhK53009799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Oct 2011 11:43:22 +0100 From: "Adrian Farrel" To: "'Greg Mirsky'" References: <042101cc82dc$0da49e50$28eddaf0$@olddog.co.uk> In-Reply-To: Date: Wed, 5 Oct 2011 11:43:19 +0100 Message-ID: <04da01cc834b$998ad460$cca07d20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJn5Gr+JLDeCP406LeaiwX/KAN2WwIXozXAAlw9XK+UEybmUA== Content-Language: en-gb Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-li-lb-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 10:40:21 -0000 Hi again Greg, We are converging. I've cut out the bits where we have reached conclusions. >>> Introduction, third para. >>> Applicability of the Loopback is limited, comparing to previous = versions, >>> to bi-directional co-routed LSP, PW and MPLS Section. I agree that >>> statement of applicability in previous versions was bit too = cumbersome >>> but this one excludes bi-directional associated LSP at all. I think = that >>> Loopback=A0can be used on this construct at MIP that are on forward=20 >>> and reverse direction of given bi-directional associated MPLS-TP = LSP.=20 >>> And I think that MPLS Section is not necessarily a bi-directional = co- >>> routed object. > > GIM>> But then PW and MPLS Section have been referred twice -=20 > after co-routed LSP, then after associated LSP. Or intention was to = apply > co-routed and associated to PW and MPLS Section? Would making the=20 > last sentence to "It can also be applied at a MEP on an associated > bidirectional LSP" be sufficient? But still, MIPs that are on forward > and reverse direction of an associated bi-directional LSP are = excluded.=20 > I believe that previous versions tried to include such MIPs since = these > are required to be aware of directions and their correlation. Is this > change intentional? You're right. I mangled the original text in my enthusiasm to have = something I could parse :-) I think there are two issues: 1. extraneous mention of PW and Section in the last sentence OLD (v7) - The loopback function allows an operator to set a specific node on a transport path into loopback mode such that it returns all received data. Loopback can be applied at a Maintenance Entity Group End Point (MEP) or a Maintenance Entity Group Intermediate Point (MIP) on a co-routed bidirectional LSP, PW or MPLS Section. It can also be applied at a MEP on an associated bidirectional LSP, PW or MPLS Section. NEW - The loopback function allows an operator to set a specific node on a transport path into loopback mode such that it returns all received data. Loopback can be applied at a Maintenance Entity Group End Point (MEP) or a Maintenance Entity Group Intermediate Point (MIP) on a co-routed bidirectional LSP, on a PW, or on an MPLS Section. It can also be applied at a MEP on an associated bidirectional LSP. END 2. Discussion of loopback at "coincident" MIPs on associated = bidirectional LSPs. This is a question for the WG not for me (I am only trying to provide an editorial service!). Would you mind raising this as a separate thread so that the WG spot and = debate the issue? >>> Section 4, p.4, second to last para. I think that management plane >>> sets in or requests Loopback on specific MP but not performs it. >> >> The two sentences in this paragraph are directly copied from the >> previous revision with the only change to drop "MUST" to lower case. >> >> Not sure what to say here since the WG clearly agreed to this text >> before. I think the intention was to say that a control plane is not >> required in order to achieve loopback. > >GIM>> What if the first sentence says: > > A management plane can be too used to set a MEP or MIP along a > transport path in Loopback.=20 Well, I don't like "too" because this document doesn't actually mention = any way to set loopback using the control plane. So what about: OLD (v7) The Loopback can be performed using a management plane. Management plane must ensure that the two MEPs are locked before performing the loopback function. NEW The management plane can be used to configure the Loopback function. The management plane must ensure that the two MEPs are locked before performing the loopback function. END >>> Definition given in Section 4.1 is broader than one in the = Introduction. >>> Personally I like the latter better though I think that it can be = expanded >>> to include MIPs on bi-directional associated LSP that are on forward = and >>> reverse direction of it. >> >> I think it is the same definition. >> See the paragraph quoted above and compare with: >>=A0 - The node in loopback mode must be on both the forward and return >>=A0 =A0 paths. This possible for all MEPs and MIPs on a co-routed >>=A0 =A0 bidirectional LSP, PW, or MPLS Section, but is only >>=A0 =A0 possible on for MEPs on associated bidirectional LSPs, PW, >>=A0 =A0 or MPLS Sections. >> ...which seems to exclude the MIPs on assoc bidir as you say. Same two issues: 1. OLD (v7) - The node in loopback mode must be on both the forward and return paths. This possible for all MEPs and MIPs on a co-routed bidirectional LSP, PW, or MPLS Section, but is only possible on for MEPs on associated bidirectional LSPs, PW, or MPLS Sections. NEW - The node in loopback mode must be on both the forward and return paths. This possible for all MEPs and MIPs on a co-routed bidirectional LSP, on a PW, or on an MPLS Section, but is only possible on for MEPs on associated bidirectional LSPs. END 2. You will raise associated bidir MIPs on the mailing list >>> I'll note that service could not be restored faster than in 3.5 = seconds >>> according to described procedure. Is that desired behavior? >> >> That is a good question for the WG. It was my assumption (from the >> previous revision) that rapid unlocking and turn-up was not a=20 >> requirement or it would have been included. >> >> If the WG now wants to include it, it will need to examine the use of = an >> unlock OAM message. This could be done using a new message or a flag >> on the existing lock message. It could be achieved by tweaking this >> document or introducing a new document. > > GIM>> I'd support explicit UnLock OAM message. I think that it is = required > if LI/LB expected to work in heterogeneous network (without defined > UnLock message or flag request to UnLock is proprietary, in my view). OK. Well, this is another technical, not editorial, change. So I am not really in a position to discuss it. Would you mind creating a separate thread for this one as well? That way the WG can decide what it wants to do. Many thanks for the thorough and thoughtful review. Adrian From Alexander.Vainshtein@ecitele.com Wed Oct 5 03:58:29 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389C021F8C67; Wed, 5 Oct 2011 03:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.436 X-Spam-Level: X-Spam-Status: No, score=-4.436 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfAaILXAVgkL; Wed, 5 Oct 2011 03:58:28 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id EA7EC21F8C66; Wed, 5 Oct 2011 03:58:27 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-15.tower-21.messagelabs.com!1317812484!53241849!3 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.4.1; banners=-,-,- Received: (qmail 8705 invoked from network); 5 Oct 2011 11:01:34 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-15.tower-21.messagelabs.com with SMTP; 5 Oct 2011 11:01:34 -0000 X-AuditID: 93eaf2e7-b7c60ae0000066f0-b9-4e8c47116e0c Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 5F.CC.26352.1174C8E4; Wed, 5 Oct 2011 14:01:21 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Wed, 5 Oct 2011 13:01:31 +0200 From: Alexander Vainshtein To: D'Alessandro Alessandro Gerardo Date: Wed, 5 Oct 2011 13:01:30 +0200 Thread-Topic: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Thread-Index: AcyDSP5l9qW6V77qTmetb2IswOgXmwAAhZ2w Message-ID: References: <081e01cc7c97$588726e0$099574a0$@olddog.co.uk> <4E8C305B.6060106@cisco.com> In-Reply-To: <4E8C305B.6060106@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMJsWRmVeSWpSXmKPExsUy+dWnL7qC7j1+Bp/WW1qcWHaYxeLZxvks Fu1dT9ktbi1dyWpx7ukcRgdWjym/N7J6LFnyk8mj5Vwvu8eafT9YAliiGhhtEvPy8ksSS1IV UlKLk22VAooyyxKTK5UUMlNslQyVFApyEpNTc1PzSmyVEgsKUvNSlOy4FDCADVBZZp5Cal5y fkpmXrqtkmewv66FhamlrqGSnZqyobE1V0hGZrFCqm5uYmaOQm5qcXFieqoCUCRhC3PGxl0P GAs2i1Rc+X2GtYFxvUAXIyeHhICJxMIpjUwQtpjEhXvr2boYuTiEBPYySrz4OJ8JwpnMKNH+ 7DZYFZuArcSm1XeBqjg4RAR8JSaclgOpYRZYxSjRcPMmG0gNi4CKxOo9/1hBEsIC6xkleu+t YQFxRAQ2MEo8mvWMBaRKRMBIYsOS32AdvAKBEgu/LgSzhQSWMkpM3qYNsoFTQFPi+QRdkDAj 0HnfT60BO4JZQFzi1pP5UGcLSCzZc54ZwhaVePkYZDFIvajEnfb1jBD1OhILdn9ig7C1JZYt fM0MsVZQ4uTMJywQvZISB1fcYJnAKD4LyYpZSNpnIWmfhaR9ASPLKkbRzJyCkqTcdANDvdTk zJLUnFS95PzcTYyQ5PN8B+Ov+SqHGAU4GJV4eDeEd/sJsSaWFVfmHmKU5GBSEuWdydjjJ8SX lJ9SmZFYnBFfVJqTWnyIUYKDWUmEd/OHLj8h3pTEyqrUonyYlAUwmCcyS3En5wMTal5JvLGB AQpHSZz3afIbXyGBdGCyy05NLUgtgmmV4eBQkuC1ZwbaKFiUmp5akZaZU4KQZuLgBNnMA7TZ CqSGt7ggMbc4Mx0if4pRUUqc1x8kIQCSyCjNg+sF5ZX6////v2IUB/pTmNcGpIoHmJPgul8B DWYCGpx6txNkMDBLwKWkGhgPhEkvvfT51TmpN24hsh4GRRYvrc28JZQlbz3cvIHJePpmHaOd PwwW2Jhvru69fSBSZMOeN/tXO6ze1D7v0+R5KtpzfIusbnofYdW+U3W9XODF6/V6N+6teCY9 xcghqfkRk0KDcKI4g3dH6foVX7P3/GU+mjctwcNFU3zuv4+KR17f3tDq8SZBiaU4I9FQi7mo OBEAoIWOPwYEAAA= Cc: "mpls@ietf.org" , "ietf@ietf.org" , "stbryant@cisco.com" Subject: Re: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 10:58:29 -0000 Alessandro, Stewart and all, I concur with Stewart: please write a draft detailing your major technical c= oncerns. I'd like to add a quote from Malcolm's presentation at the IETF meeting in P= rague: "Differences are close to invisible at the level of the requi= rements in RFC5860". Just to remind you that RFC 5680 is the MPLS-TP OAM requirements document. Malcolm has also said: "Many of the issues only become apparent when the protocol and equipment be= havior is explored" but, AFAIK, these issues have never been explicitly brought for the consider= ation. My 2c, Sasha > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Stewart Bryant > Sent: Wednesday, October 05, 2011 12:24 PM > To: D'Alessandro Alessandro Gerardo > Cc: ietf@ietf.org; mpls@ietf.org > Subject: Re: [mpls] R: FW: Last Call: considerations-01.txt> (The Reasons for Selecting a Single Solution for > MPLS-TP OAM) to Informational RFC > > On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote: > > major unresolved technical concerns > > Alessandro > > Please can I suggest that you write an internet draft detailing > these "major unresolved technical concerns" so that we > can all understand them. > > Such a draft needs to be technical, and describe the actions > that the network operator is unable to perform, or the fault > cases that they are unable to diagnose using the OAM defined > in the IETF RFCs, or late stage WG drafts. > > Alternatively if you are referring to a bug in the MPLS-TP > OAM protocols, you need to tell the community what it is. > > I believe that this request has been made a number of > times, in various forums, and, as far as I know, no document > has yet been produced. > > An argument of the form "you must standardize what I want" > will not fly. What is needed is a very clear technical definition > of the issue(s). > > When we have the "major unresolved technical concerns" > on the table, we will be in a position to determine the best > disposition of those issues. > > Stewart > > > > > > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From larryli888@yahoo.com.cn Wed Oct 5 04:48:05 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D63421F8CEC for ; Wed, 5 Oct 2011 04:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 gPgPLJrNsgP3 for ; Wed, 5 Oct 2011 04:48:04 -0700 (PDT) Received: from web15608.mail.cnb.yahoo.com (web15608.mail.cnb.yahoo.com [202.165.102.62]) by ietfa.amsl.com (Postfix) with SMTP id 1DF3621F8CF0 for ; Wed, 5 Oct 2011 04:48:02 -0700 (PDT) Received: (qmail 64746 invoked by uid 60001); 5 Oct 2011 11:51:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.cn; s=s1024; t=1317815467; bh=/ZBcYTYmS4dVQECOXJviCxcJov5f0jYLNGSJy0OXtbs=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=q6zHBLodxZBJkXdBIonqpI9eNtUtsskyc8e2/9Q2sGpuza93wLflvweSzPdiSp+heHLuQ/dQCBzqe2RnPgcBsrPBeFMaJLa6CGBV+gPrAwr5fe33chRu9JGWCk0L+Mw6DH2eaVbV1HaQ7fjSVW6JNRZTuZ+AL7TyQA1xQixEILY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mYo3S05uSlWmpd6pHY8GxEKO4pUu1Ds4/FjDlIaMbjcds34rG/ozxn6QlnU4Z3lknK7JuplKKK7ebvM+lbgkSEQOgVYe1VJ5Gm19sm3VTv5pmKOyApmFYRZjKnzajx+1LlDT+VFWWLT5QPaRURyGK5EiY56mQUn9MED6Ei8YB1E=; X-YMail-OSG: dnR7CTgVM1mcIo4_4ie2GKl2OgDeFut6rhebwV2uqNHxucN 6JDmDMlDv.MnIqOg1xBQLk54NiiBoAY375_aPelKhsTdtb375tmN1dE4MkdW 8jBssyrAezI3UlzJw4wHbALD601t89MD.WuB59OB.xUiI4usQ1fRSOhcUhKt ZaU5QsL7QYVkd0PHJ98hoNfjv65hNpjqef6jAlO0HlSGLJ9a4T9pkOazJoIF yIkLLkXsE2ayx4d9JltCjW5znAkOBXMRBFS5SHpmb..B0.7e4.bCPD9.NkQD QvPPqGtKFYVyvXUcUloJC76nT43EBVBeGahDY95H6LsTnGENLTAO2rUIN.xk UD0A1ErgzU1U8w_WUFsfbD5toB2lG5dF7KvPkYFK.dtJUlQ-- Received: from [116.92.9.130] by web15608.mail.cnb.yahoo.com via HTTP; Wed, 05 Oct 2011 19:51:06 CST X-Mailer: YahooMailClassic/14.0.7 YahooMailWebService/0.8.114.317681 Message-ID: <1317815466.64710.YahooMailClassic@web15608.mail.cnb.yahoo.com> Date: Wed, 5 Oct 2011 19:51:06 +0800 (CST) From: Larry To: "adrian@olddog.co.uk" , "mpls@ietf.org" , "ietf@ietf.org" , D'Alessandro Alessandro Gerardo In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: [mpls] =?utf-8?b?5Zue5aSN77yaICBSOiBGVzogTGFzdCBDYWxsOiA8ZHJhZnQt?= =?utf-8?q?sprecher-mpls-tp-oam-considerations-01=2Etxt=3E_=28The_Reasons_?= =?utf-8?q?for_Selecting_a_Single_Solution_for_MPLS-TP_OAM=29_to_Informati?= =?utf-8?q?onal_RFC?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 11:48:05 -0000 Dear all, So many multiple solution cases just show the way that the world and t= echnology works. Killing a solution roughly brings more damage to the indus= try. Section 3.6 discusses the elements of the choice of solutions. Current= application and deployment should be considered. In China Mobile, more tha= n 330,000 PTN box are/will based on G.8113.1. TDM PW gives a good example. G.8113.1 based OAM is relative simple and= mature and widely deployed and should be the standard. Best regards, Han Li --- 11=E5=B9=B410=E6=9C=885=E6=97=A5=EF=BC=8C=E5=91=A8=E4=B8=89, D'Alessand= ro Alessandro Gerardo =E5=86=99= =E9=81=93=EF=BC=9A > =E5=8F=91=E4=BB=B6=E4=BA=BA: D'Alessandro Alessandro Gerardo > =E4=B8=BB=E9=A2=98: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPL= S-TP OAM) to Informational RFC > =E6=94=B6=E4=BB=B6=E4=BA=BA: "adrian@olddog.co.uk" ,= "mpls@ietf.org" , "ietf@ietf.org" > =E6=97=A5=E6=9C=9F: 2011=E5=B9=B410=E6=9C=885=E6=97=A5,=E5=91=A8=E4=B8=89= ,=E4=B8=8B=E5=8D=885:38 > Dear all, > I do not support. >=20 > Basically I think it is superfluous dedicate an RFC to > state it is better having one standard instead of two ones > or many... for sure the lower are the variants the better is > for the industry (one is the ideal). >=20 > When two or more standards or de-facto standards exist it > is because the problem they solve is not exactly the same, > the way they solve the problem is optimized for different > environments/boundary conditions (more efficient, more > effective, etc). Therefore a single solution does not > necessarily meet the different market requirements. >=20 > It is fundamental to enter into the problem's details > before making consideration about the best way to proceed > (one solution, two solutions, multiple solutions) whilst the > document clearly declares it does not want to make any > technical evaluations. >=20 > After more than three years of debates within the IETF and > major unresolved technical concerns risen from some > transport operators, the existence of this draft is by > itself the sure sign that MPLS-TP OAM is a case where a > single solution has not be found to meet all the different > market requirements. Otherwise, why are we still discussing > about it....? >=20 > Therefore we must be realistic and the lessons learned from > the past should guide our decisions: if a solution cannot be > found for satisfying all the requirements it is better to > have two standards and let the market decide how to exploit > them. Are=C2=A0 we really sure the cost(many) / benefit > (none) analysis done in section 7.5 is realistic? >=20 > Best regards, > Alessandro >=20 > ------------------------------------------------------------------ > Telecom Italia > Alessandro D'Alessandro > Transport Innovation > Via Reiss Romoli, 274 - 10148 Torino > phone:=C2=A0 +39 011 228 5887 > mobile: +39 335 766 9607 > fax: +39 06 418 639 07 >=20 > -----Messaggio originale----- > Da: mpls-bounces@ietf.org > [mailto:mpls-bounces@ietf.org] > Per conto di Adrian Farrel > Inviato: luned=C3=AC 26 settembre 2011 23:58 > A: mpls@ietf.org > Oggetto: [mpls] FW: Last Call: > > (The Reasons for Selecting a Single Solution for MPLS-TP > OAM) to Informational RFC >=20 > MPLS Working Group, >=20 > Please be aware of the IETF last call as shown below. The > document was presented for publication as an individual RFC > with IETF consensus and AD sponsorship. >=20 > This draft is clearly close and relevant to the work you > do, but after discussing with the chairs I came to the > conclusion that it does not comment on the technical or > process decisions of the MPLS working groups, and it does > not attempt to make any technical evaluations or definitions > within the scope of the MPLS working group. It is more of a > philosophical analysis of the way the IETF approaches the > "two solutions" problem with special reference to MPLS-TP > OAM. >=20 > Thus, I am accepting the document as AD Sponsored rather > than running it through the MPLS working group. My reasoning > is that the working group has got plenty to do working on > technical issues without being diverted into wider IETF > philosophy. >=20 > As an AD Sponsored I-D it is subject to a four week IETF > last call. That is plenty of opportunity for everyone to > comment and express their views. Please send your comments > to the IETF mailing list as described below, or (in > exceptional circumstances) direct to the IESG. >=20 > Thanks, > Adrian >=20 > > -----Original Message----- > > From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce- > > bounces@ietf.org] > On Behalf Of The IESG > > Sent: 26 September 2011 20:43 > > To: IETF-Announce > > Subject: Last Call: > > > (The Reasons for Selecting a Single Solution for > MPLS-TP OAM) to > > Informational RFC > > > > > > The IESG has received a request from an individual > submitter to > > consider the following document: > > - 'The Reasons for Selecting a Single Solution for > MPLS-TP OAM' > >=C2=A0=C2=A0=C2=A0 > as an > > 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 2011-10-24. 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 > > > >=C2=A0 =C2=A0 The MPLS Transport Profile (MPLS-TP) is a > profile of MPLS technology > >=C2=A0 =C2=A0 for use in transport network deployments. > That is, MPLS-TP is a set > >=C2=A0 =C2=A0 of functions and features selected from > the wider MPLS toolset and > >=C2=A0 =C2=A0 applied in a consistent way to meet the > needs and requirements of > >=C2=A0 =C2=A0 operators of packet transport networks. > > > >=C2=A0 =C2=A0 During the process of development of the > profile, additions to the > >=C2=A0 =C2=A0 MPLS toolset have been made to ensure > that the tools available met > >=C2=A0 =C2=A0 the requirements. These additions were > motivated by MPLS-TP, but form > >=C2=A0 =C2=A0 part of the wider MPLS toolset such that > any of them could be used in > >=C2=A0 =C2=A0 any MPLS deployment. > > > >=C2=A0 =C2=A0 One major set of additions provides > enhanced support for Operations, > >=C2=A0 =C2=A0 Administration, and Maintenance (OAM). > This enables fault management > >=C2=A0 =C2=A0 and performance monitoring to the level > needed in a transport > >=C2=A0 =C2=A0 network. Many solutions and protocol > extensions have been proposed to > >=C2=A0 =C2=A0 address these OAM requirements, and this > document sets out the > >=C2=A0 =C2=A0 reasons for selecting a single, coherent > set of solutions for > >=C2=A0 =C2=A0 standardization. > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerati > > ons/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerati > > ons/ > > > > > > No IPR declarations have been submitted directly on > this I-D. > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 > Questo messaggio e i suoi allegati sono indirizzati > esclusivamente alle persone indicate. La diffusione, copia o > qualsiasi altra azione derivante dalla conoscenza di queste > informazioni sono rigorosamente vietate. Qualora abbiate > ricevuto questo documento per errore siete cortesemente > pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. >=20 > This e-mail and any attachments is confidential and may > contain privileged information intended for the addressee(s) > only. Dissemination, copying, printing or use by anybody > else is unauthorised. If you are not the intended recipient, > please delete this message and any attachments and advise > the sender by return e-mail, Thanks. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From yang.jian90@zte.com.cn Wed Oct 5 07:50:38 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA0121F8B90; Wed, 5 Oct 2011 07:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.743 X-Spam-Level: X-Spam-Status: No, score=-94.743 tagged_above=-999 required=5 tests=[AWL=2.252, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 NywdDxtCBmTQ; Wed, 5 Oct 2011 07:50:34 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDE521F8B77; Wed, 5 Oct 2011 07:50:33 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 46621817668700; Wed, 5 Oct 2011 22:49:42 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 92683.3450607125; Wed, 5 Oct 2011 22:53:26 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p95ErT0Z016624; Wed, 5 Oct 2011 22:53:29 +0800 (GMT-8) (envelope-from yang.jian90@zte.com.cn) In-Reply-To: <1317815466.64710.YahooMailClassic@web15608.mail.cnb.yahoo.com> To: "ietf@ietf.org" , "mpls@ietf.org" , mpls-bounces@ietf.orgLarry X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: yang.jian90@zte.com.cn Date: Wed, 5 Oct 2011 22:53:31 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-05 22:53:33 MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 X-MAIL: mse02.zte.com.cn p95ErT0Z016624 Subject: [mpls] =?gb2312?b?tPC4tDogILvYuLSjuiAgUjogRlc6IExhc3QgQ2FsbDog?= =?gb2312?b?PGRyYWZ0LXNwcmVjaGVyLW1wbHMtdHAtb2FtLWNvbnNpZGVyYXRpb25zLTAx?= =?gb2312?b?LnR4dD4gKFRoZSBSZWFzb25zIGZvciBTZWxlY3RpbmcgYSBTaW5nbGUgU29s?= =?gb2312?b?dXRpb24gZm9yIE1QTFMtVFAgT0FNKSB0byBJbmZvcm1hdGlvbmFsIFJGQw==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 14:50:38 -0000 RGVhciBBbGwsDQoNCkkgZG8gbm90IHN1cHBvcnQgZWl0aGVyLg0KDQpJbiBzZWN0aW9uIDMuNToN CklmIHR3byBNUExTIE9BTSBwcm90b2NvbHMgd2VyZSB0byBiZSBkZXBsb3llZCB3ZSB3b3VsZCBo YXZlIHRvIGNvbnNpZGVyDQp0aHJlZSBwb3NzaWJsZSBzY2VuYXJpb3M6DQoxKSBJc29sYXRpb24g b2YgdGhlIG5ldHdvcmsgaW50byB0d28gaW5jb21wYXRpYmxlIGFuZCB1bmNvbm5lY3RlZCBpc2xh bmRzLg0KDQpUd28gT0FNIHNvbHV0aW9ucyBoYXZlIGJlZW4gZGlzY3Vzc2VkIGZvciBhIGxvbmcg dGltZSBpbiBib3RoIElUVS1UIGFuZA0KSUVURi4NCkVhY2ggc29sdXRpb24gaGFzIHRoZWlyIG93 biBzdXBwb3J0ZXJzIGluY3VsZGluZyBjYXJyaWVycyBhbmQgdmVuZG9ycy4NClNvIEkgZG9uJ3Qg dGhpbmsgdGhlcmUgaXMgYW55IGludGVyd29ya2luZyBpc3N1ZSBiZXR3ZWVuIHR3byBPQU0gc29s dXRpb25zLg0KQ2FycmllciB3aWxsIHNlbGVjdCBvbmUgT0FNIHNvbHV0aW9uLCBBIG9yIEIsIGlu IHRoZWlyIG5ldHdvcmsuDQpObyBuZWVkIHRvIHNlbGVjdCBBIGFuZCBCIGF0IG9uZSBuZXR3b3Jr IGF0IHRoZSBzYW1lIHRpbWUuDQoNClJlc3BlY3QgdGhlaXIgb3duIHNlbGVjdGlvbiBhbmQgbGlz dGVuIHRvIHRoZWlyIHJlcXVpcmVtZW50cywgcGxlYXNlLg0KDQoNCkJlc3QgcmVnYXJkcywNCg0K Smlhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNCg0KDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCiAgICAgICAgICAgICBMYXJyeSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgIDxsYXJyeWxp ODg4QHlhICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQog ICAgICAgICAgICAgaG9vLmNvbS5jbj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIOaUtuS7tuS6uiANCiAgICAgICAgICAgICDlj5Hku7bkuro6ICAgICAgICAgICAg ICAgICJhZHJpYW5Ab2xkZG9nLmNvLnVrIiAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAg IG1wbHMtYm91bmNlc0BpICAgICAgICAgPGFkcmlhbkBvbGRkb2cuY28udWs+LCAibXBsc0BpZXRm Lm9yZyIgDQogICAgICAgICAgICAgZXRmLm9yZyAgICAgICAgICAgICAgICA8bXBsc0BpZXRmLm9y Zz4sICJpZXRmQGlldGYub3JnIiAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxpZXRmQGlldGYub3JnPiwgRCdBbGVzc2FuZHJvICAgICAgICAgIA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgQWxlc3NhbmRybyBHZXJhcmRvICAgICAgICAgICAg ICAgICAgICAgDQogICAgICAgICAgICAgMjAxMS0xMC0wNSAgICAgICAgICAgICA8YWxlc3NhbmRy by5kYWxlc3NhbmRyb0B0ZWxlY29taXRhbGlhLiANCiAgICAgICAgICAgICAxOTo1MSAgICAgICAg ICAgICAgICAgIGl0PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIOaKhOmAgSANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIOS4u+mimCAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFttcGxzXSDlm57lpI3vvJogIFI6 IEZXOiBMYXN0IENhbGw6ICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPGRyYWZ0LXNwcmVjaGVyLW1wbHMtdHAtb2FtLWNvbnNpZGVyYXQgDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBpb25zLTAxLnR4dD4gKFRoZSBSZWFzb25zIGZvciAgICAg ICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNlbGVjdGluZyBhIFNp bmdsZSBTb2x1dGlvbiBmb3IgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgTVBMUy1UUCBPQU0pIHRvIEluZm9ybWF0aW9uYWwgUkZDICAgICAgDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0K DQoNCkRlYXIgYWxsLA0KDQogICAgIFNvIG1hbnkgbXVsdGlwbGUgc29sdXRpb24gY2FzZXMganVz dCBzaG93IHRoZSB3YXkgdGhhdCB0aGUgd29ybGQgYW5kDQp0ZWNobm9sb2d5IHdvcmtzLiBLaWxs aW5nIGEgc29sdXRpb24gcm91Z2hseSBicmluZ3MgbW9yZSBkYW1hZ2UgdG8gdGhlDQppbmR1c3Ry eS4NCg0KICAgICBTZWN0aW9uIDMuNiBkaXNjdXNzZXMgdGhlIGVsZW1lbnRzIG9mIHRoZSBjaG9p Y2Ugb2Ygc29sdXRpb25zLiBDdXJyZW50DQphcHBsaWNhdGlvbiBhbmQgZGVwbG95bWVudCBzaG91 bGQgYmUgY29uc2lkZXJlZC4gSW4gQ2hpbmEgTW9iaWxlLCBtb3JlIHRoYW4NCjMzMCwwMDAgUFRO IGJveCBhcmUvd2lsbCBiYXNlZCBvbiBHLjgxMTMuMS4NCg0KICAgICBURE0gUFcgZ2l2ZXMgYSBn b29kIGV4YW1wbGUuIEcuODExMy4xIGJhc2VkIE9BTSBpcyByZWxhdGl2ZSBzaW1wbGUgYW5kDQpt YXR1cmUgYW5kIHdpZGVseSBkZXBsb3llZCBhbmQgc2hvdWxkIGJlIHRoZSBzdGFuZGFyZC4NCg0K DQpCZXN0IHJlZ2FyZHMsDQoNCiAgICAgICAgIEhhbiBMaQ0KDQotLS0gMTHlubQxMOaciDXml6Xv vIzlkajkuIksIEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG8NCjxhbGVzc2FuZHJvLmRh bGVzc2FuZHJvQHRlbGVjb21pdGFsaWEuaXQ+IOWGmemBk++8mg0KDQo+IOWPkeS7tuS6ujogRCdB bGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJkbw0KPGFsZXNzYW5kcm8uZGFsZXNzYW5kcm9AdGVs ZWNvbWl0YWxpYS5pdD4NCj4g5Li76aKYOiBbbXBsc10gUjogRlc6IExhc3QgQ2FsbDoNCjxkcmFm dC1zcHJlY2hlci1tcGxzLXRwLW9hbS1jb25zaWRlcmF0aW9ucy0wMS50eHQ+IChUaGUgUmVhc29u cyBmb3INClNlbGVjdGluZyBhIFNpbmdsZSBTb2x1dGlvbiBmb3IgTVBMUy1UUCBPQU0pIHRvIElu Zm9ybWF0aW9uYWwgUkZDDQo+IOaUtuS7tuS6ujogImFkcmlhbkBvbGRkb2cuY28udWsiIDxhZHJp YW5Ab2xkZG9nLmNvLnVrPiwgIm1wbHNAaWV0Zi5vcmciDQo8bXBsc0BpZXRmLm9yZz4sICJpZXRm QGlldGYub3JnIiA8aWV0ZkBpZXRmLm9yZz4NCj4g5pel5pyfOiAyMDEx5bm0MTDmnIg15pelLOWR qOS4iSzkuIvljYg1OjM4DQo+IERlYXIgYWxsLA0KPiBJIGRvIG5vdCBzdXBwb3J0Lg0KPg0KPiBC YXNpY2FsbHkgSSB0aGluayBpdCBpcyBzdXBlcmZsdW91cyBkZWRpY2F0ZSBhbiBSRkMgdG8NCj4g c3RhdGUgaXQgaXMgYmV0dGVyIGhhdmluZyBvbmUgc3RhbmRhcmQgaW5zdGVhZCBvZiB0d28gb25l cw0KPiBvciBtYW55Li4uIGZvciBzdXJlIHRoZSBsb3dlciBhcmUgdGhlIHZhcmlhbnRzIHRoZSBi ZXR0ZXIgaXMNCj4gZm9yIHRoZSBpbmR1c3RyeSAob25lIGlzIHRoZSBpZGVhbCkuDQo+DQo+IFdo ZW4gdHdvIG9yIG1vcmUgc3RhbmRhcmRzIG9yIGRlLWZhY3RvIHN0YW5kYXJkcyBleGlzdCBpdA0K PiBpcyBiZWNhdXNlIHRoZSBwcm9ibGVtIHRoZXkgc29sdmUgaXMgbm90IGV4YWN0bHkgdGhlIHNh bWUsDQo+IHRoZSB3YXkgdGhleSBzb2x2ZSB0aGUgcHJvYmxlbSBpcyBvcHRpbWl6ZWQgZm9yIGRp ZmZlcmVudA0KPiBlbnZpcm9ubWVudHMvYm91bmRhcnkgY29uZGl0aW9ucyAobW9yZSBlZmZpY2ll bnQsIG1vcmUNCj4gZWZmZWN0aXZlLCBldGMpLiBUaGVyZWZvcmUgYSBzaW5nbGUgc29sdXRpb24g ZG9lcyBub3QNCj4gbmVjZXNzYXJpbHkgbWVldCB0aGUgZGlmZmVyZW50IG1hcmtldCByZXF1aXJl bWVudHMuDQo+DQo+IEl0IGlzIGZ1bmRhbWVudGFsIHRvIGVudGVyIGludG8gdGhlIHByb2JsZW0n cyBkZXRhaWxzDQo+IGJlZm9yZSBtYWtpbmcgY29uc2lkZXJhdGlvbiBhYm91dCB0aGUgYmVzdCB3 YXkgdG8gcHJvY2VlZA0KPiAob25lIHNvbHV0aW9uLCB0d28gc29sdXRpb25zLCBtdWx0aXBsZSBz b2x1dGlvbnMpIHdoaWxzdCB0aGUNCj4gZG9jdW1lbnQgY2xlYXJseSBkZWNsYXJlcyBpdCBkb2Vz IG5vdCB3YW50IHRvIG1ha2UgYW55DQo+IHRlY2huaWNhbCBldmFsdWF0aW9ucy4NCj4NCj4gQWZ0 ZXIgbW9yZSB0aGFuIHRocmVlIHllYXJzIG9mIGRlYmF0ZXMgd2l0aGluIHRoZSBJRVRGIGFuZA0K PiBtYWpvciB1bnJlc29sdmVkIHRlY2huaWNhbCBjb25jZXJucyByaXNlbiBmcm9tIHNvbWUNCj4g dHJhbnNwb3J0IG9wZXJhdG9ycywgdGhlIGV4aXN0ZW5jZSBvZiB0aGlzIGRyYWZ0IGlzIGJ5DQo+ IGl0c2VsZiB0aGUgc3VyZSBzaWduIHRoYXQgTVBMUy1UUCBPQU0gaXMgYSBjYXNlIHdoZXJlIGEN Cj4gc2luZ2xlIHNvbHV0aW9uIGhhcyBub3QgYmUgZm91bmQgdG8gbWVldCBhbGwgdGhlIGRpZmZl cmVudA0KPiBtYXJrZXQgcmVxdWlyZW1lbnRzLiBPdGhlcndpc2UsIHdoeSBhcmUgd2Ugc3RpbGwg ZGlzY3Vzc2luZw0KPiBhYm91dCBpdC4uLi4/DQo+DQo+IFRoZXJlZm9yZSB3ZSBtdXN0IGJlIHJl YWxpc3RpYyBhbmQgdGhlIGxlc3NvbnMgbGVhcm5lZCBmcm9tDQo+IHRoZSBwYXN0IHNob3VsZCBn dWlkZSBvdXIgZGVjaXNpb25zOiBpZiBhIHNvbHV0aW9uIGNhbm5vdCBiZQ0KPiBmb3VuZCBmb3Ig c2F0aXNmeWluZyBhbGwgdGhlIHJlcXVpcmVtZW50cyBpdCBpcyBiZXR0ZXIgdG8NCj4gaGF2ZSB0 d28gc3RhbmRhcmRzIGFuZCBsZXQgdGhlIG1hcmtldCBkZWNpZGUgaG93IHRvIGV4cGxvaXQNCj4g dGhlbS4gQXJlwqAgd2UgcmVhbGx5IHN1cmUgdGhlIGNvc3QobWFueSkgLyBiZW5lZml0DQo+IChu b25lKSBhbmFseXNpcyBkb25lIGluIHNlY3Rpb24gNy41IGlzIHJlYWxpc3RpYz8NCj4NCj4gQmVz dCByZWdhcmRzLA0KPiBBbGVzc2FuZHJvDQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBUZWxlY29tIEl0YWxp YQ0KPiBBbGVzc2FuZHJvIEQnQWxlc3NhbmRybw0KPiBUcmFuc3BvcnQgSW5ub3ZhdGlvbg0KPiBW aWEgUmVpc3MgUm9tb2xpLCAyNzQgLSAxMDE0OCBUb3Jpbm8NCj4gcGhvbmU6wqAgKzM5IDAxMSAy MjggNTg4Nw0KPiBtb2JpbGU6ICszOSAzMzUgNzY2IDk2MDcNCj4gZmF4OiArMzkgMDYgNDE4IDYz OSAwNw0KPg0KPiAtLS0tLU1lc3NhZ2dpbyBvcmlnaW5hbGUtLS0tLQ0KPiBEYTogbXBscy1ib3Vu Y2VzQGlldGYub3JnDQo+IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXQ0KPiBQZXIgY29u dG8gZGkgQWRyaWFuIEZhcnJlbA0KPiBJbnZpYXRvOiBsdW5lZMOsIDI2IHNldHRlbWJyZSAyMDEx IDIzOjU4DQo+IEE6IG1wbHNAaWV0Zi5vcmcNCj4gT2dnZXR0bzogW21wbHNdIEZXOiBMYXN0IENh bGw6DQo+IDxkcmFmdC1zcHJlY2hlci1tcGxzLXRwLW9hbS1jb25zaWRlcmF0aW9ucy0wMS50eHQ+ DQo+IChUaGUgUmVhc29ucyBmb3IgU2VsZWN0aW5nIGEgU2luZ2xlIFNvbHV0aW9uIGZvciBNUExT LVRQDQo+IE9BTSkgdG8gSW5mb3JtYXRpb25hbCBSRkMNCj4NCj4gTVBMUyBXb3JraW5nIEdyb3Vw LA0KPg0KPiBQbGVhc2UgYmUgYXdhcmUgb2YgdGhlIElFVEYgbGFzdCBjYWxsIGFzIHNob3duIGJl bG93LiBUaGUNCj4gZG9jdW1lbnQgd2FzIHByZXNlbnRlZCBmb3IgcHVibGljYXRpb24gYXMgYW4g aW5kaXZpZHVhbCBSRkMNCj4gd2l0aCBJRVRGIGNvbnNlbnN1cyBhbmQgQUQgc3BvbnNvcnNoaXAu DQo+DQo+IFRoaXMgZHJhZnQgaXMgY2xlYXJseSBjbG9zZSBhbmQgcmVsZXZhbnQgdG8gdGhlIHdv cmsgeW91DQo+IGRvLCBidXQgYWZ0ZXIgZGlzY3Vzc2luZyB3aXRoIHRoZSBjaGFpcnMgSSBjYW1l IHRvIHRoZQ0KPiBjb25jbHVzaW9uIHRoYXQgaXQgZG9lcyBub3QgY29tbWVudCBvbiB0aGUgdGVj aG5pY2FsIG9yDQo+IHByb2Nlc3MgZGVjaXNpb25zIG9mIHRoZSBNUExTIHdvcmtpbmcgZ3JvdXBz LCBhbmQgaXQgZG9lcw0KPiBub3QgYXR0ZW1wdCB0byBtYWtlIGFueSB0ZWNobmljYWwgZXZhbHVh dGlvbnMgb3IgZGVmaW5pdGlvbnMNCj4gd2l0aGluIHRoZSBzY29wZSBvZiB0aGUgTVBMUyB3b3Jr aW5nIGdyb3VwLiBJdCBpcyBtb3JlIG9mIGENCj4gcGhpbG9zb3BoaWNhbCBhbmFseXNpcyBvZiB0 aGUgd2F5IHRoZSBJRVRGIGFwcHJvYWNoZXMgdGhlDQo+ICJ0d28gc29sdXRpb25zIiBwcm9ibGVt IHdpdGggc3BlY2lhbCByZWZlcmVuY2UgdG8gTVBMUy1UUA0KPiBPQU0uDQo+DQo+IFRodXMsIEkg YW0gYWNjZXB0aW5nIHRoZSBkb2N1bWVudCBhcyBBRCBTcG9uc29yZWQgcmF0aGVyDQo+IHRoYW4g cnVubmluZyBpdCB0aHJvdWdoIHRoZSBNUExTIHdvcmtpbmcgZ3JvdXAuIE15IHJlYXNvbmluZw0K PiBpcyB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBnb3QgcGxlbnR5IHRvIGRvIHdvcmtpbmcg b24NCj4gdGVjaG5pY2FsIGlzc3VlcyB3aXRob3V0IGJlaW5nIGRpdmVydGVkIGludG8gd2lkZXIg SUVURg0KPiBwaGlsb3NvcGh5Lg0KPg0KPiBBcyBhbiBBRCBTcG9uc29yZWQgSS1EIGl0IGlzIHN1 YmplY3QgdG8gYSBmb3VyIHdlZWsgSUVURg0KPiBsYXN0IGNhbGwuIFRoYXQgaXMgcGxlbnR5IG9m IG9wcG9ydHVuaXR5IGZvciBldmVyeW9uZSB0bw0KPiBjb21tZW50IGFuZCBleHByZXNzIHRoZWly IHZpZXdzLiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzDQo+IHRvIHRoZSBJRVRGIG1haWxpbmcg bGlzdCBhcyBkZXNjcmliZWQgYmVsb3csIG9yIChpbg0KPiBleGNlcHRpb25hbCBjaXJjdW1zdGFu Y2VzKSBkaXJlY3QgdG8gdGhlIElFU0cuDQo+DQo+IFRoYW5rcywNCj4gQWRyaWFuDQo+DQo+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBpZXRmLWFubm91bmNlLWJvdW5j ZXNAaWV0Zi5vcmcNCj4gW21haWx0bzppZXRmLWFubm91bmNlLQ0KPiA+IGJvdW5jZXNAaWV0Zi5v cmddDQo+IE9uIEJlaGFsZiBPZiBUaGUgSUVTRw0KPiA+IFNlbnQ6IDI2IFNlcHRlbWJlciAyMDEx IDIwOjQzDQo+ID4gVG86IElFVEYtQW5ub3VuY2UNCj4gPiBTdWJqZWN0OiBMYXN0IENhbGw6DQo+ IDxkcmFmdC1zcHJlY2hlci1tcGxzLXRwLW9hbS1jb25zaWRlcmF0aW9ucy0wMS50eHQ+DQo+ID4g KFRoZSBSZWFzb25zIGZvciBTZWxlY3RpbmcgYSBTaW5nbGUgU29sdXRpb24gZm9yDQo+IE1QTFMt VFAgT0FNKSB0bw0KPiA+IEluZm9ybWF0aW9uYWwgUkZDDQo+ID4NCj4gPg0KPiA+IFRoZSBJRVNH IGhhcyByZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSBhbiBpbmRpdmlkdWFsDQo+IHN1Ym1pdHRlciB0 bw0KPiA+IGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnQ6DQo+ID4gLSAnVGhlIFJlYXNv bnMgZm9yIFNlbGVjdGluZyBhIFNpbmdsZSBTb2x1dGlvbiBmb3INCj4gTVBMUy1UUCBPQU0nDQo+ ID7CoMKgwqA8ZHJhZnQtc3ByZWNoZXItbXBscy10cC1vYW0tY29uc2lkZXJhdGlvbnMtMDEudHh0 Pg0KPiBhcyBhbg0KPiA+IEluZm9ybWF0aW9uYWwgUkZDDQo+ID4NCj4gPiBUaGUgSUVTRyBwbGFu cyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3DQo+IHdlZWtzLCBhbmQgc29saWNp dHMNCj4gPiBmaW5hbCBjb21tZW50cyBvbiB0aGlzIGFjdGlvbi4gUGxlYXNlIHNlbmQgc3Vic3Rh bnRpdmUNCj4gY29tbWVudHMgdG8gdGhlDQo+ID4gaWV0ZkBpZXRmLm9yZw0KPiBtYWlsaW5nIGxp c3RzIGJ5IDIwMTEtMTAtMjQuIEV4Y2VwdGlvbmFsbHksIGNvbW1lbnRzIG1heQ0KPiA+IGJlIHNl bnQgdG8gaWVzZ0BpZXRmLm9yZw0KPiBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxlYXNlIHJl dGFpbiB0aGUNCj4gPiBiZWdpbm5pbmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRv bWF0ZWQNCj4gc29ydGluZy4NCj4gPg0KPiA+IEFic3RyYWN0DQo+ID4NCj4gPsKgIMKgIFRoZSBN UExTIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQKSBpcyBhDQo+IHByb2ZpbGUgb2YgTVBMUyB0 ZWNobm9sb2d5DQo+ID7CoCDCoCBmb3IgdXNlIGluIHRyYW5zcG9ydCBuZXR3b3JrIGRlcGxveW1l bnRzLg0KPiBUaGF0IGlzLCBNUExTLVRQIGlzIGEgc2V0DQo+ID7CoCDCoCBvZiBmdW5jdGlvbnMg YW5kIGZlYXR1cmVzIHNlbGVjdGVkIGZyb20NCj4gdGhlIHdpZGVyIE1QTFMgdG9vbHNldCBhbmQN Cj4gPsKgIMKgIGFwcGxpZWQgaW4gYSBjb25zaXN0ZW50IHdheSB0byBtZWV0IHRoZQ0KPiBuZWVk cyBhbmQgcmVxdWlyZW1lbnRzIG9mDQo+ID7CoCDCoCBvcGVyYXRvcnMgb2YgcGFja2V0IHRyYW5z cG9ydCBuZXR3b3Jrcy4NCj4gPg0KPiA+wqAgwqAgRHVyaW5nIHRoZSBwcm9jZXNzIG9mIGRldmVs b3BtZW50IG9mIHRoZQ0KPiBwcm9maWxlLCBhZGRpdGlvbnMgdG8gdGhlDQo+ID7CoCDCoCBNUExT IHRvb2xzZXQgaGF2ZSBiZWVuIG1hZGUgdG8gZW5zdXJlDQo+IHRoYXQgdGhlIHRvb2xzIGF2YWls YWJsZSBtZXQNCj4gPsKgIMKgIHRoZSByZXF1aXJlbWVudHMuIFRoZXNlIGFkZGl0aW9ucyB3ZXJl DQo+IG1vdGl2YXRlZCBieSBNUExTLVRQLCBidXQgZm9ybQ0KPiA+wqAgwqAgcGFydCBvZiB0aGUg d2lkZXIgTVBMUyB0b29sc2V0IHN1Y2ggdGhhdA0KPiBhbnkgb2YgdGhlbSBjb3VsZCBiZSB1c2Vk IGluDQo+ID7CoCDCoCBhbnkgTVBMUyBkZXBsb3ltZW50Lg0KPiA+DQo+ID7CoCDCoCBPbmUgbWFq b3Igc2V0IG9mIGFkZGl0aW9ucyBwcm92aWRlcw0KPiBlbmhhbmNlZCBzdXBwb3J0IGZvciBPcGVy YXRpb25zLA0KPiA+wqAgwqAgQWRtaW5pc3RyYXRpb24sIGFuZCBNYWludGVuYW5jZSAoT0FNKS4N Cj4gVGhpcyBlbmFibGVzIGZhdWx0IG1hbmFnZW1lbnQNCj4gPsKgIMKgIGFuZCBwZXJmb3JtYW5j ZSBtb25pdG9yaW5nIHRvIHRoZSBsZXZlbA0KPiBuZWVkZWQgaW4gYSB0cmFuc3BvcnQNCj4gPsKg IMKgIG5ldHdvcmsuIE1hbnkgc29sdXRpb25zIGFuZCBwcm90b2NvbA0KPiBleHRlbnNpb25zIGhh dmUgYmVlbiBwcm9wb3NlZCB0bw0KPiA+wqAgwqAgYWRkcmVzcyB0aGVzZSBPQU0gcmVxdWlyZW1l bnRzLCBhbmQgdGhpcw0KPiBkb2N1bWVudCBzZXRzIG91dCB0aGUNCj4gPsKgIMKgIHJlYXNvbnMg Zm9yIHNlbGVjdGluZyBhIHNpbmdsZSwgY29oZXJlbnQNCj4gc2V0IG9mIHNvbHV0aW9ucyBmb3IN Cj4gPsKgIMKgIHN0YW5kYXJkaXphdGlvbi4NCj4gPg0KPiA+DQo+ID4gVGhlIGZpbGUgY2FuIGJl IG9idGFpbmVkIHZpYQ0KPiA+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt c3ByZWNoZXItbXBscy10cC1vYW0tY29uc2lkZXJhdGkNCj4gPiBvbnMvDQo+ID4NCj4gPiBJRVNH IGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhDQo+ID4gaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1zcHJlY2hlci1tcGxzLXRwLW9hbS1jb25zaWRlcmF0aQ0KPiA+IG9u cy8NCj4gPg0KPiA+DQo+ID4gTm8gSVBSIGRlY2xhcmF0aW9ucyBoYXZlIGJlZW4gc3VibWl0dGVk IGRpcmVjdGx5IG9uDQo+IHRoaXMgSS1ELg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gSUVURi1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCj4g PiBJRVRGLUFubm91bmNlQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZXRmLWFubm91bmNlDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMgbWFpbGluZyBsaXN0DQo+IG1wbHNAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+DQo+IFF1 ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aQ0KPiBlc2Ns dXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8N Cj4gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBx dWVzdGUNCj4gaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3Jh IGFiYmlhdGUNCj4gcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNv cnRlc2VtZW50ZQ0KPiBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFs IG1pdHRlbnRlIGUgZGkNCj4gcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3Jhemll Lg0KPg0KPiBUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBh bmQgbWF5DQo+IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhl IGFkZHJlc3NlZShzKQ0KPiBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBv ciB1c2UgYnkgYW55Ym9keQ0KPiBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwNCj4gcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5k IGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlDQo+IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFp bCwgVGhhbmtzLg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBtcGxzIG1haWxpbmcgbGlzdA0KPiBtcGxzQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6 YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50 cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBu b3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRp b24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGgg aXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmln aW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2Fn ZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBi ZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0u DQo= From alessandro.dalessandro@telecomitalia.it Wed Oct 5 09:44:41 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463C911E8097; Wed, 5 Oct 2011 09:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.347 X-Spam-Level: X-Spam-Status: No, score=-0.347 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 0q10KzVVbCpU; Wed, 5 Oct 2011 09:44:40 -0700 (PDT) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7D911E8085; Wed, 5 Oct 2011 09:44:40 -0700 (PDT) Received: from GRFHUB706RM001.griffon.local (10.19.3.71) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 5 Oct 2011 18:47:45 +0200 Received: from GRFMBX702RM001.griffon.local ([10.19.3.20]) by GRFHUB706RM001.griffon.local ([10.19.9.239]) with mapi; Wed, 5 Oct 2011 18:47:45 +0200 From: D'Alessandro Alessandro Gerardo To: "stbryant@cisco.com" Date: Wed, 5 Oct 2011 18:47:44 +0200 Thread-Topic: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Thread-Index: AcyDSQ1rK3SEwfeKRDiGOKPSXCFEgAANNU6w Message-ID: References: <081e01cc7c97$588726e0$099574a0$@olddog.co.uk> <4E8C305B.6060106@cisco.com> In-Reply-To: <4E8C305B.6060106@cisco.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf@ietf.org" , "mpls@ietf.org" Subject: [mpls] R: R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 16:44:41 -0000 Dear Stewart, Many thanks for your answer that anyway I do not believe addresses the root= concern I have on the proposed draft. I would avoid bringing technical discussions into this thread because it i= s a declared intent of the draft in the object to NOT touch such aspects. I= 'm therefore going to answer you on a different thread. Best regards, Alessandro ------------------------------------------------------------------ Telecom Italia Alessandro D'Alessandro Transport Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -----Messaggio originale----- Da: Stewart Bryant [mailto:stbryant@cisco.com] Inviato: mercoled=EC 5 ottobre 2011 12:24 A: D'Alessandro Alessandro Gerardo Cc: adrian@olddog.co.uk; mpls@ietf.org; ietf@ietf.org Oggetto: Re: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM)= to Informational RFC On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote: > major unresolved technical concerns Alessandro Please can I suggest that you write an internet draft detailing these "majo= r unresolved technical concerns" so that we can all understand them. Such a draft needs to be technical, and describe the actions that the netwo= rk operator is unable to perform, or the fault cases that they are unable t= o diagnose using the OAM defined in the IETF RFCs, or late stage WG drafts. Alternatively if you are referring to a bug in the MPLS-TP OAM protocols, y= ou need to tell the community what it is. I believe that this request has been made a number of times, in various fo= rums, and, as far as I know, no document has yet been produced. An argument of the form "you must standardize what I want" will not fly. What is needed is a very clear technical definition of the is= sue(s). When we have the "major unresolved technical concerns" on the table, we will be in a position to determine the best disposition of= those issues. Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From alessandro.dalessandro@telecomitalia.it Wed Oct 5 09:51:17 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7392311E8094; Wed, 5 Oct 2011 09:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.384 X-Spam-Level: X-Spam-Status: No, score=-0.384 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 0VDxTuUlkaOG; Wed, 5 Oct 2011 09:51:17 -0700 (PDT) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6536F11E809D; Wed, 5 Oct 2011 09:51:10 -0700 (PDT) Received: from grfhub703rm001.griffon.local (10.19.3.10) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 5 Oct 2011 18:54:17 +0200 Received: from GRFMBX702RM001.griffon.local ([10.19.3.20]) by grfhub703rm001.griffon.local ([10.19.9.236]) with mapi; Wed, 5 Oct 2011 18:54:17 +0200 From: D'Alessandro Alessandro Gerardo To: "stbryant@cisco.com" , "Alexander.Vainshtein@ecitele.com" Date: Wed, 5 Oct 2011 18:54:16 +0200 Thread-Topic: unresolved technical concerns Thread-Index: AcyDftrXxysabIfuTL2UhQPyTTWf/w== Message-ID: Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf@ietf.org" , "mpls@ietf.org" Subject: [mpls] unresolved technical concerns X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 16:51:17 -0000 Dear Stewart, Dear Sasha, I think there are already enough contributions in that direction I (with ma= ny other experts) contributed to in the form of IETF mailing list discussio= n and ITU-T liaisons. Unfortunately I regret to say that some questions for= clarification and concerns risen in those emails (for sure some of mine) s= till remain without an answer. At the same time, some comments provided by = ITU-T liaisons still remain unresolved. Best regards, Alessandro ------------------------------------------------------------------ Telecom Italia Alessandro D'Alessandro Transport Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -----Messaggio originale----- Da: Stewart Bryant [mailto:stbryant@cisco.com] Inviato: mercoled=EC 5 ottobre 2011 12:24 A: D'Alessandro Alessandro Gerardo Cc: adrian@olddog.co.uk; mpls@ietf.org; ietf@ietf.org Oggetto: Re: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM)= to Informational RFC On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote: > major unresolved technical concerns Alessandro Please can I suggest that you write an internet draft detailing these "majo= r unresolved technical concerns" so that we can all understand them. Such a draft needs to be technical, and describe the actions that the netwo= rk operator is unable to perform, or the fault cases that they are unable t= o diagnose using the OAM defined in the IETF RFCs, or late stage WG drafts. Alternatively if you are referring to a bug in the MPLS-TP OAM protocols, y= ou need to tell the community what it is. I believe that this request has been made a number of times, in various fo= rums, and, as far as I know, no document has yet been produced. An argument of the form "you must standardize what I want" will not fly. What is needed is a very clear technical definition of the is= sue(s). When we have the "major unresolved technical concerns" on the table, we will be in a position to determine the best disposition of= those issues. Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From gregimirsky@gmail.com Wed Oct 5 10:10:19 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF9421F8CE9 for ; Wed, 5 Oct 2011 10:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 GEPDiQvioMtT for ; Wed, 5 Oct 2011 10:10:17 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0349A21F8CD9 for ; Wed, 5 Oct 2011 10:09:57 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so1909429vcb.31 for ; Wed, 05 Oct 2011 10:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=51G/Sesyj6tJrLmQo5nPKj3BipNiDSQSlb87F5/SELc=; b=HdNvSUkz2PxO7j5Vz0UmAxLjJAuwMAYGeoe19mjnydsMzL6sCy6n/X2g0Y+xAd58Wa be6PGxOmdqxpmr7ObDtqTXEgKYhZujUF35RpniZrAxe/WTfItxLw6dp+UlVqxzc0uTxF FSIQxQzwzJQ83IKgoHj3EF+Ln19u5d3EWY50I= MIME-Version: 1.0 Received: by 10.52.99.66 with SMTP id eo2mr2496828vdb.121.1317834785505; Wed, 05 Oct 2011 10:13:05 -0700 (PDT) Received: by 10.52.163.199 with HTTP; Wed, 5 Oct 2011 10:13:05 -0700 (PDT) In-Reply-To: <04da01cc834b$998ad460$cca07d20$@olddog.co.uk> References: <042101cc82dc$0da49e50$28eddaf0$@olddog.co.uk> <04da01cc834b$998ad460$cca07d20$@olddog.co.uk> Date: Wed, 5 Oct 2011 10:13:05 -0700 Message-ID: From: Greg Mirsky To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=20cf307f37c24340d304ae90526c Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-li-lb-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 17:10:19 -0000 --20cf307f37c24340d304ae90526c Content-Type: text/plain; charset=ISO-8859-1 Hi Adrian, yes we're! And I'll try to summarize it below instead of in-lining: - query the WG on applicability of the LB on "coincidental" bidirectional MIP on associated bi-directional LSP; - query the WG on introducing explicit UnLock operation to MPLS-TP OAM set - I accept proposed updates to LB applicability statement - In regard to our discussion of management plane role in setting MEP or MIP into a loopback state (Section 4, p.4, second to last para). I agree with the proposed version for the first sentence but will re-word the second: NEW The management plane must ensure that the two MEPs are locked before performing the loopback function. NEWER The management plane must ensure that the two MEPs are locked before it requests setting MEP or MIP in the loopback state. END - I feel that we're implicitly view and refer to an MPLS Section as bidirectional construct even though it is not. In case of this document I'd propose to explicitly refer to bidirectional MPLS Section where necessary. Regards, Greg On Wed, Oct 5, 2011 at 3:43 AM, Adrian Farrel wrote: > Hi again Greg, > > We are converging. > > I've cut out the bits where we have reached conclusions. > > >>> Introduction, third para. > >>> Applicability of the Loopback is limited, comparing to previous > versions, > >>> to bi-directional co-routed LSP, PW and MPLS Section. I agree that > >>> statement of applicability in previous versions was bit too cumbersome > >>> but this one excludes bi-directional associated LSP at all. I think > that > >>> Loopback can be used on this construct at MIP that are on forward > >>> and reverse direction of given bi-directional associated MPLS-TP LSP. > >>> And I think that MPLS Section is not necessarily a bi-directional co- > >>> routed object. > > > > GIM>> But then PW and MPLS Section have been referred twice - > > after co-routed LSP, then after associated LSP. Or intention was to apply > > co-routed and associated to PW and MPLS Section? Would making the > > last sentence to "It can also be applied at a MEP on an associated > > bidirectional LSP" be sufficient? But still, MIPs that are on forward > > and reverse direction of an associated bi-directional LSP are excluded. > > I believe that previous versions tried to include such MIPs since these > > are required to be aware of directions and their correlation. Is this > > change intentional? > > You're right. I mangled the original text in my enthusiasm to have > something I > could parse :-) > I think there are two issues: > > 1. extraneous mention of PW and Section in the last sentence > > OLD (v7) > - The loopback function allows an operator to set a specific node on > a transport path into loopback mode such that it returns all > received data. Loopback can be applied at a Maintenance Entity > Group End Point (MEP) or a Maintenance Entity Group Intermediate > Point (MIP) on a co-routed bidirectional LSP, PW or MPLS > Section. It can also be applied at a MEP on an associated > bidirectional LSP, PW or MPLS Section. > NEW > - The loopback function allows an operator to set a specific node on > a transport path into loopback mode such that it returns all > received data. Loopback can be applied at a Maintenance Entity > Group End Point (MEP) or a Maintenance Entity Group Intermediate > Point (MIP) on a co-routed bidirectional LSP, on a PW, or on an > MPLS Section. It can also be applied at a MEP on an associated > bidirectional LSP. > END > > 2. Discussion of loopback at "coincident" MIPs on associated bidirectional > LSPs. > This is a question for the WG not for me (I am only trying to provide an > editorial service!). > Would you mind raising this as a separate thread so that the WG spot and > debate > the issue? > > >>> Section 4, p.4, second to last para. I think that management plane > >>> sets in or requests Loopback on specific MP but not performs it. > >> > >> The two sentences in this paragraph are directly copied from the > >> previous revision with the only change to drop "MUST" to lower case. > >> > >> Not sure what to say here since the WG clearly agreed to this text > >> before. I think the intention was to say that a control plane is not > >> required in order to achieve loopback. > > > >GIM>> What if the first sentence says: > > > > A management plane can be too used to set a MEP or MIP along a > > transport path in Loopback. > > Well, I don't like "too" because this document doesn't actually mention any > way > to set loopback using the control plane. > > So what about: > > OLD (v7) > The Loopback can be performed using a management plane. Management > plane must ensure that the two MEPs are locked before performing the > loopback function. > NEW > The management plane can be used to configure the Loopback function. > The management plane must ensure that the two MEPs are locked before > performing the loopback function. > END > > >>> Definition given in Section 4.1 is broader than one in the > Introduction. > >>> Personally I like the latter better though I think that it can be > expanded > >>> to include MIPs on bi-directional associated LSP that are on forward > and > >>> reverse direction of it. > >> > >> I think it is the same definition. > >> See the paragraph quoted above and compare with: > >> - The node in loopback mode must be on both the forward and return > >> paths. This possible for all MEPs and MIPs on a co-routed > >> bidirectional LSP, PW, or MPLS Section, but is only > >> possible on for MEPs on associated bidirectional LSPs, PW, > >> or MPLS Sections. > >> ...which seems to exclude the MIPs on assoc bidir as you say. > > Same two issues: > > 1. > OLD (v7) > - The node in loopback mode must be on both the forward and return > paths. This possible for all MEPs and MIPs on a co-routed > bidirectional LSP, PW, or MPLS Section, but is only > possible on for MEPs on associated bidirectional LSPs, PW, > or MPLS Sections. > NEW > - The node in loopback mode must be on both the forward and return > paths. This possible for all MEPs and MIPs on a co-routed > bidirectional LSP, on a PW, or on an MPLS Section, but is only > possible on for MEPs on associated bidirectional LSPs. > END > > 2. You will raise associated bidir MIPs on the mailing list > > >>> I'll note that service could not be restored faster than in 3.5 seconds > >>> according to described procedure. Is that desired behavior? > >> > >> That is a good question for the WG. It was my assumption (from the > >> previous revision) that rapid unlocking and turn-up was not a > >> requirement or it would have been included. > >> > >> If the WG now wants to include it, it will need to examine the use of an > >> unlock OAM message. This could be done using a new message or a flag > >> on the existing lock message. It could be achieved by tweaking this > >> document or introducing a new document. > > > > GIM>> I'd support explicit UnLock OAM message. I think that it is > required > > if LI/LB expected to work in heterogeneous network (without defined > > UnLock message or flag request to UnLock is proprietary, in my view). > > OK. Well, this is another technical, not editorial, change. > So I am not really in a position to discuss it. > Would you mind creating a separate thread for this one as well? > That way the WG can decide what it wants to do. > > Many thanks for the thorough and thoughtful review. > > Adrian > > --20cf307f37c24340d304ae90526c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Adrian,
yes we're! And I'll try to summarize it below instead= of in-lining:
  • query the WG on applicability of the LB on "= coincidental" bidirectional MIP on associated bi-directional LSP;
  • query the WG on introducing explicit UnLock operation to MPLS-TP OAM se= t
  • I accept proposed updates to LB applicability statement
  • I= n regard to our discussion of management plane role in setting MEP or MIP i= nto a loopback state (Section 4, p.4, second to last para). I agree with th= e proposed version for the first sentence but will re-word the second:
NEW
=A0 The management plane must ensure that the two MEPs are locked before =A0 performing the loopback function.
NEWER
=A0 The management plane= must ensure that the two MEPs are locked before it requests
=A0 setting= MEP or MIP in the loopback state.
END

  • I feel that we're implicitly view and refer to an MP= LS Section as bidirectional construct even though it is not. In case of thi= s document I'd propose to explicitly refer to bidirectional MPLS Sectio= n where necessary.

Regards,
Greg


On Wed, Oct= 5, 2011 at 3:43 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi again Greg,

We are converging.

I've cut out the bits where we have reached conclusions.

>>> Introduction, third para.
>>> Applicability of the Loopback is limited, comparing to previou= s versions,
>>> to bi-directional co-routed LSP, PW and MPLS Section. I agree = that
>>> statement of applicability in previous versions was bit too cu= mbersome
>>> but this one excludes bi-directional associated LSP at all. I = think that
>>> Loopback=A0can be used on this construct at MIP that are on fo= rward
>>> and reverse direction of given bi-directional associated MPLS-= TP LSP.
>>> And I think that MPLS Section is not necessarily a bi-directio= nal co-
>>> routed object.
>
> GIM>> But then PW and MPLS Section have = been referred twice -
> after co-routed LSP, then after associated LSP. Or intention was to ap= ply
> co-routed and associated to PW and MPLS Section? Would making the
> last sentence to "It can also be applied at a MEP on an associate= d
> bidirectional LSP" be sufficient? But still, MIPs that are on for= ward
> and reverse direction of an associated bi-directional LSP are excluded= .
> I believe that previous versions tried to include such MIPs since thes= e
> are required to be aware of directions and their correlation. Is this<= br> > change intentional?

You're right. I mangled the original =A0text in my enthusiasm to = have something I
could parse :-)
I think there are two issues:

1. extraneous mention of PW and Section in the last sentence

OLD (v7)
=A0 - The loopback function allows an operator to set a = specific node on
=A0 =A0 a transport path into loopback mode such that it returns all
=A0 =A0 received data. Loopback can be applied at a Maintenance Entity
=A0 =A0 Group End Point (MEP) or a Maintenance Entity Group Intermediate =A0 =A0 Point (MIP) on a co-routed bidirectional LSP, PW or MPLS
=A0 =A0 Section. It can also be applied at a MEP on an associated
=A0 =A0 bidirectional LSP, PW or MPLS Section.
NEW
=A0 - The loopback function allows an operator to set a = specific node on
=A0 =A0 a transport path into loopback mode such that it returns all
=A0 =A0 received data. Loopback can be applied at a Maintenance Entity
=A0 =A0 Group End Point (MEP) or a Maintenance Entity Group Intermediate
=A0 =A0 Point (MIP) on a co-routed bidirectional LSP, on a PW, or on= an
=A0 =A0 MPLS Section. It can also be applied at a MEP on= an associated
=A0 =A0 bidirectional LSP.
END

2. Discussion of loopback at "coincident" MIPs on associated bidi= rectional LSPs.
This is a question for the WG not for me (I am only trying to provide an editorial service!).
Would you mind raising this as a separate thread so that the WG spot and de= bate
the issue?

>>> Section 4, p.4, second to last para. I think that management p= lane
>>> sets in or requests Loopback on specific MP but not performs i= t.
>>
>> The two sentences in this paragraph are directly copied from the
>> previous revision with the only change to drop "MUST&qu= ot; to lower case.
>>
>> Not sure what to say here since the WG clearly agreed to this text=
>> before. I think the intention was to say that a control plane is n= ot
>> required in order to achieve loopback.
>
>GIM>> What if the first sentence says:
>
> A management plane can be too used to set a MEP or MIP along a
> transport path in Loopback.

Well, I don't like "too" because this document doesn= 9;t actually mention any way
to set loopback using the control plane.

So what about:

OLD (v7)
=A0 The Loopback can be performed using a management plane. Management
=A0 plane must ensure that the two MEPs are locked before performing the =A0 loopback function.
NEW
=A0 The management plane can be used to configure the Loopback function. =A0 The management plane must ensure that the two MEPs are locked before =A0 performing the loopback function.
END

>>> Definition given in Section 4.1 is broader than one in the Int= roduction.
>>> Personally I like the latter better though I think that it can= be expanded
>>> to include MIPs on bi-directional associated LSP that are on f= orward and
>>> reverse direction of it.
>>
>> I think it is the same definition.
>> See the paragraph quoted above and compare with:
>>=A0 - The node in loopback mode must be on both the forward and ret= urn
>>=A0 =A0 paths. This possible for all MEPs and MIPs on a co-routed >>=A0 =A0 bidirectional LSP, PW, or MPLS Section, but is only
>>=A0 =A0 possible on for MEPs on associated bidirectional LSPs, PW,<= br> >>=A0 =A0 or MPLS Sections.
>> ...which seems to exclude the MIPs on assoc bidir as you say.

Same two issues:

1.
OLD (v7)
=A0 - The node in loopback mode must be on both the forw= ard and return
=A0 =A0 paths. This possible for all MEPs and MIPs on a co-routed
=A0 =A0 bidirectional LSP, PW, or MPLS Section, but is only
=A0 =A0 possible on for MEPs on associated bidirectional LSPs, PW,
=A0 =A0 or MPLS Sections.
NEW
=A0 - The node in loopback mode must be on both the forw= ard and return
=A0 =A0 paths. This possible for all MEPs and MIPs on a co-routed
=A0 =A0 bidirectional LSP, on a PW, or on an MPLS Section, but is on= ly
=A0 =A0 possible on for MEPs on associated bidirectional LSPs.
END

2. You will raise associated bidir MIPs on the mailing list

>>> I'll note that service could not be restored faster than i= n 3.5 seconds
>>> according to described procedure. Is that desired behavior? >>
>> That is a good question for the WG. It was my assumption (from the=
>> previous revision) that rapid unlocking and turn-up was not a
>> requirement or it would have been included.
>>
>> If the WG now wants to include it, it will need to examine the use= of an
>> unlock OAM message. This could be done using a new message or a fl= ag
>> on the existing lock message. It could be achieved by tweaking thi= s
>> document or introducing a new document.
>
> GIM>> I'd support explicit UnLock OAM message. I think that = it is required
> if LI/LB expected to work in heterogeneous network (without defined > UnLock message or flag request to UnLock is proprietary, in my view).<= br>
OK. Well, this is another technical, not editorial, change.
So I am not really in a position to discuss it.
Would you mind creating a separate thread for this one as well?
That way the WG can decide what it wants to do.

Many thanks for the thorough and thoughtful review.

Adrian


--20cf307f37c24340d304ae90526c-- From gregimirsky@gmail.com Wed Oct 5 11:15:44 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD1721F8C10 for ; Wed, 5 Oct 2011 11:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 fUsSD4GCyN8q for ; Wed, 5 Oct 2011 11:15:43 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B72E221F8B3D for ; Wed, 5 Oct 2011 11:15:43 -0700 (PDT) Received: by vws5 with SMTP id 5so1987483vws.31 for ; Wed, 05 Oct 2011 11:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=hI3W+La/rTlSMOnKyvqG9Qc9wN1tUWGlYGL8PkZ0VnE=; b=RoZQyNeg77cKXsG23FiKgCUAa38/wHPho5OROYoICs+PrxpPJuStvQt3Vyq/mItQnm G/fzk/8BTiG2avMR+zZ0W7sWcYuFgPxfTylwGP+i0941GtJ7caCEh/clUQJE/gl6HkPW q8+WpFVx3rfjeOEC/IREfCO+efmmjrAGBKt3I= MIME-Version: 1.0 Received: by 10.52.187.34 with SMTP id fp2mr3039209vdc.54.1317838730314; Wed, 05 Oct 2011 11:18:50 -0700 (PDT) Received: by 10.52.163.199 with HTTP; Wed, 5 Oct 2011 11:18:50 -0700 (PDT) Date: Wed, 5 Oct 2011 11:18:50 -0700 Message-ID: From: Greg Mirsky To: mpls@ietf.org Content-Type: multipart/alternative; boundary=bcaec548aaad64533d04ae913de6 Subject: [mpls] Scope of Loopback function in draft-ietf-mpls-tp-li-lb-07 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 18:15:44 -0000 --bcaec548aaad64533d04ae913de6 Content-Type: text/plain; charset=ISO-8859-1 Dear All, in review of the latest version of LI/LB document a question of what is the scope of the Loopback function in MPLS came up. The current version of the document defines scope of the Loopback as: - MEPs and MIPs on bi-directional co-routed LSP - PW - MPLS Section (I believe it should be explicitly characterized as bi-directional section) - MEPs on bi-directional associated LSP Thus MIPs of associated LSP that are on both forward and reverse directions of the same LSP are excluded and not expected to be put in the Loopback state. I think that such MIP, referred as "coincidental co-routed MIPs" must be included in scope of the Loopback function. Co-routed bi-directional LSP can be viewed as special case of associated bi-directional LSP where all MIPs are not coincidental but intentionally co-routed. But regardless of why a particular MIP happens to have co-routed character, I think, such MIP can be set in Loopback. And I propose to explicitly include "coincidental co-routed" MIPs on associated co-routed LSP in the scope of Loopback function as defined in the draft-ietf-mpls-tp-li-lb-07. Regards, Greg --bcaec548aaad64533d04ae913de6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear All,
in review of the latest version of LI/LB document a question o= f what is the scope of the Loopback function in MPLS came up. The current v= ersion of the document defines scope of the Loopback as:
  • MEPs an= d MIPs on bi-directional co-routed LSP
  • PW
  • MPLS Section (I believe it should be explicitly characterize= d as bi-directional section)
  • MEPs on bi-directional associated LSP<= /li>
Thus MIPs of associated LSP that are on both forward and reverse d= irections of the same LSP are excluded and not expected to be put in the Lo= opback state. I think that such MIP, referred as "coincidental co-rout= ed MIPs" must be included in scope of the Loopback function. Co-routed= bi-directional LSP can be viewed as special case of associated bi-directio= nal LSP where all MIPs are not coincidental but intentionally co-routed. Bu= t regardless of why a particular MIP happens to have co-routed character, I= think, such MIP can be set in Loopback. And I propose to explicitly includ= e "coincidental co-routed" MIPs on associated co-routed LSP in th= e scope of Loopback function as defined in the draft-ietf-mpls-tp-li-lb-07.=

Regards,
Greg
--bcaec548aaad64533d04ae913de6-- From gregimirsky@gmail.com Wed Oct 5 12:52:22 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9908221F8BF4 for ; Wed, 5 Oct 2011 12:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 9-kmWp-TZUfU for ; Wed, 5 Oct 2011 12:52:22 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0983511E80CC for ; Wed, 5 Oct 2011 12:52:21 -0700 (PDT) Received: by vws5 with SMTP id 5so2090537vws.31 for ; Wed, 05 Oct 2011 12:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=zbVVSZalAZJlpJvsO+AwuCluCwyzMHa+B4psV8yNxBc=; b=k+fiNL992Rcu18T46XqNmnylns9ttqxP5c35jl8jfdCwQBE9ng1QmqAvAGl64MtAC4 Vq6mc0rZ5Va3QrMF2tnfXlkC/vHor75y6vKPG7MhV12Q3y/r7LsSoZrPhBTshgBQruFY 0tDzvybAicOshd5Gi7GiugzsEJq23RP0rdZlM= MIME-Version: 1.0 Received: by 10.52.21.194 with SMTP id x2mr2857648vde.389.1317844529347; Wed, 05 Oct 2011 12:55:29 -0700 (PDT) Received: by 10.52.163.199 with HTTP; Wed, 5 Oct 2011 12:55:29 -0700 (PDT) Date: Wed, 5 Oct 2011 12:55:29 -0700 Message-ID: From: Greg Mirsky To: mpls@ietf.org Content-Type: multipart/alternative; boundary=20cf307813960a7e1304ae92976d Subject: [mpls] Lock Instruction functionality in MPLS OAM X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 19:52:22 -0000 --20cf307813960a7e1304ae92976d Content-Type: text/plain; charset=ISO-8859-1 Dear All, the latest version of LI/LB in MPLS-TP OAM defines format only of Lock Instruct. It is my understanding that unlocking can be done via the management plane and will not be result of timed out LI OAM messages. I think that since a transport path can be locked via OAM command it is logical to have a way to unlock it through OAM as well. UnLock function can be signaled by allocating one of Reserved bits in LI OAM message. Obviously such change will require updates to the document. Regards, Greg --20cf307813960a7e1304ae92976d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear All,
the latest version of LI/LB in MPLS-TP OAM defines format only= of Lock Instruct. It is my understanding that unlocking can be done via th= e management plane and will not be result of timed out LI OAM messages. I t= hink that since a transport path can be locked via OAM command it is logica= l to have a way to unlock it through OAM as well. UnLock function can be si= gnaled by allocating one of Reserved bits in LI OAM message. Obviously such= change will require updates to the document.

Regards,
Greg
--20cf307813960a7e1304ae92976d-- From tnadeau@lucidvision.com Wed Oct 5 12:58:10 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D5221F8C67 for ; Wed, 5 Oct 2011 12:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.515, 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 bYoCOAhJcihJ for ; Wed, 5 Oct 2011 12:58:09 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7567321F8C66 for ; Wed, 5 Oct 2011 12:58:09 -0700 (PDT) Received: from [10.100.69.0] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id 946B71EA6A04; Wed, 5 Oct 2011 16:01:17 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Thomas Nadeau In-Reply-To: Date: Wed, 5 Oct 2011 16:01:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6082DC91-86B1-4E2B-82BE-AE039795126F@lucidvision.com> References: To: Greg Mirsky X-Mailer: Apple Mail (2.1244.3) Cc: mpls@ietf.org Subject: Re: [mpls] Lock Instruction functionality in MPLS OAM X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 19:58:10 -0000 I have made similar comments privately to the document's editors = about a month ago, so I agree that these changes need to be made. They = need to implement some sort of default unlocking (timeout) mechanism. I = also suggested improving the security section to include some form of = authentication since you do not want a) the obvious malicious cases to = happen, but also b) the unauthorized (often mistaken) case to happen and = lock-out a network path. --Tom On Oct 5, 2011, at 3:55 PM, Greg Mirsky wrote: > Dear All, > the latest version of LI/LB in MPLS-TP OAM defines format only of Lock = Instruct. It is my understanding that unlocking can be done via the = management plane and will not be result of timed out LI OAM messages. I = think that since a transport path can be locked via OAM command it is = logical to have a way to unlock it through OAM as well. UnLock function = can be signaled by allocating one of Reserved bits in LI OAM message. = Obviously such change will require updates to the document. >=20 > Regards, > Greg > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From gregimirsky@gmail.com Wed Oct 5 13:10:03 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44D421F8BE5 for ; Wed, 5 Oct 2011 13:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 snpI0Bqt36Os for ; Wed, 5 Oct 2011 13:10:01 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF5421F8BE4 for ; Wed, 5 Oct 2011 13:10:01 -0700 (PDT) Received: by vws5 with SMTP id 5so2110149vws.31 for ; Wed, 05 Oct 2011 13:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xDIVeQbrz6Z/i9Q+V3Qallf1QpdaDJrCuqXvQTy+BVo=; b=HtMbUGMWh3pNPTJ4uIbSctM9JAGi4Wgq6l1WC3z8zIsmPMRgpQI11XZZw6yAdkPJ36 tJcFGoxK9I6ffOgKjzTj/eIBhK5IVJvRqmVwFluopHaXCkeRhzUQTMDZnh+/4S3AtfPZ MCRgFgTXBHatLFTSlTf64SCsBBQI8fgxfA3Dc= MIME-Version: 1.0 Received: by 10.52.21.194 with SMTP id x2mr2874889vde.389.1317845583917; Wed, 05 Oct 2011 13:13:03 -0700 (PDT) Received: by 10.52.163.199 with HTTP; Wed, 5 Oct 2011 13:13:03 -0700 (PDT) In-Reply-To: <6082DC91-86B1-4E2B-82BE-AE039795126F@lucidvision.com> References: <6082DC91-86B1-4E2B-82BE-AE039795126F@lucidvision.com> Date: Wed, 5 Oct 2011 13:13:03 -0700 Message-ID: From: Greg Mirsky To: Thomas Nadeau Content-Type: multipart/alternative; boundary=20cf30781396e5f1b904ae92d5b7 Cc: mpls@ietf.org Subject: Re: [mpls] Lock Instruction functionality in MPLS OAM X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 20:10:03 -0000 --20cf30781396e5f1b904ae92d5b7 Content-Type: text/plain; charset=ISO-8859-1 Hi Tom, I think that originally LI message was serving as keepalive but it changed when we realized that LI messages are not forwarded past MP set in the Loopback mode. Because of the an intermediate node being in the Loopback it is difficult to have meaningful dead timer associated with Lock state. I completely agree with need of Authentication. Perhaps we can define an Authentication TLV and specify its applicability in MPLS-TP OAM? Regards, Greg On Wed, Oct 5, 2011 at 1:01 PM, Thomas Nadeau wrote: > > I have made similar comments privately to the document's editors > about a month ago, so I agree that these changes need to be made. They > need to implement some sort of default unlocking (timeout) mechanism. I > also suggested improving the security section to include some form of > authentication since you do not want a) the obvious malicious cases to > happen, but also b) the unauthorized (often mistaken) case to happen and > lock-out a network path. > > --Tom > > > On Oct 5, 2011, at 3:55 PM, Greg Mirsky wrote: > > > Dear All, > > the latest version of LI/LB in MPLS-TP OAM defines format only of Lock > Instruct. It is my understanding that unlocking can be done via the > management plane and will not be result of timed out LI OAM messages. I > think that since a transport path can be locked via OAM command it is > logical to have a way to unlock it through OAM as well. UnLock function can > be signaled by allocating one of Reserved bits in LI OAM message. Obviously > such change will require updates to the document. > > > > Regards, > > Greg > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > --20cf30781396e5f1b904ae92d5b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tom,
I think that originally LI message was serving as keepalive but = it changed when we realized that LI messages are not forwarded past MP set = in the Loopback mode. Because of the an intermediate node being in the Loop= back it is difficult to have meaningful dead timer associated with Lock sta= te.
I completely agree with need of Authentication. Perhaps we can define an Au= thentication TLV and specify its applicability in MPLS-TP OAM?

Regar= ds,
Greg

On Wed, Oct 5, 2011 at 1:01 P= M, Thomas Nadeau <tnadeau@lucidvision.com> wrote:

=A0 =A0 =A0 =A0I have made similar comments privately to the document'= s editors about a month ago, so I agree that these changes need to be made.= =A0 They need to implement some sort of default unlocking (timeout) mechan= ism. =A0I also suggested improving the security section to include some for= m of authentication since you do not want a) the obvious malicious cases to= happen, but also b) the unauthorized (often mistaken) case to happen and l= ock-out a network path.

=A0 =A0 =A0 =A0--Tom


On Oct 5, 2011, at 3:55 PM, Greg Mirsky wrote:

> Dear All,
> the latest version of LI/LB in MPLS-TP OAM defines format only of Lock= Instruct. It is my understanding that unlocking can be done via the manage= ment plane and will not be result of timed out LI OAM messages. I think tha= t since a transport path can be locked via OAM command it is logical to hav= e a way to unlock it through OAM as well. UnLock function can be signaled b= y allocating one of Reserved bits in LI OAM message. Obviously such change = will require updates to the document.
>
> Regards,
> Greg
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls


--20cf30781396e5f1b904ae92d5b7-- From Alexander.Vainshtein@ecitele.com Wed Oct 5 13:14:26 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962A81F0C38; Wed, 5 Oct 2011 13:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.455 X-Spam-Level: X-Spam-Status: No, score=-4.455 tagged_above=-999 required=5 tests=[AWL=0.748, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uhc+CShjyBzW; Wed, 5 Oct 2011 13:14:25 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id E2A021F0C36; Wed, 5 Oct 2011 13:14:24 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1317845851!19897604!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.4.1; banners=-,-,- Received: (qmail 10589 invoked from network); 5 Oct 2011 20:17:32 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-6.tower-182.messagelabs.com with SMTP; 5 Oct 2011 20:17:32 -0000 X-AuditID: 93eaf2e7-b7c60ae0000066f0-b3-4e8cc9601f2d Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 86.DD.26352.069CC8E4; Wed, 5 Oct 2011 23:17:20 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Wed, 5 Oct 2011 22:17:30 +0200 From: Alexander Vainshtein To: D'Alessandro Alessandro Gerardo , "stbryant@cisco.com" Date: Wed, 5 Oct 2011 22:17:30 +0200 Thread-Topic: unresolved technical concerns Thread-Index: AcyDftrXxysabIfuTL2UhQPyTTWf/wAG0fFI Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTW0wTQRTNdLd1qSyuldqBaNysBqIGQn2lVWv8UIMvEFFj9EPWdmw3tNum Wx9gjBhNFAPGB0SpGnxUwysiqAhoYq0aBR9ojLEay4eCxvoMMYASwVlWEeN8TM7ce849M5N7 KUJXOCKREkQf8oq8k9NoySPRrm8pOS1FGWk3g8mm3qIwYbp3/hZpeltXTppenqtUmx51ngDz 1eklfXXq9EDguyq94lIlSN/zqHjECnJdAZjLi6Lbx/sQa0OS1cKt8ApbeGsexwo2C2fkWI+T tyIXEn0Wjvd4kGjj5mnZ/9ZcTBNEFolWt00Q7RZucXZmisk005xi5OYlTTROn6Nd5RAkFqW4 eMHJupAk8XbE4kjOZcLRXhMEngfjtwWqGjQF4CTcD2IoyMyAZ8ONGgWPhY/bazHWUjrmBoDP 7l4klUMpgKHbEbXM0jAWWF8dGVTEM/lw1/OgSsYEI8Eju48OckhmEjzQfR/IeAwzBV540AIU /lR47Gq1SsHTYNmLBowpimay4InPGXJYx6yGX8pKBykxzBoYCbUSMgb4cj2tNb+tDPBlR7lK uTQDA9fbCAXr4fs3/WqFr4ev9tYChZ8Kw6UlGgVPhedPfxjk08xo2FLWQSraBHizIkweBAb/ MAv/MLl/mNw/TH4KkFVALzg9vo0ue5oxFVkFH3KiVKvbVQ+U5nnXCH6UTwoBhgJcLM0eL8rQ qfktUp4rBBIoFaenu5twKG6j25bn4CXHBu9mJ5JCAFIEF09nbsU52sbn5SOv+0/KhD/5EJE4 0urGbSr6NkxPS/vnwBnoTuvH5TrGjpsuFyEP8v6RjqMoDtLRZlx1tBfZ0bZNgtP3N62iYmTn WOzcLnNoycO7JMGu5FuBmSosfnMPUO/7OvFe/xPvOlJ0iyjRQDfLAkYWODaLQzXlCdo5MDAQ BQb8/jF0jcyKxfM1VDWKDVXYEEUKZUM8KEOpxAIQdB8M3p/RFbzT1Ls9J9e/m589e0cgflbJ of7Qw3Nr/ct6q5/uLczd2ZMVt6RuZULX3ar6fT19+isL/e8OH+6I42vbotKZj93Z2Q1d5qXm XEN+0/rLtNR/zRg3YUEy8RWYpz1MStY/uZGpnexwjIp8et3ZcrJtwGt5QTYsKg6vbbvIkZKD N04hvBL/C4OdKmscBAAA Cc: "ietf@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] unresolved technical concerns X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 20:14:26 -0000 Dear Alessandro, Lots of thanks for a prompt response. Unfortunately your response does not really help (at least, me) to identify= even a single specific technical issue. You may attribute it to my faulty memory, but I could not remember any. Presenting these cocerns in the form of an I-D as suggested by Stewart would be the right first step. My 2c Sasha ________________________________________ From: D'Alessandro Alessandro Gerardo [alessandro.dalessandro@telecomitalia.= it] Sent: Wednesday, October 05, 2011 6:54 PM To: stbryant@cisco.com; Alexander Vainshtein Cc: adrian@olddog.co.uk; mpls@ietf.org; ietf@ietf.org Subject: unresolved technical concerns Dear Stewart, Dear Sasha, I think there are already enough contributions in that direction I (with man= y other experts) contributed to in the form of IETF mailing list discussion= and ITU-T liaisons. Unfortunately I regret to say that some questions for c= larification and concerns risen in those emails (for sure some of mine) stil= l remain without an answer. At the same time, some comments provided by ITU-= T liaisons still remain unresolved. Best regards, Alessandro ------------------------------------------------------------------ Telecom Italia Alessandro D'Alessandro Transport Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -----Messaggio originale----- Da: Stewart Bryant [mailto:stbryant@cisco.com] Inviato: mercoled=EC 5 ottobre 2011 12:24 A: D'Alessandro Alessandro Gerardo Cc: adrian@olddog.co.uk; mpls@ietf.org; ietf@ietf.org Oggetto: Re: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) t= o Informational RFC On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote: > major unresolved technical concerns Alessandro Please can I suggest that you write an internet draft detailing these "major= unresolved technical concerns" so that we can all understand them. Such a draft needs to be technical, and describe the actions that the networ= k operator is unable to perform, or the fault cases that they are unable to= diagnose using the OAM defined in the IETF RFCs, or late stage WG drafts. Alternatively if you are referring to a bug in the MPLS-TP OAM protocols, yo= u need to tell the community what it is. I believe that this request has been made a number of times, in various for= ums, and, as far as I know, no document has yet been produced. An argument of the form "you must standardize what I want" will not fly. What is needed is a very clear technical definition of the iss= ue(s). When we have the "major unresolved technical concerns" on the table, we will be in a position to determine the best disposition of= those issues. Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, please delete this message and any attachments and advise the sender= by return e-mail, Thanks. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From lufang@cisco.com Wed Oct 5 13:18:24 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C86111E80E2; Wed, 5 Oct 2011 13:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 27kziMewuvEa; Wed, 5 Oct 2011 13:18:22 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C46DB1F0C62; Wed, 5 Oct 2011 13:18:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=17592; q=dns/txt; s=iport; t=1317846091; x=1319055691; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=qNk3Sn3IC8HEQXyqywMhK22vBzt8Fi+/sYZIaLEV6Cg=; b=UwNHe2xUcOAshZOIqBvvGDdrrESO9IKzgJV/ze0IbXZlsUenvMPMqoIo qbIKNi3Blc6yaybrdT7j/eykIfHAVutN77ahOkGOSXNKDn8Q868xlSPMf THZGkK2lDAMTCtvL3NBWw+SuqiHKdkuhXrh0M1IgMn+7kituGJAz/Vyyx c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUAADe7jE6tJXG+/2dsb2JhbAA/A4RtlBaOHHiBBYFTAQEBAQIBAQEBDwEQDQQzBxAHAgICAQYCEQQBAQMCBgYTBAECAgIBARkMHwYCAQgBAQQBEggTB4dbBph8AYxBkVgCgSuCaYF/M2EEh3yRIYwy X-IronPort-AV: E=Sophos;i="4.68,493,1312156800"; d="scan'208";a="26328585" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 05 Oct 2011 20:21:30 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p95KLUou024690; Wed, 5 Oct 2011 20:21:30 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 15:21:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Wed, 5 Oct 2011 15:20:58 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25070063A5@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?UTF-8?B?W21wbHNdIOetlOWkjTogIOWbnuWkje+8miAgUjogRlc6IExhc3QgQ2Fs?= =?UTF-8?B?bDogPGRyYWZ0LXNwcmVjaGVyLW1wbHMtdHAtb2FtLWM=?= =?UTF-8?B?b25zaWRlcmF0aW9ucy0wMS50eHQ+IChUaGUgUmVhc28=?= =?UTF-8?B?bnMgZm9yIFNlbGVjdGluZyBhIFNpbmdsZSBTb2x1dGk=?= =?UTF-8?B?b24gZm9yIE1QTFMtVFAgT0FNKSB0byBJbmZvcm1hdGk=?= =?UTF-8?B?b25hbCBSRkM=?= Thread-Index: AcyDbrGcRr/Mm13DTQKNbEVGehPcOQAKJrSA References: <1317815466.64710.YahooMailClassic@web15608.mail.cnb.yahoo.com> From: "Luyuan Fang (lufang)" To: , , , X-OriginalArrivalTime: 05 Oct 2011 20:21:30.0177 (UTC) FILETIME=[5DFB0310:01CC839C] Subject: Re: [mpls] =?utf-8?b?562U5aSNOiAg5Zue5aSN77yaICBSOiBGVzogTGFzdCBDYWxs?= =?utf-8?q?=3A_=3Cdraft-sprecher-mpls-tp-oam-considerations-01=2Etx?= =?utf-8?q?t=3E_=28The_Reasons_for_Selecting_a_Single_Solution_for_?= =?utf-8?q?MPLS-TP_OAM=29_to_Informational_RFC?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 20:18:24 -0000 SmlhbiwNCg0KU2VlIGluLWxpbmUuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YNCj4geWFuZy5qaWFuOTBAenRlLmNvbS5jbg0KPiBTZW50OiBXZWRuZXNk YXksIE9jdG9iZXIgMDUsIDIwMTEgMTA6NTQgQU0NCj4gVG86IGlldGZAaWV0Zi5vcmc7IG1wbHNA aWV0Zi5vcmc7IG1wbHMtYm91bmNlc0BpZXRmLm9yZ0xhcnJ5DQo+IFN1YmplY3Q6IFttcGxzXSDn rZTlpI06IOWbnuWkje+8miBSOiBGVzogTGFzdCBDYWxsOiA8ZHJhZnQtc3ByZWNoZXItbXBscy10 cC0NCj4gb2FtLWNvbnNpZGVyYXRpb25zLTAxLnR4dD4gKFRoZSBSZWFzb25zIGZvciBTZWxlY3Rp bmcgYSBTaW5nbGUgU29sdXRpb24NCj4gZm9yIE1QTFMtVFAgT0FNKSB0byBJbmZvcm1hdGlvbmFs IFJGQw0KPiANCj4gRGVhciBBbGwsDQo+IA0KPiBJIGRvIG5vdCBzdXBwb3J0IGVpdGhlci4NCj4g DQo+IEluIHNlY3Rpb24gMy41Og0KPiBJZiB0d28gTVBMUyBPQU0gcHJvdG9jb2xzIHdlcmUgdG8g YmUgZGVwbG95ZWQgd2Ugd291bGQgaGF2ZSB0byBjb25zaWRlcg0KPiB0aHJlZSBwb3NzaWJsZSBz Y2VuYXJpb3M6DQo+IDEpIElzb2xhdGlvbiBvZiB0aGUgbmV0d29yayBpbnRvIHR3byBpbmNvbXBh dGlibGUgYW5kIHVuY29ubmVjdGVkDQo+IGlzbGFuZHMuDQo+IA0KPiBUd28gT0FNIHNvbHV0aW9u cyBoYXZlIGJlZW4gZGlzY3Vzc2VkIGZvciBhIGxvbmcgdGltZSBpbiBib3RoIElUVS1UIGFuZA0K PiBJRVRGLg0KUmVwZWF0aW5nIG1vcmUgdGltZXMgZG9lcyBub3QgbWFrZSB0aGUgYXJndW1lbnQg YmVjb21pbmcgY29ycmVjdC4gDQpJdCB3YXN0ZWQgYSBsb3Qgb2YgcGVvcGxlIGEgbG90IG9mIHRp bWUuDQoNCj4gRWFjaCBzb2x1dGlvbiBoYXMgdGhlaXIgb3duIHN1cHBvcnRlcnMgaW5jdWxkaW5n IGNhcnJpZXJzIGFuZCB2ZW5kb3JzLg0KPiBTbyBJIGRvbid0IHRoaW5rIHRoZXJlIGlzIGFueSBp bnRlcndvcmtpbmcgaXNzdWUgYmV0d2VlbiB0d28gT0FNDQo+IHNvbHV0aW9ucy4NCg0KPiBDYXJy aWVyIHdpbGwgc2VsZWN0IG9uZSBPQU0gc29sdXRpb24sIEEgb3IgQiwgaW4gdGhlaXIgbmV0d29y ay4NCj4gTm8gbmVlZCB0byBzZWxlY3QgQSBhbmQgQiBhdCBvbmUgbmV0d29yayBhdCB0aGUgc2Ft ZSB0aW1lLg0KPiANCg0KRG9uJ3QgdGhpbmsgYW55b25lIHNhaWQgdGhleSBpbnRlbmRlZCB0byBr ZWVwIGVhY2ggb2YgdGhlaXIgbmV0d29ya3MvaXNsYW5kcyBzdGF5IGZvcmV2ZXIgaXNvbGF0ZWQu DQpUd28gc29sdXRpb25zIGJyaW5nIGluIGFkZGl0aW9uYWwgaW50ZXItb3AgY29tcGxpY2F0aW9u cyBpcyBhIGZhY3QuDQoNCj4gUmVzcGVjdCB0aGVpciBvd24gc2VsZWN0aW9uIGFuZCBsaXN0ZW4g dG8gdGhlaXIgcmVxdWlyZW1lbnRzLCBwbGVhc2UuDQo+IA0KDQpGdWxseSByZXNwZWN0IGluZGl2 aWR1YWwgcHJvdmlkZXIncyBjaG9pY2Ugb2YgdGVjaG5vbG9neSwgdGhhdCBpcyBhIHNlcGFyYXRl IG1hdHRlciBmcm9tIHN0YW5kYXJkcy4NCldlIGFyZSB0YWxraW5nIGFib3V0IElFVEYgcmVxdWly ZW1lbnRzIGhlcmUuIFdoaWNoIHJlcXVpcmVtZW50IHN0YXRlZCBpbiB0aGUgUkZDcyBhcmUgbm90 IHNhdGlzZmllZCBieSB0aGUgc2luZ2UgT0FNIHNvbHV0aW9uIGRlZmluZWQgaW4gSUVURj8NCg0K PiANCj4gQmVzdCByZWdhcmRzLA0KPiANCj4gSmlhbg0KPiANCj4NClRoYW5rcywNCkx1eXVhbg0K IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAgICAgICAgICAgICAgTGFycnkNCj4gICAgICAg ICAgICAgIDxsYXJyeWxpODg4QHlhDQo+ICAgICAgICAgICAgICBob28uY29tLmNuPg0KPiDmlLbk u7bkuroNCj4gICAgICAgICAgICAgIOWPkeS7tuS6ujogICAgICAgICAgICAgICAgImFkcmlhbkBv bGRkb2cuY28udWsiDQo+ICAgICAgICAgICAgICBtcGxzLWJvdW5jZXNAaSAgICAgICAgIDxhZHJp YW5Ab2xkZG9nLmNvLnVrPiwNCj4gIm1wbHNAaWV0Zi5vcmciDQo+ICAgICAgICAgICAgICBldGYu b3JnICAgICAgICAgICAgICAgIDxtcGxzQGlldGYub3JnPiwgImlldGZAaWV0Zi5vcmciDQo+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxpZXRmQGlldGYub3JnPiwgRCdBbGVz c2FuZHJvDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFsZXNzYW5kcm8g R2VyYXJkbw0KPiAgICAgICAgICAgICAgMjAxMS0xMC0wNQ0KPiA8YWxlc3NhbmRyby5kYWxlc3Nh bmRyb0B0ZWxlY29taXRhbGlhLg0KPiAgICAgICAgICAgICAgMTk6NTEgICAgICAgICAgICAgICAg ICBpdD4NCj4gDQo+IOaKhOmAgQ0KPiANCj4gDQo+IOS4u+mimA0KPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBbbXBsc10g5Zue5aSN77yaICBSOiBGVzogTGFzdCBDYWxsOg0K PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZHJhZnQtc3ByZWNoZXItbXBs cy10cC1vYW0tDQo+IGNvbnNpZGVyYXQNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgaW9ucy0wMS50eHQ+IChUaGUgUmVhc29ucyBmb3INCj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgU2VsZWN0aW5nIGEgU2luZ2xlIFNvbHV0aW9uIGZvcg0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNUExTLVRQIE9BTSkgdG8gSW5mb3JtYXRp b25hbCBSRkMNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IERlYXIg YWxsLA0KPiANCj4gICAgICBTbyBtYW55IG11bHRpcGxlIHNvbHV0aW9uIGNhc2VzIGp1c3Qgc2hv dyB0aGUgd2F5IHRoYXQgdGhlIHdvcmxkDQo+IGFuZA0KPiB0ZWNobm9sb2d5IHdvcmtzLiBLaWxs aW5nIGEgc29sdXRpb24gcm91Z2hseSBicmluZ3MgbW9yZSBkYW1hZ2UgdG8gdGhlDQo+IGluZHVz dHJ5Lg0KPiANCj4gICAgICBTZWN0aW9uIDMuNiBkaXNjdXNzZXMgdGhlIGVsZW1lbnRzIG9mIHRo ZSBjaG9pY2Ugb2Ygc29sdXRpb25zLg0KPiBDdXJyZW50DQo+IGFwcGxpY2F0aW9uIGFuZCBkZXBs b3ltZW50IHNob3VsZCBiZSBjb25zaWRlcmVkLiBJbiBDaGluYSBNb2JpbGUsIG1vcmUNCj4gdGhh bg0KPiAzMzAsMDAwIFBUTiBib3ggYXJlL3dpbGwgYmFzZWQgb24gRy44MTEzLjEuDQo+IA0KPiAg ICAgIFRETSBQVyBnaXZlcyBhIGdvb2QgZXhhbXBsZS4gRy44MTEzLjEgYmFzZWQgT0FNIGlzIHJl bGF0aXZlIHNpbXBsZQ0KPiBhbmQNCj4gbWF0dXJlIGFuZCB3aWRlbHkgZGVwbG95ZWQgYW5kIHNo b3VsZCBiZSB0aGUgc3RhbmRhcmQuDQo+IA0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiANCj4gICAg ICAgICAgSGFuIExpDQo+IA0KPiAtLS0gMTHlubQxMOaciDXml6XvvIzlkajkuIksIEQnQWxlc3Nh bmRybyBBbGVzc2FuZHJvIEdlcmFyZG8NCj4gPGFsZXNzYW5kcm8uZGFsZXNzYW5kcm9AdGVsZWNv bWl0YWxpYS5pdD4g5YaZ6YGT77yaDQo+IA0KPiA+IOWPkeS7tuS6ujogRCdBbGVzc2FuZHJvIEFs ZXNzYW5kcm8gR2VyYXJkbw0KPiA8YWxlc3NhbmRyby5kYWxlc3NhbmRyb0B0ZWxlY29taXRhbGlh Lml0Pg0KPiA+IOS4u+mimDogW21wbHNdIFI6IEZXOiBMYXN0IENhbGw6DQo+IDxkcmFmdC1zcHJl Y2hlci1tcGxzLXRwLW9hbS1jb25zaWRlcmF0aW9ucy0wMS50eHQ+IChUaGUgUmVhc29ucyBmb3IN Cj4gU2VsZWN0aW5nIGEgU2luZ2xlIFNvbHV0aW9uIGZvciBNUExTLVRQIE9BTSkgdG8gSW5mb3Jt YXRpb25hbCBSRkMNCj4gPiDmlLbku7bkuro6ICJhZHJpYW5Ab2xkZG9nLmNvLnVrIiA8YWRyaWFu QG9sZGRvZy5jby51az4sICJtcGxzQGlldGYub3JnIg0KPiA8bXBsc0BpZXRmLm9yZz4sICJpZXRm QGlldGYub3JnIiA8aWV0ZkBpZXRmLm9yZz4NCj4gPiDml6XmnJ86IDIwMTHlubQxMOaciDXml6Us 5ZGo5LiJLOS4i+WNiDU6MzgNCj4gPiBEZWFyIGFsbCwNCj4gPiBJIGRvIG5vdCBzdXBwb3J0Lg0K PiA+DQo+ID4gQmFzaWNhbGx5IEkgdGhpbmsgaXQgaXMgc3VwZXJmbHVvdXMgZGVkaWNhdGUgYW4g UkZDIHRvDQo+ID4gc3RhdGUgaXQgaXMgYmV0dGVyIGhhdmluZyBvbmUgc3RhbmRhcmQgaW5zdGVh ZCBvZiB0d28gb25lcw0KPiA+IG9yIG1hbnkuLi4gZm9yIHN1cmUgdGhlIGxvd2VyIGFyZSB0aGUg dmFyaWFudHMgdGhlIGJldHRlciBpcw0KPiA+IGZvciB0aGUgaW5kdXN0cnkgKG9uZSBpcyB0aGUg aWRlYWwpLg0KPiA+DQo+ID4gV2hlbiB0d28gb3IgbW9yZSBzdGFuZGFyZHMgb3IgZGUtZmFjdG8g c3RhbmRhcmRzIGV4aXN0IGl0DQo+ID4gaXMgYmVjYXVzZSB0aGUgcHJvYmxlbSB0aGV5IHNvbHZl IGlzIG5vdCBleGFjdGx5IHRoZSBzYW1lLA0KPiA+IHRoZSB3YXkgdGhleSBzb2x2ZSB0aGUgcHJv YmxlbSBpcyBvcHRpbWl6ZWQgZm9yIGRpZmZlcmVudA0KPiA+IGVudmlyb25tZW50cy9ib3VuZGFy eSBjb25kaXRpb25zIChtb3JlIGVmZmljaWVudCwgbW9yZQ0KPiA+IGVmZmVjdGl2ZSwgZXRjKS4g VGhlcmVmb3JlIGEgc2luZ2xlIHNvbHV0aW9uIGRvZXMgbm90DQo+ID4gbmVjZXNzYXJpbHkgbWVl dCB0aGUgZGlmZmVyZW50IG1hcmtldCByZXF1aXJlbWVudHMuDQo+ID4NCj4gPiBJdCBpcyBmdW5k YW1lbnRhbCB0byBlbnRlciBpbnRvIHRoZSBwcm9ibGVtJ3MgZGV0YWlscw0KPiA+IGJlZm9yZSBt YWtpbmcgY29uc2lkZXJhdGlvbiBhYm91dCB0aGUgYmVzdCB3YXkgdG8gcHJvY2VlZA0KPiA+IChv bmUgc29sdXRpb24sIHR3byBzb2x1dGlvbnMsIG11bHRpcGxlIHNvbHV0aW9ucykgd2hpbHN0IHRo ZQ0KPiA+IGRvY3VtZW50IGNsZWFybHkgZGVjbGFyZXMgaXQgZG9lcyBub3Qgd2FudCB0byBtYWtl IGFueQ0KPiA+IHRlY2huaWNhbCBldmFsdWF0aW9ucy4NCj4gPg0KPiA+IEFmdGVyIG1vcmUgdGhh biB0aHJlZSB5ZWFycyBvZiBkZWJhdGVzIHdpdGhpbiB0aGUgSUVURiBhbmQNCj4gPiBtYWpvciB1 bnJlc29sdmVkIHRlY2huaWNhbCBjb25jZXJucyByaXNlbiBmcm9tIHNvbWUNCj4gPiB0cmFuc3Bv cnQgb3BlcmF0b3JzLCB0aGUgZXhpc3RlbmNlIG9mIHRoaXMgZHJhZnQgaXMgYnkNCj4gPiBpdHNl bGYgdGhlIHN1cmUgc2lnbiB0aGF0IE1QTFMtVFAgT0FNIGlzIGEgY2FzZSB3aGVyZSBhDQo+ID4g c2luZ2xlIHNvbHV0aW9uIGhhcyBub3QgYmUgZm91bmQgdG8gbWVldCBhbGwgdGhlIGRpZmZlcmVu dA0KPiA+IG1hcmtldCByZXF1aXJlbWVudHMuIE90aGVyd2lzZSwgd2h5IGFyZSB3ZSBzdGlsbCBk aXNjdXNzaW5nDQo+ID4gYWJvdXQgaXQuLi4uPw0KPiA+DQo+ID4gVGhlcmVmb3JlIHdlIG11c3Qg YmUgcmVhbGlzdGljIGFuZCB0aGUgbGVzc29ucyBsZWFybmVkIGZyb20NCj4gPiB0aGUgcGFzdCBz aG91bGQgZ3VpZGUgb3VyIGRlY2lzaW9uczogaWYgYSBzb2x1dGlvbiBjYW5ub3QgYmUNCj4gPiBm b3VuZCBmb3Igc2F0aXNmeWluZyBhbGwgdGhlIHJlcXVpcmVtZW50cyBpdCBpcyBiZXR0ZXIgdG8N Cj4gPiBoYXZlIHR3byBzdGFuZGFyZHMgYW5kIGxldCB0aGUgbWFya2V0IGRlY2lkZSBob3cgdG8g ZXhwbG9pdA0KPiA+IHRoZW0uIEFyZcKgIHdlIHJlYWxseSBzdXJlIHRoZSBjb3N0KG1hbnkpIC8g YmVuZWZpdA0KPiA+IChub25lKSBhbmFseXNpcyBkb25lIGluIHNlY3Rpb24gNy41IGlzIHJlYWxp c3RpYz8NCj4gPg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBBbGVzc2FuZHJvDQo+ID4NCj4gPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gPiBUZWxlY29tIEl0YWxpYQ0KPiA+IEFsZXNzYW5kcm8gRCdBbGVzc2FuZHJv DQo+ID4gVHJhbnNwb3J0IElubm92YXRpb24NCj4gPiBWaWEgUmVpc3MgUm9tb2xpLCAyNzQgLSAx MDE0OCBUb3Jpbm8NCj4gPiBwaG9uZTrCoCArMzkgMDExIDIyOCA1ODg3DQo+ID4gbW9iaWxlOiAr MzkgMzM1IDc2NiA5NjA3DQo+ID4gZmF4OiArMzkgMDYgNDE4IDYzOSAwNw0KPiA+DQo+ID4gLS0t LS1NZXNzYWdnaW8gb3JpZ2luYWxlLS0tLS0NCj4gPiBEYTogbXBscy1ib3VuY2VzQGlldGYub3Jn DQo+ID4gW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddDQo+ID4gUGVyIGNvbnRvIGRpIEFk cmlhbiBGYXJyZWwNCj4gPiBJbnZpYXRvOiBsdW5lZMOsIDI2IHNldHRlbWJyZSAyMDExIDIzOjU4 DQo+ID4gQTogbXBsc0BpZXRmLm9yZw0KPiA+IE9nZ2V0dG86IFttcGxzXSBGVzogTGFzdCBDYWxs Og0KPiA+IDxkcmFmdC1zcHJlY2hlci1tcGxzLXRwLW9hbS1jb25zaWRlcmF0aW9ucy0wMS50eHQ+ DQo+ID4gKFRoZSBSZWFzb25zIGZvciBTZWxlY3RpbmcgYSBTaW5nbGUgU29sdXRpb24gZm9yIE1Q TFMtVFANCj4gPiBPQU0pIHRvIEluZm9ybWF0aW9uYWwgUkZDDQo+ID4NCj4gPiBNUExTIFdvcmtp bmcgR3JvdXAsDQo+ID4NCj4gPiBQbGVhc2UgYmUgYXdhcmUgb2YgdGhlIElFVEYgbGFzdCBjYWxs IGFzIHNob3duIGJlbG93LiBUaGUNCj4gPiBkb2N1bWVudCB3YXMgcHJlc2VudGVkIGZvciBwdWJs aWNhdGlvbiBhcyBhbiBpbmRpdmlkdWFsIFJGQw0KPiA+IHdpdGggSUVURiBjb25zZW5zdXMgYW5k IEFEIHNwb25zb3JzaGlwLg0KPiA+DQo+ID4gVGhpcyBkcmFmdCBpcyBjbGVhcmx5IGNsb3NlIGFu ZCByZWxldmFudCB0byB0aGUgd29yayB5b3UNCj4gPiBkbywgYnV0IGFmdGVyIGRpc2N1c3Npbmcg d2l0aCB0aGUgY2hhaXJzIEkgY2FtZSB0byB0aGUNCj4gPiBjb25jbHVzaW9uIHRoYXQgaXQgZG9l cyBub3QgY29tbWVudCBvbiB0aGUgdGVjaG5pY2FsIG9yDQo+ID4gcHJvY2VzcyBkZWNpc2lvbnMg b2YgdGhlIE1QTFMgd29ya2luZyBncm91cHMsIGFuZCBpdCBkb2VzDQo+ID4gbm90IGF0dGVtcHQg dG8gbWFrZSBhbnkgdGVjaG5pY2FsIGV2YWx1YXRpb25zIG9yIGRlZmluaXRpb25zDQo+ID4gd2l0 aGluIHRoZSBzY29wZSBvZiB0aGUgTVBMUyB3b3JraW5nIGdyb3VwLiBJdCBpcyBtb3JlIG9mIGEN Cj4gPiBwaGlsb3NvcGhpY2FsIGFuYWx5c2lzIG9mIHRoZSB3YXkgdGhlIElFVEYgYXBwcm9hY2hl cyB0aGUNCj4gPiAidHdvIHNvbHV0aW9ucyIgcHJvYmxlbSB3aXRoIHNwZWNpYWwgcmVmZXJlbmNl IHRvIE1QTFMtVFANCj4gPiBPQU0uDQo+ID4NCj4gPiBUaHVzLCBJIGFtIGFjY2VwdGluZyB0aGUg ZG9jdW1lbnQgYXMgQUQgU3BvbnNvcmVkIHJhdGhlcg0KPiA+IHRoYW4gcnVubmluZyBpdCB0aHJv dWdoIHRoZSBNUExTIHdvcmtpbmcgZ3JvdXAuIE15IHJlYXNvbmluZw0KPiA+IGlzIHRoYXQgdGhl IHdvcmtpbmcgZ3JvdXAgaGFzIGdvdCBwbGVudHkgdG8gZG8gd29ya2luZyBvbg0KPiA+IHRlY2hu aWNhbCBpc3N1ZXMgd2l0aG91dCBiZWluZyBkaXZlcnRlZCBpbnRvIHdpZGVyIElFVEYNCj4gPiBw aGlsb3NvcGh5Lg0KPiA+DQo+ID4gQXMgYW4gQUQgU3BvbnNvcmVkIEktRCBpdCBpcyBzdWJqZWN0 IHRvIGEgZm91ciB3ZWVrIElFVEYNCj4gPiBsYXN0IGNhbGwuIFRoYXQgaXMgcGxlbnR5IG9mIG9w cG9ydHVuaXR5IGZvciBldmVyeW9uZSB0bw0KPiA+IGNvbW1lbnQgYW5kIGV4cHJlc3MgdGhlaXIg dmlld3MuIFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMNCj4gPiB0byB0aGUgSUVURiBtYWlsaW5n IGxpc3QgYXMgZGVzY3JpYmVkIGJlbG93LCBvciAoaW4NCj4gPiBleGNlcHRpb25hbCBjaXJjdW1z dGFuY2VzKSBkaXJlY3QgdG8gdGhlIElFU0cuDQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gQWRyaWFu DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBpZXRm LWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmcNCj4gPiBbbWFpbHRvOmlldGYtYW5ub3VuY2UtDQo+ ID4gPiBib3VuY2VzQGlldGYub3JnXQ0KPiA+IE9uIEJlaGFsZiBPZiBUaGUgSUVTRw0KPiA+ID4g U2VudDogMjYgU2VwdGVtYmVyIDIwMTEgMjA6NDMNCj4gPiA+IFRvOiBJRVRGLUFubm91bmNlDQo+ ID4gPiBTdWJqZWN0OiBMYXN0IENhbGw6DQo+ID4gPGRyYWZ0LXNwcmVjaGVyLW1wbHMtdHAtb2Ft LWNvbnNpZGVyYXRpb25zLTAxLnR4dD4NCj4gPiA+IChUaGUgUmVhc29ucyBmb3IgU2VsZWN0aW5n IGEgU2luZ2xlIFNvbHV0aW9uIGZvcg0KPiA+IE1QTFMtVFAgT0FNKSB0bw0KPiA+ID4gSW5mb3Jt YXRpb25hbCBSRkMNCj4gPiA+DQo+ID4gPg0KPiA+ID4gVGhlIElFU0cgaGFzIHJlY2VpdmVkIGEg cmVxdWVzdCBmcm9tIGFuIGluZGl2aWR1YWwNCj4gPiBzdWJtaXR0ZXIgdG8NCj4gPiA+IGNvbnNp ZGVyIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnQ6DQo+ID4gPiAtICdUaGUgUmVhc29ucyBmb3IgU2Vs ZWN0aW5nIGEgU2luZ2xlIFNvbHV0aW9uIGZvcg0KPiA+IE1QTFMtVFAgT0FNJw0KPiA+ID7CoMKg wqA8ZHJhZnQtc3ByZWNoZXItbXBscy10cC1vYW0tY29uc2lkZXJhdGlvbnMtMDEudHh0Pg0KPiA+ IGFzIGFuDQo+ID4gPiBJbmZvcm1hdGlvbmFsIFJGQw0KPiA+ID4NCj4gPiA+IFRoZSBJRVNHIHBs YW5zIHRvIG1ha2UgYSBkZWNpc2lvbiBpbiB0aGUgbmV4dCBmZXcNCj4gPiB3ZWVrcywgYW5kIHNv bGljaXRzDQo+ID4gPiBmaW5hbCBjb21tZW50cyBvbiB0aGlzIGFjdGlvbi4gUGxlYXNlIHNlbmQg c3Vic3RhbnRpdmUNCj4gPiBjb21tZW50cyB0byB0aGUNCj4gPiA+IGlldGZAaWV0Zi5vcmcNCj4g PiBtYWlsaW5nIGxpc3RzIGJ5IDIwMTEtMTAtMjQuIEV4Y2VwdGlvbmFsbHksIGNvbW1lbnRzIG1h eQ0KPiA+ID4gYmUgc2VudCB0byBpZXNnQGlldGYub3JnDQo+ID4gaW5zdGVhZC4gSW4gZWl0aGVy IGNhc2UsIHBsZWFzZSByZXRhaW4gdGhlDQo+ID4gPiBiZWdpbm5pbmcgb2YgdGhlIFN1YmplY3Qg bGluZSB0byBhbGxvdyBhdXRvbWF0ZWQNCj4gPiBzb3J0aW5nLg0KPiA+ID4NCj4gPiA+IEFic3Ry YWN0DQo+ID4gPg0KPiA+ID7CoCDCoCBUaGUgTVBMUyBUcmFuc3BvcnQgUHJvZmlsZSAoTVBMUy1U UCkgaXMgYQ0KPiA+IHByb2ZpbGUgb2YgTVBMUyB0ZWNobm9sb2d5DQo+ID4gPsKgIMKgIGZvciB1 c2UgaW4gdHJhbnNwb3J0IG5ldHdvcmsgZGVwbG95bWVudHMuDQo+ID4gVGhhdCBpcywgTVBMUy1U UCBpcyBhIHNldA0KPiA+ID7CoCDCoCBvZiBmdW5jdGlvbnMgYW5kIGZlYXR1cmVzIHNlbGVjdGVk IGZyb20NCj4gPiB0aGUgd2lkZXIgTVBMUyB0b29sc2V0IGFuZA0KPiA+ID7CoCDCoCBhcHBsaWVk IGluIGEgY29uc2lzdGVudCB3YXkgdG8gbWVldCB0aGUNCj4gPiBuZWVkcyBhbmQgcmVxdWlyZW1l bnRzIG9mDQo+ID4gPsKgIMKgIG9wZXJhdG9ycyBvZiBwYWNrZXQgdHJhbnNwb3J0IG5ldHdvcmtz Lg0KPiA+ID4NCj4gPiA+wqAgwqAgRHVyaW5nIHRoZSBwcm9jZXNzIG9mIGRldmVsb3BtZW50IG9m IHRoZQ0KPiA+IHByb2ZpbGUsIGFkZGl0aW9ucyB0byB0aGUNCj4gPiA+wqAgwqAgTVBMUyB0b29s c2V0IGhhdmUgYmVlbiBtYWRlIHRvIGVuc3VyZQ0KPiA+IHRoYXQgdGhlIHRvb2xzIGF2YWlsYWJs ZSBtZXQNCj4gPiA+wqAgwqAgdGhlIHJlcXVpcmVtZW50cy4gVGhlc2UgYWRkaXRpb25zIHdlcmUN Cj4gPiBtb3RpdmF0ZWQgYnkgTVBMUy1UUCwgYnV0IGZvcm0NCj4gPiA+wqAgwqAgcGFydCBvZiB0 aGUgd2lkZXIgTVBMUyB0b29sc2V0IHN1Y2ggdGhhdA0KPiA+IGFueSBvZiB0aGVtIGNvdWxkIGJl IHVzZWQgaW4NCj4gPiA+wqAgwqAgYW55IE1QTFMgZGVwbG95bWVudC4NCj4gPiA+DQo+ID4gPsKg IMKgIE9uZSBtYWpvciBzZXQgb2YgYWRkaXRpb25zIHByb3ZpZGVzDQo+ID4gZW5oYW5jZWQgc3Vw cG9ydCBmb3IgT3BlcmF0aW9ucywNCj4gPiA+wqAgwqAgQWRtaW5pc3RyYXRpb24sIGFuZCBNYWlu dGVuYW5jZSAoT0FNKS4NCj4gPiBUaGlzIGVuYWJsZXMgZmF1bHQgbWFuYWdlbWVudA0KPiA+ID7C oCDCoCBhbmQgcGVyZm9ybWFuY2UgbW9uaXRvcmluZyB0byB0aGUgbGV2ZWwNCj4gPiBuZWVkZWQg aW4gYSB0cmFuc3BvcnQNCj4gPiA+wqAgwqAgbmV0d29yay4gTWFueSBzb2x1dGlvbnMgYW5kIHBy b3RvY29sDQo+ID4gZXh0ZW5zaW9ucyBoYXZlIGJlZW4gcHJvcG9zZWQgdG8NCj4gPiA+wqAgwqAg YWRkcmVzcyB0aGVzZSBPQU0gcmVxdWlyZW1lbnRzLCBhbmQgdGhpcw0KPiA+IGRvY3VtZW50IHNl dHMgb3V0IHRoZQ0KPiA+ID7CoCDCoCByZWFzb25zIGZvciBzZWxlY3RpbmcgYSBzaW5nbGUsIGNv aGVyZW50DQo+ID4gc2V0IG9mIHNvbHV0aW9ucyBmb3INCj4gPiA+wqAgwqAgc3RhbmRhcmRpemF0 aW9uLg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBUaGUgZmlsZSBjYW4gYmUgb2J0YWluZWQgdmlhDQo+ ID4gPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNwcmVjaGVyLW1wbHMt dHAtb2FtLQ0KPiBjb25zaWRlcmF0aQ0KPiA+ID4gb25zLw0KPiA+ID4NCj4gPiA+IElFU0cgZGlz Y3Vzc2lvbiBjYW4gYmUgdHJhY2tlZCB2aWENCj4gPiA+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtc3ByZWNoZXItbXBscy10cC1vYW0tDQo+IGNvbnNpZGVyYXRpDQo+ID4g PiBvbnMvDQo+ID4gPg0KPiA+ID4NCj4gPiA+IE5vIElQUiBkZWNsYXJhdGlvbnMgaGF2ZSBiZWVu IHN1Ym1pdHRlZCBkaXJlY3RseSBvbg0KPiA+IHRoaXMgSS1ELg0KPiA+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IElFVEYtQW5ub3VuY2Ug bWFpbGluZyBsaXN0DQo+ID4gPiBJRVRGLUFubm91bmNlQGlldGYub3JnDQo+ID4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYtYW5ub3VuY2UNCj4gPg0KPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbXBscyBt YWlsaW5nIGxpc3QNCj4gPiBtcGxzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4NCj4gPiBRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9p IGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkNCj4gPiBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNv bmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8NCj4gPiBxdWFsc2lhc2kgYWx0cmEg YXppb25lIGRlcml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZQ0KPiA+IGluZm9ybWF6 aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlDQo+ID4gcmlj ZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZQ0KPiA+ IHByZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBk aQ0KPiA+IHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCj4gPg0KPiA+ IFRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkN Cj4gPiBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRy ZXNzZWUocykNCj4gPiBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1 c2UgYnkgYW55Ym9keQ0KPiA+IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LA0KPiA+IHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZQ0KPiA+IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUt bWFpbCwgVGhhbmtzLg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+IG1wbHNAaWV0Zi5vcmcN Cj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gPg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtcGxzIG1h aWxpbmcgbGlzdA0KPiBtcGxzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbXBscw0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBO b3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsDQo+IGlzIHNvbGVs eSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwNCj4gY29t bXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9i bGlnYXRlZCB0bw0KPiBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBk aXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcw0KPiBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4N Cj4gVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZp ZGVudGlhbCBhbmQNCj4gaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkNCj4gYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5DQo+IHRoZSBvcmlnaW5h dG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBh cmUNCj4gdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KPiBUaGlzIG1lc3NhZ2UgaGFz IGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtDQo+IHN5 c3RlbS4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From tnadeau@lucidvision.com Wed Oct 5 13:44:29 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B22D11E8116 for ; Wed, 5 Oct 2011 13:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 A+4ngirGg9ZQ for ; Wed, 5 Oct 2011 13:44:28 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 48A2E11E8109 for ; Wed, 5 Oct 2011 13:44:27 -0700 (PDT) Received: from [10.83.137.176] (mobile-166-137-139-005.mycingular.net [166.137.139.5]) by lucidvision.com (Postfix) with ESMTP id 404671EA6E41; Wed, 5 Oct 2011 16:47:35 -0400 (EDT) References: <6082DC91-86B1-4E2B-82BE-AE039795126F@lucidvision.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8L1) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-90-238036893 Message-Id: X-Mailer: iPhone Mail (8L1) From: Thomas Nadeau Date: Wed, 5 Oct 2011 16:47:27 -0400 To: Greg Mirsky Cc: "mpls@ietf.org" Subject: Re: [mpls] Lock Instruction functionality in MPLS OAM X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 20:44:29 -0000 --Apple-Mail-90-238036893 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 5, 2011, at 4:13 PM, Greg Mirsky wrote: > Hi Tom, > I think that originally LI message was serving as keepalive but it changed= when we realized that LI messages are not forwarded past MP set in the Loop= back mode. Because of the an intermediate node being in the Loopback it is d= ifficult to have meaningful dead timer associated with Lock state. > I completely agree with need of Authentication. Perhaps we can define an A= uthentication TLV and specify its applicability in MPLS-TP OAM? this is a good idea. >=20 > Regards, > Greg >=20 > On Wed, Oct 5, 2011 at 1:01 PM, Thomas Nadeau wr= ote: >=20 > I have made similar comments privately to the document's editors ab= out a month ago, so I agree that these changes need to be made. They need t= o implement some sort of default unlocking (timeout) mechanism. I also sugg= ested improving the security section to include some form of authentication s= ince you do not want a) the obvious malicious cases to happen, but also b) t= he unauthorized (often mistaken) case to happen and lock-out a network path.= >=20 > --Tom >=20 >=20 > On Oct 5, 2011, at 3:55 PM, Greg Mirsky wrote: >=20 > > Dear All, > > the latest version of LI/LB in MPLS-TP OAM defines format only of Lock I= nstruct. It is my understanding that unlocking can be done via the managemen= t plane and will not be result of timed out LI OAM messages. I think that si= nce a transport path can be locked via OAM command it is logical to have a w= ay to unlock it through OAM as well. UnLock function can be signaled by allo= cating one of Reserved bits in LI OAM message. Obviously such change will re= quire updates to the document. > > > > Regards, > > Greg > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 --Apple-Mail-90-238036893 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8




On Oct 5, 2011, at 4:13 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Tom,
I think that originally LI message was serving as keepalive but it changed when we realized that LI messages are not forwarded past MP set in the Loopback mode. Because of the an intermediate node being in the Loopback it is difficult to have meaningful dead timer associated with Lock state.
I completely agree with need of Authentication. Perhaps we can define an Authentication TLV and specify its applicability in MPLS-TP OAM?

this is a good idea.


Regards,
Greg

On Wed, Oct 5, 2011 at 1:01 PM, Thomas Nadeau <tnadeau@lucidvision.com> wrote:

       I have made similar comments privately to the document's editors about a month ago, so I agree that these changes need to be made.   They need to implement some sort of default unlocking (timeout) mechanism.  I also suggested improving the security section to include some form of authentication since you do not want a) the obvious malicious cases to happen, but also b) the unauthorized (often mistaken) case to happen and lock-out a network path.

       --Tom


On Oct 5, 2011, at 3:55 PM, Greg Mirsky wrote:

> Dear All,
> the latest version of LI/LB in MPLS-TP OAM defines format only of Lock Instruct. It is my understanding that unlocking can be done via the management plane and will not be result of timed out LI OAM messages. I think that since a transport path can be locked via OAM command it is logical to have a way to unlock it through OAM as well. UnLock function can be signaled by allocating one of Reserved bits in LI OAM message. Obviously such change will require updates to the document.
>
> Regards,
> Greg
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls


--Apple-Mail-90-238036893-- From lufang@cisco.com Wed Oct 5 14:08:02 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DFE21F8C33; Wed, 5 Oct 2011 14:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=0.340, 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 Lcf94YBSAufs; Wed, 5 Oct 2011 14:07:55 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 45D4421F8C32; Wed, 5 Oct 2011 14:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=5036; q=dns/txt; s=iport; t=1317849064; x=1319058664; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=RoI2OcFCFNZzx8I38Cs74BcZZwqCf8uo4JuxBnSx4NI=; b=hLU94dDiwzTOZ64CGrutJ81NJVsp3L0clCceObJMRR9YyFf++wWnzSi2 TD+p7nWG0tGZ5waSg1QcrGvnqqwW+rehrob+kht11Fs/eElsg7rcbvJzS EtUKDfrTtRMTDEjRV+NKcRFw4RA79CpBlcmZFyUtTPqZgzHq9k/bfolqK E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUAAJzGjE6tJXG8/2dsb2JhbAA4BwOZBo8UgQWBUwEBAQEDAQEBDwEdOwMGBQwCAgIBCBEEAQEBCgYXAQYBGgwfCQgBAQQBEggMBweHYZhcAZ4WAoN6GoIyYQSHTDCRIYwy X-IronPort-AV: E=Sophos;i="4.68,493,1312156800"; d="scan'208";a="26347401" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 05 Oct 2011 21:11:03 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p95LB31n023579; Wed, 5 Oct 2011 21:11:03 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 16:11:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Oct 2011 16:10:39 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25070063FD@XMB-RCD-201.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] unresolved technical concerns Thread-Index: AcyDftrXxysabIfuTL2UhQPyTTWf/wAG0fFIAAIR6SA= References: From: "Luyuan Fang (lufang)" To: "Alexander Vainshtein" , "D'Alessandro Alessandro Gerardo" , "Stewart Bryant (stbryant)" X-OriginalArrivalTime: 05 Oct 2011 21:11:03.0110 (UTC) FILETIME=[49FC9660:01CC83A3] Cc: mpls@ietf.org, ietf@ietf.org Subject: Re: [mpls] unresolved technical concerns X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 21:08:02 -0000 Yep. We are going in circles again. We need to see technical details on the issues documented in an I-D as = Stewart suggested.=20 Don't remember seeing such document either. Luyuan > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of > Alexander Vainshtein > Sent: Wednesday, October 05, 2011 4:18 PM > To: D'Alessandro Alessandro Gerardo; Stewart Bryant (stbryant) > Cc: ietf@ietf.org; mpls@ietf.org > Subject: Re: [mpls] unresolved technical concerns >=20 >=20 > Dear Alessandro, > Lots of thanks for a prompt response. >=20 > Unfortunately your response does not really help (at least, me) to > identify even a single > specific technical issue. You may attribute it to my faulty memory, > but I could not remember any. Presenting these cocerns in the form > of an I-D as suggested by Stewart would be the right first step. >=20 >=20 > My 2c > Sasha >=20 > ________________________________________ > From: D'Alessandro Alessandro Gerardo > [alessandro.dalessandro@telecomitalia.it] > Sent: Wednesday, October 05, 2011 6:54 PM > To: stbryant@cisco.com; Alexander Vainshtein > Cc: adrian@olddog.co.uk; mpls@ietf.org; ietf@ietf.org > Subject: unresolved technical concerns >=20 > Dear Stewart, Dear Sasha, > I think there are already enough contributions in that direction I > (with many other experts) contributed to in the form of IETF mailing > list discussion and ITU-T liaisons. Unfortunately I regret to say that > some questions for clarification and concerns risen in those emails > (for sure some of mine) still remain without an answer. At the same > time, some comments provided by ITU-T liaisons still remain = unresolved. >=20 > Best regards, > Alessandro >=20 > ------------------------------------------------------------------ > Telecom Italia > Alessandro D'Alessandro > Transport Innovation > Via Reiss Romoli, 274 - 10148 Torino > phone: +39 011 228 5887 > mobile: +39 335 766 9607 > fax: +39 06 418 639 07 >=20 >=20 > -----Messaggio originale----- > Da: Stewart Bryant [mailto:stbryant@cisco.com] > Inviato: mercoled=EC 5 ottobre 2011 12:24 > A: D'Alessandro Alessandro Gerardo > Cc: adrian@olddog.co.uk; mpls@ietf.org; ietf@ietf.org > Oggetto: Re: [mpls] R: FW: Last Call: considerations-01.txt> (The Reasons for Selecting a Single Solution = for > MPLS-TP OAM) to Informational RFC >=20 > On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote: > > major unresolved technical concerns >=20 > Alessandro >=20 > Please can I suggest that you write an internet draft detailing these > "major unresolved technical concerns" so that we can all understand > them. >=20 > Such a draft needs to be technical, and describe the actions that the > network operator is unable to perform, or the fault cases that they = are > unable to diagnose using the OAM defined in the IETF RFCs, or late > stage WG drafts. >=20 > Alternatively if you are referring to a bug in the MPLS-TP OAM > protocols, you need to tell the community what it is. >=20 > I believe that this request has been made a number of times, in > various forums, and, as far as I know, no document has yet been > produced. >=20 > An argument of the form "you must standardize what I want" > will not fly. What is needed is a very clear technical definition of > the issue(s). >=20 > When we have the "major unresolved technical concerns" > on the table, we will be in a position to determine the best > disposition of those issues. >=20 > Stewart >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -- > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 >=20 > Questo messaggio e i suoi allegati sono indirizzati esclusivamente = alle > persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. >=20 > This e-mail and any attachments is confidential and may contain > privileged information intended for the addressee(s) only. > Dissemination, copying, printing or use by anybody else is > unauthorised. If you are not the intended recipient, please delete = this > message and any attachments and advise the sender by return e-mail, > Thanks. >=20 >=20 >=20 > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please = inform > us by e-mail, phone or fax, and then delete the original and all = copies > thereof. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From jdrake@juniper.net Wed Oct 5 14:21:47 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B242711E80DB; Wed, 5 Oct 2011 14:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.184 X-Spam-Level: X-Spam-Status: No, score=-6.184 tagged_above=-999 required=5 tests=[AWL=0.415, 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 Aqy-qRLTWZoU; Wed, 5 Oct 2011 14:21:46 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF4811E80C4; Wed, 5 Oct 2011 14:21:46 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP; Wed, 05 Oct 2011 14:24:55 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 5 Oct 2011 14:20:50 -0700 From: John E Drake To: "Luyuan Fang (lufang)" , Alexander Vainshtein , D'Alessandro Alessandro Gerardo , "Stewart Bryant (stbryant)" Date: Wed, 5 Oct 2011 14:20:48 -0700 Thread-Topic: [mpls] unresolved technical concerns Thread-Index: AcyDftrXxysabIfuTL2UhQPyTTWf/wAG0fFIAAIR6SAAAFTy0A== Message-ID: <5E893DB832F57341992548CDBB333163A441514B08@EMBX01-HQ.jnpr.net> References: <238542D917511A45B6B8AA806E875E25070063FD@XMB-RCD-201.cisco.com> In-Reply-To: <238542D917511A45B6B8AA806E875E25070063FD@XMB-RCD-201.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "ietf@ietf.org" Subject: Re: [mpls] unresolved technical concerns X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 21:21:47 -0000 That's because it is *so* much easier to just keep mumbling 'major unresolv= ed technical concerns'. I expect it is something learned in Yoga class.=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Luyuan Fang (lufang) > Sent: Wednesday, October 05, 2011 5:11 PM > To: Alexander Vainshtein; D'Alessandro Alessandro Gerardo; Stewart > Bryant (stbryant) > Cc: mpls@ietf.org; ietf@ietf.org > Subject: Re: [mpls] unresolved technical concerns >=20 > Yep. We are going in circles again. > We need to see technical details on the issues documented in an I-D as > Stewart suggested. > Don't remember seeing such document either. >=20 > Luyuan >=20 >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Alexander Vainshtein > > Sent: Wednesday, October 05, 2011 4:18 PM > > To: D'Alessandro Alessandro Gerardo; Stewart Bryant (stbryant) > > Cc: ietf@ietf.org; mpls@ietf.org > > Subject: Re: [mpls] unresolved technical concerns > > > > > > Dear Alessandro, > > Lots of thanks for a prompt response. > > > > Unfortunately your response does not really help (at least, me) to > > identify even a single > > specific technical issue. You may attribute it to my faulty memory, > > but I could not remember any. Presenting these cocerns in the form > > of an I-D as suggested by Stewart would be the right first step. > > > > > > My 2c > > Sasha > > > > ________________________________________ > > From: D'Alessandro Alessandro Gerardo > > [alessandro.dalessandro@telecomitalia.it] > > Sent: Wednesday, October 05, 2011 6:54 PM > > To: stbryant@cisco.com; Alexander Vainshtein > > Cc: adrian@olddog.co.uk; mpls@ietf.org; ietf@ietf.org > > Subject: unresolved technical concerns > > > > Dear Stewart, Dear Sasha, > > I think there are already enough contributions in that direction I > > (with many other experts) contributed to in the form of IETF mailing > > list discussion and ITU-T liaisons. Unfortunately I regret to say > that > > some questions for clarification and concerns risen in those emails > > (for sure some of mine) still remain without an answer. At the same > > time, some comments provided by ITU-T liaisons still remain > unresolved. > > > > Best regards, > > Alessandro > > > > ------------------------------------------------------------------ > > Telecom Italia > > Alessandro D'Alessandro > > Transport Innovation > > Via Reiss Romoli, 274 - 10148 Torino > > phone: +39 011 228 5887 > > mobile: +39 335 766 9607 > > fax: +39 06 418 639 07 > > > > > > -----Messaggio originale----- > > Da: Stewart Bryant [mailto:stbryant@cisco.com] > > Inviato: mercoled=EC 5 ottobre 2011 12:24 > > A: D'Alessandro Alessandro Gerardo > > Cc: adrian@olddog.co.uk; mpls@ietf.org; ietf@ietf.org > > Oggetto: Re: [mpls] R: FW: Last Call: > considerations-01.txt> (The Reasons for Selecting a Single Solution > for > > MPLS-TP OAM) to Informational RFC > > > > On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote: > > > major unresolved technical concerns > > > > Alessandro > > > > Please can I suggest that you write an internet draft detailing these > > "major unresolved technical concerns" so that we can all understand > > them. > > > > Such a draft needs to be technical, and describe the actions that the > > network operator is unable to perform, or the fault cases that they > are > > unable to diagnose using the OAM defined in the IETF RFCs, or late > > stage WG drafts. > > > > Alternatively if you are referring to a bug in the MPLS-TP OAM > > protocols, you need to tell the community what it is. > > > > I believe that this request has been made a number of times, in > > various forums, and, as far as I know, no document has yet been > > produced. > > > > An argument of the form "you must standardize what I want" > > will not fly. What is needed is a very clear technical definition of > > the issue(s). > > > > When we have the "major unresolved technical concerns" > > on the table, we will be in a position to determine the best > > disposition of those issues. > > > > Stewart > > > > > > > > > > > > > > > > -- > > For corporate legal information go to: > > > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente > alle > > persone indicate. La diffusione, copia o qualsiasi altra azione > > derivante dalla conoscenza di queste informazioni sono rigorosamente > > vietate. Qualora abbiate ricevuto questo documento per errore siete > > cortesemente pregati di darne immediata comunicazione al mittente e > di > > provvedere alla sua distruzione, Grazie. > > > > This e-mail and any attachments is confidential and may contain > > privileged information intended for the addressee(s) only. > > Dissemination, copying, printing or use by anybody else is > > unauthorised. If you are not the intended recipient, please delete > this > > message and any attachments and advise the sender by return e-mail, > > Thanks. > > > > > > > > This e-mail message is intended for the recipient only and contains > > information which is CONFIDENTIAL and which may be proprietary to ECI > > Telecom. If you have received this transmission in error, please > inform > > us by e-mail, phone or fax, and then delete the original and all > copies > > thereof. > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From david.i.allan@ericsson.com Wed Oct 5 16:02:21 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795CD21F8CD8; Wed, 5 Oct 2011 16:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 kKHwaBSmnGEl; Wed, 5 Oct 2011 16:02:21 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id DE8D621F8CD2; Wed, 5 Oct 2011 16:02:20 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p95N5QLV009914; Wed, 5 Oct 2011 18:05:27 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.120]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 5 Oct 2011 19:05:20 -0400 From: David Allan I To: "ietf@ietf.org" , "mpls@ietf.org" Date: Wed, 5 Oct 2011 19:05:19 -0400 Thread-Topic: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Thread-Index: AcyDbrFqpM0ZIVszRuGUW9DSFCBJHAAQsrew Message-ID: <60C093A41B5E45409A19D42CF7786DFD5223D56BC2@EUSAACMS0703.eamcs.ericsson.se> References: <1317815466.64710.YahooMailClassic@web15608.mail.cnb.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 23:02:21 -0000 I think it is unfortunate that we are in a situation where such a document = has utility. But ultimately it does. Therefore I support the publication of draft-sprecher... D > MPLS Working Group, > > Please be aware of the IETF last call as shown below. The document was=20 > presented for publication as an individual RFC with IETF consensus and=20 > AD sponsorship. > > This draft is clearly close and relevant to the work you do, but after=20 > discussing with the chairs I came to the conclusion that it does not=20 > comment on the technical or process decisions of the MPLS working=20 > groups, and it does not attempt to make any technical evaluations or=20 > definitions within the scope of the MPLS working group. It is more of=20 > a philosophical analysis of the way the IETF approaches the "two=20 > solutions" problem with special reference to MPLS-TP OAM. > > Thus, I am accepting the document as AD Sponsored rather than running=20 > it through the MPLS working group. My reasoning is that the working=20 > group has got plenty to do working on technical issues without being=20 > diverted into wider IETF philosophy. > > As an AD Sponsored I-D it is subject to a four week IETF last call.=20 > That is plenty of opportunity for everyone to comment and express=20 > their views. Please send your comments to the IETF mailing list as=20 > described below, or (in exceptional circumstances) direct to the IESG. > > Thanks, > Adrian From david.sinicrope@ericsson.com Wed Oct 5 16:08:35 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B97E11E80BF; Wed, 5 Oct 2011 16:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WaznwWoA3IG; Wed, 5 Oct 2011 16:08:35 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id D8D9B11E80B7; Wed, 5 Oct 2011 16:08:34 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p95NBgEE012784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Oct 2011 18:11:43 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.120]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 5 Oct 2011 19:11:43 -0400 From: David Sinicrope To: David Allan I Date: Wed, 5 Oct 2011 19:11:18 -0400 Thread-Topic: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Thread-Index: AcyDtCUb/u9p9AMlSei45fV6ZKDIUw== Message-ID: <05B25596-719A-423C-BB6C-68868C0314B9@ericsson.com> References: <1317815466.64710.YahooMailClassic@web15608.mail.cnb.yahoo.com> <60C093A41B5E45409A19D42CF7786DFD5223D56BC2@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD5223D56BC2@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "ietf@ietf.org" Subject: Re: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 23:08:35 -0000 I concur with Dave's comment and support publication of the draft. Dave On Oct 5, 2011, at 7:06 PM, "David Allan I" wr= ote: > I think it is unfortunate that we are in a situation where such a documen= t has utility. But ultimately it does. >=20 > Therefore I support the publication of draft-sprecher... >=20 > D >=20 >=20 >=20 >> MPLS Working Group, >>=20 >> Please be aware of the IETF last call as shown below. The document was=20 >> presented for publication as an individual RFC with IETF consensus and=20 >> AD sponsorship. >>=20 >> This draft is clearly close and relevant to the work you do, but after=20 >> discussing with the chairs I came to the conclusion that it does not=20 >> comment on the technical or process decisions of the MPLS working=20 >> groups, and it does not attempt to make any technical evaluations or=20 >> definitions within the scope of the MPLS working group. It is more of=20 >> a philosophical analysis of the way the IETF approaches the "two=20 >> solutions" problem with special reference to MPLS-TP OAM. >>=20 >> Thus, I am accepting the document as AD Sponsored rather than running=20 >> it through the MPLS working group. My reasoning is that the working=20 >> group has got plenty to do working on technical issues without being=20 >> diverted into wider IETF philosophy. >>=20 >> As an AD Sponsored I-D it is subject to a four week IETF last call.=20 >> That is plenty of opportunity for everyone to comment and express=20 >> their views. Please send your comments to the IETF mailing list as=20 >> described below, or (in exceptional circumstances) direct to the IESG. >>=20 >> Thanks, >> Adrian > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From jeff.tantsura@ericsson.com Wed Oct 5 16:11:25 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A543821F8D1A; Wed, 5 Oct 2011 16:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 8zPE8QPNks9e; Wed, 5 Oct 2011 16:11:24 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBFD21F8D3F; Wed, 5 Oct 2011 16:11:20 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p95NEQXk010893; Wed, 5 Oct 2011 18:14:29 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.14]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 5 Oct 2011 19:14:25 -0400 From: Jeff Tantsura To: "mpls@ietf.org" , "ietf@ietf.org" Date: Wed, 5 Oct 2011 19:14:23 -0400 Thread-Topic: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Thread-Index: AcyDtCUb/u9p9AMlSei45fV6ZKDIUwAAExNw Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF617BBF38096@EUSAACMS0701.eamcs.ericsson.se> References: <1317815466.64710.YahooMailClassic@web15608.mail.cnb.yahoo.com> <60C093A41B5E45409A19D42CF7786DFD5223D56BC2@EUSAACMS0703.eamcs.ericsson.se> <05B25596-719A-423C-BB6C-68868C0314B9@ericsson.com> In-Reply-To: <05B25596-719A-423C-BB6C-68868C0314B9@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 23:11:25 -0000 Yes/support Regards, Jeff =20 >=20 >=20 >=20 >> MPLS Working Group, >>=20 >> Please be aware of the IETF last call as shown below. The document was=20 >> presented for publication as an individual RFC with IETF consensus and=20 >> AD sponsorship. >>=20 >> This draft is clearly close and relevant to the work you do, but after=20 >> discussing with the chairs I came to the conclusion that it does not=20 >> comment on the technical or process decisions of the MPLS working=20 >> groups, and it does not attempt to make any technical evaluations or=20 >> definitions within the scope of the MPLS working group. It is more of=20 >> a philosophical analysis of the way the IETF approaches the "two=20 >> solutions" problem with special reference to MPLS-TP OAM. >>=20 >> Thus, I am accepting the document as AD Sponsored rather than running=20 >> it through the MPLS working group. My reasoning is that the working=20 >> group has got plenty to do working on technical issues without being=20 >> diverted into wider IETF philosophy. >>=20 >> As an AD Sponsored I-D it is subject to a four week IETF last call.=20 >> That is plenty of opportunity for everyone to comment and express=20 >> their views. Please send your comments to the IETF mailing list as=20 >> described below, or (in exceptional circumstances) direct to the IESG. >>=20 >> Thanks, >> Adrian > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From gregory.mirsky@ericsson.com Wed Oct 5 16:21:43 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F7321F8DA9; Wed, 5 Oct 2011 16:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzX5TnlVfkCx; Wed, 5 Oct 2011 16:21:43 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id E7D8521F8DA6; Wed, 5 Oct 2011 16:21:40 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p95NOnxw013476 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Oct 2011 18:24:49 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.165]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 5 Oct 2011 19:24:49 -0400 From: Gregory Mirsky To: "ietf@ietf.org" Date: Wed, 5 Oct 2011 19:24:41 -0400 Thread-Topic: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Thread-Index: AcyDtcVQB9j/h6t9Tse6kXFtzFXvBgAABRxA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF12EDF7B97A9EUSAACMS0715e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 23:21:44 -0000 --_000_FE60A4E52763E84B935532D7D9294FF12EDF7B97A9EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support publication. Please consider my comments as LC comments. Regards, Greg ---------- Forwarded message ---------- From: Greg Mirsky > Date: Mon, Oct 3, 2011 at 1:02 PM Subject: Comments to draft-sprecher-mpls-tp-oam-considerations To: ietf@ietf.org Dear Authors, please find my comments below: * page 9, first para s/we loose out/we lose out/ - two times * page 9, second to last para "Partition of the network into incompatibl= e and unconnected islands is neither desirable nor acceptable." While I agr= ee with the former, the latter is highly subjective and absolutely unenforc= eable. As vendors we give operators loaded gun and a warning. What they do = with them might surprise and amaze us all. * Section 4.4, first para: "There are three MPLS signaling control proto= cols used for distributing labels to set up LSPs and PWs in MPLS networks: = LDP, RSVP-TE, and GMPLS." Perhaps GMPLS in this list should be replaced by = BGP/MPLS. RSVP-TE is equally used as signaling protocol to distribute MPLS = and GMPLS label information. There are three paradigms that operate with di= stinct sets of constructs: * LDP MPLS, a.k.a. IP/MPLS; * TE-MPLS; * TE-GMPLS. * Section 4.4, second para. Would note that relationship between LDP and= TE-(G)MPLS networks might be not only as peering but as client-server, e.g= . LDP over RSVP-TE tunnels that could be MSPL-TP. Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF12EDF7B97A9EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I support publication.
Please consider my comments as LC comments.
 

Regards,
Greg
---------- Forwarded message ----------
From: <= B=20 class=3Dgmail_sendername>Greg Mirsky <gregimirsky@gmail.com><= BR>Date:=20 Mon, Oct 3, 2011 at 1:02 PM
Subject: Comments to=20 draft-sprecher-mpls-tp-oam-considerations
To: ietf@ietf.org


Dear Authors,please=20 find my comments below:
  • page 9, first para s/we loose out/we lose out/ - two times=20
  • page 9, second to last para "Partition of the network into incompatib= le=20 and unconnected islands is neither desirable nor acceptable." While I agr= ee=20 with the former, the latter is highly subjective and absolutely unenforce= able.=20 As vendors we give operators loaded gun and a warning. What they do with = them=20 might surprise and amaze us all.
  • Section 4.4, first para: "There are three MPLS signaling control prot= ocols=20 used for distributing labels to set up LSPs and PWs in MPLS networks: LDP= ,=20 RSVP-TE, and GMPLS." Perhaps GMPLS in this list should be replaced by=20 BGP/MPLS. RSVP-TE is equally used as signaling protocol to distribute MPL= S and=20 GMPLS label information. There are three paradigms that operate with dist= inct=20 sets of constructs:=20
    • LDP MPLS, a.k.a. IP/MPLS; =20
    • TE-MPLS;=20
    • TE-GMPLS.
  • Section 4.4, second para. Would note that relationship between LDP an= d=20 TE-(G)MPLS networks might be not only as peering but as client-server, e.= g.=20 LDP over RSVP-TE tunnels that could be MSPL-TP.
Regards,
= Greg

--_000_FE60A4E52763E84B935532D7D9294FF12EDF7B97A9EUSAACMS0715e_-- From jdrake@juniper.net Thu Oct 6 04:07:38 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1E021F86AA; Thu, 6 Oct 2011 04:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.187 X-Spam-Level: X-Spam-Status: No, score=-6.187 tagged_above=-999 required=5 tests=[AWL=0.412, 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 W9vuTFrxjZoM; Thu, 6 Oct 2011 04:07:34 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id A357021F8B06; Thu, 6 Oct 2011 04:07:33 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Thu, 06 Oct 2011 04:10:44 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 6 Oct 2011 04:10:40 -0700 From: John E Drake To: David Sinicrope , David Allan I Date: Thu, 6 Oct 2011 04:10:38 -0700 Thread-Topic: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Thread-Index: AcyDtCUb/u9p9AMlSei45fV6ZKDIUwAZGqzw Message-ID: <5E893DB832F57341992548CDBB333163A441635C81@EMBX01-HQ.jnpr.net> References: <1317815466.64710.YahooMailClassic@web15608.mail.cnb.yahoo.com> <60C093A41B5E45409A19D42CF7786DFD5223D56BC2@EUSAACMS0703.eamcs.ericsson.se> <05B25596-719A-423C-BB6C-68868C0314B9@ericsson.com> In-Reply-To: <05B25596-719A-423C-BB6C-68868C0314B9@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "ietf@ietf.org" Subject: Re: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 11:07:38 -0000 As do I > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of > David Sinicrope > Sent: Wednesday, October 05, 2011 7:11 PM > To: David Allan I > Cc: mpls@ietf.org; ietf@ietf.org > Subject: Re: [mpls] R: FW: Last Call: considerations-01.txt> (The Reasons for Selecting a Single Solution for > MPLS-TP OAM) to Informational RFC >=20 > I concur with Dave's comment and support publication of the draft. > Dave >=20 >=20 >=20 > On Oct 5, 2011, at 7:06 PM, "David Allan I" > wrote: >=20 > > I think it is unfortunate that we are in a situation where such a > document has utility. But ultimately it does. > > > > Therefore I support the publication of draft-sprecher... > > > > D > > > > > > > >> MPLS Working Group, > >> > >> Please be aware of the IETF last call as shown below. The document > was > >> presented for publication as an individual RFC with IETF consensus > and > >> AD sponsorship. > >> > >> This draft is clearly close and relevant to the work you do, but > after > >> discussing with the chairs I came to the conclusion that it does not > >> comment on the technical or process decisions of the MPLS working > >> groups, and it does not attempt to make any technical evaluations or > >> definitions within the scope of the MPLS working group. It is more > of > >> a philosophical analysis of the way the IETF approaches the "two > >> solutions" problem with special reference to MPLS-TP OAM. > >> > >> Thus, I am accepting the document as AD Sponsored rather than > running > >> it through the MPLS working group. My reasoning is that the working > >> group has got plenty to do working on technical issues without being > >> diverted into wider IETF philosophy. > >> > >> As an AD Sponsored I-D it is subject to a four week IETF last call. > >> That is plenty of opportunity for everyone to comment and express > >> their views. Please send your comments to the IETF mailing list as > >> described below, or (in exceptional circumstances) direct to the > IESG. > >> > >> Thanks, > >> Adrian > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From malcolm.betts@zte.com.cn Thu Oct 6 06:58:22 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D4E21F8C12; Thu, 6 Oct 2011 06:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.006 X-Spam-Level: X-Spam-Status: No, score=-97.006 tagged_above=-999 required=5 tests=[AWL=-4.532, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_MILLIONSOF=0.315, SARE_SUB_ENC_GB2312=1.345, 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 m+OslKWAJSjO; Thu, 6 Oct 2011 06:58:21 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8499B21F8BEF; Thu, 6 Oct 2011 06:58:20 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 417131107637492; Thu, 6 Oct 2011 21:59:25 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 75544.5367726569; Thu, 6 Oct 2011 22:01:21 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p96E1IfE093068; Thu, 6 Oct 2011 22:01:18 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <4E8CBB02.3080300@gmail.com> References: <4E8CBB02.3080300@gmail.com> To: Brian E Carpenter MIME-Version: 1.0 X-KeepSent: 1990CB7D:6CAC1E82-85257921:004C680C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Thu, 6 Oct 2011 10:00:56 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-06 22:01:20, Serialize complete at 2011-10-06 22:01:20 Content-Type: multipart/alternative; boundary="=_alternative 004D056A85257921_=" X-MAIL: mse01.zte.com.cn p96E1IfE093068 Cc: "mpls@ietf.org" , "ietf@ietf.org" , ietf-bounces@ietf.org, yang.jian90@zte.com.cn, mpls-bounces@ietf.orgLarry Subject: Re: [mpls] =?gb2312?b?tPC4tDogILvYuLSjuiAgUjogRlc6IExhc3QgQ2FsbDog?= =?gb2312?b?PGRyYWZ0LXNwcmVjaGVyLW1wbHMtdHAtb2FtLWNvbnNpZGVyYXRpb25zLTAx?= =?gb2312?b?LnR4dD4gKFRoZSBSZWFzb25zIGZvciBTZWxlY3RpbmcgYSBTaW5nbGUgU29s?= =?gb2312?b?dXRpb24gZm9yIE1QTFMtVFAgT0FNKSB0byBJbmZvcm1hdGlvbmFsIFJGQw==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 13:58:22 -0000 This is a multipart message in MIME format. --=_alternative 004D056A85257921_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 QnJpYW4sDQoNClRoZSBzZWNvbmQgc29sdXRpb24gYWxyZWFkeSBleGlzdHMsICgzMDAsMDArIG5v ZGVzIGFscmVhZHkgZGVwbG95ZWQgLSBzZWUgDQpvdGhlciBlbWFpbHMgb24gdGhpcyB0aHJlYWQp LiAgV2UgbXVzdCBhY2tub3dsZWRnZSB0aGlzIGFuZCBmaW5kIHRoZSBtb3N0IA0KY29zdCBlZmZl Y3RpdmUgd2F5IG9mIGFsbG93aW5nIGludGVyY29ubmVjdGlvbi4gIFRoYXQgaXMgYmVzdCBhY2hp ZXZlZCBieSANCnJlY29nbml6aW5nIHRoZSBFdGhlcm5ldCB0b29sIHNldCBiYXNlZCBzb2x1dGlv biBhbmQgZGVmaW5pbmcgDQppbnRlcmNvbm5lY3Rpb24gc3VjaCB0aGF0IGFuIGludGVyd29ya2lu ZyBmdW5jdGlvbiBpcyBub3QgcmVxdWlyZWQuICBUaGlzIA0KaGFzIGFscmVhZHkgYmVlbiBwcm9w b3NlZCBhbmQgZG9jdW1lbnRlZCBpbiBkcmFmdCByZXZpc2VkIFJlY29tbWVuZGF0aW9uIA0KRy44 MTEwLjEgKG5vdyBpbiBJVFUtVCBsYXN0IGNhbGwpIGFuZCBpcyBkZXNjcmliZWQgaW4gDQpkcmFm dC10c2ItbXBscy10cC1hY2gtcHRuLg0KDQpSZWdhcmRzLA0KDQpNYWxjb2xtDQoNCg0KDQoNCkJy aWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IA0KU2VudCBieTog aWV0Zi1ib3VuY2VzQGlldGYub3JnDQowNS8xMC8yMDExIDA0OjE2IFBNDQoNClRvDQp5YW5nLmpp YW45MEB6dGUuY29tLmNuDQpjYw0KIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3JnPiwgRCdB bGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJkbyANCjxhbGVzc2FuZHJvLmRhbGVzc2FuZHJvQHRl bGVjb21pdGFsaWEuaXQ+LCAiaWV0ZkBpZXRmLm9yZyIgDQo8aWV0ZkBpZXRmLm9yZz4sIGxhcnJ5 bGk4ODhAeWFob28uY29tLmNuLCBtcGxzLWJvdW5jZXNAaWV0Zi5vcmdMYXJyeSwgDQoiYWRyaWFu QG9sZGRvZy5jby51ayIgPGFkcmlhbkBvbGRkb2cuY28udWs+DQpTdWJqZWN0DQpSZTogtPC4tDog W21wbHNdILvYuLSjuiAgUjogRlc6IExhc3QgQ2FsbDogDQo8ZHJhZnQtc3ByZWNoZXItbXBscy10 cC1vYW0tY29uc2lkZXJhdGlvbnMtMDEudHh0PiAoVGhlIFJlYXNvbnMgZm9yIA0KU2VsZWN0aW5n IGEgU2luZ2xlIFNvbHV0aW9uIGZvciBNUExTLVRQIE9BTSkgdG8gSW5mb3JtYXRpb25hbCBSRkMN Cg0KDQoNCg0KDQoNCkhpIEppYW4sDQoNCk9uIDIwMTEtMTAtMDYgMDM6NTMsIHlhbmcuamlhbjkw QHp0ZS5jb20uY24gd3JvdGU6DQo+IERlYXIgQWxsLA0KPiANCj4gSSBkbyBub3Qgc3VwcG9ydCBl aXRoZXIuDQo+IA0KPiBJbiBzZWN0aW9uIDMuNToNCj4gSWYgdHdvIE1QTFMgT0FNIHByb3RvY29s cyB3ZXJlIHRvIGJlIGRlcGxveWVkIHdlIHdvdWxkIGhhdmUgdG8gY29uc2lkZXINCj4gdGhyZWUg cG9zc2libGUgc2NlbmFyaW9zOg0KPiAxKSBJc29sYXRpb24gb2YgdGhlIG5ldHdvcmsgaW50byB0 d28gaW5jb21wYXRpYmxlIGFuZCB1bmNvbm5lY3RlZCANCmlzbGFuZHMuDQo+IA0KPiBUd28gT0FN IHNvbHV0aW9ucyBoYXZlIGJlZW4gZGlzY3Vzc2VkIGZvciBhIGxvbmcgdGltZSBpbiBib3RoIElU VS1UIGFuZA0KPiBJRVRGLg0KPiBFYWNoIHNvbHV0aW9uIGhhcyB0aGVpciBvd24gc3VwcG9ydGVy cyBpbmN1bGRpbmcgY2FycmllcnMgYW5kIHZlbmRvcnMuDQo+IFNvIEkgZG9uJ3QgdGhpbmsgdGhl cmUgaXMgYW55IGludGVyd29ya2luZyBpc3N1ZSBiZXR3ZWVuIHR3byBPQU0gDQpzb2x1dGlvbnMu DQo+IENhcnJpZXIgd2lsbCBzZWxlY3Qgb25lIE9BTSBzb2x1dGlvbiwgQSBvciBCLCBpbiB0aGVp ciBuZXR3b3JrLg0KPiBObyBuZWVkIHRvIHNlbGVjdCBBIGFuZCBCIGF0IG9uZSBuZXR3b3JrIGF0 IHRoZSBzYW1lIHRpbWUuDQoNClRoZXJlIGFyZSB0d28gbGFyZ2UgY29zdHMgdGhhdCB5b3UgYXJl IGlnbm9yaW5nOg0KDQphKSBhbGwgdmVuZG9ycyB3aXNoaW5nIHRvIGJpZCBmb3IgYnVzaW5lc3Mg ZnJvbSBBIGFuZCBCIHdpbGwgaGF2ZSB0bw0KICAgaW1wbGVtZW50IGFuZCBzdXBwb3J0IGJvdGgg c29sdXRpb25zLg0KDQpiKSB3aGVuIEEgYnV5cyBCIG9yIEIgYnV5cyBBLCB0aGUgaW5jb21wYXRp YmxlIG5ldHdvcmtzIHdpbGwgaGF2ZSB0bw0KICAgYmUgbWVyZ2VkLg0KDQpUaGVzZSBhcmUgY29z dHMgdGhhdCBydW4gdG8gaHVuZHJlZHMgb2YgbWlsbGlvbnMgb2YgVVNELCBFVVIgb3IgQ05ZLg0K VGhleSBhcmUgY29zdHMgY2F1c2VkIGRpcmVjdGx5IGJ5IFNET3MgY3JlYXRpbmcgcml2YWwgc29s dXRpb25zLg0KDQpJIHRoaW5rIGl0IHdvdWxkIGJlIGlycmVzcG9uc2libGUgb2YgdGhlIElFVEYg bm90IHRvIGRvY3VtZW50IHRoaXMNCnNpdHVhdGlvbi4gQXMgZW5naW5lZXJzLCB3ZSBoYXZlIGFu IGV0aGljYWwgcmVzcG9uc2liaWxpdHkgaGVyZS4NCg0KICAgIEJyaWFuDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWV0ZiBtYWlsaW5nIGxpc3QNCkll dGZAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWV0Zg0K DQoNCg0K --=_alternative 004D056A85257921_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJyaWFuLDwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhlIHNlY29uZCBzb2x1dGlvbiBhbHJlYWR5 IGV4aXN0cywNCigzMDAsMDArIG5vZGVzIGFscmVhZHkgZGVwbG95ZWQgLSBzZWUgb3RoZXIgZW1h aWxzIG9uIHRoaXMgdGhyZWFkKS4gJm5ic3A7V2UNCm11c3QgYWNrbm93bGVkZ2UgdGhpcyBhbmQg ZmluZCB0aGUgbW9zdCBjb3N0IGVmZmVjdGl2ZSB3YXkgb2YgYWxsb3dpbmcNCmludGVyY29ubmVj dGlvbi4gJm5ic3A7VGhhdCBpcyBiZXN0IGFjaGlldmVkIGJ5IHJlY29nbml6aW5nIHRoZSBFdGhl cm5ldA0KdG9vbCBzZXQgYmFzZWQgc29sdXRpb24gYW5kIGRlZmluaW5nIGludGVyY29ubmVjdGlv biBzdWNoIHRoYXQgYW4gaW50ZXJ3b3JraW5nDQpmdW5jdGlvbiBpcyBub3QgcmVxdWlyZWQuICZu YnNwO1RoaXMgaGFzIGFscmVhZHkgYmVlbiBwcm9wb3NlZCBhbmQgZG9jdW1lbnRlZA0KaW4gZHJh ZnQgcmV2aXNlZCBSZWNvbW1lbmRhdGlvbiBHLjgxMTAuMSAobm93IGluIElUVS1UIGxhc3QgY2Fs bCkgYW5kIGlzDQpkZXNjcmliZWQgaW4gZHJhZnQtdHNiLW1wbHMtdHAtYWNoLXB0bi48L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2FyZHMsPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5NYWxjb2xtPC9mb250 Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkJy aWFuIEUgQ2FycGVudGVyICZsdDticmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20mZ3Q7PC9iPg0K PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5TZW50IGJ5OiBpZXRm LWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+MDUvMTAvMjAxMSAwNDoxNiBQTTwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+VG88L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPnlhbmcuamlhbjkwQHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPmNjPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij4mcXVvdDttcGxzQGlldGYub3JnJnF1b3Q7ICZsdDttcGxzQGlldGYub3JnJmd0OywNCkQnQWxl c3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG8gJmx0O2FsZXNzYW5kcm8uZGFsZXNzYW5kcm9AdGVs ZWNvbWl0YWxpYS5pdCZndDssDQomcXVvdDtpZXRmQGlldGYub3JnJnF1b3Q7ICZsdDtpZXRmQGll dGYub3JnJmd0OywgbGFycnlsaTg4OEB5YWhvby5jb20uY24sDQptcGxzLWJvdW5jZXNAaWV0Zi5v cmdMYXJyeSwgJnF1b3Q7YWRyaWFuQG9sZGRvZy5jby51ayZxdW90OyAmbHQ7YWRyaWFuQG9sZGRv Zy5jby51ayZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlN1YmplY3Q8L2ZvbnQ+PC9kaXY+DQo8 dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiC08Li0OiBbbXBsc10gu9i4tKO6 ICZuYnNwO1I6DQpGVzogTGFzdCBDYWxsOiAmbHQ7ZHJhZnQtc3ByZWNoZXItbXBscy10cC1vYW0t Y29uc2lkZXJhdGlvbnMtMDEudHh0Jmd0Ow0KKFRoZSBSZWFzb25zIGZvciBTZWxlY3RpbmcgYSBT aW5nbGUgU29sdXRpb24gZm9yIE1QTFMtVFAgT0FNKSB0byBJbmZvcm1hdGlvbmFsDQpSRkM8L2Zv bnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwv dGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkhp IEppYW4sPGJyPg0KPGJyPg0KT24gMjAxMS0xMC0wNiAwMzo1MywgeWFuZy5qaWFuOTBAenRlLmNv bS5jbiB3cm90ZTo8YnI+DQomZ3Q7IERlYXIgQWxsLDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGRv IG5vdCBzdXBwb3J0IGVpdGhlci48YnI+DQomZ3Q7IDxicj4NCiZndDsgSW4gc2VjdGlvbiAzLjU6 PGJyPg0KJmd0OyBJZiB0d28gTVBMUyBPQU0gcHJvdG9jb2xzIHdlcmUgdG8gYmUgZGVwbG95ZWQg d2Ugd291bGQgaGF2ZSB0byBjb25zaWRlcjxicj4NCiZndDsgdGhyZWUgcG9zc2libGUgc2NlbmFy aW9zOjxicj4NCiZndDsgMSkgSXNvbGF0aW9uIG9mIHRoZSBuZXR3b3JrIGludG8gdHdvIGluY29t cGF0aWJsZSBhbmQgdW5jb25uZWN0ZWQNCmlzbGFuZHMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFR3 byBPQU0gc29sdXRpb25zIGhhdmUgYmVlbiBkaXNjdXNzZWQgZm9yIGEgbG9uZyB0aW1lIGluIGJv dGggSVRVLVQNCmFuZDxicj4NCiZndDsgSUVURi48YnI+DQomZ3Q7IEVhY2ggc29sdXRpb24gaGFz IHRoZWlyIG93biBzdXBwb3J0ZXJzIGluY3VsZGluZyBjYXJyaWVycyBhbmQgdmVuZG9ycy48YnI+ DQomZ3Q7IFNvIEkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYW55IGludGVyd29ya2luZyBpc3N1ZSBi ZXR3ZWVuIHR3byBPQU0gc29sdXRpb25zLjxicj4NCiZndDsgQ2FycmllciB3aWxsIHNlbGVjdCBv bmUgT0FNIHNvbHV0aW9uLCBBIG9yIEIsIGluIHRoZWlyIG5ldHdvcmsuPGJyPg0KJmd0OyBObyBu ZWVkIHRvIHNlbGVjdCBBIGFuZCBCIGF0IG9uZSBuZXR3b3JrIGF0IHRoZSBzYW1lIHRpbWUuPGJy Pg0KPGJyPg0KVGhlcmUgYXJlIHR3byBsYXJnZSBjb3N0cyB0aGF0IHlvdSBhcmUgaWdub3Jpbmc6 PGJyPg0KPGJyPg0KYSkgYWxsIHZlbmRvcnMgd2lzaGluZyB0byBiaWQgZm9yIGJ1c2luZXNzIGZy b20gQSBhbmQgQiB3aWxsIGhhdmUgdG88YnI+DQogJm5ic3A7IGltcGxlbWVudCBhbmQgc3VwcG9y dCBib3RoIHNvbHV0aW9ucy48YnI+DQo8YnI+DQpiKSB3aGVuIEEgYnV5cyBCIG9yIEIgYnV5cyBB LCB0aGUgaW5jb21wYXRpYmxlIG5ldHdvcmtzIHdpbGwgaGF2ZSB0bzxicj4NCiAmbmJzcDsgYmUg bWVyZ2VkLjxicj4NCjxicj4NClRoZXNlIGFyZSBjb3N0cyB0aGF0IHJ1biB0byBodW5kcmVkcyBv ZiBtaWxsaW9ucyBvZiBVU0QsIEVVUiBvciBDTlkuPGJyPg0KVGhleSBhcmUgY29zdHMgY2F1c2Vk IGRpcmVjdGx5IGJ5IFNET3MgY3JlYXRpbmcgcml2YWwgc29sdXRpb25zLjxicj4NCjxicj4NCkkg dGhpbmsgaXQgd291bGQgYmUgaXJyZXNwb25zaWJsZSBvZiB0aGUgSUVURiBub3QgdG8gZG9jdW1l bnQgdGhpczxicj4NCnNpdHVhdGlvbi4gQXMgZW5naW5lZXJzLCB3ZSBoYXZlIGFuIGV0aGljYWwg cmVzcG9uc2liaWxpdHkgaGVyZS48YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwO0JyaWFuPGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZXRm IG1haWxpbmcgbGlzdDxicj4NCklldGZAaWV0Zi5vcmc8YnI+DQo8L2ZvbnQ+PC90dD48YSBocmVm PWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWV0Zj48dHQ+PGZvbnQgc2l6 ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWV0ZjwvZm9udD48L3R0 PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 004D056A85257921_=-- From erosen@cisco.com Thu Oct 6 07:09:13 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A6A21F8D0D for ; Thu, 6 Oct 2011 07:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 MwJEBaeDmg9q for ; Thu, 6 Oct 2011 07:09:13 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFFF21F8D0A for ; Thu, 6 Oct 2011 07:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=5287; q=dns/txt; s=iport; t=1317910344; x=1319119944; h=to:subject:reply-to:date:message-id:from; bh=NHqv7vAyoDvJFaGeLBUDf5IEdMGUv21eq8Y6jeO8SnA=; b=ECNtalZspEJBPkP78k6K1UcR3m/kJIl22+X8RY/RHqHCl66d/kPchv8M /HR7VCenNv0OHdRsVkHPCe6GnhyS8CXnCTsrM4yjiyciYWpiTkJWnbUxg MbriEJoOHRLW4wedv9WpXptrSYvXfg270tuCeTPX4rcHa3HxJ11NSpZMI I=; X-IronPort-AV: E=Sophos;i="4.68,496,1312156800"; d="scan'208";a="6277921" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 06 Oct 2011 14:12:24 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p96ECNA5018510; Thu, 6 Oct 2011 14:12:23 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id p96ECMUU006361; Thu, 6 Oct 2011 10:12:22 -0400 To: mpls@ietf.org X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.1.1 Date: Thu, 06 Oct 2011 10:12:22 -0400 Message-ID: <6360.1317910342@erosen-linux> From: Eric Rosen Subject: [mpls] seamless-mcast: Question re Leaf A-D routes for internet multicast X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 14:09:14 -0000 I have a question about the "Leaf A-D Route for Internet Multicast" described in section 6.2.2 of draft-ietf-mpls-seamless-mcast-01.txt. The NLRI seems to be a bit different than the NLRI of Leaf A-D routes derived from MVPN I-PMSI/S-PMSI A-D routes, and I'd like to understand whether this difference is (a) intentional and (b) a good idea. Let's look at a Leaf A-D route that is derived from an MVPN S-PMSI A-D route. Suppose the S-PMSI A-D route has the following NLRI: route type = 3 (S-PMSI A-D route), length of this NLRI, RD, multicast source length, multicast source, multicast group length, multicast group, originating router (call it X). According to draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, a Leaf A-D route derived from this S-PMSI A-D route will have the following NLRI: route type = 5 (Leaf A-D route), length, route key, originating router (call it Y) where "route key" is defined as the MCAST-VPN NLRI of the route from which the Leaf A-D route is derived. So if we modify the diagram to show the individual fields of the route key, we find that the MCAST-VPN NLRI of the Leaf A-D route is: route type = 5 (Leaf A-D route), length of this NLRI, route type = 3 (derived from S-PMSI A-D route), length of the S-PMSI A-D route's NLRI (i.e., length from here to the field containing Y) RD, multicast source length, multicast source, multicast group length, multicast group, originator of the S-PMSI A-D route (X) originator of the Leaf A-D route (Y) However, in draft-ietf-mpls-seamless-mcast-01.txt, the NLRI of a Leaf A-D route for "Internet multicast" is defined somewhat differently, as: route type = 5 (Leaf A-D route), length of this NLRI, RD, multicast source length, multicast source, multicast group length, multicast group, ingress router, originator of the Leaf A-D route (Y) Note that the NLRI for "internet multicast" is two bytes shorter than the NLRI for MVPN, omitting the octets that would otherwise hold the type of the S-PMSI A-D route from which the Leaf A-D route was derived, as well as the length of the NLRI of that S-PMSI A-D route. The draft does state that for "internet multicast", only two RD values are legal: all zeroes or all ones. So it appears that there is a way to tell whether a Leaf A-D route was derived from some other route or not: look at the third octet of its NLRI. If that octet has the value 0x00 or the value 0xff, then the Leaf A-D route is not derived from another route, and hence must be an "Internet Multicast" route. The only other proper values of this octet are the values 0x01, 0x02, and 0x03. I would appreciate it if the authors would verify whether this is the correct interpretation or not. If it is, it would be good to add some text that calls attention to this difference, and that explains explicitly how to determine whether a received Leaf A-D route is or is not derived from some other route. If I understand this correctly, this piece of the protocol design doesn't seem like a good practice to me. The procedures for parsing the Leaf A-D route NLRI should not depend upon a priori knowledge that, in the envisioned use cases, the valid "route type" values are different than the valid values of the first octet of the RD. The coding rules for the RD and the coding rules for the route type byte should be independent. Otherwise we are just opening the door for incompatibilities and interworking problems in the future. The obvious alternative for an "internet multicast" Leaf A-D route would be: route type = 5, length of this NLRI, route type = TBD (new value to indicate that is Leaf A-D route is not derived from a PMSI A-D route.) length from here to Y (perhaps this field could be omitted without problem) RD, multicast source length, multicast source, multicast group length, multicast group, ingress router, originator of the Leaf A-D route (Y) This keeps the RD coding rules independent from the "route type" coding rules. BTW, page 13 of the draft says "the entire MCAST-VPN NLRI of the [Leaf A-D route used for Internet multicast] has the following format", and then shows a diagram that begins with the RD. This diagram does not actually show the "entire NLRI", as it omits the route type and length fields. This should be corrected. Also BTW, I think the term "Internet multicast" should actually be "global table multicast". The use of "internet multicast" in this document doesn't actually mean that the multicast comes from the internet, it just means that the multicast is not a VPN customer multicast. The "internet multicast" procedures could be used to set up, e.g., P-tunnels for MVPN, and there shouldn't be any suggestion that the P-tunnels are "internet multicasts". From lufang@cisco.com Thu Oct 6 08:20:34 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BF421F8E15; Thu, 6 Oct 2011 08:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 U9kRdlKp3snk; Thu, 6 Oct 2011 08:20:33 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 22D0521F8E11; Thu, 6 Oct 2011 08:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=3228; q=dns/txt; s=iport; t=1317914624; x=1319124224; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ITQnrsXUGuc3FYMaF+9Ti9Y1MprthLPiJTfMNsz0M18=; b=O89XRkbPQYMy/y6PueXl6uiTt314SzDZYDu06ufuPeNrR/K4SrMVAtJ4 B/Gb/NeTk133hUYuWBP00Q3t33aPb9utNns7QtctujqeAJuUKMWGsId1G P/0t62Xzb4EmC+m4w2atMCWVlWJzylf7xdAAUOxXk4ucOyxYeuidEbzDC s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIAAOPGjU6tJV2d/2dsb2JhbABDmRePHIEFgVMBAQEEAQEBDwEdCjQLDAQCAQgRBAEBAQoGEwQBBgEmHwgBCAEBBAESCBMHh2OZSQGeHQOGS2EEh32RIowz X-IronPort-AV: E=Sophos;i="4.68,496,1312156800"; d="scan'208";a="26533541" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 06 Oct 2011 15:23:41 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p96FNfgB019616; Thu, 6 Oct 2011 15:23:41 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Oct 2011 10:23:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Oct 2011 10:23:40 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25070065EF@XMB-RCD-201.cisco.com> In-Reply-To: <5E893DB832F57341992548CDBB333163A441635C81@EMBX01-HQ.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] R: FW: LastCall: (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC Thread-Index: AcyDtCUb/u9p9AMlSei45fV6ZKDIUwAZGqzwAAPaIyA= References: <1317815466.64710.YahooMailClassic@web15608.mail.cnb.yahoo.com><60C093A41B5E45409A19D42CF7786DFD5223D56BC2@EUSAACMS0703.eamcs.ericsson.se><05B25596-719A-423C-BB6C-68868C0314B9@ericsson.com> <5E893DB832F57341992548CDBB333163A441635C81@EMBX01-HQ.jnpr.net> From: "Luyuan Fang (lufang)" To: "John E Drake" , "David Sinicrope" , "David Allan I" X-OriginalArrivalTime: 06 Oct 2011 15:23:41.0266 (UTC) FILETIME=[EDB15320:01CC843B] Cc: mpls@ietf.org, ietf@ietf.org Subject: Re: [mpls] R: FW: LastCall: (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 15:20:34 -0000 Same here.=20 I support publication of the draft. Luyuan > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > John E Drake > Sent: Thursday, October 06, 2011 7:11 AM > To: David Sinicrope; David Allan I > Cc: mpls@ietf.org; ietf@ietf.org > Subject: Re: [mpls] R: FW: LastCall: considerations-01.txt> (TheReasons for Selecting a Single Solution for > MPLS-TP OAM) toInformational RFC >=20 > As do I >=20 > > -----Original Message----- > > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf > Of > > David Sinicrope > > Sent: Wednesday, October 05, 2011 7:11 PM > > To: David Allan I > > Cc: mpls@ietf.org; ietf@ietf.org > > Subject: Re: [mpls] R: FW: Last Call: > considerations-01.txt> (The Reasons for Selecting a Single Solution > for > > MPLS-TP OAM) to Informational RFC > > > > I concur with Dave's comment and support publication of the draft. > > Dave > > > > > > > > On Oct 5, 2011, at 7:06 PM, "David Allan I" > > wrote: > > > > > I think it is unfortunate that we are in a situation where such a > > document has utility. But ultimately it does. > > > > > > Therefore I support the publication of draft-sprecher... > > > > > > D > > > > > > > > > > > >> MPLS Working Group, > > >> > > >> Please be aware of the IETF last call as shown below. The document > > was > > >> presented for publication as an individual RFC with IETF consensus > > and > > >> AD sponsorship. > > >> > > >> This draft is clearly close and relevant to the work you do, but > > after > > >> discussing with the chairs I came to the conclusion that it does > not > > >> comment on the technical or process decisions of the MPLS working > > >> groups, and it does not attempt to make any technical evaluations > or > > >> definitions within the scope of the MPLS working group. It is more > > of > > >> a philosophical analysis of the way the IETF approaches the "two > > >> solutions" problem with special reference to MPLS-TP OAM. > > >> > > >> Thus, I am accepting the document as AD Sponsored rather than > > running > > >> it through the MPLS working group. My reasoning is that the > working > > >> group has got plenty to do working on technical issues without > being > > >> diverted into wider IETF philosophy. > > >> > > >> As an AD Sponsored I-D it is subject to a four week IETF last > call. > > >> That is plenty of opportunity for everyone to comment and express > > >> their views. Please send your comments to the IETF mailing list as > > >> described below, or (in exceptional circumstances) direct to the > > IESG. > > >> > > >> Thanks, > > >> Adrian > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From danfrost@cisco.com Thu Oct 6 09:29:07 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6EDE21F8B84; Thu, 6 Oct 2011 09:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, 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 tyUPMZmhpSx3; Thu, 6 Oct 2011 09:29:06 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9207721F8B77; Thu, 6 Oct 2011 09:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=danfrost@cisco.com; l=7219; q=dns/txt; s=iport; t=1317918738; x=1319128338; h=date:from:to:subject:message-id:references:mime-version: in-reply-to; bh=+vrvx+E3N8uAz0rHDQQ2c8fIaM9Bzfpyhb2OTxBlpSw=; b=Wkz/Y92D+qUUqw718rNYspu4OdrLxMx4R1FI9F/quI9xawf/kOMLBugh seZ+4GpmCbrPsXRwWeGa6ioO00QKnb0EWoFEs2o5i1UJNdjfluqrfPMOs h/LgWzWEWSW7LxXOPAUlBEqecoZt43cWeTOx1LmE5ArwkV37gNdqHiAyH s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFAPLXjU6tJXG+/2dsb2JhbABDpgCCM4EFgVMBAQEEEgEnTws7CxQ6DwEmBweiCwGeJoZLYQSTbpFH X-IronPort-AV: E=Sophos;i="4.68,497,1312156800"; d="scan'208";a="26552321" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 06 Oct 2011 16:32:17 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [10.83.106.70]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p96GWHN4024148; Thu, 6 Oct 2011 16:32:17 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id p96GWGFu011351; Thu, 6 Oct 2011 12:32:16 -0400 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id p96GWGW0011350; Thu, 6 Oct 2011 17:32:16 +0100 Date: Thu, 6 Oct 2011 17:32:16 +0100 From: Dan Frost To: Adrian Farrel , mpls@ietf.org, ietf@ietf.org Message-ID: <20111006163216.GA7154@cisco.com> References: <081e01cc7c97$588726e0$099574a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <081e01cc7c97$588726e0$099574a0$@olddog.co.uk> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [mpls] FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 16:29:07 -0000 This document provides a factual and concise summary of work, events, and points of view that have developed since the JWT, a summary that's timely and sorely needed as few in the industry outside the project (or even inside the project) can make sense of it. It also provides a thorough and accessible analysis of the costs to service providers, vendors, the market, and the end user that divergent MPLS OAM solutions will create. As such, I think the IETF has a duty to move forward with its publication; the considerations it raises are of significant importance to the Internet community. It's also noteworthy that the proponents of a non-IETF MPLS OAM technology have been unwilling thus far to document the supposed technical problems with standard MPLS/MPLS-TP OAM in an Internet draft. If one didn't know better, one might be tempted to suppose their concerns were more political than technical. Following are LC comments/suggestions on the draft, all minor and editorial. --- Suggest adding a reference to RFC 5921 in first paragraphs of abstract/introduction. --- The terms "inter-working" and "interworking" both appear repeatedly throughout; it would be good to pick one. --- Section 1.1, 4th paragraph: s/which are applicable/that are applicable/ --- Section 1.1, last sentence: s/development and deployment making/development and deployment, making/ --- Section 1.2, 2nd paragraph: s/it was considered/it was judged/ --- Section 1.2, 3rd paragraph: OLD Indeed, one of the key differences between the two environments is the choice of MPLS-TP OAM solution which makes a circular argument. NEW Indeed, one of the key differences cited between the two allegedly distinct environments is the choice of MPLS-TP OAM solution, which makes a circular argument. END --- Section 1.2, next-to-last paragraph: s/normal IETF, consensus-driven/normal consensus-driven IETF/ --- Section 3.1, first paragraph: OLD In MPLS-TP, MPLS was extended to satisfy the transport network requirements in a way that was both compatible with MPLS as has already been deployed, and MPLS and with the IETF envisioned it would develop in the future. NEW In MPLS-TP, MPLS was extended to satisfy the transport network requirements in a way that was compatible both with MPLS as has already been deployed, and with MPLS as the IETF envisioned it would develop in the future. END --- Section 3.1, 2nd paragraph: s/philosophies that have lead/philosophies that have led/ --- Section 3.2, 2nd paragraph: OLD MPLS has been deployed in operational networks for approximately a decade, with the existing MPLS OAM techniques widely deployed in operational networks. NEW MPLS has been deployed in operational networks for approximately a decade, and the existing MPLS OAM techniques have seen wide deployment. END s/MPLS based/MPLS-based/ --- Section 3.3, first paragraph: s/can transition/can cross/ --- Section 3.3, 2nd paragraph: s/exiting network layer/existing network layer/ s/fast connectivity protocol/fast connectivity verification protocol/ --- Section 3.4, first paragraph: Second sentence needs rephrasing; maybe: OLD In an isolated system this may be the case, however when, as is usually case with communications technologies, simplification in one element of the system introduces a (possibly non-linear) increase in complexity elsewhere. NEW In an isolated system this may be the case. In an interconnected system such as a communications network, however, simplification in one element of the system may increase complexity elsewhere, and this increase may be non-linear. END --- Section 3.4, 2nd paragraph: OLD However, when we drive OAM complexity out of one network element at the cost of increased complexity at a peer network element we loose out economically and, more importantly, we loose out in terms of the reliability of this important network functionality. NEW However, when we drive OAM complexity out of one network element at the cost of increased complexity at a peer network element, there is no economic benefit and, more importantly, the reliability of the network is compromised. END --- Sections 4.1-5.3: Suggest expanding acronyms and adding references. --- Section 4.3, first paragraph: OLD Every time a new codec is deployed, translation between it and all other deployed codecs must be performed available within the network, each participating node must be able to handle the new codec. Translation between codec is expensive and can lead to reduced quality. NEW Every time a new codec is deployed, translation between it and all other deployed codecs must be performed within the network; codec translation is expensive and can lead to reduced quality. In addition, each participating node must be able to handle the new codec. END --- Section 4.3, 3rd paragraph: OLD The application layer of the Internet is, however, predicated on a business model that allows for free or shared software (such as in open source developments), and is only possible with the existence of a royalty free codec. This, together with the specific characteristics of transmission over lossy packet networks comprised requirements equivalent to a major difference in functionality, and led to work in the IETF to specify a new codec. NEW The application layer of the Internet is, however, predicated on a business model that allows for the use of shared, free, and open-source software; this model requires the existence of a royalty-free codec. This, together with the specific characteristics of transmission over lossy packet networks, comprised requirements equivalent to a major difference in functionality, and led to work in the IETF to specify a new codec. END --- Section 5.2: This paragraph talks about 802.16 d/e and then mentions 802.16a; is this intentional? --- Section 6.1, 2nd paragraph: s/the protocols rules/the rules/ --- Section 6.1, 3rd paragraph: s/the protocols rules/the rules/ --- Section 6.1, 4th paragraph: s/These are obvious issues/There are obvious issues/ --- Section 6.3.1.1, last paragraph: s/route trace function/route trace functions/ --- Section 6.3.2: s/Sections/sections/ --- Section 6.3.2.1, 4th paragraph: s/in is necessary/it is necessary/ --- Section 6.3.2.1, last paragraph: s/working and is protection/working and protection/ --- Section 7.1, 2nd paragraph: s/will not will/will/ --- Section 7.1, last paragraph: This paragraph is a bit vague. It should probably be recast to be specific about the phase of work that's nearing completion and how this phase relates to the overall requirements and joint work plan. --- Section 7.3, 2nd paragraph: s/One of stated/One of the stated/ --- Section 7.4, last paragraph: s/family, makes/family makes/ --- Section 7.5, first paragraph: s/as in the in the/as in the/ --- Cheers, -d From Alexander.Vainshtein@ecitele.com Thu Oct 6 11:50:42 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44ED1F0C4C; Thu, 6 Oct 2011 11:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.474 X-Spam-Level: X-Spam-Status: No, score=-4.474 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6FXPgxdsfQ9; Thu, 6 Oct 2011 11:50:42 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 707F921F8CE0; Thu, 6 Oct 2011 11:50:40 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1317927205!43392901!2 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.4.1; banners=-,-,- Received: (qmail 15346 invoked from network); 6 Oct 2011 18:53:29 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-4.tower-27.messagelabs.com with SMTP; 6 Oct 2011 18:53:29 -0000 X-AuditID: 93eaf2e7-b7c59ae00000552f-33-4e8e0742bc23 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id CB.3F.21807.2470E8E4; Thu, 6 Oct 2011 21:53:38 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Thu, 6 Oct 2011 20:53:49 +0200 From: Alexander Vainshtein To: David Allan I Date: Thu, 6 Oct 2011 20:53:48 +0200 Thread-Topic: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Thread-Index: AcyDbrFqpM0ZIVszRuGUW9DSFCBJHAAQsrewACjM9jg= Message-ID: References: <1317815466.64710.YahooMailClassic@web15608.mail.cnb.yahoo.com> , <60C093A41B5E45409A19D42CF7786DFD5223D56BC2@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD5223D56BC2@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2WTeUzTUBzH89oyClKphbnH4h9LJcaoQxaveUyNR5xRcd7KP1i259a4dbOd hJmgM0owqDhDjLoYUQMqipm3KBoDZkRQ4xWj4n2ACp6LaDyxpYoY+9f39fv9vs9r83skznzS 6Ele8CNR4NysJpEobY19NE6IL8nK3Bcdbn5y9RRubjlSRpibKirjzPcenYofT1i/tt/SWMvL v2DWL5Fb8TY8OwjGcILg9XN+ZHAgyW5hbSKfx9kDrIF3WFgTa/C5OTvyIMFvYTmfDwkOdmyi 4b9njBzjBQMS7F4HLzgt7NQ5M41m87CRRhM7tl9f05DRiXNdvGRARg/Huw0eJEmcExnkN4uP 467Vu0O4rzY1/23oMh4E1XQxSCAhPRRGL33XqLo3vPYw0qkZ+hyALQeZYpAo61IAn0bPY4qh oS3w6MEHnaFUOgNWXf8Wp2icDsCawiu4ogk6Ha6L7QFKOYWOABh9GcSURSp9GMALO6pwtT0K XnxX0qkpeha82NiKq7jHAK4vqyQUI4FeCDetLerEAfl8nxurMBWng03PyzD13DQsP3sVV7UW vnr2M07Na+H9oghQ84PgrpqYRtUD4d7dbb/BvWDD9ueE2k2DtfvvECGgC3dDhLvVw93q4W71 XYA4ALS82+fP9TgzTRnIzvuRG2XYvZ6jQJ2aF9Xga1l6HaBJwCZRLk1JFhPH5UkBTx1IIzFW S6W3b8xieuZ6HQEXJ7lyxOVuJNUBSOJsKrXtjuxRDi6wAoneP5ZZ/tGbcX0Pu1eeT8GfMyQz 858Fq6Oa7a9nMLRTnrulCPmQ+KfahyRZSCGF2EtETpS/hHf7/9oYmaCQk2RygZKhJB/nkXin 6jcCI9l8OtQAGELwCkivo+YpIVoJuZYLXfso12VVR0dHK9DJ35xCiW1yKkm+TF07tcoQTIYk 396gQOT70WXpgyCP2JlmrP+c/HTcsUJ82YP6GFs55dWK94MfFi6b2T9sCekb5r/JJazY1k/T F7RNKj20pveN4+HpBR9sSyPFnHZiUXY+3rxySwnTVFH75vKJihrbSwvJ2GbdDM6Onpm3I7f+ 8Jqp4skNkzdPGmEtyPg57Ufh3WHJWVt5b3vs/dyWRZr1LCG5ONMAXJS4X1CBdx4JBAAA Cc: "mpls@ietf.org" , "ietf@ietf.org" Subject: Re: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 18:50:43 -0000 Hi all, I concur with both parts of Dave's message :-( and support publication of th= e draft. I have an editorial/factual comment regarding Section 4.2 of the draft. Let's begin with the fact that SAToP (i.e. RFC 4553) is not a Draft Standard= , it is a Proposed Standard RFC. Further, I am not sure that the relationship between SAToP and other TDM PW= modes - CESoPSN (RFC 5086) and TDMoIP (RFC 5087) - is correctly described i= n Section 4.2 of the draft. At least neither RFC 5086 not RFC 5087 contain a= ny explicit statements about SAToP as the "MUST to implement" protocol. My 2c, Sasha ________________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of David Allan= I [david.i.allan@ericsson.com] Sent: Thursday, October 06, 2011 1:05 AM To: ietf@ietf.org; mpls@ietf.org Subject: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to In= formational RFC I think it is unfortunate that we are in a situation where such a document h= as utility. But ultimately it does. Therefore I support the publication of draft-sprecher... D > MPLS Working Group, > > Please be aware of the IETF last call as shown below. The document was > presented for publication as an individual RFC with IETF consensus and > AD sponsorship. > > This draft is clearly close and relevant to the work you do, but after > discussing with the chairs I came to the conclusion that it does not > comment on the technical or process decisions of the MPLS working > groups, and it does not attempt to make any technical evaluations or > definitions within the scope of the MPLS working group. It is more of > a philosophical analysis of the way the IETF approaches the "two > solutions" problem with special reference to MPLS-TP OAM. > > Thus, I am accepting the document as AD Sponsored rather than running > it through the MPLS working group. My reasoning is that the working > group has got plenty to do working on technical issues without being > diverted into wider IETF philosophy. > > As an AD Sponsored I-D it is subject to a four week IETF last call. > That is plenty of opportunity for everyone to comment and express > their views. Please send your comments to the IETF mailing list as > described below, or (in exceptional circumstances) direct to the IESG. > > Thanks, > Adrian _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From malcolm.betts@zte.com.cn Thu Oct 6 14:54:40 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44E621F8D49; Thu, 6 Oct 2011 14:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.8 X-Spam-Level: X-Spam-Status: No, score=-101.8 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1GD0PcuPVKQ; Thu, 6 Oct 2011 14:54:39 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA0421F8D37; Thu, 6 Oct 2011 14:54:38 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 46621817668700; Fri, 7 Oct 2011 05:53:31 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 75544.2554717648; Fri, 7 Oct 2011 05:57:40 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p96Lvait056484; Fri, 7 Oct 2011 05:57:36 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <4E8E05E4.5020600@gmail.com> References: <4E8CBB02.3080300@gmail.com> <4E8E05E4.5020600@gmail.com> To: Brian E Carpenter MIME-Version: 1.0 X-KeepSent: 3E955E1B:A82B9C99-85257921:007832F8; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Thu, 6 Oct 2011 17:57:09 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-07 05:57:36, Serialize complete at 2011-10-07 05:57:36 Content-Type: multipart/alternative; boundary="=_alternative 00788E2885257921_=" X-MAIL: mse02.zte.com.cn p96Lvait056484 Cc: "ietf@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 21:54:40 -0000 This is a multipart message in MIME format. --=_alternative 00788E2885257921_= Content-Type: text/plain; charset="US-ASCII" Brian, Thank you for your constructive suggestion. I will attempt to start a discussion on a new thread in a few days - I am currently travelling with very limited time windows when I can access the Internet. Regards, Malcolm Brian E Carpenter 06/10/2011 03:47 PM To Malcolm.BETTS@zte.com.cn cc "adrian@olddog.co.uk" , "ietf@ietf.org" , "mpls@ietf.org" Subject Re: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Malcolm, I'm technically incompetent to comment on draft-tsb-mpls-tp-ach-ptn. However, if we reframe the debate as "how to reconcile OaM for Ethernet-based PTN with OaM for MPLS-TP-based PTN", we might have a more productive discussion. Regards Brian Carpenter On 2011-10-07 03:00, Malcolm.BETTS@zte.com.cn wrote: > Brian, > > The second solution already exists, (300,00+ nodes already deployed - see > other emails on this thread). We must acknowledge this and find the most > cost effective way of allowing interconnection. That is best achieved by > recognizing the Ethernet tool set based solution and defining > interconnection such that an interworking function is not required. This > has already been proposed and documented in draft revised Recommendation > G.8110.1 (now in ITU-T last call) and is described in > draft-tsb-mpls-tp-ach-ptn. > > Regards, > > Malcolm --=_alternative 00788E2885257921_= Content-Type: text/html; charset="US-ASCII" Brian,

Thank you for your constructive suggestion.

I will attempt to start a discussion on a new thread in a few days - I am currently travelling with very limited time windows when I can access the Internet.

Regards,

Malcolm



Brian E Carpenter <brian.e.carpenter@gmail.com>

06/10/2011 03:47 PM

To
Malcolm.BETTS@zte.com.cn
cc
"adrian@olddog.co.uk" <adrian@olddog.co.uk>, "ietf@ietf.org" <ietf@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Subject
Re:  Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt> (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC





Malcolm,

I'm technically incompetent to comment on draft-tsb-mpls-tp-ach-ptn.
However, if we reframe the debate as "how to reconcile OaM for
Ethernet-based PTN with OaM for MPLS-TP-based PTN", we might have
a more productive discussion.

Regards
  Brian Carpenter

On 2011-10-07 03:00, Malcolm.BETTS@zte.com.cn wrote:
> Brian,
>
> The second solution already exists, (300,00+ nodes already deployed - see
> other emails on this thread).  We must acknowledge this and find the most
> cost effective way of allowing interconnection.  That is best achieved by
> recognizing the Ethernet tool set based solution and defining
> interconnection such that an interworking function is not required.  This
> has already been proposed and documented in draft revised Recommendation
> G.8110.1 (now in ITU-T last call) and is described in
> draft-tsb-mpls-tp-ach-ptn.
>
> Regards,
>
> Malcolm
--=_alternative 00788E2885257921_=-- From prvs=026176935b=medel@globetel.com.ph Thu Oct 6 18:56:45 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7D421F8B98; Thu, 6 Oct 2011 18:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RELAY_IS_203=0.994] 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 UsAGZoWxzyhu; Thu, 6 Oct 2011 18:56:45 -0700 (PDT) Received: from smtp02.globetel.com.ph (smtp02.globetel.com.ph [203.177.192.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1CA21F8B95; Thu, 6 Oct 2011 18:56:44 -0700 (PDT) Received: from exgtbh01.globetel.com ([10.225.208.17]) by smtp02.globetel.com.ph (8.14.4/8.14.4) with ESMTP id p971xqh2007342; Fri, 7 Oct 2011 09:59:54 +0800 Received: from EXVSGT02.globetel.com ([10.225.208.145]) by exgtbh01.globetel.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 09:59:51 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Oct 2011 09:59:51 +0800 Message-ID: In-reply-to: <60C093A41B5E45409A19D42CF7786DFD5223D56BC2@EUSAACMS0703.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: FW: Last Call: (The Reasons forSelecting a Single Solution for MPLS-TP OAM) to Informational RFC Thread-index: AcyDbrFqpM0ZIVszRuGUW9DSFCBJHAAQsrewADjRcTA= X-Priority: 1 Priority: Urgent Importance: high References: <1317815466.64710.YahooMailClassic@web15608.mail.cnb.yahoo.com> <60C093A41B5E45409A19D42CF7786DFD5223D56BC2@EUSAACMS0703.eamcs.ericsson.se> From: "GT RAMIREZ, Medel G." To: , X-OriginalArrivalTime: 07 Oct 2011 01:59:51.0817 (UTC) FILETIME=[CD1D2F90:01CC8494] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-10-07_01:2011-10-06, 2011-10-07, 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-1012030000 definitions=main-1110060318 Subject: Re: [mpls] FW: Last Call: (The Reasons forSelecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 01:56:46 -0000 -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of David Allan I Sent: Thursday, October 06, 2011 7:05 AM To: ietf@ietf.org; mpls@ietf.org Cc: Adrian Farrel Subject: R: FW: Last Call: (The Reasons forSelecting a Single Solution for MPLS-TP OAM) to Informational RFC I think it is unfortunate that we are in a situation where such a document has utility. But ultimately it does. Therefore I support the publication of draft-sprecher... D > MPLS Working Group, > > Please be aware of the IETF last call as shown below. The document was > presented for publication as an individual RFC with IETF consensus and > AD sponsorship. > > This draft is clearly close and relevant to the work you do, but after > discussing with the chairs I came to the conclusion that it does not=20 > comment on the technical or process decisions of the MPLS working=20 > groups, and it does not attempt to make any technical evaluations or=20 > definitions within the scope of the MPLS working group. It is more of=20 > a philosophical analysis of the way the IETF approaches the "two=20 > solutions" problem with special reference to MPLS-TP OAM. > > Thus, I am accepting the document as AD Sponsored rather than running=20 > it through the MPLS working group. My reasoning is that the working=20 > group has got plenty to do working on technical issues without being=20 > diverted into wider IETF philosophy. > > As an AD Sponsored I-D it is subject to a four week IETF last call.=20 > That is plenty of opportunity for everyone to comment and express=20 > their views. Please send your comments to the IETF mailing list as=20 > described below, or (in exceptional circumstances) direct to the IESG. > > Thanks, > Adrian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf This e-mail message (including attachments, if any) is intended for the use= of the individual or the entity to whom it is addressed and may contain in= formation that is privileged, proprietary, confidential and exempt from dis= closure. If you are not the intended recipient, you are notified that any d= issemination, distribution or copying of this communication is strictly pro= hibited. If you have received this communication in error, please notify th= e sender and delete this E-mail message immediately. From ietfc@btconnect.com Fri Oct 7 03:37:38 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931C921F8BB2 for ; Fri, 7 Oct 2011 03:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 o420AbQDNdca for ; Fri, 7 Oct 2011 03:37:37 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr08.btconnect.com [213.123.26.186]) by ietfa.amsl.com (Postfix) with ESMTP id 5800E21F8520 for ; Fri, 7 Oct 2011 03:37:37 -0700 (PDT) Received: from host86-163-147-122.range86-163.btcentralplus.com (HELO pc6) ([86.163.147.122]) by c2beaomr08.btconnect.com with SMTP id EPN01104; Fri, 07 Oct 2011 11:40:44 +0100 (BST) Message-ID: <005601cc84d4$8b8e6540$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Larry" , References: <1317815466.64710.YahooMailClassic@web15608.mail.cnb.yahoo.com> Date: Fri, 7 Oct 2011 08:27:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4E8ED72B.00BC, actions=tag X-Junkmail-Premium-Raw: score=14/50, refid=2.7.2:2011.10.7.95126:17:14.805, ip=86.163.147.122, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, DATE_IN_PAST_03_06, __ANY_URI, CN_TLD, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __URI_NO_PATH, __FRAUD_CONTACT_NUM, ECARD_KNOWN_DOMAINS, __HIGHBITS, __C230066_P5, __INT_PROD_LOC, BODY_SIZE_5000_5999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS X-Junkmail-Status: score=14/50, host=c2beaomr08.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0208.4E8ED72E.01CC,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: Re: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 10:37:38 -0000 ----- Original Message ----- From: "Larry" To: ; ; ; "D'Alessandro Alessandro Gerardo" Sent: Wednesday, October 05, 2011 1:51 PM > Dear all, > > So many multiple solution cases just show the way that the world and technology works. Killing a solution roughly brings more damage to the industry. > > Section 3.6 discusses the elements of the choice of solutions. Current application and deployment should be considered. In China Mobile, more than 330,000 PTN box are/will based on G.8113.1. It is an impressive achievement and I would be interested in hearing more. In particular, what are the manufacturers involved? As you probably know, the IETF looks for interoperability between independent implementations as a condition for standardisation so I would like to know who the manufacturers are, are the implementations independent, or are they all derived from a single code source? And you say 'will be based on G.8113.1' - what actually is the specification of the existing boxes? I seem to recall last year you saying that draft-bhh-MPLS-TP-OAM-Y1731 was the basis with a plan to upgrade to G.8114. Tom Petch > > TDM PW gives a good example. G.8113.1 based OAM is relative simple and mature and widely deployed and should be the standard. > > Best regards, > > Han Li > > --- 11å¹´10月5日，周三, D'Alessandro Alessandro Gerardo 写é“： > > > å‘件人: D'Alessandro Alessandro Gerardo > 收件人: "adrian@olddog.co.uk" , "mpls@ietf.org" , "ietf@ietf.org" > > 日期: 2011å¹´10月5æ—¥,周三,下åˆ5:38 > > Dear all, > > I do not support. > > > > Basically I think it is superfluous dedicate an RFC to > > state it is better having one standard instead of two ones > > or many... for sure the lower are the variants the better is > > for the industry (one is the ideal). > > > > When two or more standards or de-facto standards exist it > > is because the problem they solve is not exactly the same, > > the way they solve the problem is optimized for different > > environments/boundary conditions (more efficient, more > > effective, etc). Therefore a single solution does not > > necessarily meet the different market requirements. > > > > It is fundamental to enter into the problem's details > > before making consideration about the best way to proceed > > (one solution, two solutions, multiple solutions) whilst the > > document clearly declares it does not want to make any > > technical evaluations. > > > > After more than three years of debates within the IETF and > > major unresolved technical concerns risen from some > > transport operators, the existence of this draft is by > > itself the sure sign that MPLS-TP OAM is a case where a > > single solution has not be found to meet all the different > > market requirements. Otherwise, why are we still discussing > > about it....? > > > > Therefore we must be realistic and the lessons learned from > > the past should guide our decisions: if a solution cannot be > > found for satisfying all the requirements it is better to > > have two standards and let the market decide how to exploit > > them. Are we really sure the cost(many) / benefit > > (none) analysis done in section 7.5 is realistic? > > > > Best regards, > > Alessandro > > > > ------------------------------------------------------------------ > > Telecom Italia > > Alessandro D'Alessandro > > Transport Innovation > > Via Reiss Romoli, 274 - 10148 Torino > > phone: +39 011 228 5887 > > mobile: +39 335 766 9607 > > fax: +39 06 418 639 07 > > > > -----Messaggio originale----- > > Da: mpls-bounces@ietf.org > > [mailto:mpls-bounces@ietf.org] > > Per conto di Adrian Farrel > > Inviato: lunedì 26 settembre 2011 23:58 > > A: mpls@ietf.org > > Oggetto: [mpls] FW: Last Call: > > > > (The Reasons for Selecting a Single Solution for MPLS-TP > > OAM) to Informational RFC > > > > MPLS Working Group, > > > > Please be aware of the IETF last call as shown below. The > > document was presented for publication as an individual RFC > > with IETF consensus and AD sponsorship. > > > > This draft is clearly close and relevant to the work you > > do, but after discussing with the chairs I came to the > > conclusion that it does not comment on the technical or > > process decisions of the MPLS working groups, and it does > > not attempt to make any technical evaluations or definitions > > within the scope of the MPLS working group. It is more of a > > philosophical analysis of the way the IETF approaches the > > "two solutions" problem with special reference to MPLS-TP > > OAM. > > > > Thus, I am accepting the document as AD Sponsored rather > > than running it through the MPLS working group. My reasoning > > is that the working group has got plenty to do working on > > technical issues without being diverted into wider IETF > > philosophy. > > > > As an AD Sponsored I-D it is subject to a four week IETF > > last call. That is plenty of opportunity for everyone to > > comment and express their views. Please send your comments > > to the IETF mailing list as described below, or (in > > exceptional circumstances) direct to the IESG. > > > > Thanks, > > Adrian > > > From Rolf.Winter@neclab.eu Fri Oct 7 06:36:05 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A32521F8B8E; Fri, 7 Oct 2011 06:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 W1J9LL3yP0BK; Fri, 7 Oct 2011 06:36:04 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2F62021F8B8F; Fri, 7 Oct 2011 06:36:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 78F44280001AC; Fri, 7 Oct 2011 15:39:17 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NK7LJ2GvXCpn; Fri, 7 Oct 2011 15:39:17 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 5A5B3280001A7; Fri, 7 Oct 2011 15:39:02 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.240]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 7 Oct 2011 15:38:41 +0200 From: Rolf Winter To: David Allan I , "ietf@ietf.org" , "mpls@ietf.org" Thread-Topic: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Thread-Index: AQHMg7NVLiGs3WUwf0Wf2ftigYyUoJVw5EGw Date: Fri, 7 Oct 2011 13:38:41 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D1D0A26C4@DAPHNIS.office.hd> References: <1317815466.64710.YahooMailClassic@web15608.mail.cnb.yahoo.com> <60C093A41B5E45409A19D42CF7786DFD5223D56BC2@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD5223D56BC2@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.202] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 13:36:05 -0000 Dave, could you be more precise about what you think the utility of this document= is in this particular situation. I mean, what will its effect be in the cu= rrent situation. What will change after this document has been published. I= t seems everybody believes the "situation" will be resolved once this docum= ent receives its RFC number. I cannot see that. Could you give me more deta= il? Best,=20 Rolf =20 NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > David Allan I > Sent: Donnerstag, 6. Oktober 2011 01:05 > To: ietf@ietf.org; mpls@ietf.org > Subject: [mpls] R: FW: Last Call: considerations-01.txt> (The Reasons for Selecting a Single Solution for > MPLS-TP OAM) to Informational RFC >=20 > I think it is unfortunate that we are in a situation where such a > document has utility. But ultimately it does. >=20 > Therefore I support the publication of draft-sprecher... >=20 > D >=20 >=20 >=20 > > MPLS Working Group, > > > > Please be aware of the IETF last call as shown below. The document > was > > presented for publication as an individual RFC with IETF consensus > and > > AD sponsorship. > > > > This draft is clearly close and relevant to the work you do, but > after > > discussing with the chairs I came to the conclusion that it does not > > comment on the technical or process decisions of the MPLS working > > groups, and it does not attempt to make any technical evaluations or > > definitions within the scope of the MPLS working group. It is more of > > a philosophical analysis of the way the IETF approaches the "two > > solutions" problem with special reference to MPLS-TP OAM. > > > > Thus, I am accepting the document as AD Sponsored rather than running > > it through the MPLS working group. My reasoning is that the working > > group has got plenty to do working on technical issues without being > > diverted into wider IETF philosophy. > > > > As an AD Sponsored I-D it is subject to a four week IETF last call. > > That is plenty of opportunity for everyone to comment and express > > their views. Please send your comments to the IETF mailing list as > > described below, or (in exceptional circumstances) direct to the IESG. > > > > Thanks, > > Adrian > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From tnadeau@lucidvision.com Fri Oct 7 07:47:00 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E6721F84D9 for ; Fri, 7 Oct 2011 07:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.458, 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 fSd8Cma3iyVE for ; Fri, 7 Oct 2011 07:47:00 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 60A8B21F84F5 for ; Fri, 7 Oct 2011 07:47:00 -0700 (PDT) Received: from [10.100.68.205] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id 4316B1EB199E for ; Fri, 7 Oct 2011 10:40:36 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Thomas Nadeau In-Reply-To: <791AD3077F94194BB2BDD13565B6295D1D0A26C4@DAPHNIS.office.hd> Date: Fri, 7 Oct 2011 10:40:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7E96D96B-F4BB-445E-A9BD-2274A06DB2B6@lucidvision.com> References: <1317815466.64710.YahooMailClassic@web15608.mail.cnb.yahoo.com> <60C093A41B5E45409A19D42CF7786DFD5223D56BC2@EUSAACMS0703.eamcs.ericsson.se> <791AD3077F94194BB2BDD13565B6295D1D0A26C4@DAPHNIS.office.hd> To: mpls@ietf.org X-Mailer: Apple Mail (2.1244.3) Subject: [mpls] Software Defined Networks (SDN) BoF in Taipei X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 14:47:00 -0000 I wanted to pass on some information regarding a BoF that is = planned for Taipei that is relevant to=20 participants of this mailing list/WG area. =20 The IAB and IESG met today to discuss BoFs for Taipei and agreed = that we will hold a BoF SDN with a goal of "discussing the technology and identifying work = items". The BoF is nominally=20 in the Routing Area, but we expect considerable involvement from the OPS = Area as well.=20 The following is a link to the drafts and other documentation = around the SDN effort including some presentations, and a link to join the BoF mailing list.=20= =09 http://trac.tools.ietf.org/bof/trac/ We encourage you to join the list, review the materials and = participate on the mailing list as well as come to the BoF if you have an interest in this work. --Tom From loa@pi.nu Fri Oct 7 07:48:49 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEEEF21F8BF3 for ; Fri, 7 Oct 2011 07:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.637 X-Spam-Level: X-Spam-Status: No, score=-102.637 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 yQ0LIE4Fvdpx for ; Fri, 7 Oct 2011 07:48:49 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0EC21F8BEE for ; Fri, 7 Oct 2011 07:48:49 -0700 (PDT) Received: from [192.168.1.64] (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 mail.pi.nu (Postfix) with ESMTPSA id 44FD12A8002; Fri, 7 Oct 2011 16:51:55 +0200 (CEST) Message-ID: <4E8F120A.8080200@pi.nu> Date: Fri, 07 Oct 2011 16:51:54 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" , draft-zhao-mpls-ldp-multi-topology@tools.ietf.org References: <4E78D844.4090809@pi.nu> In-Reply-To: <4E78D844.4090809@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 14:48:49 -0000 All, this poll has ended and we have a new working group document! Could the authors please publish draft-ietf-mpls-ldp-multi-topology-00.txt with no other changes than the file name and dates as timely as possible. /Loa for the wg chairs On 2011-09-20 20:15, Loa Andersson wrote: > Working Group, > > this is to start a two week poll to see if there is support to make > > LDP Extension for Multi Topology Support > draft-zhao-mpls-ldp-multi-topology-02.txt > > an MPLS working group document. > > Send your opinions to mpls@ietf.org > > Please remember that it is particular important that you include a > technical motivation if you don't want the ID to become a > working group document. > > The poll ends Wednesday Oct 5, 2011. > > /Loa > for the MPLS wg co-chairs > > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From david.i.allan@ericsson.com Fri Oct 7 08:18:13 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC65921F893C; Fri, 7 Oct 2011 08:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 Djgka9srU2KS; Fri, 7 Oct 2011 08:18:13 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDA821F888A; Fri, 7 Oct 2011 08:18:13 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p97FLQX7025206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Oct 2011 10:21:26 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.120]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 7 Oct 2011 11:21:24 -0400 From: David Allan I To: Rolf Winter , "ietf@ietf.org" , "mpls@ietf.org" Date: Fri, 7 Oct 2011 11:21:23 -0400 Thread-Topic: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Thread-Index: AQHMg7NVLiGs3WUwf0Wf2ftigYyUoJVw5EGwgAAbhTA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD5223D575ED@EUSAACMS0703.eamcs.ericsson.se> References: <1317815466.64710.YahooMailClassic@web15608.mail.cnb.yahoo.com> <60C093A41B5E45409A19D42CF7786DFD5223D56BC2@EUSAACMS0703.eamcs.ericsson.se> <791AD3077F94194BB2BDD13565B6295D1D0A26C4@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D1D0A26C4@DAPHNIS.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 15:18:14 -0000 IMO it is a statement of principle going forward. As such it does not "fix"= or "make go away" the current situation, but it would be an IETF consensus= position on a way forward. And I agree with that position. Lots of folks do proprietary deployments, squat on code points etc. That ca= nnot be "fixed" either, but I do not believe in rewarding it. Dave=20 -----Original Message----- From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]=20 Sent: Friday, October 07, 2011 6:39 AM To: David Allan I; ietf@ietf.org; mpls@ietf.org Subject: RE: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM)= to Informational RFC Dave, could you be more precise about what you think the utility of this document= is in this particular situation. I mean, what will its effect be in the cu= rrent situation. What will change after this document has been published. I= t seems everybody believes the "situation" will be resolved once this docum= ent receives its RFC number. I cannot see that. Could you give me more deta= il? Best,=20 Rolf =20 NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=20 > Of David Allan I > Sent: Donnerstag, 6. Oktober 2011 01:05 > To: ietf@ietf.org; mpls@ietf.org > Subject: [mpls] R: FW: Last Call: considerations-01.txt> (The Reasons for Selecting a Single Solution=20 > for MPLS-TP OAM) to Informational RFC >=20 > I think it is unfortunate that we are in a situation where such a=20 > document has utility. But ultimately it does. >=20 > Therefore I support the publication of draft-sprecher... >=20 > D >=20 >=20 >=20 > > MPLS Working Group, > > > > Please be aware of the IETF last call as shown below. The document > was > > presented for publication as an individual RFC with IETF consensus > and > > AD sponsorship. > > > > This draft is clearly close and relevant to the work you do, but > after > > discussing with the chairs I came to the conclusion that it does not=20 > > comment on the technical or process decisions of the MPLS working=20 > > groups, and it does not attempt to make any technical evaluations or=20 > > definitions within the scope of the MPLS working group. It is more=20 > > of a philosophical analysis of the way the IETF approaches the "two=20 > > solutions" problem with special reference to MPLS-TP OAM. > > > > Thus, I am accepting the document as AD Sponsored rather than=20 > > running it through the MPLS working group. My reasoning is that the=20 > > working group has got plenty to do working on technical issues=20 > > without being diverted into wider IETF philosophy. > > > > As an AD Sponsored I-D it is subject to a four week IETF last call. > > That is plenty of opportunity for everyone to comment and express=20 > > their views. Please send your comments to the IETF mailing list as=20 > > described below, or (in exceptional circumstances) direct to the IESG. > > > > Thanks, > > Adrian > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From warren@kumari.net Fri Oct 7 09:31:55 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A7621F851A; Fri, 7 Oct 2011 09:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.751 X-Spam-Level: X-Spam-Status: No, score=-104.751 tagged_above=-999 required=5 tests=[AWL=1.848, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9i971xbkGS8x; Fri, 7 Oct 2011 09:31:54 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 6798B21F84B4; Fri, 7 Oct 2011 09:31:54 -0700 (PDT) Received: from dhcp-172-19-119-117.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 133711B40923; Fri, 7 Oct 2011 12:35:06 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <05B25596-719A-423C-BB6C-68868C0314B9@ericsson.com> Date: Fri, 7 Oct 2011 12:35:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1317815466.64710.YahooMailClassic@web15608.mail.cnb.yahoo.com> <60C093A41B5E45409A19D42CF7786DFD5223D56BC2@EUSAACMS0703.eamcs.ericsson.se> <05B25596-719A-423C-BB6C-68868C0314B9@ericsson.com> To: David Sinicrope X-Mailer: Apple Mail (2.1084) Cc: "mpls@ietf.org" , "ietf@ietf.org" Subject: Re: [mpls] [IETF] Re: R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 16:31:55 -0000 While it is not perfect, I too support publication... W On Oct 5, 2011, at 7:11 PM, David Sinicrope wrote: > I concur with Dave's comment and support publication of the draft. > Dave >=20 >=20 >=20 > On Oct 5, 2011, at 7:06 PM, "David Allan I" = wrote: >=20 >> I think it is unfortunate that we are in a situation where such a = document has utility. But ultimately it does. >>=20 >> Therefore I support the publication of draft-sprecher... >>=20 >> D >>=20 >>=20 >>=20 >>> MPLS Working Group, >>>=20 >>> Please be aware of the IETF last call as shown below. The document = was=20 >>> presented for publication as an individual RFC with IETF consensus = and=20 >>> AD sponsorship. >>>=20 >>> This draft is clearly close and relevant to the work you do, but = after=20 >>> discussing with the chairs I came to the conclusion that it does not=20= >>> comment on the technical or process decisions of the MPLS working=20 >>> groups, and it does not attempt to make any technical evaluations or=20= >>> definitions within the scope of the MPLS working group. It is more = of=20 >>> a philosophical analysis of the way the IETF approaches the "two=20 >>> solutions" problem with special reference to MPLS-TP OAM. >>>=20 >>> Thus, I am accepting the document as AD Sponsored rather than = running=20 >>> it through the MPLS working group. My reasoning is that the working=20= >>> group has got plenty to do working on technical issues without being=20= >>> diverted into wider IETF philosophy. >>>=20 >>> As an AD Sponsored I-D it is subject to a four week IETF last call.=20= >>> That is plenty of opportunity for everyone to comment and express=20 >>> their views. Please send your comments to the IETF mailing list as=20= >>> described below, or (in exceptional circumstances) direct to the = IESG. >>>=20 >>> Thanks, >>> Adrian >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From internet-drafts@ietf.org Fri Oct 7 10:25:24 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1496921F8C99; Fri, 7 Oct 2011 10:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 RkHkVs9P-dA4; Fri, 7 Oct 2011 10:25:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DDD21F8C86; Fri, 7 Oct 2011 10:25:23 -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: 3.60 Message-ID: <20111007172523.4765.3502.idtracker@ietfa.amsl.com> Date: Fri, 07 Oct 2011 10:25:23 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-multi-topology-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 17:25:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : LDP Extension for Multi Topology Support Author(s) : Quintin Zhao Luyuang Fang Chao Zhou Lianyuan Li Ning So Raveendra Torvi Filename : draft-ietf-mpls-ldp-multi-topology-00.txt Pages : 21 Date : 2011-10-07 Multi-Topology (MT) routing is supported in IP through extension of IGP protocols, such as OSPF and IS-IS. Each route computed by OSPF or IS-IS is associated with a specific topology. Label Distribution Protocol (LDP) is used to distribute labels for FECs advertised by routing protocols. It is a natural requirement to extend LDP in order to make LDP be aware of MT and thus take advantage of MT based routing. This document describes options to extend the existing MPLS signalling protocol (LDP) for creating and maintaining Label Switching Paths (LSPs) in a Multi-Topology enviroment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-multi-topology-00.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-ldp-multi-topology-00.txt From loa@pi.nu Fri Oct 7 12:53:59 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9FC21F8C35 for ; Fri, 7 Oct 2011 12:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.636 X-Spam-Level: X-Spam-Status: No, score=-102.636 tagged_above=-999 required=5 tests=[AWL=-0.037, 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 yUDMIeeFlDCf for ; Fri, 7 Oct 2011 12:53:58 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id ABC1821F8C32 for ; Fri, 7 Oct 2011 12:53:58 -0700 (PDT) Received: from [192.168.1.64] (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 mail.pi.nu (Postfix) with ESMTPSA id B36682A8002; Fri, 7 Oct 2011 21:57:10 +0200 (CEST) Message-ID: <4E8F5996.80103@pi.nu> Date: Fri, 07 Oct 2011 21:57:10 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] working group last call on draft-ietf-mpls-mldp-in-band-signaling-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 19:53:59 -0000 Working group, this is to start a two week working group last call on draft-ietf-mpls-mldp-in-band-signaling-04 Please send your comments to the working group mailing list. This working group last call end on October 23rd. /Loa for the working group chars -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From brian.e.carpenter@gmail.com Wed Oct 5 13:13:12 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECCB11E80C2; Wed, 5 Oct 2011 13:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.188 X-Spam-Level: X-Spam-Status: No, score=-103.188 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, SARE_SUB_ENC_UTF8=0.152, 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 JgXPcGSlncxF; Wed, 5 Oct 2011 13:13:11 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4A811E80CC; Wed, 5 Oct 2011 13:13:08 -0700 (PDT) Received: by qadb12 with SMTP id b12so2012612qad.31 for ; Wed, 05 Oct 2011 13:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=eyKc49yYn4MwJjxwHpJWMzpXYjxFYmttMUqGqikGXw4=; b=WPLv2EvetLeEFISyMi5SQw9AJw8jWMxWEpmf2YpbzfOegfd/1j5zb9SDWoImDaxXF9 VarhS91uskyntpfQzoR2TJukakb1lNzROBJradop3ze9ihdEsm292W/3e33xf/lj41pe BeJVLlsmAkzA4Zsj7Jvyg/Dm3V3T2decMELLk= Received: by 10.224.187.9 with SMTP id cu9mr2270266qab.368.1317845776864; Wed, 05 Oct 2011 13:16:16 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id et6sm3388175qab.4.2011.10.05.13.16.12 (version=SSLv3 cipher=OTHER); Wed, 05 Oct 2011 13:16:15 -0700 (PDT) Message-ID: <4E8CBB02.3080300@gmail.com> Date: Thu, 06 Oct 2011 09:16:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: yang.jian90@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 10 Oct 2011 08:02:00 -0700 Cc: "mpls@ietf.org" , "ietf@ietf.org" , mpls-bounces@ietf.orgLarry Subject: Re: [mpls] =?utf-8?b?562U5aSNOiAg5Zue5aSN77yaICBSOiBGVzogTGFzdCBDYWxs?= =?utf-8?q?=3A_=3Cdraft-sprecher-mpls-tp-oam-considerations-01=2Etxt=3E_?= =?utf-8?q?=28The_Reasons_for_Selecting_a_Single_Solution_for_MPLS-TP_OAM?= =?utf-8?q?=29_to_Informational_RFC?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 20:13:12 -0000 Hi Jian, On 2011-10-06 03:53, yang.jian90@zte.com.cn wrote: > Dear All, > > I do not support either. > > In section 3.5: > If two MPLS OAM protocols were to be deployed we would have to consider > three possible scenarios: > 1) Isolation of the network into two incompatible and unconnected islands. > > Two OAM solutions have been discussed for a long time in both ITU-T and > IETF. > Each solution has their own supporters inculding carriers and vendors. > So I don't think there is any interworking issue between two OAM solutions. > Carrier will select one OAM solution, A or B, in their network. > No need to select A and B at one network at the same time. There are two large costs that you are ignoring: a) all vendors wishing to bid for business from A and B will have to implement and support both solutions. b) when A buys B or B buys A, the incompatible networks will have to be merged. These are costs that run to hundreds of millions of USD, EUR or CNY. They are costs caused directly by SDOs creating rival solutions. I think it would be irresponsible of the IETF not to document this situation. As engineers, we have an ethical responsibility here. Brian From brian.e.carpenter@gmail.com Thu Oct 6 12:44:49 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B4721F8DD4; Thu, 6 Oct 2011 12:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKDlvoJaal0N; Thu, 6 Oct 2011 12:44:48 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 75C0D21F8DCC; Thu, 6 Oct 2011 12:44:48 -0700 (PDT) Received: by ywm3 with SMTP id 3so3602684ywm.31 for ; Thu, 06 Oct 2011 12:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gqA+6dIeyJqEjeJco9EuI97sSIVYVIOF10vhB2bLmYk=; b=QV3MDrc1cmfA/lrqgJSDZyyIiojSvKsDfjgjP0aD5oEL8Lf4DY08oRcMW1YeTs9VOI GWpB48iMNxpMI9XfNlwi59TNeKcr9OJFzLgQqO3L/Vn2v4UzhQ8la+/MZO/rQIiGQRW/ a8Dk+gIQ1FD5r4gde/ChNNAHDw1gLg9P2l4gE= Received: by 10.223.63.75 with SMTP id a11mr5567559fai.9.1317930479464; Thu, 06 Oct 2011 12:47:59 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id u6sm8495102fan.17.2011.10.06.12.47.56 (version=SSLv3 cipher=OTHER); Thu, 06 Oct 2011 12:47:58 -0700 (PDT) Message-ID: <4E8E05E4.5020600@gmail.com> Date: Fri, 07 Oct 2011 08:47:48 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Malcolm.BETTS@zte.com.cn References: <4E8CBB02.3080300@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 10 Oct 2011 08:02:01 -0700 Cc: "ietf@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 19:44:49 -0000 Malcolm, I'm technically incompetent to comment on draft-tsb-mpls-tp-ach-ptn. However, if we reframe the debate as "how to reconcile OaM for Ethernet-based PTN with OaM for MPLS-TP-based PTN", we might have a more productive discussion. Regards Brian Carpenter On 2011-10-07 03:00, Malcolm.BETTS@zte.com.cn wrote: > Brian, > > The second solution already exists, (300,00+ nodes already deployed - see > other emails on this thread). We must acknowledge this and find the most > cost effective way of allowing interconnection. That is best achieved by > recognizing the Ethernet tool set based solution and defining > interconnection such that an interworking function is not required. This > has already been proposed and documented in draft revised Recommendation > G.8110.1 (now in ITU-T last call) and is described in > draft-tsb-mpls-tp-ach-ptn. > > Regards, > > Malcolm From randy@psg.com Fri Oct 7 13:48:14 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B5021F8BB6; Fri, 7 Oct 2011 13:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 c3RYgGl-ujrT; Fri, 7 Oct 2011 13:48:14 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id CCBE021F8BB0; Fri, 7 Oct 2011 13:48:13 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RCHO6-000130-8Y; Fri, 07 Oct 2011 20:51:22 +0000 Date: Sat, 08 Oct 2011 05:51:20 +0900 Message-ID: From: Randy Bush To: David Allan I In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD5223D575ED@EUSAACMS0703.eamcs.ericsson.se> References: <1317815466.64710.YahooMailClassic@web15608.mail.cnb.yahoo.com> <60C093A41B5E45409A19D42CF7786DFD5223D56BC2@EUSAACMS0703.eamcs.ericsson.se> <791AD3077F94194BB2BDD13565B6295D1D0A26C4@DAPHNIS.office.hd> <60C093A41B5E45409A19D42CF7786DFD5223D575ED@EUSAACMS0703.eamcs.ericsson.se> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Mon, 10 Oct 2011 08:02:27 -0700 Cc: "mpls@ietf.org" , "ietf@ietf.org" Subject: Re: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 20:48:14 -0000 > IMO it is a statement of principle going forward. As such it does not > "fix" or "make go away" the current situation, but it would be an IETF > consensus position on a way forward. And I agree with that position. > > Lots of folks do proprietary deployments, squat on code points > etc. That cannot be "fixed" either, but I do not believe in rewarding > it. or aiding or abetting it. +1 randy From adrian@olddog.co.uk Wed Oct 5 13:34:17 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C8221F8C54 for ; Wed, 5 Oct 2011 13:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.091, 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 0hhXX7r1s6R8 for ; Wed, 5 Oct 2011 13:34:16 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 5463221F8C53 for ; Wed, 5 Oct 2011 13:34:15 -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 p95KbM3W023977; Wed, 5 Oct 2011 21:37:22 +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 p95KbJ67023943 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Oct 2011 21:37:20 +0100 From: "Adrian Farrel" To: "'Greg Mirsky'" Date: Wed, 5 Oct 2011 21:37:17 +0100 Message-ID: <05b001cc839e$9332e780$b998b680$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05B1_01CC83A6.F5007740" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcyDno8DvNjhAlaLSZiOgs9JC+UekQ== Content-Language: en-gb X-Mailman-Approved-At: Mon, 10 Oct 2011 08:02:46 -0700 Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-li-lb-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 20:34:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05B1_01CC83A6.F5007740 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ack to all of that. Adrian From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: 05 October 2011 18:13 To: adrian@olddog.co.uk Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-li-lb-07.txt Hi Adrian, yes we're! And I'll try to summarize it below instead of in-lining: * query the WG on applicability of the LB on "coincidental" bidirectional MIP on associated bi-directional LSP; * query the WG on introducing explicit UnLock operation to MPLS-TP OAM set * I accept proposed updates to LB applicability statement * In regard to our discussion of management plane role in setting MEP or MIP into a loopback state (Section 4, p.4, second to last para). I agree with the proposed version for the first sentence but will re-word the second: NEW The management plane must ensure that the two MEPs are locked before performing the loopback function. NEWER The management plane must ensure that the two MEPs are locked before it requests setting MEP or MIP in the loopback state. END * I feel that we're implicitly view and refer to an MPLS Section as bidirectional construct even though it is not. In case of this document I'd propose to explicitly refer to bidirectional MPLS Section where necessary. Regards, Greg On Wed, Oct 5, 2011 at 3:43 AM, Adrian Farrel wrote: Hi again Greg, We are converging. I've cut out the bits where we have reached conclusions. >>> Introduction, third para. >>> Applicability of the Loopback is limited, comparing to previous versions, >>> to bi-directional co-routed LSP, PW and MPLS Section. I agree that >>> statement of applicability in previous versions was bit too cumbersome >>> but this one excludes bi-directional associated LSP at all. I think that >>> Loopback can be used on this construct at MIP that are on forward >>> and reverse direction of given bi-directional associated MPLS-TP LSP. >>> And I think that MPLS Section is not necessarily a bi-directional co- >>> routed object. > > GIM>> But then PW and MPLS Section have been referred twice - > after co-routed LSP, then after associated LSP. Or intention was to apply > co-routed and associated to PW and MPLS Section? Would making the > last sentence to "It can also be applied at a MEP on an associated > bidirectional LSP" be sufficient? But still, MIPs that are on forward > and reverse direction of an associated bi-directional LSP are excluded. > I believe that previous versions tried to include such MIPs since these > are required to be aware of directions and their correlation. Is this > change intentional? You're right. I mangled the original text in my enthusiasm to have something I could parse :-) I think there are two issues: 1. extraneous mention of PW and Section in the last sentence OLD (v7) - The loopback function allows an operator to set a specific node on a transport path into loopback mode such that it returns all received data. Loopback can be applied at a Maintenance Entity Group End Point (MEP) or a Maintenance Entity Group Intermediate Point (MIP) on a co-routed bidirectional LSP, PW or MPLS Section. It can also be applied at a MEP on an associated bidirectional LSP, PW or MPLS Section. NEW - The loopback function allows an operator to set a specific node on a transport path into loopback mode such that it returns all received data. Loopback can be applied at a Maintenance Entity Group End Point (MEP) or a Maintenance Entity Group Intermediate Point (MIP) on a co-routed bidirectional LSP, on a PW, or on an MPLS Section. It can also be applied at a MEP on an associated bidirectional LSP. END 2. Discussion of loopback at "coincident" MIPs on associated bidirectional LSPs. This is a question for the WG not for me (I am only trying to provide an editorial service!). Would you mind raising this as a separate thread so that the WG spot and debate the issue? >>> Section 4, p.4, second to last para. I think that management plane >>> sets in or requests Loopback on specific MP but not performs it. >> >> The two sentences in this paragraph are directly copied from the >> previous revision with the only change to drop "MUST" to lower case. >> >> Not sure what to say here since the WG clearly agreed to this text >> before. I think the intention was to say that a control plane is not >> required in order to achieve loopback. > >GIM>> What if the first sentence says: > > A management plane can be too used to set a MEP or MIP along a > transport path in Loopback. Well, I don't like "too" because this document doesn't actually mention any way to set loopback using the control plane. So what about: OLD (v7) The Loopback can be performed using a management plane. Management plane must ensure that the two MEPs are locked before performing the loopback function. NEW The management plane can be used to configure the Loopback function. The management plane must ensure that the two MEPs are locked before performing the loopback function. END >>> Definition given in Section 4.1 is broader than one in the Introduction. >>> Personally I like the latter better though I think that it can be expanded >>> to include MIPs on bi-directional associated LSP that are on forward and >>> reverse direction of it. >> >> I think it is the same definition. >> See the paragraph quoted above and compare with: >> - The node in loopback mode must be on both the forward and return >> paths. This possible for all MEPs and MIPs on a co-routed >> bidirectional LSP, PW, or MPLS Section, but is only >> possible on for MEPs on associated bidirectional LSPs, PW, >> or MPLS Sections. >> ...which seems to exclude the MIPs on assoc bidir as you say. Same two issues: 1. OLD (v7) - The node in loopback mode must be on both the forward and return paths. This possible for all MEPs and MIPs on a co-routed bidirectional LSP, PW, or MPLS Section, but is only possible on for MEPs on associated bidirectional LSPs, PW, or MPLS Sections. NEW - The node in loopback mode must be on both the forward and return paths. This possible for all MEPs and MIPs on a co-routed bidirectional LSP, on a PW, or on an MPLS Section, but is only possible on for MEPs on associated bidirectional LSPs. END 2. You will raise associated bidir MIPs on the mailing list >>> I'll note that service could not be restored faster than in 3.5 seconds >>> according to described procedure. Is that desired behavior? >> >> That is a good question for the WG. It was my assumption (from the >> previous revision) that rapid unlocking and turn-up was not a >> requirement or it would have been included. >> >> If the WG now wants to include it, it will need to examine the use of an >> unlock OAM message. This could be done using a new message or a flag >> on the existing lock message. It could be achieved by tweaking this >> document or introducing a new document. > > GIM>> I'd support explicit UnLock OAM message. I think that it is required > if LI/LB expected to work in heterogeneous network (without defined > UnLock message or flag request to UnLock is proprietary, in my view). OK. Well, this is another technical, not editorial, change. So I am not really in a position to discuss it. Would you mind creating a separate thread for this one as well? That way the WG can decide what it wants to do. Many thanks for the thorough and thoughtful review. Adrian ------=_NextPart_000_05B1_01CC83A6.F5007740 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ack to all of = that.

 

Adrian

 

From: Greg Mirsky = [mailto:gregimirsky@gmail.com]
Sent: 05 October 2011 = 18:13
To: adrian@olddog.co.uk
Cc: = mpls@ietf.org
Subject: Re: [mpls] Comments on = draft-ietf-mpls-tp-li-lb-07.txt

 

Hi = Adrian,
yes we're! And I'll try to summarize it below instead of = in-lining:

  • query the WG on applicability of the = LB on "coincidental" bidirectional MIP on associated = bi-directional LSP;
  • query the WG on introducing explicit = UnLock operation to MPLS-TP OAM set
  • I accept proposed updates to LB = applicability statement
  • In regard to our discussion of = management plane role in setting MEP or MIP into a loopback state = (Section 4, p.4, second to last para). I agree with the proposed version = for the first sentence but will re-word the = second:

NEW
  The management plane must = ensure that the two MEPs are locked before
  performing the = loopback function.
NEWER
  The management plane must ensure = that the two MEPs are locked before it requests
  setting MEP or = MIP in the loopback state.
END

  • I feel that we're implicitly view and = refer to an MPLS Section as bidirectional construct even though it is = not. In case of this document I'd propose to explicitly refer to = bidirectional MPLS Section where necessary.


Regards,
Greg

=

On Wed, Oct 5, 2011 at 3:43 AM, Adrian Farrel = <adrian@olddog.co.uk> = wrote:

Hi again Greg,

We are = converging.

I've cut out the bits where we have reached = conclusions.


>>> = Introduction, third para.
>>> Applicability of the Loopback = is limited, comparing to previous versions,
>>> to = bi-directional co-routed LSP, PW and MPLS Section. I agree = that
>>> statement of applicability in previous versions was = bit too cumbersome
>>> but this one excludes bi-directional = associated LSP at all. I think that
>>> Loopback can be = used on this construct at MIP that are on forward
>>> and = reverse direction of given bi-directional associated MPLS-TP = LSP.
>>> And I think that MPLS Section is not necessarily a = bi-directional co-
>>> routed = object.
>

> GIM>> But then PW and MPLS = Section have been referred twice -
> after co-routed LSP, then = after associated LSP. Or intention was to apply
> co-routed and = associated to PW and MPLS Section? Would making the
> last = sentence to "It can also be applied at a MEP on an = associated
> bidirectional LSP" be sufficient? But still, = MIPs that are on forward
> and reverse direction of an associated = bi-directional LSP are excluded.
> I believe that previous = versions tried to include such MIPs since these
> are required to = be aware of directions and their correlation. Is this
> change = intentional?

You're right. I = mangled the original  text in my enthusiasm to have something = I
could parse :-)
I think there are two issues:

1. = extraneous mention of PW and Section in the last sentence

OLD = (v7)

  - The loopback = function allows an operator to set a specific node on
    a = transport path into loopback mode such that it returns all
  =   received data. Loopback can be applied at a Maintenance = Entity
    Group End Point (MEP) or a Maintenance Entity = Group Intermediate
    Point (MIP) on a co-routed = bidirectional LSP, PW or MPLS
    Section. It can also be = applied at a MEP on an associated
    bidirectional LSP, PW = or MPLS Section.

NEW

  - = The loopback function allows an operator to set a specific node = on
    a transport path into loopback mode such that it = returns all
    received data. Loopback can be applied at a = Maintenance Entity
    Group End Point (MEP) or a = Maintenance Entity Group Intermediate

    Point (MIP) on a co-routed bidirectional = LSP, on a PW, or on an

  =   MPLS Section. It can also be applied at a MEP on an = associated

    = bidirectional LSP.
END

2. Discussion of loopback at = "coincident" MIPs on associated bidirectional LSPs.
This is = a question for the WG not for me (I am only trying to provide = an
editorial service!).
Would you mind raising this as a separate = thread so that the WG spot and debate
the = issue?


>>> Section = 4, p.4, second to last para. I think that management = plane
>>> sets in or requests Loopback on specific MP but = not performs it.
>>
>> The two sentences in this = paragraph are directly copied from the

>> previous revision with the only change to = drop "MUST" to lower case.

>>
>> = Not sure what to say here since the WG clearly agreed to this = text
>> before. I think the intention was to say that a control = plane is not
>> required in order to achieve = loopback.
>
>GIM>> What if the first sentence = says:
>
> A management plane can be too used to set a MEP or = MIP along a
> transport path in Loopback.

Well, I don't like "too" because this = document doesn't actually mention any way
to set loopback using the = control plane.

So what about:

OLD (v7)
  The = Loopback can be performed using a management plane. Management
  = plane must ensure that the two MEPs are locked before performing = the
  loopback function.
NEW
  The management plane = can be used to configure the Loopback function.
  The management = plane must ensure that the two MEPs are locked before
  = performing the loopback function.
END


>>> = Definition given in Section 4.1 is broader than one in the = Introduction.
>>> Personally I like the latter better though = I think that it can be expanded
>>> to include MIPs on = bi-directional associated LSP that are on forward and
>>> = reverse direction of it.
>>
>> I think it is the same = definition.
>> See the paragraph quoted above and compare = with:
>>  - The node in loopback mode must be on both the = forward and return
>>    paths. This possible for all = MEPs and MIPs on a co-routed
>>    bidirectional LSP, = PW, or MPLS Section, but is only
>>    possible on = for MEPs on associated bidirectional LSPs, PW,
>>    = or MPLS Sections.
>> ...which seems to exclude the MIPs on = assoc bidir as you say.

Same = two issues:

1.
OLD (v7)

  - The node in loopback mode must be on both the = forward and return
    paths. This possible for all MEPs = and MIPs on a co-routed
    bidirectional LSP, PW, or MPLS = Section, but is only
    possible on for MEPs on associated = bidirectional LSPs, PW,
    or MPLS = Sections.

NEW

  - = The node in loopback mode must be on both the forward and = return
    paths. This possible for all MEPs and MIPs on a = co-routed

    = bidirectional LSP, on a PW, or on an MPLS Section, but is only
  =   possible on for MEPs on associated bidirectional = LSPs.
END

2. You will raise associated bidir MIPs on the = mailing list


>>> I'll note that service = could not be restored faster than in 3.5 seconds
>>> = according to described procedure. Is that desired = behavior?
>>
>> That is a good question for the WG. It = was my assumption (from the
>> previous revision) that rapid = unlocking and turn-up was not a
>> requirement or it would have = been included.
>>
>> If the WG now wants to include = it, it will need to examine the use of an
>> unlock OAM = message. This could be done using a new message or a flag
>> on = the existing lock message. It could be achieved by tweaking = this
>> document or introducing a new document.
>
> = GIM>> I'd support explicit UnLock OAM message. I think that it is = required
> if LI/LB expected to work in heterogeneous network = (without defined
> UnLock message or flag request to UnLock is = proprietary, in my view).

OK. Well, this is another technical, not = editorial, change.
So I am not really in a position to discuss = it.
Would you mind creating a separate thread for this one as = well?
That way the WG can decide what it wants to do.

Many = thanks for the thorough and thoughtful review.

Adrian

 

------=_NextPart_000_05B1_01CC83A6.F5007740-- From sboutros@cisco.com Mon Oct 10 16:28:49 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A913121F8C34 for ; Mon, 10 Oct 2011 16:28:49 -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 UB6zbDCiPyVJ for ; Mon, 10 Oct 2011 16:28:48 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5446A21F8A64 for ; Mon, 10 Oct 2011 16:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=20046; q=dns/txt; s=iport; t=1318289328; x=1319498928; h=date:to:from:subject:cc:in-reply-to:references: mime-version:message-id; bh=QIME6AsgWWBMe2/4zIJrj/EF3hOOJWzN/xGUtGbgZQY=; b=BWlk733qzzt6zfdh2sXRz6paN/l4WM4QKb4o+8QYXdwuuBNQixBSLE5G b5ZZDda6boNKJDDnBVLJ0EZi3ELuKsPiJBYHJMqo/77U+MZNX+dcaYSZI H84nJcNywHmLEV7vlsYx+CFdBu3Zhr0kaawGUKdp/cpPXqb6QGMCsXdJ/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPt+k06rRDoG/2dsb2JhbAA7CIgIoByBBYFTAQEBAwEBAQEPAVsLEAcEGCcHGQ4fEQYBEiKHXAebKwGeMAOEF4MsBId9hloChhOEPYxA X-IronPort-AV: E=Sophos;i="4.68,519,1312156800"; d="scan'208,217";a="7076360" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 10 Oct 2011 23:28:48 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9ANSluV009425; Mon, 10 Oct 2011 23:28:47 GMT Received: from xfe-sjc-232.amer.cisco.com ([128.107.191.79]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Oct 2011 16:28:47 -0700 Received: from sboutros-wxp01.ciswco.com ([10.21.167.26]) by xfe-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Oct 2011 16:28:47 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Oct 2011 16:28:42 -0700 To: Greg Mirsky , adrian@olddog.co.uk From: Sami Boutros In-Reply-To: References: <042101cc82dc$0da49e50$28eddaf0$@olddog.co.uk> <04da01cc834b$998ad460$cca07d20$@olddog.co.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_148386812==.ALT" Message-ID: X-OriginalArrivalTime: 10 Oct 2011 23:28:47.0373 (UTC) FILETIME=[5BEFCBD0:01CC87A4] Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-li-lb-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 23:28:49 -0000 --=====================_148386812==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Greg/Adrian, Few comments inline.. At 10:13 AM 10/5/2011, Greg Mirsky wrote: >Hi Adrian, >yes we're! And I'll try to summarize it below instead of in-lining: > * query the WG on applicability of the LB on "coincidental" > bidirectional MIP on associated bi-directional LSP; Sami: we can extend the applicability to this if the WG is ok with that, given that the MIP will be bidirectional. > * query the WG on introducing explicit UnLock operation to MPLS-TP OAM set Sami: I don't think that adding an explicit UnLock is justifiable, given that (1) the UnLock message itself may not get through if the LSP is out of service.(2) The need of the lock message is for getting an LSP out of service in a coordinated way within a tight window, however an LSP coming out of service will not be fully operational except after other OAM functions like cc-cv will declare the LSP UP. > * I accept proposed updates to LB applicability statement Sami: I accepted all the editorial texts below and will be making the changes as soon as the WG last call ends in the newer version 08. Thanks, Sami > * In regard to our discussion of management plane role in > setting MEP or MIP into a loopback state (Section 4, p.4, second to > last para). I agree with the proposed version for the first > sentence but will re-word the second: >NEW > The management plane must ensure that the two MEPs are locked before > performing the loopback function. >NEWER > The management plane must ensure that the two MEPs are locked > before it requests > setting MEP or MIP in the loopback state. >END > > * I feel that we're implicitly view and refer to an MPLS Section > as bidirectional construct even though it is not. In case of this > document I'd propose to explicitly refer to bidirectional MPLS > Section where necessary. > >Regards, >Greg > > >On Wed, Oct 5, 2011 at 3:43 AM, Adrian Farrel ><adrian@olddog.co.uk> wrote: >Hi again Greg, > >We are converging. > >I've cut out the bits where we have reached conclusions. > > >>> Introduction, third para. > >>> Applicability of the Loopback is limited, comparing to previous versions, > >>> to bi-directional co-routed LSP, PW and MPLS Section. I agree that > >>> statement of applicability in previous versions was bit too cumbersome > >>> but this one excludes bi-directional associated LSP at all. I think that > >>> Loopback can be used on this construct at MIP that are on forward > >>> and reverse direction of given bi-directional associated MPLS-TP LSP. > >>> And I think that MPLS Section is not necessarily a bi-directional co- > >>> routed object. > > > > GIM>> But then PW and MPLS Section have been referred twice - > > after co-routed LSP, then after associated LSP. Or intention was to apply > > co-routed and associated to PW and MPLS Section? Would making the > > last sentence to "It can also be applied at a MEP on an associated > > bidirectional LSP" be sufficient? But still, MIPs that are on forward > > and reverse direction of an associated bi-directional LSP are excluded. > > I believe that previous versions tried to include such MIPs since these > > are required to be aware of directions and their correlation. Is this > > change intentional? > >You're right. I mangled the original text in my enthusiasm to have >something I >could parse :-) >I think there are two issues: > >1. extraneous mention of PW and Section in the last sentence > >OLD (v7) > - The loopback function allows an operator to set a specific node on > a transport path into loopback mode such that it returns all > received data. Loopback can be applied at a Maintenance Entity > Group End Point (MEP) or a Maintenance Entity Group Intermediate > Point (MIP) on a co-routed bidirectional LSP, PW or MPLS > Section. It can also be applied at a MEP on an associated > bidirectional LSP, PW or MPLS Section. >NEW > - The loopback function allows an operator to set a specific node on > a transport path into loopback mode such that it returns all > received data. Loopback can be applied at a Maintenance Entity > Group End Point (MEP) or a Maintenance Entity Group Intermediate > Point (MIP) on a co-routed bidirectional LSP, on a PW, or on an > MPLS Section. It can also be applied at a MEP on an associated > bidirectional LSP. >END > >2. Discussion of loopback at "coincident" MIPs on associated >bidirectional LSPs. >This is a question for the WG not for me (I am only trying to provide an >editorial service!). >Would you mind raising this as a separate thread so that the WG spot >and debate >the issue? > > >>> Section 4, p.4, second to last para. I think that management plane > >>> sets in or requests Loopback on specific MP but not performs it. > >> > >> The two sentences in this paragraph are directly copied from the > >> previous revision with the only change to drop "MUST" to lower case. > >> > >> Not sure what to say here since the WG clearly agreed to this text > >> before. I think the intention was to say that a control plane is not > >> required in order to achieve loopback. > > > >GIM>> What if the first sentence says: > > > > A management plane can be too used to set a MEP or MIP along a > > transport path in Loopback. > >Well, I don't like "too" because this document doesn't actually >mention any way >to set loopback using the control plane. > >So what about: > >OLD (v7) > The Loopback can be performed using a management plane. Management > plane must ensure that the two MEPs are locked before performing the > loopback function. >NEW > The management plane can be used to configure the Loopback function. > The management plane must ensure that the two MEPs are locked before > performing the loopback function. >END > > >>> Definition given in Section 4.1 is broader than one in the Introduction. > >>> Personally I like the latter better though I think that it can > be expanded > >>> to include MIPs on bi-directional associated LSP that are on forward and > >>> reverse direction of it. > >> > >> I think it is the same definition. > >> See the paragraph quoted above and compare with: > >> - The node in loopback mode must be on both the forward and return > >> paths. This possible for all MEPs and MIPs on a co-routed > >> bidirectional LSP, PW, or MPLS Section, but is only > >> possible on for MEPs on associated bidirectional LSPs, PW, > >> or MPLS Sections. > >> ...which seems to exclude the MIPs on assoc bidir as you say. > >Same two issues: > >1. >OLD (v7) > - The node in loopback mode must be on both the forward and return > paths. This possible for all MEPs and MIPs on a co-routed > bidirectional LSP, PW, or MPLS Section, but is only > possible on for MEPs on associated bidirectional LSPs, PW, > or MPLS Sections. >NEW > - The node in loopback mode must be on both the forward and return > paths. This possible for all MEPs and MIPs on a co-routed > bidirectional LSP, on a PW, or on an MPLS Section, but is only > possible on for MEPs on associated bidirectional LSPs. >END > >2. You will raise associated bidir MIPs on the mailing list > > >>> I'll note that service could not be restored faster than in 3.5 seconds > >>> according to described procedure. Is that desired behavior? > >> > >> That is a good question for the WG. It was my assumption (from the > >> previous revision) that rapid unlocking and turn-up was not a > >> requirement or it would have been included. > >> > >> If the WG now wants to include it, it will need to examine the use of an > >> unlock OAM message. This could be done using a new message or a flag > >> on the existing lock message. It could be achieved by tweaking this > >> document or introducing a new document. > > > > GIM>> I'd support explicit UnLock OAM message. I think that it is required > > if LI/LB expected to work in heterogeneous network (without defined > > UnLock message or flag request to UnLock is proprietary, in my view). > >OK. Well, this is another technical, not editorial, change. >So I am not really in a position to discuss it. >Would you mind creating a separate thread for this one as well? >That way the WG can decide what it wants to do. > >Many thanks for the thorough and thoughtful review. > >Adrian > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls --=====================_148386812==.ALT Content-Type: text/html; charset="us-ascii" Hi Greg/Adrian,

Few comments inline..
At 10:13 AM 10/5/2011, Greg Mirsky wrote:
Hi Adrian,
yes we're! And I'll try to summarize it below instead of in-lining:
  • query the WG on applicability of the LB on "coincidental" bidirectional MIP on associated bi-directional LSP;
Sami: we can extend the applicability to this if the WG is ok with that, given that the MIP will be bidirectional.

  • query the WG on introducing explicit UnLock operation to MPLS-TP OAM set
Sami: I don't think that adding an explicit UnLock is justifiable, given that (1) the UnLock message itself may not get through if the LSP is out of service.(2) The need of the lock message is for getting an LSP out of service in a coordinated way within a tight window, however an LSP coming out of service will not be fully operational except after other OAM functions like cc-cv will declare the LSP UP.

  • I accept proposed updates to LB applicability statement

Sami: I accepted all the editorial texts below and will be making the changes as soon as the WG last call ends in the newer version 08.

Thanks,

Sami

  • In regard to our discussion of management plane role in setting MEP or MIP into a loopback state (Section 4, p.4, second to last para). I agree with the proposed version for the first sentence but will re-word the second:
NEW
  The management plane must ensure that the two MEPs are locked before
  performing the loopback function.
NEWER
  The management plane must ensure that the two MEPs are locked before it requests
  setting MEP or MIP in the loopback state.
END

  • I feel that we're implicitly view and refer to an MPLS Section as bidirectional construct even though it is not. In case of this document I'd propose to explicitly refer to bidirectional MPLS Section where necessary.

Regards,
Greg


On Wed, Oct 5, 2011 at 3:43 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi again Greg,

We are converging.

I've cut out the bits where we have reached conclusions.

>>> Introduction, third para.
>>> Applicability of the Loopback is limited, comparing to previous versions,
>>> to bi-directional co-routed LSP, PW and MPLS Section. I agree that
>>> statement of applicability in previous versions was bit too cumbersome
>>> but this one excludes bi-directional associated LSP at all. I think that
>>> Loopback can be used on this construct at MIP that are on forward
>>> and reverse direction of given bi-directional associated MPLS-TP LSP.
>>> And I think that MPLS Section is not necessarily a bi-directional co-
>>> routed object.
>
> GIM>> But then PW and MPLS Section have been referred twice -
> after co-routed LSP, then after associated LSP. Or intention was to apply
> co-routed and associated to PW and MPLS Section? Would making the
> last sentence to "It can also be applied at a MEP on an associated
> bidirectional LSP" be sufficient? But still, MIPs that are on forward
> and reverse direction of an associated bi-directional LSP are excluded.
> I believe that previous versions tried to include such MIPs since these
> are required to be aware of directions and their correlation. Is this
> change intentional?

You're right. I mangled the original  text in my enthusiasm to have something I
could parse :-)
I think there are two issues:

1. extraneous mention of PW and Section in the last sentence

OLD (v7)
  - The loopback function allows an operator to set a specific node on
    a transport path into loopback mode such that it returns all
    received data. Loopback can be applied at a Maintenance Entity
    Group End Point (MEP) or a Maintenance Entity Group Intermediate
    Point (MIP) on a co-routed bidirectional LSP, PW or MPLS
    Section. It can also be applied at a MEP on an associated
    bidirectional LSP, PW or MPLS Section.
NEW
  - The loopback function allows an operator to set a specific node on
    a transport path into loopback mode such that it returns all
    received data. Loopback can be applied at a Maintenance Entity
    Group End Point (MEP) or a Maintenance Entity Group Intermediate
    Point (MIP) on a co-routed bidirectional LSP, on a PW, or on an
    MPLS Section. It can also be applied at a MEP on an associated
    bidirectional LSP.
END

2. Discussion of loopback at "coincident" MIPs on associated bidirectional LSPs.
This is a question for the WG not for me (I am only trying to provide an
editorial service!).
Would you mind raising this as a separate thread so that the WG spot and debate
the issue?

>>> Section 4, p.4, second to last para. I think that management plane
>>> sets in or requests Loopback on specific MP but not performs it.
>>
>> The two sentences in this paragraph are directly copied from the
>> previous revision with the only change to drop "MUST" to lower case.
>>
>> Not sure what to say here since the WG clearly agreed to this text
>> before. I think the intention was to say that a control plane is not
>> required in order to achieve loopback.
>
>GIM>> What if the first sentence says:
>
> A management plane can be too used to set a MEP or MIP along a
> transport path in Loopback.

Well, I don't like "too" because this document doesn't actually mention any way
to set loopback using the control plane.

So what about:

OLD (v7)
  The Loopback can be performed using a management plane. Management
  plane must ensure that the two MEPs are locked before performing the
  loopback function.
NEW
  The management plane can be used to configure the Loopback function.
  The management plane must ensure that the two MEPs are locked before
  performing the loopback function.
END

>>> Definition given in Section 4.1 is broader than one in the Introduction.
>>> Personally I like the latter better though I think that it can be expanded
>>> to include MIPs on bi-directional associated LSP that are on forward and
>>> reverse direction of it.
>>
>> I think it is the same definition.
>> See the paragraph quoted above and compare with:
>>  - The node in loopback mode must be on both the forward and return
>>    paths. This possible for all MEPs and MIPs on a co-routed
>>    bidirectional LSP, PW, or MPLS Section, but is only
>>    possible on for MEPs on associated bidirectional LSPs, PW,
>>    or MPLS Sections.
>> ...which seems to exclude the MIPs on assoc bidir as you say.

Same two issues:

1.
OLD (v7)
  - The node in loopback mode must be on both the forward and return
    paths. This possible for all MEPs and MIPs on a co-routed
    bidirectional LSP, PW, or MPLS Section, but is only
    possible on for MEPs on associated bidirectional LSPs, PW,
    or MPLS Sections.
NEW
  - The node in loopback mode must be on both the forward and return
    paths. This possible for all MEPs and MIPs on a co-routed
    bidirectional LSP, on a PW, or on an MPLS Section, but is only
    possible on for MEPs on associated bidirectional LSPs.
END

2. You will raise associated bidir MIPs on the mailing list

>>> I'll note that service could not be restored faster than in 3.5 seconds
>>> according to described procedure. Is that desired behavior?
>>
>> That is a good question for the WG. It was my assumption (from the
>> previous revision) that rapid unlocking and turn-up was not a
>> requirement or it would have been included.
>>
>> If the WG now wants to include it, it will need to examine the use of an
>> unlock OAM message. This could be done using a new message or a flag
>> on the existing lock message. It could be achieved by tweaking this
>> document or introducing a new document.
>
> GIM>> I'd support explicit UnLock OAM message. I think that it is required
> if LI/LB expected to work in heterogeneous network (without defined
> UnLock message or flag request to UnLock is proprietary, in my view).

OK. Well, this is another technical, not editorial, change.
So I am not really in a position to discuss it.
Would you mind creating a separate thread for this one as well?
That way the WG can decide what it wants to do.

Many thanks for the thorough and thoughtful review.

Adrian

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

--=====================_148386812==.ALT-- From scott.mansfield@ericsson.com Tue Oct 11 10:24:14 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A8221F8EFC; Tue, 11 Oct 2011 10:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.604, 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 xjQUnNlqAJrJ; Tue, 11 Oct 2011 10:24:13 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 268B621F8EF4; Tue, 11 Oct 2011 10:24:13 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p9BHO85O009692; Tue, 11 Oct 2011 12:24:10 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.14]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 11 Oct 2011 13:24:08 -0400 From: Scott Mansfield To: "mpls@ietf.org" Date: Tue, 11 Oct 2011 13:23:44 -0400 Thread-Topic: Liaison Statement: LS321 - Progress of Recommendation ITU-T G.8110.1/Y.1370.1 Thread-Index: AcxznxnxDY7fmYK9SYCe+dKxCwhMggUmyTlQ Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ITU-T Liaison coordination , "pwe3@ietf.org" Subject: [mpls] FW: Liaison Statement: LS321 - Progress of Recommendation ITU-T G.8110.1/Y.1370.1 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 17:24:14 -0000 Just a friendly reminder about the attached Liaison originally sent Sept 15= th. The comments on the G.8110.1 last call are due by Wednesday 12 October= .=20 Regards, -scott. > -----Original Message----- > From: Scott Mansfield=20 > Sent: Thursday, September 15, 2011 8:01 AM > To: mpls@ietf.org > Cc: pwe3@ietf.org; 'ITU-T Liaison coordination' > Subject: Liaison Statement: LS321 - Progress of=20 > Recommendation ITU-T G.8110.1/Y.1370.1=20 >=20 >=20 > MPLS and PWE3 working groups, >=20 > Please find the liaison announcing the AAP LC of G.8110.1. =20 > As noted below the document was consented at the February=20 > 2011 plenary and is now in last call. Comments are due by 12=20 > October 2011. ITU-T sector members can access the document=20 > on the AAP Announcement site here -->=20 > http://www.itu.int/ITU-T/aap/AAPRecDetails.aspx?AAPSeqNo=3D2281=20 > Comments are submitted by pressing the "Submit Comment"=20 > button found on that page. If you are not an ITU-T sector=20 > member and would like to comment on the document=20 > (https://datatracker.ietf.org/documents/LIAISON/file1263.pdf), > please send your comments to the mpls list and ISOC as a=20 > sector member (regional and other International Organization)=20 > can submit comments. >=20 > ---------- >=20 > Liaison Statement: LS321 - Progress of Recommendation ITU-T=20 > G.8110.1/Y.1370.1=20 >=20 > Submission Date: 2011-09-14=09 > From: ITU-T SG 15 (Greg Jones )=09 > To: Multiprotocol Label Switching (rcallon@juniper.net,=20 > swallow@cisco.com, loa@pi.nu)=09 > Cc: yoichi.maeda@ttc.or.jp > steve.trowbridge@alcatel-lucent.com > mpls@ietf.org=09 > Response Contact: tsbsg15@itu.int > greg.jones@itu.int > hiroshi.ota@itu.int =09 > Technical Contact: koike.yoshinori@lab.ntt.co.jp > Ghani.Abbas@ericsson.com > huub.van.helvoort@huawei.com > malcolm.betts@zte.com.cn > Kam.Lam@alcatel-lucent.com=09 > Purpose: For information=09 > Attachments: LS321 - Progress of Recommendation ITU-T=20 > G.8110.1/Y.1370.1 - pdf body=20 > =20 > LS321 - Progress of Recommendation ITU-T G.8110.1/Y.1370.1 -=20 > pdf attach=20 > =09 > Body: Recommendation ITU-T G.8110.1/Y.1370.1, "Architecture=20 > of MPLS Transport > Profile (MPLS-TP) layer network", was consented at the=20 > February meeting of SG15. The last call comment period has=20 > recently started and will close on 12 October 2011. >=20 > Attach: Last Call text of ITU-T G.8110.1/Y.1370.1. >=20 > =09 > Regards, > -scott. >=20 > SCOTT MANSFIELD > IETF ITU-T MPLS Liaison Manager >=20 > Ericsson US > BNET DUIB Technology, Network Architecture Mobile +1 (724)=20 > 931-9316 scott.mansfield@ericsson.com www.ericsson.com=20 > = From internet-drafts@ietf.org Wed Oct 12 02:28:05 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492AE21F8C8A; Wed, 12 Oct 2011 02:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 jkUr7GYXtAe2; Wed, 12 Oct 2011 02:28:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4E521F8BA4; Wed, 12 Oct 2011 02:28:04 -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: 3.60 Message-ID: <20111012092804.2434.52765.idtracker@ietfa.amsl.com> Date: Wed, 12 Oct 2011 02:28:04 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-oam-analysis-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 09:28:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : An Overview of the OAM Tool Set for MPLS based Transport= Networks Author(s) : Nurit Sprecher Luyuan Fang Filename : draft-ietf-mpls-tp-oam-analysis-06.txt Pages : 21 Date : 2011-10-12 This document provides an overview of the OAM toolset for MPLS based Transport Networks. The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data-plane) which are appropriate for transport networks as required in [MPLS-TP OAM Reqs] and support the network and services at different nested levels. This overview includes a brief recap of MPLS-TP OAM requirements and functions, and of generic mechanisms created in the MPLS data plane to allow the OAM packets run in-band and share their fate with data packets. The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group drafts) which are referenced by this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-analysis-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-analysis-06.txt From wwwrun@rfc-editor.org Wed Oct 12 03:53:03 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FE021F8C47 for ; Wed, 12 Oct 2011 03:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=0.211, 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 0u3X6mNHUkiS for ; Wed, 12 Oct 2011 03:53:03 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 313AA21F8B92 for ; Wed, 12 Oct 2011 03:53:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9C03898C240; Wed, 12 Oct 2011 03:53:00 -0700 (PDT) To: erosen@cisco.com, arun@force10networks.com, rcallon@juniper.net, stbryant@cisco.com, adrian@olddog.co.uk, rcallon@juniper.net, swallow@cisco.com, loa@pi.nu From: RFC Errata System Message-Id: <20111012105300.9C03898C240@rfc-editor.org> Date: Wed, 12 Oct 2011 03:53:00 -0700 (PDT) Cc: mpls@ietf.org, mail_bala@yahoo.com, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC3031 (2992) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 10:53:03 -0000 The following errata report has been submitted for RFC3031, "Multiprotocol Label Switching Architecture". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3031&eid=2992 -------------------------------------- Type: Editorial Reported by: Bala Venkata Section: 3.12 Original Text ------------- If the FTN maps a particular label to a set of NHLFEs that contains more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing an element from the set are beyond the scope of this document. Having the FTN map a label to a set containing more than one NHLFE may be useful if, e.g., it is desired to do load balancing over multiple equal-cost paths. Corrected Text -------------- If the FTN maps a particular FEC to a set of NHLFEs that contains more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing an element from the set are beyond the scope of this document. Having the FTN map a FEC to a set containing more than one NHLFE may be useful if, e.g., it is desired to do load balancing over multiple equal-cost paths. Notes ----- Since FTN is used for packets that arrive unlabeled (as ILM is used for label-NHLFEs), this section should be corrected. It says that "FTN maps a particular label to a set of NHLFEs" 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. -------------------------------------- RFC3031 (draft-ietf-mpls-arch-06) -------------------------------------- Title : Multiprotocol Label Switching Architecture Publication Date : January 2001 Author(s) : E. Rosen, A. Viswanathan, R. Callon Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From gregimirsky@gmail.com Wed Oct 12 14:16:55 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870A821F8B70; Wed, 12 Oct 2011 14:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 y72KlXgv2c1I; Wed, 12 Oct 2011 14:16:54 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE3321F8B57; Wed, 12 Oct 2011 14:16:54 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so79836vcb.31 for ; Wed, 12 Oct 2011 14:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=tlw6JruSGFuxBuowpkmGmw8VTO3M1Y3lX73COF2HISA=; b=wjXBXk3h1zWsimyzCBVU3ARiMkpnSEVAKBZHbJ6Ik7ae7W4MpHHZLZLHeEmf5iWy4y XOYAuVSE6RYQ/oT+HXD3vFyAyH5xzHZKU+srHIzVfIpONZ7Vw2MvzBaGm14KDco7OnOX bZuarT3XATlNtnZk7JaTX2YHIBfDUVC3lUG3k= MIME-Version: 1.0 Received: by 10.52.174.38 with SMTP id bp6mr852111vdc.75.1318454213595; Wed, 12 Oct 2011 14:16:53 -0700 (PDT) Received: by 10.52.163.199 with HTTP; Wed, 12 Oct 2011 14:16:53 -0700 (PDT) In-Reply-To: <20111007052313.28743.34664.idtracker@ietfa.amsl.com> References: <20111007052313.28743.34664.idtracker@ietfa.amsl.com> Date: Wed, 12 Oct 2011 14:16:53 -0700 Message-ID: From: Greg Mirsky To: davari@broadcom.com, amito@broadcom.com, manav.bhatia@alcatel-lucent.com, peter.roberts@alcatel-lucent.com, lmontini@cisco.com, tictoc@ietf.org, mpls@ietf.org Content-Type: multipart/alternative; boundary=bcaec51b19510dd20b04af208be1 Subject: Re: [mpls] [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 21:16:55 -0000 --bcaec51b19510dd20b04af208be1 Content-Type: text/plain; charset=ISO-8859-1 Dear Authors, et al., below are my notes to the latest version of the document. thank you for your kind consideration. - Abstract. In last paragraph UDP/IP encapsulation presented as more preferable for IP/MPLS PSN while Ethernet PW as more preferable for MPLS-TP PSN. I think that applicability statements will benefit from more extensive and argumented discussion. - Section 5, third para. Since MPLS-TP is a subset of MPLS statement "The PTP LSP MAY be MPLS LSP or MPLS-TP LSP" might be not the most accurate form of expression. At the same time the fourth paragraph suggests that PTP LSP might be configured by NMS (static configuration) or signaled by RSVP-TE/GMPLS. Have to note that RSVP-TE/GMPLS signaling is applicable only to MPLS-TP PSN. IP/MPLS LSPs are LDP signaled, MPLS-TE LSPs are signaled via RSVP-TE/MPLS. - Section 6.1 Statement "In order for an LSR to process PTP messages, the PTP Label must be the top label of the label stack" implies that Facility Backup MPLS FRR should not be used for PTP LSP. Further in Section 8 suggested that FRR Backup tunnel label must be as well associated with the PTP application. I'll note that then all LSPs that to be protected by this PTP Backup will be viewed as PTP LSPs and that might be undesirable. I think that Facility Backup FRR is not practical local protection for PTP LSP. - Section 6.2, p.11, third para. A "PTP label range" is first time referred here. How this range is defined? Where it is defined - across all MPLS PSN or only along particular PTP LSP? - Section 6.2, p.11, third para "... the PW label may be the top label in the stack, such as cases where there is only one-hop between PEs or in case of PHP ..." illustrates the same as text at the top of p.12 - section 6.2, p.12 refers not to "PTP label range" but to some mechanism to associate a label, PW label, with PTP application. Are there two mechanisms to make a label into a PTP application label - static and dynamic? Where PTP Association extensions will be defined? - Section 10, p.17. s/G-ACH/G-ACh/ Will note that VCCV Type 1 Control Channel is ACH, not G-ACH. Regards, Greg ---------- Forwarded message ---------- From: Date: Thu, Oct 6, 2011 at 10:23 PM Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-02.txt To: i-d-announce@ietf.org Cc: tictoc@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Timing over IP Connection and Transfer of Clock Working Group of the IETF. Title : Transporting PTP messages (1588) over MPLS Networks Author(s) : Shahram Davari Amit Oren Manav Bhatia Peter Roberts Laurent Montini Filename : draft-ietf-tictoc-1588overmpls-02.txt Pages : 34 Date : 2011-10-06 This document defines the method for transporting PTP messages (PDUs) over an MPLS network. The method allows for the easy identification of these PDUs at the port level to allow for port level processing of these PDUs in both LERs and LSRs. The basic idea is to transport PTP messages inside dedicated MPLS LSPs. These LSPs only carry PTP messages and possibly Control and Management packets, but they do not carry customer traffic. Two methods for transporting 1588 over MPLS are defined. The first method is to transport PTP messages directly over the dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for IP/MPLS networks. The second method is to transport PTP messages inside a PW via Ethernet encapsulation, which is more suitable for MPLS-TP networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tictoc-1588overmpls-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tictoc-1588overmpls-02.txt _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc --bcaec51b19510dd20b04af208be1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors, et al.,
below are my notes to the latest version of the do= cument. thank you for your kind consideration.
  • Abstract. In last= paragraph UDP/IP encapsulation presented as more preferable for IP/MPLS PS= N while Ethernet PW as more preferable for MPLS-TP PSN. I think that applic= ability statements will benefit from more extensive and argumented discussi= on.
  • Section 5, third para. Since MPLS-TP is a subset of MPLS statement &quo= t;The PTP LSP MAY be MPLS LSP or MPLS-TP LSP" might be not the most accurate form of exp= ression. At the same time the fourth paragraph suggests that PTP LSP might = be configured by NMS (static configuration) or signaled by RSVP-TE/GMPLS. H= ave to note that RSVP-TE/GMPLS signaling is applicable only to MPLS-TP PSN.= IP/MPLS LSPs are LDP signaled, MPLS-TE LSPs are signaled via RSVP-TE/MPLS.
  • Section 6.1 Statement "In order for an LSR to process PTP mes= sages, the PTP Label must be the top label of the label stack" implies that Facility Backup MPLS= FRR should not be used for PTP LSP. Further in Section 8 suggested that FR= R Backup tunnel label must be as well associated with the PTP application. = I'll note that then all LSPs that to be protected by this PTP Backup wi= ll be viewed as PTP LSPs and that might be undesirable. I think that Facili= ty Backup FRR is not practical local protection for PTP LSP.
  • Section 6.2, p.11, third para. A "PTP label range" is fi= rst time referred here. How this range is defined? Where it is defined - ac= ross all MPLS PSN or only along particular PTP LSP?
  • Section 6.2, p.11, third para "... the PW label may be the top lab= el in the stack, such as cases where there is only one-hop between PEs or in case of PHP ..." illustrates the same as text at the top of p.12
  • se= ction 6.2, p.12 refers not to "PTP label range" but to some mecha= nism to associate a label, PW label, with PTP application. Are there two me= chanisms to make a label into a PTP application label - static and dynamic?= Where PTP Association extensions will be defined?
  • Section 10, p.17. s/G-ACH/G-ACh/ Will note that VCCV Type 1 Control Cha= nnel is ACH, not G-ACH.

Regards,
Greg

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu, Oct 6, 2011 at 10:23 PM
Subject: [TICTOC] I-D Action: draft-i= etf-tictoc-1588overmpls-02.txt
To: i-d-announce@ietf.org
Cc: tictoc@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Timing over IP Connection and= Transfer of Clock Working Group of the IETF.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Transporting PTP messages (1588= ) over MPLS Networks
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Shahram Davari
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Amit Oren
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Manav Bhatia
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Peter Roberts
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Laurent Montini
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-tictoc-1588overmpls-02= .txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 34
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-10-06

=A0 This document defines the method for transporting PTP messages (PDUs)<= br> =A0 over an MPLS network. =A0The method allows for the easy identification=
=A0 of these PDUs at the port level to allow for port level processing of<= br> =A0 these PDUs in both LERs and LSRs.

=A0 The basic idea is to transport PTP messages inside dedicated MPLS
=A0 LSPs. =A0These LSPs only carry PTP messages and possibly Control and =A0 Management packets, but they do not carry customer traffic.

=A0 Two methods for transporting 1588 over MPLS are defined. =A0The first<= br> =A0 method is to transport PTP messages directly over the dedicated MPLS =A0 LSP via UDP/IP encapsulation, which is suitable for IP/MPLS networks.<= br> =A0 The second method is to transport PTP messages inside a PW via
=A0 Ethernet encapsulation, which is more suitable for MPLS-TP networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf= -tictoc-1588overmpls-02.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-t= ictoc-1588overmpls-02.txt
_______________________________________________
TICTOC mailing list
TICTOC@ietf.org = https://www.ietf.org/mailman/listinfo/tictoc

--bcaec51b19510dd20b04af208be1-- From ietf-ipr@ietf.org Thu Oct 13 08:19:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9048B21F8C13; Thu, 13 Oct 2011 08:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=0.249, 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 W2bRuzjmiz1E; Thu, 13 Oct 2011 08:19:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D88921F8B77; Thu, 13 Oct 2011 08:19:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: swallow@cisco.com, annamaria.fulignoli@ericsson.com, martin.vigoureux@alcatel-lucent.com, sboutros@cisco.com, dward@juniper.net, X-Test-IDTracker: no Message-ID: <20111013151904.25998.96179.idtracker@ietfa.amsl.com> Date: Thu, 13 Oct 2011 08:19:04 -0700 Cc: mpls@ietf.org, rcallon@juniper.net, stbryant@cisco.com, ipr-announce@ietf.org Subject: [mpls] IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-mpls-tp-fault-07 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 15:19:04 -0000 Dear George Swallow, Annamaria Fulignoli, Martin Vigoureux, Sami Boutros, D= avid Ward: An IPR disclosure that pertains to your Internet-Draft entitled "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault) was submitted to the IETF Secret= ariat on 2011-10-06 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1625/). The title of = the IPR disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement about= IPR related to draft-ietf-mpls-tp-fault-07.""); The IETF Secretariat From asayeed@cisco.com Thu Oct 13 09:07:12 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367AD21F8AB8; Thu, 13 Oct 2011 09:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] 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 VdgPJ9EUMD-x; Thu, 13 Oct 2011 09:07:11 -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 8766921F89B8; Thu, 13 Oct 2011 09:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=asayeed@cisco.com; l=1471; q=dns/txt; s=iport; t=1318522031; x=1319731631; h=date:subject:from:to:message-id:mime-version: content-transfer-encoding; bh=dDy04euGF/leX8FQ1vsx1PcTOLp3gqgBfCIlWFI1uNE=; b=MWMj1Yo0UsMNWPIUluTjO37DANyW0jqVtx7duG2b/CPZBSxEFVSIAW4G jr/2+RX7IjvtVO9f9LeSOeFRBzAI2uxor9BYIk/oZieRDQf/dhql26i4a aUiMlj4+De9htQcrkHLR1Fas+FDmoUaA+7o2x6eYtY/gF5Pf4zlHx9ib9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwGAEwLl06tJXG//2dsb2JhbABDiT2fFwKBBYFVAQQSAScCAU4BQ2MBBAEtB6EnAZ4vh20Ek3iFMYgWhCo X-IronPort-AV: E=Sophos;i="4.69,341,1315180800"; d="scan'208";a="28208703" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 13 Oct 2011 16:07:11 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9DG7Alj022305; Thu, 13 Oct 2011 16:07:10 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Oct 2011 11:07:10 -0500 Received: from 161.44.69.204 ([161.44.69.204]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([72.163.62.137]) with Microsoft Exchange Server HTTP-DAV ; Thu, 13 Oct 2011 16:07:10 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Thu, 13 Oct 2011 12:07:06 -0400 From: Azhar Sayeed To: , Message-ID: Thread-Topic: [mpls] Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Thread-Index: AcyJwicgxDGlQEVz9k2EfBNucWOvyQ== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Oct 2011 16:07:10.0836 (UTC) FILETIME=[2A025B40:01CC89C2] Subject: [mpls] Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 16:07:12 -0000 Hi, I support the publication of the draft as an informational RFC. This is a good example of providing an avenue for debate and then agreeing to a consensus on single solution and documenting it as a reference. The debate in SDOs has been on for a long time and every time I only get one or two examples of how a provider has deployed the alternative solution and hence it becomes mandatory for all SDOs to comply. To me those are bad choices made by people cognizant of the issues. These are the risks you take when you deploy pre-standard technology and have to rip it or migrate to standards based technology. Just because one or two providers deployed it does not mean it becomes mandatory on the rest of the world. The last time I checked there are more than 500 providers in the world. One solution is all that is needed for an IOT and two solutions are very expensive from a vendor point of view and from a provider point of view. I am sure all vendors and providers agree. From a vendor point of view they are expensive to build and from a provider point of view managing two domains is not easy. Now, no one is stopping people from inventing another protocol that looks a lot like MPLS and behaves a lot like MPLS with "better OAM" characteristics and then standardizing that protocol. I will fully support that protocol except that it cannot be called MPLS. It is a new protocol. Regards, Azhar Sayeed Cisco Systems Inc. From tnadeau@lucidvision.com Thu Oct 13 14:39:51 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E54B21F8B19 for ; Thu, 13 Oct 2011 14:39:51 -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 vMm5HrHSJ0sf for ; Thu, 13 Oct 2011 14:39:51 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3164D21F8AE9 for ; Thu, 13 Oct 2011 14:39:51 -0700 (PDT) Received: from [192.168.1.144] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 546F41EDF7CB for ; Thu, 13 Oct 2011 17:34:11 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Thomas Nadeau In-Reply-To: <791AD3077F94194BB2BDD13565B6295D1D0A26C4@DAPHNIS.office.hd> Date: Thu, 13 Oct 2011 17:34:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <231726F1-2C29-48E6-95BD-46AB48812278@lucidvision.com> References: <1317815466.64710.YahooMailClassic@web15608.mail.cnb.yahoo.com> <60C093A41B5E45409A19D42CF7786DFD5223D56BC2@EUSAACMS0703.eamcs.ericsson.se> <791AD3077F94194BB2BDD13565B6295D1D0A26C4@DAPHNIS.office.hd> To: mpls@ietf.org X-Mailer: Apple Mail (2.1244.3) Subject: [mpls] Software Defined Networks (SDN) BoF in Taipei X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 21:39:51 -0000 As an FYI, the initial schedule is out. The SDN BoF is planned = for Thursday afternoon from 1520-1720 in room 201 DEF. http://tools.ietf.org/agenda/82/ As usual, caveat emptor in that this is the initial schedule = which often changes. Please plan on being there M-F in case the = schedule changes. --Tom From gregory.mirsky@ericsson.com Thu Oct 13 15:57:53 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB78D21F8BA6 for ; Thu, 13 Oct 2011 15:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, 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 YNqrPw5mp64h for ; Thu, 13 Oct 2011 15:57:53 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 229D321F8B8F for ; Thu, 13 Oct 2011 15:57:53 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p9DMvmug016339; Thu, 13 Oct 2011 17:57:49 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.165]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 13 Oct 2011 18:57:43 -0400 From: Gregory Mirsky To: "ice@cisco.com" , "eckert@cisco.com" , "nicolai.leymann@t-systems.com" , "mpls@ietf.org" Date: Thu, 13 Oct 2011 18:57:41 -0400 Thread-Topic: WG LC comments draft-ietf-mpls-mldp-in-band-signaling-04 Thread-Index: AcyJ+4MVentOQ4PFTASmM58wrNuwSg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF12EDF856FFDEUSAACMS0715e_" MIME-Version: 1.0 Subject: [mpls] WG LC comments draft-ietf-mpls-mldp-in-band-signaling-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 22:57:53 -0000 --_000_FE60A4E52763E84B935532D7D9294FF12EDF856FFDEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors and et.al, I had problem with the following text in the document. * p.7 "In order transport the packets of sender only branch to the ro= ot of the LSP a MP2MP is created.This will cause the sender only branches t= o receive each others packets." I can not offer alternative to the text. * the very next sentence seems too long and might benefit from re-str= ucturing and/or re-phrasing "These packets will be dropped and not forwarde= d, if that affect is undesireable some other means of transport has to be e= stablished to forward packets to the root of the tree, like a Multi-Point t= o Point LSP for example." Perhaps breaking in two sentences will help "Thes= e packets will be dropped and not forwarded. If that is not desireable then= some other means of transport has to be established to forward packets to = the root of the tree, like a Multi-Point to Point LSP for example." Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF12EDF856FFDEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors and et.al,
I had problem with the following text in the document.
  • p.7 "In order transport the packets of sender only branch to the r= oot of the LSP a MP2MP is created.This will cause the sender only branches = to receive each others packets." I can not offer alternative to the te= xt.
  • the very next sentence seems too long and might benefit from re= -structuring and/or re-phrasing "These packets will be dropped and not= forwarded, if that affect is undesireable some other means of transport ha= s to be established to forward packets to the root of the tree, like a Multi-Point to Point LSP for example." Perhap= s breaking in two sentences will help "These packets will be dropped a= nd not forwarded. If that is not desireable then some other means of transp= ort has to be established to forward packets to the root of the tree, like a Multi-Point to Point LSP for example."=
 
        Regards,
           &nbs= p;    Greg
 
 --_000_FE60A4E52763E84B935532D7D9294FF12EDF856FFDEUSAACMS0715e_-- From martin.vigoureux@alcatel-lucent.com Fri Oct 14 02:30:19 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6364B21F8B49 for ; Fri, 14 Oct 2011 02:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erL5xq2juF6N for ; Fri, 14 Oct 2011 02:30:19 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7C35D21F8B2A for ; Fri, 14 Oct 2011 02:30:17 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p9E9U5jK021169 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 14 Oct 2011 11:30:16 +0200 Received: from [172.27.205.107] (135.120.57.7) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.137.0; Fri, 14 Oct 2011 11:30:06 +0200 Message-ID: <4E98011E.2080908@alcatel-lucent.com> Date: Fri, 14 Oct 2011 11:30:06 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: "MPLS @ IETF" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: [mpls] Slots requests for IETF 82 - Taipei X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 09:30:19 -0000 All, it is time we start building the agenda for Taipei. Please send *me* (cc: chairs) your requests for a presentation slot, indicating: draft name, speaker and duration (presentation + Q&As). Requests with missing information will not be considered. Please send me the requests before November 2nd. Please be aware that we might not be able to satisfy all requests. Thank you. MPLS Sessions are currently scheduled: Monday, Morning Session I 0900-1130 Thursday, Afternoon Session III 1740-1940 Note that the IETF Agenda is subject to change. regards, martin From zhang.fei3@zte.com.cn Mon Oct 17 04:09:07 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A895C21F8B32; Mon, 17 Oct 2011 04:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.436 X-Spam-Level: X-Spam-Status: No, score=-98.436 tagged_above=-999 required=5 tests=[AWL=3.401, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-mBhBrxQP99; Mon, 17 Oct 2011 04:09:07 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8349621F8B2A; Mon, 17 Oct 2011 04:09:06 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 466211279682118; Mon, 17 Oct 2011 19:02:13 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 51666.1279682118; Mon, 17 Oct 2011 19:08:52 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p9HB8prf080320; Mon, 17 Oct 2011 19:08:51 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) To: "ccamp@ietf.org" , "mpls@ietf.org" MIME-Version: 1.0 X-KeepSent: 3E7FD488:405BF0C5-4825792C:00351CBE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Mon, 17 Oct 2011 19:08:51 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-17 19:08:53, Serialize complete at 2011-10-17 19:08:53 Content-Type: multipart/alternative; boundary="=_alternative 003D3BA54825792C_=" X-MAIL: mse01.zte.com.cn p9HB8prf080320 Subject: [mpls] Request comments on draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 11:09:07 -0000 This is a multipart message in MIME format. --=_alternative 003D3BA54825792C_= Content-Type: text/plain; charset="US-ASCII" Hi all We've submitted a draft for the group's consideration, below is the link: http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00. This draft is about the supporting of MPLS-TP Maintenance Identifiers. As described in http://tools.ietf.org/html/rfc6370, at each end point, a tunnel is uniquely identified by the end point's Node_ID and a locally assigned tunnel number, which allow a compact form for the MEP_ID, and extensions will be required to GMPLS to support these identifiers. Furthermore, http://tools.ietf.org/html/rfc6373 addressed this issue in section 4.4.8. Obviously, this issue can be solved by defining a new object, such as Connection Object as described in this draft, or a new sub-TLV call MEP_ID can be carried back to the ingress LSR in Resv message when the "CV" flag of the OAM Function Flags Sub-TLV is set, which may be considered in the subsequent version of the draft http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-06. We hope you'll find the time to look through the draft and comment on the list, help judge which way is more suitable before the WG meeting in Taipei, and hope that we'll be able to have a fruitful and lively discussion there. Best, Fei --=_alternative 003D3BA54825792C_= Content-Type: text/html; charset="US-ASCII"
Hi all

We've submitted a draft for the group's consideration, below is the link:
http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00.

This draft is about the supporting of MPLS-TP Maintenance Identifiers. As described in http://tools.ietf.org/html/rfc6370, at each end point, a tunnel is uniquely identified by the end point's Node_ID and a locally assigned tunnel number, which allow a compact form for the MEP_ID, and extensions will be required to GMPLS to support these identifiers. Furthermore, http://tools.ietf.org/html/rfc6373 addressed this issue in section 4.4.8.

Obviously, this issue can be solved by defining a new object, such as Connection Object as described in this draft, or a new sub-TLV call MEP_ID can be carried back to the ingress LSR in Resv message when the "CV" flag of the OAM Function Flags Sub-TLV is set, which may be considered in the subsequent version of the draft http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-06.

We hope you'll find the time to look through the draft and comment on the list, help judge which way is more suitable before the WG meeting in Taipei, and hope that we'll be able to have a fruitful and lively discussion there.


Best,

Fei --=_alternative 003D3BA54825792C_=-- From michelg@upperside.fr Mon Oct 17 07:27:36 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B8321F8B91 for ; Mon, 17 Oct 2011 07:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 DyS0YnEqvM3y for ; Mon, 17 Oct 2011 07:27:36 -0700 (PDT) Received: from smtp27.msg.oleane.net (smtp27.msg.oleane.net [62.161.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 641B821F8BBB for ; Mon, 17 Oct 2011 07:27:35 -0700 (PDT) Received: from MichelGosseDel ([195.6.217.229]) (authenticated) by smtp27.msg.oleane.net (MSA) with ESMTP id p9HERVTw004627 for ; Mon, 17 Oct 2011 16:27:32 +0200 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Mon, 17 Oct 2011 16:27:26 +0200 Message-ID: <004901cc8cd8$e85c00f0$b91402d0$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01CC8CE9.ABE741F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcyM2F6SNnSdyiRJR3CIdvRfvv7VSg== Content-Language: fr X-PMX-Spam: Probability=10% X-PFSI-Info: PMX 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.5.11.103315 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Subject: [mpls] MPLS & Ethernet World Paris 2012 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 14:27:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004A_01CC8CE9.ABE741F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 14th edition of MPLS & Ethernet World Congress will take place from 7 to 10 February 2012 in Paris. The agenda will pay particular attention to Cloud services impact, End-to-end MPLS and Mobile LTE backhaul. All details at: http://www.uppersideconferences.com/mplsworld2012/mplsworld2012intro.html ------=_NextPart_000_004A_01CC8CE9.ABE741F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 14th edition of = MPLS & Ethernet World Congress will take place from 7 to 10 February = 2012 in Paris.

 

The agenda will pay = particular attention to Cloud services impact, End-to-end MPLS and = Mobile LTE backhaul.

 

All details at: =  http://www.uppersideco= nferences.com/mplsworld2012/mplsworld2012intro.html

 

= ------=_NextPart_000_004A_01CC8CE9.ABE741F0-- From erosen@cisco.com Mon Oct 17 08:22:31 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C37621F8C15 for ; Mon, 17 Oct 2011 08:22:31 -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 cCXyjm-sZcvR for ; Mon, 17 Oct 2011 08:22:30 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD3921F8C11 for ; Mon, 17 Oct 2011 08:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=4651; q=dns/txt; s=iport; t=1318864945; x=1320074545; h=to:subject:reply-to:date:message-id:from; bh=Zbaiwtl8UBN1N1NBBGI7iXLMT4Mx7VXX2K+QA/KV6U8=; b=dPEhqK6+nOcTN7o/8TuRNIwVwd/9O1FCKtBCf6PbhLFQGijun9Ejk7mj DmTjv0EBfSqiBZIQizIMHjUjqXVMOPMei+MM8QjAZxgoBGoSouyix+ZXL ILmTi18ELXIokp0HXGP1cLgUOr4r+M+W1tpNv8V5Ykby6iDTbtFG/55P4 Y=; X-IronPort-AV: E=Sophos;i="4.69,359,1315180800"; d="scan'208";a="28953198" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 17 Oct 2011 15:22:24 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p9HFMO72005677; Mon, 17 Oct 2011 15:22:24 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id p9HFMNjH006872; Mon, 17 Oct 2011 11:22:23 -0400 To: mpls@ietf.org Date: Mon, 17 Oct 2011 11:22:23 -0400 Message-ID: <6871.1318864943@erosen-linux> From: Eric Rosen Subject: [mpls] Forwarding discussion in ldp-multi-topology draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 15:22:31 -0000 I'd like to make a comment on the discussion of forwarding in draft-ietf-mpls-ldp-multi-topology-00.txt. The draft is about the control plane mechanism used to bind a label to a pair. The label is downstream-assigned. The interpretation of the label is thus a local matter for the downstream LDP peer that assigns it. The draft mentions the possibility of binding a stack of labels to a pair. One could also consider the possibility of binding a stack of labels to an "ordinary" address prefix in a single-topology environment. There are two separate issues: 1. defining a signaling mechanism for binding more than one label to a FEC element of some sort. 2. defining the encoding of a FEC element that represents a pair These two issues are orthogonal, and the draft is about issue 2, NOT about issue 1. Note that if we have the mechanism of 1, it could be combined with the encoding of 2. But as long as all the assigned labels are downstream-assigned, their interpretation would be a local matter for the assigner, and it would not be appropriate to require, e.g., that the top label be a context label. Thus I would suggest removing the following paragraph from section 2: "There are two possible solutions to support MT awared MPLS network from MPLS forwarding point of view. The first one is to map label to both ip address and the corresponding topology. The alternative one is to use label stacks. The upper label maps to the topology, the lower label maps to the ip address. The first option does not require change to data plane, and it could use multiple labels for the same address on different topologies. The second option requires two lookups on data forwarding plane, and it can use the same label" It suggests that if a two-label solution is ever used, the top label would be a" context label" (RFC 5331) specifying the table in which the second label is looked up. There is no particular reason to say this. The paragraph also suggests that if a context label is not used, the platform-specific label space must be used. There's no particular reason to say that either; one could imagine an environment in which an interface-specific label space could be used (e.g., each link in only one topology). These issues are outside the scope of this draft, and I think any discussion of them here will only cause confusion in the future. It would be okay to say just that this draft does not require or presuppose any changes to the MPLS data plane. Similarly, I would suggest omitting section 10 entirely. The section even pronounces itself to be outside the scope of the document. It also has a few inaccuracies. In MT based MPLS network, forwarding will be based not only on label, but also on MT-ID associsted with the label. This is not true as stated. I think what is meant is that forwarding is still based only on the label, but the label is associated with an pair. It also resolves the forwarding issue that exists in IGP multi-topology forwarding when multiple topologies share an interface with overlay address space. "overlay" --> "overlapping", I think. When this draft gets reviewed outside the MPLS group, the term "the issue that exists in IGP multi-topology forwarding" will attract unwanted attention, as it is not completely clear what that issue is, why it is such a big problem, or why it needs to be mentioned in this context. > in this mechanism, label space is not allowed to be overlapping > among different MTs I think the most you can say is that: - the specified signaling mechanisms allow all the topologies to share the platform-specific label space; this is the feature that allows the existing data plane techniques to be used; and - the specified signaling mechanisms do not provide any way for the data plane to associate a given packet with a context-specific label space. I also have some comments on the applicability section. Section 3.1 "Simplified Data-plane" is pretty standard "MPLS is good" stuff. But I'd have thought that the problem with non-MPLS multi-topology is not so much the fact that it needs multiple FIBs as that there has to be some way of associating a received packet with a particular topology. Section 3.5, "Simplified inter-AS VPN solution", suggests that multi-topology LDP allows inter-AS VPNs to be set up without using options A, B or C. I don't really understand what is being proposed here. From loa@pi.nu Mon Oct 17 17:50:43 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB2421F84F9; Mon, 17 Oct 2011 17:50:42 -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 qF8HmyBowOcU; Mon, 17 Oct 2011 17:50:42 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id DC56A21F84F8; Mon, 17 Oct 2011 17:50:41 -0700 (PDT) Received: from [10.0.2.174] (unknown [12.150.171.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id F031E2A8004; Tue, 18 Oct 2011 02:50:30 +0200 (CEST) Message-ID: <4E9CCD54.205@pi.nu> Date: Mon, 17 Oct 2011 20:50:28 -0400 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mpls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , pwe3@ietf.org Subject: Re: [mpls] Second last call on draft-ietf-mpls-tp-li-lb X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 00:50:44 -0000 Working Group, The working group last call on drat-ietf-mpls-tp-li-lb has ended. We have two outstanding issues - a proposal to add an explicit Unlock message and on the coincidental bidirectional MIP. The working group does not have consensus to add either, but the working group chairs encourage anyone to work on this to write Internet Drafts on the subjects. In the meantime we will go ahead with the draft as it is. Loa, George and Ross mpls wg co-chairs On 2011-10-03 18:23, George Swallow wrote: > All - > > draft-ietf-mpls-tp-li-lb-07.txt has gone through an extensive rewrite. > We are therefore initiating a new WG last call. Note however, the IETF > last call will run nearly concurrently. > > The last call ends at Oct 17 at 24:00 GMT. > > George, Ross, & Loa > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From quintin.zhao@huawei.com Tue Oct 18 10:14:37 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B094B21F8BA8 for ; Tue, 18 Oct 2011 10:14:37 -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 7v9QkPS7qB5G for ; Tue, 18 Oct 2011 10:14:36 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id AC89621F8B51 for ; Tue, 18 Oct 2011 10:14:36 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT9007PYUK370@usaga04-in.huawei.com> for mpls@ietf.org; Tue, 18 Oct 2011 12:14:28 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT90035OUK34E@usaga04-in.huawei.com> for mpls@ietf.org; Tue, 18 Oct 2011 12:14:27 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 18 Oct 2011 10:14:28 -0700 Received: from QZHAO (10.212.244.170) by DFWEML402-HUB.china.huawei.com (10.193.5.102) with Microsoft SMTP Server id 14.1.270.1; Tue, 18 Oct 2011 10:14:20 -0700 Date: Tue, 18 Oct 2011 13:14:09 -0400 From: Quintin Zhao In-reply-to: X-Originating-IP: [10.212.244.170] To: erosen@cisco.com Message-id: <003c01cc8db9$5a22fb90$0e68f2b0$%zhao@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcyM/zT2Bnb8V8rqQNCtHxXf+JiizAACAvHAAChuVGA= References: Cc: mpls@ietf.org Subject: Re: [mpls] Subject: Forwarding discussion in ldp-multi-topology draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 17:14:37 -0000 Eric, Thanks a lot for your detailed comments and very good suggestions! I generally agree with you that we don't need discuss the forwarding mechanism in our draft from now on. The reason we have the section 10 is that we have multiple choices for the encoding of pair in our previous versions of the draft. Now we have come to the consensus among the authors that we chose the choice of banding one label instead of a stack of labels to a pair. With this choice, forwarding mechanism is as same as when non-MPLS multi-topology is supported and it is just based only on the label, where the label is associated with an pair. What we would like to do in our next version of the draft, we will remove the section 10 and just have a short paragraph to explain briefly that LDP-MT support will not require the data plane changes using the text similar you have suggested here. " For the section 3.5, the applications scenario is that when one ISP owns multiple ASes and the VPN services crossing these ASes are usually setup using inter-AS VPNs' option A or B or C. With MPLS multiple topology, the ISP can configure a new AS with a subset of the routers which are sitting in the existing ASes. The new AS will be used to provide the VPN services and there is not inter-AS setup needed anymore. In the IETF79 meeting, Lianyuan had a presentation to describe this, here is the link for the presentation slide( page3-page7): http://www.ietf.org/proceedings/79/slides/mpls-10/mpls-10.htm. I have also a few other comments and questions and see the places with [Quintin] in line. Quintin ---------------------------------------------------------------------- Message: 1 Date: Mon, 17 Oct 2011 11:22:23 -0400 From: Eric Rosen To: mpls@ietf.org Subject: [mpls] Forwarding discussion in ldp-multi-topology draft Message-ID: <6871.1318864943@erosen-linux> I'd like to make a comment on the discussion of forwarding in draft-ietf-mpls-ldp-multi-topology-00.txt. The draft is about the control plane mechanism used to bind a label to a pair. The label is downstream-assigned. The interpretation of the label is thus a local matter for the downstream LDP peer that assigns it. The draft mentions the possibility of binding a stack of labels to a pair. One could also consider the possibility of binding a stack of labels to an "ordinary" address prefix in a single-topology environment. There are two separate issues: 1. defining a signaling mechanism for binding more than one label to a FEC element of some sort. 2. defining the encoding of a FEC element that represents a pair These two issues are orthogonal, and the draft is about issue 2, NOT about issue 1. Note that if we have the mechanism of 1, it could be combined with the encoding of 2. But as long as all the assigned labels are downstream-assigned, their interpretation would be a local matter for the assigner, and it would not be appropriate to require, e.g., that the top label be a context label. Thus I would suggest removing the following paragraph from section 2: [Quintin] Agree. "There are two possible solutions to support MT awared MPLS network from MPLS forwarding point of view. The first one is to map label to both ip address and the corresponding topology. The alternative one is to use label stacks. The upper label maps to the topology, the lower label maps to the ip address. The first option does not require change to data plane, and it could use multiple labels for the same address on different topologies. The second option requires two lookups on data forwarding plane, and it can use the same label" It suggests that if a two-label solution is ever used, the top label would be a" context label" (RFC 5331) specifying the table in which the second label is looked up. There is no particular reason to say this. The paragraph also suggests that if a context label is not used, the platform-specific label space must be used. There's no particular reason to say that either; one could imagine an environment in which an interface-specific label space could be used (e.g., each link in only one topology). These issues are outside the scope of this draft, and I think any discussion of them here will only cause confusion in the future. [Quintin] if the linter-specific label space is used, then we still have the case that this interface is used by multiple topology, right? How can we differentiate the different topologies? It would be okay to say just that this draft does not require or presuppose any changes to the MPLS data plane. Similarly, I would suggest omitting section 10 entirely. The section even pronounces itself to be outside the scope of the document. It also has a few inaccuracies. In MT based MPLS network, forwarding will be based not only on label, but also on MT-ID associsted with the label. This is not true as stated. I think what is meant is that forwarding is still based only on the label, but the label is associated with an pair. It also resolves the forwarding issue that exists in IGP multi-topology forwarding when multiple topologies share an interface with overlay address space. "overlay" --> "overlapping", I think. [Quintin] You are right. When this draft gets reviewed outside the MPLS group, the term "the issue that exists in IGP multi-topology forwarding" will attract unwanted attention, as it is not completely clear what that issue is, why it is such a big problem, or why it needs to be mentioned in this context. > in this mechanism, label space is not allowed to be overlapping > among different MTs I think the most you can say is that: - the specified signaling mechanisms allow all the topologies to share the platform-specific label space; this is the feature that allows the existing data plane techniques to be used; and - the specified signaling mechanisms do not provide any way for the data plane to associate a given packet with a context-specific label space. I also have some comments on the applicability section. [Quintin] Will use the texts you suggested here in the next version of the draft. Section 3.1 "Simplified Data-plane" is pretty standard "MPLS is good" stuff. But I'd have thought that the problem with non-MPLS multi-topology is not so much the fact that it needs multiple FIBs as that there has to be some way of associating a received packet with a particular topology. [Quintin] Can you explain more on this "some way" here? With multiple FIBs, does associating a received packet with a particular topology requires the data plane change if the existing router has not supported multiple topology before? Section 3.5, "Simplified inter-AS VPN solution", suggests that multi-topology LDP allows inter-AS VPNs to be set up without using options A, B or C. I don't really understand what is being proposed here. [Quintin] reference to the slide. ------------------------------ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls End of mpls Digest, Vol 90, Issue 23 ************************************ From adrian@olddog.co.uk Tue Oct 18 14:14:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09E421F8B0B; Tue, 18 Oct 2011 14:14:04 -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=[AWL=0.000, 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 S1oeN3UMX91i; Tue, 18 Oct 2011 14:14:04 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 8B74621F8AD2; Tue, 18 Oct 2011 14:13:58 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p9ILDrRm029375; Tue, 18 Oct 2011 22:13:53 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p9ILDoDs029358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Oct 2011 22:13:51 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , References: <4E9CCD54.205@pi.nu> In-Reply-To: <4E9CCD54.205@pi.nu> Date: Tue, 18 Oct 2011 22:13:49 +0100 Message-ID: <006b01cc8dda$d54c34f0$7fe49ed0$@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: AQIvLUUHGZYOTnEAk+0yh8qdhz7f4wEsuZcLlLP09PA= Content-Language: en-gb Cc: 'Ross Callon' , pwe3@ietf.org Subject: Re: [mpls] Second last call on draft-ietf-mpls-tp-li-lb X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 21:14:05 -0000 Thanks for that, Loa. I have entered the minor comments received as RFC Editor notes (http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-li-lb/writeup/) When the IESG has completed its review the authors can post a new revision to pick up these changes and any other issues that the IESG raise. Cheers, Adrian > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: 18 October 2011 01:50 > To: mpls@ietf.org > Cc: George Swallow; pwe3@ietf.org; Ross Callon; Adrian Farrel > Subject: Re: [mpls] Second last call on draft-ietf-mpls-tp-li-lb > > Working Group, > > The working group last call on drat-ietf-mpls-tp-li-lb has ended. > > We have two outstanding issues - a proposal to add an explicit Unlock > message and on the coincidental bidirectional MIP. > > The working group does not have consensus to add either, but the > working group chairs encourage anyone to work on this to > write Internet Drafts on the subjects. > > In the meantime we will go ahead with the draft as it is. > > Loa, George and Ross > mpls wg co-chairs > > On 2011-10-03 18:23, George Swallow wrote: > > All - > > > > draft-ietf-mpls-tp-li-lb-07.txt has gone through an extensive rewrite. > > We are therefore initiating a new WG last call. Note however, the IETF > > last call will run nearly concurrently. > > > > The last call ends at Oct 17 at 24:00 GMT. > > > > George, Ross, & Loa > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 From erminio.ottone_69@libero.it Wed Oct 19 13:49:05 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F60B11E8098; Wed, 19 Oct 2011 13:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 GiS8vczK-no9; Wed, 19 Oct 2011 13:49:04 -0700 (PDT) Received: from outrelay01.libero.it (outrelay01.libero.it [212.52.84.101]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0E111E8096; Wed, 19 Oct 2011 13:49:02 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B020C.4E9F37BB.00FF,ss=1,re=0.000,fgs=0 X-libjamoibt: 1821 Received: from wmail9.libero.it (172.31.0.78) by outrelay01.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4E3BF90A06D74BF3; Wed, 19 Oct 2011 22:48:59 +0200 Message-ID: <24553486.2302221319057339704.JavaMail.defaultUser@defaultHost> Date: Wed, 19 Oct 2011 22:48:59 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 79.6.135.33 Cc: ietf@ietf.org Subject: [mpls] R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 20:49:05 -0000 I do not support the publication of this draft. As indicated by many technical comments already raised on this topic, what the MPLS WG has defined is not a single solution but encopasses a variety of incompatible options none of which meet the requirements of major transport operators. The draft is therefore technically incorrect unless the concept of "single soution" is defined as anything but what meets the requirements of major transport operators. Looking at the precedents provided in the draft, I can see at least a couple which were a great market success (e.g., OSPF/IS-IS and SONET/SDH). I wonder whether the real motivaiton for the selection of a "single solution" as defined above is to manipulate the market to avoid MPLS-TP being as successfull as these precedents. In order to make comments according to the "IETF tradition", my text change proposal is very simple: replace the whole document with the text provided by draft-fang-mpls-tp-oam-considerations. draft-fang-mpls-tp-oam-considerations provides considerations from operators that have field experience with large scale deployments of MPLS-TP which are more relevant that incorrect phylosophical considerations. >----Messaggio originale---- >Da: adrian@olddog.co.uk >Data: 26-set-2011 23.57 >A: >Ogg: [mpls] FW: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01. txt> (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC > >MPLS Working Group, > >Please be aware of the IETF last call as shown below. The document was presented >for publication as an individual RFC with IETF consensus and AD sponsorship. > >This draft is clearly close and relevant to the work you do, but after >discussing with the chairs I came to the conclusion that it does not comment on >the technical or process decisions of the MPLS working groups, and it does not >attempt to make any technical evaluations or definitions within the scope of the >MPLS working group. It is more of a philosophical analysis of the way the IETF >approaches the "two solutions" problem with special reference to MPLS-TP OAM. > >Thus, I am accepting the document as AD Sponsored rather than running it through >the MPLS working group. My reasoning is that the working group has got plenty to >do working on technical issues without being diverted into wider IETF >philosophy. > >As an AD Sponsored I-D it is subject to a four week IETF last call. That is >plenty of opportunity for everyone to comment and express their views. Please >send your comments to the IETF mailing list as described below, or (in >exceptional circumstances) direct to the IESG. > >Thanks, >Adrian > >> -----Original Message----- >> From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- >> bounces@ietf.org] On Behalf Of The IESG >> Sent: 26 September 2011 20:43 >> To: IETF-Announce >> Subject: Last Call: (The >> Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC >> >> >> The IESG has received a request from an individual submitter to consider >> the following document: >> - 'The Reasons for Selecting a Single Solution for MPLS-TP OAM' >> as an 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 2011-10-24. 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 >> >> The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology >> for use in transport network deployments. That is, MPLS-TP is a set >> of functions and features selected from the wider MPLS toolset and >> applied in a consistent way to meet the needs and requirements of >> operators of packet transport networks. >> >> During the process of development of the profile, additions to the >> MPLS toolset have been made to ensure that the tools available met >> the requirements. These additions were motivated by MPLS-TP, but form >> part of the wider MPLS toolset such that any of them could be used in >> any MPLS deployment. >> >> One major set of additions provides enhanced support for Operations, >> Administration, and Maintenance (OAM). This enables fault management >> and performance monitoring to the level needed in a transport >> network. Many solutions and protocol extensions have been proposed to >> address these OAM requirements, and this document sets out the >> reasons for selecting a single, coherent set of solutions for >> standardization. >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From erminio.ottone_69@libero.it Wed Oct 19 13:49:25 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35C611E80AD; Wed, 19 Oct 2011 13:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.335 X-Spam-Level: X-Spam-Status: No, score=-0.335 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3, SARE_MILLIONSOF=0.315, SARE_SUB_ENC_UTF8=0.152] 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 sDoQin6nvpXZ; Wed, 19 Oct 2011 13:49:25 -0700 (PDT) Received: from outrelay02.libero.it (outrelay02.libero.it [212.52.84.102]) by ietfa.amsl.com (Postfix) with ESMTP id 0899D11E8096; Wed, 19 Oct 2011 13:49:25 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0201.4E9F37D0.0017,ss=1,re=0.000,fgs=0 X-libjamoibt: 1821 Received: from wmail9.libero.it (172.31.0.78) by outrelay02.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4E3BF94606DC628A; Wed, 19 Oct 2011 22:49:19 +0200 Message-ID: <28928821.2302421319057359974.JavaMail.defaultUser@defaultHost> Date: Wed, 19 Oct 2011 22:49:19 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.6.135.33 Cc: "mpls@ietf.org" , mpls-bounces@ietf.orgLarry, "ietf@ietf.org" Subject: [mpls] =?utf-8?b?UjogUmU6ICDnrZTlpI06ICDlm57lpI3vvJogIFI6IEZXOiBM?= =?utf-8?q?ast_Call=3A_=3Cdraft-sprecher-mpls-tp-oam-considerations-01=2Et?= =?utf-8?q?xt=3E_=28The_Reasons_for_Selecting_a_Single_Solution_for_MPLS-T?= =?utf-8?q?P_OAM=29_to_Informational_RFC?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 20:49:25 -0000 If the MPLS WG had selected the OAM solution that was already existing (as= =20 indicated multiple times by the operators which have already massively depl= oyed=20 it), we would have had a single OAM solution both in the market and in the = IETF=20 RFCs. We now have "two" OAM solutions: one (which is not actually really singular= )=20 documented by IETF RFCs and one widely implemented and deployed. This draft= is=20 not resolving this issue at all. >----Messaggio originale---- >Da: brian.e.carpenter@gmail.com >Data: 5-ott-2011 22.16 >A: >Cc: "mpls@ietf.org", "ietf@ietf.org", >Ogg: Re: [mpls] =E7=AD=94=E5=A4=8D: =E5=9B=9E=E5=A4=8D=EF=BC=9A R: FW: L= ast Call: <draft-sprecher-mpls-tp-oam- considerations-01.txt> (The Reasons for Selecting a Single Solution for = MPLS- TP OAM) to Informational RFC > >Hi Jian, > >On 2011-10-06 03:53, yang.jian90@zte.com.cn wrote: >> Dear All, >>=20 >> I do not support either. >>=20 >> In section 3.5: >> If two MPLS OAM protocols were to be deployed we would have to consider >> three possible scenarios: >> 1) Isolation of the network into two incompatible and unconnected island= s. >>=20 >> Two OAM solutions have been discussed for a long time in both ITU-T and >> IETF. >> Each solution has their own supporters inculding carriers and vendors. >> So I don't think there is any interworking issue between two OAM=20 solutions. >> Carrier will select one OAM solution, A or B, in their network. >> No need to select A and B at one network at the same time. > >There are two large costs that you are ignoring: > >a) all vendors wishing to bid for business from A and B will have to > implement and support both solutions. > >b) when A buys B or B buys A, the incompatible networks will have to > be merged. > >These are costs that run to hundreds of millions of USD, EUR or CNY. >They are costs caused directly by SDOs creating rival solutions. > >I think it would be irresponsible of the IETF not to document this >situation. As engineers, we have an ethical responsibility here. > > Brian >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From erminio.ottone_69@libero.it Wed Oct 19 13:50:16 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F9511E80A5; Wed, 19 Oct 2011 13:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.527 X-Spam-Level: X-Spam-Status: No, score=-0.527 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 kNegwfdC-Ocx; Wed, 19 Oct 2011 13:50:15 -0700 (PDT) Received: from outrelay01.libero.it (outrelay01.libero.it [212.52.84.101]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7A711E8096; Wed, 19 Oct 2011 13:50:15 -0700 (PDT) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0207.4E9F37FF.0135,ss=1,re=0.000,fgs=0 X-libjamoibt: 1821 Received: from wmail9.libero.it (172.31.0.78) by outrelay01.libero.it (8.5.133) (authenticated as erminio.ottone_69@libero.it) id 4E3BF90A06D751A5; Wed, 19 Oct 2011 22:50:07 +0200 Message-ID: <19639914.2302661319057407695.JavaMail.defaultUser@defaultHost> Date: Wed, 19 Oct 2011 22:50:07 +0200 (CEST) From: "erminio.ottone_69@libero.it" To: , "Luyuan Fang (lufang)" , Alexander Vainshtein , D'Alessandro Alessandro Gerardo , "Stewart Bryant (stbryant)" MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SenderIP: 79.6.135.33 Cc: "mpls@ietf.org" , "ietf@ietf.org" Subject: [mpls] R: Re: unresolved technical concerns X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "erminio.ottone_69@libero.it" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 20:50:16 -0000 What about going into the mailing list and LS logs and read the comments=20 provided by several service providers before asking for them being repeated= =20 again in a I-D that will fate share with the past comments (i.e., ignored)? The comments have been already made. It is now the duty of the party which = has=20 so far ignored them to provide an answer. It is also so easy to keep ingnoring drafts and technical comments and requ= est=20 people to continue to produce drafts >----Messaggio originale---- >Da: jdrake@juniper.net >Data: 5-ott-2011 23.20 >A: "Luyuan Fang (lufang)", "Alexander Vainshtein", "D'Alessandro Alessandro Gerardo", "Stewart Bryant (stbryant)" >Cc: "mpls@ietf.org", "ietf@ietf.org" >Ogg: Re: [mpls] unresolved technical concerns > >That's because it is *so* much easier to just keep mumbling 'major unresol= ved=20 technical concerns'. I expect it is something learned in Yoga class.=20 > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Luyuan Fang (lufang) >> Sent: Wednesday, October 05, 2011 5:11 PM >> To: Alexander Vainshtein; D'Alessandro Alessandro Gerardo; Stewart >> Bryant (stbryant) >> Cc: mpls@ietf.org; ietf@ietf.org >> Subject: Re: [mpls] unresolved technical concerns >>=20 >> Yep. We are going in circles again. >> We need to see technical details on the issues documented in an I-D as >> Stewart suggested. >> Don't remember seeing such document either. >>=20 >> Luyuan >>=20 >>=20 >> > -----Original Message----- >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of >> > Alexander Vainshtein >> > Sent: Wednesday, October 05, 2011 4:18 PM >> > To: D'Alessandro Alessandro Gerardo; Stewart Bryant (stbryant) >> > Cc: ietf@ietf.org; mpls@ietf.org >> > Subject: Re: [mpls] unresolved technical concerns >> > >> > >> > Dear Alessandro, >> > Lots of thanks for a prompt response. >> > >> > Unfortunately your response does not really help (at least, me) to >> > identify even a single >> > specific technical issue. You may attribute it to my faulty memory, >> > but I could not remember any. Presenting these cocerns in the form >> > of an I-D as suggested by Stewart would be the right first step. >> > >> > >> > My 2c >> > Sasha >> > >> > ________________________________________ >> > From: D'Alessandro Alessandro Gerardo >> > [alessandro.dalessandro@telecomitalia.it] >> > Sent: Wednesday, October 05, 2011 6:54 PM >> > To: stbryant@cisco.com; Alexander Vainshtein >> > Cc: adrian@olddog.co.uk; mpls@ietf.org; ietf@ietf.org >> > Subject: unresolved technical concerns >> > >> > Dear Stewart, Dear Sasha, >> > I think there are already enough contributions in that direction I >> > (with many other experts) contributed to in the form of IETF mailing >> > list discussion and ITU-T liaisons. Unfortunately I regret to say >> that >> > some questions for clarification and concerns risen in those emails >> > (for sure some of mine) still remain without an answer. At the same >> > time, some comments provided by ITU-T liaisons still remain >> unresolved. >> > >> > Best regards, >> > Alessandro >> > >> > ------------------------------------------------------------------ >> > Telecom Italia >> > Alessandro D'Alessandro >> > Transport Innovation >> > Via Reiss Romoli, 274 - 10148 Torino >> > phone: +39 011 228 5887 >> > mobile: +39 335 766 9607 >> > fax: +39 06 418 639 07 >> > >> > >> > -----Messaggio originale----- >> > Da: Stewart Bryant [mailto:stbryant@cisco.com] >> > Inviato: mercoled=C3=AC 5 ottobre 2011 12:24 >> > A: D'Alessandro Alessandro Gerardo >> > Cc: adrian@olddog.co.uk; mpls@ietf.org; ietf@ietf.org >> > Oggetto: Re: [mpls] R: FW: Last Call: > > considerations-01.txt> (The Reasons for Selecting a Single Solution >> for >> > MPLS-TP OAM) to Informational RFC >> > >> > On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote: >> > > major unresolved technical concerns >> > >> > Alessandro >> > >> > Please can I suggest that you write an internet draft detailing these >> > "major unresolved technical concerns" so that we can all understand >> > them. >> > >> > Such a draft needs to be technical, and describe the actions that the >> > network operator is unable to perform, or the fault cases that they >> are >> > unable to diagnose using the OAM defined in the IETF RFCs, or late >> > stage WG drafts. >> > >> > Alternatively if you are referring to a bug in the MPLS-TP OAM >> > protocols, you need to tell the community what it is. >> > >> > I believe that this request has been made a number of times, in >> > various forums, and, as far as I know, no document has yet been >> > produced. >> > >> > An argument of the form "you must standardize what I want" >> > will not fly. What is needed is a very clear technical definition of >> > the issue(s). >> > >> > When we have the "major unresolved technical concerns" >> > on the table, we will be in a position to determine the best >> > disposition of those issues. >> > >> > Stewart >> > >> > >> > >> > >> > >> > >> > >> > -- >> > For corporate legal information go to: >> > >> > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> > >> > >> > >> > Questo messaggio e i suoi allegati sono indirizzati esclusivamente >> alle >> > persone indicate. La diffusione, copia o qualsiasi altra azione >> > derivante dalla conoscenza di queste informazioni sono rigorosamente >> > vietate. Qualora abbiate ricevuto questo documento per errore siete >> > cortesemente pregati di darne immediata comunicazione al mittente e >> di >> > provvedere alla sua distruzione, Grazie. >> > >> > This e-mail and any attachments is confidential and may contain >> > privileged information intended for the addressee(s) only. >> > Dissemination, copying, printing or use by anybody else is >> > unauthorised. If you are not the intended recipient, please delete >> this >> > message and any attachments and advise the sender by return e-mail, >> > Thanks. >> > >> > >> > >> > This e-mail message is intended for the recipient only and contains >> > information which is CONFIDENTIAL and which may be proprietary to ECI >> > Telecom. If you have received this transmission in error, please >> inform >> > us by e-mail, phone or fax, and then delete the original and all >> copies >> > thereof. >> > >> > _______________________________________________ >> > mpls mailing list >> > mpls@ietf.org >> > https://www.ietf.org/mailman/listinfo/mpls >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From gregimirsky@gmail.com Wed Oct 19 14:15:47 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FC921F8A62 for ; Wed, 19 Oct 2011 14:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.207 X-Spam-Level: X-Spam-Status: No, score=0.207 tagged_above=-999 required=5 tests=[AWL=-3.805, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, SARE_SUB_ENC_GB2312=1.345] 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 3qO4rYHESOfT for ; Wed, 19 Oct 2011 14:15:47 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC81B21F8500 for ; Wed, 19 Oct 2011 14:15:46 -0700 (PDT) Received: by vws5 with SMTP id 5so1856360vws.31 for ; Wed, 19 Oct 2011 14:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nI/IV1M37CDfEDoRZroqxV50aVM4VXCtzkHuPa6IOqc=; b=orLAgSbW2jG6doEHrebN/EmOCvvdbQ39W/NOJfSfIYnHdLDtTWU9+Cxr/xbsSrt26u NFXpk7+9rFdgs3LQNhn4UTQxA0wz4yilTPxN+vhIQS8T/se5mCPmWJ2p2oSjjPptOTXl /JFsH4CoH4icfYyD0o9bpCT0b+JGHVY14xmYU= MIME-Version: 1.0 Received: by 10.52.19.236 with SMTP id i12mr8305606vde.58.1319058946248; Wed, 19 Oct 2011 14:15:46 -0700 (PDT) Received: by 10.52.163.199 with HTTP; Wed, 19 Oct 2011 14:15:46 -0700 (PDT) In-Reply-To: <28928821.2302421319057359974.JavaMail.defaultUser@defaultHost> References: <28928821.2302421319057359974.JavaMail.defaultUser@defaultHost> Date: Wed, 19 Oct 2011 14:15:46 -0700 Message-ID: From: Greg Mirsky To: "erminio.ottone_69@libero.it" Content-Type: multipart/alternative; boundary=20cf3078115cedce6004afad57d8 Cc: "mpls@ietf.org" , brian.e.carpenter@gmail.com, yang.jian90@zte.com.cn Subject: Re: [mpls] =?gb2312?b?UjogUmU6ILTwuLQ6ILvYuLSjuiBSOiBGVzogTGFzdCBD?= =?gb2312?b?YWxsOiA8ZHJhZnQtc3ByZWNoZXItbXBscy10cC1vYW0tY29uc2lk?= =?gb2312?b?ZXJhdGlvbnMtMDEudHh0PiAoVGhlIFJlYXNvbnMgZm9yIFNlbGVj?= =?gb2312?b?dGluZyBhIFNpbmdsZSBTb2x1dGlvbiBmb3IgTVBMUy1UUCBPQU0p?= =?gb2312?b?IHRvIEluZm9ybWF0aW9uYWwgUkZD?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 21:15:47 -0000 --20cf3078115cedce6004afad57d8 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear Erminio, being myself I can not agree with your characterization of non-IETF MPLS-TP OAM as "one widely implemented and deployed", especially in regard to scope of implementations. I think there might be two or three implementations. As for extent of deployment I've heard of three though on large number of nodes. It would be helpful if we had opportunity to hear from operators about lessons learned. Regards, Greg On Wed, Oct 19, 2011 at 1:49 PM, erminio.ottone_69@libero.it < erminio.ottone_69@libero.it> wrote: > If the MPLS WG had selected the OAM solution that was already existing (a= s > indicated multiple times by the operators which have already massively > deployed > it), we would have had a single OAM solution both in the market and in th= e > IETF > RFCs. > > We now have "two" OAM solutions: one (which is not actually really > singular) > documented by IETF RFCs and one widely implemented and deployed. This dra= ft > is > not resolving this issue at all. > > >----Messaggio originale---- > >Da: brian.e.carpenter@gmail.com > >Data: 5-ott-2011 22.16 > >A: > >Cc: "mpls@ietf.org", "ietf@ietf.org", > bounces@ietf.orgLarry> > >Ogg: Re: [mpls] =B4=F0=B8=B4: =BB=D8=B8=B4=A3=BA R: FW: Last Call: > <draft-sprecher-mpls-tp-oam- > considerations-01.txt> (The Reasons for Selecting a Single Solution fo= r > MPLS- > TP OAM) to Informational RFC > > > >Hi Jian, > > > >On 2011-10-06 03:53, yang.jian90@zte.com.cn wrote: > >> Dear All, > >> > >> I do not support either. > >> > >> In section 3.5: > >> If two MPLS OAM protocols were to be deployed we would have to conside= r > >> three possible scenarios: > >> 1) Isolation of the network into two incompatible and unconnected > islands. > >> > >> Two OAM solutions have been discussed for a long time in both ITU-T an= d > >> IETF. > >> Each solution has their own supporters inculding carriers and vendors. > >> So I don't think there is any interworking issue between two OAM > solutions. > >> Carrier will select one OAM solution, A or B, in their network. > >> No need to select A and B at one network at the same time. > > > >There are two large costs that you are ignoring: > > > >a) all vendors wishing to bid for business from A and B will have to > > implement and support both solutions. > > > >b) when A buys B or B buys A, the incompatible networks will have to > > be merged. > > > >These are costs that run to hundreds of millions of USD, EUR or CNY. > >They are costs caused directly by SDOs creating rival solutions. > > > >I think it would be irresponsible of the IETF not to document this > >situation. As engineers, we have an ethical responsibility here. > > > > Brian > >_______________________________________________ > >mpls mailing list > >mpls@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --20cf3078115cedce6004afad57d8 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear Erminio,
being myself I can not agree with your characterization of= non-IETF MPLS-TP OAM as "one widely implemented and deployed", e= specially in regard to scope of implementations. I think there might be two= or three implementations. As for extent of deployment I've heard of th= ree though on large number of nodes. It would be helpful if we had opportun= ity to hear from operators about lessons learned.

Regards,
Greg

On Wed, Oct 19, 2011= at 1:49 PM, erminio.ottone_= 69@libero.it <erminio.ottone_69@libero.it> wrote:
If the MPLS WG had selected the OAM solutio= n that was already existing (as
indicated multiple times by the operators which have already massively depl= oyed
it), we would have had a single OAM solution both in the market and in the = IETF
RFCs.

We now have "two" OAM solutions: one (which is not actually reall= y singular)
documented by IETF RFCs and one widely implemented and deployed. This draft= is
not resolving this issue at all.

>----Messaggio originale----
>Da: brian.e.carpenter@gm= ail.com
>Data: 5-ott-2011 22.16
>A: <yang.jian90@zte.com.cn= >
>Cc: "mpls@ietf.org"<<= a href=3D"mailto:mpls@ietf.org">mpls@ietf.org>, "ietf@ietf.org"<ietf@ietf.org>, <mpls-
bounces@ietf.orgLarry>
>Ogg: Re: [mpls] =B4=F0=B8=B4:  =BB=D8=B8=B4=A3=BA  R: FW: Las= t Call: &lt;draft-sprecher-mpls-tp-oam-
considerations-01.txt&gt; (The Reasons for Selecting a Single Solution = for MPLS-
TP OAM) to Informational RFC
>
>Hi Jian,
>
>On 2011-10-06 03:53, yang.jia= n90@zte.com.cn wrote:
>> Dear All,
>>
>> I do not support either.
>>
>> In section 3.5:
>> If two MPLS OAM protocols were to be deployed we would have to con= sider
>> three possible scenarios:
>> 1) Isolation of the network into two incompatible and unconnected = islands.
>>
>> Two OAM solutions have been discussed for a long time in both ITU-= T and
>> IETF.
>> Each solution has their own supporters inculding carriers and vend= ors.
>> So I don't think there is any interworking issue between two O= AM
solutions.
>> Carrier will select one OAM solution, A or B, in their network. >> No need to select A and B at one network at the same time.
>
>There are two large costs that you are ignoring:
>
>a) all vendors wishing to bid for business from A and B will have to >   implement and support both solutions.
>
>b) when A buys B or B buys A, the incompatible networks will have to >   be merged.
>
>These are costs that run to hundreds of millions of USD, EUR or CNY. >They are costs caused directly by SDOs creating rival solutions.
>
>I think it would be irresponsible of the IETF not to document this
>situation. As engineers, we have an ethical responsibility here.
>
>    Brian
>_____________________________________= __________
>mpls mailing list
>mpls@ietf.org
>https://www.ietf.org/mailman/listinfo/mpls
>


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

--20cf3078115cedce6004afad57d8-- From jdrake@juniper.net Wed Oct 19 14:49:41 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D091F0C4B; Wed, 19 Oct 2011 14:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 8cRO-Rq6RBZK; Wed, 19 Oct 2011 14:49:40 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id CAC1221F8A6C; Wed, 19 Oct 2011 14:49:39 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Wed, 19 Oct 2011 14:49:40 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 19 Oct 2011 14:49:12 -0700 From: John E Drake To: "erminio.ottone_69@libero.it" , "Luyuan Fang (lufang)" , Alexander Vainshtein , D'Alessandro Alessandro Gerardo , "Stewart Bryant (stbryant)" Date: Wed, 19 Oct 2011 14:49:10 -0700 Thread-Topic: Re: [mpls] unresolved technical concerns Thread-Index: AcyOpA6U0gsTMAwTRjuVG85eQ9VqygAA8WtQ Message-ID: <5E893DB832F57341992548CDBB333163A4448A38E2@EMBX01-HQ.jnpr.net> References: <19639914.2302661319057407695.JavaMail.defaultUser@defaultHost> In-Reply-To: <19639914.2302661319057407695.JavaMail.defaultUser@defaultHost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mpls@ietf.org" , "ietf@ietf.org" Subject: Re: [mpls] unresolved technical concerns X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 21:49:41 -0000 QWxlc3NhbmRybywNCg0KTW9zdCBvZiB0aGUgY29tbWVudHMgSSByZW1lbWJlciByZWFkaW5nIHdl cmUgb2YgdGhlIGZvcm0gIndlIGRvbid0IGxpa2UgTVBMUyBPQU0gYmVjYXVzZSBpdCBoYXMgJ21h am9yIHVucmVzb2x2ZWQgdGVjaG5pY2FsIGNvbmNlcm5zJyBhbmQgZHJhZnQtYmhoIGlzICpzbyog bXVjaCBiZXR0ZXIiLiAgSS5lLiwgdGhleSB3ZXJlIG5laXRoZXIgY29uc3RydWN0aXZlIG5vciBh Y3Rpb25hYmxlLg0KDQpUaGFua3MsDQoNCkpvaG4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBlcm1pbmlvLm90dG9uZV82OUBsaWJlcm8uaXQgW21haWx0bzplcm1pbmlv Lm90dG9uZV82OUBsaWJlcm8uaXRdDQo+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxOSwgMjAx MSAxOjUwIFBNDQo+IFRvOiBKb2huIEUgRHJha2U7IEx1eXVhbiBGYW5nIChsdWZhbmcpOyBBbGV4 YW5kZXIgVmFpbnNodGVpbjsNCj4gRCdBbGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJkbzsgU3Rl d2FydCBCcnlhbnQgKHN0YnJ5YW50KQ0KPiBDYzogbXBsc0BpZXRmLm9yZzsgaWV0ZkBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSOiBSZTogW21wbHNdIHVucmVzb2x2ZWQgdGVjaG5pY2FsIGNvbmNlcm5z DQo+IA0KPiBXaGF0IGFib3V0IGdvaW5nIGludG8gdGhlIG1haWxpbmcgbGlzdCBhbmQgTFMgbG9n cyBhbmQgcmVhZCB0aGUNCj4gY29tbWVudHMNCj4gcHJvdmlkZWQgYnkgc2V2ZXJhbCBzZXJ2aWNl IHByb3ZpZGVycyBiZWZvcmUgYXNraW5nIGZvciB0aGVtIGJlaW5nDQo+IHJlcGVhdGVkDQo+IGFn YWluIGluIGEgSS1EIHRoYXQgd2lsbCBmYXRlIHNoYXJlIHdpdGggdGhlIHBhc3QgY29tbWVudHMg KGkuZS4sDQo+IGlnbm9yZWQpPw0KPiANCj4gVGhlIGNvbW1lbnRzIGhhdmUgYmVlbiBhbHJlYWR5 IG1hZGUuIEl0IGlzIG5vdyB0aGUgZHV0eSBvZiB0aGUgcGFydHkNCj4gd2hpY2ggaGFzDQo+IHNv IGZhciBpZ25vcmVkIHRoZW0gdG8gcHJvdmlkZSBhbiBhbnN3ZXIuDQo+IA0KPiBJdCBpcyBhbHNv IHNvIGVhc3kgdG8ga2VlcCBpbmdub3JpbmcgZHJhZnRzIGFuZCB0ZWNobmljYWwgY29tbWVudHMg YW5kDQo+IHJlcXVlc3QNCj4gcGVvcGxlIHRvIGNvbnRpbnVlIHRvIHByb2R1Y2UgZHJhZnRzDQo+ IA0KPiA+LS0tLU1lc3NhZ2dpbyBvcmlnaW5hbGUtLS0tDQo+ID5EYTogamRyYWtlQGp1bmlwZXIu bmV0DQo+ID5EYXRhOiA1LW90dC0yMDExIDIzLjIwDQo+ID5BOiAiTHV5dWFuIEZhbmcgKGx1ZmFu ZykiPGx1ZmFuZ0BjaXNjby5jb20+LCAiQWxleGFuZGVyDQo+IFZhaW5zaHRlaW4iPEFsZXhhbmRl ci4NCj4gVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4sICJEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBH ZXJhcmRvIjxhbGVzc2FuZHJvLg0KPiBkYWxlc3NhbmRyb0B0ZWxlY29taXRhbGlhLml0PiwgIlN0 ZXdhcnQgQnJ5YW50DQo+IChzdGJyeWFudCkiPHN0YnJ5YW50QGNpc2NvLmNvbT4NCj4gPkNjOiAi bXBsc0BpZXRmLm9yZyI8bXBsc0BpZXRmLm9yZz4sICJpZXRmQGlldGYub3JnIjxpZXRmQGlldGYu b3JnPg0KPiA+T2dnOiBSZTogW21wbHNdIHVucmVzb2x2ZWQgdGVjaG5pY2FsIGNvbmNlcm5zDQo+ ID4NCj4gPlRoYXQncyBiZWNhdXNlIGl0IGlzICpzbyogbXVjaCBlYXNpZXIgdG8ganVzdCBrZWVw IG11bWJsaW5nICdtYWpvcg0KPiB1bnJlc29sdmVkDQo+IHRlY2huaWNhbCBjb25jZXJucycuICBJ IGV4cGVjdCBpdCBpcyBzb21ldGhpbmcgbGVhcm5lZCBpbiBZb2dhIGNsYXNzLg0KPiA+DQo+ID4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mDQo+ID4+ IEx1eXVhbiBGYW5nIChsdWZhbmcpDQo+ID4+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAwNSwg MjAxMSA1OjExIFBNDQo+ID4+IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgRCdBbGVzc2FuZHJv IEFsZXNzYW5kcm8gR2VyYXJkbzsgU3Rld2FydA0KPiA+PiBCcnlhbnQgKHN0YnJ5YW50KQ0KPiA+ PiBDYzogbXBsc0BpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW21w bHNdIHVucmVzb2x2ZWQgdGVjaG5pY2FsIGNvbmNlcm5zDQo+ID4+DQo+ID4+IFllcC4gV2UgYXJl IGdvaW5nIGluIGNpcmNsZXMgYWdhaW4uDQo+ID4+IFdlIG5lZWQgdG8gc2VlIHRlY2huaWNhbCBk ZXRhaWxzIG9uIHRoZSBpc3N1ZXMgZG9jdW1lbnRlZCBpbiBhbiBJLUQNCj4gYXMNCj4gPj4gU3Rl d2FydCBzdWdnZXN0ZWQuDQo+ID4+IERvbid0IHJlbWVtYmVyIHNlZWluZyBzdWNoIGRvY3VtZW50 IGVpdGhlci4NCj4gPj4NCj4gPj4gTHV5dWFuDQo+ID4+DQo+ID4+DQo+ID4+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZg0KPiA+PiBPZg0KPiA+PiA+ IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+ID4+ID4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDA1 LCAyMDExIDQ6MTggUE0NCj4gPj4gPiBUbzogRCdBbGVzc2FuZHJvIEFsZXNzYW5kcm8gR2VyYXJk bzsgU3Rld2FydCBCcnlhbnQgKHN0YnJ5YW50KQ0KPiA+PiA+IENjOiBpZXRmQGlldGYub3JnOyBt cGxzQGlldGYub3JnDQo+ID4+ID4gU3ViamVjdDogUmU6IFttcGxzXSB1bnJlc29sdmVkIHRlY2hu aWNhbCBjb25jZXJucw0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPiBEZWFyIEFsZXNzYW5kcm8sDQo+ ID4+ID4gTG90cyAgb2YgdGhhbmtzIGZvciBhIHByb21wdCByZXNwb25zZS4NCj4gPj4gPg0KPiA+ PiA+IFVuZm9ydHVuYXRlbHkgeW91ciByZXNwb25zZSBkb2VzIG5vdCByZWFsbHkgaGVscCAoYXQg bGVhc3QsIG1lKSB0bw0KPiA+PiA+IGlkZW50aWZ5IGV2ZW4gYSBzaW5nbGUNCj4gPj4gPiBzcGVj aWZpYyB0ZWNobmljYWwgaXNzdWUuIFlvdSBtYXkgYXR0cmlidXRlIGl0IHRvIG15IGZhdWx0eQ0K PiBtZW1vcnksDQo+ID4+ID4gYnV0IEkgY291bGQgbm90IHJlbWVtYmVyIGFueS4gUHJlc2VudGlu ZyB0aGVzZSBjb2Nlcm5zIGluIHRoZSBmb3JtDQo+ID4+ID4gb2YgYW4gSS1EIGFzIHN1Z2dlc3Rl ZCBieSBTdGV3YXJ0IHdvdWxkICBiZSB0aGUgcmlnaHQgZmlyc3Qgc3RlcC4NCj4gPj4gPg0KPiA+ PiA+DQo+ID4+ID4gTXkgMmMNCj4gPj4gPiBTYXNoYQ0KPiA+PiA+DQo+ID4+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiA+IEZyb206IEQnQWxlc3NhbmRy byBBbGVzc2FuZHJvIEdlcmFyZG8NCj4gPj4gPiBbYWxlc3NhbmRyby5kYWxlc3NhbmRyb0B0ZWxl Y29taXRhbGlhLml0XQ0KPiA+PiA+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAwNSwgMjAxMSA2 OjU0IFBNDQo+ID4+ID4gVG86IHN0YnJ5YW50QGNpc2NvLmNvbTsgQWxleGFuZGVyIFZhaW5zaHRl aW4NCj4gPj4gPiBDYzogYWRyaWFuQG9sZGRvZy5jby51azsgbXBsc0BpZXRmLm9yZzsgaWV0ZkBp ZXRmLm9yZw0KPiA+PiA+IFN1YmplY3Q6IHVucmVzb2x2ZWQgdGVjaG5pY2FsIGNvbmNlcm5zDQo+ ID4+ID4NCj4gPj4gPiBEZWFyIFN0ZXdhcnQsIERlYXIgU2FzaGEsDQo+ID4+ID4gSSB0aGluayB0 aGVyZSBhcmUgYWxyZWFkeSBlbm91Z2ggY29udHJpYnV0aW9ucyBpbiB0aGF0IGRpcmVjdGlvbiBJ DQo+ID4+ID4gKHdpdGggbWFueSBvdGhlciBleHBlcnRzKSBjb250cmlidXRlZCB0byBpbiB0aGUg Zm9ybSBvZiBJRVRGDQo+IG1haWxpbmcNCj4gPj4gPiBsaXN0IGRpc2N1c3Npb24gYW5kIElUVS1U IGxpYWlzb25zLiBVbmZvcnR1bmF0ZWx5IEkgcmVncmV0IHRvIHNheQ0KPiA+PiB0aGF0DQo+ID4+ ID4gc29tZSBxdWVzdGlvbnMgZm9yIGNsYXJpZmljYXRpb24gYW5kIGNvbmNlcm5zIHJpc2VuIGlu IHRob3NlDQo+IGVtYWlscw0KPiA+PiA+IChmb3Igc3VyZSBzb21lIG9mIG1pbmUpIHN0aWxsIHJl bWFpbiB3aXRob3V0IGFuIGFuc3dlci4gQXQgdGhlDQo+IHNhbWUNCj4gPj4gPiB0aW1lLCBzb21l IGNvbW1lbnRzIHByb3ZpZGVkIGJ5IElUVS1UIGxpYWlzb25zIHN0aWxsIHJlbWFpbg0KPiA+PiB1 bnJlc29sdmVkLg0KPiA+PiA+DQo+ID4+ID4gQmVzdCByZWdhcmRzLA0KPiA+PiA+IEFsZXNzYW5k cm8NCj4gPj4gPg0KPiA+PiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiA+IFRlbGVjb20gSXRhbGlhDQo+ID4+ ID4gQWxlc3NhbmRybyBEJ0FsZXNzYW5kcm8NCj4gPj4gPiBUcmFuc3BvcnQgSW5ub3ZhdGlvbg0K PiA+PiA+IFZpYSBSZWlzcyBSb21vbGksIDI3NCAtIDEwMTQ4IFRvcmlubw0KPiA+PiA+IHBob25l OiAgKzM5IDAxMSAyMjggNTg4Nw0KPiA+PiA+IG1vYmlsZTogKzM5IDMzNSA3NjYgOTYwNw0KPiA+ PiA+IGZheDogKzM5IDA2IDQxOCA2MzkgMDcNCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4gLS0tLS1N ZXNzYWdnaW8gb3JpZ2luYWxlLS0tLS0NCj4gPj4gPiBEYTogU3Rld2FydCBCcnlhbnQgW21haWx0 bzpzdGJyeWFudEBjaXNjby5jb21dDQo+ID4+ID4gSW52aWF0bzogbWVyY29sZWTDrCA1IG90dG9i cmUgMjAxMSAxMjoyNA0KPiA+PiA+IEE6IEQnQWxlc3NhbmRybyBBbGVzc2FuZHJvIEdlcmFyZG8N Cj4gPj4gPiBDYzogYWRyaWFuQG9sZGRvZy5jby51azsgbXBsc0BpZXRmLm9yZzsgaWV0ZkBpZXRm Lm9yZw0KPiA+PiA+IE9nZ2V0dG86IFJlOiBbbXBsc10gUjogRlc6IExhc3QgQ2FsbDogPGRyYWZ0 LXNwcmVjaGVyLW1wbHMtdHAtb2FtLQ0KPiA+PiA+IGNvbnNpZGVyYXRpb25zLTAxLnR4dD4gKFRo ZSBSZWFzb25zIGZvciBTZWxlY3RpbmcgYSBTaW5nbGUNCj4gU29sdXRpb24NCj4gPj4gZm9yDQo+ ID4+ID4gTVBMUy1UUCBPQU0pIHRvIEluZm9ybWF0aW9uYWwgUkZDDQo+ID4+ID4NCj4gPj4gPiBP biAwNS8xMC8yMDExIDEwOjM4LCBEJ0FsZXNzYW5kcm8gQWxlc3NhbmRybyBHZXJhcmRvIHdyb3Rl Og0KPiA+PiA+ICA+IG1ham9yIHVucmVzb2x2ZWQgdGVjaG5pY2FsIGNvbmNlcm5zDQo+ID4+ID4N Cj4gPj4gPiBBbGVzc2FuZHJvDQo+ID4+ID4NCj4gPj4gPiBQbGVhc2UgY2FuIEkgc3VnZ2VzdCB0 aGF0IHlvdSB3cml0ZSBhbiBpbnRlcm5ldCBkcmFmdCBkZXRhaWxpbmcNCj4gdGhlc2UNCj4gPj4g PiAibWFqb3IgdW5yZXNvbHZlZCB0ZWNobmljYWwgY29uY2VybnMiIHNvIHRoYXQgd2UgY2FuIGFs bA0KPiB1bmRlcnN0YW5kDQo+ID4+ID4gdGhlbS4NCj4gPj4gPg0KPiA+PiA+IFN1Y2ggYSBkcmFm dCBuZWVkcyB0byBiZSB0ZWNobmljYWwsIGFuZCBkZXNjcmliZSB0aGUgYWN0aW9ucyB0aGF0DQo+ IHRoZQ0KPiA+PiA+IG5ldHdvcmsgb3BlcmF0b3IgaXMgdW5hYmxlIHRvIHBlcmZvcm0sIG9yIHRo ZSBmYXVsdCBjYXNlcyB0aGF0DQo+IHRoZXkNCj4gPj4gYXJlDQo+ID4+ID4gdW5hYmxlIHRvIGRp YWdub3NlIHVzaW5nIHRoZSBPQU0gZGVmaW5lZCBpbiB0aGUgSUVURiBSRkNzLCBvciBsYXRlDQo+ ID4+ID4gc3RhZ2UgV0cgZHJhZnRzLg0KPiA+PiA+DQo+ID4+ID4gQWx0ZXJuYXRpdmVseSBpZiB5 b3UgYXJlIHJlZmVycmluZyB0byBhIGJ1ZyBpbiB0aGUgTVBMUy1UUCBPQU0NCj4gPj4gPiBwcm90 b2NvbHMsIHlvdSBuZWVkIHRvIHRlbGwgdGhlIGNvbW11bml0eSB3aGF0IGl0IGlzLg0KPiA+PiA+ DQo+ID4+ID4gSSBiZWxpZXZlIHRoYXQgdGhpcyByZXF1ZXN0IGhhcyBiZWVuIG1hZGUgIGEgbnVt YmVyIG9mIHRpbWVzLCBpbg0KPiA+PiA+IHZhcmlvdXMgZm9ydW1zLCBhbmQsIGFzIGZhciBhcyBJ IGtub3csIG5vIGRvY3VtZW50IGhhcyB5ZXQgYmVlbg0KPiA+PiA+IHByb2R1Y2VkLg0KPiA+PiA+ DQo+ID4+ID4gQW4gYXJndW1lbnQgb2YgdGhlIGZvcm0gInlvdSBtdXN0IHN0YW5kYXJkaXplIHdo YXQgSSB3YW50Ig0KPiA+PiA+IHdpbGwgbm90IGZseS4gV2hhdCBpcyBuZWVkZWQgaXMgYSB2ZXJ5 IGNsZWFyIHRlY2huaWNhbCBkZWZpbml0aW9uDQo+IG9mDQo+ID4+ID4gdGhlIGlzc3VlKHMpLg0K PiA+PiA+DQo+ID4+ID4gV2hlbiB3ZSBoYXZlIHRoZSAibWFqb3IgdW5yZXNvbHZlZCB0ZWNobmlj YWwgY29uY2VybnMiDQo+ID4+ID4gb24gdGhlIHRhYmxlLCB3ZSB3aWxsIGJlIGluIGEgcG9zaXRp b24gdG8gZGV0ZXJtaW5lIHRoZSBiZXN0DQo+ID4+ID4gZGlzcG9zaXRpb24gb2YgdGhvc2UgaXNz dWVzLg0KPiA+PiA+DQo+ID4+ID4gU3Rld2FydA0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPg0KPiA+ PiA+DQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4gLS0NCj4gPj4gPiBGb3IgY29ycG9y YXRlIGxlZ2FsIGluZm9ybWF0aW9uIGdvIHRvOg0KPiA+PiA+DQo+ID4+ID4gaHR0cDovL3d3dy5j aXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sDQo+ ID4+ID4NCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4gUXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBh bGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlDQo+ID4+IGFsbGUNCj4gPj4g PiBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRy YSBhemlvbmUNCj4gPj4gPiBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5m b3JtYXppb25pIHNvbm8NCj4gcmlnb3Jvc2FtZW50ZQ0KPiA+PiA+IHZpZXRhdGUuIFF1YWxvcmEg YWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUNCj4gc2lldGUNCj4g Pj4gPiBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9u ZSBhbCBtaXR0ZW50ZQ0KPiBlDQo+ID4+IGRpDQo+ID4+ID4gcHJvdnZlZGVyZSBhbGxhIHN1YSBk aXN0cnV6aW9uZSwgR3JhemllLg0KPiA+PiA+DQo+ID4+ID4gVGhpcyBlLW1haWwgYW5kIGFueSBh dHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluDQo+ID4+ID4gcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5Lg0KPiA+ PiA+IERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVs c2UgaXMNCj4gPj4gPiB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHBsZWFzZSBkZWxldGUNCj4gPj4gdGhpcw0KPiA+PiA+IG1lc3NhZ2UgYW5kIGFu eSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtDQo+IG1haWws DQo+ID4+ID4gVGhhbmtzLg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+IFRoaXMgZS1t YWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQNCj4gY29u dGFpbnMNCj4gPj4gPiBpbmZvcm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNo IG1heSBiZSBwcm9wcmlldGFyeSB0bw0KPiBFQ0kNCj4gPj4gPiBUZWxlY29tLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlDQo+ID4+IGluZm9y bQ0KPiA+PiA+IHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhl IG9yaWdpbmFsIGFuZCBhbGwNCj4gPj4gY29waWVzDQo+ID4+ID4gdGhlcmVvZi4NCj4gPj4gPg0K PiA+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4+ID4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPj4gPiBtcGxzQGlldGYub3JnDQo+ID4+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IG1wbHMgbWFpbGluZyBs aXN0DQo+ID4+IG1wbHNAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tcGxzDQo+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+bXBscyBtYWlsaW5nIGxpc3QNCj4gPm1wbHNAaWV0Zi5vcmcNCj4gPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+DQo+IA0KDQo= From jdrake@juniper.net Wed Oct 19 14:54:52 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FB221F8B10; Wed, 19 Oct 2011 14:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.161 X-Spam-Level: X-Spam-Status: No, score=-6.161 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, SARE_SUB_ENC_UTF8=0.152] 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 NLvP1CTLQRhQ; Wed, 19 Oct 2011 14:54:51 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 2300421F8B0C; Wed, 19 Oct 2011 14:54:51 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Wed, 19 Oct 2011 14:54:51 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 19 Oct 2011 14:54:36 -0700 From: John E Drake To: "erminio.ottone_69@libero.it" , "brian.e.carpenter@gmail.com" , "yang.jian90@zte.com.cn" Date: Wed, 19 Oct 2011 14:54:35 -0700 Thread-Topic: =?utf-8?B?W21wbHNdIFI6IFJlOiAg562U5aSNOiAg5Zue5aSN77yaICBSOiBGVzogTGFz?= =?utf-8?B?dCBDYWxsOiA8ZHJhZnQtc3ByZWNoZXItbXBscy10cC1vYW0tY29uc2lkZQ==?= =?utf-8?B?cmF0aW9ucy0wMS50eHQ+IChUaGUgUmVhc29ucyBmb3IgU2VsZWN0aW5nIA==?= =?utf-8?B?YSBTaW5nbGUgU29sdXRpb24gZm9yIE1QTFMtVFAgT0FNKSB0byBJbmZvcg==?= =?utf-8?B?bWF0aW9uYWwgUkZD?= Thread-Index: AcyOpA2RXou9f4zaRMOHsJDkZFf+XgABQf/Q Message-ID: <5E893DB832F57341992548CDBB333163A4448A390C@EMBX01-HQ.jnpr.net> References: <28928821.2302421319057359974.JavaMail.defaultUser@defaultHost> In-Reply-To: <28928821.2302421319057359974.JavaMail.defaultUser@defaultHost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-bounces@ietf.orgLarry" , "ietf@ietf.org" Subject: Re: [mpls] =?utf-8?b?UjogUmU6ICDnrZTlpI06ICDlm57lpI3vvJogIFI6IEZXOiBM?= =?utf-8?q?ast_Call=3A_=3Cdraft-sprecher-mpls-tp-oam-considerations-01=2Et?= =?utf-8?q?xt=3E_=28The_Reasons_for_Selecting_a_Single_Solution_for_MPLS-T?= =?utf-8?q?P_OAM=29_to_Informational_RFC?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 21:54:52 -0000 QWxlc3NhbmRybywNCg0KQXBwYXJlbnRseSwgdGhlIGFkdmljZSBnaXZlbiByZWdhcmRpbmcgdGhl IHJpc2tzIGFuZCBjb3N0cyBhc3NvY2lhdGVkIHdpdGggZGVwbG95aW5nIHByb3ByaWV0YXJ5IG9y IHByZS1zdGFuZGFyZCBzb2x1dGlvbnMgZGlkbid0IHJlc29uYXRlIHdpdGggeW91LiAgRG8geW91 IHJlYWxseSBleHBlY3QgdGhlIHJlc3Qgb2YgdXMgdG8gY2xlYW4gdXAgYWZ0ZXIgeW91Pw0KDQpU aGFua3MsDQoNCkpvaG4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBt cGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZg0KPiBlcm1pbmlvLm90dG9uZV82OUBsaWJlcm8uaXQNCj4gU2VudDogV2VkbmVzZGF5 LCBPY3RvYmVyIDE5LCAyMDExIDE6NDkgUE0NCj4gVG86IGJyaWFuLmUuY2FycGVudGVyQGdtYWls LmNvbTsgeWFuZy5qaWFuOTBAenRlLmNvbS5jbg0KPiBDYzogbXBsc0BpZXRmLm9yZzsgbXBscy1i b3VuY2VzQGlldGYub3JnTGFycnk7IGlldGZAaWV0Zi5vcmcNCj4gU3ViamVjdDogW21wbHNdIFI6 IFJlOiDnrZTlpI06IOWbnuWkje+8miBSOiBGVzogTGFzdCBDYWxsOiA8ZHJhZnQtc3ByZWNoZXIt DQo+IG1wbHMtdHAtb2FtLWNvbnNpZGVyYXRpb25zLTAxLnR4dD4gKFRoZSBSZWFzb25zIGZvciBT ZWxlY3RpbmcgYSBTaW5nbGUNCj4gU29sdXRpb24gZm9yIE1QTFMtVFAgT0FNKSB0byBJbmZvcm1h dGlvbmFsIFJGQw0KPiANCj4gSWYgdGhlIE1QTFMgV0cgaGFkIHNlbGVjdGVkIHRoZSBPQU0gc29s dXRpb24gdGhhdCB3YXMgYWxyZWFkeSBleGlzdGluZw0KPiAoYXMNCj4gaW5kaWNhdGVkIG11bHRp cGxlIHRpbWVzIGJ5IHRoZSBvcGVyYXRvcnMgd2hpY2ggaGF2ZSBhbHJlYWR5IG1hc3NpdmVseQ0K PiBkZXBsb3llZA0KPiBpdCksIHdlIHdvdWxkIGhhdmUgaGFkIGEgc2luZ2xlIE9BTSBzb2x1dGlv biBib3RoIGluIHRoZSBtYXJrZXQgYW5kIGluDQo+IHRoZSBJRVRGDQo+IFJGQ3MuDQo+IA0KPiBX ZSBub3cgaGF2ZSAidHdvIiBPQU0gc29sdXRpb25zOiBvbmUgKHdoaWNoIGlzIG5vdCBhY3R1YWxs eSByZWFsbHkNCj4gc2luZ3VsYXIpDQo+IGRvY3VtZW50ZWQgYnkgSUVURiBSRkNzIGFuZCBvbmUg d2lkZWx5IGltcGxlbWVudGVkIGFuZCBkZXBsb3llZC4gVGhpcw0KPiBkcmFmdCBpcw0KPiBub3Qg cmVzb2x2aW5nIHRoaXMgaXNzdWUgYXQgYWxsLg0KPiANCj4gPi0tLS1NZXNzYWdnaW8gb3JpZ2lu YWxlLS0tLQ0KPiA+RGE6IGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbQ0KPiA+RGF0YTogNS1v dHQtMjAxMSAyMi4xNg0KPiA+QTogPHlhbmcuamlhbjkwQHp0ZS5jb20uY24+DQo+ID5DYzogIm1w bHNAaWV0Zi5vcmciPG1wbHNAaWV0Zi5vcmc+LCAiaWV0ZkBpZXRmLm9yZyI8aWV0ZkBpZXRmLm9y Zz4sDQo+IDxtcGxzLQ0KPiBib3VuY2VzQGlldGYub3JnTGFycnk+DQo+ID5PZ2c6IFJlOiBbbXBs c10g562U5aSNOiAg5Zue5aSN77yaICBSOiBGVzogTGFzdCBDYWxsOiAmbHQ7ZHJhZnQtc3ByZWNo ZXItDQo+IG1wbHMtdHAtb2FtLQ0KPiBjb25zaWRlcmF0aW9ucy0wMS50eHQmZ3Q7IChUaGUgUmVh c29ucyBmb3IgU2VsZWN0aW5nIGEgU2luZ2xlIFNvbHV0aW9uDQo+IGZvciBNUExTLQ0KPiBUUCBP QU0pIHRvIEluZm9ybWF0aW9uYWwgUkZDDQo+ID4NCj4gPkhpIEppYW4sDQo+ID4NCj4gPk9uIDIw MTEtMTAtMDYgMDM6NTMsIHlhbmcuamlhbjkwQHp0ZS5jb20uY24gd3JvdGU6DQo+ID4+IERlYXIg QWxsLA0KPiA+Pg0KPiA+PiBJIGRvIG5vdCBzdXBwb3J0IGVpdGhlci4NCj4gPj4NCj4gPj4gSW4g c2VjdGlvbiAzLjU6DQo+ID4+IElmIHR3byBNUExTIE9BTSBwcm90b2NvbHMgd2VyZSB0byBiZSBk ZXBsb3llZCB3ZSB3b3VsZCBoYXZlIHRvDQo+IGNvbnNpZGVyDQo+ID4+IHRocmVlIHBvc3NpYmxl IHNjZW5hcmlvczoNCj4gPj4gMSkgSXNvbGF0aW9uIG9mIHRoZSBuZXR3b3JrIGludG8gdHdvIGlu Y29tcGF0aWJsZSBhbmQgdW5jb25uZWN0ZWQNCj4gaXNsYW5kcy4NCj4gPj4NCj4gPj4gVHdvIE9B TSBzb2x1dGlvbnMgaGF2ZSBiZWVuIGRpc2N1c3NlZCBmb3IgYSBsb25nIHRpbWUgaW4gYm90aCBJ VFUtVA0KPiBhbmQNCj4gPj4gSUVURi4NCj4gPj4gRWFjaCBzb2x1dGlvbiBoYXMgdGhlaXIgb3du IHN1cHBvcnRlcnMgaW5jdWxkaW5nIGNhcnJpZXJzIGFuZA0KPiB2ZW5kb3JzLg0KPiA+PiBTbyBJ IGRvbid0IHRoaW5rIHRoZXJlIGlzIGFueSBpbnRlcndvcmtpbmcgaXNzdWUgYmV0d2VlbiB0d28g T0FNDQo+IHNvbHV0aW9ucy4NCj4gPj4gQ2FycmllciB3aWxsIHNlbGVjdCBvbmUgT0FNIHNvbHV0 aW9uLCBBIG9yIEIsIGluIHRoZWlyIG5ldHdvcmsuDQo+ID4+IE5vIG5lZWQgdG8gc2VsZWN0IEEg YW5kIEIgYXQgb25lIG5ldHdvcmsgYXQgdGhlIHNhbWUgdGltZS4NCj4gPg0KPiA+VGhlcmUgYXJl IHR3byBsYXJnZSBjb3N0cyB0aGF0IHlvdSBhcmUgaWdub3Jpbmc6DQo+ID4NCj4gPmEpIGFsbCB2 ZW5kb3JzIHdpc2hpbmcgdG8gYmlkIGZvciBidXNpbmVzcyBmcm9tIEEgYW5kIEIgd2lsbCBoYXZl IHRvDQo+ID4gICBpbXBsZW1lbnQgYW5kIHN1cHBvcnQgYm90aCBzb2x1dGlvbnMuDQo+ID4NCj4g PmIpIHdoZW4gQSBidXlzIEIgb3IgQiBidXlzIEEsIHRoZSBpbmNvbXBhdGlibGUgbmV0d29ya3Mg d2lsbCBoYXZlIHRvDQo+ID4gICBiZSBtZXJnZWQuDQo+ID4NCj4gPlRoZXNlIGFyZSBjb3N0cyB0 aGF0IHJ1biB0byBodW5kcmVkcyBvZiBtaWxsaW9ucyBvZiBVU0QsIEVVUiBvciBDTlkuDQo+ID5U aGV5IGFyZSBjb3N0cyBjYXVzZWQgZGlyZWN0bHkgYnkgU0RPcyBjcmVhdGluZyByaXZhbCBzb2x1 dGlvbnMuDQo+ID4NCj4gPkkgdGhpbmsgaXQgd291bGQgYmUgaXJyZXNwb25zaWJsZSBvZiB0aGUg SUVURiBub3QgdG8gZG9jdW1lbnQgdGhpcw0KPiA+c2l0dWF0aW9uLiBBcyBlbmdpbmVlcnMsIHdl IGhhdmUgYW4gZXRoaWNhbCByZXNwb25zaWJpbGl0eSBoZXJlLg0KPiA+DQo+ID4gICAgQnJpYW4N Cj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID5t cGxzIG1haWxpbmcgbGlzdA0KPiA+bXBsc0BpZXRmLm9yZw0KPiA+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4NCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtcGxzIG1haWxpbmcgbGlzdA0KPiBt cGxzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cw0K From jaiharik@ipinfusion.com Thu Oct 20 00:21:17 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB39E11E8093; Thu, 20 Oct 2011 00:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 h-3dv2R1LOfF; Thu, 20 Oct 2011 00:21:07 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3623311E8086; Thu, 20 Oct 2011 00:21:07 -0700 (PDT) Received: by wwe6 with SMTP id 6so2556105wwe.13 for ; Thu, 20 Oct 2011 00:20:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.208.20 with SMTP id ga20mr3575297wbb.10.1319095246047; Thu, 20 Oct 2011 00:20:46 -0700 (PDT) Received: by 10.180.95.166 with HTTP; Thu, 20 Oct 2011 00:20:46 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Oct 2011 12:50:46 +0530 Message-ID: From: Jaihari Kalijanakiraman To: zhang.fei3@zte.com.cn Content-Type: multipart/alternative; boundary=0015174bdc8490cbac04afb5cb71 Cc: "mpls@ietf.org" , "ccamp@ietf.org" Subject: Re: [mpls] mpls Digest, Vol 90, Issue 22 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 07:21:17 -0000 --0015174bdc8490cbac04afb5cb71 Content-Type: text/plain; charset=ISO-8859-1 Hi Zhang, I have a question. The connection object in the draft has only destination tunnel number. But as per TP Identifiers RFC 6370, 5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}:: Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num} So I think the connection object should also include the destination LSP number also. Please comment.. *Thanks & Regards,* *Jai Hari M.K. IP Infusion* > Date: Mon, 17 Oct 2011 19:08:51 +0800 > From: zhang.fei3@zte.com.cn > To: "ccamp@ietf.org" , "mpls@ietf.org" > Subject: [mpls] Request comments on > draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00 > Message-ID: > < > OF3E7FD488.405BF0C5-ON4825792C.00351CBE-4825792C.003D3BA7@zte.com.cn> > Content-Type: text/plain; charset="us-ascii" > > Hi all > > We've submitted a draft for the group's consideration, below is the link: > > http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00 > . > > This draft is about the supporting of MPLS-TP Maintenance Identifiers. As > described in http://tools.ietf.org/html/rfc6370, at each end point, a > tunnel is uniquely identified by the end point's Node_ID and a locally > assigned tunnel number, which allow a compact form for the MEP_ID, and > extensions will be required to GMPLS to support these identifiers. > Furthermore, http://tools.ietf.org/html/rfc6373 addressed this issue in > section 4.4.8. > > Obviously, this issue can be solved by defining a new object, such as > Connection Object as described in this draft, or a new sub-TLV call MEP_ID > can be carried back to the ingress LSR in Resv message when the "CV" flag > of the OAM Function Flags Sub-TLV is set, which may be considered in the > subsequent version of the draft > http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-06. > > We hope you'll find the time to look through the draft and comment on the > list, help judge which way is more suitable before the WG meeting in > Taipei, and hope that we'll be able to have a fruitful and lively > discussion there. > > > Best, > > Fei > --0015174bdc8490cbac04afb5cb71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Zhang,

I have a= question.

The connection object in the draft has = only destination tunnel number.

But as per TP Iden= tifiers RFC 6370,


5.2.2.  MPLS-TP Associated Bidirectional LSP =
Identifiers
A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}:: Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}

So I think the connection object sho= uld also include the destination LSP number also.

= Please comment..


Thanks & Regards,
Jai Hari M.K.IP Infusion

=A0
Date: Mon, 17 Oct 2011 19:08:51 +0800
From: zhang.fei3@zte.com.cn To: "ccamp@ietf.org" <ccamp@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Subject: [mpls] Request comments on
=A0 =A0 =A0 =A0draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00
Message-ID:
=A0 =A0 =A0 =A0<OF3E7FD488.405BF0C5-ON4825792C.00351CBE-48= 25792C.003D3BA7@zte.com.cn>
Content-Type: text/plain; charset=3D"us-ascii"

Hi all

We've submitted a draft for the group's consideration, below is the= link:
http://tools.ietf.org/html/draft-zhang-cca= mp-mpls-tp-rsvpte-ext-tunnel-num-00.

This draft is about the supporting of MPLS-TP Maintenance Identifiers. As described in http://tools.ietf.org/html/rfc6370, at each end point, a
tunnel is uniquely identified by the end point's Node_ID and a locally<= br> assigned tunnel number, which allow a compact form for the MEP_ID, and
extensions will be required to GMPLS to support these identifiers.
Furthermore, http://tools.ietf.org/html/rfc6373 addressed this issue in
section 4.4.8.

Obviously, this issue can be solved by defining a new object, such as
Connection Object as described in this draft, or a new sub-TLV call MEP_ID<= br> can be carried back to the ingress LSR in Resv message when the "CV&qu= ot; flag
of the OAM Function Flags Sub-TLV is set, which may be considered in the subsequent version of the draft
http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-= te-mpls-tp-oam-ext-06.

We hope you'll find the time to look through the draft and comment on t= he
list, help judge which way is more suitable before the WG meeting in
Taipei, and hope that we'll be able to have a fruitful and lively
discussion there.


Best,

Fei
--0015174bdc8490cbac04afb5cb71-- From jaiharik@ipinfusion.com Thu Oct 20 00:22:56 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0FB21F84CC for ; Thu, 20 Oct 2011 00:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 msw+CSTHIzXk for ; Thu, 20 Oct 2011 00:22:52 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7417D21F84CB for ; Thu, 20 Oct 2011 00:22:52 -0700 (PDT) Received: by wyh22 with SMTP id 22so2851963wyh.31 for ; Thu, 20 Oct 2011 00:22:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.38.144 with SMTP id b16mr2349214wbe.10.1319095371430; Thu, 20 Oct 2011 00:22:51 -0700 (PDT) Received: by 10.180.95.166 with HTTP; Thu, 20 Oct 2011 00:22:51 -0700 (PDT) Date: Thu, 20 Oct 2011 12:52:51 +0530 Message-ID: From: Jaihari Kalijanakiraman To: zhang.fei3@zte.com.cn Content-Type: multipart/alternative; boundary=0022159753be09fd4904afb5d37c Cc: "mpls@ietf.org" Subject: Re: [mpls] Request comments on draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 07:22:56 -0000 --0022159753be09fd4904afb5d37c Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 20, 2011 at 12:50 PM, Jaihari Kalijanakiraman < jaiharik@ipinfusion.com> wrote: > Hi Zhang, > > I have a question. > > The connection object in the draft has only destination tunnel number. > > But as per TP Identifiers RFC 6370, > > 5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers > > A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}:: > Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num} > > > So I think the connection object should also include the destination LSP > number also. > > Please comment.. > > > *Thanks & Regards,* > *Jai Hari M.K. > IP Infusion* > > > >> Date: Mon, 17 Oct 2011 19:08:51 +0800 >> From: zhang.fei3@zte.com.cn >> To: "ccamp@ietf.org" , "mpls@ietf.org" >> Subject: [mpls] Request comments on >> draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00 >> Message-ID: >> < >> OF3E7FD488.405BF0C5-ON4825792C.00351CBE-4825792C.003D3BA7@zte.com.cn> >> Content-Type: text/plain; charset="us-ascii" >> >> Hi all >> >> We've submitted a draft for the group's consideration, below is the link: >> >> http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00 >> . >> >> This draft is about the supporting of MPLS-TP Maintenance Identifiers. As >> described in http://tools.ietf.org/html/rfc6370, at each end point, a >> tunnel is uniquely identified by the end point's Node_ID and a locally >> assigned tunnel number, which allow a compact form for the MEP_ID, and >> extensions will be required to GMPLS to support these identifiers. >> Furthermore, http://tools.ietf.org/html/rfc6373 addressed this issue in >> section 4.4.8. >> >> Obviously, this issue can be solved by defining a new object, such as >> Connection Object as described in this draft, or a new sub-TLV call MEP_ID >> can be carried back to the ingress LSR in Resv message when the "CV" flag >> of the OAM Function Flags Sub-TLV is set, which may be considered in the >> subsequent version of the draft >> http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-06. >> >> We hope you'll find the time to look through the draft and comment on the >> list, help judge which way is more suitable before the WG meeting in >> Taipei, and hope that we'll be able to have a fruitful and lively >> discussion there. >> >> >> Best, >> >> Fei >> > --0022159753be09fd4904afb5d37c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Oct 20, 2011 at 12:50 PM, Jaihar= i Kalijanakiraman <jaiharik@ipinfusion.com> wrote:
Hi Zhang,

I have a= question.

The connection object in the draft has = only destination tunnel number.

But as per TP Iden= tifiers RFC 6370,



5.2.2.  MPLS-TP Associated B=
idirectional LSP Identifiers
      A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}::
      Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}

So I think the connection object sho= uld also include the destination LSP number also.

= Please comment..


Thanks & Regards,
Jai Hari M.K.
IP Infusion

=A0
Date: Mon, 17 Oct 2011 19:08:51 +0800
From: zhang.fei3= @zte.com.cn
To: "ccamp@ietf.or= g" <ccamp@i= etf.org>, "m= pls@ietf.org" <mpls@ietf.org>
Subject: [mpls] Request comments on
=A0 =A0 =A0 =A0draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00
Message-ID:
=A0 =A0 =A0 =A0<OF3E7FD488.405BF0C5-ON48= 25792C.00351CBE-4825792C.003D3BA7@zte.com.cn>
Content-Type: text/plain; charset=3D"us-ascii"

Hi all

We've submitted a draft for the group's consideration, below is the= link:
http://tools.ietf.org/html/draft-zhang-cca= mp-mpls-tp-rsvpte-ext-tunnel-num-00.

This draft is about the supporting of MPLS-TP Maintenance Identifiers. As described in http://tools.ietf.org/html/rfc6370, at each end point, a
tunnel is uniquely identified by the end point's Node_ID and a locally<= br> assigned tunnel number, which allow a compact form for the MEP_ID, and
extensions will be required to GMPLS to support these identifiers.
Furthermore, http://tools.ietf.org/html/rfc6373 addressed this issue in
section 4.4.8.

Obviously, this issue can be solved by defining a new object, such as
Connection Object as described in this draft, or a new sub-TLV call MEP_ID<= br> can be carried back to the ingress LSR in Resv message when the "CV&qu= ot; flag
of the OAM Function Flags Sub-TLV is set, which may be considered in the subsequent version of the draft
http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-= te-mpls-tp-oam-ext-06.

We hope you'll find the time to look through the draft and comment on t= he
list, help judge which way is more suitable before the WG meeting in
Taipei, and hope that we'll be able to have a fruitful and lively
discussion there.


Best,

Fei

--0022159753be09fd4904afb5d37c-- From zhang.fei3@zte.com.cn Thu Oct 20 06:29:44 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0216921F8AEA; Thu, 20 Oct 2011 06:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.665 X-Spam-Level: X-Spam-Status: No, score=-98.665 tagged_above=-999 required=5 tests=[AWL=-1.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOQ1Ca+P3Q3S; Thu, 20 Oct 2011 06:29:43 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2AA21F8672; Thu, 20 Oct 2011 06:29:42 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 466211279682118; Thu, 20 Oct 2011 21:22:53 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 20387.3010951596; Thu, 20 Oct 2011 21:29:27 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p9KDTJkr089936; Thu, 20 Oct 2011 21:29:19 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: Jaihari Kalijanakiraman MIME-Version: 1.0 X-KeepSent: 40A7AEF2:F74D2D2D-4825792F:004801B6; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Thu, 20 Oct 2011 21:29:14 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-20 21:29:21, Serialize complete at 2011-10-20 21:29:21 Content-Type: multipart/alternative; boundary="=_alternative 004A154E4825792F_=" X-MAIL: mse01.zte.com.cn p9KDTJkr089936 Cc: "mpls@ietf.org" , "ccamp@ietf.org" Subject: Re: [mpls] Request comments on draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 13:29:44 -0000 This is a multipart message in MIME format. --=_alternative 004A154E4825792F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgSmFpaGFyaQ0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIDotKQ0KDQpUaGlzIGRyYWZ0 IGlzIGFib3V0IGhvdyB0byBjYXJyeSB0aGUgbG9jYWwgYXNzaWduZWQgdHVubmVsIG51bWJlciBv ZiANCmNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUCwgc29ycnkgSSBkbyBub3QgZGVzY3JpYmUg aXQgY2xlYXJseSBpbiB0aGUgDQptYWlsLg0KDQpBY2NvcmRpbmcgdG8gdGhlIGRlc2NyaXB0aW9u IGluIHNlY3Rpb24gNS4yLjEgb2YgdGhlIFJGQzYzNzAsIHRoZSBMU1AgDQpudW1iZXIga2VlcHMg dGhlIHNhbWUgdW5kZXIgdGhlIGNvbnRleHQgb2YgQTEgYW5kIFo5J3MgdHVubmVsIG51bWJlcnM6 IA0KDQpBMS17Tm9kZV9JRDo6VHVubmVsX051bX06Olo5LXtOb2RlX0lEOjpUdW5uZWxfTnVtfTo6 TFNQX051bQ0KDQpTbyBvbmx5IHRoZSB0dW5uZWwgbnVtYmVyIGFzc2lnbmVkIGJ5IHRoZSBkZXN0 aW5hdGlvbiBub2RlIGlzIG1pc3NpbmcuIA0KDQpBcyB0byB0aGUgYXNzb2NpYXRlZCBiaWRpcmVj dGlvbmFsIExTUCwgdGhlcmUgYXJlIHR3byBpbmRlcGVuZGVudCANCnNpZ25hbGluZyBwcm9jZWR1 cmVzIGZvciB0aGUgZm9yd2FyZCBhbmQgYmFja3dhcmQgZGlyZWN0aW9uYWwgTFNQcywgYW5kIA0K dGhlIEExIGFuZCBaOQ0Ka25vdyBlYWNoIG90aGVyIHRoZSBhc3NpZ25lZCB0dW5uZWwgbnVtYmVy IGFuZCBMU1AgbnVtYmVyLg0KDQpGdXJ0aGVybW9yZSwgdGhlIEdsb2JhbF9JRCBpcyBhbHNvIG5l ZWRlZCBpZiB0aGUgTFNQIGlzIGFjcm9zcyBkaWZmZXJlbnQgDQpBU3MsIHdoaWNoIG1heSBiZSBh ZGRlZCBpbiBuZXh0IHZlcnNpb24uDQoNCllvdXIgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCkJl c3QgcmVnYXJkcw0KDQpGZWkNCg0KDQoNCkphaWhhcmkgS2FsaWphbmFraXJhbWFuIDxqYWloYXJp a0BpcGluZnVzaW9uLmNvbT4gDQoyMDExLTEwLTIwIDE1OjIyDQoNCsrVvP7Iyw0KemhhbmcuZmVp M0B6dGUuY29tLmNuDQqzrcvNDQoibXBsc0BpZXRmLm9yZyIgPG1wbHNAaWV0Zi5vcmc+DQrW98zi DQpSZTogW21wbHNdIFJlcXVlc3QgY29tbWVudHMgb24gDQpkcmFmdC16aGFuZy1jY2FtcC1tcGxz LXRwLXJzdnB0ZS1leHQtdHVubmVsLW51bS0wMA0KDQoNCg0KDQoNCg0KDQoNCk9uIFRodSwgT2N0 IDIwLCAyMDExIGF0IDEyOjUwIFBNLCBKYWloYXJpIEthbGlqYW5ha2lyYW1hbiA8DQpqYWloYXJp a0BpcGluZnVzaW9uLmNvbT4gd3JvdGU6DQpIaSBaaGFuZywNCg0KSSBoYXZlIGEgcXVlc3Rpb24u DQoNClRoZSBjb25uZWN0aW9uIG9iamVjdCBpbiB0aGUgZHJhZnQgaGFzIG9ubHkgZGVzdGluYXRp b24gdHVubmVsIG51bWJlci4NCg0KQnV0IGFzIHBlciBUUCBJZGVudGlmaWVycyBSRkMgNjM3MCwN Cg0KDQoNCjUuMi4yLiAgTVBMUy1UUCBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQIElkZW50 aWZpZXJzDQoNCiAgICAgIEExLXtHbG9iYWxfSUQ6Ok5vZGVfSUQ6OlR1bm5lbF9OdW06OkxTUF9O dW19OjoNCiAgICAgIFo5LXtHbG9iYWxfSUQ6Ok5vZGVfSUQ6OlR1bm5lbF9OdW06OkxTUF9OdW19 DQoNCg0KU28gSSB0aGluayB0aGUgY29ubmVjdGlvbiBvYmplY3Qgc2hvdWxkIGFsc28gaW5jbHVk ZSB0aGUgZGVzdGluYXRpb24gTFNQIA0KbnVtYmVyIGFsc28uDQoNClBsZWFzZSBjb21tZW50Li4N Cg0KDQpUaGFua3MgJiBSZWdhcmRzLA0KSmFpIEhhcmkgTS5LLg0KSVAgSW5mdXNpb24NCg0KIA0K RGF0ZTogTW9uLCAxNyBPY3QgMjAxMSAxOTowODo1MSArMDgwMA0KRnJvbTogemhhbmcuZmVpM0B6 dGUuY29tLmNuDQpUbzogImNjYW1wQGlldGYub3JnIiA8Y2NhbXBAaWV0Zi5vcmc+LCAibXBsc0Bp ZXRmLm9yZyIgPG1wbHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbbXBsc10gUmVxdWVzdCBjb21tZW50 cyBvbg0KICAgICAgIGRyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10dW5uZWwt bnVtLTAwDQpNZXNzYWdlLUlEOg0KICAgICAgIDwNCk9GM0U3RkQ0ODguNDA1QkYwQzUtT040ODI1 NzkyQy4wMDM1MUNCRS00ODI1NzkyQy4wMDNEM0JBN0B6dGUuY29tLmNuPg0KQ29udGVudC1UeXBl OiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSINCg0KSGkgYWxsDQoNCldlJ3ZlIHN1Ym1p dHRlZCBhIGRyYWZ0IGZvciB0aGUgZ3JvdXAncyBjb25zaWRlcmF0aW9uLCBiZWxvdyBpcyB0aGUg bGluazoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLWNjYW1wLW1wbHMt dHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtLTAwDQouDQoNClRoaXMgZHJhZnQgaXMgYWJvdXQgdGhl IHN1cHBvcnRpbmcgb2YgTVBMUy1UUCBNYWludGVuYW5jZSBJZGVudGlmaWVycy4gQXMNCmRlc2Ny aWJlZCBpbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MzcwLCBhdCBlYWNoIGVuZCBw b2ludCwgYQ0KdHVubmVsIGlzIHVuaXF1ZWx5IGlkZW50aWZpZWQgYnkgdGhlIGVuZCBwb2ludCdz IE5vZGVfSUQgYW5kIGEgbG9jYWxseQ0KYXNzaWduZWQgdHVubmVsIG51bWJlciwgd2hpY2ggYWxs b3cgYSBjb21wYWN0IGZvcm0gZm9yIHRoZSBNRVBfSUQsIGFuZA0KZXh0ZW5zaW9ucyB3aWxsIGJl IHJlcXVpcmVkIHRvIEdNUExTIHRvIHN1cHBvcnQgdGhlc2UgaWRlbnRpZmllcnMuDQpGdXJ0aGVy bW9yZSwgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjM3MyBhZGRyZXNzZWQgdGhpcyBp c3N1ZSBpbg0Kc2VjdGlvbiA0LjQuOC4NCg0KT2J2aW91c2x5LCB0aGlzIGlzc3VlIGNhbiBiZSBz b2x2ZWQgYnkgZGVmaW5pbmcgYSBuZXcgb2JqZWN0LCBzdWNoIGFzDQpDb25uZWN0aW9uIE9iamVj dCBhcyBkZXNjcmliZWQgaW4gdGhpcyBkcmFmdCwgb3IgYSBuZXcgc3ViLVRMViBjYWxsIE1FUF9J RA0KY2FuIGJlIGNhcnJpZWQgYmFjayB0byB0aGUgaW5ncmVzcyBMU1IgaW4gUmVzdiBtZXNzYWdl IHdoZW4gdGhlICJDViIgZmxhZw0Kb2YgdGhlIE9BTSBGdW5jdGlvbiBGbGFncyBTdWItVExWIGlz IHNldCwgd2hpY2ggbWF5IGJlIGNvbnNpZGVyZWQgaW4gdGhlDQpzdWJzZXF1ZW50IHZlcnNpb24g b2YgdGhlIGRyYWZ0DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNjYW1w LXJzdnAtdGUtbXBscy10cC1vYW0tZXh0LTA2Lg0KDQpXZSBob3BlIHlvdSdsbCBmaW5kIHRoZSB0 aW1lIHRvIGxvb2sgdGhyb3VnaCB0aGUgZHJhZnQgYW5kIGNvbW1lbnQgb24gdGhlDQpsaXN0LCBo ZWxwIGp1ZGdlIHdoaWNoIHdheSBpcyBtb3JlIHN1aXRhYmxlIGJlZm9yZSB0aGUgV0cgbWVldGlu ZyBpbg0KVGFpcGVpLCBhbmQgaG9wZSB0aGF0IHdlJ2xsIGJlIGFibGUgdG8gaGF2ZSBhIGZydWl0 ZnVsIGFuZCBsaXZlbHkNCmRpc2N1c3Npb24gdGhlcmUuDQoNCg0KQmVzdCwNCg0KRmVpDQoNCg0K --=_alternative 004A154E4825792F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkhpIEphaWhhcmk8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgeW91ciBj b21tZW50cy4gOi0pPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj5UaGlzIGRyYWZ0IGlzIGFib3V0IGhvdyB0byBjYXJyeSB0aGUNCmxvY2FsIGFzc2lnbmVk IHR1bm5lbCBudW1iZXIgb2YgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQLCBzb3JyeSBJIGRv DQpub3QgZGVzY3JpYmUgaXQgY2xlYXJseSBpbiB0aGUgbWFpbC48L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkFjY29yZGluZyB0byB0aGUgZGVzY3JpcHRp b24gaW4gc2VjdGlvbg0KNS4yLjEgb2YgdGhlIFJGQzYzNzAsIHRoZSBMU1AgbnVtYmVyIGtlZXBz IHRoZSBzYW1lIHVuZGVyIHRoZSBjb250ZXh0IG9mDQpBMSBhbmQgWjkncyB0dW5uZWwgbnVtYmVy czogPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5BMS17 Tm9kZV9JRDo6VHVubmVsX051bX06Olo5LXtOb2RlX0lEOjpUdW5uZWxfTnVtfTo6TFNQX051bTxi cj4NCjxicj4NClNvIG9ubHkgdGhlIHR1bm5lbCBudW1iZXIgYXNzaWduZWQgYnkgdGhlIGRlc3Rp bmF0aW9uIG5vZGUgaXMgbWlzc2luZy4NCjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+QXMgdG8gdGhlIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1As DQp0aGVyZSBhcmUgdHdvIGluZGVwZW5kZW50IHNpZ25hbGluZyBwcm9jZWR1cmVzIGZvciB0aGUg Zm9yd2FyZCBhbmQgYmFja3dhcmQNCmRpcmVjdGlvbmFsIExTUHMsIGFuZCB0aGUgQTEgYW5kIFo5 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5rbm93IGVhY2ggb3Ro ZXIgdGhlIGFzc2lnbmVkIHR1bm5lbA0KbnVtYmVyIGFuZCBMU1AgbnVtYmVyLjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+RnVydGhlcm1vcmUsIHRoZSBH bG9iYWxfSUQgaXMgYWxzbyBuZWVkZWQNCmlmIHRoZSBMU1AgaXMgYWNyb3NzIGRpZmZlcmVudCBB U3MsIHdoaWNoIG1heSBiZSBhZGRlZCBpbiBuZXh0IHZlcnNpb24uPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5Zb3VyIGNvbW1lbnRzIGFyZSB3ZWxjb21l LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+QmVzdCBy ZWdhcmRzPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5G ZWk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+ SmFpaGFyaSBLYWxpamFuYWtpcmFtYW4NCiZsdDtqYWloYXJpa0BpcGluZnVzaW9uLmNvbSZndDs8 L2I+IDwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLTEwLTIw IDE1OjIyPC9mb250Pg0KPHRkIHdpZHRoPTYzJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPnpoYW5nLmZlaTNAenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7bXBs c0BpZXRmLm9yZyZxdW90OyAmbHQ7bXBsc0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PlJlOiBbbXBsc10gUmVxdWVzdCBjb21tZW50cyBvbiBkcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRw LXJzdnB0ZS1leHQtdHVubmVsLW51bS0wMDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0K PGJyPg0KPGJyPjxmb250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPk9u IFRodSwgT2N0IDIwLCAyMDExIGF0IDEyOjUwIFBNLCBKYWloYXJpIEthbGlqYW5ha2lyYW1hbg0K Jmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpqYWloYXJpa0BpcGluZnVzaW9uLmNvbT48Zm9udCBz aXplPTMgY29sb3I9Ymx1ZT48dT5qYWloYXJpa0BpcGluZnVzaW9uLmNvbTwvdT48L2ZvbnQ+PC9h Pjxmb250IHNpemU9Mz4mZ3Q7DQp3cm90ZTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPkhpIFpo YW5nLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+SSBoYXZlIGEgcXVlc3Rpb24uPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5UaGUgY29ubmVjdGlvbiBvYmplY3QgaW4gdGhl IGRyYWZ0IGhhcyBvbmx5IGRlc3RpbmF0aW9uDQp0dW5uZWwgbnVtYmVyLjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTM+QnV0IGFzIHBlciBUUCBJZGVudGlmaWVycyBSRkMgNjM3MCw8L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGI+PGJy Pg0KPGJyPg0KNS4yLjIuICZuYnNwO01QTFMtVFAgQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExT UCBJZGVudGlmaWVyczwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7QTEte0dsb2JhbF9JRDo6Tm9kZV9J RDo6VHVubmVsX051bTo6TFNQX051bX06Ojxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO1o5LXtH bG9iYWxfSUQ6Ok5vZGVfSUQ6OlR1bm5lbF9OdW06OkxTUF9OdW19PGJyPg0KPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9Mz5TbyBJIHRoaW5rIHRoZSBjb25uZWN0aW9uIG9iamVjdCBzaG91 bGQgYWxzbyBpbmNsdWRlIHRoZQ0KZGVzdGluYXRpb24gTFNQIG51bWJlciBhbHNvLjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTM+UGxlYXNlIGNvbW1lbnQuLjwvZm9udD4NCjxicj4NCjxi cj4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9Izk5OTk5OT48aT5UaGFua3MgJmFtcDsgUmVnYXJk cyw8L2k+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj0jOTk5OTk5PjxpPkphaSBIYXJp IE0uSy48YnI+DQpJUCBJbmZ1c2lvbjwvaT48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0z PiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+RGF0ZTogTW9uLCAxNyBPY3QgMjAxMSAx OTowODo1MSArMDgwMDxicj4NCkZyb206IDwvZm9udD48YSBocmVmPW1haWx0bzp6aGFuZy5mZWkz QHp0ZS5jb20uY24gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT56aGFu Zy5mZWkzQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+PGJyPg0KVG86ICZx dW90OzwvZm9udD48YSBocmVmPW1haWx0bzpjY2FtcEBpZXRmLm9yZyB0YXJnZXQ9X2JsYW5rPjxm b250IHNpemU9MyBjb2xvcj1ibHVlPjx1PmNjYW1wQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZv bnQgc2l6ZT0zPiZxdW90Ow0KJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpjY2FtcEBpZXRmLm9y ZyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1PmNjYW1wQGlldGYub3Jn PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPiZndDssDQomcXVvdDs8L2ZvbnQ+PGEgaHJlZj1t YWlsdG86bXBsc0BpZXRmLm9yZyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVl Pjx1Pm1wbHNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+JnF1b3Q7DQombHQ7 PC9mb250PjxhIGhyZWY9bWFpbHRvOm1wbHNAaWV0Zi5vcmcgdGFyZ2V0PV9ibGFuaz48Zm9udCBz aXplPTMgY29sb3I9Ymx1ZT48dT5tcGxzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6 ZT0zPiZndDs8YnI+DQpTdWJqZWN0OiBbbXBsc10gUmVxdWVzdCBjb21tZW50cyBvbjxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRl LWV4dC10dW5uZWwtbnVtLTAwPGJyPg0KTWVzc2FnZS1JRDo8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmbHQ7PC9mb250PjxhIGhyZWY9Im1haWx0bzpPRjNFN0ZENDg4LjQwNUJGMEM1 LU9ONDgyNTc5MkMuMDAzNTFDQkUtNDgyNTc5MkMuMDAzRDNCQTdAenRlLmNvbS5jbiIgdGFyZ2V0 PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5PRjNFN0ZENDg4LjQwNUJGMEM1LU9O NDgyNTc5MkMuMDAzNTFDQkUtNDgyNTc5MkMuMDAzRDNCQTdAenRlLmNvbS5jbjwvdT48L2ZvbnQ+ PC9hPjxmb250IHNpemU9Mz4mZ3Q7PGJyPg0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PSZxdW90O3VzLWFzY2lpJnF1b3Q7PGJyPg0KPGJyPg0KSGkgYWxsPGJyPg0KPGJyPg0KV2Un dmUgc3VibWl0dGVkIGEgZHJhZnQgZm9yIHRoZSBncm91cCdzIGNvbnNpZGVyYXRpb24sIGJlbG93 IGlzIHRoZSBsaW5rOjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT48YnI+DQo8L3U+ PC9mb250PjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLWNj YW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtLTAwIiB0YXJnZXQ9X2JsYW5rPjxmb250 IHNpemU9MyBjb2xvcj1ibHVlPjx1Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpo YW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtLTAwPC91PjwvZm9udD48L2E+ PGZvbnQgc2l6ZT0zPi48YnI+DQo8YnI+DQpUaGlzIGRyYWZ0IGlzIGFib3V0IHRoZSBzdXBwb3J0 aW5nIG9mIE1QTFMtVFAgTWFpbnRlbmFuY2UgSWRlbnRpZmllcnMuDQpBczxicj4NCmRlc2NyaWJl ZCBpbiA8L2ZvbnQ+PGEgaHJlZj1odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MzcwIHRh cmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+aHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNjM3MDwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz4sDQphdCBlYWNoIGVu ZCBwb2ludCwgYTxicj4NCnR1bm5lbCBpcyB1bmlxdWVseSBpZGVudGlmaWVkIGJ5IHRoZSBlbmQg cG9pbnQncyBOb2RlX0lEIGFuZCBhIGxvY2FsbHk8YnI+DQphc3NpZ25lZCB0dW5uZWwgbnVtYmVy LCB3aGljaCBhbGxvdyBhIGNvbXBhY3QgZm9ybSBmb3IgdGhlIE1FUF9JRCwgYW5kPGJyPg0KZXh0 ZW5zaW9ucyB3aWxsIGJlIHJlcXVpcmVkIHRvIEdNUExTIHRvIHN1cHBvcnQgdGhlc2UgaWRlbnRp ZmllcnMuPGJyPg0KRnVydGhlcm1vcmUsIDwvZm9udD48YSBocmVmPWh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzYzNzMgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48 dT5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MzczPC91PjwvZm9udD48L2E+PGZvbnQg c2l6ZT0zPg0KYWRkcmVzc2VkIHRoaXMgaXNzdWUgaW48YnI+DQpzZWN0aW9uIDQuNC44Ljxicj4N Cjxicj4NCk9idmlvdXNseSwgdGhpcyBpc3N1ZSBjYW4gYmUgc29sdmVkIGJ5IGRlZmluaW5nIGEg bmV3IG9iamVjdCwgc3VjaCBhczxicj4NCkNvbm5lY3Rpb24gT2JqZWN0IGFzIGRlc2NyaWJlZCBp biB0aGlzIGRyYWZ0LCBvciBhIG5ldyBzdWItVExWIGNhbGwgTUVQX0lEPGJyPg0KY2FuIGJlIGNh cnJpZWQgYmFjayB0byB0aGUgaW5ncmVzcyBMU1IgaW4gUmVzdiBtZXNzYWdlIHdoZW4gdGhlICZx dW90O0NWJnF1b3Q7DQpmbGFnPGJyPg0Kb2YgdGhlIE9BTSBGdW5jdGlvbiBGbGFncyBTdWItVExW IGlzIHNldCwgd2hpY2ggbWF5IGJlIGNvbnNpZGVyZWQgaW4gdGhlPGJyPg0Kc3Vic2VxdWVudCB2 ZXJzaW9uIG9mIHRoZSBkcmFmdDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT48YnI+ DQo8L3U+PC9mb250PjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtY2NhbXAtcnN2cC10ZS1tcGxzLXRwLW9hbS1leHQtMDYiIHRhcmdldD1fYmxhbms+PGZvbnQg c2l6ZT0zIGNvbG9yPWJsdWU+PHU+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1jY2FtcC1yc3ZwLXRlLW1wbHMtdHAtb2FtLWV4dC0wNjwvdT48L2ZvbnQ+PC9hPjxmb250IHNp emU9Mz4uPGJyPg0KPGJyPg0KV2UgaG9wZSB5b3UnbGwgZmluZCB0aGUgdGltZSB0byBsb29rIHRo cm91Z2ggdGhlIGRyYWZ0IGFuZCBjb21tZW50IG9uIHRoZTxicj4NCmxpc3QsIGhlbHAganVkZ2Ug d2hpY2ggd2F5IGlzIG1vcmUgc3VpdGFibGUgYmVmb3JlIHRoZSBXRyBtZWV0aW5nIGluPGJyPg0K VGFpcGVpLCBhbmQgaG9wZSB0aGF0IHdlJ2xsIGJlIGFibGUgdG8gaGF2ZSBhIGZydWl0ZnVsIGFu ZCBsaXZlbHk8YnI+DQpkaXNjdXNzaW9uIHRoZXJlLjxicj4NCjxicj4NCjxicj4NCkJlc3QsPGJy Pg0KPGJyPg0KRmVpPC9mb250Pg0KPGJyPg0KPGJyPg0K --=_alternative 004A154E4825792F_=-- From alessandro.dalessandro@telecomitalia.it Thu Oct 20 08:08:08 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2CD21F8BE7; Thu, 20 Oct 2011 08:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3, SARE_MILLIONSOF=0.315, SARE_SUB_ENC_UTF8=0.152] 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 1gXJiO4kPQUi; Thu, 20 Oct 2011 08:08:07 -0700 (PDT) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2A17321F8BD3; Thu, 20 Oct 2011 08:08:07 -0700 (PDT) Received: from grfhub701rm001.griffon.local (10.19.3.8) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 20 Oct 2011 17:08:04 +0200 Received: from GRFMBX702RM001.griffon.local ([10.19.3.20]) by grfhub701rm001.griffon.local ([10.19.9.234]) with mapi; Thu, 20 Oct 2011 17:08:03 +0200 From: D'Alessandro Alessandro Gerardo To: John E Drake Date: Thu, 20 Oct 2011 17:04:50 +0200 Thread-Topic: =?utf-8?B?W21wbHNdIFI6IFJlOiAg562U5aSNOiAg5Zue5aSN77yaICBSOiBGVzogTGFz?= =?utf-8?B?dCBDYWxsOiA8ZHJhZnQtc3ByZWNoZXItbXBscy10cC1vYW0tY29uc2lkZQ==?= =?utf-8?B?cmF0aW9ucy0wMS50eHQ+IChUaGUgUmVhc29ucyBmb3IgU2VsZWN0aW5nIA==?= =?utf-8?B?YSBTaW5nbGUgU29sdXRpb24gZm9yIE1QTFMtVFAgT0FNKSB0byBJbmZvcg==?= =?utf-8?B?bWF0aW9uYWwgUkZD?= Thread-Index: AcyOpA2RXou9f4zaRMOHsJDkZFf+XgABQf/QACNNLqA= Message-ID: References: <28928821.2302421319057359974.JavaMail.defaultUser@defaultHost> <5E893DB832F57341992548CDBB333163A4448A390C@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A4448A390C@EMBX01-HQ.jnpr.net> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mpls@ietf.org" , "ietf@ietf.org" , "yang.jian90@zte.com.cn" , "mpls-bounces@ietf.orgLarry" , "brian.e.carpenter@gmail.com" Subject: [mpls] =?utf-8?b?UjogIFI6IFJlOiAg562U5aSNOiAg5Zue5aSN77yaICBSOiBG?= =?utf-8?q?W=3A_Last_Call=3A_=3Cdraft-sprecher-mpls-tp-oam-considerations-?= =?utf-8?q?01=2Etxt=3E_=28The_Reasons_for_Selecting_a_Single_Solution_for_?= =?utf-8?q?MPLS-TP_OAM=29_to_Informational_RFC?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:08:08 -0000 Sm9obiwNCkkgb2Z0ZW4gYXBwcmVjaWF0ZSBFcm1pbmlvJ3MgY29tbWVudHMgb24gdGhpcyBtYWls aW5nIGxpc3QgYnV0IEkgaGFkIG5vdCB0aWxsIG5vdyB0aGUgcGxlYXN1cmUgdG8gbWVldCBoaW0g YmVjYXVzZSBoZSBkb2VzIG5vdCBhdHRlbmQgdGhlIElFVEYgbWVldGluZ3MuDQoNCkF0IG15IGtu b3dsZWRnZSwgSSdtIHRoZSBvbmx5ICJBbGVzc2FuZHJvIiB0aGF0IGhhcyBiZWVuIGZvbGxvd2lu ZyAgTVBMUy1UUCBzdGFuZGFyZGl6YXRpb24gcHJvY2VzcyBhbmQgYXBwYXJlbnRseSBpdCBzZWVt cyB0byBtZSB5b3Ugd2FudCB0byBhc3NvY2lhdGUgRXJtaW5pbydzIGNvbW1lbnRzIHRvIG1lIChp biB5b3VyIGVtYWlsIGJlbG93KS4NCg0KSSByZWdyZXQgdG8gdGVsbCB5b3UgdGhhdCBJIGZvbGxv dyBzdGFuZGFyZHMgb24gYmVoYWxmIG9mIFRJIGFuZCBleGNsdXNpdmVseSBmb3IgdGhlIGludGVy ZXN0IG9mIG15IENvbXBhbnkuIEkgaGF2ZSB0aGVyZWZvcmUgbm8gbmVlZCB0byB1c2UgYW4gaW5m b3JtYWwgZW1haWwgYWNjb3VudCAoYW5kIEknbGwgbmV2ZXIgZG8gaXQpLg0KDQpCZXN0IHJlZ2Fy ZHMsDQpBbGVzc2FuZHJvDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRlbGVjb20gSXRhbGlhDQpBbGVzc2FuZHJvIEQn QWxlc3NhbmRybw0KVHJhbnNwb3J0IElubm92YXRpb24NClZpYSBSZWlzcyBSb21vbGksIDI3NCAt IDEwMTQ4IFRvcmlubw0KcGhvbmU6ICArMzkgMDExIDIyOCA1ODg3DQptb2JpbGU6ICszOSAzMzUg NzY2IDk2MDcNCmZheDogKzM5IDA2IDQxOCA2MzkgMDcNCg0KDQotLS0tLU1lc3NhZ2dpbyBvcmln aW5hbGUtLS0tLQ0KRGE6IGlldGYtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmlldGYtYm91bmNl c0BpZXRmLm9yZ10gUGVyIGNvbnRvIGRpIEpvaG4gRSBEcmFrZQ0KSW52aWF0bzogbWVyY29sZWTD rCAxOSBvdHRvYnJlIDIwMTEgMjM6NTUNCkE6IGVybWluaW8ub3R0b25lXzY5QGxpYmVyby5pdDsg YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tOyB5YW5nLmppYW45MEB6dGUuY29tLmNuDQpDYzog bXBsc0BpZXRmLm9yZzsgbXBscy1ib3VuY2VzQGlldGYub3JnTGFycnk7IGlldGZAaWV0Zi5vcmcN Ck9nZ2V0dG86IFJFOiBbbXBsc10gUjogUmU6IOetlOWkjTog5Zue5aSN77yaIFI6IEZXOiBMYXN0 IENhbGw6IDxkcmFmdC1zcHJlY2hlci1tcGxzLXRwLW9hbS1jb25zaWRlcmF0aW9ucy0wMS50eHQ+ IChUaGUgUmVhc29ucyBmb3IgU2VsZWN0aW5nIGEgU2luZ2xlIFNvbHV0aW9uIGZvciBNUExTLVRQ IE9BTSkgdG8gSW5mb3JtYXRpb25hbCBSRkMNCg0KQWxlc3NhbmRybywNCg0KQXBwYXJlbnRseSwg dGhlIGFkdmljZSBnaXZlbiByZWdhcmRpbmcgdGhlIHJpc2tzIGFuZCBjb3N0cyBhc3NvY2lhdGVk IHdpdGggZGVwbG95aW5nIHByb3ByaWV0YXJ5IG9yIHByZS1zdGFuZGFyZCBzb2x1dGlvbnMgZGlk bid0IHJlc29uYXRlIHdpdGggeW91LiAgRG8geW91IHJlYWxseSBleHBlY3QgdGhlIHJlc3Qgb2Yg dXMgdG8gY2xlYW4gdXAgYWZ0ZXIgeW91Pw0KDQpUaGFua3MsDQoNCkpvaG4NCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBlcm1pbmlvLm90dG9uZV82 OUBsaWJlcm8uaXQNCj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE5LCAyMDExIDE6NDkgUE0N Cj4gVG86IGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbTsgeWFuZy5qaWFuOTBAenRlLmNvbS5j bg0KPiBDYzogbXBsc0BpZXRmLm9yZzsgbXBscy1ib3VuY2VzQGlldGYub3JnTGFycnk7IGlldGZA aWV0Zi5vcmcNCj4gU3ViamVjdDogW21wbHNdIFI6IFJlOiDnrZTlpI06IOWbnuWkje+8miBSOiBG VzogTGFzdCBDYWxsOiA8ZHJhZnQtc3ByZWNoZXItDQo+IG1wbHMtdHAtb2FtLWNvbnNpZGVyYXRp b25zLTAxLnR4dD4gKFRoZSBSZWFzb25zIGZvciBTZWxlY3RpbmcgYSBTaW5nbGUNCj4gU29sdXRp b24gZm9yIE1QTFMtVFAgT0FNKSB0byBJbmZvcm1hdGlvbmFsIFJGQw0KPg0KPiBJZiB0aGUgTVBM UyBXRyBoYWQgc2VsZWN0ZWQgdGhlIE9BTSBzb2x1dGlvbiB0aGF0IHdhcyBhbHJlYWR5IGV4aXN0 aW5nDQo+IChhcyBpbmRpY2F0ZWQgbXVsdGlwbGUgdGltZXMgYnkgdGhlIG9wZXJhdG9ycyB3aGlj aCBoYXZlIGFscmVhZHkNCj4gbWFzc2l2ZWx5IGRlcGxveWVkIGl0KSwgd2Ugd291bGQgaGF2ZSBo YWQgYSBzaW5nbGUgT0FNIHNvbHV0aW9uIGJvdGgNCj4gaW4gdGhlIG1hcmtldCBhbmQgaW4gdGhl IElFVEYgUkZDcy4NCj4NCj4gV2Ugbm93IGhhdmUgInR3byIgT0FNIHNvbHV0aW9uczogb25lICh3 aGljaCBpcyBub3QgYWN0dWFsbHkgcmVhbGx5DQo+IHNpbmd1bGFyKQ0KPiBkb2N1bWVudGVkIGJ5 IElFVEYgUkZDcyBhbmQgb25lIHdpZGVseSBpbXBsZW1lbnRlZCBhbmQgZGVwbG95ZWQuIFRoaXMN Cj4gZHJhZnQgaXMgbm90IHJlc29sdmluZyB0aGlzIGlzc3VlIGF0IGFsbC4NCj4NCj4gPi0tLS1N ZXNzYWdnaW8gb3JpZ2luYWxlLS0tLQ0KPiA+RGE6IGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNv bQ0KPiA+RGF0YTogNS1vdHQtMjAxMSAyMi4xNg0KPiA+QTogPHlhbmcuamlhbjkwQHp0ZS5jb20u Y24+DQo+ID5DYzogIm1wbHNAaWV0Zi5vcmciPG1wbHNAaWV0Zi5vcmc+LCAiaWV0ZkBpZXRmLm9y ZyI8aWV0ZkBpZXRmLm9yZz4sDQo+IDxtcGxzLQ0KPiBib3VuY2VzQGlldGYub3JnTGFycnk+DQo+ ID5PZ2c6IFJlOiBbbXBsc10g562U5aSNOiAg5Zue5aSN77yaICBSOiBGVzogTGFzdCBDYWxsOiAm bHQ7ZHJhZnQtc3ByZWNoZXItDQo+IG1wbHMtdHAtb2FtLQ0KPiBjb25zaWRlcmF0aW9ucy0wMS50 eHQmZ3Q7IChUaGUgUmVhc29ucyBmb3IgU2VsZWN0aW5nIGEgU2luZ2xlIFNvbHV0aW9uDQo+IGZv ciBNUExTLSBUUCBPQU0pIHRvIEluZm9ybWF0aW9uYWwgUkZDDQo+ID4NCj4gPkhpIEppYW4sDQo+ ID4NCj4gPk9uIDIwMTEtMTAtMDYgMDM6NTMsIHlhbmcuamlhbjkwQHp0ZS5jb20uY24gd3JvdGU6 DQo+ID4+IERlYXIgQWxsLA0KPiA+Pg0KPiA+PiBJIGRvIG5vdCBzdXBwb3J0IGVpdGhlci4NCj4g Pj4NCj4gPj4gSW4gc2VjdGlvbiAzLjU6DQo+ID4+IElmIHR3byBNUExTIE9BTSBwcm90b2NvbHMg d2VyZSB0byBiZSBkZXBsb3llZCB3ZSB3b3VsZCBoYXZlIHRvDQo+IGNvbnNpZGVyDQo+ID4+IHRo cmVlIHBvc3NpYmxlIHNjZW5hcmlvczoNCj4gPj4gMSkgSXNvbGF0aW9uIG9mIHRoZSBuZXR3b3Jr IGludG8gdHdvIGluY29tcGF0aWJsZSBhbmQgdW5jb25uZWN0ZWQNCj4gaXNsYW5kcy4NCj4gPj4N Cj4gPj4gVHdvIE9BTSBzb2x1dGlvbnMgaGF2ZSBiZWVuIGRpc2N1c3NlZCBmb3IgYSBsb25nIHRp bWUgaW4gYm90aCBJVFUtVA0KPiBhbmQNCj4gPj4gSUVURi4NCj4gPj4gRWFjaCBzb2x1dGlvbiBo YXMgdGhlaXIgb3duIHN1cHBvcnRlcnMgaW5jdWxkaW5nIGNhcnJpZXJzIGFuZA0KPiB2ZW5kb3Jz Lg0KPiA+PiBTbyBJIGRvbid0IHRoaW5rIHRoZXJlIGlzIGFueSBpbnRlcndvcmtpbmcgaXNzdWUg YmV0d2VlbiB0d28gT0FNDQo+IHNvbHV0aW9ucy4NCj4gPj4gQ2FycmllciB3aWxsIHNlbGVjdCBv bmUgT0FNIHNvbHV0aW9uLCBBIG9yIEIsIGluIHRoZWlyIG5ldHdvcmsuDQo+ID4+IE5vIG5lZWQg dG8gc2VsZWN0IEEgYW5kIEIgYXQgb25lIG5ldHdvcmsgYXQgdGhlIHNhbWUgdGltZS4NCj4gPg0K PiA+VGhlcmUgYXJlIHR3byBsYXJnZSBjb3N0cyB0aGF0IHlvdSBhcmUgaWdub3Jpbmc6DQo+ID4N Cj4gPmEpIGFsbCB2ZW5kb3JzIHdpc2hpbmcgdG8gYmlkIGZvciBidXNpbmVzcyBmcm9tIEEgYW5k IEIgd2lsbCBoYXZlIHRvDQo+ID4gICBpbXBsZW1lbnQgYW5kIHN1cHBvcnQgYm90aCBzb2x1dGlv bnMuDQo+ID4NCj4gPmIpIHdoZW4gQSBidXlzIEIgb3IgQiBidXlzIEEsIHRoZSBpbmNvbXBhdGli bGUgbmV0d29ya3Mgd2lsbCBoYXZlIHRvDQo+ID4gICBiZSBtZXJnZWQuDQo+ID4NCj4gPlRoZXNl IGFyZSBjb3N0cyB0aGF0IHJ1biB0byBodW5kcmVkcyBvZiBtaWxsaW9ucyBvZiBVU0QsIEVVUiBv ciBDTlkuDQo+ID5UaGV5IGFyZSBjb3N0cyBjYXVzZWQgZGlyZWN0bHkgYnkgU0RPcyBjcmVhdGlu ZyByaXZhbCBzb2x1dGlvbnMuDQo+ID4NCj4gPkkgdGhpbmsgaXQgd291bGQgYmUgaXJyZXNwb25z aWJsZSBvZiB0aGUgSUVURiBub3QgdG8gZG9jdW1lbnQgdGhpcw0KPiA+c2l0dWF0aW9uLiBBcyBl bmdpbmVlcnMsIHdlIGhhdmUgYW4gZXRoaWNhbCByZXNwb25zaWJpbGl0eSBoZXJlLg0KPiA+DQo+ ID4gICAgQnJpYW4NCj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID5tcGxzIG1haWxpbmcgbGlzdA0KPiA+bXBsc0BpZXRmLm9yZw0KPiA+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4NCj4NCj4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbXBscyBtYWlsaW5n IGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21wbHMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpJZXRmIG1haWxpbmcgbGlzdA0KSWV0ZkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pZXRmDQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxs ZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNh dGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFu dGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2Ft ZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBw ZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBj b211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6 aW9uZSwgR3JhemllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZp ZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBm b3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGlu ZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFu eSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhh bmtzLg0KDQo= From jaiharik@ipinfusion.com Thu Oct 20 08:40:20 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3161321F8C90; Thu, 20 Oct 2011 08:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.526 X-Spam-Level: X-Spam-Status: No, score=-0.526 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 qrvGKwrA3RsV; Thu, 20 Oct 2011 08:40:19 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E2AC621F8C8D; Thu, 20 Oct 2011 08:40:18 -0700 (PDT) Received: by vws5 with SMTP id 5so2581588vws.31 for ; Thu, 20 Oct 2011 08:40:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.68.240 with SMTP id z16mr10984323vdt.120.1319125217299; Thu, 20 Oct 2011 08:40:17 -0700 (PDT) Received: by 10.52.184.202 with HTTP; Thu, 20 Oct 2011 08:40:17 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Oct 2011 21:10:17 +0530 Message-ID: From: Jaihari Kalijanakiraman To: zhang.fei3@zte.com.cn Content-Type: multipart/alternative; boundary=20cf3079bf42fdcc4a04afbcc5df Cc: "mpls@ietf.org" , "ccamp@ietf.org" Subject: Re: [mpls] Request comments on draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:40:20 -0000 --20cf3079bf42fdcc4a04afbcc5df Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Zhang, Thanks for the clarification. Sorry I misunderstood. I have a question here.. You mentioned "As to the associated bidirectional LSP, there are two independent signaling procedures for the forward and backward directional LSPs".. So for associated bidirectional LSPs the two endpoints should have an association or binding between the forward and reverse tunnels. So if the forward and reverse directional LSPs are independently signaled, how the binding or association will be established between them.. When I read the draft, initially thought that this connection object will b= e used to establish that binding or association... Is there a way to establish this binding already.. Please clarify.. Cant we use this object to establish that binding?? Thanks again, for your kind reply... *Thanks & Regards,* *Jai Hari M.K.* *IP Infusion* 2011/10/20 > > Hi Jaihari > > Thanks for your comments. :-) > > This draft is about how to carry the local assigned tunnel number of > co-routed bidirectional LSP, sorry I do not describe it clearly in the ma= il. > > According to the description in section 5.2.1 of the RFC6370, the LSP > number keeps the same under the context of A1 and Z9's tunnel numbers: > > A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num > > So only the tunnel number assigned by the destination node is missing. > > As to the associated bidirectional LSP, there are two independent signali= ng > procedures for the forward and backward directional LSPs, and the A1 and = Z9 > know each other the assigned tunnel number and LSP number. > > Furthermore, the Global_ID is also needed if the LSP is across different > ASs, which may be added in next version. > > Your comments are welcome. > > Best regards > > Fei > > > *Jaihari Kalijanakiraman * > > 2011-10-20 15:22 > =CA=D5=BC=FE=C8=CB > zhang.fei3@zte.com.cn > =B3=AD=CB=CD > "mpls@ietf.org" > =D6=F7=CC=E2 > Re: [mpls] Request comments on > draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00 > > > > > > > On Thu, Oct 20, 2011 at 12:50 PM, Jaihari Kalijanakiraman <* > jaiharik@ipinfusion.com* > wrote: > Hi Zhang, > > I have a question. > > The connection object in the draft has only destination tunnel number. > > But as per TP Identifiers RFC 6370, > > * > > 5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers* > > A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}:: > Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num} > > > So I think the connection object should also include the destination LSP > number also. > > Please comment.. > > > *Thanks & Regards,* > *Jai Hari M.K. > IP Infusion* > > > Date: Mon, 17 Oct 2011 19:08:51 +0800 > From: *zhang.fei3@zte.com.cn* > To: "*ccamp@ietf.org* " <*ccamp@ietf.org* >, > "*mpls@ietf.org* " <*mpls@ietf.org* > > Subject: [mpls] Request comments on > draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00 > Message-ID: > <* > OF3E7FD488.405BF0C5-ON4825792C.00351CBE-4825792C.003D3BA7@zte.com.cn* > > > Content-Type: text/plain; charset=3D"us-ascii" > > Hi all > > We've submitted a draft for the group's consideration, below is the link:= * > ** > http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-nu= m-00 > * > . > > This draft is about the supporting of MPLS-TP Maintenance Identifiers. As > described in *http://tools.ietf.org/html/rfc6370*, > at each end point, a > tunnel is uniquely identified by the end point's Node_ID and a locally > assigned tunnel number, which allow a compact form for the MEP_ID, and > extensions will be required to GMPLS to support these identifiers. > Furthermore, *http://tools.ietf.org/html/rfc6373*addressed this issue in > section 4.4.8. > > Obviously, this issue can be solved by defining a new object, such as > Connection Object as described in this draft, or a new sub-TLV call MEP_I= D > can be carried back to the ingress LSR in Resv message when the "CV" flag > of the OAM Function Flags Sub-TLV is set, which may be considered in the > subsequent version of the draft* > **http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-06*= > . > > We hope you'll find the time to look through the draft and comment on the > list, help judge which way is more suitable before the WG meeting in > Taipei, and hope that we'll be able to have a fruitful and lively > discussion there. > > > Best, > > Fei > > --20cf3079bf42fdcc4a04afbcc5df Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Zhang,

Thanks for the clarification.

Sorry I misunderstood.

I have a question = here..

You mentioned "As to the&= nbsp;associated bidirectional LSP, there are two indepe= ndent signaling procedures for the forward and backward directional LSPs"..

So for associated bidirectional LSPs the two endpoints = should have an association or binding between the forward and reverse tunne= ls. 

So if the forward and reverse directiona= l LSPs are independently signaled, how the binding or association will be e= stablished between them..

When I read the draft, initially thought that this conn= ection object will be used to establish that binding or association...

Is there a way to establish this binding already.. Ple= ase clarify..

Cant we use this object to establish that binding??

Thanks again, for your kind reply...


Thanks & Regards,
Jai Hari M.K.
IP= Infusion

2011/10/20 <zhang.fei3@zte.com.c= n>

Hi Jaihari

Thanks for your comments. :-)

This draft is about how to carry t= he local assigned tunnel number of co-routed bidirectional LSP, sorry I do not describe it clearly in the mail.

According to the description in se= ction 5.2.1 of the RFC6370, the LSP number keeps the same under the context of A1 and Z9's tunnel numbers:

A1-{Node_ID::Tunnel_Num}::Z9-{Node= _ID::Tunnel_Num}::LSP_Num

So only the tunnel number assigned by the destination node is missing.

As to the associated bidirectional= LSP, there are two independent signaling procedures for the forward and backward directional LSPs, and the A1 and Z9
know each other the assigned tunne= l number and LSP number.

Furthermore, the Global_ID is also= needed if the LSP is across different ASs, which may be added in next version.

Your comments are welcome.

Best regards

Fei


Jaihari Kalijanak= iraman <jaiharik@i= pinfusion.com>

2011-10-20 15:22

=CA=D5=BC=FE=C8= =CB
zhang.fei3@zte.com.cn
=B3=AD=CB=CD
"mpls@ietf.org" <mpls@ietf.org>
=D6=F7=CC=E2
Re: [mpls] Request comments o= n draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00
On Thu, Oct 20, 2011 at 12:50 PM, Jaihari Kalijanakira= man <jaiharik@ipinfusion.com> wrote:
Hi Zhang,

I have a question.

The connection object in the draft has only destinatio= n tunnel number.

But as per TP Identifiers RFC 6370,



5.2.2.  MPLS-TP Associated Bidirectional LSP Identifiers

     A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}::
     Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}

So I think the connection object should also include t= he destination LSP number also.

Please comment..


Thanks & Regards,
Jai Hari M.K.
IP Infusion

 
Date: Mon, 17 Oct 2011 19:08:51 +0800
From: zhang.fei3@zte.com.cn
To: "ccamp@ietf.org= " <ccamp@ietf.org>= , "mpls@ietf.org"= ; <mpls@ietf.org>
Subject: [mpls] Request comments on
       draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-= 00
Message-ID:
       <OF3E7FD488.405BF0C5-ON4825792C.00351CBE-482579= 2C.003D3BA7@zte.com.cn>
Content-Type: text/plain; charset=3D"us-ascii"

Hi all

We've submitted a draft for the group's consideration, below is the= link:
http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-= num-00.

This draft is about the supporting of MPLS-TP Maintenance Identifiers. As
described in http://tools.ietf.org/html/r= fc6370, at each end point, a
tunnel is uniquely identified by the end point's Node_ID and a locally<= br> assigned tunnel number, which allow a compact form for the MEP_ID, and
extensions will be required to GMPLS to support these identifiers.
Furthermore, http://tools.ietf.org/html/r= fc6373 addressed this issue in
section 4.4.8.

Obviously, this issue can be solved by defining a new object, such as
Connection Object as described in this draft, or a new sub-TLV call MEP_ID<= br> can be carried back to the ingress LSR in Resv message when the "CV&qu= ot; flag
of the OAM Function Flags Sub-TLV is set, which may be considered in the subsequent version of the draft htt= p://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-06.

We hope you'll find the time to look through the draft and comment on t= he
list, help judge which way is more suitable before the WG meeting in
Taipei, and hope that we'll be able to have a fruitful and lively
discussion there.


Best,

Fei


--20cf3079bf42fdcc4a04afbcc5df-- From erosen@cisco.com Thu Oct 20 13:02:22 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C73511E80AB for ; Thu, 20 Oct 2011 13:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 BHVEr3VxGfeg for ; Thu, 20 Oct 2011 13:02:21 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6537611E809D for ; Thu, 20 Oct 2011 13:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=2621; q=dns/txt; s=iport; t=1319140940; x=1320350540; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=T8RRoL+PyL//tksLB1Be7sN28oH1mcRPUuqIFjO/bQg=; b=KkQbHtxlwr0DCpaLbTU9ap6pW4GWO5RPhQa40KLHpEbwMOarf3SbY5Eq 9uX06lPqX824YHsMSBydRkR70YxsqEr/8pEqt4RpPO2994gcMm3QZhX0N BIdprArtX4bxTnnw+8tEW2rOjXuUvZ6Duzaug+4GVgAyzL1Ao8QH5V87j M=; X-IronPort-AV: E=Sophos;i="4.69,380,1315180800"; d="scan'208";a="29873674" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 20 Oct 2011 20:02:20 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p9KK2J3r011210; Thu, 20 Oct 2011 20:02:19 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id p9KK2H5i018731; Thu, 20 Oct 2011 16:02:19 -0400 To: Quintin Zhao In-reply-to: Your message of Tue, 18 Oct 2011 13:14:09 -0400. <003c01cc8db9$5a22fb90$0e68f2b0$%zhao@huawei.com> Date: Thu, 20 Oct 2011 16:02:17 -0400 Message-ID: <18730.1319140937@erosen-linux> From: Eric Rosen Cc: mpls@ietf.org Subject: Re: [mpls] Subject: Forwarding discussion in ldp-multi-topology draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 20:02:22 -0000 > For the section 3.5, the applications scenario is that when one ISP owns > multiple ASes and the VPN services crossing these ASes are usually setup > using inter-AS VPNs' option A or B or C. With MPLS multiple topology, the > ISP can configure a new AS with a subset of the routers which are sitting in > the existing ASes. The new AS will be used to provide the VPN services and > there is not inter-AS setup needed anymore. In the IETF79 meeting, Lianyuan > had a presentation to describe this, here is the link for the presentation > slide( page3-page7): > http://www.ietf.org/proceedings/79/slides/mpls-10/mpls-10.htm. I took a look at the slides, but I don't really see the merit of this proposal. It's not really clear how the topology is to be set up, what the BGP relationships are, or why anyone would think this is easier or simpler than the conventional inter-AS L3VPN mechanisms (or other alternatives such as overlays, carrier's carrier, etc.) After all, the multi-topology configuration affects all the intermediate nodes, while the other mechanisms do not. But perhaps it's just difficult to understand the proposal from a few slides. Whether or not that proposal has merit, I don't think the LDP multi-topology draft should make unsubstantiated statements like "the LSP setup process can be simplified by configuring a set of routers which are in different domains into a new single domain with a new toplogy ID using the LDP multiple topology" or "the LDP lsp set up can be done easily without the complex inter-as VPN solution's option A, option B and option C." Quintin> if the interface-specific label space is used, then we still have Quintin> the case that this interface is used by multiple topology, right? Quintin> How can we differentiate the different topologies? Correct; some scenarios require use of the platform-specific label space. My only point is this is a local matter, each LSR can use whatever sort of label space is suitable for its deployment scenario. There's no need for the spec to require that the platform-specific label space be used. > With multiple FIBs, does associating a received packet with a particular > topology requires a data plane change if the existing router has not > supported multiple topology before? If the association is made by looking at a part of the IP header, I think it would be fair to say that a data plane change is required. However, it's also possible to implement non-MPLS multi-topology by using data link multiplexing techniques. From zhang.fei3@zte.com.cn Thu Oct 20 18:04:56 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E21B11E8096; Thu, 20 Oct 2011 18:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.294 X-Spam-Level: X-Spam-Status: No, score=-99.294 tagged_above=-999 required=5 tests=[AWL=-1.659, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mC3+FPkKcQjO; Thu, 20 Oct 2011 18:04:55 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4F33511E8091; Thu, 20 Oct 2011 18:04:54 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 417131279682118; Fri, 21 Oct 2011 09:01:49 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 20387.3010951596; Fri, 21 Oct 2011 09:04:48 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p9L14gmJ064573; Fri, 21 Oct 2011 09:04:42 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: Jaihari Kalijanakiraman MIME-Version: 1.0 X-KeepSent: 671D8908:85D8155E-48257930:0000A497; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Fri, 21 Oct 2011 09:04:35 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-21 09:04:43, Serialize complete at 2011-10-21 09:04:43 Content-Type: multipart/alternative; boundary="=_alternative 0005E93D48257930_=" X-MAIL: mse02.zte.com.cn p9L14gmJ064573 Cc: "mpls@ietf.org" , "ccamp@ietf.org" Subject: Re: [mpls] Request comments on draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 01:04:56 -0000 This is a multipart message in MIME format. --=_alternative 0005E93D48257930_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgSmFpaGFyaQ0KDQpBcyB0byB0aGUgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUCwgdGhl IGJpbmRpbmcgaXMgYmFzZWQgb24gdGhlIA0KRXh0ZW5kZWQgQXNzb2NpYXRpb24gb2JqZWN0LCB3 aGljaCBpcyBkZWZpbmVkIGluIHRoZSBkcmFmdA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1jY2FtcC1hc3NvYy1leHQtMDAuDQoNCkEgbmV3IEFzc29jaWF0aW9uIFR5cGUg aXMgaW50cm9kdWNlZCBpbiBhbm90aGVyIGRyYWZ0LCANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTAy Lg0KQmFzZWQgb24gdGhlIGFzc29jaWF0aW9uIHR5cGUgImFzc29jaWF0ZWQgYmlkaXJlY3Rpb25h bCBMU1AiLCB0d28gcmV2ZXJzZSANCnVuaWRpcmVjdGlvbmFsIExTUHMgY2FuIGZvcm0gdGhlIGFz c29pY2F0ZWQgYmlkaXJlY3Rpb25hbCBMU1AuDQoNCkhvd2V2ZXIsIGFjY29yZGluZyB0byB0aGUg dXNhZ2Ugb2YgdGhpcyBvYmplY3QsIHNlZSB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIA0Kc2VjdGlv biAyLjMuMSBpbiB0aGUgZHJhZnQgDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWNjYW1wLWFzc29jLWV4dC0wMCwgIm5vIGFzc29jaWF0aW9ucyANCmFyZSBtYWRlIGFjcm9z cyBQYXRoIGFuZCBSZXN2IHN0YXRlIi4NCg0KVGhhdCBpbmRpY2F0ZXMgdGhhdCB0aGUgQXNzb2Np YXRpb24gb2JqZWN0IG9yIEV4dGVuZGVkIEFzc29jaWF0aW9uIG9iamVjdCANCmNhbiBub3QgYmUg dXNlZCB0byBjYXJyeSBiYWNrIHRoZSBsb2NhbCBhc3NpZ25lZCB0dW5uZWwgbnVtYmVyIGluIHRo ZSANCmNvbnRleHQgb2YgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1AuDQoNClRoYXQgaXMgdGhl IGhpc3Rvcnkgd2h5IGEgbmV3IENvbm5lY3Rpb24gb2JqZWN0IGlzIGludHJvZHVjZWQgaGVyZSBm b3IgdGhlIA0KY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQLg0KDQpCZSBnbGFkIHRvIHNoYXJl IG15IG9waW5pb24gb24gdGhpcyBzdWJqZWN0Lg0KDQpCZXN0IHJlZ2FyZHMNCg0KRmVpDQoNCg0K DQoNCkphaWhhcmkgS2FsaWphbmFraXJhbWFuIDxqYWloYXJpa0BpcGluZnVzaW9uLmNvbT4gDQoy MDExLTEwLTIwIDIzOjQwDQoNCsrVvP7Iyw0KemhhbmcuZmVpM0B6dGUuY29tLmNuDQqzrcvNDQoi Y2NhbXBAaWV0Zi5vcmciIDxjY2FtcEBpZXRmLm9yZz4sICJtcGxzQGlldGYub3JnIiA8bXBsc0Bp ZXRmLm9yZz4NCtb3zOINClJlOiBbbXBsc10gUmVxdWVzdCBjb21tZW50cyBvbiANCmRyYWZ0LXpo YW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtLTAwDQoNCg0KDQoNCg0KDQpI aSBaaGFuZywNCg0KVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4NCg0KU29ycnkgSSBtaXN1 bmRlcnN0b29kLg0KDQpJIGhhdmUgYSBxdWVzdGlvbiBoZXJlLi4NCg0KWW91IG1lbnRpb25lZCAi QXMgdG8gdGhlIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AsIHRoZXJlIGFyZSB0d28gDQpp bmRlcGVuZGVudCBzaWduYWxpbmcgcHJvY2VkdXJlcyBmb3IgdGhlIGZvcndhcmQgYW5kIGJhY2t3 YXJkIGRpcmVjdGlvbmFsIA0KTFNQcyIuLg0KDQpTbyBmb3IgYXNzb2NpYXRlZCBiaWRpcmVjdGlv bmFsIExTUHMgdGhlIHR3byBlbmRwb2ludHMgc2hvdWxkIGhhdmUgYW4gDQphc3NvY2lhdGlvbiBv ciBiaW5kaW5nIGJldHdlZW4gdGhlIGZvcndhcmQgYW5kIHJldmVyc2UgdHVubmVscy4gDQoNClNv IGlmIHRoZSBmb3J3YXJkIGFuZCByZXZlcnNlIGRpcmVjdGlvbmFsIExTUHMgYXJlIGluZGVwZW5k ZW50bHkgc2lnbmFsZWQsIA0KaG93IHRoZSBiaW5kaW5nIG9yIGFzc29jaWF0aW9uIHdpbGwgYmUg ZXN0YWJsaXNoZWQgYmV0d2VlbiB0aGVtLi4NCg0KV2hlbiBJIHJlYWQgdGhlIGRyYWZ0LCBpbml0 aWFsbHkgdGhvdWdodCB0aGF0IHRoaXMgY29ubmVjdGlvbiBvYmplY3Qgd2lsbCANCmJlIHVzZWQg dG8gZXN0YWJsaXNoIHRoYXQgYmluZGluZyBvciBhc3NvY2lhdGlvbi4uLg0KDQpJcyB0aGVyZSBh IHdheSB0byBlc3RhYmxpc2ggdGhpcyBiaW5kaW5nIGFscmVhZHkuLiBQbGVhc2UgY2xhcmlmeS4u DQoNCkNhbnQgd2UgdXNlIHRoaXMgb2JqZWN0IHRvIGVzdGFibGlzaCB0aGF0IGJpbmRpbmc/Pw0K DQpUaGFua3MgYWdhaW4sIGZvciB5b3VyIGtpbmQgcmVwbHkuLi4NCg0KDQpUaGFua3MgJiBSZWdh cmRzLA0KSmFpIEhhcmkgTS5LLg0KSVAgSW5mdXNpb24NCg0KMjAxMS8xMC8yMCA8emhhbmcuZmVp M0B6dGUuY29tLmNuPg0KDQpIaSBKYWloYXJpIA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMu IDotKSANCg0KVGhpcyBkcmFmdCBpcyBhYm91dCBob3cgdG8gY2FycnkgdGhlIGxvY2FsIGFzc2ln bmVkIHR1bm5lbCBudW1iZXIgb2YgDQpjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1AsIHNvcnJ5 IEkgZG8gbm90IGRlc2NyaWJlIGl0IGNsZWFybHkgaW4gdGhlIA0KbWFpbC4gDQoNCkFjY29yZGlu ZyB0byB0aGUgZGVzY3JpcHRpb24gaW4gc2VjdGlvbiA1LjIuMSBvZiB0aGUgUkZDNjM3MCwgdGhl IExTUCANCm51bWJlciBrZWVwcyB0aGUgc2FtZSB1bmRlciB0aGUgY29udGV4dCBvZiBBMSBhbmQg WjkncyB0dW5uZWwgbnVtYmVyczogDQoNCkExLXtOb2RlX0lEOjpUdW5uZWxfTnVtfTo6Wjkte05v ZGVfSUQ6OlR1bm5lbF9OdW19OjpMU1BfTnVtDQoNClNvIG9ubHkgdGhlIHR1bm5lbCBudW1iZXIg YXNzaWduZWQgYnkgdGhlIGRlc3RpbmF0aW9uIG5vZGUgaXMgbWlzc2luZy4gDQoNCkFzIHRvIHRo ZSBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQLCB0aGVyZSBhcmUgdHdvIGluZGVwZW5kZW50 IA0Kc2lnbmFsaW5nIHByb2NlZHVyZXMgZm9yIHRoZSBmb3J3YXJkIGFuZCBiYWNrd2FyZCBkaXJl Y3Rpb25hbCBMU1BzLCBhbmQgDQp0aGUgQTEgYW5kIFo5IA0Ka25vdyBlYWNoIG90aGVyIHRoZSBh c3NpZ25lZCB0dW5uZWwgbnVtYmVyIGFuZCBMU1AgbnVtYmVyLiANCg0KRnVydGhlcm1vcmUsIHRo ZSBHbG9iYWxfSUQgaXMgYWxzbyBuZWVkZWQgaWYgdGhlIExTUCBpcyBhY3Jvc3MgZGlmZmVyZW50 IA0KQVNzLCB3aGljaCBtYXkgYmUgYWRkZWQgaW4gbmV4dCB2ZXJzaW9uLiANCg0KWW91ciBjb21t ZW50cyBhcmUgd2VsY29tZS4gDQoNCkJlc3QgcmVnYXJkcyANCg0KRmVpIA0KDQoNCg0KSmFpaGFy aSBLYWxpamFuYWtpcmFtYW4gPGphaWhhcmlrQGlwaW5mdXNpb24uY29tPiANCjIwMTEtMTAtMjAg MTU6MjIgDQoNCg0KytW8/sjLDQp6aGFuZy5mZWkzQHp0ZS5jb20uY24gDQqzrcvNDQoibXBsc0Bp ZXRmLm9yZyIgPG1wbHNAaWV0Zi5vcmc+IA0K1vfM4g0KUmU6IFttcGxzXSBSZXF1ZXN0IGNvbW1l bnRzIG9uIA0KZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1bm5lbC1udW0t MDANCg0KDQoNCg0KDQoNCg0KDQoNCg0KT24gVGh1LCBPY3QgMjAsIDIwMTEgYXQgMTI6NTAgUE0s IEphaWhhcmkgS2FsaWphbmFraXJhbWFuIDwNCmphaWhhcmlrQGlwaW5mdXNpb24uY29tPiB3cm90 ZTogDQpIaSBaaGFuZywgDQoNCkkgaGF2ZSBhIHF1ZXN0aW9uLiANCg0KVGhlIGNvbm5lY3Rpb24g b2JqZWN0IGluIHRoZSBkcmFmdCBoYXMgb25seSBkZXN0aW5hdGlvbiB0dW5uZWwgbnVtYmVyLiAN Cg0KQnV0IGFzIHBlciBUUCBJZGVudGlmaWVycyBSRkMgNjM3MCwgDQoNCg0KDQo1LjIuMi4gIE1Q TFMtVFAgQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExTUCBJZGVudGlmaWVycyANCg0KICAgICBB MS17R2xvYmFsX0lEOjpOb2RlX0lEOjpUdW5uZWxfTnVtOjpMU1BfTnVtfTo6DQogICAgIFo5LXtH bG9iYWxfSUQ6Ok5vZGVfSUQ6OlR1bm5lbF9OdW06OkxTUF9OdW19DQoNCg0KU28gSSB0aGluayB0 aGUgY29ubmVjdGlvbiBvYmplY3Qgc2hvdWxkIGFsc28gaW5jbHVkZSB0aGUgZGVzdGluYXRpb24g TFNQIA0KbnVtYmVyIGFsc28uIA0KDQpQbGVhc2UgY29tbWVudC4uIA0KDQoNClRoYW5rcyAmIFJl Z2FyZHMsIA0KSmFpIEhhcmkgTS5LLg0KSVAgSW5mdXNpb24gDQoNCiANCkRhdGU6IE1vbiwgMTcg T2N0IDIwMTEgMTk6MDg6NTEgKzA4MDANCkZyb206IHpoYW5nLmZlaTNAenRlLmNvbS5jbg0KVG86 ICJjY2FtcEBpZXRmLm9yZyIgPGNjYW1wQGlldGYub3JnPiwgIm1wbHNAaWV0Zi5vcmciIDxtcGxz QGlldGYub3JnPg0KU3ViamVjdDogW21wbHNdIFJlcXVlc3QgY29tbWVudHMgb24NCiAgICAgICBk cmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtdHVubmVsLW51bS0wMA0KTWVzc2Fn ZS1JRDoNCiAgICAgICA8DQpPRjNFN0ZENDg4LjQwNUJGMEM1LU9ONDgyNTc5MkMuMDAzNTFDQkUt NDgyNTc5MkMuMDAzRDNCQTdAenRlLmNvbS5jbj4NCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsg Y2hhcnNldD0idXMtYXNjaWkiDQoNCkhpIGFsbA0KDQpXZSd2ZSBzdWJtaXR0ZWQgYSBkcmFmdCBm b3IgdGhlIGdyb3VwJ3MgY29uc2lkZXJhdGlvbiwgYmVsb3cgaXMgdGhlIGxpbms6DQpodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQt dHVubmVsLW51bS0wMA0KLg0KDQpUaGlzIGRyYWZ0IGlzIGFib3V0IHRoZSBzdXBwb3J0aW5nIG9m IE1QTFMtVFAgTWFpbnRlbmFuY2UgSWRlbnRpZmllcnMuIEFzDQpkZXNjcmliZWQgaW4gaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjM3MCwgYXQgZWFjaCBlbmQgcG9pbnQsIGENCnR1bm5l bCBpcyB1bmlxdWVseSBpZGVudGlmaWVkIGJ5IHRoZSBlbmQgcG9pbnQncyBOb2RlX0lEIGFuZCBh IGxvY2FsbHkNCmFzc2lnbmVkIHR1bm5lbCBudW1iZXIsIHdoaWNoIGFsbG93IGEgY29tcGFjdCBm b3JtIGZvciB0aGUgTUVQX0lELCBhbmQNCmV4dGVuc2lvbnMgd2lsbCBiZSByZXF1aXJlZCB0byBH TVBMUyB0byBzdXBwb3J0IHRoZXNlIGlkZW50aWZpZXJzLg0KRnVydGhlcm1vcmUsIGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzYzNzMgYWRkcmVzc2VkIHRoaXMgaXNzdWUgaW4NCnNlY3Rp b24gNC40LjguDQoNCk9idmlvdXNseSwgdGhpcyBpc3N1ZSBjYW4gYmUgc29sdmVkIGJ5IGRlZmlu aW5nIGEgbmV3IG9iamVjdCwgc3VjaCBhcw0KQ29ubmVjdGlvbiBPYmplY3QgYXMgZGVzY3JpYmVk IGluIHRoaXMgZHJhZnQsIG9yIGEgbmV3IHN1Yi1UTFYgY2FsbCBNRVBfSUQNCmNhbiBiZSBjYXJy aWVkIGJhY2sgdG8gdGhlIGluZ3Jlc3MgTFNSIGluIFJlc3YgbWVzc2FnZSB3aGVuIHRoZSAiQ1Yi IGZsYWcNCm9mIHRoZSBPQU0gRnVuY3Rpb24gRmxhZ3MgU3ViLVRMViBpcyBzZXQsIHdoaWNoIG1h eSBiZSBjb25zaWRlcmVkIGluIHRoZQ0Kc3Vic2VxdWVudCB2ZXJzaW9uIG9mIHRoZSBkcmFmdA0K aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1yc3ZwLXRlLW1wbHMt dHAtb2FtLWV4dC0wNi4NCg0KV2UgaG9wZSB5b3UnbGwgZmluZCB0aGUgdGltZSB0byBsb29rIHRo cm91Z2ggdGhlIGRyYWZ0IGFuZCBjb21tZW50IG9uIHRoZQ0KbGlzdCwgaGVscCBqdWRnZSB3aGlj aCB3YXkgaXMgbW9yZSBzdWl0YWJsZSBiZWZvcmUgdGhlIFdHIG1lZXRpbmcgaW4NClRhaXBlaSwg YW5kIGhvcGUgdGhhdCB3ZSdsbCBiZSBhYmxlIHRvIGhhdmUgYSBmcnVpdGZ1bCBhbmQgbGl2ZWx5 DQpkaXNjdXNzaW9uIHRoZXJlLg0KDQoNCkJlc3QsDQoNCkZlaSANCg0KDQoNCg== --=_alternative 0005E93D48257930_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkhpIEphaWhhcmk8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkFzIHRvIHRoZSBhc3NvY2lh dGVkIGJpZGlyZWN0aW9uYWwgTFNQLA0KdGhlIGJpbmRpbmcgaXMgYmFzZWQgb24gdGhlIEV4dGVu ZGVkIEFzc29jaWF0aW9uIG9iamVjdCwgd2hpY2ggaXMgZGVmaW5lZA0KaW4gdGhlIGRyYWZ0PC9m b250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5odHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNjYW1wLWFzc29jLWV4dC0wMC48L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkEgbmV3IEFzc29jaWF0aW9uIFR5cGUg aXMgaW50cm9kdWNlZA0KaW4gYW5vdGhlciBkcmFmdDxiPiwgPC9iPmh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQt bHNwLTAyLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+QmFzZWQg b24gdGhlIGFzc29jaWF0aW9uIHR5cGUgJnF1b3Q7YXNzb2NpYXRlZA0KYmlkaXJlY3Rpb25hbCBM U1AmcXVvdDssIHR3byByZXZlcnNlIHVuaWRpcmVjdGlvbmFsIExTUHMgY2FuIGZvcm0gdGhlIGFz c29pY2F0ZWQNCmJpZGlyZWN0aW9uYWwgTFNQLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+SG93ZXZlciwgYWNjb3JkaW5nIHRvIHRoZSB1c2FnZSBvZiB0 aGlzDQpvYmplY3QsIHNlZSB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIHNlY3Rpb24gMi4zLjEgaW4g dGhlIGRyYWZ0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2NhbXAtYXNz b2MtZXh0LTAwLA0KJnF1b3Q7bm8gYXNzb2NpYXRpb25zIGFyZSBtYWRlIGFjcm9zcyBQYXRoIGFu ZCBSZXN2IHN0YXRlJnF1b3Q7LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+VGhhdCBpbmRpY2F0ZXMgdGhhdCB0aGUgQXNzb2NpYXRpb24NCm9iamVjdCBv ciBFeHRlbmRlZCBBc3NvY2lhdGlvbiBvYmplY3QgY2FuIG5vdCBiZSB1c2VkIHRvIGNhcnJ5IGJh Y2sgdGhlDQpsb2NhbCBhc3NpZ25lZCB0dW5uZWwgbnVtYmVyIGluIHRoZSBjb250ZXh0IG9mIGNv cm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+VGhhdCBpcyB0aGUgaGlzdG9yeSB3aHkgYSBuZXcgQ29ubmVjdGlv bg0Kb2JqZWN0IGlzIGludHJvZHVjZWQgaGVyZSBmb3IgdGhlIGNvLXJvdXRlZCBiaWRpcmVjdGlv bmFsIExTUC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PkJlIGdsYWQgdG8gc2hhcmUgbXkgb3BpbmlvbiBvbiB0aGlzDQpzdWJqZWN0LjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+QmVzdCByZWdhcmRzPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5GZWk8L2ZvbnQ+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+SmFpaGFy aSBLYWxpamFuYWtpcmFtYW4NCiZsdDtqYWloYXJpa0BpcGluZnVzaW9uLmNvbSZndDs8L2I+IDwv Zm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLTEwLTIwIDIzOjQw PC9mb250Pg0KPHRkIHdpZHRoPTYzJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PnpoYW5nLmZlaTNAenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7Y2NhbXBAaWV0 Zi5vcmcmcXVvdDsgJmx0O2NjYW1wQGlldGYub3JnJmd0OywNCiZxdW90O21wbHNAaWV0Zi5vcmcm cXVvdDsgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW21wbHNd IFJlcXVlc3QgY29tbWVudHMgb24gZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0 LXR1bm5lbC1udW0tMDA8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+SGkgWmhhbmcsPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0 aW9uLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+U29y cnkgSSBtaXN1bmRlcnN0b29kLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+SSBoYXZlIGEgcXVlc3Rpb24gaGVyZS4uPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5Zb3UgbWVudGlvbmVkICZxdW90O0FzIHRvIHRo ZSBhc3NvY2lhdGVkDQpiaWRpcmVjdGlvbmFsIExTUCwgdGhlcmUgYXJlIHR3byBpbmRlcGVuZGVu dCBzaWduYWxpbmcgcHJvY2VkdXJlcyBmb3IgdGhlDQpmb3J3YXJkIGFuZCBiYWNrd2FyZCBkaXJl Y3Rpb25hbCBMU1BzJnF1b3Q7Li48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPlNvIGZvciBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQcw0KdGhlIHR3 byBlbmRwb2ludHMgc2hvdWxkIGhhdmUgYW4gYXNzb2NpYXRpb24gb3IgYmluZGluZyBiZXR3ZWVu IHRoZSBmb3J3YXJkDQphbmQgcmV2ZXJzZSB0dW5uZWxzLiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlNvIGlmIHRoZSBmb3J3YXJkIGFuZCByZXZlcnNl IGRpcmVjdGlvbmFsDQpMU1BzIGFyZSBpbmRlcGVuZGVudGx5IHNpZ25hbGVkLCBob3cgdGhlIGJp bmRpbmcgb3IgYXNzb2NpYXRpb24gd2lsbCBiZQ0KZXN0YWJsaXNoZWQgYmV0d2VlbiB0aGVtLi48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPldoZW4gSSBy ZWFkIHRoZSBkcmFmdCwgaW5pdGlhbGx5IHRob3VnaHQNCnRoYXQgdGhpcyBjb25uZWN0aW9uIG9i amVjdCB3aWxsIGJlIHVzZWQgdG8gZXN0YWJsaXNoIHRoYXQgYmluZGluZyBvciBhc3NvY2lhdGlv bi4uLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+SXMg dGhlcmUgYSB3YXkgdG8gZXN0YWJsaXNoIHRoaXMgYmluZGluZw0KYWxyZWFkeS4uIFBsZWFzZSBj bGFyaWZ5Li48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PkNhbnQgd2UgdXNlIHRoaXMgb2JqZWN0IHRvIGVzdGFibGlzaA0KdGhhdCBiaW5kaW5nPz88L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBhZ2Fp biwgZm9yIHlvdXIga2luZCByZXBseS4uLjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBz aXplPTMgY29sb3I9Izk5OTk5OSBmYWNlPSJzYW5zLXNlcmlmIj48aT5UaGFua3MgJmFtcDsgUmVn YXJkcyw8L2k+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj0jOTk5OTk5IGZhY2U9InNh bnMtc2VyaWYiPjxpPkphaSBIYXJpIE0uSy48L2k+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBj b2xvcj0jOTk5OTk5IGZhY2U9InNhbnMtc2VyaWYiPjxpPklQIEluZnVzaW9uPC9pPjwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLzEwLzIwICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWls dG86emhhbmcuZmVpM0B6dGUuY29tLmNuPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNh bnMtc2VyaWYiPjx1PnpoYW5nLmZlaTNAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj48YnI+DQpIaSBKYWloYXJpIDxicj4NCjxicj4NClRoYW5rcyBmb3IgeW91 ciBjb21tZW50cy4gOi0pIDxicj4NCjxicj4NClRoaXMgZHJhZnQgaXMgYWJvdXQgaG93IHRvIGNh cnJ5IHRoZSBsb2NhbCBhc3NpZ25lZCB0dW5uZWwgbnVtYmVyIG9mIGNvLXJvdXRlZA0KYmlkaXJl Y3Rpb25hbCBMU1AsIHNvcnJ5IEkgZG8gbm90IGRlc2NyaWJlIGl0IGNsZWFybHkgaW4gdGhlIG1h aWwuIDxicj4NCjxicj4NCkFjY29yZGluZyB0byB0aGUgZGVzY3JpcHRpb24gaW4gc2VjdGlvbiA1 LjIuMSBvZiB0aGUgUkZDNjM3MCwgdGhlIExTUCBudW1iZXINCmtlZXBzIHRoZSBzYW1lIHVuZGVy IHRoZSBjb250ZXh0IG9mIEExIGFuZCBaOSdzIHR1bm5lbCBudW1iZXJzOiA8YnI+DQo8YnI+DQpB MS17Tm9kZV9JRDo6VHVubmVsX051bX06Olo5LXtOb2RlX0lEOjpUdW5uZWxfTnVtfTo6TFNQX051 bTxicj4NCjxicj4NClNvIG9ubHkgdGhlIHR1bm5lbCBudW1iZXIgYXNzaWduZWQgYnkgdGhlIGRl c3RpbmF0aW9uIG5vZGUgaXMgbWlzc2luZy4NCjxicj4NCjxicj4NCkFzIHRvIHRoZSBhc3NvY2lh dGVkIGJpZGlyZWN0aW9uYWwgTFNQLCB0aGVyZSBhcmUgdHdvIGluZGVwZW5kZW50IHNpZ25hbGlu Zw0KcHJvY2VkdXJlcyBmb3IgdGhlIGZvcndhcmQgYW5kIGJhY2t3YXJkIGRpcmVjdGlvbmFsIExT UHMsIGFuZCB0aGUgQTEgYW5kDQpaOSA8YnI+DQprbm93IGVhY2ggb3RoZXIgdGhlIGFzc2lnbmVk IHR1bm5lbCBudW1iZXIgYW5kIExTUCBudW1iZXIuIDxicj4NCjxicj4NCkZ1cnRoZXJtb3JlLCB0 aGUgR2xvYmFsX0lEIGlzIGFsc28gbmVlZGVkIGlmIHRoZSBMU1AgaXMgYWNyb3NzIGRpZmZlcmVu dA0KQVNzLCB3aGljaCBtYXkgYmUgYWRkZWQgaW4gbmV4dCB2ZXJzaW9uLiA8YnI+DQo8YnI+DQpZ b3VyIGNvbW1lbnRzIGFyZSB3ZWxjb21lLiA8YnI+DQo8YnI+DQpCZXN0IHJlZ2FyZHMgPGJyPg0K PGJyPg0KRmVpIDxicj4NCjxicj4NCjwvZm9udD4NCjxwPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD00MCU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjxiPkphaWhhcmkgS2FsaWphbmFraXJhbWFuDQombHQ7PC9iPjwvZm9udD48YSBocmVmPW1h aWx0bzpqYWloYXJpa0BpcGluZnVzaW9uLmNvbSB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBj b2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjxiPjx1PmphaWhhcmlrQGlwaW5mdXNpb24uY29t PC91PjwvYj48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mZ3Q7 PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMTAt MjAgMTU6MjI8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0K PHRkIHdpZHRoPTU5JT4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQgd2lkdGg9NiU+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQgd2lkdGg9OTMlPjxhIGhyZWY9bWFpbHRv OnpoYW5nLmZlaTNAenRlLmNvbS5jbiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1i bHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PnpoYW5nLmZlaTNAenRlLmNvbS5jbjwvdT48L2ZvbnQ+ PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ JnF1b3Q7PC9mb250PjxhIGhyZWY9bWFpbHRvOm1wbHNAaWV0Zi5vcmcgdGFyZ2V0PV9ibGFuaz48 Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5tcGxzQGlldGYub3Jn PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90Ow0KJmx0 OzwvZm9udD48YSBocmVmPW1haWx0bzptcGxzQGlldGYub3JnIHRhcmdldD1fYmxhbms+PGZvbnQg c2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+bXBsc0BpZXRmLm9yZzwvdT48 L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7PC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFttcGxz XSBSZXF1ZXN0IGNvbW1lbnRzIG9uIGRyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4 dC10dW5uZWwtbnVtLTAwPC9mb250PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9 MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTUwJT4NCjx0ZCB3aWR0aD01MCU+PC90 YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpPbiBUaHUsIE9jdCAyMCwgMjAxMSBhdCAxMjo1 MCBQTSwgSmFpaGFyaSBLYWxpamFuYWtpcmFtYW4gJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpq YWloYXJpa0BpcGluZnVzaW9uLmNvbSB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1i bHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PmphaWhhcmlrQGlwaW5mdXNpb24uY29tPC91PjwvZm9u dD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZndDsNCndyb3RlOiA8YnI+DQpI aSBaaGFuZywgPGJyPg0KPGJyPg0KSSBoYXZlIGEgcXVlc3Rpb24uIDxicj4NCjxicj4NClRoZSBj b25uZWN0aW9uIG9iamVjdCBpbiB0aGUgZHJhZnQgaGFzIG9ubHkgZGVzdGluYXRpb24gdHVubmVs IG51bWJlci4NCjxicj4NCjxicj4NCkJ1dCBhcyBwZXIgVFAgSWRlbnRpZmllcnMgUkZDIDYzNzAs IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Yj48YnI+ DQo8YnI+DQo8YnI+DQo1LjIuMi4gJm5ic3A7TVBMUy1UUCBBc3NvY2lhdGVkIEJpZGlyZWN0aW9u YWwgTFNQIElkZW50aWZpZXJzPC9iPjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KPGJy Pg0KICZuYnNwOyAmbmJzcDsgQTEte0dsb2JhbF9JRDo6Tm9kZV9JRDo6VHVubmVsX051bTo6TFNQ X051bX06Ojxicj4NCiAmbmJzcDsgJm5ic3A7IFo5LXtHbG9iYWxfSUQ6Ok5vZGVfSUQ6OlR1bm5l bF9OdW06OkxTUF9OdW19PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+ DQo8YnI+DQo8YnI+DQpTbyBJIHRoaW5rIHRoZSBjb25uZWN0aW9uIG9iamVjdCBzaG91bGQgYWxz byBpbmNsdWRlIHRoZSBkZXN0aW5hdGlvbiBMU1ANCm51bWJlciBhbHNvLiA8YnI+DQo8YnI+DQpQ bGVhc2UgY29tbWVudC4uIDxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Izk5 OTk5OSBmYWNlPSJzYW5zLXNlcmlmIj48aT48YnI+DQpUaGFua3MgJmFtcDsgUmVnYXJkcyw8L2k+ PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9 MyBjb2xvcj0jOTk5OTk5IGZhY2U9InNhbnMtc2VyaWYiPjxpPjxicj4NCkphaSBIYXJpIE0uSy48 YnI+DQpJUCBJbmZ1c2lvbjwvaT48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PiA8YnI+DQo8YnI+DQogJm5ic3A7PGJyPg0KRGF0ZTogTW9uLCAxNyBPY3QgMjAxMSAxOTowODo1 MSArMDgwMDxicj4NCkZyb206IDwvZm9udD48YSBocmVmPW1haWx0bzp6aGFuZy5mZWkzQHp0ZS5j b20uY24gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNl cmlmIj48dT56aGFuZy5mZWkzQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KVG86ICZxdW90OzwvZm9udD48YSBocmVmPW1haWx0bzpj Y2FtcEBpZXRmLm9yZyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9 InNhbnMtc2VyaWYiPjx1PmNjYW1wQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPiZxdW90Ow0KJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpjY2Ft cEBpZXRmLm9yZyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNh bnMtc2VyaWYiPjx1PmNjYW1wQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPiZndDssDQomcXVvdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86bXBsc0Bp ZXRmLm9yZyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMt c2VyaWYiPjx1Pm1wbHNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+JnF1b3Q7DQombHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOm1wbHNAaWV0Zi5v cmcgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlm Ij48dT5tcGxzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPiZndDs8YnI+DQpTdWJqZWN0OiBbbXBsc10gUmVxdWVzdCBjb21tZW50cyBvbjxicj4N CiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1l eHQtdHVubmVsLW51bS0wMDxicj4NCk1lc3NhZ2UtSUQ6PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZsdDs8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOk9GM0U3RkQ0ODguNDA1QkYwQzUtT040ODI1 NzkyQy4wMDM1MUNCRS00ODI1NzkyQy4wMDNEM0JBN0B6dGUuY29tLmNuIiB0YXJnZXQ9X2JsYW5r Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pk9GM0U3RkQ0ODgu NDA1QkYwQzUtT040ODI1NzkyQy4wMDM1MUNCRS00ODI1NzkyQy4wMDNEM0JBN0B6dGUuY29tLmNu PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZndDs8YnI+DQpD b250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9JnF1b3Q7dXMtYXNjaWkmcXVvdDs8YnI+ DQo8YnI+DQpIaSBhbGw8YnI+DQo8YnI+DQpXZSd2ZSBzdWJtaXR0ZWQgYSBkcmFmdCBmb3IgdGhl IGdyb3VwJ3MgY29uc2lkZXJhdGlvbiwgYmVsb3cgaXMgdGhlIGxpbms6PC9mb250Pjxmb250IHNp emU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctY2NhbXAtbXBscy10 cC1yc3ZwdGUtZXh0LXR1bm5lbC1udW0tMDAiIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNv bG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1bm5lbC1udW0tMDA8L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Ljxicj4NCjxicj4NClRoaXMg ZHJhZnQgaXMgYWJvdXQgdGhlIHN1cHBvcnRpbmcgb2YgTVBMUy1UUCBNYWludGVuYW5jZSBJZGVu dGlmaWVycy4NCkFzPGJyPg0KZGVzY3JpYmVkIGluIDwvZm9udD48YSBocmVmPWh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzYzNzAgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9 Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2 MzcwPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiwNCmF0IGVh Y2ggZW5kIHBvaW50LCBhPGJyPg0KdHVubmVsIGlzIHVuaXF1ZWx5IGlkZW50aWZpZWQgYnkgdGhl IGVuZCBwb2ludCdzIE5vZGVfSUQgYW5kIGEgbG9jYWxseTxicj4NCmFzc2lnbmVkIHR1bm5lbCBu dW1iZXIsIHdoaWNoIGFsbG93IGEgY29tcGFjdCBmb3JtIGZvciB0aGUgTUVQX0lELCBhbmQ8YnI+ DQpleHRlbnNpb25zIHdpbGwgYmUgcmVxdWlyZWQgdG8gR01QTFMgdG8gc3VwcG9ydCB0aGVzZSBp ZGVudGlmaWVycy48YnI+DQpGdXJ0aGVybW9yZSwgPC9mb250PjxhIGhyZWY9aHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNjM3MyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1i bHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYz NzM8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQphZGRyZXNz ZWQgdGhpcyBpc3N1ZSBpbjxicj4NCnNlY3Rpb24gNC40LjguPGJyPg0KPGJyPg0KT2J2aW91c2x5 LCB0aGlzIGlzc3VlIGNhbiBiZSBzb2x2ZWQgYnkgZGVmaW5pbmcgYSBuZXcgb2JqZWN0LCBzdWNo IGFzPGJyPg0KQ29ubmVjdGlvbiBPYmplY3QgYXMgZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQsIG9y IGEgbmV3IHN1Yi1UTFYgY2FsbCBNRVBfSUQ8YnI+DQpjYW4gYmUgY2FycmllZCBiYWNrIHRvIHRo ZSBpbmdyZXNzIExTUiBpbiBSZXN2IG1lc3NhZ2Ugd2hlbiB0aGUgJnF1b3Q7Q1YmcXVvdDsNCmZs YWc8YnI+DQpvZiB0aGUgT0FNIEZ1bmN0aW9uIEZsYWdzIFN1Yi1UTFYgaXMgc2V0LCB3aGljaCBt YXkgYmUgY29uc2lkZXJlZCBpbiB0aGU8YnI+DQpzdWJzZXF1ZW50IHZlcnNpb24gb2YgdGhlIGRy YWZ0PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pjxi cj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1jY2FtcC1yc3ZwLXRlLW1wbHMtdHAtb2FtLWV4dC0wNiIgdGFyZ2V0PV9ibGFuaz48Zm9u dCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNjYW1wLXJzdnAtdGUtbXBscy10cC1vYW0tZXh0LTA2PC91 PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPi48YnI+DQo8YnI+DQpX ZSBob3BlIHlvdSdsbCBmaW5kIHRoZSB0aW1lIHRvIGxvb2sgdGhyb3VnaCB0aGUgZHJhZnQgYW5k IGNvbW1lbnQgb24gdGhlPGJyPg0KbGlzdCwgaGVscCBqdWRnZSB3aGljaCB3YXkgaXMgbW9yZSBz dWl0YWJsZSBiZWZvcmUgdGhlIFdHIG1lZXRpbmcgaW48YnI+DQpUYWlwZWksIGFuZCBob3BlIHRo YXQgd2UnbGwgYmUgYWJsZSB0byBoYXZlIGEgZnJ1aXRmdWwgYW5kIGxpdmVseTxicj4NCmRpc2N1 c3Npb24gdGhlcmUuPGJyPg0KPGJyPg0KPGJyPg0KQmVzdCw8YnI+DQo8YnI+DQpGZWkgPGJyPg0K PC9mb250Pg0KPGJyPg0KPGJyPg0K --=_alternative 0005E93D48257930_=-- From rcallon@juniper.net Fri Oct 21 08:09:16 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17B01F0C3B for ; Fri, 21 Oct 2011 08:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.434 X-Spam-Level: X-Spam-Status: No, score=-106.434 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS6p5byq1nEX for ; Fri, 21 Oct 2011 08:09:16 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 223C91F0C53 for ; Fri, 21 Oct 2011 08:09:16 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP; Fri, 21 Oct 2011 08:09:16 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 21 Oct 2011 08:04:40 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 21 Oct 2011 11:04:39 -0400 From: Ross Callon To: "mpls@ietf.org" Date: Fri, 21 Oct 2011 11:04:37 -0400 Thread-Topic: MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt Thread-Index: AcyQAr/rqEjMcksmQGe54jeWxe/qQg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C6F17AC47CEMBX01WFjnprn_" MIME-Version: 1.0 Subject: [mpls] MPLS WG last call on draft-ietf-mpls-tp-oam-analysis-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 15:09:16 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C6F17AC47CEMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group, This is to start a two week working group last call on draft-ietf-mpls-tp-o= am-analysis-06.txt ("An Overview of the OAM Tool Set for MPLS based Trans= port Networks"). Please send comments to the mpls@ietf.org mailing lis= t. This working group last call ends on Saturday November 5th. George, Loa and Ross MPLS WG co-chairs --_000_DF7F294AF4153D498141CBEFADB17704C6F17AC47CEMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Working Group,
 
This is to start a two week working group last call on draft-ietf-mpls= -tp-oam-analysis-06.txt ("An Overview of the OAM Tool Set for  M= PLS based Transport Networks").
 
Please send comments to the mpls@ietf.org mailing list.
 
This working group last call ends on Saturday November 5th.
 
George, Loa and Ross
MPLS WG co-chairs
 
 --_000_DF7F294AF4153D498141CBEFADB17704C6F17AC47CEMBX01WFjnprn_-- From ietfc@btconnect.com Fri Oct 21 10:12:50 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6DD11F0C95 for ; Fri, 21 Oct 2011 10:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 GYMdd9TWLdMr for ; Fri, 21 Oct 2011 10:12:50 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr09.btconnect.com [213.123.26.187]) by ietfa.amsl.com (Postfix) with ESMTP id B60DB1F0C7F for ; Fri, 21 Oct 2011 10:12:49 -0700 (PDT) Received: from host86-163-151-98.range86-163.btcentralplus.com (HELO pc6) ([86.163.151.98]) by c2beaomr09.btconnect.com with SMTP id EWD92769; Fri, 21 Oct 2011 18:12:47 +0100 (BST) Message-ID: <002f01cc900b$968d89c0$4001a8c0@gateway.2wire.net> From: "t.petch" Cc: References: <20111012092804.2434.52765.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2011 18:07:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0302.4EA1A80D.011B, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.10.21.153914:17:7.586, ip=86.163.151.98, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, MISSING_HEADERS, __ANY_URI, __CP_URI_IN_BODY, __INT_PROD_LOC, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, __PHISH_SPEAR_STRUCTURE_1, RDNS_SUSP, __PHISH_SPEAR_STRUCTURE_2, BODY_SIZE_7000_LESS, TO_MALFORMED X-Junkmail-Status: score=10/50, host=c2beaomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0203.4EA1A810.0037,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-oam-analysis-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 17:12:50 -0000 Ross I had just drafted this when your Last Call came out. The technical content of this seems to be stabilising, albeit on moving foundations, but the text seems to offer scope for improvement. Taking a paragraph at random: "Continuity Check and Connectivity Verification (CC-V) [why not CC-CV as in the I-D draft-mpls-tp-cc-cv-rdi ?] are OAM operations generally used in tandem, and compliment each other. [verges on the tautological - either phrase would do] These functions are generally run pro-actively, but may also be used [we once had one proactive, the other on-demand, but I think now both are proactive but only one on demand] on-demand, either due to bandwidth considerations or for diagnoses of [diagnoses plural? of multiple conditions, or singular diagnosis?] a specific condition. Pro-actively ['Proactively' seems redundant here] [MPLS-TP OAM Reqs] [ugly abbreviation MPLS-TP seems redundant in the context, OAMREQS would be a more normal RFC-style abbreviation (but I do prefer TEXT to RFCzzxx)] states that the function should allow the MEPs to monitor the liveness and connectivity of a transport path. In on-demand mode, this function should support monitoring between the MEPs and, in addition, between a MEP and MIP [MEP and MIP? not quite what on-demand-cv says] I;'s not exactly wrong, but seems loose in its wording. Tom Petch ----- Original Message ----- From: To: Cc: Sent: Wednesday, October 12, 2011 11:28 AM Subject: [mpls] I-D Action: draft-ietf-mpls-tp-oam-analysis-06.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. > > Title : An Overview of the OAM Tool Set for MPLS based Transport Networks > Author(s) : Nurit Sprecher > Luyuan Fang > Filename : draft-ietf-mpls-tp-oam-analysis-06.txt > Pages : 21 > Date : 2011-10-12 > > This document provides an overview of the OAM toolset for MPLS based > Transport Networks. The toolset consists of a comprehensive set of > fault management and performance monitoring capabilities (operating > in the data-plane) which are appropriate for transport networks as > required in [MPLS-TP OAM Reqs] and support the network and services > at different nested levels. This overview includes a brief recap of > MPLS-TP OAM requirements and functions, and of generic mechanisms > created in the MPLS data plane to allow the OAM packets run in-band > and share their fate with data packets. The protocol definitions for > each of the MPLS-TP OAM tools are defined in separate documents (RFCs > or Working Group drafts) which are referenced by this document. > > This document is a product of a joint Internet Engineering Task Force > (IETF) / International Telecommunications Union Telecommunications > Standardization Sector (ITU-T) effort to include an MPLS Transport > Profile within the IETF MPLS and PWE3 architectures to support the > capabilities and functionalities of a packet transport network as > defined by the ITU-T. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-analysis-06.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-analysis-06.txt > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > From lizho.jin@gmail.com Fri Oct 21 18:26:11 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A9B1F0C3F for ; Fri, 21 Oct 2011 18:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 sW7qjq151G0Y for ; Fri, 21 Oct 2011 18:26:10 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 36DB91F0C3D for ; Fri, 21 Oct 2011 18:26:06 -0700 (PDT) Received: by qadc10 with SMTP id c10so1910150qad.31 for ; Fri, 21 Oct 2011 18:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=f1mjbVJ//s87+kVg60W4BMlEeRqE7xDf9Mk8UKlu8R0=; b=Z15SZjxJuYirO5xJN/yvRY9TgqPwa0AykB69XEwQyFWirSneei6WoUOHhV9PzVp0tg I+oIbuv8NrgKhlGQpeMINAQ59NELyBd/kb1nnoOiC/IBtsUQyqSHBapBA/LhI9m+FQus ZllyrRT7NA38ig59KKMeyFsaZlev7Pnq4S4Nk= MIME-Version: 1.0 Received: by 10.224.18.210 with SMTP id x18mr5880490qaa.80.1319246765708; Fri, 21 Oct 2011 18:26:05 -0700 (PDT) Received: by 10.224.54.147 with HTTP; Fri, 21 Oct 2011 18:26:05 -0700 (PDT) Date: Sat, 22 Oct 2011 09:26:05 +0800 Message-ID: From: Lizhong Jin To: mpls@ietf.org Content-Type: multipart/alternative; boundary=bcaec519618fd7573b04afd912be Cc: sharpe_tarikh@live.com Subject: Re: [mpls] RFC5036 (LDP) - request for interpretation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 01:26:11 -0000 --bcaec519618fd7573b04afd912be Content-Type: text/plain; charset=ISO-8859-1 Hi all, Following email is from Sharpe about the correct meaning of PDU Length in RFC5036. It is a bit old email, and now I meet the same question. Could anybody help to make some interpretation about this? Such kind of clarification would surely benefit the interoperation. Thanks Lizhong ------------------------------------------------------------------------------------------------------------------------- - *To*: MPLS > - *Subject*: [mpls] RFC5036 (LDP) - request for interpretation - *From*: Sharpe Tarikh > - *Date*: Thu, 12 Mar 2009 16:57:28 +0400 - *Delivered-to*: mpls at core3.amsl.com - *Importance*: Normal - *List-archive*: - *List-help*: > - *List-id*: Multi-Protocol Label Switching WG - *List-post*: > - *List-subscribe*: , < mailto:mpls-request@ietf.org?subject=subscribe> - *List-unsubscribe*: , < mailto:mpls-request@ietf.org?subject=unsubscribe> ------------------------------ Hi all, I have been reading through RFC5036 and there is a bit of ambiguity (at least as far as I am concerned) about how the "Max PDU Length" is to be interpreted. According to section 3.5.3, the "Max PDU Length" field of the LDP Initialization message is: [RFC5036 section 3.5.3] Two octet unsigned integer that proposes the maximum allowable length for LDP PDUs for the session. A value of 255 or less specifies the default maximum length of 4096 octets. Having read this, it would seem to suggest that this parameter is to be interpreted as the length of the entire LDP PDU, including all overhead fields. Therefore, if for example a Max PDU Length of 4096 is negotiated, it would seem to suggest that size of the entire LDP PDU would be no more than 4096 octets (including the Version and PDU Length fields). Now, if we turn to section 3.1, we are given a description of the "PDU Length" field in the LDP Header. The description reads as follows: [RFC5036 section 3.1] PDU Length Two octet integer specifying the total length of this PDU in octets, excluding the Version and PDU Length fields. Taking this and my interpretation of section 3.5.3, if a Max PDU Length of 4096 has been negotiated, then the maximum value of the "PDU Length" field of an LDP PDU should now be 4092 octets (taking away the 4 octets for the Version and PDU Length fields), to ensure that the maximum length of the complete LDP PDU does not exceed 4096. However, if I move further down the description of the "PDU length" field in section 3.1, I see the following: [RFC5036 section 3.1] The maximum allowable PDU Length is negotiable when an LDP session is initialized. Prior to completion of the negotiation, the maximum allowable length is 4096 bytes. Now, the point of confusion for me here is the term "PDU Length". In this description, does the term refer to the "PDU Length" field of the LDP header or the size of a maximum-length PDU. If it is the former, it invalidates my assumption from section 3.5.3 as the maximum PDU length would now be 4100. If it is the latter (which I think it should be) then I think this statement should be cleared up to explicitly state that . While this may seem an exercise in pedantry, I have encountered two implementations which are treating this differently. One believes that a negotiated Max PDU Length of 4096 allows them to send LDP PDUs with a size of 4100, while the other restricts the total PDU size to no more than 4096. Which one is correct ? Or is it the case that there really is a bit of ambiguity here that needs to be fixed up ? Your kind responses are greatly appreciated. Sharpe --bcaec519618fd7573b04afd912be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
Following email is from Sharpe about the correct meaning of PDU Length= in RFC5036. It is a bit old email, and now I meet the same question.
Could anybody help to make some interpretation about this? Such kind o= f clarification would surely=A0benefit the interoperation.
=A0
Thanks
Lizhong
=A0
=A0
----------------------------------------------------------------------= ---------------------------------------------------
=
Hi all,

I have been reading through RFC5036 and there is a bit o= f ambiguity (at least as far as I am concerned) about how the "Max PDU= Length" is to be interpreted.

According to section 3.5.3, the = "Max PDU Length" field of the LDP Initialization message is:

[RFC5036 section 3.5.3]
=A0=A0=A0 Two octet unsigned integer that pr= oposes the maximum allowable
=A0=A0=A0 length for LDP PDUs for the sessi= on. A value of 255 or less
=A0=A0=A0 specifies the default maximum lengt= h of 4096 octets.

Having read this, it would seem to suggest that this parameter is to be= interpreted as the length of the entire LDP PDU, including all overhead fi= elds. Therefore, if for example a Max PDU Length of 4096 is negotiated, it = would seem to suggest that size of the entire LDP PDU would be no more than= 4096 octets (including the Version and PDU Length fields).

Now, if we turn to section 3.1, we are given a description of the "= ;PDU Length" field in the LDP Header. The description reads as follows= :

[RFC5036 section 3.1]
=A0=A0=A0 PDU Length

=A0=A0=A0 Two= octet integer specifying the total length of this PDU in
=A0=A0=A0 octets, excluding the Version and PDU Length fields.


T= aking this and my interpretation of section 3.5.3, if a Max PDU Length of 4= 096 has been negotiated, then the maximum value of the "PDU Length&quo= t; field of an LDP PDU should now be 4092 octets (taking away the 4 octets = for the Version and PDU Length fields), to ensure that the maximum length o= f the complete LDP PDU does not exceed 4096.

However, if I move further down the description of the "PDU length= " field in section 3.1, I see the following:

[RFC5036 section 3= .1]

=A0=A0=A0 The maximum allowable PDU Length is negotiable when an= LDP session
=A0=A0=A0 is initialized. Prior to completion of the negotiation, the
= =A0=A0=A0 maximum allowable length is 4096 bytes.


Now, the point= of confusion for me here is the term "PDU Length". In this descr= iption, does the term refer to the "PDU Length" field of the LDP = header or the size of a maximum-length PDU. If it is the former, it invalid= ates my assumption from section 3.5.3 as the maximum PDU length would now b= e 4100. If it is the latter (which I think it should be) then I think this = statement should be cleared up to explicitly state that .

While this may seem an exercise in pedantry, I have encountered two imp= lementations which are treating this differently. One believes that a negot= iated Max PDU Length of 4096 allows them to send LDP PDUs with a size of 41= 00, while the other restricts the total PDU size to no more than 4096. Whic= h one is correct ? Or is it the case that there really is a bit of ambiguit= y here that needs to be fixed up ?

Your kind responses are greatly appreciated.

Sharpe

--bcaec519618fd7573b04afd912be-- From loa@pi.nu Mon Oct 24 07:01:02 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A101421F8548 for ; Mon, 24 Oct 2011 07:01:02 -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 gxigOT5eVt-F for ; Mon, 24 Oct 2011 07:01:02 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id DD73421F8505 for ; Mon, 24 Oct 2011 07:01:01 -0700 (PDT) Received: from [172.17.113.226] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id D113D2A8004 for ; Mon, 24 Oct 2011 16:00:59 +0200 (CEST) Message-ID: <4EA56F96.7040404@pi.nu> Date: Mon, 24 Oct 2011 07:00:54 -0700 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] poll on draft-weingarten-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 14:01:02 -0000 Working Group, this is to start a two week poll to see if there is support to make draft-weingarten-mpls-tp-ring-protection an mpls working group draft. Pleased send your comments to the mpls working group mailing list (mpls@ietf.org). This poll ends Sun Nov 6. /Loa for the mpls wg chairs -- -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From daniele.ceccarelli@ericsson.com Mon Oct 24 07:02:33 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386EA21F8BBA for ; Mon, 24 Oct 2011 07:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=1.600, 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 5aR1o7CbQVtp for ; Mon, 24 Oct 2011 07:02:32 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id E9FD521F854E for ; Mon, 24 Oct 2011 07:02:31 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-17-4ea56ff68cdc Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1A.6D.13753.6FF65AE4; Mon, 24 Oct 2011 16:02:30 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.125]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 24 Oct 2011 16:02:30 +0200 From: Daniele Ceccarelli To: Loa Andersson , "mpls@ietf.org" Date: Mon, 24 Oct 2011 16:02:29 +0200 Thread-Topic: [mpls] poll on draft-weingarten-mpls-tp-ring-protection Thread-Index: AcySVWJ9oaPCIBczT42+N5VuS51d8AAACWDg Message-ID: References: <4EA56F96.7040404@pi.nu> In-Reply-To: <4EA56F96.7040404@pi.nu> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [mpls] poll on draft-weingarten-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 14:02:33 -0000 Yes/support BR Daniele -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: luned=EC 24 ottobre 2011 16.01 To: mpls@ietf.org Subject: [mpls] poll on draft-weingarten-mpls-tp-ring-protection Working Group, this is to start a two week poll to see if there is support to make draft-w= eingarten-mpls-tp-ring-protection an mpls working group draft. Pleased send your comments to the mpls working group mailing list (mpls@iet= f.org). This poll ends Sun Nov 6. /Loa for the mpls wg chairs -- --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From yaacov.weingarten@nsn.com Mon Oct 24 07:03:42 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02C521F8C4A for ; Mon, 24 Oct 2011 07:03:42 -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 uP+-06ciHdeU for ; Mon, 24 Oct 2011 07:03:42 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0398B21F8C22 for ; Mon, 24 Oct 2011 07:03:41 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9OE3cet013363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 24 Oct 2011 16:03:38 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9OE3agn023998 for ; Mon, 24 Oct 2011 16:03:38 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Oct 2011 16:03:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Oct 2011 16:03:28 +0200 Message-ID: In-Reply-To: <4EA56F96.7040404@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on draft-weingarten-mpls-tp-ring-protection Thread-Index: AcySVWUE/n7i+j2NT4CVZ8+YDpHSkwAADkIw References: <4EA56F96.7040404@pi.nu> From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: X-OriginalArrivalTime: 24 Oct 2011 14:03:32.0280 (UTC) FILETIME=[B6BFCB80:01CC9255] Subject: Re: [mpls] poll on draft-weingarten-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 14:03:42 -0000 Support/Yes Yaacov Weingarten Nokia Siemens Networks -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Loa Andersson Sent: Monday, October 24, 2011 4:01 PM To: mpls@ietf.org Subject: [mpls] poll on draft-weingarten-mpls-tp-ring-protection Working Group, this is to start a two week poll to see if there is support to make draft-weingarten-mpls-tp-ring-protection an mpls working group draft. Pleased send your comments to the mpls working group mailing list (mpls@ietf.org). This poll ends Sun Nov 6. /Loa for the mpls wg chairs --=20 --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From eosborne@cisco.com Mon Oct 24 07:08:42 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA6621F8C86 for ; Mon, 24 Oct 2011 07:08:42 -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 Pm924KIowXXR for ; Mon, 24 Oct 2011 07:08:42 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id CD11321F8C88 for ; Mon, 24 Oct 2011 07:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=1056; q=dns/txt; s=iport; t=1319465321; x=1320674921; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Xi4JfWB6MJmiPXyfLjSl54cRAZcZOIBdffdVxWJc2kc=; b=PbEzbxpgXrfWEjz7p9CtdqjHxD+VXfQyicSbLivqTwXSvz0ra66RQasi 3OAo2TE8jRZRgiTOS6eIqkUFORjOYiN2wkzlaBoebxpNtrHfanjf9qfiP khh+soYTnQ96d7or+DX8Wo8rUXv2ZWcdPu3u7ABPhZr8450WjUgJtv00z E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroAAGpwpU6tJV2a/2dsb2JhbABDmVGPQYEFgW4BAQEBAwEBAQ8BHQo0FwICAgEIEQQBAQsGFwEGARoMHwkIAQEEARIIGodmlWIBnXsEAoddYQSIBpE4jEQ X-IronPort-AV: E=Sophos;i="4.69,398,1315180800"; d="scan'208";a="30537306" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 24 Oct 2011 14:08:41 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9OE8fxN004381; Mon, 24 Oct 2011 14:08:41 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Oct 2011 09:08:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Oct 2011 09:08:41 -0500 Message-ID: In-Reply-To: <4EA56F96.7040404@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on draft-weingarten-mpls-tp-ring-protection Thread-Index: AcySVWNBAa2Gr3p+Q0OeOlejVrg5KAAAQaNQ References: <4EA56F96.7040404@pi.nu> From: "Eric Osborne (eosborne)" To: "Loa Andersson" , X-OriginalArrivalTime: 24 Oct 2011 14:08:40.0856 (UTC) FILETIME=[6EACC180:01CC9256] Subject: Re: [mpls] poll on draft-weingarten-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 14:08:42 -0000 Yes, support. eric > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Monday, October 24, 2011 10:01 AM > To: mpls@ietf.org > Subject: [mpls] poll on draft-weingarten-mpls-tp-ring-protection >=20 > Working Group, >=20 > this is to start a two week poll to see if there is support to make draft- > weingarten-mpls-tp-ring-protection an mpls working group draft. >=20 > Pleased send your comments to the mpls working group mailing list > (mpls@ietf.org). >=20 > This poll ends Sun Nov 6. >=20 > /Loa > for the mpls wg chairs > -- > -- >=20 >=20 > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From martin.vigoureux@alcatel-lucent.com Mon Oct 24 07:29:49 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1D121F8CE3 for ; Mon, 24 Oct 2011 07:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWnOC2E8+7mz for ; Mon, 24 Oct 2011 07:29:48 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 577BD21F8CDF for ; Mon, 24 Oct 2011 07:29:48 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p9OEQbOP007611 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 24 Oct 2011 16:29:42 +0200 Received: from [172.27.205.177] (135.120.57.7) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 24 Oct 2011 16:29:29 +0200 Message-ID: <4EA57649.7040006@alcatel-lucent.com> Date: Mon, 24 Oct 2011 16:29:29 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: "MPLS @ IETF" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [mpls] MPLS Sessions in Taipei - IETF Agenda Change X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 14:29:49 -0000 just to be sure you noticed the change. mpls wg 2nd session is now scheduled Thursday, 1520-1720 martin From gregory.mirsky@ericsson.com Mon Oct 24 08:15:10 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E6A21F8E58 for ; Mon, 24 Oct 2011 08:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 EtwN2gI21wxK for ; Mon, 24 Oct 2011 08:15:09 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9677621F8E54 for ; Mon, 24 Oct 2011 08:15:09 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p9OFF5xn025675; Mon, 24 Oct 2011 10:15:06 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.165]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 24 Oct 2011 11:14:59 -0400 From: Gregory Mirsky To: Loa Andersson , "mpls@ietf.org" Date: Mon, 24 Oct 2011 11:14:58 -0400 Thread-Topic: [mpls] poll on draft-weingarten-mpls-tp-ring-protection Thread-Index: AcySVXNADEBamcPfSb+Nk6/CgMk+qQACjTSQ Message-ID: References: <4EA56F96.7040404@pi.nu> In-Reply-To: <4EA56F96.7040404@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] poll on draft-weingarten-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 15:15:10 -0000 Yes/support Regards, Greg=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Monday, October 24, 2011 7:01 AM To: mpls@ietf.org Subject: [mpls] poll on draft-weingarten-mpls-tp-ring-protection Working Group, this is to start a two week poll to see if there is support to make draft-w= eingarten-mpls-tp-ring-protection an mpls working group draft. Pleased send your comments to the mpls working group mailing list (mpls@iet= f.org). This poll ends Sun Nov 6. /Loa for the mpls wg chairs -- --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From jeff.tantsura@ericsson.com Mon Oct 24 08:40:11 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9C111E8088 for ; Mon, 24 Oct 2011 08:40:11 -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 bWYLiec3mPPd for ; Mon, 24 Oct 2011 08:40:10 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id CAC2511E807F for ; Mon, 24 Oct 2011 08:40:10 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p9OFdW9X017830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Oct 2011 10:40:07 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.232]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 24 Oct 2011 11:39:46 -0400 From: Jeff Tantsura To: Loa Andersson , "mpls@ietf.org" Date: Mon, 24 Oct 2011 11:39:45 -0400 Thread-Topic: [mpls] poll on draft-weingarten-mpls-tp-ring-protection Thread-Index: AcySVXflO3wWihpPSQuF/WpDEo+ZTAADaOcg Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF61817D743AC@EUSAACMS0701.eamcs.ericsson.se> References: <4EA56F96.7040404@pi.nu> In-Reply-To: <4EA56F96.7040404@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] poll on draft-weingarten-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 15:40:11 -0000 Yes/support -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Monday, October 24, 2011 7:01 AM To: mpls@ietf.org Subject: [mpls] poll on draft-weingarten-mpls-tp-ring-protection Working Group, this is to start a two week poll to see if there is support to make draft-w= eingarten-mpls-tp-ring-protection an mpls working group draft. Pleased send your comments to the mpls working group mailing list (mpls@iet= f.org). This poll ends Sun Nov 6. /Loa for the mpls wg chairs -- --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From yaakov_s@rad.com Mon Oct 24 09:01:53 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FBA21F8BF7 for ; Mon, 24 Oct 2011 09:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rDdoZyHC0fa for ; Mon, 24 Oct 2011 09:01:52 -0700 (PDT) Received: from rad.co.il (mailrelay01-q.rad.co.il [80.74.100.150]) by ietfa.amsl.com (Postfix) with ESMTP id C421421F8DFE for ; Mon, 24 Oct 2011 09:01:49 -0700 (PDT) Received: from Internal Mail-Server by MailRelay01 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 24 Oct 2011 17:56:51 +0200 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.01.0323.003; Mon, 24 Oct 2011 18:01:45 +0200 From: Yaakov Stein To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll on draft-weingarten-mpls-tp-ring-protection Thread-Index: AQHMklVphvuL/f5dxEqs+I9C6sNTXZWLp2JQ Date: Mon, 24 Oct 2011 16:01:44 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9040D1C4D@EXRAD5.ad.rad.co.il> References: <4EA56F96.7040404@pi.nu> In-Reply-To: <4EA56F96.7040404@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.170.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] poll on draft-weingarten-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 16:01:53 -0000 I support elevating this draft to WG status. Y(J)S -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Monday, October 24, 2011 16:01 To: mpls@ietf.org Subject: [mpls] poll on draft-weingarten-mpls-tp-ring-protection Working Group, this is to start a two week poll to see if there is support to make draft-weingarten-mpls-tp-ring-protection an mpls working group draft. Pleased send your comments to the mpls working group mailing list (mpls@ietf.org). This poll ends Sun Nov 6. /Loa for the mpls wg chairs --=20 --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From internet-drafts@ietf.org Mon Oct 24 16:56:03 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD76C21F8AF5; Mon, 24 Oct 2011 16:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 txUotpSSIbG1; Mon, 24 Oct 2011 16:56:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4932421F8AF9; Mon, 24 Oct 2011 16:56:02 -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: 3.61 Message-ID: <20111024235602.21232.87301.idtracker@ietfa.amsl.com> Date: Mon, 24 Oct 2011 16:56:02 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-li-lb-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 23:56:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : MPLS Transport Profile lock Instruct and Loopback Functi= ons Author(s) : Sami Boutros Siva Sivabalan Rahul Aggarwal Martin Vigoureux Xuehui Dai Filename : draft-ietf-mpls-tp-li-lb-08.txt Pages : 11 Date : 2011-10-24 Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are "lock" and "loopback= ". The lock function enables an operator to lock a transport path such that it does not carry client traffic, but can continue to carry OAM messages and may carry test traffic. The loopback function allows an operator to set a specific node on the transport path into loopback mode such that it returns all received data. This document specifies the lock function for MPLS networks and describes how the loopback function operates in MPLS networks. This document updates RFC 6371 section 7.1.1 and 7.1.2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-08.txt From prvs=02791c30cc=medel@globetel.com.ph Mon Oct 24 17:54:01 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22ACF21F8CD8 for ; Mon, 24 Oct 2011 17:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994] 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 8HvGDLOQ7v6s for ; Mon, 24 Oct 2011 17:54:00 -0700 (PDT) Received: from smtp01.globetel.com.ph (smtp01.globetel.com.ph [203.177.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id 4E66F21F8CD7 for ; Mon, 24 Oct 2011 17:53:59 -0700 (PDT) Received: from exgtbh01.globetel.com ([10.225.208.17]) by smtp01.globetel.com.ph (8.14.4/8.14.4) with ESMTP id p9P0rsac007670; Tue, 25 Oct 2011 08:53:56 +0800 Received: from EXVSGT02.globetel.com ([10.225.208.145]) by exgtbh01.globetel.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 08:53:54 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Oct 2011 08:53:54 +0800 Message-ID: In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [mpls] poll on draft-weingarten-mpls-tp-ring-protection Thread-index: AcySVWNBAa2Gr3p+Q0OeOlejVrg5KAAAQaNQABYQ2iA= X-Priority: 1 Priority: Urgent Importance: high References: <4EA56F96.7040404@pi.nu> From: "GT RAMIREZ, Medel G." To: "Loa Andersson" , X-OriginalArrivalTime: 25 Oct 2011 00:53:54.0910 (UTC) FILETIME=[920C97E0:01CC92B0] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-10-24_06:2011-10-25, 2011-10-24, 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-1012030000 definitions=main-1110240306 Subject: Re: [mpls] poll on draft-weingarten-mpls-tp-ring-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 00:54:01 -0000 + 1 Medel ++++++++++++++++++ -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Osborne (eosborne) Sent: Monday, October 24, 2011 10:09 PM To: Loa Andersson; mpls@ietf.org Subject: Re: [mpls] poll on draft-weingarten-mpls-tp-ring-protection Yes, support. eric > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Monday, October 24, 2011 10:01 AM > To: mpls@ietf.org > Subject: [mpls] poll on draft-weingarten-mpls-tp-ring-protection >=20 > Working Group, >=20 > this is to start a two week poll to see if there is support to make draft- > weingarten-mpls-tp-ring-protection an mpls working group draft. >=20 > Pleased send your comments to the mpls working group mailing list > (mpls@ietf.org). >=20 > This poll ends Sun Nov 6. >=20 > /Loa > for the mpls wg chairs > -- > -- >=20 >=20 > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls This e-mail message (including attachments, if any) is intended for the use= of the individual or the entity to whom it is addressed and may contain in= formation that is privileged, proprietary, confidential and exempt from dis= closure. If you are not the intended recipient, you are notified that any d= issemination, distribution or copying of this communication is strictly pro= hibited. If you have received this communication in error, please notify th= e sender and delete this E-mail message immediately. From fu.xihua@zte.com.cn Mon Oct 24 20:06:19 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC68021F8C40; Mon, 24 Oct 2011 20:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQyEy6AjHDRG; Mon, 24 Oct 2011 20:06:19 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1D43F21F8C3E; Mon, 24 Oct 2011 20:06:17 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 417132623888924; Tue, 25 Oct 2011 11:02:52 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 20387.2623888924; Tue, 25 Oct 2011 11:06:10 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p9P367m3022103; Tue, 25 Oct 2011 11:06:07 +0800 (GMT-8) (envelope-from fu.xihua@zte.com.cn) In-Reply-To: <20111008012424.15402.48430.idtracker@ietfa.amsl.com> To: mpls@ietf.org, ccamp@ietf.org, ospf@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: fu.xihua@zte.com.cn Date: Tue, 25 Oct 2011 11:06:08 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-25 11:06:09, Serialize complete at 2011-10-25 11:06:09 Content-Type: multipart/alternative; boundary="=_alternative 00110BAC48257934_=" X-MAIL: mse02.zte.com.cn p9P367m3022103 Subject: Re: [mpls] I-D Action: draft-fuxh-mpls-delay-loss-te-framework-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 03:06:20 -0000 This is a multipart message in MIME format. --=_alternative 00110BAC48257934_= Content-Type: text/plain; charset="US-ASCII" Hi All, We updated this delay-loss-te framework document. We want to request it as WG document in the future. If you have any comments, please let me know. Please also notice there some several protocol extension to support delay-loss-te. http://tools.ietf.org/html/draft-fuxh-mpls-delay-loss-rsvp-te-ext-00 http://www.ietf.org/id/draft-atlas-mpls-te-express-path-00.txt http://tools.ietf.org/html/draft-giacalone-ospf-te-express-path-02 http://tools.ietf.org/html/draft-previdi-isis-te-metric-extensions-00 Xihua Fu i-d-announce-bounces@ietf.org wrote 2011-10-08 09:24:24: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Traffic Engineering architecture for services aware MPLS > Author(s) : Xihua Fu > Vishwas Manral > Dave McDysan > Andrew Malis > Spencer Giacalone > Malcolm Betts > Qilei Wang > John Drake > Filename : draft-fuxh-mpls-delay-loss-te-framework-02.txt > Pages : 14 > Date : 2011-10-07 > > With more and more enterprises using cloud based services, the > distances between the user and the applications are growing. A lot > of the current applications are designed to work across LAN's and > have various inherent assumptions. For multiple applications such as > High Performance Computing and Electronic Financial markets, the > response times are critical as is packet loss, while other > applications require more throughput. > > [RFC3031] describes the architecture of MPLS based networks. This > draft extends the MPLS architecture to allow for latency, loss and > jitter as properties. It describes requirements and control plane > implication for latency and packet loss as a traffic engineering > performance metric in today's network which is consisting of > potentially multiple layers of packet transport network and optical > transport network in order to make a accurate end-to-end latency and > loss prediction before a path is established. > > Note MPLS architecture for Multicast will be taken up in a future > version of the draft. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-fuxh-mpls-delay-loss-te- > framework-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-fuxh-mpls-delay-loss-te- > framework-02.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > --=_alternative 00110BAC48257934_= Content-Type: text/html; charset="US-ASCII"
Hi All,

We updated this delay-loss-te framework document.
We want to request it as WG document in the future. If you have any comments, please let me know.

Please also notice there some several protocol extension to support delay-loss-te.
http://tools.ietf.org/html/draft-fuxh-mpls-delay-loss-rsvp-te-ext-00
http://www.ietf.org/id/draft-atlas-mpls-te-express-path-00.txt
http://tools.ietf.org/html/draft-giacalone-ospf-te-express-path-02
http://tools.ietf.org/html/draft-previdi-isis-te-metric-extensions-00

Xihua Fu


i-d-announce-bounces@ietf.org wrote 2011-10-08 09:24:24:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>    Title           : Traffic Engineering architecture for services aware MPLS
>    Author(s)       : Xihua Fu
>                           Vishwas Manral
>                           Dave McDysan
>                           Andrew Malis
>                           Spencer Giacalone
>                           Malcolm Betts
>                           Qilei Wang
>                           John Drake
>    Filename        : draft-fuxh-mpls-delay-loss-te-framework-02.txt
>    Pages           : 14
>    Date            : 2011-10-07
>
>    With more and more enterprises using cloud based services, the
>    distances between the user and the applications are growing.  A lot
>    of the current applications are designed to work across LAN&#39;s and
>    have various inherent assumptions.  For multiple applications such as
>    High Performance Computing and Electronic Financial markets, the
>    response times are critical as is packet loss, while other
>    applications require more throughput.
>
>    [RFC3031] describes the architecture of MPLS based networks.  This
>    draft extends the MPLS architecture to allow for latency, loss and
>    jitter as properties.  It describes requirements and control plane
>    implication for latency and packet loss as a traffic engineering
>    performance metric in today&#39;s network which is consisting of
>    potentially multiple layers of packet transport network and optical
>    transport network in order to make a accurate end-to-end latency and
>    loss prediction before a path is established.
>
>    Note MPLS architecture for Multicast will be taken up in a future
>    version of the draft.
>
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-fuxh-mpls-delay-loss-te-
> framework-02.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-fuxh-mpls-delay-loss-te-
> framework-02.txt
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
--=_alternative 00110BAC48257934_=-- From he.wenjuan1@zte.com.cn Tue Oct 25 00:51:30 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E3021F8A69 for ; Tue, 25 Oct 2011 00:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 Mj0BXLkDGVDY for ; Tue, 25 Oct 2011 00:51:29 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id EA6A621F8A67 for ; Tue, 25 Oct 2011 00:51:28 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 46621806486374; Tue, 25 Oct 2011 15:43:11 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 41537.1180738496; Tue, 25 Oct 2011 15:51:13 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p9P7pCmi041204; Tue, 25 Oct 2011 15:51:12 +0800 (GMT-8) (envelope-from he.wenjuan1@zte.com.cn) In-Reply-To: <4EA56F96.7040404@pi.nu> To: Loa Andersson , "mpls@ietf.org" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: he.wenjuan1@zte.com.cn Date: Tue, 25 Oct 2011 15:51:11 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-25 15:51:14, Serialize complete at 2011-10-25 15:51:14 Content-Type: multipart/alternative; boundary="=_alternative 002B647A48257934_=" X-MAIL: mse02.zte.com.cn p9P7pCmi041204 Subject: [mpls] =?gb2312?b?tPC4tDogIHBvbGwgb24gZHJhZnQtd2VpbmdhcnRlbi1t?= =?gb2312?b?cGxzLXRwLXJpbmctcHJvdGVjdGlvbg==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 07:51:30 -0000 This is a multipart message in MIME format. --=_alternative 002B647A48257934_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 WWVzL3N1cHBvcnQNCg0KDQpXZW5qdWFuDQoNCg0KDQoNCkxvYSBBbmRlcnNzb24gPGxvYUBwaS5u dT4gDQq3orz+yMs6ICBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTEtMTAtMjQgMjI6MDANCg0K ytW8/sjLDQoibXBsc0BpZXRmLm9yZyIgPG1wbHNAaWV0Zi5vcmc+DQqzrcvNDQoNCtb3zOINCltt cGxzXSBwb2xsIG9uIGRyYWZ0LXdlaW5nYXJ0ZW4tbXBscy10cC1yaW5nLXByb3RlY3Rpb24NCg0K DQoNCg0KDQoNCldvcmtpbmcgR3JvdXAsDQoNCnRoaXMgaXMgdG8gc3RhcnQgYSB0d28gd2VlayBw b2xsIHRvIHNlZSBpZiB0aGVyZSBpcyBzdXBwb3J0IHRvIG1ha2UNCmRyYWZ0LXdlaW5nYXJ0ZW4t bXBscy10cC1yaW5nLXByb3RlY3Rpb24gYW4gbXBscyB3b3JraW5nIGdyb3VwIGRyYWZ0Lg0KDQpQ bGVhc2VkIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbXBscyB3b3JraW5nIGdyb3VwIG1haWxp bmcgbGlzdA0KKG1wbHNAaWV0Zi5vcmcpLg0KDQpUaGlzIHBvbGwgZW5kcyBTdW4gTm92IDYuDQoN Ci9Mb2ENCmZvciB0aGUgbXBscyB3ZyBjaGFpcnMNCi0tIA0KLS0gDQoNCg0KTG9hIEFuZGVyc3Nv biAgICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5j b20NClNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAgICAgICAgICAgIGxvYUBwaS5u dQ0KRXJpY3Nzb24gSW5jICAgICAgICAgICAgICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEwIDcx NyA1MiAxMw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICs0 NiA3NjcgNzIgOTIgMTMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0KDQo= --=_alternative 002B647A48257934_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5ZZXMvc3VwcG9ydDwvdHQ+PC9mb250Pg0KPGJyPg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XZW5qdWFuPC9mb250Pg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkxvYSBBbmRl cnNzb24gJmx0O2xvYUBwaS5udSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7bXBscy1ib3VuY2VzQGlldGYub3JnPC9mb250 Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMTAtMjQgMjI6MDA8L2Zv bnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrV vP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1 b3Q7bXBsc0BpZXRmLm9yZyZxdW90OyAmbHQ7bXBsc0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2Zv bnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlttcGxzXSBwb2xs IG9uIGRyYWZ0LXdlaW5nYXJ0ZW4tbXBscy10cC1yaW5nLXByb3RlY3Rpb248L2ZvbnQ+PC90YWJs ZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8 YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PldvcmtpbmcgR3Jv dXAsPGJyPg0KPGJyPg0KdGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHBvbGwgdG8gc2VlIGlm IHRoZXJlIGlzIHN1cHBvcnQgdG8gbWFrZTxicj4NCmRyYWZ0LXdlaW5nYXJ0ZW4tbXBscy10cC1y aW5nLXByb3RlY3Rpb24gYW4gbXBscyB3b3JraW5nIGdyb3VwIGRyYWZ0Ljxicj4NCjxicj4NClBs ZWFzZWQgc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdvcmtpbmcgZ3JvdXAgbWFpbGlu ZyBsaXN0PGJyPg0KKG1wbHNAaWV0Zi5vcmcpLjxicj4NCjxicj4NClRoaXMgcG9sbCBlbmRzIFN1 biBOb3YgNi48YnI+DQo8YnI+DQovTG9hPGJyPg0KZm9yIHRoZSBtcGxzIHdnIGNoYWlyczxicj4N Ci0tIDxicj4NCi0tIDxicj4NCjxicj4NCjxicj4NCkxvYSBBbmRlcnNzb24gJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgJm5ic3A7IGVtYWlsOiBsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbTxicj4NClNy IFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2xvYUBwaS5udTxicj4NCkVyaWNzc29uIEluYyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGhvbmU6ICs0NiAxMCA3MTcgNTIgMTM8YnI+DQogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7KzQ2IDc2NyA3MiA5MiAx Mzxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQptcGxzQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPGJyPg0KPGJyPg0KPC90dD48L2ZvbnQ+DQo8 YnI+DQo= --=_alternative 002B647A48257934_=-- From adrian@olddog.co.uk Tue Oct 25 10:22:37 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E7221F8C2B for ; Tue, 25 Oct 2011 10:22:37 -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=[AWL=0.000, 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 w6AIE4kM0qzx for ; Tue, 25 Oct 2011 10:22:36 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9B61D21F8C0F for ; Tue, 25 Oct 2011 10:22:36 -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 p9PHMY6J025427; Tue, 25 Oct 2011 18:22:35 +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 p9PHMXtQ025408 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Oct 2011 18:22:34 +0100 From: "Adrian Farrel" To: Date: Tue, 25 Oct 2011 18:22:35 +0100 Message-ID: <01e601cc933a$b0398e50$10acaaf0$@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: AcyTOf0HPM1x/l0+RJWAOgPyfDzyGA== Content-Language: en-gb Cc: draft-ietf-mpls-ldp-iana@tools.ietf.org Subject: [mpls] draft-ietf-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 17:22:37 -0000 Hi WG, I started my review of this document and have a fairly fundamental question for the WG. The document looks at the IANA registries for LDP and compares with the protocol spec (RFC5036). It observes that there are some fields in the protocol spec marked as "reserved" and that there is no clear statement of how those fields can be used in future protocol extensions. The problem I am having is that the fields are reserved, not unassigned. If they were named fields with known uses (e.g. bit fields) it would make sense to define an assignment policy, say that the fields are currently unassigned, and use the combination of the IESG and the IANA to police future use. But what I think you are trying to do is state what the RFC means by "reserved". That is a fine thing to do in a draft if you believe it is necessary (I would note that no-one has previously found it to be necessary, but reserved fields are often scoped as MBZ to allow future extensibility). In practice, a field that is "reserved" in a standards track RFC is, well, erm, reserved. You can't suddenly start using the field without an RFC. (Just as you could not change a message format to add another field.) However, you cannot use IANA to police reserved fields. IANA manages code point registries, not protocol behavior. What you are effectively doing in this I-D is creating a negative assignment: you are asking IANA to not create a new registry for a protocol field (as yet unknown) in a specific spot in a certain TLV or message. That's hard for IANA because they don't care where or how their registries are encoded in messages. indeed, Some registries are used in multiple protocol fields. To say it another way, I read the document as saying "Ooops, we defined a couple of fields that people might start making allocations from, but which don't have IANA registries." But what I sense is actually the intention is "Hmmm, there are some reserved fields and we would like to control how those fields might get used in the future." So, coming back again to what I think it is you want to achieve: should this document simply be an update to 5036 that says "The following fields that are marked as 'reserved' in [RFC5036] are not to be used for new protocol mechanisms except through RFCs that achieve IETF consensus." And finally, my question. What is this document *really* trying to achieve? Why do you actually need it? There is one exception to all of this. The Len field of the Frame Relay Label TLV could have a registry defined. Thanks, Adrian From cpignata@cisco.com Tue Oct 25 10:44:54 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD3121F8A97 for ; Tue, 25 Oct 2011 10:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.444 X-Spam-Level: X-Spam-Status: No, score=-105.444 tagged_above=-999 required=5 tests=[AWL=1.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xu24m7vHtSMy for ; Tue, 25 Oct 2011 10:44:53 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7075B21F8A57 for ; Tue, 25 Oct 2011 10:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=3257; q=dns/txt; s=iport; t=1319564693; x=1320774293; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=zAh2YNQ2m0MR+lqlqWHBmDTYC7mfxZjkc1wlvdvkjfs=; b=MufaMRxBu8SB5kzl1nMyC3wWOvoZoUXKtp5ryhUTwyMK535ipwi1+hUG q0eXsoCl47ckYWVkzBYs51P+NDT0UgXTs3hAC7wVHckhICHgHnJWahOmb i7KmhYb3tc9Ym/8juCUwX/bhxyx+C2rTCX3IK2afSpkoHz1sE3XbKevOk 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAAABf1pk6tJXG9/2dsb2JhbABCmVaPQ4EFgW4BAQEEEgEdCj8MBAIBCBEEAQELBhcBBgFFCQgBAQQBEgganVgBnmaHdWEEiAaROYxH X-IronPort-AV: E=Sophos;i="4.69,404,1315180800"; d="scan'208";a="30905533" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 25 Oct 2011 17:44:53 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9PHiqI8030895; Tue, 25 Oct 2011 17:44:52 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 12:44:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Oct 2011 12:44:51 -0500 Message-ID: <960EC8F9A775AB40BF58D8953342D863069A9909@XMB-RCD-206.cisco.com> In-Reply-To: <01e601cc933a$b0398e50$10acaaf0$@olddog.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-mpls-ldp-iana Thread-Index: AcyTOf0HPM1x/l0+RJWAOgPyfDzyGAAAySLg References: <01e601cc933a$b0398e50$10acaaf0$@olddog.co.uk> From: "Carlos Pignataro (cpignata)" To: , X-OriginalArrivalTime: 25 Oct 2011 17:44:52.0838 (UTC) FILETIME=[CCFDE060:01CC933D] Cc: draft-ietf-mpls-ldp-iana@tools.ietf.org Subject: Re: [mpls] draft-ietf-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 17:44:54 -0000 Adrian, The one-liner response to your "Why do you actually need it?", more later: for draft-ietf-mpls-ldp-gtsm, we need to assign a bit in the Common Hello Parameter TLV for which there is no allocation policy -- that's the whole motivation. WG consensus was to, since we are doing that, we might as well proactively fill in all the gaps in RFC 5036.=20 Hope that clarifies, -- Carlos. =09 -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Tuesday, October 25, 2011 1:23 PM To: mpls@ietf.org Cc: draft-ietf-mpls-ldp-iana@tools.ietf.org Subject: draft-ietf-mpls-ldp-iana Hi WG,=20 I started my review of this document and have a fairly fundamental question for the WG. The document looks at the IANA registries for LDP and compares with the protocol spec (RFC5036). It observes that there are some fields in the protocol spec marked as "reserved" and that there is no clear statement of how those fields can be used in future protocol extensions. The problem I am having is that the fields are reserved, not unassigned. If they were named fields with known uses (e.g. bit fields) it would make sense to define an assignment policy, say that the fields are currently unassigned, and use the combination of the IESG and the IANA to police future use. But what I think you are trying to do is state what the RFC means by "reserved". That is a fine thing to do in a draft if you believe it is necessary (I would note that no-one has previously found it to be necessary, but reserved fields are often scoped as MBZ to allow future extensibility). In practice, a field that is "reserved" in a standards track RFC is, well, erm, reserved. You can't suddenly start using the field without an RFC. (Just as you could not change a message format to add another field.) However, you cannot use IANA to police reserved fields. IANA manages code point registries, not protocol behavior. What you are effectively doing in this I-D is creating a negative assignment: you are asking IANA to not create a new registry for a protocol field (as yet unknown) in a specific spot in a certain TLV or message. That's hard for IANA because they don't care where or how their registries are encoded in messages. indeed, Some registries are used in multiple protocol fields. To say it another way, I read the document as saying "Ooops, we defined a couple of fields that people might start making allocations from, but which don't have IANA registries." But what I sense is actually the intention is "Hmmm, there are some reserved fields and we would like to control how those fields might get used in the future." So, coming back again to what I think it is you want to achieve: should this document simply be an update to 5036 that says "The following fields that are marked as 'reserved' in [RFC5036] are not to be used for new protocol mechanisms except through RFCs that achieve IETF consensus." And finally, my question. What is this document *really* trying to achieve? Why do you actually need it? =09 There is one exception to all of this. The Len field of the Frame Relay Label TLV could have a registry defined. Thanks, Adrian From cpignata@cisco.com Tue Oct 25 10:50:57 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9A021F8586 for ; Tue, 25 Oct 2011 10:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.733 X-Spam-Level: X-Spam-Status: No, score=-105.733 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMCEopAc7jIl for ; Tue, 25 Oct 2011 10:50:56 -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 75F0521F8569 for ; Tue, 25 Oct 2011 10:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=3070; q=dns/txt; s=iport; t=1319565056; x=1320774656; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=9YNkWk2vtihkTU0qzoVd8Y0DVY9/nuPM8GjYkUfAeMQ=; b=PXhVracxcjP45RS0wco5Bl7dJZvDQZrQqzXv0ubP3YmCsZu99BnT/nuP KenV0HCjZdYL7RZZaq9XGKBSi2+rQXdapVK9RF4hdxHEqeu9+S62xindw UAsmPU/6OPvlexw0Yb0JYE70rDetYZ6b3sKSGq55yHUoqvi8lQ3TayhnN Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAAANb1pk6tJXHB/2dsb2JhbABCmVaPQ4EFgW4BAQEEEgEdCj8MBAIBCBEEAQELBhcBBgFFCQgBAQQBEgganVIBnmiHdWEEiAaROYxH X-IronPort-AV: E=Sophos;i="4.69,404,1315180800"; d="scan'208";a="30902315" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 25 Oct 2011 17:50:56 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p9PHottX016000; Tue, 25 Oct 2011 17:50:55 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 12:50:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Oct 2011 12:50:54 -0500 Message-ID: <960EC8F9A775AB40BF58D8953342D863069A9916@XMB-RCD-206.cisco.com> In-Reply-To: <01e601cc933a$b0398e50$10acaaf0$@olddog.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-mpls-ldp-iana Thread-Index: AcyTOf0HPM1x/l0+RJWAOgPyfDzyGAABDiRQ References: <01e601cc933a$b0398e50$10acaaf0$@olddog.co.uk> From: "Carlos Pignataro (cpignata)" To: , X-OriginalArrivalTime: 25 Oct 2011 17:50:55.0572 (UTC) FILETIME=[A532B140:01CC933E] Cc: draft-ietf-mpls-ldp-iana@tools.ietf.org Subject: Re: [mpls] draft-ietf-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 17:50:57 -0000 Adrian, BTW: The distinction between the Unassigned and Reserved labels appears in RFC 5226, which published after RFC 5036. RFC 5036 points to RFC 2434, which lacks that distinction. Thanks, -- Carlos.=20 -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Tuesday, October 25, 2011 1:23 PM To: mpls@ietf.org Cc: draft-ietf-mpls-ldp-iana@tools.ietf.org Subject: draft-ietf-mpls-ldp-iana Hi WG,=20 I started my review of this document and have a fairly fundamental question for the WG. The document looks at the IANA registries for LDP and compares with the protocol spec (RFC5036). It observes that there are some fields in the protocol spec marked as "reserved" and that there is no clear statement of how those fields can be used in future protocol extensions. The problem I am having is that the fields are reserved, not unassigned. If they were named fields with known uses (e.g. bit fields) it would make sense to define an assignment policy, say that the fields are currently unassigned, and use the combination of the IESG and the IANA to police future use. But what I think you are trying to do is state what the RFC means by "reserved". That is a fine thing to do in a draft if you believe it is necessary (I would note that no-one has previously found it to be necessary, but reserved fields are often scoped as MBZ to allow future extensibility). In practice, a field that is "reserved" in a standards track RFC is, well, erm, reserved. You can't suddenly start using the field without an RFC. (Just as you could not change a message format to add another field.) However, you cannot use IANA to police reserved fields. IANA manages code point registries, not protocol behavior. What you are effectively doing in this I-D is creating a negative assignment: you are asking IANA to not create a new registry for a protocol field (as yet unknown) in a specific spot in a certain TLV or message. That's hard for IANA because they don't care where or how their registries are encoded in messages. indeed, Some registries are used in multiple protocol fields. To say it another way, I read the document as saying "Ooops, we defined a couple of fields that people might start making allocations from, but which don't have IANA registries." But what I sense is actually the intention is "Hmmm, there are some reserved fields and we would like to control how those fields might get used in the future." So, coming back again to what I think it is you want to achieve: should this document simply be an update to 5036 that says "The following fields that are marked as 'reserved' in [RFC5036] are not to be used for new protocol mechanisms except through RFCs that achieve IETF consensus." And finally, my question. What is this document *really* trying to achieve? Why do you actually need it?=20 There is one exception to all of this. The Len field of the Frame Relay Label TLV could have a registry defined. Thanks, Adrian From adrian@olddog.co.uk Tue Oct 25 10:58:41 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F4E21F8BE7 for ; Tue, 25 Oct 2011 10:58:41 -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=[AWL=0.000, 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 YXD76AliXbxh for ; Tue, 25 Oct 2011 10:58:40 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 6522121F8BC5 for ; Tue, 25 Oct 2011 10:58:40 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p9PHwZee005245; Tue, 25 Oct 2011 18:58:35 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p9PHwYmp005237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Oct 2011 18:58:35 +0100 From: "Adrian Farrel" To: "'Carlos Pignataro \(cpignata\)'" , References: <01e601cc933a$b0398e50$10acaaf0$@olddog.co.uk> <960EC8F9A775AB40BF58D8953342D863069A9909@XMB-RCD-206.cisco.com> In-Reply-To: <960EC8F9A775AB40BF58D8953342D863069A9909@XMB-RCD-206.cisco.com> Date: Tue, 25 Oct 2011 18:58:35 +0100 Message-ID: <01f401cc933f$b827caa0$28775fe0$@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: AQJOKzfkvbQ2Pb19199bAGMoz0M0kAMdy4nglHE4JqA= Content-Language: en-gb Cc: draft-ietf-mpls-ldp-iana@tools.ietf.org Subject: Re: [mpls] draft-ietf-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 17:58:41 -0000 I understand, Carlos. Ask yourself the question whether the field in the TLV marked "reserved" is already a bit field? If it is, you are right to want to define the allocation policy and establish a registry. If it is not (but is simply a reserved field) then you have to decide whether you are allocating a new protocol field from the reserved portion of the TLV, or are redefining the whole reserved field as a bit field. You might help yourself to consider the question by considering what you would have done had you needed an 8-bit integer, not a flag. Could you have defined this from the reserved part of the TLV? Answer the question before you dreamed of draft-ietf-mpls-ldp-gtsm, and afterwards. Cheers, Adrian > -----Original Message----- > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > Sent: 25 October 2011 18:45 > To: adrian@olddog.co.uk; mpls@ietf.org > Cc: draft-ietf-mpls-ldp-iana@tools.ietf.org > Subject: RE: draft-ietf-mpls-ldp-iana > > Adrian, > > The one-liner response to your "Why do you actually need it?", more > later: for draft-ietf-mpls-ldp-gtsm, we need to assign a bit in the > Common Hello Parameter TLV for which there is no allocation policy -- > that's the whole motivation. WG consensus was to, since we are doing > that, we might as well proactively fill in all the gaps in RFC 5036. > > Hope that clarifies, > > -- Carlos. > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, October 25, 2011 1:23 PM > To: mpls@ietf.org > Cc: draft-ietf-mpls-ldp-iana@tools.ietf.org > Subject: draft-ietf-mpls-ldp-iana > > Hi WG, > > I started my review of this document and have a fairly fundamental > question for > the WG. > > The document looks at the IANA registries for LDP and compares with the > protocol > spec (RFC5036). It observes that there are some fields in the protocol > spec > marked as "reserved" and that there is no clear statement of how those > fields > can be used in future protocol extensions. > > The problem I am having is that the fields are reserved, not unassigned. > If they > were named fields with known uses (e.g. bit fields) it would make sense > to > define an assignment policy, say that the fields are currently > unassigned, and > use the combination of the IESG and the IANA to police future use. > > But what I think you are trying to do is state what the RFC means by > "reserved". > That is a fine thing to do in a draft if you believe it is necessary (I > would > note that no-one has previously found it to be necessary, but reserved > fields > are often scoped as MBZ to allow future extensibility). In practice, a > field > that is "reserved" in a standards track RFC is, well, erm, reserved. You > can't > suddenly start using the field without an RFC. (Just as you could not > change a > message format to add another field.) > > However, you cannot use IANA to police reserved fields. IANA manages > code point > registries, not protocol behavior. What you are effectively doing in > this I-D is > creating a negative assignment: you are asking IANA to not create a new > registry > for a protocol field (as yet unknown) in a specific spot in a certain > TLV or > message. That's hard for IANA because they don't care where or how their > registries are encoded in messages. indeed, Some registries are used in > multiple > protocol fields. > > To say it another way, I read the document as saying "Ooops, we defined > a couple > of fields that people might start making allocations from, but which > don't have IANA registries." But what I sense is actually the intention > is > "Hmmm, there are some reserved fields and we would like to control how > those > fields might get used in the future." > > So, coming back again to what I think it is you want to achieve: should > this > document simply be an update to 5036 that says "The following fields > that > are marked as 'reserved' in [RFC5036] are not to be used for new > protocol > mechanisms except through RFCs that achieve IETF consensus." > > And finally, my question. What is this document *really* trying to > achieve? Why > do you actually need it? > > There is one exception to all of this. The Len field of the Frame Relay > Label > TLV could have a registry defined. > > Thanks, > Adrian From adrian@olddog.co.uk Tue Oct 25 11:03:49 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740D821F8BFE for ; Tue, 25 Oct 2011 11:03:49 -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=[AWL=0.000, 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 NrPOgZhYyZ7r for ; Tue, 25 Oct 2011 11:03:48 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 87F5221F8AFA for ; Tue, 25 Oct 2011 11:03:48 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p9PI3jvM007325; Tue, 25 Oct 2011 19:03:45 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p9PI3fNT007295 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Oct 2011 19:03:45 +0100 From: "Adrian Farrel" To: "'Carlos Pignataro \(cpignata\)'" , References: <01e601cc933a$b0398e50$10acaaf0$@olddog.co.uk> <960EC8F9A775AB40BF58D8953342D863069A9916@XMB-RCD-206.cisco.com> In-Reply-To: <960EC8F9A775AB40BF58D8953342D863069A9916@XMB-RCD-206.cisco.com> Date: Tue, 25 Oct 2011 19:03:42 +0100 Message-ID: <01f501cc9340$70d29260$5277b720$@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: AQJOKzfkvbQ2Pb19199bAGMoz0M0kAHQHX2blHuoaJA= Content-Language: en-gb Cc: draft-ietf-mpls-ldp-iana@tools.ietf.org Subject: Re: [mpls] draft-ietf-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 18:03:49 -0000 I think you are mistaking the assignment policy "reserved" defined in 5226, with a field in a protocol element that is labelled as "reserved". The former is how a code point is described in a registry. The latter is how a field that has no associated use or registry is described in an RFC. Adrian > -----Original Message----- > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > Sent: 25 October 2011 18:51 > To: adrian@olddog.co.uk; mpls@ietf.org > Cc: draft-ietf-mpls-ldp-iana@tools.ietf.org > Subject: RE: draft-ietf-mpls-ldp-iana > > Adrian, > > BTW: The distinction between the Unassigned and Reserved labels appears > in RFC 5226, which published after RFC 5036. RFC 5036 points to RFC > 2434, which lacks that distinction. > > Thanks, > > -- Carlos. > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, October 25, 2011 1:23 PM > To: mpls@ietf.org > Cc: draft-ietf-mpls-ldp-iana@tools.ietf.org > Subject: draft-ietf-mpls-ldp-iana > > Hi WG, > > I started my review of this document and have a fairly fundamental > question for > the WG. > > The document looks at the IANA registries for LDP and compares with the > protocol > spec (RFC5036). It observes that there are some fields in the protocol > spec > marked as "reserved" and that there is no clear statement of how those > fields > can be used in future protocol extensions. > > The problem I am having is that the fields are reserved, not unassigned. > If they > were named fields with known uses (e.g. bit fields) it would make sense > to > define an assignment policy, say that the fields are currently > unassigned, and > use the combination of the IESG and the IANA to police future use. > > But what I think you are trying to do is state what the RFC means by > "reserved". > That is a fine thing to do in a draft if you believe it is necessary (I > would > note that no-one has previously found it to be necessary, but reserved > fields > are often scoped as MBZ to allow future extensibility). In practice, a > field > that is "reserved" in a standards track RFC is, well, erm, reserved. You > can't > suddenly start using the field without an RFC. (Just as you could not > change a > message format to add another field.) > > However, you cannot use IANA to police reserved fields. IANA manages > code point > registries, not protocol behavior. What you are effectively doing in > this I-D is > creating a negative assignment: you are asking IANA to not create a new > registry > for a protocol field (as yet unknown) in a specific spot in a certain > TLV or > message. That's hard for IANA because they don't care where or how their > registries are encoded in messages. indeed, Some registries are used in > multiple > protocol fields. > > To say it another way, I read the document as saying "Ooops, we defined > a couple > of fields that people might start making allocations from, but which > don't have IANA registries." But what I sense is actually the intention > is > "Hmmm, there are some reserved fields and we would like to control how > those > fields might get used in the future." > > So, coming back again to what I think it is you want to achieve: should > this > document simply be an update to 5036 that says "The following fields > that > are marked as 'reserved' in [RFC5036] are not to be used for new > protocol > mechanisms except through RFCs that achieve IETF consensus." > > And finally, my question. What is this document *really* trying to > achieve? Why > do you actually need it? > > There is one exception to all of this. The Len field of the Frame Relay > Label > TLV could have a registry defined. > > Thanks, > Adrian From lberger@labn.net Tue Oct 25 13:41:26 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC99221F8726 for ; Tue, 25 Oct 2011 13:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.727 X-Spam-Level: X-Spam-Status: No, score=-98.727 tagged_above=-999 required=5 tests=[AWL=-1.016, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8N9K+FgrtPq for ; Tue, 25 Oct 2011 13:41:26 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id B5E2E21F8677 for ; Tue, 25 Oct 2011 13:41:25 -0700 (PDT) Received: (qmail 1126 invoked by uid 0); 25 Oct 2011 20:41:25 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 25 Oct 2011 20:41:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=M1Zn7jISRZrMW+UQm5BsxbSw8ohs//0cGg7Awab4HcM=; b=lyECNwKrhsYMcDYAV5hj3zKP1iHlecgQgPw2mmapAfNsaItP8a7koWqXB6wn3j2p1A574Glq2gUzTctjnaLwgdPe6dW0DeQsyCKbd1a5pvs0V7WGTEJKAU8loLjz8tWf; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RInoK-0002sq-O1; Tue, 25 Oct 2011 14:41:25 -0600 Message-ID: <4EA71EF5.5060908@labn.net> Date: Tue, 25 Oct 2011 16:41:25 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: zhang.fei3@zte.com.cn References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "mpls@ietf.org" , "ccamp@ietf.org" , Jaihari Kalijanakiraman Subject: Re: [mpls] [CCAMP] Request comments on draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 20:41:26 -0000 Fei, On 10/20/2011 9:04 PM, zhang.fei3@zte.com.cn wrote: > > Hi Jaihari > > As to the associated bidirectional LSP, the binding is based on the > Extended Association object, which is defined in the draft > http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-00. > > A new Association Type is introduced in another draft*, > *http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-02. > > Based on the association type "associated bidirectional LSP", two > reverse unidirectional LSPs can form the assoicated bidirectional LSP. > > However, according to the usage of this object, see the description of > the section 2.3.1 in the draft > http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-00, "no > associations are made across Path and Resv state". > > That indicates that the Association object or Extended Association > object can not be used to carry back the local assigned tunnel number in > the context of corouted bidirectional LSP. sure, it *could*, but agree that this isn't the way to go. (Although such usage might be better than allocating a new top-level object for this purpose!) > > That is the history why a new Connection object is introduced here for > the co-routed bidirectional LSP. If all this draft is really about is providing the RFC6370 Z9 (egress) Tunnel_Num, why not just define a new LSP Attributes TLV and carry it there (in Resv messages of co-routed bidirectional LSPs)? New top-level RSVP objects are a *bid* deal as the number space is so small. Lou > > Be glad to share my opinion on this subject. > > Best regards > > Fei > > > > *Jaihari Kalijanakiraman * > > 2011-10-20 23:40 > > > ÊÕ¼þÈË > zhang.fei3@zte.com.cn > ³­ËÍ > "ccamp@ietf.org" , "mpls@ietf.org" > Ö÷Ìâ > Re: [mpls] Request comments on > draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00 > > > > > > > > > Hi Zhang, > > Thanks for the clarification. > > Sorry I misunderstood. > > I have a question here.. > > You mentioned "As to the associated bidirectional LSP, there are two > independent signaling procedures for the forward and backward > directional LSPs".. > > So for associated bidirectional LSPs the two endpoints should have an > association or binding between the forward and reverse tunnels. > > So if the forward and reverse directional LSPs are independently > signaled, how the binding or association will be established between them.. > > When I read the draft, initially thought that this connection object > will be used to establish that binding or association... > > Is there a way to establish this binding already.. Please clarify.. > > Cant we use this object to establish that binding?? > > Thanks again, for your kind reply... > > > /Thanks & Regards,/ > /Jai Hari M.K./ > /IP Infusion/ > > 2011/10/20 <_zhang.fei3@zte.com.cn_ > > > Hi Jaihari > > Thanks for your comments. :-) > > This draft is about how to carry the local assigned tunnel number of > co-routed bidirectional LSP, sorry I do not describe it clearly in the > mail. > > According to the description in section 5.2.1 of the RFC6370, the LSP > number keeps the same under the context of A1 and Z9's tunnel numbers: > > A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num > > So only the tunnel number assigned by the destination node is missing. > > As to the associated bidirectional LSP, there are two independent > signaling procedures for the forward and backward directional LSPs, and > the A1 and Z9 > know each other the assigned tunnel number and LSP number. > > Furthermore, the Global_ID is also needed if the LSP is across different > ASs, which may be added in next version. > > Your comments are welcome. > > Best regards > > Fei > > *Jaihari Kalijanakiraman <**_jaiharik@ipinfusion.com_* > *>* > > 2011-10-20 15:22 > > > ÊÕ¼þÈË > _zhang.fei3@zte.com.cn_ > ³­ËÍ > "_mpls@ietf.org_ " <_mpls@ietf.org_ > > > Ö÷Ìâ > Re: [mpls] Request comments on > draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00 > > > > > > > > > > > > > On Thu, Oct 20, 2011 at 12:50 PM, Jaihari Kalijanakiraman > <_jaiharik@ipinfusion.com_ > wrote: > Hi Zhang, > > I have a question. > > The connection object in the draft has only destination tunnel number. > > But as per TP Identifiers RFC 6370, > * > > > 5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers* > > A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}:: > Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num} > > > So I think the connection object should also include the destination LSP > number also. > > Please comment.. > > / > Thanks & Regards,/ / > Jai Hari M.K. > IP Infusion/ > > > Date: Mon, 17 Oct 2011 19:08:51 +0800 > From: _zhang.fei3@zte.com.cn_ > To: "_ccamp@ietf.org_ " <_ccamp@ietf.org_ > >, "_mpls@ietf.org_ " > <_mpls@ietf.org_ > > Subject: [mpls] Request comments on > draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00 > Message-ID: > > <_OF3E7FD488.405BF0C5-ON4825792C.00351CBE-4825792C.003D3BA7@zte.com.cn_ > > > Content-Type: text/plain; charset="us-ascii" > > Hi all > > We've submitted a draft for the group's consideration, below is the link:_ > __http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00_. > > This draft is about the supporting of MPLS-TP Maintenance Identifiers. As > described in _http://tools.ietf.org/html/rfc6370_, at each end point, a > tunnel is uniquely identified by the end point's Node_ID and a locally > assigned tunnel number, which allow a compact form for the MEP_ID, and > extensions will be required to GMPLS to support these identifiers. > Furthermore, _http://tools.ietf.org/html/rfc6373_ addressed this issue in > section 4.4.8. > > Obviously, this issue can be solved by defining a new object, such as > Connection Object as described in this draft, or a new sub-TLV call MEP_ID > can be carried back to the ingress LSR in Resv message when the "CV" flag > of the OAM Function Flags Sub-TLV is set, which may be considered in the > subsequent version of the draft_ > __http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-06_. > > We hope you'll find the time to look through the draft and comment on the > list, help judge which way is more suitable before the WG meeting in > Taipei, and hope that we'll be able to have a fruitful and lively > discussion there. > > > Best, > > Fei > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From iesg-secretary@ietf.org Tue Oct 25 15:59:39 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662D121F8B2A; Tue, 25 Oct 2011 15:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 fPJhmLqCouNp; Tue, 25 Oct 2011 15:59:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D520621F8B2D; Tue, 25 Oct 2011 15:59:38 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111025225938.14470.50705.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2011 15:59:38 -0700 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'MPLS Transport Profile lock Instruct and Loopback Functions' to Proposed Standard (draft-ietf-mpls-tp-li-lb-08.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 22:59:39 -0000 The IESG has approved the following document: - 'MPLS Transport Profile lock Instruct and Loopback Functions' (draft-ietf-mpls-tp-li-lb-08.txt) as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-li-lb/ Technical Summary Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are "lock" and "loopback". The lock function enables an operator to lock a transport path such that it does not carry client traffic, but can continue to carry OAM messages and may carry test traffic. The loopback function allows an operator to set a specific node on the transport path into loopback mode such that it returns all received data. This document specifies the lock function for MPLS networks and describes how the loopback function operates in MPLS networks. Working Group Summary This document is a MPLS working group document, and part of the joint IETF - ITU.T MPLS-TP project. It has been reviewed in both organizations and there is a solid support for the document. The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1439/ The IPD disclosure was noted on the WG mailing list and in the IETF last call. No concerns were raised. Document Quality The document is well reviewed in the MPLS and PWE3 working groups, the ITU-T and the MPLS-TP project. Several implementations are under way or planned. This document updates RFC 6371 section 7.1.1. This document contains a "downref" to RFC 6371, the Informational RFC that it updates. The downref was declared in the IETF last call. Personnel Loa Andersson (loa@pi.nu) is the document shepherd Adrian Farrel (adrian@olddog.co.uk) is the Responsible AS RFC Editor Note Section 1 bullet 2 s/an bidirectional/a bidirectional/ From ice@cisco.com Wed Oct 26 01:36:37 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2DB21F8B07 for ; Wed, 26 Oct 2011 01:36:37 -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=[AWL=0.000, 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 LihHYJaEkOXS for ; Wed, 26 Oct 2011 01:36:36 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 56E0921F84CC for ; Wed, 26 Oct 2011 01:36:36 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9Q8aX4L004384 for ; Wed, 26 Oct 2011 10:36:33 +0200 (CEST) Received: from ams-iwijnand-8712.cisco.com (ams-iwijnand-8712.cisco.com [10.55.191.147]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9Q8aRhn001054; Wed, 26 Oct 2011 10:36:29 +0200 (CEST) From: IJsbrand Wijnands Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Oct 2011 10:36:26 +0200 Message-Id: To: "Emily Chen(Ying)" , quintin.zhao@huawei.com Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Cc: mpls@ietf.org Subject: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 08:36:37 -0000 Dear Emly and Quintin, Quick comment/question on this draft. =46rom your draft, figure 3, if router R3 does not support mLDP and you = want to tunnel the mLDP traffic through it using a P2P LSP, does it not = need to be upgraded using code that supports this feature? If you need = to upgrade, why not upgrade it with mLDP code? The case where this would be useful is if there is a router that can't = support mLDP due to platform dependencies, its in the middle of the = network, but you are able to upgrade the router with new code platform = independent code supporting this feature. If the router not supporting mLDP is closer to the root node, it makes = more sense to setup a Targeted LDP session immediately with the root = skipping the non-mLDP router. That way you don't need to upgrade the = non-mLDP router at all. Thx, Ice.= From quintin.zhao@huawei.com Wed Oct 26 07:08:44 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA38B21F8B00 for ; Wed, 26 Oct 2011 07:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 cASPHbJEofP1 for ; Wed, 26 Oct 2011 07:08:44 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 4102121F8AEA for ; Wed, 26 Oct 2011 07:08:44 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTO000UPFAH33@usaga04-in.huawei.com> for mpls@ietf.org; Wed, 26 Oct 2011 09:08:42 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTO00GI8FAHTI@usaga04-in.huawei.com> for mpls@ietf.org; Wed, 26 Oct 2011 09:08:41 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 26 Oct 2011 07:08:36 -0700 Received: from QZHAO (10.212.244.195) by DFWEML402-HUB.china.huawei.com (10.193.5.102) with Microsoft SMTP Server id 14.1.270.1; Wed, 26 Oct 2011 07:08:34 -0700 Date: Wed, 26 Oct 2011 10:08:25 -0400 From: Quintin Zhao In-reply-to: X-Originating-IP: [10.212.244.195] To: 'IJsbrand Wijnands' , "'Emily Chen(Ying)'" Message-id: <000601cc93e8$bc29bf10$347d3d30$%zhao@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcyTumx5nJBteb6hSoqltiwz43Td7gAKBESw References: Cc: mpls@ietf.org Subject: Re: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 14:08:44 -0000 Dear Ice, Thanks for your comments. You are right that the R3 needs to upgraded using the code that supports this feature, the code change should be limit to the control plane to process the new type of LDP MP Status Value Element without any changes = to the forwarding plane.=20 The case that this draft addresses is that when a mLDP router (router D) needs to find out the first mLDP router ( router U) on the path to the = root, where router D is not directly connected to router U and also there is = no Target session setup yet between router U and router D. In this case, = the route D needs to use the non-mLDP router (router M) in the middle of the path between router D and router U to process the new type of LDP MP = Status Value Element and pass it on until it reaches the router U. And after = that, the router U initiates the Target session with router D.=20 It is true that if the router D can find the router U, no matter it is = close to the root or not, in the first place through offline tools or through configurations, then we can skip the non-mLDP router and setup a = Targeted LDP session without upgrading the non-mLDP router at all. We will = clarify this more in the next revision of the draft. Quintin -----Original Message----- From: IJsbrand Wijnands [mailto:ice@cisco.com]=20 Sent: 2011=C4=EA10=D4=C226=C8=D5 4:36 To: Emily Chen(Ying); quintin.zhao@huawei.com Cc: mpls@ietf.org Subject: draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 Dear Emly and Quintin, Quick comment/question on this draft. >From your draft, figure 3, if router R3 does not support mLDP and you = want to tunnel the mLDP traffic through it using a P2P LSP, does it not need = to be upgraded using code that supports this feature? If you need to = upgrade, why not upgrade it with mLDP code? The case where this would be useful is if there is a router that can't support mLDP due to platform dependencies, its in the middle of the = network, but you are able to upgrade the router with new code platform = independent code supporting this feature. If the router not supporting mLDP is closer to the root node, it makes = more sense to setup a Targeted LDP session immediately with the root skipping = the non-mLDP router. That way you don't need to upgrade the non-mLDP router = at all. Thx, Ice. From venkatflex@gmail.com Wed Oct 26 11:48:07 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D771F0C3E for ; Wed, 26 Oct 2011 11:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.697 X-Spam-Level: *** X-Spam-Status: No, score=3.697 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] 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 s3olcY5a0XTL for ; Wed, 26 Oct 2011 11:48:07 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7471F0C3C for ; Wed, 26 Oct 2011 11:48:06 -0700 (PDT) Received: by wyh22 with SMTP id 22so2345054wyh.31 for ; Wed, 26 Oct 2011 11:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Nd0cDKLJO8LxGNfA8ZS93AomoZVKXDTBs86ZYKn6M+g=; b=YnYdErr47MT+lQ1N53FfUmsAYKE/OVguP9Ehzk9JH5NUFrWbQz39ctaVN8kdgtCT9N l+YhkLaY8N+u+ayLMEHyL6UyW6zOGqW6hNFSOrkuX7DHJGw8Hodz2uK34m7IWplGJXNf LbGzglZquvpuht15b3/lou34FW+qZ7nTBGxi4= MIME-Version: 1.0 Received: by 10.227.197.71 with SMTP id ej7mr11306083wbb.15.1319654885640; Wed, 26 Oct 2011 11:48:05 -0700 (PDT) Received: by 10.180.87.102 with HTTP; Wed, 26 Oct 2011 11:48:05 -0700 (PDT) In-Reply-To: References: <4EA56F96.7040404@pi.nu> Date: Wed, 26 Oct 2011 13:48:05 -0500 Message-ID: From: venkatesan mahalingam To: Loa Andersson , "mpls@ietf.org" Content-Type: multipart/alternative; boundary=0015174c45b0af4d4204b038183a Subject: Re: [mpls] =?gb2312?b?tPC4tDogcG9sbCBvbiBkcmFmdC13ZWluZ2FydGVuLW1w?= =?gb2312?b?bHMtdHAtcmluZy1wcm90ZWN0aW9u?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 18:48:07 -0000 --0015174c45b0af4d4204b038183a Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Yes/Support Regards, Venkat. 2011/10/25 > > Yes/support > > > Wenjuan > > > > *Loa Andersson * > =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org > > 2011-10-24 22:00 > =CA=D5=BC=FE=C8=CB > "mpls@ietf.org" > =B3=AD=CB=CD > =D6=F7=CC=E2 > [mpls] poll on draft-weingarten-mpls-tp-ring-protection > > > > > Working Group, > > this is to start a two week poll to see if there is support to make > draft-weingarten-mpls-tp-ring-protection an mpls working group draft. > > Pleased send your comments to the mpls working group mailing list > (mpls@ietf.org). > > This poll ends Sun Nov 6. > > /Loa > for the mpls wg chairs > -- > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --0015174c45b0af4d4204b038183a Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Yes/Support

Regards,
Venkat.

2011/10/25 <he.wenjuan1@zte.com.cn>

Yes/support


Wenjuan



Loa Andersson <= ;loa@pi.nu>
=B7=A2=BC=FE=C8=CB:  mpls-bounces@ietf.org

2011-10-24 22:00

=CA=D5=BC=FE=C8= =CB
"mpls@ietf.org" <mpls@ietf.org>
=B3=AD=CB=CD
=D6=F7=CC=E2
[mpls] poll on draft-weingart= en-mpls-tp-ring-protection





Working Group,

this is to start a two week poll to see if there is support to make
draft-weingarten-mpls-tp-ring-protection an mpls working group draft.

Pleased send your comments to the mpls working group mailing list
(mpls@ietf.org).

This poll ends Sun Nov 6.

/Loa
for the mpls wg chairs
--
--


Loa Andersson                  = ;       email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager            = loa@pi.nu
Ericsson Inc                          phone: +46 10 717 52 13
                                         = ;    +46 767 72 92 13
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

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


--0015174c45b0af4d4204b038183a-- From Boris.Zhang@telus.com Wed Oct 26 13:26:22 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB8021F84F9 for ; Wed, 26 Oct 2011 13:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 o1qLSl2Onl8v for ; Wed, 26 Oct 2011 13:26:21 -0700 (PDT) Received: from donder.nssi.telus.com (donder.nssi.telus.com [208.38.59.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC1421F84B0 for ; Wed, 26 Oct 2011 13:26:20 -0700 (PDT) DomainKey-Signature: s=donder.nssi; d=telus.com; c=nofws; q=dns; h=X-IronPort-Anti-Spam-Filtered: X-IronPort-Anti-Spam-Result:X-IronPort-AV:Received: Received:From:To:CC:Date:Subject:Thread-Topic: Thread-Index:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:acceptlanguage:Content-Type: Content-Transfer-Encoding:MIME-Version; b=Q+TXJ74DYqb57oVxCLyXTXhClcCw0C0CxXFKEckJsgmtuFERkmaV5dO9 DubkYo60sZMUOAX+pqBvIhRVnOtAJHzw5o+NSelLjt9yHMTd3JgyDlnQd E3nUsxxRMKVVTI7odtHFmafHCK2NMD7+9O+aKs1n6PXfVYH/yIhVjlveD s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAHxsqE6OP4Bp/2dsb2JhbABChHaRT5MJgQWBbgEBAQQBAQEeATEbCwwEAgEIDQQEAQECAwsYAgMCJwsUCQgBAQQBDQUIiACjDQGSHgSBLYYmNmEEmVaMLw X-IronPort-AV: E=Sophos;i="4.69,411,1315180800"; d="scan'208";a="279241340" Received: from unknown (HELO WP40057.corp.ads) ([142.63.128.105]) by donder-o.nssi.telus.com with ESMTP/TLS/AES128-SHA; 26 Oct 2011 20:26:04 +0000 Received: from wp40067.corp.ads ([::1]) by WP40057.corp.ads ([::1]) with mapi; Wed, 26 Oct 2011 16:26:03 -0400 From: Boris Zhang To: Quintin Zhao , 'IJsbrand Wijnands' , "'Emily Chen(Ying)'" Date: Wed, 26 Oct 2011 16:26:01 -0400 Thread-Topic: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 Thread-Index: AcyTumx5nJBteb6hSoqltiwz43Td7gAKBESwAA6iEUA= Message-ID: <3CC752382EB88F48ADAC4AF9F478A15303D43D5984@WP40067.corp.ads> References: <000601cc93e8$bc29bf10$347d3d30$%zhao@huawei.com> In-Reply-To: <000601cc93e8$bc29bf10$347d3d30$%zhao@huawei.com> 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="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 20:26:22 -0000 Quintin I am still wondering in what kind of situation we have control plane capabl= e to support mLDP while forwarding plane doesn't. Does it implicate deployi= ng mLDP requesting quite a lot upgrading on forwarding plane on current pla= tform ( router & switch) ? Thanks Boris -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Qui= ntin Zhao Sent: October 26, 2011 10:08 AM To: 'IJsbrand Wijnands'; 'Emily Chen(Ying)' Cc: mpls@ietf.org Subject: Re: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 Dear Ice, Thanks for your comments. You are right that the R3 needs to upgraded using the code that supports this feature, the code change should be limit to the control plane to process the new type of LDP MP Status Value Element without any changes to the forwarding plane.=20 The case that this draft addresses is that when a mLDP router (router D) needs to find out the first mLDP router ( router U) on the path to the root= , where router D is not directly connected to router U and also there is no Target session setup yet between router U and router D. In this case, the route D needs to use the non-mLDP router (router M) in the middle of the path between router D and router U to process the new type of LDP MP Status Value Element and pass it on until it reaches the router U. And after that, the router U initiates the Target session with router D.=20 It is true that if the router D can find the router U, no matter it is clos= e to the root or not, in the first place through offline tools or through configurations, then we can skip the non-mLDP router and setup a Targeted LDP session without upgrading the non-mLDP router at all. We will clarify this more in the next revision of the draft. Quintin -----Original Message----- From: IJsbrand Wijnands [mailto:ice@cisco.com]=20 Sent: 2011=1B$BG/=1B(B10=1B$B7n=1B(B26=1B$BF|=1B(B 4:36 To: Emily Chen(Ying); quintin.zhao@huawei.com Cc: mpls@ietf.org Subject: draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 Dear Emly and Quintin, Quick comment/question on this draft. >From your draft, figure 3, if router R3 does not support mLDP and you want to tunnel the mLDP traffic through it using a P2P LSP, does it not need to be upgraded using code that supports this feature? If you need to upgrade, why not upgrade it with mLDP code? The case where this would be useful is if there is a router that can't support mLDP due to platform dependencies, its in the middle of the network= , but you are able to upgrade the router with new code platform independent code supporting this feature. If the router not supporting mLDP is closer to the root node, it makes more sense to setup a Targeted LDP session immediately with the root skipping th= e non-mLDP router. That way you don't need to upgrade the non-mLDP router at all. Thx, Ice. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From jeff.tantsura@ericsson.com Wed Oct 26 14:23:02 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355E821F845D for ; Wed, 26 Oct 2011 14:23:01 -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 u6FfAFTuOIvl for ; Wed, 26 Oct 2011 14:23:00 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5748621F8464 for ; Wed, 26 Oct 2011 14:23:00 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p9QLM6xR005060; Wed, 26 Oct 2011 16:22:09 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.232]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 26 Oct 2011 17:22:06 -0400 From: Jeff Tantsura To: Boris Zhang , Quintin Zhao , "'IJsbrand Wijnands'" , "'Emily Chen(Ying)'" Date: Wed, 26 Oct 2011 17:22:04 -0400 Thread-Topic: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 Thread-Index: AcyUJU/j7SJh5ILBQQOzOZgCCQnl1A== Message-ID: In-Reply-To: <3CC752382EB88F48ADAC4AF9F478A15303D43D5984@WP40067.corp.ads> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 21:23:02 -0000 +1 Quintin, Even though FW part of mLDP is quite complex I'd be rather interested to see a vendor implementing CP only, without FW support. --=20 Regards, Jeff On 10/26/11 1:26 PM, "Boris Zhang" wrote: >Quintin > >I am still wondering in what kind of situation we have control plane >capable to support mLDP while forwarding plane doesn't. Does it implicate >deploying mLDP requesting quite a lot upgrading on forwarding plane on >current platform ( router & switch) ? > >Thanks >Boris > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >Quintin Zhao >Sent: October 26, 2011 10:08 AM >To: 'IJsbrand Wijnands'; 'Emily Chen(Ying)' >Cc: mpls@ietf.org >Subject: Re: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 > >Dear Ice, > >Thanks for your comments. > >You are right that the R3 needs to upgraded using the code that supports >this feature, the code change should be limit to the control plane to >process the new type of LDP MP Status Value Element without any changes to >the forwarding plane. > >The case that this draft addresses is that when a mLDP router (router D) >needs to find out the first mLDP router ( router U) on the path to the >root, >where router D is not directly connected to router U and also there is no >Target session setup yet between router U and router D. In this case, the >route D needs to use the non-mLDP router (router M) in the middle of the >path between router D and router U to process the new type of LDP MP >Status >Value Element and pass it on until it reaches the router U. And after >that, >the router U initiates the Target session with router D. > >It is true that if the router D can find the router U, no matter it is >close >to the root or not, in the first place through offline tools or through >configurations, then we can skip the non-mLDP router and setup a Targeted >LDP session without upgrading the non-mLDP router at all. We will clarify >this more in the next revision of the draft. > >Quintin > >-----Original Message----- >From: IJsbrand Wijnands [mailto:ice@cisco.com] >Sent: 2011=1B$BG/=1B(B10=1B$B7n=1B(B26=1B$BF|=1B(B 4:36 >To: Emily Chen(Ying); quintin.zhao@huawei.com >Cc: mpls@ietf.org >Subject: draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 > >Dear Emly and Quintin, > >Quick comment/question on this draft. > >From your draft, figure 3, if router R3 does not support mLDP and you want >to tunnel the mLDP traffic through it using a P2P LSP, does it not need to >be upgraded using code that supports this feature? If you need to upgrade, >why not upgrade it with mLDP code? > >The case where this would be useful is if there is a router that can't >support mLDP due to platform dependencies, its in the middle of the >network, >but you are able to upgrade the router with new code platform independent >code supporting this feature. > >If the router not supporting mLDP is closer to the root node, it makes >more >sense to setup a Targeted LDP session immediately with the root skipping >the >non-mLDP router. That way you don't need to upgrade the non-mLDP router at >all. > >Thx, > >Ice. > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From cpignata@cisco.com Wed Oct 26 19:08:00 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9156B21F8AB0 for ; Wed, 26 Oct 2011 19:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLL7J887nodp for ; Wed, 26 Oct 2011 19:07:59 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id B9A4321F86A1 for ; Wed, 26 Oct 2011 19:07:59 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9R27w1H029162 for ; Wed, 26 Oct 2011 22:07:58 -0400 (EDT) Received: from [10.117.115.59] (rtp-cpignata-89110.cisco.com [10.117.115.59]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9R27tEt022288; Wed, 26 Oct 2011 22:07:55 -0400 (EDT) Message-ID: <4EA8BCFB.7030900@cisco.com> Date: Wed, 26 Oct 2011 22:07:55 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <01e601cc933a$b0398e50$10acaaf0$@olddog.co.uk> <960EC8F9A775AB40BF58D8953342D863069A9909@XMB-RCD-206.cisco.com> <01f401cc933f$b827caa0$28775fe0$@olddog.co.uk> In-Reply-To: <01f401cc933f$b827caa0$28775fe0$@olddog.co.uk> X-Enigmail-Version: 1.3.2 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, draft-ietf-mpls-ldp-iana@tools.ietf.org Subject: Re: [mpls] draft-ietf-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 02:08:00 -0000 Hi Adrian, The fields marked "reserved" are atomic fields without syntax or semantics. draft-ietf-mpls-ldp-iana does not attempt to define the field or start using it. But without it, there are no rules as to what is needed for something to start using them. There is a potential chicken-egg as well. This said, I do see your point now, as while I re-read draft-ietf-mpls-ldp-iana, the current text can be read to be making the assumption that a 6-bit field is a bit-field. On the other hand, the (proposed) allocation policy of "IETF Review" is basically (and purposely) agreeing with your intent below, in that an RFC with IETF consensus is needed. Or said a different way, the same way that a registry sets specific allocation policies for ranges of values to be used for vendor-private, we are trying to specify the (yet unspecified) policy for how to update these "Reserved" fields, and explicitly state that an RFC that achieves IETF consensus is required. So perhaps, text like the following: 2.4. Common Session Parameters TLV There are six Reserved bits in the Common Session Parameters TLV (see Section 3.5.3 of [RFC5036]). Allocations from these bits are made via IETF Review [RFC5226]. Previously, there was no rule for allocation of these bits. Should instead be: 2.4. Common Session Parameters TLV There is a six-bit Reserved field in the Common Session Parameters TLV (see Section 3.5.3 of [RFC5036]). Definition of this field is made via IETF Review [RFC5226]. Previously, there was no rule for using the bits in this Reserved field. Or do you think that the update should rename the fields to "Undefined" or simply "MBZ"? Thanks, -- Carlos. On 10/25/2011 1:58 PM, Adrian Farrel wrote: > I understand, Carlos. > > Ask yourself the question whether the field in the TLV marked "reserved" is > already a bit field? If it is, you are right to want to define the allocation > policy and establish a registry. If it is not (but is simply a reserved field) > then you have to decide whether you are allocating a new protocol field from the > reserved portion of the TLV, or are redefining the whole reserved field as a bit > field. > > You might help yourself to consider the question by considering what you would > have done had you needed an 8-bit integer, not a flag. Could you have defined > this from the reserved part of the TLV? Answer the question before you dreamed > of draft-ietf-mpls-ldp-gtsm, and afterwards. > > Cheers, > Adrian > >> -----Original Message----- >> From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >> Sent: 25 October 2011 18:45 >> To: adrian@olddog.co.uk; mpls@ietf.org >> Cc: draft-ietf-mpls-ldp-iana@tools.ietf.org >> Subject: RE: draft-ietf-mpls-ldp-iana >> >> Adrian, >> >> The one-liner response to your "Why do you actually need it?", more >> later: for draft-ietf-mpls-ldp-gtsm, we need to assign a bit in the >> Common Hello Parameter TLV for which there is no allocation policy -- >> that's the whole motivation. WG consensus was to, since we are doing >> that, we might as well proactively fill in all the gaps in RFC 5036. >> >> Hope that clarifies, >> >> -- Carlos. >> >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: Tuesday, October 25, 2011 1:23 PM >> To: mpls@ietf.org >> Cc: draft-ietf-mpls-ldp-iana@tools.ietf.org >> Subject: draft-ietf-mpls-ldp-iana >> >> Hi WG, >> >> I started my review of this document and have a fairly fundamental >> question for >> the WG. >> >> The document looks at the IANA registries for LDP and compares with the >> protocol >> spec (RFC5036). It observes that there are some fields in the protocol >> spec >> marked as "reserved" and that there is no clear statement of how those >> fields >> can be used in future protocol extensions. >> >> The problem I am having is that the fields are reserved, not unassigned. >> If they >> were named fields with known uses (e.g. bit fields) it would make sense >> to >> define an assignment policy, say that the fields are currently >> unassigned, and >> use the combination of the IESG and the IANA to police future use. >> >> But what I think you are trying to do is state what the RFC means by >> "reserved". >> That is a fine thing to do in a draft if you believe it is necessary (I >> would >> note that no-one has previously found it to be necessary, but reserved >> fields >> are often scoped as MBZ to allow future extensibility). In practice, a >> field >> that is "reserved" in a standards track RFC is, well, erm, reserved. You >> can't >> suddenly start using the field without an RFC. (Just as you could not >> change a >> message format to add another field.) >> >> However, you cannot use IANA to police reserved fields. IANA manages >> code point >> registries, not protocol behavior. What you are effectively doing in >> this I-D is >> creating a negative assignment: you are asking IANA to not create a new >> registry >> for a protocol field (as yet unknown) in a specific spot in a certain >> TLV or >> message. That's hard for IANA because they don't care where or how their >> registries are encoded in messages. indeed, Some registries are used in >> multiple >> protocol fields. >> >> To say it another way, I read the document as saying "Ooops, we defined >> a couple >> of fields that people might start making allocations from, but which >> don't have IANA registries." But what I sense is actually the intention >> is >> "Hmmm, there are some reserved fields and we would like to control how >> those >> fields might get used in the future." >> >> So, coming back again to what I think it is you want to achieve: should >> this >> document simply be an update to 5036 that says "The following fields >> that >> are marked as 'reserved' in [RFC5036] are not to be used for new >> protocol >> mechanisms except through RFCs that achieve IETF consensus." >> >> And finally, my question. What is this document *really* trying to >> achieve? Why >> do you actually need it? >> >> There is one exception to all of this. The Len field of the Frame Relay >> Label >> TLV could have a registry defined. >> >> Thanks, >> Adrian > > From cpignata@cisco.com Wed Oct 26 19:08:20 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5509E21F8B12 for ; Wed, 26 Oct 2011 19:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuiXSEQmPw-O for ; Wed, 26 Oct 2011 19:08:19 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 6638221F8B11 for ; Wed, 26 Oct 2011 19:08:19 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9R28IRb029227 for ; Wed, 26 Oct 2011 22:08:18 -0400 (EDT) Received: from [10.117.115.59] (rtp-cpignata-89110.cisco.com [10.117.115.59]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9R28IB9022836; Wed, 26 Oct 2011 22:08:18 -0400 (EDT) Message-ID: <4EA8BD11.2080008@cisco.com> Date: Wed, 26 Oct 2011 22:08:17 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <01e601cc933a$b0398e50$10acaaf0$@olddog.co.uk> <960EC8F9A775AB40BF58D8953342D863069A9916@XMB-RCD-206.cisco.com> <01f501cc9340$70d29260$5277b720$@olddog.co.uk> In-Reply-To: <01f501cc9340$70d29260$5277b720$@olddog.co.uk> X-Enigmail-Version: 1.3.2 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, draft-ietf-mpls-ldp-iana@tools.ietf.org Subject: Re: [mpls] draft-ietf-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 02:08:20 -0000 Hi Adrian, You are right, I was mistaking the two uses of "reserved". Agreed. BTW, this prompted me to grep "reserved" from RFC 5036, where it is also using the word "reserved" with multiple semantics: i. "reserved" as a protocol field being reserved (and MBZ, implying potential future extensibility); ii. "reserved" as values from a field being unassigned meaning (e.g., FR Len); and iii. range of values as "reserved" in a registry for a particular allocation scheme. These are the same "reserved" instances from RFC 3036. Thanks, -- Carlos. On 10/25/2011 2:03 PM, Adrian Farrel wrote: > I think you are mistaking the assignment policy "reserved" defined in 5226, with > a field in a protocol element that is labelled as "reserved". > > The former is how a code point is described in a registry. > The latter is how a field that has no associated use or registry is described in > an RFC. > > Adrian > >> -----Original Message----- >> From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >> Sent: 25 October 2011 18:51 >> To: adrian@olddog.co.uk; mpls@ietf.org >> Cc: draft-ietf-mpls-ldp-iana@tools.ietf.org >> Subject: RE: draft-ietf-mpls-ldp-iana >> >> Adrian, >> >> BTW: The distinction between the Unassigned and Reserved labels appears >> in RFC 5226, which published after RFC 5036. RFC 5036 points to RFC >> 2434, which lacks that distinction. >> >> Thanks, >> >> -- Carlos. >> >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: Tuesday, October 25, 2011 1:23 PM >> To: mpls@ietf.org >> Cc: draft-ietf-mpls-ldp-iana@tools.ietf.org >> Subject: draft-ietf-mpls-ldp-iana >> >> Hi WG, >> >> I started my review of this document and have a fairly fundamental >> question for >> the WG. >> >> The document looks at the IANA registries for LDP and compares with the >> protocol >> spec (RFC5036). It observes that there are some fields in the protocol >> spec >> marked as "reserved" and that there is no clear statement of how those >> fields >> can be used in future protocol extensions. >> >> The problem I am having is that the fields are reserved, not unassigned. >> If they >> were named fields with known uses (e.g. bit fields) it would make sense >> to >> define an assignment policy, say that the fields are currently >> unassigned, and >> use the combination of the IESG and the IANA to police future use. >> >> But what I think you are trying to do is state what the RFC means by >> "reserved". >> That is a fine thing to do in a draft if you believe it is necessary (I >> would >> note that no-one has previously found it to be necessary, but reserved >> fields >> are often scoped as MBZ to allow future extensibility). In practice, a >> field >> that is "reserved" in a standards track RFC is, well, erm, reserved. You >> can't >> suddenly start using the field without an RFC. (Just as you could not >> change a >> message format to add another field.) >> >> However, you cannot use IANA to police reserved fields. IANA manages >> code point >> registries, not protocol behavior. What you are effectively doing in >> this I-D is >> creating a negative assignment: you are asking IANA to not create a new >> registry >> for a protocol field (as yet unknown) in a specific spot in a certain >> TLV or >> message. That's hard for IANA because they don't care where or how their >> registries are encoded in messages. indeed, Some registries are used in >> multiple >> protocol fields. >> >> To say it another way, I read the document as saying "Ooops, we defined >> a couple >> of fields that people might start making allocations from, but which >> don't have IANA registries." But what I sense is actually the intention >> is >> "Hmmm, there are some reserved fields and we would like to control how >> those >> fields might get used in the future." >> >> So, coming back again to what I think it is you want to achieve: should >> this >> document simply be an update to 5036 that says "The following fields >> that >> are marked as 'reserved' in [RFC5036] are not to be used for new >> protocol >> mechanisms except through RFCs that achieve IETF consensus." >> >> And finally, my question. What is this document *really* trying to >> achieve? Why >> do you actually need it? >> >> There is one exception to all of this. The Len field of the Frame Relay >> Label >> TLV could have a registry defined. >> >> Thanks, >> Adrian > > From erosen@cisco.com Thu Oct 27 06:31:19 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1092E21F84AD for ; Thu, 27 Oct 2011 06:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 A5hQO5xIWm1z for ; Thu, 27 Oct 2011 06:31:18 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5655E21F84A9 for ; Thu, 27 Oct 2011 06:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=1497; q=dns/txt; s=iport; t=1319722278; x=1320931878; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=bb0d2jJ5jXWBTFlMfyXNUIVsNoKlLRiEQlSNqk0Yu1Q=; b=J/A00fcImCui9y4QzsV2zp11AS9NgvLFQX6F+iVCxE1MCJyTBEYw0WzL q04P6YaziN2e5ua8SvFYd+BlXR2xqedLawp4F+42Qb2wCJd2KmgILhJf3 rrw8l905+52s6uy/bIMVGEMtbJhuODr9z2rbzl3w5bFFucox/+sWPncpj Q=; X-IronPort-AV: E=Sophos;i="4.69,413,1315180800"; d="scan'208";a="31380556" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 27 Oct 2011 13:31:17 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9RDVHBe025377; Thu, 27 Oct 2011 13:31:17 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id p9RDVFmu006125; Thu, 27 Oct 2011 09:31:15 -0400 To: Carlos Pignataro In-reply-to: Your message of Wed, 26 Oct 2011 22:07:55 -0400. <4EA8BCFB.7030900@cisco.com> Date: Thu, 27 Oct 2011 09:31:15 -0400 Message-ID: <6124.1319722275@erosen-linux> From: Eric Rosen Cc: draft-ietf-mpls-ldp-iana@tools.ietf.org, mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 13:31:19 -0000 > The fields marked "reserved" are atomic fields without syntax or > semantics. draft-ietf-mpls-ldp-iana does not attempt to define the field > or start using it. But without it, there are no rules as to what is > needed for something to start using them. Since there are currently no IANA registries for the fields in question, it is currently impossible for IANA to make any assignments to those fields. As those fields are part of an IETF standard protocol, a redefinition of those fields could only be accomplished by a "standards action". So what is wrong with the status quo? The only issue I see is that if one wants to use one of the currently unused bits, there is no central place to go to see if any other standards-track RFC is already using it. I think this is a real issue, but I'm not sure it can be addressed by creating an IANA registry. IANA will ask not only for the allocation policy, but for the range of values that are assignable. If we don't know whether we may want to use a field as a bit field or as 13-bit integer, I don't know how we would provide that information to them. Maybe all that is needed is to have the GTSM draft indicate that it updates RFC 5036, and mention in the abstract and introduction that it uses a bit that is reserved in RFC 5036. It's also hard to see the point of creating registries for "ATM Label TLV", "Frame Relay Label TLV". The first standards track RFC that needs these registries can request them. From adrian@olddog.co.uk Thu Oct 27 07:00:43 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADE521F8B0F for ; Thu, 27 Oct 2011 07:00:43 -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=[AWL=0.000, 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 ZzD8Di5OzMmc for ; Thu, 27 Oct 2011 07:00:42 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 51DE421F8772 for ; Thu, 27 Oct 2011 07:00:42 -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 p9RE0Z2N013851; Thu, 27 Oct 2011 15:00:35 +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 p9RE0XXa013824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Oct 2011 15:00:34 +0100 From: "Adrian Farrel" To: , "'Carlos Pignataro'" References: Your message of Wed, 26 Oct 2011 22:07:55 -0400. <4EA8BCFB.7030900@cisco.com> <6124.1319722275@erosen-linux> In-Reply-To: <6124.1319722275@erosen-linux> Date: Thu, 27 Oct 2011 15:00:34 +0100 Message-ID: <013901cc94b0$ccb8a670$6629f350$@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: AQGfz/gpcxtbFVe57UShIZoquiPWFJXpwOmA Content-Language: en-gb Cc: mpls@ietf.org, draft-ietf-mpls-ldp-iana@tools.ietf.org Subject: Re: [mpls] draft-ietf-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 14:00:43 -0000 Thanks Eric, I think that pretty much captures it. We have previously had similar "problems" when multiple I-Ds have started to allocate flags from a reserved space. We have usually handled this by turning all of part of the reserved space into a flags field and asking IANA to manage it. But this has often only been necessary when there is a flurry of multiple I-Ds attacking the same area. In this case, I think the new I-D should simply define a new bit flag, show where it fits into the TLV structure, and move on. Cheers, Adrian > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: 27 October 2011 14:31 > To: Carlos Pignataro > Cc: adrian@olddog.co.uk; mpls@ietf.org; draft-ietf-mpls-ldp-iana@tools.ietf.org > Subject: Re: [mpls] draft-ietf-mpls-ldp-iana > > > > The fields marked "reserved" are atomic fields without syntax or > > semantics. draft-ietf-mpls-ldp-iana does not attempt to define the field > > or start using it. But without it, there are no rules as to what is > > needed for something to start using them. > > Since there are currently no IANA registries for the fields in question, it > is currently impossible for IANA to make any assignments to those fields. > As those fields are part of an IETF standard protocol, a redefinition of > those fields could only be accomplished by a "standards action". So what is > wrong with the status quo? > > The only issue I see is that if one wants to use one of the currently unused > bits, there is no central place to go to see if any other standards-track > RFC is already using it. I think this is a real issue, but I'm not sure it > can be addressed by creating an IANA registry. IANA will ask not only for > the allocation policy, but for the range of values that are assignable. If > we don't know whether we may want to use a field as a bit field or as 13-bit > integer, I don't know how we would provide that information to them. > > Maybe all that is needed is to have the GTSM draft indicate that it updates > RFC 5036, and mention in the abstract and introduction that it uses a bit > that is reserved in RFC 5036. > > It's also hard to see the point of creating registries for "ATM Label TLV", > "Frame Relay Label TLV". The first standards track RFC that needs these > registries can request them. > > From cpignata@cisco.com Thu Oct 27 07:57:20 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9622A21F8ADE for ; Thu, 27 Oct 2011 07:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p67+TsgEvAWq for ; Thu, 27 Oct 2011 07:57:20 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id B98CE21F86F6 for ; Thu, 27 Oct 2011 07:57:19 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9REvIqc009536 for ; Thu, 27 Oct 2011 10:57:18 -0400 (EDT) Received: from [10.117.115.60] (rtp-cpignata-89111.cisco.com [10.117.115.60]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9REvHDr016517; Thu, 27 Oct 2011 10:57:17 -0400 (EDT) Message-ID: <4EA9714F.4050600@cisco.com> Date: Thu, 27 Oct 2011 10:57:19 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: adrian@olddog.co.uk References: Your message of Wed, 26 Oct 2011 22:07:55 -0400. <4EA8BCFB.7030900@cisco.com> <6124.1319722275@erosen-linux> <013901cc94b0$ccb8a670$6629f350$@olddog.co.uk> In-Reply-To: <013901cc94b0$ccb8a670$6629f350$@olddog.co.uk> X-Enigmail-Version: 1.3.2 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, draft-ietf-mpls-ldp-iana@tools.ietf.org Subject: Re: [mpls] draft-ietf-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 14:57:20 -0000 Eric, This makes sense and I'm totally OK with that path forward. I'll wait a bit to see if there's more WG input. Adrian, Thanks for initially bringing this up -- just for clarity: we can have the GTSM draft update RFC 5036 and define a single G bit, and additionally were you suggesting that it would be useful to also i. define reserved as bitfield for the Common Hello/Session Parameters (I think not, but asking for completeness); ii. provide a statement (as you previously suggested) that "The following fields that are marked as 'reserved' in [RFC5036] are not to be used for new protocol mechanisms except through RFCs that achieve IETF consensus"; or iii. do nothing else? I am a bit sensitive to the potential issue that Eric and you also highlight, which is that there is no central place to know what's used. Frankly, I think that that was one of the strongest implied motivations here. So checking RFC 5036 an implementor sees: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Common Hello Parms(0x0400)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hold Time |T|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ And unless he or she first sees, second understands, and third follows the "Updates" link chain, they would not immediately know that there is a bit that was claimed to be used. In a way, I've used the IANA pages for that. What's your sense? Should a nibble be turned into a bitflag and given to IANA (so we see bits "T, R, G (future), unassigned")? This would perhaps only make sense for Common Hello/Session Parameters? Or even turn the existing ones? Thanks, -- Carlos. On 10/27/2011 10:00 AM, Adrian Farrel wrote: > Thanks Eric, > > I think that pretty much captures it. > > We have previously had similar "problems" when multiple I-Ds have started to > allocate flags from a reserved space. We have usually handled this by turning > all of part of the reserved space into a flags field and asking IANA to manage > it. But this has often only been necessary when there is a flurry of multiple > I-Ds attacking the same area. > > In this case, I think the new I-D should simply define a new bit flag, show > where it fits into the TLV structure, and move on. > > Cheers, > Adrian > >> -----Original Message----- >> From: Eric Rosen [mailto:erosen@cisco.com] >> Sent: 27 October 2011 14:31 >> To: Carlos Pignataro >> Cc: adrian@olddog.co.uk; mpls@ietf.org; > draft-ietf-mpls-ldp-iana@tools.ietf.org >> Subject: Re: [mpls] draft-ietf-mpls-ldp-iana >> >> >>> The fields marked "reserved" are atomic fields without syntax or >>> semantics. draft-ietf-mpls-ldp-iana does not attempt to define the field >>> or start using it. But without it, there are no rules as to what is >>> needed for something to start using them. >> Since there are currently no IANA registries for the fields in question, it >> is currently impossible for IANA to make any assignments to those fields. >> As those fields are part of an IETF standard protocol, a redefinition of >> those fields could only be accomplished by a "standards action". So what is >> wrong with the status quo? >> >> The only issue I see is that if one wants to use one of the currently unused >> bits, there is no central place to go to see if any other standards-track >> RFC is already using it. I think this is a real issue, but I'm not sure it >> can be addressed by creating an IANA registry. IANA will ask not only for >> the allocation policy, but for the range of values that are assignable. If >> we don't know whether we may want to use a field as a bit field or as 13-bit >> integer, I don't know how we would provide that information to them. >> >> Maybe all that is needed is to have the GTSM draft indicate that it updates >> RFC 5036, and mention in the abstract and introduction that it uses a bit >> that is reserved in RFC 5036. >> >> It's also hard to see the point of creating registries for "ATM Label TLV", >> "Frame Relay Label TLV". The first standards track RFC that needs these >> registries can request them. >> >> > > From quintin.zhao@huawei.com Thu Oct 27 07:57:36 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E76A21F8B36 for ; Thu, 27 Oct 2011 07:57:36 -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 M5vndvEc+Qzq for ; Thu, 27 Oct 2011 07:57:35 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 7794A21F86F6 for ; Thu, 27 Oct 2011 07:57:35 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTQ00MBYC7Y3T@usaga04-in.huawei.com> for mpls@ietf.org; Thu, 27 Oct 2011 09:57:34 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTQ00B7YC7X6A@usaga04-in.huawei.com> for mpls@ietf.org; Thu, 27 Oct 2011 09:57:34 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 27 Oct 2011 07:57:27 -0700 Received: from QZHAO (10.212.246.15) by DFWEML402-HUB.china.huawei.com (10.193.5.102) with Microsoft SMTP Server id 14.1.270.1; Thu, 27 Oct 2011 07:57:27 -0700 Date: Thu, 27 Oct 2011 10:57:19 -0400 From: Quintin Zhao In-reply-to: X-Originating-IP: [10.212.246.15] To: 'Jeff Tantsura' , 'Boris Zhang' , 'IJsbrand Wijnands' , "'Emily Chen(Ying)'" Message-id: <000d01cc94b8$bb20bd00$31623700$%zhao@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcyUJU/j7SJh5ILBQQOzOZgCCQnl1AAk1XXg References: <3CC752382EB88F48ADAC4AF9F478A15303D43D5984@WP40067.corp.ads> Cc: mpls@ietf.org Subject: Re: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 14:57:36 -0000 Boris, Jeff, Thanks for your comments! Supporting the full mLDP feature requires at least forwarding plane = changes to support the MPLS multicast package forwarding. Depending on the protection mechanisms for mLDP LSP implemented, it may also require the forwarding changes to support mLDP LSP's link and/or node protections features. The changes for the control plane of the non-mLDP node in this proposal = is just to pass the new type of LDP MP Status Value Element in a = notification message to its upstream node. It doesn't require the implementing of the whole mLDP control plane feature for the p2p node. It is true that even this is a small feature change, it still needs the upgrade of the = control plane.=20 Quintin -----Original Message----- From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com]=20 Sent: 2011=C4=EA10=D4=C226=C8=D5 17:22 To: Boris Zhang; Quintin Zhao; 'IJsbrand Wijnands'; 'Emily Chen(Ying)' Cc: mpls@ietf.org Subject: Re: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 +1 Quintin, Even though FW part of mLDP is quite complex I'd be rather interested to see a vendor implementing CP only, without FW support. --=20 Regards, Jeff On 10/26/11 1:26 PM, "Boris Zhang" wrote: >Quintin > >I am still wondering in what kind of situation we have control plane >capable to support mLDP while forwarding plane doesn't. Does it = implicate >deploying mLDP requesting quite a lot upgrading on forwarding plane on >current platform ( router & switch) ? > >Thanks >Boris > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >Quintin Zhao >Sent: October 26, 2011 10:08 AM >To: 'IJsbrand Wijnands'; 'Emily Chen(Ying)' >Cc: mpls@ietf.org >Subject: Re: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 > >Dear Ice, > >Thanks for your comments. > >You are right that the R3 needs to upgraded using the code that = supports >this feature, the code change should be limit to the control plane to >process the new type of LDP MP Status Value Element without any changes = to >the forwarding plane. > >The case that this draft addresses is that when a mLDP router (router = D) >needs to find out the first mLDP router ( router U) on the path to the >root, >where router D is not directly connected to router U and also there is = no >Target session setup yet between router U and router D. In this case, = the >route D needs to use the non-mLDP router (router M) in the middle of = the >path between router D and router U to process the new type of LDP MP >Status >Value Element and pass it on until it reaches the router U. And after >that, >the router U initiates the Target session with router D. > >It is true that if the router D can find the router U, no matter it is >close >to the root or not, in the first place through offline tools or through >configurations, then we can skip the non-mLDP router and setup a = Targeted >LDP session without upgrading the non-mLDP router at all. We will = clarify >this more in the next revision of the draft. > >Quintin > >-----Original Message----- >From: IJsbrand Wijnands [mailto:ice@cisco.com] >Sent: 2011=C4=EA10=D4=C226=C8=D5 4:36 >To: Emily Chen(Ying); quintin.zhao@huawei.com >Cc: mpls@ietf.org >Subject: draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 > >Dear Emly and Quintin, > >Quick comment/question on this draft. > >From your draft, figure 3, if router R3 does not support mLDP and you = want >to tunnel the mLDP traffic through it using a P2P LSP, does it not need = to >be upgraded using code that supports this feature? If you need to = upgrade, >why not upgrade it with mLDP code? > >The case where this would be useful is if there is a router that can't >support mLDP due to platform dependencies, its in the middle of the >network, >but you are able to upgrade the router with new code platform = independent >code supporting this feature. > >If the router not supporting mLDP is closer to the root node, it makes >more >sense to setup a Targeted LDP session immediately with the root = skipping >the >non-mLDP router. That way you don't need to upgrade the non-mLDP router = at >all. > >Thx, > >Ice. > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From erosen@cisco.com Thu Oct 27 08:28:38 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A4721F8B8B for ; Thu, 27 Oct 2011 08:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 6mWguSVXr4TA for ; Thu, 27 Oct 2011 08:28:37 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAE421F8B8D for ; Thu, 27 Oct 2011 08:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=3952; q=dns/txt; s=iport; t=1319729312; x=1320938912; h=to:cc:subject:in-reply-to:references:date:message-id: from; bh=G7Et3JitdP+48rqtP2+r/a6z+8IGBnyUBbib9S/ltQU=; b=mCf4JBFCNkbIIqAvXCubUeVUXJgu7miICkpXNBSwlSa7aJfZyq8IYFuz lis6ijDX00bZAOd8t1SqI+BLRvvAvKQ5nk56y5skXgfxqGhYLstiVlyl1 o38qCcLd455XweSnGdtWxS74lUH1dS0Oj6nThwfGx5EbQhjnjIwPulJKV c=; X-IronPort-AV: E=Sophos;i="4.69,413,1315180800"; d="scan'208";a="10699083" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 27 Oct 2011 15:28:32 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9RFSVeK028841; Thu, 27 Oct 2011 15:28:31 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id p9RFSUbo007214; Thu, 27 Oct 2011 11:28:30 -0400 To: Quintin Zhao In-reply-to: <000601cc93e8$bc29bf10$347d3d30$%zhao@huawei.com> References: <000601cc93e8$bc29bf10$347d3d30$%zhao@huawei.com> Comments: In-reply-to Quintin Zhao message dated "Wed, 26 Oct 2011 10:08:25 -0400." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.1.1 Date: Thu, 27 Oct 2011 11:28:30 -0400 Message-ID: <7213.1319729310@erosen-linux> From: Eric Rosen Cc: mpls@ietf.org, "'Emily Chen\(Ying\)'" , 'IJsbrand Wijnands' Subject: Re: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 15:28:38 -0000 I share the already-expressed concern that there is no real use case of this. In theory, one can imagine deployments where all the routers support the mLDP control plane, but some do not support an MPLS multicast data plane. In practice, I'm not so sure. There may be deployments in which multicast forwarding capability is supported only around the edges of the network, and the core is "multicast free". The use of mLDP in this kind of deployment is discussed in draft-napierala-mpls-targeted-mldp. I also have some technical questions about the draft. I'm a little confused about the capability you're defining. Presumably it means "I don't support mLDP natively, but I support the mLDP tunnel mode". So I guess it would be illegal to advertise this capability and also advertise the ordinary "mLDP capability, though this isn't stated. In the topology: Root---R1---R2---R3---R4 suppose that R2 and R3 are "mldp-tunnel-only" mode routers, but R1 and R4 are full mldp routers. I think the interaction being proposed is: * R4 selects R3 as the upstream node for * R4 knows (from the capability) that R3 is "mldp-tunnel-only" * Therefore R4 asks R3 "who is the closest 'full mLDP' node on your path to Root?" R4 has to remember that it asked this question, and that it is waiting for an answer. * R3 asks R2 the same question, also telling it "R4 needs to know". * R2 selects R1 as the upstream node for and determines that R1 is a "full mLDP" node. * So R2 tells R1 "set up a targeted mLDP session with R4". Of course, R4 will probably not accept this session until some more messages flow from R2 to R3 to R4. * R2 tells R3 "R1 is the closest full mLDP node on the path to Root". * R3 tells R4 "R1 is the closest full mLDP node on the path to Root". * Once R4 learns this fact from R3, R4 will now be willing to accept a T-mLDP session from R1, and will choose R1 as its upstream hop (over a P2P tunnel) to Root. (Unless the unicast routing has changed in the meantime, of course.) I think this raises a number of issues: * I don't think I could say from the draft exactly which messages are used for which purposes. * If R2's next hop to Root changes, it needs to tell R3 to that R1 is no longer on the path, and R3 needs to tell R4. R4 may need to tear down the targeted session to R1. Probably R2 has to tell R1 "R4 is no longer going to use you as the upstream hop for Root", in which case R1 may need to tear down the targeted session. None of this is discussed in the draft. * If R2's next hop to Root changes, it also needs to find the closest full mLDP node on the new path to Root. Then it needs to tell R3, R3 needs to tell R4, etc. * To make this work, I think the intermediate nodes have to maintain state about which upstream node is the closest full mLDP node to Root, and which downstream nodes have asked about the path to Root. * If R4's next hop to Root changes, R4 has to tell R3 "never mind, I no longer care about the closest full mLDP node on your path to Root". R3 has to tell R2 "never mind", R2 has to tell R1 "tear down your T-mLDP session to R4" (if you have no other reason to keep it up). R4 will also have to tear down its T-mLDP session to R1 (if it has no other reason to keep it up.) This should all be discussed in the draft. The draft needs a lot more detail, and I think it will turn out to be quite complicated to handle all the race conditions and corner cases correctly. It's just not worth it unless there is a real use case. I'm also not sure that the notification messages and status tlv are the right mechanisms, as the functionality that seems to be needed is more like "request/respond/withdraw/release" than it is like "notify". From yakov@juniper.net Thu Oct 27 08:35:30 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12AF21F8B95 for ; Thu, 27 Oct 2011 08:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNMKigoR8ele for ; Thu, 27 Oct 2011 08:35:29 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 805BC21F8B85 for ; Thu, 27 Oct 2011 08:35:29 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Thu, 27 Oct 2011 08:35:29 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 27 Oct 2011 08:32:21 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p9RFWLh45984; Thu, 27 Oct 2011 08:32:21 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201110271532.p9RFWLh45984@magenta.juniper.net> To: In-Reply-To: <6360.1317910342@erosen-linux> References: <6360.1317910342@erosen-linux> X-MH-In-Reply-To: Eric Rosen message dated "Thu, 06 Oct 2011 10:12:22 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <62053.1319729541.1@juniper.net> Date: Thu, 27 Oct 2011 08:32:21 -0700 From: Yakov Rekhter Cc: mpls@ietf.org Subject: Re: [mpls] seamless-mcast: Question re Leaf A-D routes for internet multicast X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 15:35:30 -0000 Eric, > I have a question about the "Leaf A-D Route for Internet Multicast" > described in section 6.2.2 of draft-ietf-mpls-seamless-mcast-01.txt. The > NLRI seems to be a bit different than the NLRI of Leaf A-D routes derived > from MVPN I-PMSI/S-PMSI A-D routes, and I'd like to understand whether this > difference is (a) intentional and (b) a good idea. > > Let's look at a Leaf A-D route that is derived from an MVPN S-PMSI A-D > route. > > Suppose the S-PMSI A-D route has the following NLRI: > > route type = 3 (S-PMSI A-D route), > length of this NLRI, > RD, > multicast source length, > multicast source, > multicast group length, > multicast group, > originating router (call it X). > > According to draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, a Leaf A-D > route derived from this S-PMSI A-D route will have the following NLRI: > > route type = 5 (Leaf A-D route), > length, > route key, > originating router (call it Y) > > where "route key" is defined as the MCAST-VPN NLRI of the route from which > the Leaf A-D route is derived. So if we modify the diagram to show the > individual fields of the route key, we find that the MCAST-VPN NLRI of the > Leaf A-D route is: > > route type = 5 (Leaf A-D route), > length of this NLRI, > route type = 3 (derived from S-PMSI A-D route), > length of the S-PMSI A-D route's NLRI (i.e., length from here > to the field containing Y) > RD, > multicast source length, > multicast source, > multicast group length, > multicast group, > originator of the S-PMSI A-D route (X) > originator of the Leaf A-D route (Y) That is correct. > However, in draft-ietf-mpls-seamless-mcast-01.txt, the NLRI of a Leaf A-D > route for "Internet multicast" is defined somewhat differently, as: > > route type = 5 (Leaf A-D route), > length of this NLRI, > RD, > multicast source length, > multicast source, > multicast group length, > multicast group, > ingress router, > originator of the Leaf A-D route (Y) > > Note that the NLRI for "internet multicast" is two bytes shorter than the > NLRI for MVPN, omitting the octets that would otherwise hold the type of the > S-PMSI A-D route from which the Leaf A-D route was derived, as well as the > length of the NLRI of that S-PMSI A-D route. That is correct too. > The draft does state that for "internet multicast", only two RD values are > legal: all zeroes or all ones. So it appears that there is a way to tell > whether a Leaf A-D route was derived from some other route or not: look at > the third octet of its NLRI. If that octet has the value 0x00 or the value > 0xff, then the Leaf A-D route is not derived from another route, and hence > must be an "Internet Multicast" route. The only other proper values of this > octet are the values 0x01, 0x02, and 0x03. > > I would appreciate it if the authors would verify whether this is the > correct interpretation or not. If it is, it would be good to add some text > that calls attention to this difference, and that explains explicitly how to > determine whether a received Leaf A-D route is or is not derived from some > other route. We will add some text to cover this in the next version of the draft. > If I understand this correctly, this piece of the protocol design doesn't > seem like a good practice to me. The procedures for parsing the Leaf A-D > route NLRI should not depend upon a priori knowledge that, in the envisioned > use cases, the valid "route type" values are different than the valid values > of the first octet of the RD. The coding rules for the RD and the coding > rules for the route type byte should be independent. Otherwise we are just > opening the door for incompatibilities and interworking problems in the > future. > > The obvious alternative for an "internet multicast" Leaf A-D route would be: > > route type = 5, > length of this NLRI, > route type = TBD (new value to indicate that is Leaf A-D route is > not derived from a PMSI A-D route.) > length from here to Y (perhaps this field could be omitted > without problem) > RD, > multicast source length, > multicast source, > multicast group length, > multicast group, > ingress router, > originator of the Leaf A-D route (Y) > > This keeps the RD coding rules independent from the "route type" coding > rules. > > BTW, page 13 of the draft says "the entire MCAST-VPN NLRI of the [Leaf A-D > route used for Internet multicast] has the following format", and then shows > a diagram that begins with the RD. This diagram does not actually show the > "entire NLRI", as it omits the route type and length fields. This should be > corrected. We will correct the diagram in the next version of the draft. > Also BTW, I think the term "Internet multicast" should actually be "global > table multicast". The use of "internet multicast" in this document doesn't > actually mean that the multicast comes from the internet, it just means that > the multicast is not a VPN customer multicast. The "internet multicast" > procedures could be used to set up, e.g., P-tunnels for MVPN, and there > shouldn't be any suggestion that the P-tunnels are "internet multicasts". We'll replace "Internet multicast" with "global table multicast" in the next version of the draft. Yakov. From ietfc@btconnect.com Thu Oct 27 08:35:50 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FBA21F8BB3 for ; Thu, 27 Oct 2011 08:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.449, 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 noMb3tbtZi82 for ; Thu, 27 Oct 2011 08:35:49 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr10.btconnect.com [213.123.20.128]) by ietfa.amsl.com (Postfix) with ESMTP id EF5E221F8BB2 for ; Thu, 27 Oct 2011 08:35:48 -0700 (PDT) Received: from host86-163-151-98.range86-163.btcentralplus.com (HELO pc6) ([86.163.151.98]) by c2bthomr10.btconnect.com with SMTP id EYZ20028; Thu, 27 Oct 2011 16:35:35 +0100 (BST) Message-ID: <000f01cc94b4$fc2e0400$4001a8c0@gateway.2wire.net> From: "t.petch" To: , "Carlos Pignataro" References: <6124.1319722275@erosen-linux> Date: Thu, 27 Oct 2011 16:30:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4EA97A45.0096, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.10.27.143914:17:7.944, ip=86.163.151.98, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS, MULTIPLE_RCPTS X-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0201.4EA97A47.01AF,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: mpls@ietf.org, draft-ietf-mpls-ldp-iana@tools.ietf.org Subject: Re: [mpls] draft-ietf-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 15:35:50 -0000 ----- Original Message ----- From: "Eric Rosen" To: "Carlos Pignataro" Cc: ; Sent: Thursday, October 27, 2011 3:31 PM > > > The fields marked "reserved" are atomic fields without syntax or > > semantics. draft-ietf-mpls-ldp-iana does not attempt to define the field > > or start using it. But without it, there are no rules as to what is > > needed for something to start using them. > > Since there are currently no IANA registries for the fields in question, it > is currently impossible for IANA to make any assignments to those fields. > As those fields are part of an IETF standard protocol, a redefinition of > those fields could only be accomplished by a "standards action". So what is > wrong with the status quo? > > The only issue I see is that if one wants to use one of the currently unused > bits, there is no central place to go to see if any other standards-track > RFC is already using it. I think this is a real issue, but I'm not sure it > can be addressed by creating an IANA registry. IANA will ask not only for > the allocation policy, but for the range of values that are assignable. If > we don't know whether we may want to use a field as a bit field or as 13-bit > integer, I don't know how we would provide that information to them. > > Maybe all that is needed is to have the GTSM draft indicate that it updates > RFC 5036, and mention in the abstract and introduction that it uses a bit > that is reserved in RFC 5036. > > It's also hard to see the point of creating registries for "ATM Label TLV", > "Frame Relay Label TLV". The first standards track RFC that needs these > registries can request them. I agree; this I-D, which I regret not having read earlier else I would have opposed its adoption seems to be setting in concrete matters that the editors of RFC5036, in their wisdom, left open until and when there was a need to be more specific, and, with the exception of one small item for GTSM, that wisdom appears, to me, still to be wise. Tom Petch > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > From cpignata@cisco.com Thu Oct 27 09:15:14 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C6421F8C28 for ; Thu, 27 Oct 2011 09:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.606 X-Spam-Level: X-Spam-Status: No, score=-105.606 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItQfQGmDrtjl for ; Thu, 27 Oct 2011 09:15:13 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7AF21F8C26 for ; Thu, 27 Oct 2011 09:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=3464; q=dns/txt; s=iport; t=1319732113; x=1320941713; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=pnST0DYdkJKhcNnNBB53YNmNliBr/99zG2xADG0eihE=; b=CyCWAjJCT73hGJR5bBQxBie5zjAVBZpl1Jv02hH58zRZK92CNG7C3fVh ozO0djpZPIIAP7Qef26lL0ZXny8VdNL3q09dN76h1M3QwBIEZw4WRgBy+ O+GHBmHpHsPgh7968PsnVzb2twi0uCT211/677Bd2vPgamxPPitK56DpE s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4BAPOCqU6tJV2Y/2dsb2JhbABDmg2PUYEFgXIBAQECAgEBAQ8BHQo0CwwEAgEIEQQBAQsGFwEGASYfCQgBAQQBEggBGYdoljwBnl6IHWEEiAaRPYxH X-IronPort-AV: E=Sophos;i="4.69,413,1315180800"; d="scan'208";a="31456695" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 27 Oct 2011 16:15:12 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9RGF8Nc013594; Thu, 27 Oct 2011 16:15:12 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Oct 2011 11:15:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Oct 2011 11:15:12 -0500 Message-ID: <960EC8F9A775AB40BF58D8953342D863069AA0C1@XMB-RCD-206.cisco.com> In-Reply-To: <000f01cc94b4$fc2e0400$4001a8c0@gateway.2wire.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] draft-ietf-mpls-ldp-iana Thread-Index: AcyUvhmQFND43YCuSb6slTF6Cw3DmQABDK8Q References: <6124.1319722275@erosen-linux> <000f01cc94b4$fc2e0400$4001a8c0@gateway.2wire.net> From: "Carlos Pignataro (cpignata)" To: "t.petch" , "Eric Rosen (erosen)" X-OriginalArrivalTime: 27 Oct 2011 16:15:09.0249 (UTC) FILETIME=[98F2E310:01CC94C3] Cc: mpls@ietf.org, draft-ietf-mpls-ldp-iana@tools.ietf.org Subject: Re: [mpls] draft-ietf-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 16:15:14 -0000 Similar states happen for other protocols as well. For example with the IPv6 ND Router Advertisement flags, where RFC2461 left a 6-bit Reserved opaque field next to two bit-flags (see ), and then other RFCs (RFC3775, RFC4191, RFC4389) define more bits from that Reserved. Finally, RFC5175 rationalizes all this in an IANA Registry, and further extends the bit-flag. But, to Eric's point, note that here an Experimental RFC 4389 defines a "Reserved" bit from a Std-track one. So it might not be automatically evident that the only redefinition path is as per "standards action". Seems like the proposed path forward good. Thanks, -- Carlos. PS: Tom: you may have also missed to oppose? Hindsight is 20/20. -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com]=20 Sent: Thursday, October 27, 2011 10:30 AM To: Eric Rosen (erosen); Carlos Pignataro (cpignata) Cc: draft-ietf-mpls-ldp-iana@tools.ietf.org; mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-ldp-iana ----- Original Message -----=20 From: "Eric Rosen" To: "Carlos Pignataro" Cc: ; Sent: Thursday, October 27, 2011 3:31 PM >=20 > > The fields marked "reserved" are atomic fields without syntax or > > semantics. draft-ietf-mpls-ldp-iana does not attempt to define the field > > or start using it. But without it, there are no rules as to what is > > needed for something to start using them. >=20 > Since there are currently no IANA registries for the fields in question, it > is currently impossible for IANA to make any assignments to those fields. > As those fields are part of an IETF standard protocol, a redefinition of > those fields could only be accomplished by a "standards action". So what is > wrong with the status quo? >=20 > The only issue I see is that if one wants to use one of the currently unused > bits, there is no central place to go to see if any other standards-track > RFC is already using it. I think this is a real issue, but I'm not sure it > can be addressed by creating an IANA registry. IANA will ask not only for > the allocation policy, but for the range of values that are assignable. If > we don't know whether we may want to use a field as a bit field or as 13-bit > integer, I don't know how we would provide that information to them. >=20 > Maybe all that is needed is to have the GTSM draft indicate that it updates > RFC 5036, and mention in the abstract and introduction that it uses a bit > that is reserved in RFC 5036. >=20 > It's also hard to see the point of creating registries for "ATM Label TLV", > "Frame Relay Label TLV". The first standards track RFC that needs these > registries can request them. I agree; this I-D, which I regret not having read earlier else I would have=20 opposed its adoption seems to be setting in concrete matters that the=20 editors of RFC5036, in their wisdom, left open until and when there=20 was a need to be more specific, and, with the exception of one small item for GTSM, that wisdom appears, to me, still to be wise. Tom Petch >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 From quintin.zhao@huawei.com Thu Oct 27 11:41:25 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB3521F84AD for ; Thu, 27 Oct 2011 11:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, 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 dQwY3SzVlq+M for ; Thu, 27 Oct 2011 11:41:25 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id F2B3521F84AC for ; Thu, 27 Oct 2011 11:41:24 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTQ002WBMKZ0F@usaga04-in.huawei.com> for mpls@ietf.org; Thu, 27 Oct 2011 13:41:23 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTQ00GGHMKY7R@usaga04-in.huawei.com> for mpls@ietf.org; Thu, 27 Oct 2011 13:41:23 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 27 Oct 2011 11:41:24 -0700 Received: from QZHAO (10.212.246.15) by DFWEML402-HUB.china.huawei.com (10.193.5.102) with Microsoft SMTP Server id 14.1.270.1; Thu, 27 Oct 2011 11:41:15 -0700 Date: Thu, 27 Oct 2011 14:41:10 -0400 From: Quintin Zhao In-reply-to: <18730.1319140937@erosen-linux> X-Originating-IP: [10.212.246.15] To: erosen@cisco.com Message-id: <001601cc94d7$ffead000$ffc07000$%zhao@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcyPY4v8T0FQE3a0Sr2atsHQTIERhwFbyw7Q References: "18 Oct 2011 13:14:09 -0400." <003c01cc8db9$5a22fb90$0e68f2b0$%zhao@huawei.com> <18730.1319140937@erosen-linux> Cc: mpls@ietf.org Subject: Re: [mpls] Subject: Forwarding discussion in ldp-multi-topology draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 18:41:25 -0000 Eric=A3=AC We did more testing/investigating and have some inputs for the concerns = and=20 questions you described in you last email. Either in the future version = of this LDP-MT draft or in the future version of the MPLS MT requirement/applicability draft,=20 we will add more explanations and examples details for this inter-AS vpn scenarios.=20 Thanks for your time! Quintin Eric>It's not really clear how the topology is to be set up, what the Eric>BGP relationships are, or why anyone would think this is easier or simpler Eric>than the conventional inter-AS L3VPN mechanisms (or other = alternatives such Eric>as overlays, carrier's carrier, etc.) After all, the = multi-topology Eric>configuration affects all the intermediate nodes, while the other mechanisms Eric>do not. But perhaps it's just difficult to understand the proposal from a few slides. The new AS configured using MPLS MT for inter-AS vpn purpose can have = the topology=20 specific routes including the VPN routes and IGP routes maintained = within itself and these=20 routes don't need to be propagated into other existing ASes. At the same time, the BGP routes=20 within other ASes using default topology don't need to be propagated = into this new AS. =20 it is true that all the nodes within this new AS need to be configured = for this new topology=20 for the inter-AS vpn purpose. In the case that not all of the = intermediate routes can be upgraded to=20 support the MT, then the tunneling through method can help the user to = do a phasing upgrade. Eric>Whether or not that proposal has merit, I don't think the LDP multi-topology Eric>draft should make unsubstantiated statements like Eric> "the LSP setup process can be simplified by configuring a = set of Eric> routers which are in different domains into a new single = domain with Eric> a new toplogy ID using the LDP multiple topology" Eric> or Eric> "the LDP lsp set up can be done easily without the complex inter-as Eric> VPN solution's option A, option B and option C." Agree. We will rephrase this in the new version of the draft to remove = the word "simplified" and "easily"=20 and just state that LDP multi-topology is another way to solve the = inter-AS VPN solution. We let users to=20 decide which solution is more suitable for their deployment environment. =20 From Kannan.Sampath@aricent.com Thu Oct 27 23:36:50 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F0E11E8099 for ; Thu, 27 Oct 2011 23:36:50 -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 giM9+lAL2ESK for ; Thu, 27 Oct 2011 23:36:49 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8FF11E80A1 for ; Thu, 27 Oct 2011 23:36:48 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 5D19636B3F; Fri, 28 Oct 2011 12:00:34 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id 45CBD36B3B; Fri, 28 Oct 2011 12:00:34 +0530 (IST) Received: from GUREXMB02.ASIAN.AD.ARICENT.COM ([10.203.171.130]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi; Fri, 28 Oct 2011 12:06:41 +0530 From: Kannan KV Sampath To: Quintin Zhao Date: Fri, 28 Oct 2011 12:06:39 +0530 Thread-Topic: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 Thread-Index: AcyUvR31zMiyPeDHSeyCszN/+jy/1gAfXxww Message-ID: <04EDFA4923CA7849A51A812953FF8736020EFC79DC@GUREXMB02.ASIAN.AD.ARICENT.COM> References: <000601cc93e8$bc29bf10$347d3d30$%zhao@huawei.com> <7213.1319729310@erosen-linux> In-Reply-To: <7213.1319729310@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "'Emily Chen\(Ying\)'" , 'IJsbrand Wijnands' Subject: Re: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 06:36:50 -0000 Hi Quintin, I have the same opinion as of Eric. The draft looks like a theoretical requirement. If there is no practical real time use case, it is not worth it to make it = so complicated. If you add more details and address the concerns raised by Eric, and, if we= start thinking about FRR, protection, etc., for both p2p tunnel and the mu= lticast path, the draft will become too complicated. May be you can explain more about the real time use case for this requireme= nt. Regards, Kannan -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eri= c Rosen Sent: Thursday, October 27, 2011 8:59 PM To: Quintin Zhao Cc: mpls@ietf.org; 'Emily Chen(Ying)'; 'IJsbrand Wijnands' Subject: Re: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 I share the already-expressed concern that there is no real use case of this. In theory, one can imagine deployments where all the routers support the mLDP control plane, but some do not support an MPLS multicast data plane. In practice, I'm not so sure. There may be deployments in which multicast forwarding capability is supported only around the edges of the network, and the core is "multicast free". The use of mLDP in this kind of deployment is discussed in draft-napierala-mpls-targeted-mldp. I also have some technical questions about the draft. I'm a little confused about the capability you're defining. Presumably it means "I don't support mLDP natively, but I support the mLDP tunnel mode". So I guess it would be illegal to advertise this capability and also advertise the ordinary "mLDP capability, though this isn't stated. In the topology: Root---R1---R2---R3---R4 suppose that R2 and R3 are "mldp-tunnel-only" mode routers, but R1 and R4 are full mldp routers. I think the interaction being proposed is: * R4 selects R3 as the upstream node for * R4 knows (from the capability) that R3 is "mldp-tunnel-only" * Therefore R4 asks R3 "who is the closest 'full mLDP' node on your path to Root?" R4 has to remember that it asked this question, and that it is waiting for an answer. * R3 asks R2 the same question, also telling it "R4 needs to know". * R2 selects R1 as the upstream node for and determines that R1 is a "full mLDP" node. * So R2 tells R1 "set up a targeted mLDP session with R4". Of course, R4 will probably not accept this session until some more messages flow from R2 to R3 to R4. * R2 tells R3 "R1 is the closest full mLDP node on the path to Root". * R3 tells R4 "R1 is the closest full mLDP node on the path to Root". * Once R4 learns this fact from R3, R4 will now be willing to accept a T-mLDP session from R1, and will choose R1 as its upstream hop (over a P2P tunnel) to Root. (Unless the unicast routing has changed in the meantime, of course.) I think this raises a number of issues: * I don't think I could say from the draft exactly which messages are use= d for which purposes. * If R2's next hop to Root changes, it needs to tell R3 to that R1 is no longer on the path, and R3 needs to tell R4. R4 may need to tear down the targeted session to R1. Probably R2 has to tell R1 "R4 is no longe= r going to use you as the upstream hop for Root", in which case R1 may need to tear down the targeted session. None of this is discussed in the draft. * If R2's next hop to Root changes, it also needs to find the closest ful= l mLDP node on the new path to Root. Then it needs to tell R3, R3 needs to tell R4, etc. * To make this work, I think the intermediate nodes have to maintain stat= e about which upstream node is the closest full mLDP node to Root, and which downstream nodes have asked about the path to Root. * If R4's next hop to Root changes, R4 has to tell R3 "never mind, I no longer care about the closest full mLDP node on your path to Root". R3 has to tell R2 "never mind", R2 has to tell R1 "tear down your T-mLDP session to R4" (if you have no other reason to keep it up). R4 will also have to tear down its T-mLDP session to R1 (if it has no other reason to keep it up.) This should all be discussed in the draft. The draft needs a lot more detail, and I think it will turn out to be quite complicated to handle all the race conditions and corner cases correctly. It's just not worth it unless there is a real use case. I'm also not sure that the notification messages and status tlv are the right mechanisms, as the functionality that seems to be needed is more like "request/respond/withdraw/release" than it is like "notify". _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D From quintin.zhao@huawei.com Fri Oct 28 07:58:36 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FB021F8B03 for ; Fri, 28 Oct 2011 07:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.375, 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 tMxyWe09nwr4 for ; Fri, 28 Oct 2011 07:58:35 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1706C21F8A64 for ; Fri, 28 Oct 2011 07:58:35 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTS00LGJ6XL1F@usaga02-in.huawei.com> for mpls@ietf.org; Fri, 28 Oct 2011 09:58:33 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LTS00HQ16XKA2@usaga02-in.huawei.com> for mpls@ietf.org; Fri, 28 Oct 2011 09:58:33 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 28 Oct 2011 07:58:25 -0700 Received: from QZHAO (10.212.244.5) by DFWEML402-HUB.china.huawei.com (10.193.5.102) with Microsoft SMTP Server id 14.1.270.1; Fri, 28 Oct 2011 07:58:25 -0700 Date: Fri, 28 Oct 2011 10:58:17 -0400 From: Quintin Zhao In-reply-to: <04EDFA4923CA7849A51A812953FF8736020EFC79DC@GUREXMB02.ASIAN.AD.ARICENT.COM> X-Originating-IP: [10.212.244.5] To: 'Eric Rosen' , 'Kannan KV Sampath' Message-id: <000701cc9582$07c2dd40$174897c0$%zhao@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcyUvR31zMiyPeDHSeyCszN/+jy/1gAfXxwwAA7+xgA= References: <000601cc93e8$bc29bf10$347d3d30$%zhao@huawei.com> <7213.1319729310@erosen-linux> <04EDFA4923CA7849A51A812953FF8736020EFC79DC@GUREXMB02.ASIAN.AD.ARICENT.COM> Cc: mpls@ietf.org, "'Emily Chen\(Ying\)'" , 'IJsbrand Wijnands' Subject: Re: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 14:58:36 -0000 Eric, Kannan, Thanks for your comments and suggestions! The user's requirement for this scenario is this: The first phase deployment needs the limited number of nodes to be upgraded to support = the mLDP and leave the rest of the nodes in the network as it is. Since the mLDP bud node might be in any place of the network, it is a little more complex than a "mLDP free core" network which Eric pointed out. It depends on the size of the network and how long the transition period = is for the complete upgrade of the network to mLDP, the non-direct = upstream mLDP node's finding might be needed in this deployment scenario to = trigger the T-LDP dynamically and in the failure cases, it needs to be tear down automatically also. For the signaling mechanism, we indeed missed a lot of details in the = draft as Eric pointed out including the capability advertisement and also we = did not describe clearly the goal for this solution is to make the mLDP LSP setup info to be passed through the non-mLDP node without maintaining = state. Now based on Eric's comment, we need further investigate to see if we = can make the solution work without making it very complex. Two more clarification question for Eric's analysis, (1) Once R1 receives the notification message from R2, R1 can initiated = the T-LDP session directly to R4 by telling R4 that it has received the notification message (protocol extension might be needed) . In this way, there is no need to make the R2 and R3 to maintain the state and R4 = doesn't need to wait for the message coming back from R1 through R2 and R3. Will this work? (2) Why can't we tear down the T-LDP session between R1 and R4 only when = the R4's next hop to root, in the example it is R3, is changed? =20 Quintin =20 -----Original Message----- From: Kannan KV Sampath [mailto:Kannan.Sampath@aricent.com]=20 Sent: 2011=C4=EA10=D4=C228=C8=D5 2:37 To: Quintin Zhao Cc: mpls@ietf.org; 'Emily Chen(Ying)'; 'IJsbrand Wijnands'; Eric Rosen Subject: RE: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 Hi Quintin, I have the same opinion as of Eric. The draft looks like a theoretical requirement. If there is no practical real time use case, it is not worth it to make = it so complicated. If you add more details and address the concerns raised by Eric, and, if = we start thinking about FRR, protection, etc., for both p2p tunnel and the multicast path, the draft will become too complicated. May be you can explain more about the real time use case for this requirement. Regards, Kannan -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Eric Rosen Sent: Thursday, October 27, 2011 8:59 PM To: Quintin Zhao Cc: mpls@ietf.org; 'Emily Chen(Ying)'; 'IJsbrand Wijnands' Subject: Re: [mpls] draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 I share the already-expressed concern that there is no real use case of this. In theory, one can imagine deployments where all the routers = support the mLDP control plane, but some do not support an MPLS multicast data plane. In practice, I'm not so sure. There may be deployments in which multicast forwarding capability is supported only around the edges of the network, and the core is = "multicast free". The use of mLDP in this kind of deployment is discussed in draft-napierala-mpls-targeted-mldp. I also have some technical questions about the draft. I'm a little confused about the capability you're defining. Presumably = it means "I don't support mLDP natively, but I support the mLDP tunnel = mode". So I guess it would be illegal to advertise this capability and also advertise the ordinary "mLDP capability, though this isn't stated. In the topology: Root---R1---R2---R3---R4 suppose that R2 and R3 are "mldp-tunnel-only" mode routers, but R1 and R4 are full mldp routers. I think the interaction being proposed is: * R4 selects R3 as the upstream node for * R4 knows (from the capability) that R3 is "mldp-tunnel-only" * Therefore R4 asks R3 "who is the closest 'full mLDP' node on your = path to Root?" R4 has to remember that it asked this question, and that = it is waiting for an answer. * R3 asks R2 the same question, also telling it "R4 needs to know". * R2 selects R1 as the upstream node for and determines that = R1 is a "full mLDP" node. * So R2 tells R1 "set up a targeted mLDP session with R4". Of course, R4 will probably not accept this session until some more messages flow from R2 to R3 to R4. * R2 tells R3 "R1 is the closest full mLDP node on the path to Root". * R3 tells R4 "R1 is the closest full mLDP node on the path to Root". * Once R4 learns this fact from R3, R4 will now be willing to accept a T-mLDP session from R1, and will choose R1 as its upstream hop (over = a P2P tunnel) to Root. (Unless the unicast routing has changed in the meantime, of course.) I think this raises a number of issues: * I don't think I could say from the draft exactly which messages are = used for which purposes. * If R2's next hop to Root changes, it needs to tell R3 to that R1 is = no longer on the path, and R3 needs to tell R4. R4 may need to tear = down the targeted session to R1. Probably R2 has to tell R1 "R4 is no = longer going to use you as the upstream hop for Root", in which case R1 may need to tear down the targeted session. None of this is discussed = in the draft. * If R2's next hop to Root changes, it also needs to find the closest = full mLDP node on the new path to Root. Then it needs to tell R3, R3 = needs to tell R4, etc. * To make this work, I think the intermediate nodes have to maintain = state about which upstream node is the closest full mLDP node to Root, and which downstream nodes have asked about the path to Root. * If R4's next hop to Root changes, R4 has to tell R3 "never mind, I = no longer care about the closest full mLDP node on your path to Root". = R3 has to tell R2 "never mind", R2 has to tell R1 "tear down your = T-mLDP session to R4" (if you have no other reason to keep it up). R4 will also have to tear down its T-mLDP session to R1 (if it has no other reason to keep it up.) This should all be discussed in the draft. The draft needs a lot more detail, and I think it will turn out to be = quite complicated to handle all the race conditions and corner cases = correctly. It's just not worth it unless there is a real use case. I'm also not sure that the notification messages and status tlv are the right mechanisms, as the functionality that seems to be needed is more = like "request/respond/withdraw/release" than it is like "notify". _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D =3D=3D=3D Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D =3D=3D=3D From internet-drafts@ietf.org Fri Oct 28 08:46:33 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC2421F8AEC; Fri, 28 Oct 2011 08:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 HLOJMytDQDhw; Fri, 28 Oct 2011 08:46:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4161821F8AD9; Fri, 28 Oct 2011 08:46:33 -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: 3.62 Message-ID: <20111028154633.8120.42786.idtracker@ietfa.amsl.com> Date: Fri, 28 Oct 2011 08:46:33 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-itu-t-identifiers-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 15:46:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : MPLS-TP Identifiers Following ITU-T Conventions Author(s) : Rolf Winter Eric Gray Huub van Helvoort Malcolm Betts Filename : draft-ietf-mpls-tp-itu-t-identifiers-01.txt Pages : 7 Date : 2011-10-28 This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and OAM functions to include identifier information in a format typically used by the ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-itu-t-identifiers-01= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-itu-t-identifiers-01.= txt From zhang.fei3@zte.com.cn Fri Oct 28 20:04:22 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84E421F8444; Fri, 28 Oct 2011 20:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.459 X-Spam-Level: X-Spam-Status: No, score=-98.459 tagged_above=-999 required=5 tests=[AWL=-0.824, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ypYypLEWeK2; Fri, 28 Oct 2011 20:04:21 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFEB1F0C35; Fri, 28 Oct 2011 20:04:20 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 466211279682118; Sat, 29 Oct 2011 10:56:00 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 60802.3522714603; Sat, 29 Oct 2011 11:03:50 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p9T340Ju032970; Sat, 29 Oct 2011 11:04:00 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <4EA71EF5.5060908@labn.net> To: Lou Berger MIME-Version: 1.0 X-KeepSent: 103F9DD6:3EF425EA-48257938:00106EA1; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Sat, 29 Oct 2011 11:03:53 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-29 11:04:02, Serialize complete at 2011-10-29 11:04:02 Content-Type: multipart/alternative; boundary="=_alternative 0010D56348257938_=" X-MAIL: mse02.zte.com.cn p9T340Ju032970 Cc: "mpls@ietf.org" , "ccamp@ietf.org" , Jaihari Kalijanakiraman Subject: Re: [mpls] [CCAMP] Request comments on draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 03:04:22 -0000 This is a multipart message in MIME format. --=_alternative 0010D56348257938_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 TG91DQoNClRoYW5rcyBmb3IgcG9pbnRpbmcgb3V0IHRoaXMgaXNzdWUsIHdlIHdpbGwgcmV2aXNl IGl0IGFuZCBhZGQgdGhlIGdsb2JhbCANCm5vZGUgaWQgaW5mb3JtYXRpb24gaW4gbmV4dCB2ZXJz aW9uDQoNCkJlc3QgcmVnYXJkcw0KDQpGZWkgDQoNCg0KDQpMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxh Ym4ubmV0PiANCjIwMTEtMTAtMjYgMDQ6NDENCg0KytW8/sjLDQp6aGFuZy5mZWkzQHp0ZS5jb20u Y24NCrOty80NCkphaWhhcmkgS2FsaWphbmFraXJhbWFuIDxqYWloYXJpa0BpcGluZnVzaW9uLmNv bT4sICJtcGxzQGlldGYub3JnIiANCjxtcGxzQGlldGYub3JnPiwgImNjYW1wQGlldGYub3JnIiA8 Y2NhbXBAaWV0Zi5vcmc+DQrW98ziDQpSZTogW0NDQU1QXSBbbXBsc10gUmVxdWVzdCBjb21tZW50 cyBvbiANCmRyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtLTAw DQoNCg0KDQoNCg0KDQpGZWksDQogDQoNCk9uIDEwLzIwLzIwMTEgOTowNCBQTSwgemhhbmcuZmVp M0B6dGUuY29tLmNuIHdyb3RlOg0KPiANCj4gSGkgSmFpaGFyaQ0KPiANCj4gQXMgdG8gdGhlIGFz c29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AsIHRoZSBiaW5kaW5nIGlzIGJhc2VkIG9uIHRoZQ0K PiBFeHRlbmRlZCBBc3NvY2lhdGlvbiBvYmplY3QsIHdoaWNoIGlzIGRlZmluZWQgaW4gdGhlIGRy YWZ0DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2NhbXAtYXNzb2Mt ZXh0LTAwLg0KPiANCj4gQSBuZXcgQXNzb2NpYXRpb24gVHlwZSBpcyBpbnRyb2R1Y2VkIGluIGFu b3RoZXIgZHJhZnQqLA0KPiANCipodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wMi4NCj4gDQo+IEJhc2Vk IG9uIHRoZSBhc3NvY2lhdGlvbiB0eXBlICJhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQIiwg dHdvDQo+IHJldmVyc2UgdW5pZGlyZWN0aW9uYWwgTFNQcyBjYW4gZm9ybSB0aGUgYXNzb2ljYXRl ZCBiaWRpcmVjdGlvbmFsIExTUC4NCj4gDQo+IEhvd2V2ZXIsIGFjY29yZGluZyB0byB0aGUgdXNh Z2Ugb2YgdGhpcyBvYmplY3QsIHNlZSB0aGUgZGVzY3JpcHRpb24gb2YNCj4gdGhlIHNlY3Rpb24g Mi4zLjEgaW4gdGhlIGRyYWZ0DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtY2NhbXAtYXNzb2MtZXh0LTAwLCAibm8NCj4gYXNzb2NpYXRpb25zIGFyZSBtYWRlIGFjcm9z cyBQYXRoIGFuZCBSZXN2IHN0YXRlIi4NCj4gDQo+IFRoYXQgaW5kaWNhdGVzIHRoYXQgdGhlIEFz c29jaWF0aW9uIG9iamVjdCBvciBFeHRlbmRlZCBBc3NvY2lhdGlvbg0KPiBvYmplY3QgY2FuIG5v dCBiZSB1c2VkIHRvIGNhcnJ5IGJhY2sgdGhlIGxvY2FsIGFzc2lnbmVkIHR1bm5lbCBudW1iZXIg aW4NCj4gdGhlIGNvbnRleHQgb2YgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1AuDQoNCnN1cmUs IGl0ICpjb3VsZCosIGJ1dCBhZ3JlZSB0aGF0IHRoaXMgaXNuJ3QgdGhlIHdheSB0byBnby4gKEFs dGhvdWdoDQpzdWNoIHVzYWdlIG1pZ2h0IGJlIGJldHRlciB0aGFuIGFsbG9jYXRpbmcgYSBuZXcg dG9wLWxldmVsIG9iamVjdCBmb3INCnRoaXMgcHVycG9zZSEpDQoNCj4gDQo+IFRoYXQgaXMgdGhl IGhpc3Rvcnkgd2h5IGEgbmV3IENvbm5lY3Rpb24gb2JqZWN0IGlzIGludHJvZHVjZWQgaGVyZSBm b3INCj4gdGhlIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUC4NCg0KSWYgYWxsIHRoaXMgZHJh ZnQgaXMgcmVhbGx5IGFib3V0IGlzIHByb3ZpZGluZyB0aGUgUkZDNjM3MCBaOSAoZWdyZXNzKQ0K VHVubmVsX051bSwgd2h5IG5vdCBqdXN0IGRlZmluZSBhIG5ldyBMU1AgQXR0cmlidXRlcyBUTFYg YW5kIGNhcnJ5IGl0DQp0aGVyZSAoaW4gUmVzdiBtZXNzYWdlcyBvZiBjby1yb3V0ZWQgYmlkaXJl Y3Rpb25hbCBMU1BzKT8gIE5ldyB0b3AtbGV2ZWwNClJTVlAgb2JqZWN0cyBhcmUgYSAqYmlkKiBk ZWFsIGFzIHRoZSBudW1iZXIgc3BhY2UgaXMgc28gc21hbGwuDQoNCkxvdQ0KPiANCj4gQmUgZ2xh ZCB0byBzaGFyZSBteSBvcGluaW9uIG9uIHRoaXMgc3ViamVjdC4NCj4gDQo+IEJlc3QgcmVnYXJk cw0KPiANCj4gRmVpDQo+IA0KPiANCj4gDQo+ICpKYWloYXJpIEthbGlqYW5ha2lyYW1hbiA8amFp aGFyaWtAaXBpbmZ1c2lvbi5jb20+Kg0KPiANCj4gMjAxMS0xMC0yMCAyMzo0MA0KPiANCj4gDQo+ IMrVvP7Iyw0KPiAgICAgICAgICAgICAgICB6aGFuZy5mZWkzQHp0ZS5jb20uY24NCj4gs63LzQ0K PiAgICAgICAgICAgICAgICAiY2NhbXBAaWV0Zi5vcmciIDxjY2FtcEBpZXRmLm9yZz4sICJtcGxz QGlldGYub3JnIiANCjxtcGxzQGlldGYub3JnPg0KPiDW98ziDQo+ICAgICAgICAgICAgICAgIFJl OiBbbXBsc10gUmVxdWVzdCBjb21tZW50cyBvbg0KPiBkcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRw LXJzdnB0ZS1leHQtdHVubmVsLW51bS0wMA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4g DQo+IEhpIFpoYW5nLA0KPiANCj4gVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4NCj4gDQo+ IFNvcnJ5IEkgbWlzdW5kZXJzdG9vZC4NCj4gDQo+IEkgaGF2ZSBhIHF1ZXN0aW9uIGhlcmUuLg0K PiANCj4gWW91IG1lbnRpb25lZCAiQXMgdG8gdGhlIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBM U1AsIHRoZXJlIGFyZSB0d28NCj4gaW5kZXBlbmRlbnQgc2lnbmFsaW5nIHByb2NlZHVyZXMgZm9y IHRoZSBmb3J3YXJkIGFuZCBiYWNrd2FyZA0KPiBkaXJlY3Rpb25hbCBMU1BzIi4uDQo+IA0KPiBT byBmb3IgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUHMgdGhlIHR3byBlbmRwb2ludHMgc2hv dWxkIGhhdmUgYW4NCj4gYXNzb2NpYXRpb24gb3IgYmluZGluZyBiZXR3ZWVuIHRoZSBmb3J3YXJk IGFuZCByZXZlcnNlIHR1bm5lbHMuDQo+IA0KPiBTbyBpZiB0aGUgZm9yd2FyZCBhbmQgcmV2ZXJz ZSBkaXJlY3Rpb25hbCBMU1BzIGFyZSBpbmRlcGVuZGVudGx5DQo+IHNpZ25hbGVkLCBob3cgdGhl IGJpbmRpbmcgb3IgYXNzb2NpYXRpb24gd2lsbCBiZSBlc3RhYmxpc2hlZCBiZXR3ZWVuIA0KdGhl bS4uDQo+IA0KPiBXaGVuIEkgcmVhZCB0aGUgZHJhZnQsIGluaXRpYWxseSB0aG91Z2h0IHRoYXQg dGhpcyBjb25uZWN0aW9uIG9iamVjdA0KPiB3aWxsIGJlIHVzZWQgdG8gZXN0YWJsaXNoIHRoYXQg YmluZGluZyBvciBhc3NvY2lhdGlvbi4uLg0KPiANCj4gSXMgdGhlcmUgYSB3YXkgdG8gZXN0YWJs aXNoIHRoaXMgYmluZGluZyBhbHJlYWR5Li4gUGxlYXNlIGNsYXJpZnkuLg0KPiANCj4gQ2FudCB3 ZSB1c2UgdGhpcyBvYmplY3QgdG8gZXN0YWJsaXNoIHRoYXQgYmluZGluZz8/DQo+IA0KPiBUaGFu a3MgYWdhaW4sIGZvciB5b3VyIGtpbmQgcmVwbHkuLi4NCj4gDQo+IA0KPiAvVGhhbmtzICYgUmVn YXJkcywvDQo+IC9KYWkgSGFyaSBNLksuLw0KPiAvSVAgSW5mdXNpb24vDQo+IA0KPiAyMDExLzEw LzIwIDxfemhhbmcuZmVpM0B6dGUuY29tLmNuXyA8bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5j bj4+DQo+IA0KPiBIaSBKYWloYXJpDQo+IA0KPiBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIDot KQ0KPiANCj4gVGhpcyBkcmFmdCBpcyBhYm91dCBob3cgdG8gY2FycnkgdGhlIGxvY2FsIGFzc2ln bmVkIHR1bm5lbCBudW1iZXIgb2YNCj4gY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQLCBzb3Jy eSBJIGRvIG5vdCBkZXNjcmliZSBpdCBjbGVhcmx5IGluIHRoZQ0KPiBtYWlsLg0KPiANCj4gQWNj b3JkaW5nIHRvIHRoZSBkZXNjcmlwdGlvbiBpbiBzZWN0aW9uIDUuMi4xIG9mIHRoZSBSRkM2Mzcw LCB0aGUgTFNQDQo+IG51bWJlciBrZWVwcyB0aGUgc2FtZSB1bmRlciB0aGUgY29udGV4dCBvZiBB MSBhbmQgWjkncyB0dW5uZWwgbnVtYmVyczoNCj4gDQo+IEExLXtOb2RlX0lEOjpUdW5uZWxfTnVt fTo6Wjkte05vZGVfSUQ6OlR1bm5lbF9OdW19OjpMU1BfTnVtDQo+IA0KPiBTbyBvbmx5IHRoZSB0 dW5uZWwgbnVtYmVyIGFzc2lnbmVkIGJ5IHRoZSBkZXN0aW5hdGlvbiBub2RlIGlzIG1pc3Npbmcu DQo+IA0KPiBBcyB0byB0aGUgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUCwgdGhlcmUgYXJl IHR3byBpbmRlcGVuZGVudA0KPiBzaWduYWxpbmcgcHJvY2VkdXJlcyBmb3IgdGhlIGZvcndhcmQg YW5kIGJhY2t3YXJkIGRpcmVjdGlvbmFsIExTUHMsIGFuZA0KPiB0aGUgQTEgYW5kIFo5DQo+IGtu b3cgZWFjaCBvdGhlciB0aGUgYXNzaWduZWQgdHVubmVsIG51bWJlciBhbmQgTFNQIG51bWJlci4N Cj4gDQo+IEZ1cnRoZXJtb3JlLCB0aGUgR2xvYmFsX0lEIGlzIGFsc28gbmVlZGVkIGlmIHRoZSBM U1AgaXMgYWNyb3NzIGRpZmZlcmVudA0KPiBBU3MsIHdoaWNoIG1heSBiZSBhZGRlZCBpbiBuZXh0 IHZlcnNpb24uDQo+IA0KPiBZb3VyIGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KPiANCj4gQmVzdCBy ZWdhcmRzDQo+IA0KPiBGZWkNCj4gDQo+ICpKYWloYXJpIEthbGlqYW5ha2lyYW1hbiA8KipfamFp aGFyaWtAaXBpbmZ1c2lvbi5jb21fKg0KPiA8bWFpbHRvOmphaWhhcmlrQGlwaW5mdXNpb24uY29t Pio+Kg0KPiANCj4gMjAxMS0xMC0yMCAxNToyMg0KPiANCj4gDQo+IMrVvP7Iyw0KPiAgICAgICAg ICAgICAgICBfemhhbmcuZmVpM0B6dGUuY29tLmNuXyA8bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNv bS5jbj4NCj4gs63LzQ0KPiAgICAgICAgICAgICAgICAiX21wbHNAaWV0Zi5vcmdfIDxtYWlsdG86 bXBsc0BpZXRmLm9yZz4iIDxfbXBsc0BpZXRmLm9yZ18NCj4gPG1haWx0bzptcGxzQGlldGYub3Jn Pj4NCj4g1vfM4g0KPiAgICAgICAgICAgICAgICBSZTogW21wbHNdIFJlcXVlc3QgY29tbWVudHMg b24NCj4gZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1bm5lbC1udW0tMDAN Cj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gT24gVGh1 LCBPY3QgMjAsIDIwMTEgYXQgMTI6NTAgUE0sIEphaWhhcmkgS2FsaWphbmFraXJhbWFuDQo+IDxf amFpaGFyaWtAaXBpbmZ1c2lvbi5jb21fIDxtYWlsdG86amFpaGFyaWtAaXBpbmZ1c2lvbi5jb20+ PiB3cm90ZToNCj4gSGkgWmhhbmcsDQo+IA0KPiBJIGhhdmUgYSBxdWVzdGlvbi4NCj4gDQo+IFRo ZSBjb25uZWN0aW9uIG9iamVjdCBpbiB0aGUgZHJhZnQgaGFzIG9ubHkgZGVzdGluYXRpb24gdHVu bmVsIG51bWJlci4NCj4gDQo+IEJ1dCBhcyBwZXIgVFAgSWRlbnRpZmllcnMgUkZDIDYzNzAsDQo+ ICoNCj4gDQo+IA0KPiA1LjIuMi4gIE1QTFMtVFAgQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExT UCBJZGVudGlmaWVycyoNCj4gDQo+ICAgICBBMS17R2xvYmFsX0lEOjpOb2RlX0lEOjpUdW5uZWxf TnVtOjpMU1BfTnVtfTo6DQo+ICAgICBaOS17R2xvYmFsX0lEOjpOb2RlX0lEOjpUdW5uZWxfTnVt OjpMU1BfTnVtfQ0KPiANCj4gDQo+IFNvIEkgdGhpbmsgdGhlIGNvbm5lY3Rpb24gb2JqZWN0IHNo b3VsZCBhbHNvIGluY2x1ZGUgdGhlIGRlc3RpbmF0aW9uIExTUA0KPiBudW1iZXIgYWxzby4NCj4g DQo+IFBsZWFzZSBjb21tZW50Li4NCj4gDQo+IC8NCj4gVGhhbmtzICYgUmVnYXJkcywvIC8NCj4g SmFpIEhhcmkgTS5LLg0KPiBJUCBJbmZ1c2lvbi8NCj4gDQo+IA0KPiBEYXRlOiBNb24sIDE3IE9j dCAyMDExIDE5OjA4OjUxICswODAwDQo+IEZyb206IF96aGFuZy5mZWkzQHp0ZS5jb20uY25fIDxt YWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuPg0KPiBUbzogIl9jY2FtcEBpZXRmLm9yZ18gPG1h aWx0bzpjY2FtcEBpZXRmLm9yZz4iIDxfY2NhbXBAaWV0Zi5vcmdfDQo+IDxtYWlsdG86Y2NhbXBA aWV0Zi5vcmc+PiwgIl9tcGxzQGlldGYub3JnXyA8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+Ig0KPiA8 X21wbHNAaWV0Zi5vcmdfIDxtYWlsdG86bXBsc0BpZXRmLm9yZz4+DQo+IFN1YmplY3Q6IFttcGxz XSBSZXF1ZXN0IGNvbW1lbnRzIG9uDQo+ICAgICAgIGRyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAt cnN2cHRlLWV4dC10dW5uZWwtbnVtLTAwDQo+IE1lc3NhZ2UtSUQ6DQo+IA0KPiA8X09GM0U3RkQ0 ODguNDA1QkYwQzUtT040ODI1NzkyQy4wMDM1MUNCRS00ODI1NzkyQy4wMDNEM0JBN0B6dGUuY29t LmNuXw0KPiA8DQptYWlsdG86T0YzRTdGRDQ4OC40MDVCRjBDNS1PTjQ4MjU3OTJDLjAwMzUxQ0JF LTQ4MjU3OTJDLjAwM0QzQkE3QHp0ZS5jb20uY24NCj4+DQo+IENvbnRlbnQtVHlwZTogdGV4dC9w bGFpbjsgY2hhcnNldD0idXMtYXNjaWkiDQo+IA0KPiBIaSBhbGwNCj4gDQo+IFdlJ3ZlIHN1Ym1p dHRlZCBhIGRyYWZ0IGZvciB0aGUgZ3JvdXAncyBjb25zaWRlcmF0aW9uLCBiZWxvdyBpcyB0aGUg DQpsaW5rOl8NCj4gDQpfX2h0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLWNj YW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtLTAwXy4NCj4gDQo+IFRoaXMgZHJhZnQg aXMgYWJvdXQgdGhlIHN1cHBvcnRpbmcgb2YgTVBMUy1UUCBNYWludGVuYW5jZSBJZGVudGlmaWVy cy4gDQpBcw0KPiBkZXNjcmliZWQgaW4gX2h0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYz NzBfLCBhdCBlYWNoIGVuZCBwb2ludCwgYQ0KPiB0dW5uZWwgaXMgdW5pcXVlbHkgaWRlbnRpZmll ZCBieSB0aGUgZW5kIHBvaW50J3MgTm9kZV9JRCBhbmQgYSBsb2NhbGx5DQo+IGFzc2lnbmVkIHR1 bm5lbCBudW1iZXIsIHdoaWNoIGFsbG93IGEgY29tcGFjdCBmb3JtIGZvciB0aGUgTUVQX0lELCBh bmQNCj4gZXh0ZW5zaW9ucyB3aWxsIGJlIHJlcXVpcmVkIHRvIEdNUExTIHRvIHN1cHBvcnQgdGhl c2UgaWRlbnRpZmllcnMuDQo+IEZ1cnRoZXJtb3JlLCBfaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNjM3M18gYWRkcmVzc2VkIHRoaXMgaXNzdWUgDQppbg0KPiBzZWN0aW9uIDQuNC44Lg0K PiANCj4gT2J2aW91c2x5LCB0aGlzIGlzc3VlIGNhbiBiZSBzb2x2ZWQgYnkgZGVmaW5pbmcgYSBu ZXcgb2JqZWN0LCBzdWNoIGFzDQo+IENvbm5lY3Rpb24gT2JqZWN0IGFzIGRlc2NyaWJlZCBpbiB0 aGlzIGRyYWZ0LCBvciBhIG5ldyBzdWItVExWIGNhbGwgDQpNRVBfSUQNCj4gY2FuIGJlIGNhcnJp ZWQgYmFjayB0byB0aGUgaW5ncmVzcyBMU1IgaW4gUmVzdiBtZXNzYWdlIHdoZW4gdGhlICJDViIg DQpmbGFnDQo+IG9mIHRoZSBPQU0gRnVuY3Rpb24gRmxhZ3MgU3ViLVRMViBpcyBzZXQsIHdoaWNo IG1heSBiZSBjb25zaWRlcmVkIGluIHRoZQ0KPiBzdWJzZXF1ZW50IHZlcnNpb24gb2YgdGhlIGRy YWZ0Xw0KPiANCl9faHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1y c3ZwLXRlLW1wbHMtdHAtb2FtLWV4dC0wNl8uDQo+IA0KPiBXZSBob3BlIHlvdSdsbCBmaW5kIHRo ZSB0aW1lIHRvIGxvb2sgdGhyb3VnaCB0aGUgZHJhZnQgYW5kIGNvbW1lbnQgb24gDQp0aGUNCj4g bGlzdCwgaGVscCBqdWRnZSB3aGljaCB3YXkgaXMgbW9yZSBzdWl0YWJsZSBiZWZvcmUgdGhlIFdH IG1lZXRpbmcgaW4NCj4gVGFpcGVpLCBhbmQgaG9wZSB0aGF0IHdlJ2xsIGJlIGFibGUgdG8gaGF2 ZSBhIGZydWl0ZnVsIGFuZCBsaXZlbHkNCj4gZGlzY3Vzc2lvbiB0aGVyZS4NCj4gDQo+IA0KPiBC ZXN0LA0KPiANCj4gRmVpDQo+IA0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4gQ0NBTVBA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0K DQoNCg0K --=_alternative 0010D56348257938_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxvdTwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzIGZvciBwb2ludGluZyBvdXQg dGhpcyBpc3N1ZSwNCndlIHdpbGwgcmV2aXNlIGl0IGFuZCBhZGQgdGhlIGdsb2JhbCBub2RlIGlk IGluZm9ybWF0aW9uIGluIG5leHQgdmVyc2lvbjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVzdCByZWdhcmRzPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5GZWkgPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0K PHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkxvdSBCZXJnZXIgJmx0O2xiZXJnZXJAbGFibi5u ZXQmZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIw MTEtMTAtMjYgMDQ6NDE8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+emhhbmcuZmVpM0B6dGUuY29tLmNuPC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5K YWloYXJpIEthbGlqYW5ha2lyYW1hbiAmbHQ7amFpaGFyaWtAaXBpbmZ1c2lvbi5jb20mZ3Q7LA0K JnF1b3Q7bXBsc0BpZXRmLm9yZyZxdW90OyAmbHQ7bXBsc0BpZXRmLm9yZyZndDssICZxdW90O2Nj YW1wQGlldGYub3JnJnF1b3Q7DQombHQ7Y2NhbXBAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5SZTogW0NDQU1QXSBbbXBsc10gUmVxdWVzdCBjb21tZW50cw0Kb24gJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1bm5l bC1udW0tMDA8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPkZlaSw8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KPGJyPg0KPGJyPg0KT24gMTAvMjAvMjAxMSA5OjA0IFBNLCB6 aGFuZy5mZWkzQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhpIEphaWhh cmk8YnI+DQomZ3Q7IDxicj4NCiZndDsgQXMgdG8gdGhlIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25h bCBMU1AsIHRoZSBiaW5kaW5nIGlzIGJhc2VkIG9uIHRoZTxicj4NCiZndDsgRXh0ZW5kZWQgQXNz b2NpYXRpb24gb2JqZWN0LCB3aGljaCBpcyBkZWZpbmVkIGluIHRoZSBkcmFmdDxicj4NCiZndDsg aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1hc3NvYy1leHQtMDAu PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEEgbmV3IEFzc29jaWF0aW9uIFR5cGUgaXMgaW50cm9kdWNl ZCBpbiBhbm90aGVyIGRyYWZ0Kiw8YnI+DQomZ3Q7ICpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wMi48 YnI+DQomZ3Q7IDxicj4NCiZndDsgQmFzZWQgb24gdGhlIGFzc29jaWF0aW9uIHR5cGUgJnF1b3Q7 YXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUCZxdW90OywNCnR3bzxicj4NCiZndDsgcmV2ZXJz ZSB1bmlkaXJlY3Rpb25hbCBMU1BzIGNhbiBmb3JtIHRoZSBhc3NvaWNhdGVkIGJpZGlyZWN0aW9u YWwNCkxTUC48YnI+DQomZ3Q7IDxicj4NCiZndDsgSG93ZXZlciwgYWNjb3JkaW5nIHRvIHRoZSB1 c2FnZSBvZiB0aGlzIG9iamVjdCwgc2VlIHRoZSBkZXNjcmlwdGlvbg0Kb2Y8YnI+DQomZ3Q7IHRo ZSBzZWN0aW9uIDIuMy4xIGluIHRoZSBkcmFmdDxicj4NCiZndDsgaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1hc3NvYy1leHQtMDAsICZxdW90O25vPGJyPg0KJmd0 OyBhc3NvY2lhdGlvbnMgYXJlIG1hZGUgYWNyb3NzIFBhdGggYW5kIFJlc3Ygc3RhdGUmcXVvdDsu PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYXQgaW5kaWNhdGVzIHRoYXQgdGhlIEFzc29jaWF0aW9u IG9iamVjdCBvciBFeHRlbmRlZCBBc3NvY2lhdGlvbjxicj4NCiZndDsgb2JqZWN0IGNhbiBub3Qg YmUgdXNlZCB0byBjYXJyeSBiYWNrIHRoZSBsb2NhbCBhc3NpZ25lZCB0dW5uZWwgbnVtYmVyDQpp bjxicj4NCiZndDsgdGhlIGNvbnRleHQgb2YgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1AuPGJy Pg0KPGJyPg0Kc3VyZSwgaXQgKmNvdWxkKiwgYnV0IGFncmVlIHRoYXQgdGhpcyBpc24ndCB0aGUg d2F5IHRvIGdvLiAoQWx0aG91Z2g8YnI+DQpzdWNoIHVzYWdlIG1pZ2h0IGJlIGJldHRlciB0aGFu IGFsbG9jYXRpbmcgYSBuZXcgdG9wLWxldmVsIG9iamVjdCBmb3I8YnI+DQp0aGlzIHB1cnBvc2Uh KTxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGF0IGlzIHRoZSBoaXN0b3J5IHdoeSBhIG5l dyBDb25uZWN0aW9uIG9iamVjdCBpcyBpbnRyb2R1Y2VkIGhlcmUNCmZvcjxicj4NCiZndDsgdGhl IGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUC48YnI+DQo8YnI+DQpJZiBhbGwgdGhpcyBkcmFm dCBpcyByZWFsbHkgYWJvdXQgaXMgcHJvdmlkaW5nIHRoZSBSRkM2MzcwIFo5IChlZ3Jlc3MpPGJy Pg0KVHVubmVsX051bSwgd2h5IG5vdCBqdXN0IGRlZmluZSBhIG5ldyBMU1AgQXR0cmlidXRlcyBU TFYgYW5kIGNhcnJ5IGl0PGJyPg0KdGhlcmUgKGluIFJlc3YgbWVzc2FnZXMgb2YgY28tcm91dGVk IGJpZGlyZWN0aW9uYWwgTFNQcyk/ICZuYnNwO05ldyB0b3AtbGV2ZWw8YnI+DQpSU1ZQIG9iamVj dHMgYXJlIGEgKmJpZCogZGVhbCBhcyB0aGUgbnVtYmVyIHNwYWNlIGlzIHNvIHNtYWxsLjxicj4N Cjxicj4NCkxvdTxicj4NCiZndDsgPGJyPg0KJmd0OyBCZSBnbGFkIHRvIHNoYXJlIG15IG9waW5p b24gb24gdGhpcyBzdWJqZWN0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBCZXN0IHJlZ2FyZHM8YnI+ DQomZ3Q7IDxicj4NCiZndDsgRmVpPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyAqSmFpaGFyaSBLYWxpamFuYWtpcmFtYW4gJmx0O2phaWhhcmlrQGlwaW5mdXNpb24u Y29tJmd0Oyo8YnI+DQomZ3Q7IDxicj4NCiZndDsgMjAxMS0xMC0yMCAyMzo0MDxicj4NCiZndDsg PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsgytW8/sjLPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3poYW5nLmZl aTNAenRlLmNvbS5jbjxicj4NCiZndDsgs63LzTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtjY2FtcEBp ZXRmLm9yZyZxdW90Ow0KJmx0O2NjYW1wQGlldGYub3JnJmd0OywgJnF1b3Q7bXBsc0BpZXRmLm9y ZyZxdW90OyAmbHQ7bXBsc0BpZXRmLm9yZyZndDs8YnI+DQomZ3Q7INb3zOI8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7UmU6DQpbbXBsc10gUmVxdWVzdCBjb21tZW50cyBvbjxicj4NCiZndDsgZHJhZnQtemhhbmct Y2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1bm5lbC1udW0tMDA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhpIFpoYW5nLDxicj4NCiZndDsgPGJyPg0KJmd0 OyBUaGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9uLjxicj4NCiZndDsgPGJyPg0KJmd0OyBTb3Jy eSBJIG1pc3VuZGVyc3Rvb2QuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgaGF2ZSBhIHF1ZXN0aW9u IGhlcmUuLjxicj4NCiZndDsgPGJyPg0KJmd0OyBZb3UgbWVudGlvbmVkICZxdW90O0FzIHRvIHRo ZSBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQLCB0aGVyZQ0KYXJlIHR3bzxicj4NCiZndDsg aW5kZXBlbmRlbnQgc2lnbmFsaW5nIHByb2NlZHVyZXMgZm9yIHRoZSBmb3J3YXJkIGFuZCBiYWNr d2FyZDxicj4NCiZndDsgZGlyZWN0aW9uYWwgTFNQcyZxdW90Oy4uPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IFNvIGZvciBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQcyB0aGUgdHdvIGVuZHBvaW50 cyBzaG91bGQgaGF2ZQ0KYW48YnI+DQomZ3Q7IGFzc29jaWF0aW9uIG9yIGJpbmRpbmcgYmV0d2Vl biB0aGUgZm9yd2FyZCBhbmQgcmV2ZXJzZSB0dW5uZWxzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBT byBpZiB0aGUgZm9yd2FyZCBhbmQgcmV2ZXJzZSBkaXJlY3Rpb25hbCBMU1BzIGFyZSBpbmRlcGVu ZGVudGx5PGJyPg0KJmd0OyBzaWduYWxlZCwgaG93IHRoZSBiaW5kaW5nIG9yIGFzc29jaWF0aW9u IHdpbGwgYmUgZXN0YWJsaXNoZWQgYmV0d2Vlbg0KdGhlbS4uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFdoZW4gSSByZWFkIHRoZSBkcmFmdCwgaW5pdGlhbGx5IHRob3VnaHQgdGhhdCB0aGlzIGNvbm5l Y3Rpb24gb2JqZWN0PGJyPg0KJmd0OyB3aWxsIGJlIHVzZWQgdG8gZXN0YWJsaXNoIHRoYXQgYmlu ZGluZyBvciBhc3NvY2lhdGlvbi4uLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJcyB0aGVyZSBhIHdh eSB0byBlc3RhYmxpc2ggdGhpcyBiaW5kaW5nIGFscmVhZHkuLiBQbGVhc2UgY2xhcmlmeS4uPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IENhbnQgd2UgdXNlIHRoaXMgb2JqZWN0IHRvIGVzdGFibGlzaCB0 aGF0IGJpbmRpbmc/Pzxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFua3MgYWdhaW4sIGZvciB5b3Vy IGtpbmQgcmVwbHkuLi48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAvVGhhbmtzICZh bXA7IFJlZ2FyZHMsLzxicj4NCiZndDsgL0phaSBIYXJpIE0uSy4vPGJyPg0KJmd0OyAvSVAgSW5m dXNpb24vPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDIwMTEvMTAvMjAgJmx0O196aGFuZy5mZWkzQHp0 ZS5jb20uY25fICZsdDttYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuJmd0OyZndDs8YnI+DQom Z3Q7IDxicj4NCiZndDsgSGkgSmFpaGFyaTxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFua3MgZm9y IHlvdXIgY29tbWVudHMuIDotKTxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGlzIGRyYWZ0IGlzIGFi b3V0IGhvdyB0byBjYXJyeSB0aGUgbG9jYWwgYXNzaWduZWQgdHVubmVsIG51bWJlcg0Kb2Y8YnI+ DQomZ3Q7IGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUCwgc29ycnkgSSBkbyBub3QgZGVzY3Jp YmUgaXQgY2xlYXJseSBpbg0KdGhlPGJyPg0KJmd0OyBtYWlsLjxicj4NCiZndDsgPGJyPg0KJmd0 OyBBY2NvcmRpbmcgdG8gdGhlIGRlc2NyaXB0aW9uIGluIHNlY3Rpb24gNS4yLjEgb2YgdGhlIFJG QzYzNzAsIHRoZQ0KTFNQPGJyPg0KJmd0OyBudW1iZXIga2VlcHMgdGhlIHNhbWUgdW5kZXIgdGhl IGNvbnRleHQgb2YgQTEgYW5kIFo5J3MgdHVubmVsIG51bWJlcnM6PGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEExLXtOb2RlX0lEOjpUdW5uZWxfTnVtfTo6Wjkte05vZGVfSUQ6OlR1bm5lbF9OdW19OjpM U1BfTnVtPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNvIG9ubHkgdGhlIHR1bm5lbCBudW1iZXIgYXNz aWduZWQgYnkgdGhlIGRlc3RpbmF0aW9uIG5vZGUgaXMgbWlzc2luZy48YnI+DQomZ3Q7IDxicj4N CiZndDsgQXMgdG8gdGhlIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AsIHRoZXJlIGFyZSB0 d28gaW5kZXBlbmRlbnQ8YnI+DQomZ3Q7IHNpZ25hbGluZyBwcm9jZWR1cmVzIGZvciB0aGUgZm9y d2FyZCBhbmQgYmFja3dhcmQgZGlyZWN0aW9uYWwgTFNQcywNCmFuZDxicj4NCiZndDsgdGhlIEEx IGFuZCBaOTxicj4NCiZndDsga25vdyBlYWNoIG90aGVyIHRoZSBhc3NpZ25lZCB0dW5uZWwgbnVt YmVyIGFuZCBMU1AgbnVtYmVyLjxicj4NCiZndDsgPGJyPg0KJmd0OyBGdXJ0aGVybW9yZSwgdGhl IEdsb2JhbF9JRCBpcyBhbHNvIG5lZWRlZCBpZiB0aGUgTFNQIGlzIGFjcm9zcyBkaWZmZXJlbnQ8 YnI+DQomZ3Q7IEFTcywgd2hpY2ggbWF5IGJlIGFkZGVkIGluIG5leHQgdmVyc2lvbi48YnI+DQom Z3Q7IDxicj4NCiZndDsgWW91ciBjb21tZW50cyBhcmUgd2VsY29tZS48YnI+DQomZ3Q7IDxicj4N CiZndDsgQmVzdCByZWdhcmRzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEZlaTxicj4NCiZndDsgPGJy Pg0KJmd0OyAqSmFpaGFyaSBLYWxpamFuYWtpcmFtYW4gJmx0OyoqX2phaWhhcmlrQGlwaW5mdXNp b24uY29tXyo8YnI+DQomZ3Q7ICZsdDttYWlsdG86amFpaGFyaWtAaXBpbmZ1c2lvbi5jb20mZ3Q7 KiZndDsqPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDIwMTEtMTAtMjAgMTU6MjI8YnI+DQomZ3Q7IDxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7IMrVvP7Iyzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtfemhhbmcuZmVp M0B6dGUuY29tLmNuXw0KJmx0O21haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24mZ3Q7PGJyPg0K Jmd0OyCzrcvNPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O19tcGxzQGlldGYub3JnXw0KJmx0O21haWx0 bzptcGxzQGlldGYub3JnJmd0OyZxdW90OyAmbHQ7X21wbHNAaWV0Zi5vcmdfPGJyPg0KJmd0OyAm bHQ7bWFpbHRvOm1wbHNAaWV0Zi5vcmcmZ3Q7Jmd0Ozxicj4NCiZndDsg1vfM4jxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtSZToNClttcGxzXSBSZXF1ZXN0IGNvbW1lbnRzIG9uPGJyPg0KJmd0OyBkcmFmdC16aGFu Zy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtdHVubmVsLW51bS0wMDxicj4NCiZndDsgPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgPGJyPg0KJmd0OyBPbiBUaHUsIE9jdCAyMCwgMjAxMSBhdCAxMjo1MCBQTSwgSmFpaGFy aSBLYWxpamFuYWtpcmFtYW48YnI+DQomZ3Q7ICZsdDtfamFpaGFyaWtAaXBpbmZ1c2lvbi5jb21f ICZsdDttYWlsdG86amFpaGFyaWtAaXBpbmZ1c2lvbi5jb20mZ3Q7Jmd0Ow0Kd3JvdGU6PGJyPg0K Jmd0OyBIaSBaaGFuZyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBoYXZlIGEgcXVlc3Rpb24uPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBjb25uZWN0aW9uIG9iamVjdCBpbiB0aGUgZHJhZnQgaGFz IG9ubHkgZGVzdGluYXRpb24gdHVubmVsIG51bWJlci48YnI+DQomZ3Q7IDxicj4NCiZndDsgQnV0 IGFzIHBlciBUUCBJZGVudGlmaWVycyBSRkMgNjM3MCw8YnI+DQomZ3Q7ICo8YnI+DQomZ3Q7IDxi cj4NCiZndDsgPGJyPg0KJmd0OyA1LjIuMi4gJm5ic3A7TVBMUy1UUCBBc3NvY2lhdGVkIEJpZGly ZWN0aW9uYWwgTFNQIElkZW50aWZpZXJzKjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7IEExLXtHbG9iYWxfSUQ6Ok5vZGVfSUQ6OlR1bm5lbF9OdW06OkxTUF9OdW19Ojo8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsgWjkte0dsb2JhbF9JRDo6Tm9kZV9JRDo6VHVubmVsX051bTo6TFNQ X051bX08YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBTbyBJIHRoaW5rIHRoZSBjb25u ZWN0aW9uIG9iamVjdCBzaG91bGQgYWxzbyBpbmNsdWRlIHRoZSBkZXN0aW5hdGlvbg0KTFNQPGJy Pg0KJmd0OyBudW1iZXIgYWxzby48YnI+DQomZ3Q7IDxicj4NCiZndDsgUGxlYXNlIGNvbW1lbnQu Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAvPGJyPg0KJmd0OyBUaGFua3MgJmFtcDsgUmVnYXJkcywv IC88YnI+DQomZ3Q7IEphaSBIYXJpIE0uSy48YnI+DQomZ3Q7IElQIEluZnVzaW9uLzxicj4NCiZn dDsgPGJyPg0KJmd0OyAmbmJzcDs8YnI+DQomZ3Q7IERhdGU6IE1vbiwgMTcgT2N0IDIwMTEgMTk6 MDg6NTEgKzA4MDA8YnI+DQomZ3Q7IEZyb206IF96aGFuZy5mZWkzQHp0ZS5jb20uY25fICZsdDtt YWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuJmd0Ozxicj4NCiZndDsgVG86ICZxdW90O19jY2Ft cEBpZXRmLm9yZ18gJmx0O21haWx0bzpjY2FtcEBpZXRmLm9yZyZndDsmcXVvdDsgJmx0O19jY2Ft cEBpZXRmLm9yZ188YnI+DQomZ3Q7ICZsdDttYWlsdG86Y2NhbXBAaWV0Zi5vcmcmZ3Q7Jmd0Oywg JnF1b3Q7X21wbHNAaWV0Zi5vcmdfICZsdDttYWlsdG86bXBsc0BpZXRmLm9yZyZndDsmcXVvdDs8 YnI+DQomZ3Q7ICZsdDtfbXBsc0BpZXRmLm9yZ18gJmx0O21haWx0bzptcGxzQGlldGYub3JnJmd0 OyZndDs8YnI+DQomZ3Q7IFN1YmplY3Q6IFttcGxzXSBSZXF1ZXN0IGNvbW1lbnRzIG9uPGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0 ZS1leHQtdHVubmVsLW51bS0wMDxicj4NCiZndDsgTWVzc2FnZS1JRDo8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyAmbHQ7X09GM0U3RkQ0ODguNDA1QkYwQzUtT040ODI1 NzkyQy4wMDM1MUNCRS00ODI1NzkyQy4wMDNEM0JBN0B6dGUuY29tLmNuXzxicj4NCiZndDsgJmx0 O21haWx0bzpPRjNFN0ZENDg4LjQwNUJGMEM1LU9ONDgyNTc5MkMuMDAzNTFDQkUtNDgyNTc5MkMu MDAzRDNCQTdAenRlLmNvbS5jbiZndDsmZ3Q7PGJyPg0KJmd0OyBDb250ZW50LVR5cGU6IHRleHQv cGxhaW47IGNoYXJzZXQ9JnF1b3Q7dXMtYXNjaWkmcXVvdDs8YnI+DQomZ3Q7IDxicj4NCiZndDsg SGkgYWxsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdlJ3ZlIHN1Ym1pdHRlZCBhIGRyYWZ0IGZvciB0 aGUgZ3JvdXAncyBjb25zaWRlcmF0aW9uLCBiZWxvdyBpcyB0aGUNCmxpbms6Xzxicj4NCiZndDsg X19odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJz dnB0ZS1leHQtdHVubmVsLW51bS0wMF8uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoaXMgZHJhZnQg aXMgYWJvdXQgdGhlIHN1cHBvcnRpbmcgb2YgTVBMUy1UUCBNYWludGVuYW5jZSBJZGVudGlmaWVy cy4NCkFzPGJyPg0KJmd0OyBkZXNjcmliZWQgaW4gX2h0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzYzNzBfLCBhdCBlYWNoIGVuZCBwb2ludCwNCmE8YnI+DQomZ3Q7IHR1bm5lbCBpcyB1bmlx dWVseSBpZGVudGlmaWVkIGJ5IHRoZSBlbmQgcG9pbnQncyBOb2RlX0lEIGFuZCBhIGxvY2FsbHk8 YnI+DQomZ3Q7IGFzc2lnbmVkIHR1bm5lbCBudW1iZXIsIHdoaWNoIGFsbG93IGEgY29tcGFjdCBm b3JtIGZvciB0aGUgTUVQX0lELA0KYW5kPGJyPg0KJmd0OyBleHRlbnNpb25zIHdpbGwgYmUgcmVx dWlyZWQgdG8gR01QTFMgdG8gc3VwcG9ydCB0aGVzZSBpZGVudGlmaWVycy48YnI+DQomZ3Q7IEZ1 cnRoZXJtb3JlLCBfaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjM3M18gYWRkcmVzc2Vk IHRoaXMgaXNzdWUNCmluPGJyPg0KJmd0OyBzZWN0aW9uIDQuNC44Ljxicj4NCiZndDsgPGJyPg0K Jmd0OyBPYnZpb3VzbHksIHRoaXMgaXNzdWUgY2FuIGJlIHNvbHZlZCBieSBkZWZpbmluZyBhIG5l dyBvYmplY3QsIHN1Y2gNCmFzPGJyPg0KJmd0OyBDb25uZWN0aW9uIE9iamVjdCBhcyBkZXNjcmli ZWQgaW4gdGhpcyBkcmFmdCwgb3IgYSBuZXcgc3ViLVRMViBjYWxsDQpNRVBfSUQ8YnI+DQomZ3Q7 IGNhbiBiZSBjYXJyaWVkIGJhY2sgdG8gdGhlIGluZ3Jlc3MgTFNSIGluIFJlc3YgbWVzc2FnZSB3 aGVuIHRoZSAmcXVvdDtDViZxdW90Ow0KZmxhZzxicj4NCiZndDsgb2YgdGhlIE9BTSBGdW5jdGlv biBGbGFncyBTdWItVExWIGlzIHNldCwgd2hpY2ggbWF5IGJlIGNvbnNpZGVyZWQNCmluIHRoZTxi cj4NCiZndDsgc3Vic2VxdWVudCB2ZXJzaW9uIG9mIHRoZSBkcmFmdF88YnI+DQomZ3Q7IF9faHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1yc3ZwLXRlLW1wbHMtdHAt b2FtLWV4dC0wNl8uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdlIGhvcGUgeW91J2xsIGZpbmQgdGhl IHRpbWUgdG8gbG9vayB0aHJvdWdoIHRoZSBkcmFmdCBhbmQgY29tbWVudA0Kb24gdGhlPGJyPg0K Jmd0OyBsaXN0LCBoZWxwIGp1ZGdlIHdoaWNoIHdheSBpcyBtb3JlIHN1aXRhYmxlIGJlZm9yZSB0 aGUgV0cgbWVldGluZw0KaW48YnI+DQomZ3Q7IFRhaXBlaSwgYW5kIGhvcGUgdGhhdCB3ZSdsbCBi ZSBhYmxlIHRvIGhhdmUgYSBmcnVpdGZ1bCBhbmQgbGl2ZWx5PGJyPg0KJmd0OyBkaXNjdXNzaW9u IHRoZXJlLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJlc3QsPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IEZlaTxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsg PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZndDsgQ0NBTVAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBDQ0FNUEBpZXRmLm9yZzxi cj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDxicj4N Cjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 0010D56348257938_=-- From internet-drafts@ietf.org Fri Oct 28 20:52:07 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD921F0C47; Fri, 28 Oct 2011 20:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 x+n-Ap-3ewMT; Fri, 28 Oct 2011 20:52:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D0921F846A; Fri, 28 Oct 2011 20:52:07 -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: 3.62 Message-ID: <20111029035207.11446.31938.idtracker@ietfa.amsl.com> Date: Fri, 28 Oct 2011 20:52:07 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-ttl-tlv-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 03:52:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Definition of Time-to-Live TLV for LSP-Ping Mechanisms Author(s) : Siva Sivabalan Sami Boutros George Swallow Shaleen Saxena Vishwas Manral Sam Aldrin Filename : draft-ietf-mpls-lsp-ping-ttl-tlv-01.txt Pages : 7 Date : 2011-10-28 LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. However, in the present form, this mechanism is inadequate to verify connectivity of a segment of a Multi-Segment PseudoWire (MS-PW) from any node on the path of the MS-PW. This document defines a TLV to address this shortcoming. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-ttl-tlv-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-ttl-tlv-01.txt From internet-drafts@ietf.org Sun Oct 30 19:40:11 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9043821F8B1C; Sun, 30 Oct 2011 19:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+jHW-x29UWa; Sun, 30 Oct 2011 19:40:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2627721F8B15; Sun, 30 Oct 2011 19:40:11 -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: 3.62 Message-ID: <20111031024011.27189.85842.idtracker@ietfa.amsl.com> Date: Sun, 30 Oct 2011 19:40:11 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-return-path-specified-lsp-ping-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 02:40:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Return Path Specified LSP Ping Author(s) : Mach(Guoyi) Chen Wei Cao So Ning Frederic Jounay Simon Delord Filename : draft-ietf-mpls-return-path-specified-lsp-ping-04.txt Pages : 18 Date : 2011-10-30 This document defines extensions to the failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP Ping" that allow selection of the LSP to use for= the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness. It may also be used by Bidirectional Forwarding Detection (BFD) for MPLS bootstrap signaling thereby making BFD for MPLS more robust. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-return-path-specified-l= sp-ping-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-return-path-specified-ls= p-ping-04.txt From Rolf.Winter@neclab.eu Mon Oct 31 03:13:46 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7BC21F8CF7 for ; Mon, 31 Oct 2011 03:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 0Pea+th6v7Rv for ; Mon, 31 Oct 2011 03:13:45 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id AAE1821F8CDD for ; Mon, 31 Oct 2011 03:13:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 5EA85280000F8 for ; Mon, 31 Oct 2011 11:14:20 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4et-g7Y5A5Fy for ; Mon, 31 Oct 2011 11:14:20 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 4357628000083 for ; Mon, 31 Oct 2011 11:14:15 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.17]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 31 Oct 2011 11:13:40 +0100 From: Rolf Winter To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-farrel-mpls-tp-mip-mep-map-05.txt Thread-Index: AQHMl7Pm9p+lmAi+9EelPoDcKoEiapWWOzPg Date: Mon, 31 Oct 2011 10:13:39 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D24F5263E@PALLENE.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.202] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [mpls] New Version Notification for draft-farrel-mpls-tp-mip-mep-map-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 10:13:46 -0000 SGksDQoNCndlIGp1c3Qgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2Ygb3VyIGRyYWZ0IHRpdGxl ZCAiSGFuZGxpbmcgTVBMUy1UUCBPQU0gUGFja2V0cyBUYXJnZXRlZCBhdCBJbnRlcm5hbCBNSVBz Ii4gTm93IHRoYXQgYWxsIGJhc2Ugc3BlY3MgYXJlIGRvbmUsIEkgdGhpbmsgdGhlIFdHIHNob3Vs ZCBzdGFydCB3b3JraW5nIG9uIGludGVybmFsIE1JUCBhZGRyZXNzaW5nIGFzIHNwZWNpZmllZCBp biB0aGUgT0FNIEZyYW1ld29yayBkb2N1bWVudC4gV2UgbmFycm93ZWQgdGhlIG9wdGlvbnMgd2Ug aGFkIGluIHRoZSBkb2N1bWVudCBiZWZvcmUgZG93biB0byBhIHNpbmdsZSBvbmUuIFNvIHdlIGJl bGlldmUgdGhpcyBpcyBub3cgYSBnb29kIGJhc2lzIGZvciB0aGUgV0cgdG8gc3RhcnQgd29yayBv bi4gQ29tbWVudHMsIGFzIGFsd2F5cywgaGlnaGx5IGFwcHJlY2lhdGVkLg0KDQpCZXN0LA0KDQpS b2xmDQoNCg0KTkVDIEV1cm9wZSBMaW1pdGVkIHwgUmVnaXN0ZXJlZCBPZmZpY2U6IE5FQyBIb3Vz ZSwgMSBWaWN0b3JpYSBSb2FkLCBMb25kb24gVzMgNkJMIHwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5k IDI4MzIwMTQgDQoNCg0K From internet-drafts@ietf.org Mon Oct 31 03:31:46 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA2821F8D0D; Mon, 31 Oct 2011 03:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 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 Nb+XxoxQ9q2v; Mon, 31 Oct 2011 03:31:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E210621F8C48; Mon, 31 Oct 2011 03:31:45 -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: 3.62 Message-ID: <20111031103145.14696.1394.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 03:31:45 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-itu-t-identifiers-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 10:31:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : MPLS-TP Identifiers Following ITU-T Conventions Author(s) : Rolf Winter Eric Gray Huub van Helvoort Malcolm Betts Filename : draft-ietf-mpls-tp-itu-t-identifiers-02.txt Pages : 7 Date : 2011-10-31 This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and OAM functions to include identifier information in a format typically used by the ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-itu-t-identifiers-02= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-itu-t-identifiers-02.= txt From yaacov.weingarten@nsn.com Mon Oct 31 05:47:30 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B5521F8DC5 for ; Mon, 31 Oct 2011 05:47:30 -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 ZomcUhHEGj4T for ; Mon, 31 Oct 2011 05:47:30 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 138E321F8CC2 for ; Mon, 31 Oct 2011 05:47:29 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9VClSAv011001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Oct 2011 13:47:28 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9VClM8D023040; Mon, 31 Oct 2011 13:47:27 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 13:47:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Oct 2011 13:47:24 +0100 Message-ID: In-Reply-To: <20111031103145.14696.1394.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question for clarification on draft-ietf-mpls-tp-itu-t-identifiers-02.txt Thread-Index: AcyXuFHkn22+RPiSQFqBcT3/lmomSAAEeHtQ References: <20111031103145.14696.1394.idtracker@ietfa.amsl.com> From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: X-OriginalArrivalTime: 31 Oct 2011 12:47:26.0295 (UTC) FILETIME=[3E1A0670:01CC97CB] Cc: draft-ietf-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: [mpls] Question for clarification on draft-ietf-mpls-tp-itu-t-identifiers-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 12:47:30 -0000 Hi Question for my clarification about the MEG-ID format: =20 When defining the MEG-ID the draft states - "followed by a Unique MEG ID Code (UMC) as defined in [Y.1731_cor1]"=20 The Corrigendum does not specify what the character set that is used for the UMC is. Could you please clarify what is the character set that is used for the UMC? Assuming a ICC of 6 characters - what is the maximum number of MEG-IDs supported by this format (dependent upon the character set)? Thank you, yaacov -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext internet-drafts@ietf.org Sent: Monday, October 31, 2011 12:32 PM To: i-d-announce@ietf.org Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-itu-t-identifiers-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS-TP Identifiers Following ITU-T Conventions Author(s) : Rolf Winter Eric Gray Huub van Helvoort Malcolm Betts Filename : draft-ietf-mpls-tp-itu-t-identifiers-02.txt Pages : 7 Date : 2011-10-31 This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and OAM functions to include identifier information in a format typically used by the ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-itu-t-identifiers -02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-itu-t-identifiers- 02.txt _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From huubatwork@gmail.com Mon Oct 31 06:59:45 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D3B21F8AB9 for ; Mon, 31 Oct 2011 06:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, 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 O-QItyV5OiI3 for ; Mon, 31 Oct 2011 06:59:45 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B1D9321F858C for ; Mon, 31 Oct 2011 06:59:44 -0700 (PDT) Received: by eyg24 with SMTP id 24so5621315eyg.31 for ; Mon, 31 Oct 2011 06:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=9SWJHV1Lsnu1D99TOtHR7H5ppi2OpFJa+mMB9pRlcAQ=; b=MKO+Wygfir+vQFqXSFWkp48HJrMTUJ9xAJFyCJHE9+wRof3J1SI2LDVF8zG/MadY6d 4nQXKumxtNgryO3csrMOmQwAHHX5F9v3JLJ8iuHOSQOT/sc7MJRLMuqE52u84cI1gd1j iPcpSdG9+06oJ8opwAe6Mb3y6ww+bchgyw/Xc= Received: by 10.213.13.220 with SMTP id d28mr768654eba.14.1320069583900; Mon, 31 Oct 2011 06:59:43 -0700 (PDT) Received: from McAsterix.local (dhcp-077-250-051-060.chello.nl. [77.250.51.60]) by mx.google.com with ESMTPS id a49sm51355372eea.2.2011.10.31.06.59.40 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 31 Oct 2011 06:59:40 -0700 (PDT) Message-ID: <4EAEA9CB.8060809@gmail.com> Date: Mon, 31 Oct 2011 14:59:39 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: mpls@ietf.org References: <20111031103145.14696.1394.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: Re: [mpls] Question for clarification on draft-ietf-mpls-tp-itu-t-identifiers-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 13:59:45 -0000 Yaacov, hi You wondered: > Question for my clarification about the MEG-ID format: > > When defining the MEG-ID the draft states - "followed by a > Unique MEG ID Code (UMC) as defined in [Y.1731_cor1]" > > The Corrigendum does not specify what the character set that > is used for the UMC is. Could you please clarify what is the > character set that is used for the UMC? The Corrigendum contains the following text: "A.2 Global MEG ID format based on CC and ICC Figure A-4 shows the format that uses the ITU Carrier Code (ICC) with Country Code (CC). The MEG ID Value is identified by Type 33 and consists of 15 characters coded according to [ITU T.50]." and: "The UMC code immediately follows the ICC and shall consist of 7-12 characters, with trailing NULLs, completing the 15-character MEG ID Value." So the UMC is part of the MEG ID which consists of 15 T.50 coded characters. T.50 describes a set of 128 characters (i.e. 7 bits per character) > Assuming a ICC of 6 characters - what is the maximum number of > MEG-IDs supported by this format (dependent upon the character > set)? In figure A-5 of the corrigendum you have seen that in case of a 6 character ICC the UMC consists of up to 7 characters. The maximum number is then 7 characters of 7 bits = 2^49 MEG-IDs per service provider. > Thank you, You're welcome, Huub. From hongk@cisco.com Mon Oct 31 07:50:40 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B688821F8C4C for ; Mon, 31 Oct 2011 07:50:39 -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 iVrOW80oQMyK for ; Mon, 31 Oct 2011 07:50:38 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BB78E21F8C48 for ; Mon, 31 Oct 2011 07:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hongk@cisco.com; l=2135; q=dns/txt; s=iport; t=1320072638; x=1321282238; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=j7srWiVuJbsV+MkKVgov2rVRJHMunymC8dJFHxCju9U=; b=gDfMwKwenW8wDf+4EgJRnzBkHyUR0Po67Vnyz7hzZT/kgw+Xy5TXbH6F l1ilgcGtrW7JHroPik2Bi0Q5HoJeXiKmmLa99aCAMvm9amDhEMThWYHcP 4fXQ1oCHrxiPW99ilYvCVyS4Bd37+ZJ2ICl24KYv5EG8gxC/WLJFCM14u 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMAANK0rk6tJV2c/2dsb2JhbABDmV2PU4EFgXIBAQEBAgEBAQEPAR0KLQcLBQcEAgEIEQQBAQsGFwEGASYfCQgBAQQBEggah2AIlUMBjjSPWgSIIWEEiAaRPoxH X-IronPort-AV: E=Sophos;i="4.69,432,1315180800"; d="scan'208";a="32210478" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 31 Oct 2011 14:50:38 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p9VEocft024109; Mon, 31 Oct 2011 14:50:38 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 09:50:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Oct 2011 09:50:37 -0500 Message-ID: <515703B08A3A064C9CC8C09ACCC710DC0545F4F7@XMB-RCD-103.cisco.com> In-Reply-To: <4EAEA9CB.8060809@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Question for clarification ondraft-ietf-mpls-tp-itu-t-identifiers-02.txt Thread-Index: AcyX1VzPPghajP1VSiSydzTHzco5dAABOCGw References: <20111031103145.14696.1394.idtracker@ietfa.amsl.com> <4EAEA9CB.8060809@gmail.com> From: "Kyung-Yeop Hong (hongk)" To: , X-OriginalArrivalTime: 31 Oct 2011 14:50:38.0178 (UTC) FILETIME=[7401DC20:01CC97DC] Cc: draft-ietf-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: Re: [mpls] Question for clarification ondraft-ietf-mpls-tp-itu-t-identifiers-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 14:50:40 -0000 >The maximum number is then 7 characters of 7 bits =3D 2^49 MEG-IDs per service provider. Y.1731 is using either an alphabetic (A-Z) or numeric (0-9) for MEG IDs as per M.1400, and thus you have 36 states per character.=20 So the maximum number is 36^7, not 2^49. KY -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Huub van Helvoort Sent: Monday, October 31, 2011 10:00 AM To: mpls@ietf.org Cc: draft-ietf-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: Re: [mpls] Question for clarification ondraft-ietf-mpls-tp-itu-t-identifiers-02.txt Yaacov, hi You wondered: > Question for my clarification about the MEG-ID format: > > When defining the MEG-ID the draft states - "followed by a > Unique MEG ID Code (UMC) as defined in [Y.1731_cor1]" > > The Corrigendum does not specify what the character set that > is used for the UMC is. Could you please clarify what is the > character set that is used for the UMC? The Corrigendum contains the following text: "A.2 Global MEG ID format based on CC and ICC Figure A-4 shows the format that uses the ITU Carrier Code (ICC) with Country Code (CC). The MEG ID Value is identified by Type 33 and consists of 15 characters coded according to [ITU T.50]." and: "The UMC code immediately follows the ICC and shall consist of 7-12 characters, with trailing NULLs, completing the 15-character MEG ID Value." So the UMC is part of the MEG ID which consists of 15 T.50 coded characters. T.50 describes a set of 128 characters (i.e. 7 bits per character) > Assuming a ICC of 6 characters - what is the maximum number of > MEG-IDs supported by this format (dependent upon the character > set)? In figure A-5 of the corrigendum you have seen that in case of a 6 character ICC the UMC consists of up to 7 characters. The maximum number is then 7 characters of 7 bits =3D 2^49 MEG-IDs per service provider. > Thank you, You're welcome, Huub. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From huubatwork@gmail.com Mon Oct 31 08:28:18 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B110311E80AE for ; Mon, 31 Oct 2011 08:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, 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 Cc3I00aPfVf3 for ; Mon, 31 Oct 2011 08:28:18 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4165611E80A5 for ; Mon, 31 Oct 2011 08:28:17 -0700 (PDT) Received: by eyg24 with SMTP id 24so5717545eyg.31 for ; Mon, 31 Oct 2011 08:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=xzPPFnrHdNPnotL4xuz70Zn8v9s9WttQ9BM1w5Z9glU=; b=pHMqzO2SMkESCweGYeZPDAMegJt3b7UwEeyJl0R5D9aY9rFZXweL3BKhQ4ui4YGhys Xu0TZxTOkXN0dt2B3DOZDEmNWKiwJf7NHfIc7apOfWAuzdJ7njragh9X8fwLWzDu3b7b g4Dj5PLESgvors2hb7KUmSXA0GEEE5minOj8k= Received: by 10.14.15.80 with SMTP id e56mr1304230eee.3.1320074896104; Mon, 31 Oct 2011 08:28:16 -0700 (PDT) Received: from McAsterix.local (dhcp-077-250-051-060.chello.nl. [77.250.51.60]) by mx.google.com with ESMTPS id d6sm23633266eec.10.2011.10.31.08.28.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 31 Oct 2011 08:28:15 -0700 (PDT) Message-ID: <4EAEBE8D.4030903@gmail.com> Date: Mon, 31 Oct 2011 16:28:13 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: mpls@ietf.org References: <20111031103145.14696.1394.idtracker@ietfa.amsl.com> <4EAEA9CB.8060809@gmail.com> <515703B08A3A064C9CC8C09ACCC710DC0545F4F7@XMB-RCD-103.cisco.com> In-Reply-To: <515703B08A3A064C9CC8C09ACCC710DC0545F4F7@XMB-RCD-103.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mpls-tp-itu-t-identifiers@tools.ietf.org Subject: Re: [mpls] Question for clarification ondraft-ietf-mpls-tp-itu-t-identifiers-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 15:28:18 -0000 Hello KY, You wrote: >> The maximum number is then 7 characters of 7 bits = 2^49 MEG-IDs >> per service provider. > > Y.1731 is using either an alphabetic (A-Z) or numeric (0-9) for MEG IDs > as per M.1400, and thus you have 36 states per character. > So the maximum number is 36^7, not 2^49. The alphabetic/numeric is for CC and ICC. Y.1731 states: "The UMC shall be a matter for the organization to which the ICC has been assigned, provided that uniqueness is guaranteed" Even in case the SP follows M.1400 36^7 is still a large number. A single SP can assign 11 MEG_IDs to every human living on our planet. https://www.census.gov/population/popclockworld.html Best reagrds, Huub. > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Huub van Helvoort > Sent: Monday, October 31, 2011 10:00 AM > To: mpls@ietf.org > Cc: draft-ietf-mpls-tp-itu-t-identifiers@tools.ietf.org > Subject: Re: [mpls] Question for clarification > ondraft-ietf-mpls-tp-itu-t-identifiers-02.txt > > Yaacov, hi > > You wondered: > >> Question for my clarification about the MEG-ID format: >> >> When defining the MEG-ID the draft states - "followed by a > > Unique MEG ID Code (UMC) as defined in [Y.1731_cor1]" >> >> The Corrigendum does not specify what the character set that > > is used for the UMC is. Could you please clarify what is the > > character set that is used for the UMC? > > The Corrigendum contains the following text: > > "A.2 Global MEG ID format based on CC and ICC > Figure A-4 shows the format that uses the ITU Carrier Code (ICC) > with Country Code (CC). The MEG ID Value is identified by Type 33 > and consists of 15 characters coded according to [ITU T.50]." > > and: > > "The UMC code immediately follows the ICC and shall consist of > 7-12 characters, with trailing NULLs, completing the 15-character > MEG ID Value." > > So the UMC is part of the MEG ID which consists of 15 T.50 coded > characters. > T.50 describes a set of 128 characters (i.e. 7 bits per character) > >> Assuming a ICC of 6 characters - what is the maximum number of > > MEG-IDs supported by this format (dependent upon the character > > set)? > > In figure A-5 of the corrigendum you have seen that in case of a > 6 character ICC the UMC consists of up to 7 characters. > The maximum number is then 7 characters of 7 bits = 2^49 MEG-IDs > per service provider. > >> Thank you, > > You're welcome, Huub. From internet-drafts@ietf.org Mon Oct 31 08:43:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C593B1F0C4B; Mon, 31 Oct 2011 08:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 HqCZqOfUDls7; Mon, 31 Oct 2011 08:43:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DD821F8E14; Mon, 31 Oct 2011 08:43:04 -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: 3.62 Message-ID: <20111031154304.27550.48205.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 08:43:04 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 15:43:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Configuration of Pro-Active Operations, Administration, = and Maintenance (OAM) Functions for MPLS-based Transport Networks using LSP= Ping Author(s) : Elisa Bellagamba Loa Andersson Pontus Skoldstrom Dave Ward John Drake Filename : draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-03.txt Pages : 21 Date : 2011-10-31 This specification describes the configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a set of TLVs that are carried by the LSP Ping protocol This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-mpls-tp-oam-co= nf-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-mpls-tp-oam-con= f-03.txt From stbryant@cisco.com Mon Oct 31 09:33:01 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F351F0C82 for ; Mon, 31 Oct 2011 09:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.642 X-Spam-Level: X-Spam-Status: No, score=-109.642 tagged_above=-999 required=5 tests=[AWL=0.957, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ggo+P3Y0cH5c for ; Mon, 31 Oct 2011 09:33:01 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id C85A41F0C44 for ; Mon, 31 Oct 2011 09:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2727; q=dns/txt; s=iport; t=1320078781; x=1321288381; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=dCInsbk6/d969+p33WOB/3KLxN7nbDe8LzTZ68K5HKU=; b=C1UHvaclYkQc0fL4ulylDkPYHHqvrszz+K8TY9Bzbzk2oOvHD8eGtbd0 yc8Ez9qyix89601lbOdoMjDR/Hb6r7XLCP32irif/1Mua/mP5TEieoedx JC7t/UBizDhmpmxH9tEGBIM/uoOOS4+3Mp5wBTp0z2E5xBKnpFnT+WPcN 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMBAHfNrk6Q/khR/2dsb2JhbABCmWNDjw+BBYFyAQEBAQMSAQIBIi8eBAsRBAEBAQkeBw8CNQkIEwYCAQEeh2iVVAGDKg8BinqPaQSJAgSUDpFf X-IronPort-AV: E=Sophos;i="4.69,432,1315180800"; d="scan'208";a="58898453" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 31 Oct 2011 16:32:59 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9VGWxRd008925 for ; Mon, 31 Oct 2011 16:32:59 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p9VGWsch007995; Mon, 31 Oct 2011 16:32:55 GMT Message-ID: <4EAECDB6.70109@cisco.com> Date: Mon, 31 Oct 2011 16:32:54 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mpls@ietf.org References: <20111031103145.14696.1394.idtracker@ietfa.amsl.com> <4EAEA9CB.8060809@gmail.com> <515703B08A3A064C9CC8C09ACCC710DC0545F4F7@XMB-RCD-103.cisco.com> <4EAEBE8D.4030903@gmail.com> In-Reply-To: <4EAEBE8D.4030903@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] Question for clarification ondraft-ietf-mpls-tp-itu-t-identifiers-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 16:33:02 -0000 On 31/10/2011 15:28, Huub van Helvoort wrote: > Hello KY, > > You wrote: > >>> The maximum number is then 7 characters of 7 bits = 2^49 MEG-IDs >>> per service provider. >> >> Y.1731 is using either an alphabetic (A-Z) or numeric (0-9) for MEG IDs >> as per M.1400, and thus you have 36 states per character. >> So the maximum number is 36^7, not 2^49. > > The alphabetic/numeric is for CC and ICC. > Y.1731 states: "The UMC shall be a matter for the organization to > which the ICC has been assigned, provided that uniqueness is guaranteed" > > Even in case the SP follows M.1400 36^7 is still a large number. > A single SP can assign 11 MEG_IDs to every human living on our planet. > > https://www.census.gov/population/popclockworld.html > > Best reagrds, Huub. > > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Huub van Helvoort >> Sent: Monday, October 31, 2011 10:00 AM >> To: mpls@ietf.org >> Cc: draft-ietf-mpls-tp-itu-t-identifiers@tools.ietf.org >> Subject: Re: [mpls] Question for clarification >> ondraft-ietf-mpls-tp-itu-t-identifiers-02.txt >> >> Yaacov, hi >> >> You wondered: >> >>> Question for my clarification about the MEG-ID format: >>> >>> When defining the MEG-ID the draft states - "followed by a >> > Unique MEG ID Code (UMC) as defined in [Y.1731_cor1]" >>> >>> The Corrigendum does not specify what the character set that >> > is used for the UMC is. Could you please clarify what is the >> > character set that is used for the UMC? >> >> The Corrigendum contains the following text: >> >> "A.2 Global MEG ID format based on CC and ICC >> Figure A-4 shows the format that uses the ITU Carrier Code (ICC) >> with Country Code (CC). The MEG ID Value is identified by Type 33 >> and consists of 15 characters coded according to [ITU T.50]." >> >> and: >> >> "The UMC code immediately follows the ICC and shall consist of >> 7-12 characters, with trailing NULLs, completing the 15-character >> MEG ID Value." >> >> So the UMC is part of the MEG ID which consists of 15 T.50 coded >> characters. >> T.50 describes a set of 128 characters (i.e. 7 bits per character) >> >>> Assuming a ICC of 6 characters - what is the maximum number of >> > MEG-IDs supported by this format (dependent upon the character >> > set)? >> >> In figure A-5 of the corrigendum you have seen that in case of a >> 6 character ICC the UMC consists of up to 7 characters. >> The maximum number is then 7 characters of 7 bits = 2^49 MEG-IDs >> per service provider. Yes, but the Ethernet people will tell you that a lot a grains of sand will be feeling cut off from the net ;) Stewart From internet-drafts@ietf.org Mon Oct 31 11:13:00 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC2421F8E09; Mon, 31 Oct 2011 11:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 6KuiobtvolKt; Mon, 31 Oct 2011 11:13:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9ED21F8E04; Mon, 31 Oct 2011 11:12:59 -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: 3.62 Message-ID: <20111031181259.21133.43696.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 11:12:59 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-security-framework-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 18:13:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : MPLS-TP Security Framework Author(s) : Luyuan Fang Ben Niven-Jenkins Scott Mansfield Richard F. Graveman Filename : draft-ietf-mpls-tp-security-framework-02.txt Pages : 25 Date : 2011-10-31 This document provides a security framework for Multiprotocol Label Switching Transport Profile (MPLS-TP). Extended from MPLS technologies, MPLS-TP introduces new OAM capabilities, a transport- oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects that are relevant in the context of MPLS-TP specifically. It describes the security requirements for MPLS-TP and potential security threats and mitigation procedures for MPLS-TP networks and MPLS-TP inter-connection to MPLS and GMPLS networks. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF Consensus.] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-security-framework-0= 2.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-security-framework-02= .txt From internet-drafts@ietf.org Mon Oct 31 15:27:20 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2748411E831B; Mon, 31 Oct 2011 15:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 0SgmD+jG7+-G; Mon, 31 Oct 2011 15:27:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7474011E830E; Mon, 31 Oct 2011 15:27:19 -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: 3.62 Message-ID: <20111031222719.5634.42105.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 15:27:19 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-entropy-label-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 22:27:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : The Use of Entropy Labels in MPLS Forwarding Author(s) : Kireeti Kompella John Drake Shane Amante Wim Henderickx Lucy Yong Filename : draft-ietf-mpls-entropy-label-01.txt Pages : 25 Date : 2011-10-31 Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defin= es the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-entropy-label-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-entropy-label-01.txt From internet-drafts@ietf.org Mon Oct 31 16:38:17 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242F511E83A5; Mon, 31 Oct 2011 16:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 7nt2dyXyLqYw; Mon, 31 Oct 2011 16:38:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A379F11E839D; Mon, 31 Oct 2011 16:38:12 -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: 3.62 Message-ID: <20111031233812.1552.48606.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 16:38:12 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-multi-topology-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:38:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : LDP Extensions for Multi Topology Routing Author(s) : Quintin Zhao Luyuang Fang Chao Zhou Lianyuan Li Ning So Raveendra Torvi Filename : draft-ietf-mpls-ldp-multi-topology-01.txt Pages : 21 Date : 2011-10-31 Multi-Topology (MT) routing is supported in IP through extension of IGP protocols, such as OSPF and IS-IS. It would be advantageous to extend Multiprotocol Label Switching (MPLS), using Label Distribution Protocol (LDP), to support multiple topologies. These LDP extensions, known as Multiple Topology Label Distribution Protocol (MT LDP), would allow the configuration of multiple topologies within an MPLS LDP enabled network. This document describes the protocol extensions required to extend the existing MPLS LDP signalling protocol for creating and maintaining LSPs in an MT environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-multi-topology-01.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-ldp-multi-topology-01.txt From wwwrun@rfc-editor.org Mon Oct 31 21:56:18 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FC321F8C7E; Mon, 31 Oct 2011 21:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.5 X-Spam-Level: X-Spam-Status: No, score=-101.5 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lw7kkZwaRBRN; Mon, 31 Oct 2011 21:56:17 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id B4FB521F8C77; Mon, 31 Oct 2011 21:56:17 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5273162199; Mon, 31 Oct 2011 21:51:59 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111101045159.5273162199@rfc-editor.org> Date: Mon, 31 Oct 2011 21:51:59 -0700 (PDT) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6378 on MPLS Transport Profile (MPLS-TP) Linear Protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 04:56:18 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6378 Title: MPLS Transport Profile (MPLS-TP) Linear Protection Author: Y. Weingarten, Ed., S. Bryant, E. Osborne, N. Sprecher, A. Fulignoli, Ed. Status: Standards Track Stream: IETF Date: October 2011 Mailbox: yaacov.weingarten@nsn.com, stbryant@cisco.com, eosborne@cisco.com, nurit.sprecher@nsn.com, annamaria.fulignoli@ericsson.com Pages: 45 Characters: 99684 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-tp-linear-protection-09.txt URL: http://www.rfc-editor.org/rfc/rfc6378.txt This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document addresses the functionality described in the MPLS-TP Survivability Framework document (RFC 6372) and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection, as described in that document. [STANDARDS-TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC