From wwwrun@rfc-editor.org Thu Aug 1 09:49:52 2013 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 1A54A21F9FDA; Thu, 1 Aug 2013 09:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.268 X-Spam-Level: X-Spam-Status: No, score=-102.268 tagged_above=-999 required=5 tests=[AWL=0.332, 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 B10nWgVsNYpr; Thu, 1 Aug 2013 09:49:49 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id BD96A21F9D1E; Thu, 1 Aug 2013 09:49:26 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 90A6462176; Thu, 1 Aug 2013 09:45:53 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130801164553.90A6462176@rfc-editor.org> Date: Thu, 1 Aug 2013 09:45:53 -0700 (PDT) Cc: drafts-update-ref@iana.org, mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6965 on MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design 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, 01 Aug 2013 16:49:52 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6965 Title: MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design Author: L. Fang, Ed., N. Bitar, R. Zhang, M. Daikoku, P. Pan Status: Informational Stream: IETF Date: August 2013 Mailbox: lufang@cisco.com, nabil.bitar@verizon.com, raymond.zhang@alcatel-lucent.com, ms-daikoku@kddi.com, ppan@infinera.com Pages: 16 Characters: 36728 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-tp-use-cases-and-design-08.txt URL: http://www.rfc-editor.org/rfc/rfc6965.txt This document describes the applicability of the MPLS Transport Profile (MPLS-TP) with use case studies and network design considerations. The use cases include Metro Ethernet access and aggregation transport, mobile backhaul, and packet optical transport. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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/search/rfc_search.php 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 From saalvare@cisco.com Fri Aug 2 01:43:00 2013 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 F054811E82B3 for ; Fri, 2 Aug 2013 01:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eF0Jnnjlkno for ; Fri, 2 Aug 2013 01:42:54 -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 0649321F8756 for ; Fri, 2 Aug 2013 01:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=578; q=dns/txt; s=iport; t=1375432686; x=1376642286; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=IFPA83+yfBbO9iHGFxfPKAFM7XNfX+HxAGn5TXNnlQ8=; b=Yn1Kuhy1jXRQbVAQkE6fbyY9jsMxxrOX+b8lV0RrfaCwd28ykjVPqFFu yEFd5N6/3mZaDxMiZ0QSBjcvni0rmt/CHlEMn/uPOjNfkE2VC5OLtppYP bxRkBbqpqQfAQs9kt7RxsRWRTbuedjZ3SEJnh6l08MPphzsDeV+uik30/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAMhu+1GtJV2Y/2dsb2JhbABbgwaBBb5NgRsWdIImAQEDOj8SASoUQiYBBA4NiAi5GY9WMYMgcwOpLYMXgio X-IronPort-AV: E=Sophos;i="4.89,799,1367971200"; d="scan'208";a="242643350" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 02 Aug 2013 08:38:02 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r728c2hm020086 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 2 Aug 2013 08:38:02 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.8]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Fri, 2 Aug 2013 03:38:02 -0500 From: "Santiago Alvarez (saalvare)" To: "mpls@ietf.org" Thread-Topic: LDP Color LSP - downstream unsolicited and on-demand Thread-Index: Ac6PWyqry9DwoxlGSgaq5SIsAqUn8w== Date: Fri, 2 Aug 2013 08:38:01 +0000 Message-ID: <0C8935EE66D53445A3D3982BD9BE54681DFADE56@xmb-aln-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.118.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Santiago Alvarez \(saalvare\)" Subject: [mpls] LDP Color LSP - downstream unsolicited and on-demand 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, 02 Aug 2013 08:43:00 -0000 If I understood the question correctly, Ina asked why draft-alvarez-mpls-ld= p-color-lsp-00 was only considering downstream unsolicited label allocation= . As mentioned on the mic, draft focuses on downstream label allocation, b= oth unsolicited and on-demand. Here's a snippet from the current doc: " An egress LSR MAY include the Color List TLV in a Label Mapping Message if using Downstream Unsolicited mode. An LSR may include the TLV in Label Request Messages if using Downstream on Demand mode. " Any further feedback appreciated. Thanks. SA -- From stbryant@cisco.com Fri Aug 2 02:07:23 2013 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 8B50F11E833F; Fri, 2 Aug 2013 02:07:22 -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 sWU1kD89p-JK; Fri, 2 Aug 2013 02:07: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 8466511E82ED; Fri, 2 Aug 2013 02:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=58039; q=dns/txt; s=iport; t=1375434119; x=1376643719; h=message-id:date:from:reply-to:mime-version:to:cc:subject: content-transfer-encoding; bh=6RKliOZig2Q4B/WoFXscPAj7WgBtMisPEzxRgz0CBl0=; b=A8vL9iV16t5mXlY9rHbrlAeCMxJVAH45yCmgbM/tw/FalwkL428OdnXG ya+julkhqTucosppplQWTvcQZMDIxrf4h56ZImrJA4j+ly/0/ccFKSt/v UbvCdlOEG/OxCRxT1isnCNFF6tbGmH+95KItIzKMzMChNiFi9FI+6PlpA Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEFAKd0+1GQ/khM/2dsb2JhbABRCoMGATS/HYEbFnSCRQEdLgESLQ8MKAI4FAEJAwEFAgEBF4d1DJ8/mT6ONAIJBgWBGyIRhAIDiy6BEocHQYNXgSqFbIo4gxiBaAgX X-IronPort-AV: E=Sophos;i="4.89,800,1367971200"; d="scan'208";a="85379318" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 02 Aug 2013 09:00:54 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7290p3w026368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Aug 2013 09:00:52 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r7290oBR001361; Fri, 2 Aug 2013 10:00:50 +0100 (BST) Message-ID: <51FB7543.801@cisco.com> Date: Fri, 02 Aug 2013 10:00:51 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mpls-chairs@tools.ietf.org" , "tictoc-chairs@tools.ietf.org" , int-ads@tools.ietf.org, "rtg-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-tictoc-1588overmpls@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: [mpls] Comments on draft-ietf-tictoc-1588overmpls 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: Fri, 02 Aug 2013 09:07:36 -0000 SB> This draft does not seem to provide a precise definition SB> the properties of the new LSP type that it wishes to SB> define, in particular it does it define the PHB of those SB> LSPs, nor the full interaction with the MPLS SB> architecture. SB> SB> I have not tracked TICTOC for a while but I thought that SB> the original plan was to define the concept of an offset SB> into a packet to do the correction. SB> SB> It is disappointing that the opportunity was not taken SB> to define a timing shim inside the timing LSP so that SB> a time correction could be added to any packet such that SB> the MPLS system was isolated from the details of the SB> complexity of the particular time transfer type. SB> I think that much more clarify is needed in terms of SB> definition of the new LSP type, since it is unclear SB> from this text how to implement one. SB> SB> There are a lot of other MPLS services such as SB> LSP ping that need to be considered. SB> SB> Please see inline for more comments. However these SB> comments are made in the context of the text as written SB> whilst I have a fundamental concern that this approach SB> lacks an MPLS architectural soundness that need SB> greater thought with significant impact on the SB> draft. - Stewart TICTOC Working Group S. Davari Internet-Draft A. Oren Intended status: Standards Track Broadcom Corp. Expires: December 17, 2013 M. Bhatia P. Roberts Alcatel-Lucent L. Montini L. Martini Cisco Systems June 15, 2013 Transporting Timing messages over MPLS Networks draft-ietf-tictoc-1588overmpls-05 Abstract This document defines the method for transporting Timing messages such as PTP and NTP over an MPLS network. The method allows for the easy identification of these PDUs at the port level to allow for port SB> What is a port level processing of these PDUs in both LERs and LSRs. The basic idea is to transport Timing messages inside dedicated MPLS LSPs. These LSPs only carry Timing messages and possibly Control and Management packets, but they do not carry customer traffic. SB> More specifically they only carry traffic associated with the SB> timing service and its support. SB> The question arose WRT BFD - surely BFD is allowed, BUT surely SB> also it gets carried in a structure that causes it to get SB> timestamped. Two methods for transporting Timing messages over MPLS are defined. SB> Perhaps the right approach is to define the new LSP type and then SB> seperately to define the mapping of the various timing services SB> over that LSP type. The first method is to transport Timing messages directly over the dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for MPLS networks. The second method is to transport Timing messages inside a PW via Ethernet encapsulation. SB> I think that we should note that there are some SB> h/w reasons for this preference. A clean sheet approach SB> would have been to use PTP over MPLS with no intermediate SB> layers. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 17, 2013. Davari, et al. Expires December 17, 2013 [Page 1] Internet-Draft Transporting Timing over MPLS June 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . 9 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . . 12 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . 13 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . . 13 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . . 13 6.3. Other Timing Encapsulation methods . . . . . . . . . . . . 14 7. Timing message Processing . . . . . . . . . . . . . . . . . . 15 8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 16 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. OAM, Control and Management . . . . . . . . . . . . . . . . . 20 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 21 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . . 22 Davari, et al. Expires December 17, 2013 [Page 2] Internet-Draft Transporting Timing over MPLS June 2013 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 23 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . . 23 15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . . 23 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . . 24 16. Other considerations . . . . . . . . . . . . . . . . . . . . . 25 17. Security Considerations . . . . . . . . . . . . . . . . . . . 26 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 20.1. Normative References . . . . . . . . . . . . . . . . . . . 29 20.2. Informative References . . . . . . . . . . . . . . . . . . 29 Appendix 1. Routing extensions for Timing-aware Routers . . . . . 32 Appendix 2. Signaling Extensions for Creating Timing LSPs . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Davari, et al. Expires December 17, 2013 [Page 3] Internet-Draft Transporting Timing over MPLS June 2013 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. When used in lower case, these words convey their typical use in common language, and are not to be interpreted as described in RFC2119 [RFC2119]. Davari, et al. Expires December 17, 2013 [Page 4] Internet-Draft Transporting Timing over MPLS June 2013 1. Introduction The objective of Precision Time Protocol (PTP) and Network Timing Protocol (NTP) are to synchronize independent clocks running on separate nodes of a distributed system. [IEEE-1588] defines PTP messages for frequency, phase and time synchronization. The PTP messages include PTP PDUs over UDP/IP (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex F of [IEEE-1588]). SB> Sure BUT it is acknowledged that IEEE is open to the definition SB> of other PTP mappings if they provide better optimisation. This document defines mapping and transport of the PTP messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP defines several clock types: ordinary clocks, boundary clocks, end- to-end transparent clocks, and peer-to-peer transparent clocks. Transparent clocks require intermediate nodes to update correction field inside PTP message that reflects the transit time in the node. [RFC5905] defines NTP messages for clock and time synchronization. The PTP messages (PDUs) are transported over UDP/IP. This document SB> Should that be NTP messages? SB> It needs to be made clear as soon as you introduce NTP that SB> they use different time representations. defines mapping and transport of the NTP messages defined in [RFC5905] over MPLS networks. One key attribute of all of these Timing messages is that the Time stamp processing should occur as close as possible to the actual transmission and reception at the physical port interface. This targets optimal time and/or frequency recovery by avoiding variable delay introduced by queues internal to the clocks. SB> As I recall NTP has no epoch point defined, and I am not sure SB> where that point is in the case of PTP in this mapping SB> Hopefully this will get defined in due course. To facilitate the fast and efficient recognition of Timing messages at the port level when the Timing messages are carried over MPLS LSPs, SB> Over a new LSP type with time optimied characteristics this document defines the specific encapsulations that should be used. SB> Hopefully it will also define the PHP In addition, it can be expected that there will exist LSR/ LERs where only a subset of the physical ports will have the port- based Timing message processing capabilities. SB> Do you need to clarify that this only works at base and not in SB> a label heirarchy. In order to ensure that the LSPs carrying Timing packets always enter and exit ports with this capability, routing extensions are defined to advertise this capability on a port basis and to allow for the establishment of LSPs that only transit such ports. While this path establishment restriction may be applied only at the LER Ingress and/or egress ports, it becomes more important when using transparent clock capable LSRs in the path. SB> I do not understand the implications of the last SB> sentences - starting ", it becomes" Port based Timing message processing involves Timing message recognition. Once the Timing messages are recognized they can be modified based on the reception or transmission Time-stamp. This document provides two methods for transporting Timing messages over MPLS. One is applicable to MPLS environment and the other one is applicable to MPLS/MPLS-TP environment SB> I think the sentence is incomplete. Davari, et al. Expires December 17, 2013 [Page 5] Internet-Draft Transporting Timing over MPLS June 2013 The solution involves transporting Timing messages over dedicated LSPs called Timing LSPs. These LSPs carry Timing messages and MAY carry Management and control messages, but not data plane client traffic. SB> It is not clear why this restriction applies. Timing LSPs can be established statically or via signaling. SB> s/statically/by provisioning/network management/ Extensions to control plane (OSPF, ISIS, etc.) is required to enable routers to distribute their Timing processing capabilities over MPLS to other routers. However such extensions are outside the scope of this document. When signaling is used to setup the PTP LSP, Extensions to signaling SB> is it a PTP LSP or a Timing LSP? protocols (e.g., RSVP-TE) are required for establishing PTP LSPs. However such extensions are outside the scope of this document. SB> for mpls-tp GMPLS is the signalling protocol While the techniques included herein allow for the establishment of paths optimized to include Time-stamping capable links, the performance of the Slave clocks is outside the scope of this document. At the time of publishing this specification, Transparent Clocking (TC) is only defined for PTP. Therefore at this time any part of this specification that talks about Transparent Clocking applies only to PTP. Davari, et al. Expires December 17, 2013 [Page 6] Internet-Draft Transporting Timing over MPLS June 2013 2. Terminology 1588: The timing and synchronization as defined by IEEE 1588. SB> I think that there is a more formal name for the 1588 group SB> that needs to be used here. SB> Also do we need to talk about 1588-200? as there is SB> an update in progress NTP: The timing and synchronization protocol defined by IETF RFC-1305 and RFC-5905. PTP: The timing and synchronization protocol used by 1588. SB> need the proper name for 1588 Master Clock: The source of 1588 timing to a set of slave clocks. Master Port: A port on a ordinary or boundary clock that is in Master state. This is the source of timing toward slave ports. SB> I am not sure the reader knows what a port is Slave Clock: A receiver of 1588 timing from a master clock. Slave Port: A port on a boundary clock or ordinary clock that is receiving timing from a master clock. Ordinary Clock: A device with a single PTP port. Transparent Clock. A device that measures the time taken for a PTP event message to transit the device and then updates the correctionField of the message with this transit time. Boundary Clock: A device with more than one PTP port. Generally boundary clocks will have one port in slave state to receive timing and then other ports in master state to re-distribute the timing. PTP LSP: An LSP dedicated to carry PTP messages SB> PTP or timing? PTP PW: A PW within a PTP LSP that is dedicated to carry PTP messages. SB> Ah I don't think that PWE3 know what one of these is CW: Pseudowire Control Word LAG: Link Aggregation ECMP: Equal Cost Multipath CF: Correction Field, a field inside certain PTP messages (message type 0-3)that holds the accumulative transit time inside intermediate switches Timing messages: Timing Protocol messages that are exchanged between routers in order to establish a synchronized clock. SB> A number of these definitions look like copies of IEEE1588 SB> definitions. We need to provide references and note the SB> priority of the IEEE base reference. Davari, et al. Expires December 17, 2013 [Page 7] Internet-Draft Transporting Timing over MPLS June 2013 3. Problem Statement [IEEE-1588] has defined methods for transporting PTP messages over Ethernet and IP networks. [RFC5905] has defined the method of transporting NTP messages over IP networks. There is a need to transport Timing messages over MPLS networks while supporting the Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC) functionality in the LER and LSRs in the MPLS network. There are multiple ways of transporting Timing over MPLS. However, there is a requirement to limit the possible encapsulation options to simplify the Timing message identification and processing required at the port level. When Timing-awareness is needed, Timing messages should not be transported over LSPs or PWs that are carrying customer traffic because LSRs perform Label switching based on the top label in the stack. SB> Have you explained why? To detect Timing messages inside such LSPs require special hardware to do deep packet inspection at line rate. Even if such hardware exists, the payload can't be deterministically identified by LSRs because the payload type is a context of the PW label, and the PW label and its context are only known to the Edge routers (PEs/ LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, CES, etc). Even if one restricts an LSP to only carry Ethernet PWs, the LSRs dont have the knowledge of whether PW Control Word (CW) is present or not and therefore can not deterministically identify the payload. A generic method is defined in this document that does not require deep packet inspection at line rate, and can deterministically identify Timing messages. This method can be used to detect Timing Messages in both one-step and two-step clock implementations of ordinary, boundary and transparent clocks. SB> Needs a ref and I am sure many MPLS specialists will not understand SB> the msg types. Davari, et al. Expires December 17, 2013 [Page 8] Internet-Draft Transporting Timing over MPLS June 2013 4. Timing over MPLS Architecture Timing messages are exchange between Timing ports on ordinary and SB> Have you defined a timing port? boundary clocks. Boundary clocks terminate the Timing messages and act as master for other boundary clocks or for slave clocks. End-to- End Transparent clocks do not terminate the Timing messages but they do modify the contents of the Timing messages as they transit across the transparent clock. Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent Clock (TC) could be implemented in either LERs or LSRs. SB> LER and LSR need to be expanded An example is shown in Figure 1, where the LERs act as Ordinary Clock (OC) and are the initiating/terminating point for Timing messages. The ingress LER encapsulates the Timing messages in Timing LSP and the Egress LER terminates the Timing LSP. The LSRs act as Transparent Clock (TC) and just update the Timing field in the Timing messages. +--------+ +-------+ +-------+ +-------+ +--------+ |Switch, | | | | | | | |Switch, | | Router |-----| LER |-----| LSR |-----| LER |-----| Router | | | | OC | | TC | | OC | | | +--------+ +-------+ +-------+ +-------+ +--------+ / \ +-------+ / \ +-------+ | LER | / \ | LER | | Master|---/ \---| Slave | | Clock | | Clock | +-------+ +-------+ Figure (1) - Deployment example 1 of timing over MPLS network Another example is shown in Figure2, where LERs terminate the Timing messages received from switch/routers that are outside of the MPLS network acting as OC or BC. In this example LERs regenerate the clock and initiate timing messages encapsulated in Timing LSP toward the MPLS network, while the LSRs act as Transparent Clock (TC) and just update the Timing field in the Timing messages, which are already encapsulated in Timing LSPs. Davari, et al. Expires December 17, 2013 [Page 9] Internet-Draft Transporting Timing over MPLS June 2013 +--------+ +-------+ +-------+ +-------+ +--------+ |Switch, | | | | | | | |Switch, | | Router |-----| LER |-----| LSR |-----| LER |-----| Router | | OC/BC | | BC | | TC | | BC | | OC/BC | +--------+ +-------+ +-------+ +-------+ +--------+ Figure (2) - Deployment example 2 of timing over MPLS network Another example is shown in Figure 3, where LERs do not terminate the Timing messages received from switch/routers that are outside of the MPLS network acting as OC, TC or BC. The LERs act as TC and update the Timing field in the Timing messages as they transit the LER, while encapsulating them in timing LSP. The LSRs also act as Transparent Clock (TC) and just update the Timing field in the Timing messages which are already encapsulated in Timing LSPs. +--------+ +-------+ +-------+ +-------+ +--------+ |Switch, | | | | | | | |Switch, | | Router |-----| LER |-----| LSR |-----| LER |-----| Router | |OC/TC/BC| | TC | | TC | | TC | |OC/TC/BC| +--------+ +-------+ +-------+ +-------+ +--------+ Figure (3) - Deployment example 3 of timing over MPLS network Another example is shown in Figure 4, where LERs and LSRs support Boundary Clocks. A single-hop LSP is created between two adjacent LSRs engaged in BC operation. Other methods such as PTP transport over Ethernet MAY be used for transporting timing messages if the link between the two routers is Ethernet. +--------+ +-------+ +-------+ +-------+ +--------+ |Switch, | | | | | | | |Switch, | | Router |-----| LER |-----| LSR |-----| LER |-----| Router | | OC/BC | | BC | | BC | | BC | | OC/BC | +--------+ +-------+ +-------+ +-------+ +--------+ Figure (4) - Deployment example 3 of timing over MPLS network An MPLS domain MAY serve multiple customers. In these cases the MPLS domain (maintained by a service provider) may provide timing services to multiple customers, each having their own Timing domain. The Timing over MPLS architecture assumes full mesh of Timing LSPs between all LERs supporting this specification. SB> Note sure this is right - the salves surely do not need to SB> exchange timing amongst themselves It supports Point-to- point (VPWS) and Multipoint (VPLS) services. SB> What does that mean? You do not carry user data traffic? SB> Maybe it's the ordering of the statemnets that is causing SB> confusion. This means that a customer may purchase a Point-to-point Timing service between two customer sites or a Multipoint Timing service between more than Davari, et al. Expires December 17, 2013 [Page 10] Internet-Draft Transporting Timing over MPLS June 2013 two customer sites. The Timing over MPLS architecture supports P2P or P2MP Timing LSPs. This means that the Timing Multicast messages such as PTP Multicast event messages can be transported over P2MP Timing LSP or be replicated and transported over many P2P Timing LSPs. SB> Note we do not yet have a definition of a P2MP mpls-tp LSP SB> nor a P2MP PW, although we are close. Timing messages, that do not require Time stamping or Correction Field update MAY be transported over Timing LSPs to simplify hardware and software. PTP Announce messages that determine the Timing LSP terminating point behavior such as BC/OC/TC SHOULD be transported over the Timing LSP to simplify hardware and software. SB> have you defined and referenced PTP announce msgs? Davari, et al. Expires December 17, 2013 [Page 11] Internet-Draft Transporting Timing over MPLS June 2013 5. Dedicated LSPs for Timing messages Many methods have been considered for identifying the Timing messages when they are encapsulated in MPLS such as using GAL/G-ACH or a new reserved label. These methods were not attractive since they either required deep packet inspection at line rate in the intermediate LSRs or they required use of a scarce new reserved label. Also one of the goals was to reuse existing OAM mechanisms. SB> RLs = SPLs are not so rare now. In any case needs a ref. The method defined in this document can be used by LER and LSRs to identify Timing messages in MPLS tunnels by just looking at the top label in the MPLS label stack, which only carry Timing messages as well as OAM, but not data plane client traffic. Compliant implementations MUST use dedicated LSPs to carry Timing messages over MPLS. SB> I think that we need a definition of the properies of these LSPs These LSPs are herein referred to as "Timing LSPs" and the labels associated with these LSPs as "Timing LSP labels". The Timing LSPs that runs between Ingress and Egress LERs MUST be co-routed. Alternatively, a single bidirectional co-routed LSP can be used. SB> I though that you said you could use M2MP LSPs - these are not SB> bidirectional. Co-routing of the two directions is required to limit the difference in the delays in the Master clock to Slave clock direction compared to the Slave clock to Master clock direction. The Timing LSP MAY be MPLS/MPLS-TP LSP. The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS. New Extensions to RSVP-TE/GMPLS TLVs are required; however they are outside the scope of this document. The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such as BFD and LSP Ping but the LSP data plane client plane traffic MUST be Timing packets only. SB> Why? Davari, et al. Expires December 17, 2013 [Page 12] Internet-Draft Transporting Timing over MPLS June 2013 6. Timing over LSP Encapsulation The encapsulations is not LSP is it? This document defines two methods for carrying Timing messages over MPLS. The first method is carrying UDP/IP encapsulated Timing messages over Timing LSPs, and the second method, is carrying Ethernet encapsulated Timing messages over Ethernet PWs inside Timing LSPs. 6.1. Timing over UDP/IP over MPLS Encapsulation The simplest method of transporting Timing messages over MPLS is to encapsulate Timing PDUs in UDP/IP and then encapsulate them in Timing LSP. This format is shown in Figure 4. +----------------------+ | Timing LSP Label | +----------------------+ | IPv4/6 | +----------------------+ | UDP | +----------------------+ | Timing PDU | +----------------------+ Figure (4) - Timing over UDP/IP over MPLS Encapsulation This encapsulation is very simple and is useful when the network between Timing Master Clock and Slave Clock is MPLS network. SB> Simple is a judgement call In order for an LER/LSR to process Timing messages, the Timing LSP Label must be at the top label of the label stack. The LER/LSR MUST know that the Timing LSP Label is used for carrying Timing messages. This can be accomplished via static configuration or via RSVP-TE signaling. The UDP/IP encapsulation of PTP MUST follow Annex D and E of [IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow [RFC5905]. 6.2. Timing over PW Encapsulation Another method of transporting Timing over MPLS networks is by encapsulating Timing PDUs in PW which in turn is transported over Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448], shown in Fig 5(A) MUST be used and the Ethernet encapsulation of PTP MUST follow Annex F of [IEEE-1588]. Davari, et al. Expires December 17, 2013 [Page 13] Internet-Draft Transporting Timing over MPLS June 2013 The RAW mode or Tagged mode defined in [RFC4448] MAY be used and the Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The Timing over PW encapsulation MUST use the Control Word (CW) as specified in [RFC4448] to ensure proper detection of PTP messages inside the MPLS packets for Timing over LSP and Timing over PW encapsulation. SB> That needs explanation The use of Sequence Number in the CW is optional. SB> Given that s/n are never in practice deployed, you could probably SB> simplify things by sayig that they are not used. Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over PW (the IP PW discussed in [RFC4447]) shown in Fig 5(B). +----------------+ +----------------+ |Timing LSP Label| |Timing LSP Label| +----------------+ +----------------+ | PW Label | | PW Label | +----------------+ +----------------+ | Control Word | | IP | +----------------+ +----------------+ | Ethernet | | UDP | | Header | +----------------+ +----------------+ | Timing PDU | |S-VLAN(Optional)| | | +----------------+ +----------------+ |C-VLAN(Optional)| (B) +----------------+ | Timing PDU | | | +----------------+ (A) Figure (5) - Timing over PW Encapsulations In order for an LSR to process PTP messages, the top label of the label stack (the Tunnel Label) MUST be a Timing label. S> You said that before. 6.3. Other Timing Encapsulation methods In future other timing encapsulation methods may be introduced, such as a new shim header after the Bottom of Stack to carry the Timing information. Such new encapsulations are outside the scope of this document. SB> Taking a pure MPLS pov, you can simplify a lot of the text SB> out of the definition of the LSP Davari, et al. Expires December 17, 2013 [Page 14] Internet-Draft Transporting Timing over MPLS June 2013 SB> I think we need a section on LSP processing 7. Timing message Processing Each Timing protocol such as PTP and NTP, define their set of Timing messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, FOLLOW_UP, etc messages. Some of the Timing messages require time stamping or correction field update at port level and some dont. It is the job of the LER/LSR to parse the timing message and find out the type of the Timing message and decide whether and how to Time- stamp it (e.g., BC) or update correction field(e.g., TC). SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing SB> function rather than the LER? For example the following PTP messages (called Event messages) require time-stamping or correction field update: o SYNC o DELAY_REQ (Delay Request) o PDELAY_REQ (Peer Delay Request) o PDELAY_RESP (Peer Delay Response) SYNC and DELAY_REQ are exchanged between Master Clock and Slave Clock and MUST be transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP are exchanged between adjacent PTP clocks (i.e. Master, Slave, Boundary, or Transparent) and SHOULD be transported over single hop PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP, and PDELAY_RESP_FOLLOW_UP messages MUST also be transported over the PTP LSPs. For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be transported over two PTP LSPs that are in opposite directions. These PTP LSPs, which are in opposite directions MUST be congruent and co- routed. Alternatively, a single bidirectional co-routed LSP can be used. Except as indicated above for the two-step PTP clocks, Non-Event PTP message types do not need to be processed by intermediate routers. These message types MAY be carried in PTP Tunnel LSPs. SB> Are you saying that a timing P router has to be msg type sensitive? Davari, et al. Expires December 17, 2013 [Page 15] Internet-Draft Transporting Timing over MPLS June 2013 8. Protection and Redundancy SB> This is a bit of a jump - I don't know how the LSP itself works yet! In order to ensure continuous uninterrupted operation of slave clocks, usually as a general practice, slave clocks (or ports) track redundant master clocks. It is the responsibility of the network operator to ensure that physically disjoint Timing LSPs are established between a slave clock (or port) and redundant master clocks (or ports). When a slave clock (or port) listens to redundant master clocks or ports, any prolonged Timing LSP outage will trigger the slave clock or port to switch to a redundant master clock or port. LSP/PW protection such as Linear protection Switching (1:1, 1+1), Ring protection switching or MPLS Fast Reroute (FRR) generally switch alternative path that usually cause a change in delay, which if undetected by slave clock can reduce accuracy of the slave clock. Therefore protection switching MAY be used, as long as phase jumps upon switchover due to differences in path latency are detected and compensated for (such compensation not being required if BCs or peer- peer TCs are used throughout). Note that any protection or reroute mechanism that adds additional MPLS label to the label stack, such as Facility Backup Fast Reroute, MUST ensure that the pushed label is also a Timing Label to ensure recognition of the MPLS frame as containing Timing messages, as it transits the backup path. Davari, et al. Expires December 17, 2013 [Page 16] Internet-Draft Transporting Timing over MPLS June 2013 9. ECMP To ensure the optimal operation of slave clocks and avoid error introduced by forward and reverse path delay asymmetry, the physical path for Timing messages from master clock to slave Clock and vice versa must be the same for all Event Timing messages listed in section 7. Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost Multipath). Davari, et al. Expires December 17, 2013 [Page 17] Internet-Draft Transporting Timing over MPLS June 2013 10. PHP To ensure that the label on the top of the label stack is the Timing LSP Label, PHP MUST not be used. Davari, et al. Expires December 17, 2013 [Page 18] Internet-Draft Transporting Timing over MPLS June 2013 11. Entropy To ensure all Timing messages in a Timing LSP take the same path, Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and Entropy Label MUST NOT be used for the PWs that are carried inside Timing LSP [RFC6391]. SB> This is incorrect - you mean that all msgs of the same timing SB> flow need to have the same EL value. Davari, et al. Expires December 17, 2013 [Page 19] Internet-Draft Transporting Timing over MPLS June 2013 12. OAM, Control and Management In order to monitor Timing LSPs and their encapsulated PWs, they MUST be able to carry OAM and management messages. These management messages MUST be differentiated from Timing messages via already defined IETF methods. For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY run over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These Management protocols can easily be identified by the UDP Destination Port number or by GAL/G-ACH respectively. Also BFD, LSP-Ping and other management messages MAY run over the PWs encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3 or 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is going to be deprecated by IETF). In this case G-ACH, PW label (TTL=1) or GAL-ACH are used to identify such management messages. Davari, et al. Expires December 17, 2013 [Page 20] Internet-Draft Transporting Timing over MPLS June 2013 13. QoS Considerations In network deployments where not every LSR/LER is Timing-aware, it is important to reduce the impact of the non-Timing-aware LSR/LERs on the timing recovery in the slave clock. The Timing messages are time critical and must be treated with the highest priority. Therefore Timing over MPLS messages must be treated with the highest priority in the routers. This can be achieved by proper setup of Timing LSPs. It is recommended that the Timing LSPs are setup or configured properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC2697] for drop eligibility. Davari, et al. Expires December 17, 2013 [Page 21] Internet-Draft Transporting Timing over MPLS June 2013 14. FCS and Checksum Recalculation When time-stamp generation and timing packet adjustment is performed near the physical port hardware, the process MUST include recalculation of the Ethernet FCS. SB> The above is confusing - an LSR always recomputes the link layer SB> CRC which may or may not be Ethernet. Also FCS retention for the payload Ethernet described in [RFC4720] MUST NOT be used. For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum may be required as per UDP transport standards. SB> You really need to be working on getting the IPv6 C?S computation SB> removed from PTP msgs. When UDP checksum is used, each Timing-aware LER/LSR must either incrementally update the UDP checksum after Time stamping or Correction Field update or verify the UDP checksum on reception from upstream and recalculate the checksum completely on transmission to downstream node after Time stamping or Correction Field update. Davari, et al. Expires December 17, 2013 [Page 22] Internet-Draft Transporting Timing over MPLS June 2013 15. Behavior of LER/LSR Timing-capable/aware LERs and LSRs are routers that have one or more SB> You mean physical interfaces? interfaces that can perform Timing operations (OC/BC/TC) on Timing packets and are configured to do so. Timing-capable/aware LERs and LSRs can advertise their Timing-capability per-interface via control plane such as OSPF or IS-IS. SB> ISIS and OSPF are routing protocols. The Timing-capable/aware LERs can then signals Timing LSPs via RSVP-TE signaling. Alternatively the Timing capability of LER and LSRs may be configured in a centralized controller and the Timing LSP may be setup using manual configuration or other methods such as SDN. SB> it can also be configured individually rather then through SB> a cebtral controllwe 15.1. Behavior of Timing-capable/aware LER When a Timing-capable/aware LER behaves as a Transparent clock and receives a Timing message from a Timing-capable/aware non-MPLS interface, the LER updates the Correction Field (CF) and encapsulates and forwards the timing message over previously established Timing LSP. SB> You need to call out the details so that people properly SB> understand the definition of the new LSP. Also when a Timing message is received from a Timing-capable/ aware MPLS interface, LER updates the Correction Filed (CF) and decapsulates the MPLS encapsulation and forwards the timing message to a non-MPLS interface. When a Timing-capable/aware LER behaves as a Boundary clock and receives a Timing message from a Timing-capable/aware non MPLS interface, the LER Timestamps the Timing packet and sends it to the LERs Boundary clock processing module. Also when a Timing message is received from a Timing- capable/aware MPLS interface, the LER Timestamps the Timing packet and sends it to the LERs Boundary clock processing module. When a Timing-capable/aware LER behaves as an Ordinary Clock toward the MPLS network, and receives a Timing message from a Timing- capable/aware MPLS interface, the LER Timestamps the Timing packet and sends it to the LERs Ordinary clock processing module. 15.2. Behavior of Timing-capable/aware LSR When a Timing-capable/aware LSR behaves as a Transparent clock and receives a Timing message from a Timing-capable/aware MPLS interface, The LSR updates the Correction Filed (CF) and forwards the timing message over another MPLS interface. When a Timing-capable/aware LSR behaves as a Boundary clock and receives a Timing message from a Timing-capable/aware MPLS interface. The LSR performs the functions of a Boundary Clock in terminating the received Timing message and re-generating a new timing message over another (or the same) MPLS interface. Davari, et al. Expires December 17, 2013 [Page 23] Internet-Draft Transporting Timing over MPLS June 2013 15.3. Behavior of non-Timing-capable/aware LSR It is most beneficial when all LSRs in the path of a Timing LSP be timing-Capable/aware LSRs. This would ensure the highest quality time and clock synchronization by Timing Slave Clocks. However, this specification does not mandate that all LSRs in path of a Timing LSP be Timing- capable/aware. Non-Timing-capable/aware LSRs just switch the packets encapsulated in Timing LSPs and dont perform any Timing operation (TC or BC). However as explained in QoS section the Timing over MPLS packets MUST be still be treated with the highest priority based on their Traffic Class (TC) marking. Davari, et al. Expires December 17, 2013 [Page 24] Internet-Draft Transporting Timing over MPLS June 2013 16. Other considerations [IEEE-1588] defines an optional peer-to-peer Transparent clocking that requires peer delay measurement between two adjacent Timing- capable/ aware routers/switches. Peer delay measurement messages need to be time stamped and terminated by the Timing-capable/aware routers/ switches. This means that two adjacent LSRs may be engaged in a peer delay measurement. For transporting such peer delay measurement messages a single-hop LSP SHOULD to be created between the two adjacent LSRs engaged in peer delay measurement to carry peer delay measurement messages. Other methods such as PTP transport over Ethernet MAY be used for transporting peer delay measurement messages if the link between the two routers is Ethernet. In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ ware routers/switches MUST maintain a list of all the neighbors it needs to send a PDelay_Req to, where each neighbor corresponds to a timing LSP. The use of Explicit Null Label (Label= 0 or 2) is acceptable as long as either the Explicit Null label is the bottom of stack label (applicable only to UDP/IP encapsulation) or the label below the Explicit Null label is a PTP label. Davari, et al. Expires December 17, 2013 [Page 25] Internet-Draft Transporting Timing over MPLS June 2013 17. Security Considerations MPLS PW security considerations in general are discussed in [RFC3985] and [RFC4447],and those considerations also apply to this document. An experimental security protocol is defined in [IEEE-1588].The PTP security extension and protocol provides group source authentication, message integrity, and replay attack protection for PTP messages. When the MPLS network (provider network) serves multiple customers, it is important to maintain and process each customers clock and Timing messages separately from other customers to ensure there is no cross- customer effect. For example if an LER BC is synchronized to a specific grandmaster, belonging to customer A, then the LER MUST use that BC clock only for customer A to ensure that customer A cannot attack other customers by manipulating its time. Timing messages MAY be encrypted or authenticated, provided that the LERs/LSRs that are Timing capable/aware can authenticate/ decrypt the timing messages. Davari, et al. Expires December 17, 2013 [Page 26] Internet-Draft Transporting Timing over MPLS June 2013 18. Acknowledgements The authors would like to thank Ron Cohen, Yaakov Stein, Tal Mizrahi, Stefano Ruffini, Peter Meyer, and other members of IETF for reviewing and providing feedback on this draft. Davari, et al. Expires December 17, 2013 [Page 27] Internet-Draft Transporting Timing over MPLS June 2013 19. IANA Considerations There are no IANA requirements in this specification. Davari, et al. Expires December 17, 2013 [Page 28] Internet-Draft Transporting Timing over MPLS June 2013 20. References 20.1. Normative References [IEEE-1588] IEEE 1588-2008, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems". [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture", RFC 3985, March 2005. [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006. [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention", RFC 4720, November 2006. [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007. [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. 20.2. Informative References [I-D.ietf-pwe3-fat-pw] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow Aware Transport of Pseudowires over an MPLS Packet Switched Network", draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011. Davari, et al. Expires December 17, 2013 [Page 29] Internet-Draft Transporting Timing over MPLS June 2013 [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)". [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999. [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004. [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 4970, July 2007. [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", RFC 4971, July 2007. [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008. [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008. [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, September 2008. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. Davari, et al. Expires December 17, 2013 [Page 30] Internet-Draft Transporting Timing over MPLS June 2013 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, November 2011. [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, November 2012. Davari, et al. Expires December 17, 2013 [Page 31] Internet-Draft Transporting Timing over MPLS June 2013 1. Routing extensions for Timing-aware Routers MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE) link information used for constraint-based routing. Indeed, it is useful to advertise data plane TE router link capabilities, such as the capability for a router to be Timing-aware. This capability MUST then be taken into account during path computation to prefer or even require links that advertise themselves as Timing-aware. In this way the path can ensure the entry and exit points into the LERs and, if desired, the links into the LSRs are able to perform port based time-stamping thus minimizing their impact on the performance of the slave clock. extensions are required to OSPF and IS-IS in order to advertise Timing-aware capabilities of a link. Such extensions are outside the scope of this document; however such extension SHOULD be able to signal the following information per Router Link: o Capable of processing PTP, NTP or other Timing flows o Capable of performing Transparent Clock operation o Capable of performing Boundary Clock operation Davari, et al. Expires December 17, 2013 [Page 32] Internet-Draft Transporting Timing over MPLS June 2013 2. Signaling Extensions for Creating Timing LSPs RSVP-TE signaling MAY be used to setup the timing LSPs. When RSVP-TE is used to setup Timing LSPs, some information that indicates that the LSP is carrying Timing flows MUST be included in the new Extensions to RSVP-TE: The following information MAY also be included in the new Extensions to RSVP-TE: o Offset from Bottom of Stack (BoS) to the start of the Time-stamp field o Number of VLANs in case of PW encapsulation o Timestamp field Type * Correction Field, Timestamp o Timestamp Field format * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit NTP, etc. Note that in case the above optional information is signaled with RSVP-TE for a Timing LSP, all the Timing packets carried in that LSP must have the same signaled characteristics. For example if Timestamp format is signaled as 64-bit PTPv1, then all Timing packets must use 64-bit PTPv1 time-stamp. Davari, et al. Expires December 17, 2013 [Page 33] Internet-Draft Transporting Timing over MPLS June 2013 Authors' Addresses Shahram Davari Broadcom Corp. San Jose, CA 95134 USA Email: davari@broadcom.com Amit Oren Broadcom Corp. San Jose, CA 95134 USA Email: amito@broadcom.com Manav Bhatia Alcatel-Lucent Bangalore, India Email: manav.bhatia@alcatel-lucent.com Peter Roberts Alcatel-Lucent Kanata, Canada Email: peter.roberts@alcatel-lucent.com Laurent Montini Cisco Systems San Jose CA USA Email: lmontini@cisco.com Davari, et al. Expires December 17, 2013 [Page 34] Internet-Draft Transporting Timing over MPLS June 2013 Luca Cisco Systems San Jose CA USA Email: lmartini@cisco.com Davari, et al. Expires December 17, 2013 [Page 35] -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From ina@juniper.net Fri Aug 2 02:59:57 2013 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 42DCF11E8117 for ; Fri, 2 Aug 2013 02:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.033 X-Spam-Level: X-Spam-Status: No, score=0.033 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] 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 3x69eGzwH6x6 for ; Fri, 2 Aug 2013 02:59:49 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 4218211E82FA for ; Fri, 2 Aug 2013 02:59:38 -0700 (PDT) Received: from mail89-am1-R.bigfish.com (10.3.201.248) by AM1EHSOBE008.bigfish.com (10.3.204.28) with Microsoft SMTP Server id 14.1.225.22; Fri, 2 Aug 2013 09:59:37 +0000 Received: from mail89-am1 (localhost [127.0.0.1]) by mail89-am1-R.bigfish.com (Postfix) with ESMTP id 53C0216016F for ; Fri, 2 Aug 2013 09:59:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF03-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz9371I542I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275dh1de097hz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail89-am1: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=ina@juniper.net; helo=P-EMF03-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail89-am1 (localhost.localdomain [127.0.0.1]) by mail89-am1 (MessageSwitch) id 1375437575664200_11847; Fri, 2 Aug 2013 09:59:35 +0000 (UTC) Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.254]) by mail89-am1.bigfish.com (Postfix) with ESMTP id 9C8762A01D8 for ; Fri, 2 Aug 2013 09:59:35 +0000 (UTC) Received: from P-EMF03-SAC.jnpr.net (66.129.224.54) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 2 Aug 2013 09:59:30 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF03-SAC.jnpr.net (172.24.192.19) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 2 Aug 2013 02:59:29 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Fri, 2 Aug 2013 02:59:28 -0700 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.207) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 2 Aug 2013 03:12:24 -0700 Received: from mail96-am1-R.bigfish.com (10.3.201.235) by AM1EHSOBE023.bigfish.com (10.3.207.145) with Microsoft SMTP Server id 14.1.225.22; Fri, 2 Aug 2013 09:59:26 +0000 Received: from mail96-am1 (localhost [127.0.0.1]) by mail96-am1-R.bigfish.com (Postfix) with ESMTP id 851403403EB for ; Fri, 2 Aug 2013 09:59:26 +0000 (UTC) Received: from mail96-am1 (localhost.localdomain [127.0.0.1]) by mail96-am1 (MessageSwitch) id 1375437564925279_4380; Fri, 2 Aug 2013 09:59:24 +0000 (UTC) Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.225]) by mail96-am1.bigfish.com (Postfix) with ESMTP id D48E63E004C; Fri, 2 Aug 2013 09:59:24 +0000 (UTC) Received: from BLUPRD0511HT002.namprd05.prod.outlook.com (157.56.232.213) by AM1EHSMHS011.bigfish.com (10.3.207.111) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 2 Aug 2013 09:59:24 +0000 Received: from BLUPRD0511MB436.namprd05.prod.outlook.com ([169.254.4.24]) by BLUPRD0511HT002.namprd05.prod.outlook.com ([10.255.135.165]) with mapi id 14.16.0329.000; Fri, 2 Aug 2013 09:59:22 +0000 From: Ina Minei To: "Santiago Alvarez (saalvare)" , "mpls@ietf.org" Thread-Topic: LDP Color LSP - downstream unsolicited and on-demand Thread-Index: Ac6PWyqry9DwoxlGSgaq5SIsAqUn8wABmFzQ Date: Fri, 2 Aug 2013 09:59:22 +0000 Message-ID: <70BDAD02381BA54CA31315A2A26A7AD30383F771@BLUPRD0511MB436.namprd05.prod.outlook.com> References: <0C8935EE66D53445A3D3982BD9BE54681DFADE56@xmb-aln-x09.cisco.com> In-Reply-To: <0C8935EE66D53445A3D3982BD9BE54681DFADE56@xmb-aln-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [mpls] LDP Color LSP - downstream unsolicited and on-demand 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, 02 Aug 2013 09:59:57 -0000 Thank you for pointing out the text.=20 A few questions on the draft: - can you explain how the egress would know the colors it should advertise?= (I am assuming you are assuming additional information from a different pr= otocol, it would be good for the document to explicitly state this is the c= ase and provide a use case) - What kind of guarantees can the head end have regarding the path establis= hed, given that it has no indication whether all routers in the path suppor= t color matches or were able to select a path conforming to the colors (bas= ically only part of the path conforms to colors) and how does this relate t= o the use cases solved. To give an extreme example, if c1 is "low latency" = and c2 is "high latency", the egress signals for C1 but at node X only colo= r c2 is available, given the requirement in section 5 for "at least one def= ault path", what can be said of the resulting path at the head end (apart f= rom the fact that a path exists). Does this mean that the default path has = to be defined per color? - the document does not specify the lsping processing rules, in particular = at nodes where a particular color does not exist. Can you explain? Thanks, Ina=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of San= tiago Alvarez (saalvare) Sent: Friday, August 02, 2013 1:38 AM To: mpls@ietf.org Cc: Santiago Alvarez (saalvare) Subject: [mpls] LDP Color LSP - downstream unsolicited and on-demand If I understood the question correctly, Ina asked why draft-alvarez-mpls-ld= p-color-lsp-00 was only considering downstream unsolicited label allocation= . As mentioned on the mic, draft focuses on downstream label allocation, b= oth unsolicited and on-demand. Here's a snippet from the current doc: " An egress LSR MAY include the Color List TLV in a Label Mapping Message if using Downstream Unsolicited mode. An LSR may include the TLV in Label Request Messages if using Downstream on Demand mode. " Any further feedback appreciated. Thanks. SA -- _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From stbryant@cisco.com Fri Aug 2 03:02:15 2013 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 1C9D821E82DB; Fri, 2 Aug 2013 03:02:15 -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 W53Wdj8NZ1AT; Fri, 2 Aug 2013 03:02:09 -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 BA2BC21E82B8; Fri, 2 Aug 2013 03:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=58853; q=dns/txt; s=iport; t=1375437728; x=1376647328; h=message-id:date:from:reply-to:mime-version:to:cc:subject: content-transfer-encoding; bh=V6+bXfJLr6FMwuS+ayZ8inCnBSrHT8BTYWA4steJYCU=; b=TPf+yaEYvtj2Q8Xb+6gLRb0NrBp/ZyNjmPmJ/b9K2/cYWk4aVGxxDPe9 lIfaETsGeh3A7nEEx69W/6A9hDelp2NagGk1dlHsGl5NFpbGFZpBexelP hnQATbgDFcIYnRjxnYcPTdF2HLKz32KDpMmu4hONE5VecXGSTmya4Uv2D I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFACuD+1GQ/khL/2dsb2JhbABQCoMGNb8igRwWdIJFAR0uAREBLQ8MChgDAgECATcUAQkDAQUCAQEXh3UMn0aZQ45FAgkGBYEbIhGEAwOLLoEShwdBg1eBKoVsijiDGIFoCBc X-IronPort-AV: E=Sophos;i="4.89,800,1367971200"; d="scan'208";a="157898215" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 02 Aug 2013 10:02:02 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r72A1x1f013725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Aug 2013 10:01:59 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r72A1wA0005902; Fri, 2 Aug 2013 11:01:59 +0100 (BST) Message-ID: <51FB8396.9020504@cisco.com> Date: Fri, 02 Aug 2013 11:01:58 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mpls-chairs@tools.ietf.org" , "tictoc-chairs@tools.ietf.org" , int-ads@tools.ietf.org, "rtg-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-tictoc-1588overmpls@tools.ietf.org, John E Drake Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: [mpls] Comments on draft-ietf-tictoc-1588overmpls 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: Fri, 02 Aug 2013 10:02:15 -0000 Talking to John Drake about this, an alternative general model is for the LSP is that it is an LSP that timestamps the packet and then passes it to an application associated with the LSP at that hop. This has a lot of merit. If however we think about it some more we have a type of network service chaining going on here and so we don't need an LSP per say, because the path and instruction can be in the packet. In other words a general solution to the problem is to define an LSP with the properties that the packet is passed one hop, timestamped and delivered to the associated application. How this is MPLS construct is used to support time tranfer is entirely within the scope of TICTOC, but at the MPLS layer we have a clean reusable network service. - Stewart ============ SB> This draft does not seem to provide a precise definition SB> the properties of the new LSP type that it wishes to SB> define, in particular it does it define the PHB of those SB> LSPs, nor the full interaction with the MPLS SB> architecture. SB> SB> I have not tracked TICTOC for a while but I thought that SB> the original plan was to define the concept of an offset SB> into a packet to do the correction. SB> SB> It is disappointing that the opportunity was not taken SB> to define a timing shim inside the timing LSP so that SB> a time correction could be added to any packet such that SB> the MPLS system was isolated from the details of the SB> complexity of the particular time transfer type. SB> I think that much more clarify is needed in terms of SB> definition of the new LSP type, since it is unclear SB> from this text how to implement one. SB> SB> There are a lot of other MPLS services such as SB> LSP ping that need to be considered. SB> SB> Please see inline for more comments. However these SB> comments are made in the context of the text as written SB> whilst I have a fundamental concern that this approach SB> lacks an MPLS architectural soundness that need SB> greater thought with significant impact on the SB> draft. - Stewart TICTOC Working Group S. Davari Internet-Draft A. Oren Intended status: Standards Track Broadcom Corp. Expires: December 17, 2013 M. Bhatia P. Roberts Alcatel-Lucent L. Montini L. Martini Cisco Systems June 15, 2013 Transporting Timing messages over MPLS Networks draft-ietf-tictoc-1588overmpls-05 Abstract This document defines the method for transporting Timing messages such as PTP and NTP over an MPLS network. The method allows for the easy identification of these PDUs at the port level to allow for port SB> What is a port level processing of these PDUs in both LERs and LSRs. The basic idea is to transport Timing messages inside dedicated MPLS LSPs. These LSPs only carry Timing messages and possibly Control and Management packets, but they do not carry customer traffic. SB> More specifically they only carry traffic associated with the SB> timing service and its support. SB> The question arose WRT BFD - surely BFD is allowed, BUT surely SB> also it gets carried in a structure that causes it to get SB> timestamped. Two methods for transporting Timing messages over MPLS are defined. SB> Perhaps the right approach is to define the new LSP type and then SB> seperately to define the mapping of the various timing services SB> over that LSP type. The first method is to transport Timing messages directly over the dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for MPLS networks. The second method is to transport Timing messages inside a PW via Ethernet encapsulation. SB> I think that we should note that there are some SB> h/w reasons for this preference. A clean sheet approach SB> would have been to use PTP over MPLS with no intermediate SB> layers. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 17, 2013. Davari, et al. Expires December 17, 2013 [Page 1] Internet-Draft Transporting Timing over MPLS June 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . 9 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . . 12 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . 13 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . . 13 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . . 13 6.3. Other Timing Encapsulation methods . . . . . . . . . . . . 14 7. Timing message Processing . . . . . . . . . . . . . . . . . . 15 8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 16 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. OAM, Control and Management . . . . . . . . . . . . . . . . . 20 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 21 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . . 22 Davari, et al. Expires December 17, 2013 [Page 2] Internet-Draft Transporting Timing over MPLS June 2013 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 23 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . . 23 15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . . 23 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . . 24 16. Other considerations . . . . . . . . . . . . . . . . . . . . . 25 17. Security Considerations . . . . . . . . . . . . . . . . . . . 26 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 20.1. Normative References . . . . . . . . . . . . . . . . . . . 29 20.2. Informative References . . . . . . . . . . . . . . . . . . 29 Appendix 1. Routing extensions for Timing-aware Routers . . . . . 32 Appendix 2. Signaling Extensions for Creating Timing LSPs . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Davari, et al. Expires December 17, 2013 [Page 3] Internet-Draft Transporting Timing over MPLS June 2013 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. When used in lower case, these words convey their typical use in common language, and are not to be interpreted as described in RFC2119 [RFC2119]. Davari, et al. Expires December 17, 2013 [Page 4] Internet-Draft Transporting Timing over MPLS June 2013 1. Introduction The objective of Precision Time Protocol (PTP) and Network Timing Protocol (NTP) are to synchronize independent clocks running on separate nodes of a distributed system. [IEEE-1588] defines PTP messages for frequency, phase and time synchronization. The PTP messages include PTP PDUs over UDP/IP (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex F of [IEEE-1588]). SB> Sure BUT it is acknowledged that IEEE is open to the definition SB> of other PTP mappings if they provide better optimisation. This document defines mapping and transport of the PTP messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP defines several clock types: ordinary clocks, boundary clocks, end- to-end transparent clocks, and peer-to-peer transparent clocks. Transparent clocks require intermediate nodes to update correction field inside PTP message that reflects the transit time in the node. [RFC5905] defines NTP messages for clock and time synchronization. The PTP messages (PDUs) are transported over UDP/IP. This document SB> Should that be NTP messages? SB> It needs to be made clear as soon as you introduce NTP that SB> they use different time representations. defines mapping and transport of the NTP messages defined in [RFC5905] over MPLS networks. One key attribute of all of these Timing messages is that the Time stamp processing should occur as close as possible to the actual transmission and reception at the physical port interface. This targets optimal time and/or frequency recovery by avoiding variable delay introduced by queues internal to the clocks. SB> As I recall NTP has no epoch point defined, and I am not sure SB> where that point is in the case of PTP in this mapping SB> Hopefully this will get defined in due course. To facilitate the fast and efficient recognition of Timing messages at the port level when the Timing messages are carried over MPLS LSPs, SB> Over a new LSP type with time optimied characteristics this document defines the specific encapsulations that should be used. SB> Hopefully it will also define the PHP In addition, it can be expected that there will exist LSR/ LERs where only a subset of the physical ports will have the port- based Timing message processing capabilities. SB> Do you need to clarify that this only works at base and not in SB> a label heirarchy. In order to ensure that the LSPs carrying Timing packets always enter and exit ports with this capability, routing extensions are defined to advertise this capability on a port basis and to allow for the establishment of LSPs that only transit such ports. While this path establishment restriction may be applied only at the LER Ingress and/or egress ports, it becomes more important when using transparent clock capable LSRs in the path. SB> I do not understand the implications of the last SB> sentences - starting ", it becomes" Port based Timing message processing involves Timing message recognition. Once the Timing messages are recognized they can be modified based on the reception or transmission Time-stamp. This document provides two methods for transporting Timing messages over MPLS. One is applicable to MPLS environment and the other one is applicable to MPLS/MPLS-TP environment SB> I think the sentence is incomplete. Davari, et al. Expires December 17, 2013 [Page 5] Internet-Draft Transporting Timing over MPLS June 2013 The solution involves transporting Timing messages over dedicated LSPs called Timing LSPs. These LSPs carry Timing messages and MAY carry Management and control messages, but not data plane client traffic. SB> It is not clear why this restriction applies. Timing LSPs can be established statically or via signaling. SB> s/statically/by provisioning/network management/ Extensions to control plane (OSPF, ISIS, etc.) is required to enable routers to distribute their Timing processing capabilities over MPLS to other routers. However such extensions are outside the scope of this document. When signaling is used to setup the PTP LSP, Extensions to signaling SB> is it a PTP LSP or a Timing LSP? protocols (e.g., RSVP-TE) are required for establishing PTP LSPs. However such extensions are outside the scope of this document. SB> for mpls-tp GMPLS is the signalling protocol While the techniques included herein allow for the establishment of paths optimized to include Time-stamping capable links, the performance of the Slave clocks is outside the scope of this document. At the time of publishing this specification, Transparent Clocking (TC) is only defined for PTP. Therefore at this time any part of this specification that talks about Transparent Clocking applies only to PTP. Davari, et al. Expires December 17, 2013 [Page 6] Internet-Draft Transporting Timing over MPLS June 2013 2. Terminology 1588: The timing and synchronization as defined by IEEE 1588. SB> I think that there is a more formal name for the 1588 group SB> that needs to be used here. SB> Also do we need to talk about 1588-200? as there is SB> an update in progress NTP: The timing and synchronization protocol defined by IETF RFC-1305 and RFC-5905. PTP: The timing and synchronization protocol used by 1588. SB> need the proper name for 1588 Master Clock: The source of 1588 timing to a set of slave clocks. Master Port: A port on a ordinary or boundary clock that is in Master state. This is the source of timing toward slave ports. SB> I am not sure the reader knows what a port is Slave Clock: A receiver of 1588 timing from a master clock. Slave Port: A port on a boundary clock or ordinary clock that is receiving timing from a master clock. Ordinary Clock: A device with a single PTP port. Transparent Clock. A device that measures the time taken for a PTP event message to transit the device and then updates the correctionField of the message with this transit time. Boundary Clock: A device with more than one PTP port. Generally boundary clocks will have one port in slave state to receive timing and then other ports in master state to re-distribute the timing. PTP LSP: An LSP dedicated to carry PTP messages SB> PTP or timing? PTP PW: A PW within a PTP LSP that is dedicated to carry PTP messages. SB> Ah I don't think that PWE3 know what one of these is CW: Pseudowire Control Word LAG: Link Aggregation ECMP: Equal Cost Multipath CF: Correction Field, a field inside certain PTP messages (message type 0-3)that holds the accumulative transit time inside intermediate switches Timing messages: Timing Protocol messages that are exchanged between routers in order to establish a synchronized clock. SB> A number of these definitions look like copies of IEEE1588 SB> definitions. We need to provide references and note the SB> priority of the IEEE base reference. Davari, et al. Expires December 17, 2013 [Page 7] Internet-Draft Transporting Timing over MPLS June 2013 3. Problem Statement [IEEE-1588] has defined methods for transporting PTP messages over Ethernet and IP networks. [RFC5905] has defined the method of transporting NTP messages over IP networks. There is a need to transport Timing messages over MPLS networks while supporting the Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC) functionality in the LER and LSRs in the MPLS network. There are multiple ways of transporting Timing over MPLS. However, there is a requirement to limit the possible encapsulation options to simplify the Timing message identification and processing required at the port level. When Timing-awareness is needed, Timing messages should not be transported over LSPs or PWs that are carrying customer traffic because LSRs perform Label switching based on the top label in the stack. SB> Have you explained why? To detect Timing messages inside such LSPs require special hardware to do deep packet inspection at line rate. Even if such hardware exists, the payload can't be deterministically identified by LSRs because the payload type is a context of the PW label, and the PW label and its context are only known to the Edge routers (PEs/ LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, CES, etc). Even if one restricts an LSP to only carry Ethernet PWs, the LSRs dont have the knowledge of whether PW Control Word (CW) is present or not and therefore can not deterministically identify the payload. A generic method is defined in this document that does not require deep packet inspection at line rate, and can deterministically identify Timing messages. This method can be used to detect Timing Messages in both one-step and two-step clock implementations of ordinary, boundary and transparent clocks. SB> Needs a ref and I am sure many MPLS specialists will not understand SB> the msg types. Davari, et al. Expires December 17, 2013 [Page 8] Internet-Draft Transporting Timing over MPLS June 2013 4. Timing over MPLS Architecture Timing messages are exchange between Timing ports on ordinary and SB> Have you defined a timing port? boundary clocks. Boundary clocks terminate the Timing messages and act as master for other boundary clocks or for slave clocks. End-to- End Transparent clocks do not terminate the Timing messages but they do modify the contents of the Timing messages as they transit across the transparent clock. Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent Clock (TC) could be implemented in either LERs or LSRs. SB> LER and LSR need to be expanded An example is shown in Figure 1, where the LERs act as Ordinary Clock (OC) and are the initiating/terminating point for Timing messages. The ingress LER encapsulates the Timing messages in Timing LSP and the Egress LER terminates the Timing LSP. The LSRs act as Transparent Clock (TC) and just update the Timing field in the Timing messages. +--------+ +-------+ +-------+ +-------+ +--------+ |Switch, | | | | | | | |Switch, | | Router |-----| LER |-----| LSR |-----| LER |-----| Router | | | | OC | | TC | | OC | | | +--------+ +-------+ +-------+ +-------+ +--------+ / \ +-------+ / \ +-------+ | LER | / \ | LER | | Master|---/ \---| Slave | | Clock | | Clock | +-------+ +-------+ Figure (1) - Deployment example 1 of timing over MPLS network Another example is shown in Figure2, where LERs terminate the Timing messages received from switch/routers that are outside of the MPLS network acting as OC or BC. In this example LERs regenerate the clock and initiate timing messages encapsulated in Timing LSP toward the MPLS network, while the LSRs act as Transparent Clock (TC) and just update the Timing field in the Timing messages, which are already encapsulated in Timing LSPs. Davari, et al. Expires December 17, 2013 [Page 9] Internet-Draft Transporting Timing over MPLS June 2013 +--------+ +-------+ +-------+ +-------+ +--------+ |Switch, | | | | | | | |Switch, | | Router |-----| LER |-----| LSR |-----| LER |-----| Router | | OC/BC | | BC | | TC | | BC | | OC/BC | +--------+ +-------+ +-------+ +-------+ +--------+ Figure (2) - Deployment example 2 of timing over MPLS network Another example is shown in Figure 3, where LERs do not terminate the Timing messages received from switch/routers that are outside of the MPLS network acting as OC, TC or BC. The LERs act as TC and update the Timing field in the Timing messages as they transit the LER, while encapsulating them in timing LSP. The LSRs also act as Transparent Clock (TC) and just update the Timing field in the Timing messages which are already encapsulated in Timing LSPs. +--------+ +-------+ +-------+ +-------+ +--------+ |Switch, | | | | | | | |Switch, | | Router |-----| LER |-----| LSR |-----| LER |-----| Router | |OC/TC/BC| | TC | | TC | | TC | |OC/TC/BC| +--------+ +-------+ +-------+ +-------+ +--------+ Figure (3) - Deployment example 3 of timing over MPLS network Another example is shown in Figure 4, where LERs and LSRs support Boundary Clocks. A single-hop LSP is created between two adjacent LSRs engaged in BC operation. Other methods such as PTP transport over Ethernet MAY be used for transporting timing messages if the link between the two routers is Ethernet. +--------+ +-------+ +-------+ +-------+ +--------+ |Switch, | | | | | | | |Switch, | | Router |-----| LER |-----| LSR |-----| LER |-----| Router | | OC/BC | | BC | | BC | | BC | | OC/BC | +--------+ +-------+ +-------+ +-------+ +--------+ Figure (4) - Deployment example 3 of timing over MPLS network An MPLS domain MAY serve multiple customers. In these cases the MPLS domain (maintained by a service provider) may provide timing services to multiple customers, each having their own Timing domain. The Timing over MPLS architecture assumes full mesh of Timing LSPs between all LERs supporting this specification. SB> Note sure this is right - the salves surely do not need to SB> exchange timing amongst themselves It supports Point-to- point (VPWS) and Multipoint (VPLS) services. SB> What does that mean? You do not carry user data traffic? SB> Maybe it's the ordering of the statemnets that is causing SB> confusion. This means that a customer may purchase a Point-to-point Timing service between two customer sites or a Multipoint Timing service between more than Davari, et al. Expires December 17, 2013 [Page 10] Internet-Draft Transporting Timing over MPLS June 2013 two customer sites. The Timing over MPLS architecture supports P2P or P2MP Timing LSPs. This means that the Timing Multicast messages such as PTP Multicast event messages can be transported over P2MP Timing LSP or be replicated and transported over many P2P Timing LSPs. SB> Note we do not yet have a definition of a P2MP mpls-tp LSP SB> nor a P2MP PW, although we are close. Timing messages, that do not require Time stamping or Correction Field update MAY be transported over Timing LSPs to simplify hardware and software. PTP Announce messages that determine the Timing LSP terminating point behavior such as BC/OC/TC SHOULD be transported over the Timing LSP to simplify hardware and software. SB> have you defined and referenced PTP announce msgs? Davari, et al. Expires December 17, 2013 [Page 11] Internet-Draft Transporting Timing over MPLS June 2013 5. Dedicated LSPs for Timing messages Many methods have been considered for identifying the Timing messages when they are encapsulated in MPLS such as using GAL/G-ACH or a new reserved label. These methods were not attractive since they either required deep packet inspection at line rate in the intermediate LSRs or they required use of a scarce new reserved label. Also one of the goals was to reuse existing OAM mechanisms. SB> RLs = SPLs are not so rare now. In any case needs a ref. The method defined in this document can be used by LER and LSRs to identify Timing messages in MPLS tunnels by just looking at the top label in the MPLS label stack, which only carry Timing messages as well as OAM, but not data plane client traffic. Compliant implementations MUST use dedicated LSPs to carry Timing messages over MPLS. SB> I think that we need a definition of the properies of these LSPs These LSPs are herein referred to as "Timing LSPs" and the labels associated with these LSPs as "Timing LSP labels". The Timing LSPs that runs between Ingress and Egress LERs MUST be co-routed. Alternatively, a single bidirectional co-routed LSP can be used. SB> I though that you said you could use M2MP LSPs - these are not SB> bidirectional. Co-routing of the two directions is required to limit the difference in the delays in the Master clock to Slave clock direction compared to the Slave clock to Master clock direction. The Timing LSP MAY be MPLS/MPLS-TP LSP. The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS. New Extensions to RSVP-TE/GMPLS TLVs are required; however they are outside the scope of this document. The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such as BFD and LSP Ping but the LSP data plane client plane traffic MUST be Timing packets only. SB> Why? Davari, et al. Expires December 17, 2013 [Page 12] Internet-Draft Transporting Timing over MPLS June 2013 6. Timing over LSP Encapsulation The encapsulations is not LSP is it? This document defines two methods for carrying Timing messages over MPLS. The first method is carrying UDP/IP encapsulated Timing messages over Timing LSPs, and the second method, is carrying Ethernet encapsulated Timing messages over Ethernet PWs inside Timing LSPs. 6.1. Timing over UDP/IP over MPLS Encapsulation The simplest method of transporting Timing messages over MPLS is to encapsulate Timing PDUs in UDP/IP and then encapsulate them in Timing LSP. This format is shown in Figure 4. +----------------------+ | Timing LSP Label | +----------------------+ | IPv4/6 | +----------------------+ | UDP | +----------------------+ | Timing PDU | +----------------------+ Figure (4) - Timing over UDP/IP over MPLS Encapsulation This encapsulation is very simple and is useful when the network between Timing Master Clock and Slave Clock is MPLS network. SB> Simple is a judgement call In order for an LER/LSR to process Timing messages, the Timing LSP Label must be at the top label of the label stack. The LER/LSR MUST know that the Timing LSP Label is used for carrying Timing messages. This can be accomplished via static configuration or via RSVP-TE signaling. The UDP/IP encapsulation of PTP MUST follow Annex D and E of [IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow [RFC5905]. 6.2. Timing over PW Encapsulation Another method of transporting Timing over MPLS networks is by encapsulating Timing PDUs in PW which in turn is transported over Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448], shown in Fig 5(A) MUST be used and the Ethernet encapsulation of PTP MUST follow Annex F of [IEEE-1588]. Davari, et al. Expires December 17, 2013 [Page 13] Internet-Draft Transporting Timing over MPLS June 2013 The RAW mode or Tagged mode defined in [RFC4448] MAY be used and the Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The Timing over PW encapsulation MUST use the Control Word (CW) as specified in [RFC4448] to ensure proper detection of PTP messages inside the MPLS packets for Timing over LSP and Timing over PW encapsulation. SB> That needs explanation The use of Sequence Number in the CW is optional. SB> Given that s/n are never in practice deployed, you could probably SB> simplify things by sayig that they are not used. Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over PW (the IP PW discussed in [RFC4447]) shown in Fig 5(B). +----------------+ +----------------+ |Timing LSP Label| |Timing LSP Label| +----------------+ +----------------+ | PW Label | | PW Label | +----------------+ +----------------+ | Control Word | | IP | +----------------+ +----------------+ | Ethernet | | UDP | | Header | +----------------+ +----------------+ | Timing PDU | |S-VLAN(Optional)| | | +----------------+ +----------------+ |C-VLAN(Optional)| (B) +----------------+ | Timing PDU | | | +----------------+ (A) Figure (5) - Timing over PW Encapsulations In order for an LSR to process PTP messages, the top label of the label stack (the Tunnel Label) MUST be a Timing label. S> You said that before. 6.3. Other Timing Encapsulation methods In future other timing encapsulation methods may be introduced, such as a new shim header after the Bottom of Stack to carry the Timing information. Such new encapsulations are outside the scope of this document. SB> Taking a pure MPLS pov, you can simplify a lot of the text SB> out of the definition of the LSP Davari, et al. Expires December 17, 2013 [Page 14] Internet-Draft Transporting Timing over MPLS June 2013 SB> I think we need a section on LSP processing 7. Timing message Processing Each Timing protocol such as PTP and NTP, define their set of Timing messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, FOLLOW_UP, etc messages. Some of the Timing messages require time stamping or correction field update at port level and some dont. It is the job of the LER/LSR to parse the timing message and find out the type of the Timing message and decide whether and how to Time- stamp it (e.g., BC) or update correction field(e.g., TC). SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing SB> function rather than the LER? For example the following PTP messages (called Event messages) require time-stamping or correction field update: o SYNC o DELAY_REQ (Delay Request) o PDELAY_REQ (Peer Delay Request) o PDELAY_RESP (Peer Delay Response) SYNC and DELAY_REQ are exchanged between Master Clock and Slave Clock and MUST be transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP are exchanged between adjacent PTP clocks (i.e. Master, Slave, Boundary, or Transparent) and SHOULD be transported over single hop PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP, and PDELAY_RESP_FOLLOW_UP messages MUST also be transported over the PTP LSPs. For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be transported over two PTP LSPs that are in opposite directions. These PTP LSPs, which are in opposite directions MUST be congruent and co- routed. Alternatively, a single bidirectional co-routed LSP can be used. Except as indicated above for the two-step PTP clocks, Non-Event PTP message types do not need to be processed by intermediate routers. These message types MAY be carried in PTP Tunnel LSPs. SB> Are you saying that a timing P router has to be msg type sensitive? Davari, et al. Expires December 17, 2013 [Page 15] Internet-Draft Transporting Timing over MPLS June 2013 8. Protection and Redundancy SB> This is a bit of a jump - I don't know how the LSP itself works yet! In order to ensure continuous uninterrupted operation of slave clocks, usually as a general practice, slave clocks (or ports) track redundant master clocks. It is the responsibility of the network operator to ensure that physically disjoint Timing LSPs are established between a slave clock (or port) and redundant master clocks (or ports). When a slave clock (or port) listens to redundant master clocks or ports, any prolonged Timing LSP outage will trigger the slave clock or port to switch to a redundant master clock or port. LSP/PW protection such as Linear protection Switching (1:1, 1+1), Ring protection switching or MPLS Fast Reroute (FRR) generally switch alternative path that usually cause a change in delay, which if undetected by slave clock can reduce accuracy of the slave clock. Therefore protection switching MAY be used, as long as phase jumps upon switchover due to differences in path latency are detected and compensated for (such compensation not being required if BCs or peer- peer TCs are used throughout). Note that any protection or reroute mechanism that adds additional MPLS label to the label stack, such as Facility Backup Fast Reroute, MUST ensure that the pushed label is also a Timing Label to ensure recognition of the MPLS frame as containing Timing messages, as it transits the backup path. Davari, et al. Expires December 17, 2013 [Page 16] Internet-Draft Transporting Timing over MPLS June 2013 9. ECMP To ensure the optimal operation of slave clocks and avoid error introduced by forward and reverse path delay asymmetry, the physical path for Timing messages from master clock to slave Clock and vice versa must be the same for all Event Timing messages listed in section 7. Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost Multipath). Davari, et al. Expires December 17, 2013 [Page 17] Internet-Draft Transporting Timing over MPLS June 2013 10. PHP To ensure that the label on the top of the label stack is the Timing LSP Label, PHP MUST not be used. Davari, et al. Expires December 17, 2013 [Page 18] Internet-Draft Transporting Timing over MPLS June 2013 11. Entropy To ensure all Timing messages in a Timing LSP take the same path, Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and Entropy Label MUST NOT be used for the PWs that are carried inside Timing LSP [RFC6391]. SB> This is incorrect - you mean that all msgs of the same timing SB> flow need to have the same EL value. Davari, et al. Expires December 17, 2013 [Page 19] Internet-Draft Transporting Timing over MPLS June 2013 12. OAM, Control and Management In order to monitor Timing LSPs and their encapsulated PWs, they MUST be able to carry OAM and management messages. These management messages MUST be differentiated from Timing messages via already defined IETF methods. For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY run over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These Management protocols can easily be identified by the UDP Destination Port number or by GAL/G-ACH respectively. Also BFD, LSP-Ping and other management messages MAY run over the PWs encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3 or 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is going to be deprecated by IETF). In this case G-ACH, PW label (TTL=1) or GAL-ACH are used to identify such management messages. Davari, et al. Expires December 17, 2013 [Page 20] Internet-Draft Transporting Timing over MPLS June 2013 13. QoS Considerations In network deployments where not every LSR/LER is Timing-aware, it is important to reduce the impact of the non-Timing-aware LSR/LERs on the timing recovery in the slave clock. The Timing messages are time critical and must be treated with the highest priority. Therefore Timing over MPLS messages must be treated with the highest priority in the routers. This can be achieved by proper setup of Timing LSPs. It is recommended that the Timing LSPs are setup or configured properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC2697] for drop eligibility. Davari, et al. Expires December 17, 2013 [Page 21] Internet-Draft Transporting Timing over MPLS June 2013 14. FCS and Checksum Recalculation When time-stamp generation and timing packet adjustment is performed near the physical port hardware, the process MUST include recalculation of the Ethernet FCS. SB> The above is confusing - an LSR always recomputes the link layer SB> CRC which may or may not be Ethernet. Also FCS retention for the payload Ethernet described in [RFC4720] MUST NOT be used. For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum may be required as per UDP transport standards. SB> You really need to be working on getting the IPv6 C?S computation SB> removed from PTP msgs. When UDP checksum is used, each Timing-aware LER/LSR must either incrementally update the UDP checksum after Time stamping or Correction Field update or verify the UDP checksum on reception from upstream and recalculate the checksum completely on transmission to downstream node after Time stamping or Correction Field update. Davari, et al. Expires December 17, 2013 [Page 22] Internet-Draft Transporting Timing over MPLS June 2013 15. Behavior of LER/LSR Timing-capable/aware LERs and LSRs are routers that have one or more SB> You mean physical interfaces? interfaces that can perform Timing operations (OC/BC/TC) on Timing packets and are configured to do so. Timing-capable/aware LERs and LSRs can advertise their Timing-capability per-interface via control plane such as OSPF or IS-IS. SB> ISIS and OSPF are routing protocols. The Timing-capable/aware LERs can then signals Timing LSPs via RSVP-TE signaling. Alternatively the Timing capability of LER and LSRs may be configured in a centralized controller and the Timing LSP may be setup using manual configuration or other methods such as SDN. SB> it can also be configured individually rather then through SB> a cebtral controllwe 15.1. Behavior of Timing-capable/aware LER When a Timing-capable/aware LER behaves as a Transparent clock and receives a Timing message from a Timing-capable/aware non-MPLS interface, the LER updates the Correction Field (CF) and encapsulates and forwards the timing message over previously established Timing LSP. SB> You need to call out the details so that people properly SB> understand the definition of the new LSP. Also when a Timing message is received from a Timing-capable/ aware MPLS interface, LER updates the Correction Filed (CF) and decapsulates the MPLS encapsulation and forwards the timing message to a non-MPLS interface. When a Timing-capable/aware LER behaves as a Boundary clock and receives a Timing message from a Timing-capable/aware non MPLS interface, the LER Timestamps the Timing packet and sends it to the LERs Boundary clock processing module. Also when a Timing message is received from a Timing- capable/aware MPLS interface, the LER Timestamps the Timing packet and sends it to the LERs Boundary clock processing module. When a Timing-capable/aware LER behaves as an Ordinary Clock toward the MPLS network, and receives a Timing message from a Timing- capable/aware MPLS interface, the LER Timestamps the Timing packet and sends it to the LERs Ordinary clock processing module. 15.2. Behavior of Timing-capable/aware LSR When a Timing-capable/aware LSR behaves as a Transparent clock and receives a Timing message from a Timing-capable/aware MPLS interface, The LSR updates the Correction Filed (CF) and forwards the timing message over another MPLS interface. When a Timing-capable/aware LSR behaves as a Boundary clock and receives a Timing message from a Timing-capable/aware MPLS interface. The LSR performs the functions of a Boundary Clock in terminating the received Timing message and re-generating a new timing message over another (or the same) MPLS interface. Davari, et al. Expires December 17, 2013 [Page 23] Internet-Draft Transporting Timing over MPLS June 2013 15.3. Behavior of non-Timing-capable/aware LSR It is most beneficial when all LSRs in the path of a Timing LSP be timing-Capable/aware LSRs. This would ensure the highest quality time and clock synchronization by Timing Slave Clocks. However, this specification does not mandate that all LSRs in path of a Timing LSP be Timing- capable/aware. Non-Timing-capable/aware LSRs just switch the packets encapsulated in Timing LSPs and dont perform any Timing operation (TC or BC). However as explained in QoS section the Timing over MPLS packets MUST be still be treated with the highest priority based on their Traffic Class (TC) marking. Davari, et al. Expires December 17, 2013 [Page 24] Internet-Draft Transporting Timing over MPLS June 2013 16. Other considerations [IEEE-1588] defines an optional peer-to-peer Transparent clocking that requires peer delay measurement between two adjacent Timing- capable/ aware routers/switches. Peer delay measurement messages need to be time stamped and terminated by the Timing-capable/aware routers/ switches. This means that two adjacent LSRs may be engaged in a peer delay measurement. For transporting such peer delay measurement messages a single-hop LSP SHOULD to be created between the two adjacent LSRs engaged in peer delay measurement to carry peer delay measurement messages. Other methods such as PTP transport over Ethernet MAY be used for transporting peer delay measurement messages if the link between the two routers is Ethernet. In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ ware routers/switches MUST maintain a list of all the neighbors it needs to send a PDelay_Req to, where each neighbor corresponds to a timing LSP. The use of Explicit Null Label (Label= 0 or 2) is acceptable as long as either the Explicit Null label is the bottom of stack label (applicable only to UDP/IP encapsulation) or the label below the Explicit Null label is a PTP label. Davari, et al. Expires December 17, 2013 [Page 25] Internet-Draft Transporting Timing over MPLS June 2013 17. Security Considerations MPLS PW security considerations in general are discussed in [RFC3985] and [RFC4447],and those considerations also apply to this document. An experimental security protocol is defined in [IEEE-1588].The PTP security extension and protocol provides group source authentication, message integrity, and replay attack protection for PTP messages. When the MPLS network (provider network) serves multiple customers, it is important to maintain and process each customers clock and Timing messages separately from other customers to ensure there is no cross- customer effect. For example if an LER BC is synchronized to a specific grandmaster, belonging to customer A, then the LER MUST use that BC clock only for customer A to ensure that customer A cannot attack other customers by manipulating its time. Timing messages MAY be encrypted or authenticated, provided that the LERs/LSRs that are Timing capable/aware can authenticate/ decrypt the timing messages. Davari, et al. Expires December 17, 2013 [Page 26] Internet-Draft Transporting Timing over MPLS June 2013 18. Acknowledgements The authors would like to thank Ron Cohen, Yaakov Stein, Tal Mizrahi, Stefano Ruffini, Peter Meyer, and other members of IETF for reviewing and providing feedback on this draft. Davari, et al. Expires December 17, 2013 [Page 27] Internet-Draft Transporting Timing over MPLS June 2013 19. IANA Considerations There are no IANA requirements in this specification. Davari, et al. Expires December 17, 2013 [Page 28] Internet-Draft Transporting Timing over MPLS June 2013 20. References 20.1. Normative References [IEEE-1588] IEEE 1588-2008, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems". [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture", RFC 3985, March 2005. [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006. [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention", RFC 4720, November 2006. [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007. [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. 20.2. Informative References [I-D.ietf-pwe3-fat-pw] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow Aware Transport of Pseudowires over an MPLS Packet Switched Network", draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011. Davari, et al. Expires December 17, 2013 [Page 29] Internet-Draft Transporting Timing over MPLS June 2013 [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)". [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999. [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004. [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 4970, July 2007. [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", RFC 4971, July 2007. [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008. [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008. [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, September 2008. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. Davari, et al. Expires December 17, 2013 [Page 30] Internet-Draft Transporting Timing over MPLS June 2013 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, November 2011. [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, November 2012. Davari, et al. Expires December 17, 2013 [Page 31] Internet-Draft Transporting Timing over MPLS June 2013 1. Routing extensions for Timing-aware Routers MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE) link information used for constraint-based routing. Indeed, it is useful to advertise data plane TE router link capabilities, such as the capability for a router to be Timing-aware. This capability MUST then be taken into account during path computation to prefer or even require links that advertise themselves as Timing-aware. In this way the path can ensure the entry and exit points into the LERs and, if desired, the links into the LSRs are able to perform port based time-stamping thus minimizing their impact on the performance of the slave clock. extensions are required to OSPF and IS-IS in order to advertise Timing-aware capabilities of a link. Such extensions are outside the scope of this document; however such extension SHOULD be able to signal the following information per Router Link: o Capable of processing PTP, NTP or other Timing flows o Capable of performing Transparent Clock operation o Capable of performing Boundary Clock operation Davari, et al. Expires December 17, 2013 [Page 32] Internet-Draft Transporting Timing over MPLS June 2013 2. Signaling Extensions for Creating Timing LSPs RSVP-TE signaling MAY be used to setup the timing LSPs. When RSVP-TE is used to setup Timing LSPs, some information that indicates that the LSP is carrying Timing flows MUST be included in the new Extensions to RSVP-TE: The following information MAY also be included in the new Extensions to RSVP-TE: o Offset from Bottom of Stack (BoS) to the start of the Time-stamp field o Number of VLANs in case of PW encapsulation o Timestamp field Type * Correction Field, Timestamp o Timestamp Field format * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit NTP, etc. Note that in case the above optional information is signaled with RSVP-TE for a Timing LSP, all the Timing packets carried in that LSP must have the same signaled characteristics. For example if Timestamp format is signaled as 64-bit PTPv1, then all Timing packets must use 64-bit PTPv1 time-stamp. Davari, et al. Expires December 17, 2013 [Page 33] Internet-Draft Transporting Timing over MPLS June 2013 Authors' Addresses Shahram Davari Broadcom Corp. San Jose, CA 95134 USA Email: davari@broadcom.com Amit Oren Broadcom Corp. San Jose, CA 95134 USA Email: amito@broadcom.com Manav Bhatia Alcatel-Lucent Bangalore, India Email: manav.bhatia@alcatel-lucent.com Peter Roberts Alcatel-Lucent Kanata, Canada Email: peter.roberts@alcatel-lucent.com Laurent Montini Cisco Systems San Jose CA USA Email: lmontini@cisco.com Davari, et al. Expires December 17, 2013 [Page 34] Internet-Draft Transporting Timing over MPLS June 2013 Luca Cisco Systems San Jose CA USA Email: lmartini@cisco.com Davari, et al. Expires December 17, 2013 [Page 35] -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From gregory.mirsky@ericsson.com Fri Aug 2 03:11:04 2013 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 B86D711E832A for ; Fri, 2 Aug 2013 03:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xE71-tezLaE for ; Fri, 2 Aug 2013 03:10:58 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF1821E80A8 for ; Fri, 2 Aug 2013 03:10:55 -0700 (PDT) X-AuditID: c6180641-b7f986d000007a82-fe-51fb85ae4ca0 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 6D.DC.31362.EA58BF15; Fri, 2 Aug 2013 12:10:54 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Fri, 2 Aug 2013 06:10:54 -0400 From: Gregory Mirsky To: "mpls@ietf.org" Thread-Topic: Drafts related to shared mesh protection and interconnected ring protection Thread-Index: Ac6PaJEb14rcB2AZTZOtd8fFZvtT5w== Date: Fri, 2 Aug 2013 10:10:53 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B6BB7DB@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B6BB7DBeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyuXSPt+661t+BBnPvGljcWrqS1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGZu6FzEVnBSpeHx6IWMD4zvBLkZODgkBE4muqe9YIGwxiQv3 1rOB2EICRxklvp7RhbCXMUo8220BYrMJGEm82NjDDmKLCChLHJnYzQpiCwuESfy8fIkNIh4t 8eL3dlYIW09i0omnYPUsAioSz06cYASxeQV8Ja5/XQtmMwLt/X5qDROIzSwgLnHryXwmiHsE JJbsOc8MYYtKvHz8jxXCVpZY8mQ/C0R9vsStqRtYIWYKSpyc+YRlAqPQLCSjZiEpm4WkDCKu I7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9i5CgtTi3LTTcy3MQIDPtjEmyOOxgXfLI8xCjN waIkzrtB70ygkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsaQTZ/l3pqovfofoeA5Y4P2m1Nl mzivpJlFsAuk+c9yY8s/7JCq3cXoI8i379SF5KBJXRN5Hi7p+pyw9recWPmPtuSn9RGznfaK 3+Bz7Vk8x9tYXiTFzzEpiOn1Dc8i+cumzjXn0zljMkLNdt963OR3Rme3xLKKg/r+/HM8V3hV a/ZOyd56Q4mlOCPRUIu5qDgRADHPQWlJAgAA Subject: [mpls] Drafts related to shared mesh protection and interconnected 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: Fri, 02 Aug 2013 10:11:04 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B6BB7DBeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Hui (apologize for not getting your e-mail in time), et. al, below are drafts I believe are relevant to proposal you've presented today: * On Shared Mesh Protection: * Supporting Shared Mesh Protection in MPLS-TP Networks draft-pan-sha= red-mesh-protection-05.txt * MPLS-TP Shared Mesh Protection draft-cheung-mpls-tp-mesh-protection= -05.txt * A framework for the use of SPMEs for shared mesh protection draft-a= llan-mpls-spme-smp-fmwk-01 * On Interconnected Ring Protection (extending RFC 6974): * MPLS-TP protection for interconnected rings draft-liu-mpls-tp-inter= connected-ring-protection-04 Kind regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B6BB7DBeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Hui (apologize for not getting your e-mail in time), et. al,
below are drafts I believe are relevant to proposal you've presented t= oday:
  • On Shared Mesh Protection:
  • Supporting Shared Mesh Protection in MPLS-TP Networks draft-pan-shared-= mesh-protection-05.txt
  • MPLS-TP Shared Mesh Protection draft-cheung-= mpls-tp-mesh-protection-05.txt
  • A framework for the use of SPMEs for= shared mesh protection draft-allan-mpls-spme-smp-fmwk-01
  • On Interconnected Ring Protection (extending RFC 6974):
  • MPLS-TP protection for interconnected rings draft-liu-mpls-tp-interconn= ected-ring-protection-04
 
        Kind regards,
           &nbs= p;    Greg
 
 --_000_7347100B5761DC41A166AC17F22DF1121B6BB7DBeusaamb103erics_-- From davari@broadcom.com Fri Aug 2 03:24:02 2013 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 9470D21E82D3; Fri, 2 Aug 2013 03:24:02 -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 d7GBZieuU69G; Fri, 2 Aug 2013 03:23:58 -0700 (PDT) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id DF17121F8EB2; Fri, 2 Aug 2013 03:23:57 -0700 (PDT) Received: from [10.9.208.53] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 02 Aug 2013 03:13:42 -0700 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.1.438.0; Fri, 2 Aug 2013 03:23:33 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS04.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Fri, 2 Aug 2013 03:23:33 -0700 From: "Shahram Davari" To: "" Thread-Topic: [mpls] Comments on draft-ietf-tictoc-1588overmpls Thread-Index: AQHOj2dsoD26UTw5FECSgmrxo5m7wJmBtd9E Date: Fri, 2 Aug 2013 10:23:33 +0000 Message-ID: References: <51FB8396.9020504@cisco.com> In-Reply-To: <51FB8396.9020504@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-WSS-ID: 7DE559DC2L869999094-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "tictoc-chairs@tools.ietf.org" , "mpls@ietf.org" , "tictoc@ietf.org" , "draft-ietf-tictoc-1588overmpls@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "int-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Comments on draft-ietf-tictoc-1588overmpls 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, 02 Aug 2013 10:24:02 -0000 Hi Stewart We have already looked at similar approach. The issue with one hop LSP is t= hat not all LSRs are 1588 capable. One of the requirements is for non-1588 = capable routers to just switch the packet normally. Regards, Shahram On Aug 2, 2013, at 12:02 PM, "Stewart Bryant" wrote: > Talking to John Drake about this, an alternative general > model is for the LSP is that it is an LSP that timestamps > the packet and then passes it to an application associated > with the LSP at that hop. >=20 > This has a lot of merit. >=20 > If however we think about it some more we have a > type of network service chaining going on here and > so we don't need an LSP per say, because the path > and instruction can be in the packet. >=20 > In other words a general solution to the problem > is to define an LSP with the properties that the > packet is passed one hop, timestamped and delivered > to the associated application. >=20 > How this is MPLS construct is used to support time > tranfer is entirely within the scope of TICTOC, but > at the MPLS layer we have a clean reusable network > service. >=20 > - Stewart >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > SB> This draft does not seem to provide a precise definition > SB> the properties of the new LSP type that it wishes to > SB> define, in particular it does it define the PHB of those > SB> LSPs, nor the full interaction with the MPLS > SB> architecture. > SB> > SB> I have not tracked TICTOC for a while but I thought that > SB> the original plan was to define the concept of an offset > SB> into a packet to do the correction. > SB> > SB> It is disappointing that the opportunity was not taken > SB> to define a timing shim inside the timing LSP so that > SB> a time correction could be added to any packet such that > SB> the MPLS system was isolated from the details of the > SB> complexity of the particular time transfer type. >=20 > SB> I think that much more clarify is needed in terms of > SB> definition of the new LSP type, since it is unclear > SB> from this text how to implement one. > SB> > SB> There are a lot of other MPLS services such as > SB> LSP ping that need to be considered. > SB> > SB> Please see inline for more comments. However these > SB> comments are made in the context of the text as written > SB> whilst I have a fundamental concern that this approach > SB> lacks an MPLS architectural soundness that need > SB> greater thought with significant impact on the > SB> draft. >=20 > - Stewart >=20 >=20 > TICTOC Working Group S. Davari > Internet-Draft A. Oren > Intended status: Standards Track Broadcom Corp. > Expires: December 17, 2013 M. Bhatia > P. Roberts > Alcatel-Lucent > L. Montini > L. Martini > Cisco Systems > June 15, 2013 >=20 >=20 > Transporting Timing messages over MPLS Networks > draft-ietf-tictoc-1588overmpls-05 >=20 > Abstract >=20 > This document defines the method for transporting Timing messages > such as PTP and NTP over an MPLS network. The method allows for the > easy identification of these PDUs at the port level to allow for port >=20 > SB> What is a port >=20 > level processing of these PDUs in both LERs and LSRs. >=20 > The basic idea is to transport Timing messages inside dedicated MPLS > LSPs. These LSPs only carry Timing messages and possibly Control and > Management packets, but they do not carry customer traffic. >=20 > SB> More specifically they only carry traffic associated with the > SB> timing service and its support. > SB> The question arose WRT BFD - surely BFD is allowed, BUT surely > SB> also it gets carried in a structure that causes it to get > SB> timestamped. >=20 > Two methods for transporting Timing messages over MPLS are defined. >=20 > SB> Perhaps the right approach is to define the new LSP type and then > SB> seperately to define the mapping of the various timing services > SB> over that LSP type. >=20 > The first method is to transport Timing messages directly over the > dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for > MPLS networks. The second method is to transport Timing messages > inside a PW via Ethernet encapsulation. >=20 > SB> I think that we should note that there are some > SB> h/w reasons for this preference. A clean sheet approach > SB> would have been to use PTP over MPLS with no intermediate > SB> layers. >=20 > Status of this Memo >=20 > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. >=20 > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." >=20 > This Internet-Draft will expire on December 17, 2013. >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 1] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > Copyright Notice >=20 > Copyright (c) 2013 IETF Trust and the persons identified as the > document authors. All rights reserved. >=20 > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. >=20 >=20 > Table of Contents >=20 > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 >=20 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 >=20 > 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 >=20 > 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . 9 >=20 > 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . . 12 >=20 > 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . 13 > 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . . 13 > 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . . 13 > 6.3. Other Timing Encapsulation methods . . . . . . . . . . . . 14 >=20 > 7. Timing message Processing . . . . . . . . . . . . . . . . . . 15 >=20 > 8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 16 >=20 > 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 >=20 > 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 >=20 > 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 >=20 > 12. OAM, Control and Management . . . . . . . . . . . . . . . . . 20 >=20 > 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 21 >=20 > 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . . 22 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 2] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 23 > 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . . 23 > 15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . . 23 > 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . . 24 >=20 > 16. Other considerations . . . . . . . . . . . . . . . . . . . . . 25 >=20 > 17. Security Considerations . . . . . . . . . . . . . . . . . . . 26 >=20 > 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 >=20 > 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 >=20 > 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 > 20.1. Normative References . . . . . . . . . . . . . . . . . . . 29 > 20.2. Informative References . . . . . . . . . . . . . . . . . . 29 >=20 > Appendix 1. Routing extensions for Timing-aware Routers . . . . . 32 >=20 > Appendix 2. Signaling Extensions for Creating Timing LSPs . . . . 33 >=20 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 3] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC2119 [RFC2119]. >=20 > When used in lower case, these words convey their typical use in > common language, and are not to be interpreted as described in > RFC2119 [RFC2119]. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 4] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 1. Introduction >=20 > The objective of Precision Time Protocol (PTP) and Network Timing > Protocol (NTP) are to synchronize independent clocks running on > separate nodes of a distributed system. >=20 > [IEEE-1588] defines PTP messages for frequency, phase and time > synchronization. The PTP messages include PTP PDUs over UDP/IP > (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex F of > [IEEE-1588]). >=20 > SB> Sure BUT it is acknowledged that IEEE is open to the definition > SB> of other PTP mappings if they provide better optimisation. >=20 > This document defines mapping and transport of the PTP > messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP > defines several clock types: ordinary clocks, boundary clocks, end- > to-end transparent clocks, and peer-to-peer transparent clocks. > Transparent clocks require intermediate nodes to update correction > field inside PTP message that reflects the transit time in the node. >=20 > [RFC5905] defines NTP messages for clock and time synchronization. > The PTP messages (PDUs) are transported over UDP/IP. This document > SB> Should that be NTP messages? > SB> It needs to be made clear as soon as you introduce NTP that > SB> they use different time representations. >=20 > defines mapping and transport of the NTP messages defined in > [RFC5905] over MPLS networks. >=20 > One key attribute of all of these Timing messages is that the Time > stamp processing should occur as close as possible to the actual > transmission and reception at the physical port interface. This > targets optimal time and/or frequency recovery by avoiding variable > delay introduced by queues internal to the clocks. >=20 > SB> As I recall NTP has no epoch point defined, and I am not sure > SB> where that point is in the case of PTP in this mapping > SB> Hopefully this will get defined in due course. >=20 > To facilitate the fast and efficient recognition of Timing messages > at the port level when the Timing messages are carried over MPLS > LSPs, >=20 > SB> Over a new LSP type with time optimied characteristics >=20 > this document defines the specific encapsulations that should > be used. > SB> Hopefully it will also define the PHP >=20 > In addition, it can be expected that there will exist LSR/ > LERs where only a subset of the physical ports will have the port- > based Timing message processing capabilities. > SB> Do you need to clarify that this only works at base and not in > SB> a label heirarchy. >=20 >=20 > In order to ensure > that the LSPs carrying Timing packets always enter and exit ports > with this capability, routing extensions are defined to advertise > this capability on a port basis and to allow for the establishment of > LSPs that only transit such ports. While this path establishment > restriction may be applied only at the LER Ingress and/or egress > ports, it becomes more important when using transparent clock capable > LSRs in the path. > SB> I do not understand the implications of the last > SB> sentences - starting ", it becomes" >=20 >=20 > Port based Timing message processing involves Timing message > recognition. Once the Timing messages are recognized they can be > modified based on the reception or transmission Time-stamp. >=20 > This document provides two methods for transporting Timing messages > over MPLS. One is applicable to MPLS environment and the other one > is applicable to MPLS/MPLS-TP environment >=20 > SB> I think the sentence is incomplete. >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 5] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > The solution involves transporting Timing messages over dedicated > LSPs called Timing LSPs. These LSPs carry Timing messages and MAY > carry Management and control messages, but not data plane client > traffic. >=20 > SB> It is not clear why this restriction applies. >=20 > Timing LSPs can be established statically or via signaling. > SB> s/statically/by provisioning/network management/ >=20 > Extensions to control plane (OSPF, ISIS, etc.) is required to enable > routers to distribute their Timing processing capabilities over MPLS > to other routers. However such extensions are outside the scope of > this document. >=20 > When signaling is used to setup the PTP LSP, Extensions to signaling > SB> is it a PTP LSP or a Timing LSP? >=20 > protocols (e.g., RSVP-TE) are required for establishing PTP LSPs. > However such extensions are outside the scope of this document. >=20 > SB> for mpls-tp GMPLS is the signalling protocol >=20 > While the techniques included herein allow for the establishment of > paths optimized to include Time-stamping capable links, the > performance of the Slave clocks is outside the scope of this > document. >=20 > At the time of publishing this specification, Transparent Clocking > (TC) is only defined for PTP. Therefore at this time any part of > this specification that talks about Transparent Clocking applies only > to PTP. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 6] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 2. Terminology >=20 > 1588: The timing and synchronization as defined by IEEE 1588. >=20 > SB> I think that there is a more formal name for the 1588 group > SB> that needs to be used here. > SB> Also do we need to talk about 1588-200? as there is > SB> an update in progress >=20 > NTP: The timing and synchronization protocol defined by IETF RFC-1305 > and RFC-5905. >=20 > PTP: The timing and synchronization protocol used by 1588. > SB> need the proper name for 1588 >=20 > Master Clock: The source of 1588 timing to a set of slave clocks. >=20 > Master Port: A port on a ordinary or boundary clock that is in Master > state. This is the source of timing toward slave ports. >=20 > SB> I am not sure the reader knows what a port is >=20 > Slave Clock: A receiver of 1588 timing from a master clock. >=20 > Slave Port: A port on a boundary clock or ordinary clock that is > receiving timing from a master clock. >=20 > Ordinary Clock: A device with a single PTP port. >=20 > Transparent Clock. A device that measures the time taken for a PTP > event message to transit the device and then updates the > correctionField of the message with this transit time. >=20 > Boundary Clock: A device with more than one PTP port. Generally > boundary clocks will have one port in slave state to receive timing > and then other ports in master state to re-distribute the timing. >=20 > PTP LSP: An LSP dedicated to carry PTP messages >=20 > SB> PTP or timing? >=20 >=20 > PTP PW: A PW within a PTP LSP that is dedicated to carry PTP > messages. >=20 > SB> Ah I don't think that PWE3 know what one of these is >=20 > CW: Pseudowire Control Word >=20 > LAG: Link Aggregation >=20 > ECMP: Equal Cost Multipath >=20 > CF: Correction Field, a field inside certain PTP messages (message > type 0-3)that holds the accumulative transit time inside intermediate > switches >=20 > Timing messages: Timing Protocol messages that are exchanged between > routers in order to establish a synchronized clock. >=20 > SB> A number of these definitions look like copies of IEEE1588 > SB> definitions. We need to provide references and note the > SB> priority of the IEEE base reference. >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 7] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 3. Problem Statement >=20 > [IEEE-1588] has defined methods for transporting PTP messages over > Ethernet and IP networks. [RFC5905] has defined the method of > transporting NTP messages over IP networks. There is a need to > transport Timing messages over MPLS networks while supporting the > Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC) > functionality in the LER and LSRs in the MPLS network. >=20 > There are multiple ways of transporting Timing over MPLS. However, > there is a requirement to limit the possible encapsulation options to > simplify the Timing message identification and processing required at > the port level. >=20 > When Timing-awareness is needed, Timing messages should not be > transported over LSPs or PWs that are carrying customer traffic > because LSRs perform Label switching based on the top label in the > stack. >=20 > SB> Have you explained why? >=20 > To detect Timing messages inside such LSPs require special > hardware to do deep packet inspection at line rate. Even if such > hardware exists, the payload can't be deterministically identified by > LSRs because the payload type is a context of the PW label, and the > PW label and its context are only known to the Edge routers (PEs/ > LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, CES, > etc). Even if one restricts an LSP to only carry Ethernet PWs, the > LSRs dont have the knowledge of whether PW Control Word (CW) is > present or not and therefore can not deterministically identify the > payload. >=20 > A generic method is defined in this document that does not require > deep packet inspection at line rate, and can deterministically > identify Timing messages. This method can be used to detect Timing > Messages in both one-step and two-step clock implementations of > ordinary, boundary and transparent clocks. >=20 > SB> Needs a ref and I am sure many MPLS specialists will not understand > SB> the msg types. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 8] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 4. Timing over MPLS Architecture >=20 > Timing messages are exchange between Timing ports on ordinary and >=20 > SB> Have you defined a timing port? >=20 > boundary clocks. Boundary clocks terminate the Timing messages and > act as master for other boundary clocks or for slave clocks. End-to- > End Transparent clocks do not terminate the Timing messages but they > do modify the contents of the Timing messages as they transit across > the transparent clock. >=20 > Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent Clock >=20 > (TC) could be implemented in either LERs or LSRs. >=20 > SB> LER and LSR need to be expanded >=20 > An example is shown in Figure 1, where the LERs act as Ordinary Clock > (OC) and are the initiating/terminating point for Timing messages. > The ingress LER encapsulates the Timing messages in Timing LSP and > the Egress LER terminates the Timing LSP. The LSRs act as > Transparent Clock (TC) and just update the Timing field in the Timing > messages. >=20 >=20 > +--------+ +-------+ +-------+ +-------+ +--------+ > |Switch, | | | | | | | |Switch, | > | Router |-----| LER |-----| LSR |-----| LER |-----| Router | > | | | OC | | TC | | OC | | | > +--------+ +-------+ +-------+ +-------+ +--------+ > / \ > +-------+ / \ +-------+ > | LER | / \ | LER | > | Master|---/ \---| Slave | > | Clock | | Clock | > +-------+ +-------+ >=20 > Figure (1) - Deployment example 1 of timing over MPLS network >=20 > Another example is shown in Figure2, where LERs terminate the Timing > messages received from switch/routers that are outside of the MPLS > network acting as OC or BC. In this example LERs regenerate the > clock and initiate timing messages encapsulated in Timing LSP toward > the MPLS network, while the LSRs act as Transparent Clock (TC) and > just update the Timing field in the Timing messages, which are > already encapsulated in Timing LSPs. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 9] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > +--------+ +-------+ +-------+ +-------+ +--------+ > |Switch, | | | | | | | |Switch, | > | Router |-----| LER |-----| LSR |-----| LER |-----| Router | > | OC/BC | | BC | | TC | | BC | | OC/BC | > +--------+ +-------+ +-------+ +-------+ +--------+ >=20 > Figure (2) - Deployment example 2 of timing over MPLS network >=20 >=20 > Another example is shown in Figure 3, where LERs do not terminate the > Timing messages received from switch/routers that are outside of the > MPLS network acting as OC, TC or BC. The LERs act as TC and update > the Timing field in the Timing messages as they transit the LER, > while encapsulating them in timing LSP. The LSRs also act as > Transparent Clock (TC) and just update the Timing field in the Timing > messages which are already encapsulated in Timing LSPs. >=20 > +--------+ +-------+ +-------+ +-------+ +--------+ > |Switch, | | | | | | | |Switch, | > | Router |-----| LER |-----| LSR |-----| LER |-----| Router | > |OC/TC/BC| | TC | | TC | | TC | |OC/TC/BC| > +--------+ +-------+ +-------+ +-------+ +--------+ >=20 > Figure (3) - Deployment example 3 of timing over MPLS network >=20 > Another example is shown in Figure 4, where LERs and LSRs support > Boundary Clocks. A single-hop LSP is created between two adjacent > LSRs engaged in BC operation. Other methods such as PTP transport > over Ethernet MAY be used for transporting timing messages if the > link between the two routers is Ethernet. >=20 > +--------+ +-------+ +-------+ +-------+ +--------+ > |Switch, | | | | | | | |Switch, | > | Router |-----| LER |-----| LSR |-----| LER |-----| Router | > | OC/BC | | BC | | BC | | BC | | OC/BC | > +--------+ +-------+ +-------+ +-------+ +--------+ >=20 > Figure (4) - Deployment example 3 of timing over MPLS network >=20 > An MPLS domain MAY serve multiple customers. In these cases the MPLS > domain (maintained by a service provider) may provide timing services > to multiple customers, each having their own Timing domain. >=20 > The Timing over MPLS architecture assumes full mesh of Timing LSPs > between all LERs supporting this specification. >=20 > SB> Note sure this is right - the salves surely do not need to > SB> exchange timing amongst themselves >=20 > It supports > Point-to- point (VPWS) and Multipoint (VPLS) services. >=20 > SB> What does that mean? You do not carry user data traffic? > SB> Maybe it's the ordering of the statemnets that is causing > SB> confusion. >=20 > This means > that a customer may purchase a Point-to-point Timing service between > two customer sites or a Multipoint Timing service between more than >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 10] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > two customer sites. >=20 > The Timing over MPLS architecture supports P2P or P2MP Timing LSPs. > This means that the Timing Multicast messages such as PTP Multicast > event messages can be transported over P2MP Timing LSP or be > replicated and transported over many P2P Timing LSPs. >=20 > SB> Note we do not yet have a definition of a P2MP mpls-tp LSP > SB> nor a P2MP PW, although we are close. >=20 > Timing messages, that do not require Time stamping or Correction > Field update MAY be transported over Timing LSPs to simplify hardware > and software. >=20 > PTP Announce messages that determine the Timing LSP terminating point > behavior such as BC/OC/TC SHOULD be transported over the Timing LSP > to simplify hardware and software. >=20 > SB> have you defined and referenced PTP announce msgs? >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 11] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 5. Dedicated LSPs for Timing messages >=20 > Many methods have been considered for identifying the Timing messages > when they are encapsulated in MPLS such as using GAL/G-ACH or a new > reserved label. These methods were not attractive since they either > required deep packet inspection at line rate in the intermediate LSRs > or they required use of a scarce new reserved label. Also one of the > goals was to reuse existing OAM mechanisms. >=20 > SB> RLs =3D SPLs are not so rare now. In any case needs a ref. >=20 > The method defined in this document can be used by LER and LSRs to > identify Timing messages in MPLS tunnels by just looking at the top > label in the MPLS label stack, which only carry Timing messages as > well as OAM, but not data plane client traffic. >=20 > Compliant implementations MUST use dedicated LSPs to carry Timing > messages over MPLS. >=20 > SB> I think that we need a definition of the properies of these LSPs >=20 > These LSPs are herein referred to as "Timing > LSPs" and the labels associated with these LSPs as "Timing LSP > labels". The Timing LSPs that runs between Ingress and Egress LERs > MUST be co-routed. Alternatively, a single bidirectional co-routed > LSP can be used. >=20 > SB> I though that you said you could use M2MP LSPs - these are not > SB> bidirectional. >=20 > Co-routing of the two directions is required to limit the difference > in the delays in the Master clock to Slave clock direction compared > to the Slave clock to Master clock direction. The Timing LSP MAY be > MPLS/MPLS-TP LSP. >=20 > The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS. > New Extensions to RSVP-TE/GMPLS TLVs are required; however they are > outside the scope of this document. >=20 > The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such as > BFD and LSP Ping but the LSP data plane client plane traffic MUST be > Timing packets only. >=20 > SB> Why? >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 12] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 6. Timing over LSP Encapsulation >=20 > The encapsulations is not LSP is it? >=20 > This document defines two methods for carrying Timing messages over > MPLS. The first method is carrying UDP/IP encapsulated Timing > messages over Timing LSPs, and the second method, is carrying > Ethernet encapsulated Timing messages over Ethernet PWs inside Timing > LSPs. >=20 > 6.1. Timing over UDP/IP over MPLS Encapsulation >=20 > The simplest method of transporting Timing messages over MPLS is to > encapsulate Timing PDUs in UDP/IP and then encapsulate them in Timing > LSP. This format is shown in Figure 4. >=20 >=20 > +----------------------+ > | Timing LSP Label | > +----------------------+ > | IPv4/6 | > +----------------------+ > | UDP | > +----------------------+ > | Timing PDU | > +----------------------+ >=20 > Figure (4) - Timing over UDP/IP over MPLS Encapsulation >=20 >=20 > This encapsulation is very simple and is useful when the network > between Timing Master Clock and Slave Clock is MPLS network. >=20 > SB> Simple is a judgement call >=20 > In order for an LER/LSR to process Timing messages, the Timing LSP > Label must be at the top label of the label stack. The LER/LSR MUST > know that the Timing LSP Label is used for carrying Timing messages. > This can be accomplished via static configuration or via RSVP-TE > signaling. >=20 > The UDP/IP encapsulation of PTP MUST follow Annex D and E of > [IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow > [RFC5905]. >=20 > 6.2. Timing over PW Encapsulation >=20 > Another method of transporting Timing over MPLS networks is by > encapsulating Timing PDUs in PW which in turn is transported over > Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448], > shown in Fig 5(A) MUST be used and the Ethernet encapsulation of PTP > MUST follow Annex F of [IEEE-1588]. >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 13] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > The RAW mode or Tagged mode defined in [RFC4448] MAY be used and the > Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The > Timing over PW encapsulation MUST use the Control Word (CW) as > specified in [RFC4448] to ensure proper detection of PTP messages > inside the MPLS packets for Timing over LSP and Timing over PW > encapsulation. >=20 > SB> That needs explanation >=20 > The use of Sequence Number in the CW is optional. >=20 > SB> Given that s/n are never in practice deployed, you could probably > SB> simplify things by sayig that they are not used. >=20 > Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over PW > (the IP PW discussed in [RFC4447]) shown in Fig 5(B). >=20 > +----------------+ +----------------+ > |Timing LSP Label| |Timing LSP Label| > +----------------+ +----------------+ > | PW Label | | PW Label | > +----------------+ +----------------+ > | Control Word | | IP | > +----------------+ +----------------+ > | Ethernet | | UDP | > | Header | +----------------+ > +----------------+ | Timing PDU | > |S-VLAN(Optional)| | | > +----------------+ +----------------+ > |C-VLAN(Optional)| (B) > +----------------+ > | Timing PDU | > | | > +----------------+ > (A) >=20 > Figure (5) - Timing over PW Encapsulations >=20 > In order for an LSR to process PTP messages, the top label of the > label stack (the Tunnel Label) MUST be a Timing label. >=20 > S> You said that before. >=20 > 6.3. Other Timing Encapsulation methods >=20 > In future other timing encapsulation methods may be introduced, such > as a new shim header after the Bottom of Stack to carry the Timing > information. Such new encapsulations are outside the scope of this > document. >=20 >=20 > SB> Taking a pure MPLS pov, you can simplify a lot of the text > SB> out of the definition of the LSP >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 14] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > SB> I think we need a section on LSP processing >=20 > 7. Timing message Processing >=20 > Each Timing protocol such as PTP and NTP, define their set of Timing > messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, > FOLLOW_UP, etc messages. >=20 > Some of the Timing messages require time stamping or correction field > update at port level and some dont. It is the job of the LER/LSR to > parse the timing message and find out the type of the Timing message > and decide whether and how to Time- stamp it (e.g., BC) or update > correction field(e.g., TC). >=20 >=20 > SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing > SB> function rather than the LER? >=20 > For example the following PTP messages (called Event messages) > require time-stamping or correction field update: >=20 > o SYNC >=20 > o DELAY_REQ (Delay Request) >=20 > o PDELAY_REQ (Peer Delay Request) >=20 > o PDELAY_RESP (Peer Delay Response) >=20 > SYNC and DELAY_REQ are exchanged between Master Clock and Slave Clock > and MUST be transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP > are exchanged between adjacent PTP clocks (i.e. Master, Slave, > Boundary, or Transparent) and SHOULD be transported over single hop > PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP, > and PDELAY_RESP_FOLLOW_UP messages MUST also be transported over the > PTP LSPs. >=20 > For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be > transported over two PTP LSPs that are in opposite directions. These > PTP LSPs, which are in opposite directions MUST be congruent and co- > routed. Alternatively, a single bidirectional co-routed LSP can be > used. >=20 > Except as indicated above for the two-step PTP clocks, Non-Event PTP > message types do not need to be processed by intermediate routers. > These message types MAY be carried in PTP Tunnel LSPs. >=20 > SB> Are you saying that a timing P router has to be msg type sensitive? >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 15] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 8. Protection and Redundancy >=20 >=20 > SB> This is a bit of a jump - I don't know how the LSP itself works yet! >=20 > In order to ensure continuous uninterrupted operation of slave > clocks, usually as a general practice, slave clocks (or ports) track > redundant master clocks. >=20 > It is the responsibility of the network operator to ensure that > physically disjoint Timing LSPs are established between a slave clock > (or port) and redundant master clocks (or ports). >=20 > When a slave clock (or port) listens to redundant master clocks or > ports, any prolonged Timing LSP outage will trigger the slave clock > or port to switch to a redundant master clock or port. >=20 > LSP/PW protection such as Linear protection Switching (1:1, 1+1), > Ring protection switching or MPLS Fast Reroute (FRR) generally switch > alternative path that usually cause a change in delay, which if > undetected by slave clock can reduce accuracy of the slave clock. >=20 > Therefore protection switching MAY be used, as long as phase jumps > upon switchover due to differences in path latency are detected and > compensated for (such compensation not being required if BCs or peer- > peer TCs are used throughout). >=20 > Note that any protection or reroute mechanism that adds additional > MPLS label to the label stack, such as Facility Backup Fast Reroute, > MUST ensure that the pushed label is also a Timing Label to ensure > recognition of the MPLS frame as containing Timing messages, as it > transits the backup path. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 16] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 9. ECMP >=20 > To ensure the optimal operation of slave clocks and avoid error > introduced by forward and reverse path delay asymmetry, the physical > path for Timing messages from master clock to slave Clock and vice > versa must be the same for all Event Timing messages listed in > section 7. >=20 > Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost > Multipath). >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 17] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 10. PHP >=20 > To ensure that the label on the top of the label stack is the Timing > LSP Label, PHP MUST not be used. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 18] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 11. Entropy >=20 > To ensure all Timing messages in a Timing LSP take the same path, > Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and > Entropy Label MUST NOT be used for the PWs that are carried inside > Timing LSP [RFC6391]. >=20 > SB> This is incorrect - you mean that all msgs of the same timing > SB> flow need to have the same EL value. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 19] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 12. OAM, Control and Management >=20 > In order to monitor Timing LSPs and their encapsulated PWs, they MUST > be able to carry OAM and management messages. These management > messages MUST be differentiated from Timing messages via already > defined IETF methods. >=20 > For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY run > over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These > Management protocols can easily be identified by the UDP Destination > Port number or by GAL/G-ACH respectively. >=20 > Also BFD, LSP-Ping and other management messages MAY run over the PWs > encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3 or > 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is going > to be deprecated by IETF). In this case G-ACH, PW label (TTL=3D1) or > GAL-ACH are used to identify such management messages. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 20] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 13. QoS Considerations >=20 > In network deployments where not every LSR/LER is Timing-aware, it is > important to reduce the impact of the non-Timing-aware LSR/LERs on > the timing recovery in the slave clock. The Timing messages are time > critical and must be treated with the highest priority. Therefore > Timing over MPLS messages must be treated with the highest priority > in the routers. This can be achieved by proper setup of Timing LSPs. >=20 > It is recommended that the Timing LSPs are setup or configured > properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC2697] > for drop eligibility. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 21] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 14. FCS and Checksum Recalculation >=20 > When time-stamp generation and timing packet adjustment is performed > near the physical port hardware, the process MUST include > recalculation of the Ethernet FCS. >=20 > SB> The above is confusing - an LSR always recomputes the link layer > SB> CRC which may or may not be Ethernet. >=20 > Also FCS retention for the > payload Ethernet described in [RFC4720] MUST NOT be used. >=20 > For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum > may be required as per UDP transport standards. >=20 > SB> You really need to be working on getting the IPv6 C?S computation > SB> removed from PTP msgs. >=20 > When UDP checksum is used, each Timing-aware LER/LSR must either > incrementally update the UDP checksum after Time stamping or > Correction Field update or verify the UDP checksum on reception from > upstream and recalculate the checksum completely on transmission to > downstream node after Time stamping or Correction Field update. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 22] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 15. Behavior of LER/LSR >=20 > Timing-capable/aware LERs and LSRs are routers that have one or more >=20 > SB> You mean physical interfaces? >=20 > interfaces that can perform Timing operations (OC/BC/TC) on Timing > packets and are configured to do so. Timing-capable/aware LERs and > LSRs can advertise their Timing-capability per-interface via control > plane such as OSPF or IS-IS. > SB> ISIS and OSPF are routing protocols. >=20 > The Timing-capable/aware LERs can then > signals Timing LSPs via RSVP-TE signaling. Alternatively the Timing > capability of LER and LSRs may be configured in a centralized > controller and the Timing LSP may be setup using manual configuration > or other methods such as SDN. >=20 > SB> it can also be configured individually rather then through > SB> a cebtral controllwe >=20 > 15.1. Behavior of Timing-capable/aware LER >=20 > When a Timing-capable/aware LER behaves as a Transparent clock and > receives a Timing message from a Timing-capable/aware non-MPLS > interface, the LER updates the Correction Field (CF) and encapsulates > and forwards the timing message over previously established Timing > LSP. >=20 > SB> You need to call out the details so that people properly > SB> understand the definition of the new LSP. >=20 > Also when a Timing message is received from a Timing-capable/ > aware MPLS interface, LER updates the Correction Filed (CF) and > decapsulates the MPLS encapsulation and forwards the timing message > to a non-MPLS interface. >=20 > When a Timing-capable/aware LER behaves as a Boundary clock and > receives a Timing message from a Timing-capable/aware non MPLS > interface, the LER Timestamps the Timing packet and sends it to the > LERs Boundary clock processing module. Also when a Timing message is > received from a Timing- capable/aware MPLS interface, the LER > Timestamps the Timing packet and sends it to the LERs Boundary clock > processing module. >=20 > When a Timing-capable/aware LER behaves as an Ordinary Clock toward > the MPLS network, and receives a Timing message from a Timing- > capable/aware MPLS interface, the LER Timestamps the Timing packet > and sends it to the LERs Ordinary clock processing module. >=20 > 15.2. Behavior of Timing-capable/aware LSR >=20 > When a Timing-capable/aware LSR behaves as a Transparent clock and > receives a Timing message from a Timing-capable/aware MPLS interface, > The LSR updates the Correction Filed (CF) and forwards the timing > message over another MPLS interface. >=20 > When a Timing-capable/aware LSR behaves as a Boundary clock and > receives a Timing message from a Timing-capable/aware MPLS interface. > The LSR performs the functions of a Boundary Clock in terminating the > received Timing message and re-generating a new timing message over > another (or the same) MPLS interface. >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 23] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 15.3. Behavior of non-Timing-capable/aware LSR >=20 > It is most beneficial when all LSRs in the path of a Timing LSP be > timing-Capable/aware LSRs. This would ensure the highest quality > time and clock synchronization by Timing Slave Clocks. However, this > specification does not mandate that all LSRs in path of a Timing LSP > be Timing- capable/aware. >=20 > Non-Timing-capable/aware LSRs just switch the packets encapsulated in > Timing LSPs and dont perform any Timing operation (TC or BC). > However as explained in QoS section the Timing over MPLS packets MUST > be still be treated with the highest priority based on their Traffic > Class (TC) marking. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 24] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 16. Other considerations >=20 > [IEEE-1588] defines an optional peer-to-peer Transparent clocking > that requires peer delay measurement between two adjacent Timing- > capable/ aware routers/switches. Peer delay measurement messages > need to be time stamped and terminated by the Timing-capable/aware > routers/ switches. This means that two adjacent LSRs may be engaged > in a peer delay measurement. >=20 > For transporting such peer delay measurement messages a single-hop > LSP SHOULD to be created between the two adjacent LSRs engaged in > peer delay measurement to carry peer delay measurement messages. > Other methods such as PTP transport over Ethernet MAY be used for > transporting peer delay measurement messages if the link between the > two routers is Ethernet. >=20 > In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ ware > routers/switches MUST maintain a list of all the neighbors it needs > to send a PDelay_Req to, where each neighbor corresponds to a timing > LSP. >=20 > The use of Explicit Null Label (Label=3D 0 or 2) is acceptable as long > as either the Explicit Null label is the bottom of stack label > (applicable only to UDP/IP encapsulation) or the label below the > Explicit Null label is a PTP label. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 25] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 17. Security Considerations >=20 > MPLS PW security considerations in general are discussed in [RFC3985] > and [RFC4447],and those considerations also apply to this document. >=20 > An experimental security protocol is defined in [IEEE-1588].The PTP > security extension and protocol provides group source authentication, > message integrity, and replay attack protection for PTP messages. >=20 > When the MPLS network (provider network) serves multiple customers, > it is important to maintain and process each customers clock and > Timing messages separately from other customers to ensure there is no > cross- customer effect. For example if an LER BC is synchronized to > a specific grandmaster, belonging to customer A, then the LER MUST > use that BC clock only for customer A to ensure that customer A > cannot attack other customers by manipulating its time. >=20 > Timing messages MAY be encrypted or authenticated, provided that the > LERs/LSRs that are Timing capable/aware can authenticate/ decrypt the > timing messages. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 26] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 18. Acknowledgements >=20 > The authors would like to thank Ron Cohen, Yaakov Stein, Tal Mizrahi, > Stefano Ruffini, Peter Meyer, and other members of IETF for reviewing > and providing feedback on this draft. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 27] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 19. IANA Considerations >=20 > There are no IANA requirements in this specification. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 28] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 20. References >=20 > 20.1. Normative References >=20 > [IEEE-1588] > IEEE 1588-2008, "IEEE Standard for a Precision Clock > Synchronization Protocol for Networked Measurement and > Control Systems". >=20 > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. >=20 > [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- > Edge (PWE3) Architecture", RFC 3985, March 2005. >=20 > [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery > Proxies (ND Proxy)", RFC 4389, April 2006. >=20 > [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. > Heron, "Pseudowire Setup and Maintenance Using the Label > Distribution Protocol (LDP)", RFC 4447, April 2006. >=20 > [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, > "Encapsulation Methods for Transport of Ethernet over MPLS > Networks", RFC 4448, April 2006. >=20 > [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire > Emulation Edge-to-Edge (PWE3) Frame Check Sequence > Retention", RFC 4720, November 2006. >=20 > [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit > Connectivity Verification (VCCV): A Control Channel for > Pseudowires", RFC 5085, December 2007. >=20 > [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection > (BFD)", RFC 5880, June 2010. >=20 > [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, > "Bidirectional Forwarding Detection (BFD) for MPLS Label > Switched Paths (LSPs)", RFC 5884, June 2010. >=20 > 20.2. Informative References >=20 > [I-D.ietf-pwe3-fat-pw] > Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, > J., and S. Amante, "Flow Aware Transport of Pseudowires > over an MPLS Packet Switched Network", > draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011. >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 29] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate > system routeing information exchange protocol for use in > conjunction with the Protocol for providing the > Connectionless-mode Network Service (ISO 8473)". >=20 > [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and > dual environments", RFC 1195, December 1990. >=20 > [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. >=20 > [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color > Marker", RFC 2697, September 1999. >=20 > [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, > J., Courtney, W., Davari, S., Firoiu, V., and D. > Stiliadis, "An Expedited Forwarding PHB (Per-Hop > Behavior)", RFC 3246, March 2002. >=20 > [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering > (TE) Extensions to OSPF Version 2", RFC 3630, > September 2003. >=20 > [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate > System (IS-IS) Extensions for Traffic Engineering (TE)", > RFC 3784, June 2004. >=20 > [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. > Shaffer, "Extensions to OSPF for Advertising Optional > Router Capabilities", RFC 4970, July 2007. >=20 > [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate > System to Intermediate System (IS-IS) Extensions for > Advertising Router Information", RFC 4971, July 2007. >=20 > [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi > Topology (MT) Routing in Intermediate System to > Intermediate Systems (IS-ISs)", RFC 5120, February 2008. >=20 > [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic > Engineering", RFC 5305, October 2008. >=20 > [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, > "Traffic Engineering Extensions to OSPF Version 3", > RFC 5329, September 2008. >=20 > [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF > for IPv6", RFC 5340, July 2008. >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 30] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network > Time Protocol Version 4: Protocol and Algorithms > Specification", RFC 5905, June 2010. >=20 > [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, > J., and S. Amante, "Flow-Aware Transport of Pseudowires > over an MPLS Packet Switched Network", RFC 6391, > November 2011. >=20 > [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and > L. Yong, "The Use of Entropy Labels in MPLS Forwarding", > RFC 6790, November 2012. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 31] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 1. Routing extensions for Timing-aware Routers >=20 > MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and > IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE) > link information used for constraint-based routing. >=20 > Indeed, it is useful to advertise data plane TE router link > capabilities, such as the capability for a router to be Timing-aware. > This capability MUST then be taken into account during path > computation to prefer or even require links that advertise themselves > as Timing-aware. In this way the path can ensure the entry and exit > points into the LERs and, if desired, the links into the LSRs are > able to perform port based time-stamping thus minimizing their impact > on the performance of the slave clock. >=20 > extensions are required to OSPF and IS-IS in order to advertise > Timing-aware capabilities of a link. Such extensions are outside the > scope of this document; however such extension SHOULD be able to > signal the following information per Router Link: >=20 > o Capable of processing PTP, NTP or other Timing flows >=20 > o Capable of performing Transparent Clock operation >=20 > o Capable of performing Boundary Clock operation >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 32] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > 2. Signaling Extensions for Creating Timing LSPs >=20 > RSVP-TE signaling MAY be used to setup the timing LSPs. When RSVP-TE > is used to setup Timing LSPs, some information that indicates that > the LSP is carrying Timing flows MUST be included in the new > Extensions to RSVP-TE: >=20 > The following information MAY also be included in the new Extensions > to RSVP-TE: >=20 > o Offset from Bottom of Stack (BoS) to the start of the Time-stamp > field >=20 > o Number of VLANs in case of PW encapsulation >=20 > o Timestamp field Type >=20 > * Correction Field, Timestamp >=20 > o Timestamp Field format >=20 > * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit > NTP, etc. >=20 > Note that in case the above optional information is signaled with > RSVP-TE for a Timing LSP, all the Timing packets carried in that LSP > must have the same signaled characteristics. For example if > Timestamp format is signaled as 64-bit PTPv1, then all Timing packets > must use 64-bit PTPv1 time-stamp. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 33] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > Authors' Addresses >=20 > Shahram Davari > Broadcom Corp. > San Jose, CA 95134 > USA >=20 > Email: davari@broadcom.com >=20 >=20 > Amit Oren > Broadcom Corp. > San Jose, CA 95134 > USA >=20 > Email: amito@broadcom.com >=20 >=20 > Manav Bhatia > Alcatel-Lucent > Bangalore, > India >=20 > Email: manav.bhatia@alcatel-lucent.com >=20 >=20 > Peter Roberts > Alcatel-Lucent > Kanata, > Canada >=20 > Email: peter.roberts@alcatel-lucent.com >=20 >=20 > Laurent Montini > Cisco Systems > San Jose CA > USA >=20 > Email: lmontini@cisco.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 34] > =0C > Internet-Draft Transporting Timing over MPLS June 2013 >=20 >=20 > Luca > Cisco Systems > San Jose CA > USA >=20 > Email: lmartini@cisco.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Davari, et al. Expires December 17, 2013 [Page 35] > =0C >=20 > --=20 > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From jdrake@juniper.net Fri Aug 2 03:52:23 2013 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 A99F311E8241; Fri, 2 Aug 2013 03:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.533 X-Spam-Level: * X-Spam-Status: No, score=1.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] 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 hVBUASLshY42; Fri, 2 Aug 2013 03:52:13 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 2585711E8210; Fri, 2 Aug 2013 03:52:12 -0700 (PDT) Received: from mail13-am1-R.bigfish.com (10.3.201.244) by AM1EHSOBE019.bigfish.com (10.3.207.141) with Microsoft SMTP Server id 14.1.225.22; Fri, 2 Aug 2013 10:52:11 +0000 Received: from mail13-am1 (localhost [127.0.0.1]) by mail13-am1-R.bigfish.com (Postfix) with ESMTP id 094911A00F5; Fri, 2 Aug 2013 10:52:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VPS-30(zz62a3I98dI9371I601I542Iec9I1432I1418I168aJzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de096h8275bh8275dh1de097hz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail13-am1: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=jdrake@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail13-am1 (localhost.localdomain [127.0.0.1]) by mail13-am1 (MessageSwitch) id 137544072793821_1236; Fri, 2 Aug 2013 10:52:07 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.228]) by mail13-am1.bigfish.com (Postfix) with ESMTP id 12E283C0046; Fri, 2 Aug 2013 10:52:07 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.54) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 2 Aug 2013 10:52:06 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF01-SAC.jnpr.net (172.24.192.17) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 2 Aug 2013 03:52:04 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Fri, 2 Aug 2013 03:52:04 -0700 Received: from DB8EHSOBE022.bigfish.com (213.199.154.187) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 2 Aug 2013 04:04:59 -0700 Received: from mail83-db8-R.bigfish.com (10.174.8.239) by DB8EHSOBE022.bigfish.com (10.174.4.85) with Microsoft SMTP Server id 14.1.225.22; Fri, 2 Aug 2013 10:52:01 +0000 Received: from mail83-db8 (localhost [127.0.0.1]) by mail83-db8-R.bigfish.com (Postfix) with ESMTP id 347825402B8; Fri, 2 Aug 2013 10:52:01 +0000 (UTC) Received: from mail83-db8 (localhost.localdomain [127.0.0.1]) by mail83-db8 (MessageSwitch) id 1375440705320831_27751; Fri, 2 Aug 2013 10:51:45 +0000 (UTC) Received: from DB8EHSMHS024.bigfish.com (unknown [10.174.8.232]) by mail83-db8.bigfish.com (Postfix) with ESMTP id 3E7CFCC0047; Fri, 2 Aug 2013 10:51:45 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS024.bigfish.com (10.174.4.34) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 2 Aug 2013 10:51:43 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.45]) by BL2PRD0510HT001.namprd05.prod.outlook.com ([10.255.100.36]) with mapi id 14.16.0341.000; Fri, 2 Aug 2013 10:51:42 +0000 From: John E Drake To: Shahram Davari , "" Thread-Topic: [mpls] Comments on draft-ietf-tictoc-1588overmpls Thread-Index: AQHOj2d0A3VaSYY+akqLLdxXI6C3DpmBtd+AgAAHkOA= Date: Fri, 2 Aug 2013 10:51:41 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E2076CBA4@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <51FB8396.9020504@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%BROADCOM.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls@ietf.org" , "tictoc-chairs@tools.ietf.org" , "tictoc@ietf.org" , "draft-ietf-tictoc-1588overmpls@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "int-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Comments on draft-ietf-tictoc-1588overmpls 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, 02 Aug 2013 10:52:24 -0000 Shahram, The LSPs would be between LSRs that are 1588 capable, so they could be one = or more hops. Yours Irrespectively, John > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Friday, August 02, 2013 3:24 AM > To: > Cc: mpls-chairs@tools.ietf.org; tictoc-chairs@tools.ietf.org; int- > ads@tools.ietf.org; rtg-ads@tools.ietf.org; draft-ietf-tictoc- > 1588overmpls@tools.ietf.org; John E Drake; mpls@ietf.org; > tictoc@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-tictoc-1588overmpls >=20 > Hi Stewart >=20 > We have already looked at similar approach. The issue with one hop LSP > is that not all LSRs are 1588 capable. One of the requirements is for > non-1588 capable routers to just switch the packet normally. >=20 > Regards, > Shahram >=20 >=20 > On Aug 2, 2013, at 12:02 PM, "Stewart Bryant" > wrote: >=20 > > Talking to John Drake about this, an alternative general > > model is for the LSP is that it is an LSP that timestamps > > the packet and then passes it to an application associated > > with the LSP at that hop. > > > > This has a lot of merit. > > > > If however we think about it some more we have a > > type of network service chaining going on here and > > so we don't need an LSP per say, because the path > > and instruction can be in the packet. > > > > In other words a general solution to the problem > > is to define an LSP with the properties that the > > packet is passed one hop, timestamped and delivered > > to the associated application. > > > > How this is MPLS construct is used to support time > > tranfer is entirely within the scope of TICTOC, but > > at the MPLS layer we have a clean reusable network > > service. > > > > - Stewart > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > SB> This draft does not seem to provide a precise definition > > SB> the properties of the new LSP type that it wishes to > > SB> define, in particular it does it define the PHB of those > > SB> LSPs, nor the full interaction with the MPLS > > SB> architecture. > > SB> > > SB> I have not tracked TICTOC for a while but I thought that > > SB> the original plan was to define the concept of an offset > > SB> into a packet to do the correction. > > SB> > > SB> It is disappointing that the opportunity was not taken > > SB> to define a timing shim inside the timing LSP so that > > SB> a time correction could be added to any packet such that > > SB> the MPLS system was isolated from the details of the > > SB> complexity of the particular time transfer type. > > > > SB> I think that much more clarify is needed in terms of > > SB> definition of the new LSP type, since it is unclear > > SB> from this text how to implement one. > > SB> > > SB> There are a lot of other MPLS services such as > > SB> LSP ping that need to be considered. > > SB> > > SB> Please see inline for more comments. However these > > SB> comments are made in the context of the text as written > > SB> whilst I have a fundamental concern that this approach > > SB> lacks an MPLS architectural soundness that need > > SB> greater thought with significant impact on the > > SB> draft. > > > > - Stewart > > > > > > TICTOC Working Group S. > Davari > > Internet-Draft A. > Oren > > Intended status: Standards Track Broadcom > Corp. > > Expires: December 17, 2013 M. > Bhatia > > P. > Roberts > > Alcatel- > Lucent > > L. > Montini > > L. > Martini > > Cisco > Systems > > June 15, > 2013 > > > > > > Transporting Timing messages over MPLS Networks > > draft-ietf-tictoc-1588overmpls-05 > > > > Abstract > > > > This document defines the method for transporting Timing messages > > such as PTP and NTP over an MPLS network. The method allows for > the > > easy identification of these PDUs at the port level to allow for > port > > > > SB> What is a port > > > > level processing of these PDUs in both LERs and LSRs. > > > > The basic idea is to transport Timing messages inside dedicated > MPLS > > LSPs. These LSPs only carry Timing messages and possibly Control > and > > Management packets, but they do not carry customer traffic. > > > > SB> More specifically they only carry traffic associated with the > > SB> timing service and its support. > > SB> The question arose WRT BFD - surely BFD is allowed, BUT surely > > SB> also it gets carried in a structure that causes it to get > > SB> timestamped. > > > > Two methods for transporting Timing messages over MPLS are defined. > > > > SB> Perhaps the right approach is to define the new LSP type and then > > SB> seperately to define the mapping of the various timing services > > SB> over that LSP type. > > > > The first method is to transport Timing messages directly over the > > dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for > > MPLS networks. The second method is to transport Timing messages > > inside a PW via Ethernet encapsulation. > > > > SB> I think that we should note that there are some > > SB> h/w reasons for this preference. A clean sheet approach > > SB> would have been to use PTP over MPLS with no intermediate > > SB> layers. > > > > Status of this Memo > > > > This Internet-Draft is submitted in full conformance with the > > provisions of BCP 78 and BCP 79. > > > > Internet-Drafts are working documents of the Internet Engineering > > Task Force (IETF). Note that other groups may also distribute > > working documents as Internet-Drafts. The list of current > Internet- > > Drafts is at http://datatracker.ietf.org/drafts/current/. > > > > Internet-Drafts are draft documents valid for a maximum of six > months > > and may be updated, replaced, or obsoleted by other documents at > any > > time. It is inappropriate to use Internet-Drafts as reference > > material or to cite them other than as "work in progress." > > > > This Internet-Draft will expire on December 17, 2013. > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 1] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > Copyright Notice > > > > Copyright (c) 2013 IETF Trust and the persons identified as the > > document authors. All rights reserved. > > > > This document is subject to BCP 78 and the IETF Trust's Legal > > Provisions Relating to IETF Documents > > (http://trustee.ietf.org/license-info) in effect on the date of > > publication of this document. Please review these documents > > carefully, as they describe your rights and restrictions with > respect > > to this document. Code Components extracted from this document > must > > include Simplified BSD License text as described in Section 4.e of > > the Trust Legal Provisions and are provided without warranty as > > described in the Simplified BSD License. > > > > > > Table of Contents > > > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . > 5 > > > > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . > 7 > > > > 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . > 8 > > > > 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . > 9 > > > > 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . . > 12 > > > > 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . > 13 > > 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . . > 13 > > 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . . > 13 > > 6.3. Other Timing Encapsulation methods . . . . . . . . . . . . > 14 > > > > 7. Timing message Processing . . . . . . . . . . . . . . . . . . > 15 > > > > 8. Protection and Redundancy . . . . . . . . . . . . . . . . . . > 16 > > > > 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > 17 > > > > 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > 18 > > > > 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . > 19 > > > > 12. OAM, Control and Management . . . . . . . . . . . . . . . . . > 20 > > > > 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . > 21 > > > > 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . . > 22 > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 2] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . > 23 > > 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . . > 23 > > 15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . . > 23 > > 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . . > 24 > > > > 16. Other considerations . . . . . . . . . . . . . . . . . . . . . > 25 > > > > 17. Security Considerations . . . . . . . . . . . . . . . . . . . > 26 > > > > 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . > 27 > > > > 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . > 28 > > > > 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . > 29 > > 20.1. Normative References . . . . . . . . . . . . . . . . . . . > 29 > > 20.2. Informative References . . . . . . . . . . . . . . . . . . > 29 > > > > Appendix 1. Routing extensions for Timing-aware Routers . . . . . > 32 > > > > Appendix 2. Signaling Extensions for Creating Timing LSPs . . . . > 33 > > > > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . > 34 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 3] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this > > document are to be interpreted as described in RFC2119 [RFC2119]. > > > > When used in lower case, these words convey their typical use in > > common language, and are not to be interpreted as described in > > RFC2119 [RFC2119]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 4] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 1. Introduction > > > > The objective of Precision Time Protocol (PTP) and Network Timing > > Protocol (NTP) are to synchronize independent clocks running on > > separate nodes of a distributed system. > > > > [IEEE-1588] defines PTP messages for frequency, phase and time > > synchronization. The PTP messages include PTP PDUs over UDP/IP > > (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex F > of > > [IEEE-1588]). > > > > SB> Sure BUT it is acknowledged that IEEE is open to the definition > > SB> of other PTP mappings if they provide better optimisation. > > > > This document defines mapping and transport of the PTP > > messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP > > defines several clock types: ordinary clocks, boundary clocks, end- > > to-end transparent clocks, and peer-to-peer transparent clocks. > > Transparent clocks require intermediate nodes to update correction > > field inside PTP message that reflects the transit time in the > node. > > > > [RFC5905] defines NTP messages for clock and time synchronization. > > The PTP messages (PDUs) are transported over UDP/IP. This document > > SB> Should that be NTP messages? > > SB> It needs to be made clear as soon as you introduce NTP that > > SB> they use different time representations. > > > > defines mapping and transport of the NTP messages defined in > > [RFC5905] over MPLS networks. > > > > One key attribute of all of these Timing messages is that the Time > > stamp processing should occur as close as possible to the actual > > transmission and reception at the physical port interface. This > > targets optimal time and/or frequency recovery by avoiding variable > > delay introduced by queues internal to the clocks. > > > > SB> As I recall NTP has no epoch point defined, and I am not sure > > SB> where that point is in the case of PTP in this mapping > > SB> Hopefully this will get defined in due course. > > > > To facilitate the fast and efficient recognition of Timing messages > > at the port level when the Timing messages are carried over MPLS > > LSPs, > > > > SB> Over a new LSP type with time optimied characteristics > > > > this document defines the specific encapsulations that should > > be used. > > SB> Hopefully it will also define the PHP > > > > In addition, it can be expected that there will exist LSR/ > > LERs where only a subset of the physical ports will have the port- > > based Timing message processing capabilities. > > SB> Do you need to clarify that this only works at base and not in > > SB> a label heirarchy. > > > > > > In order to ensure > > that the LSPs carrying Timing packets always enter and exit ports > > with this capability, routing extensions are defined to advertise > > this capability on a port basis and to allow for the establishment > of > > LSPs that only transit such ports. While this path establishment > > restriction may be applied only at the LER Ingress and/or egress > > ports, it becomes more important when using transparent clock > capable > > LSRs in the path. > > SB> I do not understand the implications of the last > > SB> sentences - starting ", it becomes" > > > > > > Port based Timing message processing involves Timing message > > recognition. Once the Timing messages are recognized they can be > > modified based on the reception or transmission Time-stamp. > > > > This document provides two methods for transporting Timing messages > > over MPLS. One is applicable to MPLS environment and the other one > > is applicable to MPLS/MPLS-TP environment > > > > SB> I think the sentence is incomplete. > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 5] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > The solution involves transporting Timing messages over dedicated > > LSPs called Timing LSPs. These LSPs carry Timing messages and MAY > > carry Management and control messages, but not data plane client > > traffic. > > > > SB> It is not clear why this restriction applies. > > > > Timing LSPs can be established statically or via signaling. > > SB> s/statically/by provisioning/network management/ > > > > Extensions to control plane (OSPF, ISIS, etc.) is required to > enable > > routers to distribute their Timing processing capabilities over > MPLS > > to other routers. However such extensions are outside the scope of > > this document. > > > > When signaling is used to setup the PTP LSP, Extensions to > signaling > > SB> is it a PTP LSP or a Timing LSP? > > > > protocols (e.g., RSVP-TE) are required for establishing PTP LSPs. > > However such extensions are outside the scope of this document. > > > > SB> for mpls-tp GMPLS is the signalling protocol > > > > While the techniques included herein allow for the establishment of > > paths optimized to include Time-stamping capable links, the > > performance of the Slave clocks is outside the scope of this > > document. > > > > At the time of publishing this specification, Transparent Clocking > > (TC) is only defined for PTP. Therefore at this time any part of > > this specification that talks about Transparent Clocking applies > only > > to PTP. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 6] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 2. Terminology > > > > 1588: The timing and synchronization as defined by IEEE 1588. > > > > SB> I think that there is a more formal name for the 1588 group > > SB> that needs to be used here. > > SB> Also do we need to talk about 1588-200? as there is > > SB> an update in progress > > > > NTP: The timing and synchronization protocol defined by IETF RFC- > 1305 > > and RFC-5905. > > > > PTP: The timing and synchronization protocol used by 1588. > > SB> need the proper name for 1588 > > > > Master Clock: The source of 1588 timing to a set of slave clocks. > > > > Master Port: A port on a ordinary or boundary clock that is in > Master > > state. This is the source of timing toward slave ports. > > > > SB> I am not sure the reader knows what a port is > > > > Slave Clock: A receiver of 1588 timing from a master clock. > > > > Slave Port: A port on a boundary clock or ordinary clock that is > > receiving timing from a master clock. > > > > Ordinary Clock: A device with a single PTP port. > > > > Transparent Clock. A device that measures the time taken for a PTP > > event message to transit the device and then updates the > > correctionField of the message with this transit time. > > > > Boundary Clock: A device with more than one PTP port. Generally > > boundary clocks will have one port in slave state to receive timing > > and then other ports in master state to re-distribute the timing. > > > > PTP LSP: An LSP dedicated to carry PTP messages > > > > SB> PTP or timing? > > > > > > PTP PW: A PW within a PTP LSP that is dedicated to carry PTP > > messages. > > > > SB> Ah I don't think that PWE3 know what one of these is > > > > CW: Pseudowire Control Word > > > > LAG: Link Aggregation > > > > ECMP: Equal Cost Multipath > > > > CF: Correction Field, a field inside certain PTP messages (message > > type 0-3)that holds the accumulative transit time inside > intermediate > > switches > > > > Timing messages: Timing Protocol messages that are exchanged > between > > routers in order to establish a synchronized clock. > > > > SB> A number of these definitions look like copies of IEEE1588 > > SB> definitions. We need to provide references and note the > > SB> priority of the IEEE base reference. > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 7] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 3. Problem Statement > > > > [IEEE-1588] has defined methods for transporting PTP messages over > > Ethernet and IP networks. [RFC5905] has defined the method of > > transporting NTP messages over IP networks. There is a need to > > transport Timing messages over MPLS networks while supporting the > > Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC) > > functionality in the LER and LSRs in the MPLS network. > > > > There are multiple ways of transporting Timing over MPLS. However, > > there is a requirement to limit the possible encapsulation options > to > > simplify the Timing message identification and processing required > at > > the port level. > > > > When Timing-awareness is needed, Timing messages should not be > > transported over LSPs or PWs that are carrying customer traffic > > because LSRs perform Label switching based on the top label in the > > stack. > > > > SB> Have you explained why? > > > > To detect Timing messages inside such LSPs require special > > hardware to do deep packet inspection at line rate. Even if such > > hardware exists, the payload can't be deterministically identified > by > > LSRs because the payload type is a context of the PW label, and the > > PW label and its context are only known to the Edge routers (PEs/ > > LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, > CES, > > etc). Even if one restricts an LSP to only carry Ethernet PWs, the > > LSRs dont have the knowledge of whether PW Control Word (CW) is > > present or not and therefore can not deterministically identify the > > payload. > > > > A generic method is defined in this document that does not require > > deep packet inspection at line rate, and can deterministically > > identify Timing messages. This method can be used to detect Timing > > Messages in both one-step and two-step clock implementations of > > ordinary, boundary and transparent clocks. > > > > SB> Needs a ref and I am sure many MPLS specialists will not > understand > > SB> the msg types. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 8] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 4. Timing over MPLS Architecture > > > > Timing messages are exchange between Timing ports on ordinary and > > > > SB> Have you defined a timing port? > > > > boundary clocks. Boundary clocks terminate the Timing messages and > > act as master for other boundary clocks or for slave clocks. End- > to- > > End Transparent clocks do not terminate the Timing messages but > they > > do modify the contents of the Timing messages as they transit > across > > the transparent clock. > > > > Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent > Clock > > > > (TC) could be implemented in either LERs or LSRs. > > > > SB> LER and LSR need to be expanded > > > > An example is shown in Figure 1, where the LERs act as Ordinary > Clock > > (OC) and are the initiating/terminating point for Timing messages. > > The ingress LER encapsulates the Timing messages in Timing LSP and > > the Egress LER terminates the Timing LSP. The LSRs act as > > Transparent Clock (TC) and just update the Timing field in the > Timing > > messages. > > > > > > +--------+ +-------+ +-------+ +-------+ +------ > --+ > > |Switch, | | | | | | | > |Switch, | > > | Router |-----| LER |-----| LSR |-----| LER |-----| > Router | > > | | | OC | | TC | | OC | | > | > > +--------+ +-------+ +-------+ +-------+ +------ > --+ > > / \ > > +-------+ / \ +------- > + > > | LER | / \ | LER > | > > | Master|---/ \---| Slave > | > > | Clock | | Clock > | > > +-------+ +------- > + > > > > Figure (1) - Deployment example 1 of timing over MPLS network > > > > Another example is shown in Figure2, where LERs terminate the > Timing > > messages received from switch/routers that are outside of the MPLS > > network acting as OC or BC. In this example LERs regenerate the > > clock and initiate timing messages encapsulated in Timing LSP > toward > > the MPLS network, while the LSRs act as Transparent Clock (TC) and > > just update the Timing field in the Timing messages, which are > > already encapsulated in Timing LSPs. > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 9] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > +--------+ +-------+ +-------+ +-------+ +------- > -+ > > |Switch, | | | | | | | |Switch, > | > > | Router |-----| LER |-----| LSR |-----| LER |-----| Router > | > > | OC/BC | | BC | | TC | | BC | | OC/BC > | > > +--------+ +-------+ +-------+ +-------+ +------- > -+ > > > > Figure (2) - Deployment example 2 of timing over MPLS network > > > > > > Another example is shown in Figure 3, where LERs do not terminate > the > > Timing messages received from switch/routers that are outside of > the > > MPLS network acting as OC, TC or BC. The LERs act as TC and update > > the Timing field in the Timing messages as they transit the LER, > > while encapsulating them in timing LSP. The LSRs also act as > > Transparent Clock (TC) and just update the Timing field in the > Timing > > messages which are already encapsulated in Timing LSPs. > > > > +--------+ +-------+ +-------+ +-------+ +------ > --+ > > |Switch, | | | | | | | > |Switch, | > > | Router |-----| LER |-----| LSR |-----| LER |-----| > Router | > > |OC/TC/BC| | TC | | TC | | TC | > |OC/TC/BC| > > +--------+ +-------+ +-------+ +-------+ +------ > --+ > > > > Figure (3) - Deployment example 3 of timing over MPLS network > > > > Another example is shown in Figure 4, where LERs and LSRs support > > Boundary Clocks. A single-hop LSP is created between two adjacent > > LSRs engaged in BC operation. Other methods such as PTP transport > > over Ethernet MAY be used for transporting timing messages if the > > link between the two routers is Ethernet. > > > > +--------+ +-------+ +-------+ +-------+ +------- > -+ > > |Switch, | | | | | | | |Switch, > | > > | Router |-----| LER |-----| LSR |-----| LER |-----| Router > | > > | OC/BC | | BC | | BC | | BC | | OC/BC > | > > +--------+ +-------+ +-------+ +-------+ +------- > -+ > > > > Figure (4) - Deployment example 3 of timing over MPLS network > > > > An MPLS domain MAY serve multiple customers. In these cases the > MPLS > > domain (maintained by a service provider) may provide timing > services > > to multiple customers, each having their own Timing domain. > > > > The Timing over MPLS architecture assumes full mesh of Timing LSPs > > between all LERs supporting this specification. > > > > SB> Note sure this is right - the salves surely do not need to > > SB> exchange timing amongst themselves > > > > It supports > > Point-to- point (VPWS) and Multipoint (VPLS) services. > > > > SB> What does that mean? You do not carry user data traffic? > > SB> Maybe it's the ordering of the statemnets that is causing > > SB> confusion. > > > > This means > > that a customer may purchase a Point-to-point Timing service > between > > two customer sites or a Multipoint Timing service between more than > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 10] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > two customer sites. > > > > The Timing over MPLS architecture supports P2P or P2MP Timing LSPs. > > This means that the Timing Multicast messages such as PTP Multicast > > event messages can be transported over P2MP Timing LSP or be > > replicated and transported over many P2P Timing LSPs. > > > > SB> Note we do not yet have a definition of a P2MP mpls-tp LSP > > SB> nor a P2MP PW, although we are close. > > > > Timing messages, that do not require Time stamping or Correction > > Field update MAY be transported over Timing LSPs to simplify > hardware > > and software. > > > > PTP Announce messages that determine the Timing LSP terminating > point > > behavior such as BC/OC/TC SHOULD be transported over the Timing LSP > > to simplify hardware and software. > > > > SB> have you defined and referenced PTP announce msgs? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 11] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 5. Dedicated LSPs for Timing messages > > > > Many methods have been considered for identifying the Timing > messages > > when they are encapsulated in MPLS such as using GAL/G-ACH or a new > > reserved label. These methods were not attractive since they > either > > required deep packet inspection at line rate in the intermediate > LSRs > > or they required use of a scarce new reserved label. Also one of > the > > goals was to reuse existing OAM mechanisms. > > > > SB> RLs =3D SPLs are not so rare now. In any case needs a ref. > > > > The method defined in this document can be used by LER and LSRs to > > identify Timing messages in MPLS tunnels by just looking at the top > > label in the MPLS label stack, which only carry Timing messages as > > well as OAM, but not data plane client traffic. > > > > Compliant implementations MUST use dedicated LSPs to carry Timing > > messages over MPLS. > > > > SB> I think that we need a definition of the properies of these LSPs > > > > These LSPs are herein referred to as "Timing > > LSPs" and the labels associated with these LSPs as "Timing LSP > > labels". The Timing LSPs that runs between Ingress and Egress LERs > > MUST be co-routed. Alternatively, a single bidirectional co-routed > > LSP can be used. > > > > SB> I though that you said you could use M2MP LSPs - these are not > > SB> bidirectional. > > > > Co-routing of the two directions is required to limit the > difference > > in the delays in the Master clock to Slave clock direction compared > > to the Slave clock to Master clock direction. The Timing LSP MAY > be > > MPLS/MPLS-TP LSP. > > > > The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS. > > New Extensions to RSVP-TE/GMPLS TLVs are required; however they are > > outside the scope of this document. > > > > The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such > as > > BFD and LSP Ping but the LSP data plane client plane traffic MUST > be > > Timing packets only. > > > > SB> Why? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 12] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 6. Timing over LSP Encapsulation > > > > The encapsulations is not LSP is it? > > > > This document defines two methods for carrying Timing messages over > > MPLS. The first method is carrying UDP/IP encapsulated Timing > > messages over Timing LSPs, and the second method, is carrying > > Ethernet encapsulated Timing messages over Ethernet PWs inside > Timing > > LSPs. > > > > 6.1. Timing over UDP/IP over MPLS Encapsulation > > > > The simplest method of transporting Timing messages over MPLS is to > > encapsulate Timing PDUs in UDP/IP and then encapsulate them in > Timing > > LSP. This format is shown in Figure 4. > > > > > > +----------------------+ > > | Timing LSP Label | > > +----------------------+ > > | IPv4/6 | > > +----------------------+ > > | UDP | > > +----------------------+ > > | Timing PDU | > > +----------------------+ > > > > Figure (4) - Timing over UDP/IP over MPLS Encapsulation > > > > > > This encapsulation is very simple and is useful when the network > > between Timing Master Clock and Slave Clock is MPLS network. > > > > SB> Simple is a judgement call > > > > In order for an LER/LSR to process Timing messages, the Timing LSP > > Label must be at the top label of the label stack. The LER/LSR > MUST > > know that the Timing LSP Label is used for carrying Timing > messages. > > This can be accomplished via static configuration or via RSVP-TE > > signaling. > > > > The UDP/IP encapsulation of PTP MUST follow Annex D and E of > > [IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow > > [RFC5905]. > > > > 6.2. Timing over PW Encapsulation > > > > Another method of transporting Timing over MPLS networks is by > > encapsulating Timing PDUs in PW which in turn is transported over > > Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448], > > shown in Fig 5(A) MUST be used and the Ethernet encapsulation of > PTP > > MUST follow Annex F of [IEEE-1588]. > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 13] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > The RAW mode or Tagged mode defined in [RFC4448] MAY be used and > the > > Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The > > Timing over PW encapsulation MUST use the Control Word (CW) as > > specified in [RFC4448] to ensure proper detection of PTP messages > > inside the MPLS packets for Timing over LSP and Timing over PW > > encapsulation. > > > > SB> That needs explanation > > > > The use of Sequence Number in the CW is optional. > > > > SB> Given that s/n are never in practice deployed, you could probably > > SB> simplify things by sayig that they are not used. > > > > Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over > PW > > (the IP PW discussed in [RFC4447]) shown in Fig 5(B). > > > > +----------------+ +----------------+ > > |Timing LSP Label| |Timing LSP Label| > > +----------------+ +----------------+ > > | PW Label | | PW Label | > > +----------------+ +----------------+ > > | Control Word | | IP | > > +----------------+ +----------------+ > > | Ethernet | | UDP | > > | Header | +----------------+ > > +----------------+ | Timing PDU | > > |S-VLAN(Optional)| | | > > +----------------+ +----------------+ > > |C-VLAN(Optional)| (B) > > +----------------+ > > | Timing PDU | > > | | > > +----------------+ > > (A) > > > > Figure (5) - Timing over PW Encapsulations > > > > In order for an LSR to process PTP messages, the top label of the > > label stack (the Tunnel Label) MUST be a Timing label. > > > > S> You said that before. > > > > 6.3. Other Timing Encapsulation methods > > > > In future other timing encapsulation methods may be introduced, > such > > as a new shim header after the Bottom of Stack to carry the Timing > > information. Such new encapsulations are outside the scope of this > > document. > > > > > > SB> Taking a pure MPLS pov, you can simplify a lot of the text > > SB> out of the definition of the LSP > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 14] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > SB> I think we need a section on LSP processing > > > > 7. Timing message Processing > > > > Each Timing protocol such as PTP and NTP, define their set of > Timing > > messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, > > FOLLOW_UP, etc messages. > > > > Some of the Timing messages require time stamping or correction > field > > update at port level and some dont. It is the job of the LER/LSR > to > > parse the timing message and find out the type of the Timing > message > > and decide whether and how to Time- stamp it (e.g., BC) or update > > correction field(e.g., TC). > > > > > > SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing > > SB> function rather than the LER? > > > > For example the following PTP messages (called Event messages) > > require time-stamping or correction field update: > > > > o SYNC > > > > o DELAY_REQ (Delay Request) > > > > o PDELAY_REQ (Peer Delay Request) > > > > o PDELAY_RESP (Peer Delay Response) > > > > SYNC and DELAY_REQ are exchanged between Master Clock and Slave > Clock > > and MUST be transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP > > are exchanged between adjacent PTP clocks (i.e. Master, Slave, > > Boundary, or Transparent) and SHOULD be transported over single hop > > PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP, > > and PDELAY_RESP_FOLLOW_UP messages MUST also be transported over > the > > PTP LSPs. > > > > For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be > > transported over two PTP LSPs that are in opposite directions. > These > > PTP LSPs, which are in opposite directions MUST be congruent and > co- > > routed. Alternatively, a single bidirectional co-routed LSP can be > > used. > > > > Except as indicated above for the two-step PTP clocks, Non-Event > PTP > > message types do not need to be processed by intermediate routers. > > These message types MAY be carried in PTP Tunnel LSPs. > > > > SB> Are you saying that a timing P router has to be msg type > sensitive? > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 15] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 8. Protection and Redundancy > > > > > > SB> This is a bit of a jump - I don't know how the LSP itself works > yet! > > > > In order to ensure continuous uninterrupted operation of slave > > clocks, usually as a general practice, slave clocks (or ports) > track > > redundant master clocks. > > > > It is the responsibility of the network operator to ensure that > > physically disjoint Timing LSPs are established between a slave > clock > > (or port) and redundant master clocks (or ports). > > > > When a slave clock (or port) listens to redundant master clocks or > > ports, any prolonged Timing LSP outage will trigger the slave clock > > or port to switch to a redundant master clock or port. > > > > LSP/PW protection such as Linear protection Switching (1:1, 1+1), > > Ring protection switching or MPLS Fast Reroute (FRR) generally > switch > > alternative path that usually cause a change in delay, which if > > undetected by slave clock can reduce accuracy of the slave clock. > > > > Therefore protection switching MAY be used, as long as phase jumps > > upon switchover due to differences in path latency are detected and > > compensated for (such compensation not being required if BCs or > peer- > > peer TCs are used throughout). > > > > Note that any protection or reroute mechanism that adds additional > > MPLS label to the label stack, such as Facility Backup Fast > Reroute, > > MUST ensure that the pushed label is also a Timing Label to ensure > > recognition of the MPLS frame as containing Timing messages, as it > > transits the backup path. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 16] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 9. ECMP > > > > To ensure the optimal operation of slave clocks and avoid error > > introduced by forward and reverse path delay asymmetry, the > physical > > path for Timing messages from master clock to slave Clock and vice > > versa must be the same for all Event Timing messages listed in > > section 7. > > > > Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost > > Multipath). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 17] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 10. PHP > > > > To ensure that the label on the top of the label stack is the > Timing > > LSP Label, PHP MUST not be used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 18] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 11. Entropy > > > > To ensure all Timing messages in a Timing LSP take the same path, > > Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and > > Entropy Label MUST NOT be used for the PWs that are carried inside > > Timing LSP [RFC6391]. > > > > SB> This is incorrect - you mean that all msgs of the same timing > > SB> flow need to have the same EL value. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 19] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 12. OAM, Control and Management > > > > In order to monitor Timing LSPs and their encapsulated PWs, they > MUST > > be able to carry OAM and management messages. These management > > messages MUST be differentiated from Timing messages via already > > defined IETF methods. > > > > For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY run > > over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These > > Management protocols can easily be identified by the UDP > Destination > > Port number or by GAL/G-ACH respectively. > > > > Also BFD, LSP-Ping and other management messages MAY run over the > PWs > > encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3 > or > > 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is > going > > to be deprecated by IETF). In this case G-ACH, PW label (TTL=3D1) or > > GAL-ACH are used to identify such management messages. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 20] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 13. QoS Considerations > > > > In network deployments where not every LSR/LER is Timing-aware, it > is > > important to reduce the impact of the non-Timing-aware LSR/LERs on > > the timing recovery in the slave clock. The Timing messages are > time > > critical and must be treated with the highest priority. Therefore > > Timing over MPLS messages must be treated with the highest priority > > in the routers. This can be achieved by proper setup of Timing > LSPs. > > > > It is recommended that the Timing LSPs are setup or configured > > properly to indicate EF-PHB [RFC3246]for the CoS and Green > [RFC2697] > > for drop eligibility. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 21] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 14. FCS and Checksum Recalculation > > > > When time-stamp generation and timing packet adjustment is > performed > > near the physical port hardware, the process MUST include > > recalculation of the Ethernet FCS. > > > > SB> The above is confusing - an LSR always recomputes the link layer > > SB> CRC which may or may not be Ethernet. > > > > Also FCS retention for the > > payload Ethernet described in [RFC4720] MUST NOT be used. > > > > For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum > > may be required as per UDP transport standards. > > > > SB> You really need to be working on getting the IPv6 C?S computation > > SB> removed from PTP msgs. > > > > When UDP checksum is used, each Timing-aware LER/LSR must either > > incrementally update the UDP checksum after Time stamping or > > Correction Field update or verify the UDP checksum on reception > from > > upstream and recalculate the checksum completely on transmission to > > downstream node after Time stamping or Correction Field update. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 22] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 15. Behavior of LER/LSR > > > > Timing-capable/aware LERs and LSRs are routers that have one or > more > > > > SB> You mean physical interfaces? > > > > interfaces that can perform Timing operations (OC/BC/TC) on Timing > > packets and are configured to do so. Timing-capable/aware LERs and > > LSRs can advertise their Timing-capability per-interface via > control > > plane such as OSPF or IS-IS. > > SB> ISIS and OSPF are routing protocols. > > > > The Timing-capable/aware LERs can then > > signals Timing LSPs via RSVP-TE signaling. Alternatively the > Timing > > capability of LER and LSRs may be configured in a centralized > > controller and the Timing LSP may be setup using manual > configuration > > or other methods such as SDN. > > > > SB> it can also be configured individually rather then through > > SB> a cebtral controllwe > > > > 15.1. Behavior of Timing-capable/aware LER > > > > When a Timing-capable/aware LER behaves as a Transparent clock and > > receives a Timing message from a Timing-capable/aware non-MPLS > > interface, the LER updates the Correction Field (CF) and > encapsulates > > and forwards the timing message over previously established Timing > > LSP. > > > > SB> You need to call out the details so that people properly > > SB> understand the definition of the new LSP. > > > > Also when a Timing message is received from a Timing-capable/ > > aware MPLS interface, LER updates the Correction Filed (CF) and > > decapsulates the MPLS encapsulation and forwards the timing message > > to a non-MPLS interface. > > > > When a Timing-capable/aware LER behaves as a Boundary clock and > > receives a Timing message from a Timing-capable/aware non MPLS > > interface, the LER Timestamps the Timing packet and sends it to the > > LERs Boundary clock processing module. Also when a Timing message > is > > received from a Timing- capable/aware MPLS interface, the LER > > Timestamps the Timing packet and sends it to the LERs Boundary > clock > > processing module. > > > > When a Timing-capable/aware LER behaves as an Ordinary Clock toward > > the MPLS network, and receives a Timing message from a Timing- > > capable/aware MPLS interface, the LER Timestamps the Timing packet > > and sends it to the LERs Ordinary clock processing module. > > > > 15.2. Behavior of Timing-capable/aware LSR > > > > When a Timing-capable/aware LSR behaves as a Transparent clock and > > receives a Timing message from a Timing-capable/aware MPLS > interface, > > The LSR updates the Correction Filed (CF) and forwards the timing > > message over another MPLS interface. > > > > When a Timing-capable/aware LSR behaves as a Boundary clock and > > receives a Timing message from a Timing-capable/aware MPLS > interface. > > The LSR performs the functions of a Boundary Clock in terminating > the > > received Timing message and re-generating a new timing message over > > another (or the same) MPLS interface. > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 23] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 15.3. Behavior of non-Timing-capable/aware LSR > > > > It is most beneficial when all LSRs in the path of a Timing LSP be > > timing-Capable/aware LSRs. This would ensure the highest quality > > time and clock synchronization by Timing Slave Clocks. However, > this > > specification does not mandate that all LSRs in path of a Timing > LSP > > be Timing- capable/aware. > > > > Non-Timing-capable/aware LSRs just switch the packets encapsulated > in > > Timing LSPs and dont perform any Timing operation (TC or BC). > > However as explained in QoS section the Timing over MPLS packets > MUST > > be still be treated with the highest priority based on their > Traffic > > Class (TC) marking. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 24] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 16. Other considerations > > > > [IEEE-1588] defines an optional peer-to-peer Transparent clocking > > that requires peer delay measurement between two adjacent Timing- > > capable/ aware routers/switches. Peer delay measurement messages > > need to be time stamped and terminated by the Timing-capable/aware > > routers/ switches. This means that two adjacent LSRs may be > engaged > > in a peer delay measurement. > > > > For transporting such peer delay measurement messages a single-hop > > LSP SHOULD to be created between the two adjacent LSRs engaged in > > peer delay measurement to carry peer delay measurement messages. > > Other methods such as PTP transport over Ethernet MAY be used for > > transporting peer delay measurement messages if the link between > the > > two routers is Ethernet. > > > > In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ > ware > > routers/switches MUST maintain a list of all the neighbors it needs > > to send a PDelay_Req to, where each neighbor corresponds to a > timing > > LSP. > > > > The use of Explicit Null Label (Label=3D 0 or 2) is acceptable as > long > > as either the Explicit Null label is the bottom of stack label > > (applicable only to UDP/IP encapsulation) or the label below the > > Explicit Null label is a PTP label. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 25] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 17. Security Considerations > > > > MPLS PW security considerations in general are discussed in > [RFC3985] > > and [RFC4447],and those considerations also apply to this document. > > > > An experimental security protocol is defined in [IEEE-1588].The PTP > > security extension and protocol provides group source > authentication, > > message integrity, and replay attack protection for PTP messages. > > > > When the MPLS network (provider network) serves multiple customers, > > it is important to maintain and process each customers clock and > > Timing messages separately from other customers to ensure there is > no > > cross- customer effect. For example if an LER BC is synchronized > to > > a specific grandmaster, belonging to customer A, then the LER MUST > > use that BC clock only for customer A to ensure that customer A > > cannot attack other customers by manipulating its time. > > > > Timing messages MAY be encrypted or authenticated, provided that > the > > LERs/LSRs that are Timing capable/aware can authenticate/ decrypt > the > > timing messages. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 26] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 18. Acknowledgements > > > > The authors would like to thank Ron Cohen, Yaakov Stein, Tal > Mizrahi, > > Stefano Ruffini, Peter Meyer, and other members of IETF for > reviewing > > and providing feedback on this draft. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 27] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 19. IANA Considerations > > > > There are no IANA requirements in this specification. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 28] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 20. References > > > > 20.1. Normative References > > > > [IEEE-1588] > > IEEE 1588-2008, "IEEE Standard for a Precision Clock > > Synchronization Protocol for Networked Measurement and > > Control Systems". > > > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > > Requirement Levels", BCP 14, RFC 2119, March 1997. > > > > [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- > > Edge (PWE3) Architecture", RFC 3985, March 2005. > > > > [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor > Discovery > > Proxies (ND Proxy)", RFC 4389, April 2006. > > > > [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. > > Heron, "Pseudowire Setup and Maintenance Using the Label > > Distribution Protocol (LDP)", RFC 4447, April 2006. > > > > [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, > > "Encapsulation Methods for Transport of Ethernet over > MPLS > > Networks", RFC 4448, April 2006. > > > > [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire > > Emulation Edge-to-Edge (PWE3) Frame Check Sequence > > Retention", RFC 4720, November 2006. > > > > [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit > > Connectivity Verification (VCCV): A Control Channel for > > Pseudowires", RFC 5085, December 2007. > > > > [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding > Detection > > (BFD)", RFC 5880, June 2010. > > > > [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, > > "Bidirectional Forwarding Detection (BFD) for MPLS Label > > Switched Paths (LSPs)", RFC 5884, June 2010. > > > > 20.2. Informative References > > > > [I-D.ietf-pwe3-fat-pw] > > Bryant, S., Filsfils, C., Drafz, U., Kompella, V., > Regan, > > J., and S. Amante, "Flow Aware Transport of Pseudowires > > over an MPLS Packet Switched Network", > > draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011. > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 29] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate > > system routeing information exchange protocol for use in > > conjunction with the Protocol for providing the > > Connectionless-mode Network Service (ISO 8473)". > > > > [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and > > dual environments", RFC 1195, December 1990. > > > > [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. > > > > [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color > > Marker", RFC 2697, September 1999. > > > > [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le > Boudec, > > J., Courtney, W., Davari, S., Firoiu, V., and D. > > Stiliadis, "An Expedited Forwarding PHB (Per-Hop > > Behavior)", RFC 3246, March 2002. > > > > [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic > Engineering > > (TE) Extensions to OSPF Version 2", RFC 3630, > > September 2003. > > > > [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate > > System (IS-IS) Extensions for Traffic Engineering (TE)", > > RFC 3784, June 2004. > > > > [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. > > Shaffer, "Extensions to OSPF for Advertising Optional > > Router Capabilities", RFC 4970, July 2007. > > > > [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate > > System to Intermediate System (IS-IS) Extensions for > > Advertising Router Information", RFC 4971, July 2007. > > > > [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi > > Topology (MT) Routing in Intermediate System to > > Intermediate Systems (IS-ISs)", RFC 5120, February 2008. > > > > [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic > > Engineering", RFC 5305, October 2008. > > > > [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, > > "Traffic Engineering Extensions to OSPF Version 3", > > RFC 5329, September 2008. > > > > [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF > > for IPv6", RFC 5340, July 2008. > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 30] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, > "Network > > Time Protocol Version 4: Protocol and Algorithms > > Specification", RFC 5905, June 2010. > > > > [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., > Regan, > > J., and S. Amante, "Flow-Aware Transport of Pseudowires > > over an MPLS Packet Switched Network", RFC 6391, > > November 2011. > > > > [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and > > L. Yong, "The Use of Entropy Labels in MPLS Forwarding", > > RFC 6790, November 2012. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 31] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 1. Routing extensions for Timing-aware Routers > > > > MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] > and > > IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering > (TE) > > link information used for constraint-based routing. > > > > Indeed, it is useful to advertise data plane TE router link > > capabilities, such as the capability for a router to be Timing- > aware. > > This capability MUST then be taken into account during path > > computation to prefer or even require links that advertise > themselves > > as Timing-aware. In this way the path can ensure the entry and > exit > > points into the LERs and, if desired, the links into the LSRs are > > able to perform port based time-stamping thus minimizing their > impact > > on the performance of the slave clock. > > > > extensions are required to OSPF and IS-IS in order to advertise > > Timing-aware capabilities of a link. Such extensions are outside > the > > scope of this document; however such extension SHOULD be able to > > signal the following information per Router Link: > > > > o Capable of processing PTP, NTP or other Timing flows > > > > o Capable of performing Transparent Clock operation > > > > o Capable of performing Boundary Clock operation > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 32] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > 2. Signaling Extensions for Creating Timing LSPs > > > > RSVP-TE signaling MAY be used to setup the timing LSPs. When RSVP- > TE > > is used to setup Timing LSPs, some information that indicates that > > the LSP is carrying Timing flows MUST be included in the new > > Extensions to RSVP-TE: > > > > The following information MAY also be included in the new > Extensions > > to RSVP-TE: > > > > o Offset from Bottom of Stack (BoS) to the start of the Time-stamp > > field > > > > o Number of VLANs in case of PW encapsulation > > > > o Timestamp field Type > > > > * Correction Field, Timestamp > > > > o Timestamp Field format > > > > * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit > > NTP, etc. > > > > Note that in case the above optional information is signaled with > > RSVP-TE for a Timing LSP, all the Timing packets carried in that > LSP > > must have the same signaled characteristics. For example if > > Timestamp format is signaled as 64-bit PTPv1, then all Timing > packets > > must use 64-bit PTPv1 time-stamp. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 33] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > Authors' Addresses > > > > Shahram Davari > > Broadcom Corp. > > San Jose, CA 95134 > > USA > > > > Email: davari@broadcom.com > > > > > > Amit Oren > > Broadcom Corp. > > San Jose, CA 95134 > > USA > > > > Email: amito@broadcom.com > > > > > > Manav Bhatia > > Alcatel-Lucent > > Bangalore, > > India > > > > Email: manav.bhatia@alcatel-lucent.com > > > > > > Peter Roberts > > Alcatel-Lucent > > Kanata, > > Canada > > > > Email: peter.roberts@alcatel-lucent.com > > > > > > Laurent Montini > > Cisco Systems > > San Jose CA > > USA > > > > Email: lmontini@cisco.com > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 34] > >=20 > > Internet-Draft Transporting Timing over MPLS June > 2013 > > > > > > Luca > > Cisco Systems > > San Jose CA > > USA > > > > Email: lmartini@cisco.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page > 35] > >=20 > > > > -- > > 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 > > >=20 >=20 From davari@broadcom.com Fri Aug 2 06:42:47 2013 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 CD2AE21E80AA; Fri, 2 Aug 2013 06:42:46 -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 Mrat-QwE5wud; Fri, 2 Aug 2013 06:42:40 -0700 (PDT) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9747D11E8321; Fri, 2 Aug 2013 06:42:35 -0700 (PDT) Received: from [10.9.208.57] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 02 Aug 2013 06:32:28 -0700 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.14) by IRVEXCHCAS08.corp.ad.broadcom.com (10.9.208.57) with Microsoft SMTP Server (TLS) id 14.1.438.0; Fri, 2 Aug 2013 06:42:19 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS06.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Fri, 2 Aug 2013 06:42:19 -0700 From: "Shahram Davari" To: "John E Drake" Thread-Topic: [mpls] Comments on draft-ietf-tictoc-1588overmpls Thread-Index: AQHOj2dsoD26UTw5FECSgmrxo5m7wJmBtd9EgAB9NYD//7pTBA== Date: Fri, 2 Aug 2013 13:42:18 +0000 Message-ID: References: <51FB8396.9020504@cisco.com> , <0182DEA5604B3A44A2EE61F3EE3ED69E2076CBA4@BL2PRD0510MB349.namprd05.prod.outlook.com> In-Reply-To: <0182DEA5604B3A44A2EE61F3EE3ED69E2076CBA4@BL2PRD0510MB349.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-WSS-ID: 7DE56B662L870061941-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , "tictoc-chairs@tools.ietf.org" , "tictoc@ietf.org" , "draft-ietf-tictoc-1588overmpls@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "int-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Comments on draft-ietf-tictoc-1588overmpls 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, 02 Aug 2013 13:42:47 -0000 Hi John In that case I fail to understand the difference between your proposal and = the current draft. In both cases you need a special LSP to tell the HW to Timestamp the packet= and I assume you need to use RSVPTE to sign it. That is what the draft doe= s. Regards, Shahram On Aug 2, 2013, at 12:52 PM, "John E Drake" wrote: > Shahram, >=20 > The LSPs would be between LSRs that are 1588 capable, so they could be on= e or more hops. >=20 > Yours Irrespectively, >=20 > John >=20 >=20 >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Friday, August 02, 2013 3:24 AM >> To: >> Cc: mpls-chairs@tools.ietf.org; tictoc-chairs@tools.ietf.org; int- >> ads@tools.ietf.org; rtg-ads@tools.ietf.org; draft-ietf-tictoc- >> 1588overmpls@tools.ietf.org; John E Drake; mpls@ietf.org; >> tictoc@ietf.org >> Subject: Re: [mpls] Comments on draft-ietf-tictoc-1588overmpls >>=20 >> Hi Stewart >>=20 >> We have already looked at similar approach. The issue with one hop LSP >> is that not all LSRs are 1588 capable. One of the requirements is for >> non-1588 capable routers to just switch the packet normally. >>=20 >> Regards, >> Shahram >>=20 >>=20 >> On Aug 2, 2013, at 12:02 PM, "Stewart Bryant" >> wrote: >>=20 >>> Talking to John Drake about this, an alternative general >>> model is for the LSP is that it is an LSP that timestamps >>> the packet and then passes it to an application associated >>> with the LSP at that hop. >>>=20 >>> This has a lot of merit. >>>=20 >>> If however we think about it some more we have a >>> type of network service chaining going on here and >>> so we don't need an LSP per say, because the path >>> and instruction can be in the packet. >>>=20 >>> In other words a general solution to the problem >>> is to define an LSP with the properties that the >>> packet is passed one hop, timestamped and delivered >>> to the associated application. >>>=20 >>> How this is MPLS construct is used to support time >>> tranfer is entirely within the scope of TICTOC, but >>> at the MPLS layer we have a clean reusable network >>> service. >>>=20 >>> - Stewart >>>=20 >>>=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> SB> This draft does not seem to provide a precise definition >>> SB> the properties of the new LSP type that it wishes to >>> SB> define, in particular it does it define the PHB of those >>> SB> LSPs, nor the full interaction with the MPLS >>> SB> architecture. >>> SB> >>> SB> I have not tracked TICTOC for a while but I thought that >>> SB> the original plan was to define the concept of an offset >>> SB> into a packet to do the correction. >>> SB> >>> SB> It is disappointing that the opportunity was not taken >>> SB> to define a timing shim inside the timing LSP so that >>> SB> a time correction could be added to any packet such that >>> SB> the MPLS system was isolated from the details of the >>> SB> complexity of the particular time transfer type. >>>=20 >>> SB> I think that much more clarify is needed in terms of >>> SB> definition of the new LSP type, since it is unclear >>> SB> from this text how to implement one. >>> SB> >>> SB> There are a lot of other MPLS services such as >>> SB> LSP ping that need to be considered. >>> SB> >>> SB> Please see inline for more comments. However these >>> SB> comments are made in the context of the text as written >>> SB> whilst I have a fundamental concern that this approach >>> SB> lacks an MPLS architectural soundness that need >>> SB> greater thought with significant impact on the >>> SB> draft. >>>=20 >>> - Stewart >>>=20 >>>=20 >>> TICTOC Working Group S. >> Davari >>> Internet-Draft A. >> Oren >>> Intended status: Standards Track Broadcom >> Corp. >>> Expires: December 17, 2013 M. >> Bhatia >>> P. >> Roberts >>> Alcatel- >> Lucent >>> L. >> Montini >>> L. >> Martini >>> Cisco >> Systems >>> June 15, >> 2013 >>>=20 >>>=20 >>> Transporting Timing messages over MPLS Networks >>> draft-ietf-tictoc-1588overmpls-05 >>>=20 >>> Abstract >>>=20 >>> This document defines the method for transporting Timing messages >>> such as PTP and NTP over an MPLS network. The method allows for >> the >>> easy identification of these PDUs at the port level to allow for >> port >>>=20 >>> SB> What is a port >>>=20 >>> level processing of these PDUs in both LERs and LSRs. >>>=20 >>> The basic idea is to transport Timing messages inside dedicated >> MPLS >>> LSPs. These LSPs only carry Timing messages and possibly Control >> and >>> Management packets, but they do not carry customer traffic. >>>=20 >>> SB> More specifically they only carry traffic associated with the >>> SB> timing service and its support. >>> SB> The question arose WRT BFD - surely BFD is allowed, BUT surely >>> SB> also it gets carried in a structure that causes it to get >>> SB> timestamped. >>>=20 >>> Two methods for transporting Timing messages over MPLS are defined. >>>=20 >>> SB> Perhaps the right approach is to define the new LSP type and then >>> SB> seperately to define the mapping of the various timing services >>> SB> over that LSP type. >>>=20 >>> The first method is to transport Timing messages directly over the >>> dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for >>> MPLS networks. The second method is to transport Timing messages >>> inside a PW via Ethernet encapsulation. >>>=20 >>> SB> I think that we should note that there are some >>> SB> h/w reasons for this preference. A clean sheet approach >>> SB> would have been to use PTP over MPLS with no intermediate >>> SB> layers. >>>=20 >>> Status of this Memo >>>=20 >>> This Internet-Draft is submitted in full conformance with the >>> provisions of BCP 78 and BCP 79. >>>=20 >>> Internet-Drafts are working documents of the Internet Engineering >>> Task Force (IETF). Note that other groups may also distribute >>> working documents as Internet-Drafts. The list of current >> Internet- >>> Drafts is at http://datatracker.ietf.org/drafts/current/. >>>=20 >>> Internet-Drafts are draft documents valid for a maximum of six >> months >>> and may be updated, replaced, or obsoleted by other documents at >> any >>> time. It is inappropriate to use Internet-Drafts as reference >>> material or to cite them other than as "work in progress." >>>=20 >>> This Internet-Draft will expire on December 17, 2013. >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 1] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> Copyright Notice >>>=20 >>> Copyright (c) 2013 IETF Trust and the persons identified as the >>> document authors. All rights reserved. >>>=20 >>> This document is subject to BCP 78 and the IETF Trust's Legal >>> Provisions Relating to IETF Documents >>> (http://trustee.ietf.org/license-info) in effect on the date of >>> publication of this document. Please review these documents >>> carefully, as they describe your rights and restrictions with >> respect >>> to this document. Code Components extracted from this document >> must >>> include Simplified BSD License text as described in Section 4.e of >>> the Trust Legal Provisions and are provided without warranty as >>> described in the Simplified BSD License. >>>=20 >>>=20 >>> Table of Contents >>>=20 >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . >> 5 >>>=20 >>> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . >> 7 >>>=20 >>> 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . >> 8 >>>=20 >>> 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . >> 9 >>>=20 >>> 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . . >> 12 >>>=20 >>> 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . >> 13 >>> 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . . >> 13 >>> 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . . >> 13 >>> 6.3. Other Timing Encapsulation methods . . . . . . . . . . . . >> 14 >>>=20 >>> 7. Timing message Processing . . . . . . . . . . . . . . . . . . >> 15 >>>=20 >>> 8. Protection and Redundancy . . . . . . . . . . . . . . . . . . >> 16 >>>=20 >>> 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >> 17 >>>=20 >>> 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >> 18 >>>=20 >>> 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . >> 19 >>>=20 >>> 12. OAM, Control and Management . . . . . . . . . . . . . . . . . >> 20 >>>=20 >>> 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . >> 21 >>>=20 >>> 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . . >> 22 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 2] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . >> 23 >>> 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . . >> 23 >>> 15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . . >> 23 >>> 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . . >> 24 >>>=20 >>> 16. Other considerations . . . . . . . . . . . . . . . . . . . . . >> 25 >>>=20 >>> 17. Security Considerations . . . . . . . . . . . . . . . . . . . >> 26 >>>=20 >>> 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . >> 27 >>>=20 >>> 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . >> 28 >>>=20 >>> 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . >> 29 >>> 20.1. Normative References . . . . . . . . . . . . . . . . . . . >> 29 >>> 20.2. Informative References . . . . . . . . . . . . . . . . . . >> 29 >>>=20 >>> Appendix 1. Routing extensions for Timing-aware Routers . . . . . >> 32 >>>=20 >>> Appendix 2. Signaling Extensions for Creating Timing LSPs . . . . >> 33 >>>=20 >>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . >> 34 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 3] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in >> this >>> document are to be interpreted as described in RFC2119 [RFC2119]. >>>=20 >>> When used in lower case, these words convey their typical use in >>> common language, and are not to be interpreted as described in >>> RFC2119 [RFC2119]. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 4] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 1. Introduction >>>=20 >>> The objective of Precision Time Protocol (PTP) and Network Timing >>> Protocol (NTP) are to synchronize independent clocks running on >>> separate nodes of a distributed system. >>>=20 >>> [IEEE-1588] defines PTP messages for frequency, phase and time >>> synchronization. The PTP messages include PTP PDUs over UDP/IP >>> (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex F >> of >>> [IEEE-1588]). >>>=20 >>> SB> Sure BUT it is acknowledged that IEEE is open to the definition >>> SB> of other PTP mappings if they provide better optimisation. >>>=20 >>> This document defines mapping and transport of the PTP >>> messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP >>> defines several clock types: ordinary clocks, boundary clocks, end- >>> to-end transparent clocks, and peer-to-peer transparent clocks. >>> Transparent clocks require intermediate nodes to update correction >>> field inside PTP message that reflects the transit time in the >> node. >>>=20 >>> [RFC5905] defines NTP messages for clock and time synchronization. >>> The PTP messages (PDUs) are transported over UDP/IP. This document >>> SB> Should that be NTP messages? >>> SB> It needs to be made clear as soon as you introduce NTP that >>> SB> they use different time representations. >>>=20 >>> defines mapping and transport of the NTP messages defined in >>> [RFC5905] over MPLS networks. >>>=20 >>> One key attribute of all of these Timing messages is that the Time >>> stamp processing should occur as close as possible to the actual >>> transmission and reception at the physical port interface. This >>> targets optimal time and/or frequency recovery by avoiding variable >>> delay introduced by queues internal to the clocks. >>>=20 >>> SB> As I recall NTP has no epoch point defined, and I am not sure >>> SB> where that point is in the case of PTP in this mapping >>> SB> Hopefully this will get defined in due course. >>>=20 >>> To facilitate the fast and efficient recognition of Timing messages >>> at the port level when the Timing messages are carried over MPLS >>> LSPs, >>>=20 >>> SB> Over a new LSP type with time optimied characteristics >>>=20 >>> this document defines the specific encapsulations that should >>> be used. >>> SB> Hopefully it will also define the PHP >>>=20 >>> In addition, it can be expected that there will exist LSR/ >>> LERs where only a subset of the physical ports will have the port- >>> based Timing message processing capabilities. >>> SB> Do you need to clarify that this only works at base and not in >>> SB> a label heirarchy. >>>=20 >>>=20 >>> In order to ensure >>> that the LSPs carrying Timing packets always enter and exit ports >>> with this capability, routing extensions are defined to advertise >>> this capability on a port basis and to allow for the establishment >> of >>> LSPs that only transit such ports. While this path establishment >>> restriction may be applied only at the LER Ingress and/or egress >>> ports, it becomes more important when using transparent clock >> capable >>> LSRs in the path. >>> SB> I do not understand the implications of the last >>> SB> sentences - starting ", it becomes" >>>=20 >>>=20 >>> Port based Timing message processing involves Timing message >>> recognition. Once the Timing messages are recognized they can be >>> modified based on the reception or transmission Time-stamp. >>>=20 >>> This document provides two methods for transporting Timing messages >>> over MPLS. One is applicable to MPLS environment and the other one >>> is applicable to MPLS/MPLS-TP environment >>>=20 >>> SB> I think the sentence is incomplete. >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 5] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> The solution involves transporting Timing messages over dedicated >>> LSPs called Timing LSPs. These LSPs carry Timing messages and MAY >>> carry Management and control messages, but not data plane client >>> traffic. >>>=20 >>> SB> It is not clear why this restriction applies. >>>=20 >>> Timing LSPs can be established statically or via signaling. >>> SB> s/statically/by provisioning/network management/ >>>=20 >>> Extensions to control plane (OSPF, ISIS, etc.) is required to >> enable >>> routers to distribute their Timing processing capabilities over >> MPLS >>> to other routers. However such extensions are outside the scope of >>> this document. >>>=20 >>> When signaling is used to setup the PTP LSP, Extensions to >> signaling >>> SB> is it a PTP LSP or a Timing LSP? >>>=20 >>> protocols (e.g., RSVP-TE) are required for establishing PTP LSPs. >>> However such extensions are outside the scope of this document. >>>=20 >>> SB> for mpls-tp GMPLS is the signalling protocol >>>=20 >>> While the techniques included herein allow for the establishment of >>> paths optimized to include Time-stamping capable links, the >>> performance of the Slave clocks is outside the scope of this >>> document. >>>=20 >>> At the time of publishing this specification, Transparent Clocking >>> (TC) is only defined for PTP. Therefore at this time any part of >>> this specification that talks about Transparent Clocking applies >> only >>> to PTP. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 6] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 2. Terminology >>>=20 >>> 1588: The timing and synchronization as defined by IEEE 1588. >>>=20 >>> SB> I think that there is a more formal name for the 1588 group >>> SB> that needs to be used here. >>> SB> Also do we need to talk about 1588-200? as there is >>> SB> an update in progress >>>=20 >>> NTP: The timing and synchronization protocol defined by IETF RFC- >> 1305 >>> and RFC-5905. >>>=20 >>> PTP: The timing and synchronization protocol used by 1588. >>> SB> need the proper name for 1588 >>>=20 >>> Master Clock: The source of 1588 timing to a set of slave clocks. >>>=20 >>> Master Port: A port on a ordinary or boundary clock that is in >> Master >>> state. This is the source of timing toward slave ports. >>>=20 >>> SB> I am not sure the reader knows what a port is >>>=20 >>> Slave Clock: A receiver of 1588 timing from a master clock. >>>=20 >>> Slave Port: A port on a boundary clock or ordinary clock that is >>> receiving timing from a master clock. >>>=20 >>> Ordinary Clock: A device with a single PTP port. >>>=20 >>> Transparent Clock. A device that measures the time taken for a PTP >>> event message to transit the device and then updates the >>> correctionField of the message with this transit time. >>>=20 >>> Boundary Clock: A device with more than one PTP port. Generally >>> boundary clocks will have one port in slave state to receive timing >>> and then other ports in master state to re-distribute the timing. >>>=20 >>> PTP LSP: An LSP dedicated to carry PTP messages >>>=20 >>> SB> PTP or timing? >>>=20 >>>=20 >>> PTP PW: A PW within a PTP LSP that is dedicated to carry PTP >>> messages. >>>=20 >>> SB> Ah I don't think that PWE3 know what one of these is >>>=20 >>> CW: Pseudowire Control Word >>>=20 >>> LAG: Link Aggregation >>>=20 >>> ECMP: Equal Cost Multipath >>>=20 >>> CF: Correction Field, a field inside certain PTP messages (message >>> type 0-3)that holds the accumulative transit time inside >> intermediate >>> switches >>>=20 >>> Timing messages: Timing Protocol messages that are exchanged >> between >>> routers in order to establish a synchronized clock. >>>=20 >>> SB> A number of these definitions look like copies of IEEE1588 >>> SB> definitions. We need to provide references and note the >>> SB> priority of the IEEE base reference. >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 7] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 3. Problem Statement >>>=20 >>> [IEEE-1588] has defined methods for transporting PTP messages over >>> Ethernet and IP networks. [RFC5905] has defined the method of >>> transporting NTP messages over IP networks. There is a need to >>> transport Timing messages over MPLS networks while supporting the >>> Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC) >>> functionality in the LER and LSRs in the MPLS network. >>>=20 >>> There are multiple ways of transporting Timing over MPLS. However, >>> there is a requirement to limit the possible encapsulation options >> to >>> simplify the Timing message identification and processing required >> at >>> the port level. >>>=20 >>> When Timing-awareness is needed, Timing messages should not be >>> transported over LSPs or PWs that are carrying customer traffic >>> because LSRs perform Label switching based on the top label in the >>> stack. >>>=20 >>> SB> Have you explained why? >>>=20 >>> To detect Timing messages inside such LSPs require special >>> hardware to do deep packet inspection at line rate. Even if such >>> hardware exists, the payload can't be deterministically identified >> by >>> LSRs because the payload type is a context of the PW label, and the >>> PW label and its context are only known to the Edge routers (PEs/ >>> LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, >> CES, >>> etc). Even if one restricts an LSP to only carry Ethernet PWs, the >>> LSRs dont have the knowledge of whether PW Control Word (CW) is >>> present or not and therefore can not deterministically identify the >>> payload. >>>=20 >>> A generic method is defined in this document that does not require >>> deep packet inspection at line rate, and can deterministically >>> identify Timing messages. This method can be used to detect Timing >>> Messages in both one-step and two-step clock implementations of >>> ordinary, boundary and transparent clocks. >>>=20 >>> SB> Needs a ref and I am sure many MPLS specialists will not >> understand >>> SB> the msg types. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 8] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 4. Timing over MPLS Architecture >>>=20 >>> Timing messages are exchange between Timing ports on ordinary and >>>=20 >>> SB> Have you defined a timing port? >>>=20 >>> boundary clocks. Boundary clocks terminate the Timing messages and >>> act as master for other boundary clocks or for slave clocks. End- >> to- >>> End Transparent clocks do not terminate the Timing messages but >> they >>> do modify the contents of the Timing messages as they transit >> across >>> the transparent clock. >>>=20 >>> Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent >> Clock >>>=20 >>> (TC) could be implemented in either LERs or LSRs. >>>=20 >>> SB> LER and LSR need to be expanded >>>=20 >>> An example is shown in Figure 1, where the LERs act as Ordinary >> Clock >>> (OC) and are the initiating/terminating point for Timing messages. >>> The ingress LER encapsulates the Timing messages in Timing LSP and >>> the Egress LER terminates the Timing LSP. The LSRs act as >>> Transparent Clock (TC) and just update the Timing field in the >> Timing >>> messages. >>>=20 >>>=20 >>> +--------+ +-------+ +-------+ +-------+ +------ >> --+ >>> |Switch, | | | | | | | >> |Switch, | >>> | Router |-----| LER |-----| LSR |-----| LER |-----| >> Router | >>> | | | OC | | TC | | OC | | >> | >>> +--------+ +-------+ +-------+ +-------+ +------ >> --+ >>> / \ >>> +-------+ / \ +------- >> + >>> | LER | / \ | LER >> | >>> | Master|---/ \---| Slave >> | >>> | Clock | | Clock >> | >>> +-------+ +------- >> + >>>=20 >>> Figure (1) - Deployment example 1 of timing over MPLS network >>>=20 >>> Another example is shown in Figure2, where LERs terminate the >> Timing >>> messages received from switch/routers that are outside of the MPLS >>> network acting as OC or BC. In this example LERs regenerate the >>> clock and initiate timing messages encapsulated in Timing LSP >> toward >>> the MPLS network, while the LSRs act as Transparent Clock (TC) and >>> just update the Timing field in the Timing messages, which are >>> already encapsulated in Timing LSPs. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 9] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> +--------+ +-------+ +-------+ +-------+ +------- >> -+ >>> |Switch, | | | | | | | |Switch, >> | >>> | Router |-----| LER |-----| LSR |-----| LER |-----| Router >> | >>> | OC/BC | | BC | | TC | | BC | | OC/BC >> | >>> +--------+ +-------+ +-------+ +-------+ +------- >> -+ >>>=20 >>> Figure (2) - Deployment example 2 of timing over MPLS network >>>=20 >>>=20 >>> Another example is shown in Figure 3, where LERs do not terminate >> the >>> Timing messages received from switch/routers that are outside of >> the >>> MPLS network acting as OC, TC or BC. The LERs act as TC and update >>> the Timing field in the Timing messages as they transit the LER, >>> while encapsulating them in timing LSP. The LSRs also act as >>> Transparent Clock (TC) and just update the Timing field in the >> Timing >>> messages which are already encapsulated in Timing LSPs. >>>=20 >>> +--------+ +-------+ +-------+ +-------+ +------ >> --+ >>> |Switch, | | | | | | | >> |Switch, | >>> | Router |-----| LER |-----| LSR |-----| LER |-----| >> Router | >>> |OC/TC/BC| | TC | | TC | | TC | >> |OC/TC/BC| >>> +--------+ +-------+ +-------+ +-------+ +------ >> --+ >>>=20 >>> Figure (3) - Deployment example 3 of timing over MPLS network >>>=20 >>> Another example is shown in Figure 4, where LERs and LSRs support >>> Boundary Clocks. A single-hop LSP is created between two adjacent >>> LSRs engaged in BC operation. Other methods such as PTP transport >>> over Ethernet MAY be used for transporting timing messages if the >>> link between the two routers is Ethernet. >>>=20 >>> +--------+ +-------+ +-------+ +-------+ +------- >> -+ >>> |Switch, | | | | | | | |Switch, >> | >>> | Router |-----| LER |-----| LSR |-----| LER |-----| Router >> | >>> | OC/BC | | BC | | BC | | BC | | OC/BC >> | >>> +--------+ +-------+ +-------+ +-------+ +------- >> -+ >>>=20 >>> Figure (4) - Deployment example 3 of timing over MPLS network >>>=20 >>> An MPLS domain MAY serve multiple customers. In these cases the >> MPLS >>> domain (maintained by a service provider) may provide timing >> services >>> to multiple customers, each having their own Timing domain. >>>=20 >>> The Timing over MPLS architecture assumes full mesh of Timing LSPs >>> between all LERs supporting this specification. >>>=20 >>> SB> Note sure this is right - the salves surely do not need to >>> SB> exchange timing amongst themselves >>>=20 >>> It supports >>> Point-to- point (VPWS) and Multipoint (VPLS) services. >>>=20 >>> SB> What does that mean? You do not carry user data traffic? >>> SB> Maybe it's the ordering of the statemnets that is causing >>> SB> confusion. >>>=20 >>> This means >>> that a customer may purchase a Point-to-point Timing service >> between >>> two customer sites or a Multipoint Timing service between more than >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 10] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> two customer sites. >>>=20 >>> The Timing over MPLS architecture supports P2P or P2MP Timing LSPs. >>> This means that the Timing Multicast messages such as PTP Multicast >>> event messages can be transported over P2MP Timing LSP or be >>> replicated and transported over many P2P Timing LSPs. >>>=20 >>> SB> Note we do not yet have a definition of a P2MP mpls-tp LSP >>> SB> nor a P2MP PW, although we are close. >>>=20 >>> Timing messages, that do not require Time stamping or Correction >>> Field update MAY be transported over Timing LSPs to simplify >> hardware >>> and software. >>>=20 >>> PTP Announce messages that determine the Timing LSP terminating >> point >>> behavior such as BC/OC/TC SHOULD be transported over the Timing LSP >>> to simplify hardware and software. >>>=20 >>> SB> have you defined and referenced PTP announce msgs? >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 11] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 5. Dedicated LSPs for Timing messages >>>=20 >>> Many methods have been considered for identifying the Timing >> messages >>> when they are encapsulated in MPLS such as using GAL/G-ACH or a new >>> reserved label. These methods were not attractive since they >> either >>> required deep packet inspection at line rate in the intermediate >> LSRs >>> or they required use of a scarce new reserved label. Also one of >> the >>> goals was to reuse existing OAM mechanisms. >>>=20 >>> SB> RLs =3D SPLs are not so rare now. In any case needs a ref. >>>=20 >>> The method defined in this document can be used by LER and LSRs to >>> identify Timing messages in MPLS tunnels by just looking at the top >>> label in the MPLS label stack, which only carry Timing messages as >>> well as OAM, but not data plane client traffic. >>>=20 >>> Compliant implementations MUST use dedicated LSPs to carry Timing >>> messages over MPLS. >>>=20 >>> SB> I think that we need a definition of the properies of these LSPs >>>=20 >>> These LSPs are herein referred to as "Timing >>> LSPs" and the labels associated with these LSPs as "Timing LSP >>> labels". The Timing LSPs that runs between Ingress and Egress LERs >>> MUST be co-routed. Alternatively, a single bidirectional co-routed >>> LSP can be used. >>>=20 >>> SB> I though that you said you could use M2MP LSPs - these are not >>> SB> bidirectional. >>>=20 >>> Co-routing of the two directions is required to limit the >> difference >>> in the delays in the Master clock to Slave clock direction compared >>> to the Slave clock to Master clock direction. The Timing LSP MAY >> be >>> MPLS/MPLS-TP LSP. >>>=20 >>> The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS. >>> New Extensions to RSVP-TE/GMPLS TLVs are required; however they are >>> outside the scope of this document. >>>=20 >>> The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such >> as >>> BFD and LSP Ping but the LSP data plane client plane traffic MUST >> be >>> Timing packets only. >>>=20 >>> SB> Why? >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 12] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 6. Timing over LSP Encapsulation >>>=20 >>> The encapsulations is not LSP is it? >>>=20 >>> This document defines two methods for carrying Timing messages over >>> MPLS. The first method is carrying UDP/IP encapsulated Timing >>> messages over Timing LSPs, and the second method, is carrying >>> Ethernet encapsulated Timing messages over Ethernet PWs inside >> Timing >>> LSPs. >>>=20 >>> 6.1. Timing over UDP/IP over MPLS Encapsulation >>>=20 >>> The simplest method of transporting Timing messages over MPLS is to >>> encapsulate Timing PDUs in UDP/IP and then encapsulate them in >> Timing >>> LSP. This format is shown in Figure 4. >>>=20 >>>=20 >>> +----------------------+ >>> | Timing LSP Label | >>> +----------------------+ >>> | IPv4/6 | >>> +----------------------+ >>> | UDP | >>> +----------------------+ >>> | Timing PDU | >>> +----------------------+ >>>=20 >>> Figure (4) - Timing over UDP/IP over MPLS Encapsulation >>>=20 >>>=20 >>> This encapsulation is very simple and is useful when the network >>> between Timing Master Clock and Slave Clock is MPLS network. >>>=20 >>> SB> Simple is a judgement call >>>=20 >>> In order for an LER/LSR to process Timing messages, the Timing LSP >>> Label must be at the top label of the label stack. The LER/LSR >> MUST >>> know that the Timing LSP Label is used for carrying Timing >> messages. >>> This can be accomplished via static configuration or via RSVP-TE >>> signaling. >>>=20 >>> The UDP/IP encapsulation of PTP MUST follow Annex D and E of >>> [IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow >>> [RFC5905]. >>>=20 >>> 6.2. Timing over PW Encapsulation >>>=20 >>> Another method of transporting Timing over MPLS networks is by >>> encapsulating Timing PDUs in PW which in turn is transported over >>> Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448], >>> shown in Fig 5(A) MUST be used and the Ethernet encapsulation of >> PTP >>> MUST follow Annex F of [IEEE-1588]. >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 13] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> The RAW mode or Tagged mode defined in [RFC4448] MAY be used and >> the >>> Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The >>> Timing over PW encapsulation MUST use the Control Word (CW) as >>> specified in [RFC4448] to ensure proper detection of PTP messages >>> inside the MPLS packets for Timing over LSP and Timing over PW >>> encapsulation. >>>=20 >>> SB> That needs explanation >>>=20 >>> The use of Sequence Number in the CW is optional. >>>=20 >>> SB> Given that s/n are never in practice deployed, you could probably >>> SB> simplify things by sayig that they are not used. >>>=20 >>> Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over >> PW >>> (the IP PW discussed in [RFC4447]) shown in Fig 5(B). >>>=20 >>> +----------------+ +----------------+ >>> |Timing LSP Label| |Timing LSP Label| >>> +----------------+ +----------------+ >>> | PW Label | | PW Label | >>> +----------------+ +----------------+ >>> | Control Word | | IP | >>> +----------------+ +----------------+ >>> | Ethernet | | UDP | >>> | Header | +----------------+ >>> +----------------+ | Timing PDU | >>> |S-VLAN(Optional)| | | >>> +----------------+ +----------------+ >>> |C-VLAN(Optional)| (B) >>> +----------------+ >>> | Timing PDU | >>> | | >>> +----------------+ >>> (A) >>>=20 >>> Figure (5) - Timing over PW Encapsulations >>>=20 >>> In order for an LSR to process PTP messages, the top label of the >>> label stack (the Tunnel Label) MUST be a Timing label. >>>=20 >>> S> You said that before. >>>=20 >>> 6.3. Other Timing Encapsulation methods >>>=20 >>> In future other timing encapsulation methods may be introduced, >> such >>> as a new shim header after the Bottom of Stack to carry the Timing >>> information. Such new encapsulations are outside the scope of this >>> document. >>>=20 >>>=20 >>> SB> Taking a pure MPLS pov, you can simplify a lot of the text >>> SB> out of the definition of the LSP >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 14] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> SB> I think we need a section on LSP processing >>>=20 >>> 7. Timing message Processing >>>=20 >>> Each Timing protocol such as PTP and NTP, define their set of >> Timing >>> messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, >>> FOLLOW_UP, etc messages. >>>=20 >>> Some of the Timing messages require time stamping or correction >> field >>> update at port level and some dont. It is the job of the LER/LSR >> to >>> parse the timing message and find out the type of the Timing >> message >>> and decide whether and how to Time- stamp it (e.g., BC) or update >>> correction field(e.g., TC). >>>=20 >>>=20 >>> SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing >>> SB> function rather than the LER? >>>=20 >>> For example the following PTP messages (called Event messages) >>> require time-stamping or correction field update: >>>=20 >>> o SYNC >>>=20 >>> o DELAY_REQ (Delay Request) >>>=20 >>> o PDELAY_REQ (Peer Delay Request) >>>=20 >>> o PDELAY_RESP (Peer Delay Response) >>>=20 >>> SYNC and DELAY_REQ are exchanged between Master Clock and Slave >> Clock >>> and MUST be transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP >>> are exchanged between adjacent PTP clocks (i.e. Master, Slave, >>> Boundary, or Transparent) and SHOULD be transported over single hop >>> PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP, >>> and PDELAY_RESP_FOLLOW_UP messages MUST also be transported over >> the >>> PTP LSPs. >>>=20 >>> For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be >>> transported over two PTP LSPs that are in opposite directions. >> These >>> PTP LSPs, which are in opposite directions MUST be congruent and >> co- >>> routed. Alternatively, a single bidirectional co-routed LSP can be >>> used. >>>=20 >>> Except as indicated above for the two-step PTP clocks, Non-Event >> PTP >>> message types do not need to be processed by intermediate routers. >>> These message types MAY be carried in PTP Tunnel LSPs. >>>=20 >>> SB> Are you saying that a timing P router has to be msg type >> sensitive? >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 15] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 8. Protection and Redundancy >>>=20 >>>=20 >>> SB> This is a bit of a jump - I don't know how the LSP itself works >> yet! >>>=20 >>> In order to ensure continuous uninterrupted operation of slave >>> clocks, usually as a general practice, slave clocks (or ports) >> track >>> redundant master clocks. >>>=20 >>> It is the responsibility of the network operator to ensure that >>> physically disjoint Timing LSPs are established between a slave >> clock >>> (or port) and redundant master clocks (or ports). >>>=20 >>> When a slave clock (or port) listens to redundant master clocks or >>> ports, any prolonged Timing LSP outage will trigger the slave clock >>> or port to switch to a redundant master clock or port. >>>=20 >>> LSP/PW protection such as Linear protection Switching (1:1, 1+1), >>> Ring protection switching or MPLS Fast Reroute (FRR) generally >> switch >>> alternative path that usually cause a change in delay, which if >>> undetected by slave clock can reduce accuracy of the slave clock. >>>=20 >>> Therefore protection switching MAY be used, as long as phase jumps >>> upon switchover due to differences in path latency are detected and >>> compensated for (such compensation not being required if BCs or >> peer- >>> peer TCs are used throughout). >>>=20 >>> Note that any protection or reroute mechanism that adds additional >>> MPLS label to the label stack, such as Facility Backup Fast >> Reroute, >>> MUST ensure that the pushed label is also a Timing Label to ensure >>> recognition of the MPLS frame as containing Timing messages, as it >>> transits the backup path. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 16] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 9. ECMP >>>=20 >>> To ensure the optimal operation of slave clocks and avoid error >>> introduced by forward and reverse path delay asymmetry, the >> physical >>> path for Timing messages from master clock to slave Clock and vice >>> versa must be the same for all Event Timing messages listed in >>> section 7. >>>=20 >>> Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost >>> Multipath). >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 17] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 10. PHP >>>=20 >>> To ensure that the label on the top of the label stack is the >> Timing >>> LSP Label, PHP MUST not be used. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 18] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 11. Entropy >>>=20 >>> To ensure all Timing messages in a Timing LSP take the same path, >>> Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and >>> Entropy Label MUST NOT be used for the PWs that are carried inside >>> Timing LSP [RFC6391]. >>>=20 >>> SB> This is incorrect - you mean that all msgs of the same timing >>> SB> flow need to have the same EL value. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 19] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 12. OAM, Control and Management >>>=20 >>> In order to monitor Timing LSPs and their encapsulated PWs, they >> MUST >>> be able to carry OAM and management messages. These management >>> messages MUST be differentiated from Timing messages via already >>> defined IETF methods. >>>=20 >>> For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY run >>> over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These >>> Management protocols can easily be identified by the UDP >> Destination >>> Port number or by GAL/G-ACH respectively. >>>=20 >>> Also BFD, LSP-Ping and other management messages MAY run over the >> PWs >>> encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3 >> or >>> 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is >> going >>> to be deprecated by IETF). In this case G-ACH, PW label (TTL=3D1) or >>> GAL-ACH are used to identify such management messages. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 20] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 13. QoS Considerations >>>=20 >>> In network deployments where not every LSR/LER is Timing-aware, it >> is >>> important to reduce the impact of the non-Timing-aware LSR/LERs on >>> the timing recovery in the slave clock. The Timing messages are >> time >>> critical and must be treated with the highest priority. Therefore >>> Timing over MPLS messages must be treated with the highest priority >>> in the routers. This can be achieved by proper setup of Timing >> LSPs. >>>=20 >>> It is recommended that the Timing LSPs are setup or configured >>> properly to indicate EF-PHB [RFC3246]for the CoS and Green >> [RFC2697] >>> for drop eligibility. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 21] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 14. FCS and Checksum Recalculation >>>=20 >>> When time-stamp generation and timing packet adjustment is >> performed >>> near the physical port hardware, the process MUST include >>> recalculation of the Ethernet FCS. >>>=20 >>> SB> The above is confusing - an LSR always recomputes the link layer >>> SB> CRC which may or may not be Ethernet. >>>=20 >>> Also FCS retention for the >>> payload Ethernet described in [RFC4720] MUST NOT be used. >>>=20 >>> For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum >>> may be required as per UDP transport standards. >>>=20 >>> SB> You really need to be working on getting the IPv6 C?S computation >>> SB> removed from PTP msgs. >>>=20 >>> When UDP checksum is used, each Timing-aware LER/LSR must either >>> incrementally update the UDP checksum after Time stamping or >>> Correction Field update or verify the UDP checksum on reception >> from >>> upstream and recalculate the checksum completely on transmission to >>> downstream node after Time stamping or Correction Field update. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 22] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 15. Behavior of LER/LSR >>>=20 >>> Timing-capable/aware LERs and LSRs are routers that have one or >> more >>>=20 >>> SB> You mean physical interfaces? >>>=20 >>> interfaces that can perform Timing operations (OC/BC/TC) on Timing >>> packets and are configured to do so. Timing-capable/aware LERs and >>> LSRs can advertise their Timing-capability per-interface via >> control >>> plane such as OSPF or IS-IS. >>> SB> ISIS and OSPF are routing protocols. >>>=20 >>> The Timing-capable/aware LERs can then >>> signals Timing LSPs via RSVP-TE signaling. Alternatively the >> Timing >>> capability of LER and LSRs may be configured in a centralized >>> controller and the Timing LSP may be setup using manual >> configuration >>> or other methods such as SDN. >>>=20 >>> SB> it can also be configured individually rather then through >>> SB> a cebtral controllwe >>>=20 >>> 15.1. Behavior of Timing-capable/aware LER >>>=20 >>> When a Timing-capable/aware LER behaves as a Transparent clock and >>> receives a Timing message from a Timing-capable/aware non-MPLS >>> interface, the LER updates the Correction Field (CF) and >> encapsulates >>> and forwards the timing message over previously established Timing >>> LSP. >>>=20 >>> SB> You need to call out the details so that people properly >>> SB> understand the definition of the new LSP. >>>=20 >>> Also when a Timing message is received from a Timing-capable/ >>> aware MPLS interface, LER updates the Correction Filed (CF) and >>> decapsulates the MPLS encapsulation and forwards the timing message >>> to a non-MPLS interface. >>>=20 >>> When a Timing-capable/aware LER behaves as a Boundary clock and >>> receives a Timing message from a Timing-capable/aware non MPLS >>> interface, the LER Timestamps the Timing packet and sends it to the >>> LERs Boundary clock processing module. Also when a Timing message >> is >>> received from a Timing- capable/aware MPLS interface, the LER >>> Timestamps the Timing packet and sends it to the LERs Boundary >> clock >>> processing module. >>>=20 >>> When a Timing-capable/aware LER behaves as an Ordinary Clock toward >>> the MPLS network, and receives a Timing message from a Timing- >>> capable/aware MPLS interface, the LER Timestamps the Timing packet >>> and sends it to the LERs Ordinary clock processing module. >>>=20 >>> 15.2. Behavior of Timing-capable/aware LSR >>>=20 >>> When a Timing-capable/aware LSR behaves as a Transparent clock and >>> receives a Timing message from a Timing-capable/aware MPLS >> interface, >>> The LSR updates the Correction Filed (CF) and forwards the timing >>> message over another MPLS interface. >>>=20 >>> When a Timing-capable/aware LSR behaves as a Boundary clock and >>> receives a Timing message from a Timing-capable/aware MPLS >> interface. >>> The LSR performs the functions of a Boundary Clock in terminating >> the >>> received Timing message and re-generating a new timing message over >>> another (or the same) MPLS interface. >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 23] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 15.3. Behavior of non-Timing-capable/aware LSR >>>=20 >>> It is most beneficial when all LSRs in the path of a Timing LSP be >>> timing-Capable/aware LSRs. This would ensure the highest quality >>> time and clock synchronization by Timing Slave Clocks. However, >> this >>> specification does not mandate that all LSRs in path of a Timing >> LSP >>> be Timing- capable/aware. >>>=20 >>> Non-Timing-capable/aware LSRs just switch the packets encapsulated >> in >>> Timing LSPs and dont perform any Timing operation (TC or BC). >>> However as explained in QoS section the Timing over MPLS packets >> MUST >>> be still be treated with the highest priority based on their >> Traffic >>> Class (TC) marking. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 24] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 16. Other considerations >>>=20 >>> [IEEE-1588] defines an optional peer-to-peer Transparent clocking >>> that requires peer delay measurement between two adjacent Timing- >>> capable/ aware routers/switches. Peer delay measurement messages >>> need to be time stamped and terminated by the Timing-capable/aware >>> routers/ switches. This means that two adjacent LSRs may be >> engaged >>> in a peer delay measurement. >>>=20 >>> For transporting such peer delay measurement messages a single-hop >>> LSP SHOULD to be created between the two adjacent LSRs engaged in >>> peer delay measurement to carry peer delay measurement messages. >>> Other methods such as PTP transport over Ethernet MAY be used for >>> transporting peer delay measurement messages if the link between >> the >>> two routers is Ethernet. >>>=20 >>> In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ >> ware >>> routers/switches MUST maintain a list of all the neighbors it needs >>> to send a PDelay_Req to, where each neighbor corresponds to a >> timing >>> LSP. >>>=20 >>> The use of Explicit Null Label (Label=3D 0 or 2) is acceptable as >> long >>> as either the Explicit Null label is the bottom of stack label >>> (applicable only to UDP/IP encapsulation) or the label below the >>> Explicit Null label is a PTP label. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 25] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 17. Security Considerations >>>=20 >>> MPLS PW security considerations in general are discussed in >> [RFC3985] >>> and [RFC4447],and those considerations also apply to this document. >>>=20 >>> An experimental security protocol is defined in [IEEE-1588].The PTP >>> security extension and protocol provides group source >> authentication, >>> message integrity, and replay attack protection for PTP messages. >>>=20 >>> When the MPLS network (provider network) serves multiple customers, >>> it is important to maintain and process each customers clock and >>> Timing messages separately from other customers to ensure there is >> no >>> cross- customer effect. For example if an LER BC is synchronized >> to >>> a specific grandmaster, belonging to customer A, then the LER MUST >>> use that BC clock only for customer A to ensure that customer A >>> cannot attack other customers by manipulating its time. >>>=20 >>> Timing messages MAY be encrypted or authenticated, provided that >> the >>> LERs/LSRs that are Timing capable/aware can authenticate/ decrypt >> the >>> timing messages. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 26] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 18. Acknowledgements >>>=20 >>> The authors would like to thank Ron Cohen, Yaakov Stein, Tal >> Mizrahi, >>> Stefano Ruffini, Peter Meyer, and other members of IETF for >> reviewing >>> and providing feedback on this draft. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 27] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 19. IANA Considerations >>>=20 >>> There are no IANA requirements in this specification. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 28] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 20. References >>>=20 >>> 20.1. Normative References >>>=20 >>> [IEEE-1588] >>> IEEE 1588-2008, "IEEE Standard for a Precision Clock >>> Synchronization Protocol for Networked Measurement and >>> Control Systems". >>>=20 >>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >>> Requirement Levels", BCP 14, RFC 2119, March 1997. >>>=20 >>> [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- >>> Edge (PWE3) Architecture", RFC 3985, March 2005. >>>=20 >>> [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor >> Discovery >>> Proxies (ND Proxy)", RFC 4389, April 2006. >>>=20 >>> [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. >>> Heron, "Pseudowire Setup and Maintenance Using the Label >>> Distribution Protocol (LDP)", RFC 4447, April 2006. >>>=20 >>> [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, >>> "Encapsulation Methods for Transport of Ethernet over >> MPLS >>> Networks", RFC 4448, April 2006. >>>=20 >>> [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire >>> Emulation Edge-to-Edge (PWE3) Frame Check Sequence >>> Retention", RFC 4720, November 2006. >>>=20 >>> [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit >>> Connectivity Verification (VCCV): A Control Channel for >>> Pseudowires", RFC 5085, December 2007. >>>=20 >>> [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding >> Detection >>> (BFD)", RFC 5880, June 2010. >>>=20 >>> [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, >>> "Bidirectional Forwarding Detection (BFD) for MPLS Label >>> Switched Paths (LSPs)", RFC 5884, June 2010. >>>=20 >>> 20.2. Informative References >>>=20 >>> [I-D.ietf-pwe3-fat-pw] >>> Bryant, S., Filsfils, C., Drafz, U., Kompella, V., >> Regan, >>> J., and S. Amante, "Flow Aware Transport of Pseudowires >>> over an MPLS Packet Switched Network", >>> draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011. >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 29] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate >>> system routeing information exchange protocol for use in >>> conjunction with the Protocol for providing the >>> Connectionless-mode Network Service (ISO 8473)". >>>=20 >>> [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and >>> dual environments", RFC 1195, December 1990. >>>=20 >>> [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. >>>=20 >>> [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color >>> Marker", RFC 2697, September 1999. >>>=20 >>> [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le >> Boudec, >>> J., Courtney, W., Davari, S., Firoiu, V., and D. >>> Stiliadis, "An Expedited Forwarding PHB (Per-Hop >>> Behavior)", RFC 3246, March 2002. >>>=20 >>> [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic >> Engineering >>> (TE) Extensions to OSPF Version 2", RFC 3630, >>> September 2003. >>>=20 >>> [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate >>> System (IS-IS) Extensions for Traffic Engineering (TE)", >>> RFC 3784, June 2004. >>>=20 >>> [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. >>> Shaffer, "Extensions to OSPF for Advertising Optional >>> Router Capabilities", RFC 4970, July 2007. >>>=20 >>> [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate >>> System to Intermediate System (IS-IS) Extensions for >>> Advertising Router Information", RFC 4971, July 2007. >>>=20 >>> [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi >>> Topology (MT) Routing in Intermediate System to >>> Intermediate Systems (IS-ISs)", RFC 5120, February 2008. >>>=20 >>> [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic >>> Engineering", RFC 5305, October 2008. >>>=20 >>> [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, >>> "Traffic Engineering Extensions to OSPF Version 3", >>> RFC 5329, September 2008. >>>=20 >>> [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF >>> for IPv6", RFC 5340, July 2008. >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 30] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, >> "Network >>> Time Protocol Version 4: Protocol and Algorithms >>> Specification", RFC 5905, June 2010. >>>=20 >>> [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., >> Regan, >>> J., and S. Amante, "Flow-Aware Transport of Pseudowires >>> over an MPLS Packet Switched Network", RFC 6391, >>> November 2011. >>>=20 >>> [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and >>> L. Yong, "The Use of Entropy Labels in MPLS Forwarding", >>> RFC 6790, November 2012. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 31] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 1. Routing extensions for Timing-aware Routers >>>=20 >>> MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] >> and >>> IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering >> (TE) >>> link information used for constraint-based routing. >>>=20 >>> Indeed, it is useful to advertise data plane TE router link >>> capabilities, such as the capability for a router to be Timing- >> aware. >>> This capability MUST then be taken into account during path >>> computation to prefer or even require links that advertise >> themselves >>> as Timing-aware. In this way the path can ensure the entry and >> exit >>> points into the LERs and, if desired, the links into the LSRs are >>> able to perform port based time-stamping thus minimizing their >> impact >>> on the performance of the slave clock. >>>=20 >>> extensions are required to OSPF and IS-IS in order to advertise >>> Timing-aware capabilities of a link. Such extensions are outside >> the >>> scope of this document; however such extension SHOULD be able to >>> signal the following information per Router Link: >>>=20 >>> o Capable of processing PTP, NTP or other Timing flows >>>=20 >>> o Capable of performing Transparent Clock operation >>>=20 >>> o Capable of performing Boundary Clock operation >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 32] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> 2. Signaling Extensions for Creating Timing LSPs >>>=20 >>> RSVP-TE signaling MAY be used to setup the timing LSPs. When RSVP- >> TE >>> is used to setup Timing LSPs, some information that indicates that >>> the LSP is carrying Timing flows MUST be included in the new >>> Extensions to RSVP-TE: >>>=20 >>> The following information MAY also be included in the new >> Extensions >>> to RSVP-TE: >>>=20 >>> o Offset from Bottom of Stack (BoS) to the start of the Time-stamp >>> field >>>=20 >>> o Number of VLANs in case of PW encapsulation >>>=20 >>> o Timestamp field Type >>>=20 >>> * Correction Field, Timestamp >>>=20 >>> o Timestamp Field format >>>=20 >>> * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit >>> NTP, etc. >>>=20 >>> Note that in case the above optional information is signaled with >>> RSVP-TE for a Timing LSP, all the Timing packets carried in that >> LSP >>> must have the same signaled characteristics. For example if >>> Timestamp format is signaled as 64-bit PTPv1, then all Timing >> packets >>> must use 64-bit PTPv1 time-stamp. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 33] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> Authors' Addresses >>>=20 >>> Shahram Davari >>> Broadcom Corp. >>> San Jose, CA 95134 >>> USA >>>=20 >>> Email: davari@broadcom.com >>>=20 >>>=20 >>> Amit Oren >>> Broadcom Corp. >>> San Jose, CA 95134 >>> USA >>>=20 >>> Email: amito@broadcom.com >>>=20 >>>=20 >>> Manav Bhatia >>> Alcatel-Lucent >>> Bangalore, >>> India >>>=20 >>> Email: manav.bhatia@alcatel-lucent.com >>>=20 >>>=20 >>> Peter Roberts >>> Alcatel-Lucent >>> Kanata, >>> Canada >>>=20 >>> Email: peter.roberts@alcatel-lucent.com >>>=20 >>>=20 >>> Laurent Montini >>> Cisco Systems >>> San Jose CA >>> USA >>>=20 >>> Email: lmontini@cisco.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 34] >=20 >>> Internet-Draft Transporting Timing over MPLS June >> 2013 >>>=20 >>>=20 >>> Luca >>> Cisco Systems >>> San Jose CA >>> USA >>>=20 >>> Email: lmartini@cisco.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Davari, et al. Expires December 17, 2013 [Page >> 35] >=20 >>>=20 >>> -- >>> For corporate legal information go to: >>>=20 >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 >=20 >=20 From gregimirsky@gmail.com Fri Aug 2 09:05:12 2013 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 24FCB21E80AA; Fri, 2 Aug 2013 09:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HTO-amJs1bu; Fri, 2 Aug 2013 09:05:03 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE6B11E80EC; Fri, 2 Aug 2013 09:05:03 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id pb11so862794veb.39 for ; Fri, 02 Aug 2013 09:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2DRL4dvauohU652vU+8NK+DlsZbcPu6JM4Z0Ix83fQg=; b=WfVI9PplvzYUYOE3UzMq8uHom7xyHhma5rcWPwM+60RV0eTWkvXQtw1vAXIz/h8Pay IDo77UIlS6dsB2mAubiwE4+ZTUaZ37+tVgtRCyddtKWzaSKP17EybK1wiNxFCEVchPm2 +/rrYXEW/f3/FalmDZMTOeoA8rCHa27qjZZenusQGz3kjts2kYNtUKxppJYM7Gc4zCSJ x0DgFOD93JBpz4cdeCBO8tjXsfwFlnu0qeiG1ERREBAXX8JtkfvLUZ2OpjLoSwGZw8o3 2fSjOLtlgs20dKXoY2fYZJFHUyiwpkQYAf2AIDI3cYDOLrUMNAqdFcbDwdJMonR6zJG8 plkA== MIME-Version: 1.0 X-Received: by 10.52.37.232 with SMTP id b8mr1829445vdk.80.1375459498670; Fri, 02 Aug 2013 09:04:58 -0700 (PDT) Received: by 10.220.159.143 with HTTP; Fri, 2 Aug 2013 09:04:58 -0700 (PDT) Received: by 10.220.159.143 with HTTP; Fri, 2 Aug 2013 09:04:58 -0700 (PDT) In-Reply-To: References: <51FB8396.9020504@cisco.com> <0182DEA5604B3A44A2EE61F3EE3ED69E2076CBA4@BL2PRD0510MB349.namprd05.prod.outlook.com> Date: Fri, 2 Aug 2013 18:04:58 +0200 Message-ID: From: Greg Mirsky To: Shahram Davari Content-Type: multipart/alternative; boundary=bcaec51d2c10d243ea04e2f91efd Cc: "mpls@ietf.org" , "tictoc-chairs@tools.ietf.org" , tictoc@ietf.org, "draft-ietf-tictoc-1588overmpls@tools.ietf.org" , "rtg-ads@tools.ietf.org" , int-ads@tools.ietf.org, "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Comments on draft-ietf-tictoc-1588overmpls 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, 02 Aug 2013 16:05:12 -0000 --bcaec51d2c10d243ea04e2f91efd Content-Type: text/plain; charset=ISO-8859-1 Hi Shahram, I think that John suggested creation of LSPs interconnecting all 1588-capable nodes. It is absolutely not what current document defines but that reminds me of what I've suggested around November of 2011. Regards, Greg On Aug 2, 2013 6:43 AM, "Shahram Davari" wrote: > Hi John > > In that case I fail to understand the difference between your proposal and > the current draft. > > In both cases you need a special LSP to tell the HW to Timestamp the > packet and I assume you need to use RSVPTE to sign it. That is what the > draft does. > > Regards, > Shahram > > > On Aug 2, 2013, at 12:52 PM, "John E Drake" wrote: > > > Shahram, > > > > The LSPs would be between LSRs that are 1588 capable, so they could be > one or more hops. > > > > Yours Irrespectively, > > > > John > > > > > >> -----Original Message----- > >> From: Shahram Davari [mailto:davari@broadcom.com] > >> Sent: Friday, August 02, 2013 3:24 AM > >> To: > >> Cc: mpls-chairs@tools.ietf.org; tictoc-chairs@tools.ietf.org; int- > >> ads@tools.ietf.org; rtg-ads@tools.ietf.org; draft-ietf-tictoc- > >> 1588overmpls@tools.ietf.org; John E Drake; mpls@ietf.org; > >> tictoc@ietf.org > >> Subject: Re: [mpls] Comments on draft-ietf-tictoc-1588overmpls > >> > >> Hi Stewart > >> > >> We have already looked at similar approach. The issue with one hop LSP > >> is that not all LSRs are 1588 capable. One of the requirements is for > >> non-1588 capable routers to just switch the packet normally. > >> > >> Regards, > >> Shahram > >> > >> > >> On Aug 2, 2013, at 12:02 PM, "Stewart Bryant" > >> wrote: > >> > >>> Talking to John Drake about this, an alternative general > >>> model is for the LSP is that it is an LSP that timestamps > >>> the packet and then passes it to an application associated > >>> with the LSP at that hop. > >>> > >>> This has a lot of merit. > >>> > >>> If however we think about it some more we have a > >>> type of network service chaining going on here and > >>> so we don't need an LSP per say, because the path > >>> and instruction can be in the packet. > >>> > >>> In other words a general solution to the problem > >>> is to define an LSP with the properties that the > >>> packet is passed one hop, timestamped and delivered > >>> to the associated application. > >>> > >>> How this is MPLS construct is used to support time > >>> tranfer is entirely within the scope of TICTOC, but > >>> at the MPLS layer we have a clean reusable network > >>> service. > >>> > >>> - Stewart > >>> > >>> > >>> ============ > >>> SB> This draft does not seem to provide a precise definition > >>> SB> the properties of the new LSP type that it wishes to > >>> SB> define, in particular it does it define the PHB of those > >>> SB> LSPs, nor the full interaction with the MPLS > >>> SB> architecture. > >>> SB> > >>> SB> I have not tracked TICTOC for a while but I thought that > >>> SB> the original plan was to define the concept of an offset > >>> SB> into a packet to do the correction. > >>> SB> > >>> SB> It is disappointing that the opportunity was not taken > >>> SB> to define a timing shim inside the timing LSP so that > >>> SB> a time correction could be added to any packet such that > >>> SB> the MPLS system was isolated from the details of the > >>> SB> complexity of the particular time transfer type. > >>> > >>> SB> I think that much more clarify is needed in terms of > >>> SB> definition of the new LSP type, since it is unclear > >>> SB> from this text how to implement one. > >>> SB> > >>> SB> There are a lot of other MPLS services such as > >>> SB> LSP ping that need to be considered. > >>> SB> > >>> SB> Please see inline for more comments. However these > >>> SB> comments are made in the context of the text as written > >>> SB> whilst I have a fundamental concern that this approach > >>> SB> lacks an MPLS architectural soundness that need > >>> SB> greater thought with significant impact on the > >>> SB> draft. > >>> > >>> - Stewart > >>> > >>> > >>> TICTOC Working Group S. > >> Davari > >>> Internet-Draft A. > >> Oren > >>> Intended status: Standards Track Broadcom > >> Corp. > >>> Expires: December 17, 2013 M. > >> Bhatia > >>> P. > >> Roberts > >>> Alcatel- > >> Lucent > >>> L. > >> Montini > >>> L. > >> Martini > >>> Cisco > >> Systems > >>> June 15, > >> 2013 > >>> > >>> > >>> Transporting Timing messages over MPLS Networks > >>> draft-ietf-tictoc-1588overmpls-05 > >>> > >>> Abstract > >>> > >>> This document defines the method for transporting Timing messages > >>> such as PTP and NTP over an MPLS network. The method allows for > >> the > >>> easy identification of these PDUs at the port level to allow for > >> port > >>> > >>> SB> What is a port > >>> > >>> level processing of these PDUs in both LERs and LSRs. > >>> > >>> The basic idea is to transport Timing messages inside dedicated > >> MPLS > >>> LSPs. These LSPs only carry Timing messages and possibly Control > >> and > >>> Management packets, but they do not carry customer traffic. > >>> > >>> SB> More specifically they only carry traffic associated with the > >>> SB> timing service and its support. > >>> SB> The question arose WRT BFD - surely BFD is allowed, BUT surely > >>> SB> also it gets carried in a structure that causes it to get > >>> SB> timestamped. > >>> > >>> Two methods for transporting Timing messages over MPLS are defined. > >>> > >>> SB> Perhaps the right approach is to define the new LSP type and then > >>> SB> seperately to define the mapping of the various timing services > >>> SB> over that LSP type. > >>> > >>> The first method is to transport Timing messages directly over the > >>> dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for > >>> MPLS networks. The second method is to transport Timing messages > >>> inside a PW via Ethernet encapsulation. > >>> > >>> SB> I think that we should note that there are some > >>> SB> h/w reasons for this preference. A clean sheet approach > >>> SB> would have been to use PTP over MPLS with no intermediate > >>> SB> layers. > >>> > >>> Status of this Memo > >>> > >>> This Internet-Draft is submitted in full conformance with the > >>> provisions of BCP 78 and BCP 79. > >>> > >>> Internet-Drafts are working documents of the Internet Engineering > >>> Task Force (IETF). Note that other groups may also distribute > >>> working documents as Internet-Drafts. The list of current > >> Internet- > >>> Drafts is at http://datatracker.ietf.org/drafts/current/. > >>> > >>> Internet-Drafts are draft documents valid for a maximum of six > >> months > >>> and may be updated, replaced, or obsoleted by other documents at > >> any > >>> time. It is inappropriate to use Internet-Drafts as reference > >>> material or to cite them other than as "work in progress." > >>> > >>> This Internet-Draft will expire on December 17, 2013. > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 1] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> Copyright Notice > >>> > >>> Copyright (c) 2013 IETF Trust and the persons identified as the > >>> document authors. All rights reserved. > >>> > >>> This document is subject to BCP 78 and the IETF Trust's Legal > >>> Provisions Relating to IETF Documents > >>> (http://trustee.ietf.org/license-info) in effect on the date of > >>> publication of this document. Please review these documents > >>> carefully, as they describe your rights and restrictions with > >> respect > >>> to this document. Code Components extracted from this document > >> must > >>> include Simplified BSD License text as described in Section 4.e of > >>> the Trust Legal Provisions and are provided without warranty as > >>> described in the Simplified BSD License. > >>> > >>> > >>> Table of Contents > >>> > >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . > >> 5 > >>> > >>> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . > >> 7 > >>> > >>> 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . > >> 8 > >>> > >>> 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . > >> 9 > >>> > >>> 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . . > >> 12 > >>> > >>> 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . > >> 13 > >>> 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . . > >> 13 > >>> 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . . > >> 13 > >>> 6.3. Other Timing Encapsulation methods . . . . . . . . . . . . > >> 14 > >>> > >>> 7. Timing message Processing . . . . . . . . . . . . . . . . . . > >> 15 > >>> > >>> 8. Protection and Redundancy . . . . . . . . . . . . . . . . . . > >> 16 > >>> > >>> 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > >> 17 > >>> > >>> 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > >> 18 > >>> > >>> 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . > >> 19 > >>> > >>> 12. OAM, Control and Management . . . . . . . . . . . . . . . . . > >> 20 > >>> > >>> 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . > >> 21 > >>> > >>> 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . . > >> 22 > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 2] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . > >> 23 > >>> 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . . > >> 23 > >>> 15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . . > >> 23 > >>> 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . . > >> 24 > >>> > >>> 16. Other considerations . . . . . . . . . . . . . . . . . . . . . > >> 25 > >>> > >>> 17. Security Considerations . . . . . . . . . . . . . . . . . . . > >> 26 > >>> > >>> 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . > >> 27 > >>> > >>> 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . > >> 28 > >>> > >>> 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . > >> 29 > >>> 20.1. Normative References . . . . . . . . . . . . . . . . . . . > >> 29 > >>> 20.2. Informative References . . . . . . . . . . . . . . . . . . > >> 29 > >>> > >>> Appendix 1. Routing extensions for Timing-aware Routers . . . . . > >> 32 > >>> > >>> Appendix 2. Signaling Extensions for Creating Timing LSPs . . . . > >> 33 > >>> > >>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . > >> 34 > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 3] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > >> this > >>> document are to be interpreted as described in RFC2119 [RFC2119]. > >>> > >>> When used in lower case, these words convey their typical use in > >>> common language, and are not to be interpreted as described in > >>> RFC2119 [RFC2119]. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 4] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 1. Introduction > >>> > >>> The objective of Precision Time Protocol (PTP) and Network Timing > >>> Protocol (NTP) are to synchronize independent clocks running on > >>> separate nodes of a distributed system. > >>> > >>> [IEEE-1588] defines PTP messages for frequency, phase and time > >>> synchronization. The PTP messages include PTP PDUs over UDP/IP > >>> (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex F > >> of > >>> [IEEE-1588]). > >>> > >>> SB> Sure BUT it is acknowledged that IEEE is open to the definition > >>> SB> of other PTP mappings if they provide better optimisation. > >>> > >>> This document defines mapping and transport of the PTP > >>> messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP > >>> defines several clock types: ordinary clocks, boundary clocks, end- > >>> to-end transparent clocks, and peer-to-peer transparent clocks. > >>> Transparent clocks require intermediate nodes to update correction > >>> field inside PTP message that reflects the transit time in the > >> node. > >>> > >>> [RFC5905] defines NTP messages for clock and time synchronization. > >>> The PTP messages (PDUs) are transported over UDP/IP. This document > >>> SB> Should that be NTP messages? > >>> SB> It needs to be made clear as soon as you introduce NTP that > >>> SB> they use different time representations. > >>> > >>> defines mapping and transport of the NTP messages defined in > >>> [RFC5905] over MPLS networks. > >>> > >>> One key attribute of all of these Timing messages is that the Time > >>> stamp processing should occur as close as possible to the actual > >>> transmission and reception at the physical port interface. This > >>> targets optimal time and/or frequency recovery by avoiding variable > >>> delay introduced by queues internal to the clocks. > >>> > >>> SB> As I recall NTP has no epoch point defined, and I am not sure > >>> SB> where that point is in the case of PTP in this mapping > >>> SB> Hopefully this will get defined in due course. > >>> > >>> To facilitate the fast and efficient recognition of Timing messages > >>> at the port level when the Timing messages are carried over MPLS > >>> LSPs, > >>> > >>> SB> Over a new LSP type with time optimied characteristics > >>> > >>> this document defines the specific encapsulations that should > >>> be used. > >>> SB> Hopefully it will also define the PHP > >>> > >>> In addition, it can be expected that there will exist LSR/ > >>> LERs where only a subset of the physical ports will have the port- > >>> based Timing message processing capabilities. > >>> SB> Do you need to clarify that this only works at base and not in > >>> SB> a label heirarchy. > >>> > >>> > >>> In order to ensure > >>> that the LSPs carrying Timing packets always enter and exit ports > >>> with this capability, routing extensions are defined to advertise > >>> this capability on a port basis and to allow for the establishment > >> of > >>> LSPs that only transit such ports. While this path establishment > >>> restriction may be applied only at the LER Ingress and/or egress > >>> ports, it becomes more important when using transparent clock > >> capable > >>> LSRs in the path. > >>> SB> I do not understand the implications of the last > >>> SB> sentences - starting ", it becomes" > >>> > >>> > >>> Port based Timing message processing involves Timing message > >>> recognition. Once the Timing messages are recognized they can be > >>> modified based on the reception or transmission Time-stamp. > >>> > >>> This document provides two methods for transporting Timing messages > >>> over MPLS. One is applicable to MPLS environment and the other one > >>> is applicable to MPLS/MPLS-TP environment > >>> > >>> SB> I think the sentence is incomplete. > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 5] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> The solution involves transporting Timing messages over dedicated > >>> LSPs called Timing LSPs. These LSPs carry Timing messages and MAY > >>> carry Management and control messages, but not data plane client > >>> traffic. > >>> > >>> SB> It is not clear why this restriction applies. > >>> > >>> Timing LSPs can be established statically or via signaling. > >>> SB> s/statically/by provisioning/network management/ > >>> > >>> Extensions to control plane (OSPF, ISIS, etc.) is required to > >> enable > >>> routers to distribute their Timing processing capabilities over > >> MPLS > >>> to other routers. However such extensions are outside the scope of > >>> this document. > >>> > >>> When signaling is used to setup the PTP LSP, Extensions to > >> signaling > >>> SB> is it a PTP LSP or a Timing LSP? > >>> > >>> protocols (e.g., RSVP-TE) are required for establishing PTP LSPs. > >>> However such extensions are outside the scope of this document. > >>> > >>> SB> for mpls-tp GMPLS is the signalling protocol > >>> > >>> While the techniques included herein allow for the establishment of > >>> paths optimized to include Time-stamping capable links, the > >>> performance of the Slave clocks is outside the scope of this > >>> document. > >>> > >>> At the time of publishing this specification, Transparent Clocking > >>> (TC) is only defined for PTP. Therefore at this time any part of > >>> this specification that talks about Transparent Clocking applies > >> only > >>> to PTP. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 6] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 2. Terminology > >>> > >>> 1588: The timing and synchronization as defined by IEEE 1588. > >>> > >>> SB> I think that there is a more formal name for the 1588 group > >>> SB> that needs to be used here. > >>> SB> Also do we need to talk about 1588-200? as there is > >>> SB> an update in progress > >>> > >>> NTP: The timing and synchronization protocol defined by IETF RFC- > >> 1305 > >>> and RFC-5905. > >>> > >>> PTP: The timing and synchronization protocol used by 1588. > >>> SB> need the proper name for 1588 > >>> > >>> Master Clock: The source of 1588 timing to a set of slave clocks. > >>> > >>> Master Port: A port on a ordinary or boundary clock that is in > >> Master > >>> state. This is the source of timing toward slave ports. > >>> > >>> SB> I am not sure the reader knows what a port is > >>> > >>> Slave Clock: A receiver of 1588 timing from a master clock. > >>> > >>> Slave Port: A port on a boundary clock or ordinary clock that is > >>> receiving timing from a master clock. > >>> > >>> Ordinary Clock: A device with a single PTP port. > >>> > >>> Transparent Clock. A device that measures the time taken for a PTP > >>> event message to transit the device and then updates the > >>> correctionField of the message with this transit time. > >>> > >>> Boundary Clock: A device with more than one PTP port. Generally > >>> boundary clocks will have one port in slave state to receive timing > >>> and then other ports in master state to re-distribute the timing. > >>> > >>> PTP LSP: An LSP dedicated to carry PTP messages > >>> > >>> SB> PTP or timing? > >>> > >>> > >>> PTP PW: A PW within a PTP LSP that is dedicated to carry PTP > >>> messages. > >>> > >>> SB> Ah I don't think that PWE3 know what one of these is > >>> > >>> CW: Pseudowire Control Word > >>> > >>> LAG: Link Aggregation > >>> > >>> ECMP: Equal Cost Multipath > >>> > >>> CF: Correction Field, a field inside certain PTP messages (message > >>> type 0-3)that holds the accumulative transit time inside > >> intermediate > >>> switches > >>> > >>> Timing messages: Timing Protocol messages that are exchanged > >> between > >>> routers in order to establish a synchronized clock. > >>> > >>> SB> A number of these definitions look like copies of IEEE1588 > >>> SB> definitions. We need to provide references and note the > >>> SB> priority of the IEEE base reference. > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 7] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 3. Problem Statement > >>> > >>> [IEEE-1588] has defined methods for transporting PTP messages over > >>> Ethernet and IP networks. [RFC5905] has defined the method of > >>> transporting NTP messages over IP networks. There is a need to > >>> transport Timing messages over MPLS networks while supporting the > >>> Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC) > >>> functionality in the LER and LSRs in the MPLS network. > >>> > >>> There are multiple ways of transporting Timing over MPLS. However, > >>> there is a requirement to limit the possible encapsulation options > >> to > >>> simplify the Timing message identification and processing required > >> at > >>> the port level. > >>> > >>> When Timing-awareness is needed, Timing messages should not be > >>> transported over LSPs or PWs that are carrying customer traffic > >>> because LSRs perform Label switching based on the top label in the > >>> stack. > >>> > >>> SB> Have you explained why? > >>> > >>> To detect Timing messages inside such LSPs require special > >>> hardware to do deep packet inspection at line rate. Even if such > >>> hardware exists, the payload can't be deterministically identified > >> by > >>> LSRs because the payload type is a context of the PW label, and the > >>> PW label and its context are only known to the Edge routers (PEs/ > >>> LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, > >> CES, > >>> etc). Even if one restricts an LSP to only carry Ethernet PWs, the > >>> LSRs dont have the knowledge of whether PW Control Word (CW) is > >>> present or not and therefore can not deterministically identify the > >>> payload. > >>> > >>> A generic method is defined in this document that does not require > >>> deep packet inspection at line rate, and can deterministically > >>> identify Timing messages. This method can be used to detect Timing > >>> Messages in both one-step and two-step clock implementations of > >>> ordinary, boundary and transparent clocks. > >>> > >>> SB> Needs a ref and I am sure many MPLS specialists will not > >> understand > >>> SB> the msg types. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 8] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 4. Timing over MPLS Architecture > >>> > >>> Timing messages are exchange between Timing ports on ordinary and > >>> > >>> SB> Have you defined a timing port? > >>> > >>> boundary clocks. Boundary clocks terminate the Timing messages and > >>> act as master for other boundary clocks or for slave clocks. End- > >> to- > >>> End Transparent clocks do not terminate the Timing messages but > >> they > >>> do modify the contents of the Timing messages as they transit > >> across > >>> the transparent clock. > >>> > >>> Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent > >> Clock > >>> > >>> (TC) could be implemented in either LERs or LSRs. > >>> > >>> SB> LER and LSR need to be expanded > >>> > >>> An example is shown in Figure 1, where the LERs act as Ordinary > >> Clock > >>> (OC) and are the initiating/terminating point for Timing messages. > >>> The ingress LER encapsulates the Timing messages in Timing LSP and > >>> the Egress LER terminates the Timing LSP. The LSRs act as > >>> Transparent Clock (TC) and just update the Timing field in the > >> Timing > >>> messages. > >>> > >>> > >>> +--------+ +-------+ +-------+ +-------+ +------ > >> --+ > >>> |Switch, | | | | | | | > >> |Switch, | > >>> | Router |-----| LER |-----| LSR |-----| LER |-----| > >> Router | > >>> | | | OC | | TC | | OC | | > >> | > >>> +--------+ +-------+ +-------+ +-------+ +------ > >> --+ > >>> / \ > >>> +-------+ / \ +------- > >> + > >>> | LER | / \ | LER > >> | > >>> | Master|---/ \---| Slave > >> | > >>> | Clock | | Clock > >> | > >>> +-------+ +------- > >> + > >>> > >>> Figure (1) - Deployment example 1 of timing over MPLS network > >>> > >>> Another example is shown in Figure2, where LERs terminate the > >> Timing > >>> messages received from switch/routers that are outside of the MPLS > >>> network acting as OC or BC. In this example LERs regenerate the > >>> clock and initiate timing messages encapsulated in Timing LSP > >> toward > >>> the MPLS network, while the LSRs act as Transparent Clock (TC) and > >>> just update the Timing field in the Timing messages, which are > >>> already encapsulated in Timing LSPs. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 9] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> +--------+ +-------+ +-------+ +-------+ +------- > >> -+ > >>> |Switch, | | | | | | | |Switch, > >> | > >>> | Router |-----| LER |-----| LSR |-----| LER |-----| Router > >> | > >>> | OC/BC | | BC | | TC | | BC | | OC/BC > >> | > >>> +--------+ +-------+ +-------+ +-------+ +------- > >> -+ > >>> > >>> Figure (2) - Deployment example 2 of timing over MPLS network > >>> > >>> > >>> Another example is shown in Figure 3, where LERs do not terminate > >> the > >>> Timing messages received from switch/routers that are outside of > >> the > >>> MPLS network acting as OC, TC or BC. The LERs act as TC and update > >>> the Timing field in the Timing messages as they transit the LER, > >>> while encapsulating them in timing LSP. The LSRs also act as > >>> Transparent Clock (TC) and just update the Timing field in the > >> Timing > >>> messages which are already encapsulated in Timing LSPs. > >>> > >>> +--------+ +-------+ +-------+ +-------+ +------ > >> --+ > >>> |Switch, | | | | | | | > >> |Switch, | > >>> | Router |-----| LER |-----| LSR |-----| LER |-----| > >> Router | > >>> |OC/TC/BC| | TC | | TC | | TC | > >> |OC/TC/BC| > >>> +--------+ +-------+ +-------+ +-------+ +------ > >> --+ > >>> > >>> Figure (3) - Deployment example 3 of timing over MPLS network > >>> > >>> Another example is shown in Figure 4, where LERs and LSRs support > >>> Boundary Clocks. A single-hop LSP is created between two adjacent > >>> LSRs engaged in BC operation. Other methods such as PTP transport > >>> over Ethernet MAY be used for transporting timing messages if the > >>> link between the two routers is Ethernet. > >>> > >>> +--------+ +-------+ +-------+ +-------+ +------- > >> -+ > >>> |Switch, | | | | | | | |Switch, > >> | > >>> | Router |-----| LER |-----| LSR |-----| LER |-----| Router > >> | > >>> | OC/BC | | BC | | BC | | BC | | OC/BC > >> | > >>> +--------+ +-------+ +-------+ +-------+ +------- > >> -+ > >>> > >>> Figure (4) - Deployment example 3 of timing over MPLS network > >>> > >>> An MPLS domain MAY serve multiple customers. In these cases the > >> MPLS > >>> domain (maintained by a service provider) may provide timing > >> services > >>> to multiple customers, each having their own Timing domain. > >>> > >>> The Timing over MPLS architecture assumes full mesh of Timing LSPs > >>> between all LERs supporting this specification. > >>> > >>> SB> Note sure this is right - the salves surely do not need to > >>> SB> exchange timing amongst themselves > >>> > >>> It supports > >>> Point-to- point (VPWS) and Multipoint (VPLS) services. > >>> > >>> SB> What does that mean? You do not carry user data traffic? > >>> SB> Maybe it's the ordering of the statemnets that is causing > >>> SB> confusion. > >>> > >>> This means > >>> that a customer may purchase a Point-to-point Timing service > >> between > >>> two customer sites or a Multipoint Timing service between more than > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 10] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> two customer sites. > >>> > >>> The Timing over MPLS architecture supports P2P or P2MP Timing LSPs. > >>> This means that the Timing Multicast messages such as PTP Multicast > >>> event messages can be transported over P2MP Timing LSP or be > >>> replicated and transported over many P2P Timing LSPs. > >>> > >>> SB> Note we do not yet have a definition of a P2MP mpls-tp LSP > >>> SB> nor a P2MP PW, although we are close. > >>> > >>> Timing messages, that do not require Time stamping or Correction > >>> Field update MAY be transported over Timing LSPs to simplify > >> hardware > >>> and software. > >>> > >>> PTP Announce messages that determine the Timing LSP terminating > >> point > >>> behavior such as BC/OC/TC SHOULD be transported over the Timing LSP > >>> to simplify hardware and software. > >>> > >>> SB> have you defined and referenced PTP announce msgs? > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 11] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 5. Dedicated LSPs for Timing messages > >>> > >>> Many methods have been considered for identifying the Timing > >> messages > >>> when they are encapsulated in MPLS such as using GAL/G-ACH or a new > >>> reserved label. These methods were not attractive since they > >> either > >>> required deep packet inspection at line rate in the intermediate > >> LSRs > >>> or they required use of a scarce new reserved label. Also one of > >> the > >>> goals was to reuse existing OAM mechanisms. > >>> > >>> SB> RLs = SPLs are not so rare now. In any case needs a ref. > >>> > >>> The method defined in this document can be used by LER and LSRs to > >>> identify Timing messages in MPLS tunnels by just looking at the top > >>> label in the MPLS label stack, which only carry Timing messages as > >>> well as OAM, but not data plane client traffic. > >>> > >>> Compliant implementations MUST use dedicated LSPs to carry Timing > >>> messages over MPLS. > >>> > >>> SB> I think that we need a definition of the properies of these LSPs > >>> > >>> These LSPs are herein referred to as "Timing > >>> LSPs" and the labels associated with these LSPs as "Timing LSP > >>> labels". The Timing LSPs that runs between Ingress and Egress LERs > >>> MUST be co-routed. Alternatively, a single bidirectional co-routed > >>> LSP can be used. > >>> > >>> SB> I though that you said you could use M2MP LSPs - these are not > >>> SB> bidirectional. > >>> > >>> Co-routing of the two directions is required to limit the > >> difference > >>> in the delays in the Master clock to Slave clock direction compared > >>> to the Slave clock to Master clock direction. The Timing LSP MAY > >> be > >>> MPLS/MPLS-TP LSP. > >>> > >>> The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS. > >>> New Extensions to RSVP-TE/GMPLS TLVs are required; however they are > >>> outside the scope of this document. > >>> > >>> The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such > >> as > >>> BFD and LSP Ping but the LSP data plane client plane traffic MUST > >> be > >>> Timing packets only. > >>> > >>> SB> Why? > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 12] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 6. Timing over LSP Encapsulation > >>> > >>> The encapsulations is not LSP is it? > >>> > >>> This document defines two methods for carrying Timing messages over > >>> MPLS. The first method is carrying UDP/IP encapsulated Timing > >>> messages over Timing LSPs, and the second method, is carrying > >>> Ethernet encapsulated Timing messages over Ethernet PWs inside > >> Timing > >>> LSPs. > >>> > >>> 6.1. Timing over UDP/IP over MPLS Encapsulation > >>> > >>> The simplest method of transporting Timing messages over MPLS is to > >>> encapsulate Timing PDUs in UDP/IP and then encapsulate them in > >> Timing > >>> LSP. This format is shown in Figure 4. > >>> > >>> > >>> +----------------------+ > >>> | Timing LSP Label | > >>> +----------------------+ > >>> | IPv4/6 | > >>> +----------------------+ > >>> | UDP | > >>> +----------------------+ > >>> | Timing PDU | > >>> +----------------------+ > >>> > >>> Figure (4) - Timing over UDP/IP over MPLS Encapsulation > >>> > >>> > >>> This encapsulation is very simple and is useful when the network > >>> between Timing Master Clock and Slave Clock is MPLS network. > >>> > >>> SB> Simple is a judgement call > >>> > >>> In order for an LER/LSR to process Timing messages, the Timing LSP > >>> Label must be at the top label of the label stack. The LER/LSR > >> MUST > >>> know that the Timing LSP Label is used for carrying Timing > >> messages. > >>> This can be accomplished via static configuration or via RSVP-TE > >>> signaling. > >>> > >>> The UDP/IP encapsulation of PTP MUST follow Annex D and E of > >>> [IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow > >>> [RFC5905]. > >>> > >>> 6.2. Timing over PW Encapsulation > >>> > >>> Another method of transporting Timing over MPLS networks is by > >>> encapsulating Timing PDUs in PW which in turn is transported over > >>> Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448], > >>> shown in Fig 5(A) MUST be used and the Ethernet encapsulation of > >> PTP > >>> MUST follow Annex F of [IEEE-1588]. > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 13] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> The RAW mode or Tagged mode defined in [RFC4448] MAY be used and > >> the > >>> Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The > >>> Timing over PW encapsulation MUST use the Control Word (CW) as > >>> specified in [RFC4448] to ensure proper detection of PTP messages > >>> inside the MPLS packets for Timing over LSP and Timing over PW > >>> encapsulation. > >>> > >>> SB> That needs explanation > >>> > >>> The use of Sequence Number in the CW is optional. > >>> > >>> SB> Given that s/n are never in practice deployed, you could probably > >>> SB> simplify things by sayig that they are not used. > >>> > >>> Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over > >> PW > >>> (the IP PW discussed in [RFC4447]) shown in Fig 5(B). > >>> > >>> +----------------+ +----------------+ > >>> |Timing LSP Label| |Timing LSP Label| > >>> +----------------+ +----------------+ > >>> | PW Label | | PW Label | > >>> +----------------+ +----------------+ > >>> | Control Word | | IP | > >>> +----------------+ +----------------+ > >>> | Ethernet | | UDP | > >>> | Header | +----------------+ > >>> +----------------+ | Timing PDU | > >>> |S-VLAN(Optional)| | | > >>> +----------------+ +----------------+ > >>> |C-VLAN(Optional)| (B) > >>> +----------------+ > >>> | Timing PDU | > >>> | | > >>> +----------------+ > >>> (A) > >>> > >>> Figure (5) - Timing over PW Encapsulations > >>> > >>> In order for an LSR to process PTP messages, the top label of the > >>> label stack (the Tunnel Label) MUST be a Timing label. > >>> > >>> S> You said that before. > >>> > >>> 6.3. Other Timing Encapsulation methods > >>> > >>> In future other timing encapsulation methods may be introduced, > >> such > >>> as a new shim header after the Bottom of Stack to carry the Timing > >>> information. Such new encapsulations are outside the scope of this > >>> document. > >>> > >>> > >>> SB> Taking a pure MPLS pov, you can simplify a lot of the text > >>> SB> out of the definition of the LSP > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 14] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> SB> I think we need a section on LSP processing > >>> > >>> 7. Timing message Processing > >>> > >>> Each Timing protocol such as PTP and NTP, define their set of > >> Timing > >>> messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, > >>> FOLLOW_UP, etc messages. > >>> > >>> Some of the Timing messages require time stamping or correction > >> field > >>> update at port level and some dont. It is the job of the LER/LSR > >> to > >>> parse the timing message and find out the type of the Timing > >> message > >>> and decide whether and how to Time- stamp it (e.g., BC) or update > >>> correction field(e.g., TC). > >>> > >>> > >>> SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing > >>> SB> function rather than the LER? > >>> > >>> For example the following PTP messages (called Event messages) > >>> require time-stamping or correction field update: > >>> > >>> o SYNC > >>> > >>> o DELAY_REQ (Delay Request) > >>> > >>> o PDELAY_REQ (Peer Delay Request) > >>> > >>> o PDELAY_RESP (Peer Delay Response) > >>> > >>> SYNC and DELAY_REQ are exchanged between Master Clock and Slave > >> Clock > >>> and MUST be transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP > >>> are exchanged between adjacent PTP clocks (i.e. Master, Slave, > >>> Boundary, or Transparent) and SHOULD be transported over single hop > >>> PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP, > >>> and PDELAY_RESP_FOLLOW_UP messages MUST also be transported over > >> the > >>> PTP LSPs. > >>> > >>> For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be > >>> transported over two PTP LSPs that are in opposite directions. > >> These > >>> PTP LSPs, which are in opposite directions MUST be congruent and > >> co- > >>> routed. Alternatively, a single bidirectional co-routed LSP can be > >>> used. > >>> > >>> Except as indicated above for the two-step PTP clocks, Non-Event > >> PTP > >>> message types do not need to be processed by intermediate routers. > >>> These message types MAY be carried in PTP Tunnel LSPs. > >>> > >>> SB> Are you saying that a timing P router has to be msg type > >> sensitive? > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 15] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 8. Protection and Redundancy > >>> > >>> > >>> SB> This is a bit of a jump - I don't know how the LSP itself works > >> yet! > >>> > >>> In order to ensure continuous uninterrupted operation of slave > >>> clocks, usually as a general practice, slave clocks (or ports) > >> track > >>> redundant master clocks. > >>> > >>> It is the responsibility of the network operator to ensure that > >>> physically disjoint Timing LSPs are established between a slave > >> clock > >>> (or port) and redundant master clocks (or ports). > >>> > >>> When a slave clock (or port) listens to redundant master clocks or > >>> ports, any prolonged Timing LSP outage will trigger the slave clock > >>> or port to switch to a redundant master clock or port. > >>> > >>> LSP/PW protection such as Linear protection Switching (1:1, 1+1), > >>> Ring protection switching or MPLS Fast Reroute (FRR) generally > >> switch > >>> alternative path that usually cause a change in delay, which if > >>> undetected by slave clock can reduce accuracy of the slave clock. > >>> > >>> Therefore protection switching MAY be used, as long as phase jumps > >>> upon switchover due to differences in path latency are detected and > >>> compensated for (such compensation not being required if BCs or > >> peer- > >>> peer TCs are used throughout). > >>> > >>> Note that any protection or reroute mechanism that adds additional > >>> MPLS label to the label stack, such as Facility Backup Fast > >> Reroute, > >>> MUST ensure that the pushed label is also a Timing Label to ensure > >>> recognition of the MPLS frame as containing Timing messages, as it > >>> transits the backup path. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 16] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 9. ECMP > >>> > >>> To ensure the optimal operation of slave clocks and avoid error > >>> introduced by forward and reverse path delay asymmetry, the > >> physical > >>> path for Timing messages from master clock to slave Clock and vice > >>> versa must be the same for all Event Timing messages listed in > >>> section 7. > >>> > >>> Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost > >>> Multipath). > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 17] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 10. PHP > >>> > >>> To ensure that the label on the top of the label stack is the > >> Timing > >>> LSP Label, PHP MUST not be used. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 18] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 11. Entropy > >>> > >>> To ensure all Timing messages in a Timing LSP take the same path, > >>> Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and > >>> Entropy Label MUST NOT be used for the PWs that are carried inside > >>> Timing LSP [RFC6391]. > >>> > >>> SB> This is incorrect - you mean that all msgs of the same timing > >>> SB> flow need to have the same EL value. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 19] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 12. OAM, Control and Management > >>> > >>> In order to monitor Timing LSPs and their encapsulated PWs, they > >> MUST > >>> be able to carry OAM and management messages. These management > >>> messages MUST be differentiated from Timing messages via already > >>> defined IETF methods. > >>> > >>> For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY run > >>> over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These > >>> Management protocols can easily be identified by the UDP > >> Destination > >>> Port number or by GAL/G-ACH respectively. > >>> > >>> Also BFD, LSP-Ping and other management messages MAY run over the > >> PWs > >>> encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3 > >> or > >>> 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is > >> going > >>> to be deprecated by IETF). In this case G-ACH, PW label (TTL=1) or > >>> GAL-ACH are used to identify such management messages. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 20] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 13. QoS Considerations > >>> > >>> In network deployments where not every LSR/LER is Timing-aware, it > >> is > >>> important to reduce the impact of the non-Timing-aware LSR/LERs on > >>> the timing recovery in the slave clock. The Timing messages are > >> time > >>> critical and must be treated with the highest priority. Therefore > >>> Timing over MPLS messages must be treated with the highest priority > >>> in the routers. This can be achieved by proper setup of Timing > >> LSPs. > >>> > >>> It is recommended that the Timing LSPs are setup or configured > >>> properly to indicate EF-PHB [RFC3246]for the CoS and Green > >> [RFC2697] > >>> for drop eligibility. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 21] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 14. FCS and Checksum Recalculation > >>> > >>> When time-stamp generation and timing packet adjustment is > >> performed > >>> near the physical port hardware, the process MUST include > >>> recalculation of the Ethernet FCS. > >>> > >>> SB> The above is confusing - an LSR always recomputes the link layer > >>> SB> CRC which may or may not be Ethernet. > >>> > >>> Also FCS retention for the > >>> payload Ethernet described in [RFC4720] MUST NOT be used. > >>> > >>> For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum > >>> may be required as per UDP transport standards. > >>> > >>> SB> You really need to be working on getting the IPv6 C?S computation > >>> SB> removed from PTP msgs. > >>> > >>> When UDP checksum is used, each Timing-aware LER/LSR must either > >>> incrementally update the UDP checksum after Time stamping or > >>> Correction Field update or verify the UDP checksum on reception > >> from > >>> upstream and recalculate the checksum completely on transmission to > >>> downstream node after Time stamping or Correction Field update. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 22] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 15. Behavior of LER/LSR > >>> > >>> Timing-capable/aware LERs and LSRs are routers that have one or > >> more > >>> > >>> SB> You mean physical interfaces? > >>> > >>> interfaces that can perform Timing operations (OC/BC/TC) on Timing > >>> packets and are configured to do so. Timing-capable/aware LERs and > >>> LSRs can advertise their Timing-capability per-interface via > >> control > >>> plane such as OSPF or IS-IS. > >>> SB> ISIS and OSPF are routing protocols. > >>> > >>> The Timing-capable/aware LERs can then > >>> signals Timing LSPs via RSVP-TE signaling. Alternatively the > >> Timing > >>> capability of LER and LSRs may be configured in a centralized > >>> controller and the Timing LSP may be setup using manual > >> configuration > >>> or other methods such as SDN. > >>> > >>> SB> it can also be configured individually rather then through > >>> SB> a cebtral controllwe > >>> > >>> 15.1. Behavior of Timing-capable/aware LER > >>> > >>> When a Timing-capable/aware LER behaves as a Transparent clock and > >>> receives a Timing message from a Timing-capable/aware non-MPLS > >>> interface, the LER updates the Correction Field (CF) and > >> encapsulates > >>> and forwards the timing message over previously established Timing > >>> LSP. > >>> > >>> SB> You need to call out the details so that people properly > >>> SB> understand the definition of the new LSP. > >>> > >>> Also when a Timing message is received from a Timing-capable/ > >>> aware MPLS interface, LER updates the Correction Filed (CF) and > >>> decapsulates the MPLS encapsulation and forwards the timing message > >>> to a non-MPLS interface. > >>> > >>> When a Timing-capable/aware LER behaves as a Boundary clock and > >>> receives a Timing message from a Timing-capable/aware non MPLS > >>> interface, the LER Timestamps the Timing packet and sends it to the > >>> LERs Boundary clock processing module. Also when a Timing message > >> is > >>> received from a Timing- capable/aware MPLS interface, the LER > >>> Timestamps the Timing packet and sends it to the LERs Boundary > >> clock > >>> processing module. > >>> > >>> When a Timing-capable/aware LER behaves as an Ordinary Clock toward > >>> the MPLS network, and receives a Timing message from a Timing- > >>> capable/aware MPLS interface, the LER Timestamps the Timing packet > >>> and sends it to the LERs Ordinary clock processing module. > >>> > >>> 15.2. Behavior of Timing-capable/aware LSR > >>> > >>> When a Timing-capable/aware LSR behaves as a Transparent clock and > >>> receives a Timing message from a Timing-capable/aware MPLS > >> interface, > >>> The LSR updates the Correction Filed (CF) and forwards the timing > >>> message over another MPLS interface. > >>> > >>> When a Timing-capable/aware LSR behaves as a Boundary clock and > >>> receives a Timing message from a Timing-capable/aware MPLS > >> interface. > >>> The LSR performs the functions of a Boundary Clock in terminating > >> the > >>> received Timing message and re-generating a new timing message over > >>> another (or the same) MPLS interface. > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 23] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 15.3. Behavior of non-Timing-capable/aware LSR > >>> > >>> It is most beneficial when all LSRs in the path of a Timing LSP be > >>> timing-Capable/aware LSRs. This would ensure the highest quality > >>> time and clock synchronization by Timing Slave Clocks. However, > >> this > >>> specification does not mandate that all LSRs in path of a Timing > >> LSP > >>> be Timing- capable/aware. > >>> > >>> Non-Timing-capable/aware LSRs just switch the packets encapsulated > >> in > >>> Timing LSPs and dont perform any Timing operation (TC or BC). > >>> However as explained in QoS section the Timing over MPLS packets > >> MUST > >>> be still be treated with the highest priority based on their > >> Traffic > >>> Class (TC) marking. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 24] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 16. Other considerations > >>> > >>> [IEEE-1588] defines an optional peer-to-peer Transparent clocking > >>> that requires peer delay measurement between two adjacent Timing- > >>> capable/ aware routers/switches. Peer delay measurement messages > >>> need to be time stamped and terminated by the Timing-capable/aware > >>> routers/ switches. This means that two adjacent LSRs may be > >> engaged > >>> in a peer delay measurement. > >>> > >>> For transporting such peer delay measurement messages a single-hop > >>> LSP SHOULD to be created between the two adjacent LSRs engaged in > >>> peer delay measurement to carry peer delay measurement messages. > >>> Other methods such as PTP transport over Ethernet MAY be used for > >>> transporting peer delay measurement messages if the link between > >> the > >>> two routers is Ethernet. > >>> > >>> In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ > >> ware > >>> routers/switches MUST maintain a list of all the neighbors it needs > >>> to send a PDelay_Req to, where each neighbor corresponds to a > >> timing > >>> LSP. > >>> > >>> The use of Explicit Null Label (Label= 0 or 2) is acceptable as > >> long > >>> as either the Explicit Null label is the bottom of stack label > >>> (applicable only to UDP/IP encapsulation) or the label below the > >>> Explicit Null label is a PTP label. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 25] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 17. Security Considerations > >>> > >>> MPLS PW security considerations in general are discussed in > >> [RFC3985] > >>> and [RFC4447],and those considerations also apply to this document. > >>> > >>> An experimental security protocol is defined in [IEEE-1588].The PTP > >>> security extension and protocol provides group source > >> authentication, > >>> message integrity, and replay attack protection for PTP messages. > >>> > >>> When the MPLS network (provider network) serves multiple customers, > >>> it is important to maintain and process each customers clock and > >>> Timing messages separately from other customers to ensure there is > >> no > >>> cross- customer effect. For example if an LER BC is synchronized > >> to > >>> a specific grandmaster, belonging to customer A, then the LER MUST > >>> use that BC clock only for customer A to ensure that customer A > >>> cannot attack other customers by manipulating its time. > >>> > >>> Timing messages MAY be encrypted or authenticated, provided that > >> the > >>> LERs/LSRs that are Timing capable/aware can authenticate/ decrypt > >> the > >>> timing messages. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 26] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 18. Acknowledgements > >>> > >>> The authors would like to thank Ron Cohen, Yaakov Stein, Tal > >> Mizrahi, > >>> Stefano Ruffini, Peter Meyer, and other members of IETF for > >> reviewing > >>> and providing feedback on this draft. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 27] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 19. IANA Considerations > >>> > >>> There are no IANA requirements in this specification. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 28] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 20. References > >>> > >>> 20.1. Normative References > >>> > >>> [IEEE-1588] > >>> IEEE 1588-2008, "IEEE Standard for a Precision Clock > >>> Synchronization Protocol for Networked Measurement and > >>> Control Systems". > >>> > >>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > >>> Requirement Levels", BCP 14, RFC 2119, March 1997. > >>> > >>> [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- > >>> Edge (PWE3) Architecture", RFC 3985, March 2005. > >>> > >>> [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor > >> Discovery > >>> Proxies (ND Proxy)", RFC 4389, April 2006. > >>> > >>> [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. > >>> Heron, "Pseudowire Setup and Maintenance Using the Label > >>> Distribution Protocol (LDP)", RFC 4447, April 2006. > >>> > >>> [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, > >>> "Encapsulation Methods for Transport of Ethernet over > >> MPLS > >>> Networks", RFC 4448, April 2006. > >>> > >>> [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire > >>> Emulation Edge-to-Edge (PWE3) Frame Check Sequence > >>> Retention", RFC 4720, November 2006. > >>> > >>> [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit > >>> Connectivity Verification (VCCV): A Control Channel for > >>> Pseudowires", RFC 5085, December 2007. > >>> > >>> [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding > >> Detection > >>> (BFD)", RFC 5880, June 2010. > >>> > >>> [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, > >>> "Bidirectional Forwarding Detection (BFD) for MPLS Label > >>> Switched Paths (LSPs)", RFC 5884, June 2010. > >>> > >>> 20.2. Informative References > >>> > >>> [I-D.ietf-pwe3-fat-pw] > >>> Bryant, S., Filsfils, C., Drafz, U., Kompella, V., > >> Regan, > >>> J., and S. Amante, "Flow Aware Transport of Pseudowires > >>> over an MPLS Packet Switched Network", > >>> draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011. > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 29] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate > >>> system routeing information exchange protocol for use in > >>> conjunction with the Protocol for providing the > >>> Connectionless-mode Network Service (ISO 8473)". > >>> > >>> [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and > >>> dual environments", RFC 1195, December 1990. > >>> > >>> [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. > >>> > >>> [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color > >>> Marker", RFC 2697, September 1999. > >>> > >>> [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le > >> Boudec, > >>> J., Courtney, W., Davari, S., Firoiu, V., and D. > >>> Stiliadis, "An Expedited Forwarding PHB (Per-Hop > >>> Behavior)", RFC 3246, March 2002. > >>> > >>> [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic > >> Engineering > >>> (TE) Extensions to OSPF Version 2", RFC 3630, > >>> September 2003. > >>> > >>> [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate > >>> System (IS-IS) Extensions for Traffic Engineering (TE)", > >>> RFC 3784, June 2004. > >>> > >>> [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. > >>> Shaffer, "Extensions to OSPF for Advertising Optional > >>> Router Capabilities", RFC 4970, July 2007. > >>> > >>> [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate > >>> System to Intermediate System (IS-IS) Extensions for > >>> Advertising Router Information", RFC 4971, July 2007. > >>> > >>> [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi > >>> Topology (MT) Routing in Intermediate System to > >>> Intermediate Systems (IS-ISs)", RFC 5120, February 2008. > >>> > >>> [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic > >>> Engineering", RFC 5305, October 2008. > >>> > >>> [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, > >>> "Traffic Engineering Extensions to OSPF Version 3", > >>> RFC 5329, September 2008. > >>> > >>> [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF > >>> for IPv6", RFC 5340, July 2008. > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 30] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, > >> "Network > >>> Time Protocol Version 4: Protocol and Algorithms > >>> Specification", RFC 5905, June 2010. > >>> > >>> [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., > >> Regan, > >>> J., and S. Amante, "Flow-Aware Transport of Pseudowires > >>> over an MPLS Packet Switched Network", RFC 6391, > >>> November 2011. > >>> > >>> [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and > >>> L. Yong, "The Use of Entropy Labels in MPLS Forwarding", > >>> RFC 6790, November 2012. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 31] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 1. Routing extensions for Timing-aware Routers > >>> > >>> MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] > >> and > >>> IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering > >> (TE) > >>> link information used for constraint-based routing. > >>> > >>> Indeed, it is useful to advertise data plane TE router link > >>> capabilities, such as the capability for a router to be Timing- > >> aware. > >>> This capability MUST then be taken into account during path > >>> computation to prefer or even require links that advertise > >> themselves > >>> as Timing-aware. In this way the path can ensure the entry and > >> exit > >>> points into the LERs and, if desired, the links into the LSRs are > >>> able to perform port based time-stamping thus minimizing their > >> impact > >>> on the performance of the slave clock. > >>> > >>> extensions are required to OSPF and IS-IS in order to advertise > >>> Timing-aware capabilities of a link. Such extensions are outside > >> the > >>> scope of this document; however such extension SHOULD be able to > >>> signal the following information per Router Link: > >>> > >>> o Capable of processing PTP, NTP or other Timing flows > >>> > >>> o Capable of performing Transparent Clock operation > >>> > >>> o Capable of performing Boundary Clock operation > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 32] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> 2. Signaling Extensions for Creating Timing LSPs > >>> > >>> RSVP-TE signaling MAY be used to setup the timing LSPs. When RSVP- > >> TE > >>> is used to setup Timing LSPs, some information that indicates that > >>> the LSP is carrying Timing flows MUST be included in the new > >>> Extensions to RSVP-TE: > >>> > >>> The following information MAY also be included in the new > >> Extensions > >>> to RSVP-TE: > >>> > >>> o Offset from Bottom of Stack (BoS) to the start of the Time-stamp > >>> field > >>> > >>> o Number of VLANs in case of PW encapsulation > >>> > >>> o Timestamp field Type > >>> > >>> * Correction Field, Timestamp > >>> > >>> o Timestamp Field format > >>> > >>> * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit > >>> NTP, etc. > >>> > >>> Note that in case the above optional information is signaled with > >>> RSVP-TE for a Timing LSP, all the Timing packets carried in that > >> LSP > >>> must have the same signaled characteristics. For example if > >>> Timestamp format is signaled as 64-bit PTPv1, then all Timing > >> packets > >>> must use 64-bit PTPv1 time-stamp. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 33] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> Authors' Addresses > >>> > >>> Shahram Davari > >>> Broadcom Corp. > >>> San Jose, CA 95134 > >>> USA > >>> > >>> Email: davari@broadcom.com > >>> > >>> > >>> Amit Oren > >>> Broadcom Corp. > >>> San Jose, CA 95134 > >>> USA > >>> > >>> Email: amito@broadcom.com > >>> > >>> > >>> Manav Bhatia > >>> Alcatel-Lucent > >>> Bangalore, > >>> India > >>> > >>> Email: manav.bhatia@alcatel-lucent.com > >>> > >>> > >>> Peter Roberts > >>> Alcatel-Lucent > >>> Kanata, > >>> Canada > >>> > >>> Email: peter.roberts@alcatel-lucent.com > >>> > >>> > >>> Laurent Montini > >>> Cisco Systems > >>> San Jose CA > >>> USA > >>> > >>> Email: lmontini@cisco.com > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 34] > > > >>> Internet-Draft Transporting Timing over MPLS June > >> 2013 > >>> > >>> > >>> Luca > >>> Cisco Systems > >>> San Jose CA > >>> USA > >>> > >>> Email: lmartini@cisco.com > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page > >> 35] > > > >>> > >>> -- > >>> 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 > > > > > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --bcaec51d2c10d243ea04e2f91efd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Shahram,
I think that John suggested creation of LSPs interconnecting all 1588-capab= le nodes. It is absolutely not what current document defines but that remin= ds me of what I've suggested around November of 2011.
Regards,
Greg

On Aug 2, 2013 6:43 AM, "Shahram Davari&quo= t; <davari@broadcom.com> w= rote:
Hi John

In that case I fail to understand the difference between your proposal and = the current draft.

In both cases you need a special LSP to tell the HW to Timestamp the packet= and I assume you need to use RSVPTE to sign it. That is what the draft doe= s.

Regards,
Shahram


On Aug 2, 2013, at 12:52 PM, "John E Drake" <jdrake@juniper.net> wrote:

> Shahram,
>
> The LSPs would be between LSRs that are 1588 capable, so they could be= one or more hops.
>
> Yours Irrespectively,
>
> John
>
>
>> -----Original Message-----
>> From: Shahram Davari [mailto:davari@broadcom.com]
>> Sent: Friday, August 02, 2013 3:24 AM
>> To: <stbryant@cisco.com>
>> Cc: mpls-chairs@tool= s.ietf.org; tictoc-chai= rs@tools.ietf.org; int-
>> ads@tools.ietf.org; rtg-ads@tools.ietf.org; draft-iet= f-tictoc-
>> 1588overmpls@tools.= ietf.org; John E Drake; mpls@ietf.org<= /a>;
>> tictoc@ietf.org
>> Subject: Re: [mpls] Comments on draft-ietf-tictoc-1588overmpls
>>
>> Hi Stewart
>>
>> We have already looked at similar approach. The issue with one hop= LSP
>> is that not all LSRs are 1588 capable. One of the requirements is = for
>> non-1588 capable routers to just switch the packet normally.
>>
>> Regards,
>> Shahram
>>
>>
>> On Aug 2, 2013, at 12:02 PM, "Stewart Bryant" <stbryant@cisco.com>
>> wrote:
>>
>>> Talking to John Drake about this, an alternative general
>>> model is for the LSP is that it is an LSP that timestamps
>>> the packet and then passes it to an application associated
>>> with the LSP at that hop.
>>>
>>> This has a lot of merit.
>>>
>>> If however we think about it some more we have a
>>> type of network service chaining going on here and
>>> so we don't need an LSP per say, because the path
>>> and instruction can be in the packet.
>>>
>>> In other words a general solution =A0to the problem
>>> is to define an LSP with the properties that the
>>> packet is passed one hop, timestamped and delivered
>>> to the associated application.
>>>
>>> How this is MPLS construct is used to support time
>>> tranfer is entirely within the scope of TICTOC, but
>>> at the MPLS layer we have a clean reusable network
>>> service.
>>>
>>> - Stewart
>>>
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> SB> This draft does not seem to provide a precise definitio= n
>>> SB> the properties of the new LSP type that it wishes to >>> SB> define, in particular it does it define the PHB of thos= e
>>> SB> LSPs, nor the full interaction with the MPLS
>>> SB> architecture.
>>> SB>
>>> SB> I have not tracked TICTOC for a while but I thought tha= t
>>> SB> the original plan was to define the concept of an offse= t
>>> SB> into a packet to do the correction.
>>> SB>
>>> SB> It is disappointing that the opportunity was not taken<= br> >>> SB> to define a timing shim inside the timing LSP so that >>> SB> a time correction could be added to any packet such tha= t
>>> SB> the MPLS system was isolated from the details of the >>> SB> complexity of the particular time transfer type.
>>>
>>> SB> I think that much more clarify is needed in terms of >>> SB> definition of the new LSP type, since it is unclear
>>> SB> from this text how to implement one.
>>> SB>
>>> SB> There are a lot of other MPLS services such as
>>> SB> LSP ping that need to be considered.
>>> SB>
>>> SB> Please see inline for more comments. However these
>>> SB> comments are made in the context of the text as written=
>>> SB> whilst I have a fundamental concern that this approach<= br> >>> SB> lacks an MPLS architectural soundness that need
>>> SB> greater thought with significant impact on the
>>> SB> draft.
>>>
>>> - Stewart
>>>
>>>
>>> TICTOC Working Group =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 S.
>> Davari
>>> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A.
>> Oren
>>> Intended status: Standards Track =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0Broadcom
>> Corp.
>>> Expires: December 17, 2013 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 M.
>> Bhatia
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 P.
>> Roberts
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Alcatel-
>> Lucent
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 L.
>> Montini
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 L.
>> Martini
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Cisco
>> Systems
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0June 15,
>> 2013
>>>
>>>
>>> =A0 =A0 =A0 =A0 =A0 Transporting Timing messages over MPLS Net= works
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0draft-ietf-tictoc-1588overm= pls-05
>>>
>>> Abstract
>>>
>>> =A0This document defines the method for transporting Timing me= ssages
>>> =A0such as PTP and NTP over an MPLS network. =A0The method all= ows for
>> the
>>> =A0easy identification of these PDUs at the port level to allo= w for
>> port
>>>
>>> SB> What is a port
>>>
>>> =A0level processing of these PDUs in both LERs and LSRs.
>>>
>>> =A0The basic idea is to transport Timing messages inside dedic= ated
>> MPLS
>>> =A0LSPs. =A0These LSPs only carry Timing messages and possibly= Control
>> and
>>> =A0Management packets, but they do not carry customer traffic.=
>>>
>>> SB> More specifically they only carry traffic associated wi= th the
>>> SB> timing service and its support.
>>> SB> The question arose WRT BFD - surely BFD is allowed, BUT= surely
>>> SB> also it gets carried in a structure that causes it to g= et
>>> SB> timestamped.
>>>
>>> =A0Two methods for transporting Timing messages over MPLS are = defined.
>>>
>>> SB> Perhaps the right approach is to define the new LSP typ= e and then
>>> SB> seperately to define =A0the mapping of the various timi= ng services
>>> SB> over that LSP type.
>>>
>>> =A0The first method is to transport Timing messages directly o= ver the
>>> =A0dedicated MPLS LSP via UDP/IP encapsulation, which is suita= ble for
>>> =A0MPLS networks. =A0The second method is to transport Timing = messages
>>> =A0inside a PW via Ethernet encapsulation.
>>>
>>> SB> I think that we should note that there are some
>>> SB> h/w reasons for this preference. A clean sheet approach=
>>> SB> would have been to use PTP over MPLS with no intermedia= te
>>> SB> layers.
>>>
>>> Status of this Memo
>>>
>>> =A0This Internet-Draft is submitted in full conformance with t= he
>>> =A0provisions of BCP 78 and BCP 79.
>>>
>>> =A0Internet-Drafts are working documents of the Internet Engin= eering
>>> =A0Task Force (IETF). =A0Note that other groups may also distr= ibute
>>> =A0working documents as Internet-Drafts. =A0The list of curren= t
>> Internet-
>>> =A0Drafts is at http://datatracker.ietf.org/drafts/current/= .
>>>
>>> =A0Internet-Drafts are draft documents valid for a maximum of = six
>> months
>>> =A0and may be updated, replaced, or obsoleted by other documen= ts at
>> any
>>> =A0time. =A0It is inappropriate to use Internet-Drafts as refe= rence
>>> =A0material or to cite them other than as "work in progre= ss."
>>>
>>> =A0This Internet-Draft will expire on December 17, 2013.
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page
>> 1]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> Copyright Notice
>>>
>>> =A0Copyright (c) 2013 IETF Trust and the persons identified as= the
>>> =A0document authors. =A0All rights reserved.
>>>
>>> =A0This document is subject to BCP 78 and the IETF Trust's= Legal
>>> =A0Provisions Relating to IETF Documents
>>> =A0(http://trustee.ietf.org/license-info) in effect on the date of=
>>> =A0publication of this document. =A0Please review these docume= nts
>>> =A0carefully, as they describe your rights and restrictions wi= th
>> respect
>>> =A0to this document. =A0Code Components extracted from this do= cument
>> must
>>> =A0include Simplified BSD License text as described in Section= 4.e of
>>> =A0the Trust Legal Provisions and are provided without warrant= y as
>>> =A0described in the Simplified BSD License.
>>>
>>>
>>> Table of Contents
>>>
>>> =A01. =A0Introduction . . . . . . . . . . . . . . . . . . . . = . . . . .
>> 5
>>>
>>> =A02. =A0Terminology =A0. . . . . . . . . . . . . . . . . . . = . . . . . .
>> 7
>>>
>>> =A03. =A0Problem Statement =A0. . . . . . . . . . . . . . . . = . . . . . .
>> 8
>>>
>>> =A04. =A0Timing over MPLS Architecture =A0. . . . . . . . . . = . . . . . .
>> 9
>>>
>>> =A05. =A0Dedicated LSPs for Timing messages . . . . . . . . . = . . . . .
>> 12
>>>
>>> =A06. =A0Timing over LSP Encapsulation =A0. . . . . . . . . . = . . . . . .
>> 13
>>> =A0 =A06.1. =A0Timing over UDP/IP over MPLS Encapsulation . . = . . . . . .
>> 13
>>> =A0 =A06.2. =A0Timing over PW Encapsulation . . . . . . . . . = . . . . . .
>> 13
>>> =A0 =A06.3. =A0Other Timing Encapsulation methods . . . . . . = . . . . . .
>> 14
>>>
>>> =A07. =A0Timing message Processing =A0. . . . . . . . . . . . = . . . . . .
>> 15
>>>
>>> =A08. =A0Protection and Redundancy =A0. . . . . . . . . . . . = . . . . . .
>> 16
>>>
>>> =A09. =A0ECMP . . . . . . . . . . . . . . . . . . . . . . . . = . . . . .
>> 17
>>>
>>> =A010. PHP =A0. . . . . . . . . . . . . . . . . . . . . . . . = . . . . .
>> 18
>>>
>>> =A011. Entropy =A0. . . . . . . . . . . . . . . . . . . . . . = . . . . .
>> 19
>>>
>>> =A012. OAM, Control and Management =A0. . . . . . . . . . . . = . . . . .
>> 20
>>>
>>> =A013. QoS Considerations . . . . . . . . . . . . . . . . . . = . . . .
>> 21
>>>
>>> =A014. FCS and Checksum Recalculation . . . . . . . . . . . . = . . . .
>> 22
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page
>> 2]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> =A015. Behavior of LER/LSR =A0. . . . . . . . . . . . . . . . = . . . . .
>> 23
>>> =A0 =A015.1. Behavior of Timing-capable/aware LER . . . . . . = . . . . .
>> 23
>>> =A0 =A015.2. Behavior of Timing-capable/aware LSR . . . . . . = . . . . .
>> 23
>>> =A0 =A015.3. Behavior of non-Timing-capable/aware LSR . . . . = . . . . .
>> 24
>>>
>>> =A016. Other considerations . . . . . . . . . . . . . . . . . = . . . .
>> 25
>>>
>>> =A017. Security Considerations =A0. . . . . . . . . . . . . . = . . . . .
>> 26
>>>
>>> =A018. Acknowledgements . . . . . . . . . . . . . . . . . . . = . . . .
>> 27
>>>
>>> =A019. IANA Considerations =A0. . . . . . . . . . . . . . . . = . . . . .
>> 28
>>>
>>> =A020. References . . . . . . . . . . . . . . . . . . . . . . = . . . .
>> 29
>>> =A0 =A020.1. Normative References . . . . . . . . . . . . . . = . . . . .
>> 29
>>> =A0 =A020.2. Informative References . . . . . . . . . . . . . = . . . . .
>> 29
>>>
>>> =A0Appendix 1. =A0Routing extensions for Timing-aware Routers = . . . . .
>> 32
>>>
>>> =A0Appendix 2. =A0Signaling Extensions for Creating Timing LSP= s . . . .
>> 33
>>>
>>> =A0Authors' Addresses . . . . . . . . . . . . . . . . . . = . . . . . .
>> 34
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page
>> 3]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> =A0The key words "MUST", "MUST NOT", "= ;REQUIRED", "SHALL", "SHALL NOT",
>>> =A0"SHOULD", "SHOULD NOT", "RECOMMEND= ED", "MAY", and "OPTIONAL" in
>> this
>>> =A0document are to be interpreted as described in RFC2119 [RFC= 2119].
>>>
>>> =A0When used in lower case, these words convey their typical u= se in
>>> =A0common language, and are not to be interpreted as described= in
>>> =A0RFC2119 [RFC2119].
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page
>> 4]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> 1. =A0Introduction
>>>
>>> =A0The objective of Precision Time Protocol (PTP) and Network = Timing
>>> =A0Protocol (NTP) are to synchronize independent clocks runnin= g on
>>> =A0separate nodes of a distributed system.
>>>
>>> =A0[IEEE-1588] defines PTP messages for frequency, phase and t= ime
>>> =A0synchronization. =A0The PTP messages include PTP PDUs over = UDP/IP
>>> =A0(Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (= Annex F
>> of
>>> =A0[IEEE-1588]).
>>>
>>> SB> Sure BUT it is acknowledged that IEEE is open to the de= finition
>>> SB> of other PTP mappings if they provide better optimisati= on.
>>>
>>> =A0This document defines mapping and transport of the PTP
>>> =A0messages defined in [IEEE-1588] over MPLS/MPLS-TP networks.= =A0PTP
>>> =A0defines several clock types: ordinary clocks, boundary cloc= ks, end-
>>> =A0to-end transparent clocks, and peer-to-peer transparent clo= cks.
>>> =A0Transparent clocks require intermediate nodes to update cor= rection
>>> =A0field inside PTP message that reflects the transit time in = the
>> node.
>>>
>>> =A0[RFC5905] defines NTP messages for clock and time synchroni= zation.
>>> =A0The PTP messages (PDUs) are transported over UDP/IP. =A0Thi= s document
>>> SB> Should that be NTP messages?
>>> SB> It needs to be made clear as soon as you introduce NTP = that
>>> SB> they use different time representations.
>>>
>>> =A0defines mapping and transport of the NTP messages defined i= n
>>> =A0[RFC5905] over MPLS networks.
>>>
>>> =A0One key attribute of all of these Timing messages is that t= he Time
>>> =A0stamp processing should occur as close as possible to the a= ctual
>>> =A0transmission and reception at the physical port interface. = =A0This
>>> =A0targets optimal time and/or frequency recovery by avoiding = variable
>>> =A0delay introduced by queues internal to the clocks.
>>>
>>> SB> As I recall NTP has no epoch point defined, and I am no= t sure
>>> SB> where that point is in the case of PTP in this mapping<= br> >>> SB> Hopefully this will get defined in due course.
>>>
>>> =A0To facilitate the fast and efficient recognition of Timing = messages
>>> =A0at the port level when the Timing messages are carried over= MPLS
>>> =A0LSPs,
>>>
>>> SB> Over a new LSP type with time optimied characteristics<= br> >>>
>>> =A0this document defines the specific encapsulations that shou= ld
>>> =A0be used.
>>> SB> Hopefully it will also define the PHP
>>>
>>> =A0In addition, it can be expected that there will exist LSR/<= br> >>> =A0LERs where only a subset of the physical ports will have th= e port-
>>> =A0based Timing message processing capabilities.
>>> SB> Do you need to clarify that this only works at base and= not in
>>> SB> a label heirarchy.
>>>
>>>
>>> =A0In order to ensure
>>> =A0that the LSPs carrying Timing packets always enter and exit= ports
>>> =A0with this capability, routing extensions are defined to adv= ertise
>>> =A0this capability on a port basis and to allow for the establ= ishment
>> of
>>> =A0LSPs that only transit such ports. =A0While this path estab= lishment
>>> =A0restriction may be applied only at the LER Ingress and/or e= gress
>>> =A0ports, it becomes more important when using transparent clo= ck
>> capable
>>> =A0LSRs in the path.
>>> SB> I do not understand the implications of the last
>>> SB> sentences - starting ", it becomes"
>>>
>>>
>>> =A0Port based Timing message processing involves Timing messag= e
>>> =A0recognition. =A0Once the Timing messages are recognized the= y can be
>>> =A0modified based on the reception or transmission Time-stamp.=
>>>
>>> =A0This document provides two methods for transporting Timing = messages
>>> =A0over MPLS. =A0One is applicable to MPLS environment and the= other one
>>> =A0is applicable to MPLS/MPLS-TP environment
>>>
>>> SB> I think the sentence is incomplete.
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page
>> 5]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> =A0The solution involves transporting Timing messages over ded= icated
>>> =A0LSPs called Timing LSPs. =A0These LSPs carry Timing message= s and MAY
>>> =A0carry Management and control messages, but not data plane c= lient
>>> =A0traffic.
>>>
>>> SB> It is not clear why this restriction applies.
>>>
>>> =A0Timing LSPs can be established statically or via signaling.=
>>> SB> s/statically/by provisioning/network management/
>>>
>>> =A0Extensions to control plane (OSPF, ISIS, etc.) is required = to
>> enable
>>> =A0routers to distribute their Timing processing capabilities = over
>> MPLS
>>> =A0to other routers. =A0However such extensions are outside th= e scope of
>>> =A0this document.
>>>
>>> =A0When signaling is used to setup the PTP LSP, Extensions to<= br> >> signaling
>>> SB> is it a PTP LSP or a Timing LSP?
>>>
>>> =A0protocols (e.g., RSVP-TE) are required for establishing PTP= LSPs.
>>> =A0However such extensions are outside the scope of this docum= ent.
>>>
>>> SB> for mpls-tp GMPLS is the signalling protocol
>>>
>>> =A0While the techniques included herein allow for the establis= hment of
>>> =A0paths optimized to include Time-stamping capable links, the=
>>> =A0performance of the Slave clocks is outside the scope of thi= s
>>> =A0document.
>>>
>>> =A0At the time of publishing this specification, Transparent C= locking
>>> =A0(TC) is only defined for PTP. =A0Therefore at this time any= part of
>>> =A0this specification that talks about Transparent Clocking ap= plies
>> only
>>> =A0to PTP.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page
>> 6]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> 2. =A0Terminology
>>>
>>> =A01588: The timing and synchronization as defined by IEEE 158= 8.
>>>
>>> SB> I think that there is a more formal name for the 1588 g= roup
>>> SB> that needs to be used here.
>>> SB> Also do we need to talk about 1588-200? as there is
>>> SB> an update in progress
>>>
>>> =A0NTP: The timing and synchronization protocol defined by IET= F RFC-
>> 1305
>>> =A0and RFC-5905.
>>>
>>> =A0PTP: The timing and synchronization protocol used by 1588.<= br> >>> SB> need the proper name for 1588
>>>
>>> =A0Master Clock: The source of 1588 timing to a set of slave c= locks.
>>>
>>> =A0Master Port: A port on a ordinary or boundary clock that is= in
>> Master
>>> =A0state. =A0This is the source of timing toward slave ports.<= br> >>>
>>> SB> I am not sure the reader knows what a port is
>>>
>>> =A0Slave Clock: A receiver of 1588 timing from a master clock.=
>>>
>>> =A0Slave Port: A port on a boundary clock or ordinary clock th= at is
>>> =A0receiving timing from a master clock.
>>>
>>> =A0Ordinary Clock: A device with a single PTP port.
>>>
>>> =A0Transparent Clock. =A0A device that measures the time taken= for a PTP
>>> =A0event message to transit the device and then updates the >>> =A0correctionField of the message with this transit time.
>>>
>>> =A0Boundary Clock: A device with more than one PTP port. =A0Ge= nerally
>>> =A0boundary clocks will have one port in slave state to receiv= e timing
>>> =A0and then other ports in master state to re-distribute the t= iming.
>>>
>>> =A0PTP LSP: An LSP dedicated to carry PTP messages
>>>
>>> SB> PTP or timing?
>>>
>>>
>>> =A0PTP PW: A PW within a PTP LSP that is dedicated to carry PT= P
>>> =A0messages.
>>>
>>> SB> Ah I don't think that PWE3 know what one of these i= s
>>>
>>> =A0CW: Pseudowire Control Word
>>>
>>> =A0LAG: Link Aggregation
>>>
>>> =A0ECMP: Equal Cost Multipath
>>>
>>> =A0CF: Correction Field, a field inside certain PTP messages (= message
>>> =A0type 0-3)that holds the accumulative transit time inside >> intermediate
>>> =A0switches
>>>
>>> =A0Timing messages: Timing Protocol messages that are exchange= d
>> between
>>> =A0routers in order to establish a synchronized clock.
>>>
>>> SB> A number of these definitions look like copies of IEEE1= 588
>>> SB> definitions. We need to provide references and note the=
>>> SB> priority of the IEEE base reference.
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page
>> 7]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> 3. =A0Problem Statement
>>>
>>> =A0[IEEE-1588] has defined methods for transporting PTP messag= es over
>>> =A0Ethernet and IP networks. =A0[RFC5905] has defined the meth= od of
>>> =A0transporting NTP messages over IP networks. =A0There is a n= eed to
>>> =A0transport Timing messages over MPLS networks while supporti= ng the
>>> =A0Transparent Clock (TC), Boundary Clock (BC) and Ordinary Cl= ock (OC)
>>> =A0functionality in the LER and LSRs in the MPLS network.
>>>
>>> =A0There are multiple ways of transporting Timing over MPLS. = =A0However,
>>> =A0there is a requirement to limit the possible encapsulation = options
>> to
>>> =A0simplify the Timing message identification and processing r= equired
>> at
>>> =A0the port level.
>>>
>>> =A0When Timing-awareness is needed, Timing messages should not= be
>>> =A0transported over LSPs or PWs that are carrying customer tra= ffic
>>> =A0because LSRs perform Label switching based on the top label= in the
>>> =A0stack.
>>>
>>> SB> Have you explained why?
>>>
>>> =A0To detect Timing messages inside such LSPs require special<= br> >>> =A0hardware to do deep packet inspection at line rate. =A0Even= if such
>>> =A0hardware exists, the payload can't be deterministically= identified
>> by
>>> =A0LSRs because the payload type is a context of the PW label,= and the
>>> =A0PW label and its context are only known to the Edge routers= (PEs/
>>> =A0LERs); LSRs dont know what is a PWs payload (Ethernet, ATM,= FR,
>> CES,
>>> =A0etc). =A0Even if one restricts an LSP to only carry Etherne= t PWs, the
>>> =A0LSRs dont have the knowledge of whether PW Control Word (CW= ) is
>>> =A0present or not and therefore can not deterministically iden= tify the
>>> =A0payload.
>>>
>>> =A0A generic method is defined in this document that does not = require
>>> =A0deep packet inspection at line rate, and can deterministica= lly
>>> =A0identify Timing messages. =A0This method can be used to det= ect Timing
>>> =A0Messages in both one-step and two-step clock implementation= s of
>>> =A0ordinary, boundary and transparent clocks.
>>>
>>> SB> Needs a ref and I am sure many MPLS specialists will no= t
>> understand
>>> SB> the msg types.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page
>> 8]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> 4. =A0Timing over MPLS Architecture
>>>
>>> =A0Timing messages are exchange between Timing ports on ordina= ry and
>>>
>>> SB> Have you defined a timing port?
>>>
>>> =A0boundary clocks. =A0Boundary clocks terminate the Timing me= ssages and
>>> =A0act as master for other boundary clocks or for slave clocks= . =A0End-
>> to-
>>> =A0End Transparent clocks do not terminate the Timing messages= but
>> they
>>> =A0do modify the contents of the Timing messages as they trans= it
>> across
>>> =A0the transparent clock.
>>>
>>> =A0Master/Slave clocks (OCs), Boundary Clocks (BC) and Transpa= rent
>> Clock
>>>
>>> =A0(TC) could be implemented in either LERs or LSRs.
>>>
>>> SB> LER and LSR need to be expanded
>>>
>>> =A0An example is shown in Figure 1, where the LERs act as Ordi= nary
>> Clock
>>> =A0(OC) and are the initiating/terminating point for Timing me= ssages.
>>> =A0The ingress LER encapsulates the Timing messages in Timing = LSP and
>>> =A0the Egress LER terminates the Timing LSP. =A0The LSRs act a= s
>>> =A0Transparent Clock (TC) and just update the Timing field in = the
>> Timing
>>> =A0messages.
>>>
>>>
>>> =A0 =A0 +--------+ =A0 =A0 +-------+ =A0 =A0 +-------+ =A0 =A0= +-------+ =A0 =A0 +------
>> --+
>>> =A0 =A0 |Switch, | =A0 =A0 | =A0 =A0 =A0 | =A0 =A0 | =A0 =A0 = =A0 | =A0 =A0 | =A0 =A0 =A0 |
>> |Switch, |
>>> =A0 =A0 | Router |-----| =A0LER =A0|-----| =A0LSR =A0|-----| = =A0LER =A0|-----|
>> Router |
>>> =A0 =A0 | =A0 =A0 =A0 =A0| =A0 =A0 | =A0OC =A0 | =A0 =A0 | =A0= TC =A0 | =A0 =A0 | =A0OC =A0 | =A0 =A0 |
>> |
>>> =A0 =A0 +--------+ =A0 =A0 +-------+ =A0 =A0 +-------+ =A0 =A0= +-------+ =A0 =A0 +------
>> --+
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
>>> =A0 =A0 +-------+ =A0 =A0 / =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 =A0 +-------
>> +
>>> =A0 =A0 | =A0LER =A0| =A0 =A0/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ =A0 =A0| =A0LER
>> |
>>> =A0 =A0 | Master|---/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \---| Slave
>> |
>>> =A0 =A0 | Clock | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Clock
>> |
>>> =A0 =A0 +-------+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +-------
>> +
>>>
>>> =A0 =A0Figure (1) - Deployment example 1 of timing over MPLS n= etwork
>>>
>>> =A0Another example is shown in Figure2, where LERs terminate t= he
>> Timing
>>> =A0messages received from switch/routers that are outside of t= he MPLS
>>> =A0network acting as OC or BC. =A0In this example LERs regener= ate the
>>> =A0clock and initiate timing messages encapsulated in Timing L= SP
>> toward
>>> =A0the MPLS network, while the LSRs act as Transparent Clock (= TC) and
>>> =A0just update the Timing field in the Timing messages, which = are
>>> =A0already encapsulated in Timing LSPs.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Page
>> 9]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> =A0 =A0+--------+ =A0 =A0 +-------+ =A0 =A0 +-------+ =A0 =A0 = +-------+ =A0 =A0 +-------
>> -+
>>> =A0 =A0|Switch, | =A0 =A0 | =A0 =A0 =A0 | =A0 =A0 | =A0 =A0 = =A0 | =A0 =A0 | =A0 =A0 =A0 | =A0 =A0 |Switch,
>> |
>>> =A0 =A0| Router |-----| =A0LER =A0|-----| =A0LSR =A0|-----| = =A0LER =A0|-----| Router
>> |
>>> =A0 =A0| OC/BC =A0| =A0 =A0 | =A0BC =A0 | =A0 =A0 | =A0TC =A0 = | =A0 =A0 | =A0BC =A0 | =A0 =A0 | OC/BC
>> |
>>> =A0 =A0+--------+ =A0 =A0 +-------+ =A0 =A0 +-------+ =A0 =A0 = +-------+ =A0 =A0 +-------
>> -+
>>>
>>> =A0 =A0Figure (2) - Deployment example 2 of timing over MPLS n= etwork
>>>
>>>
>>> =A0Another example is shown in Figure 3, where LERs do not ter= minate
>> the
>>> =A0Timing messages received from switch/routers that are outsi= de of
>> the
>>> =A0MPLS network acting as OC, TC or BC. =A0The LERs act as TC = and update
>>> =A0the Timing field in the Timing messages as they transit the= LER,
>>> =A0while encapsulating them in timing LSP. =A0The LSRs also ac= t as
>>> =A0Transparent Clock (TC) and just update the Timing field in = the
>> Timing
>>> =A0messages which are already encapsulated in Timing LSPs.
>>>
>>> =A0 =A0 +--------+ =A0 =A0 +-------+ =A0 =A0 +-------+ =A0 =A0= +-------+ =A0 =A0 +------
>> --+
>>> =A0 =A0 |Switch, | =A0 =A0 | =A0 =A0 =A0 | =A0 =A0 | =A0 =A0 = =A0 | =A0 =A0 | =A0 =A0 =A0 |
>> |Switch, |
>>> =A0 =A0 | Router |-----| =A0LER =A0|-----| =A0LSR =A0|-----| = =A0LER =A0|-----|
>> Router |
>>> =A0 =A0 |OC/TC/BC| =A0 =A0 | =A0TC =A0 | =A0 =A0 | =A0TC =A0 |= =A0 =A0 | =A0TC =A0 |
>> |OC/TC/BC|
>>> =A0 =A0 +--------+ =A0 =A0 +-------+ =A0 =A0 +-------+ =A0 =A0= +-------+ =A0 =A0 +------
>> --+
>>>
>>> =A0 Figure (3) - Deployment example 3 of timing over MPLS netw= ork
>>>
>>> =A0Another example is shown in Figure 4, where LERs and LSRs s= upport
>>> =A0Boundary Clocks. =A0A single-hop LSP is created between two= adjacent
>>> =A0LSRs engaged in BC operation. =A0Other methods such as PTP = transport
>>> =A0over Ethernet MAY be used for transporting timing messages = if the
>>> =A0link between the two routers is Ethernet.
>>>
>>> =A0 =A0+--------+ =A0 =A0 +-------+ =A0 =A0 +-------+ =A0 =A0 = +-------+ =A0 =A0 +-------
>> -+
>>> =A0 =A0|Switch, | =A0 =A0 | =A0 =A0 =A0 | =A0 =A0 | =A0 =A0 = =A0 | =A0 =A0 | =A0 =A0 =A0 | =A0 =A0 |Switch,
>> |
>>> =A0 =A0| Router |-----| =A0LER =A0|-----| =A0LSR =A0|-----| = =A0LER =A0|-----| Router
>> |
>>> =A0 =A0| OC/BC =A0| =A0 =A0 | =A0BC =A0 | =A0 =A0 | =A0BC =A0 = | =A0 =A0 | =A0BC =A0 | =A0 =A0 | OC/BC
>> |
>>> =A0 =A0+--------+ =A0 =A0 +-------+ =A0 =A0 +-------+ =A0 =A0 = +-------+ =A0 =A0 +-------
>> -+
>>>
>>> =A0Figure (4) - Deployment example 3 of timing over MPLS netwo= rk
>>>
>>> =A0An MPLS domain MAY serve multiple customers. =A0In these ca= ses the
>> MPLS
>>> =A0domain (maintained by a service provider) may provide timin= g
>> services
>>> =A0to multiple customers, each having their own Timing domain.=
>>>
>>> =A0The Timing over MPLS architecture assumes full mesh of Timi= ng LSPs
>>> =A0between all LERs supporting this specification.
>>>
>>> SB> Note sure this is right - the salves surely do not need= to
>>> SB> exchange timing amongst themselves
>>>
>>> =A0It supports
>>> =A0Point-to- point (VPWS) and Multipoint (VPLS) services.
>>>
>>> SB> What does that mean? You do not carry user data traffic= ?
>>> SB> Maybe it's the ordering of the statemnets that is c= ausing
>>> SB> confusion.
>>>
>>> =A0This means
>>> =A0that a customer may purchase a Point-to-point Timing servic= e
>> between
>>> =A0two customer sites or a Multipoint Timing service between m= ore than
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 10]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> =A0two customer sites.
>>>
>>> =A0The Timing over MPLS architecture supports P2P or P2MP Timi= ng LSPs.
>>> =A0This means that the Timing Multicast messages such as PTP M= ulticast
>>> =A0event messages can be transported over P2MP Timing LSP or b= e
>>> =A0replicated and transported over many P2P Timing LSPs.
>>>
>>> SB> Note we do not yet have a definition of a P2MP mpls-tp = LSP
>>> SB> nor a P2MP PW, although we are close.
>>>
>>> =A0Timing messages, that do not require Time stamping or Corre= ction
>>> =A0Field update MAY be transported over Timing LSPs to simplif= y
>> hardware
>>> =A0and software.
>>>
>>> =A0PTP Announce messages that determine the Timing LSP termina= ting
>> point
>>> =A0behavior such as BC/OC/TC SHOULD be transported over the Ti= ming LSP
>>> =A0to simplify hardware and software.
>>>
>>> SB> have you defined and referenced PTP announce msgs?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 11]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> 5. =A0Dedicated LSPs for Timing messages
>>>
>>> =A0Many methods have been considered for identifying the Timin= g
>> messages
>>> =A0when they are encapsulated in MPLS such as using GAL/G-ACH = or a new
>>> =A0reserved label. =A0These methods were not attractive since = they
>> either
>>> =A0required deep packet inspection at line rate in the interme= diate
>> LSRs
>>> =A0or they required use of a scarce new reserved label. =A0Als= o one of
>> the
>>> =A0goals was to reuse existing OAM mechanisms.
>>>
>>> SB> RLs =3D SPLs are not so rare now. In any case needs a r= ef.
>>>
>>> =A0The method defined in this document can be used by LER and = LSRs to
>>> =A0identify Timing messages in MPLS tunnels by just looking at= the top
>>> =A0label in the MPLS label stack, which only carry Timing mess= ages as
>>> =A0well as OAM, but not data plane client traffic.
>>>
>>> =A0Compliant implementations MUST use dedicated LSPs to carry = Timing
>>> =A0messages over MPLS.
>>>
>>> SB> I think that we need a definition of the properies of t= hese LSPs
>>>
>>> =A0These LSPs are herein referred to as "Timing
>>> =A0LSPs" and the labels associated with these LSPs as &qu= ot;Timing LSP
>>> =A0labels". =A0The Timing LSPs that runs between Ingress = and Egress LERs
>>> =A0MUST be co-routed. =A0Alternatively, a single bidirectional= co-routed
>>> =A0LSP can be used.
>>>
>>> SB> I though that you said you could use M2MP LSPs - these = are not
>>> SB> bidirectional.
>>>
>>> =A0Co-routing of the two directions is required to limit the >> difference
>>> =A0in the delays in the Master clock to Slave clock direction = compared
>>> =A0to the Slave clock to Master clock direction. =A0The Timing= LSP MAY
>> be
>>> =A0MPLS/MPLS-TP LSP.
>>>
>>> =A0The Timing LSPs could be configured or signaled via RSVP-TE= /GMPLS.
>>> =A0New Extensions to RSVP-TE/GMPLS TLVs are required; however = they are
>>> =A0outside the scope of this document.
>>>
>>> =A0The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffi= c such
>> as
>>> =A0BFD and LSP Ping but the LSP data plane client plane traffi= c MUST
>> be
>>> =A0Timing packets only.
>>>
>>> SB> Why?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 12]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> 6. =A0Timing over LSP Encapsulation
>>>
>>> The encapsulations is not LSP is it?
>>>
>>> =A0This document defines two methods for carrying Timing messa= ges over
>>> =A0MPLS. =A0The first method is carrying UDP/IP encapsulated T= iming
>>> =A0messages over Timing LSPs, and the second method, is carryi= ng
>>> =A0Ethernet encapsulated Timing messages over Ethernet PWs ins= ide
>> Timing
>>> =A0LSPs.
>>>
>>> 6.1. =A0Timing over UDP/IP over MPLS Encapsulation
>>>
>>> =A0The simplest method of transporting Timing messages over MP= LS is to
>>> =A0encapsulate Timing PDUs in UDP/IP and then encapsulate them= in
>> Timing
>>> =A0LSP. =A0This format is shown in Figure 4.
>>>
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +----------------------+ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Timing LSP Label =A0= |
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +----------------------+ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0IPv4/6 = =A0 =A0 =A0 =A0|
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +----------------------+ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 UDP =A0 = =A0 =A0 =A0 =A0|
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +----------------------+ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Timing PDU =A0 = =A0 =A0 |
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +----------------------+ >>>
>>> =A0 =A0 Figure (4) - Timing over UDP/IP over MPLS Encapsulatio= n
>>>
>>>
>>> =A0This encapsulation is very simple and is useful when the ne= twork
>>> =A0between Timing Master Clock and Slave Clock is MPLS network= .
>>>
>>> SB> Simple is a judgement call
>>>
>>> =A0In order for an LER/LSR to process Timing messages, the Tim= ing LSP
>>> =A0Label must be at the top label of the label stack. =A0The L= ER/LSR
>> MUST
>>> =A0know that the Timing LSP Label is used for carrying Timing<= br> >> messages.
>>> =A0This can be accomplished via static configuration or via RS= VP-TE
>>> =A0signaling.
>>>
>>> =A0The UDP/IP encapsulation of PTP MUST follow Annex D and E o= f
>>> =A0[IEEE-1588]. =A0While the UDP/IP encapsulation of NTP MUST = follow
>>> =A0[RFC5905].
>>>
>>> 6.2. =A0Timing over PW Encapsulation
>>>
>>> =A0Another method of transporting Timing over MPLS networks is= by
>>> =A0encapsulating Timing PDUs in PW which in turn is transporte= d over
>>> =A0Timing LSPs. =A0In case of PTP, Ethernet PW encapsulation [= RFC4448],
>>> =A0shown in Fig 5(A) MUST be used and the Ethernet encapsulati= on of
>> PTP
>>> =A0MUST follow Annex F of [IEEE-1588].
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 13]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> =A0The RAW mode or Tagged mode defined in [RFC4448] MAY be use= d and
>> the
>>> =A0Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN).= =A0The
>>> =A0Timing over PW encapsulation MUST use the Control Word (CW)= as
>>> =A0specified in [RFC4448] to ensure proper detection of PTP me= ssages
>>> =A0inside the MPLS packets for Timing over LSP and Timing over= PW
>>> =A0encapsulation.
>>>
>>> SB> That needs explanation
>>>
>>> =A0The use of Sequence Number in the CW is optional.
>>>
>>> SB> Given that s/n are never in practice deployed, you coul= d probably
>>> SB> simplify things by sayig that they are not used.
>>>
>>> =A0Timing over PW encapsulation for NTP MUST use NTP over UDP/= IP over
>> PW
>>> =A0(the IP PW discussed in [RFC4447]) shown in Fig 5(B).
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +----------------+ =A0+---= -------------+
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|Timing LSP Label| =A0|= Timing LSP Label|
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+----------------+ =A0+= ----------------+
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0PW Label =A0 = =A0| =A0| =A0 =A0PW Label =A0 =A0|
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+----------------+ =A0+= ----------------+
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0Control Word =A0| = =A0| =A0 =A0 =A0IP =A0 =A0 =A0 =A0|
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+----------------+ =A0+= ----------------+
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Ethernet =A0 = =A0| =A0| =A0 =A0 =A0UDP =A0 =A0 =A0 |
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Header =A0 = =A0 | =A0+----------------+
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+----------------+ =A0|= =A0 Timing PDU =A0 |
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|S-VLAN(Optional)| =A0|= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+----------------+ =A0+= ----------------+
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|C-VLAN(Optional)| =A0 = =A0 =A0 =A0(B)
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+----------------+
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Timing PDU =A0 |<= br> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0|
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+----------------+
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (A)
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 Figure (5) - Timing over PW Encapsulat= ions
>>>
>>> =A0In order for an LSR to process PTP messages, the top label = of the
>>> =A0label stack (the Tunnel Label) MUST be a Timing label.
>>>
>>> S> You said that before.
>>>
>>> 6.3. =A0Other Timing Encapsulation methods
>>>
>>> =A0In future other timing encapsulation methods may be introdu= ced,
>> such
>>> =A0as a new shim header after the Bottom of Stack to carry the= Timing
>>> =A0information. =A0Such new encapsulations are outside the sco= pe of this
>>> =A0document.
>>>
>>>
>>> SB> Taking a pure MPLS pov, you can simplify a lot of the t= ext
>>> SB> out of the definition of the LSP
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 14]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> SB> I think we need a section on LSP processing
>>>
>>> 7. =A0Timing message Processing
>>>
>>> =A0Each Timing protocol such as PTP and NTP, define their set = of
>> Timing
>>> =A0messages. =A0For example PTP defines SYNC, DELAY_REQ, DELAY= _RESP,
>>> =A0FOLLOW_UP, etc messages.
>>>
>>> =A0Some of the Timing messages require time stamping or correc= tion
>> field
>>> =A0update at port level and some dont. =A0It is the job of the= LER/LSR
>> to
>>> =A0parse the timing message and find out the type of the Timin= g
>> message
>>> =A0and decide whether and how to Time- stamp it (e.g., BC) or = update
>>> =A0correction field(e.g., TC).
>>>
>>>
>>> SB> AAAAAAAAAAAH. Surely this is the function of the PTP pr= cessing
>>> SB> function rather than the LER?
>>>
>>> =A0For example the following PTP messages (called Event messag= es)
>>> =A0require time-stamping or correction field update:
>>>
>>> =A0o =A0SYNC
>>>
>>> =A0o =A0DELAY_REQ (Delay Request)
>>>
>>> =A0o =A0PDELAY_REQ (Peer Delay Request)
>>>
>>> =A0o =A0PDELAY_RESP (Peer Delay Response)
>>>
>>> =A0SYNC and DELAY_REQ are exchanged between Master Clock and S= lave
>> Clock
>>> =A0and MUST be transported over PTP LSPs. =A0PDELAY_REQ and PD= ELAY_RESP
>>> =A0are exchanged between adjacent PTP clocks (i.e. =A0Master, = Slave,
>>> =A0Boundary, or Transparent) and SHOULD be transported over si= ngle hop
>>> =A0PTP LSPs. =A0If Two Step PTP clocks are present, then the F= OLLOW_UP,
>>> =A0and PDELAY_RESP_FOLLOW_UP messages MUST also be transported= over
>> the
>>> =A0PTP LSPs.
>>>
>>> =A0For a given instance of 1588 protocol, SYNC and DELAY_REQ M= UST be
>>> =A0transported over two PTP LSPs that are in opposite directio= ns.
>> These
>>> =A0PTP LSPs, which are in opposite directions MUST be congruen= t and
>> co-
>>> =A0routed. =A0Alternatively, a single bidirectional co-routed = LSP can be
>>> =A0used.
>>>
>>> =A0Except as indicated above for the two-step PTP clocks, Non-= Event
>> PTP
>>> =A0message types do not need to be processed by intermediate r= outers.
>>> =A0These message types MAY be carried in PTP Tunnel LSPs.
>>>
>>> SB> Are you saying that a timing P router has to be msg typ= e
>> sensitive?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 15]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> 8. =A0Protection and Redundancy
>>>
>>>
>>> SB> This is a bit of a jump - I don't know how the LSP = itself works
>> yet!
>>>
>>> =A0In order to ensure continuous uninterrupted operation of sl= ave
>>> =A0clocks, usually as a general practice, slave clocks (or por= ts)
>> track
>>> =A0redundant master clocks.
>>>
>>> =A0It is the responsibility of the network operator to ensure = that
>>> =A0physically disjoint Timing LSPs are established between a s= lave
>> clock
>>> =A0(or port) and redundant master clocks (or ports).
>>>
>>> =A0When a slave clock (or port) listens to redundant master cl= ocks or
>>> =A0ports, any prolonged Timing LSP outage will trigger the sla= ve clock
>>> =A0or port to switch to a redundant master clock or port.
>>>
>>> =A0LSP/PW protection such as Linear protection Switching (1:1,= 1+1),
>>> =A0Ring protection switching or MPLS Fast Reroute (FRR) genera= lly
>> switch
>>> =A0alternative path that usually cause a change in delay, whic= h if
>>> =A0undetected by slave clock can reduce accuracy of the slave = clock.
>>>
>>> =A0Therefore protection switching MAY be used, as long as phas= e jumps
>>> =A0upon switchover due to differences in path latency are dete= cted and
>>> =A0compensated for (such compensation not being required if BC= s or
>> peer-
>>> =A0peer TCs are used throughout).
>>>
>>> =A0Note that any protection or reroute mechanism that adds add= itional
>>> =A0MPLS label to the label stack, such as Facility Backup Fast=
>> Reroute,
>>> =A0MUST ensure that the pushed label is also a Timing Label to= ensure
>>> =A0recognition of the MPLS frame as containing Timing messages= , as it
>>> =A0transits the backup path.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 16]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> 9. =A0ECMP
>>>
>>> =A0To ensure the optimal operation of slave clocks and avoid e= rror
>>> =A0introduced by forward and reverse path delay asymmetry, the=
>> physical
>>> =A0path for Timing messages from master clock to slave Clock a= nd vice
>>> =A0versa must be the same for all Event Timing messages listed= in
>>> =A0section 7.
>>>
>>> =A0Therefore the Timing LSPs MUST not be subject to ECMP (Equa= l Cost
>>> =A0Multipath).
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 17]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> 10. =A0PHP
>>>
>>> =A0To ensure that the label on the top of the label stack is t= he
>> Timing
>>> =A0LSP Label, PHP MUST not be used.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 18]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> 11. =A0Entropy
>>>
>>> =A0To ensure all Timing messages in a Timing LSP take the same= path,
>>> =A0Entropy Label MUST NOT be used for the Timing LSP[RFC6790] = and
>>> =A0Entropy Label MUST NOT be used for the PWs that are carried= inside
>>> =A0Timing LSP [RFC6391].
>>>
>>> SB> This is incorrect - you mean that all msgs of the same = timing
>>> SB> flow need to have the same EL value.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 19]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> 12. =A0OAM, Control and Management
>>>
>>> =A0In order to monitor Timing LSPs and their encapsulated PWs,= they
>> MUST
>>> =A0be able to carry OAM and management messages. =A0These mana= gement
>>> =A0messages MUST be differentiated from Timing messages via al= ready
>>> =A0defined IETF methods.
>>>
>>> =A0For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389]= MAY run
>>> =A0over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. = =A0These
>>> =A0Management protocols can easily be identified by the UDP >> Destination
>>> =A0Port number or by GAL/G-ACH respectively.
>>>
>>> =A0Also BFD, LSP-Ping and other management messages MAY run ov= er the
>> PWs
>>> =A0encapsulated in Timing LSP via one of the defined VCCVs (Ty= pe 1, 3
>> or
>>> =A04) [RFC5085] (note that VCCV Type 2 using Router Alert Labe= l is
>> going
>>> =A0to be deprecated by IETF). =A0In this case G-ACH, PW label = (TTL=3D1) or
>>> =A0GAL-ACH are used to identify such management messages.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 20]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> 13. =A0QoS Considerations
>>>
>>> =A0In network deployments where not every LSR/LER is Timing-aw= are, it
>> is
>>> =A0important to reduce the impact of the non-Timing-aware LSR/= LERs on
>>> =A0the timing recovery in the slave clock. =A0The Timing messa= ges are
>> time
>>> =A0critical and must be treated with the highest priority. =A0= Therefore
>>> =A0Timing over MPLS messages must be treated with the highest = priority
>>> =A0in the routers. =A0This can be achieved by proper setup of = Timing
>> LSPs.
>>>
>>> =A0It is recommended that the Timing LSPs are setup or configu= red
>>> =A0properly to indicate EF-PHB [RFC3246]for the CoS and Green<= br> >> [RFC2697]
>>> =A0for drop eligibility.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 21]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> 14. =A0FCS and Checksum Recalculation
>>>
>>> =A0When time-stamp generation and timing packet adjustment is<= br> >> performed
>>> =A0near the physical port hardware, the process MUST include >>> =A0recalculation of the Ethernet FCS.
>>>
>>> SB> The above is confusing - an LSR always recomputes the l= ink layer
>>> SB> CRC which may or may not be Ethernet.
>>>
>>> =A0Also FCS retention for the
>>> =A0payload Ethernet described in [RFC4720] MUST NOT be used. >>>
>>> =A0For UDP/IP encapsulation mode of Timing over MPLS, the UDP = checksum
>>> =A0may be required as per UDP transport standards.
>>>
>>> SB> You really need to be working on getting the IPv6 C?S c= omputation
>>> SB> removed from PTP msgs.
>>>
>>> =A0When UDP checksum is used, each Timing-aware LER/LSR must e= ither
>>> =A0incrementally update the UDP checksum after Time stamping o= r
>>> =A0Correction Field update or verify the UDP checksum on recep= tion
>> from
>>> =A0upstream and recalculate the checksum completely on transmi= ssion to
>>> =A0downstream node after Time stamping or Correction Field upd= ate.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 22]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> 15. =A0Behavior of LER/LSR
>>>
>>> =A0Timing-capable/aware LERs and LSRs are routers that have on= e or
>> more
>>>
>>> SB> You mean physical interfaces?
>>>
>>> =A0interfaces that can perform Timing operations (OC/BC/TC) on= Timing
>>> =A0packets and are configured to do so. =A0Timing-capable/awar= e LERs and
>>> =A0LSRs can advertise their Timing-capability per-interface vi= a
>> control
>>> =A0plane such as OSPF or IS-IS.
>>> SB> ISIS and OSPF are routing protocols.
>>>
>>> The Timing-capable/aware LERs can then
>>> =A0signals Timing LSPs via RSVP-TE signaling. =A0Alternatively= the
>> Timing
>>> =A0capability of LER and LSRs may be configured in a centraliz= ed
>>> =A0controller and the Timing LSP may be setup using manual
>> configuration
>>> =A0or other methods such as SDN.
>>>
>>> SB> it can also be configured individually rather then thro= ugh
>>> SB> a cebtral controllwe
>>>
>>> 15.1. =A0Behavior of Timing-capable/aware LER
>>>
>>> =A0When a Timing-capable/aware LER behaves as a Transparent cl= ock and
>>> =A0receives a Timing message from a Timing-capable/aware non-M= PLS
>>> =A0interface, the LER updates the Correction Field (CF) and >> encapsulates
>>> =A0and forwards the timing message over previously established= Timing
>>> =A0LSP.
>>>
>>> SB> You need to call out the details so that people properl= y
>>> SB> understand the definition of the new LSP.
>>>
>>> =A0Also when a Timing message is received from a Timing-capabl= e/
>>> =A0aware MPLS interface, LER updates the Correction Filed (CF)= and
>>> =A0decapsulates the MPLS encapsulation and forwards the timing= message
>>> =A0to a non-MPLS interface.
>>>
>>> =A0When a Timing-capable/aware LER behaves as a Boundary clock= and
>>> =A0receives a Timing message from a Timing-capable/aware non M= PLS
>>> =A0interface, the LER Timestamps the Timing packet and sends i= t to the
>>> =A0LERs Boundary clock processing module. =A0Also when a Timin= g message
>> is
>>> =A0received from a Timing- capable/aware MPLS interface, the L= ER
>>> =A0Timestamps the Timing packet and sends it to the LERs Bound= ary
>> clock
>>> =A0processing module.
>>>
>>> =A0When a Timing-capable/aware LER behaves as an Ordinary Cloc= k toward
>>> =A0the MPLS network, and receives a Timing message from a Timi= ng-
>>> =A0capable/aware MPLS interface, the LER Timestamps the Timing= packet
>>> =A0and sends it to the LERs Ordinary clock processing module.<= br> >>>
>>> 15.2. =A0Behavior of Timing-capable/aware LSR
>>>
>>> =A0When a Timing-capable/aware LSR behaves as a Transparent cl= ock and
>>> =A0receives a Timing message from a Timing-capable/aware MPLS<= br> >> interface,
>>> =A0The LSR updates the Correction Filed (CF) and forwards the = timing
>>> =A0message over another MPLS interface.
>>>
>>> =A0When a Timing-capable/aware LSR behaves as a Boundary clock= and
>>> =A0receives a Timing message from a Timing-capable/aware MPLS<= br> >> interface.
>>> =A0The LSR performs the functions of a Boundary Clock in termi= nating
>> the
>>> =A0received Timing message and re-generating a new timing mess= age over
>>> =A0another (or the same) MPLS interface.
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 23]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> 15.3. =A0Behavior of non-Timing-capable/aware LSR
>>>
>>> =A0It is most beneficial when all LSRs in the path of a Timing= LSP be
>>> =A0timing-Capable/aware LSRs. =A0This would ensure the highest= quality
>>> =A0time and clock synchronization by Timing Slave Clocks. =A0H= owever,
>> this
>>> =A0specification does not mandate that all LSRs in path of a T= iming
>> LSP
>>> =A0be Timing- capable/aware.
>>>
>>> =A0Non-Timing-capable/aware LSRs just switch the packets encap= sulated
>> in
>>> =A0Timing LSPs and dont perform any Timing operation (TC or BC= ).
>>> =A0However as explained in QoS section the Timing over MPLS pa= ckets
>> MUST
>>> =A0be still be treated with the highest priority based on thei= r
>> Traffic
>>> =A0Class (TC) marking.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 24]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> 16. =A0Other considerations
>>>
>>> =A0[IEEE-1588] defines an optional peer-to-peer Transparent cl= ocking
>>> =A0that requires peer delay measurement between two adjacent T= iming-
>>> =A0capable/ aware routers/switches. =A0Peer delay measurement = messages
>>> =A0need to be time stamped and terminated by the Timing-capabl= e/aware
>>> =A0routers/ switches. =A0This means that two adjacent LSRs may= be
>> engaged
>>> =A0in a peer delay measurement.
>>>
>>> =A0For transporting such peer delay measurement messages a sin= gle-hop
>>> =A0LSP SHOULD to be created between the two adjacent LSRs enga= ged in
>>> =A0peer delay measurement to carry peer delay measurement mess= ages.
>>> =A0Other methods such as PTP transport over Ethernet MAY be us= ed for
>>> =A0transporting peer delay measurement messages if the link be= tween
>> the
>>> =A0two routers is Ethernet.
>>>
>>> =A0In Peer-to-peer transparent clocking (P2P TC), a Timing-cap= able/
>> ware
>>> =A0routers/switches MUST maintain a list of all the neighbors = it needs
>>> =A0to send a PDelay_Req to, where each neighbor corresponds to= a
>> timing
>>> =A0LSP.
>>>
>>> =A0The use of Explicit Null Label (Label=3D 0 or 2) is accepta= ble as
>> long
>>> =A0as either the Explicit Null label is the bottom of stack la= bel
>>> =A0(applicable only to UDP/IP encapsulation) or the label belo= w the
>>> =A0Explicit Null label is a PTP label.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 25]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> 17. =A0Security Considerations
>>>
>>> =A0MPLS PW security considerations in general are discussed in=
>> [RFC3985]
>>> =A0and [RFC4447],and those considerations also apply to this d= ocument.
>>>
>>> =A0An experimental security protocol is defined in [IEEE-1588]= .The PTP
>>> =A0security extension and protocol provides group source
>> authentication,
>>> =A0message integrity, and replay attack protection for PTP mes= sages.
>>>
>>> =A0When the MPLS network (provider network) serves multiple cu= stomers,
>>> =A0it is important to maintain and process each customers cloc= k and
>>> =A0Timing messages separately from other customers to ensure t= here is
>> no
>>> =A0cross- customer effect. =A0For example if an LER BC is sync= hronized
>> to
>>> =A0a specific grandmaster, belonging to customer A, then the L= ER MUST
>>> =A0use that BC clock only for customer A to ensure that custom= er A
>>> =A0cannot attack other customers by manipulating its time.
>>>
>>> =A0Timing messages MAY be encrypted or authenticated, provided= that
>> the
>>> =A0LERs/LSRs that are Timing capable/aware can authenticate/ d= ecrypt
>> the
>>> =A0timing messages.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 26]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> 18. =A0Acknowledgements
>>>
>>> =A0The authors would like to thank Ron Cohen, Yaakov Stein, Ta= l
>> Mizrahi,
>>> =A0Stefano Ruffini, Peter Meyer, and other members of IETF for=
>> reviewing
>>> =A0and providing feedback on this draft.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 27]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> 19. =A0IANA Considerations
>>>
>>> =A0There are no IANA requirements in this specification.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 28]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> 20. =A0References
>>>
>>> 20.1. =A0Normative References
>>>
>>> =A0[IEEE-1588]
>>> =A0 =A0 =A0 =A0 =A0 =A0 IEEE 1588-2008, "IEEE Standard fo= r a Precision Clock
>>> =A0 =A0 =A0 =A0 =A0 =A0 Synchronization Protocol for Networked= Measurement and
>>> =A0 =A0 =A0 =A0 =A0 =A0 Control Systems".
>>>
>>> =A0[RFC2119] =A0Bradner, S., "Key words for use in RFCs t= o Indicate
>>> =A0 =A0 =A0 =A0 =A0 =A0 Requirement Levels", BCP 14, RFC = 2119, March 1997.
>>>
>>> =A0[RFC3985] =A0Bryant, S. and P. Pate, "Pseudo Wire Emul= ation Edge-to-
>>> =A0 =A0 =A0 =A0 =A0 =A0 Edge (PWE3) Architecture", RFC 39= 85, March 2005.
>>>
>>> =A0[RFC4389] =A0Thaler, D., Talwar, M., and C. Patel, "Ne= ighbor
>> Discovery
>>> =A0 =A0 =A0 =A0 =A0 =A0 Proxies (ND Proxy)", RFC 4389, Ap= ril 2006.
>>>
>>> =A0[RFC4447] =A0Martini, L., Rosen, E., El-Aawar, N., Smith, T= ., and G.
>>> =A0 =A0 =A0 =A0 =A0 =A0 Heron, "Pseudowire Setup and Main= tenance Using the Label
>>> =A0 =A0 =A0 =A0 =A0 =A0 Distribution Protocol (LDP)", RFC= 4447, April 2006.
>>>
>>> =A0[RFC4448] =A0Martini, L., Rosen, E., El-Aawar, N., and G. H= eron,
>>> =A0 =A0 =A0 =A0 =A0 =A0 "Encapsulation Methods for Transp= ort of Ethernet over
>> MPLS
>>> =A0 =A0 =A0 =A0 =A0 =A0 Networks", RFC 4448, April 2006.<= br> >>>
>>> =A0[RFC4720] =A0Malis, A., Allan, D., and N. Del Regno, "= Pseudowire
>>> =A0 =A0 =A0 =A0 =A0 =A0 Emulation Edge-to-Edge (PWE3) Frame Ch= eck Sequence
>>> =A0 =A0 =A0 =A0 =A0 =A0 Retention", RFC 4720, November 20= 06.
>>>
>>> =A0[RFC5085] =A0Nadeau, T. and C. Pignataro, "Pseudowire = Virtual Circuit
>>> =A0 =A0 =A0 =A0 =A0 =A0 Connectivity Verification (VCCV): A Co= ntrol Channel for
>>> =A0 =A0 =A0 =A0 =A0 =A0 Pseudowires", RFC 5085, December = 2007.
>>>
>>> =A0[RFC5880] =A0Katz, D. and D. Ward, "Bidirectional Forw= arding
>> Detection
>>> =A0 =A0 =A0 =A0 =A0 =A0 (BFD)", RFC 5880, June 2010.
>>>
>>> =A0[RFC5884] =A0Aggarwal, R., Kompella, K., Nadeau, T., and G.= Swallow,
>>> =A0 =A0 =A0 =A0 =A0 =A0 "Bidirectional Forwarding Detecti= on (BFD) for MPLS Label
>>> =A0 =A0 =A0 =A0 =A0 =A0 Switched Paths (LSPs)", RFC 5884,= June 2010.
>>>
>>> 20.2. =A0Informative References
>>>
>>> =A0[I-D.ietf-pwe3-fat-pw]
>>> =A0 =A0 =A0 =A0 =A0 =A0 Bryant, S., Filsfils, C., Drafz, U., K= ompella, V.,
>> Regan,
>>> =A0 =A0 =A0 =A0 =A0 =A0 J., and S. Amante, "Flow Aware Tr= ansport of Pseudowires
>>> =A0 =A0 =A0 =A0 =A0 =A0 over an MPLS Packet Switched Network&q= uot;,
>>> =A0 =A0 =A0 =A0 =A0 =A0 draft-ietf-pwe3-fat-pw-07 (work in pro= gress), July 2011.
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 29]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> =A0[ISO] =A0 =A0 =A0ISO/IEC 10589:1992, "Intermediate sys= tem to Intermediate
>>> =A0 =A0 =A0 =A0 =A0 =A0 system routeing information exchange p= rotocol for use in
>>> =A0 =A0 =A0 =A0 =A0 =A0 conjunction with the Protocol for prov= iding the
>>> =A0 =A0 =A0 =A0 =A0 =A0 Connectionless-mode Network Service (I= SO 8473)".
>>>
>>> =A0[RFC1195] =A0Callon, R., "Use of OSI IS-IS for routing= in TCP/IP and
>>> =A0 =A0 =A0 =A0 =A0 =A0 dual environments", RFC 1195, Dec= ember 1990.
>>>
>>> =A0[RFC2328] =A0Moy, J., "OSPF Version 2", STD 54, R= FC 2328, April 1998.
>>>
>>> =A0[RFC2697] =A0Heinanen, J. and R. Guerin, "A Single Rat= e Three Color
>>> =A0 =A0 =A0 =A0 =A0 =A0 Marker", RFC 2697, September 1999= .
>>>
>>> =A0[RFC3246] =A0Davie, B., Charny, A., Bennet, J., Benson, K.,= Le
>> Boudec,
>>> =A0 =A0 =A0 =A0 =A0 =A0 J., Courtney, W., Davari, S., Firoiu, = V., and D.
>>> =A0 =A0 =A0 =A0 =A0 =A0 Stiliadis, "An Expedited Forwardi= ng PHB (Per-Hop
>>> =A0 =A0 =A0 =A0 =A0 =A0 Behavior)", RFC 3246, March 2002.=
>>>
>>> =A0[RFC3630] =A0Katz, D., Kompella, K., and D. Yeung, "Tr= affic
>> Engineering
>>> =A0 =A0 =A0 =A0 =A0 =A0 (TE) Extensions to OSPF Version 2"= ;, RFC 3630,
>>> =A0 =A0 =A0 =A0 =A0 =A0 September 2003.
>>>
>>> =A0[RFC3784] =A0Smit, H. and T. Li, "Intermediate System = to Intermediate
>>> =A0 =A0 =A0 =A0 =A0 =A0 System (IS-IS) Extensions for Traffic = Engineering (TE)",
>>> =A0 =A0 =A0 =A0 =A0 =A0 RFC 3784, June 2004.
>>>
>>> =A0[RFC4970] =A0Lindem, A., Shen, N., Vasseur, JP., Aggarwal, = R., and S.
>>> =A0 =A0 =A0 =A0 =A0 =A0 Shaffer, "Extensions to OSPF for = Advertising Optional
>>> =A0 =A0 =A0 =A0 =A0 =A0 Router Capabilities", RFC 4970, J= uly 2007.
>>>
>>> =A0[RFC4971] =A0Vasseur, JP., Shen, N., and R. Aggarwal, "= ;Intermediate
>>> =A0 =A0 =A0 =A0 =A0 =A0 System to Intermediate System (IS-IS) = Extensions for
>>> =A0 =A0 =A0 =A0 =A0 =A0 Advertising Router Information", = RFC 4971, July 2007.
>>>
>>> =A0[RFC5120] =A0Przygienda, T., Shen, N., and N. Sheth, "= M-ISIS: Multi
>>> =A0 =A0 =A0 =A0 =A0 =A0 Topology (MT) Routing in Intermediate = System to
>>> =A0 =A0 =A0 =A0 =A0 =A0 Intermediate Systems (IS-ISs)", R= FC 5120, February 2008.
>>>
>>> =A0[RFC5305] =A0Li, T. and H. Smit, "IS-IS Extensions for= Traffic
>>> =A0 =A0 =A0 =A0 =A0 =A0 Engineering", RFC 5305, October 2= 008.
>>>
>>> =A0[RFC5329] =A0Ishiguro, K., Manral, V., Davey, A., and A. Li= ndem,
>>> =A0 =A0 =A0 =A0 =A0 =A0 "Traffic Engineering Extensions t= o OSPF Version 3",
>>> =A0 =A0 =A0 =A0 =A0 =A0 RFC 5329, September 2008.
>>>
>>> =A0[RFC5340] =A0Coltun, R., Ferguson, D., Moy, J., and A. Lind= em, "OSPF
>>> =A0 =A0 =A0 =A0 =A0 =A0 for IPv6", RFC 5340, July 2008. >>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 30]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> =A0[RFC5905] =A0Mills, D., Martin, J., Burbank, J., and W. Kas= ch,
>> "Network
>>> =A0 =A0 =A0 =A0 =A0 =A0 Time Protocol Version 4: Protocol and = Algorithms
>>> =A0 =A0 =A0 =A0 =A0 =A0 Specification", RFC 5905, June 20= 10.
>>>
>>> =A0[RFC6391] =A0Bryant, S., Filsfils, C., Drafz, U., Kompella,= V.,
>> Regan,
>>> =A0 =A0 =A0 =A0 =A0 =A0 J., and S. Amante, "Flow-Aware Tr= ansport of Pseudowires
>>> =A0 =A0 =A0 =A0 =A0 =A0 over an MPLS Packet Switched Network&q= uot;, RFC 6391,
>>> =A0 =A0 =A0 =A0 =A0 =A0 November 2011.
>>>
>>> =A0[RFC6790] =A0Kompella, K., Drake, J., Amante, S., Henderick= x, W., and
>>> =A0 =A0 =A0 =A0 =A0 =A0 L. Yong, "The Use of Entropy Labe= ls in MPLS Forwarding",
>>> =A0 =A0 =A0 =A0 =A0 =A0 RFC 6790, November 2012.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 31]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> 1. =A0Routing extensions for Timing-aware Routers
>>>
>>> =A0MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC= 5340]
>> and
>>> =A0IS-IS [ISO] [RFC1195] in order to advertise Traffic Enginee= ring
>> (TE)
>>> =A0link information used for constraint-based routing.
>>>
>>> =A0Indeed, it is useful to advertise data plane TE router link=
>>> =A0capabilities, such as the capability for a router to be Tim= ing-
>> aware.
>>> =A0This capability MUST then be taken into account during path=
>>> =A0computation to prefer or even require links that advertise<= br> >> themselves
>>> =A0as Timing-aware. =A0In this way the path can ensure the ent= ry and
>> exit
>>> =A0points into the LERs and, if desired, the links into the LS= Rs are
>>> =A0able to perform port based time-stamping thus minimizing th= eir
>> impact
>>> =A0on the performance of the slave clock.
>>>
>>> =A0extensions are required to OSPF and IS-IS in order to adver= tise
>>> =A0Timing-aware capabilities of a link. =A0Such extensions are= outside
>> the
>>> =A0scope of this document; however such extension SHOULD be ab= le to
>>> =A0signal the following information per Router Link:
>>>
>>> =A0o =A0Capable of processing PTP, NTP or other Timing flows >>>
>>> =A0o =A0Capable of performing Transparent Clock operation
>>>
>>> =A0o =A0Capable of performing Boundary Clock operation
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 32]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> 2. =A0Signaling Extensions for Creating Timing LSPs
>>>
>>> =A0RSVP-TE signaling MAY be used to setup the timing LSPs. =A0= When RSVP-
>> TE
>>> =A0is used to setup Timing LSPs, some information that indicat= es that
>>> =A0the LSP is carrying Timing flows MUST be included in the ne= w
>>> =A0Extensions to RSVP-TE:
>>>
>>> =A0The following information MAY also be included in the new >> Extensions
>>> =A0to RSVP-TE:
>>>
>>> =A0o =A0Offset from Bottom of Stack (BoS) to the start of the = Time-stamp
>>> =A0 =A0 field
>>>
>>> =A0o =A0Number of VLANs in case of PW encapsulation
>>>
>>> =A0o =A0Timestamp field Type
>>>
>>> =A0 =A0 * =A0Correction Field, Timestamp
>>>
>>> =A0o =A0Timestamp Field format
>>>
>>> =A0 =A0 * =A064-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NT= P, 128-bit
>>> =A0 =A0 =A0 =A0NTP, etc.
>>>
>>> =A0Note that in case the above optional information is signale= d with
>>> =A0RSVP-TE for a Timing LSP, all the Timing packets carried in= that
>> LSP
>>> =A0must have the same signaled characteristics. =A0For example= if
>>> =A0Timestamp format is signaled as 64-bit PTPv1, then all Timi= ng
>> packets
>>> =A0must use 64-bit PTPv1 time-stamp.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 33]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> Authors' Addresses
>>>
>>> =A0Shahram Davari
>>> =A0Broadcom Corp.
>>> =A0San Jose, CA =A095134
>>> =A0USA
>>>
>>> =A0Email: davari@broadc= om.com
>>>
>>>
>>> =A0Amit Oren
>>> =A0Broadcom Corp.
>>> =A0San Jose, CA =A095134
>>> =A0USA
>>>
>>> =A0Email: amito@broadcom= .com
>>>
>>>
>>> =A0Manav Bhatia
>>> =A0Alcatel-Lucent
>>> =A0Bangalore,
>>> =A0India
>>>
>>> =A0Email: m= anav.bhatia@alcatel-lucent.com
>>>
>>>
>>> =A0Peter Roberts
>>> =A0Alcatel-Lucent
>>> =A0Kanata,
>>> =A0Canada
>>>
>>> =A0Email: = peter.roberts@alcatel-lucent.com
>>>
>>>
>>> =A0Laurent Montini
>>> =A0Cisco Systems
>>> =A0San Jose CA
>>> =A0USA
>>>
>>> =A0Email: lmontini@cisco= .com
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 34]
>
>>> Internet-Draft =A0 =A0 =A0 =A0Transporting Timing over MPLS = =A0 =A0 =A0 =A0 =A0 =A0June
>> 2013
>>>
>>>
>>> =A0Luca
>>> =A0Cisco Systems
>>> =A0San Jose CA
>>> =A0USA
>>>
>>> =A0Email: lmartini@cisco= .com
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Davari, et al. =A0 =A0 =A0 =A0 =A0Expires December 17, 2013 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[Page
>> 35]
>
>>>
>>> --
>>> For corporate legal information go to:
>>>
>>> http://www.cisco.com/web/about/doing_bus= iness/legal/cri/index.html
>>>
>>> _______________________________________________
>>> 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
--bcaec51d2c10d243ea04e2f91efd-- From Alexander.Vainshtein@ecitele.com Sun Aug 4 01:21:58 2013 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 2A76221F9A72 for ; Sun, 4 Aug 2013 01:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 je10VZcx5WvV for ; Sun, 4 Aug 2013 01:21:42 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.114]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1C621F9AA1 for ; Sun, 4 Aug 2013 01:21:34 -0700 (PDT) Received: from [193.109.254.147:23744] by server-10.bemta-14.messagelabs.com id C4/D9-17555-D0F0EF15; Sun, 04 Aug 2013 08:21:33 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1375604486!2548670!4 X-Originating-IP: [147.234.242.234] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26385 invoked from network); 4 Aug 2013 08:21:32 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Aug 2013 08:21:32 -0000 X-AuditID: 93eaf2e7-b7f4d6d000005d50-88-51fe0f095c3b Received: from ILPTWPVEXCA01.ecitele.com ( [172.31.244.224]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 19.57.23888.90F0EF15; Sun, 4 Aug 2013 11:21:29 +0300 (IDT) Received: from ILPTWPVEXMB02.ecitele.com ([fe80::5979:ca8d:419f:56df]) by ILPTWPVEXCA01.ecitele.com ([fe80::ac15:43ab:d541:dfa7%12]) with mapi id 14.03.0123.003; Sun, 4 Aug 2013 11:21:29 +0300 From: Alexander Vainshtein To: "stbryant@cisco.com" Thread-Topic: [TICTOC] Comments on draft-ietf-tictoc-1588overmpls Thread-Index: AQHOj2AMghL6qRFw2EmhP8ypbGfBrJmEtKhw Date: Sun, 4 Aug 2013 08:21:28 +0000 Message-ID: References: <51FB7543.801@cisco.com> In-Reply-To: <51FB7543.801@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.35.10] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUy+dWnL7pc/P8CDV7Ok7K4tXQlqwOjx5Il P5kCGKMaGG0S8/LySxJLUhVSUouTbZUCijLLEpMrlRQyU2yVDJUUCnISk1NzU/NKbJUSCwpS 81KU7LgUMIANUFlmnkJqXnJ+SmZeuq2SZ7C/roWFqaWuoZKdmrKhsTVXSEZmsUKqbm5iZo5C bmpxcWJ6qgJQJGELc8ahmZ2sBX2dLBWXFj9lamDc9J6pi5GTQ0LAROLatcPsELaYxIV769m6 GLk4hAQOMkr8+jqHHcI5wigxtW8dG0gVm4CtxKbVd8FsEQFdidkbbjCC2MwCHhLflu8Bs4UF HCSa9k5ghqhxlNh5bwIrhG0kMev2W7AaFgEViQuHm8Hm8AoESPza9wWongNomYrE728WICan gKrEyvkOIBWMQLd9P7WGCWKTuMStJ/Oh7heQWLLnPDOELSrx8vE/VghbTuLJk1MsEPU6Egt2 f2KDsLUlli18zQyxVVDi5MwnLBD1khIHV9xgmcAoPgvJillI2mchaZ+FpH0BI8sqRtHMnIKS pNx0A0O91OTMktScVL3k/NxNjJCk8XwH46/5KocYXYG+nsgsxZ2cD0w6eSXxxgYGuDlK4rzL G8L9hQTSgQknOzW1ILUovqg0J7X4ECMTB6dUA2P/j2MMS5kWKmxr68/0WX9+cnQhr6Hu02Mv FUXC/025om/GeHSLp8vf63uzQhsaGW7fyVznwdah5v8/9LP0AyfNmx2cz356OYZNv+LOJBl3 8VOr373JYR8c7/xttrzdt9HsXrG5/7kv9X+3h05bpjiBS27Vocn7c2VjwxO+6a/cw7PFI/3N pBQlluKMREMt5qLiRADFbbtrEgMAAA== Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] Comments on draft-ietf-tictoc-1588overmpls 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, 04 Aug 2013 08:21:58 -0000 Stewart and all, I concur with Stewart's statement that the draft does not define "full inter= action with MPLS architecture". E.g., one of the objectives of the draft is to provide a technique that woul= d be backward-compatible with old LSRs that cannot provide on-path support f= or timing distribution, while the other objective is to make every LSR on th= e path aware that some MPLS packets are carrying timing-related messages and= hence require on-path support. IMHO and FWIW, the MPLS data plane architecture allows just two methods for= making a transit LSR to provide special processing to a labeled packet: - It would carry some kind of an "alert label" on top of the label stack and= , specifically, on top of any labels used for actual forwarding OR, - The TTL in the top label stack entry has been set to 1. The draft does not follow any of these approaches. I must also admit that Section 12 "OAM, Control and Management" of the draft= looks somewhat in E.g., I could not understand from the text whether BFD, LSP-Ping etc. OAM me= ssages would be subjected to on-path support procedures for timing messages= or not. My 2c, Sasha > -----Original Message----- > From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf O= f > Stewart Bryant > Sent: Friday, August 02, 2013 12:01 PM > To: mpls-chairs@tools.ietf.org; tictoc-chairs@tools.ietf.org; int- > ads@tools.ietf.org; rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; dr= aft- > ietf-tictoc-1588overmpls@tools.ietf.org > Cc: mpls@ietf.org; tictoc@ietf.org > Subject: [TICTOC] Comments on draft-ietf-tictoc-1588overmpls > > SB> This draft does not seem to provide a precise definition > SB> the properties of the new LSP type that it wishes to > SB> define, in particular it does it define the PHB of those > SB> LSPs, nor the full interaction with the MPLS > SB> architecture. > SB> > SB> I have not tracked TICTOC for a while but I thought that > SB> the original plan was to define the concept of an offset > SB> into a packet to do the correction. > SB> > SB> It is disappointing that the opportunity was not taken > SB> to define a timing shim inside the timing LSP so that > SB> a time correction could be added to any packet such that > SB> the MPLS system was isolated from the details of the > SB> complexity of the particular time transfer type. > > SB> I think that much more clarify is needed in terms of > SB> definition of the new LSP type, since it is unclear > SB> from this text how to implement one. > SB> > SB> There are a lot of other MPLS services such as > SB> LSP ping that need to be considered. > SB> > SB> Please see inline for more comments. However these > SB> comments are made in the context of the text as written > SB> whilst I have a fundamental concern that this approach > SB> lacks an MPLS architectural soundness that need > SB> greater thought with significant impact on the > SB> draft. > > - Stewart > > > TICTOC Working Group S. Davari > Internet-Draft A. Oren > Intended status: Standards Track Broadcom Corp. > Expires: December 17, 2013 M. Bhatia > P. Roberts > Alcatel-Lucent > L. Montini > L. Martini > Cisco Systems > June 15, 2013 > > > Transporting Timing messages over MPLS Networks > draft-ietf-tictoc-1588overmpls-05 > > Abstract > > This document defines the method for transporting Timing messages > such as PTP and NTP over an MPLS network. The method allows for the > easy identification of these PDUs at the port level to allow for port > > SB> What is a port > > level processing of these PDUs in both LERs and LSRs. > > The basic idea is to transport Timing messages inside dedicated MPLS > LSPs. These LSPs only carry Timing messages and possibly Control and > Management packets, but they do not carry customer traffic. > > SB> More specifically they only carry traffic associated with the > SB> timing service and its support. > SB> The question arose WRT BFD - surely BFD is allowed, BUT surely > SB> also it gets carried in a structure that causes it to get > SB> timestamped. > > Two methods for transporting Timing messages over MPLS are defined. > > SB> Perhaps the right approach is to define the new LSP type and then > SB> seperately to define the mapping of the various timing services > SB> over that LSP type. > > The first method is to transport Timing messages directly over the > dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for > MPLS networks. The second method is to transport Timing messages > inside a PW via Ethernet encapsulation. > > SB> I think that we should note that there are some > SB> h/w reasons for this preference. A clean sheet approach > SB> would have been to use PTP over MPLS with no intermediate > SB> layers. > > Status of this Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on December 17, 2013. > > > > Davari, et al. Expires December 17, 2013 [Page 1] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > Copyright Notice > > Copyright (c) 2013 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 > > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 > > 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 > > 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . 9 > > 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . . 12 > > 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . 13 > 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . . 13 > 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . . 13 > 6.3. Other Timing Encapsulation methods . . . . . . . . . . . . 14 > > 7. Timing message Processing . . . . . . . . . . . . . . . . . . 15 > > 8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 16 > > 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 > > 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 > > 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 > > 12. OAM, Control and Management . . . . . . . . . . . . . . . . . 20 > > 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 21 > > 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . . 22 > > > > Davari, et al. Expires December 17, 2013 [Page 2] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 23 > 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . . 23 > 15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . . 23 > 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . . 24 > > 16. Other considerations . . . . . . . . . . . . . . . . . . . . . 25 > > 17. Security Considerations . . . . . . . . . . . . . . . . . . . 26 > > 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 > > 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 > > 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 > 20.1. Normative References . . . . . . . . . . . . . . . . . . . 29 > 20.2. Informative References . . . . . . . . . . . . . . . . . . 29 > > Appendix 1. Routing extensions for Timing-aware Routers . . . . . 32 > > Appendix 2. Signaling Extensions for Creating Timing LSPs . . . . 33 > > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 3] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this > document are to be interpreted as described in RFC2119 [RFC2119]. > > When used in lower case, these words convey their typical use in > common language, and are not to be interpreted as described in > RFC2119 [RFC2119]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 4] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 1. Introduction > > The objective of Precision Time Protocol (PTP) and Network Timing > Protocol (NTP) are to synchronize independent clocks running on > separate nodes of a distributed system. > > [IEEE-1588] defines PTP messages for frequency, phase and time > synchronization. The PTP messages include PTP PDUs over UDP/IP > (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex F of > [IEEE-1588]). > > SB> Sure BUT it is acknowledged that IEEE is open to the definition > SB> of other PTP mappings if they provide better optimisation. > > This document defines mapping and transport of the PTP > messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP > defines several clock types: ordinary clocks, boundary clocks, end- > to-end transparent clocks, and peer-to-peer transparent clocks. > Transparent clocks require intermediate nodes to update correction > field inside PTP message that reflects the transit time in the node. > > [RFC5905] defines NTP messages for clock and time synchronization. > The PTP messages (PDUs) are transported over UDP/IP. This document > SB> Should that be NTP messages? > SB> It needs to be made clear as soon as you introduce NTP that > SB> they use different time representations. > > defines mapping and transport of the NTP messages defined in > [RFC5905] over MPLS networks. > > One key attribute of all of these Timing messages is that the Time > stamp processing should occur as close as possible to the actual > transmission and reception at the physical port interface. This > targets optimal time and/or frequency recovery by avoiding variable > delay introduced by queues internal to the clocks. > > SB> As I recall NTP has no epoch point defined, and I am not sure > SB> where that point is in the case of PTP in this mapping > SB> Hopefully this will get defined in due course. > > To facilitate the fast and efficient recognition of Timing messages > at the port level when the Timing messages are carried over MPLS > LSPs, > > SB> Over a new LSP type with time optimied characteristics > > this document defines the specific encapsulations that should > be used. > SB> Hopefully it will also define the PHP > > In addition, it can be expected that there will exist LSR/ > LERs where only a subset of the physical ports will have the port- > based Timing message processing capabilities. > SB> Do you need to clarify that this only works at base and not in > SB> a label heirarchy. > > > In order to ensure > that the LSPs carrying Timing packets always enter and exit ports > with this capability, routing extensions are defined to advertise > this capability on a port basis and to allow for the establishment of > LSPs that only transit such ports. While this path establishment > restriction may be applied only at the LER Ingress and/or egress > ports, it becomes more important when using transparent clock capable > LSRs in the path. > SB> I do not understand the implications of the last > SB> sentences - starting ", it becomes" > > > Port based Timing message processing involves Timing message > recognition. Once the Timing messages are recognized they can be > modified based on the reception or transmission Time-stamp. > > This document provides two methods for transporting Timing messages > over MPLS. One is applicable to MPLS environment and the other one > is applicable to MPLS/MPLS-TP environment > > SB> I think the sentence is incomplete. > > > > Davari, et al. Expires December 17, 2013 [Page 5] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > The solution involves transporting Timing messages over dedicated > LSPs called Timing LSPs. These LSPs carry Timing messages and MAY > carry Management and control messages, but not data plane client > traffic. > > SB> It is not clear why this restriction applies. > > Timing LSPs can be established statically or via signaling. > SB> s/statically/by provisioning/network management/ > > Extensions to control plane (OSPF, ISIS, etc.) is required to enable > routers to distribute their Timing processing capabilities over MPLS > to other routers. However such extensions are outside the scope of > this document. > > When signaling is used to setup the PTP LSP, Extensions to signaling > SB> is it a PTP LSP or a Timing LSP? > > protocols (e.g., RSVP-TE) are required for establishing PTP LSPs. > However such extensions are outside the scope of this document. > > SB> for mpls-tp GMPLS is the signalling protocol > > While the techniques included herein allow for the establishment of > paths optimized to include Time-stamping capable links, the > performance of the Slave clocks is outside the scope of this > document. > > At the time of publishing this specification, Transparent Clocking > (TC) is only defined for PTP. Therefore at this time any part of > this specification that talks about Transparent Clocking applies only > to PTP. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 6] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 2. Terminology > > 1588: The timing and synchronization as defined by IEEE 1588. > > SB> I think that there is a more formal name for the 1588 group > SB> that needs to be used here. > SB> Also do we need to talk about 1588-200? as there is > SB> an update in progress > > NTP: The timing and synchronization protocol defined by IETF RFC-1305 > and RFC-5905. > > PTP: The timing and synchronization protocol used by 1588. > SB> need the proper name for 1588 > > Master Clock: The source of 1588 timing to a set of slave clocks. > > Master Port: A port on a ordinary or boundary clock that is in Master > state. This is the source of timing toward slave ports. > > SB> I am not sure the reader knows what a port is > > Slave Clock: A receiver of 1588 timing from a master clock. > > Slave Port: A port on a boundary clock or ordinary clock that is > receiving timing from a master clock. > > Ordinary Clock: A device with a single PTP port. > > Transparent Clock. A device that measures the time taken for a PTP > event message to transit the device and then updates the > correctionField of the message with this transit time. > > Boundary Clock: A device with more than one PTP port. Generally > boundary clocks will have one port in slave state to receive timing > and then other ports in master state to re-distribute the timing. > > PTP LSP: An LSP dedicated to carry PTP messages > > SB> PTP or timing? > > > PTP PW: A PW within a PTP LSP that is dedicated to carry PTP > messages. > > SB> Ah I don't think that PWE3 know what one of these is > > CW: Pseudowire Control Word > > LAG: Link Aggregation > > ECMP: Equal Cost Multipath > > CF: Correction Field, a field inside certain PTP messages (message > type 0-3)that holds the accumulative transit time inside intermediate > switches > > Timing messages: Timing Protocol messages that are exchanged between > routers in order to establish a synchronized clock. > > SB> A number of these definitions look like copies of IEEE1588 > SB> definitions. We need to provide references and note the > SB> priority of the IEEE base reference. > > > > Davari, et al. Expires December 17, 2013 [Page 7] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 3. Problem Statement > > [IEEE-1588] has defined methods for transporting PTP messages over > Ethernet and IP networks. [RFC5905] has defined the method of > transporting NTP messages over IP networks. There is a need to > transport Timing messages over MPLS networks while supporting the > Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC) > functionality in the LER and LSRs in the MPLS network. > > There are multiple ways of transporting Timing over MPLS. However, > there is a requirement to limit the possible encapsulation options to > simplify the Timing message identification and processing required at > the port level. > > When Timing-awareness is needed, Timing messages should not be > transported over LSPs or PWs that are carrying customer traffic > because LSRs perform Label switching based on the top label in the > stack. > > SB> Have you explained why? > > To detect Timing messages inside such LSPs require special > hardware to do deep packet inspection at line rate. Even if such > hardware exists, the payload can't be deterministically identified by > LSRs because the payload type is a context of the PW label, and the > PW label and its context are only known to the Edge routers (PEs/ > LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, CES, > etc). Even if one restricts an LSP to only carry Ethernet PWs, the > LSRs dont have the knowledge of whether PW Control Word (CW) is > present or not and therefore can not deterministically identify the > payload. > > A generic method is defined in this document that does not require > deep packet inspection at line rate, and can deterministically > identify Timing messages. This method can be used to detect Timing > Messages in both one-step and two-step clock implementations of > ordinary, boundary and transparent clocks. > > SB> Needs a ref and I am sure many MPLS specialists will not understand > SB> the msg types. > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 8] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 4. Timing over MPLS Architecture > > Timing messages are exchange between Timing ports on ordinary and > > SB> Have you defined a timing port? > > boundary clocks. Boundary clocks terminate the Timing messages and > act as master for other boundary clocks or for slave clocks. End-to- > End Transparent clocks do not terminate the Timing messages but they > do modify the contents of the Timing messages as they transit across > the transparent clock. > > Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent Clock > > (TC) could be implemented in either LERs or LSRs. > > SB> LER and LSR need to be expanded > > An example is shown in Figure 1, where the LERs act as Ordinary Clock > (OC) and are the initiating/terminating point for Timing messages. > The ingress LER encapsulates the Timing messages in Timing LSP and > the Egress LER terminates the Timing LSP. The LSRs act as > Transparent Clock (TC) and just update the Timing field in the Timing > messages. > > > +--------+ +-------+ +-------+ +-------+ +--------+ > |Switch, | | | | | | | |Switch, | > | Router |-----| LER |-----| LSR |-----| LER |-----| Router | > | | | OC | | TC | | OC | | | > +--------+ +-------+ +-------+ +-------+ +--------+ > / \ > +-------+ / \ +-------+ > | LER | / \ | LER | > | Master|---/ \---| Slave | > | Clock | | Clock | > +-------+ +-------+ > > Figure (1) - Deployment example 1 of timing over MPLS network > > Another example is shown in Figure2, where LERs terminate the Timing > messages received from switch/routers that are outside of the MPLS > network acting as OC or BC. In this example LERs regenerate the > clock and initiate timing messages encapsulated in Timing LSP toward > the MPLS network, while the LSRs act as Transparent Clock (TC) and > just update the Timing field in the Timing messages, which are > already encapsulated in Timing LSPs. > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 9] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > +--------+ +-------+ +-------+ +-------+ +--------+ > |Switch, | | | | | | | |Switch, | > | Router |-----| LER |-----| LSR |-----| LER |-----| Router | > | OC/BC | | BC | | TC | | BC | | OC/BC | > +--------+ +-------+ +-------+ +-------+ +--------+ > > Figure (2) - Deployment example 2 of timing over MPLS network > > > Another example is shown in Figure 3, where LERs do not terminate the > Timing messages received from switch/routers that are outside of the > MPLS network acting as OC, TC or BC. The LERs act as TC and update > the Timing field in the Timing messages as they transit the LER, > while encapsulating them in timing LSP. The LSRs also act as > Transparent Clock (TC) and just update the Timing field in the Timing > messages which are already encapsulated in Timing LSPs. > > +--------+ +-------+ +-------+ +-------+ +--------+ > |Switch, | | | | | | | |Switch, | > | Router |-----| LER |-----| LSR |-----| LER |-----| Router | > |OC/TC/BC| | TC | | TC | | TC | |OC/TC/BC| > +--------+ +-------+ +-------+ +-------+ +--------+ > > Figure (3) - Deployment example 3 of timing over MPLS network > > Another example is shown in Figure 4, where LERs and LSRs support > Boundary Clocks. A single-hop LSP is created between two adjacent > LSRs engaged in BC operation. Other methods such as PTP transport > over Ethernet MAY be used for transporting timing messages if the > link between the two routers is Ethernet. > > +--------+ +-------+ +-------+ +-------+ +--------+ > |Switch, | | | | | | | |Switch, | > | Router |-----| LER |-----| LSR |-----| LER |-----| Router | > | OC/BC | | BC | | BC | | BC | | OC/BC | > +--------+ +-------+ +-------+ +-------+ +--------+ > > Figure (4) - Deployment example 3 of timing over MPLS network > > An MPLS domain MAY serve multiple customers. In these cases the MPLS > domain (maintained by a service provider) may provide timing services > to multiple customers, each having their own Timing domain. > > The Timing over MPLS architecture assumes full mesh of Timing LSPs > between all LERs supporting this specification. > > SB> Note sure this is right - the salves surely do not need to > SB> exchange timing amongst themselves > > It supports > Point-to- point (VPWS) and Multipoint (VPLS) services. > > SB> What does that mean? You do not carry user data traffic? > SB> Maybe it's the ordering of the statemnets that is causing > SB> confusion. > > This means > that a customer may purchase a Point-to-point Timing service between > two customer sites or a Multipoint Timing service between more than > > > > Davari, et al. Expires December 17, 2013 [Page 10] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > two customer sites. > > The Timing over MPLS architecture supports P2P or P2MP Timing LSPs. > This means that the Timing Multicast messages such as PTP Multicast > event messages can be transported over P2MP Timing LSP or be > replicated and transported over many P2P Timing LSPs. > > SB> Note we do not yet have a definition of a P2MP mpls-tp LSP > SB> nor a P2MP PW, although we are close. > > Timing messages, that do not require Time stamping or Correction > Field update MAY be transported over Timing LSPs to simplify hardware > and software. > > PTP Announce messages that determine the Timing LSP terminating point > behavior such as BC/OC/TC SHOULD be transported over the Timing LSP > to simplify hardware and software. > > SB> have you defined and referenced PTP announce msgs? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 11] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 5. Dedicated LSPs for Timing messages > > Many methods have been considered for identifying the Timing messages > when they are encapsulated in MPLS such as using GAL/G-ACH or a new > reserved label. These methods were not attractive since they either > required deep packet inspection at line rate in the intermediate LSRs > or they required use of a scarce new reserved label. Also one of the > goals was to reuse existing OAM mechanisms. > > SB> RLs =3D SPLs are not so rare now. In any case needs a ref. > > The method defined in this document can be used by LER and LSRs to > identify Timing messages in MPLS tunnels by just looking at the top > label in the MPLS label stack, which only carry Timing messages as > well as OAM, but not data plane client traffic. > > Compliant implementations MUST use dedicated LSPs to carry Timing > messages over MPLS. > > SB> I think that we need a definition of the properies of these LSPs > > These LSPs are herein referred to as "Timing > LSPs" and the labels associated with these LSPs as "Timing LSP > labels". The Timing LSPs that runs between Ingress and Egress LERs > MUST be co-routed. Alternatively, a single bidirectional co-routed > LSP can be used. > > SB> I though that you said you could use M2MP LSPs - these are not > SB> bidirectional. > > Co-routing of the two directions is required to limit the difference > in the delays in the Master clock to Slave clock direction compared > to the Slave clock to Master clock direction. The Timing LSP MAY be > MPLS/MPLS-TP LSP. > > The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS. > New Extensions to RSVP-TE/GMPLS TLVs are required; however they are > outside the scope of this document. > > The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such as > BFD and LSP Ping but the LSP data plane client plane traffic MUST be > Timing packets only. > > SB> Why? > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 12] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 6. Timing over LSP Encapsulation > > The encapsulations is not LSP is it? > > This document defines two methods for carrying Timing messages over > MPLS. The first method is carrying UDP/IP encapsulated Timing > messages over Timing LSPs, and the second method, is carrying > Ethernet encapsulated Timing messages over Ethernet PWs inside Timing > LSPs. > > 6.1. Timing over UDP/IP over MPLS Encapsulation > > The simplest method of transporting Timing messages over MPLS is to > encapsulate Timing PDUs in UDP/IP and then encapsulate them in Timing > LSP. This format is shown in Figure 4. > > > +----------------------+ > | Timing LSP Label | > +----------------------+ > | IPv4/6 | > +----------------------+ > | UDP | > +----------------------+ > | Timing PDU | > +----------------------+ > > Figure (4) - Timing over UDP/IP over MPLS Encapsulation > > > This encapsulation is very simple and is useful when the network > between Timing Master Clock and Slave Clock is MPLS network. > > SB> Simple is a judgement call > > In order for an LER/LSR to process Timing messages, the Timing LSP > Label must be at the top label of the label stack. The LER/LSR MUST > know that the Timing LSP Label is used for carrying Timing messages. > This can be accomplished via static configuration or via RSVP-TE > signaling. > > The UDP/IP encapsulation of PTP MUST follow Annex D and E of > [IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow > [RFC5905]. > > 6.2. Timing over PW Encapsulation > > Another method of transporting Timing over MPLS networks is by > encapsulating Timing PDUs in PW which in turn is transported over > Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448], > shown in Fig 5(A) MUST be used and the Ethernet encapsulation of PTP > MUST follow Annex F of [IEEE-1588]. > > > > Davari, et al. Expires December 17, 2013 [Page 13] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > The RAW mode or Tagged mode defined in [RFC4448] MAY be used and the > Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The > Timing over PW encapsulation MUST use the Control Word (CW) as > specified in [RFC4448] to ensure proper detection of PTP messages > inside the MPLS packets for Timing over LSP and Timing over PW > encapsulation. > > SB> That needs explanation > > The use of Sequence Number in the CW is optional. > > SB> Given that s/n are never in practice deployed, you could probably > SB> simplify things by sayig that they are not used. > > Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over PW > (the IP PW discussed in [RFC4447]) shown in Fig 5(B). > > +----------------+ +----------------+ > |Timing LSP Label| |Timing LSP Label| > +----------------+ +----------------+ > | PW Label | | PW Label | > +----------------+ +----------------+ > | Control Word | | IP | > +----------------+ +----------------+ > | Ethernet | | UDP | > | Header | +----------------+ > +----------------+ | Timing PDU | > |S-VLAN(Optional)| | | > +----------------+ +----------------+ > |C-VLAN(Optional)| (B) > +----------------+ > | Timing PDU | > | | > +----------------+ > (A) > > Figure (5) - Timing over PW Encapsulations > > In order for an LSR to process PTP messages, the top label of the > label stack (the Tunnel Label) MUST be a Timing label. > > S> You said that before. > > 6.3. Other Timing Encapsulation methods > > In future other timing encapsulation methods may be introduced, such > as a new shim header after the Bottom of Stack to carry the Timing > information. Such new encapsulations are outside the scope of this > document. > > > SB> Taking a pure MPLS pov, you can simplify a lot of the text > SB> out of the definition of the LSP > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 14] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > SB> I think we need a section on LSP processing > > 7. Timing message Processing > > Each Timing protocol such as PTP and NTP, define their set of Timing > messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, > FOLLOW_UP, etc messages. > > Some of the Timing messages require time stamping or correction field > update at port level and some dont. It is the job of the LER/LSR to > parse the timing message and find out the type of the Timing message > and decide whether and how to Time- stamp it (e.g., BC) or update > correction field(e.g., TC). > > > SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing > SB> function rather than the LER? > > For example the following PTP messages (called Event messages) > require time-stamping or correction field update: > > o SYNC > > o DELAY_REQ (Delay Request) > > o PDELAY_REQ (Peer Delay Request) > > o PDELAY_RESP (Peer Delay Response) > > SYNC and DELAY_REQ are exchanged between Master Clock and Slave Clock > and MUST be transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP > are exchanged between adjacent PTP clocks (i.e. Master, Slave, > Boundary, or Transparent) and SHOULD be transported over single hop > PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP, > and PDELAY_RESP_FOLLOW_UP messages MUST also be transported over > the > PTP LSPs. > > For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be > transported over two PTP LSPs that are in opposite directions. These > PTP LSPs, which are in opposite directions MUST be congruent and co- > routed. Alternatively, a single bidirectional co-routed LSP can be > used. > > Except as indicated above for the two-step PTP clocks, Non-Event PTP > message types do not need to be processed by intermediate routers. > These message types MAY be carried in PTP Tunnel LSPs. > > SB> Are you saying that a timing P router has to be msg type sensitive? > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 15] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 8. Protection and Redundancy > > > SB> This is a bit of a jump - I don't know how the LSP itself works yet! > > In order to ensure continuous uninterrupted operation of slave > clocks, usually as a general practice, slave clocks (or ports) track > redundant master clocks. > > It is the responsibility of the network operator to ensure that > physically disjoint Timing LSPs are established between a slave clock > (or port) and redundant master clocks (or ports). > > When a slave clock (or port) listens to redundant master clocks or > ports, any prolonged Timing LSP outage will trigger the slave clock > or port to switch to a redundant master clock or port. > > LSP/PW protection such as Linear protection Switching (1:1, 1+1), > Ring protection switching or MPLS Fast Reroute (FRR) generally switch > alternative path that usually cause a change in delay, which if > undetected by slave clock can reduce accuracy of the slave clock. > > Therefore protection switching MAY be used, as long as phase jumps > upon switchover due to differences in path latency are detected and > compensated for (such compensation not being required if BCs or peer- > peer TCs are used throughout). > > Note that any protection or reroute mechanism that adds additional > MPLS label to the label stack, such as Facility Backup Fast Reroute, > MUST ensure that the pushed label is also a Timing Label to ensure > recognition of the MPLS frame as containing Timing messages, as it > transits the backup path. > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 16] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 9. ECMP > > To ensure the optimal operation of slave clocks and avoid error > introduced by forward and reverse path delay asymmetry, the physical > path for Timing messages from master clock to slave Clock and vice > versa must be the same for all Event Timing messages listed in > section 7. > > Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost > Multipath). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 17] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 10. PHP > > To ensure that the label on the top of the label stack is the Timing > LSP Label, PHP MUST not be used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 18] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 11. Entropy > > To ensure all Timing messages in a Timing LSP take the same path, > Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and > Entropy Label MUST NOT be used for the PWs that are carried inside > Timing LSP [RFC6391]. > > SB> This is incorrect - you mean that all msgs of the same timing > SB> flow need to have the same EL value. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 19] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 12. OAM, Control and Management > > In order to monitor Timing LSPs and their encapsulated PWs, they MUST > be able to carry OAM and management messages. These management > messages MUST be differentiated from Timing messages via already > defined IETF methods. > > For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY run > over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These > Management protocols can easily be identified by the UDP Destination > Port number or by GAL/G-ACH respectively. > > Also BFD, LSP-Ping and other management messages MAY run over the PWs > encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3 or > 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is going > to be deprecated by IETF). In this case G-ACH, PW label (TTL=3D1) or > GAL-ACH are used to identify such management messages. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 20] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 13. QoS Considerations > > In network deployments where not every LSR/LER is Timing-aware, it is > important to reduce the impact of the non-Timing-aware LSR/LERs on > the timing recovery in the slave clock. The Timing messages are time > critical and must be treated with the highest priority. Therefore > Timing over MPLS messages must be treated with the highest priority > in the routers. This can be achieved by proper setup of Timing LSPs. > > It is recommended that the Timing LSPs are setup or configured > properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC2697] > for drop eligibility. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 21] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 14. FCS and Checksum Recalculation > > When time-stamp generation and timing packet adjustment is performed > near the physical port hardware, the process MUST include > recalculation of the Ethernet FCS. > > SB> The above is confusing - an LSR always recomputes the link layer > SB> CRC which may or may not be Ethernet. > > Also FCS retention for the > payload Ethernet described in [RFC4720] MUST NOT be used. > > For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum > may be required as per UDP transport standards. > > SB> You really need to be working on getting the IPv6 C?S computation > SB> removed from PTP msgs. > > When UDP checksum is used, each Timing-aware LER/LSR must either > incrementally update the UDP checksum after Time stamping or > Correction Field update or verify the UDP checksum on reception from > upstream and recalculate the checksum completely on transmission to > downstream node after Time stamping or Correction Field update. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 22] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 15. Behavior of LER/LSR > > Timing-capable/aware LERs and LSRs are routers that have one or more > > SB> You mean physical interfaces? > > interfaces that can perform Timing operations (OC/BC/TC) on Timing > packets and are configured to do so. Timing-capable/aware LERs and > LSRs can advertise their Timing-capability per-interface via control > plane such as OSPF or IS-IS. > SB> ISIS and OSPF are routing protocols. > > The Timing-capable/aware LERs can then > signals Timing LSPs via RSVP-TE signaling. Alternatively the Timing > capability of LER and LSRs may be configured in a centralized > controller and the Timing LSP may be setup using manual configuration > or other methods such as SDN. > > SB> it can also be configured individually rather then through > SB> a cebtral controllwe > > 15.1. Behavior of Timing-capable/aware LER > > When a Timing-capable/aware LER behaves as a Transparent clock and > receives a Timing message from a Timing-capable/aware non-MPLS > interface, the LER updates the Correction Field (CF) and encapsulates > and forwards the timing message over previously established Timing > LSP. > > SB> You need to call out the details so that people properly > SB> understand the definition of the new LSP. > > Also when a Timing message is received from a Timing-capable/ > aware MPLS interface, LER updates the Correction Filed (CF) and > decapsulates the MPLS encapsulation and forwards the timing message > to a non-MPLS interface. > > When a Timing-capable/aware LER behaves as a Boundary clock and > receives a Timing message from a Timing-capable/aware non MPLS > interface, the LER Timestamps the Timing packet and sends it to the > LERs Boundary clock processing module. Also when a Timing message is > received from a Timing- capable/aware MPLS interface, the LER > Timestamps the Timing packet and sends it to the LERs Boundary clock > processing module. > > When a Timing-capable/aware LER behaves as an Ordinary Clock toward > the MPLS network, and receives a Timing message from a Timing- > capable/aware MPLS interface, the LER Timestamps the Timing packet > and sends it to the LERs Ordinary clock processing module. > > 15.2. Behavior of Timing-capable/aware LSR > > When a Timing-capable/aware LSR behaves as a Transparent clock and > receives a Timing message from a Timing-capable/aware MPLS interface, > The LSR updates the Correction Filed (CF) and forwards the timing > message over another MPLS interface. > > When a Timing-capable/aware LSR behaves as a Boundary clock and > receives a Timing message from a Timing-capable/aware MPLS interface. > The LSR performs the functions of a Boundary Clock in terminating the > received Timing message and re-generating a new timing message over > another (or the same) MPLS interface. > > > > Davari, et al. Expires December 17, 2013 [Page 23] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 15.3. Behavior of non-Timing-capable/aware LSR > > It is most beneficial when all LSRs in the path of a Timing LSP be > timing-Capable/aware LSRs. This would ensure the highest quality > time and clock synchronization by Timing Slave Clocks. However, this > specification does not mandate that all LSRs in path of a Timing LSP > be Timing- capable/aware. > > Non-Timing-capable/aware LSRs just switch the packets encapsulated in > Timing LSPs and dont perform any Timing operation (TC or BC). > However as explained in QoS section the Timing over MPLS packets MUST > be still be treated with the highest priority based on their Traffic > Class (TC) marking. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 24] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 16. Other considerations > > [IEEE-1588] defines an optional peer-to-peer Transparent clocking > that requires peer delay measurement between two adjacent Timing- > capable/ aware routers/switches. Peer delay measurement messages > need to be time stamped and terminated by the Timing-capable/aware > routers/ switches. This means that two adjacent LSRs may be engaged > in a peer delay measurement. > > For transporting such peer delay measurement messages a single-hop > LSP SHOULD to be created between the two adjacent LSRs engaged in > peer delay measurement to carry peer delay measurement messages. > Other methods such as PTP transport over Ethernet MAY be used for > transporting peer delay measurement messages if the link between the > two routers is Ethernet. > > In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ ware > routers/switches MUST maintain a list of all the neighbors it needs > to send a PDelay_Req to, where each neighbor corresponds to a timing > LSP. > > The use of Explicit Null Label (Label=3D 0 or 2) is acceptable as long > as either the Explicit Null label is the bottom of stack label > (applicable only to UDP/IP encapsulation) or the label below the > Explicit Null label is a PTP label. > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 25] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 17. Security Considerations > > MPLS PW security considerations in general are discussed in [RFC3985] > and [RFC4447],and those considerations also apply to this document. > > An experimental security protocol is defined in [IEEE-1588].The PTP > security extension and protocol provides group source authentication, > message integrity, and replay attack protection for PTP messages. > > When the MPLS network (provider network) serves multiple customers, > it is important to maintain and process each customers clock and > Timing messages separately from other customers to ensure there is no > cross- customer effect. For example if an LER BC is synchronized to > a specific grandmaster, belonging to customer A, then the LER MUST > use that BC clock only for customer A to ensure that customer A > cannot attack other customers by manipulating its time. > > Timing messages MAY be encrypted or authenticated, provided that the > LERs/LSRs that are Timing capable/aware can authenticate/ decrypt the > timing messages. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 26] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 18. Acknowledgements > > The authors would like to thank Ron Cohen, Yaakov Stein, Tal Mizrahi, > Stefano Ruffini, Peter Meyer, and other members of IETF for reviewing > and providing feedback on this draft. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 27] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 19. IANA Considerations > > There are no IANA requirements in this specification. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 28] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 20. References > > 20.1. Normative References > > [IEEE-1588] > IEEE 1588-2008, "IEEE Standard for a Precision Clock > Synchronization Protocol for Networked Measurement and > Control Systems". > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- > Edge (PWE3) Architecture", RFC 3985, March 2005. > > [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery > Proxies (ND Proxy)", RFC 4389, April 2006. > > [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. > Heron, "Pseudowire Setup and Maintenance Using the Label > Distribution Protocol (LDP)", RFC 4447, April 2006. > > [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, > "Encapsulation Methods for Transport of Ethernet over MPLS > Networks", RFC 4448, April 2006. > > [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire > Emulation Edge-to-Edge (PWE3) Frame Check Sequence > Retention", RFC 4720, November 2006. > > [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit > Connectivity Verification (VCCV): A Control Channel for > Pseudowires", RFC 5085, December 2007. > > [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection > (BFD)", RFC 5880, June 2010. > > [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, > "Bidirectional Forwarding Detection (BFD) for MPLS Label > Switched Paths (LSPs)", RFC 5884, June 2010. > > 20.2. Informative References > > [I-D.ietf-pwe3-fat-pw] > Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, > J., and S. Amante, "Flow Aware Transport of Pseudowires > over an MPLS Packet Switched Network", > draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011. > > > > Davari, et al. Expires December 17, 2013 [Page 29] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate > system routeing information exchange protocol for use in > conjunction with the Protocol for providing the > Connectionless-mode Network Service (ISO 8473)". > > [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and > dual environments", RFC 1195, December 1990. > > [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. > > [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color > Marker", RFC 2697, September 1999. > > [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, > J., Courtney, W., Davari, S., Firoiu, V., and D. > Stiliadis, "An Expedited Forwarding PHB (Per-Hop > Behavior)", RFC 3246, March 2002. > > [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering > (TE) Extensions to OSPF Version 2", RFC 3630, > September 2003. > > [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate > System (IS-IS) Extensions for Traffic Engineering (TE)", > RFC 3784, June 2004. > > [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. > Shaffer, "Extensions to OSPF for Advertising Optional > Router Capabilities", RFC 4970, July 2007. > > [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate > System to Intermediate System (IS-IS) Extensions for > Advertising Router Information", RFC 4971, July 2007. > > [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi > Topology (MT) Routing in Intermediate System to > Intermediate Systems (IS-ISs)", RFC 5120, February 2008. > > [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic > Engineering", RFC 5305, October 2008. > > [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, > "Traffic Engineering Extensions to OSPF Version 3", > RFC 5329, September 2008. > > [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF > for IPv6", RFC 5340, July 2008. > > > > > Davari, et al. Expires December 17, 2013 [Page 30] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network > Time Protocol Version 4: Protocol and Algorithms > Specification", RFC 5905, June 2010. > > [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, > J., and S. Amante, "Flow-Aware Transport of Pseudowires > over an MPLS Packet Switched Network", RFC 6391, > November 2011. > > [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and > L. Yong, "The Use of Entropy Labels in MPLS Forwarding", > RFC 6790, November 2012. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 31] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 1. Routing extensions for Timing-aware Routers > > MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and > IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE) > link information used for constraint-based routing. > > Indeed, it is useful to advertise data plane TE router link > capabilities, such as the capability for a router to be Timing-aware. > This capability MUST then be taken into account during path > computation to prefer or even require links that advertise themselves > as Timing-aware. In this way the path can ensure the entry and exit > points into the LERs and, if desired, the links into the LSRs are > able to perform port based time-stamping thus minimizing their impact > on the performance of the slave clock. > > extensions are required to OSPF and IS-IS in order to advertise > Timing-aware capabilities of a link. Such extensions are outside the > scope of this document; however such extension SHOULD be able to > signal the following information per Router Link: > > o Capable of processing PTP, NTP or other Timing flows > > o Capable of performing Transparent Clock operation > > o Capable of performing Boundary Clock operation > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 32] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > 2. Signaling Extensions for Creating Timing LSPs > > RSVP-TE signaling MAY be used to setup the timing LSPs. When RSVP-TE > is used to setup Timing LSPs, some information that indicates that > the LSP is carrying Timing flows MUST be included in the new > Extensions to RSVP-TE: > > The following information MAY also be included in the new Extensions > to RSVP-TE: > > o Offset from Bottom of Stack (BoS) to the start of the Time-stamp > field > > o Number of VLANs in case of PW encapsulation > > o Timestamp field Type > > * Correction Field, Timestamp > > o Timestamp Field format > > * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit > NTP, etc. > > Note that in case the above optional information is signaled with > RSVP-TE for a Timing LSP, all the Timing packets carried in that LSP > must have the same signaled characteristics. For example if > Timestamp format is signaled as 64-bit PTPv1, then all Timing packets > must use 64-bit PTPv1 time-stamp. > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 33] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > Authors' Addresses > > Shahram Davari > Broadcom Corp. > San Jose, CA 95134 > USA > > Email: davari@broadcom.com > > > Amit Oren > Broadcom Corp. > San Jose, CA 95134 > USA > > Email: amito@broadcom.com > > > Manav Bhatia > Alcatel-Lucent > Bangalore, > India > > Email: manav.bhatia@alcatel-lucent.com > > > Peter Roberts > Alcatel-Lucent > Kanata, > Canada > > Email: peter.roberts@alcatel-lucent.com > > > Laurent Montini > Cisco Systems > San Jose CA > USA > > Email: lmontini@cisco.com > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 34] > > Internet-Draft Transporting Timing over MPLS June 2013 > > > Luca > Cisco Systems > San Jose CA > USA > > Email: lmartini@cisco.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Davari, et al. Expires December 17, 2013 [Page 35] > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc 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 davarish@yahoo.com Sun Aug 4 02:40:27 2013 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 E448C21F9AC4 for ; Sun, 4 Aug 2013 02:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 SbdV-VNsw74O for ; Sun, 4 Aug 2013 02:40:23 -0700 (PDT) Received: from nm48-vm2.bullet.mail.gq1.yahoo.com (nm48-vm2.bullet.mail.gq1.yahoo.com [67.195.87.190]) by ietfa.amsl.com (Postfix) with ESMTP id 41D4B21F9956 for ; Sun, 4 Aug 2013 02:40:18 -0700 (PDT) Received: from [98.137.12.63] by nm48.bullet.mail.gq1.yahoo.com with NNFMP; 04 Aug 2013 09:40:16 -0000 Received: from [98.136.164.77] by tm8.bullet.mail.gq1.yahoo.com with NNFMP; 04 Aug 2013 09:40:16 -0000 Received: from [127.0.0.1] by smtp239.mail.gq1.yahoo.com with NNFMP; 04 Aug 2013 09:40:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1375609216; bh=JyRw1/3tiObsThfCkXU5K0iKPNkWj626nUOoWjNweBY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=D2XIbHKyq5RSyd62qy80wnlflXBkUd2GIAvz9iEtj+cekloqPfVdsMbO+Y0g3zfmTqX9Txrk5wInTDEEJE7ZM7GUm02xKlvftIGq3Q2cuoOjPFjfVY2XhYIC7uKHBw+kaofA8PN4g7SpXHHP+3+O0kTQN08O3OGDjSGjO9TSICI= X-Yahoo-Newman-Id: 288057.58595.bm@smtp239.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: SC5BptIVM1lCQhouG0U8uGHi65bxQXEUev1.flr0tBTrWtI z79mk8.GSMP6wU82FEGR7Vuwsljk2NFwmecWUrJ_d4mWOT_DKnclEClVY79G O1mqK_0uF0apW2rm2LaCPDN4WRaVJh2u6tgH2yB7gzlzT7cp03TYbrpJmw_I 39B6Z1qb1lORrhW7RNmCJ_uMOXgLT5_MPkQS8gQH9GHEOvJkq5mzxnnbjMgV KuCGSCTK5Fza3Hy00UYyOVh9n7.cv_edewfBErwwkj4uWWBfXGP8KPoo4dMr UJnk5qQ2WUGnLYSs65yTjdisamoCTxEazM_H4cJY6DyAay4NAhllOZ54fPOH NqH6x5fCodbSB3Svm149qi9OyxdjqbW2j7mNnnvvo9vmfFXC_fPCwMW0PuMr tdtlZNhJB.AK2GeffYOnUb36jrXEGK0K2t75jqKo9dS6N9DCwPnCcjIVn0HH pxHFOa2IxbD9jv_IEvezpcIR5UBrpLU6DpGZiyVJhKz5cDAZqpZh7CiaHXrd tR8hPudYClqChgLEunii0mnXiH9lkfQ4oM.hEOFI2w900ChU3iR32 X-Yahoo-SMTP: ygPrP9CswBCWPbPtKJlJyLY0KMlg X-Rocket-Received: from [192.168.0.103] (davarish@98.248.42.143 with ) by smtp239.mail.gq1.yahoo.com with SMTP; 04 Aug 2013 09:40:16 +0000 UTC References: <51FB7543.801@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A403) From: "S. Davari" Date: Sun, 4 Aug 2013 02:40:13 -0700 To: Alexander Vainshtein Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] Comments on draft-ietf-tictoc-1588overmpls 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, 04 Aug 2013 09:40:28 -0000 Hi Sasha Perhaps you have not understood the draft well. The main reason that the dra= ft chose to use a dedicated LSP that is signaled via RSVPTE indicating it is= a timing LSP is to be backward compatible with non-1588 nodes. Such nodes s= imply just switch the packet. Your proposal had been considered and was rejected since it was not backward= compatible. Nodes receiving alert label or TTL =3D 1 send the packet to CPU= . You can refer to the meeting notes. Regards, Shahram On Aug 4, 2013, at 1:21 AM, Alexander Vainshtein wrote: > Stewart and all, > I concur with Stewart's statement that the draft does not define "full int= eraction with MPLS architecture". >=20 > E.g., one of the objectives of the draft is to provide a technique that wo= uld be backward-compatible with old LSRs that cannot provide on-path support= for timing distribution, while the other objective is to make every LSR on t= he path aware that some MPLS packets are carrying timing-related messages an= d hence require on-path support. >=20 > IMHO and FWIW, the MPLS data plane architecture allows just two methods fo= r making a transit LSR to provide special processing to a labeled packet: > - It would carry some kind of an "alert label" on top of the label stack a= nd, specifically, on top of any labels used for actual forwarding > OR, > - The TTL in the top label stack entry has been set to 1. >=20 >=20 > The draft does not follow any of these approaches. >=20 > I must also admit that Section 12 "OAM, Control and Management" of the dra= ft looks somewhat in > E.g., I could not understand from the text whether BFD, LSP-Ping etc. OAM m= essages would be subjected to on-path support procedures for timing messages= or not. >=20 > My 2c, > Sasha >=20 >> -----Original Message----- >> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf O= f >> Stewart Bryant >> Sent: Friday, August 02, 2013 12:01 PM >> To: mpls-chairs@tools.ietf.org; tictoc-chairs@tools.ietf.org; int- >> ads@tools.ietf.org; rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; d= raft- >> ietf-tictoc-1588overmpls@tools.ietf.org >> Cc: mpls@ietf.org; tictoc@ietf.org >> Subject: [TICTOC] Comments on draft-ietf-tictoc-1588overmpls >>=20 >> SB> This draft does not seem to provide a precise definition >> SB> the properties of the new LSP type that it wishes to >> SB> define, in particular it does it define the PHB of those >> SB> LSPs, nor the full interaction with the MPLS >> SB> architecture. >> SB> >> SB> I have not tracked TICTOC for a while but I thought that >> SB> the original plan was to define the concept of an offset >> SB> into a packet to do the correction. >> SB> >> SB> It is disappointing that the opportunity was not taken >> SB> to define a timing shim inside the timing LSP so that >> SB> a time correction could be added to any packet such that >> SB> the MPLS system was isolated from the details of the >> SB> complexity of the particular time transfer type. >>=20 >> SB> I think that much more clarify is needed in terms of >> SB> definition of the new LSP type, since it is unclear >> SB> from this text how to implement one. >> SB> >> SB> There are a lot of other MPLS services such as >> SB> LSP ping that need to be considered. >> SB> >> SB> Please see inline for more comments. However these >> SB> comments are made in the context of the text as written >> SB> whilst I have a fundamental concern that this approach >> SB> lacks an MPLS architectural soundness that need >> SB> greater thought with significant impact on the >> SB> draft. >>=20 >> - Stewart >>=20 >>=20 >> TICTOC Working Group S. Davari >> Internet-Draft A. Oren >> Intended status: Standards Track Broadcom Corp. >> Expires: December 17, 2013 M. Bhatia >> P. Roberts >> Alcatel-Lucent >> L. Montini >> L. Martini >> Cisco Systems >> June 15, 2013 >>=20 >>=20 >> Transporting Timing messages over MPLS Networks >> draft-ietf-tictoc-1588overmpls-05 >>=20 >> Abstract >>=20 >> This document defines the method for transporting Timing messages >> such as PTP and NTP over an MPLS network. The method allows for the >> easy identification of these PDUs at the port level to allow for port >>=20 >> SB> What is a port >>=20 >> level processing of these PDUs in both LERs and LSRs. >>=20 >> The basic idea is to transport Timing messages inside dedicated MPLS >> LSPs. These LSPs only carry Timing messages and possibly Control and >> Management packets, but they do not carry customer traffic. >>=20 >> SB> More specifically they only carry traffic associated with the >> SB> timing service and its support. >> SB> The question arose WRT BFD - surely BFD is allowed, BUT surely >> SB> also it gets carried in a structure that causes it to get >> SB> timestamped. >>=20 >> Two methods for transporting Timing messages over MPLS are defined. >>=20 >> SB> Perhaps the right approach is to define the new LSP type and then >> SB> seperately to define the mapping of the various timing services >> SB> over that LSP type. >>=20 >> The first method is to transport Timing messages directly over the >> dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for >> MPLS networks. The second method is to transport Timing messages >> inside a PW via Ethernet encapsulation. >>=20 >> SB> I think that we should note that there are some >> SB> h/w reasons for this preference. A clean sheet approach >> SB> would have been to use PTP over MPLS with no intermediate >> SB> layers. >>=20 >> Status of this Memo >>=20 >> This Internet-Draft is submitted in full conformance with the >> provisions of BCP 78 and BCP 79. >>=20 >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF). Note that other groups may also distribute >> working documents as Internet-Drafts. The list of current Internet- >> Drafts is at http://datatracker.ietf.org/drafts/current/. >>=20 >> Internet-Drafts are draft documents valid for a maximum of six months >> and may be updated, replaced, or obsoleted by other documents at any >> time. It is inappropriate to use Internet-Drafts as reference >> material or to cite them other than as "work in progress." >>=20 >> This Internet-Draft will expire on December 17, 2013. >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 1] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> Copyright Notice >>=20 >> Copyright (c) 2013 IETF Trust and the persons identified as the >> document authors. All rights reserved. >>=20 >> This document is subject to BCP 78 and the IETF Trust's Legal >> Provisions Relating to IETF Documents >> (http://trustee.ietf.org/license-info) in effect on the date of >> publication of this document. Please review these documents >> carefully, as they describe your rights and restrictions with respect >> to this document. Code Components extracted from this document must >> include Simplified BSD License text as described in Section 4.e of >> the Trust Legal Provisions and are provided without warranty as >> described in the Simplified BSD License. >>=20 >>=20 >> Table of Contents >>=20 >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 >>=20 >> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 >>=20 >> 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 >>=20 >> 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . 9 >>=20 >> 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . . 12 >>=20 >> 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . 13 >> 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . . 13 >> 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . . 13 >> 6.3. Other Timing Encapsulation methods . . . . . . . . . . . . 14 >>=20 >> 7. Timing message Processing . . . . . . . . . . . . . . . . . . 15 >>=20 >> 8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 16 >>=20 >> 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 >>=20 >> 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 >>=20 >> 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 >>=20 >> 12. OAM, Control and Management . . . . . . . . . . . . . . . . . 20 >>=20 >> 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 21 >>=20 >> 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . . 22 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 2] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 23 >> 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . . 23 >> 15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . . 23 >> 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . . 24 >>=20 >> 16. Other considerations . . . . . . . . . . . . . . . . . . . . . 25 >>=20 >> 17. Security Considerations . . . . . . . . . . . . . . . . . . . 26 >>=20 >> 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 >>=20 >> 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 >>=20 >> 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 >> 20.1. Normative References . . . . . . . . . . . . . . . . . . . 29 >> 20.2. Informative References . . . . . . . . . . . . . . . . . . 29 >>=20 >> Appendix 1. Routing extensions for Timing-aware Routers . . . . . 32 >>=20 >> Appendix 2. Signaling Extensions for Creating Timing LSPs . . . . 33 >>=20 >> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 3] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in >> this >> document are to be interpreted as described in RFC2119 [RFC2119]. >>=20 >> When used in lower case, these words convey their typical use in >> common language, and are not to be interpreted as described in >> RFC2119 [RFC2119]. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 4] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 1. Introduction >>=20 >> The objective of Precision Time Protocol (PTP) and Network Timing >> Protocol (NTP) are to synchronize independent clocks running on >> separate nodes of a distributed system. >>=20 >> [IEEE-1588] defines PTP messages for frequency, phase and time >> synchronization. The PTP messages include PTP PDUs over UDP/IP >> (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex F of >> [IEEE-1588]). >>=20 >> SB> Sure BUT it is acknowledged that IEEE is open to the definition >> SB> of other PTP mappings if they provide better optimisation. >>=20 >> This document defines mapping and transport of the PTP >> messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP >> defines several clock types: ordinary clocks, boundary clocks, end- >> to-end transparent clocks, and peer-to-peer transparent clocks. >> Transparent clocks require intermediate nodes to update correction >> field inside PTP message that reflects the transit time in the node. >>=20 >> [RFC5905] defines NTP messages for clock and time synchronization. >> The PTP messages (PDUs) are transported over UDP/IP. This document >> SB> Should that be NTP messages? >> SB> It needs to be made clear as soon as you introduce NTP that >> SB> they use different time representations. >>=20 >> defines mapping and transport of the NTP messages defined in >> [RFC5905] over MPLS networks. >>=20 >> One key attribute of all of these Timing messages is that the Time >> stamp processing should occur as close as possible to the actual >> transmission and reception at the physical port interface. This >> targets optimal time and/or frequency recovery by avoiding variable >> delay introduced by queues internal to the clocks. >>=20 >> SB> As I recall NTP has no epoch point defined, and I am not sure >> SB> where that point is in the case of PTP in this mapping >> SB> Hopefully this will get defined in due course. >>=20 >> To facilitate the fast and efficient recognition of Timing messages >> at the port level when the Timing messages are carried over MPLS >> LSPs, >>=20 >> SB> Over a new LSP type with time optimied characteristics >>=20 >> this document defines the specific encapsulations that should >> be used. >> SB> Hopefully it will also define the PHP >>=20 >> In addition, it can be expected that there will exist LSR/ >> LERs where only a subset of the physical ports will have the port- >> based Timing message processing capabilities. >> SB> Do you need to clarify that this only works at base and not in >> SB> a label heirarchy. >>=20 >>=20 >> In order to ensure >> that the LSPs carrying Timing packets always enter and exit ports >> with this capability, routing extensions are defined to advertise >> this capability on a port basis and to allow for the establishment of >> LSPs that only transit such ports. While this path establishment >> restriction may be applied only at the LER Ingress and/or egress >> ports, it becomes more important when using transparent clock capable >> LSRs in the path. >> SB> I do not understand the implications of the last >> SB> sentences - starting ", it becomes" >>=20 >>=20 >> Port based Timing message processing involves Timing message >> recognition. Once the Timing messages are recognized they can be >> modified based on the reception or transmission Time-stamp. >>=20 >> This document provides two methods for transporting Timing messages >> over MPLS. One is applicable to MPLS environment and the other one >> is applicable to MPLS/MPLS-TP environment >>=20 >> SB> I think the sentence is incomplete. >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 5] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> The solution involves transporting Timing messages over dedicated >> LSPs called Timing LSPs. These LSPs carry Timing messages and MAY >> carry Management and control messages, but not data plane client >> traffic. >>=20 >> SB> It is not clear why this restriction applies. >>=20 >> Timing LSPs can be established statically or via signaling. >> SB> s/statically/by provisioning/network management/ >>=20 >> Extensions to control plane (OSPF, ISIS, etc.) is required to enable >> routers to distribute their Timing processing capabilities over MPLS >> to other routers. However such extensions are outside the scope of >> this document. >>=20 >> When signaling is used to setup the PTP LSP, Extensions to signaling >> SB> is it a PTP LSP or a Timing LSP? >>=20 >> protocols (e.g., RSVP-TE) are required for establishing PTP LSPs. >> However such extensions are outside the scope of this document. >>=20 >> SB> for mpls-tp GMPLS is the signalling protocol >>=20 >> While the techniques included herein allow for the establishment of >> paths optimized to include Time-stamping capable links, the >> performance of the Slave clocks is outside the scope of this >> document. >>=20 >> At the time of publishing this specification, Transparent Clocking >> (TC) is only defined for PTP. Therefore at this time any part of >> this specification that talks about Transparent Clocking applies only >> to PTP. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 6] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 2. Terminology >>=20 >> 1588: The timing and synchronization as defined by IEEE 1588. >>=20 >> SB> I think that there is a more formal name for the 1588 group >> SB> that needs to be used here. >> SB> Also do we need to talk about 1588-200? as there is >> SB> an update in progress >>=20 >> NTP: The timing and synchronization protocol defined by IETF RFC-1305 >> and RFC-5905. >>=20 >> PTP: The timing and synchronization protocol used by 1588. >> SB> need the proper name for 1588 >>=20 >> Master Clock: The source of 1588 timing to a set of slave clocks. >>=20 >> Master Port: A port on a ordinary or boundary clock that is in Master >> state. This is the source of timing toward slave ports. >>=20 >> SB> I am not sure the reader knows what a port is >>=20 >> Slave Clock: A receiver of 1588 timing from a master clock. >>=20 >> Slave Port: A port on a boundary clock or ordinary clock that is >> receiving timing from a master clock. >>=20 >> Ordinary Clock: A device with a single PTP port. >>=20 >> Transparent Clock. A device that measures the time taken for a PTP >> event message to transit the device and then updates the >> correctionField of the message with this transit time. >>=20 >> Boundary Clock: A device with more than one PTP port. Generally >> boundary clocks will have one port in slave state to receive timing >> and then other ports in master state to re-distribute the timing. >>=20 >> PTP LSP: An LSP dedicated to carry PTP messages >>=20 >> SB> PTP or timing? >>=20 >>=20 >> PTP PW: A PW within a PTP LSP that is dedicated to carry PTP >> messages. >>=20 >> SB> Ah I don't think that PWE3 know what one of these is >>=20 >> CW: Pseudowire Control Word >>=20 >> LAG: Link Aggregation >>=20 >> ECMP: Equal Cost Multipath >>=20 >> CF: Correction Field, a field inside certain PTP messages (message >> type 0-3)that holds the accumulative transit time inside intermediate >> switches >>=20 >> Timing messages: Timing Protocol messages that are exchanged between >> routers in order to establish a synchronized clock. >>=20 >> SB> A number of these definitions look like copies of IEEE1588 >> SB> definitions. We need to provide references and note the >> SB> priority of the IEEE base reference. >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 7] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 3. Problem Statement >>=20 >> [IEEE-1588] has defined methods for transporting PTP messages over >> Ethernet and IP networks. [RFC5905] has defined the method of >> transporting NTP messages over IP networks. There is a need to >> transport Timing messages over MPLS networks while supporting the >> Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC) >> functionality in the LER and LSRs in the MPLS network. >>=20 >> There are multiple ways of transporting Timing over MPLS. However, >> there is a requirement to limit the possible encapsulation options to >> simplify the Timing message identification and processing required at >> the port level. >>=20 >> When Timing-awareness is needed, Timing messages should not be >> transported over LSPs or PWs that are carrying customer traffic >> because LSRs perform Label switching based on the top label in the >> stack. >>=20 >> SB> Have you explained why? >>=20 >> To detect Timing messages inside such LSPs require special >> hardware to do deep packet inspection at line rate. Even if such >> hardware exists, the payload can't be deterministically identified by >> LSRs because the payload type is a context of the PW label, and the >> PW label and its context are only known to the Edge routers (PEs/ >> LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, CES, >> etc). Even if one restricts an LSP to only carry Ethernet PWs, the >> LSRs dont have the knowledge of whether PW Control Word (CW) is >> present or not and therefore can not deterministically identify the >> payload. >>=20 >> A generic method is defined in this document that does not require >> deep packet inspection at line rate, and can deterministically >> identify Timing messages. This method can be used to detect Timing >> Messages in both one-step and two-step clock implementations of >> ordinary, boundary and transparent clocks. >>=20 >> SB> Needs a ref and I am sure many MPLS specialists will not understand >> SB> the msg types. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 8] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 4. Timing over MPLS Architecture >>=20 >> Timing messages are exchange between Timing ports on ordinary and >>=20 >> SB> Have you defined a timing port? >>=20 >> boundary clocks. Boundary clocks terminate the Timing messages and >> act as master for other boundary clocks or for slave clocks. End-to- >> End Transparent clocks do not terminate the Timing messages but they >> do modify the contents of the Timing messages as they transit across >> the transparent clock. >>=20 >> Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent Clock >>=20 >> (TC) could be implemented in either LERs or LSRs. >>=20 >> SB> LER and LSR need to be expanded >>=20 >> An example is shown in Figure 1, where the LERs act as Ordinary Clock >> (OC) and are the initiating/terminating point for Timing messages. >> The ingress LER encapsulates the Timing messages in Timing LSP and >> the Egress LER terminates the Timing LSP. The LSRs act as >> Transparent Clock (TC) and just update the Timing field in the Timing >> messages. >>=20 >>=20 >> +--------+ +-------+ +-------+ +-------+ +--------+= >> |Switch, | | | | | | | |Switch, |= >> | Router |-----| LER |-----| LSR |-----| LER |-----| Router |= >> | | | OC | | TC | | OC | | |= >> +--------+ +-------+ +-------+ +-------+ +--------+= >> / \ >> +-------+ / \ +-------+ >> | LER | / \ | LER | >> | Master|---/ \---| Slave | >> | Clock | | Clock | >> +-------+ +-------+ >>=20 >> Figure (1) - Deployment example 1 of timing over MPLS network >>=20 >> Another example is shown in Figure2, where LERs terminate the Timing >> messages received from switch/routers that are outside of the MPLS >> network acting as OC or BC. In this example LERs regenerate the >> clock and initiate timing messages encapsulated in Timing LSP toward >> the MPLS network, while the LSRs act as Transparent Clock (TC) and >> just update the Timing field in the Timing messages, which are >> already encapsulated in Timing LSPs. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 9] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> +--------+ +-------+ +-------+ +-------+ +--------+ >> |Switch, | | | | | | | |Switch, | >> | Router |-----| LER |-----| LSR |-----| LER |-----| Router | >> | OC/BC | | BC | | TC | | BC | | OC/BC | >> +--------+ +-------+ +-------+ +-------+ +--------+ >>=20 >> Figure (2) - Deployment example 2 of timing over MPLS network >>=20 >>=20 >> Another example is shown in Figure 3, where LERs do not terminate the >> Timing messages received from switch/routers that are outside of the >> MPLS network acting as OC, TC or BC. The LERs act as TC and update >> the Timing field in the Timing messages as they transit the LER, >> while encapsulating them in timing LSP. The LSRs also act as >> Transparent Clock (TC) and just update the Timing field in the Timing >> messages which are already encapsulated in Timing LSPs. >>=20 >> +--------+ +-------+ +-------+ +-------+ +--------+= >> |Switch, | | | | | | | |Switch, |= >> | Router |-----| LER |-----| LSR |-----| LER |-----| Router |= >> |OC/TC/BC| | TC | | TC | | TC | |OC/TC/BC|= >> +--------+ +-------+ +-------+ +-------+ +--------+= >>=20 >> Figure (3) - Deployment example 3 of timing over MPLS network >>=20 >> Another example is shown in Figure 4, where LERs and LSRs support >> Boundary Clocks. A single-hop LSP is created between two adjacent >> LSRs engaged in BC operation. Other methods such as PTP transport >> over Ethernet MAY be used for transporting timing messages if the >> link between the two routers is Ethernet. >>=20 >> +--------+ +-------+ +-------+ +-------+ +--------+ >> |Switch, | | | | | | | |Switch, | >> | Router |-----| LER |-----| LSR |-----| LER |-----| Router | >> | OC/BC | | BC | | BC | | BC | | OC/BC | >> +--------+ +-------+ +-------+ +-------+ +--------+ >>=20 >> Figure (4) - Deployment example 3 of timing over MPLS network >>=20 >> An MPLS domain MAY serve multiple customers. In these cases the MPLS >> domain (maintained by a service provider) may provide timing services >> to multiple customers, each having their own Timing domain. >>=20 >> The Timing over MPLS architecture assumes full mesh of Timing LSPs >> between all LERs supporting this specification. >>=20 >> SB> Note sure this is right - the salves surely do not need to >> SB> exchange timing amongst themselves >>=20 >> It supports >> Point-to- point (VPWS) and Multipoint (VPLS) services. >>=20 >> SB> What does that mean? You do not carry user data traffic? >> SB> Maybe it's the ordering of the statemnets that is causing >> SB> confusion. >>=20 >> This means >> that a customer may purchase a Point-to-point Timing service between >> two customer sites or a Multipoint Timing service between more than >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 10] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> two customer sites. >>=20 >> The Timing over MPLS architecture supports P2P or P2MP Timing LSPs. >> This means that the Timing Multicast messages such as PTP Multicast >> event messages can be transported over P2MP Timing LSP or be >> replicated and transported over many P2P Timing LSPs. >>=20 >> SB> Note we do not yet have a definition of a P2MP mpls-tp LSP >> SB> nor a P2MP PW, although we are close. >>=20 >> Timing messages, that do not require Time stamping or Correction >> Field update MAY be transported over Timing LSPs to simplify hardware >> and software. >>=20 >> PTP Announce messages that determine the Timing LSP terminating point >> behavior such as BC/OC/TC SHOULD be transported over the Timing LSP >> to simplify hardware and software. >>=20 >> SB> have you defined and referenced PTP announce msgs? >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 11] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 5. Dedicated LSPs for Timing messages >>=20 >> Many methods have been considered for identifying the Timing messages >> when they are encapsulated in MPLS such as using GAL/G-ACH or a new >> reserved label. These methods were not attractive since they either >> required deep packet inspection at line rate in the intermediate LSRs >> or they required use of a scarce new reserved label. Also one of the >> goals was to reuse existing OAM mechanisms. >>=20 >> SB> RLs =3D SPLs are not so rare now. In any case needs a ref. >>=20 >> The method defined in this document can be used by LER and LSRs to >> identify Timing messages in MPLS tunnels by just looking at the top >> label in the MPLS label stack, which only carry Timing messages as >> well as OAM, but not data plane client traffic. >>=20 >> Compliant implementations MUST use dedicated LSPs to carry Timing >> messages over MPLS. >>=20 >> SB> I think that we need a definition of the properies of these LSPs >>=20 >> These LSPs are herein referred to as "Timing >> LSPs" and the labels associated with these LSPs as "Timing LSP >> labels". The Timing LSPs that runs between Ingress and Egress LERs >> MUST be co-routed. Alternatively, a single bidirectional co-routed >> LSP can be used. >>=20 >> SB> I though that you said you could use M2MP LSPs - these are not >> SB> bidirectional. >>=20 >> Co-routing of the two directions is required to limit the difference >> in the delays in the Master clock to Slave clock direction compared >> to the Slave clock to Master clock direction. The Timing LSP MAY be >> MPLS/MPLS-TP LSP. >>=20 >> The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS. >> New Extensions to RSVP-TE/GMPLS TLVs are required; however they are >> outside the scope of this document. >>=20 >> The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such as >> BFD and LSP Ping but the LSP data plane client plane traffic MUST be >> Timing packets only. >>=20 >> SB> Why? >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 12] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 6. Timing over LSP Encapsulation >>=20 >> The encapsulations is not LSP is it? >>=20 >> This document defines two methods for carrying Timing messages over >> MPLS. The first method is carrying UDP/IP encapsulated Timing >> messages over Timing LSPs, and the second method, is carrying >> Ethernet encapsulated Timing messages over Ethernet PWs inside Timing >> LSPs. >>=20 >> 6.1. Timing over UDP/IP over MPLS Encapsulation >>=20 >> The simplest method of transporting Timing messages over MPLS is to >> encapsulate Timing PDUs in UDP/IP and then encapsulate them in Timing >> LSP. This format is shown in Figure 4. >>=20 >>=20 >> +----------------------+ >> | Timing LSP Label | >> +----------------------+ >> | IPv4/6 | >> +----------------------+ >> | UDP | >> +----------------------+ >> | Timing PDU | >> +----------------------+ >>=20 >> Figure (4) - Timing over UDP/IP over MPLS Encapsulation >>=20 >>=20 >> This encapsulation is very simple and is useful when the network >> between Timing Master Clock and Slave Clock is MPLS network. >>=20 >> SB> Simple is a judgement call >>=20 >> In order for an LER/LSR to process Timing messages, the Timing LSP >> Label must be at the top label of the label stack. The LER/LSR MUST >> know that the Timing LSP Label is used for carrying Timing messages. >> This can be accomplished via static configuration or via RSVP-TE >> signaling. >>=20 >> The UDP/IP encapsulation of PTP MUST follow Annex D and E of >> [IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow >> [RFC5905]. >>=20 >> 6.2. Timing over PW Encapsulation >>=20 >> Another method of transporting Timing over MPLS networks is by >> encapsulating Timing PDUs in PW which in turn is transported over >> Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448], >> shown in Fig 5(A) MUST be used and the Ethernet encapsulation of PTP >> MUST follow Annex F of [IEEE-1588]. >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 13] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> The RAW mode or Tagged mode defined in [RFC4448] MAY be used and the >> Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The >> Timing over PW encapsulation MUST use the Control Word (CW) as >> specified in [RFC4448] to ensure proper detection of PTP messages >> inside the MPLS packets for Timing over LSP and Timing over PW >> encapsulation. >>=20 >> SB> That needs explanation >>=20 >> The use of Sequence Number in the CW is optional. >>=20 >> SB> Given that s/n are never in practice deployed, you could probably >> SB> simplify things by sayig that they are not used. >>=20 >> Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over PW >> (the IP PW discussed in [RFC4447]) shown in Fig 5(B). >>=20 >> +----------------+ +----------------+ >> |Timing LSP Label| |Timing LSP Label| >> +----------------+ +----------------+ >> | PW Label | | PW Label | >> +----------------+ +----------------+ >> | Control Word | | IP | >> +----------------+ +----------------+ >> | Ethernet | | UDP | >> | Header | +----------------+ >> +----------------+ | Timing PDU | >> |S-VLAN(Optional)| | | >> +----------------+ +----------------+ >> |C-VLAN(Optional)| (B) >> +----------------+ >> | Timing PDU | >> | | >> +----------------+ >> (A) >>=20 >> Figure (5) - Timing over PW Encapsulations >>=20 >> In order for an LSR to process PTP messages, the top label of the >> label stack (the Tunnel Label) MUST be a Timing label. >>=20 >> S> You said that before. >>=20 >> 6.3. Other Timing Encapsulation methods >>=20 >> In future other timing encapsulation methods may be introduced, such >> as a new shim header after the Bottom of Stack to carry the Timing >> information. Such new encapsulations are outside the scope of this >> document. >>=20 >>=20 >> SB> Taking a pure MPLS pov, you can simplify a lot of the text >> SB> out of the definition of the LSP >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 14] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> SB> I think we need a section on LSP processing >>=20 >> 7. Timing message Processing >>=20 >> Each Timing protocol such as PTP and NTP, define their set of Timing >> messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, >> FOLLOW_UP, etc messages. >>=20 >> Some of the Timing messages require time stamping or correction field >> update at port level and some dont. It is the job of the LER/LSR to >> parse the timing message and find out the type of the Timing message >> and decide whether and how to Time- stamp it (e.g., BC) or update >> correction field(e.g., TC). >>=20 >>=20 >> SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing >> SB> function rather than the LER? >>=20 >> For example the following PTP messages (called Event messages) >> require time-stamping or correction field update: >>=20 >> o SYNC >>=20 >> o DELAY_REQ (Delay Request) >>=20 >> o PDELAY_REQ (Peer Delay Request) >>=20 >> o PDELAY_RESP (Peer Delay Response) >>=20 >> SYNC and DELAY_REQ are exchanged between Master Clock and Slave Clock >> and MUST be transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP >> are exchanged between adjacent PTP clocks (i.e. Master, Slave, >> Boundary, or Transparent) and SHOULD be transported over single hop >> PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP, >> and PDELAY_RESP_FOLLOW_UP messages MUST also be transported over >> the >> PTP LSPs. >>=20 >> For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be >> transported over two PTP LSPs that are in opposite directions. These >> PTP LSPs, which are in opposite directions MUST be congruent and co- >> routed. Alternatively, a single bidirectional co-routed LSP can be >> used. >>=20 >> Except as indicated above for the two-step PTP clocks, Non-Event PTP >> message types do not need to be processed by intermediate routers. >> These message types MAY be carried in PTP Tunnel LSPs. >>=20 >> SB> Are you saying that a timing P router has to be msg type sensitive? >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 15] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 8. Protection and Redundancy >>=20 >>=20 >> SB> This is a bit of a jump - I don't know how the LSP itself works yet! >>=20 >> In order to ensure continuous uninterrupted operation of slave >> clocks, usually as a general practice, slave clocks (or ports) track >> redundant master clocks. >>=20 >> It is the responsibility of the network operator to ensure that >> physically disjoint Timing LSPs are established between a slave clock >> (or port) and redundant master clocks (or ports). >>=20 >> When a slave clock (or port) listens to redundant master clocks or >> ports, any prolonged Timing LSP outage will trigger the slave clock >> or port to switch to a redundant master clock or port. >>=20 >> LSP/PW protection such as Linear protection Switching (1:1, 1+1), >> Ring protection switching or MPLS Fast Reroute (FRR) generally switch >> alternative path that usually cause a change in delay, which if >> undetected by slave clock can reduce accuracy of the slave clock. >>=20 >> Therefore protection switching MAY be used, as long as phase jumps >> upon switchover due to differences in path latency are detected and >> compensated for (such compensation not being required if BCs or peer- >> peer TCs are used throughout). >>=20 >> Note that any protection or reroute mechanism that adds additional >> MPLS label to the label stack, such as Facility Backup Fast Reroute, >> MUST ensure that the pushed label is also a Timing Label to ensure >> recognition of the MPLS frame as containing Timing messages, as it >> transits the backup path. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 16] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 9. ECMP >>=20 >> To ensure the optimal operation of slave clocks and avoid error >> introduced by forward and reverse path delay asymmetry, the physical >> path for Timing messages from master clock to slave Clock and vice >> versa must be the same for all Event Timing messages listed in >> section 7. >>=20 >> Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost >> Multipath). >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 17] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 10. PHP >>=20 >> To ensure that the label on the top of the label stack is the Timing >> LSP Label, PHP MUST not be used. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 18] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 11. Entropy >>=20 >> To ensure all Timing messages in a Timing LSP take the same path, >> Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and >> Entropy Label MUST NOT be used for the PWs that are carried inside >> Timing LSP [RFC6391]. >>=20 >> SB> This is incorrect - you mean that all msgs of the same timing >> SB> flow need to have the same EL value. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 19] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 12. OAM, Control and Management >>=20 >> In order to monitor Timing LSPs and their encapsulated PWs, they MUST >> be able to carry OAM and management messages. These management >> messages MUST be differentiated from Timing messages via already >> defined IETF methods. >>=20 >> For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY run >> over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These >> Management protocols can easily be identified by the UDP Destination >> Port number or by GAL/G-ACH respectively. >>=20 >> Also BFD, LSP-Ping and other management messages MAY run over the PWs >> encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3 or >> 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is going >> to be deprecated by IETF). In this case G-ACH, PW label (TTL=3D1) or >> GAL-ACH are used to identify such management messages. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 20] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 13. QoS Considerations >>=20 >> In network deployments where not every LSR/LER is Timing-aware, it is >> important to reduce the impact of the non-Timing-aware LSR/LERs on >> the timing recovery in the slave clock. The Timing messages are time >> critical and must be treated with the highest priority. Therefore >> Timing over MPLS messages must be treated with the highest priority >> in the routers. This can be achieved by proper setup of Timing LSPs. >>=20 >> It is recommended that the Timing LSPs are setup or configured >> properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC2697] >> for drop eligibility. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 21] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 14. FCS and Checksum Recalculation >>=20 >> When time-stamp generation and timing packet adjustment is performed >> near the physical port hardware, the process MUST include >> recalculation of the Ethernet FCS. >>=20 >> SB> The above is confusing - an LSR always recomputes the link layer >> SB> CRC which may or may not be Ethernet. >>=20 >> Also FCS retention for the >> payload Ethernet described in [RFC4720] MUST NOT be used. >>=20 >> For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum >> may be required as per UDP transport standards. >>=20 >> SB> You really need to be working on getting the IPv6 C?S computation >> SB> removed from PTP msgs. >>=20 >> When UDP checksum is used, each Timing-aware LER/LSR must either >> incrementally update the UDP checksum after Time stamping or >> Correction Field update or verify the UDP checksum on reception from >> upstream and recalculate the checksum completely on transmission to >> downstream node after Time stamping or Correction Field update. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 22] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 15. Behavior of LER/LSR >>=20 >> Timing-capable/aware LERs and LSRs are routers that have one or more >>=20 >> SB> You mean physical interfaces? >>=20 >> interfaces that can perform Timing operations (OC/BC/TC) on Timing >> packets and are configured to do so. Timing-capable/aware LERs and >> LSRs can advertise their Timing-capability per-interface via control >> plane such as OSPF or IS-IS. >> SB> ISIS and OSPF are routing protocols. >>=20 >> The Timing-capable/aware LERs can then >> signals Timing LSPs via RSVP-TE signaling. Alternatively the Timing >> capability of LER and LSRs may be configured in a centralized >> controller and the Timing LSP may be setup using manual configuration >> or other methods such as SDN. >>=20 >> SB> it can also be configured individually rather then through >> SB> a cebtral controllwe >>=20 >> 15.1. Behavior of Timing-capable/aware LER >>=20 >> When a Timing-capable/aware LER behaves as a Transparent clock and >> receives a Timing message from a Timing-capable/aware non-MPLS >> interface, the LER updates the Correction Field (CF) and encapsulates >> and forwards the timing message over previously established Timing >> LSP. >>=20 >> SB> You need to call out the details so that people properly >> SB> understand the definition of the new LSP. >>=20 >> Also when a Timing message is received from a Timing-capable/ >> aware MPLS interface, LER updates the Correction Filed (CF) and >> decapsulates the MPLS encapsulation and forwards the timing message >> to a non-MPLS interface. >>=20 >> When a Timing-capable/aware LER behaves as a Boundary clock and >> receives a Timing message from a Timing-capable/aware non MPLS >> interface, the LER Timestamps the Timing packet and sends it to the >> LERs Boundary clock processing module. Also when a Timing message is >> received from a Timing- capable/aware MPLS interface, the LER >> Timestamps the Timing packet and sends it to the LERs Boundary clock >> processing module. >>=20 >> When a Timing-capable/aware LER behaves as an Ordinary Clock toward >> the MPLS network, and receives a Timing message from a Timing- >> capable/aware MPLS interface, the LER Timestamps the Timing packet >> and sends it to the LERs Ordinary clock processing module. >>=20 >> 15.2. Behavior of Timing-capable/aware LSR >>=20 >> When a Timing-capable/aware LSR behaves as a Transparent clock and >> receives a Timing message from a Timing-capable/aware MPLS interface, >> The LSR updates the Correction Filed (CF) and forwards the timing >> message over another MPLS interface. >>=20 >> When a Timing-capable/aware LSR behaves as a Boundary clock and >> receives a Timing message from a Timing-capable/aware MPLS interface. >> The LSR performs the functions of a Boundary Clock in terminating the >> received Timing message and re-generating a new timing message over >> another (or the same) MPLS interface. >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 23] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 15.3. Behavior of non-Timing-capable/aware LSR >>=20 >> It is most beneficial when all LSRs in the path of a Timing LSP be >> timing-Capable/aware LSRs. This would ensure the highest quality >> time and clock synchronization by Timing Slave Clocks. However, this >> specification does not mandate that all LSRs in path of a Timing LSP >> be Timing- capable/aware. >>=20 >> Non-Timing-capable/aware LSRs just switch the packets encapsulated in >> Timing LSPs and dont perform any Timing operation (TC or BC). >> However as explained in QoS section the Timing over MPLS packets MUST >> be still be treated with the highest priority based on their Traffic >> Class (TC) marking. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 24] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 16. Other considerations >>=20 >> [IEEE-1588] defines an optional peer-to-peer Transparent clocking >> that requires peer delay measurement between two adjacent Timing- >> capable/ aware routers/switches. Peer delay measurement messages >> need to be time stamped and terminated by the Timing-capable/aware >> routers/ switches. This means that two adjacent LSRs may be engaged >> in a peer delay measurement. >>=20 >> For transporting such peer delay measurement messages a single-hop >> LSP SHOULD to be created between the two adjacent LSRs engaged in >> peer delay measurement to carry peer delay measurement messages. >> Other methods such as PTP transport over Ethernet MAY be used for >> transporting peer delay measurement messages if the link between the >> two routers is Ethernet. >>=20 >> In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ ware >> routers/switches MUST maintain a list of all the neighbors it needs >> to send a PDelay_Req to, where each neighbor corresponds to a timing >> LSP. >>=20 >> The use of Explicit Null Label (Label=3D 0 or 2) is acceptable as long= >> as either the Explicit Null label is the bottom of stack label >> (applicable only to UDP/IP encapsulation) or the label below the >> Explicit Null label is a PTP label. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 25] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 17. Security Considerations >>=20 >> MPLS PW security considerations in general are discussed in [RFC3985] >> and [RFC4447],and those considerations also apply to this document. >>=20 >> An experimental security protocol is defined in [IEEE-1588].The PTP >> security extension and protocol provides group source authentication, >> message integrity, and replay attack protection for PTP messages. >>=20 >> When the MPLS network (provider network) serves multiple customers, >> it is important to maintain and process each customers clock and >> Timing messages separately from other customers to ensure there is no >> cross- customer effect. For example if an LER BC is synchronized to >> a specific grandmaster, belonging to customer A, then the LER MUST >> use that BC clock only for customer A to ensure that customer A >> cannot attack other customers by manipulating its time. >>=20 >> Timing messages MAY be encrypted or authenticated, provided that the >> LERs/LSRs that are Timing capable/aware can authenticate/ decrypt the >> timing messages. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 26] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 18. Acknowledgements >>=20 >> The authors would like to thank Ron Cohen, Yaakov Stein, Tal Mizrahi, >> Stefano Ruffini, Peter Meyer, and other members of IETF for reviewing >> and providing feedback on this draft. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 27] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 19. IANA Considerations >>=20 >> There are no IANA requirements in this specification. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 28] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 20. References >>=20 >> 20.1. Normative References >>=20 >> [IEEE-1588] >> IEEE 1588-2008, "IEEE Standard for a Precision Clock >> Synchronization Protocol for Networked Measurement and >> Control Systems". >>=20 >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, March 1997. >>=20 >> [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- >> Edge (PWE3) Architecture", RFC 3985, March 2005. >>=20 >> [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery >> Proxies (ND Proxy)", RFC 4389, April 2006. >>=20 >> [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. >> Heron, "Pseudowire Setup and Maintenance Using the Label >> Distribution Protocol (LDP)", RFC 4447, April 2006. >>=20 >> [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, >> "Encapsulation Methods for Transport of Ethernet over MPLS >> Networks", RFC 4448, April 2006. >>=20 >> [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire >> Emulation Edge-to-Edge (PWE3) Frame Check Sequence >> Retention", RFC 4720, November 2006. >>=20 >> [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit >> Connectivity Verification (VCCV): A Control Channel for >> Pseudowires", RFC 5085, December 2007. >>=20 >> [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection >> (BFD)", RFC 5880, June 2010. >>=20 >> [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, >> "Bidirectional Forwarding Detection (BFD) for MPLS Label >> Switched Paths (LSPs)", RFC 5884, June 2010. >>=20 >> 20.2. Informative References >>=20 >> [I-D.ietf-pwe3-fat-pw] >> Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, >> J., and S. Amante, "Flow Aware Transport of Pseudowires >> over an MPLS Packet Switched Network", >> draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011. >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 29] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate >> system routeing information exchange protocol for use in >> conjunction with the Protocol for providing the >> Connectionless-mode Network Service (ISO 8473)". >>=20 >> [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and >> dual environments", RFC 1195, December 1990. >>=20 >> [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. >>=20 >> [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color >> Marker", RFC 2697, September 1999. >>=20 >> [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, >> J., Courtney, W., Davari, S., Firoiu, V., and D. >> Stiliadis, "An Expedited Forwarding PHB (Per-Hop >> Behavior)", RFC 3246, March 2002. >>=20 >> [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering >> (TE) Extensions to OSPF Version 2", RFC 3630, >> September 2003. >>=20 >> [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate >> System (IS-IS) Extensions for Traffic Engineering (TE)", >> RFC 3784, June 2004. >>=20 >> [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. >> Shaffer, "Extensions to OSPF for Advertising Optional >> Router Capabilities", RFC 4970, July 2007. >>=20 >> [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate >> System to Intermediate System (IS-IS) Extensions for >> Advertising Router Information", RFC 4971, July 2007. >>=20 >> [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi >> Topology (MT) Routing in Intermediate System to >> Intermediate Systems (IS-ISs)", RFC 5120, February 2008. >>=20 >> [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic >> Engineering", RFC 5305, October 2008. >>=20 >> [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, >> "Traffic Engineering Extensions to OSPF Version 3", >> RFC 5329, September 2008. >>=20 >> [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF >> for IPv6", RFC 5340, July 2008. >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 30] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network >> Time Protocol Version 4: Protocol and Algorithms >> Specification", RFC 5905, June 2010. >>=20 >> [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, >> J., and S. Amante, "Flow-Aware Transport of Pseudowires >> over an MPLS Packet Switched Network", RFC 6391, >> November 2011. >>=20 >> [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and >> L. Yong, "The Use of Entropy Labels in MPLS Forwarding", >> RFC 6790, November 2012. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 31] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 1. Routing extensions for Timing-aware Routers >>=20 >> MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and >> IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE) >> link information used for constraint-based routing. >>=20 >> Indeed, it is useful to advertise data plane TE router link >> capabilities, such as the capability for a router to be Timing-aware. >> This capability MUST then be taken into account during path >> computation to prefer or even require links that advertise themselves >> as Timing-aware. In this way the path can ensure the entry and exit >> points into the LERs and, if desired, the links into the LSRs are >> able to perform port based time-stamping thus minimizing their impact >> on the performance of the slave clock. >>=20 >> extensions are required to OSPF and IS-IS in order to advertise >> Timing-aware capabilities of a link. Such extensions are outside the >> scope of this document; however such extension SHOULD be able to >> signal the following information per Router Link: >>=20 >> o Capable of processing PTP, NTP or other Timing flows >>=20 >> o Capable of performing Transparent Clock operation >>=20 >> o Capable of performing Boundary Clock operation >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 32] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 2. Signaling Extensions for Creating Timing LSPs >>=20 >> RSVP-TE signaling MAY be used to setup the timing LSPs. When RSVP-TE >> is used to setup Timing LSPs, some information that indicates that >> the LSP is carrying Timing flows MUST be included in the new >> Extensions to RSVP-TE: >>=20 >> The following information MAY also be included in the new Extensions >> to RSVP-TE: >>=20 >> o Offset from Bottom of Stack (BoS) to the start of the Time-stamp >> field >>=20 >> o Number of VLANs in case of PW encapsulation >>=20 >> o Timestamp field Type >>=20 >> * Correction Field, Timestamp >>=20 >> o Timestamp Field format >>=20 >> * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit >> NTP, etc. >>=20 >> Note that in case the above optional information is signaled with >> RSVP-TE for a Timing LSP, all the Timing packets carried in that LSP >> must have the same signaled characteristics. For example if >> Timestamp format is signaled as 64-bit PTPv1, then all Timing packets >> must use 64-bit PTPv1 time-stamp. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 33] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> Authors' Addresses >>=20 >> Shahram Davari >> Broadcom Corp. >> San Jose, CA 95134 >> USA >>=20 >> Email: davari@broadcom.com >>=20 >>=20 >> Amit Oren >> Broadcom Corp. >> San Jose, CA 95134 >> USA >>=20 >> Email: amito@broadcom.com >>=20 >>=20 >> Manav Bhatia >> Alcatel-Lucent >> Bangalore, >> India >>=20 >> Email: manav.bhatia@alcatel-lucent.com >>=20 >>=20 >> Peter Roberts >> Alcatel-Lucent >> Kanata, >> Canada >>=20 >> Email: peter.roberts@alcatel-lucent.com >>=20 >>=20 >> Laurent Montini >> Cisco Systems >> San Jose CA >> USA >>=20 >> Email: lmontini@cisco.com >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 34] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> Luca >> Cisco Systems >> San Jose CA >> USA >>=20 >> Email: lmartini@cisco.com >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 35] >=20 >>=20 >> -- >> For corporate legal information go to: >>=20 >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>=20 >> _______________________________________________ >> TICTOC mailing list >> TICTOC@ietf.org >> https://www.ietf.org/mailman/listinfo/tictoc >=20 >=20 > This e-mail message is intended for the recipient only and contains inform= ation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If y= ou have received this transmission in error, please inform us by e-mail, pho= ne 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 Alexander.Vainshtein@ecitele.com Sun Aug 4 02:47:38 2013 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 5714D21F8488 for ; Sun, 4 Aug 2013 02:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.702 X-Spam-Level: X-Spam-Status: No, score=-3.702 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 3GkhKkXjcrDw for ; Sun, 4 Aug 2013 02:47:33 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.165]) by ietfa.amsl.com (Postfix) with ESMTP id C412521F9A64 for ; Sun, 4 Aug 2013 02:47:32 -0700 (PDT) Received: from [85.158.138.51:34528] by server-5.bemta-3.messagelabs.com id AC/97-15398-2332EF15; Sun, 04 Aug 2013 09:47:30 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1375609648!30031696!1 X-Originating-IP: [147.234.242.234] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21191 invoked from network); 4 Aug 2013 09:47:29 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Aug 2013 09:47:29 -0000 X-AuditID: 93eaf2e7-b7f4d6d000005d50-d5-51fe232f39bd Received: from ILPTWPVEXCA02.ecitele.com ( [172.31.244.232]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 86.89.23888.F232EF15; Sun, 4 Aug 2013 12:47:28 +0300 (IDT) Received: from ILPTWPVEXMB02.ecitele.com ([fe80::5979:ca8d:419f:56df]) by ILPTWPVEXCA02.ecitele.com ([fe80::c473:490d:3a7e:e34a%12]) with mapi id 14.03.0123.003; Sun, 4 Aug 2013 12:47:27 +0300 From: Alexander Vainshtein To: "S. Davari" Thread-Topic: [mpls] [TICTOC] Comments on draft-ietf-tictoc-1588overmpls Thread-Index: AQHOj2AMghL6qRFw2EmhP8ypbGfBrJmEtKhw///niYCAADPcwA== Date: Sun, 4 Aug 2013 09:47:26 +0000 Message-ID: References: <51FB7543.801@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.35.10] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42KZ/OrTF10D5X+BBvfOy1kcfN7EaHFr6UpW ByaPJUt+MnnMmnWYKYApqoHRJjEvL78ksSRVISW1ONlWKaAosywxuVJJITPFVslQSaEgJzE5 NTc1r8RWKbGgIDUvRcmOSwED2ACVZeYppOYl56dk5qXbKnkG++taWJha6hoq2akpGxpbc4Vk ZBYrpOrmJmbmKOSmFhcnpqcqAEUStjBn9D9bzV5wag1LxaFZV5kbGFsbmbsYOTkkBEwkHk5b AGWLSVy4t56ti5GLQ0jgIKPE3r6zjBDOEUaJN4dfgFWxCdhKbFp9lw3EFhFQkVi6fSkLiM0s UCpx/s5mRhBbWMBdov/FFqgaD4neXfcYIWwniTe3P7OC2CxAvbu//QWzeQUCJH62LWWFWDaP UaKh/zRYAyfQsk9978AWMAKd9/3UGiaIZeISt57MZ4I4W0BiyZ7zUC+ISrx8/I8VwpaTePLk FNRxOhILdn9ig7C1JZYtfM0MsVhQ4uTMJywQ9ZISB1fcYJnAKD4LyYpZSNpnIWmfhaR9ASPL KkbRzJyCkqTcdANDvdTkzJLUnFS95PzcTYyQdPJ8B+Ov+SqHGF2BHp/ILMWdnA9MR3kl8cYG Brg5SuK8yxvC/YUE0oFpJzs1tSC1KL6oNCe1+BAjEwenVANjDNO7HXqvD19jT7i4zr8vPYpv aq3SeyWPoiOKWz7s9/iltde3+vOKhE7XXU3FX/RZuW7HJK6+NEluppJ4/QTjxETXBcylOacy DnmuOXj6S4ytR12iZ/GkjdEb5+7+fN9sR9rmiEMrVFWkfq08tPFa4p+YZxudnNc0Fekc+d1+ 3Kfr39RTgVNuKrEUZyQaajEXFScCABVT+qIfAwAA Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] Comments on draft-ietf-tictoc-1588overmpls 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, 04 Aug 2013 09:47:38 -0000 Shahram hi, I think that I have understood the objectives of the draft. I have been just trying to say that, IMHO and FWIW, these objectives CANNOT= BE MET within the scope of the MPLS data plane architecture. Regards, Sasha > -----Original Message----- > From: S. Davari [mailto:davarish@yahoo.com] > Sent: Sunday, August 04, 2013 12:40 PM > To: Alexander Vainshtein > Cc: stbryant@cisco.com; mpls@ietf.org; tictoc@ietf.org > Subject: Re: [mpls] [TICTOC] Comments on draft-ietf-tictoc-1588overmpls > > Hi Sasha > > Perhaps you have not understood the draft well. The main reason that the d= raft > chose to use a dedicated LSP that is signaled via RSVPTE indicating it is= a > timing LSP is to be backward compatible with non-1588 nodes. Such nodes > simply just switch the packet. > > Your proposal had been considered and was rejected since it was not backwa= rd > compatible. Nodes receiving alert label or TTL =3D 1 send the packet to CP= U. You > can refer to the meeting notes. > > Regards, > Shahram > > > On Aug 4, 2013, at 1:21 AM, Alexander Vainshtein > wrote: > > > Stewart and all, > > I concur with Stewart's statement that the draft does not define "full > interaction with MPLS architecture". > > > > E.g., one of the objectives of the draft is to provide a technique that= would be > backward-compatible with old LSRs that cannot provide on-path support for > timing distribution, while the other objective is to make every LSR on the= path > aware that some MPLS packets are carrying timing-related messages and henc= e > require on-path support. > > > > IMHO and FWIW, the MPLS data plane architecture allows just two methods > for making a transit LSR to provide special processing to a labeled packet= : > > - It would carry some kind of an "alert label" on top of the label stack= and, > specifically, on top of any labels used for actual forwarding > > OR, > > - The TTL in the top label stack entry has been set to 1. > > > > > > The draft does not follow any of these approaches. > > > > I must also admit that Section 12 "OAM, Control and Management" of the > draft looks somewhat in > > E.g., I could not understand from the text whether BFD, LSP-Ping etc. OA= M > messages would be subjected to on-path support procedures for timing > messages or not. > > > > My 2c, > > Sasha > > > >> -----Original Message----- > >> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behal= f > Of > >> Stewart Bryant > >> Sent: Friday, August 02, 2013 12:01 PM > >> To: mpls-chairs@tools.ietf.org; tictoc-chairs@tools.ietf.org; int- > >> ads@tools.ietf.org; rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.org;= draft- > >> ietf-tictoc-1588overmpls@tools.ietf.org > >> Cc: mpls@ietf.org; tictoc@ietf.org > >> Subject: [TICTOC] Comments on draft-ietf-tictoc-1588overmpls > >> > >> SB> This draft does not seem to provide a precise definition > >> SB> the properties of the new LSP type that it wishes to > >> SB> define, in particular it does it define the PHB of those > >> SB> LSPs, nor the full interaction with the MPLS > >> SB> architecture. > >> SB> > >> SB> I have not tracked TICTOC for a while but I thought that > >> SB> the original plan was to define the concept of an offset > >> SB> into a packet to do the correction. > >> SB> > >> SB> It is disappointing that the opportunity was not taken > >> SB> to define a timing shim inside the timing LSP so that > >> SB> a time correction could be added to any packet such that > >> SB> the MPLS system was isolated from the details of the > >> SB> complexity of the particular time transfer type. > >> > >> SB> I think that much more clarify is needed in terms of > >> SB> definition of the new LSP type, since it is unclear > >> SB> from this text how to implement one. > >> SB> > >> SB> There are a lot of other MPLS services such as > >> SB> LSP ping that need to be considered. > >> SB> > >> SB> Please see inline for more comments. However these > >> SB> comments are made in the context of the text as written > >> SB> whilst I have a fundamental concern that this approach > >> SB> lacks an MPLS architectural soundness that need > >> SB> greater thought with significant impact on the > >> SB> draft. > >> > >> - Stewart > >> > >> > >> TICTOC Working Group S. Davar= i > >> Internet-Draft A. Ore= n > >> Intended status: Standards Track Broadcom Corp= . > >> Expires: December 17, 2013 M. Bhati= a > >> P. Robert= s > >> Alcatel-Lucen= t > >> L. Montin= i > >> L. Martin= i > >> Cisco System= s > >> June 15, 201= 3 > >> > >> > >> Transporting Timing messages over MPLS Networks > >> draft-ietf-tictoc-1588overmpls-05 > >> > >> Abstract > >> > >> This document defines the method for transporting Timing messages > >> such as PTP and NTP over an MPLS network. The method allows for the > >> easy identification of these PDUs at the port level to allow for por= t > >> > >> SB> What is a port > >> > >> level processing of these PDUs in both LERs and LSRs. > >> > >> The basic idea is to transport Timing messages inside dedicated MPLS > >> LSPs. These LSPs only carry Timing messages and possibly Control an= d > >> Management packets, but they do not carry customer traffic. > >> > >> SB> More specifically they only carry traffic associated with the > >> SB> timing service and its support. > >> SB> The question arose WRT BFD - surely BFD is allowed, BUT surely > >> SB> also it gets carried in a structure that causes it to get > >> SB> timestamped. > >> > >> Two methods for transporting Timing messages over MPLS are defined. > >> > >> SB> Perhaps the right approach is to define the new LSP type and then > >> SB> seperately to define the mapping of the various timing services > >> SB> over that LSP type. > >> > >> The first method is to transport Timing messages directly over the > >> dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for > >> MPLS networks. The second method is to transport Timing messages > >> inside a PW via Ethernet encapsulation. > >> > >> SB> I think that we should note that there are some > >> SB> h/w reasons for this preference. A clean sheet approach > >> SB> would have been to use PTP over MPLS with no intermediate > >> SB> layers. > >> > >> Status of this Memo > >> > >> This Internet-Draft is submitted in full conformance with the > >> provisions of BCP 78 and BCP 79. > >> > >> Internet-Drafts are working documents of the Internet Engineering > >> Task Force (IETF). Note that other groups may also distribute > >> working documents as Internet-Drafts. The list of current Internet- > >> Drafts is at http://datatracker.ietf.org/drafts/current/. > >> > >> Internet-Drafts are draft documents valid for a maximum of six month= s > >> and may be updated, replaced, or obsoleted by other documents at any > >> time. It is inappropriate to use Internet-Drafts as reference > >> material or to cite them other than as "work in progress." > >> > >> This Internet-Draft will expire on December 17, 2013. > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 1= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> Copyright Notice > >> > >> Copyright (c) 2013 IETF Trust and the persons identified as the > >> document authors. All rights reserved. > >> > >> This document is subject to BCP 78 and the IETF Trust's Legal > >> Provisions Relating to IETF Documents > >> (http://trustee.ietf.org/license-info) in effect on the date of > >> publication of this document. Please review these documents > >> carefully, as they describe your rights and restrictions with respec= t > >> to this document. Code Components extracted from this document must > >> include Simplified BSD License text as described in Section 4.e of > >> the Trust Legal Provisions and are provided without warranty as > >> described in the Simplified BSD License. > >> > >> > >> Table of Contents > >> > >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 5 > >> > >> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . = 7 > >> > >> 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . = 8 > >> > >> 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . = 9 > >> > >> 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . . 1= 2 > >> > >> 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . 1= 3 > >> 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . . 1= 3 > >> 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . . 1= 3 > >> 6.3. Other Timing Encapsulation methods . . . . . . . . . . . . 1= 4 > >> > >> 7. Timing message Processing . . . . . . . . . . . . . . . . . . 1= 5 > >> > >> 8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 1= 6 > >> > >> 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1= 7 > >> > >> 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1= 8 > >> > >> 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . 1= 9 > >> > >> 12. OAM, Control and Management . . . . . . . . . . . . . . . . . 2= 0 > >> > >> 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 2= 1 > >> > >> 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . . 2= 2 > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 2= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 2= 3 > >> 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . . 2= 3 > >> 15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . . 2= 3 > >> 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . . 2= 4 > >> > >> 16. Other considerations . . . . . . . . . . . . . . . . . . . . . 2= 5 > >> > >> 17. Security Considerations . . . . . . . . . . . . . . . . . . . 2= 6 > >> > >> 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 2= 7 > >> > >> 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 2= 8 > >> > >> 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 2= 9 > >> 20.1. Normative References . . . . . . . . . . . . . . . . . . . 2= 9 > >> 20.2. Informative References . . . . . . . . . . . . . . . . . . 2= 9 > >> > >> Appendix 1. Routing extensions for Timing-aware Routers . . . . . 3= 2 > >> > >> Appendix 2. Signaling Extensions for Creating Timing LSPs . . . . 3= 3 > >> > >> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 3= 4 > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 3= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > >> this > >> document are to be interpreted as described in RFC2119 [RFC2119]. > >> > >> When used in lower case, these words convey their typical use in > >> common language, and are not to be interpreted as described in > >> RFC2119 [RFC2119]. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 4= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 1. Introduction > >> > >> The objective of Precision Time Protocol (PTP) and Network Timing > >> Protocol (NTP) are to synchronize independent clocks running on > >> separate nodes of a distributed system. > >> > >> [IEEE-1588] defines PTP messages for frequency, phase and time > >> synchronization. The PTP messages include PTP PDUs over UDP/IP > >> (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex F o= f > >> [IEEE-1588]). > >> > >> SB> Sure BUT it is acknowledged that IEEE is open to the definition > >> SB> of other PTP mappings if they provide better optimisation. > >> > >> This document defines mapping and transport of the PTP > >> messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP > >> defines several clock types: ordinary clocks, boundary clocks, end- > >> to-end transparent clocks, and peer-to-peer transparent clocks. > >> Transparent clocks require intermediate nodes to update correction > >> field inside PTP message that reflects the transit time in the node. > >> > >> [RFC5905] defines NTP messages for clock and time synchronization. > >> The PTP messages (PDUs) are transported over UDP/IP. This document > >> SB> Should that be NTP messages? > >> SB> It needs to be made clear as soon as you introduce NTP that > >> SB> they use different time representations. > >> > >> defines mapping and transport of the NTP messages defined in > >> [RFC5905] over MPLS networks. > >> > >> One key attribute of all of these Timing messages is that the Time > >> stamp processing should occur as close as possible to the actual > >> transmission and reception at the physical port interface. This > >> targets optimal time and/or frequency recovery by avoiding variable > >> delay introduced by queues internal to the clocks. > >> > >> SB> As I recall NTP has no epoch point defined, and I am not sure > >> SB> where that point is in the case of PTP in this mapping > >> SB> Hopefully this will get defined in due course. > >> > >> To facilitate the fast and efficient recognition of Timing messages > >> at the port level when the Timing messages are carried over MPLS > >> LSPs, > >> > >> SB> Over a new LSP type with time optimied characteristics > >> > >> this document defines the specific encapsulations that should > >> be used. > >> SB> Hopefully it will also define the PHP > >> > >> In addition, it can be expected that there will exist LSR/ > >> LERs where only a subset of the physical ports will have the port- > >> based Timing message processing capabilities. > >> SB> Do you need to clarify that this only works at base and not in > >> SB> a label heirarchy. > >> > >> > >> In order to ensure > >> that the LSPs carrying Timing packets always enter and exit ports > >> with this capability, routing extensions are defined to advertise > >> this capability on a port basis and to allow for the establishment o= f > >> LSPs that only transit such ports. While this path establishment > >> restriction may be applied only at the LER Ingress and/or egress > >> ports, it becomes more important when using transparent clock capabl= e > >> LSRs in the path. > >> SB> I do not understand the implications of the last > >> SB> sentences - starting ", it becomes" > >> > >> > >> Port based Timing message processing involves Timing message > >> recognition. Once the Timing messages are recognized they can be > >> modified based on the reception or transmission Time-stamp. > >> > >> This document provides two methods for transporting Timing messages > >> over MPLS. One is applicable to MPLS environment and the other one > >> is applicable to MPLS/MPLS-TP environment > >> > >> SB> I think the sentence is incomplete. > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 5= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> The solution involves transporting Timing messages over dedicated > >> LSPs called Timing LSPs. These LSPs carry Timing messages and MAY > >> carry Management and control messages, but not data plane client > >> traffic. > >> > >> SB> It is not clear why this restriction applies. > >> > >> Timing LSPs can be established statically or via signaling. > >> SB> s/statically/by provisioning/network management/ > >> > >> Extensions to control plane (OSPF, ISIS, etc.) is required to enable > >> routers to distribute their Timing processing capabilities over MPLS > >> to other routers. However such extensions are outside the scope of > >> this document. > >> > >> When signaling is used to setup the PTP LSP, Extensions to signaling > >> SB> is it a PTP LSP or a Timing LSP? > >> > >> protocols (e.g., RSVP-TE) are required for establishing PTP LSPs. > >> However such extensions are outside the scope of this document. > >> > >> SB> for mpls-tp GMPLS is the signalling protocol > >> > >> While the techniques included herein allow for the establishment of > >> paths optimized to include Time-stamping capable links, the > >> performance of the Slave clocks is outside the scope of this > >> document. > >> > >> At the time of publishing this specification, Transparent Clocking > >> (TC) is only defined for PTP. Therefore at this time any part of > >> this specification that talks about Transparent Clocking applies onl= y > >> to PTP. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 6= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 2. Terminology > >> > >> 1588: The timing and synchronization as defined by IEEE 1588. > >> > >> SB> I think that there is a more formal name for the 1588 group > >> SB> that needs to be used here. > >> SB> Also do we need to talk about 1588-200? as there is > >> SB> an update in progress > >> > >> NTP: The timing and synchronization protocol defined by IETF RFC-130= 5 > >> and RFC-5905. > >> > >> PTP: The timing and synchronization protocol used by 1588. > >> SB> need the proper name for 1588 > >> > >> Master Clock: The source of 1588 timing to a set of slave clocks. > >> > >> Master Port: A port on a ordinary or boundary clock that is in Maste= r > >> state. This is the source of timing toward slave ports. > >> > >> SB> I am not sure the reader knows what a port is > >> > >> Slave Clock: A receiver of 1588 timing from a master clock. > >> > >> Slave Port: A port on a boundary clock or ordinary clock that is > >> receiving timing from a master clock. > >> > >> Ordinary Clock: A device with a single PTP port. > >> > >> Transparent Clock. A device that measures the time taken for a PTP > >> event message to transit the device and then updates the > >> correctionField of the message with this transit time. > >> > >> Boundary Clock: A device with more than one PTP port. Generally > >> boundary clocks will have one port in slave state to receive timing > >> and then other ports in master state to re-distribute the timing. > >> > >> PTP LSP: An LSP dedicated to carry PTP messages > >> > >> SB> PTP or timing? > >> > >> > >> PTP PW: A PW within a PTP LSP that is dedicated to carry PTP > >> messages. > >> > >> SB> Ah I don't think that PWE3 know what one of these is > >> > >> CW: Pseudowire Control Word > >> > >> LAG: Link Aggregation > >> > >> ECMP: Equal Cost Multipath > >> > >> CF: Correction Field, a field inside certain PTP messages (message > >> type 0-3)that holds the accumulative transit time inside intermediat= e > >> switches > >> > >> Timing messages: Timing Protocol messages that are exchanged between > >> routers in order to establish a synchronized clock. > >> > >> SB> A number of these definitions look like copies of IEEE1588 > >> SB> definitions. We need to provide references and note the > >> SB> priority of the IEEE base reference. > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 7= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 3. Problem Statement > >> > >> [IEEE-1588] has defined methods for transporting PTP messages over > >> Ethernet and IP networks. [RFC5905] has defined the method of > >> transporting NTP messages over IP networks. There is a need to > >> transport Timing messages over MPLS networks while supporting the > >> Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC) > >> functionality in the LER and LSRs in the MPLS network. > >> > >> There are multiple ways of transporting Timing over MPLS. However, > >> there is a requirement to limit the possible encapsulation options t= o > >> simplify the Timing message identification and processing required a= t > >> the port level. > >> > >> When Timing-awareness is needed, Timing messages should not be > >> transported over LSPs or PWs that are carrying customer traffic > >> because LSRs perform Label switching based on the top label in the > >> stack. > >> > >> SB> Have you explained why? > >> > >> To detect Timing messages inside such LSPs require special > >> hardware to do deep packet inspection at line rate. Even if such > >> hardware exists, the payload can't be deterministically identified b= y > >> LSRs because the payload type is a context of the PW label, and the > >> PW label and its context are only known to the Edge routers (PEs/ > >> LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, CES, > >> etc). Even if one restricts an LSP to only carry Ethernet PWs, the > >> LSRs dont have the knowledge of whether PW Control Word (CW) is > >> present or not and therefore can not deterministically identify the > >> payload. > >> > >> A generic method is defined in this document that does not require > >> deep packet inspection at line rate, and can deterministically > >> identify Timing messages. This method can be used to detect Timing > >> Messages in both one-step and two-step clock implementations of > >> ordinary, boundary and transparent clocks. > >> > >> SB> Needs a ref and I am sure many MPLS specialists will not understand > >> SB> the msg types. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 8= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 4. Timing over MPLS Architecture > >> > >> Timing messages are exchange between Timing ports on ordinary and > >> > >> SB> Have you defined a timing port? > >> > >> boundary clocks. Boundary clocks terminate the Timing messages and > >> act as master for other boundary clocks or for slave clocks. End-to= - > >> End Transparent clocks do not terminate the Timing messages but they > >> do modify the contents of the Timing messages as they transit across > >> the transparent clock. > >> > >> Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent Cloc= k > >> > >> (TC) could be implemented in either LERs or LSRs. > >> > >> SB> LER and LSR need to be expanded > >> > >> An example is shown in Figure 1, where the LERs act as Ordinary Cloc= k > >> (OC) and are the initiating/terminating point for Timing messages. > >> The ingress LER encapsulates the Timing messages in Timing LSP and > >> the Egress LER terminates the Timing LSP. The LSRs act as > >> Transparent Clock (TC) and just update the Timing field in the Timin= g > >> messages. > >> > >> > >> +--------+ +-------+ +-------+ +-------+ +-------= -+ > >> |Switch, | | | | | | | |Switch,= | > >> | Router |-----| LER |-----| LSR |-----| LER |-----| Router= | > >> | | | OC | | TC | | OC | | = | > >> +--------+ +-------+ +-------+ +-------+ +-------= -+ > >> / \ > >> +-------+ / \ +-------+ > >> | LER | / \ | LER | > >> | Master|---/ \---| Slave | > >> | Clock | | Clock | > >> +-------+ +-------+ > >> > >> Figure (1) - Deployment example 1 of timing over MPLS network > >> > >> Another example is shown in Figure2, where LERs terminate the Timing > >> messages received from switch/routers that are outside of the MPLS > >> network acting as OC or BC. In this example LERs regenerate the > >> clock and initiate timing messages encapsulated in Timing LSP toward > >> the MPLS network, while the LSRs act as Transparent Clock (TC) and > >> just update the Timing field in the Timing messages, which are > >> already encapsulated in Timing LSPs. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 9= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> +--------+ +-------+ +-------+ +-------+ +--------= + > >> |Switch, | | | | | | | |Switch,= | > >> | Router |-----| LER |-----| LSR |-----| LER |-----| Router= | > >> | OC/BC | | BC | | TC | | BC | | OC/BC = | > >> +--------+ +-------+ +-------+ +-------+ +--------= + > >> > >> Figure (2) - Deployment example 2 of timing over MPLS network > >> > >> > >> Another example is shown in Figure 3, where LERs do not terminate th= e > >> Timing messages received from switch/routers that are outside of the > >> MPLS network acting as OC, TC or BC. The LERs act as TC and update > >> the Timing field in the Timing messages as they transit the LER, > >> while encapsulating them in timing LSP. The LSRs also act as > >> Transparent Clock (TC) and just update the Timing field in the Timin= g > >> messages which are already encapsulated in Timing LSPs. > >> > >> +--------+ +-------+ +-------+ +-------+ +-------= -+ > >> |Switch, | | | | | | | |Switch,= | > >> | Router |-----| LER |-----| LSR |-----| LER |-----| Router= | > >> |OC/TC/BC| | TC | | TC | | TC | |OC/TC/B= C| > >> +--------+ +-------+ +-------+ +-------+ +-------= -+ > >> > >> Figure (3) - Deployment example 3 of timing over MPLS network > >> > >> Another example is shown in Figure 4, where LERs and LSRs support > >> Boundary Clocks. A single-hop LSP is created between two adjacent > >> LSRs engaged in BC operation. Other methods such as PTP transport > >> over Ethernet MAY be used for transporting timing messages if the > >> link between the two routers is Ethernet. > >> > >> +--------+ +-------+ +-------+ +-------+ +--------= + > >> |Switch, | | | | | | | |Switch,= | > >> | Router |-----| LER |-----| LSR |-----| LER |-----| Router= | > >> | OC/BC | | BC | | BC | | BC | | OC/BC = | > >> +--------+ +-------+ +-------+ +-------+ +--------= + > >> > >> Figure (4) - Deployment example 3 of timing over MPLS network > >> > >> An MPLS domain MAY serve multiple customers. In these cases the MPL= S > >> domain (maintained by a service provider) may provide timing service= s > >> to multiple customers, each having their own Timing domain. > >> > >> The Timing over MPLS architecture assumes full mesh of Timing LSPs > >> between all LERs supporting this specification. > >> > >> SB> Note sure this is right - the salves surely do not need to > >> SB> exchange timing amongst themselves > >> > >> It supports > >> Point-to- point (VPWS) and Multipoint (VPLS) services. > >> > >> SB> What does that mean? You do not carry user data traffic? > >> SB> Maybe it's the ordering of the statemnets that is causing > >> SB> confusion. > >> > >> This means > >> that a customer may purchase a Point-to-point Timing service between > >> two customer sites or a Multipoint Timing service between more than > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 10= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> two customer sites. > >> > >> The Timing over MPLS architecture supports P2P or P2MP Timing LSPs. > >> This means that the Timing Multicast messages such as PTP Multicast > >> event messages can be transported over P2MP Timing LSP or be > >> replicated and transported over many P2P Timing LSPs. > >> > >> SB> Note we do not yet have a definition of a P2MP mpls-tp LSP > >> SB> nor a P2MP PW, although we are close. > >> > >> Timing messages, that do not require Time stamping or Correction > >> Field update MAY be transported over Timing LSPs to simplify hardwar= e > >> and software. > >> > >> PTP Announce messages that determine the Timing LSP terminating poin= t > >> behavior such as BC/OC/TC SHOULD be transported over the Timing LSP > >> to simplify hardware and software. > >> > >> SB> have you defined and referenced PTP announce msgs? > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 11= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 5. Dedicated LSPs for Timing messages > >> > >> Many methods have been considered for identifying the Timing message= s > >> when they are encapsulated in MPLS such as using GAL/G-ACH or a new > >> reserved label. These methods were not attractive since they either > >> required deep packet inspection at line rate in the intermediate LSR= s > >> or they required use of a scarce new reserved label. Also one of th= e > >> goals was to reuse existing OAM mechanisms. > >> > >> SB> RLs =3D SPLs are not so rare now. In any case needs a ref. > >> > >> The method defined in this document can be used by LER and LSRs to > >> identify Timing messages in MPLS tunnels by just looking at the top > >> label in the MPLS label stack, which only carry Timing messages as > >> well as OAM, but not data plane client traffic. > >> > >> Compliant implementations MUST use dedicated LSPs to carry Timing > >> messages over MPLS. > >> > >> SB> I think that we need a definition of the properies of these LSPs > >> > >> These LSPs are herein referred to as "Timing > >> LSPs" and the labels associated with these LSPs as "Timing LSP > >> labels". The Timing LSPs that runs between Ingress and Egress LERs > >> MUST be co-routed. Alternatively, a single bidirectional co-routed > >> LSP can be used. > >> > >> SB> I though that you said you could use M2MP LSPs - these are not > >> SB> bidirectional. > >> > >> Co-routing of the two directions is required to limit the difference > >> in the delays in the Master clock to Slave clock direction compared > >> to the Slave clock to Master clock direction. The Timing LSP MAY be > >> MPLS/MPLS-TP LSP. > >> > >> The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS. > >> New Extensions to RSVP-TE/GMPLS TLVs are required; however they are > >> outside the scope of this document. > >> > >> The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such as > >> BFD and LSP Ping but the LSP data plane client plane traffic MUST be > >> Timing packets only. > >> > >> SB> Why? > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 12= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 6. Timing over LSP Encapsulation > >> > >> The encapsulations is not LSP is it? > >> > >> This document defines two methods for carrying Timing messages over > >> MPLS. The first method is carrying UDP/IP encapsulated Timing > >> messages over Timing LSPs, and the second method, is carrying > >> Ethernet encapsulated Timing messages over Ethernet PWs inside Timin= g > >> LSPs. > >> > >> 6.1. Timing over UDP/IP over MPLS Encapsulation > >> > >> The simplest method of transporting Timing messages over MPLS is to > >> encapsulate Timing PDUs in UDP/IP and then encapsulate them in Timin= g > >> LSP. This format is shown in Figure 4. > >> > >> > >> +----------------------+ > >> | Timing LSP Label | > >> +----------------------+ > >> | IPv4/6 | > >> +----------------------+ > >> | UDP | > >> +----------------------+ > >> | Timing PDU | > >> +----------------------+ > >> > >> Figure (4) - Timing over UDP/IP over MPLS Encapsulation > >> > >> > >> This encapsulation is very simple and is useful when the network > >> between Timing Master Clock and Slave Clock is MPLS network. > >> > >> SB> Simple is a judgement call > >> > >> In order for an LER/LSR to process Timing messages, the Timing LSP > >> Label must be at the top label of the label stack. The LER/LSR MUST > >> know that the Timing LSP Label is used for carrying Timing messages. > >> This can be accomplished via static configuration or via RSVP-TE > >> signaling. > >> > >> The UDP/IP encapsulation of PTP MUST follow Annex D and E of > >> [IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow > >> [RFC5905]. > >> > >> 6.2. Timing over PW Encapsulation > >> > >> Another method of transporting Timing over MPLS networks is by > >> encapsulating Timing PDUs in PW which in turn is transported over > >> Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448], > >> shown in Fig 5(A) MUST be used and the Ethernet encapsulation of PTP > >> MUST follow Annex F of [IEEE-1588]. > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 13= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> The RAW mode or Tagged mode defined in [RFC4448] MAY be used and > the > >> Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The > >> Timing over PW encapsulation MUST use the Control Word (CW) as > >> specified in [RFC4448] to ensure proper detection of PTP messages > >> inside the MPLS packets for Timing over LSP and Timing over PW > >> encapsulation. > >> > >> SB> That needs explanation > >> > >> The use of Sequence Number in the CW is optional. > >> > >> SB> Given that s/n are never in practice deployed, you could probably > >> SB> simplify things by sayig that they are not used. > >> > >> Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over > PW > >> (the IP PW discussed in [RFC4447]) shown in Fig 5(B). > >> > >> +----------------+ +----------------+ > >> |Timing LSP Label| |Timing LSP Label| > >> +----------------+ +----------------+ > >> | PW Label | | PW Label | > >> +----------------+ +----------------+ > >> | Control Word | | IP | > >> +----------------+ +----------------+ > >> | Ethernet | | UDP | > >> | Header | +----------------+ > >> +----------------+ | Timing PDU | > >> |S-VLAN(Optional)| | | > >> +----------------+ +----------------+ > >> |C-VLAN(Optional)| (B) > >> +----------------+ > >> | Timing PDU | > >> | | > >> +----------------+ > >> (A) > >> > >> Figure (5) - Timing over PW Encapsulations > >> > >> In order for an LSR to process PTP messages, the top label of the > >> label stack (the Tunnel Label) MUST be a Timing label. > >> > >> S> You said that before. > >> > >> 6.3. Other Timing Encapsulation methods > >> > >> In future other timing encapsulation methods may be introduced, such > >> as a new shim header after the Bottom of Stack to carry the Timing > >> information. Such new encapsulations are outside the scope of this > >> document. > >> > >> > >> SB> Taking a pure MPLS pov, you can simplify a lot of the text > >> SB> out of the definition of the LSP > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 14= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> SB> I think we need a section on LSP processing > >> > >> 7. Timing message Processing > >> > >> Each Timing protocol such as PTP and NTP, define their set of Timing > >> messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, > >> FOLLOW_UP, etc messages. > >> > >> Some of the Timing messages require time stamping or correction fiel= d > >> update at port level and some dont. It is the job of the LER/LSR to > >> parse the timing message and find out the type of the Timing message > >> and decide whether and how to Time- stamp it (e.g., BC) or update > >> correction field(e.g., TC). > >> > >> > >> SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing > >> SB> function rather than the LER? > >> > >> For example the following PTP messages (called Event messages) > >> require time-stamping or correction field update: > >> > >> o SYNC > >> > >> o DELAY_REQ (Delay Request) > >> > >> o PDELAY_REQ (Peer Delay Request) > >> > >> o PDELAY_RESP (Peer Delay Response) > >> > >> SYNC and DELAY_REQ are exchanged between Master Clock and Slave > Clock > >> and MUST be transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP > >> are exchanged between adjacent PTP clocks (i.e. Master, Slave, > >> Boundary, or Transparent) and SHOULD be transported over single hop > >> PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP, > >> and PDELAY_RESP_FOLLOW_UP messages MUST also be transported over > >> the > >> PTP LSPs. > >> > >> For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be > >> transported over two PTP LSPs that are in opposite directions. Thes= e > >> PTP LSPs, which are in opposite directions MUST be congruent and co- > >> routed. Alternatively, a single bidirectional co-routed LSP can be > >> used. > >> > >> Except as indicated above for the two-step PTP clocks, Non-Event PTP > >> message types do not need to be processed by intermediate routers. > >> These message types MAY be carried in PTP Tunnel LSPs. > >> > >> SB> Are you saying that a timing P router has to be msg type sensitive? > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 15= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 8. Protection and Redundancy > >> > >> > >> SB> This is a bit of a jump - I don't know how the LSP itself works yet= ! > >> > >> In order to ensure continuous uninterrupted operation of slave > >> clocks, usually as a general practice, slave clocks (or ports) track > >> redundant master clocks. > >> > >> It is the responsibility of the network operator to ensure that > >> physically disjoint Timing LSPs are established between a slave cloc= k > >> (or port) and redundant master clocks (or ports). > >> > >> When a slave clock (or port) listens to redundant master clocks or > >> ports, any prolonged Timing LSP outage will trigger the slave clock > >> or port to switch to a redundant master clock or port. > >> > >> LSP/PW protection such as Linear protection Switching (1:1, 1+1), > >> Ring protection switching or MPLS Fast Reroute (FRR) generally switc= h > >> alternative path that usually cause a change in delay, which if > >> undetected by slave clock can reduce accuracy of the slave clock. > >> > >> Therefore protection switching MAY be used, as long as phase jumps > >> upon switchover due to differences in path latency are detected and > >> compensated for (such compensation not being required if BCs or peer= - > >> peer TCs are used throughout). > >> > >> Note that any protection or reroute mechanism that adds additional > >> MPLS label to the label stack, such as Facility Backup Fast Reroute, > >> MUST ensure that the pushed label is also a Timing Label to ensure > >> recognition of the MPLS frame as containing Timing messages, as it > >> transits the backup path. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 16= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 9. ECMP > >> > >> To ensure the optimal operation of slave clocks and avoid error > >> introduced by forward and reverse path delay asymmetry, the physical > >> path for Timing messages from master clock to slave Clock and vice > >> versa must be the same for all Event Timing messages listed in > >> section 7. > >> > >> Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost > >> Multipath). > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 17= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 10. PHP > >> > >> To ensure that the label on the top of the label stack is the Timing > >> LSP Label, PHP MUST not be used. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 18= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 11. Entropy > >> > >> To ensure all Timing messages in a Timing LSP take the same path, > >> Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and > >> Entropy Label MUST NOT be used for the PWs that are carried inside > >> Timing LSP [RFC6391]. > >> > >> SB> This is incorrect - you mean that all msgs of the same timing > >> SB> flow need to have the same EL value. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 19= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 12. OAM, Control and Management > >> > >> In order to monitor Timing LSPs and their encapsulated PWs, they MUS= T > >> be able to carry OAM and management messages. These management > >> messages MUST be differentiated from Timing messages via already > >> defined IETF methods. > >> > >> For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY run > >> over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These > >> Management protocols can easily be identified by the UDP Destination > >> Port number or by GAL/G-ACH respectively. > >> > >> Also BFD, LSP-Ping and other management messages MAY run over the > PWs > >> encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3 o= r > >> 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is goin= g > >> to be deprecated by IETF). In this case G-ACH, PW label (TTL=3D1) o= r > >> GAL-ACH are used to identify such management messages. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 20= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 13. QoS Considerations > >> > >> In network deployments where not every LSR/LER is Timing-aware, it i= s > >> important to reduce the impact of the non-Timing-aware LSR/LERs on > >> the timing recovery in the slave clock. The Timing messages are tim= e > >> critical and must be treated with the highest priority. Therefore > >> Timing over MPLS messages must be treated with the highest priority > >> in the routers. This can be achieved by proper setup of Timing LSPs= . > >> > >> It is recommended that the Timing LSPs are setup or configured > >> properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC2697] > >> for drop eligibility. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 21= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 14. FCS and Checksum Recalculation > >> > >> When time-stamp generation and timing packet adjustment is performed > >> near the physical port hardware, the process MUST include > >> recalculation of the Ethernet FCS. > >> > >> SB> The above is confusing - an LSR always recomputes the link layer > >> SB> CRC which may or may not be Ethernet. > >> > >> Also FCS retention for the > >> payload Ethernet described in [RFC4720] MUST NOT be used. > >> > >> For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum > >> may be required as per UDP transport standards. > >> > >> SB> You really need to be working on getting the IPv6 C?S computation > >> SB> removed from PTP msgs. > >> > >> When UDP checksum is used, each Timing-aware LER/LSR must either > >> incrementally update the UDP checksum after Time stamping or > >> Correction Field update or verify the UDP checksum on reception from > >> upstream and recalculate the checksum completely on transmission to > >> downstream node after Time stamping or Correction Field update. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 22= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 15. Behavior of LER/LSR > >> > >> Timing-capable/aware LERs and LSRs are routers that have one or more > >> > >> SB> You mean physical interfaces? > >> > >> interfaces that can perform Timing operations (OC/BC/TC) on Timing > >> packets and are configured to do so. Timing-capable/aware LERs and > >> LSRs can advertise their Timing-capability per-interface via control > >> plane such as OSPF or IS-IS. > >> SB> ISIS and OSPF are routing protocols. > >> > >> The Timing-capable/aware LERs can then > >> signals Timing LSPs via RSVP-TE signaling. Alternatively the Timing > >> capability of LER and LSRs may be configured in a centralized > >> controller and the Timing LSP may be setup using manual configuratio= n > >> or other methods such as SDN. > >> > >> SB> it can also be configured individually rather then through > >> SB> a cebtral controllwe > >> > >> 15.1. Behavior of Timing-capable/aware LER > >> > >> When a Timing-capable/aware LER behaves as a Transparent clock and > >> receives a Timing message from a Timing-capable/aware non-MPLS > >> interface, the LER updates the Correction Field (CF) and encapsulate= s > >> and forwards the timing message over previously established Timing > >> LSP. > >> > >> SB> You need to call out the details so that people properly > >> SB> understand the definition of the new LSP. > >> > >> Also when a Timing message is received from a Timing-capable/ > >> aware MPLS interface, LER updates the Correction Filed (CF) and > >> decapsulates the MPLS encapsulation and forwards the timing message > >> to a non-MPLS interface. > >> > >> When a Timing-capable/aware LER behaves as a Boundary clock and > >> receives a Timing message from a Timing-capable/aware non MPLS > >> interface, the LER Timestamps the Timing packet and sends it to the > >> LERs Boundary clock processing module. Also when a Timing message i= s > >> received from a Timing- capable/aware MPLS interface, the LER > >> Timestamps the Timing packet and sends it to the LERs Boundary clock > >> processing module. > >> > >> When a Timing-capable/aware LER behaves as an Ordinary Clock toward > >> the MPLS network, and receives a Timing message from a Timing- > >> capable/aware MPLS interface, the LER Timestamps the Timing packet > >> and sends it to the LERs Ordinary clock processing module. > >> > >> 15.2. Behavior of Timing-capable/aware LSR > >> > >> When a Timing-capable/aware LSR behaves as a Transparent clock and > >> receives a Timing message from a Timing-capable/aware MPLS interface= , > >> The LSR updates the Correction Filed (CF) and forwards the timing > >> message over another MPLS interface. > >> > >> When a Timing-capable/aware LSR behaves as a Boundary clock and > >> receives a Timing message from a Timing-capable/aware MPLS interface= . > >> The LSR performs the functions of a Boundary Clock in terminating th= e > >> received Timing message and re-generating a new timing message over > >> another (or the same) MPLS interface. > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 23= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 15.3. Behavior of non-Timing-capable/aware LSR > >> > >> It is most beneficial when all LSRs in the path of a Timing LSP be > >> timing-Capable/aware LSRs. This would ensure the highest quality > >> time and clock synchronization by Timing Slave Clocks. However, thi= s > >> specification does not mandate that all LSRs in path of a Timing LSP > >> be Timing- capable/aware. > >> > >> Non-Timing-capable/aware LSRs just switch the packets encapsulated i= n > >> Timing LSPs and dont perform any Timing operation (TC or BC). > >> However as explained in QoS section the Timing over MPLS packets MUS= T > >> be still be treated with the highest priority based on their Traffic > >> Class (TC) marking. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 24= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 16. Other considerations > >> > >> [IEEE-1588] defines an optional peer-to-peer Transparent clocking > >> that requires peer delay measurement between two adjacent Timing- > >> capable/ aware routers/switches. Peer delay measurement messages > >> need to be time stamped and terminated by the Timing-capable/aware > >> routers/ switches. This means that two adjacent LSRs may be engaged > >> in a peer delay measurement. > >> > >> For transporting such peer delay measurement messages a single-hop > >> LSP SHOULD to be created between the two adjacent LSRs engaged in > >> peer delay measurement to carry peer delay measurement messages. > >> Other methods such as PTP transport over Ethernet MAY be used for > >> transporting peer delay measurement messages if the link between the > >> two routers is Ethernet. > >> > >> In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ war= e > >> routers/switches MUST maintain a list of all the neighbors it needs > >> to send a PDelay_Req to, where each neighbor corresponds to a timing > >> LSP. > >> > >> The use of Explicit Null Label (Label=3D 0 or 2) is acceptable as lo= ng > >> as either the Explicit Null label is the bottom of stack label > >> (applicable only to UDP/IP encapsulation) or the label below the > >> Explicit Null label is a PTP label. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 25= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 17. Security Considerations > >> > >> MPLS PW security considerations in general are discussed in [RFC3985= ] > >> and [RFC4447],and those considerations also apply to this document. > >> > >> An experimental security protocol is defined in [IEEE-1588].The PTP > >> security extension and protocol provides group source authentication= , > >> message integrity, and replay attack protection for PTP messages. > >> > >> When the MPLS network (provider network) serves multiple customers, > >> it is important to maintain and process each customers clock and > >> Timing messages separately from other customers to ensure there is n= o > >> cross- customer effect. For example if an LER BC is synchronized to > >> a specific grandmaster, belonging to customer A, then the LER MUST > >> use that BC clock only for customer A to ensure that customer A > >> cannot attack other customers by manipulating its time. > >> > >> Timing messages MAY be encrypted or authenticated, provided that the > >> LERs/LSRs that are Timing capable/aware can authenticate/ decrypt th= e > >> timing messages. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 26= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 18. Acknowledgements > >> > >> The authors would like to thank Ron Cohen, Yaakov Stein, Tal Mizrahi= , > >> Stefano Ruffini, Peter Meyer, and other members of IETF for reviewin= g > >> and providing feedback on this draft. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 27= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 19. IANA Considerations > >> > >> There are no IANA requirements in this specification. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 28= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 20. References > >> > >> 20.1. Normative References > >> > >> [IEEE-1588] > >> IEEE 1588-2008, "IEEE Standard for a Precision Clock > >> Synchronization Protocol for Networked Measurement and > >> Control Systems". > >> > >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > >> Requirement Levels", BCP 14, RFC 2119, March 1997. > >> > >> [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- > >> Edge (PWE3) Architecture", RFC 3985, March 2005. > >> > >> [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery > >> Proxies (ND Proxy)", RFC 4389, April 2006. > >> > >> [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. > >> Heron, "Pseudowire Setup and Maintenance Using the Label > >> Distribution Protocol (LDP)", RFC 4447, April 2006. > >> > >> [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, > >> "Encapsulation Methods for Transport of Ethernet over MPL= S > >> Networks", RFC 4448, April 2006. > >> > >> [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire > >> Emulation Edge-to-Edge (PWE3) Frame Check Sequence > >> Retention", RFC 4720, November 2006. > >> > >> [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit > >> Connectivity Verification (VCCV): A Control Channel for > >> Pseudowires", RFC 5085, December 2007. > >> > >> [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection > >> (BFD)", RFC 5880, June 2010. > >> > >> [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, > >> "Bidirectional Forwarding Detection (BFD) for MPLS Label > >> Switched Paths (LSPs)", RFC 5884, June 2010. > >> > >> 20.2. Informative References > >> > >> [I-D.ietf-pwe3-fat-pw] > >> Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, > >> J., and S. Amante, "Flow Aware Transport of Pseudowires > >> over an MPLS Packet Switched Network", > >> draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011. > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 29= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate > >> system routeing information exchange protocol for use in > >> conjunction with the Protocol for providing the > >> Connectionless-mode Network Service (ISO 8473)". > >> > >> [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and > >> dual environments", RFC 1195, December 1990. > >> > >> [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. > >> > >> [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color > >> Marker", RFC 2697, September 1999. > >> > >> [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, > >> J., Courtney, W., Davari, S., Firoiu, V., and D. > >> Stiliadis, "An Expedited Forwarding PHB (Per-Hop > >> Behavior)", RFC 3246, March 2002. > >> > >> [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineerin= g > >> (TE) Extensions to OSPF Version 2", RFC 3630, > >> September 2003. > >> > >> [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate > >> System (IS-IS) Extensions for Traffic Engineering (TE)", > >> RFC 3784, June 2004. > >> > >> [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. > >> Shaffer, "Extensions to OSPF for Advertising Optional > >> Router Capabilities", RFC 4970, July 2007. > >> > >> [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate > >> System to Intermediate System (IS-IS) Extensions for > >> Advertising Router Information", RFC 4971, July 2007. > >> > >> [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi > >> Topology (MT) Routing in Intermediate System to > >> Intermediate Systems (IS-ISs)", RFC 5120, February 2008. > >> > >> [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic > >> Engineering", RFC 5305, October 2008. > >> > >> [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, > >> "Traffic Engineering Extensions to OSPF Version 3", > >> RFC 5329, September 2008. > >> > >> [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF > >> for IPv6", RFC 5340, July 2008. > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 30= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Networ= k > >> Time Protocol Version 4: Protocol and Algorithms > >> Specification", RFC 5905, June 2010. > >> > >> [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, > >> J., and S. Amante, "Flow-Aware Transport of Pseudowires > >> over an MPLS Packet Switched Network", RFC 6391, > >> November 2011. > >> > >> [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and > >> L. Yong, "The Use of Entropy Labels in MPLS Forwarding", > >> RFC 6790, November 2012. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 31= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 1. Routing extensions for Timing-aware Routers > >> > >> MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and > >> IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE) > >> link information used for constraint-based routing. > >> > >> Indeed, it is useful to advertise data plane TE router link > >> capabilities, such as the capability for a router to be Timing-aware= . > >> This capability MUST then be taken into account during path > >> computation to prefer or even require links that advertise themselve= s > >> as Timing-aware. In this way the path can ensure the entry and exit > >> points into the LERs and, if desired, the links into the LSRs are > >> able to perform port based time-stamping thus minimizing their impac= t > >> on the performance of the slave clock. > >> > >> extensions are required to OSPF and IS-IS in order to advertise > >> Timing-aware capabilities of a link. Such extensions are outside th= e > >> scope of this document; however such extension SHOULD be able to > >> signal the following information per Router Link: > >> > >> o Capable of processing PTP, NTP or other Timing flows > >> > >> o Capable of performing Transparent Clock operation > >> > >> o Capable of performing Boundary Clock operation > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 32= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> 2. Signaling Extensions for Creating Timing LSPs > >> > >> RSVP-TE signaling MAY be used to setup the timing LSPs. When RSVP-T= E > >> is used to setup Timing LSPs, some information that indicates that > >> the LSP is carrying Timing flows MUST be included in the new > >> Extensions to RSVP-TE: > >> > >> The following information MAY also be included in the new Extensions > >> to RSVP-TE: > >> > >> o Offset from Bottom of Stack (BoS) to the start of the Time-stamp > >> field > >> > >> o Number of VLANs in case of PW encapsulation > >> > >> o Timestamp field Type > >> > >> * Correction Field, Timestamp > >> > >> o Timestamp Field format > >> > >> * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit > >> NTP, etc. > >> > >> Note that in case the above optional information is signaled with > >> RSVP-TE for a Timing LSP, all the Timing packets carried in that LSP > >> must have the same signaled characteristics. For example if > >> Timestamp format is signaled as 64-bit PTPv1, then all Timing packet= s > >> must use 64-bit PTPv1 time-stamp. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 33= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> Authors' Addresses > >> > >> Shahram Davari > >> Broadcom Corp. > >> San Jose, CA 95134 > >> USA > >> > >> Email: davari@broadcom.com > >> > >> > >> Amit Oren > >> Broadcom Corp. > >> San Jose, CA 95134 > >> USA > >> > >> Email: amito@broadcom.com > >> > >> > >> Manav Bhatia > >> Alcatel-Lucent > >> Bangalore, > >> India > >> > >> Email: manav.bhatia@alcatel-lucent.com > >> > >> > >> Peter Roberts > >> Alcatel-Lucent > >> Kanata, > >> Canada > >> > >> Email: peter.roberts@alcatel-lucent.com > >> > >> > >> Laurent Montini > >> Cisco Systems > >> San Jose CA > >> USA > >> > >> Email: lmontini@cisco.com > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 34= ] > > > >> Internet-Draft Transporting Timing over MPLS June 201= 3 > >> > >> > >> Luca > >> Cisco Systems > >> San Jose CA > >> USA > >> > >> Email: lmartini@cisco.com > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Davari, et al. Expires December 17, 2013 [Page 35= ] > > > >> > >> -- > >> For corporate legal information go to: > >> > >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html > >> > >> _______________________________________________ > >> TICTOC mailing list > >> TICTOC@ietf.org > >> https://www.ietf.org/mailman/listinfo/tictoc > > > > > > 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 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 stbryant@cisco.com Mon Aug 5 02:30:25 2013 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 700F221F8EB3; Mon, 5 Aug 2013 02:30:19 -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 Kj6u+2UzcgHs; Mon, 5 Aug 2013 02:30:09 -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 8779C21F97C7; Mon, 5 Aug 2013 02:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=69317; q=dns/txt; s=iport; t=1375694963; x=1376904563; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Pf82lB9bGTRKsubYizE4CBG/tR2TdaUDf3oMUbE1+Lg=; b=fOVuzPULB4lczKII/ui3tPYTDyiHuSwIoFnpFEIjy9A47b0rRn4fp8j6 ws/DbEeuf469/CrKAokdXQcx8I24FsWZIZQiLLXGPZId31d0DppacLdLj 07ADeemj1z11341OX00Gdz+0oIF1ZAA8zSoY6va+QT8rESD32CHvNDBTU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAEFv/1GQ/khN/2dsb2JhbABQCoMGNb9JgR4WdIIkAQEBAwEBAQEXAR0uAQcKAQwECxEBAwEBAQkMCggHCQMCAQIBFR8DBggGCgMBBQIBAReHbwYMtG2ORgIJBgUFgRYiBwYEhAMDjEGHB0GDV4EqhW2KOIMYgWcBBQMX X-IronPort-AV: E=Sophos;i="4.89,817,1367971200"; d="scan'208";a="158008151" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 05 Aug 2013 09:29:20 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r759TIbR011511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Aug 2013 09:29:18 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r759TC9Z028298; Mon, 5 Aug 2013 10:29:12 +0100 (BST) Message-ID: <51FF7068.9080600@cisco.com> Date: Mon, 05 Aug 2013 10:29:12 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "S. Davari" References: <51FB7543.801@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] Comments on draft-ietf-tictoc-1588overmpls 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, 05 Aug 2013 09:30:27 -0000 My concern is that we are creating a new LSP type in MPLS (which is a architectural change and thus needs to be very carefully considered) without asking the question "how can I do this in the most general way, to maximize flexibility/reuse" I suggested an LSP type that has the properties "timestamp and pass to application", but I think that Sasha raises a good point about using router alert. However RA has no implicit timestamp, so maybe we need a new type of RA that has the properties "timestamp, and pass top application indicated by the next label". That would be quite useful in a number of OAM applications. There is possibly some GAL variant of that design that should also be considered. The application could worry about the path and where it was necessary to skip some hops a hierarchical LSP would accomplish that, with the specific benefit that the application would consciously do this, and may be able to apply some form of compensation within the network. - Stewart On 04/08/2013 10:40, S. Davari wrote: > Hi Sasha > > Perhaps you have not understood the draft well. The main reason that the draft chose to use a dedicated LSP that is signaled via RSVPTE indicating it is a timing LSP is to be backward compatible with non-1588 nodes. Such nodes simply just switch the packet. > > Your proposal had been considered and was rejected since it was not backward compatible. Nodes receiving alert label or TTL = 1 send the packet to CPU. You can refer to the meeting notes. > > Regards, > Shahram > > > On Aug 4, 2013, at 1:21 AM, Alexander Vainshtein wrote: > >> Stewart and all, >> I concur with Stewart's statement that the draft does not define "full interaction with MPLS architecture". >> >> E.g., one of the objectives of the draft is to provide a technique that would be backward-compatible with old LSRs that cannot provide on-path support for timing distribution, while the other objective is to make every LSR on the path aware that some MPLS packets are carrying timing-related messages and hence require on-path support. >> >> IMHO and FWIW, the MPLS data plane architecture allows just two methods for making a transit LSR to provide special processing to a labeled packet: >> - It would carry some kind of an "alert label" on top of the label stack and, specifically, on top of any labels used for actual forwarding >> OR, >> - The TTL in the top label stack entry has been set to 1. >> >> >> The draft does not follow any of these approaches. >> >> I must also admit that Section 12 "OAM, Control and Management" of the draft looks somewhat in >> E.g., I could not understand from the text whether BFD, LSP-Ping etc. OAM messages would be subjected to on-path support procedures for timing messages or not. >> >> My 2c, >> Sasha >> >>> -----Original Message----- >>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of >>> Stewart Bryant >>> Sent: Friday, August 02, 2013 12:01 PM >>> To: mpls-chairs@tools.ietf.org; tictoc-chairs@tools.ietf.org; int- >>> ads@tools.ietf.org; rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft- >>> ietf-tictoc-1588overmpls@tools.ietf.org >>> Cc: mpls@ietf.org; tictoc@ietf.org >>> Subject: [TICTOC] Comments on draft-ietf-tictoc-1588overmpls >>> >>> SB> This draft does not seem to provide a precise definition >>> SB> the properties of the new LSP type that it wishes to >>> SB> define, in particular it does it define the PHB of those >>> SB> LSPs, nor the full interaction with the MPLS >>> SB> architecture. >>> SB> >>> SB> I have not tracked TICTOC for a while but I thought that >>> SB> the original plan was to define the concept of an offset >>> SB> into a packet to do the correction. >>> SB> >>> SB> It is disappointing that the opportunity was not taken >>> SB> to define a timing shim inside the timing LSP so that >>> SB> a time correction could be added to any packet such that >>> SB> the MPLS system was isolated from the details of the >>> SB> complexity of the particular time transfer type. >>> >>> SB> I think that much more clarify is needed in terms of >>> SB> definition of the new LSP type, since it is unclear >>> SB> from this text how to implement one. >>> SB> >>> SB> There are a lot of other MPLS services such as >>> SB> LSP ping that need to be considered. >>> SB> >>> SB> Please see inline for more comments. However these >>> SB> comments are made in the context of the text as written >>> SB> whilst I have a fundamental concern that this approach >>> SB> lacks an MPLS architectural soundness that need >>> SB> greater thought with significant impact on the >>> SB> draft. >>> >>> - Stewart >>> >>> >>> TICTOC Working Group S. Davari >>> Internet-Draft A. Oren >>> Intended status: Standards Track Broadcom Corp. >>> Expires: December 17, 2013 M. Bhatia >>> P. Roberts >>> Alcatel-Lucent >>> L. Montini >>> L. Martini >>> Cisco Systems >>> June 15, 2013 >>> >>> >>> Transporting Timing messages over MPLS Networks >>> draft-ietf-tictoc-1588overmpls-05 >>> >>> Abstract >>> >>> This document defines the method for transporting Timing messages >>> such as PTP and NTP over an MPLS network. The method allows for the >>> easy identification of these PDUs at the port level to allow for port >>> >>> SB> What is a port >>> >>> level processing of these PDUs in both LERs and LSRs. >>> >>> The basic idea is to transport Timing messages inside dedicated MPLS >>> LSPs. These LSPs only carry Timing messages and possibly Control and >>> Management packets, but they do not carry customer traffic. >>> >>> SB> More specifically they only carry traffic associated with the >>> SB> timing service and its support. >>> SB> The question arose WRT BFD - surely BFD is allowed, BUT surely >>> SB> also it gets carried in a structure that causes it to get >>> SB> timestamped. >>> >>> Two methods for transporting Timing messages over MPLS are defined. >>> >>> SB> Perhaps the right approach is to define the new LSP type and then >>> SB> seperately to define the mapping of the various timing services >>> SB> over that LSP type. >>> >>> The first method is to transport Timing messages directly over the >>> dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for >>> MPLS networks. The second method is to transport Timing messages >>> inside a PW via Ethernet encapsulation. >>> >>> SB> I think that we should note that there are some >>> SB> h/w reasons for this preference. A clean sheet approach >>> SB> would have been to use PTP over MPLS with no intermediate >>> SB> layers. >>> >>> Status of this Memo >>> >>> This Internet-Draft is submitted in full conformance with the >>> provisions of BCP 78 and BCP 79. >>> >>> Internet-Drafts are working documents of the Internet Engineering >>> Task Force (IETF). Note that other groups may also distribute >>> working documents as Internet-Drafts. The list of current Internet- >>> Drafts is at http://datatracker.ietf.org/drafts/current/. >>> >>> Internet-Drafts are draft documents valid for a maximum of six months >>> and may be updated, replaced, or obsoleted by other documents at any >>> time. It is inappropriate to use Internet-Drafts as reference >>> material or to cite them other than as "work in progress." >>> >>> This Internet-Draft will expire on December 17, 2013. >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 1] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> Copyright Notice >>> >>> Copyright (c) 2013 IETF Trust and the persons identified as the >>> document authors. All rights reserved. >>> >>> This document is subject to BCP 78 and the IETF Trust's Legal >>> Provisions Relating to IETF Documents >>> (http://trustee.ietf.org/license-info) in effect on the date of >>> publication of this document. Please review these documents >>> carefully, as they describe your rights and restrictions with respect >>> to this document. Code Components extracted from this document must >>> include Simplified BSD License text as described in Section 4.e of >>> the Trust Legal Provisions and are provided without warranty as >>> described in the Simplified BSD License. >>> >>> >>> Table of Contents >>> >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 >>> >>> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 >>> >>> 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 >>> >>> 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . 9 >>> >>> 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . . 12 >>> >>> 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . 13 >>> 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . . 13 >>> 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . . 13 >>> 6.3. Other Timing Encapsulation methods . . . . . . . . . . . . 14 >>> >>> 7. Timing message Processing . . . . . . . . . . . . . . . . . . 15 >>> >>> 8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 16 >>> >>> 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 >>> >>> 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 >>> >>> 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 >>> >>> 12. OAM, Control and Management . . . . . . . . . . . . . . . . . 20 >>> >>> 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 21 >>> >>> 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . . 22 >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 2] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 23 >>> 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . . 23 >>> 15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . . 23 >>> 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . . 24 >>> >>> 16. Other considerations . . . . . . . . . . . . . . . . . . . . . 25 >>> >>> 17. Security Considerations . . . . . . . . . . . . . . . . . . . 26 >>> >>> 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 >>> >>> 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 >>> >>> 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 >>> 20.1. Normative References . . . . . . . . . . . . . . . . . . . 29 >>> 20.2. Informative References . . . . . . . . . . . . . . . . . . 29 >>> >>> Appendix 1. Routing extensions for Timing-aware Routers . . . . . 32 >>> >>> Appendix 2. Signaling Extensions for Creating Timing LSPs . . . . 33 >>> >>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 3] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in >>> this >>> document are to be interpreted as described in RFC2119 [RFC2119]. >>> >>> When used in lower case, these words convey their typical use in >>> common language, and are not to be interpreted as described in >>> RFC2119 [RFC2119]. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 4] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 1. Introduction >>> >>> The objective of Precision Time Protocol (PTP) and Network Timing >>> Protocol (NTP) are to synchronize independent clocks running on >>> separate nodes of a distributed system. >>> >>> [IEEE-1588] defines PTP messages for frequency, phase and time >>> synchronization. The PTP messages include PTP PDUs over UDP/IP >>> (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex F of >>> [IEEE-1588]). >>> >>> SB> Sure BUT it is acknowledged that IEEE is open to the definition >>> SB> of other PTP mappings if they provide better optimisation. >>> >>> This document defines mapping and transport of the PTP >>> messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP >>> defines several clock types: ordinary clocks, boundary clocks, end- >>> to-end transparent clocks, and peer-to-peer transparent clocks. >>> Transparent clocks require intermediate nodes to update correction >>> field inside PTP message that reflects the transit time in the node. >>> >>> [RFC5905] defines NTP messages for clock and time synchronization. >>> The PTP messages (PDUs) are transported over UDP/IP. This document >>> SB> Should that be NTP messages? >>> SB> It needs to be made clear as soon as you introduce NTP that >>> SB> they use different time representations. >>> >>> defines mapping and transport of the NTP messages defined in >>> [RFC5905] over MPLS networks. >>> >>> One key attribute of all of these Timing messages is that the Time >>> stamp processing should occur as close as possible to the actual >>> transmission and reception at the physical port interface. This >>> targets optimal time and/or frequency recovery by avoiding variable >>> delay introduced by queues internal to the clocks. >>> >>> SB> As I recall NTP has no epoch point defined, and I am not sure >>> SB> where that point is in the case of PTP in this mapping >>> SB> Hopefully this will get defined in due course. >>> >>> To facilitate the fast and efficient recognition of Timing messages >>> at the port level when the Timing messages are carried over MPLS >>> LSPs, >>> >>> SB> Over a new LSP type with time optimied characteristics >>> >>> this document defines the specific encapsulations that should >>> be used. >>> SB> Hopefully it will also define the PHP >>> >>> In addition, it can be expected that there will exist LSR/ >>> LERs where only a subset of the physical ports will have the port- >>> based Timing message processing capabilities. >>> SB> Do you need to clarify that this only works at base and not in >>> SB> a label heirarchy. >>> >>> >>> In order to ensure >>> that the LSPs carrying Timing packets always enter and exit ports >>> with this capability, routing extensions are defined to advertise >>> this capability on a port basis and to allow for the establishment of >>> LSPs that only transit such ports. While this path establishment >>> restriction may be applied only at the LER Ingress and/or egress >>> ports, it becomes more important when using transparent clock capable >>> LSRs in the path. >>> SB> I do not understand the implications of the last >>> SB> sentences - starting ", it becomes" >>> >>> >>> Port based Timing message processing involves Timing message >>> recognition. Once the Timing messages are recognized they can be >>> modified based on the reception or transmission Time-stamp. >>> >>> This document provides two methods for transporting Timing messages >>> over MPLS. One is applicable to MPLS environment and the other one >>> is applicable to MPLS/MPLS-TP environment >>> >>> SB> I think the sentence is incomplete. >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 5] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> The solution involves transporting Timing messages over dedicated >>> LSPs called Timing LSPs. These LSPs carry Timing messages and MAY >>> carry Management and control messages, but not data plane client >>> traffic. >>> >>> SB> It is not clear why this restriction applies. >>> >>> Timing LSPs can be established statically or via signaling. >>> SB> s/statically/by provisioning/network management/ >>> >>> Extensions to control plane (OSPF, ISIS, etc.) is required to enable >>> routers to distribute their Timing processing capabilities over MPLS >>> to other routers. However such extensions are outside the scope of >>> this document. >>> >>> When signaling is used to setup the PTP LSP, Extensions to signaling >>> SB> is it a PTP LSP or a Timing LSP? >>> >>> protocols (e.g., RSVP-TE) are required for establishing PTP LSPs. >>> However such extensions are outside the scope of this document. >>> >>> SB> for mpls-tp GMPLS is the signalling protocol >>> >>> While the techniques included herein allow for the establishment of >>> paths optimized to include Time-stamping capable links, the >>> performance of the Slave clocks is outside the scope of this >>> document. >>> >>> At the time of publishing this specification, Transparent Clocking >>> (TC) is only defined for PTP. Therefore at this time any part of >>> this specification that talks about Transparent Clocking applies only >>> to PTP. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 6] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 2. Terminology >>> >>> 1588: The timing and synchronization as defined by IEEE 1588. >>> >>> SB> I think that there is a more formal name for the 1588 group >>> SB> that needs to be used here. >>> SB> Also do we need to talk about 1588-200? as there is >>> SB> an update in progress >>> >>> NTP: The timing and synchronization protocol defined by IETF RFC-1305 >>> and RFC-5905. >>> >>> PTP: The timing and synchronization protocol used by 1588. >>> SB> need the proper name for 1588 >>> >>> Master Clock: The source of 1588 timing to a set of slave clocks. >>> >>> Master Port: A port on a ordinary or boundary clock that is in Master >>> state. This is the source of timing toward slave ports. >>> >>> SB> I am not sure the reader knows what a port is >>> >>> Slave Clock: A receiver of 1588 timing from a master clock. >>> >>> Slave Port: A port on a boundary clock or ordinary clock that is >>> receiving timing from a master clock. >>> >>> Ordinary Clock: A device with a single PTP port. >>> >>> Transparent Clock. A device that measures the time taken for a PTP >>> event message to transit the device and then updates the >>> correctionField of the message with this transit time. >>> >>> Boundary Clock: A device with more than one PTP port. Generally >>> boundary clocks will have one port in slave state to receive timing >>> and then other ports in master state to re-distribute the timing. >>> >>> PTP LSP: An LSP dedicated to carry PTP messages >>> >>> SB> PTP or timing? >>> >>> >>> PTP PW: A PW within a PTP LSP that is dedicated to carry PTP >>> messages. >>> >>> SB> Ah I don't think that PWE3 know what one of these is >>> >>> CW: Pseudowire Control Word >>> >>> LAG: Link Aggregation >>> >>> ECMP: Equal Cost Multipath >>> >>> CF: Correction Field, a field inside certain PTP messages (message >>> type 0-3)that holds the accumulative transit time inside intermediate >>> switches >>> >>> Timing messages: Timing Protocol messages that are exchanged between >>> routers in order to establish a synchronized clock. >>> >>> SB> A number of these definitions look like copies of IEEE1588 >>> SB> definitions. We need to provide references and note the >>> SB> priority of the IEEE base reference. >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 7] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 3. Problem Statement >>> >>> [IEEE-1588] has defined methods for transporting PTP messages over >>> Ethernet and IP networks. [RFC5905] has defined the method of >>> transporting NTP messages over IP networks. There is a need to >>> transport Timing messages over MPLS networks while supporting the >>> Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC) >>> functionality in the LER and LSRs in the MPLS network. >>> >>> There are multiple ways of transporting Timing over MPLS. However, >>> there is a requirement to limit the possible encapsulation options to >>> simplify the Timing message identification and processing required at >>> the port level. >>> >>> When Timing-awareness is needed, Timing messages should not be >>> transported over LSPs or PWs that are carrying customer traffic >>> because LSRs perform Label switching based on the top label in the >>> stack. >>> >>> SB> Have you explained why? >>> >>> To detect Timing messages inside such LSPs require special >>> hardware to do deep packet inspection at line rate. Even if such >>> hardware exists, the payload can't be deterministically identified by >>> LSRs because the payload type is a context of the PW label, and the >>> PW label and its context are only known to the Edge routers (PEs/ >>> LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, CES, >>> etc). Even if one restricts an LSP to only carry Ethernet PWs, the >>> LSRs dont have the knowledge of whether PW Control Word (CW) is >>> present or not and therefore can not deterministically identify the >>> payload. >>> >>> A generic method is defined in this document that does not require >>> deep packet inspection at line rate, and can deterministically >>> identify Timing messages. This method can be used to detect Timing >>> Messages in both one-step and two-step clock implementations of >>> ordinary, boundary and transparent clocks. >>> >>> SB> Needs a ref and I am sure many MPLS specialists will not understand >>> SB> the msg types. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 8] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 4. Timing over MPLS Architecture >>> >>> Timing messages are exchange between Timing ports on ordinary and >>> >>> SB> Have you defined a timing port? >>> >>> boundary clocks. Boundary clocks terminate the Timing messages and >>> act as master for other boundary clocks or for slave clocks. End-to- >>> End Transparent clocks do not terminate the Timing messages but they >>> do modify the contents of the Timing messages as they transit across >>> the transparent clock. >>> >>> Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent Clock >>> >>> (TC) could be implemented in either LERs or LSRs. >>> >>> SB> LER and LSR need to be expanded >>> >>> An example is shown in Figure 1, where the LERs act as Ordinary Clock >>> (OC) and are the initiating/terminating point for Timing messages. >>> The ingress LER encapsulates the Timing messages in Timing LSP and >>> the Egress LER terminates the Timing LSP. The LSRs act as >>> Transparent Clock (TC) and just update the Timing field in the Timing >>> messages. >>> >>> >>> +--------+ +-------+ +-------+ +-------+ +--------+ >>> |Switch, | | | | | | | |Switch, | >>> | Router |-----| LER |-----| LSR |-----| LER |-----| Router | >>> | | | OC | | TC | | OC | | | >>> +--------+ +-------+ +-------+ +-------+ +--------+ >>> / \ >>> +-------+ / \ +-------+ >>> | LER | / \ | LER | >>> | Master|---/ \---| Slave | >>> | Clock | | Clock | >>> +-------+ +-------+ >>> >>> Figure (1) - Deployment example 1 of timing over MPLS network >>> >>> Another example is shown in Figure2, where LERs terminate the Timing >>> messages received from switch/routers that are outside of the MPLS >>> network acting as OC or BC. In this example LERs regenerate the >>> clock and initiate timing messages encapsulated in Timing LSP toward >>> the MPLS network, while the LSRs act as Transparent Clock (TC) and >>> just update the Timing field in the Timing messages, which are >>> already encapsulated in Timing LSPs. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 9] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> +--------+ +-------+ +-------+ +-------+ +--------+ >>> |Switch, | | | | | | | |Switch, | >>> | Router |-----| LER |-----| LSR |-----| LER |-----| Router | >>> | OC/BC | | BC | | TC | | BC | | OC/BC | >>> +--------+ +-------+ +-------+ +-------+ +--------+ >>> >>> Figure (2) - Deployment example 2 of timing over MPLS network >>> >>> >>> Another example is shown in Figure 3, where LERs do not terminate the >>> Timing messages received from switch/routers that are outside of the >>> MPLS network acting as OC, TC or BC. The LERs act as TC and update >>> the Timing field in the Timing messages as they transit the LER, >>> while encapsulating them in timing LSP. The LSRs also act as >>> Transparent Clock (TC) and just update the Timing field in the Timing >>> messages which are already encapsulated in Timing LSPs. >>> >>> +--------+ +-------+ +-------+ +-------+ +--------+ >>> |Switch, | | | | | | | |Switch, | >>> | Router |-----| LER |-----| LSR |-----| LER |-----| Router | >>> |OC/TC/BC| | TC | | TC | | TC | |OC/TC/BC| >>> +--------+ +-------+ +-------+ +-------+ +--------+ >>> >>> Figure (3) - Deployment example 3 of timing over MPLS network >>> >>> Another example is shown in Figure 4, where LERs and LSRs support >>> Boundary Clocks. A single-hop LSP is created between two adjacent >>> LSRs engaged in BC operation. Other methods such as PTP transport >>> over Ethernet MAY be used for transporting timing messages if the >>> link between the two routers is Ethernet. >>> >>> +--------+ +-------+ +-------+ +-------+ +--------+ >>> |Switch, | | | | | | | |Switch, | >>> | Router |-----| LER |-----| LSR |-----| LER |-----| Router | >>> | OC/BC | | BC | | BC | | BC | | OC/BC | >>> +--------+ +-------+ +-------+ +-------+ +--------+ >>> >>> Figure (4) - Deployment example 3 of timing over MPLS network >>> >>> An MPLS domain MAY serve multiple customers. In these cases the MPLS >>> domain (maintained by a service provider) may provide timing services >>> to multiple customers, each having their own Timing domain. >>> >>> The Timing over MPLS architecture assumes full mesh of Timing LSPs >>> between all LERs supporting this specification. >>> >>> SB> Note sure this is right - the salves surely do not need to >>> SB> exchange timing amongst themselves >>> >>> It supports >>> Point-to- point (VPWS) and Multipoint (VPLS) services. >>> >>> SB> What does that mean? You do not carry user data traffic? >>> SB> Maybe it's the ordering of the statemnets that is causing >>> SB> confusion. >>> >>> This means >>> that a customer may purchase a Point-to-point Timing service between >>> two customer sites or a Multipoint Timing service between more than >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 10] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> two customer sites. >>> >>> The Timing over MPLS architecture supports P2P or P2MP Timing LSPs. >>> This means that the Timing Multicast messages such as PTP Multicast >>> event messages can be transported over P2MP Timing LSP or be >>> replicated and transported over many P2P Timing LSPs. >>> >>> SB> Note we do not yet have a definition of a P2MP mpls-tp LSP >>> SB> nor a P2MP PW, although we are close. >>> >>> Timing messages, that do not require Time stamping or Correction >>> Field update MAY be transported over Timing LSPs to simplify hardware >>> and software. >>> >>> PTP Announce messages that determine the Timing LSP terminating point >>> behavior such as BC/OC/TC SHOULD be transported over the Timing LSP >>> to simplify hardware and software. >>> >>> SB> have you defined and referenced PTP announce msgs? >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 11] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 5. Dedicated LSPs for Timing messages >>> >>> Many methods have been considered for identifying the Timing messages >>> when they are encapsulated in MPLS such as using GAL/G-ACH or a new >>> reserved label. These methods were not attractive since they either >>> required deep packet inspection at line rate in the intermediate LSRs >>> or they required use of a scarce new reserved label. Also one of the >>> goals was to reuse existing OAM mechanisms. >>> >>> SB> RLs = SPLs are not so rare now. In any case needs a ref. >>> >>> The method defined in this document can be used by LER and LSRs to >>> identify Timing messages in MPLS tunnels by just looking at the top >>> label in the MPLS label stack, which only carry Timing messages as >>> well as OAM, but not data plane client traffic. >>> >>> Compliant implementations MUST use dedicated LSPs to carry Timing >>> messages over MPLS. >>> >>> SB> I think that we need a definition of the properies of these LSPs >>> >>> These LSPs are herein referred to as "Timing >>> LSPs" and the labels associated with these LSPs as "Timing LSP >>> labels". The Timing LSPs that runs between Ingress and Egress LERs >>> MUST be co-routed. Alternatively, a single bidirectional co-routed >>> LSP can be used. >>> >>> SB> I though that you said you could use M2MP LSPs - these are not >>> SB> bidirectional. >>> >>> Co-routing of the two directions is required to limit the difference >>> in the delays in the Master clock to Slave clock direction compared >>> to the Slave clock to Master clock direction. The Timing LSP MAY be >>> MPLS/MPLS-TP LSP. >>> >>> The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS. >>> New Extensions to RSVP-TE/GMPLS TLVs are required; however they are >>> outside the scope of this document. >>> >>> The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such as >>> BFD and LSP Ping but the LSP data plane client plane traffic MUST be >>> Timing packets only. >>> >>> SB> Why? >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 12] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 6. Timing over LSP Encapsulation >>> >>> The encapsulations is not LSP is it? >>> >>> This document defines two methods for carrying Timing messages over >>> MPLS. The first method is carrying UDP/IP encapsulated Timing >>> messages over Timing LSPs, and the second method, is carrying >>> Ethernet encapsulated Timing messages over Ethernet PWs inside Timing >>> LSPs. >>> >>> 6.1. Timing over UDP/IP over MPLS Encapsulation >>> >>> The simplest method of transporting Timing messages over MPLS is to >>> encapsulate Timing PDUs in UDP/IP and then encapsulate them in Timing >>> LSP. This format is shown in Figure 4. >>> >>> >>> +----------------------+ >>> | Timing LSP Label | >>> +----------------------+ >>> | IPv4/6 | >>> +----------------------+ >>> | UDP | >>> +----------------------+ >>> | Timing PDU | >>> +----------------------+ >>> >>> Figure (4) - Timing over UDP/IP over MPLS Encapsulation >>> >>> >>> This encapsulation is very simple and is useful when the network >>> between Timing Master Clock and Slave Clock is MPLS network. >>> >>> SB> Simple is a judgement call >>> >>> In order for an LER/LSR to process Timing messages, the Timing LSP >>> Label must be at the top label of the label stack. The LER/LSR MUST >>> know that the Timing LSP Label is used for carrying Timing messages. >>> This can be accomplished via static configuration or via RSVP-TE >>> signaling. >>> >>> The UDP/IP encapsulation of PTP MUST follow Annex D and E of >>> [IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow >>> [RFC5905]. >>> >>> 6.2. Timing over PW Encapsulation >>> >>> Another method of transporting Timing over MPLS networks is by >>> encapsulating Timing PDUs in PW which in turn is transported over >>> Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448], >>> shown in Fig 5(A) MUST be used and the Ethernet encapsulation of PTP >>> MUST follow Annex F of [IEEE-1588]. >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 13] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> The RAW mode or Tagged mode defined in [RFC4448] MAY be used and the >>> Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The >>> Timing over PW encapsulation MUST use the Control Word (CW) as >>> specified in [RFC4448] to ensure proper detection of PTP messages >>> inside the MPLS packets for Timing over LSP and Timing over PW >>> encapsulation. >>> >>> SB> That needs explanation >>> >>> The use of Sequence Number in the CW is optional. >>> >>> SB> Given that s/n are never in practice deployed, you could probably >>> SB> simplify things by sayig that they are not used. >>> >>> Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over PW >>> (the IP PW discussed in [RFC4447]) shown in Fig 5(B). >>> >>> +----------------+ +----------------+ >>> |Timing LSP Label| |Timing LSP Label| >>> +----------------+ +----------------+ >>> | PW Label | | PW Label | >>> +----------------+ +----------------+ >>> | Control Word | | IP | >>> +----------------+ +----------------+ >>> | Ethernet | | UDP | >>> | Header | +----------------+ >>> +----------------+ | Timing PDU | >>> |S-VLAN(Optional)| | | >>> +----------------+ +----------------+ >>> |C-VLAN(Optional)| (B) >>> +----------------+ >>> | Timing PDU | >>> | | >>> +----------------+ >>> (A) >>> >>> Figure (5) - Timing over PW Encapsulations >>> >>> In order for an LSR to process PTP messages, the top label of the >>> label stack (the Tunnel Label) MUST be a Timing label. >>> >>> S> You said that before. >>> >>> 6.3. Other Timing Encapsulation methods >>> >>> In future other timing encapsulation methods may be introduced, such >>> as a new shim header after the Bottom of Stack to carry the Timing >>> information. Such new encapsulations are outside the scope of this >>> document. >>> >>> >>> SB> Taking a pure MPLS pov, you can simplify a lot of the text >>> SB> out of the definition of the LSP >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 14] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> SB> I think we need a section on LSP processing >>> >>> 7. Timing message Processing >>> >>> Each Timing protocol such as PTP and NTP, define their set of Timing >>> messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, >>> FOLLOW_UP, etc messages. >>> >>> Some of the Timing messages require time stamping or correction field >>> update at port level and some dont. It is the job of the LER/LSR to >>> parse the timing message and find out the type of the Timing message >>> and decide whether and how to Time- stamp it (e.g., BC) or update >>> correction field(e.g., TC). >>> >>> >>> SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing >>> SB> function rather than the LER? >>> >>> For example the following PTP messages (called Event messages) >>> require time-stamping or correction field update: >>> >>> o SYNC >>> >>> o DELAY_REQ (Delay Request) >>> >>> o PDELAY_REQ (Peer Delay Request) >>> >>> o PDELAY_RESP (Peer Delay Response) >>> >>> SYNC and DELAY_REQ are exchanged between Master Clock and Slave Clock >>> and MUST be transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP >>> are exchanged between adjacent PTP clocks (i.e. Master, Slave, >>> Boundary, or Transparent) and SHOULD be transported over single hop >>> PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP, >>> and PDELAY_RESP_FOLLOW_UP messages MUST also be transported over >>> the >>> PTP LSPs. >>> >>> For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be >>> transported over two PTP LSPs that are in opposite directions. These >>> PTP LSPs, which are in opposite directions MUST be congruent and co- >>> routed. Alternatively, a single bidirectional co-routed LSP can be >>> used. >>> >>> Except as indicated above for the two-step PTP clocks, Non-Event PTP >>> message types do not need to be processed by intermediate routers. >>> These message types MAY be carried in PTP Tunnel LSPs. >>> >>> SB> Are you saying that a timing P router has to be msg type sensitive? >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 15] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 8. Protection and Redundancy >>> >>> >>> SB> This is a bit of a jump - I don't know how the LSP itself works yet! >>> >>> In order to ensure continuous uninterrupted operation of slave >>> clocks, usually as a general practice, slave clocks (or ports) track >>> redundant master clocks. >>> >>> It is the responsibility of the network operator to ensure that >>> physically disjoint Timing LSPs are established between a slave clock >>> (or port) and redundant master clocks (or ports). >>> >>> When a slave clock (or port) listens to redundant master clocks or >>> ports, any prolonged Timing LSP outage will trigger the slave clock >>> or port to switch to a redundant master clock or port. >>> >>> LSP/PW protection such as Linear protection Switching (1:1, 1+1), >>> Ring protection switching or MPLS Fast Reroute (FRR) generally switch >>> alternative path that usually cause a change in delay, which if >>> undetected by slave clock can reduce accuracy of the slave clock. >>> >>> Therefore protection switching MAY be used, as long as phase jumps >>> upon switchover due to differences in path latency are detected and >>> compensated for (such compensation not being required if BCs or peer- >>> peer TCs are used throughout). >>> >>> Note that any protection or reroute mechanism that adds additional >>> MPLS label to the label stack, such as Facility Backup Fast Reroute, >>> MUST ensure that the pushed label is also a Timing Label to ensure >>> recognition of the MPLS frame as containing Timing messages, as it >>> transits the backup path. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 16] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 9. ECMP >>> >>> To ensure the optimal operation of slave clocks and avoid error >>> introduced by forward and reverse path delay asymmetry, the physical >>> path for Timing messages from master clock to slave Clock and vice >>> versa must be the same for all Event Timing messages listed in >>> section 7. >>> >>> Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost >>> Multipath). >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 17] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 10. PHP >>> >>> To ensure that the label on the top of the label stack is the Timing >>> LSP Label, PHP MUST not be used. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 18] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 11. Entropy >>> >>> To ensure all Timing messages in a Timing LSP take the same path, >>> Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and >>> Entropy Label MUST NOT be used for the PWs that are carried inside >>> Timing LSP [RFC6391]. >>> >>> SB> This is incorrect - you mean that all msgs of the same timing >>> SB> flow need to have the same EL value. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 19] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 12. OAM, Control and Management >>> >>> In order to monitor Timing LSPs and their encapsulated PWs, they MUST >>> be able to carry OAM and management messages. These management >>> messages MUST be differentiated from Timing messages via already >>> defined IETF methods. >>> >>> For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY run >>> over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These >>> Management protocols can easily be identified by the UDP Destination >>> Port number or by GAL/G-ACH respectively. >>> >>> Also BFD, LSP-Ping and other management messages MAY run over the PWs >>> encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3 or >>> 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is going >>> to be deprecated by IETF). In this case G-ACH, PW label (TTL=1) or >>> GAL-ACH are used to identify such management messages. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 20] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 13. QoS Considerations >>> >>> In network deployments where not every LSR/LER is Timing-aware, it is >>> important to reduce the impact of the non-Timing-aware LSR/LERs on >>> the timing recovery in the slave clock. The Timing messages are time >>> critical and must be treated with the highest priority. Therefore >>> Timing over MPLS messages must be treated with the highest priority >>> in the routers. This can be achieved by proper setup of Timing LSPs. >>> >>> It is recommended that the Timing LSPs are setup or configured >>> properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC2697] >>> for drop eligibility. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 21] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 14. FCS and Checksum Recalculation >>> >>> When time-stamp generation and timing packet adjustment is performed >>> near the physical port hardware, the process MUST include >>> recalculation of the Ethernet FCS. >>> >>> SB> The above is confusing - an LSR always recomputes the link layer >>> SB> CRC which may or may not be Ethernet. >>> >>> Also FCS retention for the >>> payload Ethernet described in [RFC4720] MUST NOT be used. >>> >>> For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum >>> may be required as per UDP transport standards. >>> >>> SB> You really need to be working on getting the IPv6 C?S computation >>> SB> removed from PTP msgs. >>> >>> When UDP checksum is used, each Timing-aware LER/LSR must either >>> incrementally update the UDP checksum after Time stamping or >>> Correction Field update or verify the UDP checksum on reception from >>> upstream and recalculate the checksum completely on transmission to >>> downstream node after Time stamping or Correction Field update. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 22] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 15. Behavior of LER/LSR >>> >>> Timing-capable/aware LERs and LSRs are routers that have one or more >>> >>> SB> You mean physical interfaces? >>> >>> interfaces that can perform Timing operations (OC/BC/TC) on Timing >>> packets and are configured to do so. Timing-capable/aware LERs and >>> LSRs can advertise their Timing-capability per-interface via control >>> plane such as OSPF or IS-IS. >>> SB> ISIS and OSPF are routing protocols. >>> >>> The Timing-capable/aware LERs can then >>> signals Timing LSPs via RSVP-TE signaling. Alternatively the Timing >>> capability of LER and LSRs may be configured in a centralized >>> controller and the Timing LSP may be setup using manual configuration >>> or other methods such as SDN. >>> >>> SB> it can also be configured individually rather then through >>> SB> a cebtral controllwe >>> >>> 15.1. Behavior of Timing-capable/aware LER >>> >>> When a Timing-capable/aware LER behaves as a Transparent clock and >>> receives a Timing message from a Timing-capable/aware non-MPLS >>> interface, the LER updates the Correction Field (CF) and encapsulates >>> and forwards the timing message over previously established Timing >>> LSP. >>> >>> SB> You need to call out the details so that people properly >>> SB> understand the definition of the new LSP. >>> >>> Also when a Timing message is received from a Timing-capable/ >>> aware MPLS interface, LER updates the Correction Filed (CF) and >>> decapsulates the MPLS encapsulation and forwards the timing message >>> to a non-MPLS interface. >>> >>> When a Timing-capable/aware LER behaves as a Boundary clock and >>> receives a Timing message from a Timing-capable/aware non MPLS >>> interface, the LER Timestamps the Timing packet and sends it to the >>> LERs Boundary clock processing module. Also when a Timing message is >>> received from a Timing- capable/aware MPLS interface, the LER >>> Timestamps the Timing packet and sends it to the LERs Boundary clock >>> processing module. >>> >>> When a Timing-capable/aware LER behaves as an Ordinary Clock toward >>> the MPLS network, and receives a Timing message from a Timing- >>> capable/aware MPLS interface, the LER Timestamps the Timing packet >>> and sends it to the LERs Ordinary clock processing module. >>> >>> 15.2. Behavior of Timing-capable/aware LSR >>> >>> When a Timing-capable/aware LSR behaves as a Transparent clock and >>> receives a Timing message from a Timing-capable/aware MPLS interface, >>> The LSR updates the Correction Filed (CF) and forwards the timing >>> message over another MPLS interface. >>> >>> When a Timing-capable/aware LSR behaves as a Boundary clock and >>> receives a Timing message from a Timing-capable/aware MPLS interface. >>> The LSR performs the functions of a Boundary Clock in terminating the >>> received Timing message and re-generating a new timing message over >>> another (or the same) MPLS interface. >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 23] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 15.3. Behavior of non-Timing-capable/aware LSR >>> >>> It is most beneficial when all LSRs in the path of a Timing LSP be >>> timing-Capable/aware LSRs. This would ensure the highest quality >>> time and clock synchronization by Timing Slave Clocks. However, this >>> specification does not mandate that all LSRs in path of a Timing LSP >>> be Timing- capable/aware. >>> >>> Non-Timing-capable/aware LSRs just switch the packets encapsulated in >>> Timing LSPs and dont perform any Timing operation (TC or BC). >>> However as explained in QoS section the Timing over MPLS packets MUST >>> be still be treated with the highest priority based on their Traffic >>> Class (TC) marking. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 24] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 16. Other considerations >>> >>> [IEEE-1588] defines an optional peer-to-peer Transparent clocking >>> that requires peer delay measurement between two adjacent Timing- >>> capable/ aware routers/switches. Peer delay measurement messages >>> need to be time stamped and terminated by the Timing-capable/aware >>> routers/ switches. This means that two adjacent LSRs may be engaged >>> in a peer delay measurement. >>> >>> For transporting such peer delay measurement messages a single-hop >>> LSP SHOULD to be created between the two adjacent LSRs engaged in >>> peer delay measurement to carry peer delay measurement messages. >>> Other methods such as PTP transport over Ethernet MAY be used for >>> transporting peer delay measurement messages if the link between the >>> two routers is Ethernet. >>> >>> In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ ware >>> routers/switches MUST maintain a list of all the neighbors it needs >>> to send a PDelay_Req to, where each neighbor corresponds to a timing >>> LSP. >>> >>> The use of Explicit Null Label (Label= 0 or 2) is acceptable as long >>> as either the Explicit Null label is the bottom of stack label >>> (applicable only to UDP/IP encapsulation) or the label below the >>> Explicit Null label is a PTP label. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 25] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 17. Security Considerations >>> >>> MPLS PW security considerations in general are discussed in [RFC3985] >>> and [RFC4447],and those considerations also apply to this document. >>> >>> An experimental security protocol is defined in [IEEE-1588].The PTP >>> security extension and protocol provides group source authentication, >>> message integrity, and replay attack protection for PTP messages. >>> >>> When the MPLS network (provider network) serves multiple customers, >>> it is important to maintain and process each customers clock and >>> Timing messages separately from other customers to ensure there is no >>> cross- customer effect. For example if an LER BC is synchronized to >>> a specific grandmaster, belonging to customer A, then the LER MUST >>> use that BC clock only for customer A to ensure that customer A >>> cannot attack other customers by manipulating its time. >>> >>> Timing messages MAY be encrypted or authenticated, provided that the >>> LERs/LSRs that are Timing capable/aware can authenticate/ decrypt the >>> timing messages. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 26] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 18. Acknowledgements >>> >>> The authors would like to thank Ron Cohen, Yaakov Stein, Tal Mizrahi, >>> Stefano Ruffini, Peter Meyer, and other members of IETF for reviewing >>> and providing feedback on this draft. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 27] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 19. IANA Considerations >>> >>> There are no IANA requirements in this specification. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 28] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 20. References >>> >>> 20.1. Normative References >>> >>> [IEEE-1588] >>> IEEE 1588-2008, "IEEE Standard for a Precision Clock >>> Synchronization Protocol for Networked Measurement and >>> Control Systems". >>> >>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >>> Requirement Levels", BCP 14, RFC 2119, March 1997. >>> >>> [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- >>> Edge (PWE3) Architecture", RFC 3985, March 2005. >>> >>> [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery >>> Proxies (ND Proxy)", RFC 4389, April 2006. >>> >>> [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. >>> Heron, "Pseudowire Setup and Maintenance Using the Label >>> Distribution Protocol (LDP)", RFC 4447, April 2006. >>> >>> [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, >>> "Encapsulation Methods for Transport of Ethernet over MPLS >>> Networks", RFC 4448, April 2006. >>> >>> [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire >>> Emulation Edge-to-Edge (PWE3) Frame Check Sequence >>> Retention", RFC 4720, November 2006. >>> >>> [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit >>> Connectivity Verification (VCCV): A Control Channel for >>> Pseudowires", RFC 5085, December 2007. >>> >>> [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection >>> (BFD)", RFC 5880, June 2010. >>> >>> [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, >>> "Bidirectional Forwarding Detection (BFD) for MPLS Label >>> Switched Paths (LSPs)", RFC 5884, June 2010. >>> >>> 20.2. Informative References >>> >>> [I-D.ietf-pwe3-fat-pw] >>> Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, >>> J., and S. Amante, "Flow Aware Transport of Pseudowires >>> over an MPLS Packet Switched Network", >>> draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011. >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 29] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate >>> system routeing information exchange protocol for use in >>> conjunction with the Protocol for providing the >>> Connectionless-mode Network Service (ISO 8473)". >>> >>> [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and >>> dual environments", RFC 1195, December 1990. >>> >>> [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. >>> >>> [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color >>> Marker", RFC 2697, September 1999. >>> >>> [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, >>> J., Courtney, W., Davari, S., Firoiu, V., and D. >>> Stiliadis, "An Expedited Forwarding PHB (Per-Hop >>> Behavior)", RFC 3246, March 2002. >>> >>> [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering >>> (TE) Extensions to OSPF Version 2", RFC 3630, >>> September 2003. >>> >>> [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate >>> System (IS-IS) Extensions for Traffic Engineering (TE)", >>> RFC 3784, June 2004. >>> >>> [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. >>> Shaffer, "Extensions to OSPF for Advertising Optional >>> Router Capabilities", RFC 4970, July 2007. >>> >>> [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate >>> System to Intermediate System (IS-IS) Extensions for >>> Advertising Router Information", RFC 4971, July 2007. >>> >>> [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi >>> Topology (MT) Routing in Intermediate System to >>> Intermediate Systems (IS-ISs)", RFC 5120, February 2008. >>> >>> [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic >>> Engineering", RFC 5305, October 2008. >>> >>> [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, >>> "Traffic Engineering Extensions to OSPF Version 3", >>> RFC 5329, September 2008. >>> >>> [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF >>> for IPv6", RFC 5340, July 2008. >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 30] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network >>> Time Protocol Version 4: Protocol and Algorithms >>> Specification", RFC 5905, June 2010. >>> >>> [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, >>> J., and S. Amante, "Flow-Aware Transport of Pseudowires >>> over an MPLS Packet Switched Network", RFC 6391, >>> November 2011. >>> >>> [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and >>> L. Yong, "The Use of Entropy Labels in MPLS Forwarding", >>> RFC 6790, November 2012. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 31] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 1. Routing extensions for Timing-aware Routers >>> >>> MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and >>> IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE) >>> link information used for constraint-based routing. >>> >>> Indeed, it is useful to advertise data plane TE router link >>> capabilities, such as the capability for a router to be Timing-aware. >>> This capability MUST then be taken into account during path >>> computation to prefer or even require links that advertise themselves >>> as Timing-aware. In this way the path can ensure the entry and exit >>> points into the LERs and, if desired, the links into the LSRs are >>> able to perform port based time-stamping thus minimizing their impact >>> on the performance of the slave clock. >>> >>> extensions are required to OSPF and IS-IS in order to advertise >>> Timing-aware capabilities of a link. Such extensions are outside the >>> scope of this document; however such extension SHOULD be able to >>> signal the following information per Router Link: >>> >>> o Capable of processing PTP, NTP or other Timing flows >>> >>> o Capable of performing Transparent Clock operation >>> >>> o Capable of performing Boundary Clock operation >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 32] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> 2. Signaling Extensions for Creating Timing LSPs >>> >>> RSVP-TE signaling MAY be used to setup the timing LSPs. When RSVP-TE >>> is used to setup Timing LSPs, some information that indicates that >>> the LSP is carrying Timing flows MUST be included in the new >>> Extensions to RSVP-TE: >>> >>> The following information MAY also be included in the new Extensions >>> to RSVP-TE: >>> >>> o Offset from Bottom of Stack (BoS) to the start of the Time-stamp >>> field >>> >>> o Number of VLANs in case of PW encapsulation >>> >>> o Timestamp field Type >>> >>> * Correction Field, Timestamp >>> >>> o Timestamp Field format >>> >>> * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit >>> NTP, etc. >>> >>> Note that in case the above optional information is signaled with >>> RSVP-TE for a Timing LSP, all the Timing packets carried in that LSP >>> must have the same signaled characteristics. For example if >>> Timestamp format is signaled as 64-bit PTPv1, then all Timing packets >>> must use 64-bit PTPv1 time-stamp. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 33] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> Authors' Addresses >>> >>> Shahram Davari >>> Broadcom Corp. >>> San Jose, CA 95134 >>> USA >>> >>> Email: davari@broadcom.com >>> >>> >>> Amit Oren >>> Broadcom Corp. >>> San Jose, CA 95134 >>> USA >>> >>> Email: amito@broadcom.com >>> >>> >>> Manav Bhatia >>> Alcatel-Lucent >>> Bangalore, >>> India >>> >>> Email: manav.bhatia@alcatel-lucent.com >>> >>> >>> Peter Roberts >>> Alcatel-Lucent >>> Kanata, >>> Canada >>> >>> Email: peter.roberts@alcatel-lucent.com >>> >>> >>> Laurent Montini >>> Cisco Systems >>> San Jose CA >>> USA >>> >>> Email: lmontini@cisco.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 34] >>> Internet-Draft Transporting Timing over MPLS June 2013 >>> >>> >>> Luca >>> Cisco Systems >>> San Jose CA >>> USA >>> >>> Email: lmartini@cisco.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 35] >>> -- >>> For corporate legal information go to: >>> >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>> >>> _______________________________________________ >>> TICTOC mailing list >>> TICTOC@ietf.org >>> https://www.ietf.org/mailman/listinfo/tictoc >> >> 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 > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From internet-drafts@ietf.org Mon Aug 5 07:42:33 2013 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 6AD0821F9F50; Mon, 5 Aug 2013 07:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, 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 7994AJ7kpB-I; Mon, 5 Aug 2013 07:42:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C95321F9E21; Mon, 5 Aug 2013 07:42:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130805144226.7628.68757.idtracker@ietfa.amsl.com> Date: Mon, 05 Aug 2013 07:42:26 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-relay-reply-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, 05 Aug 2013 14:42: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 Gro= up of the IETF. Title : Relayed Echo Reply mechanism for LSP Ping Author(s) : Jian Luo Lizhong Jin Thomas Nadeau George Swallow Filename : draft-ietf-mpls-lsp-ping-relay-reply-01.txt Pages : 15 Date : 2013-08-05 Abstract: In some inter-AS and inter-area deployment scenarios for LSP Ping and Traceroute, a replying LSR may not have the available route to the initiator, and the Echo Reply message sent to the initiator would be discarded resulting in false negatives or complete failure of operation of LSP Ping and Traceroute. This document describes extensions to LSP Ping mechanism to enable the replying LSR to have the capability to relay the echo response by a set of routable intermediate nodes to the initiator during the traceroute process in inter-AS and inter-area scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-relay-reply There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-relay-reply-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-lsp-ping-relay-reply-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From davari@broadcom.com Mon Aug 5 13:29:40 2013 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 729F321F8421; Mon, 5 Aug 2013 13:29:40 -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 HiLtiy-VpSMx; Mon, 5 Aug 2013 13:29:27 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8335921F9F2D; Mon, 5 Aug 2013 13:29:26 -0700 (PDT) Received: from [10.9.208.53] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Mon, 05 Aug 2013 13:25:27 -0700 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from SJEXCHCAS07.corp.ad.broadcom.com (10.16.203.16) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.1.438.0; Mon, 5 Aug 2013 13:29:17 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS07.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Mon, 5 Aug 2013 13:29:16 -0700 From: "Shahram Davari" To: "stbryant@cisco.com" , "S. Davari" Thread-Topic: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls Thread-Index: AQHOkPa4jpilABu4V0eu/dc/FPmvd5mGz+gAgABBHaA= Date: Mon, 5 Aug 2013 20:29:16 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F281BEC731A@SJEXCHMB12.corp.ad.broadcom.com> References: <51FB7543.801@cisco.com> <51FF7068.9080600@cisco.com> In-Reply-To: <51FF7068.9080600@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7E1ED5BD31W80904505-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] Comments on draft-ietf-tictoc-1588overmpls 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, 05 Aug 2013 20:29:40 -0000 Hi Stewart, Your suggestion of " I suggested an LSP type that has the properties "times= tamp and pass to application", is a subset of the existing draft and should= work. It basically limits the time stamping and correction field update to= LERs (while the draft supports time stamping at LER and LSR). However Sasha's suggestion of using a reserved label (RAL, GAL or any other= reserved label) does not satisfy one of the major requirements, which is b= ackward compatibility. Routers that don't understand this reserved label wi= ll drop or copy to CPU such packets.=20 Regards, Shahram -----Original Message----- From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of= Stewart Bryant Sent: Monday, August 05, 2013 2:29 AM To: S. Davari Cc: mpls@ietf.org; tictoc@ietf.org Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls My concern is that we are creating a new LSP type in MPLS (which is a architectural change and thus needs to be very carefully considered) without asking the question "how can I do this in the most general way, to maximize flexibility/reuse" I suggested an LSP type that has the properties "timestamp and pass to application", but I think that Sasha raises a good point about using router alert. However RA has no implicit timestamp, so maybe we need a new type of RA that has the properties "timestamp, and pass top application indicated by the next label". That would be quite useful in a number of OAM applications. There is possibly some GAL variant of that design that should also be considered. The application could worry about the path and where it was necessary to skip some hops a hierarchical LSP would accomplish that, with the specific benefit that the application would consciously do this, and may be able to apply some form of compensation within the network. - Stewart On 04/08/2013 10:40, S. Davari wrote: > Hi Sasha > > Perhaps you have not understood the draft well. The main reason that the = draft chose to use a dedicated LSP that is signaled via RSVPTE indicating i= t is a timing LSP is to be backward compatible with non-1588 nodes. Such no= des simply just switch the packet. > > Your proposal had been considered and was rejected since it was not backw= ard compatible. Nodes receiving alert label or TTL =3D 1 send the packet to= CPU. You can refer to the meeting notes. > > Regards, > Shahram > > > On Aug 4, 2013, at 1:21 AM, Alexander Vainshtein wrote: > >> Stewart and all, >> I concur with Stewart's statement that the draft does not define "full i= nteraction with MPLS architecture". >> >> E.g., one of the objectives of the draft is to provide a technique that = would be backward-compatible with old LSRs that cannot provide on-path supp= ort for timing distribution, while the other objective is to make every LSR= on the path aware that some MPLS packets are carrying timing-related messa= ges and hence require on-path support. >> >> IMHO and FWIW, the MPLS data plane architecture allows just two methods = for making a transit LSR to provide special processing to a labeled packet: >> - It would carry some kind of an "alert label" on top of the label stack= and, specifically, on top of any labels used for actual forwarding >> OR, >> - The TTL in the top label stack entry has been set to 1. >> >> >> The draft does not follow any of these approaches. >> >> I must also admit that Section 12 "OAM, Control and Management" of the d= raft looks somewhat in >> E.g., I could not understand from the text whether BFD, LSP-Ping etc. OA= M messages would be subjected to on-path support procedures for timing mess= ages or not. >> >> My 2c, >> Sasha >> >>> -----Original Message----- >>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behal= f Of >>> Stewart Bryant >>> Sent: Friday, August 02, 2013 12:01 PM >>> To: mpls-chairs@tools.ietf.org; tictoc-chairs@tools.ietf.org; int- >>> ads@tools.ietf.org; rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.org;= draft- >>> ietf-tictoc-1588overmpls@tools.ietf.org >>> Cc: mpls@ietf.org; tictoc@ietf.org >>> Subject: [TICTOC] Comments on draft-ietf-tictoc-1588overmpls >>> >>> SB> This draft does not seem to provide a precise definition >>> SB> the properties of the new LSP type that it wishes to >>> SB> define, in particular it does it define the PHB of those >>> SB> LSPs, nor the full interaction with the MPLS >>> SB> architecture. >>> SB> >>> SB> I have not tracked TICTOC for a while but I thought that >>> SB> the original plan was to define the concept of an offset >>> SB> into a packet to do the correction. >>> SB> >>> SB> It is disappointing that the opportunity was not taken >>> SB> to define a timing shim inside the timing LSP so that >>> SB> a time correction could be added to any packet such that >>> SB> the MPLS system was isolated from the details of the >>> SB> complexity of the particular time transfer type. >>> >>> SB> I think that much more clarify is needed in terms of >>> SB> definition of the new LSP type, since it is unclear >>> SB> from this text how to implement one. >>> SB> >>> SB> There are a lot of other MPLS services such as >>> SB> LSP ping that need to be considered. >>> SB> >>> SB> Please see inline for more comments. However these >>> SB> comments are made in the context of the text as written >>> SB> whilst I have a fundamental concern that this approach >>> SB> lacks an MPLS architectural soundness that need >>> SB> greater thought with significant impact on the >>> SB> draft. >>> >>> - Stewart >>> >>> >>> TICTOC Working Group S. Davar= i >>> Internet-Draft A. Ore= n >>> Intended status: Standards Track Broadcom Corp= . >>> Expires: December 17, 2013 M. Bhati= a >>> P. Rober= ts >>> Alcatel-Luce= nt >>> L. Monti= ni >>> L. Marti= ni >>> Cisco Syste= ms >>> June 15, 20= 13 >>> >>> >>> Transporting Timing messages over MPLS Networks >>> draft-ietf-tictoc-1588overmpls-05 >>> >>> Abstract >>> >>> This document defines the method for transporting Timing messages >>> such as PTP and NTP over an MPLS network. The method allows for th= e >>> easy identification of these PDUs at the port level to allow for po= rt >>> >>> SB> What is a port >>> >>> level processing of these PDUs in both LERs and LSRs. >>> >>> The basic idea is to transport Timing messages inside dedicated MPL= S >>> LSPs. These LSPs only carry Timing messages and possibly Control a= nd >>> Management packets, but they do not carry customer traffic. >>> >>> SB> More specifically they only carry traffic associated with the >>> SB> timing service and its support. >>> SB> The question arose WRT BFD - surely BFD is allowed, BUT surely >>> SB> also it gets carried in a structure that causes it to get >>> SB> timestamped. >>> >>> Two methods for transporting Timing messages over MPLS are defined. >>> >>> SB> Perhaps the right approach is to define the new LSP type and then >>> SB> seperately to define the mapping of the various timing services >>> SB> over that LSP type. >>> >>> The first method is to transport Timing messages directly over the >>> dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for >>> MPLS networks. The second method is to transport Timing messages >>> inside a PW via Ethernet encapsulation. >>> >>> SB> I think that we should note that there are some >>> SB> h/w reasons for this preference. A clean sheet approach >>> SB> would have been to use PTP over MPLS with no intermediate >>> SB> layers. >>> >>> Status of this Memo >>> >>> This Internet-Draft is submitted in full conformance with the >>> provisions of BCP 78 and BCP 79. >>> >>> Internet-Drafts are working documents of the Internet Engineering >>> Task Force (IETF). Note that other groups may also distribute >>> working documents as Internet-Drafts. The list of current Internet= - >>> Drafts is at http://datatracker.ietf.org/drafts/current/. >>> >>> Internet-Drafts are draft documents valid for a maximum of six mont= hs >>> and may be updated, replaced, or obsoleted by other documents at an= y >>> time. It is inappropriate to use Internet-Drafts as reference >>> material or to cite them other than as "work in progress." >>> >>> This Internet-Draft will expire on December 17, 2013. >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 1= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> Copyright Notice >>> >>> Copyright (c) 2013 IETF Trust and the persons identified as the >>> document authors. All rights reserved. >>> >>> This document is subject to BCP 78 and the IETF Trust's Legal >>> Provisions Relating to IETF Documents >>> (http://trustee.ietf.org/license-info) in effect on the date of >>> publication of this document. Please review these documents >>> carefully, as they describe your rights and restrictions with respe= ct >>> to this document. Code Components extracted from this document mus= t >>> include Simplified BSD License text as described in Section 4.e of >>> the Trust Legal Provisions and are provided without warranty as >>> described in the Simplified BSD License. >>> >>> >>> Table of Contents >>> >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 5 >>> >>> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . = 7 >>> >>> 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . = 8 >>> >>> 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . = 9 >>> >>> 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . . = 12 >>> >>> 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . = 13 >>> 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . . = 13 >>> 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . . = 13 >>> 6.3. Other Timing Encapsulation methods . . . . . . . . . . . . = 14 >>> >>> 7. Timing message Processing . . . . . . . . . . . . . . . . . . = 15 >>> >>> 8. Protection and Redundancy . . . . . . . . . . . . . . . . . . = 16 >>> >>> 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . = 17 >>> >>> 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . = 18 >>> >>> 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . = 19 >>> >>> 12. OAM, Control and Management . . . . . . . . . . . . . . . . . = 20 >>> >>> 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . = 21 >>> >>> 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . . = 22 >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 2= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . = 23 >>> 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . . = 23 >>> 15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . . = 23 >>> 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . . = 24 >>> >>> 16. Other considerations . . . . . . . . . . . . . . . . . . . . . = 25 >>> >>> 17. Security Considerations . . . . . . . . . . . . . . . . . . . = 26 >>> >>> 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . = 27 >>> >>> 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 28 >>> >>> 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . = 29 >>> 20.1. Normative References . . . . . . . . . . . . . . . . . . . = 29 >>> 20.2. Informative References . . . . . . . . . . . . . . . . . . = 29 >>> >>> Appendix 1. Routing extensions for Timing-aware Routers . . . . . = 32 >>> >>> Appendix 2. Signaling Extensions for Creating Timing LSPs . . . . = 33 >>> >>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . = 34 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 3= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in >>> this >>> document are to be interpreted as described in RFC2119 [RFC2119]. >>> >>> When used in lower case, these words convey their typical use in >>> common language, and are not to be interpreted as described in >>> RFC2119 [RFC2119]. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 4= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 1. Introduction >>> >>> The objective of Precision Time Protocol (PTP) and Network Timing >>> Protocol (NTP) are to synchronize independent clocks running on >>> separate nodes of a distributed system. >>> >>> [IEEE-1588] defines PTP messages for frequency, phase and time >>> synchronization. The PTP messages include PTP PDUs over UDP/IP >>> (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex F = of >>> [IEEE-1588]). >>> >>> SB> Sure BUT it is acknowledged that IEEE is open to the definition >>> SB> of other PTP mappings if they provide better optimisation. >>> >>> This document defines mapping and transport of the PTP >>> messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP >>> defines several clock types: ordinary clocks, boundary clocks, end- >>> to-end transparent clocks, and peer-to-peer transparent clocks. >>> Transparent clocks require intermediate nodes to update correction >>> field inside PTP message that reflects the transit time in the node= . >>> >>> [RFC5905] defines NTP messages for clock and time synchronization. >>> The PTP messages (PDUs) are transported over UDP/IP. This document >>> SB> Should that be NTP messages? >>> SB> It needs to be made clear as soon as you introduce NTP that >>> SB> they use different time representations. >>> >>> defines mapping and transport of the NTP messages defined in >>> [RFC5905] over MPLS networks. >>> >>> One key attribute of all of these Timing messages is that the Time >>> stamp processing should occur as close as possible to the actual >>> transmission and reception at the physical port interface. This >>> targets optimal time and/or frequency recovery by avoiding variable >>> delay introduced by queues internal to the clocks. >>> >>> SB> As I recall NTP has no epoch point defined, and I am not sure >>> SB> where that point is in the case of PTP in this mapping >>> SB> Hopefully this will get defined in due course. >>> >>> To facilitate the fast and efficient recognition of Timing messages >>> at the port level when the Timing messages are carried over MPLS >>> LSPs, >>> >>> SB> Over a new LSP type with time optimied characteristics >>> >>> this document defines the specific encapsulations that should >>> be used. >>> SB> Hopefully it will also define the PHP >>> >>> In addition, it can be expected that there will exist LSR/ >>> LERs where only a subset of the physical ports will have the port- >>> based Timing message processing capabilities. >>> SB> Do you need to clarify that this only works at base and not in >>> SB> a label heirarchy. >>> >>> >>> In order to ensure >>> that the LSPs carrying Timing packets always enter and exit ports >>> with this capability, routing extensions are defined to advertise >>> this capability on a port basis and to allow for the establishment = of >>> LSPs that only transit such ports. While this path establishment >>> restriction may be applied only at the LER Ingress and/or egress >>> ports, it becomes more important when using transparent clock capab= le >>> LSRs in the path. >>> SB> I do not understand the implications of the last >>> SB> sentences - starting ", it becomes" >>> >>> >>> Port based Timing message processing involves Timing message >>> recognition. Once the Timing messages are recognized they can be >>> modified based on the reception or transmission Time-stamp. >>> >>> This document provides two methods for transporting Timing messages >>> over MPLS. One is applicable to MPLS environment and the other one >>> is applicable to MPLS/MPLS-TP environment >>> >>> SB> I think the sentence is incomplete. >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 5= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> The solution involves transporting Timing messages over dedicated >>> LSPs called Timing LSPs. These LSPs carry Timing messages and MAY >>> carry Management and control messages, but not data plane client >>> traffic. >>> >>> SB> It is not clear why this restriction applies. >>> >>> Timing LSPs can be established statically or via signaling. >>> SB> s/statically/by provisioning/network management/ >>> >>> Extensions to control plane (OSPF, ISIS, etc.) is required to enabl= e >>> routers to distribute their Timing processing capabilities over MPL= S >>> to other routers. However such extensions are outside the scope of >>> this document. >>> >>> When signaling is used to setup the PTP LSP, Extensions to signalin= g >>> SB> is it a PTP LSP or a Timing LSP? >>> >>> protocols (e.g., RSVP-TE) are required for establishing PTP LSPs. >>> However such extensions are outside the scope of this document. >>> >>> SB> for mpls-tp GMPLS is the signalling protocol >>> >>> While the techniques included herein allow for the establishment of >>> paths optimized to include Time-stamping capable links, the >>> performance of the Slave clocks is outside the scope of this >>> document. >>> >>> At the time of publishing this specification, Transparent Clocking >>> (TC) is only defined for PTP. Therefore at this time any part of >>> this specification that talks about Transparent Clocking applies on= ly >>> to PTP. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 6= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 2. Terminology >>> >>> 1588: The timing and synchronization as defined by IEEE 1588. >>> >>> SB> I think that there is a more formal name for the 1588 group >>> SB> that needs to be used here. >>> SB> Also do we need to talk about 1588-200? as there is >>> SB> an update in progress >>> >>> NTP: The timing and synchronization protocol defined by IETF RFC-13= 05 >>> and RFC-5905. >>> >>> PTP: The timing and synchronization protocol used by 1588. >>> SB> need the proper name for 1588 >>> >>> Master Clock: The source of 1588 timing to a set of slave clocks. >>> >>> Master Port: A port on a ordinary or boundary clock that is in Mast= er >>> state. This is the source of timing toward slave ports. >>> >>> SB> I am not sure the reader knows what a port is >>> >>> Slave Clock: A receiver of 1588 timing from a master clock. >>> >>> Slave Port: A port on a boundary clock or ordinary clock that is >>> receiving timing from a master clock. >>> >>> Ordinary Clock: A device with a single PTP port. >>> >>> Transparent Clock. A device that measures the time taken for a PTP >>> event message to transit the device and then updates the >>> correctionField of the message with this transit time. >>> >>> Boundary Clock: A device with more than one PTP port. Generally >>> boundary clocks will have one port in slave state to receive timing >>> and then other ports in master state to re-distribute the timing. >>> >>> PTP LSP: An LSP dedicated to carry PTP messages >>> >>> SB> PTP or timing? >>> >>> >>> PTP PW: A PW within a PTP LSP that is dedicated to carry PTP >>> messages. >>> >>> SB> Ah I don't think that PWE3 know what one of these is >>> >>> CW: Pseudowire Control Word >>> >>> LAG: Link Aggregation >>> >>> ECMP: Equal Cost Multipath >>> >>> CF: Correction Field, a field inside certain PTP messages (message >>> type 0-3)that holds the accumulative transit time inside intermedia= te >>> switches >>> >>> Timing messages: Timing Protocol messages that are exchanged betwee= n >>> routers in order to establish a synchronized clock. >>> >>> SB> A number of these definitions look like copies of IEEE1588 >>> SB> definitions. We need to provide references and note the >>> SB> priority of the IEEE base reference. >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 7= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 3. Problem Statement >>> >>> [IEEE-1588] has defined methods for transporting PTP messages over >>> Ethernet and IP networks. [RFC5905] has defined the method of >>> transporting NTP messages over IP networks. There is a need to >>> transport Timing messages over MPLS networks while supporting the >>> Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC) >>> functionality in the LER and LSRs in the MPLS network. >>> >>> There are multiple ways of transporting Timing over MPLS. However, >>> there is a requirement to limit the possible encapsulation options = to >>> simplify the Timing message identification and processing required = at >>> the port level. >>> >>> When Timing-awareness is needed, Timing messages should not be >>> transported over LSPs or PWs that are carrying customer traffic >>> because LSRs perform Label switching based on the top label in the >>> stack. >>> >>> SB> Have you explained why? >>> >>> To detect Timing messages inside such LSPs require special >>> hardware to do deep packet inspection at line rate. Even if such >>> hardware exists, the payload can't be deterministically identified = by >>> LSRs because the payload type is a context of the PW label, and the >>> PW label and its context are only known to the Edge routers (PEs/ >>> LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, CES= , >>> etc). Even if one restricts an LSP to only carry Ethernet PWs, the >>> LSRs dont have the knowledge of whether PW Control Word (CW) is >>> present or not and therefore can not deterministically identify the >>> payload. >>> >>> A generic method is defined in this document that does not require >>> deep packet inspection at line rate, and can deterministically >>> identify Timing messages. This method can be used to detect Timing >>> Messages in both one-step and two-step clock implementations of >>> ordinary, boundary and transparent clocks. >>> >>> SB> Needs a ref and I am sure many MPLS specialists will not understand >>> SB> the msg types. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 8= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 4. Timing over MPLS Architecture >>> >>> Timing messages are exchange between Timing ports on ordinary and >>> >>> SB> Have you defined a timing port? >>> >>> boundary clocks. Boundary clocks terminate the Timing messages and >>> act as master for other boundary clocks or for slave clocks. End-t= o- >>> End Transparent clocks do not terminate the Timing messages but the= y >>> do modify the contents of the Timing messages as they transit acros= s >>> the transparent clock. >>> >>> Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent Clo= ck >>> >>> (TC) could be implemented in either LERs or LSRs. >>> >>> SB> LER and LSR need to be expanded >>> >>> An example is shown in Figure 1, where the LERs act as Ordinary Clo= ck >>> (OC) and are the initiating/terminating point for Timing messages. >>> The ingress LER encapsulates the Timing messages in Timing LSP and >>> the Egress LER terminates the Timing LSP. The LSRs act as >>> Transparent Clock (TC) and just update the Timing field in the Timi= ng >>> messages. >>> >>> >>> +--------+ +-------+ +-------+ +-------+ +------= --+ >>> |Switch, | | | | | | | |Switch= , | >>> | Router |-----| LER |-----| LSR |-----| LER |-----| Route= r | >>> | | | OC | | TC | | OC | | = | >>> +--------+ +-------+ +-------+ +-------+ +------= --+ >>> / \ >>> +-------+ / \ +-------= + >>> | LER | / \ | LER = | >>> | Master|---/ \---| Slave = | >>> | Clock | | Clock = | >>> +-------+ +-------= + >>> >>> Figure (1) - Deployment example 1 of timing over MPLS network >>> >>> Another example is shown in Figure2, where LERs terminate the Timin= g >>> messages received from switch/routers that are outside of the MPLS >>> network acting as OC or BC. In this example LERs regenerate the >>> clock and initiate timing messages encapsulated in Timing LSP towar= d >>> the MPLS network, while the LSRs act as Transparent Clock (TC) and >>> just update the Timing field in the Timing messages, which are >>> already encapsulated in Timing LSPs. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 9= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> +--------+ +-------+ +-------+ +-------+ +-------= -+ >>> |Switch, | | | | | | | |Switch,= | >>> | Router |-----| LER |-----| LSR |-----| LER |-----| Router= | >>> | OC/BC | | BC | | TC | | BC | | OC/BC = | >>> +--------+ +-------+ +-------+ +-------+ +-------= -+ >>> >>> Figure (2) - Deployment example 2 of timing over MPLS network >>> >>> >>> Another example is shown in Figure 3, where LERs do not terminate t= he >>> Timing messages received from switch/routers that are outside of th= e >>> MPLS network acting as OC, TC or BC. The LERs act as TC and update >>> the Timing field in the Timing messages as they transit the LER, >>> while encapsulating them in timing LSP. The LSRs also act as >>> Transparent Clock (TC) and just update the Timing field in the Timi= ng >>> messages which are already encapsulated in Timing LSPs. >>> >>> +--------+ +-------+ +-------+ +-------+ +------= --+ >>> |Switch, | | | | | | | |Switch= , | >>> | Router |-----| LER |-----| LSR |-----| LER |-----| Route= r | >>> |OC/TC/BC| | TC | | TC | | TC | |OC/TC/= BC| >>> +--------+ +-------+ +-------+ +-------+ +------= --+ >>> >>> Figure (3) - Deployment example 3 of timing over MPLS network >>> >>> Another example is shown in Figure 4, where LERs and LSRs support >>> Boundary Clocks. A single-hop LSP is created between two adjacent >>> LSRs engaged in BC operation. Other methods such as PTP transport >>> over Ethernet MAY be used for transporting timing messages if the >>> link between the two routers is Ethernet. >>> >>> +--------+ +-------+ +-------+ +-------+ +-------= -+ >>> |Switch, | | | | | | | |Switch,= | >>> | Router |-----| LER |-----| LSR |-----| LER |-----| Router= | >>> | OC/BC | | BC | | BC | | BC | | OC/BC = | >>> +--------+ +-------+ +-------+ +-------+ +-------= -+ >>> >>> Figure (4) - Deployment example 3 of timing over MPLS network >>> >>> An MPLS domain MAY serve multiple customers. In these cases the MP= LS >>> domain (maintained by a service provider) may provide timing servic= es >>> to multiple customers, each having their own Timing domain. >>> >>> The Timing over MPLS architecture assumes full mesh of Timing LSPs >>> between all LERs supporting this specification. >>> >>> SB> Note sure this is right - the salves surely do not need to >>> SB> exchange timing amongst themselves >>> >>> It supports >>> Point-to- point (VPWS) and Multipoint (VPLS) services. >>> >>> SB> What does that mean? You do not carry user data traffic? >>> SB> Maybe it's the ordering of the statemnets that is causing >>> SB> confusion. >>> >>> This means >>> that a customer may purchase a Point-to-point Timing service betwee= n >>> two customer sites or a Multipoint Timing service between more than >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 10= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> two customer sites. >>> >>> The Timing over MPLS architecture supports P2P or P2MP Timing LSPs. >>> This means that the Timing Multicast messages such as PTP Multicast >>> event messages can be transported over P2MP Timing LSP or be >>> replicated and transported over many P2P Timing LSPs. >>> >>> SB> Note we do not yet have a definition of a P2MP mpls-tp LSP >>> SB> nor a P2MP PW, although we are close. >>> >>> Timing messages, that do not require Time stamping or Correction >>> Field update MAY be transported over Timing LSPs to simplify hardwa= re >>> and software. >>> >>> PTP Announce messages that determine the Timing LSP terminating poi= nt >>> behavior such as BC/OC/TC SHOULD be transported over the Timing LSP >>> to simplify hardware and software. >>> >>> SB> have you defined and referenced PTP announce msgs? >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 11= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 5. Dedicated LSPs for Timing messages >>> >>> Many methods have been considered for identifying the Timing messag= es >>> when they are encapsulated in MPLS such as using GAL/G-ACH or a new >>> reserved label. These methods were not attractive since they eithe= r >>> required deep packet inspection at line rate in the intermediate LS= Rs >>> or they required use of a scarce new reserved label. Also one of t= he >>> goals was to reuse existing OAM mechanisms. >>> >>> SB> RLs =3D SPLs are not so rare now. In any case needs a ref. >>> >>> The method defined in this document can be used by LER and LSRs to >>> identify Timing messages in MPLS tunnels by just looking at the top >>> label in the MPLS label stack, which only carry Timing messages as >>> well as OAM, but not data plane client traffic. >>> >>> Compliant implementations MUST use dedicated LSPs to carry Timing >>> messages over MPLS. >>> >>> SB> I think that we need a definition of the properies of these LSPs >>> >>> These LSPs are herein referred to as "Timing >>> LSPs" and the labels associated with these LSPs as "Timing LSP >>> labels". The Timing LSPs that runs between Ingress and Egress LERs >>> MUST be co-routed. Alternatively, a single bidirectional co-routed >>> LSP can be used. >>> >>> SB> I though that you said you could use M2MP LSPs - these are not >>> SB> bidirectional. >>> >>> Co-routing of the two directions is required to limit the differenc= e >>> in the delays in the Master clock to Slave clock direction compared >>> to the Slave clock to Master clock direction. The Timing LSP MAY b= e >>> MPLS/MPLS-TP LSP. >>> >>> The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS. >>> New Extensions to RSVP-TE/GMPLS TLVs are required; however they are >>> outside the scope of this document. >>> >>> The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such a= s >>> BFD and LSP Ping but the LSP data plane client plane traffic MUST b= e >>> Timing packets only. >>> >>> SB> Why? >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 12= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 6. Timing over LSP Encapsulation >>> >>> The encapsulations is not LSP is it? >>> >>> This document defines two methods for carrying Timing messages over >>> MPLS. The first method is carrying UDP/IP encapsulated Timing >>> messages over Timing LSPs, and the second method, is carrying >>> Ethernet encapsulated Timing messages over Ethernet PWs inside Timi= ng >>> LSPs. >>> >>> 6.1. Timing over UDP/IP over MPLS Encapsulation >>> >>> The simplest method of transporting Timing messages over MPLS is to >>> encapsulate Timing PDUs in UDP/IP and then encapsulate them in Timi= ng >>> LSP. This format is shown in Figure 4. >>> >>> >>> +----------------------+ >>> | Timing LSP Label | >>> +----------------------+ >>> | IPv4/6 | >>> +----------------------+ >>> | UDP | >>> +----------------------+ >>> | Timing PDU | >>> +----------------------+ >>> >>> Figure (4) - Timing over UDP/IP over MPLS Encapsulation >>> >>> >>> This encapsulation is very simple and is useful when the network >>> between Timing Master Clock and Slave Clock is MPLS network. >>> >>> SB> Simple is a judgement call >>> >>> In order for an LER/LSR to process Timing messages, the Timing LSP >>> Label must be at the top label of the label stack. The LER/LSR MUS= T >>> know that the Timing LSP Label is used for carrying Timing messages= . >>> This can be accomplished via static configuration or via RSVP-TE >>> signaling. >>> >>> The UDP/IP encapsulation of PTP MUST follow Annex D and E of >>> [IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow >>> [RFC5905]. >>> >>> 6.2. Timing over PW Encapsulation >>> >>> Another method of transporting Timing over MPLS networks is by >>> encapsulating Timing PDUs in PW which in turn is transported over >>> Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448], >>> shown in Fig 5(A) MUST be used and the Ethernet encapsulation of PT= P >>> MUST follow Annex F of [IEEE-1588]. >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 13= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> The RAW mode or Tagged mode defined in [RFC4448] MAY be used and th= e >>> Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The >>> Timing over PW encapsulation MUST use the Control Word (CW) as >>> specified in [RFC4448] to ensure proper detection of PTP messages >>> inside the MPLS packets for Timing over LSP and Timing over PW >>> encapsulation. >>> >>> SB> That needs explanation >>> >>> The use of Sequence Number in the CW is optional. >>> >>> SB> Given that s/n are never in practice deployed, you could probably >>> SB> simplify things by sayig that they are not used. >>> >>> Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over = PW >>> (the IP PW discussed in [RFC4447]) shown in Fig 5(B). >>> >>> +----------------+ +----------------+ >>> |Timing LSP Label| |Timing LSP Label| >>> +----------------+ +----------------+ >>> | PW Label | | PW Label | >>> +----------------+ +----------------+ >>> | Control Word | | IP | >>> +----------------+ +----------------+ >>> | Ethernet | | UDP | >>> | Header | +----------------+ >>> +----------------+ | Timing PDU | >>> |S-VLAN(Optional)| | | >>> +----------------+ +----------------+ >>> |C-VLAN(Optional)| (B) >>> +----------------+ >>> | Timing PDU | >>> | | >>> +----------------+ >>> (A) >>> >>> Figure (5) - Timing over PW Encapsulations >>> >>> In order for an LSR to process PTP messages, the top label of the >>> label stack (the Tunnel Label) MUST be a Timing label. >>> >>> S> You said that before. >>> >>> 6.3. Other Timing Encapsulation methods >>> >>> In future other timing encapsulation methods may be introduced, suc= h >>> as a new shim header after the Bottom of Stack to carry the Timing >>> information. Such new encapsulations are outside the scope of this >>> document. >>> >>> >>> SB> Taking a pure MPLS pov, you can simplify a lot of the text >>> SB> out of the definition of the LSP >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 14= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> SB> I think we need a section on LSP processing >>> >>> 7. Timing message Processing >>> >>> Each Timing protocol such as PTP and NTP, define their set of Timin= g >>> messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, >>> FOLLOW_UP, etc messages. >>> >>> Some of the Timing messages require time stamping or correction fie= ld >>> update at port level and some dont. It is the job of the LER/LSR t= o >>> parse the timing message and find out the type of the Timing messag= e >>> and decide whether and how to Time- stamp it (e.g., BC) or update >>> correction field(e.g., TC). >>> >>> >>> SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing >>> SB> function rather than the LER? >>> >>> For example the following PTP messages (called Event messages) >>> require time-stamping or correction field update: >>> >>> o SYNC >>> >>> o DELAY_REQ (Delay Request) >>> >>> o PDELAY_REQ (Peer Delay Request) >>> >>> o PDELAY_RESP (Peer Delay Response) >>> >>> SYNC and DELAY_REQ are exchanged between Master Clock and Slave Clo= ck >>> and MUST be transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP >>> are exchanged between adjacent PTP clocks (i.e. Master, Slave, >>> Boundary, or Transparent) and SHOULD be transported over single hop >>> PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP, >>> and PDELAY_RESP_FOLLOW_UP messages MUST also be transported over >>> the >>> PTP LSPs. >>> >>> For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be >>> transported over two PTP LSPs that are in opposite directions. The= se >>> PTP LSPs, which are in opposite directions MUST be congruent and co= - >>> routed. Alternatively, a single bidirectional co-routed LSP can be >>> used. >>> >>> Except as indicated above for the two-step PTP clocks, Non-Event PT= P >>> message types do not need to be processed by intermediate routers. >>> These message types MAY be carried in PTP Tunnel LSPs. >>> >>> SB> Are you saying that a timing P router has to be msg type sensitive? >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 15= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 8. Protection and Redundancy >>> >>> >>> SB> This is a bit of a jump - I don't know how the LSP itself works yet= ! >>> >>> In order to ensure continuous uninterrupted operation of slave >>> clocks, usually as a general practice, slave clocks (or ports) trac= k >>> redundant master clocks. >>> >>> It is the responsibility of the network operator to ensure that >>> physically disjoint Timing LSPs are established between a slave clo= ck >>> (or port) and redundant master clocks (or ports). >>> >>> When a slave clock (or port) listens to redundant master clocks or >>> ports, any prolonged Timing LSP outage will trigger the slave clock >>> or port to switch to a redundant master clock or port. >>> >>> LSP/PW protection such as Linear protection Switching (1:1, 1+1), >>> Ring protection switching or MPLS Fast Reroute (FRR) generally swit= ch >>> alternative path that usually cause a change in delay, which if >>> undetected by slave clock can reduce accuracy of the slave clock. >>> >>> Therefore protection switching MAY be used, as long as phase jumps >>> upon switchover due to differences in path latency are detected and >>> compensated for (such compensation not being required if BCs or pee= r- >>> peer TCs are used throughout). >>> >>> Note that any protection or reroute mechanism that adds additional >>> MPLS label to the label stack, such as Facility Backup Fast Reroute= , >>> MUST ensure that the pushed label is also a Timing Label to ensure >>> recognition of the MPLS frame as containing Timing messages, as it >>> transits the backup path. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 16= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 9. ECMP >>> >>> To ensure the optimal operation of slave clocks and avoid error >>> introduced by forward and reverse path delay asymmetry, the physica= l >>> path for Timing messages from master clock to slave Clock and vice >>> versa must be the same for all Event Timing messages listed in >>> section 7. >>> >>> Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost >>> Multipath). >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 17= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 10. PHP >>> >>> To ensure that the label on the top of the label stack is the Timin= g >>> LSP Label, PHP MUST not be used. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 18= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 11. Entropy >>> >>> To ensure all Timing messages in a Timing LSP take the same path, >>> Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and >>> Entropy Label MUST NOT be used for the PWs that are carried inside >>> Timing LSP [RFC6391]. >>> >>> SB> This is incorrect - you mean that all msgs of the same timing >>> SB> flow need to have the same EL value. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 19= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 12. OAM, Control and Management >>> >>> In order to monitor Timing LSPs and their encapsulated PWs, they MU= ST >>> be able to carry OAM and management messages. These management >>> messages MUST be differentiated from Timing messages via already >>> defined IETF methods. >>> >>> For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY run >>> over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These >>> Management protocols can easily be identified by the UDP Destinatio= n >>> Port number or by GAL/G-ACH respectively. >>> >>> Also BFD, LSP-Ping and other management messages MAY run over the P= Ws >>> encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3 = or >>> 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is goi= ng >>> to be deprecated by IETF). In this case G-ACH, PW label (TTL=3D1) = or >>> GAL-ACH are used to identify such management messages. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 20= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 13. QoS Considerations >>> >>> In network deployments where not every LSR/LER is Timing-aware, it = is >>> important to reduce the impact of the non-Timing-aware LSR/LERs on >>> the timing recovery in the slave clock. The Timing messages are ti= me >>> critical and must be treated with the highest priority. Therefore >>> Timing over MPLS messages must be treated with the highest priority >>> in the routers. This can be achieved by proper setup of Timing LSP= s. >>> >>> It is recommended that the Timing LSPs are setup or configured >>> properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC2697= ] >>> for drop eligibility. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 21= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 14. FCS and Checksum Recalculation >>> >>> When time-stamp generation and timing packet adjustment is performe= d >>> near the physical port hardware, the process MUST include >>> recalculation of the Ethernet FCS. >>> >>> SB> The above is confusing - an LSR always recomputes the link layer >>> SB> CRC which may or may not be Ethernet. >>> >>> Also FCS retention for the >>> payload Ethernet described in [RFC4720] MUST NOT be used. >>> >>> For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum >>> may be required as per UDP transport standards. >>> >>> SB> You really need to be working on getting the IPv6 C?S computation >>> SB> removed from PTP msgs. >>> >>> When UDP checksum is used, each Timing-aware LER/LSR must either >>> incrementally update the UDP checksum after Time stamping or >>> Correction Field update or verify the UDP checksum on reception fro= m >>> upstream and recalculate the checksum completely on transmission to >>> downstream node after Time stamping or Correction Field update. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 22= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 15. Behavior of LER/LSR >>> >>> Timing-capable/aware LERs and LSRs are routers that have one or mor= e >>> >>> SB> You mean physical interfaces? >>> >>> interfaces that can perform Timing operations (OC/BC/TC) on Timing >>> packets and are configured to do so. Timing-capable/aware LERs and >>> LSRs can advertise their Timing-capability per-interface via contro= l >>> plane such as OSPF or IS-IS. >>> SB> ISIS and OSPF are routing protocols. >>> >>> The Timing-capable/aware LERs can then >>> signals Timing LSPs via RSVP-TE signaling. Alternatively the Timin= g >>> capability of LER and LSRs may be configured in a centralized >>> controller and the Timing LSP may be setup using manual configurati= on >>> or other methods such as SDN. >>> >>> SB> it can also be configured individually rather then through >>> SB> a cebtral controllwe >>> >>> 15.1. Behavior of Timing-capable/aware LER >>> >>> When a Timing-capable/aware LER behaves as a Transparent clock and >>> receives a Timing message from a Timing-capable/aware non-MPLS >>> interface, the LER updates the Correction Field (CF) and encapsulat= es >>> and forwards the timing message over previously established Timing >>> LSP. >>> >>> SB> You need to call out the details so that people properly >>> SB> understand the definition of the new LSP. >>> >>> Also when a Timing message is received from a Timing-capable/ >>> aware MPLS interface, LER updates the Correction Filed (CF) and >>> decapsulates the MPLS encapsulation and forwards the timing message >>> to a non-MPLS interface. >>> >>> When a Timing-capable/aware LER behaves as a Boundary clock and >>> receives a Timing message from a Timing-capable/aware non MPLS >>> interface, the LER Timestamps the Timing packet and sends it to the >>> LERs Boundary clock processing module. Also when a Timing message = is >>> received from a Timing- capable/aware MPLS interface, the LER >>> Timestamps the Timing packet and sends it to the LERs Boundary cloc= k >>> processing module. >>> >>> When a Timing-capable/aware LER behaves as an Ordinary Clock toward >>> the MPLS network, and receives a Timing message from a Timing- >>> capable/aware MPLS interface, the LER Timestamps the Timing packet >>> and sends it to the LERs Ordinary clock processing module. >>> >>> 15.2. Behavior of Timing-capable/aware LSR >>> >>> When a Timing-capable/aware LSR behaves as a Transparent clock and >>> receives a Timing message from a Timing-capable/aware MPLS interfac= e, >>> The LSR updates the Correction Filed (CF) and forwards the timing >>> message over another MPLS interface. >>> >>> When a Timing-capable/aware LSR behaves as a Boundary clock and >>> receives a Timing message from a Timing-capable/aware MPLS interfac= e. >>> The LSR performs the functions of a Boundary Clock in terminating t= he >>> received Timing message and re-generating a new timing message over >>> another (or the same) MPLS interface. >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 23= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 15.3. Behavior of non-Timing-capable/aware LSR >>> >>> It is most beneficial when all LSRs in the path of a Timing LSP be >>> timing-Capable/aware LSRs. This would ensure the highest quality >>> time and clock synchronization by Timing Slave Clocks. However, th= is >>> specification does not mandate that all LSRs in path of a Timing LS= P >>> be Timing- capable/aware. >>> >>> Non-Timing-capable/aware LSRs just switch the packets encapsulated = in >>> Timing LSPs and dont perform any Timing operation (TC or BC). >>> However as explained in QoS section the Timing over MPLS packets MU= ST >>> be still be treated with the highest priority based on their Traffi= c >>> Class (TC) marking. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 24= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 16. Other considerations >>> >>> [IEEE-1588] defines an optional peer-to-peer Transparent clocking >>> that requires peer delay measurement between two adjacent Timing- >>> capable/ aware routers/switches. Peer delay measurement messages >>> need to be time stamped and terminated by the Timing-capable/aware >>> routers/ switches. This means that two adjacent LSRs may be engage= d >>> in a peer delay measurement. >>> >>> For transporting such peer delay measurement messages a single-hop >>> LSP SHOULD to be created between the two adjacent LSRs engaged in >>> peer delay measurement to carry peer delay measurement messages. >>> Other methods such as PTP transport over Ethernet MAY be used for >>> transporting peer delay measurement messages if the link between th= e >>> two routers is Ethernet. >>> >>> In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ wa= re >>> routers/switches MUST maintain a list of all the neighbors it needs >>> to send a PDelay_Req to, where each neighbor corresponds to a timin= g >>> LSP. >>> >>> The use of Explicit Null Label (Label=3D 0 or 2) is acceptable as l= ong >>> as either the Explicit Null label is the bottom of stack label >>> (applicable only to UDP/IP encapsulation) or the label below the >>> Explicit Null label is a PTP label. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 25= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 17. Security Considerations >>> >>> MPLS PW security considerations in general are discussed in [RFC398= 5] >>> and [RFC4447],and those considerations also apply to this document. >>> >>> An experimental security protocol is defined in [IEEE-1588].The PTP >>> security extension and protocol provides group source authenticatio= n, >>> message integrity, and replay attack protection for PTP messages. >>> >>> When the MPLS network (provider network) serves multiple customers, >>> it is important to maintain and process each customers clock and >>> Timing messages separately from other customers to ensure there is = no >>> cross- customer effect. For example if an LER BC is synchronized t= o >>> a specific grandmaster, belonging to customer A, then the LER MUST >>> use that BC clock only for customer A to ensure that customer A >>> cannot attack other customers by manipulating its time. >>> >>> Timing messages MAY be encrypted or authenticated, provided that th= e >>> LERs/LSRs that are Timing capable/aware can authenticate/ decrypt t= he >>> timing messages. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 26= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 18. Acknowledgements >>> >>> The authors would like to thank Ron Cohen, Yaakov Stein, Tal Mizrah= i, >>> Stefano Ruffini, Peter Meyer, and other members of IETF for reviewi= ng >>> and providing feedback on this draft. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 27= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 19. IANA Considerations >>> >>> There are no IANA requirements in this specification. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 28= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 20. References >>> >>> 20.1. Normative References >>> >>> [IEEE-1588] >>> IEEE 1588-2008, "IEEE Standard for a Precision Clock >>> Synchronization Protocol for Networked Measurement and >>> Control Systems". >>> >>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >>> Requirement Levels", BCP 14, RFC 2119, March 1997. >>> >>> [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- >>> Edge (PWE3) Architecture", RFC 3985, March 2005. >>> >>> [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discover= y >>> Proxies (ND Proxy)", RFC 4389, April 2006. >>> >>> [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. >>> Heron, "Pseudowire Setup and Maintenance Using the Label >>> Distribution Protocol (LDP)", RFC 4447, April 2006. >>> >>> [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, >>> "Encapsulation Methods for Transport of Ethernet over MP= LS >>> Networks", RFC 4448, April 2006. >>> >>> [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire >>> Emulation Edge-to-Edge (PWE3) Frame Check Sequence >>> Retention", RFC 4720, November 2006. >>> >>> [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit >>> Connectivity Verification (VCCV): A Control Channel for >>> Pseudowires", RFC 5085, December 2007. >>> >>> [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detectio= n >>> (BFD)", RFC 5880, June 2010. >>> >>> [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, >>> "Bidirectional Forwarding Detection (BFD) for MPLS Label >>> Switched Paths (LSPs)", RFC 5884, June 2010. >>> >>> 20.2. Informative References >>> >>> [I-D.ietf-pwe3-fat-pw] >>> Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan= , >>> J., and S. Amante, "Flow Aware Transport of Pseudowires >>> over an MPLS Packet Switched Network", >>> draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011. >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 29= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate >>> system routeing information exchange protocol for use in >>> conjunction with the Protocol for providing the >>> Connectionless-mode Network Service (ISO 8473)". >>> >>> [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and >>> dual environments", RFC 1195, December 1990. >>> >>> [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. >>> >>> [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color >>> Marker", RFC 2697, September 1999. >>> >>> [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec= , >>> J., Courtney, W., Davari, S., Firoiu, V., and D. >>> Stiliadis, "An Expedited Forwarding PHB (Per-Hop >>> Behavior)", RFC 3246, March 2002. >>> >>> [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineeri= ng >>> (TE) Extensions to OSPF Version 2", RFC 3630, >>> September 2003. >>> >>> [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate >>> System (IS-IS) Extensions for Traffic Engineering (TE)", >>> RFC 3784, June 2004. >>> >>> [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. >>> Shaffer, "Extensions to OSPF for Advertising Optional >>> Router Capabilities", RFC 4970, July 2007. >>> >>> [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate >>> System to Intermediate System (IS-IS) Extensions for >>> Advertising Router Information", RFC 4971, July 2007. >>> >>> [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi >>> Topology (MT) Routing in Intermediate System to >>> Intermediate Systems (IS-ISs)", RFC 5120, February 2008. >>> >>> [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic >>> Engineering", RFC 5305, October 2008. >>> >>> [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, >>> "Traffic Engineering Extensions to OSPF Version 3", >>> RFC 5329, September 2008. >>> >>> [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF >>> for IPv6", RFC 5340, July 2008. >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 30= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Netwo= rk >>> Time Protocol Version 4: Protocol and Algorithms >>> Specification", RFC 5905, June 2010. >>> >>> [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan= , >>> J., and S. Amante, "Flow-Aware Transport of Pseudowires >>> over an MPLS Packet Switched Network", RFC 6391, >>> November 2011. >>> >>> [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and >>> L. Yong, "The Use of Entropy Labels in MPLS Forwarding", >>> RFC 6790, November 2012. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 31= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 1. Routing extensions for Timing-aware Routers >>> >>> MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] an= d >>> IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE= ) >>> link information used for constraint-based routing. >>> >>> Indeed, it is useful to advertise data plane TE router link >>> capabilities, such as the capability for a router to be Timing-awar= e. >>> This capability MUST then be taken into account during path >>> computation to prefer or even require links that advertise themselv= es >>> as Timing-aware. In this way the path can ensure the entry and exi= t >>> points into the LERs and, if desired, the links into the LSRs are >>> able to perform port based time-stamping thus minimizing their impa= ct >>> on the performance of the slave clock. >>> >>> extensions are required to OSPF and IS-IS in order to advertise >>> Timing-aware capabilities of a link. Such extensions are outside t= he >>> scope of this document; however such extension SHOULD be able to >>> signal the following information per Router Link: >>> >>> o Capable of processing PTP, NTP or other Timing flows >>> >>> o Capable of performing Transparent Clock operation >>> >>> o Capable of performing Boundary Clock operation >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 32= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> 2. Signaling Extensions for Creating Timing LSPs >>> >>> RSVP-TE signaling MAY be used to setup the timing LSPs. When RSVP-= TE >>> is used to setup Timing LSPs, some information that indicates that >>> the LSP is carrying Timing flows MUST be included in the new >>> Extensions to RSVP-TE: >>> >>> The following information MAY also be included in the new Extension= s >>> to RSVP-TE: >>> >>> o Offset from Bottom of Stack (BoS) to the start of the Time-stamp >>> field >>> >>> o Number of VLANs in case of PW encapsulation >>> >>> o Timestamp field Type >>> >>> * Correction Field, Timestamp >>> >>> o Timestamp Field format >>> >>> * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit >>> NTP, etc. >>> >>> Note that in case the above optional information is signaled with >>> RSVP-TE for a Timing LSP, all the Timing packets carried in that LS= P >>> must have the same signaled characteristics. For example if >>> Timestamp format is signaled as 64-bit PTPv1, then all Timing packe= ts >>> must use 64-bit PTPv1 time-stamp. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 33= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> Authors' Addresses >>> >>> Shahram Davari >>> Broadcom Corp. >>> San Jose, CA 95134 >>> USA >>> >>> Email: davari@broadcom.com >>> >>> >>> Amit Oren >>> Broadcom Corp. >>> San Jose, CA 95134 >>> USA >>> >>> Email: amito@broadcom.com >>> >>> >>> Manav Bhatia >>> Alcatel-Lucent >>> Bangalore, >>> India >>> >>> Email: manav.bhatia@alcatel-lucent.com >>> >>> >>> Peter Roberts >>> Alcatel-Lucent >>> Kanata, >>> Canada >>> >>> Email: peter.roberts@alcatel-lucent.com >>> >>> >>> Laurent Montini >>> Cisco Systems >>> San Jose CA >>> USA >>> >>> Email: lmontini@cisco.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 34= ] >>> Internet-Draft Transporting Timing over MPLS June 201= 3 >>> >>> >>> Luca >>> Cisco Systems >>> San Jose CA >>> USA >>> >>> Email: lmartini@cisco.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Davari, et al. Expires December 17, 2013 [Page 35= ] >>> -- >>> For corporate legal information go to: >>> >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>> >>> _______________________________________________ >>> TICTOC mailing list >>> TICTOC@ietf.org >>> https://www.ietf.org/mailman/listinfo/tictoc >> >> This e-mail message is intended for the recipient only and contains info= rmation 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 > . > --=20 For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc From internet-drafts@ietf.org Mon Aug 5 14:00:09 2013 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 06C7F21F9EC4; Mon, 5 Aug 2013 14:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, 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 OgwcsrUaZBW1; Mon, 5 Aug 2013 14:00:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4EA21F8EEA; Mon, 5 Aug 2013 14:00:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130805210007.31581.2159.idtracker@ietfa.amsl.com> Date: Mon, 05 Aug 2013 14:00:08 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-targeted-mldp-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, 05 Aug 2013 21:00:09 -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 Gro= up of the IETF. Title : Using LDP Multipoint Extensions on Targeted LDP Sessions Author(s) : Maria Napierala Eric C. Rosen Filename : draft-ietf-mpls-targeted-mldp-03.txt Pages : 10 Date : 2013-08-05 Abstract: As specified in RFC 6388, Label Distribution Protocol (LDP) can be used to set up Point-to-Multipoint (P2MP) and Multipoint-to- Multipoint (MP2MP) Label Switched Paths. However, RFC 6388 presupposes that the two endpoints of an LDP session are directly connected. The LDP base specification (RFC 5036) allows for the case where the two endpoints of an LDP session are not directly connected; such a session is known as a "Targeted LDP" session. This document provides the specification for using the LDP P2MP/MP2MP extensions over a Targeted LDP session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-targeted-mldp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-targeted-mldp-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-targeted-mldp-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Alexander.Vainshtein@ecitele.com Tue Aug 6 00:38:52 2013 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 3AEF311E80E1 for ; Tue, 6 Aug 2013 00:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 dpqf+R+jVT3v for ; Tue, 6 Aug 2013 00:38:47 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.162]) by ietfa.amsl.com (Postfix) with ESMTP id B769321F9FCE for ; Tue, 6 Aug 2013 00:38:45 -0700 (PDT) Received: from [85.158.138.51:65290] by server-2.bemta-3.messagelabs.com id E1/D0-21241-408A0025; Tue, 06 Aug 2013 07:38:44 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1375774719!28438247!3 X-Originating-IP: [147.234.242.234] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1301 invoked from network); 6 Aug 2013 07:38:43 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Aug 2013 07:38:43 -0000 X-AuditID: 93eaf2e7-b7ef66d00000140d-77-5200a802b343 Received: from ILPTWPVEXCA01.ecitele.com ( [172.31.244.224]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 01.18.05133.208A0025; Tue, 6 Aug 2013 10:38:42 +0300 (IDT) Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA01.ecitele.com ([fe80::ac15:43ab:d541:dfa7%12]) with mapi id 14.03.0123.003; Tue, 6 Aug 2013 10:38:41 +0300 From: Alexander Vainshtein To: Shahram Davari Thread-Topic: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls Thread-Index: AQHOkhqJ+XHALQ/MzkWnZzr9BEl1M5mHyTyg Date: Tue, 6 Aug 2013 07:38:40 +0000 Message-ID: References: <51FB7543.801@cisco.com> <51FF7068.9080600@cisco.com> <4A6CE49E6084B141B15C0713B8993F281BEC731A@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BEC731A@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.35.10] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42KZ/OrTF12mFQxBBn/26VocfN7EaHFr6UpW ByaPJUt+MnnMmnWYKYApqoHRJjEvL78ksSRVISW1ONlWKaAosywxuVJJITPFVslQSaEgJzE5 NTc1r8RWKbGgIDUvRcmOSwED2ACVZeYppOYl56dk5qXbKnkG++taWJha6hoq2akpGxpbc4Vk ZBYrpOrmJmbmKOSmFhcnpqcqAEUStjBnrHvey16w6y5Lxd/PP5kbGHcvY+5i5OSQEDCRmP9o KyOELSZx4d56ti5GLg4hgYOMEqcX9TJDOEcYJQ6dOcUCUsUmYCuxafVdNhBbREBD4uCtK2CT mAWmM0q8fWjRxcjBISzgLnH4hx9EiYdE59TzjBC2kUTbkfdgNouAisTpF2fARvIKBEhsWPOL CWJXF5PE8T/zwIo4BcIlju+4DraLEei676fWMEHsEpe49WQ+E8TVAhJL9pyH+kZU4uXjf6wQ tpzEkycQNzML6Egs2P2JDcLWlli28DUzxGJBiZMzn7BA1EtKHFxxg2UCo/gsJCtmIWmfhaR9 FpL2BYwsqxhFM3MKSpJy0w0M9VKTM0tSc1L1kvNzNzFCksnzHYy/5qscYnQFenwisxR3cj4w GeWVxBsbGODmKInzLm8I9xcSSAcmnezU1ILUovii0pzU4kOMTBycUg2MTTeLao7MLUyZHyG+ oUP370uWypw3Cz5zybnd5+wU9fDZ2juZg6NOeWuwitbMWZJzlIs431173HNirn1LfL5SpvUb 8aXn3BmPbZROWzefM1UguXz5YVbnT3++TTv14P62Nb800p+laW/Zf8eFTVAw7Dsj+8wcDq1N W2Z8578Wu2L3r82hU77VKbEUZyQaajEXFScCACDtIR8eAwAA Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] Comments on draft-ietf-tictoc-1588overmpls 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, 06 Aug 2013 07:38:52 -0000 Shahram, I agree with you that the routers that do not recognize a Timing Alert label= would send the packet to the CPU. (This would be easy to arrange since we a= re speaking about a reserved label.) I do not, however, see this as a serious issue, because the SW running on th= is CPU would (hopefully) be upgradable to handle the packet correctly i.e.,= to forward it to where it should be forwarded and, if it is forwarded as a= labeled packet, to prepend the Timing Alert Label on top of its label stack= . It could even record the residence time (as observed by the CPU in the pro= per place in the packet. This would mean that introducing additional error t= o whatever timing information is associated with this packet - but this is w= hat you should anyway expect if there are non-compliant routers on your path= , right? Regards, Sasha > -----Original Message----- > From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf O= f > Shahram Davari > Sent: Monday, August 05, 2013 11:29 PM > To: stbryant@cisco.com; S. Davari > Cc: mpls@ietf.org; tictoc@ietf.org > Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls > > Hi Stewart, > > Your suggestion of " I suggested an LSP type that has the properties "time= stamp > and pass to application", is a subset of the existing draft and should wor= k. It > basically limits the time stamping and correction field update to LERs (wh= ile the > draft supports time stamping at LER and LSR). > > However Sasha's suggestion of using a reserved label (RAL, GAL or any othe= r > reserved label) does not satisfy one of the major requirements, which is > backward compatibility. Routers that don't understand this reserved label= will > drop or copy to CPU such packets. > > Regards, > Shahram > > -----Original Message----- > From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf O= f > Stewart Bryant > Sent: Monday, August 05, 2013 2:29 AM > To: S. Davari > Cc: mpls@ietf.org; tictoc@ietf.org > Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls > > My concern is that we are creating a new LSP type in MPLS > (which is a architectural change and thus needs to be very carefully > considered) without asking the question "how can I do this > in the most general way, to maximize flexibility/reuse" > > I suggested an LSP type that has the properties "timestamp > and pass to application", but I think that Sasha raises a good > point about using router alert. However RA has no implicit > timestamp, so maybe we need a new type of RA that has the > properties "timestamp, and pass top application indicated by > the next label". That would be quite useful in a number > of OAM applications. There is possibly some GAL variant > of that design that should also be considered. > > The application could worry about the path and where it > was necessary to skip some hops a hierarchical LSP would > accomplish that, with the specific benefit that the application > would consciously do this, and may be able to apply some > form of compensation within the network. > > - Stewart > > On 04/08/2013 10:40, S. Davari wrote: > > Hi Sasha > > > > Perhaps you have not understood the draft well. The main reason that the > draft chose to use a dedicated LSP that is signaled via RSVPTE indicating= it is a > timing LSP is to be backward compatible with non-1588 nodes. Such nodes > simply just switch the packet. > > > > Your proposal had been considered and was rejected since it was not > backward compatible. Nodes receiving alert label or TTL =3D 1 send the pac= ket to > CPU. You can refer to the meeting notes. > > > > Regards, > > Shahram > > > > > > On Aug 4, 2013, at 1:21 AM, Alexander Vainshtein > wrote: > > > >> Stewart and all, > >> I concur with Stewart's statement that the draft does not define "full > interaction with MPLS architecture". > >> > >> E.g., one of the objectives of the draft is to provide a technique that= would > be backward-compatible with old LSRs that cannot provide on-path support f= or > timing distribution, while the other objective is to make every LSR on the= path > aware that some MPLS packets are carrying timing-related messages and henc= e > require on-path support. > >> > >> IMHO and FWIW, the MPLS data plane architecture allows just two methods > for making a transit LSR to provide special processing to a labeled packet= : > >> - It would carry some kind of an "alert label" on top of the label stac= k and, > specifically, on top of any labels used for actual forwarding > >> OR, > >> - The TTL in the top label stack entry has been set to 1. > >> > >> > >> The draft does not follow any of these approaches. > >> > >> I must also admit that Section 12 "OAM, Control and Management" of the > draft looks somewhat in > >> E.g., I could not understand from the text whether BFD, LSP-Ping etc. O= AM > messages would be subjected to on-path support procedures for timing > messages or not. > >> > >> My 2c, > >> Sasha > >> > >>> -----Original Message----- > >>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Beha= lf > Of > >>> Stewart Bryant > >>> Sent: Friday, August 02, 2013 12:01 PM > >>> To: mpls-chairs@tools.ietf.org; tictoc-chairs@tools.ietf.org; int- > >>> ads@tools.ietf.org; rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.org= ; > draft- > >>> ietf-tictoc-1588overmpls@tools.ietf.org > >>> Cc: mpls@ietf.org; tictoc@ietf.org > >>> Subject: [TICTOC] Comments on draft-ietf-tictoc-1588overmpls > >>> > >>> SB> This draft does not seem to provide a precise definition > >>> SB> the properties of the new LSP type that it wishes to > >>> SB> define, in particular it does it define the PHB of those > >>> SB> LSPs, nor the full interaction with the MPLS > >>> SB> architecture. > >>> SB> > >>> SB> I have not tracked TICTOC for a while but I thought that > >>> SB> the original plan was to define the concept of an offset > >>> SB> into a packet to do the correction. > >>> SB> > >>> SB> It is disappointing that the opportunity was not taken > >>> SB> to define a timing shim inside the timing LSP so that > >>> SB> a time correction could be added to any packet such that > >>> SB> the MPLS system was isolated from the details of the > >>> SB> complexity of the particular time transfer type. > >>> > >>> SB> I think that much more clarify is needed in terms of > >>> SB> definition of the new LSP type, since it is unclear > >>> SB> from this text how to implement one. > >>> SB> > >>> SB> There are a lot of other MPLS services such as > >>> SB> LSP ping that need to be considered. > >>> SB> > >>> SB> Please see inline for more comments. However these > >>> SB> comments are made in the context of the text as written > >>> SB> whilst I have a fundamental concern that this approach > >>> SB> lacks an MPLS architectural soundness that need > >>> SB> greater thought with significant impact on the > >>> SB> draft. > >>> > >>> - Stewart > >>> > >>> > >>> TICTOC Working Group S. Dava= ri > >>> Internet-Draft A. Or= en > >>> Intended status: Standards Track Broadcom Cor= p. > >>> Expires: December 17, 2013 M. Bhat= ia > >>> P. Robe= rts > >>> Alcatel-Luc= ent > >>> L. Mont= ini > >>> L. Mart= ini > >>> Cisco Syst= ems > >>> June 15, 2= 013 > >>> > >>> > >>> Transporting Timing messages over MPLS Networks > >>> draft-ietf-tictoc-1588overmpls-05 > >>> > >>> Abstract > >>> > >>> This document defines the method for transporting Timing messages > >>> such as PTP and NTP over an MPLS network. The method allows for t= he > >>> easy identification of these PDUs at the port level to allow for p= ort > >>> > >>> SB> What is a port > >>> > >>> level processing of these PDUs in both LERs and LSRs. > >>> > >>> The basic idea is to transport Timing messages inside dedicated MP= LS > >>> LSPs. These LSPs only carry Timing messages and possibly Control= and > >>> Management packets, but they do not carry customer traffic. > >>> > >>> SB> More specifically they only carry traffic associated with the > >>> SB> timing service and its support. > >>> SB> The question arose WRT BFD - surely BFD is allowed, BUT surely > >>> SB> also it gets carried in a structure that causes it to get > >>> SB> timestamped. > >>> > >>> Two methods for transporting Timing messages over MPLS are defined= . > >>> > >>> SB> Perhaps the right approach is to define the new LSP type and then > >>> SB> seperately to define the mapping of the various timing services > >>> SB> over that LSP type. > >>> > >>> The first method is to transport Timing messages directly over the > >>> dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for > >>> MPLS networks. The second method is to transport Timing messages > >>> inside a PW via Ethernet encapsulation. > >>> > >>> SB> I think that we should note that there are some > >>> SB> h/w reasons for this preference. A clean sheet approach > >>> SB> would have been to use PTP over MPLS with no intermediate > >>> SB> layers. > >>> > >>> Status of this Memo > >>> > >>> This Internet-Draft is submitted in full conformance with the > >>> provisions of BCP 78 and BCP 79. > >>> > >>> Internet-Drafts are working documents of the Internet Engineering > >>> Task Force (IETF). Note that other groups may also distribute > >>> working documents as Internet-Drafts. The list of current Interne= t- > >>> Drafts is at http://datatracker.ietf.org/drafts/current/. > >>> > >>> Internet-Drafts are draft documents valid for a maximum of six mon= ths > >>> and may be updated, replaced, or obsoleted by other documents at a= ny > >>> time. It is inappropriate to use Internet-Drafts as reference > >>> material or to cite them other than as "work in progress." > >>> > >>> This Internet-Draft will expire on December 17, 2013. > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page= 1] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> Copyright Notice > >>> > >>> Copyright (c) 2013 IETF Trust and the persons identified as the > >>> document authors. All rights reserved. > >>> > >>> This document is subject to BCP 78 and the IETF Trust's Legal > >>> Provisions Relating to IETF Documents > >>> (http://trustee.ietf.org/license-info) in effect on the date of > >>> publication of this document. Please review these documents > >>> carefully, as they describe your rights and restrictions with resp= ect > >>> to this document. Code Components extracted from this document mu= st > >>> include Simplified BSD License text as described in Section 4.e of > >>> the Trust Legal Provisions and are provided without warranty as > >>> described in the Simplified BSD License. > >>> > >>> > >>> Table of Contents > >>> > >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .= 5 > >>> > >>> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .= 7 > >>> > >>> 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . .= 8 > >>> > >>> 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . .= 9 > >>> > >>> 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . .= 12 > >>> > >>> 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . .= 13 > >>> 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . .= 13 > >>> 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . .= 13 > >>> 6.3. Other Timing Encapsulation methods . . . . . . . . . . . .= 14 > >>> > >>> 7. Timing message Processing . . . . . . . . . . . . . . . . . .= 15 > >>> > >>> 8. Protection and Redundancy . . . . . . . . . . . . . . . . . .= 16 > >>> > >>> 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .= 17 > >>> > >>> 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .= 18 > >>> > >>> 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . .= 19 > >>> > >>> 12. OAM, Control and Management . . . . . . . . . . . . . . . . .= 20 > >>> > >>> 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . .= 21 > >>> > >>> 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . .= 22 > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page= 2] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . .= 23 > >>> 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . .= 23 > >>> 15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . .= 23 > >>> 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . .= 24 > >>> > >>> 16. Other considerations . . . . . . . . . . . . . . . . . . . . .= 25 > >>> > >>> 17. Security Considerations . . . . . . . . . . . . . . . . . . .= 26 > >>> > >>> 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .= 27 > >>> > >>> 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . .= 28 > >>> > >>> 20. References . . . . . . . . . . . . . . . . . . . . . . . . . .= 29 > >>> 20.1. Normative References . . . . . . . . . . . . . . . . . . .= 29 > >>> 20.2. Informative References . . . . . . . . . . . . . . . . . .= 29 > >>> > >>> Appendix 1. Routing extensions for Timing-aware Routers . . . . .= 32 > >>> > >>> Appendix 2. Signaling Extensions for Creating Timing LSPs . . . .= 33 > >>> > >>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .= 34 > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page= 3] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", > >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" > in > >>> this > >>> document are to be interpreted as described in RFC2119 [RFC2119]. > >>> > >>> When used in lower case, these words convey their typical use in > >>> common language, and are not to be interpreted as described in > >>> RFC2119 [RFC2119]. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page= 4] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 1. Introduction > >>> > >>> The objective of Precision Time Protocol (PTP) and Network Timing > >>> Protocol (NTP) are to synchronize independent clocks running on > >>> separate nodes of a distributed system. > >>> > >>> [IEEE-1588] defines PTP messages for frequency, phase and time > >>> synchronization. The PTP messages include PTP PDUs over UDP/IP > >>> (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex F= of > >>> [IEEE-1588]). > >>> > >>> SB> Sure BUT it is acknowledged that IEEE is open to the definition > >>> SB> of other PTP mappings if they provide better optimisation. > >>> > >>> This document defines mapping and transport of the PTP > >>> messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP > >>> defines several clock types: ordinary clocks, boundary clocks, end= - > >>> to-end transparent clocks, and peer-to-peer transparent clocks. > >>> Transparent clocks require intermediate nodes to update correction > >>> field inside PTP message that reflects the transit time in the nod= e. > >>> > >>> [RFC5905] defines NTP messages for clock and time synchronization. > >>> The PTP messages (PDUs) are transported over UDP/IP. This documen= t > >>> SB> Should that be NTP messages? > >>> SB> It needs to be made clear as soon as you introduce NTP that > >>> SB> they use different time representations. > >>> > >>> defines mapping and transport of the NTP messages defined in > >>> [RFC5905] over MPLS networks. > >>> > >>> One key attribute of all of these Timing messages is that the Time > >>> stamp processing should occur as close as possible to the actual > >>> transmission and reception at the physical port interface. This > >>> targets optimal time and/or frequency recovery by avoiding variabl= e > >>> delay introduced by queues internal to the clocks. > >>> > >>> SB> As I recall NTP has no epoch point defined, and I am not sure > >>> SB> where that point is in the case of PTP in this mapping > >>> SB> Hopefully this will get defined in due course. > >>> > >>> To facilitate the fast and efficient recognition of Timing message= s > >>> at the port level when the Timing messages are carried over MPLS > >>> LSPs, > >>> > >>> SB> Over a new LSP type with time optimied characteristics > >>> > >>> this document defines the specific encapsulations that should > >>> be used. > >>> SB> Hopefully it will also define the PHP > >>> > >>> In addition, it can be expected that there will exist LSR/ > >>> LERs where only a subset of the physical ports will have the port- > >>> based Timing message processing capabilities. > >>> SB> Do you need to clarify that this only works at base and not in > >>> SB> a label heirarchy. > >>> > >>> > >>> In order to ensure > >>> that the LSPs carrying Timing packets always enter and exit ports > >>> with this capability, routing extensions are defined to advertise > >>> this capability on a port basis and to allow for the establishment= of > >>> LSPs that only transit such ports. While this path establishment > >>> restriction may be applied only at the LER Ingress and/or egress > >>> ports, it becomes more important when using transparent clock capa= ble > >>> LSRs in the path. > >>> SB> I do not understand the implications of the last > >>> SB> sentences - starting ", it becomes" > >>> > >>> > >>> Port based Timing message processing involves Timing message > >>> recognition. Once the Timing messages are recognized they can be > >>> modified based on the reception or transmission Time-stamp. > >>> > >>> This document provides two methods for transporting Timing message= s > >>> over MPLS. One is applicable to MPLS environment and the other on= e > >>> is applicable to MPLS/MPLS-TP environment > >>> > >>> SB> I think the sentence is incomplete. > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page= 5] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> The solution involves transporting Timing messages over dedicated > >>> LSPs called Timing LSPs. These LSPs carry Timing messages and MAY > >>> carry Management and control messages, but not data plane client > >>> traffic. > >>> > >>> SB> It is not clear why this restriction applies. > >>> > >>> Timing LSPs can be established statically or via signaling. > >>> SB> s/statically/by provisioning/network management/ > >>> > >>> Extensions to control plane (OSPF, ISIS, etc.) is required to enab= le > >>> routers to distribute their Timing processing capabilities over MP= LS > >>> to other routers. However such extensions are outside the scope o= f > >>> this document. > >>> > >>> When signaling is used to setup the PTP LSP, Extensions to signali= ng > >>> SB> is it a PTP LSP or a Timing LSP? > >>> > >>> protocols (e.g., RSVP-TE) are required for establishing PTP LSPs. > >>> However such extensions are outside the scope of this document. > >>> > >>> SB> for mpls-tp GMPLS is the signalling protocol > >>> > >>> While the techniques included herein allow for the establishment o= f > >>> paths optimized to include Time-stamping capable links, the > >>> performance of the Slave clocks is outside the scope of this > >>> document. > >>> > >>> At the time of publishing this specification, Transparent Clocking > >>> (TC) is only defined for PTP. Therefore at this time any part of > >>> this specification that talks about Transparent Clocking applies o= nly > >>> to PTP. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page= 6] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 2. Terminology > >>> > >>> 1588: The timing and synchronization as defined by IEEE 1588. > >>> > >>> SB> I think that there is a more formal name for the 1588 group > >>> SB> that needs to be used here. > >>> SB> Also do we need to talk about 1588-200? as there is > >>> SB> an update in progress > >>> > >>> NTP: The timing and synchronization protocol defined by IETF RFC-1= 305 > >>> and RFC-5905. > >>> > >>> PTP: The timing and synchronization protocol used by 1588. > >>> SB> need the proper name for 1588 > >>> > >>> Master Clock: The source of 1588 timing to a set of slave clocks. > >>> > >>> Master Port: A port on a ordinary or boundary clock that is in Mas= ter > >>> state. This is the source of timing toward slave ports. > >>> > >>> SB> I am not sure the reader knows what a port is > >>> > >>> Slave Clock: A receiver of 1588 timing from a master clock. > >>> > >>> Slave Port: A port on a boundary clock or ordinary clock that is > >>> receiving timing from a master clock. > >>> > >>> Ordinary Clock: A device with a single PTP port. > >>> > >>> Transparent Clock. A device that measures the time taken for a PT= P > >>> event message to transit the device and then updates the > >>> correctionField of the message with this transit time. > >>> > >>> Boundary Clock: A device with more than one PTP port. Generally > >>> boundary clocks will have one port in slave state to receive timin= g > >>> and then other ports in master state to re-distribute the timing. > >>> > >>> PTP LSP: An LSP dedicated to carry PTP messages > >>> > >>> SB> PTP or timing? > >>> > >>> > >>> PTP PW: A PW within a PTP LSP that is dedicated to carry PTP > >>> messages. > >>> > >>> SB> Ah I don't think that PWE3 know what one of these is > >>> > >>> CW: Pseudowire Control Word > >>> > >>> LAG: Link Aggregation > >>> > >>> ECMP: Equal Cost Multipath > >>> > >>> CF: Correction Field, a field inside certain PTP messages (message > >>> type 0-3)that holds the accumulative transit time inside intermedi= ate > >>> switches > >>> > >>> Timing messages: Timing Protocol messages that are exchanged > between > >>> routers in order to establish a synchronized clock. > >>> > >>> SB> A number of these definitions look like copies of IEEE1588 > >>> SB> definitions. We need to provide references and note the > >>> SB> priority of the IEEE base reference. > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page= 7] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 3. Problem Statement > >>> > >>> [IEEE-1588] has defined methods for transporting PTP messages over > >>> Ethernet and IP networks. [RFC5905] has defined the method of > >>> transporting NTP messages over IP networks. There is a need to > >>> transport Timing messages over MPLS networks while supporting the > >>> Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC= ) > >>> functionality in the LER and LSRs in the MPLS network. > >>> > >>> There are multiple ways of transporting Timing over MPLS. However= , > >>> there is a requirement to limit the possible encapsulation options= to > >>> simplify the Timing message identification and processing required= at > >>> the port level. > >>> > >>> When Timing-awareness is needed, Timing messages should not be > >>> transported over LSPs or PWs that are carrying customer traffic > >>> because LSRs perform Label switching based on the top label in the > >>> stack. > >>> > >>> SB> Have you explained why? > >>> > >>> To detect Timing messages inside such LSPs require special > >>> hardware to do deep packet inspection at line rate. Even if such > >>> hardware exists, the payload can't be deterministically identified= by > >>> LSRs because the payload type is a context of the PW label, and th= e > >>> PW label and its context are only known to the Edge routers (PEs/ > >>> LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, CE= S, > >>> etc). Even if one restricts an LSP to only carry Ethernet PWs, th= e > >>> LSRs dont have the knowledge of whether PW Control Word (CW) is > >>> present or not and therefore can not deterministically identify th= e > >>> payload. > >>> > >>> A generic method is defined in this document that does not require > >>> deep packet inspection at line rate, and can deterministically > >>> identify Timing messages. This method can be used to detect Timin= g > >>> Messages in both one-step and two-step clock implementations of > >>> ordinary, boundary and transparent clocks. > >>> > >>> SB> Needs a ref and I am sure many MPLS specialists will not understan= d > >>> SB> the msg types. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page= 8] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 4. Timing over MPLS Architecture > >>> > >>> Timing messages are exchange between Timing ports on ordinary and > >>> > >>> SB> Have you defined a timing port? > >>> > >>> boundary clocks. Boundary clocks terminate the Timing messages an= d > >>> act as master for other boundary clocks or for slave clocks. End-= to- > >>> End Transparent clocks do not terminate the Timing messages but th= ey > >>> do modify the contents of the Timing messages as they transit acro= ss > >>> the transparent clock. > >>> > >>> Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent Cl= ock > >>> > >>> (TC) could be implemented in either LERs or LSRs. > >>> > >>> SB> LER and LSR need to be expanded > >>> > >>> An example is shown in Figure 1, where the LERs act as Ordinary Cl= ock > >>> (OC) and are the initiating/terminating point for Timing messages. > >>> The ingress LER encapsulates the Timing messages in Timing LSP and > >>> the Egress LER terminates the Timing LSP. The LSRs act as > >>> Transparent Clock (TC) and just update the Timing field in the Tim= ing > >>> messages. > >>> > >>> > >>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ > >>> |Switch, | | | | | | | |Switc= h, | > >>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rout= er | > >>> | | | OC | | TC | | OC | | = | > >>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ > >>> / \ > >>> +-------+ / \ +------= -+ > >>> | LER | / \ | LER= | > >>> | Master|---/ \---| Slave= | > >>> | Clock | | Clock= | > >>> +-------+ +------= -+ > >>> > >>> Figure (1) - Deployment example 1 of timing over MPLS network > >>> > >>> Another example is shown in Figure2, where LERs terminate the Timi= ng > >>> messages received from switch/routers that are outside of the MPLS > >>> network acting as OC or BC. In this example LERs regenerate the > >>> clock and initiate timing messages encapsulated in Timing LSP towa= rd > >>> the MPLS network, while the LSRs act as Transparent Clock (TC) and > >>> just update the Timing field in the Timing messages, which are > >>> already encapsulated in Timing LSPs. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page= 9] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> +--------+ +-------+ +-------+ +-------+ +------= --+ > >>> |Switch, | | | | | | | |Switch= , | > >>> | Router |-----| LER |-----| LSR |-----| LER |-----| Route= r | > >>> | OC/BC | | BC | | TC | | BC | | OC/BC= | > >>> +--------+ +-------+ +-------+ +-------+ +------= --+ > >>> > >>> Figure (2) - Deployment example 2 of timing over MPLS network > >>> > >>> > >>> Another example is shown in Figure 3, where LERs do not terminate= the > >>> Timing messages received from switch/routers that are outside of t= he > >>> MPLS network acting as OC, TC or BC. The LERs act as TC and updat= e > >>> the Timing field in the Timing messages as they transit the LER, > >>> while encapsulating them in timing LSP. The LSRs also act as > >>> Transparent Clock (TC) and just update the Timing field in the Tim= ing > >>> messages which are already encapsulated in Timing LSPs. > >>> > >>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ > >>> |Switch, | | | | | | | |Switc= h, | > >>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rout= er | > >>> |OC/TC/BC| | TC | | TC | | TC | |OC/TC= /BC| > >>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ > >>> > >>> Figure (3) - Deployment example 3 of timing over MPLS network > >>> > >>> Another example is shown in Figure 4, where LERs and LSRs support > >>> Boundary Clocks. A single-hop LSP is created between two adjacent > >>> LSRs engaged in BC operation. Other methods such as PTP transport > >>> over Ethernet MAY be used for transporting timing messages if the > >>> link between the two routers is Ethernet. > >>> > >>> +--------+ +-------+ +-------+ +-------+ +------= --+ > >>> |Switch, | | | | | | | |Switch= , | > >>> | Router |-----| LER |-----| LSR |-----| LER |-----| Route= r | > >>> | OC/BC | | BC | | BC | | BC | | OC/BC= | > >>> +--------+ +-------+ +-------+ +-------+ +------= --+ > >>> > >>> Figure (4) - Deployment example 3 of timing over MPLS network > >>> > >>> An MPLS domain MAY serve multiple customers. In these cases the > MPLS > >>> domain (maintained by a service provider) may provide timing servi= ces > >>> to multiple customers, each having their own Timing domain. > >>> > >>> The Timing over MPLS architecture assumes full mesh of Timing LSPs > >>> between all LERs supporting this specification. > >>> > >>> SB> Note sure this is right - the salves surely do not need to > >>> SB> exchange timing amongst themselves > >>> > >>> It supports > >>> Point-to- point (VPWS) and Multipoint (VPLS) services. > >>> > >>> SB> What does that mean? You do not carry user data traffic? > >>> SB> Maybe it's the ordering of the statemnets that is causing > >>> SB> confusion. > >>> > >>> This means > >>> that a customer may purchase a Point-to-point Timing service betwe= en > >>> two customer sites or a Multipoint Timing service between more tha= n > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 1= 0] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> two customer sites. > >>> > >>> The Timing over MPLS architecture supports P2P or P2MP Timing LSPs= . > >>> This means that the Timing Multicast messages such as PTP Multicas= t > >>> event messages can be transported over P2MP Timing LSP or be > >>> replicated and transported over many P2P Timing LSPs. > >>> > >>> SB> Note we do not yet have a definition of a P2MP mpls-tp LSP > >>> SB> nor a P2MP PW, although we are close. > >>> > >>> Timing messages, that do not require Time stamping or Correction > >>> Field update MAY be transported over Timing LSPs to simplify hardw= are > >>> and software. > >>> > >>> PTP Announce messages that determine the Timing LSP terminating > point > >>> behavior such as BC/OC/TC SHOULD be transported over the Timing LS= P > >>> to simplify hardware and software. > >>> > >>> SB> have you defined and referenced PTP announce msgs? > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 1= 1] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 5. Dedicated LSPs for Timing messages > >>> > >>> Many methods have been considered for identifying the Timing > messages > >>> when they are encapsulated in MPLS such as using GAL/G-ACH or a ne= w > >>> reserved label. These methods were not attractive since they eith= er > >>> required deep packet inspection at line rate in the intermediate L= SRs > >>> or they required use of a scarce new reserved label. Also one of= the > >>> goals was to reuse existing OAM mechanisms. > >>> > >>> SB> RLs =3D SPLs are not so rare now. In any case needs a ref. > >>> > >>> The method defined in this document can be used by LER and LSRs to > >>> identify Timing messages in MPLS tunnels by just looking at the to= p > >>> label in the MPLS label stack, which only carry Timing messages as > >>> well as OAM, but not data plane client traffic. > >>> > >>> Compliant implementations MUST use dedicated LSPs to carry Timing > >>> messages over MPLS. > >>> > >>> SB> I think that we need a definition of the properies of these LSPs > >>> > >>> These LSPs are herein referred to as "Timing > >>> LSPs" and the labels associated with these LSPs as "Timing LSP > >>> labels". The Timing LSPs that runs between Ingress and Egress LER= s > >>> MUST be co-routed. Alternatively, a single bidirectional co-route= d > >>> LSP can be used. > >>> > >>> SB> I though that you said you could use M2MP LSPs - these are not > >>> SB> bidirectional. > >>> > >>> Co-routing of the two directions is required to limit the differen= ce > >>> in the delays in the Master clock to Slave clock direction compare= d > >>> to the Slave clock to Master clock direction. The Timing LSP MAY= be > >>> MPLS/MPLS-TP LSP. > >>> > >>> The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS. > >>> New Extensions to RSVP-TE/GMPLS TLVs are required; however they ar= e > >>> outside the scope of this document. > >>> > >>> The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such= as > >>> BFD and LSP Ping but the LSP data plane client plane traffic MUST= be > >>> Timing packets only. > >>> > >>> SB> Why? > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 1= 2] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 6. Timing over LSP Encapsulation > >>> > >>> The encapsulations is not LSP is it? > >>> > >>> This document defines two methods for carrying Timing messages ove= r > >>> MPLS. The first method is carrying UDP/IP encapsulated Timing > >>> messages over Timing LSPs, and the second method, is carrying > >>> Ethernet encapsulated Timing messages over Ethernet PWs inside > Timing > >>> LSPs. > >>> > >>> 6.1. Timing over UDP/IP over MPLS Encapsulation > >>> > >>> The simplest method of transporting Timing messages over MPLS is t= o > >>> encapsulate Timing PDUs in UDP/IP and then encapsulate them in > Timing > >>> LSP. This format is shown in Figure 4. > >>> > >>> > >>> +----------------------+ > >>> | Timing LSP Label | > >>> +----------------------+ > >>> | IPv4/6 | > >>> +----------------------+ > >>> | UDP | > >>> +----------------------+ > >>> | Timing PDU | > >>> +----------------------+ > >>> > >>> Figure (4) - Timing over UDP/IP over MPLS Encapsulation > >>> > >>> > >>> This encapsulation is very simple and is useful when the network > >>> between Timing Master Clock and Slave Clock is MPLS network. > >>> > >>> SB> Simple is a judgement call > >>> > >>> In order for an LER/LSR to process Timing messages, the Timing LSP > >>> Label must be at the top label of the label stack. The LER/LSR MU= ST > >>> know that the Timing LSP Label is used for carrying Timing message= s. > >>> This can be accomplished via static configuration or via RSVP-TE > >>> signaling. > >>> > >>> The UDP/IP encapsulation of PTP MUST follow Annex D and E of > >>> [IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow > >>> [RFC5905]. > >>> > >>> 6.2. Timing over PW Encapsulation > >>> > >>> Another method of transporting Timing over MPLS networks is by > >>> encapsulating Timing PDUs in PW which in turn is transported over > >>> Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448], > >>> shown in Fig 5(A) MUST be used and the Ethernet encapsulation of P= TP > >>> MUST follow Annex F of [IEEE-1588]. > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 1= 3] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> The RAW mode or Tagged mode defined in [RFC4448] MAY be used and > the > >>> Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The > >>> Timing over PW encapsulation MUST use the Control Word (CW) as > >>> specified in [RFC4448] to ensure proper detection of PTP messages > >>> inside the MPLS packets for Timing over LSP and Timing over PW > >>> encapsulation. > >>> > >>> SB> That needs explanation > >>> > >>> The use of Sequence Number in the CW is optional. > >>> > >>> SB> Given that s/n are never in practice deployed, you could probably > >>> SB> simplify things by sayig that they are not used. > >>> > >>> Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over > PW > >>> (the IP PW discussed in [RFC4447]) shown in Fig 5(B). > >>> > >>> +----------------+ +----------------+ > >>> |Timing LSP Label| |Timing LSP Label| > >>> +----------------+ +----------------+ > >>> | PW Label | | PW Label | > >>> +----------------+ +----------------+ > >>> | Control Word | | IP | > >>> +----------------+ +----------------+ > >>> | Ethernet | | UDP | > >>> | Header | +----------------+ > >>> +----------------+ | Timing PDU | > >>> |S-VLAN(Optional)| | | > >>> +----------------+ +----------------+ > >>> |C-VLAN(Optional)| (B) > >>> +----------------+ > >>> | Timing PDU | > >>> | | > >>> +----------------+ > >>> (A) > >>> > >>> Figure (5) - Timing over PW Encapsulations > >>> > >>> In order for an LSR to process PTP messages, the top label of the > >>> label stack (the Tunnel Label) MUST be a Timing label. > >>> > >>> S> You said that before. > >>> > >>> 6.3. Other Timing Encapsulation methods > >>> > >>> In future other timing encapsulation methods may be introduced, su= ch > >>> as a new shim header after the Bottom of Stack to carry the Timing > >>> information. Such new encapsulations are outside the scope of thi= s > >>> document. > >>> > >>> > >>> SB> Taking a pure MPLS pov, you can simplify a lot of the text > >>> SB> out of the definition of the LSP > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 1= 4] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> SB> I think we need a section on LSP processing > >>> > >>> 7. Timing message Processing > >>> > >>> Each Timing protocol such as PTP and NTP, define their set of Timi= ng > >>> messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, > >>> FOLLOW_UP, etc messages. > >>> > >>> Some of the Timing messages require time stamping or correction fi= eld > >>> update at port level and some dont. It is the job of the LER/LSR= to > >>> parse the timing message and find out the type of the Timing messa= ge > >>> and decide whether and how to Time- stamp it (e.g., BC) or update > >>> correction field(e.g., TC). > >>> > >>> > >>> SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing > >>> SB> function rather than the LER? > >>> > >>> For example the following PTP messages (called Event messages) > >>> require time-stamping or correction field update: > >>> > >>> o SYNC > >>> > >>> o DELAY_REQ (Delay Request) > >>> > >>> o PDELAY_REQ (Peer Delay Request) > >>> > >>> o PDELAY_RESP (Peer Delay Response) > >>> > >>> SYNC and DELAY_REQ are exchanged between Master Clock and Slave > Clock > >>> and MUST be transported over PTP LSPs. PDELAY_REQ and > PDELAY_RESP > >>> are exchanged between adjacent PTP clocks (i.e. Master, Slave, > >>> Boundary, or Transparent) and SHOULD be transported over single ho= p > >>> PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP, > >>> and PDELAY_RESP_FOLLOW_UP messages MUST also be transported > over > >>> the > >>> PTP LSPs. > >>> > >>> For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be > >>> transported over two PTP LSPs that are in opposite directions. Th= ese > >>> PTP LSPs, which are in opposite directions MUST be congruent and c= o- > >>> routed. Alternatively, a single bidirectional co-routed LSP can b= e > >>> used. > >>> > >>> Except as indicated above for the two-step PTP clocks, Non-Event P= TP > >>> message types do not need to be processed by intermediate routers. > >>> These message types MAY be carried in PTP Tunnel LSPs. > >>> > >>> SB> Are you saying that a timing P router has to be msg type sensitive= ? > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 1= 5] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 8. Protection and Redundancy > >>> > >>> > >>> SB> This is a bit of a jump - I don't know how the LSP itself works ye= t! > >>> > >>> In order to ensure continuous uninterrupted operation of slave > >>> clocks, usually as a general practice, slave clocks (or ports) tra= ck > >>> redundant master clocks. > >>> > >>> It is the responsibility of the network operator to ensure that > >>> physically disjoint Timing LSPs are established between a slave cl= ock > >>> (or port) and redundant master clocks (or ports). > >>> > >>> When a slave clock (or port) listens to redundant master clocks or > >>> ports, any prolonged Timing LSP outage will trigger the slave cloc= k > >>> or port to switch to a redundant master clock or port. > >>> > >>> LSP/PW protection such as Linear protection Switching (1:1, 1+1), > >>> Ring protection switching or MPLS Fast Reroute (FRR) generally swi= tch > >>> alternative path that usually cause a change in delay, which if > >>> undetected by slave clock can reduce accuracy of the slave clock. > >>> > >>> Therefore protection switching MAY be used, as long as phase jumps > >>> upon switchover due to differences in path latency are detected an= d > >>> compensated for (such compensation not being required if BCs or pe= er- > >>> peer TCs are used throughout). > >>> > >>> Note that any protection or reroute mechanism that adds additional > >>> MPLS label to the label stack, such as Facility Backup Fast Rerout= e, > >>> MUST ensure that the pushed label is also a Timing Label to ensure > >>> recognition of the MPLS frame as containing Timing messages, as it > >>> transits the backup path. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 1= 6] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 9. ECMP > >>> > >>> To ensure the optimal operation of slave clocks and avoid error > >>> introduced by forward and reverse path delay asymmetry, the physic= al > >>> path for Timing messages from master clock to slave Clock and vice > >>> versa must be the same for all Event Timing messages listed in > >>> section 7. > >>> > >>> Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost > >>> Multipath). > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 1= 7] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 10. PHP > >>> > >>> To ensure that the label on the top of the label stack is the Timi= ng > >>> LSP Label, PHP MUST not be used. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 1= 8] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 11. Entropy > >>> > >>> To ensure all Timing messages in a Timing LSP take the same path, > >>> Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and > >>> Entropy Label MUST NOT be used for the PWs that are carried inside > >>> Timing LSP [RFC6391]. > >>> > >>> SB> This is incorrect - you mean that all msgs of the same timing > >>> SB> flow need to have the same EL value. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 1= 9] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 12. OAM, Control and Management > >>> > >>> In order to monitor Timing LSPs and their encapsulated PWs, they M= UST > >>> be able to carry OAM and management messages. These management > >>> messages MUST be differentiated from Timing messages via already > >>> defined IETF methods. > >>> > >>> For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY ru= n > >>> over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These > >>> Management protocols can easily be identified by the UDP Destinati= on > >>> Port number or by GAL/G-ACH respectively. > >>> > >>> Also BFD, LSP-Ping and other management messages MAY run over the > PWs > >>> encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3= or > >>> 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is go= ing > >>> to be deprecated by IETF). In this case G-ACH, PW label (TTL=3D1)= or > >>> GAL-ACH are used to identify such management messages. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 2= 0] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 13. QoS Considerations > >>> > >>> In network deployments where not every LSR/LER is Timing-aware, it= is > >>> important to reduce the impact of the non-Timing-aware LSR/LERs on > >>> the timing recovery in the slave clock. The Timing messages are t= ime > >>> critical and must be treated with the highest priority. Therefore > >>> Timing over MPLS messages must be treated with the highest priorit= y > >>> in the routers. This can be achieved by proper setup of Timing LS= Ps. > >>> > >>> It is recommended that the Timing LSPs are setup or configured > >>> properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC269= 7] > >>> for drop eligibility. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 2= 1] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 14. FCS and Checksum Recalculation > >>> > >>> When time-stamp generation and timing packet adjustment is perform= ed > >>> near the physical port hardware, the process MUST include > >>> recalculation of the Ethernet FCS. > >>> > >>> SB> The above is confusing - an LSR always recomputes the link layer > >>> SB> CRC which may or may not be Ethernet. > >>> > >>> Also FCS retention for the > >>> payload Ethernet described in [RFC4720] MUST NOT be used. > >>> > >>> For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksu= m > >>> may be required as per UDP transport standards. > >>> > >>> SB> You really need to be working on getting the IPv6 C?S computation > >>> SB> removed from PTP msgs. > >>> > >>> When UDP checksum is used, each Timing-aware LER/LSR must either > >>> incrementally update the UDP checksum after Time stamping or > >>> Correction Field update or verify the UDP checksum on reception fr= om > >>> upstream and recalculate the checksum completely on transmission t= o > >>> downstream node after Time stamping or Correction Field update. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 2= 2] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 15. Behavior of LER/LSR > >>> > >>> Timing-capable/aware LERs and LSRs are routers that have one or mo= re > >>> > >>> SB> You mean physical interfaces? > >>> > >>> interfaces that can perform Timing operations (OC/BC/TC) on Timing > >>> packets and are configured to do so. Timing-capable/aware LERs an= d > >>> LSRs can advertise their Timing-capability per-interface via contr= ol > >>> plane such as OSPF or IS-IS. > >>> SB> ISIS and OSPF are routing protocols. > >>> > >>> The Timing-capable/aware LERs can then > >>> signals Timing LSPs via RSVP-TE signaling. Alternatively the Timi= ng > >>> capability of LER and LSRs may be configured in a centralized > >>> controller and the Timing LSP may be setup using manual configurat= ion > >>> or other methods such as SDN. > >>> > >>> SB> it can also be configured individually rather then through > >>> SB> a cebtral controllwe > >>> > >>> 15.1. Behavior of Timing-capable/aware LER > >>> > >>> When a Timing-capable/aware LER behaves as a Transparent clock and > >>> receives a Timing message from a Timing-capable/aware non-MPLS > >>> interface, the LER updates the Correction Field (CF) and encapsula= tes > >>> and forwards the timing message over previously established Timing > >>> LSP. > >>> > >>> SB> You need to call out the details so that people properly > >>> SB> understand the definition of the new LSP. > >>> > >>> Also when a Timing message is received from a Timing-capable/ > >>> aware MPLS interface, LER updates the Correction Filed (CF) and > >>> decapsulates the MPLS encapsulation and forwards the timing messag= e > >>> to a non-MPLS interface. > >>> > >>> When a Timing-capable/aware LER behaves as a Boundary clock and > >>> receives a Timing message from a Timing-capable/aware non MPLS > >>> interface, the LER Timestamps the Timing packet and sends it to th= e > >>> LERs Boundary clock processing module. Also when a Timing message= is > >>> received from a Timing- capable/aware MPLS interface, the LER > >>> Timestamps the Timing packet and sends it to the LERs Boundary clo= ck > >>> processing module. > >>> > >>> When a Timing-capable/aware LER behaves as an Ordinary Clock towar= d > >>> the MPLS network, and receives a Timing message from a Timing- > >>> capable/aware MPLS interface, the LER Timestamps the Timing packet > >>> and sends it to the LERs Ordinary clock processing module. > >>> > >>> 15.2. Behavior of Timing-capable/aware LSR > >>> > >>> When a Timing-capable/aware LSR behaves as a Transparent clock and > >>> receives a Timing message from a Timing-capable/aware MPLS > interface, > >>> The LSR updates the Correction Filed (CF) and forwards the timing > >>> message over another MPLS interface. > >>> > >>> When a Timing-capable/aware LSR behaves as a Boundary clock and > >>> receives a Timing message from a Timing-capable/aware MPLS > interface. > >>> The LSR performs the functions of a Boundary Clock in terminating= the > >>> received Timing message and re-generating a new timing message ove= r > >>> another (or the same) MPLS interface. > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 2= 3] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 15.3. Behavior of non-Timing-capable/aware LSR > >>> > >>> It is most beneficial when all LSRs in the path of a Timing LSP be > >>> timing-Capable/aware LSRs. This would ensure the highest quality > >>> time and clock synchronization by Timing Slave Clocks. However, t= his > >>> specification does not mandate that all LSRs in path of a Timing L= SP > >>> be Timing- capable/aware. > >>> > >>> Non-Timing-capable/aware LSRs just switch the packets encapsulated= in > >>> Timing LSPs and dont perform any Timing operation (TC or BC). > >>> However as explained in QoS section the Timing over MPLS packets > MUST > >>> be still be treated with the highest priority based on their Traff= ic > >>> Class (TC) marking. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 2= 4] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 16. Other considerations > >>> > >>> [IEEE-1588] defines an optional peer-to-peer Transparent clocking > >>> that requires peer delay measurement between two adjacent Timing- > >>> capable/ aware routers/switches. Peer delay measurement messages > >>> need to be time stamped and terminated by the Timing-capable/aware > >>> routers/ switches. This means that two adjacent LSRs may be engag= ed > >>> in a peer delay measurement. > >>> > >>> For transporting such peer delay measurement messages a single-hop > >>> LSP SHOULD to be created between the two adjacent LSRs engaged in > >>> peer delay measurement to carry peer delay measurement messages. > >>> Other methods such as PTP transport over Ethernet MAY be used for > >>> transporting peer delay measurement messages if the link between t= he > >>> two routers is Ethernet. > >>> > >>> In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ w= are > >>> routers/switches MUST maintain a list of all the neighbors it need= s > >>> to send a PDelay_Req to, where each neighbor corresponds to a timi= ng > >>> LSP. > >>> > >>> The use of Explicit Null Label (Label=3D 0 or 2) is acceptable as= long > >>> as either the Explicit Null label is the bottom of stack label > >>> (applicable only to UDP/IP encapsulation) or the label below the > >>> Explicit Null label is a PTP label. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 2= 5] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 17. Security Considerations > >>> > >>> MPLS PW security considerations in general are discussed in [RFC39= 85] > >>> and [RFC4447],and those considerations also apply to this document= . > >>> > >>> An experimental security protocol is defined in [IEEE-1588].The PT= P > >>> security extension and protocol provides group source authenticati= on, > >>> message integrity, and replay attack protection for PTP messages. > >>> > >>> When the MPLS network (provider network) serves multiple customers= , > >>> it is important to maintain and process each customers clock and > >>> Timing messages separately from other customers to ensure there is= no > >>> cross- customer effect. For example if an LER BC is synchronized= to > >>> a specific grandmaster, belonging to customer A, then the LER MUST > >>> use that BC clock only for customer A to ensure that customer A > >>> cannot attack other customers by manipulating its time. > >>> > >>> Timing messages MAY be encrypted or authenticated, provided that t= he > >>> LERs/LSRs that are Timing capable/aware can authenticate/ decrypt= the > >>> timing messages. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 2= 6] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 18. Acknowledgements > >>> > >>> The authors would like to thank Ron Cohen, Yaakov Stein, Tal Mizra= hi, > >>> Stefano Ruffini, Peter Meyer, and other members of IETF for review= ing > >>> and providing feedback on this draft. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 2= 7] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 19. IANA Considerations > >>> > >>> There are no IANA requirements in this specification. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 2= 8] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 20. References > >>> > >>> 20.1. Normative References > >>> > >>> [IEEE-1588] > >>> IEEE 1588-2008, "IEEE Standard for a Precision Clock > >>> Synchronization Protocol for Networked Measurement and > >>> Control Systems". > >>> > >>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > >>> Requirement Levels", BCP 14, RFC 2119, March 1997. > >>> > >>> [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- > >>> Edge (PWE3) Architecture", RFC 3985, March 2005. > >>> > >>> [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discove= ry > >>> Proxies (ND Proxy)", RFC 4389, April 2006. > >>> > >>> [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. > >>> Heron, "Pseudowire Setup and Maintenance Using the Labe= l > >>> Distribution Protocol (LDP)", RFC 4447, April 2006. > >>> > >>> [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, > >>> "Encapsulation Methods for Transport of Ethernet over M= PLS > >>> Networks", RFC 4448, April 2006. > >>> > >>> [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire > >>> Emulation Edge-to-Edge (PWE3) Frame Check Sequence > >>> Retention", RFC 4720, November 2006. > >>> > >>> [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circui= t > >>> Connectivity Verification (VCCV): A Control Channel for > >>> Pseudowires", RFC 5085, December 2007. > >>> > >>> [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detecti= on > >>> (BFD)", RFC 5880, June 2010. > >>> > >>> [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, > >>> "Bidirectional Forwarding Detection (BFD) for MPLS Labe= l > >>> Switched Paths (LSPs)", RFC 5884, June 2010. > >>> > >>> 20.2. Informative References > >>> > >>> [I-D.ietf-pwe3-fat-pw] > >>> Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Rega= n, > >>> J., and S. Amante, "Flow Aware Transport of Pseudowires > >>> over an MPLS Packet Switched Network", > >>> draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011= . > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 2= 9] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediat= e > >>> system routeing information exchange protocol for use i= n > >>> conjunction with the Protocol for providing the > >>> Connectionless-mode Network Service (ISO 8473)". > >>> > >>> [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and > >>> dual environments", RFC 1195, December 1990. > >>> > >>> [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998= . > >>> > >>> [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color > >>> Marker", RFC 2697, September 1999. > >>> > >>> [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boude= c, > >>> J., Courtney, W., Davari, S., Firoiu, V., and D. > >>> Stiliadis, "An Expedited Forwarding PHB (Per-Hop > >>> Behavior)", RFC 3246, March 2002. > >>> > >>> [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineer= ing > >>> (TE) Extensions to OSPF Version 2", RFC 3630, > >>> September 2003. > >>> > >>> [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediat= e > >>> System (IS-IS) Extensions for Traffic Engineering (TE)"= , > >>> RFC 3784, June 2004. > >>> > >>> [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S= . > >>> Shaffer, "Extensions to OSPF for Advertising Optional > >>> Router Capabilities", RFC 4970, July 2007. > >>> > >>> [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate > >>> System to Intermediate System (IS-IS) Extensions for > >>> Advertising Router Information", RFC 4971, July 2007. > >>> > >>> [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi > >>> Topology (MT) Routing in Intermediate System to > >>> Intermediate Systems (IS-ISs)", RFC 5120, February 2008= . > >>> > >>> [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic > >>> Engineering", RFC 5305, October 2008. > >>> > >>> [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, > >>> "Traffic Engineering Extensions to OSPF Version 3", > >>> RFC 5329, September 2008. > >>> > >>> [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF > >>> for IPv6", RFC 5340, July 2008. > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 3= 0] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Netw= ork > >>> Time Protocol Version 4: Protocol and Algorithms > >>> Specification", RFC 5905, June 2010. > >>> > >>> [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Rega= n, > >>> J., and S. Amante, "Flow-Aware Transport of Pseudowires > >>> over an MPLS Packet Switched Network", RFC 6391, > >>> November 2011. > >>> > >>> [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., an= d > >>> L. Yong, "The Use of Entropy Labels in MPLS Forwarding"= , > >>> RFC 6790, November 2012. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 3= 1] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 1. Routing extensions for Timing-aware Routers > >>> > >>> MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] a= nd > >>> IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (T= E) > >>> link information used for constraint-based routing. > >>> > >>> Indeed, it is useful to advertise data plane TE router link > >>> capabilities, such as the capability for a router to be Timing-awa= re. > >>> This capability MUST then be taken into account during path > >>> computation to prefer or even require links that advertise themsel= ves > >>> as Timing-aware. In this way the path can ensure the entry and ex= it > >>> points into the LERs and, if desired, the links into the LSRs are > >>> able to perform port based time-stamping thus minimizing their imp= act > >>> on the performance of the slave clock. > >>> > >>> extensions are required to OSPF and IS-IS in order to advertise > >>> Timing-aware capabilities of a link. Such extensions are outside= the > >>> scope of this document; however such extension SHOULD be able to > >>> signal the following information per Router Link: > >>> > >>> o Capable of processing PTP, NTP or other Timing flows > >>> > >>> o Capable of performing Transparent Clock operation > >>> > >>> o Capable of performing Boundary Clock operation > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 3= 2] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> 2. Signaling Extensions for Creating Timing LSPs > >>> > >>> RSVP-TE signaling MAY be used to setup the timing LSPs. When RSVP= -TE > >>> is used to setup Timing LSPs, some information that indicates that > >>> the LSP is carrying Timing flows MUST be included in the new > >>> Extensions to RSVP-TE: > >>> > >>> The following information MAY also be included in the new Extensio= ns > >>> to RSVP-TE: > >>> > >>> o Offset from Bottom of Stack (BoS) to the start of the Time-stam= p > >>> field > >>> > >>> o Number of VLANs in case of PW encapsulation > >>> > >>> o Timestamp field Type > >>> > >>> * Correction Field, Timestamp > >>> > >>> o Timestamp Field format > >>> > >>> * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit > >>> NTP, etc. > >>> > >>> Note that in case the above optional information is signaled with > >>> RSVP-TE for a Timing LSP, all the Timing packets carried in that L= SP > >>> must have the same signaled characteristics. For example if > >>> Timestamp format is signaled as 64-bit PTPv1, then all Timing pack= ets > >>> must use 64-bit PTPv1 time-stamp. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 3= 3] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> Authors' Addresses > >>> > >>> Shahram Davari > >>> Broadcom Corp. > >>> San Jose, CA 95134 > >>> USA > >>> > >>> Email: davari@broadcom.com > >>> > >>> > >>> Amit Oren > >>> Broadcom Corp. > >>> San Jose, CA 95134 > >>> USA > >>> > >>> Email: amito@broadcom.com > >>> > >>> > >>> Manav Bhatia > >>> Alcatel-Lucent > >>> Bangalore, > >>> India > >>> > >>> Email: manav.bhatia@alcatel-lucent.com > >>> > >>> > >>> Peter Roberts > >>> Alcatel-Lucent > >>> Kanata, > >>> Canada > >>> > >>> Email: peter.roberts@alcatel-lucent.com > >>> > >>> > >>> Laurent Montini > >>> Cisco Systems > >>> San Jose CA > >>> USA > >>> > >>> Email: lmontini@cisco.com > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 3= 4] > >>> Internet-Draft Transporting Timing over MPLS June 20= 13 > >>> > >>> > >>> Luca > >>> Cisco Systems > >>> San Jose CA > >>> USA > >>> > >>> Email: lmartini@cisco.com > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Davari, et al. Expires December 17, 2013 [Page 3= 5] > >>> -- > >>> For corporate legal information go to: > >>> > >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html > >>> > >>> _______________________________________________ > >>> TICTOC mailing list > >>> TICTOC@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tictoc > >> > >> 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 > > . > > > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > > > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc 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 loa@pi.nu Tue Aug 6 02:50:30 2013 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 1FF4021F9C28 for ; Tue, 6 Aug 2013 02:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4lIoR08KPoi for ; Tue, 6 Aug 2013 02:50:22 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD7F21F8FCE for ; Tue, 6 Aug 2013 02:50:17 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 039A31801570; Tue, 6 Aug 2013 11:50:15 +0200 (CEST) Message-ID: <5200C6DD.9000609@pi.nu> Date: Tue, 06 Aug 2013 11:50:21 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-targeted-mldp@tools.ietf.org Subject: [mpls] Implementation Poll on draft-ietf-mpls-targeted-mldp 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, 06 Aug 2013 09:50:30 -0000 Working Group, draft-ietf-mpls-targeted-mldp has been updated after working group last call (version -03) and we are almost ready to send it to the IESG with a request for publication. In preparing the shepherd write-up we need information on existing implementations. This is to start a poll for implementations of draft-ietf-mpls-targeted-mldp. If you have an implementation please respond to the mailing-list or directly to the wg-chairs. /Loa for the wg chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From internet-drafts@ietf.org Tue Aug 6 04:09:31 2013 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 38E0321F9BF7; Tue, 6 Aug 2013 04:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 S1BmVlYgJSdY; Tue, 6 Aug 2013 04:09:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB0F21F9BCA; Tue, 6 Aug 2013 04:09:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130806110930.32553.33044.idtracker@ietfa.amsl.com> Date: Tue, 06 Aug 2013 04:09:30 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-mldp-node-protection-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: Tue, 06 Aug 2013 11:09:31 -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 Gro= up of the IETF. Title : mLDP Node Protection Author(s) : IJsbrand Wijnands Eric Rosen Kamran Raza Jeff Tantsura Alia Atlas Huawei Technology Filename : draft-ietf-mpls-mldp-node-protection-00.txt Pages : 16 Date : 2013-08-06 Abstract: This document describes procedures to support node protection for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (MP LSPs) built by LDP ("Label Distribution Protocol"), or simply mLDP. In order to protect a node N, the Point of Local Repair (PLR) LSR of N must learn the Merge Point (MPT) LSR(s) of node N such that traffic can be redirected to them in case node N fails. Redirecting the traffic around the failed node N depends on existing P2P LSPs originated from the PLR LSR to the MPT LSRs while bypassing LSR node N. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-node-protection There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-mldp-node-protection-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From davarish@yahoo.com Tue Aug 6 06:35:30 2013 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 F1CF921F9CF1 for ; Tue, 6 Aug 2013 06:35: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=[BAYES_00=-2.599, 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 DweE0YPnnI7x for ; Tue, 6 Aug 2013 06:35:25 -0700 (PDT) Received: from nm15.bullet.mail.bf1.yahoo.com (nm15.bullet.mail.bf1.yahoo.com [98.139.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 79FA621F9C99 for ; Tue, 6 Aug 2013 06:35:24 -0700 (PDT) Received: from [98.139.212.147] by nm15.bullet.mail.bf1.yahoo.com with NNFMP; 06 Aug 2013 13:35:22 -0000 Received: from [98.139.211.199] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 06 Aug 2013 13:35:22 -0000 Received: from [127.0.0.1] by smtp208.mail.bf1.yahoo.com with NNFMP; 06 Aug 2013 13:35:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1375796122; bh=GyRmXObHO/J+l9hhJ5xWBh9mIjV1vt/Eq75FXXAxScc=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=WQvCjf+nMPOHoxrdw+X/EzR6ecX/caNXqbasmtDzbjjQeRx5g1Fpq9XIhat84AlO3Z0J7j/DnLQuBdswksZcgvKrPK2XXPz3YriXKKCc/jPmRvq2mGA6hc7sW8+tRfVGNIwLBpVmUYtWWKd1Lnofsh1UfN7Ti7lptU9GadGuSQo= X-Yahoo-Newman-Id: 482266.10068.bm@smtp208.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: bF6jTbAVM1ksMcJmHbO4rXWaSwGE4M6qiD46htd5rfB9YVV k7YG39zJ.Yjq93nPvQ8Bhxd2Ime.HAmvHMpppbUE2MLY2hlPk9S3ZVjf7kf_ qZeBo0nHYt1KEQhkWUA27uFQpjTYws0sX970GCCeYKELL4sF36qxDXZyY2_o 3CNwA1J5s0VEB.7kThR.I45gxslG026vN5JztMyS3y_1S5BH4SXbFzN8met0 ymldn.dQ57WWh1rSwQu4wJVLdxvY266qQNnI_mGuI8bY2WHlsqCjpkO41q4k hA2gpMLLZ1.acImjzMtacit55NUmzew5Mb9kpoZ3TonYZXuO9tAxcl.BuWPi BOeoCSK9jBpH5nl0vJe6drTdw.ee1RXeOAAwy4027TYd7.HUuzf0GUiYHaTy 7h8Z1Tc9R5VKduBLVBKGfHPgZoIYLjpGO8ZeA1Tus1miGUUfzg5RVVZnDDwq t9L.cm3gFQP5DUIcW3fDhd4cIJ6RXDr6Q0riMASJ9RJVgWw4NUC40UOsKnj3 h65R1TUR5KvFxi_bHD8CFxMsJzB4eUG8_PyrXE4jodX2PsdNg X-Yahoo-SMTP: ygPrP9CswBCWPbPtKJlJyLY0KMlg X-Rocket-Received: from [192.168.0.103] (davarish@98.248.42.143 with ) by smtp208.mail.bf1.yahoo.com with SMTP; 06 Aug 2013 06:35:22 -0700 PDT References: <51FB7543.801@cisco.com> <51FF7068.9080600@cisco.com> <4A6CE49E6084B141B15C0713B8993F281BEC731A@SJEXCHMB12.corp.ad.broadcom.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A403) From: "S. Davari" Date: Tue, 6 Aug 2013 06:35:15 -0700 To: Alexander Vainshtein Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] Comments on draft-ietf-tictoc-1588overmpls 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, 06 Aug 2013 13:35:30 -0000 Sasha, If a router is not 1588 aware we want it to switch the packet with minimum j= itter and delay via high priority queue.=20 Sending it to CPU creates large jitter and delay since the CPUs are generall= y busy doing other things. Time stamping or updating CF in the CPU won't hel= p since it does not cover the variable delay that is incurred from the time t= he packet enters the router to the time the packet gets processed by CPU. I wish it was that easy! Regards, Shahram On Aug 6, 2013, at 12:38 AM, Alexander Vainshtein wrote: > Shahram, > I agree with you that the routers that do not recognize a Timing Alert lab= el would send the packet to the CPU. (This would be easy to arrange since we= are speaking about a reserved label.) >=20 > I do not, however, see this as a serious issue, because the SW running on t= his CPU would (hopefully) be upgradable to handle the packet correctly i.e.,= to forward it to where it should be forwarded and, if it is forwarded as a l= abeled packet, to prepend the Timing Alert Label on top of its label stack. I= t could even record the residence time (as observed by the CPU in the proper= place in the packet. This would mean that introducing additional error to w= hatever timing information is associated with this packet - but this is what= you should anyway expect if there are non-compliant routers on your path, r= ight? >=20 > Regards, > Sasha >=20 >> -----Original Message----- >> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf O= f >> Shahram Davari >> Sent: Monday, August 05, 2013 11:29 PM >> To: stbryant@cisco.com; S. Davari >> Cc: mpls@ietf.org; tictoc@ietf.org >> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls >>=20 >> Hi Stewart, >>=20 >> Your suggestion of " I suggested an LSP type that has the properties "tim= estamp >> and pass to application", is a subset of the existing draft and should wo= rk. It >> basically limits the time stamping and correction field update to LERs (w= hile the >> draft supports time stamping at LER and LSR). >>=20 >> However Sasha's suggestion of using a reserved label (RAL, GAL or any oth= er >> reserved label) does not satisfy one of the major requirements, which is >> backward compatibility. Routers that don't understand this reserved label= will >> drop or copy to CPU such packets. >>=20 >> Regards, >> Shahram >>=20 >> -----Original Message----- >> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf O= f >> Stewart Bryant >> Sent: Monday, August 05, 2013 2:29 AM >> To: S. Davari >> Cc: mpls@ietf.org; tictoc@ietf.org >> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls >>=20 >> My concern is that we are creating a new LSP type in MPLS >> (which is a architectural change and thus needs to be very carefully >> considered) without asking the question "how can I do this >> in the most general way, to maximize flexibility/reuse" >>=20 >> I suggested an LSP type that has the properties "timestamp >> and pass to application", but I think that Sasha raises a good >> point about using router alert. However RA has no implicit >> timestamp, so maybe we need a new type of RA that has the >> properties "timestamp, and pass top application indicated by >> the next label". That would be quite useful in a number >> of OAM applications. There is possibly some GAL variant >> of that design that should also be considered. >>=20 >> The application could worry about the path and where it >> was necessary to skip some hops a hierarchical LSP would >> accomplish that, with the specific benefit that the application >> would consciously do this, and may be able to apply some >> form of compensation within the network. >>=20 >> - Stewart >>=20 >> On 04/08/2013 10:40, S. Davari wrote: >>> Hi Sasha >>>=20 >>> Perhaps you have not understood the draft well. The main reason that the= >> draft chose to use a dedicated LSP that is signaled via RSVPTE indicating= it is a >> timing LSP is to be backward compatible with non-1588 nodes. Such nodes >> simply just switch the packet. >>>=20 >>> Your proposal had been considered and was rejected since it was not >> backward compatible. Nodes receiving alert label or TTL =3D 1 send the pa= cket to >> CPU. You can refer to the meeting notes. >>>=20 >>> Regards, >>> Shahram >>>=20 >>>=20 >>> On Aug 4, 2013, at 1:21 AM, Alexander Vainshtein >> wrote: >>>=20 >>>> Stewart and all, >>>> I concur with Stewart's statement that the draft does not define "full >> interaction with MPLS architecture". >>>>=20 >>>> E.g., one of the objectives of the draft is to provide a technique that= would >> be backward-compatible with old LSRs that cannot provide on-path support f= or >> timing distribution, while the other objective is to make every LSR on th= e path >> aware that some MPLS packets are carrying timing-related messages and hen= ce >> require on-path support. >>>>=20 >>>> IMHO and FWIW, the MPLS data plane architecture allows just two methods= >> for making a transit LSR to provide special processing to a labeled packe= t: >>>> - It would carry some kind of an "alert label" on top of the label stac= k and, >> specifically, on top of any labels used for actual forwarding >>>> OR, >>>> - The TTL in the top label stack entry has been set to 1. >>>>=20 >>>>=20 >>>> The draft does not follow any of these approaches. >>>>=20 >>>> I must also admit that Section 12 "OAM, Control and Management" of the >> draft looks somewhat in >>>> E.g., I could not understand from the text whether BFD, LSP-Ping etc. O= AM >> messages would be subjected to on-path support procedures for timing >> messages or not. >>>>=20 >>>> My 2c, >>>> Sasha >>>>=20 >>>>> -----Original Message----- >>>>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Beha= lf >> Of >>>>> Stewart Bryant >>>>> Sent: Friday, August 02, 2013 12:01 PM >>>>> To: mpls-chairs@tools.ietf.org; tictoc-chairs@tools.ietf.org; int- >>>>> ads@tools.ietf.org; rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.org= ; >> draft- >>>>> ietf-tictoc-1588overmpls@tools.ietf.org >>>>> Cc: mpls@ietf.org; tictoc@ietf.org >>>>> Subject: [TICTOC] Comments on draft-ietf-tictoc-1588overmpls >>>>>=20 >>>>> SB> This draft does not seem to provide a precise definition >>>>> SB> the properties of the new LSP type that it wishes to >>>>> SB> define, in particular it does it define the PHB of those >>>>> SB> LSPs, nor the full interaction with the MPLS >>>>> SB> architecture. >>>>> SB> >>>>> SB> I have not tracked TICTOC for a while but I thought that >>>>> SB> the original plan was to define the concept of an offset >>>>> SB> into a packet to do the correction. >>>>> SB> >>>>> SB> It is disappointing that the opportunity was not taken >>>>> SB> to define a timing shim inside the timing LSP so that >>>>> SB> a time correction could be added to any packet such that >>>>> SB> the MPLS system was isolated from the details of the >>>>> SB> complexity of the particular time transfer type. >>>>>=20 >>>>> SB> I think that much more clarify is needed in terms of >>>>> SB> definition of the new LSP type, since it is unclear >>>>> SB> from this text how to implement one. >>>>> SB> >>>>> SB> There are a lot of other MPLS services such as >>>>> SB> LSP ping that need to be considered. >>>>> SB> >>>>> SB> Please see inline for more comments. However these >>>>> SB> comments are made in the context of the text as written >>>>> SB> whilst I have a fundamental concern that this approach >>>>> SB> lacks an MPLS architectural soundness that need >>>>> SB> greater thought with significant impact on the >>>>> SB> draft. >>>>>=20 >>>>> - Stewart >>>>>=20 >>>>>=20 >>>>> TICTOC Working Group S. Dava= ri >>>>> Internet-Draft A. Or= en >>>>> Intended status: Standards Track Broadcom Cor= p. >>>>> Expires: December 17, 2013 M. Bhat= ia >>>>> P. Rober= ts >>>>> Alcatel-Luce= nt >>>>> L. Monti= ni >>>>> L. Marti= ni >>>>> Cisco Syste= ms >>>>> June 15, 20= 13 >>>>>=20 >>>>>=20 >>>>> Transporting Timing messages over MPLS Networks >>>>> draft-ietf-tictoc-1588overmpls-05 >>>>>=20 >>>>> Abstract >>>>>=20 >>>>> This document defines the method for transporting Timing messages >>>>> such as PTP and NTP over an MPLS network. The method allows for th= e >>>>> easy identification of these PDUs at the port level to allow for po= rt >>>>>=20 >>>>> SB> What is a port >>>>>=20 >>>>> level processing of these PDUs in both LERs and LSRs. >>>>>=20 >>>>> The basic idea is to transport Timing messages inside dedicated MPL= S >>>>> LSPs. These LSPs only carry Timing messages and possibly Control a= nd >>>>> Management packets, but they do not carry customer traffic. >>>>>=20 >>>>> SB> More specifically they only carry traffic associated with the >>>>> SB> timing service and its support. >>>>> SB> The question arose WRT BFD - surely BFD is allowed, BUT surely >>>>> SB> also it gets carried in a structure that causes it to get >>>>> SB> timestamped. >>>>>=20 >>>>> Two methods for transporting Timing messages over MPLS are defined.= >>>>>=20 >>>>> SB> Perhaps the right approach is to define the new LSP type and then >>>>> SB> seperately to define the mapping of the various timing services >>>>> SB> over that LSP type. >>>>>=20 >>>>> The first method is to transport Timing messages directly over the >>>>> dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for >>>>> MPLS networks. The second method is to transport Timing messages >>>>> inside a PW via Ethernet encapsulation. >>>>>=20 >>>>> SB> I think that we should note that there are some >>>>> SB> h/w reasons for this preference. A clean sheet approach >>>>> SB> would have been to use PTP over MPLS with no intermediate >>>>> SB> layers. >>>>>=20 >>>>> Status of this Memo >>>>>=20 >>>>> This Internet-Draft is submitted in full conformance with the >>>>> provisions of BCP 78 and BCP 79. >>>>>=20 >>>>> Internet-Drafts are working documents of the Internet Engineering >>>>> Task Force (IETF). Note that other groups may also distribute >>>>> working documents as Internet-Drafts. The list of current Internet= - >>>>> Drafts is at http://datatracker.ietf.org/drafts/current/. >>>>>=20 >>>>> Internet-Drafts are draft documents valid for a maximum of six mont= hs >>>>> and may be updated, replaced, or obsoleted by other documents at an= y >>>>> time. It is inappropriate to use Internet-Drafts as reference >>>>> material or to cite them other than as "work in progress." >>>>>=20 >>>>> This Internet-Draft will expire on December 17, 2013. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 1= ] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> Copyright Notice >>>>>=20 >>>>> Copyright (c) 2013 IETF Trust and the persons identified as the >>>>> document authors. All rights reserved. >>>>>=20 >>>>> This document is subject to BCP 78 and the IETF Trust's Legal >>>>> Provisions Relating to IETF Documents >>>>> (http://trustee.ietf.org/license-info) in effect on the date of >>>>> publication of this document. Please review these documents >>>>> carefully, as they describe your rights and restrictions with respe= ct >>>>> to this document. Code Components extracted from this document mus= t >>>>> include Simplified BSD License text as described in Section 4.e of >>>>> the Trust Legal Provisions and are provided without warranty as >>>>> described in the Simplified BSD License. >>>>>=20 >>>>>=20 >>>>> Table of Contents >>>>>=20 >>>>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 5 >>>>>=20 >>>>> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . = 7 >>>>>=20 >>>>> 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . = 8 >>>>>=20 >>>>> 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . = 9 >>>>>=20 >>>>> 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . . 1= 2 >>>>>=20 >>>>> 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . 1= 3 >>>>> 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . . 1= 3 >>>>> 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . . 1= 3 >>>>> 6.3. Other Timing Encapsulation methods . . . . . . . . . . . . 1= 4 >>>>>=20 >>>>> 7. Timing message Processing . . . . . . . . . . . . . . . . . . 1= 5 >>>>>=20 >>>>> 8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 1= 6 >>>>>=20 >>>>> 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1= 7 >>>>>=20 >>>>> 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1= 8 >>>>>=20 >>>>> 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . 1= 9 >>>>>=20 >>>>> 12. OAM, Control and Management . . . . . . . . . . . . . . . . . 2= 0 >>>>>=20 >>>>> 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 2= 1 >>>>>=20 >>>>> 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . . 2= 2 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 2= ] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 2= 3 >>>>> 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . . 2= 3 >>>>> 15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . . 2= 3 >>>>> 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . . 2= 4 >>>>>=20 >>>>> 16. Other considerations . . . . . . . . . . . . . . . . . . . . . 2= 5 >>>>>=20 >>>>> 17. Security Considerations . . . . . . . . . . . . . . . . . . . 2= 6 >>>>>=20 >>>>> 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 2= 7 >>>>>=20 >>>>> 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 2= 8 >>>>>=20 >>>>> 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 2= 9 >>>>> 20.1. Normative References . . . . . . . . . . . . . . . . . . . 2= 9 >>>>> 20.2. Informative References . . . . . . . . . . . . . . . . . . 2= 9 >>>>>=20 >>>>> Appendix 1. Routing extensions for Timing-aware Routers . . . . . 3= 2 >>>>>=20 >>>>> Appendix 2. Signaling Extensions for Creating Timing LSPs . . . . 3= 3 >>>>>=20 >>>>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 3= 4 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 3= ] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >> NOT", >>>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" >> in >>>>> this >>>>> document are to be interpreted as described in RFC2119 [RFC2119]. >>>>>=20 >>>>> When used in lower case, these words convey their typical use in >>>>> common language, and are not to be interpreted as described in >>>>> RFC2119 [RFC2119]. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 4= ] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 1. Introduction >>>>>=20 >>>>> The objective of Precision Time Protocol (PTP) and Network Timing >>>>> Protocol (NTP) are to synchronize independent clocks running on >>>>> separate nodes of a distributed system. >>>>>=20 >>>>> [IEEE-1588] defines PTP messages for frequency, phase and time >>>>> synchronization. The PTP messages include PTP PDUs over UDP/IP >>>>> (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex F o= f >>>>> [IEEE-1588]). >>>>>=20 >>>>> SB> Sure BUT it is acknowledged that IEEE is open to the definition >>>>> SB> of other PTP mappings if they provide better optimisation. >>>>>=20 >>>>> This document defines mapping and transport of the PTP >>>>> messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP >>>>> defines several clock types: ordinary clocks, boundary clocks, end-= >>>>> to-end transparent clocks, and peer-to-peer transparent clocks. >>>>> Transparent clocks require intermediate nodes to update correction >>>>> field inside PTP message that reflects the transit time in the node= . >>>>>=20 >>>>> [RFC5905] defines NTP messages for clock and time synchronization. >>>>> The PTP messages (PDUs) are transported over UDP/IP. This document= >>>>> SB> Should that be NTP messages? >>>>> SB> It needs to be made clear as soon as you introduce NTP that >>>>> SB> they use different time representations. >>>>>=20 >>>>> defines mapping and transport of the NTP messages defined in >>>>> [RFC5905] over MPLS networks. >>>>>=20 >>>>> One key attribute of all of these Timing messages is that the Time >>>>> stamp processing should occur as close as possible to the actual >>>>> transmission and reception at the physical port interface. This >>>>> targets optimal time and/or frequency recovery by avoiding variable= >>>>> delay introduced by queues internal to the clocks. >>>>>=20 >>>>> SB> As I recall NTP has no epoch point defined, and I am not sure >>>>> SB> where that point is in the case of PTP in this mapping >>>>> SB> Hopefully this will get defined in due course. >>>>>=20 >>>>> To facilitate the fast and efficient recognition of Timing messages= >>>>> at the port level when the Timing messages are carried over MPLS >>>>> LSPs, >>>>>=20 >>>>> SB> Over a new LSP type with time optimied characteristics >>>>>=20 >>>>> this document defines the specific encapsulations that should >>>>> be used. >>>>> SB> Hopefully it will also define the PHP >>>>>=20 >>>>> In addition, it can be expected that there will exist LSR/ >>>>> LERs where only a subset of the physical ports will have the port- >>>>> based Timing message processing capabilities. >>>>> SB> Do you need to clarify that this only works at base and not in >>>>> SB> a label heirarchy. >>>>>=20 >>>>>=20 >>>>> In order to ensure >>>>> that the LSPs carrying Timing packets always enter and exit ports >>>>> with this capability, routing extensions are defined to advertise >>>>> this capability on a port basis and to allow for the establishment o= f >>>>> LSPs that only transit such ports. While this path establishment >>>>> restriction may be applied only at the LER Ingress and/or egress >>>>> ports, it becomes more important when using transparent clock capab= le >>>>> LSRs in the path. >>>>> SB> I do not understand the implications of the last >>>>> SB> sentences - starting ", it becomes" >>>>>=20 >>>>>=20 >>>>> Port based Timing message processing involves Timing message >>>>> recognition. Once the Timing messages are recognized they can be >>>>> modified based on the reception or transmission Time-stamp. >>>>>=20 >>>>> This document provides two methods for transporting Timing messages= >>>>> over MPLS. One is applicable to MPLS environment and the other one= >>>>> is applicable to MPLS/MPLS-TP environment >>>>>=20 >>>>> SB> I think the sentence is incomplete. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 5= ] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> The solution involves transporting Timing messages over dedicated >>>>> LSPs called Timing LSPs. These LSPs carry Timing messages and MAY >>>>> carry Management and control messages, but not data plane client >>>>> traffic. >>>>>=20 >>>>> SB> It is not clear why this restriction applies. >>>>>=20 >>>>> Timing LSPs can be established statically or via signaling. >>>>> SB> s/statically/by provisioning/network management/ >>>>>=20 >>>>> Extensions to control plane (OSPF, ISIS, etc.) is required to enabl= e >>>>> routers to distribute their Timing processing capabilities over MPL= S >>>>> to other routers. However such extensions are outside the scope of= >>>>> this document. >>>>>=20 >>>>> When signaling is used to setup the PTP LSP, Extensions to signalin= g >>>>> SB> is it a PTP LSP or a Timing LSP? >>>>>=20 >>>>> protocols (e.g., RSVP-TE) are required for establishing PTP LSPs. >>>>> However such extensions are outside the scope of this document. >>>>>=20 >>>>> SB> for mpls-tp GMPLS is the signalling protocol >>>>>=20 >>>>> While the techniques included herein allow for the establishment of= >>>>> paths optimized to include Time-stamping capable links, the >>>>> performance of the Slave clocks is outside the scope of this >>>>> document. >>>>>=20 >>>>> At the time of publishing this specification, Transparent Clocking >>>>> (TC) is only defined for PTP. Therefore at this time any part of >>>>> this specification that talks about Transparent Clocking applies on= ly >>>>> to PTP. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 6= ] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 2. Terminology >>>>>=20 >>>>> 1588: The timing and synchronization as defined by IEEE 1588. >>>>>=20 >>>>> SB> I think that there is a more formal name for the 1588 group >>>>> SB> that needs to be used here. >>>>> SB> Also do we need to talk about 1588-200? as there is >>>>> SB> an update in progress >>>>>=20 >>>>> NTP: The timing and synchronization protocol defined by IETF RFC-13= 05 >>>>> and RFC-5905. >>>>>=20 >>>>> PTP: The timing and synchronization protocol used by 1588. >>>>> SB> need the proper name for 1588 >>>>>=20 >>>>> Master Clock: The source of 1588 timing to a set of slave clocks. >>>>>=20 >>>>> Master Port: A port on a ordinary or boundary clock that is in Mast= er >>>>> state. This is the source of timing toward slave ports. >>>>>=20 >>>>> SB> I am not sure the reader knows what a port is >>>>>=20 >>>>> Slave Clock: A receiver of 1588 timing from a master clock. >>>>>=20 >>>>> Slave Port: A port on a boundary clock or ordinary clock that is >>>>> receiving timing from a master clock. >>>>>=20 >>>>> Ordinary Clock: A device with a single PTP port. >>>>>=20 >>>>> Transparent Clock. A device that measures the time taken for a PTP= >>>>> event message to transit the device and then updates the >>>>> correctionField of the message with this transit time. >>>>>=20 >>>>> Boundary Clock: A device with more than one PTP port. Generally >>>>> boundary clocks will have one port in slave state to receive timing= >>>>> and then other ports in master state to re-distribute the timing. >>>>>=20 >>>>> PTP LSP: An LSP dedicated to carry PTP messages >>>>>=20 >>>>> SB> PTP or timing? >>>>>=20 >>>>>=20 >>>>> PTP PW: A PW within a PTP LSP that is dedicated to carry PTP >>>>> messages. >>>>>=20 >>>>> SB> Ah I don't think that PWE3 know what one of these is >>>>>=20 >>>>> CW: Pseudowire Control Word >>>>>=20 >>>>> LAG: Link Aggregation >>>>>=20 >>>>> ECMP: Equal Cost Multipath >>>>>=20 >>>>> CF: Correction Field, a field inside certain PTP messages (message >>>>> type 0-3)that holds the accumulative transit time inside intermedia= te >>>>> switches >>>>>=20 >>>>> Timing messages: Timing Protocol messages that are exchanged >> between >>>>> routers in order to establish a synchronized clock. >>>>>=20 >>>>> SB> A number of these definitions look like copies of IEEE1588 >>>>> SB> definitions. We need to provide references and note the >>>>> SB> priority of the IEEE base reference. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 7= ] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 3. Problem Statement >>>>>=20 >>>>> [IEEE-1588] has defined methods for transporting PTP messages over >>>>> Ethernet and IP networks. [RFC5905] has defined the method of >>>>> transporting NTP messages over IP networks. There is a need to >>>>> transport Timing messages over MPLS networks while supporting the >>>>> Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC)= >>>>> functionality in the LER and LSRs in the MPLS network. >>>>>=20 >>>>> There are multiple ways of transporting Timing over MPLS. However,= >>>>> there is a requirement to limit the possible encapsulation options t= o >>>>> simplify the Timing message identification and processing required a= t >>>>> the port level. >>>>>=20 >>>>> When Timing-awareness is needed, Timing messages should not be >>>>> transported over LSPs or PWs that are carrying customer traffic >>>>> because LSRs perform Label switching based on the top label in the >>>>> stack. >>>>>=20 >>>>> SB> Have you explained why? >>>>>=20 >>>>> To detect Timing messages inside such LSPs require special >>>>> hardware to do deep packet inspection at line rate. Even if such >>>>> hardware exists, the payload can't be deterministically identified b= y >>>>> LSRs because the payload type is a context of the PW label, and the= >>>>> PW label and its context are only known to the Edge routers (PEs/ >>>>> LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, CES= , >>>>> etc). Even if one restricts an LSP to only carry Ethernet PWs, the= >>>>> LSRs dont have the knowledge of whether PW Control Word (CW) is >>>>> present or not and therefore can not deterministically identify the= >>>>> payload. >>>>>=20 >>>>> A generic method is defined in this document that does not require >>>>> deep packet inspection at line rate, and can deterministically >>>>> identify Timing messages. This method can be used to detect Timing= >>>>> Messages in both one-step and two-step clock implementations of >>>>> ordinary, boundary and transparent clocks. >>>>>=20 >>>>> SB> Needs a ref and I am sure many MPLS specialists will not understan= d >>>>> SB> the msg types. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 8= ] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 4. Timing over MPLS Architecture >>>>>=20 >>>>> Timing messages are exchange between Timing ports on ordinary and >>>>>=20 >>>>> SB> Have you defined a timing port? >>>>>=20 >>>>> boundary clocks. Boundary clocks terminate the Timing messages and= >>>>> act as master for other boundary clocks or for slave clocks. End-t= o- >>>>> End Transparent clocks do not terminate the Timing messages but the= y >>>>> do modify the contents of the Timing messages as they transit acros= s >>>>> the transparent clock. >>>>>=20 >>>>> Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent Clo= ck >>>>>=20 >>>>> (TC) could be implemented in either LERs or LSRs. >>>>>=20 >>>>> SB> LER and LSR need to be expanded >>>>>=20 >>>>> An example is shown in Figure 1, where the LERs act as Ordinary Clo= ck >>>>> (OC) and are the initiating/terminating point for Timing messages. >>>>> The ingress LER encapsulates the Timing messages in Timing LSP and >>>>> the Egress LER terminates the Timing LSP. The LSRs act as >>>>> Transparent Clock (TC) and just update the Timing field in the Timi= ng >>>>> messages. >>>>>=20 >>>>>=20 >>>>> +--------+ +-------+ +-------+ +-------+ +------= --+ >>>>> |Switch, | | | | | | | |Switch= , | >>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Route= r | >>>>> | | | OC | | TC | | OC | | = | >>>>> +--------+ +-------+ +-------+ +-------+ +------= --+ >>>>> / \ >>>>> +-------+ / \ +-------= + >>>>> | LER | / \ | LER |= >>>>> | Master|---/ \---| Slave |= >>>>> | Clock | | Clock |= >>>>> +-------+ +-------= + >>>>>=20 >>>>> Figure (1) - Deployment example 1 of timing over MPLS network >>>>>=20 >>>>> Another example is shown in Figure2, where LERs terminate the Timin= g >>>>> messages received from switch/routers that are outside of the MPLS >>>>> network acting as OC or BC. In this example LERs regenerate the >>>>> clock and initiate timing messages encapsulated in Timing LSP towar= d >>>>> the MPLS network, while the LSRs act as Transparent Clock (TC) and >>>>> just update the Timing field in the Timing messages, which are >>>>> already encapsulated in Timing LSPs. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 9= ] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> +--------+ +-------+ +-------+ +-------+ +-------= -+ >>>>> |Switch, | | | | | | | |Switch,= | >>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Router= | >>>>> | OC/BC | | BC | | TC | | BC | | OC/BC = | >>>>> +--------+ +-------+ +-------+ +-------+ +-------= -+ >>>>>=20 >>>>> Figure (2) - Deployment example 2 of timing over MPLS network >>>>>=20 >>>>>=20 >>>>> Another example is shown in Figure 3, where LERs do not terminate t= he >>>>> Timing messages received from switch/routers that are outside of th= e >>>>> MPLS network acting as OC, TC or BC. The LERs act as TC and update= >>>>> the Timing field in the Timing messages as they transit the LER, >>>>> while encapsulating them in timing LSP. The LSRs also act as >>>>> Transparent Clock (TC) and just update the Timing field in the Timi= ng >>>>> messages which are already encapsulated in Timing LSPs. >>>>>=20 >>>>> +--------+ +-------+ +-------+ +-------+ +------= --+ >>>>> |Switch, | | | | | | | |Switch= , | >>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Route= r | >>>>> |OC/TC/BC| | TC | | TC | | TC | |OC/TC/= BC| >>>>> +--------+ +-------+ +-------+ +-------+ +------= --+ >>>>>=20 >>>>> Figure (3) - Deployment example 3 of timing over MPLS network >>>>>=20 >>>>> Another example is shown in Figure 4, where LERs and LSRs support >>>>> Boundary Clocks. A single-hop LSP is created between two adjacent >>>>> LSRs engaged in BC operation. Other methods such as PTP transport >>>>> over Ethernet MAY be used for transporting timing messages if the >>>>> link between the two routers is Ethernet. >>>>>=20 >>>>> +--------+ +-------+ +-------+ +-------+ +-------= -+ >>>>> |Switch, | | | | | | | |Switch,= | >>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Router= | >>>>> | OC/BC | | BC | | BC | | BC | | OC/BC = | >>>>> +--------+ +-------+ +-------+ +-------+ +-------= -+ >>>>>=20 >>>>> Figure (4) - Deployment example 3 of timing over MPLS network >>>>>=20 >>>>> An MPLS domain MAY serve multiple customers. In these cases the >> MPLS >>>>> domain (maintained by a service provider) may provide timing servic= es >>>>> to multiple customers, each having their own Timing domain. >>>>>=20 >>>>> The Timing over MPLS architecture assumes full mesh of Timing LSPs >>>>> between all LERs supporting this specification. >>>>>=20 >>>>> SB> Note sure this is right - the salves surely do not need to >>>>> SB> exchange timing amongst themselves >>>>>=20 >>>>> It supports >>>>> Point-to- point (VPWS) and Multipoint (VPLS) services. >>>>>=20 >>>>> SB> What does that mean? You do not carry user data traffic? >>>>> SB> Maybe it's the ordering of the statemnets that is causing >>>>> SB> confusion. >>>>>=20 >>>>> This means >>>>> that a customer may purchase a Point-to-point Timing service betwee= n >>>>> two customer sites or a Multipoint Timing service between more than= >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 1= 0] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> two customer sites. >>>>>=20 >>>>> The Timing over MPLS architecture supports P2P or P2MP Timing LSPs.= >>>>> This means that the Timing Multicast messages such as PTP Multicast= >>>>> event messages can be transported over P2MP Timing LSP or be >>>>> replicated and transported over many P2P Timing LSPs. >>>>>=20 >>>>> SB> Note we do not yet have a definition of a P2MP mpls-tp LSP >>>>> SB> nor a P2MP PW, although we are close. >>>>>=20 >>>>> Timing messages, that do not require Time stamping or Correction >>>>> Field update MAY be transported over Timing LSPs to simplify hardwa= re >>>>> and software. >>>>>=20 >>>>> PTP Announce messages that determine the Timing LSP terminating >> point >>>>> behavior such as BC/OC/TC SHOULD be transported over the Timing LSP= >>>>> to simplify hardware and software. >>>>>=20 >>>>> SB> have you defined and referenced PTP announce msgs? >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 1= 1] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 5. Dedicated LSPs for Timing messages >>>>>=20 >>>>> Many methods have been considered for identifying the Timing >> messages >>>>> when they are encapsulated in MPLS such as using GAL/G-ACH or a new= >>>>> reserved label. These methods were not attractive since they eithe= r >>>>> required deep packet inspection at line rate in the intermediate LS= Rs >>>>> or they required use of a scarce new reserved label. Also one of t= he >>>>> goals was to reuse existing OAM mechanisms. >>>>>=20 >>>>> SB> RLs =3D SPLs are not so rare now. In any case needs a ref. >>>>>=20 >>>>> The method defined in this document can be used by LER and LSRs to >>>>> identify Timing messages in MPLS tunnels by just looking at the top= >>>>> label in the MPLS label stack, which only carry Timing messages as >>>>> well as OAM, but not data plane client traffic. >>>>>=20 >>>>> Compliant implementations MUST use dedicated LSPs to carry Timing >>>>> messages over MPLS. >>>>>=20 >>>>> SB> I think that we need a definition of the properies of these LSPs >>>>>=20 >>>>> These LSPs are herein referred to as "Timing >>>>> LSPs" and the labels associated with these LSPs as "Timing LSP >>>>> labels". The Timing LSPs that runs between Ingress and Egress LERs= >>>>> MUST be co-routed. Alternatively, a single bidirectional co-routed= >>>>> LSP can be used. >>>>>=20 >>>>> SB> I though that you said you could use M2MP LSPs - these are not >>>>> SB> bidirectional. >>>>>=20 >>>>> Co-routing of the two directions is required to limit the differenc= e >>>>> in the delays in the Master clock to Slave clock direction compared= >>>>> to the Slave clock to Master clock direction. The Timing LSP MAY b= e >>>>> MPLS/MPLS-TP LSP. >>>>>=20 >>>>> The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS. >>>>> New Extensions to RSVP-TE/GMPLS TLVs are required; however they are= >>>>> outside the scope of this document. >>>>>=20 >>>>> The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such a= s >>>>> BFD and LSP Ping but the LSP data plane client plane traffic MUST b= e >>>>> Timing packets only. >>>>>=20 >>>>> SB> Why? >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 1= 2] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 6. Timing over LSP Encapsulation >>>>>=20 >>>>> The encapsulations is not LSP is it? >>>>>=20 >>>>> This document defines two methods for carrying Timing messages over= >>>>> MPLS. The first method is carrying UDP/IP encapsulated Timing >>>>> messages over Timing LSPs, and the second method, is carrying >>>>> Ethernet encapsulated Timing messages over Ethernet PWs inside >> Timing >>>>> LSPs. >>>>>=20 >>>>> 6.1. Timing over UDP/IP over MPLS Encapsulation >>>>>=20 >>>>> The simplest method of transporting Timing messages over MPLS is to= >>>>> encapsulate Timing PDUs in UDP/IP and then encapsulate them in >> Timing >>>>> LSP. This format is shown in Figure 4. >>>>>=20 >>>>>=20 >>>>> +----------------------+ >>>>> | Timing LSP Label | >>>>> +----------------------+ >>>>> | IPv4/6 | >>>>> +----------------------+ >>>>> | UDP | >>>>> +----------------------+ >>>>> | Timing PDU | >>>>> +----------------------+ >>>>>=20 >>>>> Figure (4) - Timing over UDP/IP over MPLS Encapsulation >>>>>=20 >>>>>=20 >>>>> This encapsulation is very simple and is useful when the network >>>>> between Timing Master Clock and Slave Clock is MPLS network. >>>>>=20 >>>>> SB> Simple is a judgement call >>>>>=20 >>>>> In order for an LER/LSR to process Timing messages, the Timing LSP >>>>> Label must be at the top label of the label stack. The LER/LSR MUS= T >>>>> know that the Timing LSP Label is used for carrying Timing messages= . >>>>> This can be accomplished via static configuration or via RSVP-TE >>>>> signaling. >>>>>=20 >>>>> The UDP/IP encapsulation of PTP MUST follow Annex D and E of >>>>> [IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow >>>>> [RFC5905]. >>>>>=20 >>>>> 6.2. Timing over PW Encapsulation >>>>>=20 >>>>> Another method of transporting Timing over MPLS networks is by >>>>> encapsulating Timing PDUs in PW which in turn is transported over >>>>> Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448], >>>>> shown in Fig 5(A) MUST be used and the Ethernet encapsulation of PT= P >>>>> MUST follow Annex F of [IEEE-1588]. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 1= 3] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> The RAW mode or Tagged mode defined in [RFC4448] MAY be used and >> the >>>>> Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The >>>>> Timing over PW encapsulation MUST use the Control Word (CW) as >>>>> specified in [RFC4448] to ensure proper detection of PTP messages >>>>> inside the MPLS packets for Timing over LSP and Timing over PW >>>>> encapsulation. >>>>>=20 >>>>> SB> That needs explanation >>>>>=20 >>>>> The use of Sequence Number in the CW is optional. >>>>>=20 >>>>> SB> Given that s/n are never in practice deployed, you could probably >>>>> SB> simplify things by sayig that they are not used. >>>>>=20 >>>>> Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over >> PW >>>>> (the IP PW discussed in [RFC4447]) shown in Fig 5(B). >>>>>=20 >>>>> +----------------+ +----------------+ >>>>> |Timing LSP Label| |Timing LSP Label| >>>>> +----------------+ +----------------+ >>>>> | PW Label | | PW Label | >>>>> +----------------+ +----------------+ >>>>> | Control Word | | IP | >>>>> +----------------+ +----------------+ >>>>> | Ethernet | | UDP | >>>>> | Header | +----------------+ >>>>> +----------------+ | Timing PDU | >>>>> |S-VLAN(Optional)| | | >>>>> +----------------+ +----------------+ >>>>> |C-VLAN(Optional)| (B) >>>>> +----------------+ >>>>> | Timing PDU | >>>>> | | >>>>> +----------------+ >>>>> (A) >>>>>=20 >>>>> Figure (5) - Timing over PW Encapsulations >>>>>=20 >>>>> In order for an LSR to process PTP messages, the top label of the >>>>> label stack (the Tunnel Label) MUST be a Timing label. >>>>>=20 >>>>> S> You said that before. >>>>>=20 >>>>> 6.3. Other Timing Encapsulation methods >>>>>=20 >>>>> In future other timing encapsulation methods may be introduced, suc= h >>>>> as a new shim header after the Bottom of Stack to carry the Timing >>>>> information. Such new encapsulations are outside the scope of this= >>>>> document. >>>>>=20 >>>>>=20 >>>>> SB> Taking a pure MPLS pov, you can simplify a lot of the text >>>>> SB> out of the definition of the LSP >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 1= 4] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> SB> I think we need a section on LSP processing >>>>>=20 >>>>> 7. Timing message Processing >>>>>=20 >>>>> Each Timing protocol such as PTP and NTP, define their set of Timin= g >>>>> messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, >>>>> FOLLOW_UP, etc messages. >>>>>=20 >>>>> Some of the Timing messages require time stamping or correction fie= ld >>>>> update at port level and some dont. It is the job of the LER/LSR t= o >>>>> parse the timing message and find out the type of the Timing messag= e >>>>> and decide whether and how to Time- stamp it (e.g., BC) or update >>>>> correction field(e.g., TC). >>>>>=20 >>>>>=20 >>>>> SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing >>>>> SB> function rather than the LER? >>>>>=20 >>>>> For example the following PTP messages (called Event messages) >>>>> require time-stamping or correction field update: >>>>>=20 >>>>> o SYNC >>>>>=20 >>>>> o DELAY_REQ (Delay Request) >>>>>=20 >>>>> o PDELAY_REQ (Peer Delay Request) >>>>>=20 >>>>> o PDELAY_RESP (Peer Delay Response) >>>>>=20 >>>>> SYNC and DELAY_REQ are exchanged between Master Clock and Slave >> Clock >>>>> and MUST be transported over PTP LSPs. PDELAY_REQ and >> PDELAY_RESP >>>>> are exchanged between adjacent PTP clocks (i.e. Master, Slave, >>>>> Boundary, or Transparent) and SHOULD be transported over single hop= >>>>> PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP, >>>>> and PDELAY_RESP_FOLLOW_UP messages MUST also be transported >> over >>>>> the >>>>> PTP LSPs. >>>>>=20 >>>>> For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be >>>>> transported over two PTP LSPs that are in opposite directions. The= se >>>>> PTP LSPs, which are in opposite directions MUST be congruent and co= - >>>>> routed. Alternatively, a single bidirectional co-routed LSP can be= >>>>> used. >>>>>=20 >>>>> Except as indicated above for the two-step PTP clocks, Non-Event PT= P >>>>> message types do not need to be processed by intermediate routers. >>>>> These message types MAY be carried in PTP Tunnel LSPs. >>>>>=20 >>>>> SB> Are you saying that a timing P router has to be msg type sensitive= ? >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 1= 5] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 8. Protection and Redundancy >>>>>=20 >>>>>=20 >>>>> SB> This is a bit of a jump - I don't know how the LSP itself works ye= t! >>>>>=20 >>>>> In order to ensure continuous uninterrupted operation of slave >>>>> clocks, usually as a general practice, slave clocks (or ports) trac= k >>>>> redundant master clocks. >>>>>=20 >>>>> It is the responsibility of the network operator to ensure that >>>>> physically disjoint Timing LSPs are established between a slave clo= ck >>>>> (or port) and redundant master clocks (or ports). >>>>>=20 >>>>> When a slave clock (or port) listens to redundant master clocks or >>>>> ports, any prolonged Timing LSP outage will trigger the slave clock= >>>>> or port to switch to a redundant master clock or port. >>>>>=20 >>>>> LSP/PW protection such as Linear protection Switching (1:1, 1+1), >>>>> Ring protection switching or MPLS Fast Reroute (FRR) generally swit= ch >>>>> alternative path that usually cause a change in delay, which if >>>>> undetected by slave clock can reduce accuracy of the slave clock. >>>>>=20 >>>>> Therefore protection switching MAY be used, as long as phase jumps >>>>> upon switchover due to differences in path latency are detected and= >>>>> compensated for (such compensation not being required if BCs or pee= r- >>>>> peer TCs are used throughout). >>>>>=20 >>>>> Note that any protection or reroute mechanism that adds additional >>>>> MPLS label to the label stack, such as Facility Backup Fast Reroute= , >>>>> MUST ensure that the pushed label is also a Timing Label to ensure >>>>> recognition of the MPLS frame as containing Timing messages, as it >>>>> transits the backup path. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 1= 6] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 9. ECMP >>>>>=20 >>>>> To ensure the optimal operation of slave clocks and avoid error >>>>> introduced by forward and reverse path delay asymmetry, the physica= l >>>>> path for Timing messages from master clock to slave Clock and vice >>>>> versa must be the same for all Event Timing messages listed in >>>>> section 7. >>>>>=20 >>>>> Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost >>>>> Multipath). >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 1= 7] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 10. PHP >>>>>=20 >>>>> To ensure that the label on the top of the label stack is the Timin= g >>>>> LSP Label, PHP MUST not be used. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 1= 8] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 11. Entropy >>>>>=20 >>>>> To ensure all Timing messages in a Timing LSP take the same path, >>>>> Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and >>>>> Entropy Label MUST NOT be used for the PWs that are carried inside >>>>> Timing LSP [RFC6391]. >>>>>=20 >>>>> SB> This is incorrect - you mean that all msgs of the same timing >>>>> SB> flow need to have the same EL value. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 1= 9] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 12. OAM, Control and Management >>>>>=20 >>>>> In order to monitor Timing LSPs and their encapsulated PWs, they MU= ST >>>>> be able to carry OAM and management messages. These management >>>>> messages MUST be differentiated from Timing messages via already >>>>> defined IETF methods. >>>>>=20 >>>>> For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY run= >>>>> over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These >>>>> Management protocols can easily be identified by the UDP Destinatio= n >>>>> Port number or by GAL/G-ACH respectively. >>>>>=20 >>>>> Also BFD, LSP-Ping and other management messages MAY run over the >> PWs >>>>> encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3 o= r >>>>> 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is goi= ng >>>>> to be deprecated by IETF). In this case G-ACH, PW label (TTL=3D1) o= r >>>>> GAL-ACH are used to identify such management messages. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 2= 0] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 13. QoS Considerations >>>>>=20 >>>>> In network deployments where not every LSR/LER is Timing-aware, it i= s >>>>> important to reduce the impact of the non-Timing-aware LSR/LERs on >>>>> the timing recovery in the slave clock. The Timing messages are ti= me >>>>> critical and must be treated with the highest priority. Therefore >>>>> Timing over MPLS messages must be treated with the highest priority= >>>>> in the routers. This can be achieved by proper setup of Timing LSP= s. >>>>>=20 >>>>> It is recommended that the Timing LSPs are setup or configured >>>>> properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC2697= ] >>>>> for drop eligibility. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 2= 1] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 14. FCS and Checksum Recalculation >>>>>=20 >>>>> When time-stamp generation and timing packet adjustment is performe= d >>>>> near the physical port hardware, the process MUST include >>>>> recalculation of the Ethernet FCS. >>>>>=20 >>>>> SB> The above is confusing - an LSR always recomputes the link layer >>>>> SB> CRC which may or may not be Ethernet. >>>>>=20 >>>>> Also FCS retention for the >>>>> payload Ethernet described in [RFC4720] MUST NOT be used. >>>>>=20 >>>>> For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum= >>>>> may be required as per UDP transport standards. >>>>>=20 >>>>> SB> You really need to be working on getting the IPv6 C?S computation >>>>> SB> removed from PTP msgs. >>>>>=20 >>>>> When UDP checksum is used, each Timing-aware LER/LSR must either >>>>> incrementally update the UDP checksum after Time stamping or >>>>> Correction Field update or verify the UDP checksum on reception fro= m >>>>> upstream and recalculate the checksum completely on transmission to= >>>>> downstream node after Time stamping or Correction Field update. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 2= 2] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 15. Behavior of LER/LSR >>>>>=20 >>>>> Timing-capable/aware LERs and LSRs are routers that have one or mor= e >>>>>=20 >>>>> SB> You mean physical interfaces? >>>>>=20 >>>>> interfaces that can perform Timing operations (OC/BC/TC) on Timing >>>>> packets and are configured to do so. Timing-capable/aware LERs and= >>>>> LSRs can advertise their Timing-capability per-interface via contro= l >>>>> plane such as OSPF or IS-IS. >>>>> SB> ISIS and OSPF are routing protocols. >>>>>=20 >>>>> The Timing-capable/aware LERs can then >>>>> signals Timing LSPs via RSVP-TE signaling. Alternatively the Timin= g >>>>> capability of LER and LSRs may be configured in a centralized >>>>> controller and the Timing LSP may be setup using manual configurati= on >>>>> or other methods such as SDN. >>>>>=20 >>>>> SB> it can also be configured individually rather then through >>>>> SB> a cebtral controllwe >>>>>=20 >>>>> 15.1. Behavior of Timing-capable/aware LER >>>>>=20 >>>>> When a Timing-capable/aware LER behaves as a Transparent clock and >>>>> receives a Timing message from a Timing-capable/aware non-MPLS >>>>> interface, the LER updates the Correction Field (CF) and encapsulat= es >>>>> and forwards the timing message over previously established Timing >>>>> LSP. >>>>>=20 >>>>> SB> You need to call out the details so that people properly >>>>> SB> understand the definition of the new LSP. >>>>>=20 >>>>> Also when a Timing message is received from a Timing-capable/ >>>>> aware MPLS interface, LER updates the Correction Filed (CF) and >>>>> decapsulates the MPLS encapsulation and forwards the timing message= >>>>> to a non-MPLS interface. >>>>>=20 >>>>> When a Timing-capable/aware LER behaves as a Boundary clock and >>>>> receives a Timing message from a Timing-capable/aware non MPLS >>>>> interface, the LER Timestamps the Timing packet and sends it to the= >>>>> LERs Boundary clock processing module. Also when a Timing message i= s >>>>> received from a Timing- capable/aware MPLS interface, the LER >>>>> Timestamps the Timing packet and sends it to the LERs Boundary cloc= k >>>>> processing module. >>>>>=20 >>>>> When a Timing-capable/aware LER behaves as an Ordinary Clock toward= >>>>> the MPLS network, and receives a Timing message from a Timing- >>>>> capable/aware MPLS interface, the LER Timestamps the Timing packet >>>>> and sends it to the LERs Ordinary clock processing module. >>>>>=20 >>>>> 15.2. Behavior of Timing-capable/aware LSR >>>>>=20 >>>>> When a Timing-capable/aware LSR behaves as a Transparent clock and >>>>> receives a Timing message from a Timing-capable/aware MPLS >> interface, >>>>> The LSR updates the Correction Filed (CF) and forwards the timing >>>>> message over another MPLS interface. >>>>>=20 >>>>> When a Timing-capable/aware LSR behaves as a Boundary clock and >>>>> receives a Timing message from a Timing-capable/aware MPLS >> interface. >>>>> The LSR performs the functions of a Boundary Clock in terminating t= he >>>>> received Timing message and re-generating a new timing message over= >>>>> another (or the same) MPLS interface. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 2= 3] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 15.3. Behavior of non-Timing-capable/aware LSR >>>>>=20 >>>>> It is most beneficial when all LSRs in the path of a Timing LSP be >>>>> timing-Capable/aware LSRs. This would ensure the highest quality >>>>> time and clock synchronization by Timing Slave Clocks. However, th= is >>>>> specification does not mandate that all LSRs in path of a Timing LS= P >>>>> be Timing- capable/aware. >>>>>=20 >>>>> Non-Timing-capable/aware LSRs just switch the packets encapsulated i= n >>>>> Timing LSPs and dont perform any Timing operation (TC or BC). >>>>> However as explained in QoS section the Timing over MPLS packets >> MUST >>>>> be still be treated with the highest priority based on their Traffi= c >>>>> Class (TC) marking. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 2= 4] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 16. Other considerations >>>>>=20 >>>>> [IEEE-1588] defines an optional peer-to-peer Transparent clocking >>>>> that requires peer delay measurement between two adjacent Timing- >>>>> capable/ aware routers/switches. Peer delay measurement messages >>>>> need to be time stamped and terminated by the Timing-capable/aware >>>>> routers/ switches. This means that two adjacent LSRs may be engage= d >>>>> in a peer delay measurement. >>>>>=20 >>>>> For transporting such peer delay measurement messages a single-hop >>>>> LSP SHOULD to be created between the two adjacent LSRs engaged in >>>>> peer delay measurement to carry peer delay measurement messages. >>>>> Other methods such as PTP transport over Ethernet MAY be used for >>>>> transporting peer delay measurement messages if the link between th= e >>>>> two routers is Ethernet. >>>>>=20 >>>>> In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ wa= re >>>>> routers/switches MUST maintain a list of all the neighbors it needs= >>>>> to send a PDelay_Req to, where each neighbor corresponds to a timin= g >>>>> LSP. >>>>>=20 >>>>> The use of Explicit Null Label (Label=3D 0 or 2) is acceptable as l= ong >>>>> as either the Explicit Null label is the bottom of stack label >>>>> (applicable only to UDP/IP encapsulation) or the label below the >>>>> Explicit Null label is a PTP label. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 2= 5] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 17. Security Considerations >>>>>=20 >>>>> MPLS PW security considerations in general are discussed in [RFC398= 5] >>>>> and [RFC4447],and those considerations also apply to this document.= >>>>>=20 >>>>> An experimental security protocol is defined in [IEEE-1588].The PTP= >>>>> security extension and protocol provides group source authenticatio= n, >>>>> message integrity, and replay attack protection for PTP messages. >>>>>=20 >>>>> When the MPLS network (provider network) serves multiple customers,= >>>>> it is important to maintain and process each customers clock and >>>>> Timing messages separately from other customers to ensure there is n= o >>>>> cross- customer effect. For example if an LER BC is synchronized t= o >>>>> a specific grandmaster, belonging to customer A, then the LER MUST >>>>> use that BC clock only for customer A to ensure that customer A >>>>> cannot attack other customers by manipulating its time. >>>>>=20 >>>>> Timing messages MAY be encrypted or authenticated, provided that th= e >>>>> LERs/LSRs that are Timing capable/aware can authenticate/ decrypt t= he >>>>> timing messages. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 2= 6] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 18. Acknowledgements >>>>>=20 >>>>> The authors would like to thank Ron Cohen, Yaakov Stein, Tal Mizrah= i, >>>>> Stefano Ruffini, Peter Meyer, and other members of IETF for reviewi= ng >>>>> and providing feedback on this draft. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 2= 7] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 19. IANA Considerations >>>>>=20 >>>>> There are no IANA requirements in this specification. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 2= 8] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 20. References >>>>>=20 >>>>> 20.1. Normative References >>>>>=20 >>>>> [IEEE-1588] >>>>> IEEE 1588-2008, "IEEE Standard for a Precision Clock >>>>> Synchronization Protocol for Networked Measurement and >>>>> Control Systems". >>>>>=20 >>>>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >>>>> Requirement Levels", BCP 14, RFC 2119, March 1997. >>>>>=20 >>>>> [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- >>>>> Edge (PWE3) Architecture", RFC 3985, March 2005. >>>>>=20 >>>>> [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discover= y >>>>> Proxies (ND Proxy)", RFC 4389, April 2006. >>>>>=20 >>>>> [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. >>>>> Heron, "Pseudowire Setup and Maintenance Using the Label= >>>>> Distribution Protocol (LDP)", RFC 4447, April 2006. >>>>>=20 >>>>> [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, >>>>> "Encapsulation Methods for Transport of Ethernet over MP= LS >>>>> Networks", RFC 4448, April 2006. >>>>>=20 >>>>> [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire >>>>> Emulation Edge-to-Edge (PWE3) Frame Check Sequence >>>>> Retention", RFC 4720, November 2006. >>>>>=20 >>>>> [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit= >>>>> Connectivity Verification (VCCV): A Control Channel for >>>>> Pseudowires", RFC 5085, December 2007. >>>>>=20 >>>>> [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detectio= n >>>>> (BFD)", RFC 5880, June 2010. >>>>>=20 >>>>> [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, >>>>> "Bidirectional Forwarding Detection (BFD) for MPLS Label= >>>>> Switched Paths (LSPs)", RFC 5884, June 2010. >>>>>=20 >>>>> 20.2. Informative References >>>>>=20 >>>>> [I-D.ietf-pwe3-fat-pw] >>>>> Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan= , >>>>> J., and S. Amante, "Flow Aware Transport of Pseudowires >>>>> over an MPLS Packet Switched Network", >>>>> draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011.= >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 2= 9] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate= >>>>> system routeing information exchange protocol for use in= >>>>> conjunction with the Protocol for providing the >>>>> Connectionless-mode Network Service (ISO 8473)". >>>>>=20 >>>>> [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and >>>>> dual environments", RFC 1195, December 1990. >>>>>=20 >>>>> [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.= >>>>>=20 >>>>> [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color >>>>> Marker", RFC 2697, September 1999. >>>>>=20 >>>>> [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec= , >>>>> J., Courtney, W., Davari, S., Firoiu, V., and D. >>>>> Stiliadis, "An Expedited Forwarding PHB (Per-Hop >>>>> Behavior)", RFC 3246, March 2002. >>>>>=20 >>>>> [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineeri= ng >>>>> (TE) Extensions to OSPF Version 2", RFC 3630, >>>>> September 2003. >>>>>=20 >>>>> [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate= >>>>> System (IS-IS) Extensions for Traffic Engineering (TE)",= >>>>> RFC 3784, June 2004. >>>>>=20 >>>>> [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.= >>>>> Shaffer, "Extensions to OSPF for Advertising Optional >>>>> Router Capabilities", RFC 4970, July 2007. >>>>>=20 >>>>> [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate >>>>> System to Intermediate System (IS-IS) Extensions for >>>>> Advertising Router Information", RFC 4971, July 2007. >>>>>=20 >>>>> [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi >>>>> Topology (MT) Routing in Intermediate System to >>>>> Intermediate Systems (IS-ISs)", RFC 5120, February 2008.= >>>>>=20 >>>>> [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic >>>>> Engineering", RFC 5305, October 2008. >>>>>=20 >>>>> [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, >>>>> "Traffic Engineering Extensions to OSPF Version 3", >>>>> RFC 5329, September 2008. >>>>>=20 >>>>> [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF >>>>> for IPv6", RFC 5340, July 2008. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 3= 0] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Netwo= rk >>>>> Time Protocol Version 4: Protocol and Algorithms >>>>> Specification", RFC 5905, June 2010. >>>>>=20 >>>>> [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan= , >>>>> J., and S. Amante, "Flow-Aware Transport of Pseudowires >>>>> over an MPLS Packet Switched Network", RFC 6391, >>>>> November 2011. >>>>>=20 >>>>> [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and= >>>>> L. Yong, "The Use of Entropy Labels in MPLS Forwarding",= >>>>> RFC 6790, November 2012. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 3= 1] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 1. Routing extensions for Timing-aware Routers >>>>>=20 >>>>> MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] an= d >>>>> IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE= ) >>>>> link information used for constraint-based routing. >>>>>=20 >>>>> Indeed, it is useful to advertise data plane TE router link >>>>> capabilities, such as the capability for a router to be Timing-awar= e. >>>>> This capability MUST then be taken into account during path >>>>> computation to prefer or even require links that advertise themselv= es >>>>> as Timing-aware. In this way the path can ensure the entry and exi= t >>>>> points into the LERs and, if desired, the links into the LSRs are >>>>> able to perform port based time-stamping thus minimizing their impa= ct >>>>> on the performance of the slave clock. >>>>>=20 >>>>> extensions are required to OSPF and IS-IS in order to advertise >>>>> Timing-aware capabilities of a link. Such extensions are outside t= he >>>>> scope of this document; however such extension SHOULD be able to >>>>> signal the following information per Router Link: >>>>>=20 >>>>> o Capable of processing PTP, NTP or other Timing flows >>>>>=20 >>>>> o Capable of performing Transparent Clock operation >>>>>=20 >>>>> o Capable of performing Boundary Clock operation >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 3= 2] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> 2. Signaling Extensions for Creating Timing LSPs >>>>>=20 >>>>> RSVP-TE signaling MAY be used to setup the timing LSPs. When RSVP-= TE >>>>> is used to setup Timing LSPs, some information that indicates that >>>>> the LSP is carrying Timing flows MUST be included in the new >>>>> Extensions to RSVP-TE: >>>>>=20 >>>>> The following information MAY also be included in the new Extension= s >>>>> to RSVP-TE: >>>>>=20 >>>>> o Offset from Bottom of Stack (BoS) to the start of the Time-stamp= >>>>> field >>>>>=20 >>>>> o Number of VLANs in case of PW encapsulation >>>>>=20 >>>>> o Timestamp field Type >>>>>=20 >>>>> * Correction Field, Timestamp >>>>>=20 >>>>> o Timestamp Field format >>>>>=20 >>>>> * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit >>>>> NTP, etc. >>>>>=20 >>>>> Note that in case the above optional information is signaled with >>>>> RSVP-TE for a Timing LSP, all the Timing packets carried in that LS= P >>>>> must have the same signaled characteristics. For example if >>>>> Timestamp format is signaled as 64-bit PTPv1, then all Timing packe= ts >>>>> must use 64-bit PTPv1 time-stamp. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 3= 3] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> Authors' Addresses >>>>>=20 >>>>> Shahram Davari >>>>> Broadcom Corp. >>>>> San Jose, CA 95134 >>>>> USA >>>>>=20 >>>>> Email: davari@broadcom.com >>>>>=20 >>>>>=20 >>>>> Amit Oren >>>>> Broadcom Corp. >>>>> San Jose, CA 95134 >>>>> USA >>>>>=20 >>>>> Email: amito@broadcom.com >>>>>=20 >>>>>=20 >>>>> Manav Bhatia >>>>> Alcatel-Lucent >>>>> Bangalore, >>>>> India >>>>>=20 >>>>> Email: manav.bhatia@alcatel-lucent.com >>>>>=20 >>>>>=20 >>>>> Peter Roberts >>>>> Alcatel-Lucent >>>>> Kanata, >>>>> Canada >>>>>=20 >>>>> Email: peter.roberts@alcatel-lucent.com >>>>>=20 >>>>>=20 >>>>> Laurent Montini >>>>> Cisco Systems >>>>> San Jose CA >>>>> USA >>>>>=20 >>>>> Email: lmontini@cisco.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 3= 4] >>>>> Internet-Draft Transporting Timing over MPLS June 20= 13 >>>>>=20 >>>>>=20 >>>>> Luca >>>>> Cisco Systems >>>>> San Jose CA >>>>> USA >>>>>=20 >>>>> Email: lmartini@cisco.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Davari, et al. Expires December 17, 2013 [Page 3= 5] >>>>> -- >>>>> For corporate legal information go to: >>>>>=20 >>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>=20 >>>>> _______________________________________________ >>>>> TICTOC mailing list >>>>> TICTOC@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tictoc >>>>=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 u= s 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 >>> . >>=20 >>=20 >> -- >> For corporate legal information go to: >>=20 >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>=20 >> _______________________________________________ >> TICTOC mailing list >> TICTOC@ietf.org >> https://www.ietf.org/mailman/listinfo/tictoc >>=20 >>=20 >> _______________________________________________ >> TICTOC mailing list >> TICTOC@ietf.org >> https://www.ietf.org/mailman/listinfo/tictoc >=20 >=20 > This e-mail message is intended for the recipient only and contains inform= ation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If y= ou have received this transmission in error, please inform us by e-mail, pho= ne or fax, and then delete the original and all copies thereof. >=20 From Alexander.Vainshtein@ecitele.com Tue Aug 6 07:49:33 2013 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 40ECD21F9EAA for ; Tue, 6 Aug 2013 07:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, UNPARSEABLE_RELAY=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 vwxKJIpfCIbl for ; Tue, 6 Aug 2013 07:49:28 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.140]) by ietfa.amsl.com (Postfix) with ESMTP id 147A321F9F86 for ; Tue, 6 Aug 2013 07:49:15 -0700 (PDT) Received: from [85.158.139.83:22771] by server-4.bemta-5.messagelabs.com id BC/C7-17085-3EC01025; Tue, 06 Aug 2013 14:49:07 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1375800544!30500987!1 X-Originating-IP: [147.234.242.234] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10660 invoked from network); 6 Aug 2013 14:49:05 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Aug 2013 14:49:05 -0000 X-AuditID: 93eaf2e7-b7ef66d00000140d-4c-52010cdf4271 Received: from ILPTWPVEXCA02.ecitele.com ( [172.31.244.232]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id B2.25.05133.FDC01025; Tue, 6 Aug 2013 17:49:04 +0300 (IDT) Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA02.ecitele.com ([fe80::c473:490d:3a7e:e34a%12]) with mapi id 14.03.0123.003; Tue, 6 Aug 2013 17:49:03 +0300 From: Alexander Vainshtein To: "S. Davari" Thread-Topic: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls Thread-Index: AQHOkhqJ+XHALQ/MzkWnZzr9BEl1M5mHyTyggAAz1YCAAEUhkA== Date: Tue, 6 Aug 2013 14:49:02 +0000 Message-ID: References: <51FB7543.801@cisco.com> <51FF7068.9080600@cisco.com> <4A6CE49E6084B141B15C0713B8993F281BEC731A@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.35.10] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleLIzCtJLcpLzFFi42KZ/OrTF90HPIxBBrcfqlqs7/W0uLV0JasD k8es+2fZPJYs+ckUwBTVwGiTmJeXX5JYkqqQklqcbKsUUJRZlphcqaSQmWKrZKikUJCTmJya m5pXYquUWFCQmpeiZMelgAFsgMoy8xRS85LzUzLz0m2VPIP9dS0sTC11DZXs1JQNja25QjIy ixVSdXMTM3MUclOLixPTUxWAIglbmDNOr7rPXnCii7Vi4s5NrA2Mq64wdzFyckgImEi82PqQ EcIWk7hwbz1bFyMXh5DAQUaJ+9t+giWEBI4wStx9pwNiswnYSmxafZcNxBYRUJFYun0pC4jN LDCXUaL3gEkXIweHsIC7xOEffhAlHhKdU88zQthOEvvP/GYCsVmAWu/NXM4OYvMKBEj0Pd7M ArG3hVli9oOlYMdxAu06uasNrIgR6Ljvp9YwQewSl7j1ZD4TxNECEkv2nId6RlTi5eN/rBC2 nMSTJ6egbtORWLD7ExuErS2xbOFrZojFghInZz5hgaiXlDi44gbLBEbxWUhWzELSPgtJ+ywk 7QsYWVYximbmFJQk5aYbGOqlJmeWpOak6iXn525ihCSS5zsYf81XOcToCvT4RGYp7uR8YCLK K4k3NjDAzVES513eEO4vJJAOTDnZqakFqUXxRaU5qcWHGJk4OKUaGJ0m2MbY+C2dKXu7vkBG 8/FDrw1zE3rmrfZ+dKvi6IR7tgxxAtO/HFt5SyNV5pXjomvLz/sdLrmW9TnOKnLj88f5rJ1P f/sfWCfbvuS/tWj3+y9Nd2aze3r3SZXYLit48+vCut936oszVk+OuJjju0HC02mF0MLTBzIj FJYxvl1wXfO368HD778osRRnJBpqMRcVJwIABQML0hwDAAA= Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] Comments on draft-ietf-tictoc-1588overmpls 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, 06 Aug 2013 14:49:33 -0000 Shahram, >From my experience (admittedly limited), it could be much easier to detect a= nd filter out large jitter than very low one. And, in any case, I would wait for the conclusion of the ITU-T SG15 delibera= tions on partial on path support for 1588. Regards, Sasha > -----Original Message----- > From: S. Davari [mailto:davarish@yahoo.com] > Sent: Tuesday, August 06, 2013 4:35 PM > To: Alexander Vainshtein > Cc: Shahram Davari; mpls@ietf.org; tictoc@ietf.org; stbryant@cisco.com > Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls > > Sasha, > > If a router is not 1588 aware we want it to switch the packet with minimum > jitter and delay via high priority queue. > > Sending it to CPU creates large jitter and delay since the CPUs are genera= lly > busy doing other things. Time stamping or updating CF in the CPU won't hel= p > since it does not cover the variable delay that is incurred from the time= the > packet enters the router to the time the packet gets processed by CPU. > > I wish it was that easy! > > Regards, > Shahram > > > On Aug 6, 2013, at 12:38 AM, Alexander Vainshtein > wrote: > > > Shahram, > > I agree with you that the routers that do not recognize a Timing Alert l= abel > would send the packet to the CPU. (This would be easy to arrange since we= are > speaking about a reserved label.) > > > > I do not, however, see this as a serious issue, because the SW running o= n this > CPU would (hopefully) be upgradable to handle the packet correctly i.e., t= o > forward it to where it should be forwarded and, if it is forwarded as a la= beled > packet, to prepend the Timing Alert Label on top of its label stack. It co= uld even > record the residence time (as observed by the CPU in the proper place in t= he > packet. This would mean that introducing additional error to whatever timi= ng > information is associated with this packet - but this is what you should a= nyway > expect if there are non-compliant routers on your path, right? > > > > Regards, > > Sasha > > > >> -----Original Message----- > >> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behal= f > Of > >> Shahram Davari > >> Sent: Monday, August 05, 2013 11:29 PM > >> To: stbryant@cisco.com; S. Davari > >> Cc: mpls@ietf.org; tictoc@ietf.org > >> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls > >> > >> Hi Stewart, > >> > >> Your suggestion of " I suggested an LSP type that has the properties > "timestamp > >> and pass to application", is a subset of the existing draft and should= work. It > >> basically limits the time stamping and correction field update to LERs= (while > the > >> draft supports time stamping at LER and LSR). > >> > >> However Sasha's suggestion of using a reserved label (RAL, GAL or any o= ther > >> reserved label) does not satisfy one of the major requirements, which i= s > >> backward compatibility. Routers that don't understand this reserved lab= el > will > >> drop or copy to CPU such packets. > >> > >> Regards, > >> Shahram > >> > >> -----Original Message----- > >> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behal= f > Of > >> Stewart Bryant > >> Sent: Monday, August 05, 2013 2:29 AM > >> To: S. Davari > >> Cc: mpls@ietf.org; tictoc@ietf.org > >> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls > >> > >> My concern is that we are creating a new LSP type in MPLS > >> (which is a architectural change and thus needs to be very carefully > >> considered) without asking the question "how can I do this > >> in the most general way, to maximize flexibility/reuse" > >> > >> I suggested an LSP type that has the properties "timestamp > >> and pass to application", but I think that Sasha raises a good > >> point about using router alert. However RA has no implicit > >> timestamp, so maybe we need a new type of RA that has the > >> properties "timestamp, and pass top application indicated by > >> the next label". That would be quite useful in a number > >> of OAM applications. There is possibly some GAL variant > >> of that design that should also be considered. > >> > >> The application could worry about the path and where it > >> was necessary to skip some hops a hierarchical LSP would > >> accomplish that, with the specific benefit that the application > >> would consciously do this, and may be able to apply some > >> form of compensation within the network. > >> > >> - Stewart > >> > >> On 04/08/2013 10:40, S. Davari wrote: > >>> Hi Sasha > >>> > >>> Perhaps you have not understood the draft well. The main reason that t= he > >> draft chose to use a dedicated LSP that is signaled via RSVPTE indicati= ng it is > a > >> timing LSP is to be backward compatible with non-1588 nodes. Such nodes > >> simply just switch the packet. > >>> > >>> Your proposal had been considered and was rejected since it was not > >> backward compatible. Nodes receiving alert label or TTL =3D 1 send the= packet > to > >> CPU. You can refer to the meeting notes. > >>> > >>> Regards, > >>> Shahram > >>> > >>> > >>> On Aug 4, 2013, at 1:21 AM, Alexander Vainshtein > >> wrote: > >>> > >>>> Stewart and all, > >>>> I concur with Stewart's statement that the draft does not define "ful= l > >> interaction with MPLS architecture". > >>>> > >>>> E.g., one of the objectives of the draft is to provide a technique th= at would > >> be backward-compatible with old LSRs that cannot provide on-path suppor= t > for > >> timing distribution, while the other objective is to make every LSR on= the > path > >> aware that some MPLS packets are carrying timing-related messages and > hence > >> require on-path support. > >>>> > >>>> IMHO and FWIW, the MPLS data plane architecture allows just two > methods > >> for making a transit LSR to provide special processing to a labeled pac= ket: > >>>> - It would carry some kind of an "alert label" on top of the label st= ack and, > >> specifically, on top of any labels used for actual forwarding > >>>> OR, > >>>> - The TTL in the top label stack entry has been set to 1. > >>>> > >>>> > >>>> The draft does not follow any of these approaches. > >>>> > >>>> I must also admit that Section 12 "OAM, Control and Management" of th= e > >> draft looks somewhat in > >>>> E.g., I could not understand from the text whether BFD, LSP-Ping etc.= OAM > >> messages would be subjected to on-path support procedures for timing > >> messages or not. > >>>> > >>>> My 2c, > >>>> Sasha > >>>> > >>>>> -----Original Message----- > >>>>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On > Behalf > >> Of > >>>>> Stewart Bryant > >>>>> Sent: Friday, August 02, 2013 12:01 PM > >>>>> To: mpls-chairs@tools.ietf.org; tictoc-chairs@tools.ietf.org; int- > >>>>> ads@tools.ietf.org; rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.o= rg; > >> draft- > >>>>> ietf-tictoc-1588overmpls@tools.ietf.org > >>>>> Cc: mpls@ietf.org; tictoc@ietf.org > >>>>> Subject: [TICTOC] Comments on draft-ietf-tictoc-1588overmpls > >>>>> > >>>>> SB> This draft does not seem to provide a precise definition > >>>>> SB> the properties of the new LSP type that it wishes to > >>>>> SB> define, in particular it does it define the PHB of those > >>>>> SB> LSPs, nor the full interaction with the MPLS > >>>>> SB> architecture. > >>>>> SB> > >>>>> SB> I have not tracked TICTOC for a while but I thought that > >>>>> SB> the original plan was to define the concept of an offset > >>>>> SB> into a packet to do the correction. > >>>>> SB> > >>>>> SB> It is disappointing that the opportunity was not taken > >>>>> SB> to define a timing shim inside the timing LSP so that > >>>>> SB> a time correction could be added to any packet such that > >>>>> SB> the MPLS system was isolated from the details of the > >>>>> SB> complexity of the particular time transfer type. > >>>>> > >>>>> SB> I think that much more clarify is needed in terms of > >>>>> SB> definition of the new LSP type, since it is unclear > >>>>> SB> from this text how to implement one. > >>>>> SB> > >>>>> SB> There are a lot of other MPLS services such as > >>>>> SB> LSP ping that need to be considered. > >>>>> SB> > >>>>> SB> Please see inline for more comments. However these > >>>>> SB> comments are made in the context of the text as written > >>>>> SB> whilst I have a fundamental concern that this approach > >>>>> SB> lacks an MPLS architectural soundness that need > >>>>> SB> greater thought with significant impact on the > >>>>> SB> draft. > >>>>> > >>>>> - Stewart > >>>>> > >>>>> > >>>>> TICTOC Working Group S. Da= vari > >>>>> Internet-Draft A.= Oren > >>>>> Intended status: Standards Track Broadcom C= orp. > >>>>> Expires: December 17, 2013 M. Bh= atia > >>>>> P. Rob= erts > >>>>> Alcatel-Lu= cent > >>>>> L. Mon= tini > >>>>> L. Mar= tini > >>>>> Cisco Sys= tems > >>>>> June 15,= 2013 > >>>>> > >>>>> > >>>>> Transporting Timing messages over MPLS Networks > >>>>> draft-ietf-tictoc-1588overmpls-05 > >>>>> > >>>>> Abstract > >>>>> > >>>>> This document defines the method for transporting Timing messages > >>>>> such as PTP and NTP over an MPLS network. The method allows for > the > >>>>> easy identification of these PDUs at the port level to allow for= port > >>>>> > >>>>> SB> What is a port > >>>>> > >>>>> level processing of these PDUs in both LERs and LSRs. > >>>>> > >>>>> The basic idea is to transport Timing messages inside dedicated M= PLS > >>>>> LSPs. These LSPs only carry Timing messages and possibly Control= and > >>>>> Management packets, but they do not carry customer traffic. > >>>>> > >>>>> SB> More specifically they only carry traffic associated with the > >>>>> SB> timing service and its support. > >>>>> SB> The question arose WRT BFD - surely BFD is allowed, BUT surely > >>>>> SB> also it gets carried in a structure that causes it to get > >>>>> SB> timestamped. > >>>>> > >>>>> Two methods for transporting Timing messages over MPLS are define= d. > >>>>> > >>>>> SB> Perhaps the right approach is to define the new LSP type and the= n > >>>>> SB> seperately to define the mapping of the various timing services > >>>>> SB> over that LSP type. > >>>>> > >>>>> The first method is to transport Timing messages directly over th= e > >>>>> dedicated MPLS LSP via UDP/IP encapsulation, which is suitable fo= r > >>>>> MPLS networks. The second method is to transport Timing messages > >>>>> inside a PW via Ethernet encapsulation. > >>>>> > >>>>> SB> I think that we should note that there are some > >>>>> SB> h/w reasons for this preference. A clean sheet approach > >>>>> SB> would have been to use PTP over MPLS with no intermediate > >>>>> SB> layers. > >>>>> > >>>>> Status of this Memo > >>>>> > >>>>> This Internet-Draft is submitted in full conformance with the > >>>>> provisions of BCP 78 and BCP 79. > >>>>> > >>>>> Internet-Drafts are working documents of the Internet Engineering > >>>>> Task Force (IETF). Note that other groups may also distribute > >>>>> working documents as Internet-Drafts. The list of current Intern= et- > >>>>> Drafts is at http://datatracker.ietf.org/drafts/current/. > >>>>> > >>>>> Internet-Drafts are draft documents valid for a maximum of six mo= nths > >>>>> and may be updated, replaced, or obsoleted by other documents at= any > >>>>> time. It is inappropriate to use Internet-Drafts as reference > >>>>> material or to cite them other than as "work in progress." > >>>>> > >>>>> This Internet-Draft will expire on December 17, 2013. > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Pag= e 1] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> Copyright Notice > >>>>> > >>>>> Copyright (c) 2013 IETF Trust and the persons identified as the > >>>>> document authors. All rights reserved. > >>>>> > >>>>> This document is subject to BCP 78 and the IETF Trust's Legal > >>>>> Provisions Relating to IETF Documents > >>>>> (http://trustee.ietf.org/license-info) in effect on the date of > >>>>> publication of this document. Please review these documents > >>>>> carefully, as they describe your rights and restrictions with res= pect > >>>>> to this document. Code Components extracted from this document > must > >>>>> include Simplified BSD License text as described in Section 4.e o= f > >>>>> the Trust Legal Provisions and are provided without warranty as > >>>>> described in the Simplified BSD License. > >>>>> > >>>>> > >>>>> Table of Contents > >>>>> > >>>>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .= . 5 > >>>>> > >>>>> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . .= . 7 > >>>>> > >>>>> 3. Problem Statement . . . . . . . . . . . . . . . . . . . . .= . 8 > >>>>> > >>>>> 4. Timing over MPLS Architecture . . . . . . . . . . . . . . .= . 9 > >>>>> > >>>>> 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . .= . 12 > >>>>> > >>>>> 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . .= . 13 > >>>>> 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . .= . 13 > >>>>> 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . .= . 13 > >>>>> 6.3. Other Timing Encapsulation methods . . . . . . . . . . .= . 14 > >>>>> > >>>>> 7. Timing message Processing . . . . . . . . . . . . . . . . .= . 15 > >>>>> > >>>>> 8. Protection and Redundancy . . . . . . . . . . . . . . . . .= . 16 > >>>>> > >>>>> 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . .= . 17 > >>>>> > >>>>> 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . .= . 18 > >>>>> > >>>>> 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . .= . 19 > >>>>> > >>>>> 12. OAM, Control and Management . . . . . . . . . . . . . . . .= . 20 > >>>>> > >>>>> 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . .= . 21 > >>>>> > >>>>> 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . .= . 22 > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Pag= e 2] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . .= . 23 > >>>>> 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . .= . 23 > >>>>> 15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . .= . 23 > >>>>> 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . .= . 24 > >>>>> > >>>>> 16. Other considerations . . . . . . . . . . . . . . . . . . . .= . 25 > >>>>> > >>>>> 17. Security Considerations . . . . . . . . . . . . . . . . . .= . 26 > >>>>> > >>>>> 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .= . 27 > >>>>> > >>>>> 19. IANA Considerations . . . . . . . . . . . . . . . . . . . .= . 28 > >>>>> > >>>>> 20. References . . . . . . . . . . . . . . . . . . . . . . . . .= . 29 > >>>>> 20.1. Normative References . . . . . . . . . . . . . . . . . .= . 29 > >>>>> 20.2. Informative References . . . . . . . . . . . . . . . . .= . 29 > >>>>> > >>>>> Appendix 1. Routing extensions for Timing-aware Routers . . . .= . 32 > >>>>> > >>>>> Appendix 2. Signaling Extensions for Creating Timing LSPs . . .= . 33 > >>>>> > >>>>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .= . 34 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Pag= e 3] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > >> NOT", > >>>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" > >> in > >>>>> this > >>>>> document are to be interpreted as described in RFC2119 [RFC2119]. > >>>>> > >>>>> When used in lower case, these words convey their typical use in > >>>>> common language, and are not to be interpreted as described in > >>>>> RFC2119 [RFC2119]. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Pag= e 4] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 1. Introduction > >>>>> > >>>>> The objective of Precision Time Protocol (PTP) and Network Timing > >>>>> Protocol (NTP) are to synchronize independent clocks running on > >>>>> separate nodes of a distributed system. > >>>>> > >>>>> [IEEE-1588] defines PTP messages for frequency, phase and time > >>>>> synchronization. The PTP messages include PTP PDUs over UDP/IP > >>>>> (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex= F of > >>>>> [IEEE-1588]). > >>>>> > >>>>> SB> Sure BUT it is acknowledged that IEEE is open to the definition > >>>>> SB> of other PTP mappings if they provide better optimisation. > >>>>> > >>>>> This document defines mapping and transport of the PTP > >>>>> messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP > >>>>> defines several clock types: ordinary clocks, boundary clocks, en= d- > >>>>> to-end transparent clocks, and peer-to-peer transparent clocks. > >>>>> Transparent clocks require intermediate nodes to update correctio= n > >>>>> field inside PTP message that reflects the transit time in the no= de. > >>>>> > >>>>> [RFC5905] defines NTP messages for clock and time synchronization= . > >>>>> The PTP messages (PDUs) are transported over UDP/IP. This docume= nt > >>>>> SB> Should that be NTP messages? > >>>>> SB> It needs to be made clear as soon as you introduce NTP that > >>>>> SB> they use different time representations. > >>>>> > >>>>> defines mapping and transport of the NTP messages defined in > >>>>> [RFC5905] over MPLS networks. > >>>>> > >>>>> One key attribute of all of these Timing messages is that the Tim= e > >>>>> stamp processing should occur as close as possible to the actual > >>>>> transmission and reception at the physical port interface. This > >>>>> targets optimal time and/or frequency recovery by avoiding variab= le > >>>>> delay introduced by queues internal to the clocks. > >>>>> > >>>>> SB> As I recall NTP has no epoch point defined, and I am not sure > >>>>> SB> where that point is in the case of PTP in this mapping > >>>>> SB> Hopefully this will get defined in due course. > >>>>> > >>>>> To facilitate the fast and efficient recognition of Timing messag= es > >>>>> at the port level when the Timing messages are carried over MPLS > >>>>> LSPs, > >>>>> > >>>>> SB> Over a new LSP type with time optimied characteristics > >>>>> > >>>>> this document defines the specific encapsulations that should > >>>>> be used. > >>>>> SB> Hopefully it will also define the PHP > >>>>> > >>>>> In addition, it can be expected that there will exist LSR/ > >>>>> LERs where only a subset of the physical ports will have the port= - > >>>>> based Timing message processing capabilities. > >>>>> SB> Do you need to clarify that this only works at base and not in > >>>>> SB> a label heirarchy. > >>>>> > >>>>> > >>>>> In order to ensure > >>>>> that the LSPs carrying Timing packets always enter and exit ports > >>>>> with this capability, routing extensions are defined to advertise > >>>>> this capability on a port basis and to allow for the establishmen= t of > >>>>> LSPs that only transit such ports. While this path establishment > >>>>> restriction may be applied only at the LER Ingress and/or egress > >>>>> ports, it becomes more important when using transparent clock > capable > >>>>> LSRs in the path. > >>>>> SB> I do not understand the implications of the last > >>>>> SB> sentences - starting ", it becomes" > >>>>> > >>>>> > >>>>> Port based Timing message processing involves Timing message > >>>>> recognition. Once the Timing messages are recognized they can be > >>>>> modified based on the reception or transmission Time-stamp. > >>>>> > >>>>> This document provides two methods for transporting Timing > messages > >>>>> over MPLS. One is applicable to MPLS environment and the other o= ne > >>>>> is applicable to MPLS/MPLS-TP environment > >>>>> > >>>>> SB> I think the sentence is incomplete. > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Pag= e 5] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> The solution involves transporting Timing messages over dedicated > >>>>> LSPs called Timing LSPs. These LSPs carry Timing messages and MA= Y > >>>>> carry Management and control messages, but not data plane client > >>>>> traffic. > >>>>> > >>>>> SB> It is not clear why this restriction applies. > >>>>> > >>>>> Timing LSPs can be established statically or via signaling. > >>>>> SB> s/statically/by provisioning/network management/ > >>>>> > >>>>> Extensions to control plane (OSPF, ISIS, etc.) is required to ena= ble > >>>>> routers to distribute their Timing processing capabilities over M= PLS > >>>>> to other routers. However such extensions are outside the scope= of > >>>>> this document. > >>>>> > >>>>> When signaling is used to setup the PTP LSP, Extensions to signal= ing > >>>>> SB> is it a PTP LSP or a Timing LSP? > >>>>> > >>>>> protocols (e.g., RSVP-TE) are required for establishing PTP LSPs. > >>>>> However such extensions are outside the scope of this document. > >>>>> > >>>>> SB> for mpls-tp GMPLS is the signalling protocol > >>>>> > >>>>> While the techniques included herein allow for the establishment= of > >>>>> paths optimized to include Time-stamping capable links, the > >>>>> performance of the Slave clocks is outside the scope of this > >>>>> document. > >>>>> > >>>>> At the time of publishing this specification, Transparent Clockin= g > >>>>> (TC) is only defined for PTP. Therefore at this time any part of > >>>>> this specification that talks about Transparent Clocking applies= only > >>>>> to PTP. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Pag= e 6] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 2. Terminology > >>>>> > >>>>> 1588: The timing and synchronization as defined by IEEE 1588. > >>>>> > >>>>> SB> I think that there is a more formal name for the 1588 group > >>>>> SB> that needs to be used here. > >>>>> SB> Also do we need to talk about 1588-200? as there is > >>>>> SB> an update in progress > >>>>> > >>>>> NTP: The timing and synchronization protocol defined by IETF RFC-= 1305 > >>>>> and RFC-5905. > >>>>> > >>>>> PTP: The timing and synchronization protocol used by 1588. > >>>>> SB> need the proper name for 1588 > >>>>> > >>>>> Master Clock: The source of 1588 timing to a set of slave clocks. > >>>>> > >>>>> Master Port: A port on a ordinary or boundary clock that is in Ma= ster > >>>>> state. This is the source of timing toward slave ports. > >>>>> > >>>>> SB> I am not sure the reader knows what a port is > >>>>> > >>>>> Slave Clock: A receiver of 1588 timing from a master clock. > >>>>> > >>>>> Slave Port: A port on a boundary clock or ordinary clock that is > >>>>> receiving timing from a master clock. > >>>>> > >>>>> Ordinary Clock: A device with a single PTP port. > >>>>> > >>>>> Transparent Clock. A device that measures the time taken for a P= TP > >>>>> event message to transit the device and then updates the > >>>>> correctionField of the message with this transit time. > >>>>> > >>>>> Boundary Clock: A device with more than one PTP port. Generally > >>>>> boundary clocks will have one port in slave state to receive timi= ng > >>>>> and then other ports in master state to re-distribute the timing. > >>>>> > >>>>> PTP LSP: An LSP dedicated to carry PTP messages > >>>>> > >>>>> SB> PTP or timing? > >>>>> > >>>>> > >>>>> PTP PW: A PW within a PTP LSP that is dedicated to carry PTP > >>>>> messages. > >>>>> > >>>>> SB> Ah I don't think that PWE3 know what one of these is > >>>>> > >>>>> CW: Pseudowire Control Word > >>>>> > >>>>> LAG: Link Aggregation > >>>>> > >>>>> ECMP: Equal Cost Multipath > >>>>> > >>>>> CF: Correction Field, a field inside certain PTP messages (messag= e > >>>>> type 0-3)that holds the accumulative transit time inside intermed= iate > >>>>> switches > >>>>> > >>>>> Timing messages: Timing Protocol messages that are exchanged > >> between > >>>>> routers in order to establish a synchronized clock. > >>>>> > >>>>> SB> A number of these definitions look like copies of IEEE1588 > >>>>> SB> definitions. We need to provide references and note the > >>>>> SB> priority of the IEEE base reference. > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Pag= e 7] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 3. Problem Statement > >>>>> > >>>>> [IEEE-1588] has defined methods for transporting PTP messages ove= r > >>>>> Ethernet and IP networks. [RFC5905] has defined the method of > >>>>> transporting NTP messages over IP networks. There is a need to > >>>>> transport Timing messages over MPLS networks while supporting the > >>>>> Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (O= C) > >>>>> functionality in the LER and LSRs in the MPLS network. > >>>>> > >>>>> There are multiple ways of transporting Timing over MPLS. Howeve= r, > >>>>> there is a requirement to limit the possible encapsulation option= s to > >>>>> simplify the Timing message identification and processing require= d at > >>>>> the port level. > >>>>> > >>>>> When Timing-awareness is needed, Timing messages should not be > >>>>> transported over LSPs or PWs that are carrying customer traffic > >>>>> because LSRs perform Label switching based on the top label in th= e > >>>>> stack. > >>>>> > >>>>> SB> Have you explained why? > >>>>> > >>>>> To detect Timing messages inside such LSPs require special > >>>>> hardware to do deep packet inspection at line rate. Even if such > >>>>> hardware exists, the payload can't be deterministically identifie= d by > >>>>> LSRs because the payload type is a context of the PW label, and t= he > >>>>> PW label and its context are only known to the Edge routers (PEs/ > >>>>> LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, C= ES, > >>>>> etc). Even if one restricts an LSP to only carry Ethernet PWs, t= he > >>>>> LSRs dont have the knowledge of whether PW Control Word (CW) is > >>>>> present or not and therefore can not deterministically identify t= he > >>>>> payload. > >>>>> > >>>>> A generic method is defined in this document that does not requir= e > >>>>> deep packet inspection at line rate, and can deterministically > >>>>> identify Timing messages. This method can be used to detect Timi= ng > >>>>> Messages in both one-step and two-step clock implementations of > >>>>> ordinary, boundary and transparent clocks. > >>>>> > >>>>> SB> Needs a ref and I am sure many MPLS specialists will not underst= and > >>>>> SB> the msg types. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Pag= e 8] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 4. Timing over MPLS Architecture > >>>>> > >>>>> Timing messages are exchange between Timing ports on ordinary and > >>>>> > >>>>> SB> Have you defined a timing port? > >>>>> > >>>>> boundary clocks. Boundary clocks terminate the Timing messages a= nd > >>>>> act as master for other boundary clocks or for slave clocks. End= -to- > >>>>> End Transparent clocks do not terminate the Timing messages but t= hey > >>>>> do modify the contents of the Timing messages as they transit acr= oss > >>>>> the transparent clock. > >>>>> > >>>>> Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent > Clock > >>>>> > >>>>> (TC) could be implemented in either LERs or LSRs. > >>>>> > >>>>> SB> LER and LSR need to be expanded > >>>>> > >>>>> An example is shown in Figure 1, where the LERs act as Ordinary C= lock > >>>>> (OC) and are the initiating/terminating point for Timing messages= . > >>>>> The ingress LER encapsulates the Timing messages in Timing LSP an= d > >>>>> the Egress LER terminates the Timing LSP. The LSRs act as > >>>>> Transparent Clock (TC) and just update the Timing field in the Ti= ming > >>>>> messages. > >>>>> > >>>>> > >>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ > >>>>> |Switch, | | | | | | | |Swit= ch, | > >>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rou= ter | > >>>>> | | | OC | | TC | | OC | | = | > >>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ > >>>>> / \ > >>>>> +-------+ / \ +-----= --+ > >>>>> | LER | / \ | LER= | > >>>>> | Master|---/ \---| Slav= e | > >>>>> | Clock | | Cloc= k | > >>>>> +-------+ +-----= --+ > >>>>> > >>>>> Figure (1) - Deployment example 1 of timing over MPLS network > >>>>> > >>>>> Another example is shown in Figure2, where LERs terminate the Tim= ing > >>>>> messages received from switch/routers that are outside of the MPL= S > >>>>> network acting as OC or BC. In this example LERs regenerate the > >>>>> clock and initiate timing messages encapsulated in Timing LSP tow= ard > >>>>> the MPLS network, while the LSRs act as Transparent Clock (TC) an= d > >>>>> just update the Timing field in the Timing messages, which are > >>>>> already encapsulated in Timing LSPs. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Pag= e 9] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ > >>>>> |Switch, | | | | | | | |Switc= h, | > >>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rout= er | > >>>>> | OC/BC | | BC | | TC | | BC | | OC/B= C | > >>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ > >>>>> > >>>>> Figure (2) - Deployment example 2 of timing over MPLS network > >>>>> > >>>>> > >>>>> Another example is shown in Figure 3, where LERs do not terminate= the > >>>>> Timing messages received from switch/routers that are outside of= the > >>>>> MPLS network acting as OC, TC or BC. The LERs act as TC and upda= te > >>>>> the Timing field in the Timing messages as they transit the LER, > >>>>> while encapsulating them in timing LSP. The LSRs also act as > >>>>> Transparent Clock (TC) and just update the Timing field in the Ti= ming > >>>>> messages which are already encapsulated in Timing LSPs. > >>>>> > >>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ > >>>>> |Switch, | | | | | | | |Swit= ch, | > >>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rou= ter | > >>>>> |OC/TC/BC| | TC | | TC | | TC | |OC/T= C/BC| > >>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ > >>>>> > >>>>> Figure (3) - Deployment example 3 of timing over MPLS network > >>>>> > >>>>> Another example is shown in Figure 4, where LERs and LSRs support > >>>>> Boundary Clocks. A single-hop LSP is created between two adjacen= t > >>>>> LSRs engaged in BC operation. Other methods such as PTP transpor= t > >>>>> over Ethernet MAY be used for transporting timing messages if the > >>>>> link between the two routers is Ethernet. > >>>>> > >>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ > >>>>> |Switch, | | | | | | | |Switc= h, | > >>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rout= er | > >>>>> | OC/BC | | BC | | BC | | BC | | OC/B= C | > >>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ > >>>>> > >>>>> Figure (4) - Deployment example 3 of timing over MPLS network > >>>>> > >>>>> An MPLS domain MAY serve multiple customers. In these cases the > >> MPLS > >>>>> domain (maintained by a service provider) may provide timing serv= ices > >>>>> to multiple customers, each having their own Timing domain. > >>>>> > >>>>> The Timing over MPLS architecture assumes full mesh of Timing LSP= s > >>>>> between all LERs supporting this specification. > >>>>> > >>>>> SB> Note sure this is right - the salves surely do not need to > >>>>> SB> exchange timing amongst themselves > >>>>> > >>>>> It supports > >>>>> Point-to- point (VPWS) and Multipoint (VPLS) services. > >>>>> > >>>>> SB> What does that mean? You do not carry user data traffic? > >>>>> SB> Maybe it's the ordering of the statemnets that is causing > >>>>> SB> confusion. > >>>>> > >>>>> This means > >>>>> that a customer may purchase a Point-to-point Timing service betw= een > >>>>> two customer sites or a Multipoint Timing service between more th= an > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 10] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> two customer sites. > >>>>> > >>>>> The Timing over MPLS architecture supports P2P or P2MP Timing LSP= s. > >>>>> This means that the Timing Multicast messages such as PTP Multica= st > >>>>> event messages can be transported over P2MP Timing LSP or be > >>>>> replicated and transported over many P2P Timing LSPs. > >>>>> > >>>>> SB> Note we do not yet have a definition of a P2MP mpls-tp LSP > >>>>> SB> nor a P2MP PW, although we are close. > >>>>> > >>>>> Timing messages, that do not require Time stamping or Correction > >>>>> Field update MAY be transported over Timing LSPs to simplify hard= ware > >>>>> and software. > >>>>> > >>>>> PTP Announce messages that determine the Timing LSP terminating > >> point > >>>>> behavior such as BC/OC/TC SHOULD be transported over the Timing > LSP > >>>>> to simplify hardware and software. > >>>>> > >>>>> SB> have you defined and referenced PTP announce msgs? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 11] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 5. Dedicated LSPs for Timing messages > >>>>> > >>>>> Many methods have been considered for identifying the Timing > >> messages > >>>>> when they are encapsulated in MPLS such as using GAL/G-ACH or a > new > >>>>> reserved label. These methods were not attractive since they eit= her > >>>>> required deep packet inspection at line rate in the intermediate= LSRs > >>>>> or they required use of a scarce new reserved label. Also one of= the > >>>>> goals was to reuse existing OAM mechanisms. > >>>>> > >>>>> SB> RLs =3D SPLs are not so rare now. In any case needs a ref. > >>>>> > >>>>> The method defined in this document can be used by LER and LSRs t= o > >>>>> identify Timing messages in MPLS tunnels by just looking at the t= op > >>>>> label in the MPLS label stack, which only carry Timing messages a= s > >>>>> well as OAM, but not data plane client traffic. > >>>>> > >>>>> Compliant implementations MUST use dedicated LSPs to carry Timing > >>>>> messages over MPLS. > >>>>> > >>>>> SB> I think that we need a definition of the properies of these LSPs > >>>>> > >>>>> These LSPs are herein referred to as "Timing > >>>>> LSPs" and the labels associated with these LSPs as "Timing LSP > >>>>> labels". The Timing LSPs that runs between Ingress and Egress LE= Rs > >>>>> MUST be co-routed. Alternatively, a single bidirectional co-rout= ed > >>>>> LSP can be used. > >>>>> > >>>>> SB> I though that you said you could use M2MP LSPs - these are not > >>>>> SB> bidirectional. > >>>>> > >>>>> Co-routing of the two directions is required to limit the differe= nce > >>>>> in the delays in the Master clock to Slave clock direction compar= ed > >>>>> to the Slave clock to Master clock direction. The Timing LSP MAY= be > >>>>> MPLS/MPLS-TP LSP. > >>>>> > >>>>> The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS= . > >>>>> New Extensions to RSVP-TE/GMPLS TLVs are required; however they > are > >>>>> outside the scope of this document. > >>>>> > >>>>> The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such > as > >>>>> BFD and LSP Ping but the LSP data plane client plane traffic MUST= be > >>>>> Timing packets only. > >>>>> > >>>>> SB> Why? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 12] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 6. Timing over LSP Encapsulation > >>>>> > >>>>> The encapsulations is not LSP is it? > >>>>> > >>>>> This document defines two methods for carrying Timing messages ov= er > >>>>> MPLS. The first method is carrying UDP/IP encapsulated Timing > >>>>> messages over Timing LSPs, and the second method, is carrying > >>>>> Ethernet encapsulated Timing messages over Ethernet PWs inside > >> Timing > >>>>> LSPs. > >>>>> > >>>>> 6.1. Timing over UDP/IP over MPLS Encapsulation > >>>>> > >>>>> The simplest method of transporting Timing messages over MPLS is= to > >>>>> encapsulate Timing PDUs in UDP/IP and then encapsulate them in > >> Timing > >>>>> LSP. This format is shown in Figure 4. > >>>>> > >>>>> > >>>>> +----------------------+ > >>>>> | Timing LSP Label | > >>>>> +----------------------+ > >>>>> | IPv4/6 | > >>>>> +----------------------+ > >>>>> | UDP | > >>>>> +----------------------+ > >>>>> | Timing PDU | > >>>>> +----------------------+ > >>>>> > >>>>> Figure (4) - Timing over UDP/IP over MPLS Encapsulation > >>>>> > >>>>> > >>>>> This encapsulation is very simple and is useful when the network > >>>>> between Timing Master Clock and Slave Clock is MPLS network. > >>>>> > >>>>> SB> Simple is a judgement call > >>>>> > >>>>> In order for an LER/LSR to process Timing messages, the Timing LS= P > >>>>> Label must be at the top label of the label stack. The LER/LSR M= UST > >>>>> know that the Timing LSP Label is used for carrying Timing messag= es. > >>>>> This can be accomplished via static configuration or via RSVP-TE > >>>>> signaling. > >>>>> > >>>>> The UDP/IP encapsulation of PTP MUST follow Annex D and E of > >>>>> [IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow > >>>>> [RFC5905]. > >>>>> > >>>>> 6.2. Timing over PW Encapsulation > >>>>> > >>>>> Another method of transporting Timing over MPLS networks is by > >>>>> encapsulating Timing PDUs in PW which in turn is transported over > >>>>> Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448]= , > >>>>> shown in Fig 5(A) MUST be used and the Ethernet encapsulation of= PTP > >>>>> MUST follow Annex F of [IEEE-1588]. > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 13] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> The RAW mode or Tagged mode defined in [RFC4448] MAY be used > and > >> the > >>>>> Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The > >>>>> Timing over PW encapsulation MUST use the Control Word (CW) as > >>>>> specified in [RFC4448] to ensure proper detection of PTP messages > >>>>> inside the MPLS packets for Timing over LSP and Timing over PW > >>>>> encapsulation. > >>>>> > >>>>> SB> That needs explanation > >>>>> > >>>>> The use of Sequence Number in the CW is optional. > >>>>> > >>>>> SB> Given that s/n are never in practice deployed, you could probabl= y > >>>>> SB> simplify things by sayig that they are not used. > >>>>> > >>>>> Timing over PW encapsulation for NTP MUST use NTP over UDP/IP ove= r > >> PW > >>>>> (the IP PW discussed in [RFC4447]) shown in Fig 5(B). > >>>>> > >>>>> +----------------+ +----------------+ > >>>>> |Timing LSP Label| |Timing LSP Label| > >>>>> +----------------+ +----------------+ > >>>>> | PW Label | | PW Label | > >>>>> +----------------+ +----------------+ > >>>>> | Control Word | | IP | > >>>>> +----------------+ +----------------+ > >>>>> | Ethernet | | UDP | > >>>>> | Header | +----------------+ > >>>>> +----------------+ | Timing PDU | > >>>>> |S-VLAN(Optional)| | | > >>>>> +----------------+ +----------------+ > >>>>> |C-VLAN(Optional)| (B) > >>>>> +----------------+ > >>>>> | Timing PDU | > >>>>> | | > >>>>> +----------------+ > >>>>> (A) > >>>>> > >>>>> Figure (5) - Timing over PW Encapsulations > >>>>> > >>>>> In order for an LSR to process PTP messages, the top label of the > >>>>> label stack (the Tunnel Label) MUST be a Timing label. > >>>>> > >>>>> S> You said that before. > >>>>> > >>>>> 6.3. Other Timing Encapsulation methods > >>>>> > >>>>> In future other timing encapsulation methods may be introduced, s= uch > >>>>> as a new shim header after the Bottom of Stack to carry the Timin= g > >>>>> information. Such new encapsulations are outside the scope of th= is > >>>>> document. > >>>>> > >>>>> > >>>>> SB> Taking a pure MPLS pov, you can simplify a lot of the text > >>>>> SB> out of the definition of the LSP > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 14] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> SB> I think we need a section on LSP processing > >>>>> > >>>>> 7. Timing message Processing > >>>>> > >>>>> Each Timing protocol such as PTP and NTP, define their set of Tim= ing > >>>>> messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, > >>>>> FOLLOW_UP, etc messages. > >>>>> > >>>>> Some of the Timing messages require time stamping or correction f= ield > >>>>> update at port level and some dont. It is the job of the LER/LSR= to > >>>>> parse the timing message and find out the type of the Timing mess= age > >>>>> and decide whether and how to Time- stamp it (e.g., BC) or update > >>>>> correction field(e.g., TC). > >>>>> > >>>>> > >>>>> SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing > >>>>> SB> function rather than the LER? > >>>>> > >>>>> For example the following PTP messages (called Event messages) > >>>>> require time-stamping or correction field update: > >>>>> > >>>>> o SYNC > >>>>> > >>>>> o DELAY_REQ (Delay Request) > >>>>> > >>>>> o PDELAY_REQ (Peer Delay Request) > >>>>> > >>>>> o PDELAY_RESP (Peer Delay Response) > >>>>> > >>>>> SYNC and DELAY_REQ are exchanged between Master Clock and Slave > >> Clock > >>>>> and MUST be transported over PTP LSPs. PDELAY_REQ and > >> PDELAY_RESP > >>>>> are exchanged between adjacent PTP clocks (i.e. Master, Slave, > >>>>> Boundary, or Transparent) and SHOULD be transported over single h= op > >>>>> PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP= , > >>>>> and PDELAY_RESP_FOLLOW_UP messages MUST also be transported > >> over > >>>>> the > >>>>> PTP LSPs. > >>>>> > >>>>> For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be > >>>>> transported over two PTP LSPs that are in opposite directions. T= hese > >>>>> PTP LSPs, which are in opposite directions MUST be congruent and= co- > >>>>> routed. Alternatively, a single bidirectional co-routed LSP can= be > >>>>> used. > >>>>> > >>>>> Except as indicated above for the two-step PTP clocks, Non-Event= PTP > >>>>> message types do not need to be processed by intermediate routers= . > >>>>> These message types MAY be carried in PTP Tunnel LSPs. > >>>>> > >>>>> SB> Are you saying that a timing P router has to be msg type sensiti= ve? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 15] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 8. Protection and Redundancy > >>>>> > >>>>> > >>>>> SB> This is a bit of a jump - I don't know how the LSP itself works= yet! > >>>>> > >>>>> In order to ensure continuous uninterrupted operation of slave > >>>>> clocks, usually as a general practice, slave clocks (or ports) tr= ack > >>>>> redundant master clocks. > >>>>> > >>>>> It is the responsibility of the network operator to ensure that > >>>>> physically disjoint Timing LSPs are established between a slave c= lock > >>>>> (or port) and redundant master clocks (or ports). > >>>>> > >>>>> When a slave clock (or port) listens to redundant master clocks o= r > >>>>> ports, any prolonged Timing LSP outage will trigger the slave clo= ck > >>>>> or port to switch to a redundant master clock or port. > >>>>> > >>>>> LSP/PW protection such as Linear protection Switching (1:1, 1+1), > >>>>> Ring protection switching or MPLS Fast Reroute (FRR) generally sw= itch > >>>>> alternative path that usually cause a change in delay, which if > >>>>> undetected by slave clock can reduce accuracy of the slave clock. > >>>>> > >>>>> Therefore protection switching MAY be used, as long as phase jump= s > >>>>> upon switchover due to differences in path latency are detected a= nd > >>>>> compensated for (such compensation not being required if BCs or p= eer- > >>>>> peer TCs are used throughout). > >>>>> > >>>>> Note that any protection or reroute mechanism that adds additiona= l > >>>>> MPLS label to the label stack, such as Facility Backup Fast Rerou= te, > >>>>> MUST ensure that the pushed label is also a Timing Label to ensur= e > >>>>> recognition of the MPLS frame as containing Timing messages, as i= t > >>>>> transits the backup path. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 16] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 9. ECMP > >>>>> > >>>>> To ensure the optimal operation of slave clocks and avoid error > >>>>> introduced by forward and reverse path delay asymmetry, the physi= cal > >>>>> path for Timing messages from master clock to slave Clock and vic= e > >>>>> versa must be the same for all Event Timing messages listed in > >>>>> section 7. > >>>>> > >>>>> Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost > >>>>> Multipath). > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 17] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 10. PHP > >>>>> > >>>>> To ensure that the label on the top of the label stack is the Tim= ing > >>>>> LSP Label, PHP MUST not be used. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 18] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 11. Entropy > >>>>> > >>>>> To ensure all Timing messages in a Timing LSP take the same path, > >>>>> Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and > >>>>> Entropy Label MUST NOT be used for the PWs that are carried insid= e > >>>>> Timing LSP [RFC6391]. > >>>>> > >>>>> SB> This is incorrect - you mean that all msgs of the same timing > >>>>> SB> flow need to have the same EL value. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 19] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 12. OAM, Control and Management > >>>>> > >>>>> In order to monitor Timing LSPs and their encapsulated PWs, they > MUST > >>>>> be able to carry OAM and management messages. These > management > >>>>> messages MUST be differentiated from Timing messages via already > >>>>> defined IETF methods. > >>>>> > >>>>> For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY > run > >>>>> over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These > >>>>> Management protocols can easily be identified by the UDP Destinat= ion > >>>>> Port number or by GAL/G-ACH respectively. > >>>>> > >>>>> Also BFD, LSP-Ping and other management messages MAY run over the > >> PWs > >>>>> encapsulated in Timing LSP via one of the defined VCCVs (Type 1,= 3 or > >>>>> 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is g= oing > >>>>> to be deprecated by IETF). In this case G-ACH, PW label (TTL=3D1= ) or > >>>>> GAL-ACH are used to identify such management messages. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 20] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 13. QoS Considerations > >>>>> > >>>>> In network deployments where not every LSR/LER is Timing-aware, i= t is > >>>>> important to reduce the impact of the non-Timing-aware LSR/LERs o= n > >>>>> the timing recovery in the slave clock. The Timing messages are= time > >>>>> critical and must be treated with the highest priority. Therefor= e > >>>>> Timing over MPLS messages must be treated with the highest priori= ty > >>>>> in the routers. This can be achieved by proper setup of Timing L= SPs. > >>>>> > >>>>> It is recommended that the Timing LSPs are setup or configured > >>>>> properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC26= 97] > >>>>> for drop eligibility. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 21] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 14. FCS and Checksum Recalculation > >>>>> > >>>>> When time-stamp generation and timing packet adjustment is > performed > >>>>> near the physical port hardware, the process MUST include > >>>>> recalculation of the Ethernet FCS. > >>>>> > >>>>> SB> The above is confusing - an LSR always recomputes the link layer > >>>>> SB> CRC which may or may not be Ethernet. > >>>>> > >>>>> Also FCS retention for the > >>>>> payload Ethernet described in [RFC4720] MUST NOT be used. > >>>>> > >>>>> For UDP/IP encapsulation mode of Timing over MPLS, the UDP > checksum > >>>>> may be required as per UDP transport standards. > >>>>> > >>>>> SB> You really need to be working on getting the IPv6 C?S computatio= n > >>>>> SB> removed from PTP msgs. > >>>>> > >>>>> When UDP checksum is used, each Timing-aware LER/LSR must either > >>>>> incrementally update the UDP checksum after Time stamping or > >>>>> Correction Field update or verify the UDP checksum on reception f= rom > >>>>> upstream and recalculate the checksum completely on transmission= to > >>>>> downstream node after Time stamping or Correction Field update. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 22] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 15. Behavior of LER/LSR > >>>>> > >>>>> Timing-capable/aware LERs and LSRs are routers that have one or > more > >>>>> > >>>>> SB> You mean physical interfaces? > >>>>> > >>>>> interfaces that can perform Timing operations (OC/BC/TC) on Timin= g > >>>>> packets and are configured to do so. Timing-capable/aware LERs a= nd > >>>>> LSRs can advertise their Timing-capability per-interface via cont= rol > >>>>> plane such as OSPF or IS-IS. > >>>>> SB> ISIS and OSPF are routing protocols. > >>>>> > >>>>> The Timing-capable/aware LERs can then > >>>>> signals Timing LSPs via RSVP-TE signaling. Alternatively the Tim= ing > >>>>> capability of LER and LSRs may be configured in a centralized > >>>>> controller and the Timing LSP may be setup using manual configura= tion > >>>>> or other methods such as SDN. > >>>>> > >>>>> SB> it can also be configured individually rather then through > >>>>> SB> a cebtral controllwe > >>>>> > >>>>> 15.1. Behavior of Timing-capable/aware LER > >>>>> > >>>>> When a Timing-capable/aware LER behaves as a Transparent clock > and > >>>>> receives a Timing message from a Timing-capable/aware non-MPLS > >>>>> interface, the LER updates the Correction Field (CF) and encapsul= ates > >>>>> and forwards the timing message over previously established Timin= g > >>>>> LSP. > >>>>> > >>>>> SB> You need to call out the details so that people properly > >>>>> SB> understand the definition of the new LSP. > >>>>> > >>>>> Also when a Timing message is received from a Timing-capable/ > >>>>> aware MPLS interface, LER updates the Correction Filed (CF) and > >>>>> decapsulates the MPLS encapsulation and forwards the timing > message > >>>>> to a non-MPLS interface. > >>>>> > >>>>> When a Timing-capable/aware LER behaves as a Boundary clock and > >>>>> receives a Timing message from a Timing-capable/aware non MPLS > >>>>> interface, the LER Timestamps the Timing packet and sends it to t= he > >>>>> LERs Boundary clock processing module. Also when a Timing messag= e > is > >>>>> received from a Timing- capable/aware MPLS interface, the LER > >>>>> Timestamps the Timing packet and sends it to the LERs Boundary cl= ock > >>>>> processing module. > >>>>> > >>>>> When a Timing-capable/aware LER behaves as an Ordinary Clock > toward > >>>>> the MPLS network, and receives a Timing message from a Timing- > >>>>> capable/aware MPLS interface, the LER Timestamps the Timing packe= t > >>>>> and sends it to the LERs Ordinary clock processing module. > >>>>> > >>>>> 15.2. Behavior of Timing-capable/aware LSR > >>>>> > >>>>> When a Timing-capable/aware LSR behaves as a Transparent clock an= d > >>>>> receives a Timing message from a Timing-capable/aware MPLS > >> interface, > >>>>> The LSR updates the Correction Filed (CF) and forwards the timing > >>>>> message over another MPLS interface. > >>>>> > >>>>> When a Timing-capable/aware LSR behaves as a Boundary clock and > >>>>> receives a Timing message from a Timing-capable/aware MPLS > >> interface. > >>>>> The LSR performs the functions of a Boundary Clock in terminating= the > >>>>> received Timing message and re-generating a new timing message > over > >>>>> another (or the same) MPLS interface. > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 23] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 15.3. Behavior of non-Timing-capable/aware LSR > >>>>> > >>>>> It is most beneficial when all LSRs in the path of a Timing LSP b= e > >>>>> timing-Capable/aware LSRs. This would ensure the highest quality > >>>>> time and clock synchronization by Timing Slave Clocks. However,= this > >>>>> specification does not mandate that all LSRs in path of a Timing= LSP > >>>>> be Timing- capable/aware. > >>>>> > >>>>> Non-Timing-capable/aware LSRs just switch the packets encapsulate= d > in > >>>>> Timing LSPs and dont perform any Timing operation (TC or BC). > >>>>> However as explained in QoS section the Timing over MPLS packets > >> MUST > >>>>> be still be treated with the highest priority based on their Traf= fic > >>>>> Class (TC) marking. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 24] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 16. Other considerations > >>>>> > >>>>> [IEEE-1588] defines an optional peer-to-peer Transparent clocking > >>>>> that requires peer delay measurement between two adjacent Timing- > >>>>> capable/ aware routers/switches. Peer delay measurement messages > >>>>> need to be time stamped and terminated by the Timing-capable/awar= e > >>>>> routers/ switches. This means that two adjacent LSRs may be enga= ged > >>>>> in a peer delay measurement. > >>>>> > >>>>> For transporting such peer delay measurement messages a single-ho= p > >>>>> LSP SHOULD to be created between the two adjacent LSRs engaged in > >>>>> peer delay measurement to carry peer delay measurement messages. > >>>>> Other methods such as PTP transport over Ethernet MAY be used for > >>>>> transporting peer delay measurement messages if the link between= the > >>>>> two routers is Ethernet. > >>>>> > >>>>> In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/= ware > >>>>> routers/switches MUST maintain a list of all the neighbors it nee= ds > >>>>> to send a PDelay_Req to, where each neighbor corresponds to a tim= ing > >>>>> LSP. > >>>>> > >>>>> The use of Explicit Null Label (Label=3D 0 or 2) is acceptable as= long > >>>>> as either the Explicit Null label is the bottom of stack label > >>>>> (applicable only to UDP/IP encapsulation) or the label below the > >>>>> Explicit Null label is a PTP label. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 25] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 17. Security Considerations > >>>>> > >>>>> MPLS PW security considerations in general are discussed in > [RFC3985] > >>>>> and [RFC4447],and those considerations also apply to this documen= t. > >>>>> > >>>>> An experimental security protocol is defined in [IEEE-1588].The P= TP > >>>>> security extension and protocol provides group source authenticat= ion, > >>>>> message integrity, and replay attack protection for PTP messages. > >>>>> > >>>>> When the MPLS network (provider network) serves multiple customer= s, > >>>>> it is important to maintain and process each customers clock and > >>>>> Timing messages separately from other customers to ensure there i= s > no > >>>>> cross- customer effect. For example if an LER BC is synchronized= to > >>>>> a specific grandmaster, belonging to customer A, then the LER MUS= T > >>>>> use that BC clock only for customer A to ensure that customer A > >>>>> cannot attack other customers by manipulating its time. > >>>>> > >>>>> Timing messages MAY be encrypted or authenticated, provided that > the > >>>>> LERs/LSRs that are Timing capable/aware can authenticate/ decrypt > the > >>>>> timing messages. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 26] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 18. Acknowledgements > >>>>> > >>>>> The authors would like to thank Ron Cohen, Yaakov Stein, Tal Mizr= ahi, > >>>>> Stefano Ruffini, Peter Meyer, and other members of IETF for revie= wing > >>>>> and providing feedback on this draft. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 27] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 19. IANA Considerations > >>>>> > >>>>> There are no IANA requirements in this specification. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 28] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 20. References > >>>>> > >>>>> 20.1. Normative References > >>>>> > >>>>> [IEEE-1588] > >>>>> IEEE 1588-2008, "IEEE Standard for a Precision Clock > >>>>> Synchronization Protocol for Networked Measurement and > >>>>> Control Systems". > >>>>> > >>>>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > >>>>> Requirement Levels", BCP 14, RFC 2119, March 1997. > >>>>> > >>>>> [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to= - > >>>>> Edge (PWE3) Architecture", RFC 3985, March 2005. > >>>>> > >>>>> [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discov= ery > >>>>> Proxies (ND Proxy)", RFC 4389, April 2006. > >>>>> > >>>>> [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G= . > >>>>> Heron, "Pseudowire Setup and Maintenance Using the Lab= el > >>>>> Distribution Protocol (LDP)", RFC 4447, April 2006. > >>>>> > >>>>> [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, > >>>>> "Encapsulation Methods for Transport of Ethernet over= MPLS > >>>>> Networks", RFC 4448, April 2006. > >>>>> > >>>>> [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire > >>>>> Emulation Edge-to-Edge (PWE3) Frame Check Sequence > >>>>> Retention", RFC 4720, November 2006. > >>>>> > >>>>> [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circu= it > >>>>> Connectivity Verification (VCCV): A Control Channel fo= r > >>>>> Pseudowires", RFC 5085, December 2007. > >>>>> > >>>>> [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detect= ion > >>>>> (BFD)", RFC 5880, June 2010. > >>>>> > >>>>> [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow= , > >>>>> "Bidirectional Forwarding Detection (BFD) for MPLS Lab= el > >>>>> Switched Paths (LSPs)", RFC 5884, June 2010. > >>>>> > >>>>> 20.2. Informative References > >>>>> > >>>>> [I-D.ietf-pwe3-fat-pw] > >>>>> Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Reg= an, > >>>>> J., and S. Amante, "Flow Aware Transport of Pseudowire= s > >>>>> over an MPLS Packet Switched Network", > >>>>> draft-ietf-pwe3-fat-pw-07 (work in progress), July 201= 1. > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 29] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermedia= te > >>>>> system routeing information exchange protocol for use= in > >>>>> conjunction with the Protocol for providing the > >>>>> Connectionless-mode Network Service (ISO 8473)". > >>>>> > >>>>> [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP an= d > >>>>> dual environments", RFC 1195, December 1990. > >>>>> > >>>>> [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 199= 8. > >>>>> > >>>>> [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color > >>>>> Marker", RFC 2697, September 1999. > >>>>> > >>>>> [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boud= ec, > >>>>> J., Courtney, W., Davari, S., Firoiu, V., and D. > >>>>> Stiliadis, "An Expedited Forwarding PHB (Per-Hop > >>>>> Behavior)", RFC 3246, March 2002. > >>>>> > >>>>> [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Enginee= ring > >>>>> (TE) Extensions to OSPF Version 2", RFC 3630, > >>>>> September 2003. > >>>>> > >>>>> [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermedia= te > >>>>> System (IS-IS) Extensions for Traffic Engineering (TE)= ", > >>>>> RFC 3784, June 2004. > >>>>> > >>>>> [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and= S. > >>>>> Shaffer, "Extensions to OSPF for Advertising Optional > >>>>> Router Capabilities", RFC 4970, July 2007. > >>>>> > >>>>> [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate > >>>>> System to Intermediate System (IS-IS) Extensions for > >>>>> Advertising Router Information", RFC 4971, July 2007. > >>>>> > >>>>> [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi > >>>>> Topology (MT) Routing in Intermediate System to > >>>>> Intermediate Systems (IS-ISs)", RFC 5120, February 200= 8. > >>>>> > >>>>> [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic > >>>>> Engineering", RFC 5305, October 2008. > >>>>> > >>>>> [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, > >>>>> "Traffic Engineering Extensions to OSPF Version 3", > >>>>> RFC 5329, September 2008. > >>>>> > >>>>> [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSP= F > >>>>> for IPv6", RFC 5340, July 2008. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 30] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Net= work > >>>>> Time Protocol Version 4: Protocol and Algorithms > >>>>> Specification", RFC 5905, June 2010. > >>>>> > >>>>> [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Reg= an, > >>>>> J., and S. Amante, "Flow-Aware Transport of Pseudowire= s > >>>>> over an MPLS Packet Switched Network", RFC 6391, > >>>>> November 2011. > >>>>> > >>>>> [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., a= nd > >>>>> L. Yong, "The Use of Entropy Labels in MPLS Forwarding= ", > >>>>> RFC 6790, November 2012. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 31] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 1. Routing extensions for Timing-aware Routers > >>>>> > >>>>> MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] > and > >>>>> IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (= TE) > >>>>> link information used for constraint-based routing. > >>>>> > >>>>> Indeed, it is useful to advertise data plane TE router link > >>>>> capabilities, such as the capability for a router to be Timing-aw= are. > >>>>> This capability MUST then be taken into account during path > >>>>> computation to prefer or even require links that advertise themse= lves > >>>>> as Timing-aware. In this way the path can ensure the entry and e= xit > >>>>> points into the LERs and, if desired, the links into the LSRs are > >>>>> able to perform port based time-stamping thus minimizing their im= pact > >>>>> on the performance of the slave clock. > >>>>> > >>>>> extensions are required to OSPF and IS-IS in order to advertise > >>>>> Timing-aware capabilities of a link. Such extensions are outside= the > >>>>> scope of this document; however such extension SHOULD be able to > >>>>> signal the following information per Router Link: > >>>>> > >>>>> o Capable of processing PTP, NTP or other Timing flows > >>>>> > >>>>> o Capable of performing Transparent Clock operation > >>>>> > >>>>> o Capable of performing Boundary Clock operation > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 32] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> 2. Signaling Extensions for Creating Timing LSPs > >>>>> > >>>>> RSVP-TE signaling MAY be used to setup the timing LSPs. When RSV= P- > TE > >>>>> is used to setup Timing LSPs, some information that indicates tha= t > >>>>> the LSP is carrying Timing flows MUST be included in the new > >>>>> Extensions to RSVP-TE: > >>>>> > >>>>> The following information MAY also be included in the new Extensi= ons > >>>>> to RSVP-TE: > >>>>> > >>>>> o Offset from Bottom of Stack (BoS) to the start of the Time-sta= mp > >>>>> field > >>>>> > >>>>> o Number of VLANs in case of PW encapsulation > >>>>> > >>>>> o Timestamp field Type > >>>>> > >>>>> * Correction Field, Timestamp > >>>>> > >>>>> o Timestamp Field format > >>>>> > >>>>> * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit > >>>>> NTP, etc. > >>>>> > >>>>> Note that in case the above optional information is signaled with > >>>>> RSVP-TE for a Timing LSP, all the Timing packets carried in that= LSP > >>>>> must have the same signaled characteristics. For example if > >>>>> Timestamp format is signaled as 64-bit PTPv1, then all Timing pac= kets > >>>>> must use 64-bit PTPv1 time-stamp. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 33] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> Authors' Addresses > >>>>> > >>>>> Shahram Davari > >>>>> Broadcom Corp. > >>>>> San Jose, CA 95134 > >>>>> USA > >>>>> > >>>>> Email: davari@broadcom.com > >>>>> > >>>>> > >>>>> Amit Oren > >>>>> Broadcom Corp. > >>>>> San Jose, CA 95134 > >>>>> USA > >>>>> > >>>>> Email: amito@broadcom.com > >>>>> > >>>>> > >>>>> Manav Bhatia > >>>>> Alcatel-Lucent > >>>>> Bangalore, > >>>>> India > >>>>> > >>>>> Email: manav.bhatia@alcatel-lucent.com > >>>>> > >>>>> > >>>>> Peter Roberts > >>>>> Alcatel-Lucent > >>>>> Kanata, > >>>>> Canada > >>>>> > >>>>> Email: peter.roberts@alcatel-lucent.com > >>>>> > >>>>> > >>>>> Laurent Montini > >>>>> Cisco Systems > >>>>> San Jose CA > >>>>> USA > >>>>> > >>>>> Email: lmontini@cisco.com > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 34] > >>>>> Internet-Draft Transporting Timing over MPLS June= 2013 > >>>>> > >>>>> > >>>>> Luca > >>>>> Cisco Systems > >>>>> San Jose CA > >>>>> USA > >>>>> > >>>>> Email: lmartini@cisco.com > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Davari, et al. Expires December 17, 2013 [Page= 35] > >>>>> -- > >>>>> For corporate legal information go to: > >>>>> > >>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html > >>>>> > >>>>> _______________________________________________ > >>>>> TICTOC mailing list > >>>>> TICTOC@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/tictoc > >>>> > >>>> 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 > >>> . > >> > >> > >> -- > >> For corporate legal information go to: > >> > >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html > >> > >> _______________________________________________ > >> TICTOC mailing list > >> TICTOC@ietf.org > >> https://www.ietf.org/mailman/listinfo/tictoc > >> > >> > >> _______________________________________________ > >> TICTOC mailing list > >> TICTOC@ietf.org > >> https://www.ietf.org/mailman/listinfo/tictoc > > > > > > 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. > > 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 saalvare@cisco.com Tue Aug 6 08:53:30 2013 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 B6D5221F9FF9 for ; Tue, 6 Aug 2013 08:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ko5kf3MjVc4a for ; Tue, 6 Aug 2013 08:53:25 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0B07721F9980 for ; Tue, 6 Aug 2013 08:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3476; q=dns/txt; s=iport; t=1375804392; x=1377013992; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nNT/qp8I/7RIc/cPGAG0ww0Oh5jh04+WCYw43BC32V4=; b=H2clU+jSkWlt59DwMD5lQqziTiQjpR68tPeipuWHR/7cqg9fUv+xaVJZ lqxbIXuvVNTONTE1rXPAoNKtfXvmy3VV8V0qNt/lD5cFYf2yOMGPCqXHC r9vdwE5Mx35Rx4YsnSJk4+5L4lyYVpocrcIkmmdJ+eO4T2IK4MzTmFSmW Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAMsaAVKtJV2d/2dsb2JhbABagwY1UL59gR0WdIIkAQEBAwEBAQE3NAsFBwQCAQgRBAEBCxQJBycLFAkIAQEEAQ0FCIgCBgy2TgSPaTEHBoMUdAOpL4MXgWgFPQ X-IronPort-AV: E=Sophos;i="4.89,827,1367971200"; d="scan'208";a="244217623" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 06 Aug 2013 15:53:08 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r76Fr7lZ020392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Aug 2013 15:53:07 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.187]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 6 Aug 2013 10:53:07 -0500 From: "Santiago Alvarez (saalvare)" To: Ina Minei , "mpls@ietf.org" Thread-Topic: LDP Color LSP - downstream unsolicited and on-demand Thread-Index: Ac6PWyqry9DwoxlGSgaq5SIsAqUn8wABmFzQALsUu5A= Date: Tue, 6 Aug 2013 15:53:06 +0000 Message-ID: <0C8935EE66D53445A3D3982BD9BE54681DFC7473@xmb-aln-x09.cisco.com> References: <0C8935EE66D53445A3D3982BD9BE54681DFADE56@xmb-aln-x09.cisco.com> <70BDAD02381BA54CA31315A2A26A7AD30383F771@BLUPRD0511MB436.namprd05.prod.outlook.com> In-Reply-To: <70BDAD02381BA54CA31315A2A26A7AD30383F771@BLUPRD0511MB436.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.163.88] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Santiago Alvarez \(saalvare\)" Subject: Re: [mpls] LDP Color LSP - downstream unsolicited and on-demand 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, 06 Aug 2013 15:53:30 -0000 Ina, Comments below. Thanks. Cheers. SA -- > -----Original Message----- > From: Ina Minei [mailto:ina@juniper.net] > Sent: Friday, August 02, 2013 2:59 AM > To: Santiago Alvarez (saalvare); mpls@ietf.org > Subject: RE: LDP Color LSP - downstream unsolicited and on-demand >=20 > Thank you for pointing out the text. >=20 > A few questions on the draft: > - can you explain how the egress would know the colors it should > advertise? (I am assuming you are assuming additional information from > a different protocol, it would be good for the document to explicitly > state this is the case and provide a use case) How an egress decides what colors to signal interest for is currently out o= f scope. If you feel it should be otherwise, I'd be interested in hearing = your views. > - What kind of guarantees can the head end have regarding the path > established, given that it has no indication whether all routers in the > path support color matches or were able to select a path conforming to > the colors (basically only part of the path conforms to colors) and how > does this relate to the use cases solved.=20 Using the terminology in section 3, the color LSR is the device responsible= for initiating the advertisement of label mappings with an explicit color = id. If an ingress LSR receives such mapping, it can tell that there's at l= east one color LSR between itself and the egress LSR with a matching path, = plus the LSRs between itself and the color LSR are capable of signaling col= or LSPs. > To give an extreme example, > if c1 is "low latency" and c2 is "high latency", the egress signals for > C1 but at node X only color c2 is available, given the requirement in > section 5 for "at least one default path", what can be said of the > resulting path at the head end (apart from the fact that a path > exists). Does this mean that the default path has to be defined per > color? If X is a color LSR and only has a C2 path and no default, the ingress LSR = would receive no path to the destination prefix. > - the document does not specify the lsping processing rules, in > particular at nodes where a particular color does not exist. Can you > explain? I believe there are some additional LSP Ping details that we need to define= in a later revision.=20 =20 >=20 > Thanks, >=20 > Ina >=20 >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Santiago Alvarez (saalvare) > Sent: Friday, August 02, 2013 1:38 AM > To: mpls@ietf.org > Cc: Santiago Alvarez (saalvare) > Subject: [mpls] LDP Color LSP - downstream unsolicited and on-demand >=20 > If I understood the question correctly, Ina asked why draft-alvarez- > mpls-ldp-color-lsp-00 was only considering downstream unsolicited label > allocation. As mentioned on the mic, draft focuses on downstream label > allocation, both unsolicited and on-demand. Here's a snippet from the > current doc: >=20 > " An egress LSR MAY include the Color List TLV in a Label Mapping > Message if using Downstream Unsolicited mode. An LSR may include > the > TLV in Label Request Messages if using Downstream on Demand mode. > " >=20 > Any further feedback appreciated. Thanks. >=20 > SA > -- >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 >=20 From internet-drafts@ietf.org Tue Aug 6 12:31:31 2013 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 AEDED21F9E13; Tue, 6 Aug 2013 12:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, 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 QDZdxnIGeCQW; Tue, 6 Aug 2013 12:31:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C28221F9D34; Tue, 6 Aug 2013 12:31: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: 4.70 Message-ID: <20130806193131.4978.94649.idtracker@ietfa.amsl.com> Date: Tue, 06 Aug 2013 12:31:31 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-1ton-protection-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, 06 Aug 2013 19:31: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 Gro= up of the IETF. Title : MPLS-TP 1toN Protection Author(s) : Eric Osborne Fei Zhang Yaacov Weingarten Filename : draft-ietf-mpls-tp-1ton-protection-02.txt Pages : 36 Date : 2013-08-06 Abstract: There is a requirement for Multiprotocol Label Switching Transport Profile(MPLS-TP) to support 1:n linear protection for transport paths. This requirement is further elaborated in RFC6372 [SurvivFwk]. The basic protocol for linear protection, specified in RFC6378 [LinProt], is limited to 1+1 and 1:1 protection. This document extends that protocol to address the additional functionality necessary to support scenarios where a single protection path is preconfigured to provide protection of multiple transport paths between two joint endpoints. 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-1ton-protection There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-1ton-protection-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-1ton-protection-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietf-ipr@ietf.org Tue Aug 6 13:28:27 2013 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 1DDFC21E809E; Tue, 6 Aug 2013 13:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.201, 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 2PzybDjq6gxt; Tue, 6 Aug 2013 13:28:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C4611E80EA; Tue, 6 Aug 2013 13:28:23 -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,vlim@cisco.com,aldrin.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 4.70 Message-ID: <20130806202823.3114.27860.idtracker@ietfa.amsl.com> Date: Tue, 06 Aug 2013 13:28:23 -0700 Cc: mpls@ietf.org, rcallon@juniper.net, ipr-announce@ietf.org Subject: [mpls] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-mpls-proxy-lsp-ping-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, 06 Aug 2013 20:28:27 -0000 Dear George Swallow, Vanson Lim, Sam Aldrin: An IPR disclosure that pertains to your Internet-Draft entitled "Proxy MPLS Echo Request" (draft-ietf-mpls-proxy-lsp-ping) was submitted to the IETF Secretariat on 2013-08-05 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2164/). The = title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-mp= ls- proxy-lsp-ping-00.""); The IETF Secretariat From ina@juniper.net Tue Aug 6 16:20:36 2013 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 B2AAB21F9425 for ; Tue, 6 Aug 2013 16:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.283 X-Spam-Level: X-Spam-Status: No, score=-1.283 tagged_above=-999 required=5 tests=[AWL=1.316, 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 J7Y0eic6gcNY for ; Tue, 6 Aug 2013 16:20:31 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0250.outbound.messaging.microsoft.com [213.199.154.250]) by ietfa.amsl.com (Postfix) with ESMTP id 89B2B21F9984 for ; Tue, 6 Aug 2013 16:20:29 -0700 (PDT) Received: from mail102-db9-R.bigfish.com (10.174.16.240) by DB9EHSOBE025.bigfish.com (10.174.14.88) with Microsoft SMTP Server id 14.1.225.22; Tue, 6 Aug 2013 23:20:28 +0000 Received: from mail102-db9 (localhost [127.0.0.1]) by mail102-db9-R.bigfish.com (Postfix) with ESMTP id 771672024D; Tue, 6 Aug 2013 23:20:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz9371I542I1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275dh1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: pass (mail102-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=ina@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(377454003)(189002)(199002)(13464003)(164054003)(49866001)(76482001)(74316001)(56776001)(47976001)(66066001)(74502001)(50986001)(47736001)(33646001)(63696002)(74366001)(79102001)(54316002)(65816001)(59766001)(77982001)(74662001)(54356001)(80022001)(47446002)(31966008)(69226001)(19580405001)(19580385001)(83322001)(19580395003)(74876001)(46102001)(81542001)(80976001)(81342001)(16406001)(51856001)(83072001)(74706001)(53806001)(4396001)(76786001)(76796001)(76576001)(77096001)(56816003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB048; H:BY2PR05MB048.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail102-db9 (localhost.localdomain [127.0.0.1]) by mail102-db9 (MessageSwitch) id 1375831226622845_15726; Tue, 6 Aug 2013 23:20:26 +0000 (UTC) Received: from DB9EHSMHS028.bigfish.com (unknown [10.174.16.245]) by mail102-db9.bigfish.com (Postfix) with ESMTP id 93E8834004B; Tue, 6 Aug 2013 23:20:26 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS028.bigfish.com (10.174.14.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 6 Aug 2013 23:20:25 +0000 Received: from BY2PR05MB048.namprd05.prod.outlook.com (10.242.34.156) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.341.1; Tue, 6 Aug 2013 23:20:20 +0000 Received: from BY2PR05MB048.namprd05.prod.outlook.com (10.242.34.156) by BY2PR05MB048.namprd05.prod.outlook.com (10.242.34.156) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 6 Aug 2013 23:20:17 +0000 Received: from BY2PR05MB048.namprd05.prod.outlook.com ([169.254.9.249]) by BY2PR05MB048.namprd05.prod.outlook.com ([169.254.9.68]) with mapi id 15.00.0731.000; Tue, 6 Aug 2013 23:20:14 +0000 From: Ina Minei To: "Santiago Alvarez (saalvare)" , "mpls@ietf.org" Thread-Topic: LDP Color LSP - downstream unsolicited and on-demand Thread-Index: Ac6PWyqry9DwoxlGSgaq5SIsAqUn8wABmFzQALsUu5AAKq7SIA== Date: Tue, 6 Aug 2013 23:20:14 +0000 Message-ID: <25d835b34e4745839a86fb66f39c200d@BY2PR05MB048.namprd05.prod.outlook.com> References: <0C8935EE66D53445A3D3982BD9BE54681DFADE56@xmb-aln-x09.cisco.com> <70BDAD02381BA54CA31315A2A26A7AD30383F771@BLUPRD0511MB436.namprd05.prod.outlook.com> <0C8935EE66D53445A3D3982BD9BE54681DFC7473@xmb-aln-x09.cisco.com> In-Reply-To: <0C8935EE66D53445A3D3982BD9BE54681DFC7473@xmb-aln-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 0930AAFAD9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [mpls] LDP Color LSP - downstream unsolicited and on-demand 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, 06 Aug 2013 23:20:36 -0000 Santiago,=20 Please see inline.=20 > A few questions on the draft: > - can you explain how the egress would know the colors it should=20 > advertise? (I am assuming you are assuming additional information from=20 > a different protocol, it would be good for the document to explicitly=20 > state this is the case and provide a use case) How an egress decides what colors to signal interest for is currently out o= f scope. If you feel it should be otherwise, I'd be interested in hearing = your views. ### I agree it is out of scope, but the draft should say so explicitly. The= current text says: "Egress LSR: May signal interest in particular colors towards upstream LSRs in order to influence the signaling behavior of color LSRs." You may want to add that how the egress determines the colors it is interes= ted in, and whether or not additional protocols are necessary, is outside t= he scope of this document.=20 ### It might also be very good to add a motivation/use cases section, which= may further clarify the use (right now there is one paragraph only, in the= introduction section). I find this paragraph (starting with "A sample depl= oyment scenario") a bit confusing, since it implies that the characteristic= s of the path are not necessarily end to end, but apply to just a part of t= he path (the text "implement a forwarding preference for low latency or hig= h bandwidth at the downstream P device"). Most of my comments below treat c= olor as a characteristic of the link and assume it has to exist for all lin= ks in the path. It would really help to clarify these assumptions and use c= ases up front.=20 > - What kind of guarantees can the head end have regarding the path=20 > established, given that it has no indication whether all routers in=20 > the path support color matches or were able to select a path=20 > conforming to the colors (basically only part of the path conforms to=20 > colors) and how does this relate to the use cases solved. Using the terminology in section 3, the color LSR is the device responsible= for initiating the advertisement of label mappings with an explicit color = id. If an ingress LSR receives such mapping, it can tell that there's at l= east one color LSR between itself and the egress LSR with a matching path, = plus the LSRs between itself and the color LSR are capable of signaling col= or LSPs. ### see my comment above. > To give an extreme example, > if c1 is "low latency" and c2 is "high latency", the egress signals=20 > for > C1 but at node X only color c2 is available, given the requirement in=20 > section 5 for "at least one default path", what can be said of the=20 > resulting path at the head end (apart from the fact that a path=20 > exists). Does this mean that the default path has to be defined per=20 > color? If X is a color LSR and only has a C2 path and no default, the ingress LSR = would receive no path to the destination prefix. ### I don't understand why this would be the case. Section 5 says:=20 " At least one path MUST be defined as the "default" path. This path SHOULD be used as a second best match in the absence of an exact color match."=20 So in this case, at node X the path with color C2 MUST also be the default,= no? I am confused about the specification, I'm sure I'm missing something = in the operation (and I mean this in a constructive way, hoping this discus= sion will help make the draft a bit clearer). I think the main difference i= n how I am thinking of it and how the draft is written is that the draft se= ems to focus on use cases where there is a choice at some mid-point, and I = am thinking of use cases where all links must comply to the color.=20 ### Final question - the draft assumes ordered control, correct? You may wa= nt to spell this out explicitly as well.=20 > - the document does not specify the lsping processing rules, in=20 > particular at nodes where a particular color does not exist. Can you=20 > explain? I believe there are some additional LSP Ping details that we need to define= in a later revision.=20 =20 >=20 > Thanks, >=20 > Ina >=20 >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=20 > Of Santiago Alvarez (saalvare) > Sent: Friday, August 02, 2013 1:38 AM > To: mpls@ietf.org > Cc: Santiago Alvarez (saalvare) > Subject: [mpls] LDP Color LSP - downstream unsolicited and on-demand >=20 > If I understood the question correctly, Ina asked why draft-alvarez- > mpls-ldp-color-lsp-00 was only considering downstream unsolicited=20 > label allocation. As mentioned on the mic, draft focuses on=20 > downstream label allocation, both unsolicited and on-demand. Here's a=20 > snippet from the current doc: >=20 > " An egress LSR MAY include the Color List TLV in a Label Mapping > Message if using Downstream Unsolicited mode. An LSR may include=20 > the > TLV in Label Request Messages if using Downstream on Demand mode. > " >=20 > Any further feedback appreciated. Thanks. >=20 > SA > -- >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 >=20 From loa@pi.nu Wed Aug 7 05:28:34 2013 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 7698D21F9E8B for ; Wed, 7 Aug 2013 05:28:34 -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 AQwmq0eQRya8 for ; Wed, 7 Aug 2013 05:28:29 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 36F5421F9B66 for ; Wed, 7 Aug 2013 05:28:28 -0700 (PDT) Received: from [109.58.177.73] (109.58.177.73.bredband.tre.se [109.58.177.73]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id DEC211801589; Wed, 7 Aug 2013 14:28:26 +0200 (CEST) Message-ID: <52023D71.3020708@pi.nu> Date: Wed, 07 Aug 2013 14:28:33 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: curtis@ipv6.occnc.com References: <201307261743.r6QHhwjG065662@gateway1.orleans.occnc.com> In-Reply-To: <201307261743.r6QHhwjG065662@gateway1.orleans.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" , Kireeti Kompella Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 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, 07 Aug 2013 12:28:34 -0000 Folks, I'm trying to sort out the ELI / special purpose labels issue. If I understand Kireeti correctly what he say is that if we declare 15/ELI/EL an error (i.e. 15/ELI "reserved do not assign"), then anyone searching a label stack and fing the ELI needs to check whether there is a label with the value 15 before it. This creates extra logic that has to executed and written. I think this is true. At least if you allow for that some implementations that today are standard compatible, but just blindly scans through the label stack to find the ELI and don't bother to look at the other labels than the EL. However, I think we need to look if there are other cases there what is proposed by Kireeti leads to increasing complexity. If we for example we know that the 16 lowest values are not in the ranges allocated for extended label space that might simplify the search of the labels in the extended space. Any HW aspects on this? /Loa On 2013-07-26 19:43, Curtis Villamizar wrote: > > In message <62CCD4C52ACDAD4481149BD5D8A72FD316D6FE01@CH1PRD0510MB355.namprd05.prod.outlook.com> > Ross Callon writes: > >> Reminder, please send responses to the MPLS WG email list. >> >> Thanks, Ross >> >> From: Ross Callon [mailto:rcallon@juniper.net] >> Sent: Tuesday, July 16, 2013 1:00 PM >> To: mpls@ietf.org; draft-ietf-mpls-special-purpose-labels@tools.ietf.org >> Cc: mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) >> Subject: MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 >> >> Working Group, >> >> This is to start Working Group last call on >> draft-ietf-mpls-special-purpose-labels-03 >> >> Please send your comments to the mpls working group mailing list >> (mpls@ietf.org). >> >> Please send both technical comments, and (if you are happy with the >> document as is) also send indications of support. >> >> There are no IPR claims against this draft. The co-authors have >> earlier stated that they are not aware of any IPR applicable to this >> draft. >> >> If anyone else in the working group is aware of IPRs claims against >> this draft, the time to disclose that is now. >> >> Due to the upcoming IETF meeting in Berlin, this last call will be >> extended by an extra week (which implies that the last call will be >> ongoing during the IETF meeting). This working group last call will >> end on August 6, 2013. >> >> Ross >> for the wg co-chairs > > > Ross, authors, > > I really don't see the value of using 7 as an extended special purpose > label. > > Values 0-6 and 8-15 of the extended special purpose label registry > are set aside as reserved; these MUST NOT appear in the data plane. > Label 7 (when received) retains its meaning as ELI whether a regular > or an extended special purpose label; this is to simplify the logic > for transit LSRs looking for entropy labels. However, an LSR wishing > to insert an entropy label SHOULD insert label 7 as a regular special > purpose label, not as an extended special purpose label. > > Why insert 15 ELI EL rather than ELI EL. If only new LSR insert EL, > why not make the MUST not apply to use of 0-15 as extended special > purpose labels. I suggest replacing with: > > Values 0-15 of the extended special purpose label registry are set > aside as reserved; these MUST NOT appear in the data plane. > > This would also change table 1. > > I would also drop bullet 3 from the list in IANA Considerations. That > bullet contains the text "Note: any new allocation from the Special > Purpose MPLS Label Values registry MUST also say whether the same > value needs to be reserved in the Extended Special Purpose MPLS Label > Values registry." > > BTW "extension label" has a acronym collision with entropy label, > unless we abbreviate extension label XL. ESP labels might also be a > good acronym Extended Special Purpose MPLS Label. The acronym > collision with existing use of ESP might actually make sense, > particularly in regard to the experimental ESP range. :-) > > It might help to introduce the acronyms "XL" and "ESP label" or "ESPL" > in this document. > > Right now the document does not say what an LSR should do if it > encounters an unknown (to it) ESP label. This should require a > separate section entitled "Forwarding Packets with Unknown Extension > Labels". If this label is deep in the stack, the it seems that the > best action would be to always ignore it. > > In thinking about what an LSR should do, there are two possibilities > if the unknown ESP label hits the top of the stack. One possibility > is drop the packet. The other is pop the XL and ESP and process the > next label or BOS. One way to accomplish that would be to reserve a > range for each of these two possibilities. Tabel 1 becomes. > > +---------------+----------------------------------------------+ > | Range | Allocation Policy | > +---------------+----------------------------------------------+ > | 0 - 15 | Reserved. Not to be allocated. MUST NOT | > | | appear in the data plane. | > | | | > | 16 - 127 | Standards Action (drop packet if unknown) | > | | | > | 128 - 239 | Standards Action (pop XL and ESP if unknown) | > | | | > | 240 - 247 | Experimental (drop packet if unknown) | > | | | > | 248 - 255 | Experimental (pop XL and ESP if unknown) | > | | | > | 256 - 1048575 | Reserved | > +---------------+----------------------------------------------+ > > The experimental ESP space could also be split in the same way. The > experimental space is small. Maybe that's good. > > Only if we think there might be a reason to drop a packet with unknown > ESP label deep in the stack would we want to further split the space > to include that possibility. > > If there is no concensus behind the changes I've suggested here, then > I support the document going forward. I would prefer that the > suggested changes be seriously considered. > > Curtis > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From internet-drafts@ietf.org Wed Aug 7 10:37:01 2013 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 56D0421F9A78; Wed, 7 Aug 2013 10:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.008, 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 mKmyPymvXdxh; Wed, 7 Aug 2013 10:37:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F86721F848A; Wed, 7 Aug 2013 10:36: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: 4.70.p1 Message-ID: <20130807173631.14025.46345.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2013 10:36:31 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-linear-protection-mib-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: Wed, 07 Aug 2013 17:37:01 -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 Gro= up of the IETF. Title : MPLS Transport Profile Linear Protection MIB Author(s) : Kingston Smiler Selvaraj Venkatesan Mahalingam Vishwas Manral Daniel King Sam Aldrin Filename : draft-ietf-mpls-tp-linear-protection-mib-01.txt Pages : 29 Date : 2013-08-07 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing MPLS Transport Profile (MPLS-TP) Linear Protection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-linear-protection-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-linear-protection-mib-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-linear-protection-mib= -01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From eosborne@cisco.com Thu Aug 8 05:34:38 2013 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 9F70E21F9EAD for ; Thu, 8 Aug 2013 05:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92CEE6IhLvbz for ; Thu, 8 Aug 2013 05:34:33 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAB621F9EB5 for ; Thu, 8 Aug 2013 05:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5553; q=dns/txt; s=iport; t=1375965273; x=1377174873; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=675+bOLGdzYZZvktGbdn902fFKSQ77nJXymqDEjDwDA=; b=YPIWjS90ZWU5VSH4bVrzntz6YzqGpfq/lHncyh3QEOfhII0qQ/v9aVyY LWiPZI+y22Iyc/Lkj4PsxgXC+6mit1ZM98FYqqOPzPH36psOvfSpMYXRB 6wCoHytDzAyXmVRA36sk34DQtUrYP8a05ghEnEl+JFQnKf3CMm5+B9l6p E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAJSPA1KtJXHA/2dsb2JhbABbgwY1UL5JgRoWdIImAQQnE1EBKhRCJgEEGwGIBwyYJaAvj2qDUnQDlAqVJoMYgio X-IronPort-AV: E=Sophos;i="4.89,838,1367971200"; d="scan'208";a="245083022" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 08 Aug 2013 12:34:26 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r78CYQw7000534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 8 Aug 2013 12:34:26 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.235]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 8 Aug 2013 07:34:25 -0500 From: "Eric Osborne (eosborne)" To: "mpls@ietf.org" Thread-Topic: Mode negotiation for PSC Thread-Index: Ac6ULYh0Wz1ulMCERKa7JFuZBxS/GA== Date: Thu, 8 Aug 2013 12:34:25 +0000 Message-ID: <20ECF67871905846A80F77F8F4A27572102C229B@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.66.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] Mode negotiation for PSC 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, 08 Aug 2013 12:34:38 -0000 As per last Friday's presentation in Berlin (http://www.ietf.org/proceeding= s/87/slides/slides-87-mpls-15.ppt), we will be adding "ITU Mode" to PSC to = allow for behaviors that satisfy both IETF and ITU requirements. This mode= will be backward-compatible and negotiated using PSC TLVs. =20 The drafts in that ppt define five capabilities which separate ITU mode fro= m IETF mode. IETF mode is defined as the absence of these five capabilitie= s, and ITU mode is defined as the use of all five of these capabilities. I= t may help to think of IETF mode as 00000 and ITU mode as 11111. The mecha= nism to define and negotiate these modes will have room for expansion past = five bits, so if we ever decide we need more capabilities negotiation in PS= C (shared mesh? m:n? other fancy stuff?) we can. =20 As of right now we are only discussing two modes, but it is possible to def= ine a mode which is some combination of these five things other than 00000 = or 11111. So a mode is really the set of negotiated capabilities between t= wo devices. There are two ways we can negotiate the use of one more or the other: 1) Each node announces the mode that it wants, and if the other side doesn'= t want exactly the same mode then PSC will not function. That is, both nod= es say "my mode is 0bxxxxx" (for now, either 00000 or 11111) and if both no= des don't say the same thing then they complain to the operator and refuse = to function. Advantage: easy, and if both ends are in a single administrative domain I e= xpect the operator to be able to configure both ends to match. Disadvantage: tricky if we ever start talking about modes other than 00000 = or 11111. I don't want a node to say "I support mode 00000, mode 00001, mo= de 00010, mode 00011, .... mode 11111" because if we add a few more capabil= ities we could end up announcing the support of hundreds or thousands of mo= des. Does not allow PSC to come up unless the modes match on both sides, e= ven if there is some common subset they could both agree on. or 2) Each node announces the set of capabilities that it can support along wi= th the ones that it requires, and if the two nodes can find a common subset= of features then they will converge on those features in PSC. Advantage: flexible. If two endpoints can find a common feature subset (se= e example below) then they will come up. Disadvantage: more complex code, easier to get wrong and converge on a unde= sirable subset. Examples of each negotiation method are below, both for clarity and to demo= nstrate that method #2 works. My question for the WG is, which one would p= eople prefer, and why? eric --------------------------------- Examples =3D=3D=3D=3D=3D=3D=3D=3D All examples are between two nodes, A and Z. These examples focus on the a= ctual negotiation, not on the necessary TLV bits to enable the negotiation. Example of method 1 ------------------- Node A sends a single TLV to Node Z containg the mode bitmap. Node Z sends= the same to A. Call them A.Mode and Z.Mode. If they do not match then so= me default behavior happens - either PSC doesn't come up or they default to= one predetermined mode. A.mode =3D Z. mode =3D 00000 A->Z: "I am configured for mode 00000" Z->A: "I am configured for mode 00000" This results in PSC coming up in IETF mode. A.mode =3D Z.mode =3D 11111 A->Z: "I am configured for mode 11111" Z->A: "I am configured for mode 11111" This results in PSC coming up in ITU mode. A.mode !=3D Z.mode (say, 00001 and 00010) A->Z: "I am configured for mode 00001" Z->A: "I am configured for mode 00010" PSC does not come up. Example of method 2 ------------------- Both Node A and Node Z announce two things - Capabilities and Mask. Capabilities is a bitmap of the capabilities that are supported. Mask is a mask of don't-care bits against the Capabilities string. A 0 in = Mask means "I don't care if we do this capability or not", and a 1 means "w= e must (or must not) agree on this capability in order to come up". A.capabilities =3D 00000 A.mask =3D 00000 This says "I am capable of supporting all capabilities and I don't care if = we do any of them or not" A.capabilities =3D 00000 A.mask =3D 11111 This says "We must not use any of the optional capabilities" - Capabilities= bits are all zero, and Mask bits say "we must agree that the corresponding= capability is zero". This is 'IETF mode'. A.capabilities =3D 11111 A.mask =3D 11111 This is 'ITU Mode' Where it gets complicated (or awesome, depending on your perspective) is wh= en you have various subsets. Consider: A.Capabilities =3D=3D 01100 A.Mask =3D=3D 01100 Z.Capabilities =3D=3D 01110 Z.Mask =3D=3D 01110 Negotiation procedures. Each side does: res =3D (A.Capabilites & Z.Mask) ^ (Z.Capabilities & A.Mask) res =3D (01100 & 01110) ^ (01110 & 01100) res =3D (01100) ^ (01100) res =3D 00000 if res =3D=3D 0 then it is possible for both sides to find a common subset = that they support. This common subset is called the 'negotiated set', and is determined by: negotiated_set =3D A.Capabilities | B.Capabilities negotiated_set =3D 01100 | 01110=20 negotiated_set =3D 01100 if res !=3D 0 then it is impossible to find a subset that the two ends can = agree on, and PSC will never come up. Once each side computes the negotiated set, they signal it and PSC starts t= o work. From saalvare@cisco.com Thu Aug 8 10:11:03 2013 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 CD9C521E805D for ; Thu, 8 Aug 2013 10:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHjri+SRHKt4 for ; Thu, 8 Aug 2013 10:10:56 -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 466F921E808C for ; Thu, 8 Aug 2013 10:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6342; q=dns/txt; s=iport; t=1375981852; x=1377191452; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xtbUrXcS8spiNTeUkS0/sLcFP5E22z+6b0qTEm2y6mo=; b=KXdT6zcWzpDULY/z4WyP/zgMCF+K0sPY8eQX11NQbjST4FS86JIYMhuq yDA2RUPnF7Fn12MmmWs7hYCnRurtVpFM+ls1ZFeWg7HFif5qT6sN67GVY z9UYmxT7Bb9GRlBe7u0AfbCn+0tVfDDx6QffTD9OdTSEQzecfva6xSj0R E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAHzQA1KtJV2b/2dsb2JhbABbgwY1UL5JgRoWdIIkAQEBBAEBATc0CwwEAgEIEQQBAQsUCQcnCxQJCAEBBAENBQiICAy5JgSPajEHBoMUdAOUCpUmgxiCKg X-IronPort-AV: E=Sophos;i="4.89,840,1367971200"; d="scan'208";a="245149800" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 08 Aug 2013 17:10:44 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r78HAh8k030365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Aug 2013 17:10:43 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.187]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 8 Aug 2013 12:10:43 -0500 From: "Santiago Alvarez (saalvare)" To: Ina Minei , "mpls@ietf.org" Thread-Topic: LDP Color LSP - downstream unsolicited and on-demand Thread-Index: Ac6PWyqry9DwoxlGSgaq5SIsAqUn8wABmFzQALsUu5AAKq7SIABXDGNw Date: Thu, 8 Aug 2013 17:10:42 +0000 Message-ID: <0C8935EE66D53445A3D3982BD9BE54681DFCAD2A@xmb-aln-x09.cisco.com> References: <0C8935EE66D53445A3D3982BD9BE54681DFADE56@xmb-aln-x09.cisco.com> <70BDAD02381BA54CA31315A2A26A7AD30383F771@BLUPRD0511MB436.namprd05.prod.outlook.com> <0C8935EE66D53445A3D3982BD9BE54681DFC7473@xmb-aln-x09.cisco.com> <25d835b34e4745839a86fb66f39c200d@BY2PR05MB048.namprd05.prod.outlook.com> In-Reply-To: <25d835b34e4745839a86fb66f39c200d@BY2PR05MB048.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.163.88] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Santiago Alvarez \(saalvare\)" Subject: Re: [mpls] LDP Color LSP - downstream unsolicited and on-demand 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, 08 Aug 2013 17:11:03 -0000 Hi Ina, Thanks a lot for the feedback. Some comments below. > -----Original Message----- > From: Ina Minei [mailto:ina@juniper.net] > Sent: Tuesday, August 06, 2013 4:20 PM > To: Santiago Alvarez (saalvare); mpls@ietf.org > Subject: RE: LDP Color LSP - downstream unsolicited and on-demand >=20 > Santiago, >=20 > Please see inline. >=20 > > A few questions on the draft: > > - can you explain how the egress would know the colors it should > > advertise? (I am assuming you are assuming additional information > from > > a different protocol, it would be good for the document to explicitly > > state this is the case and provide a use case) >=20 > How an egress decides what colors to signal interest for is currently > out of scope. If you feel it should be otherwise, I'd be interested in > hearing your views. >=20 > ### I agree it is out of scope, but the draft should say so explicitly. > The current text says: > "Egress LSR: > May signal interest in particular colors towards upstream LSRs in > order to influence the signaling behavior of color LSRs." > You may want to add that how the egress determines the colors it is > interested in, and whether or not additional protocols are necessary, > is outside the scope of this document. >=20 Point taken. > ### It might also be very good to add a motivation/use cases section, > which may further clarify the use (right now there is one paragraph > only, in the introduction section). I find this paragraph (starting > with "A sample deployment scenario") a bit confusing, since it implies > that the characteristics of the path are not necessarily end to end, > but apply to just a part of the path (the text "implement a forwarding > preference for low latency or high bandwidth at the downstream P > device"). Most of my comments below treat color as a characteristic of > the link and assume it has to exist for all links in the path. It would > really help to clarify these assumptions and use cases up front. >=20 Point taken. > > - What kind of guarantees can the head end have regarding the path > > established, given that it has no indication whether all routers in > > the path support color matches or were able to select a path > > conforming to the colors (basically only part of the path conforms to > > colors) and how does this relate to the use cases solved. >=20 > Using the terminology in section 3, the color LSR is the device > responsible for initiating the advertisement of label mappings with an > explicit color id. If an ingress LSR receives such mapping, it can > tell that there's at least one color LSR between itself and the egress > LSR with a matching path, plus the LSRs between itself and the color > LSR are capable of signaling color LSPs. > ### see my comment above. >=20 > > To give an extreme example, > > if c1 is "low latency" and c2 is "high latency", the egress signals > > for > > C1 but at node X only color c2 is available, given the requirement in > > section 5 for "at least one default path", what can be said of the > > resulting path at the head end (apart from the fact that a path > > exists). Does this mean that the default path has to be defined per > > color? >=20 > If X is a color LSR and only has a C2 path and no default, the ingress > LSR would receive no path to the destination prefix. >=20 > ### I don't understand why this would be the case. Section 5 says: > " At least one path > MUST be defined as the "default" path. This path SHOULD be used as > a > second best match in the absence of an exact color match." > So in this case, at node X the path with color C2 MUST also be the > default, no? I am confused about the specification, I'm sure I'm > missing something in the operation (and I mean this in a constructive > way, hoping this discussion will help make the draft a bit clearer). I > think the main difference in how I am thinking of it and how the draft > is written is that the draft seems to focus on use cases where there is > a choice at some mid-point, and I am thinking of use cases where all > links must comply to the color. >=20 You accurately introduced it as an extreme example. The way I read your tex= t was a scenario where the default path wasn't operational. We'll look int= o adding some text around the availability of the default path. Also, we're addressing use cases where there's a forwarding choice at some = mid-point. That's certainly one scenario. Extensions should ultimately ad= dress scenarios with multiple (or ultimately all) links/paths complying to = a color. > ### Final question - the draft assumes ordered control, correct? You > may want to spell this out explicitly as well. >=20 Detailing the label mapping procedures is part of the next steps. Thanks again. > > - the document does not specify the lsping processing rules, in > > particular at nodes where a particular color does not exist. Can you > > explain? >=20 > I believe there are some additional LSP Ping details that we need to > define in a later revision. >=20 > > > > Thanks, > > > > Ina > > > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of Santiago Alvarez (saalvare) > > Sent: Friday, August 02, 2013 1:38 AM > > To: mpls@ietf.org > > Cc: Santiago Alvarez (saalvare) > > Subject: [mpls] LDP Color LSP - downstream unsolicited and on-demand > > > > If I understood the question correctly, Ina asked why draft-alvarez- > > mpls-ldp-color-lsp-00 was only considering downstream unsolicited > > label allocation. As mentioned on the mic, draft focuses on > > downstream label allocation, both unsolicited and on-demand. Here's > a > > snippet from the current doc: > > > > " An egress LSR MAY include the Color List TLV in a Label Mapping > > Message if using Downstream Unsolicited mode. An LSR may include > > the > > TLV in Label Request Messages if using Downstream on Demand mode. > > " > > > > Any further feedback appreciated. Thanks. > > > > SA > > -- > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > >=20 >=20 >=20 From pabloisnot@gmail.com Thu Aug 8 10:45:25 2013 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 9FBE511E8153 for ; Thu, 8 Aug 2013 10:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64IKVDqEacjO for ; Thu, 8 Aug 2013 10:45:24 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2E52311E81F5 for ; Thu, 8 Aug 2013 10:45:18 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id pa12so3301637veb.2 for ; Thu, 08 Aug 2013 10:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k30i3IOuEHnRoSDt0zlP5TFTgEC3vHzK12Hok1dPdn8=; b=TqMfURsFEWevW11ABB58yCtAR76vidzwtDaM38SM27+Ef0cfcQGHkSeMBj0P6rCytI /VXpYzmJWzp6c8EhOhri01r4pS4SmT3NoAT0Gui7FxcxgY5iows8/0gFLaSMkyDJXXnt DgISC1e1xaGJYr1uziDCuutMuQc+haGpg/1phNTCv5yZgR2w2kkcnZBYbvKIGjSlt5gh tH1XEPLk3ZGB76KaoRNY2Tq5oVk65q8i6aGEQl/0fkxpGoG+KehMLkSM+0etyQDnsv/c BVqh3Bzww4bFi8Cuu3ThP6FbhNaPg8X/PHGZbtlXwGXDKnQgOHNMrc7zM8cucsG5OqZR X8QA== MIME-Version: 1.0 X-Received: by 10.220.50.10 with SMTP id x10mr2786293vcf.86.1375983918160; Thu, 08 Aug 2013 10:45:18 -0700 (PDT) Received: by 10.52.38.166 with HTTP; Thu, 8 Aug 2013 10:45:18 -0700 (PDT) In-Reply-To: <52023D71.3020708@pi.nu> References: <201307261743.r6QHhwjG065662@gateway1.orleans.occnc.com> <52023D71.3020708@pi.nu> Date: Thu, 8 Aug 2013 13:45:18 -0400 Message-ID: From: Pablo Frank To: Loa Andersson Content-Type: multipart/alternative; boundary=047d7b343f30a8a6a804e37338a7 Cc: "mpls@ietf.org" , Kireeti Kompella , Ross Callon , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 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, 08 Aug 2013 17:45:25 -0000 --047d7b343f30a8a6a804e37338a7 Content-Type: text/plain; charset=ISO-8859-1 I'm not sure a transit LSR needs to enforce the rule, does it? If we rely on the LERs to enforce the rule then the worst that will happen is that a broken packet may get accidentally hashed down the wrong component of a LAG or ECMP but will get discarded anyway when it arrives at the destination. Are there router implementations that do an exhaustive integrity check on the rest of the labels in a label stack once it decides to swap the outermost label? I suspect most don't. I could see a packet coming in with a broken label stack that's missing the BOS bit that could result in erroneous parsing of an "ELI". Or maybe it has on-the-wire implicit NULL label somewhere in the stack. We don't expect transit LSRs to go hunting for these types of problems, right? So why should it hunt for problems with the disposition of the special purpose labels? regards, Pablo On Wed, Aug 7, 2013 at 8:28 AM, Loa Andersson wrote: > Folks, > > I'm trying to sort out the ELI / special purpose labels issue. > > If I understand Kireeti correctly what he say is that if we > declare 15/ELI/EL an error (i.e. 15/ELI "reserved do not assign"), then > anyone searching a label stack and fing the ELI needs to check whether > there is a label with the value 15 before it. This creates extra logic > that has to executed and written. > > I think this is true. At least if you allow for that some > implementations that today are standard compatible, but just blindly > scans through the label stack to find the ELI and don't bother to > look at the other labels than the EL. > > However, I think we need to look if there are other cases there what > is proposed by Kireeti leads to increasing complexity. > > If we for example we know that the 16 lowest values are not in > the ranges allocated for extended label space that might simplify > the search of the labels in the extended space. > > Any HW aspects on this? > > > > > /Loa > > > > > On 2013-07-26 19:43, Curtis Villamizar wrote: > >> >> In message <62CCD4C52ACDAD4481149BD5D8A72**FD316D6FE01@CH1PRD0510MB355.** >> namprd05.prod.outlook.com<62CCD4C52ACDAD4481149BD5D8A72FD316D6FE01@CH1PRD0510MB355.namprd05.prod.outlook.com> >> > >> Ross Callon writes: >> >> Reminder, please send responses to the MPLS WG email list. >>> >>> Thanks, Ross >>> >>> From: Ross Callon [mailto:rcallon@juniper.net] >>> Sent: Tuesday, July 16, 2013 1:00 PM >>> To: mpls@ietf.org; draft-ietf-mpls-special-** >>> purpose-labels@tools.ietf.org >>> Cc: mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) >>> Subject: MPLS WG last call on draft-ietf-mpls-special-** >>> purpose-labels-03 >>> >>> Working Group, >>> >>> This is to start Working Group last call on >>> draft-ietf-mpls-special-**purpose-labels-03 >>> >>> Please send your comments to the mpls working group mailing list >>> (mpls@ietf.org>). >>> >>> Please send both technical comments, and (if you are happy with the >>> document as is) also send indications of support. >>> >>> There are no IPR claims against this draft. The co-authors have >>> earlier stated that they are not aware of any IPR applicable to this >>> draft. >>> >>> If anyone else in the working group is aware of IPRs claims against >>> this draft, the time to disclose that is now. >>> >>> Due to the upcoming IETF meeting in Berlin, this last call will be >>> extended by an extra week (which implies that the last call will be >>> ongoing during the IETF meeting). This working group last call will >>> end on August 6, 2013. >>> >>> Ross >>> for the wg co-chairs >>> >> >> >> Ross, authors, >> >> I really don't see the value of using 7 as an extended special purpose >> label. >> >> Values 0-6 and 8-15 of the extended special purpose label registry >> are set aside as reserved; these MUST NOT appear in the data plane. >> Label 7 (when received) retains its meaning as ELI whether a regular >> or an extended special purpose label; this is to simplify the logic >> for transit LSRs looking for entropy labels. However, an LSR wishing >> to insert an entropy label SHOULD insert label 7 as a regular special >> purpose label, not as an extended special purpose label. >> >> Why insert 15 ELI EL rather than ELI EL. If only new LSR insert EL, >> why not make the MUST not apply to use of 0-15 as extended special >> purpose labels. I suggest replacing with: >> >> Values 0-15 of the extended special purpose label registry are set >> aside as reserved; these MUST NOT appear in the data plane. >> >> This would also change table 1. >> >> I would also drop bullet 3 from the list in IANA Considerations. That >> bullet contains the text "Note: any new allocation from the Special >> Purpose MPLS Label Values registry MUST also say whether the same >> value needs to be reserved in the Extended Special Purpose MPLS Label >> Values registry." >> >> BTW "extension label" has a acronym collision with entropy label, >> unless we abbreviate extension label XL. ESP labels might also be a >> good acronym Extended Special Purpose MPLS Label. The acronym >> collision with existing use of ESP might actually make sense, >> particularly in regard to the experimental ESP range. :-) >> >> It might help to introduce the acronyms "XL" and "ESP label" or "ESPL" >> in this document. >> >> Right now the document does not say what an LSR should do if it >> encounters an unknown (to it) ESP label. This should require a >> separate section entitled "Forwarding Packets with Unknown Extension >> Labels". If this label is deep in the stack, the it seems that the >> best action would be to always ignore it. >> >> In thinking about what an LSR should do, there are two possibilities >> if the unknown ESP label hits the top of the stack. One possibility >> is drop the packet. The other is pop the XL and ESP and process the >> next label or BOS. One way to accomplish that would be to reserve a >> range for each of these two possibilities. Tabel 1 becomes. >> >> +---------------+-------------**------------------------------**---+ >> | Range | Allocation Policy | >> +---------------+-------------**------------------------------**---+ >> | 0 - 15 | Reserved. Not to be allocated. MUST NOT | >> | | appear in the data plane. | >> | | | >> | 16 - 127 | Standards Action (drop packet if unknown) | >> | | | >> | 128 - 239 | Standards Action (pop XL and ESP if unknown) | >> | | | >> | 240 - 247 | Experimental (drop packet if unknown) | >> | | | >> | 248 - 255 | Experimental (pop XL and ESP if unknown) | >> | | | >> | 256 - 1048575 | Reserved | >> +---------------+-------------**------------------------------**---+ >> >> The experimental ESP space could also be split in the same way. The >> experimental space is small. Maybe that's good. >> >> Only if we think there might be a reason to drop a packet with unknown >> ESP label deep in the stack would we want to further split the space >> to include that possibility. >> >> If there is no concensus behind the changes I've suggested here, then >> I support the document going forward. I would prefer that the >> suggested changes be seriously considered. >> >> Curtis >> ______________________________**_________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/**listinfo/mpls >> >> > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > ______________________________**_________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/**listinfo/mpls > --047d7b343f30a8a6a804e37338a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm not sure a transit LSR needs to enforce the rule, = does it? =A0If we rely on the LERs to enforce the rule then the worst that = will happen is that a broken packet may get accidentally hashed down the wr= ong component of a LAG or ECMP but will get discarded anyway when it arrive= s at the destination.

Are there router implementations that do an exhaustive integ= rity check on the rest of the labels in a label stack once it decides to sw= ap the outermost label? =A0I suspect most don't. =A0I could see a packe= t coming in with a broken label stack that's missing the BOS bit that c= ould result in erroneous parsing of an "ELI". =A0Or maybe it has = on-the-wire implicit NULL label somewhere in the stack. =A0We don't exp= ect transit LSRs to go hunting for these types of problems, right? =A0So wh= y should it hunt for problems with the disposition of the special purpose l= abels?

regards,
Pablo


On Wed, Aug 7, 2013 at 8:28 AM, = Loa Andersson <loa@pi.nu> wrote:
Folks, <chair hat off>

I'm trying to sort out the ELI / special purpose labels issue.

If I understand Kireeti correctly what he say is that if we
declare 15/ELI/EL an error (i.e. 15/ELI "reserved do not assign")= , then
anyone searching a label stack and fing the ELI needs to check whether
there is a label with the value 15 before it. This creates extra logic
that has to executed and written.

I think this is true. At least if you allow for that some
implementations that today are standard compatible, but just blindly
scans through the label stack to find the ELI and don't bother to
look at the other labels than the EL.

However, I think we need to look if there are other cases there what
is proposed by Kireeti leads to increasing complexity.

If we for example we know that the 16 lowest values are not in
the ranges allocated for extended label space that might simplify
the search of the labels in the extended space.

Any HW aspects on this?


<chair hat on>

/Loa




On 2013-07-26 19:43, Curtis Villamizar wrote:

In message <62CCD4C52ACDAD4= 481149BD5D8A72FD316D6FE01@CH1PRD0510MB355.namprd05.prod.outlo= ok.com>
Ross Callon writes:

Reminder, please send responses to the MPLS WG email list.

Thanks, Ross

From: Ross Callon [mailto:rcallon@juniper.net]
Sent: Tuesday, July 16, 2013 1:00 PM
To: mpls@ietf.org; <= a href=3D"mailto:draft-ietf-mpls-special-purpose-labels@tools.ietf.org" tar= get=3D"_blank">draft-ietf-mpls-special-purpose-labels@tools.ietf.org=
Cc: mpls-ch= airs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN)
Subject: MPLS WG last call on draft-ietf-mpls-special-purpose-labels= -03

Working Group,

This is to start Working Group last call on
draft-ietf-mpls-special-purpose-labels-03

Please send your comments to the mpls working group mailing list
(mpls@ietf.org<ma= ilto:mpls@ietf.or= g>).

Please send both technical comments, and (if you are happy with the
document as is) also send indications of support.

There are no IPR claims against this draft. The co-authors have
earlier stated that they are not aware of any IPR applicable to this
draft.

If anyone else in the working group is aware of IPRs claims against
this draft, the time to disclose that is now.

Due to the upcoming IETF meeting in Berlin, this last call will be
extended by an extra week (which implies that the last call will be
ongoing during the IETF meeting). =A0This working group last call will
end on August 6, 2013.

Ross
for the wg co-chairs


Ross, authors,

I really don't see the value of using 7 as an extended special purpose<= br> label.

=A0 =A0 Values 0-6 and 8-15 of the extended special purpose label registry<= br> =A0 =A0 are set aside as reserved; these MUST NOT appear in the data plane.=
=A0 =A0 Label 7 (when received) retains its meaning as ELI whether a regula= r
=A0 =A0 or an extended special purpose label; this is to simplify the logic=
=A0 =A0 for transit LSRs looking for entropy labels. =A0However, an LSR wis= hing
=A0 =A0 to insert an entropy label SHOULD insert label 7 as a regular speci= al
=A0 =A0 purpose label, not as an extended special purpose label.

Why insert 15 ELI EL rather than ELI EL. =A0If only new LSR insert EL,
why not make the MUST not apply to use of 0-15 as extended special
purpose labels. =A0I suggest replacing with:

=A0 =A0 Values 0-15 of the extended special purpose label registry are set<= br> =A0 =A0 aside as reserved; these MUST NOT appear in the data plane.

This would also change table 1.

I would also drop bullet 3 from the list in IANA Considerations. =A0That bullet contains the text "Note: any new allocation from the Special Purpose MPLS Label Values registry MUST also say whether the same
value needs to be reserved in the Extended Special Purpose MPLS Label
Values registry."

BTW "extension label" has a acronym collision with entropy label,=
unless we abbreviate extension label XL. =A0ESP labels might also be a
good acronym Extended Special Purpose MPLS Label. =A0The acronym
collision with existing use of ESP might actually make sense,
particularly in regard to the experimental ESP range. =A0:-)

It might help to introduce the acronyms "XL" and "ESP label&= quot; or "ESPL"
in this document.

Right now the document does not say what an LSR should do if it
encounters an unknown (to it) ESP label. =A0This should require a
separate section entitled "Forwarding Packets with Unknown Extension Labels". =A0If this label is deep in the stack, the it seems that the<= br> best action would be to always ignore it.

In thinking about what an LSR should do, there are two possibilities
if the unknown ESP label hits the top of the stack. =A0One possibility
is drop the packet. =A0The other is pop the XL and ESP and process the
next label or BOS. =A0One way to accomplish that would be to reserve a
range for each of these two possibilities. =A0Tabel 1 becomes.

=A0 =A0 +---------------+-------------------------------------------= ---+
=A0 =A0 | Range =A0 =A0 =A0 =A0 | Allocation Policy =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 +---------------+-------------------------------------------= ---+
=A0 =A0 | 0 - 15 =A0 =A0 =A0 =A0| Reserved. =A0Not to be allocated. =A0MUST= NOT =A0 =A0|
=A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 | appear in the data plane. =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 | 16 - 127 =A0 =A0 =A0| Standards Action (drop packet if unknown) = =A0 =A0|
=A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 | 128 - 239 =A0 =A0 | Standards Action (pop XL and ESP if unknown) = |
=A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 | 240 - 247 =A0 =A0 | Experimental (drop packet if unknown) =A0 =A0= =A0 =A0|
=A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 | 248 - 255 =A0 =A0 | Experimental (pop XL and ESP if unknown) =A0 = =A0 |
=A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 | 256 - 1048575 | Reserved =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 +---------------+-------------------------------------------= ---+

The experimental ESP space could also be split in the same way. =A0The
experimental space is small. =A0Maybe that's good.

Only if we think there might be a reason to drop a packet with unknown
ESP label deep in the stack would we want to further split the space
to include that possibility.

If there is no concensus behind the changes I've suggested here, then I support the document going forward. =A0I would prefer that the
suggested changes be seriously considered.

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


--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: loa@mail01.huawei.com
Senior MPLS Expert =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Huawei Technologies (consultant) =A0 =A0 phone: +46 739 81 21 64

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

--047d7b343f30a8a6a804e37338a7-- From erosen@cisco.com Thu Aug 8 11:33:24 2013 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 C309111E81F8 for ; Thu, 8 Aug 2013 11:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSCIPER3Aw50 for ; Thu, 8 Aug 2013 11:33: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 B6DCC11E81EB for ; Thu, 8 Aug 2013 11:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1641; q=dns/txt; s=iport; t=1375986793; x=1377196393; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=pHrfh4SguC1yyKLU+GJEYKzbhxxuMmPV7IJtGyCwlj8=; b=LKIfk80bcIuGaG5aBRnogNCqZQRjgY61AKV3rFSl+bqxaixMnKgO8C9X 8uA7nL+ZsFpwQrG6oMZQM2bI626810It06qpyWPxyZAvBdDd06FwaeOT6 I/4HzG5pITb50paxTXC4i6idDeh7L9J8+wJ8YbK0M3HOjiJcOXYQ4mM9r g=; X-IronPort-AV: E=Sophos;i="4.89,840,1367971200"; d="scan'208";a="245191300" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 08 Aug 2013 18:33:13 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r78IXCpI022764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 18:33:13 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 r78IXBH4004947; Thu, 8 Aug 2013 14:33:11 -0400 From: Eric Rosen To: Pablo Frank In-reply-to: Your message of Thu, 08 Aug 2013 13:45:18 -0400. Date: Thu, 08 Aug 2013 14:33:10 -0400 Message-ID: <4946.1375986790@erosen-linux> Cc: "mpls@ietf.org" , Kireeti Kompella , Ross Callon , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 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, 08 Aug 2013 18:33:24 -0000 > I'm not sure a transit LSR needs to enforce the rule, does it? That's not the issue; the issue is whether the transit LSR, when it hashes on the entropy label, is following the entropy label hashing spec. > If we rely on the LERs to enforce the rule then the worst that will happen > is that a broken packet may get accidentally hashed down the wrong > component No, the worst that can happen is that is that the transit LSR is declared to be non-compliant with the specs, since the label on which it is hashing does not appear immediately after a valid ELI. The sort of bureaucrat who would make such a declaration will not be dissuaded by the argument that this violation of the specs is of no practical import. And one cannot simply assume that such bureaucrats will have no influence on purchasing or deployment decisions. So if we don't want the transit LSR to have to check that a 7 is not preceded by a 15, it is best to make 15/7 legal, and to give it the same meaning as a 7 that is not preceded by a 15. > I could see a packet coming in with a broken label stack that's missing > the BOS bit that could result in erroneous parsing of an "ELI" Not analogous. If the BOS bit is missing, the transit LSR will parse past the intended end of the stack, but that's what it is supposed to do per the specifications. > Or maybe it has on-the-wire implicit NULL label somewhere in the stack. Not analogous. The transit LSR will not take any action on the label value 3, so it can't be faulted. But it will act on the label value 7, which could give rise to the bureaucratic objection above. From martin.stiemerling@neclab.eu Thu Aug 8 12:57:32 2013 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 582F221F859A; Thu, 8 Aug 2013 12:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 FUyIOVAJQEWM; Thu, 8 Aug 2013 12:57:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A874421F9A34; Thu, 8 Aug 2013 12:57:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Martin Stiemerling" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130808195718.13984.49026.idtracker@ietfa.amsl.com> Date: Thu, 08 Aug 2013 12:57:18 -0700 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: [mpls] Martin Stiemerling's No Objection on charter-ietf-mpls-05-01: (with COMMENT) 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, 08 Aug 2013 19:57:32 -0000 Martin Stiemerling has entered the following ballot position for charter-ietf-mpls-05-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-mpls/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am Ok with the charter, but the headline in the tool says "Is this charter ready for external review? Is this charter ready for approval without external review?", interesting isn't it? Is it now w/ or w/o external review? From pabloisnot@gmail.com Fri Aug 9 06:42:49 2013 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 3404D21F949F for ; Fri, 9 Aug 2013 06:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7uo8HBajCMd for ; Fri, 9 Aug 2013 06:42:48 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6902921F9C33 for ; Fri, 9 Aug 2013 06:42:46 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id m1so3899764ves.41 for ; Fri, 09 Aug 2013 06:42:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bfup0AHwzj/NUFIqRaKM28tjD/MO3kLVkmOnNzFHo9c=; b=bTG8w8/qFDLYRj0kFatV1irIu6t/Y+XpmBO/E7v9rQyABu0dbOAQIJoSKqhacxwOBF YZeRp0KvBievGkfTkso0kDz/iWT02xwRs5518M7Ms1h4B8NyK4fsTyjjVYk1FiMVi7Nz 7vMB+7GN6cxgzadTfmHygjGnnRLPbfAsR5FTHZ9F/g+KztW19iRooHUOSjl0FfjFY/JT TvhTWRxayOOeHsbTIILlJDhRNED342kAYx6ty+/8CncPL6b4jThiTZV2lfVGzNPqRiaR hqgte8YlOJCCNqacGbdLGJP8FNZrN7Lih4bXRtCLJF8/J7H7w2zcnWaQ4lEHqu+QSOxQ RlcA== MIME-Version: 1.0 X-Received: by 10.52.179.225 with SMTP id dj1mr363815vdc.89.1376055765871; Fri, 09 Aug 2013 06:42:45 -0700 (PDT) Received: by 10.52.38.166 with HTTP; Fri, 9 Aug 2013 06:42:45 -0700 (PDT) In-Reply-To: <4946.1375986790@erosen-linux> References: <4946.1375986790@erosen-linux> Date: Fri, 9 Aug 2013 09:42:45 -0400 Message-ID: From: Pablo Frank To: "Eric Rosen (erosen)" Content-Type: multipart/alternative; boundary=bcaec5171ec91dc14c04e383f35d Cc: "mpls@ietf.org" , Kireeti Kompella , Ross Callon , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 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, 09 Aug 2013 13:42:49 -0000 --bcaec5171ec91dc14c04e383f35d Content-Type: text/plain; charset=ISO-8859-1 Okay, I can buy the argument that it's just an "insurance policy against bureaucrats". The text, as written, says that an implementation SHOULD use 7/ over 15/7/ which means we're at least _discouraging_ the use of 15/7/. That seems okay to me now. thanks, Pablo On Thu, Aug 8, 2013 at 2:33 PM, Eric Rosen wrote: > > I'm not sure a transit LSR needs to enforce the rule, does it? > > That's not the issue; the issue is whether the transit LSR, when it hashes > on the entropy label, is following the entropy label hashing spec. > > > If we rely on the LERs to enforce the rule then the worst that will > happen > > is that a broken packet may get accidentally hashed down the wrong > > component > > No, the worst that can happen is that is that the transit LSR is declared > to > be non-compliant with the specs, since the label on which it is hashing > does > not appear immediately after a valid ELI. > > The sort of bureaucrat who would make such a declaration will not be > dissuaded by the argument that this violation of the specs is of no > practical import. And one cannot simply assume that such bureaucrats will > have no influence on purchasing or deployment decisions. > > So if we don't want the transit LSR to have to check that a 7 is not > preceded by a 15, it is best to make 15/7 legal, and to give it the same > meaning as a 7 that is not preceded by a 15. > > > I could see a packet coming in with a broken label stack that's missing > > the BOS bit that could result in erroneous parsing of an "ELI" > > Not analogous. If the BOS bit is missing, the transit LSR will parse past > the intended end of the stack, but that's what it is supposed to do per the > specifications. > > > Or maybe it has on-the-wire implicit NULL label somewhere in the stack. > > Not analogous. The transit LSR will not take any action on the label value > 3, so it can't be faulted. But it will act on the label value 7, which > could give rise to the bureaucratic objection above. > > --bcaec5171ec91dc14c04e383f35d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Okay, I can buy the argument that it's just an "i= nsurance policy against bureaucrats". =A0The text, as written, says th= at an implementation SHOULD use 7/<entropy> over 15/7/<entropy>= which means we're at least _discouraging_ the use of 15/7/<entropy&= gt;. =A0That seems okay to me now.

thanks,
Pablo


On Thu, Aug 8, 2013 at 2:33 PM, Eric R= osen <erosen@cisco.com> wrote:
> I'm not sure a tr= ansit LSR needs to enforce the rule, does it?

That's not the issue; the issue is whether the transit LSR, when = it hashes
on the entropy label, is following the entropy label hashing spec.

> If we rely on the LERs to enforce the rule then the worst that will ha= ppen
> is that a broken packet may get accidentally hashed down the wrong
> component

No, the worst that can happen is that is that the transit LSR is decl= ared to
be non-compliant with the specs, since the label on which it is hashing doe= s
not appear immediately after a valid ELI.

The sort of bureaucrat who would make such a declaration will not be
dissuaded by the argument that this violation of the specs is of no
practical import. =A0And one cannot simply assume that such bureaucrats wil= l
have no influence on purchasing or deployment decisions.

So if we don't want the transit LSR to have to check that a 7 is not preceded by a 15, it is best to make 15/7 legal, and to give it the same meaning as a 7 that is not preceded by a 15.

> I could see a packet coming in with a broken label stack that's mi= ssing
> the BOS bit that could result in erroneous parsing of an "ELI&quo= t;

Not analogous. =A0If the BOS bit is missing, the transit LSR will par= se past
the intended end of the stack, but that's what it is supposed to do per= the
specifications.

> Or maybe it has on-the-wire implicit NULL label somewhere in the stack= .

Not analogous. =A0The transit LSR will not take any action on the lab= el value
3, so it can't be faulted. =A0But it will act on the label value 7, whi= ch
could give rise to the bureaucratic objection above.


--bcaec5171ec91dc14c04e383f35d-- From rcallon@juniper.net Fri Aug 9 13:33:40 2013 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 8F67A21F9D3B for ; Fri, 9 Aug 2013 13:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.01 X-Spam-Level: X-Spam-Status: No, score=-101.01 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, 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 DnuHF9BR1qYe for ; Fri, 9 Aug 2013 13:33:34 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 579A711E815E for ; Fri, 9 Aug 2013 13:28:33 -0700 (PDT) Received: from mail92-am1-R.bigfish.com (10.3.201.233) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Aug 2013 20:28:30 +0000 Received: from mail92-am1 (localhost [127.0.0.1]) by mail92-am1-R.bigfish.com (Postfix) with ESMTP id 37ABF260052; Fri, 9 Aug 2013 20:28:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: PS-20(zz9371Ic85fh4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz1d7338h1de098h1033IL17326ah18c673h1c8fb4h1de096h8275bh8275dh1de097hz2fh2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h9a9j1155h) Received-SPF: pass (mail92-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(164054003)(199002)(189002)(69226001)(80976001)(76576001)(66066001)(56816003)(50986001)(19580395003)(4396001)(83322001)(80022001)(79102001)(19580385001)(77096001)(46102001)(19580405001)(15202345003)(74706001)(53806001)(76482001)(65816001)(47976001)(18717965001)(74316001)(47736001)(49866001)(33646001)(77982001)(56776001)(16406001)(63696002)(54356001)(59766001)(74876001)(74366001)(16236675002)(31966008)(81542001)(83072001)(51856001)(74502001)(76796001)(19300405004)(76786001)(1941001)(81342001)(47446002)(54316002)(74662001)(81686001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB072; H:BLUPR05MB070.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail92-am1 (localhost.localdomain [127.0.0.1]) by mail92-am1 (MessageSwitch) id 1376080107869926_14060; Fri, 9 Aug 2013 20:28:27 +0000 (UTC) Received: from AM1EHSMHS021.bigfish.com (unknown [10.3.201.233]) by mail92-am1.bigfish.com (Postfix) with ESMTP id CF3BE380046; Fri, 9 Aug 2013 20:28:27 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS021.bigfish.com (10.3.207.150) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 9 Aug 2013 20:28:27 +0000 Received: from BLUPR05MB072.namprd05.prod.outlook.com (10.255.214.27) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.341.1; Fri, 9 Aug 2013 20:28:26 +0000 Received: from BLUPR05MB070.namprd05.prod.outlook.com (10.255.214.15) by BLUPR05MB072.namprd05.prod.outlook.com (10.255.214.27) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 9 Aug 2013 20:28:24 +0000 Received: from BLUPR05MB070.namprd05.prod.outlook.com ([169.254.15.164]) by BLUPR05MB070.namprd05.prod.outlook.com ([169.254.15.164]) with mapi id 15.00.0731.000; Fri, 9 Aug 2013 20:28:24 +0000 From: Ross Callon To: Ross Callon , "mpls@ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Thread-Topic: MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 Thread-Index: AQHOgkXk/5e12m2TNkeFcdzsBEiRqZmNeXGQ Date: Fri, 9 Aug 2013 20:28:24 +0000 Message-ID: <18dba3497ae64dd1b884767acc961696@BLUPR05MB070.namprd05.prod.outlook.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C76D83@CH1PRD0510MB355.namprd05.prod.outlook.com> <62CCD4C52ACDAD4481149BD5D8A72FD316D6D7D6@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316D6D7D6@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0933E9FD8D Content-Type: multipart/alternative; boundary="_000_18dba3497ae64dd1b884767acc961696BLUPR05MB070namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%ALCATEL-LUCENT.COM$RO%1$TLS%0$FQDN%$TlsDn% Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 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, 09 Aug 2013 20:33:40 -0000 --_000_18dba3497ae64dd1b884767acc961696BLUPR05MB070namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This last call should have ended already. However, there have been relative= ly few comments, most of which have been focused on a specific technical is= sue. While it appears that this issue might be close to resolution, we have= relatively little indication of support (and so far no indication of oppos= ition except for comments on technical details to be resolved). As such we are extending the last call for one week, until one week from to= day. Please take a look at the draft and let us know whether the document i= s ready for publication (modulo resolution of the comments already received= ). This extended last call will end one week from today, on Friday August 1= 6th. Thanks, Ross (as WG chair) From: Ross Callon [mailto:rcallon@juniper.net] Sent: Tuesday, July 16, 2013 1:00 PM To: mpls@ietf.org; draft-ietf-mpls-special-purpose-labels@tools.ietf.org Cc: mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) Subject: MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 Working Group, This is to start Working Group last call on draft-ietf-mpls-special-purpos= e-labels-03 Please send your comments to the mpls working group mailing list (mpls@ietf= .org). Please send both technical comments, and (if you are happy with the documen= t as is) also send indications of support. There are no IPR claims against this draft. The co-authors have earlier sta= ted that they are not aware of any IPR applicable to this draft. If anyone else in the working group is aware of IPRs claims against this draft, the time to disclose that is now. Due to the upcoming IETF meeting in Berlin, this last call will be extended= by an extra week (which implies that the last call will be ongoing during the IETF meeting).= This working group last call will end on August 6, 2013. Ross for the wg co-chairs --_000_18dba3497ae64dd1b884767acc961696BLUPR05MB070namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This last call should hav= e ended already. However, there have been relatively few comments, most of = which have been focused on a specific technical issue. While it appears that this issue might be close to resolution, we have relativel= y little indication of support (and so far no indication of opposition exce= pt for comments on technical details to be resolved).

 <= /p>

As such we are extending = the last call for one week, until one week from today. Please take a look a= t the draft and let us know whether the document is ready for publication (modulo resolution of the comments already received). This= extended last call will end one week from today, on Friday August 16t= h.

 <= /p>

Thanks, Ross

(as WG chair)<= /span>

 <= /p>

From: Ross Cal= lon [mailto:rcallon@juniper.net]
Sent: Tuesday, July 16, 2013 1:00 PM
To: mpls@ietf.org; draft-ietf-mpls-special-purpose-labels@tools.ietf= .org
Cc: mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN)
Subject: MPLS WG last call on draft-ietf-mpls-special-purpose-labels= -03

 

Working Group,

 

This = is to start Working Group last call on  draft-ietf-mpls-special-purpose-labels-03

 

Please send your comments to the mpls w= orking group mailing list (mpls@ietf.org).

 

Please send both technical comments, an= d (if you are happy with the document as is)

also send indications of support.

 

There are no IPR claims against this dr= aft. The co-authors have earlier stated that they

are not aware of any IPR applicable to this draft.

 

If anyone else in the working group is aware of IPRs claims against

this draft, the time to disclose that i= s now.

 

Due to the upcoming IETF meeting in Ber= lin, this last call will be extended by an extra week

(which implies that the last call will = be ongoing during the IETF meeting). This working group

last call will end on August 6, 2013.

 

Ross

for the wg co-chairs<= /p>

 <= /p>

--_000_18dba3497ae64dd1b884767acc961696BLUPR05MB070namprd05pro_-- From huubatwork@gmail.com Fri Aug 9 13:57:37 2013 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 6E04621F847C for ; Fri, 9 Aug 2013 13:57: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=[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 QChdJ-hRT-vi for ; Fri, 9 Aug 2013 13:57:36 -0700 (PDT) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id BCEFF11E8123 for ; Fri, 9 Aug 2013 13:49:35 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id c41so2379413eek.11 for ; Fri, 09 Aug 2013 13:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=ezfe4lrxcc3yQHUkCtATASw1fLahKzB+eZugq19XaJ0=; b=BxrgPE6Q8pWzGhs5wF9Dh0qblezc7sAZwJpd33dLwZNASoBru5duvaprxloXjtxies lSkJpLskZuxf1rLlSNIk8zE75RefEkVex/0FRsUCBv6atoPqiO0+j2PJO8VZMTlQfB2M EQFg8Iy59HiaCjNANQ2vV98kw1pngNyzDanzXCPUlpPO+SF4ApCDq6aEEuAXFlHMerZZ kBkSkNOMoZCDJUz2BCnWJwzwAnnKDGhCXc73EoUbdJtPj15Qze2acDkwgd9bQ2utARAh N2EvRTCHTcTMEiLOInJSFGVcHD/1dcftXcnA52JSfgx+ObE5e5PSTSnLe+s107lv45FN Xr8A== X-Received: by 10.14.183.2 with SMTP id p2mr14911409eem.44.1376081374816; Fri, 09 Aug 2013 13:49:34 -0700 (PDT) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id a6sm20073816eei.10.2013.08.09.13.49.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Aug 2013 13:49:34 -0700 (PDT) Message-ID: <520555DE.6090304@gmail.com> Date: Fri, 09 Aug 2013 22:49:34 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ross Callon References: <62CCD4C52ACDAD4481149BD5D8A72FD316D78B3E@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316D78B3E@CH1PRD0510MB355.namprd05.prod.outlook.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org" Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-tp-rosetta-stone-11.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: Fri, 09 Aug 2013 20:57:37 -0000 As the editor of this draft I support publication. Only one comment: I would like to acknowledge the contributions by Tom Petch to improve the quality of this draft. Cheers, Huub. ======= > Working Group, > > This is to start Working Group last call > ondraft-ietf-mpls-tp-rosetta-stone-11.txt > > Please send your comments to the mpls working groupmailing list > (mpls@ietf.org ). > > Please send both technical comments, and (if you are happywith the > document as is) > > also send indications of support. > > There are no IPR claims against this draft.The co-authors have stated > that they are not > > awareof any IPR applicable to this draft.If anyone else in the working > group is aware of > > IPRs claims againstthis draft, the time to disclose that is now. > > Due to the upcoming IETF meeting in Berlin, this last call will be > extended by an extra week > > (which implies that the last call will be ongoing during the IETF > meeting). This working group > > last call will end on August 14, 2013. > > Ross > > for the wg co-chairs > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- ***************************************************************** 请记ä½ï¼Œä½ æ˜¯ç‹¬ä¸€æ— äºŒçš„，就åƒå…¶ä»–æ¯ä¸€ä¸ªäººä¸€æ · From ryoo@etri.re.kr Fri Aug 9 16:47:22 2013 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 2BA9921F9A6A for ; Fri, 9 Aug 2013 16:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5a8si8JOr52R for ; Fri, 9 Aug 2013 16:47:15 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF7521F9D50 for ; Fri, 9 Aug 2013 16:41:14 -0700 (PDT) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 10 Aug 2013 08:41:08 +0900 Received: from SMTP2.etri.info ([169.254.2.99]) by SMTP4.etri.info ([129.254.28.74]) with mapi id 14.01.0355.002; Sat, 10 Aug 2013 08:41:08 +0900 From: "Ryoo, Jeong-dong" To: Ross Callon Thread-Topic: [mpls] MPLS WG last call on draft-ietf-mpls-tp-rosetta-stone-11.txt Thread-Index: AQHOlUMd+pv7fgl3kU+Ful5ouQvWAZmNhrN1 Date: Fri, 9 Aug 2013 23:41:07 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A28154B55@SMTP2.etri.info> References: <62CCD4C52ACDAD4481149BD5D8A72FD316D78B3E@CH1PRD0510MB355.namprd05.prod.outlook.com>, <520555DE.6090304@gmail.com> In-Reply-To: <520555DE.6090304@gmail.com> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.45] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28154B55SMTP2etriinfo_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org" Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-tp-rosetta-stone-11.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, 09 Aug 2013 23:47:22 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28154B55SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgc3VwcG9ydCB0aGUgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudCBhcyBpdCBj YW4gYmUgc2VydmVkIGFzIGdvb2QgZm91bmRhdGlvbiBmb3IgdW5kZXJzdGFuZGluZyB0aGUgZG9j dW1lbnRzIHdyaXR0ZW4gYnkgdGhlIG90aGVyIFNETy4NCg0KQmVzdCByZWdhcmRzLA0KDQpKZW9u Zy1kb25nDQoNCg0KDQo9PT09PT09DQo+IFdvcmtpbmcgR3JvdXAsDQo+DQo+IFRoaXMgaXMgdG8g c3RhcnQgV29ya2luZyBHcm91cCBsYXN0IGNhbGwNCj4gb25kcmFmdC1pZXRmLW1wbHMtdHAtcm9z ZXR0YS1zdG9uZS0xMS50eHQNCj4NCj4gUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUg bXBscyB3b3JraW5nIGdyb3VwbWFpbGluZyBsaXN0DQo+IChtcGxzQGlldGYub3JnICkuDQo+DQo+ IFBsZWFzZSBzZW5kIGJvdGggdGVjaG5pY2FsIGNvbW1lbnRzLCBhbmQgKGlmIHlvdSBhcmUgaGFw cHl3aXRoIHRoZQ0KPiBkb2N1bWVudCBhcyBpcykNCj4NCj4gYWxzbyBzZW5kIGluZGljYXRpb25z IG9mIHN1cHBvcnQuDQo+DQo+IFRoZXJlIGFyZSBubyBJUFIgY2xhaW1zIGFnYWluc3QgdGhpcyBk cmFmdC5UaGUgY28tYXV0aG9ycyBoYXZlIHN0YXRlZA0KPiB0aGF0IHRoZXkgYXJlIG5vdA0KPg0K PiBhd2FyZW9mIGFueSBJUFIgYXBwbGljYWJsZSB0byB0aGlzIGRyYWZ0LklmIGFueW9uZSBlbHNl IGluIHRoZSB3b3JraW5nDQo+IGdyb3VwIGlzIGF3YXJlIG9mDQo+DQo+IElQUnMgY2xhaW1zIGFn YWluc3R0aGlzIGRyYWZ0LCB0aGUgdGltZSB0byBkaXNjbG9zZSB0aGF0IGlzIG5vdy4NCj4NCj4g RHVlIHRvIHRoZSB1cGNvbWluZyBJRVRGIG1lZXRpbmcgaW4gQmVybGluLCB0aGlzIGxhc3QgY2Fs bCB3aWxsIGJlDQo+IGV4dGVuZGVkIGJ5IGFuIGV4dHJhIHdlZWsNCj4NCj4gKHdoaWNoIGltcGxp ZXMgdGhhdCB0aGUgbGFzdCBjYWxsIHdpbGwgYmUgb25nb2luZyBkdXJpbmcgdGhlIElFVEYNCj4g bWVldGluZykuIFRoaXMgd29ya2luZyBncm91cA0KPg0KPiBsYXN0IGNhbGwgd2lsbCBlbmQgb24g QXVndXN0IDE0LCAyMDEzLg0KPg0KPiBSb3NzDQo+DQo+IGZvciB0aGUgd2cgY28tY2hhaXJzDQo+ DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IG1wbHMgbWFpbGluZyBsaXN0DQo+IG1wbHNAaWV0Zi5vcmcNCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28154B55SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5IaSw8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUt SEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0 Ij5JIHN1cHBvcnQgdGhlIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYXMgaXQmbmJzcDtj YW4gYmUgc2VydmVkIGFzJm5ic3A7Z29vZCBmb3VuZGF0aW9uJm5ic3A7Zm9yIHVuZGVyc3RhbmRp bmcgdGhlIGRvY3VtZW50cyZuYnNwO3dyaXR0ZW4gYnkmbmJzcDt0aGUgb3RoZXImbmJzcDtTRE8u PGJyPg0KPGJyPg0KPGRpdj5CZXN0IHJlZ2FyZHMsPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0K PGRpdj5KZW9uZy1kb25nPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxkaXY+PGJyPg0KPT09PT09PTxicj4NCiZndDsgV29ya2luZyBHcm91cCw8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBUaGlzIGlzIHRvIHN0YXJ0IFdvcmtpbmcgR3JvdXAgbGFzdCBjYWxsPGJyPg0K Jmd0OyBvbmRyYWZ0LWlldGYtbXBscy10cC1yb3NldHRhLXN0b25lLTExLnR4dDxicj4NCiZndDs8 YnI+DQomZ3Q7IFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIG1wbHMgd29ya2luZyBn cm91cG1haWxpbmcgbGlzdDxicj4NCiZndDsgKG1wbHNAaWV0Zi5vcmcNCjw/eG1sOm5hbWVzcGFj ZSBwcmVmaXggPSBtYWlsdG8gLz4NCiA8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+KS48YnI+DQomZ3Q7 PGJyPg0KJmd0OyBQbGVhc2Ugc2VuZCBib3RoIHRlY2huaWNhbCBjb21tZW50cywgYW5kIChpZiB5 b3UgYXJlIGhhcHB5d2l0aCB0aGU8YnI+DQomZ3Q7IGRvY3VtZW50IGFzIGlzKTxicj4NCiZndDs8 YnI+DQomZ3Q7IGFsc28gc2VuZCBpbmRpY2F0aW9ucyBvZiBzdXBwb3J0Ljxicj4NCiZndDs8YnI+ DQomZ3Q7IFRoZXJlIGFyZSBubyBJUFIgY2xhaW1zIGFnYWluc3QgdGhpcyBkcmFmdC5UaGUgY28t YXV0aG9ycyBoYXZlIHN0YXRlZDxicj4NCiZndDsgdGhhdCB0aGV5IGFyZSBub3Q8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBhd2FyZW9mIGFueSBJUFIgYXBwbGljYWJsZSB0byB0aGlzIGRyYWZ0LklmIGFu eW9uZSBlbHNlIGluIHRoZSB3b3JraW5nPGJyPg0KJmd0OyBncm91cCBpcyBhd2FyZSBvZjxicj4N CiZndDs8YnI+DQomZ3Q7IElQUnMgY2xhaW1zIGFnYWluc3R0aGlzIGRyYWZ0LCB0aGUgdGltZSB0 byBkaXNjbG9zZSB0aGF0IGlzIG5vdy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBEdWUgdG8gdGhlIHVw Y29taW5nIElFVEYgbWVldGluZyBpbiBCZXJsaW4sIHRoaXMgbGFzdCBjYWxsIHdpbGwgYmU8YnI+ DQomZ3Q7IGV4dGVuZGVkIGJ5IGFuIGV4dHJhIHdlZWs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAod2hp Y2ggaW1wbGllcyB0aGF0IHRoZSBsYXN0IGNhbGwgd2lsbCBiZSBvbmdvaW5nIGR1cmluZyB0aGUg SUVURjxicj4NCiZndDsgbWVldGluZykuIFRoaXMgd29ya2luZyBncm91cDxicj4NCiZndDs8YnI+ DQomZ3Q7IGxhc3QgY2FsbCB3aWxsIGVuZCBvbiBBdWd1c3QgMTQsIDIwMTMuPGJyPg0KJmd0Ozxi cj4NCiZndDsgUm9zczxicj4NCiZndDs8YnI+DQomZ3Q7IGZvciB0aGUgd2cgY28tY2hhaXJzPGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgbXBscyBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7IG1wbHNAaWV0Zi5vcmc8YnI+DQo8L21haWx0bzptcGxzQGlldGYub3JnPjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28154B55SMTP2etriinfo_-- From kireeti.kompella@gmail.com Sat Aug 10 08:29:10 2013 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 D516A21F995E for ; Sat, 10 Aug 2013 08:29:10 -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 XPGbEjOa52kH for ; Sat, 10 Aug 2013 08:29:10 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id AC28421F9E7C for ; Sat, 10 Aug 2013 08:23:00 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id l18so346644qak.18 for ; Sat, 10 Aug 2013 08:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QTsOH/uSk325oc5YaksfhmMhK4aJZoXcBvsJ1+Z+FUw=; b=esn7vwa1I+XsdGu7tV5pS1XohhtCO1KAXVqa5RqoYeBHusUCwxm7hJe36MBO0Qs6ID uPEi+H3gSitSUsPYmEZLbrPvetK//aX6Y0vUSvGnP0KSYbzvCm+RKcPWnD1tklxG0BLL By6UF/RDAjyyCtpd+csZjfMdhIZ5CfAXGSgYqgL7kN0eVHVukkSOd/7bSvoAFG+jAj0v qPOh0hAXqENBNDKUpLV2VGTShPqlQW+hZykX8DZpGyF+se+sTQXc6eqjQ3gxlNQrR5La rJm3wn39/eIDv9VQvEv/nuAuj1A0gLRi/StzJocRwIIUTm0dWr1mTvaVb73rOF0M36ts o1MQ== X-Received: by 10.49.59.134 with SMTP id z6mr6029700qeq.49.1376148180166; Sat, 10 Aug 2013 08:23:00 -0700 (PDT) Received: from [172.28.131.194] (westford-nat.juniper.net. [66.129.232.2]) by mx.google.com with ESMTPSA id u8sm25584723qey.5.2013.08.10.08.22.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 10 Aug 2013 08:22:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Kireeti Kompella In-Reply-To: <201307261743.r6QHhwjG065662@gateway1.orleans.occnc.com> Date: Sat, 10 Aug 2013 08:22:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <07A84E3A-E552-4D0F-BBB0-7E87EE25E3C7@gmail.com> References: <201307261743.r6QHhwjG065662@gateway1.orleans.occnc.com> To: curtis@ipv6.occnc.com X-Mailer: Apple Mail (2.1508) Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 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, 10 Aug 2013 15:29:11 -0000 On Jul 26, 2013, at 10:43 , Curtis Villamizar = wrote: > Why insert 15 ELI EL rather than ELI EL. =20 Don't. Ever :) The only purpose of keeping XL ELI in the table is to simplify transit = LSR behavior. See Eric's email (Aug 8, 11:33 PDT) or Loa's email (Aug = 7, 5:28 PDT). > I would also drop bullet 3 from the list in IANA Considerations. That > bullet contains the text "Note: any new allocation from the Special > Purpose MPLS Label Values registry MUST also say whether the same > value needs to be reserved in the Extended Special Purpose MPLS Label > Values registry." Good catch! > BTW "extension label" has a acronym collision with entropy label, > unless we abbreviate extension label XL. ESP labels might also be a > good acronym Extended Special Purpose MPLS Label. The acronym > collision with existing use of ESP might actually make sense, > particularly in regard to the experimental ESP range. :-) >=20 > It might help to introduce the acronyms "XL" and "ESP label" or "ESPL" > in this document. Will add text. > Right now the document does not say what an LSR should do if it > encounters an unknown (to it) ESP label. This should require a > separate section entitled "Forwarding Packets with Unknown Extension > Labels". If this label is deep in the stack, the it seems that the > best action would be to always ignore it. >=20 > In thinking about what an LSR should do, there are two possibilities > if the unknown ESP label hits the top of the stack. One possibility > is drop the packet. The other is pop the XL and ESP and process the > next label or BOS. One way to accomplish that would be to reserve a > range for each of these two possibilities. Tabel 1 becomes. The behavior today is to=20 a) ignore any label not at top of stack, except for load balancing = purposes; and b) to drop a packet that has a reserved label unknown to the router. So, I agree with your suggestion to add a section on what to do with an = unknown ESPL, but I would keep it simple and say drop the packet :) If people think splitting the space the way you suggest is a good idea, = I'll add it. If not, we can always add another registry later. > If there is no concensus behind the changes I've suggested here, then > I support the document going forward. I would prefer that the > suggested changes be seriously considered. I think some are good, and will add them. Thanks for the comments! Kireeti. > Curtis > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From kireeti@juniper.net Sat Aug 10 08:37:54 2013 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 378B921F9D15 for ; Sat, 10 Aug 2013 08:37:52 -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 RbiGa2l1cE2t for ; Sat, 10 Aug 2013 08:37:46 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 09B4C21F9DFC for ; Sat, 10 Aug 2013 08:30:41 -0700 (PDT) Received: from mail230-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.22; Sat, 10 Aug 2013 15:30:41 +0000 Received: from mail230-va3 (localhost [127.0.0.1]) by mail230-va3-R.bigfish.com (Postfix) with ESMTP id 15CE51C0292; Sat, 10 Aug 2013 15:30:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -2 X-BigFish: PS-2(zz98dIda00h4015Idc73hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h8275bh1de097hz2fh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1155h) Received-SPF: pass (mail230-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kireeti@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(164054003)(24454002)(199002)(189002)(81542001)(4396001)(33656001)(69226001)(80976001)(83322001)(66066001)(50986001)(19580395003)(79102001)(80022001)(77096001)(56816003)(46102001)(19580405001)(74706001)(76482001)(65816001)(47976001)(74366001)(56776001)(36756003)(49866001)(77982001)(16406001)(63696002)(54356001)(53806001)(59766001)(47736001)(74502001)(51856001)(76796001)(76786001)(31966008)(83072001)(81342001)(74662001)(47446002)(74876001)(54316002)(558084003)(81686001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB072; H:BLUPR05MB120.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail230-va3 (localhost.localdomain [127.0.0.1]) by mail230-va3 (MessageSwitch) id 1376148638700745_17309; Sat, 10 Aug 2013 15:30:38 +0000 (UTC) Received: from VA3EHSMHS041.bigfish.com (unknown [10.7.14.238]) by mail230-va3.bigfish.com (Postfix) with ESMTP id A6EE5BA01D4; Sat, 10 Aug 2013 15:30:38 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS041.bigfish.com (10.7.99.51) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 10 Aug 2013 15:30:37 +0000 Received: from BLUPR05MB072.namprd05.prod.outlook.com (10.255.214.27) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.341.1; Sat, 10 Aug 2013 15:30:36 +0000 Received: from BLUPR05MB120.namprd05.prod.outlook.com (10.255.214.28) by BLUPR05MB072.namprd05.prod.outlook.com (10.255.214.27) with Microsoft SMTP Server (TLS) id 15.0.731.16; Sat, 10 Aug 2013 15:30:35 +0000 Received: from BLUPR05MB120.namprd05.prod.outlook.com ([169.254.12.141]) by BLUPR05MB120.namprd05.prod.outlook.com ([169.254.12.141]) with mapi id 15.00.0731.000; Sat, 10 Aug 2013 15:30:35 +0000 From: Kireeti Kompella To: "erosen@cisco.com" Thread-Topic: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 Thread-Index: AQHOlGW7jiDhBkASqkm9r7wNAfuoIJmOlE+A Date: Sat, 10 Aug 2013 15:30:35 +0000 Message-ID: <09764FF9-DC6E-47DB-A03C-E201F13B7DDC@juniper.net> References: <4946.1375986790@erosen-linux> In-Reply-To: <4946.1375986790@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 09347618C4 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls@ietf.org" , Ross Callon , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 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, 10 Aug 2013 15:37:54 -0000 On Aug 8, 2013, at 11:33 , Eric Rosen wrote: > So if we don't want the transit LSR to have to check that a 7 is not > preceded by a 15, it is best to make 15/7 legal, and to give it the same > meaning as a 7 that is not preceded by a 15. Exactly! Thanks, Eric. Kireeti From kireeti@juniper.net Sat Aug 10 08:40:08 2013 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 A329C11E81AB for ; Sat, 10 Aug 2013 08:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 VnnnIB+mvHEX for ; Sat, 10 Aug 2013 08:40:02 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id BB2F421F9D87 for ; Sat, 10 Aug 2013 08:32:37 -0700 (PDT) Received: from mail8-db8-R.bigfish.com (10.174.8.239) by DB8EHSOBE042.bigfish.com (10.174.4.105) with Microsoft SMTP Server id 14.1.225.22; Sat, 10 Aug 2013 15:32:37 +0000 Received: from mail8-db8 (localhost [127.0.0.1]) by mail8-db8-R.bigfish.com (Postfix) with ESMTP id E453E1740239; Sat, 10 Aug 2013 15:32:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -2 X-BigFish: PS-2(zz98dI1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1de097hz2fh2a8h668h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1155h) Received-SPF: pass (mail8-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kireeti@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(51704005)(189002)(199002)(74366001)(79102001)(59766001)(77982001)(74706001)(81342001)(49866001)(50986001)(47976001)(76482001)(47736001)(74876001)(4396001)(54356001)(74662001)(63696002)(31966008)(56816003)(54316002)(69226001)(46102001)(80976001)(76796001)(77096001)(74502001)(56776001)(16406001)(81542001)(76786001)(36756003)(47446002)(33656001)(83072001)(65816001)(51856001)(19580395003)(66066001)(53806001)(19580405001)(83322001)(80022001)(81686001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB071; H:BLUPR05MB120.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail8-db8 (localhost.localdomain [127.0.0.1]) by mail8-db8 (MessageSwitch) id 1376148754565458_10128; Sat, 10 Aug 2013 15:32:34 +0000 (UTC) Received: from DB8EHSMHS015.bigfish.com (unknown [10.174.8.235]) by mail8-db8.bigfish.com (Postfix) with ESMTP id 7B568DC0046; Sat, 10 Aug 2013 15:32:34 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS015.bigfish.com (10.174.4.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 10 Aug 2013 15:32:33 +0000 Received: from BLUPR05MB071.namprd05.prod.outlook.com (10.255.214.24) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.341.1; Sat, 10 Aug 2013 15:32:31 +0000 Received: from BLUPR05MB120.namprd05.prod.outlook.com (10.255.214.28) by BLUPR05MB071.namprd05.prod.outlook.com (10.255.214.24) with Microsoft SMTP Server (TLS) id 15.0.731.16; Sat, 10 Aug 2013 15:32:30 +0000 Received: from BLUPR05MB120.namprd05.prod.outlook.com ([169.254.12.141]) by BLUPR05MB120.namprd05.prod.outlook.com ([169.254.12.141]) with mapi id 15.00.0731.000; Sat, 10 Aug 2013 15:32:30 +0000 From: Kireeti Kompella To: Loa Andersson Thread-Topic: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 Thread-Index: AQHOk2mmjiDhBkASqkm9r7wNAfuoIJmOls+A Date: Sat, 10 Aug 2013 15:32:29 +0000 Message-ID: <600E2353-6F95-4470-A8DB-2B21318A554D@juniper.net> References: <201307261743.r6QHhwjG065662@gateway1.orleans.occnc.com> <52023D71.3020708@pi.nu> In-Reply-To: <52023D71.3020708@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 09347618C4 Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 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, 10 Aug 2013 15:40:08 -0000 Hi Loa, On Aug 7, 2013, at 05:28 , Loa Andersson wrote: > Folks, >=20 > I'm trying to sort out the ELI / special purpose labels issue. >=20 > If I understand Kireeti correctly what he say is that if we > declare 15/ELI/EL an error (i.e. 15/ELI "reserved do not assign"), then > anyone searching a label stack and fing the ELI needs to check whether > there is a label with the value 15 before it. This creates extra logic > that has to executed and written. Yes. > However, I think we need to look if there are other cases there what > is proposed by Kireeti leads to increasing complexity. >=20 > If we for example we know that the 16 lowest values are not in > the ranges allocated for extended label space that might simplify > the search of the labels in the extended space. >=20 > Any HW aspects on this? I don't believe so, and unless someone speaks up, I'll assume not :) Kireeti. > >=20 > /Loa From kireeti.kompella@gmail.com Sat Aug 10 08:41:52 2013 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 6D69821F9EF2 for ; Sat, 10 Aug 2013 08:41:52 -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 vgR5ozhbgW1H for ; Sat, 10 Aug 2013 08:41:52 -0700 (PDT) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAAD11E8191 for ; Sat, 10 Aug 2013 08:34:24 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 6so2917567qeb.17 for ; Sat, 10 Aug 2013 08:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=A2cAylhYbb2ZHKfjCqbURzIYd8aXB6GrfRIXbuleV1I=; b=Co7BqZnw6bVNb/2hQ7UMMxD79W2Qqa5y7NbeLmWioZ0pwHkOgmHp4LoB5qhg3dov1h Gaq8EO63fGUnKXHe4GzTEq/VmezNF7DfZUoUngld+cHsmStFjZLx+Vz6yz1hpd+Bf4WW 6Q1RQg6b2lKmBbu4LxYMqZeGLTzT9naD+DdYXA37IbPIWSyde5Uu/c6Vv0mfcliGxZvw WBVAP7lqrT9tZ319zCZ3QTougwiD9k30evwQBpC1P455wi8ulSrHcp4nub90OTDws85g 6QRFE8/JeYc7KuQRYxi3bdY1+1NM1FrRKZFXNPxeRBwdfOJZqvTucvfFAMNspah8HQsm 63XA== X-Received: by 10.224.161.76 with SMTP id q12mr16700527qax.3.1376148863864; Sat, 10 Aug 2013 08:34:23 -0700 (PDT) Received: from [172.28.131.194] (westford-nat.juniper.net. [66.129.232.2]) by mx.google.com with ESMTPSA id j11sm28173178qaa.7.2013.08.10.08.34.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 10 Aug 2013 08:34:21 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Kireeti Kompella In-Reply-To: Date: Sat, 10 Aug 2013 08:34:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6A644729-229B-4DE7-A8F0-B5ED2689F110@gmail.com> References: <29F9570C-4598-41D2-8E2B-473233C9D185@gmail.com> To: Alia Atlas X-Mailer: Apple Mail (2.1508) Cc: mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-special-purpose-labels-01 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, 10 Aug 2013 15:41:52 -0000 On Jul 9, 2013, at 05:29 , Alia Atlas wrote: > I think it makes sense and helps clarify the reasoning. It would be = useful to have a sentence or two in the draft changing: >=20 > "Label 7 (when received) retains its meaning as ELI whether a regular > or an extended special purpose label; this is to simplify the logic > for transit LSRs looking for entropy labels." >=20 > to >=20 > "Label 7 (when received) retains its meaning as ELI whether a regular = or an extended special purpose label; this simplifies a transit LSR's = task of looking for entropy labels since it may just look for label 7 = and need not verify that the previous label in the stack is not the = Extension Label 15. Will do. Thanks for the wording. > Alia From kireeti.kompella@gmail.com Sat Aug 10 09:07:33 2013 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 CB09F11E8109 for ; Sat, 10 Aug 2013 09:07:32 -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.001, 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 Eqs-dRJsxZ88 for ; Sat, 10 Aug 2013 09:07:31 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6A721F9B4D for ; Sat, 10 Aug 2013 08:59:32 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id e11so2674987qcx.22 for ; Sat, 10 Aug 2013 08:59:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=5A6tybE7TxV2YWXroHr1k66wn1vSOa3MQeeSG8tu3dk=; b=rP4ic1G0GHumR/ybIeqnlXhoUy5uOFoePr81s/11kqqHiFwja0WGYfbOyH2+lvPkNM eUp6WifiDuuIQkeUmNcjT5a+4EoOgpR8HMjPhThOewGlFAv1voS3BJQabR/L+UrWnjNt EjTGilJ/yZtESTHCifiZyqkGxvFSDvw4RPOIhUsSQFwPXCRYSjCiyv/jMq2+i8qf3Aks h+bVxegUZ314aw5hnOJ10FDn/wJ8UGJfTsnLE4ZpGqwKYYV7pykyl3MPoX4xLc0NYVYN F1CPlyVjl+xqI508kd87j9r/IdQiMq2ZiRrIcXQGBmiRrbbugOr7zrgyu1KBYk0WGVsy Y12g== X-Received: by 10.224.67.202 with SMTP id s10mr14794535qai.78.1376150368798; Sat, 10 Aug 2013 08:59:28 -0700 (PDT) Received: from [172.28.131.194] (westford-nat.juniper.net. [66.129.232.2]) by mx.google.com with ESMTPSA id y1sm28289116qaj.2.2013.08.10.08.59.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 10 Aug 2013 08:59:27 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_2994334C-7C8E-4CA4-AF7B-55049D490908" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Kireeti Kompella In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E012024C3@MISOUT7MSGUSR9I.ITServices.sbc.com> Date: Sat, 10 Aug 2013 08:59:23 -0700 Message-Id: <45C4ACC4-88D1-4004-B3DC-DC0F2B010A1F@gmail.com> References: <29F9570C-4598-41D2-8E2B-473233C9D185@gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CDECC@NKGEML512-MBS.china.huawei.com> <1D70D757A2C9D54D83B4CBD7625FA80E012024C3@MISOUT7MSGUSR9I.ITServices.sbc.com> To: "NAPIERALA, MARIA H" X-Mailer: Apple Mail (2.1508) Cc: mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-special-purpose-labels-01 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, 10 Aug 2013 16:07:33 -0000 --Apple-Mail=_2994334C-7C8E-4CA4-AF7B-55049D490908 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi Maria, On Jul 13, 2013, at 16:50 , "NAPIERALA, MARIA H" wrote: (wow -- only a month later :)) > Hi Kireeti, > =20 > A comment on the ranges of Extended Special Purpose MPLS Labels: > (1) Shouldn=A1=AFt there be a larger Unassigned range (using = terminology of RFC 5226)? As I understand, the Unassigned tag is used by IANA to say that the = values in a certain allocation range have not yet been assigned. If a = registry is created as requested, labels 16-239 will be marked = Unassigned (until some are allocated). > (2) Why is Reserved range so large? What is the purpose? The Reserved range says two things: a) all labels following an extension label should be treated as extended = special purpose labels; and b) we don't think we need so many, but we don't know what the allocation = policy should be if we would need more, so we won't say anything right = now. > Maria Kireeti. --Apple-Mail=_2994334C-7C8E-4CA4-AF7B-55049D490908 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 Hi Maria,

On = Jul 13, 2013, at 16:50 , "NAPIERALA, MARIA H" <mn1921@att.com> = wrote:

(wow -- only a month later = :))

A comment on the ranges of = (1) Shouldn=A1=AFt there be a = larger Unassigned = range (using terminology of RFC = 5226)?

As I = understand, the Unassigned tag is used by IANA to say that the values in = a certain allocation range have not yet been assigned.  If a = registry is created as requested, labels 16-239 will be marked = Unassigned (until some are allocated).

   Why is Reserved = range so large? What is the = purpose?

The = Reserved range says two things:
a) all labels following an = extension label should be treated as extended special purpose labels; = and
b) we don't think we need so many, but we don't know what = the allocation policy should be if we would need more, so we won't say = anything right now.

Maria

Kireeti.=

= --Apple-Mail=_2994334C-7C8E-4CA4-AF7B-55049D490908-- From kireeti.kompella@gmail.com Sat Aug 10 09:16:16 2013 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 B993311E815E for ; Sat, 10 Aug 2013 09:16:16 -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 jKkigDaY8XaV for ; Sat, 10 Aug 2013 09:16:16 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 615D511E817D for ; Sat, 10 Aug 2013 09:10:02 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id bq6so358700qab.19 for ; Sat, 10 Aug 2013 09:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QU7jLCYwjjMxAFYZ0pepWZPw0xmUyPOUhAQtgqb7TxE=; b=KR7ch03me+soeW9hvb757pb5zOj9peWCiibETL2DnzCiOju6WP7W++TgAwBf+//Fzc bFRZDpLyaj5yPxubMWu6w4w1lofH33Rvp/2x+jGy4sIW6xqizyCPpXMZu/eOWT2WylqZ 8mg5ufd1esKwqdCdRkdUstpq7uzirZykKLGzOsw0wor0ip7qotEmBvxTJgsovLxGG5vY bJsHq+3ROWdLTJO5HpkmlxTvHHimf4Xvbu6Xa03txKJzEeotEPlI5XP2/9OhL2bHxRzI MDgRcADq6anRn4dEp+CW+wOXErxJYNfbZRn9/Mm9Uf6TMiDehVyP3DM3lAcl+3ITwCjN wzLw== X-Received: by 10.224.76.71 with SMTP id b7mr16718386qak.48.1376150995305; Sat, 10 Aug 2013 09:09:55 -0700 (PDT) Received: from [172.28.131.194] (westford-nat.juniper.net. [66.129.232.2]) by mx.google.com with ESMTPSA id a2sm25757936qek.7.2013.08.10.09.09.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 10 Aug 2013 09:09:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Kireeti Kompella In-Reply-To: <201307261743.r6QHhwjG065662@gateway1.orleans.occnc.com> Date: Sat, 10 Aug 2013 09:09:49 -0700 Content-Transfer-Encoding: 7bit Message-Id: <4BAB4A92-B07C-4AD5-8079-8A25F1335DDA@gmail.com> References: <201307261743.r6QHhwjG065662@gateway1.orleans.occnc.com> To: curtis@ipv6.occnc.com X-Mailer: Apple Mail (2.1508) Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-special-purpose-labels@tools.ietf.org Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 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, 10 Aug 2013 16:16:16 -0000 On Jul 26, 2013, at 10:43 , Curtis Villamizar wrote: > Right now the document does not say what an LSR should do if it > encounters an unknown (to it) ESP label. This should require a > separate section entitled "Forwarding Packets with Unknown Extension > Labels". If this label is deep in the stack, the it seems that the > best action would be to always ignore it. New text: 3.1.1. Forwarding Packets with Extended Special Purpose Labels If an LSR encounters an extension label at the top of stack and it doesn't understand extension labels, it SHOULD drop the packet. If an LSR encounters an extended special purpose label at the top of stack that it doesn't understand, it SHOULD drop the packet. In either case, it MAY log the event, but such logging MUST be rate- limited. An LSR SHOULD NOT make forwarding decisions on labels not at the top of stack. For load balancing decisions, see Answer 6 of Section 3. I expect Adrian to ask "why SHOULD and not MUST?" Is there is reference for the second para (say in 3031/3032)? Kireeti From xuxiaohu@huawei.com Sun Aug 11 18:05:24 2013 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 35B2311E814C for ; Sun, 11 Aug 2013 18:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 7-eQtI+TZb+E for ; Sun, 11 Aug 2013 18:05:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 774C421F9D7C for ; Sun, 11 Aug 2013 17:59:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVX79810; Mon, 12 Aug 2013 00:59:56 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 12 Aug 2013 01:59:32 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 12 Aug 2013 01:59:56 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.204]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.01.0323.007; Mon, 12 Aug 2013 08:58:53 +0800 From: Xuxiaohu To: Ross Callon , "mpls@ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Thread-Topic: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 Thread-Index: AQHOgkXkYrQd1q7nwESyW7qFSZgPV5mNeXGQgANv7dA= Date: Mon, 12 Aug 2013 00:58:52 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081E369B@NKGEML512-MBS.china.huawei.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C76D83@CH1PRD0510MB355.namprd05.prod.outlook.com> <62CCD4C52ACDAD4481149BD5D8A72FD316D6D7D6@CH1PRD0510MB355.namprd05.prod.outlook.com> <18dba3497ae64dd1b884767acc961696@BLUPR05MB070.namprd05.prod.outlook.com> In-Reply-To: <18dba3497ae64dd1b884767acc961696@BLUPR05MB070.namprd05.prod.outlook.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081E369BNKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 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, 12 Aug 2013 01:05:25 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081E369BNKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIHRoZSBkb2N1bWVudCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uDQoNCkJlc3Qg cmVnYXJkcywNClhpYW9odQ0KDQq3orz+yMs6IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Om1wbHMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBSb3NzIENhbGxvbg0Kt6LLzcqxvOQ6IDIwMTPE 6jjUwjEwyNUgNDoyOA0KytW8/sjLOiBSb3NzIENhbGxvbjsgbXBsc0BpZXRmLm9yZzsgZHJhZnQt aWV0Zi1tcGxzLXNwZWNpYWwtcHVycG9zZS1sYWJlbHNAdG9vbHMuaWV0Zi5vcmcNCrOty806IG1w bHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQrW98ziOiBSZTogW21wbHNdIE1QTFMgV0cgbGFzdCBj YWxsIG9uIGRyYWZ0LWlldGYtbXBscy1zcGVjaWFsLXB1cnBvc2UtbGFiZWxzLTAzDQoNClRoaXMg bGFzdCBjYWxsIHNob3VsZCBoYXZlIGVuZGVkIGFscmVhZHkuIEhvd2V2ZXIsIHRoZXJlIGhhdmUg YmVlbiByZWxhdGl2ZWx5IGZldyBjb21tZW50cywgbW9zdCBvZiB3aGljaCBoYXZlIGJlZW4gZm9j dXNlZCBvbiBhIHNwZWNpZmljIHRlY2huaWNhbCBpc3N1ZS4gV2hpbGUgaXQgYXBwZWFycyB0aGF0 IHRoaXMgaXNzdWUgbWlnaHQgYmUgY2xvc2UgdG8gcmVzb2x1dGlvbiwgd2UgaGF2ZSByZWxhdGl2 ZWx5IGxpdHRsZSBpbmRpY2F0aW9uIG9mIHN1cHBvcnQgKGFuZCBzbyBmYXIgbm8gaW5kaWNhdGlv biBvZiBvcHBvc2l0aW9uIGV4Y2VwdCBmb3IgY29tbWVudHMgb24gdGVjaG5pY2FsIGRldGFpbHMg dG8gYmUgcmVzb2x2ZWQpLg0KDQpBcyBzdWNoIHdlIGFyZSBleHRlbmRpbmcgdGhlIGxhc3QgY2Fs bCBmb3Igb25lIHdlZWssIHVudGlsIG9uZSB3ZWVrIGZyb20gdG9kYXkuIFBsZWFzZSB0YWtlIGEg bG9vayBhdCB0aGUgZHJhZnQgYW5kIGxldCB1cyBrbm93IHdoZXRoZXIgdGhlIGRvY3VtZW50IGlz IHJlYWR5IGZvciBwdWJsaWNhdGlvbiAobW9kdWxvIHJlc29sdXRpb24gb2YgdGhlIGNvbW1lbnRz IGFscmVhZHkgcmVjZWl2ZWQpLiBUaGlzIGV4dGVuZGVkIGxhc3QgY2FsbCB3aWxsIGVuZCBvbmUg d2VlayBmcm9tIHRvZGF5LCBvbiBGcmlkYXkgQXVndXN0IDE2dGguDQoNClRoYW5rcywgUm9zcw0K KGFzIFdHIGNoYWlyKQ0KDQpGcm9tOiBSb3NzIENhbGxvbiBbbWFpbHRvOnJjYWxsb25AanVuaXBl ci5uZXRdDQpTZW50OiBUdWVzZGF5LCBKdWx5IDE2LCAyMDEzIDE6MDAgUE0NClRvOiBtcGxzQGll dGYub3JnOyBkcmFmdC1pZXRmLW1wbHMtc3BlY2lhbC1wdXJwb3NlLWxhYmVsc0B0b29scy5pZXRm Lm9yZw0KQ2M6IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBWSUdPVVJFVVgsIE1BUlRJTiAo TUFSVElOKQ0KU3ViamVjdDogTVBMUyBXRyBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXNw ZWNpYWwtcHVycG9zZS1sYWJlbHMtMDMNCg0KV29ya2luZyBHcm91cCwNCg0KVGhpcyBpcyB0byBz dGFydCBXb3JraW5nIEdyb3VwIGxhc3QgY2FsbCBvbiAgZHJhZnQtaWV0Zi1tcGxzLXNwZWNpYWwt cHVycG9zZS1sYWJlbHMtMDMNCg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbXBs cyB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCAobXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0Bp ZXRmLm9yZz4pLg0KDQpQbGVhc2Ugc2VuZCBib3RoIHRlY2huaWNhbCBjb21tZW50cywgYW5kIChp ZiB5b3UgYXJlIGhhcHB5IHdpdGggdGhlIGRvY3VtZW50IGFzIGlzKQ0KYWxzbyBzZW5kIGluZGlj YXRpb25zIG9mIHN1cHBvcnQuDQoNClRoZXJlIGFyZSBubyBJUFIgY2xhaW1zIGFnYWluc3QgdGhp cyBkcmFmdC4gVGhlIGNvLWF1dGhvcnMgaGF2ZSBlYXJsaWVyIHN0YXRlZCB0aGF0IHRoZXkNCmFy ZSBub3QgYXdhcmUgb2YgYW55IElQUiBhcHBsaWNhYmxlIHRvIHRoaXMgZHJhZnQuDQoNCklmIGFu eW9uZSBlbHNlIGluIHRoZSB3b3JraW5nIGdyb3VwIGlzIGF3YXJlIG9mIElQUnMgY2xhaW1zIGFn YWluc3QNCnRoaXMgZHJhZnQsIHRoZSB0aW1lIHRvIGRpc2Nsb3NlIHRoYXQgaXMgbm93Lg0KDQpE dWUgdG8gdGhlIHVwY29taW5nIElFVEYgbWVldGluZyBpbiBCZXJsaW4sIHRoaXMgbGFzdCBjYWxs IHdpbGwgYmUgZXh0ZW5kZWQgYnkgYW4gZXh0cmEgd2Vlaw0KKHdoaWNoIGltcGxpZXMgdGhhdCB0 aGUgbGFzdCBjYWxsIHdpbGwgYmUgb25nb2luZyBkdXJpbmcgdGhlIElFVEYgbWVldGluZykuIFRo aXMgd29ya2luZyBncm91cA0KbGFzdCBjYWxsIHdpbGwgZW5kIG9uIEF1Z3VzdCA2LCAyMDEzLg0K DQpSb3NzDQpmb3IgdGhlIHdnIGNvLWNoYWlycw0KDQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081E369BNKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I believe the document is ready= for publication.

 

Best regards,=

Xiaohu

 = ;

=B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org= [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED = Ross Callon
=B7=A2=CB=CD= =CA=B1=BC=E4: 2013=C4=EA8=D4=C2<= span lang=3D"EN-US">10=C8=D5 4:28
=CA=D5=BC=FE=C8=CB: Ross Callon; mpls@ietf.org; draft-ietf-mpls-special-purpose-labels@= tools.ietf.org
=B3=AD=CB=CD: mpls-chairs@tools.ietf.org
=D6=F7=CC=E2: Re: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03=

 

This last = call should have ended already. However, there have been relatively few com= ments, most of which have been focused on a specific technical issue. While it appears that this issue might be close to resolution, we h= ave relatively little indication of support (and so far no indication of op= position except for comments on technical details to be resolved).

 = ;

As such we= are extending the last call for one week, until one week from today. Pleas= e take a look at the draft and let us know whether the document is ready for publication (modulo resolution of the comments already receiv= ed). This extended last call will end one week from today, on Friday August= 16th.

 = ;

Thanks, Ro= ss

(as WG cha= ir)

 = ;

From: Ross Callon [mailto:rcallon@juniper.net]
Sent: Tuesday, July 16, 2013 1:00 PM
To: mpls@ietf.org; draft-ietf-mpls-special-purpose-labels@tools.ietf= .org
Cc: mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN)
Subject: MPLS WG last call on draft-ietf-mpls-special-purpose-labels= -03

 

Working Group,

 =

This is to start Working Group last call on  draft-ietf-mpls-special-purpose-labels-03

 =

Please send your comment= s to the mpls working group mailing list (mpls@ietf.org).

 =

Please send both technic= al comments, and (if you are happy with the document as is)

also send indications of= support.

 =

There are no IPR claims = against this draft. The co-authors have earlier stated that they

are not aware of any IPR applicable to this draft.

 =

If anyone else in the wo= rking group is aware of IPRs claims against

this draft, the time to = disclose that is now.

 =

Due to the upcoming IETF= meeting in Berlin, this last call will be extended by an extra week

(which implies that the = last call will be ongoing during the IETF meeting). This working group

last call will end on Au= gust 6, 2013.

 =

Ross

for the wg co-chairs

 = ;

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081E369BNKGEML512MBSchi_-- From tochio@jp.fujitsu.com Sun Aug 11 18:10:50 2013 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 F1D0121E805A for ; Sun, 11 Aug 2013 18:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 QNVSfTz2ajra for ; Sun, 11 Aug 2013 18:10:44 -0700 (PDT) Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35]) by ietfa.amsl.com (Postfix) with ESMTP id D287311E80FC for ; Sun, 11 Aug 2013 18:02:05 -0700 (PDT) Received: from m3.gw.fujitsu.co.jp (unknown [10.0.50.73]) by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id D30C044DD86 for ; Mon, 12 Aug 2013 10:02:03 +0900 (JST) Received: from smail (m3 [127.0.0.1]) by outgoing.m3.gw.fujitsu.co.jp (Postfix) with ESMTP id C603145DEB7 for ; Mon, 12 Aug 2013 10:02:03 +0900 (JST) Received: from s3.gw.fujitsu.co.jp (s3.gw.fujitsu.co.jp [10.0.50.93]) by m3.gw.fujitsu.co.jp (Postfix) with ESMTP id B0FBC45DEB2 for ; Mon, 12 Aug 2013 10:02:03 +0900 (JST) Received: from s3.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id A4048E08001 for ; Mon, 12 Aug 2013 10:02:03 +0900 (JST) Received: from flabmail.flab.fujitsu.co.jp (flabmail.flab.fujitsu.co.jp [10.25.192.37]) by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id 58FE11DB803C for ; Mon, 12 Aug 2013 10:02:03 +0900 (JST) Received: from vskawa.flab.fujitsu.co.jp (vskawa.flab.fujitsu.co.jp [10.25.192.39]) by flabmail.flab.fujitsu.co.jp (8.14.4/8.14.4/110310-Fujitsu Labs. Domain Mail Master) with ESMTP id r7C123dM008770 for ; Mon, 12 Aug 2013 10:02:03 +0900 (JST) X-AuditID: 0a19c027-b7f7a8e000000f25-2f-5208340b86e0 Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.105]) by vskawa.flab.fujitsu.co.jp (Symantec Messaging Gateway) with SMTP id 40.D0.03877.B0438025; Mon, 12 Aug 2013 10:02:03 +0900 (JST) Received: from [127.0.0.1] (dhcp61.dream.flab.fujitsu.co.jp [10.25.144.194]) by dm.kawasaki.flab.fujitsu.co.jp (8.14.4/8.14.4) with ESMTP id r7C11KC2030673 for ; Mon, 12 Aug 2013 10:02:03 +0900 X-SecurityPolicyCheck: OK by SHieldMailChecker v1.8.4 Message-ID: <5208337E.4090206@jp.fujitsu.com> Date: Mon, 12 Aug 2013 09:59:42 +0900 From: Yuji Tochio User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mpls@ietf.org References: <62CCD4C52ACDAD4481149BD5D8A72FD316D78B3E@CH1PRD0510MB355.namprd05.prod.outlook.com>, <520555DE.6090304@gmail.com> <5B4A6CBE3924BB41A3BEE462A8E0B75A28154B55@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A28154B55@SMTP2.etri.info> Content-Type: multipart/alternative; boundary="------------020104020402010801090608" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsXCJXkgU5fbhCPI4PhtfotbS1eyOjB6LFny kymAMYrLJiU1J7MstUjfLoEr4+mWe+wFO/Urzr/ewdzA2KLQxcjJISFgItHe28gGYYtJXLi3 Hsjm4hASeMwo8fbiWRYI5wqjxMfj2xghqkwlJq57BmbzCuhKLL7znB3EZhFQlfj1ag8LiM0m oClxbeYdsBpRgWCJ3Y+fsULUC0qcnPkErEYEyJ529SiYLSwQIPH+6gQmiGU7GSVm/G8Fa+AU cJc407qSCcRmFgiTWDJ1JvsERv5ZSGbNQpKCsHUlbp74yARhy0tsfzuHGcLWkXjffJEdWXwB I9sqRsmy4uzE8kS9tJzEJL200qzMkuJSveR8vayCTYyQ8FXfwfhskeYhRgEORiUe3i9SHEFC rIllxZW5hxglOJiVRHgXKQCFeFMSK6tSi/Lji0pzUosPMTJxcEo1MHZml8fXt2p17vPOalfa 4Li42vypGKPY/6CV6bMjzQ7ufffWLXnNKR77z4e+iHg+2rlT/NOtpdmTVFkVboZ65GYxfJMx eLhMojZiv0qA84Src1dOTZN4Uq591fCwu29RfWLz5qJL83uqlt6erRj6X8q+6cb65jlSvSt5 Eoy27NXrcdwotOhMuBJLcUaioRZzUXEiANpO+Nw9AgAA Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-tp-rosetta-stone-11.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, 12 Aug 2013 01:10:51 -0000 This is a multi-part message in MIME format. --------------020104020402010801090608 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi all I also support the publication. Regards, Yuji (2013/08/10 8:41), Ryoo, Jeong-dong wrote: > Hi, > I support the publication of this document as it can be served as good foundation for understanding the documents written by the other SDO. > > Best regards, > Jeong-dong > > ======= > > Working Group, > > > > This is to start Working Group last call > > ondraft-ietf-mpls-tp-rosetta-stone-11.txt > > > > Please send your comments to the mpls working groupmailing list > > (mpls@ietf.org ). > > > > Please send both technical comments, and (if you are happywith the > > document as is) > > > > also send indications of support. > > > > There are no IPR claims against this draft.The co-authors have stated > > that they are not > > > > awareof any IPR applicable to this draft.If anyone else in the working > > group is aware of > > > > IPRs claims againstthis draft, the time to disclose that is now. > > > > Due to the upcoming IETF meeting in Berlin, this last call will be > > extended by an extra week > > > > (which implies that the last call will be ongoing during the IETF > > meeting). This working group > > > > last call will end on August 14, 2013. > > > > Ross > > > > for the wg co-chairs > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --------------020104020402010801090608 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit
Hi all

I also support the publication.

Regards, Yuji

(2013/08/10 8:41), Ryoo, Jeong-dong wrote:
Hi,
 
I support the publication of this document as it can be served as good foundation for understanding the documents written by the other SDO.

Best regards,
 
Jeong-dong
 
 

=======
> Working Group,
>
> This is to start Working Group last call
> ondraft-ietf-mpls-tp-rosetta-stone-11.txt
>
> Please send your comments to the mpls working groupmailing list
> (mpls@ietf.org ).
>
> Please send both technical comments, and (if you are happywith the
> document as is)
>
> also send indications of support.
>
> There are no IPR claims against this draft.The co-authors have stated
> that they are not
>
> awareof any IPR applicable to this draft.If anyone else in the working
> group is aware of
>
> IPRs claims againstthis draft, the time to disclose that is now.
>
> Due to the upcoming IETF meeting in Berlin, this last call will be
> extended by an extra week
>
> (which implies that the last call will be ongoing during the IETF
> meeting). This working group
>
> last call will end on August 14, 2013.
>
> Ross
>
> for the wg co-chairs
>
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org


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

--------------020104020402010801090608-- From mach.chen@huawei.com Sun Aug 11 18:56:12 2013 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 2153C21E8098 for ; Sun, 11 Aug 2013 18:56:12 -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=-0.000, 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 G1DyHsZtEA0P for ; Sun, 11 Aug 2013 18:56:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 61D6C11E8163 for ; Sun, 11 Aug 2013 18:48:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUH16764; Mon, 12 Aug 2013 01:48:53 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 12 Aug 2013 02:48:28 +0100 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 12 Aug 2013 02:48:51 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.128]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.007; Mon, 12 Aug 2013 09:48:47 +0800 From: Mach Chen To: Ross Callon , "mpls@ietf.org" , "draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org" Thread-Topic: MPLS WG last call on draft-ietf-mpls-tp-rosetta-stone-11.txt Thread-Index: AQHOiBXOGyaLMJ0V/0ufIkWYEqyzEJmQ60LQ Date: Mon, 12 Aug 2013 01:48:46 +0000 Message-ID: References: <62CCD4C52ACDAD4481149BD5D8A72FD316D78B3E@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316D78B3E@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BFC386szxeml558mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-tp-rosetta-stone-11.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, 12 Aug 2013 01:56:12 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BFC386szxeml558mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have read the draft, I think the draft is useful and well written. So, I = support to publish the daft. Best regards, Mach From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Wednesday, July 24, 2013 10:31 AM To: mpls@ietf.org; draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] MPLS WG last call on draft-ietf-mpls-tp-rosetta-stone-11.tx= t Working Group, This is to start Working Group last call on draft-ietf-mpls-tp-rosetta-sto= ne-11.txt Please send your comments to the mpls working group mailing list (mpls@ietf= .org). Please send both technical comments, and (if you are happy with the documen= t as is) also send indications of support. There are no IPR claims against this draft. The co-authors have stated that= they are not aware of any IPR applicable to this draft. If anyone else in the working gr= oup is aware of IPRs claims against this draft, the time to disclose that is now. Due to the upcoming IETF meeting in Berlin, this last call will be extended= by an extra week (which implies that the last call will be ongoing during the IETF meeting).= This working group last call will end on August 14, 2013. Ross for the wg co-chairs --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BFC386szxeml558mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi,

=  

= I have read the draft, I think th= e draft is useful and well written. So, I support to publish the daft. =

=  

= Best regards,

= Mach

=  

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Wednesday, July 24, 20= 13 10:31 AM
To: mpls@ietf.org; draft-iet= f-mpls-tp-rosetta-stone@tools.ietf.org
Cc: mpls-chairs@tools.ietf.o= rg
Subject: [mpls] MPLS WG last= call on draft-ietf-mpls-tp-rosetta-stone-11.txt

 

Working Group,

 

= This is to start Working Group last call on  draft-ietf-mpls-tp-rosetta-stone-11.txt

 

Please send your comments to the mpls working group mailing list (mpls@ietf.org).<= font color=3D"#1f497d">

 

Please send both technical comments, and (if you are happy with the document as is)

also send indications of support.

 

There are no IPR claims against this draft. The co-authors have stated that they are not

aware of any IPR applicable to this draft.<= span style=3D"color:#1F497D"> If anyone else in the working group <= span style=3D"color:#1F497D">is aware of

IPRs claims against this draft, the time to disclose that is now.

 

Due to the upcoming IETF meeting in Berlin, this last call will b= e extended by an extra week

(which implies that the last call will be ongoing during the IETF= meeting). This working group

last call will end on August 14, 201= 3.

 

Ross

for the wg co-chairs

=  

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BFC386szxeml558mbschi_-- From hejia@huawei.com Sun Aug 11 20:00:09 2013 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 5230721F9C69 for ; Sun, 11 Aug 2013 20:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 Qyzh1Bnm9Y5D for ; Sun, 11 Aug 2013 20:00:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 74D4421F9E6C for ; Sun, 11 Aug 2013 19:53:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVX86231; Mon, 12 Aug 2013 02:53:25 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 12 Aug 2013 03:53:21 +0100 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 12 Aug 2013 03:53:24 +0100 Received: from SZXEML505-MBX.china.huawei.com ([169.254.1.92]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.007; Mon, 12 Aug 2013 10:53:18 +0800 From: "Hejia (Jia)" To: Ross Callon , "mpls@ietf.org" , "draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org" Thread-Topic: MPLS WG last call on draft-ietf-mpls-tp-rosetta-stone-11.txt Thread-Index: AQHOiBXOGyaLMJ0V/0ufIkWYEqyzEJmQ/ZjQ Date: Mon, 12 Aug 2013 02:53:17 +0000 Message-ID: <735916399E11684EAF4EB4FB376B71952C700A3A@SZXEML505-MBX.china.huawei.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD316D78B3E@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316D78B3E@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.169] Content-Type: multipart/alternative; boundary="_000_735916399E11684EAF4EB4FB376B71952C700A3ASZXEML505MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-tp-rosetta-stone-11.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, 12 Aug 2013 03:00:09 -0000 --_000_735916399E11684EAF4EB4FB376B71952C700A3ASZXEML505MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KDQpCLlIuDQpKaWENCg0Kt6K8/sjLOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gUm9zcyBDYWxsb24NCreiy83Ksbzk OiAyMDEzxOo31MIyNMjVIDEwOjMxDQrK1bz+yMs6IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYt bXBscy10cC1yb3NldHRhLXN0b25lQHRvb2xzLmlldGYub3JnDQqzrcvNOiBtcGxzLWNoYWlyc0B0 b29scy5pZXRmLm9yZw0K1vfM4jogW21wbHNdIE1QTFMgV0cgbGFzdCBjYWxsIG9uIGRyYWZ0LWll dGYtbXBscy10cC1yb3NldHRhLXN0b25lLTExLnR4dA0KDQpXb3JraW5nIEdyb3VwLA0KDQpUaGlz IGlzIHRvIHN0YXJ0IFdvcmtpbmcgR3JvdXAgbGFzdCBjYWxsIG9uICBkcmFmdC1pZXRmLW1wbHMt dHAtcm9zZXR0YS1zdG9uZS0xMS50eHQNCg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0 aGUgbXBscyB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCAobXBsc0BpZXRmLm9yZzxtYWlsdG86 bXBsc0BpZXRmLm9yZz4pLg0KDQpQbGVhc2Ugc2VuZCBib3RoIHRlY2huaWNhbCBjb21tZW50cywg YW5kIChpZiB5b3UgYXJlIGhhcHB5IHdpdGggdGhlIGRvY3VtZW50IGFzIGlzKQ0KYWxzbyBzZW5k IGluZGljYXRpb25zIG9mIHN1cHBvcnQuDQoNClRoZXJlIGFyZSBubyBJUFIgY2xhaW1zIGFnYWlu c3QgdGhpcyBkcmFmdC4gVGhlIGNvLWF1dGhvcnMgaGF2ZSBzdGF0ZWQgdGhhdCB0aGV5IGFyZSBu b3QNCmF3YXJlIG9mIGFueSBJUFIgYXBwbGljYWJsZSB0byB0aGlzIGRyYWZ0LiBJZiBhbnlvbmUg ZWxzZSBpbiB0aGUgd29ya2luZyBncm91cCBpcyBhd2FyZSBvZg0KSVBScyBjbGFpbXMgYWdhaW5z dCB0aGlzIGRyYWZ0LCB0aGUgdGltZSB0byBkaXNjbG9zZSB0aGF0IGlzIG5vdy4NCg0KRHVlIHRv IHRoZSB1cGNvbWluZyBJRVRGIG1lZXRpbmcgaW4gQmVybGluLCB0aGlzIGxhc3QgY2FsbCB3aWxs IGJlIGV4dGVuZGVkIGJ5IGFuIGV4dHJhIHdlZWsNCih3aGljaCBpbXBsaWVzIHRoYXQgdGhlIGxh c3QgY2FsbCB3aWxsIGJlIG9uZ29pbmcgZHVyaW5nIHRoZSBJRVRGIG1lZXRpbmcpLiBUaGlzIHdv cmtpbmcgZ3JvdXANCmxhc3QgY2FsbCB3aWxsIGVuZCBvbiBBdWd1c3QgMTQsIDIwMTMuDQoNClJv c3MNCmZvciB0aGUgd2cgY28tY2hhaXJzDQoNCg== --_000_735916399E11684EAF4EB4FB376B71952C700A3ASZXEML505MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Support.

 = ;

 = ;

B.R.<= /o:p>

Jia

 = ;

=B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org= [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED = Ross Callon
=B7=A2=CB=CD= =CA=B1=BC=E4: 2013=C4=EA7=D4=C2<= span lang=3D"EN-US">24=C8=D5 10:31
=CA=D5=BC=FE=C8=CB: mpls@ietf.org; draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org
=B3=AD=CB=CD: mpls-chairs@tools.ietf.org
=D6=F7=CC=E2: [mpls] MPLS WG last call on draft-ietf-mpls-tp-rosetta-stone-11.txt<= /o:p>

 

Working Group,

 =

This is to start Working Group last call on  draft-ietf-mpls-tp-rosetta-stone-11.txt

 =

Please send your comment= s to the mpls working group mailing list (mpls@ietf.org).

 =

Please send both technic= al comments, and (if you are happy with the document as is)

also send indications of= support.

 =

There are no IPR claims = against this draft. The co-authors have stated that they are not

aware of any IPR applicable to this draft. <= /span>If anyone else in the working group is aware of

IPRs claims against this draft, the time to disclose that is now.

 =

Due to the upcoming IETF= meeting in Berlin, this last call will be extended by an extra week

(which implies that the = last call will be ongoing during the IETF meeting). This working group

last call will end on Au= gust 14, 2013.

 =

Ross

for the wg co-chairs

 = ;

--_000_735916399E11684EAF4EB4FB376B71952C700A3ASZXEML505MBXchi_-- From loa@pi.nu Mon Aug 12 03:13:23 2013 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 91C2721F91CE for ; Mon, 12 Aug 2013 03:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucymGrihx4CM for ; Mon, 12 Aug 2013 03:12:45 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0201421E80A3 for ; Mon, 12 Aug 2013 01:27:29 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id EA2621801668; Mon, 12 Aug 2013 10:27:19 +0200 (CEST) Message-ID: <52089C6A.1060104@pi.nu> Date: Mon, 12 Aug 2013 10:27:22 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Eric Osborne (eosborne)" References: <20ECF67871905846A80F77F8F4A27572102C229B@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A27572102C229B@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" Subject: Re: [mpls] Mode negotiation for PSC 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, 12 Aug 2013 10:13:25 -0000 Eric, On 2013-08-08 14:34, Eric Osborne (eosborne) wrote: > Example of method 2 > ------------------- > Both Node A and Node Z announce two things - Capabilities and Mask. > Capabilities is a bitmap of the capabilities that are supported. > Mask is a mask of don't-care bits against the Capabilities string. A 0 in Mask means "I don't care if we do this capability or not", and a 1 means "we must (or must not) agree on this capability in order to come up". > > A.capabilities = 00000 > A.mask = 00000 Why is this not A.capabilities = 11111 A.mask = 00000 ? /Loa > > This says "I am capable of supporting all capabilities and I don't care if we do any of them or not" -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From adrian@olddog.co.uk Mon Aug 12 10:23:08 2013 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 4269E21F90FD; Mon, 12 Aug 2013 10:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 cLBBUdXfeYzR; Mon, 12 Aug 2013 10:23:03 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1C121F84EA; Mon, 12 Aug 2013 10:18:08 -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 r7CHHvf5030809; Mon, 12 Aug 2013 18:17:57 +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 r7CHHuoj030797 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Aug 2013 18:17:56 +0100 From: "Adrian Farrel" To: "'Martin Stiemerling'" , "'The IESG'" References: <20130808195718.13984.49026.idtracker@ietfa.amsl.com> In-Reply-To: <20130808195718.13984.49026.idtracker@ietfa.amsl.com> Date: Mon, 12 Aug 2013 18:17:56 +0100 Message-ID: <01cb01ce977f$e34f0310$a9ed0930$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGbazHxH4PRZ09LcIvIzh0Td0I++Jn4J9Ug Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] Martin Stiemerling's No Objection on charter-ietf-mpls-05-01: (with COMMENT) 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, 12 Aug 2013 17:23:08 -0000 Hmmm. My intention was to ask for: - approval of this charter by the IESG - agreement that this does not need to go for external review I will try to poke the tool to make it say this. Adrian > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of > Martin Stiemerling > Sent: 08 August 2013 20:57 > To: The IESG > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org > Subject: Martin Stiemerling's No Objection on charter-ietf-mpls-05-01: (with > COMMENT) > > Martin Stiemerling has entered the following ballot position for > charter-ietf-mpls-05-01: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/charter-ietf-mpls/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I am Ok with the charter, but the headline in the tool says "Is this > charter ready for external review? Is this charter ready for approval > without external review?", interesting isn't it? > > Is it now w/ or w/o external review? From huubatwork@gmail.com Mon Aug 12 13:08:55 2013 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 8B0AB21F9A35 for ; Mon, 12 Aug 2013 13:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] 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 63ZLD9huqeqW for ; Mon, 12 Aug 2013 13:08:54 -0700 (PDT) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 99F2F21F9A38 for ; Mon, 12 Aug 2013 13:08:53 -0700 (PDT) Received: by mail-ea0-f181.google.com with SMTP id d10so3705288eaj.40 for ; Mon, 12 Aug 2013 13:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ABZNQY1FsVVWOquk1qu54pS9IeTNAmCfaxgXqVt247c=; b=W50keVTVo8jWs/hV4bIc/5HtXW4AGpfsZrMjlhCCdIGWSyL8qoDC3qixKNHygEQZOU yzUZ8B0pRArn0EdYPINmIdfX+D6+IRCzB3+3yz+zaA4ro0lle5Q1awnTtpyQtHnV8coR cxt6cGGHcmk0cywKdBfHgffFfY7fXYvj5n2vK2IU7ICVmNl2zGo+93PUGSgbOJ1SnpGt 1KqQAAR/PW9Hr2dbVjKIFlorzUUI8ZYC1gwa2ujw8oVRtrHt2YaUzFPc2CzadY2R2ELQ MrYR3BaJ+jEmoOq2j9ni55NO61Ie8xQr0I0CXUVZ7sbbgU9y45W+VJuOzIGBBFOIoDIJ arxg== X-Received: by 10.14.198.73 with SMTP id u49mr829309een.13.1376338129667; Mon, 12 Aug 2013 13:08:49 -0700 (PDT) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id bp43sm60178873eeb.4.2013.08.12.13.08.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Aug 2013 13:08:49 -0700 (PDT) Message-ID: <520940D0.5010301@gmail.com> Date: Mon, 12 Aug 2013 22:08:48 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mpls@ietf.org References: <20ECF67871905846A80F77F8F4A27572102C229B@xmb-rcd-x09.cisco.com> <52089C6A.1060104@pi.nu> In-Reply-To: <52089C6A.1060104@pi.nu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mpls] Mode negotiation for PSC 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, 12 Aug 2013 20:08:55 -0000 Hej Loa, You wondered: > On 2013-08-08 14:34, Eric Osborne (eosborne) wrote: > > >> Example of method 2 >> ------------------- >> Both Node A and Node Z announce two things - Capabilities and Mask. >> Capabilities is a bitmap of the capabilities that are supported. >> Mask is a mask of don't-care bits against the Capabilities string. A >> 0 in Mask means "I don't care if we do this capability or not", and a >> 1 means "we must (or must not) agree on this capability in order to >> come up". >> >> A.capabilities = 00000 >> A.mask = 00000 > > Why is this not > > A.capabilities = 11111 > A.mask = 00000 > > ? This latter is indeed what node A should indicate for "I am capable of supporting all capabilities and I don't care if we do any of them or not" Regards, Huub. -- ***************************************************************** 请记ä½ï¼Œä½ æ˜¯ç‹¬ä¸€æ— äºŒçš„，就åƒå…¶ä»–æ¯ä¸€ä¸ªäººä¸€æ · From larryli888@yahoo.com.cn Mon Aug 12 19:07:47 2013 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 07CE021E8054 for ; Mon, 12 Aug 2013 19:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.453 X-Spam-Level: X-Spam-Status: No, score=0.453 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, 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 Pe9xDuRaF0yC for ; Mon, 12 Aug 2013 19:07:41 -0700 (PDT) Received: from nm19-vm6.bullet.mail.sg3.yahoo.com (nm19-vm6.bullet.mail.sg3.yahoo.com [106.10.149.117]) by ietfa.amsl.com (Postfix) with ESMTP id BF28811E80FE for ; Mon, 12 Aug 2013 19:07:37 -0700 (PDT) Received: from [106.10.166.125] by nm19.bullet.mail.sg3.yahoo.com with NNFMP; 13 Aug 2013 02:07:28 -0000 Received: from [106.10.151.187] by tm14.bullet.mail.sg3.yahoo.com with NNFMP; 13 Aug 2013 02:07:28 -0000 Received: from [127.0.0.1] by omp1013.mail.sg3.yahoo.com with NNFMP; 13 Aug 2013 02:07:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 49835.47103.bm@omp1013.mail.sg3.yahoo.com Received: (qmail 49576 invoked by uid 60001); 13 Aug 2013 02:07:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1376359646; bh=wr+9Ax6rcwwRqUPRL34xekg1DTazcZOd4bLh7P1RrPA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=tGUqeaHpq+vjJDAtKD2ldLYlg+YX1mSiqbl9KLsiMemGVJKEYidLlqgEjOK7jYlHLSrYldXe0kNCYcW4xTlieuX4c4TfTrLxp+FdIksIsCXibo5HPfXRjcQutMPu24AlPBo0bXXS6jhtx8pOErRHpeuZyStyUmLWu8v9903OVeo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=lZld3mMpxcglUaBH+oLm53l8SiYLKsLAMdPmBc1VtglU1P7qfzjJIOi5kB8/W6EdtP5WmKVhfafdBWS+9o61wdCctb6iCqIcCQ6cu5bZutkRBMZuKjcxW3zXfnpUqUB/GDUTs5WeNNB2edenl6niGbME1eQBX+wTB4ZBF6GJmDU= ; X-YMail-OSG: YUz30oAVM1lup5Mh39U.PIrFBjZ4AwwNr2V4VPnHwiV5YPC 0MKF3iXilFh.l24DnuNZ1XghFIKrjq4mHtJXg4OL8.fyT7RGGijzWWI9Zc42 sJACRUAEwgyuca2EiGTbd3d1eNQSmg7pjxvrJjl1lWjFEPvLsZ480QQPXdwv PsjBGzkh9SwebzFR2EOTZuplgiXFAsvizUmXTfkTkII59m8GLp1pLhyFZG3Q UdkiU_mtlRjxGGj5ra304Lg4ppJtwOpJ34t_GkDny_bHDRU6HJSd7Dfn4A9k 9H3hRXBA_hqqdvX_dSgCTDDtcAetcdc9BieQhzYmE593HM02Es.Oo2J2YHX5 F8xrsj4Y6HB1obWT2kifx3kqz3eb5pOI9sQPhmKZCPaJphXWT4wkX.VfQ6Cc KyoxpG5i0Uy0TT45B.kLXIp_5hlk5qw6SS0EvgFgnfRatAVyicuw3..I7Tvz Lj3Kj8Mf0ereySFN7BdNPSTV7wmKlNuS3GkUUGjd3UMzPBLq4tg0IKSBZiF2 C.99LCNxlS3cxxH3TF.F_NjQ.Y8mXI4DYVEnhiiodTaT3 Received: from [221.130.253.135] by web15608.mail.cnb.yahoo.com via HTTP; Tue, 13 Aug 2013 10:07:26 CST X-Rocket-MIMEInfo: 002.001, KzEKwqAKKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpIYW4gTGksIFBoLkQgCkNoaW5hIE1vYmlsZSBSZXNlYXJjaCBJbnN0aXR1dGUKMzIgWHVhbnd1bWVuIFdlc3QgU3RyZWV0LCBYaWNoZW5nIERpc3RyaWN0LCBCZWlqaW5nIDEwMDA1MywgQ2hpbmEgCkZheDogKzg2IDEwIDYzMTM1MTU5IApNT0JJTEU6IDEzNTAxMDkzMzg1IAoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioBMAEBAQE- X-Mailer: YahooMailWebService/0.8.148.557 References: <62CCD4C52ACDAD4481149BD5D8A72FD316D78B3E@CH1PRD0510MB355.namprd05.prod.outlook.com>, <520555DE.6090304@gmail.com> <5B4A6CBE3924BB41A3BEE462A8E0B75A28154B55@SMTP2.etri.info> <5208337E.4090206@jp.fujitsu.com> Message-ID: <1376359646.26553.YahooMailNeo@web15608.mail.cnb.yahoo.com> Date: Tue, 13 Aug 2013 10:07:26 +0800 (CST) From: Larry To: Yuji Tochio , "mpls@ietf.org" In-Reply-To: <5208337E.4090206@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1134129794-1222831790-1376359646=:26553" Subject: [mpls] =?utf-8?b?5Zue5aSN77yaICBNUExTIFdHIGxhc3QgY2FsbCBvbiBkcmFm?= =?utf-8?q?t-ietf-mpls-tp-rosetta-stone-11=2Etxt?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Larry List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 02:07:47 -0000 ---1134129794-1222831790-1376359646=:26553 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1=0A=C2=A0=0A*************************************************************= ************=0AHan Li, Ph.D =0AChina Mobile Research Institute=0A32 Xuanwum= en West Street, Xicheng District, Beijing 100053, China =0AFax: +86 10 6313= 5159 =0AMOBILE: 13501093385 =0A********************************************= *****************************=0A=0A=0A________________________________=0A = =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Yuji Tochio =0A= =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A mpls@ietf.org =0A=E5=8F=91=E9=80=81=E6= =97=A5=E6=9C=9F=EF=BC=9A 2013=E5=B9=B48=E6=9C=8812=E6=97=A5, =E6=98=9F=E6= =9C=9F=E4=B8=80, 8:59 =E4=B8=8A=E5=8D=88=0A=E4=B8=BB=E9=A2=98: Re: [mpls] M= PLS WG last call on draft-ietf-mpls-tp-rosetta-stone-11.txt=0A =0A=0A=0AHi = all=0A=0AI also support the publication.=0A=0ARegards, Yuji=0A=0A(2013/08/1= 0 8:41), Ryoo, Jeong-dong wrote:=0A=0A =0A>Hi,=0A>=C2=A0=0A>I support the p= ublication of this document as it=C2=A0can be served as=C2=A0good foundatio= n=C2=A0for understanding the documents=C2=A0written by=C2=A0the other=C2=A0= SDO.=0A>=0A>=0A>Best regards,=0A>=C2=A0=0A>Jeong-dong=0A>=C2=A0=0A>=C2=A0= =0A>=0A>=3D=3D=3D=3D=3D=3D=3D=0A>> Working Group,=0A>>=0A>> This is to star= t Working Group last call=0A>> ondraft-ietf-mpls-tp-rosetta-stone-11.txt=0A= >>=0A>> Please send your comments to the mpls working=0A gro= upmailing list=0A>> (mpls@ietf.org ).=0A>>=0A>> Please send both technical = comments, and (if you=0A are happywith the=0A>> document a= s is)=0A>>=0A>> also send indications of support.=0A>>=0A>> There are no IP= R claims against this draft.The=0A co-authors have stated= =0A>> that they are not=0A>>=0A>> awareof any IPR applicable to this draft.= If=0A anyone else in the working=0A>> group is aware of=0A= >>=0A>> IPRs claims againstthis draft, the time to=0A disc= lose that is now.=0A>>=0A>> Due to the upcoming IETF meeting in Berlin, thi= s=0A last call will be=0A>> extended by an extra week=0A>>= =0A>> (which implies that the last call will be ongoing=0A = during the IETF=0A>> meeting). This working group=0A>>=0A>> last call will= end on August 14, 2013.=0A>>=0A>> Ross=0A>>=0A>> for the wg co-chairs=0A>>= =0A>>=0A>>=0A>> _______________________________________________=0A>> mpls m= ailing list=0A>> mpls@ietf.org=0A>=0A>=0A>=0A>_____________________________= __________________=0Ampls mailing list mpls@ietf.org https://www.ietf.org/m= ailman/listinfo/mpls =0A=0A_______________________________________________= =0Ampls mailing list=0Ampls@ietf.org=0Ahttps://www.ietf.org/mailman/listinf= o/mpls ---1134129794-1222831790-1376359646=:26553 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1
 
**************************************************= ***********************
Han Li, Ph.D
China Mobile Research Institute=
32 Xuanwumen West Street, Xicheng District, Beijing 100053, China
F= ax: +86 10 63135159
MOBILE: 13501093385
***************************= **********************************************

=E5=8F=91=E4=BB= =B6=E4=BA=BA=EF=BC=9A Yuji Tochio <tochio@jp.fujitsu.com><= br> =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC= =9A mpls@ietf.org
=E5=8F=91=E9=80=81=E6=97=A5=E6=9C=9F=EF=BC=9A= 2013=E5=B9=B48=E6=9C=8812=E6=97=A5, =E6=98=9F=E6=9C=9F=E4=B8=80= , 8:59 =E4=B8=8A=E5=8D=88
=E4=B8= =BB=E9=A2=98: Re: [mpls] MPLS WG last call on draft-ietf-mpls-tp= -rosetta-stone-11.txt
=0A =0A=0A =0A =0A
=0A
Hi all
=0A
=0A I also su= pport the publication.
=0A
=0A Regards, Yuji
=0A <= br>=0A (2013/08/10 8:41), Ryoo, Jeong-dong wrote:
=0A
=0A =
=0A =0A =0A
=0A =0A <= div>=0A
Hi,
=0A =
 
=0A
I support the publication of=0A this docume= nt as it can be served as good foundation for=0A = understanding the documents written by the other SDO.
= =0A
=0A
Best regards,
=0A =
 
=0A
Jeong-dong
=0A =
 
=0A
 
=0A
<= br>=0A =3D=3D=3D=3D=3D=3D=3D
=0A > Work= ing Group,
=0A >
=0A > This is to= start Working Group last call
=0A > ondraft-ietf-mpls= -tp-rosetta-stone-11.txt
=0A >
=0A &= gt; Please send your comments to the mpls working=0A groupma= iling list
=0A > (mpls@ietf.org=0A = ).
=0A >
=0A > Please send bo= th technical comments, and (if you=0A are happywith the=0A > document as is)
=0A >
= =0A > also send indications of support.
=0A = >
=0A > There are no IPR claims against = this draft.The=0A co-authors have stated
=0A = > that they are not
=0A >
=0A = > awareof any IPR applicable to this draft.If=0A = anyone else in the working
=0A > group is aware of=
=0A >
=0A > IPRs claims agai= nstthis draft, the time to=0A disclose that is now.
=0A= >
=0A > Due to the upcoming IET= F meeting in Berlin, this=0A last call will be
=0A = > extended by an extra week
=0A >=0A > (which implies that the last call will be ongoin= g=0A during the IETF
=0A > meeting)= . This working group
=0A >
=0A &= gt; last call will end on August 14, 2013.
=0A >
= =0A > Ross
=0A >
=0A = > for the wg co-chairs
=0A >
=0A = >
=0A >
=0A >= _______________________________________________
=0A &g= t; mpls mailing list
=0A > mpls@ietf.org
=0A =
=0A
=0A
=0A =0A
=0A
=0A
=0A
=0A 
__________________=
_____________________________=0Ampls mailing list=0Ampls@ietf.org=0Ahttps://www.ietf.or=
g/mailman/listinfo/mpls=0A
=0A =0A
=0A =0A=0A

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

---1134129794-1222831790-1376359646=:26553-- From presnick@qti.qualcomm.com Mon Aug 12 18:13:39 2013 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 F293121F9F96; Mon, 12 Aug 2013 18:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 EecvmsjS8PjX; Mon, 12 Aug 2013 18:13:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA89421F84DB; Mon, 12 Aug 2013 18:13:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130813011330.21644.1820.idtracker@ietfa.amsl.com> Date: Mon, 12 Aug 2013 18:13:30 -0700 X-Mailman-Approved-At: Mon, 12 Aug 2013 21:14:26 -0700 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: [mpls] Pete Resnick's No Objection on charter-ietf-mpls-05-01: (with COMMENT) 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, 13 Aug 2013 01:13:39 -0000 Pete Resnick has entered the following ballot position for charter-ietf-mpls-05-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-mpls/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "The responsibility includes..." What an odd construction. Can better words be chosen? - Maintain existing MPLS requirements, mechanisms, and protocols, in coordination with other working groups, e.g. CCAMP, PWE3 and OPSAWG working groups. I'm not sure what work item(s) you're talking about here. Is the WG updating existing requirements documents and/or protocol documents in response to new requirements from CCAMP, PWE3, and OPSAWG? Not clear from what's said what is being referred to. - Evolve key MPLS protocols, including LDP, tLDP, mLDP, RSVP-TE and LSP Ping to meet new requirements. Same question as above. "Evolve" is an odd word to choose, and I'm curious if the list of protocols is exhaustive. Please clarify. - Determine MPLS-specific aspects of traffic engineering for multi-areas/multi-AS in cooperation with the CCAMP WG Is there a reason this bullet changed from the previous version? It seems to have removed the "and document it" part. I'm not going to block this rechartering, but I would like to hear why the charter became (apparently) more mushy than it had been. From lizho.jin@gmail.com Mon Aug 12 21:31:58 2013 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 15A2111E8122 for ; Mon, 12 Aug 2013 21:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27bSTPKiVBnQ for ; Mon, 12 Aug 2013 21:31:57 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFA511E810F for ; Mon, 12 Aug 2013 21:31:57 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id k15so3848515qcv.40 for ; Mon, 12 Aug 2013 21:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=2EYt/G2DyPFZ9yFSa+b+UXPWX1brCDjf3gklu0+yWsg=; b=eveDWOyFgYWYPUNKP0u64T78K7VuzlIdArd43Q7FXk9dXZtVBpqoqjcgv544bZ7f0S mx5vBvIJbyke7Ab/dPm8g+QeDlD9dyCA9H5Pr0F5hA5oAx6XzM4AOyJUTDeM9xWRn66J 3FZjEYEc06wjNqx89ZkL2397hUg52YnC+TwcoPU4HFcRJkX2jz2QVFXUWYRglf6Cp0AY PzD01as2NeBXPZjhOtPcqfI3qK2z9laZtl23sJsiuWKYEdQ8eR8nZU/mqFqJFSDpVdtK 6lkuDupsnRsFFeniejM5BfDruSpT1Ryyv0R2gfhUdpD69HTWTyBlsokGhk1upcwq0Lf4 SkSw== MIME-Version: 1.0 X-Received: by 10.224.120.202 with SMTP id e10mr2758730qar.23.1376368315805; Mon, 12 Aug 2013 21:31:55 -0700 (PDT) Received: by 10.49.27.36 with HTTP; Mon, 12 Aug 2013 21:31:55 -0700 (PDT) Date: Tue, 13 Aug 2013 12:31:55 +0800 Message-ID: From: Lizhong Jin To: kireeti@juniper.net Content-Type: multipart/alternative; boundary=001a11c333e08b3b1204e3ccb84a Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 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, 13 Aug 2013 04:31:58 -0000 --001a11c333e08b3b1204e3ccb84a Content-Type: text/plain; charset=ISO-8859-1 > > > > However, I think we need to look if there are other cases there what > > is proposed by Kireeti leads to increasing complexity. > > > > If we for example we know that the 16 lowest values are not in > > the ranges allocated for extended label space that might simplify > > the search of the labels in the extended space. > > > > Any HW aspects on this? > > I don't believe so, and unless someone speaks up, I'll assume not :) > > Kireeti. > [Lizhong] let me try to explain my concern from HW aspects. 1. the HW will not process the MPLS label one by one like software, instead, the HW will process the lable with pipeline. If the HW supports to process 3 MPLS application label, then it always will process the 3 labels at the same time. 2. that means the HW behavior will not search a label with 7, and ignore other labels before and after 7. HW will always check the label before 7(ELI). Then from my view, the benefit Kireeti try to get does not exist in some HW implementations as I know. Then the increasing complexity it brings is the Extended Special Purpose MPLS Label table looking up. Now we will have two reserved label tables: 1. 0~15, it is the traditional reserved label table. This table is directly indexed by the reserved label. 2. 7, 16~1048575, it is the Extended Special Purpose label table. The table could not be directly indexed by the label, because the labels are not consecutive. You have to use addtional logic to index to the table. Anyway, this is not a block issue, and allowing 15/7 label may benefit some other implementations that I do not know. Thanks Lizhong > > > > > > /Loa > > > --001a11c333e08b3b1204e3ccb84a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

> However, I think we need to look if there are other cases there what > is proposed by Kireeti leads to increasing complexity.
>
> If we for example we know that the 16 lowest values are not in
> the ranges allocated for extended label space that might simplify
> the search of the labels in the extended space.
>
> Any HW aspects on this?

I don't believe so, and unless someone speaks up, I'll assume not := )

Kireeti.
=A0
[Lizhong] let me try to explain my conc= ern from HW aspects.
1. the HW will not process the MPLS label on= e by one like software, instead, the HW will process the lable with pipelin= e. If the HW supports to process 3 MPLS application label, then it always w= ill process the 3 labels at the same time.
2. that means the HW behavior will not search a label with 7, and igno= re other labels before and after=A07. HW will always check the label before= 7(ELI).
Then from my view, the benefit Kireeti try to get does n= ot exist in some HW implementations as I know.
=A0
Then the increasing complexity it brings is the Extended= Special Purpose MPLS Label table looking up. Now we will have two reserved= label=A0tables:
1. 0~15, it is the traditional reserved label ta= ble. This table is directly=A0indexed by the reserved label.
2. 7, 16~1048575, it is the Extended Special Purpose label table. The = table could not be directly indexed by the label, because the labels=A0are = not consecutive. You have to use addtional logic to index to the table.
=A0
Anyway, this is not a block issue, and=A0allowing 15/7 l= abel=A0may benefit some other implementations that I do not know.
=A0
Thanks
Lizhong
=A0
=A0
=A0
> <chair hat on>
>
> /Loa


--001a11c333e08b3b1204e3ccb84a-- From mach.chen@huawei.com Tue Aug 13 02:04:44 2013 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 3844421E80E5 for ; Tue, 13 Aug 2013 02:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyz8a9trBoqy for ; Tue, 13 Aug 2013 02:04:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 80EB921E80EB for ; Tue, 13 Aug 2013 02:04:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVZ05918; Tue, 13 Aug 2013 09:04:31 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 13 Aug 2013 10:04:01 +0100 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 13 Aug 2013 10:04:27 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.128]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.007; Tue, 13 Aug 2013 17:04:23 +0800 From: Mach Chen To: Ross Callon , "mpls@ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Thread-Topic: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 Thread-Index: AQHOgkXk/5e12m2TNkeFcdzsBEiRqZmNeXGQgAWEQjA= Date: Tue, 13 Aug 2013 09:04:23 +0000 Message-ID: References: <62CCD4C52ACDAD4481149BD5D8A72FD316C76D83@CH1PRD0510MB355.namprd05.prod.outlook.com> <62CCD4C52ACDAD4481149BD5D8A72FD316D6D7D6@CH1PRD0510MB355.namprd05.prod.outlook.com> <18dba3497ae64dd1b884767acc961696@BLUPR05MB070.namprd05.prod.outlook.com> In-Reply-To: <18dba3497ae64dd1b884767acc961696@BLUPR05MB070.namprd05.prod.outlook.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BFCCAEszxeml558mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 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, 13 Aug 2013 09:04:44 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BFCCAEszxeml558mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have read the draft and think the draft is ready to be moved forward. One minor comment: Section 3.1 "An extension label MUST be followed by another label L (and thus MUST have= the bottom-of-stack bit clear)." "...if the latter, it may be an extension label, and thus followed by an ex= tended special purpose label." This gives my feeling that, other than 15, there would be other extension = labels, is this the intention? Or there will be only one "extension label".= If it's the later, I would remind change the text as: "The extension label MUST be followed by another label L (and thus MUST hav= e the bottom-of-stack bit clear)." "...if the latter, it may be the extension label, and thus followed by an e= xtended special purpose label." Best regards, Mach From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Saturday, August 10, 2013 4:28 AM To: Ross Callon; mpls@ietf.org; draft-ietf-mpls-special-purpose-labels@tool= s.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-la= bels-03 This last call should have ended already. However, there have been relative= ly few comments, most of which have been focused on a specific technical is= sue. While it appears that this issue might be close to resolution, we have= relatively little indication of support (and so far no indication of oppos= ition except for comments on technical details to be resolved). As such we are extending the last call for one week, until one week from to= day. Please take a look at the draft and let us know whether the document i= s ready for publication (modulo resolution of the comments already received= ). This extended last call will end one week from today, on Friday August 1= 6th. Thanks, Ross (as WG chair) From: Ross Callon [mailto:rcallon@juniper.net] Sent: Tuesday, July 16, 2013 1:00 PM To: mpls@ietf.org; draft-ietf-mpls-special-purpose-labels@tools.ietf.org Cc: mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) Subject: MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 Working Group, This is to start Working Group last call on draft-ietf-mpls-special-purpos= e-labels-03 Please send your comments to the mpls working group mailing list (mpls@ietf= .org). Please send both technical comments, and (if you are happy with the documen= t as is) also send indications of support. There are no IPR claims against this draft. The co-authors have earlier sta= ted that they are not aware of any IPR applicable to this draft. If anyone else in the working group is aware of IPRs claims against this draft, the time to disclose that is now. Due to the upcoming IETF meeting in Berlin, this last call will be extended= by an extra week (which implies that the last call will be ongoing during the IETF meeting).= This working group last call will end on August 6, 2013. Ross for the wg co-chairs --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BFCCAEszxeml558mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi,

=  

= I have read the draft and think the draft is ready to be moved forward.

=  

= One minor comment:

= Section 3.1

= “An extension label MUST be= followed by another label L (and thus MUST have the bottom-of-stack bit clear).R= 21;

=  

= “…if the latter, it m= ay be an extension label, and thus followed by an extended special purpose label.”=

=  

= This gives my feeling that, other than 15,  there would be othe= r extension labels, is this the intention? Or there will be only one “= ;extension label”. If it’s the later, I would remind change the= text as:

=  

= “The extension label MUST be followed by another label L (and thus MUST have th= e bottom-of-stack bit clear).”

=  

= “…if the latter, it m= ay be the extension label, and thus followed by an extended special purpose label.&#= 8221;

=  

=  

= Best regards,

= Mach

=  

=  

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Saturday, August 10, 2= 013 4:28 AM
To: Ross Callon; mpls@ietf.o= rg; draft-ietf-mpls-special-purpose-labels@tools.ietf.org
Cc: mpls-chairs@tools.ietf.o= rg
Subject: Re: [mpls] MPLS WG = last call on draft-ietf-mpls-special-purpose-labels-03

 

= This last call should have ended = already. However, there have been relatively few comments, most of which have been focused on a specific technical issue. While it appears= that this issue might be close to resolution, we have relatively little in= dication of support (and so far no indication of opposition except for comm= ents on technical details to be resolved).

=  

= As such we are extending the last= call for one week, until one week from today. Please take a look at the draft and let us know whether the document is ready for publication= (modulo resolution of the comments already received). This extended last c= all will end one week from today, on Friday August 16th.

=  

= Thanks, Ross

= (as WG chair)

=  

From: Ross Callon [mailto:rcallon@juniper.net]
Sent: Tuesday, July 16, 2013= 1:00 PM
To: mpls@ietf.org; draft-iet= f-mpls-special-purpose-labels@tools.ietf.org
Cc: mpls-chairs@tools.ietf.o= rg; VIGOUREUX, MARTIN (MARTIN)
Subject: MPLS WG last call o= n draft-ietf-mpls-special-purpose-labels-03

 

Working Group,

 

= This is to start Working Group last call on  draft-ietf-mpls-special-purpose-labels-03

 

Please send your comments to the mpls working group mailing list (mpls@ietf.org).<= font color=3D"#1f497d">

 

Please send both technical comments, and (if you are happy with the document as is)

also send indications of support.

 

There are no IPR claims against this draft. The co-authors have earlier stated that they

are not aware of any IPR applicable to this draft.<= span style=3D"color:#1F497D">

 

If anyone else in the working group is awar= e of IPRs claims against

this draft, the time to disclose that is now.

 

Due to the upcoming IETF meeting in Berlin, this last call will b= e extended by an extra week

(which implies that the last call will be ongoing during the IETF= meeting). This working group

last call will end on August 6, 2013.

 

Ross

for the wg co-chairs

=  

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BFCCAEszxeml558mbschi_-- From ietfc@btconnect.com Tue Aug 13 04:43:15 2013 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 6EFE811E8164 for ; Tue, 13 Aug 2013 04:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] 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 DwIdutMOe0EZ for ; Tue, 13 Aug 2013 04:43:09 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0186.outbound.messaging.microsoft.com [213.199.154.186]) by ietfa.amsl.com (Postfix) with ESMTP id CEFFA11E80EF for ; Tue, 13 Aug 2013 04:43:08 -0700 (PDT) Received: from mail151-db8-R.bigfish.com (10.174.8.244) by DB8EHSOBE006.bigfish.com (10.174.4.69) with Microsoft SMTP Server id 14.1.225.22; Tue, 13 Aug 2013 11:43:07 +0000 Received: from mail151-db8 (localhost [127.0.0.1]) by mail151-db8-R.bigfish.com (Postfix) with ESMTP id 7B9EB2200C1; Tue, 13 Aug 2013 11:43:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -14 X-BigFish: PS-14(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz8275ch1de098h1033IL8275bh8275dh1de097hz2dh2a8h5a9h668h839h93fhd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh19f0h1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail151-db8 (localhost.localdomain [127.0.0.1]) by mail151-db8 (MessageSwitch) id 1376394185992604_6387; Tue, 13 Aug 2013 11:43:05 +0000 (UTC) Received: from DB8EHSMHS022.bigfish.com (unknown [10.174.8.252]) by mail151-db8.bigfish.com (Postfix) with ESMTP id ECD84120045; Tue, 13 Aug 2013 11:43:05 +0000 (UTC) Received: from DB3PRD0710HT003.eurprd07.prod.outlook.com (157.56.253.85) by DB8EHSMHS022.bigfish.com (10.174.4.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 13 Aug 2013 11:43:05 +0000 Received: from pc6 (86.135.129.242) by pod51017.outlook.com (10.255.75.38) with Microsoft SMTP Server (TLS) id 14.16.347.3; Tue, 13 Aug 2013 11:43:05 +0000 Message-ID: <014201ce981a$34692240$4001a8c0@gateway.2wire.net> From: t.petch To: , Ross Callon References: <62CCD4C52ACDAD4481149BD5D8A72FD316D78B3E@CH1PRD0510MB355.namprd05.prod.outlook.com> <520555DE.6090304@gmail.com> Date: Tue, 13 Aug 2013 12:41:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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-Originating-IP: [86.135.129.242] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%JUNIPER.NET$RO%1$TLS%0$FQDN%$TlsDn% Cc: mpls@ietf.org, draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org Subject: Re: [mpls] MPLS WG last call ondraft-ietf-mpls-tp-rosetta-stone-11.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, 13 Aug 2013 11:43:15 -0000 ----- Original Message ----- From: "Huub van Helvoort" To: "Ross Callon" Cc: ; ; Sent: Friday, August 09, 2013 9:49 PM > As the editor of this draft I support publication. > > Only one comment: I would like to acknowledge the contributions by > Tom Petch to improve the quality of this draft. And I would like to acknowledge all the work that Huub has done to produce a document worthy of publication. I wonder (!) about 3.9 First use of PM, worth expanding; I had assumed that Problem Management is intended, but note that RFC6371, RFC5921 etc would say that it is Performance Monitoring 3.36. Server layer: A service layer is a layer network /service/server/? Tom Petch > > Cheers, Huub. > > > ======= > > Working Group, > > > > This is to start Working Group last call > > ondraft-ietf-mpls-tp-rosetta-stone-11.txt > > > > Please send your comments to the mpls working groupmailing list > > (mpls@ietf.org ). > > > > Please send both technical comments, and (if you are happywith the > > document as is) > > > > also send indications of support. > > > > There are no IPR claims against this draft.The co-authors have stated > > that they are not > > > > awareof any IPR applicable to this draft.If anyone else in the working > > group is aware of > > > > IPRs claims againstthis draft, the time to disclose that is now. > > > > Due to the upcoming IETF meeting in Berlin, this last call will be > > extended by an extra week > > > > (which implies that the last call will be ongoing during the IETF > > meeting). This working group > > > > last call will end on August 14, 2013. > > > > Ross > > > > for the wg co-chairs > >> From akatlas@gmail.com Tue Aug 13 07:19:03 2013 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 6032D21E813B for ; Tue, 13 Aug 2013 07:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBuk4ODUQgz5 for ; Tue, 13 Aug 2013 07:19:02 -0700 (PDT) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 944C521E8119 for ; Tue, 13 Aug 2013 07:19:02 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i10so11332587oag.2 for ; Tue, 13 Aug 2013 07:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vXRqfB06iTkvnkjTfFphFvxc0dzP888iGOQKrxY/r4k=; b=NWZ9vfEkpqTpj3/yOZHg2z92Xv52ZgLOEZ3IyRpBJLzRGwGee3q9wlqAdNBcdEyUQc CD0s8oYKKNdrJGse6RBrh99b4qe6xkaLqnphEcdj5Z5x+bYAXEPYfbfEQA3i43eAmiaY +XP6aTuUiiOhl/pp2WfGMcKHyT01j7x7iJvqctw2WgsK+U49evOKq+kS8we9cZEcshQu LEkgpxqLJkAAa/gLgxif5m9jP8JO2LIyxqYa1Mql9Qu7YiABy8ns1oHGdUZPsgukly61 CySjqTNhg0SKwx70b5eoYACO4o877tr5YPsscOh3/MIgocEnZjhTY6osz+zmxrewHXc/ Qa2A== MIME-Version: 1.0 X-Received: by 10.182.56.197 with SMTP id c5mr7018402obq.51.1376403541226; Tue, 13 Aug 2013 07:19:01 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Tue, 13 Aug 2013 07:19:01 -0700 (PDT) In-Reply-To: <18dba3497ae64dd1b884767acc961696@BLUPR05MB070.namprd05.prod.outlook.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C76D83@CH1PRD0510MB355.namprd05.prod.outlook.com> <62CCD4C52ACDAD4481149BD5D8A72FD316D6D7D6@CH1PRD0510MB355.namprd05.prod.outlook.com> <18dba3497ae64dd1b884767acc961696@BLUPR05MB070.namprd05.prod.outlook.com> Date: Tue, 13 Aug 2013 10:19:01 -0400 Message-ID: From: Alia Atlas To: Ross Callon Content-Type: multipart/alternative; boundary=001a11c25782247ad504e3d4ecc8 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 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, 13 Aug 2013 14:19:03 -0000 --001a11c25782247ad504e3d4ecc8 Content-Type: text/plain; charset=ISO-8859-1 I read the draft and, modulo the comments already received, believe it is ready for publication. Alia On Fri, Aug 9, 2013 at 4:28 PM, Ross Callon wrote: > This last call should have ended already. However, there have been > relatively few comments, most of which have been focused on a specific > technical issue. While it appears that this issue might be close to > resolution, we have relatively little indication of support (and so far no > indication of opposition except for comments on technical details to be > resolved). **** > > ** ** > > As such we are extending the last call for one week, until one week from > today. Please take a look at the draft and let us know whether the document > is ready for publication (modulo resolution of the comments already > received). This extended last call will end one week from today, on Friday > August 16th. **** > > ** ** > > Thanks, Ross**** > > (as WG chair)**** > > ** ** > > *From:* Ross Callon [mailto:rcallon@juniper.net] > *Sent:* Tuesday, July 16, 2013 1:00 PM > *To:* mpls@ietf.org; draft-ietf-mpls-special-purpose-labels@tools.ietf.org > *Cc:* mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) > *Subject:* MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03* > *** > > ** ** > > Working Group,**** > > **** > > This is to start Working Group last call on > draft-ietf-mpls-special-purpose-labels-03**** > > **** > > Please send your comments to the mpls working group mailing list ( > mpls@ietf.org).**** > > **** > > Please send both technical comments, and (if you are happy with the > document as is) **** > > also send indications of support.**** > > **** > > There are no IPR claims against this draft. The co-authors have earlier > stated that they **** > > are not aware of any IPR applicable to this draft.**** > > **** > > If anyone else in the working group is aware of IPRs claims against**** > > this draft, the time to disclose that is now.**** > > **** > > Due to the upcoming IETF meeting in Berlin, this last call will be > extended by an extra week **** > > (which implies that the last call will be ongoing during the IETF > meeting). This working group **** > > last call will end on August 6, 2013.**** > > **** > > Ross**** > > for the wg co-chairs**** > > ** ** > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --001a11c25782247ad504e3d4ecc8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I read the draft and, modulo the comments already received= , believe it is ready for publication.

Alia
<= div class=3D"gmail_extra">

On Fri, Aug 9,= 2013 at 4:28 PM, Ross Callon <rcallon@juniper.net> wrote:=

This last call should hav= e ended already. However, there have been relatively few comments, most of = which have been focused on a specific technical issue. While it appears that this issue might be close to resolution, we have relativel= y little indication of support (and so far no indication of opposition exce= pt for comments on technical details to be resolved).

=A0<= /p>

As such we are extending = the last call for one week, until one week from today. Please take a look a= t the draft and let us know whether the document is ready for publication (modulo resolution of the comments already received). This= extended last call will end one week from today, on Friday August 16t= h.

=A0<= /p>

Thanks, Ross

(as WG chair)

=A0<= /p>

From: Ross Cal= lon [mailto:rcallo= n@juniper.net]
Sent: Tuesday, July 16, 2013 1:00 PM
To: mpls@ietf.org= ; draft-ietf-mpls-special-purpose-labels@tools.ietf.org=
Cc: = mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN)
Subject: MPLS WG last call on draft-ietf-mpls-special-purpose-labels= -03

=A0

Working Group,

=A0

This = is to start Working Group last call on=A0 draft-ietf-mpls-special-purpose-labels-03

=A0

Please send your comments to the mpls w= orking group mailing list (mpls@ietf.org).

=A0

Please send both technical comments, an= d (if you are happy with the document as is)

also send indications of support.

=A0

There are no IPR claims against this dr= aft. The co-authors have earlier stated that they

are not aware of any IPR applicable to this draft.

=A0

If anyone else in the working group is aware of IPRs claims against=

this draft, the time to disclose that i= s now.

=A0

Due to the upcoming IETF meeting in Ber= lin, this last call will be extended by an extra week

(which implies that the last call will = be ongoing during the IETF meeting). This working group

last call will end on August 6, 2013.

=A0

Ross

for the wg co-chairs

=A0<= /p>


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


--001a11c25782247ad504e3d4ecc8-- From rcallon@juniper.net Tue Aug 13 09:04:55 2013 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 7F12C21E81A0 for ; Tue, 13 Aug 2013 09:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.704 X-Spam-Level: X-Spam-Status: No, score=-98.704 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, 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 jS0U7Ln7epvX for ; Tue, 13 Aug 2013 09:04:49 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 90B6621E814E for ; Tue, 13 Aug 2013 09:04:42 -0700 (PDT) Received: from mail209-co1-R.bigfish.com (10.243.78.254) by CO1EHSOBE034.bigfish.com (10.243.66.99) with Microsoft SMTP Server id 14.1.225.22; Tue, 13 Aug 2013 16:04:40 +0000 Received: from mail209-co1 (localhost [127.0.0.1]) by mail209-co1-R.bigfish.com (Postfix) with ESMTP id 1BEE1A0096; Tue, 13 Aug 2013 16:04:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 6 X-BigFish: PS6(zzc85fh4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz18c673hz2fh2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9ja02m1155h) Received-SPF: pass (mail209-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(164054003)(76176001)(81342001)(74366001)(15202345003)(65816001)(63696002)(80022001)(47976001)(5406001)(33646001)(76482001)(47736001)(51856001)(54356001)(69226001)(74876001)(19580385001)(31966008)(83322001)(19580395003)(46102001)(66066001)(74316001)(16406001)(49866001)(81686001)(77982001)(59766001)(74662001)(47446002)(74502001)(83072001)(76786001)(76576001)(56776001)(76796001)(56816003)(77096001)(81542001)(74706001)(79102001)(53806001)(4396001)(80976001)(54316002)(25636003)(50986001)(24736002)(5416002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB072; H:BLUPR05MB070.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail209-co1 (localhost.localdomain [127.0.0.1]) by mail209-co1 (MessageSwitch) id 1376409878322604_21376; Tue, 13 Aug 2013 16:04:38 +0000 (UTC) Received: from CO1EHSMHS023.bigfish.com (unknown [10.243.78.253]) by mail209-co1.bigfish.com (Postfix) with ESMTP id 4A29E80047; Tue, 13 Aug 2013 16:04:38 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS023.bigfish.com (10.243.66.33) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 13 Aug 2013 16:04:38 +0000 Received: from BLUPR05MB072.namprd05.prod.outlook.com (10.255.214.27) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.341.1; Tue, 13 Aug 2013 16:04:36 +0000 Received: from BLUPR05MB070.namprd05.prod.outlook.com (10.255.214.15) by BLUPR05MB072.namprd05.prod.outlook.com (10.255.214.27) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 13 Aug 2013 16:04:34 +0000 Received: from BLUPR05MB070.namprd05.prod.outlook.com ([169.254.15.164]) by BLUPR05MB070.namprd05.prod.outlook.com ([169.254.15.164]) with mapi id 15.00.0731.000; Tue, 13 Aug 2013 16:04:33 +0000 From: Ross Callon To: Loa Andersson , "loa@mail01.huawei.com" , "mpls@ietf.org" Thread-Index: Ac6YPsyftOXWOcULRzSYS3nyIK9grA== Date: Tue, 13 Aug 2013 16:04:33 +0000 Message-ID: <548939e7b7d94b0eaedb6010aaf118a6@BLUPR05MB070.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0937FB07C5 Content-Type: multipart/alternative; boundary="_000_548939e7b7d94b0eaedb6010aaf118a6BLUPR05MB070namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%ALCATEL-LUCENT.COM$RO%1$TLS%0$FQDN%$TlsDn% Cc: Ross Callon Subject: [mpls] (no subject) 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, 13 Aug 2013 16:04:55 -0000 --_000_548939e7b7d94b0eaedb6010aaf118a6BLUPR05MB070namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group, The author of draft-andersson-mpls-moving-iana-registries has told the working group chairs that the draft is ready to be adopted as a working group document. Before starting the the poll to see if we have consensus to make a working group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-andersson-mpls-moving-iana-registries? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The documents will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) --_000_548939e7b7d94b0eaedb6010aaf118a6BLUPR05MB070namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Working Group,
 
The author of draft-andersson-mpls-moving-iana-registries has told the=
working group chairs that the draft is ready to be adopted as a workin= g
group document.
 
Before starting the the poll to see if we have consensus to make a
working group document we need to do an IPR poll.
 
This mail starts that IPR poll.
 
Are you aware of any IPR that applies to
draft-andersson-mpls-moving-iana-registries?
 
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).
 
If you are listed as a document author or contributor please respond t= o
this email regardless of whether or not you are aware of any relevant<= /div>
IPR. *The response needs to be sent to the MPLS wg mailing list.* The =
documents will not advance to the next stage until a response
has been received from each author and contributor.
 
If you are on the MPLS WG email list but are not listed as an author o= r
contributor, then please explicitly respond only if you are aware of a= ny
IPR that has not yet been disclosed in conformance with IETF rules.
 
Thanks, Ross
(as MPLS WG co-chair)
 
 --_000_548939e7b7d94b0eaedb6010aaf118a6BLUPR05MB070namprd05pro_-- From rcallon@juniper.net Tue Aug 13 09:54:02 2013 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 9A1AD11E81A7 for ; Tue, 13 Aug 2013 09:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.085 X-Spam-Level: X-Spam-Status: No, score=-99.085 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132, 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 XQs2IAQ1H1Z1 for ; Tue, 13 Aug 2013 09:53:55 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0189.outbound.messaging.microsoft.com [213.199.154.189]) by ietfa.amsl.com (Postfix) with ESMTP id ACE7811E81A4 for ; Tue, 13 Aug 2013 09:53:53 -0700 (PDT) Received: from mail149-db8-R.bigfish.com (10.174.8.246) by DB8EHSOBE027.bigfish.com (10.174.4.90) with Microsoft SMTP Server id 14.1.225.22; Tue, 13 Aug 2013 16:53:52 +0000 Received: from mail149-db8 (localhost [127.0.0.1]) by mail149-db8-R.bigfish.com (Postfix) with ESMTP id 78F401400D1; Tue, 13 Aug 2013 16:53:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: PS1(zzc85fh4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz18c673hz2fh2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail149-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(164054003)(76176001)(81342001)(74366001)(15202345003)(65816001)(63696002)(80022001)(47976001)(33646001)(76482001)(19580385001)(47736001)(51856001)(54356001)(69226001)(74876001)(31966008)(83322001)(19580395003)(46102001)(66066001)(74316001)(16406001)(81686001)(49866001)(77982001)(59766001)(74662001)(47446002)(74502001)(81542001)(83072001)(76786001)(76576001)(56776001)(76796001)(56816003)(77096001)(74706001)(79102001)(4396001)(53806001)(80976001)(54316002)(50986001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB072; H:BLUPR05MB070.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail149-db8 (localhost.localdomain [127.0.0.1]) by mail149-db8 (MessageSwitch) id 1376412830142188_31627; Tue, 13 Aug 2013 16:53:50 +0000 (UTC) Received: from DB8EHSMHS019.bigfish.com (unknown [10.174.8.246]) by mail149-db8.bigfish.com (Postfix) with ESMTP id 141F0C0049; Tue, 13 Aug 2013 16:53:50 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS019.bigfish.com (10.174.4.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 13 Aug 2013 16:53:48 +0000 Received: from BLUPR05MB072.namprd05.prod.outlook.com (10.255.214.27) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.341.1; Tue, 13 Aug 2013 16:53:45 +0000 Received: from BLUPR05MB070.namprd05.prod.outlook.com (10.255.214.15) by BLUPR05MB072.namprd05.prod.outlook.com (10.255.214.27) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 13 Aug 2013 16:53:44 +0000 Received: from BLUPR05MB070.namprd05.prod.outlook.com ([169.254.15.164]) by BLUPR05MB070.namprd05.prod.outlook.com ([169.254.15.164]) with mapi id 15.00.0731.000; Tue, 13 Aug 2013 16:53:44 +0000 From: Ross Callon To: "loa@mail01.huawei.com" , "mpls@ietf.org" Thread-Topic: IPR poll on draft-andersson-mpls-moving-iana-registries Thread-Index: AQHOmEWrV3ijeFv9CUmMLcHBT/h+pw== Date: Tue, 13 Aug 2013 16:53:44 +0000 Message-ID: <8a9299fbf44940e79354a03b56815e93@BLUPR05MB070.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0937FB07C5 Content-Type: multipart/alternative; boundary="_000_8a9299fbf44940e79354a03b56815e93BLUPR05MB070namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%ALCATEL-LUCENT.COM$RO%1$TLS%0$FQDN%$TlsDn% Cc: Ross Callon Subject: [mpls] IPR poll on draft-andersson-mpls-moving-iana-registries 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, 13 Aug 2013 16:54:02 -0000 --_000_8a9299fbf44940e79354a03b56815e93BLUPR05MB070namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group, The author of draft-andersson-mpls-moving-iana-registries has told the working group chairs that the draft is ready to be adopted as a working group document. Before starting the the poll to see if we have consensus to make a working group document we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-andersson-mpls-moving-iana-registries? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The documents will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) (resent with correct subject line) --_000_8a9299fbf44940e79354a03b56815e93BLUPR05MB070namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Working Group,
 
The author of draft-andersson-mpls-moving-iana-registries has told the=
working group chairs that the draft is ready to be adopted as a workin= g
group document.
 
Before starting the the poll to see if we have consensus to make a
working group document we need to do an IPR poll.
 
This mail starts that IPR poll.
 
Are you aware of any IPR that applies to
draft-andersson-mpls-moving-iana-registries?
 
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).
 
If you are listed as a document author or contributor please respond t= o
this email regardless of whether or not you are aware of any relevant<= /div>
IPR. *The response needs to be sent to the MPLS wg mailing list.* The =
documents will not advance to the next stage until a response
has been received from each author and contributor.
 
If you are on the MPLS WG email list but are not listed as an author o= r
contributor, then please explicitly respond only if you are aware of a= ny
IPR that has not yet been disclosed in conformance with IETF rules.
 
Thanks, Ross
(as MPLS WG co-chair)
(resent with correct subject line)
 
 --_000_8a9299fbf44940e79354a03b56815e93BLUPR05MB070namprd05pro_-- From loa@pi.nu Tue Aug 13 10:13:50 2013 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 C934D11E818C for ; Tue, 13 Aug 2013 10:13:50 -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 WmGKLVkC-1UA for ; Tue, 13 Aug 2013 10:13:35 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id C9E3D11E81A2 for ; Tue, 13 Aug 2013 10:13:34 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D387E18000AA; Tue, 13 Aug 2013 19:13:33 +0200 (CEST) Message-ID: <520A6940.9040304@pi.nu> Date: Tue, 13 Aug 2013 19:13:36 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ross Callon References: <8a9299fbf44940e79354a03b56815e93@BLUPR05MB070.namprd05.prod.outlook.com> In-Reply-To: <8a9299fbf44940e79354a03b56815e93@BLUPR05MB070.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "loa@mail01.huawei.com" Subject: Re: [mpls] IPR poll on draft-andersson-mpls-moving-iana-registries 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, 13 Aug 2013 17:13:50 -0000 Ross, I'm the only author of this document and I'm not aware of any IPRs. /Loa On 2013-08-13 18:53, Ross Callon wrote: > Working Group, > The author of draft-andersson-mpls-moving-iana-registries has told the > working group chairs that the draft is ready to be adopted as a working > group document. > Before starting the the poll to see if we have consensus to make a > working group document we need to do an IPR poll. > This mail starts that IPR poll. > Are you aware of any IPR that applies to > draft-andersson-mpls-moving-iana-registries? > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > documents will not advance to the next stage until a response > has been received from each author and contributor. > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > Thanks, Ross > (as MPLS WG co-chair) > (resent with correct subject line) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From rcallon@juniper.net Tue Aug 13 11:24:03 2013 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 86E7521E80F3 for ; Tue, 13 Aug 2013 11:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.275 X-Spam-Level: X-Spam-Status: No, score=-99.275 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132, 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 vjTGteb-SFPi for ; Tue, 13 Aug 2013 11:23:57 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by ietfa.amsl.com (Postfix) with ESMTP id ECB2F21E80DA for ; Tue, 13 Aug 2013 11:23:56 -0700 (PDT) Received: from mail104-db8-R.bigfish.com (10.174.8.236) by DB8EHSOBE034.bigfish.com (10.174.4.97) with Microsoft SMTP Server id 14.1.225.22; Tue, 13 Aug 2013 18:23:55 +0000 Received: from mail104-db8 (localhost [127.0.0.1]) by mail104-db8-R.bigfish.com (Postfix) with ESMTP id CC885EC0154; Tue, 13 Aug 2013 18:23:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: PS-19(zzc85fh4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL18c673h1de097hz2fh2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail104-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(164054003)(74876001)(80976001)(16406001)(79102001)(76796001)(81686001)(19580385001)(69226001)(56816003)(76786001)(74366001)(74662001)(31966008)(19580395003)(76176001)(81542001)(77096001)(83322001)(19580405001)(76482001)(77982001)(33646001)(59766001)(81342001)(74706001)(54356001)(53806001)(47736001)(50986001)(4396001)(56776001)(49866001)(76576001)(46102001)(83072001)(15202345003)(63696002)(47976001)(47446002)(65816001)(74316001)(66066001)(80022001)(74502001)(51856001)(54316002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB069; H:BLUPR05MB070.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail104-db8 (localhost.localdomain [127.0.0.1]) by mail104-db8 (MessageSwitch) id 1376418233455043_17574; Tue, 13 Aug 2013 18:23:53 +0000 (UTC) Received: from DB8EHSMHS028.bigfish.com (unknown [10.174.8.248]) by mail104-db8.bigfish.com (Postfix) with ESMTP id 6A11EC4006A; Tue, 13 Aug 2013 18:23:53 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS028.bigfish.com (10.174.4.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 13 Aug 2013 18:23:52 +0000 Received: from BLUPR05MB069.namprd05.prod.outlook.com (10.255.214.14) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.341.1; Tue, 13 Aug 2013 18:23:50 +0000 Received: from BLUPR05MB070.namprd05.prod.outlook.com (10.255.214.15) by BLUPR05MB069.namprd05.prod.outlook.com (10.255.214.14) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 13 Aug 2013 18:23:49 +0000 Received: from BLUPR05MB070.namprd05.prod.outlook.com ([169.254.15.164]) by BLUPR05MB070.namprd05.prod.outlook.com ([169.254.15.164]) with mapi id 15.00.0731.000; Tue, 13 Aug 2013 18:23:48 +0000 From: Ross Callon To: "mpls@ietf.org" Thread-Topic: Poll for Adoption draft-andersson-mpls-moving-iana-registries-00 Thread-Index: Ac6YUkBh7zV9g+sGRCSLJd3RtsoDnw== Date: Tue, 13 Aug 2013 18:23:48 +0000 Message-ID: <5efa5403aab843bdbcc382a8143640ee@BLUPR05MB070.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0937FB07C5 Content-Type: multipart/alternative; boundary="_000_5efa5403aab843bdbcc382a8143640eeBLUPR05MB070namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%ALCATEL-LUCENT.COM$RO%1$TLS%0$FQDN%$TlsDn% Cc: "mpls-chairs@tools.ietf.org" , "loa@mail01.huawei.com" Subject: [mpls] Poll for Adoption draft-andersson-mpls-moving-iana-registries-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, 13 Aug 2013 18:24:03 -0000 --_000_5efa5403aab843bdbcc382a8143640eeBLUPR05MB070namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is to start a "two week" poll on adopting draft-andersson-mpls-moving-iana-registries-00 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end August 28, 2013. Thanks, Ross --_000_5efa5403aab843bdbcc382a8143640eeBLUPR05MB070namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This is to start a "two week" poll on adopting
draft-andersson-mpls-moving-iana-registries-00
as an MPLS working group document.
 
Please send your comments (support/not support) to the mpls working
group mailing list (mpls@ietf.org).
 
This poll will end August 28, 2013.
 
Thanks, Ross
 
 --_000_5efa5403aab843bdbcc382a8143640eeBLUPR05MB070namprd05pro_-- From cpignata@cisco.com Tue Aug 13 19:53:22 2013 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 4449911E8103 for ; Tue, 13 Aug 2013 19:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 28y6vxsdLNbB for ; Tue, 13 Aug 2013 19:53:17 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4D47C11E80FF for ; Tue, 13 Aug 2013 19:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8864; q=dns/txt; s=iport; t=1376448797; x=1377658397; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=w2KMNAttR+vOrppTi60qkREPfY88EgcWrlCrFGThH4U=; b=lO20v7kLJ7nozzv5pX3sCjJqqtc+AoiwDSUImb0XlTxOEu0kkQuMremX TTPkfbJmhk1QVd0WnSXJ6WuqNNvEwgBrC/iCCqcyHytauCX7nunzYZEOI 0OIbYO2CTnF3DqMuSWyvbI8Pxysoj1RCKggNFJX7bj1dqdDg07gDxWWOp 0=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAKfwClKtJXHB/2dsb2JhbABbgkJENVC+YoElFnSCJAEBAQMBAQEBawsFCwIBCA4UJCcLJQEBBAENBQgBBYd8Bgy4VJALLQQHgxt2A5AWgS6XcYMbgio X-IronPort-AV: E=Sophos;i="4.89,874,1367971200"; d="asc'?scan'208,217";a="247110365" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 14 Aug 2013 02:53:15 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7E2rFRa021914 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Aug 2013 02:53:15 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 21:53:15 -0500 From: "Carlos Pignataro (cpignata)" To: Ross Callon , "loa@mail01.huawei.com" Thread-Topic: [mpls] Poll for Adoption draft-andersson-mpls-moving-iana-registries-00 Thread-Index: Ac6YUkBh7zV9g+sGRCSLJd3RtsoDnwAcRPgA Date: Wed, 14 Aug 2013 02:53:14 +0000 Message-ID: <95067C434CE250468B77282634C96ED322DFE5CE@xmb-aln-x02.cisco.com> References: <5efa5403aab843bdbcc382a8143640ee@BLUPR05MB070.namprd05.prod.outlook.com> In-Reply-To: <5efa5403aab843bdbcc382a8143640ee@BLUPR05MB070.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.108.150] Content-Type: multipart/signed; boundary="Apple-Mail=_C34100D5-D55A-438F-B1D9-E6782DAB9F72"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for Adoption draft-andersson-mpls-moving-iana-registries-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, 14 Aug 2013 02:53:22 -0000 --Apple-Mail=_C34100D5-D55A-438F-B1D9-E6782DAB9F72 Content-Type: multipart/alternative; boundary="Apple-Mail=_FE3E4E00-2A6B-49C9-951E-E15B7C9B4786" --Apple-Mail=_FE3E4E00-2A6B-49C9-951E-E15B7C9B4786 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I believe that fixing and organizing misplaced number registrations is = useful and worthwhile as it prevents future confusion, and typically = welcome clean-ups. However, I do not support adoption of = draft-andersson-mpls-moving-iana-registries-00 in its current form. The document solves a small part of the potential source of confusion, = and, to me, it should fix all potential inconsistencies or leave things = as-is. Specifically:=20 draft-andersson-mpls-moving-iana-registries proposes only to move four = namespaces currently in [1] from [RFC6374] into a new heading = (registry). However, there's still the following potential inconsistencies, with all = these protocol elements from the G-ACH in different places: The G-ACH Channel Types namespace, although now it's a superset of the = original PW-ACH, is still titled "Pseudowire Associated Channel Types" = and is hosted in the pwe3-parameters registry. [2] Other G-ACH namespaces and assignments from [RFC6427] and [RFC6378] = reside in their own mpls-oam-parameters page [3] G-ACh Advertisement Protocol namespaces are in the pwe3-parameters = registry [4] [5] [6], although these are not PWE3. CC/CV MEP-ID TLV namespace with pwe3-parameters [7] I would suggest that either things are left as they are, or all these = G-ACH/PW-ACH namespaces are moved under a main "Generic Associated = Channel (G-ACH)" registry *if* there's consensus for the clean-up. Thanks, -- Carlos. [1] = http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-par= ameters.xml#measurement-timestamp [2] = https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#pwe= 3-parameters-11 [3] = https://www.iana.org/assignments/mpls-oam-parameters/mpls-oam-parameters.x= html [4] = https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gac= h-application [5] = https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gac= h-tlv [6] = https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gac= h-ethernet [7] = https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#cc-= cv-mep-id On Aug 13, 2013, at 2:23 PM, Ross Callon wrote: > This is to start a "two week" poll on adopting > draft-andersson-mpls-moving-iana-registries-00 > as an MPLS working group document. > =20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). > =20 > This poll will end August 28, 2013. > =20 > Thanks, Ross > =20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail=_FE3E4E00-2A6B-49C9-951E-E15B7C9B4786 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I believe that fixing and = organizing misplaced number registrations is useful and worthwhile as it = prevents future confusion, and typically welcome = clean-ups.

However, I do not support adoption = of draft-andersson-mpls-moving-iana-registries-00 in its current = form.

The document solves a small part of the = potential source of confusion, and, to me, it should fix all potential = inconsistencies or leave things = as-is.

Specifically: 
  • draft-andersson-mpls-moving-iana-registries = proposes only to move four namespaces currently in [1] = from [RFC6374] into a new heading = (registry).

However, there's still = the following potential inconsistencies, with all these protocol = elements from the G-ACH in different places:
  • The G-ACH Channel Types namespace, although = now it's a superset of the original PW-ACH, is still titled "Pseudowire = Associated Channel Types" and is hosted in the pwe3-parameters registry. = [2]
  • Other G-ACH namespaces and assignments from [RFC6427] = and [RFC6378] reside in their own mpls-oam-parameters page = [3]
  • G-ACh Advertisement Protocol namespaces are in the = pwe3-parameters registry [4] [5] [6], although these are not = PWE3.
  • CC/CV MEP-ID TLV namespace with pwe3-parameters = [7]

I would suggest that either = things are left as they are, or all these G-ACH/PW-ACH namespaces are = moved under a main "Generic Associated Channel (G-ACH)" registry *if* = there's consensus for the = clean-up.

Thanks,

-- = Carlos.



On= Aug 13, 2013, at 2:23 PM, Ross Callon <rcallon@juniper.net> = wrote:

This is to start a "two week" poll on = adopting
draft-andersson-mpls-moving-iana-registries-00
as an MPLS working group document.
 
Please = send your comments (support/not support) to the mpls = working
group mailing list (mpls@ietf.org).
 
This poll will end August 28, = 2013.
 
Thanks, = Ross
 
_________________________________= ______________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/m= ailman/listinfo/mpls

= --Apple-Mail=_FE3E4E00-2A6B-49C9-951E-E15B7C9B4786-- --Apple-Mail=_C34100D5-D55A-438F-B1D9-E6782DAB9F72 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlIK8RoACgkQtfDPGTp3USz5jQCdFD3uyaja6urmFa+1WkvkrMSN NSkAoNgnv6w9e6ziEM+0bvTovRHZ6exq =wTWS -----END PGP SIGNATURE----- --Apple-Mail=_C34100D5-D55A-438F-B1D9-E6782DAB9F72-- From loa@pi.nu Tue Aug 13 23:25:33 2013 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 4643E11E8126 for ; Tue, 13 Aug 2013 23:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfXpYXWW1l3H for ; Tue, 13 Aug 2013 23:25:29 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE2811E8122 for ; Tue, 13 Aug 2013 23:25:27 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 06F5A18000AA; Wed, 14 Aug 2013 08:25:25 +0200 (CEST) Message-ID: <520B22D9.5060400@pi.nu> Date: Wed, 14 Aug 2013 08:25:29 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" References: <5efa5403aab843bdbcc382a8143640ee@BLUPR05MB070.namprd05.prod.outlook.com> <95067C434CE250468B77282634C96ED322DFE5CE@xmb-aln-x02.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED322DFE5CE@xmb-aln-x02.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "loa@mail01.huawei.com" Subject: Re: [mpls] Poll for Adoption draft-andersson-mpls-moving-iana-registries-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, 14 Aug 2013 06:25:33 -0000 Carlos, While I tend to agree that someone (hint) should write-up a document fixing the G-ACh registries, that is not the purpose of the current documents. It is looking to clean up the LSP Ping registries. We have tried the approach "fixing everything" and failed to get our heads around it, decided to take a stepwise approach. If we now stumble on the first step (or rather second, since cleaning up the LSP registy structure was the first) I'm afraid that nothing will be done. Since you say (below) "solves a small part" I hope we can do this and go ahead and do the rest as soon as we have the cycles. /Loa On 2013-08-14 04:53, Carlos Pignataro (cpignata) wrote: > I believe that fixing and organizing misplaced number registrations is > useful and worthwhile as it prevents future confusion, and typically > welcome clean-ups. > > However, I do not support adoption > of draft-andersson-mpls-moving-iana-registries-00 in its current form. > > The document solves a small part of the potential source of confusion, > and, to me, it should fix all potential inconsistencies or leave things > as-is. > > Specifically: > > * draft-andersson-mpls-moving-iana-registries proposes only to move > four namespaces currently in [1] from [RFC6374] into a new heading > (registry). > > > However, there's still the following potential inconsistencies, with all > these protocol elements from the G-ACH in different places: > > * The G-ACH Channel Types namespace, although now it's a superset of > the original PW-ACH, is still titled "Pseudowire Associated Channel > Types" and is hosted in the pwe3-parameters registry. [2] > * Other G-ACH namespaces and assignments from [RFC6427] > and [RFC6378] reside in their own mpls-oam-parameters page [3] > * G-ACh Advertisement Protocol namespaces are in the pwe3-parameters > registry [4] [5] [6], although these are not PWE3. > * CC/CV MEP-ID TLV namespace with pwe3-parameters [7] > > > I would suggest that either things are left as they are, or all these > G-ACH/PW-ACH namespaces are moved under a main "Generic Associated > Channel (G-ACH)" registry *if* there's consensus for the clean-up. > > Thanks, > > -- Carlos. > > [1] > http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml#measurement-timestamp > [2] > https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#pwe3-parameters-11 > [3] > https://www.iana.org/assignments/mpls-oam-parameters/mpls-oam-parameters.xhtml > [4] > https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gach-application > [5] > https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gach-tlv > [6] > https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gach-ethernet > [7] > https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#cc-cv-mep-id > > > On Aug 13, 2013, at 2:23 PM, Ross Callon > wrote: > >> This is to start a "two week" poll on adopting >> draft-andersson-mpls-moving-iana-registries-00 >> as an MPLS working group document. >> Please send your comments (support/not support) to the mpls working >> group mailing list (mpls@ietf.org ). >> This poll will end August 28, 2013. >> Thanks, Ross >> _______________________________________________ >> 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 > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From N.Leymann@telekom.de Wed Aug 14 05:11:34 2013 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 54CDF21E8087 for ; Wed, 14 Aug 2013 05:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 2+3vmpJFvJYd for ; Wed, 14 Aug 2013 05:11:29 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id C952521E8086 for ; Wed, 14 Aug 2013 05:11:27 -0700 (PDT) Received: from he101251.emea1.cds.t-internal.com ([10.125.92.154]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 14 Aug 2013 14:11:25 +0200 Received: from HE111543.emea1.cds.t-internal.com ([10.125.90.96]) by HE101251.emea1.cds.t-internal.com ([fe80::e428:2144:dcc5:bcce%14]) with mapi; Wed, 14 Aug 2013 14:11:17 +0200 From: To: , Date: Wed, 14 Aug 2013 14:11:16 +0200 Thread-Topic: IPR poll on draft-ietf-mpls-seamless-mpls Thread-Index: Ac6JRrTDN7l8iTmWS6qrSt+l8FV1ugPoGRiQ Message-ID: <9762ACF04FA26B4388476841256BDE02011AE090E780@HE111543.emea1.cds.t-internal.com> References: <51F13BDD.9080704@pi.nu> In-Reply-To: <51F13BDD.9080704@pi.nu> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls-chairs@tools.ietf.org, draft-ietf-mpls-seamless-mpls.all@tools.ietf.org Subject: Re: [mpls] IPR poll on draft-ietf-mpls-seamless-mpls 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, 14 Aug 2013 12:11:34 -0000 Hi Loa, I am not aware of an IPR related to this draft. regards Nic -----Urspr=FCngliche Nachricht----- Von: Loa Andersson [mailto:loa@pi.nu] Gesendet: Donnerstag, 25. Juli 2013 16:53 An: mpls@ietf.org Cc: mpls-chairs@tools.ietf.org; draft-ietf-mpls-seamless-mpls.all@tools.iet= f.org; VIGOUREUX, MARTIN (MARTIN) Betreff: IPR poll on draft-ietf-mpls-seamless-mpls Working Group, The authors of draft-ietf-mpls-seamless-mpls has told the working group chairs that the draft is ready to be working group last called. We have not poll for IPRs on this draft earlier. Before starting the the wglc we need to do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-seamless-mpls? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The documents will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From yshen@juniper.net Wed Aug 14 08:34:59 2013 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 0672721F9DE1 for ; Wed, 14 Aug 2013 08:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFSrbxh4E05o for ; Wed, 14 Aug 2013 08:34:52 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8B66421F9655 for ; Wed, 14 Aug 2013 08:34:52 -0700 (PDT) Received: from mail74-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE015.bigfish.com (10.9.40.35) with Microsoft SMTP Server id 14.1.225.22; Wed, 14 Aug 2013 15:34:51 +0000 Received: from mail74-tx2 (localhost [127.0.0.1]) by mail74-tx2-R.bigfish.com (Postfix) with ESMTP id 9F45C1C007F; Wed, 14 Aug 2013 15:34:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: PS-20(zz9371Ic85fh4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz1d7338h1de098h1033IL17326ah18c673h1c8fb4h1de096h8275bh8275dh1de097hz2fh2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail74-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=yshen@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(377454003)(164054003)(18717965001)(47976001)(19300405004)(74316001)(59766001)(80022001)(50986001)(15202345003)(79102001)(65816001)(54356001)(77982001)(81342001)(81686001)(74876001)(4396001)(16236675002)(53806001)(49866001)(66066001)(80976001)(51856001)(69226001)(47736001)(16406001)(74706001)(74662001)(19580405001)(19580385001)(31966008)(76796001)(83072001)(74502001)(47446002)(76786001)(76576001)(74366001)(77096001)(83322001)(56816003)(54316002)(81542001)(63696002)(46102001)(56776001)(19580395003)(1941001)(33646001)(76482001)(81816001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB079; H:BY2PR05MB046.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail74-tx2 (localhost.localdomain [127.0.0.1]) by mail74-tx2 (MessageSwitch) id 1376494489300878_23937; Wed, 14 Aug 2013 15:34:49 +0000 (UTC) Received: from TX2EHSMHS014.bigfish.com (unknown [10.9.14.233]) by mail74-tx2.bigfish.com (Postfix) with ESMTP id B2625100041; Wed, 14 Aug 2013 15:34:48 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS014.bigfish.com (10.9.99.114) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 14 Aug 2013 15:34:43 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.347.3; Wed, 14 Aug 2013 15:34:43 +0000 Received: from BY2PR05MB046.namprd05.prod.outlook.com (10.242.34.144) by BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) with Microsoft SMTP Server (TLS) id 15.0.731.12; Wed, 14 Aug 2013 15:34:40 +0000 Received: from BY2PR05MB046.namprd05.prod.outlook.com ([169.254.10.135]) by BY2PR05MB046.namprd05.prod.outlook.com ([169.254.10.208]) with mapi id 15.00.0731.000; Wed, 14 Aug 2013 15:34:40 +0000 From: Yimin Shen To: Ross Callon , "mpls@ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Thread-Topic: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 Thread-Index: AQHOgkXk/5e12m2TNkeFcdzsBEiRqZmU87UA Date: Wed, 14 Aug 2013 15:34:40 +0000 Message-ID: <8ecd1024ec854c0c9e7d459da7257d12@BY2PR05MB046.namprd05.prod.outlook.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C76D83@CH1PRD0510MB355.namprd05.prod.outlook.com> <62CCD4C52ACDAD4481149BD5D8A72FD316D6D7D6@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316D6D7D6@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0938781D02 Content-Type: multipart/alternative; boundary="_000_8ecd1024ec854c0c9e7d459da7257d12BY2PR05MB046namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 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, 14 Aug 2013 15:34:59 -0000 --_000_8ecd1024ec854c0c9e7d459da7257d12BY2PR05MB046namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've read this draft. I believe that it is useful, it specifies a graceful = solution, and it's ready for publication. Thanks, -Yimin Shen From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Tuesday, July 16, 2013 1:00 PM To: mpls@ietf.org; draft-ietf-mpls-special-purpose-labels@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels= -03 Working Group, This is to start Working Group last call on draft-ietf-mpls-special-purpos= e-labels-03 Please send your comments to the mpls working group mailing list (mpls@ietf= .org). Please send both technical comments, and (if you are happy with the documen= t as is) also send indications of support. There are no IPR claims against this draft. The co-authors have earlier sta= ted that they are not aware of any IPR applicable to this draft. If anyone else in the working group is aware of IPRs claims against this draft, the time to disclose that is now. Due to the upcoming IETF meeting in Berlin, this last call will be extended= by an extra week (which implies that the last call will be ongoing during the IETF meeting).= This working group last call will end on August 6, 2013. Ross for the wg co-chairs --_000_8ecd1024ec854c0c9e7d459da7257d12BY2PR05MB046namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve read this draf= t. I believe that it is useful, it specifies a graceful solution, and it= 217;s ready for publication.

 <= /p>

Thanks,=

 <= /p>

-Yimin Shen

 <= /p>

 <= /p>

From: mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Tuesday, July 16, 2013 1:00 PM
To: mpls@ietf.org; draft-ietf-mpls-special-purpose-labels@tools.ietf= .org
Cc: mpls-chairs@tools.ietf.org
Subject: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose= -labels-03

 

Working Group,

 

This = is to start Working Group last call on  draft-ietf-mpls-special-purpose-labels-03

 

Please send your comments to the mpls w= orking group mailing list (mpls@ietf.org).

 

Please send both technical comments, an= d (if you are happy with the document as is)

also send indications of support.

 

There are no IPR claims against this dr= aft. The co-authors have earlier stated that they

are not aware of any IPR applicable to this draft.

 

If anyone else in the working group is aware of IPRs claims against

this draft, the time to disclose that i= s now.

 

Due to the upcoming IETF meeting in Ber= lin, this last call will be extended by an extra week

(which implies that the last call will = be ongoing during the IETF meeting). This working group

last call will end on August 6, 2013.

 

Ross

for the wg co-chairs<= /p>

 <= /p>

--_000_8ecd1024ec854c0c9e7d459da7257d12BY2PR05MB046namprd05pro_-- From cpignata@cisco.com Wed Aug 14 09:25:52 2013 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 906F311E8176 for ; Wed, 14 Aug 2013 09:25:51 -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 KXSf7IHtBqWi for ; Wed, 14 Aug 2013 09:25:39 -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 86D8F21F9BDB for ; Wed, 14 Aug 2013 09:25:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5435; q=dns/txt; s=iport; t=1376497537; x=1377707137; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jCgb8TY1BHL4BSrGCiZ22bT0TLTl6xlqsZNpfiDmmY0=; b=S9FZDAnEOgY0kDKqEYqMcwMbrQbQnP9L/GaF+cIDrhvJuWCToWXibgbE NjpstIAstwSfbof1AOXzK5mCT1AZLnwrb0xuJjKCVf39bahfJQPM1eP+K Pr5aiHhR/YDZG04e6kUGRhBiNKjYBthml4zK1Vcpkzf+yn0xx3eM41VAl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFADiuC1KtJXHA/2dsb2JhbABbgwY1UL5lgSQWdIIkAQEBAwEBAQFoAwsFCQICAQgYCh0HGwwLFBEBAQQOBQgBiAEGDLkkBI5/gRoCMQeDG3cDiHWgQYMbgXE5 X-IronPort-AV: E=Sophos;i="4.89,878,1367971200"; d="scan'208";a="247274729" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 14 Aug 2013 16:25:36 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7EGPZVM001466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Aug 2013 16:25:35 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 14 Aug 2013 11:25:35 -0500 From: "Carlos Pignataro (cpignata)" To: Loa Andersson Thread-Topic: [mpls] Poll for Adoption draft-andersson-mpls-moving-iana-registries-00 Thread-Index: Ac6YUkBh7zV9g+sGRCSLJd3RtsoDnwAcRPgAAAdpqoAAFPV2AA== Date: Wed, 14 Aug 2013 16:25:35 +0000 Message-ID: <95067C434CE250468B77282634C96ED322E05236@xmb-aln-x02.cisco.com> References: <5efa5403aab843bdbcc382a8143640ee@BLUPR05MB070.namprd05.prod.outlook.com> <95067C434CE250468B77282634C96ED322DFE5CE@xmb-aln-x02.cisco.com> <520B22D9.5060400@pi.nu> In-Reply-To: <520B22D9.5060400@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.50] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <420ECDBE7079834ABB0231A54CF4A216@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "loa@mail01.huawei.com" Subject: Re: [mpls] Poll for Adoption draft-andersson-mpls-moving-iana-registries-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, 14 Aug 2013 16:25:52 -0000 Hi, Loa, Please see inline. On Aug 14, 2013, at 2:25 AM, Loa Andersson wrote: > Carlos, >=20 > While I tend to agree that someone (hint) should write-up a document > fixing the G-ACh registries, that is not the purpose of the current > documents. It is looking to clean up the LSP Ping registries. >=20 The title of the current document is "Moving Generic Associated Channel reg= istries to a new name space". This in itself sets up a broader goal than tossing namespaces outside LSP P= ing registry over the wall. > We have tried the approach "fixing everything" and failed to get our > heads around it, decided to take a stepwise approach. If we now stumble > on the first step (or rather second, since cleaning up the LSP registy > structure was the first) I'm afraid that nothing will be done. >=20 I wouldn't say "fix everything", but I would say "fix consistently" or "fix= atomically". I do understand now that your goal is to clean up the LSP Pin= g registry. However, since you are "Moving Generic Associated Channel regis= tries to a new name space", "fix modularly" can mean coalesce all the GACH = registries, from LSP Ping as well as from the other 2-3 registries. In othe= r words, fix two (LSP Ping and GACH) with potentially very small additional= incremental effort. > Since you say (below) "solves a small part" I hope we can do this and > go ahead and do the rest as soon as we have the cycles. >=20 My humble view is that just moving these four falls short of meaningful cha= nge.=20 This is just a datapoint, my opinion, and I was too optimistic with "solves= a small part". I tried to present a proposal along with my comments that, to me, has more = return on cycles: coalesce the G-ACH registries, currently in LSP Ping, PWE= 3, and MPLS OAM. Since you gave me a "hint" above, I'd be happy to help out= with this if the WG consensus is that the work makes sense. Thanks, -- Carlos. > /Loa >=20 > On 2013-08-14 04:53, Carlos Pignataro (cpignata) wrote: >> I believe that fixing and organizing misplaced number registrations is >> useful and worthwhile as it prevents future confusion, and typically >> welcome clean-ups. >>=20 >> However, I do not support adoption >> of draft-andersson-mpls-moving-iana-registries-00 in its current form. >>=20 >> The document solves a small part of the potential source of confusion, >> and, to me, it should fix all potential inconsistencies or leave things >> as-is. >>=20 >> Specifically: >>=20 >> * draft-andersson-mpls-moving-iana-registries proposes only to move >> four namespaces currently in [1] from [RFC6374] into a new heading >> (registry). >>=20 >>=20 >> However, there's still the following potential inconsistencies, with all >> these protocol elements from the G-ACH in different places: >>=20 >> * The G-ACH Channel Types namespace, although now it's a superset of >> the original PW-ACH, is still titled "Pseudowire Associated Channel >> Types" and is hosted in the pwe3-parameters registry. [2] >> * Other G-ACH namespaces and assignments from [RFC6427] >> and [RFC6378] reside in their own mpls-oam-parameters page [3] >> * G-ACh Advertisement Protocol namespaces are in the pwe3-parameters >> registry [4] [5] [6], although these are not PWE3. >> * CC/CV MEP-ID TLV namespace with pwe3-parameters [7] >>=20 >>=20 >> I would suggest that either things are left as they are, or all these >> G-ACH/PW-ACH namespaces are moved under a main "Generic Associated >> Channel (G-ACH)" registry *if* there's consensus for the clean-up. >>=20 >> Thanks, >>=20 >> -- Carlos. >>=20 >> [1] >> http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-p= arameters.xml#measurement-timestamp >> [2] >> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#p= we3-parameters-11 >> [3] >> https://www.iana.org/assignments/mpls-oam-parameters/mpls-oam-parameters= .xhtml >> [4] >> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#g= ach-application >> [5] >> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#g= ach-tlv >> [6] >> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#g= ach-ethernet >> [7] >> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#c= c-cv-mep-id >>=20 >>=20 >> On Aug 13, 2013, at 2:23 PM, Ross Callon > > wrote: >>=20 >>> This is to start a "two week" poll on adopting >>> draft-andersson-mpls-moving-iana-registries-00 >>> as an MPLS working group document. >>> Please send your comments (support/not support) to the mpls working >>> group mailing list (mpls@ietf.org ). >>> This poll will end August 28, 2013. >>> Thanks, Ross >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>=20 >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >=20 > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Wed Aug 14 09:37:55 2013 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 E3F8511E81F0 for ; Wed, 14 Aug 2013 09:37:55 -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 y4RduAOS6Uiv for ; Wed, 14 Aug 2013 09:37:51 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3353311E818E for ; Wed, 14 Aug 2013 09:37:51 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 21A6F1802038; Wed, 14 Aug 2013 18:37:50 +0200 (CEST) Message-ID: <520BB261.7030809@pi.nu> Date: Wed, 14 Aug 2013 18:37:53 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" References: <5efa5403aab843bdbcc382a8143640ee@BLUPR05MB070.namprd05.prod.outlook.com> <95067C434CE250468B77282634C96ED322DFE5CE@xmb-aln-x02.cisco.com> <520B22D9.5060400@pi.nu> <95067C434CE250468B77282634C96ED322E05236@xmb-aln-x02.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED322E05236@xmb-aln-x02.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "loa@mail01.huawei.com" Subject: Re: [mpls] Poll for Adoption draft-andersson-mpls-moving-iana-registries-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, 14 Aug 2013 16:37:56 -0000 Carlos, as long as we move them out of the LSP Ping registry and we can find a place where we have consensus that we should move them, I fine with that. Any suggestions? /Loa On 2013-08-14 18:25, Carlos Pignataro (cpignata) wrote: > Hi, Loa, > > Please see inline. > > On Aug 14, 2013, at 2:25 AM, Loa Andersson wrote: > >> Carlos, >> >> While I tend to agree that someone (hint) should write-up a document >> fixing the G-ACh registries, that is not the purpose of the current >> documents. It is looking to clean up the LSP Ping registries. >> > > The title of the current document is "Moving Generic Associated Channel registries to a new name space". > > This in itself sets up a broader goal than tossing namespaces outside LSP Ping registry over the wall. > >> We have tried the approach "fixing everything" and failed to get our >> heads around it, decided to take a stepwise approach. If we now stumble >> on the first step (or rather second, since cleaning up the LSP registy >> structure was the first) I'm afraid that nothing will be done. >> > > I wouldn't say "fix everything", but I would say "fix consistently" or "fix atomically". I do understand now that your goal is to clean up the LSP Ping registry. However, since you are "Moving Generic Associated Channel registries to a new name space", "fix modularly" can mean coalesce all the GACH registries, from LSP Ping as well as from the other 2-3 registries. In other words, fix two (LSP Ping and GACH) with potentially very small additional incremental effort. > >> Since you say (below) "solves a small part" I hope we can do this and >> go ahead and do the rest as soon as we have the cycles. >> > > My humble view is that just moving these four falls short of meaningful change. > > This is just a datapoint, my opinion, and I was too optimistic with "solves a small part". > > I tried to present a proposal along with my comments that, to me, has more return on cycles: coalesce the G-ACH registries, currently in LSP Ping, PWE3, and MPLS OAM. Since you gave me a "hint" above, I'd be happy to help out with this if the WG consensus is that the work makes sense. > > Thanks, > > -- Carlos. > > >> /Loa >> >> On 2013-08-14 04:53, Carlos Pignataro (cpignata) wrote: >>> I believe that fixing and organizing misplaced number registrations is >>> useful and worthwhile as it prevents future confusion, and typically >>> welcome clean-ups. >>> >>> However, I do not support adoption >>> of draft-andersson-mpls-moving-iana-registries-00 in its current form. >>> >>> The document solves a small part of the potential source of confusion, >>> and, to me, it should fix all potential inconsistencies or leave things >>> as-is. >>> >>> Specifically: >>> >>> * draft-andersson-mpls-moving-iana-registries proposes only to move >>> four namespaces currently in [1] from [RFC6374] into a new heading >>> (registry). >>> >>> >>> However, there's still the following potential inconsistencies, with all >>> these protocol elements from the G-ACH in different places: >>> >>> * The G-ACH Channel Types namespace, although now it's a superset of >>> the original PW-ACH, is still titled "Pseudowire Associated Channel >>> Types" and is hosted in the pwe3-parameters registry. [2] >>> * Other G-ACH namespaces and assignments from [RFC6427] >>> and [RFC6378] reside in their own mpls-oam-parameters page [3] >>> * G-ACh Advertisement Protocol namespaces are in the pwe3-parameters >>> registry [4] [5] [6], although these are not PWE3. >>> * CC/CV MEP-ID TLV namespace with pwe3-parameters [7] >>> >>> >>> I would suggest that either things are left as they are, or all these >>> G-ACH/PW-ACH namespaces are moved under a main "Generic Associated >>> Channel (G-ACH)" registry *if* there's consensus for the clean-up. >>> >>> Thanks, >>> >>> -- Carlos. >>> >>> [1] >>> http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml#measurement-timestamp >>> [2] >>> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#pwe3-parameters-11 >>> [3] >>> https://www.iana.org/assignments/mpls-oam-parameters/mpls-oam-parameters.xhtml >>> [4] >>> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gach-application >>> [5] >>> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gach-tlv >>> [6] >>> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gach-ethernet >>> [7] >>> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#cc-cv-mep-id >>> >>> >>> On Aug 13, 2013, at 2:23 PM, Ross Callon >> > wrote: >>> >>>> This is to start a "two week" poll on adopting >>>> draft-andersson-mpls-moving-iana-registries-00 >>>> as an MPLS working group document. >>>> Please send your comments (support/not support) to the mpls working >>>> group mailing list (mpls@ietf.org ). >>>> This poll will end August 28, 2013. >>>> Thanks, Ross >>>> _______________________________________________ >>>> 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 >>> >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From cpignata@cisco.com Wed Aug 14 09:59:12 2013 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 D6D4A11E8138 for ; Wed, 14 Aug 2013 09:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Dizvz-pe5yGw for ; Wed, 14 Aug 2013 09:59:08 -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 EF2CD11E80AD for ; Wed, 14 Aug 2013 09:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17942; q=dns/txt; s=iport; t=1376499548; x=1377709148; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wwyZqxPYYK6NfN/agi/ujB8u1AvFpJwg79IzPB8Akec=; b=Agt18Pn66H8XXJOQ+mTi9zERz7cDVCswhi3dUwfxM5MBiBFyDGg1we0Z IzMbVDrQVSk0RFKf8htFOco+5A4BkUbnJtbZPojQKTtIAx+2EOeqxrQxc Rxek75pvdR5lWJx44Q4VE06zMZz0D4wWua5urZllz9+Vgb/rO79NaZTKt Q=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFALG2C1KtJXG9/2dsb2JhbABbgwY1UL5lgSQWdIIkAQEBAwEBAQFoAwsFCQICAQgYCh0HGwwLFBECBA4FCAEFh3wGDLkRBI5/gRwFLAeDG3cDkBaBLpdygxuBcTk X-IronPort-AV: E=Sophos;i="4.89,878,1367971200"; d="asc'?scan'208,217";a="247108771" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 14 Aug 2013 16:59:00 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7EGx02j032639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Aug 2013 16:59:00 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Wed, 14 Aug 2013 11:59:00 -0500 From: "Carlos Pignataro (cpignata)" To: Loa Andersson Thread-Topic: [mpls] Poll for Adoption draft-andersson-mpls-moving-iana-registries-00 Thread-Index: AQHOmQygexQei+QGC0qqnPis7dL7Z5mVQN0A Date: Wed, 14 Aug 2013 16:59:00 +0000 Message-ID: <95067C434CE250468B77282634C96ED322E05628@xmb-aln-x02.cisco.com> References: <5efa5403aab843bdbcc382a8143640ee@BLUPR05MB070.namprd05.prod.outlook.com> <95067C434CE250468B77282634C96ED322DFE5CE@xmb-aln-x02.cisco.com> <520B22D9.5060400@pi.nu> <95067C434CE250468B77282634C96ED322E05236@xmb-aln-x02.cisco.com> <520BB261.7030809@pi.nu> In-Reply-To: <520BB261.7030809@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.50] Content-Type: multipart/signed; boundary="Apple-Mail=_92269965-B544-418D-A6E6-AA00877B2D80"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "loa@mail01.huawei.com" Subject: Re: [mpls] Poll for Adoption draft-andersson-mpls-moving-iana-registries-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, 14 Aug 2013 16:59:13 -0000 --Apple-Mail=_92269965-B544-418D-A6E6-AA00877B2D80 Content-Type: multipart/alternative; boundary="Apple-Mail=_2A8E909B-805D-418C-90E8-E70B1E981C8D" --Apple-Mail=_2A8E909B-805D-418C-90E8-E70B1E981C8D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Loa, Yes, what I already suggested: get all the mpls-gach allocations = together in a new registry (from mpls-lsp-ping-parameters, = pwe3-parameters, and mpls-oam-parameters, into a new one). Basically you have hierarchical allocations, that should be together: = there are registries created for many individual values of G-ACH Type = ("Pseudowire Associated Channel Type"). They should follow. If you are moving 4 registries from mpls-lsp-ping-parameters, where do = you propose they'd end up? BTW: These are the full G-ACH numbers for GACH: Pseudowire Associated Channel Types Associated Channel Header TLV Registry // empty to be removed MPLS Fault OAM Message Type Registry MPLS Fault OAM Flag Registry MPLS Fault OAM TLV Registry MPLS PSC Request Registry MPLS PSC TLV Registry G-ACh Advertisement Protocol Application Registry G-ACh Advertisement Protocol TLV Registry G-ACh Advertisement Protocol: Ethernet Interface Parameters CC/CV MEP-ID TLV Registry Measurement Timestamp Type Loss/Delay Measurement Control Code: Query Codes Loss/Delay Measurement Control Code: Response Codes MPLS Loss/Delay Measurement TLV Object Thanks, -- Carlos. On Aug 14, 2013, at 12:37 PM, Loa Andersson wrote: > Carlos, >=20 > as long as we move them out of the LSP Ping registry and we can find a > place where we have consensus that we should move them, I fine with > that. >=20 > Any suggestions? >=20 > /Loa >=20 > On 2013-08-14 18:25, Carlos Pignataro (cpignata) wrote: >> Hi, Loa, >>=20 >> Please see inline. >>=20 >> On Aug 14, 2013, at 2:25 AM, Loa Andersson wrote: >>=20 >>> Carlos, >>>=20 >>> While I tend to agree that someone (hint) should write-up a document >>> fixing the G-ACh registries, that is not the purpose of the current >>> documents. It is looking to clean up the LSP Ping registries. >>>=20 >>=20 >> The title of the current document is "Moving Generic Associated = Channel registries to a new name space". >>=20 >> This in itself sets up a broader goal than tossing namespaces outside = LSP Ping registry over the wall. >>=20 >>> We have tried the approach "fixing everything" and failed to get our >>> heads around it, decided to take a stepwise approach. If we now = stumble >>> on the first step (or rather second, since cleaning up the LSP = registy >>> structure was the first) I'm afraid that nothing will be done. >>>=20 >>=20 >> I wouldn't say "fix everything", but I would say "fix consistently" = or "fix atomically". I do understand now that your goal is to clean up = the LSP Ping registry. However, since you are "Moving Generic Associated = Channel registries to a new name space", "fix modularly" can mean = coalesce all the GACH registries, from LSP Ping as well as from the = other 2-3 registries. In other words, fix two (LSP Ping and GACH) with = potentially very small additional incremental effort. >>=20 >>> Since you say (below) "solves a small part" I hope we can do this = and >>> go ahead and do the rest as soon as we have the cycles. >>>=20 >>=20 >> My humble view is that just moving these four falls short of = meaningful change. >>=20 >> This is just a datapoint, my opinion, and I was too optimistic with = "solves a small part". >>=20 >> I tried to present a proposal along with my comments that, to me, has = more return on cycles: coalesce the G-ACH registries, currently in LSP = Ping, PWE3, and MPLS OAM. Since you gave me a "hint" above, I'd be happy = to help out with this if the WG consensus is that the work makes sense. >>=20 >> Thanks, >>=20 >> -- Carlos. >>=20 >>=20 >>> /Loa >>>=20 >>> On 2013-08-14 04:53, Carlos Pignataro (cpignata) wrote: >>>> I believe that fixing and organizing misplaced number registrations = is >>>> useful and worthwhile as it prevents future confusion, and = typically >>>> welcome clean-ups. >>>>=20 >>>> However, I do not support adoption >>>> of draft-andersson-mpls-moving-iana-registries-00 in its current = form. >>>>=20 >>>> The document solves a small part of the potential source of = confusion, >>>> and, to me, it should fix all potential inconsistencies or leave = things >>>> as-is. >>>>=20 >>>> Specifically: >>>>=20 >>>> * draft-andersson-mpls-moving-iana-registries proposes only to = move >>>> four namespaces currently in [1] from [RFC6374] into a new = heading >>>> (registry). >>>>=20 >>>>=20 >>>> However, there's still the following potential inconsistencies, = with all >>>> these protocol elements from the G-ACH in different places: >>>>=20 >>>> * The G-ACH Channel Types namespace, although now it's a superset = of >>>> the original PW-ACH, is still titled "Pseudowire Associated = Channel >>>> Types" and is hosted in the pwe3-parameters registry. [2] >>>> * Other G-ACH namespaces and assignments from [RFC6427] >>>> and [RFC6378] reside in their own mpls-oam-parameters page [3] >>>> * G-ACh Advertisement Protocol namespaces are in the = pwe3-parameters >>>> registry [4] [5] [6], although these are not PWE3. >>>> * CC/CV MEP-ID TLV namespace with pwe3-parameters [7] >>>>=20 >>>>=20 >>>> I would suggest that either things are left as they are, or all = these >>>> G-ACH/PW-ACH namespaces are moved under a main "Generic Associated >>>> Channel (G-ACH)" registry *if* there's consensus for the clean-up. >>>>=20 >>>> Thanks, >>>>=20 >>>> -- Carlos. >>>>=20 >>>> [1] >>>> = http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-par= ameters.xml#measurement-timestamp >>>> [2] >>>> = https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#pwe= 3-parameters-11 >>>> [3] >>>> = https://www.iana.org/assignments/mpls-oam-parameters/mpls-oam-parameters.x= html >>>> [4] >>>> = https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gac= h-application >>>> [5] >>>> = https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gac= h-tlv >>>> [6] >>>> = https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gac= h-ethernet >>>> [7] >>>> = https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#cc-= cv-mep-id >>>>=20 >>>>=20 >>>> On Aug 13, 2013, at 2:23 PM, Ross Callon >>> > wrote: >>>>=20 >>>>> This is to start a "two week" poll on adopting >>>>> draft-andersson-mpls-moving-iana-registries-00 >>>>> as an MPLS working group document. >>>>> Please send your comments (support/not support) to the mpls = working >>>>> group mailing list (mpls@ietf.org ). >>>>> This poll will end August 28, 2013. >>>>> Thanks, Ross >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>>>=20 >>>=20 >>> -- >>>=20 >>>=20 >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>=20 >=20 > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 --Apple-Mail=_2A8E909B-805D-418C-90E8-E70B1E981C8D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

If you are moving 4 = registries from mpls-lsp-ping-parameters, where do you propose = they'd end up?

BTW: These are the full G-ACH = numbers for GACH:
  • Pseudowire Associated Channel = Types
  • Associated Channel Header TLV Registry // empty to be = removed
    • MPLS Fault OAM Message Type Registry
    • MPLS = Fault OAM Flag Registry
    • MPLS Fault OAM TLV Registry
    • MPLS = PSC Request Registry
    • MPLS PSC TLV Registry
    • G-ACh = Advertisement Protocol Application Registry
    • G-ACh Advertisement = Protocol TLV Registry
    • G-ACh Advertisement Protocol: Ethernet = Interface Parameters
    • CC/CV MEP-ID TLV = Registry
    • Measurement Timestamp Type
    • Loss/Delay = Measurement Control Code: Query Codes
    • Loss/Delay Measurement = Control Code: Response Codes
    • MPLS Loss/Delay Measurement = TLV Object
Thanks,

-- = Carlos.

On Aug 14, 2013, at 12:37 PM, Loa = Andersson <loa@pi.nu>
 wrote:
Carlos,

as long as we move them out of the LSP Ping = registry and we can find a
place where we have consensus that we = should move them, I fine with
that.

Any = suggestions?

/Loa

On 2013-08-14 18:25, Carlos Pignataro = (cpignata) wrote:
Hi, Loa,

Please = see inline.

On Aug 14, 2013, at 2:25 AM, Loa Andersson <loa@pi.nu> wrote:

Carlos,

While I tend to agree that someone (hint) = should write-up a document
fixing the G-ACh registries, that is not = the purpose of the current
documents. It is looking to clean up the = LSP Ping registries.


The title of the current = document is "Moving Generic Associated Channel registries to a new name = space".

This in itself sets up a broader goal than tossing = namespaces outside LSP Ping registry over the wall.

We have tried the approach "fixing everything" and failed = to get our
heads around it, decided to take a stepwise approach. If = we now stumble
on the first step (or rather second, since cleaning up = the LSP registy
structure was the first) I'm afraid that nothing will = be done.


I wouldn't say "fix everything", but I = would say "fix consistently" or "fix atomically". I do understand now = that your goal is to clean up the LSP Ping registry. However, since you = are "Moving Generic Associated Channel registries to a new name space", = "fix modularly" can mean coalesce all the GACH registries, from LSP Ping = as well as from the other 2-3 registries. In other words, fix two (LSP = Ping and GACH) with potentially very small additional incremental = effort.

Since you say (below) "solves a = small part" I hope we can do this and
go ahead and do the rest as = soon as we have the cycles.


My humble view is = that just moving these four falls short of meaningful = change.

This is just a datapoint, my opinion, and I was too = optimistic with "solves a small part".

I tried to present a = proposal along with my comments that, to me, has more return on cycles: = coalesce the G-ACH registries, currently in LSP Ping, PWE3, and MPLS = OAM. Since you gave me a "hint" above, I'd be happy to help out with = this if the WG consensus is that the work makes = sense.

Thanks,

-- Carlos.


/Loa

On 2013-08-14 04:53, Carlos Pignataro = (cpignata) wrote:
I believe that fixing and = organizing misplaced number registrations is
useful and worthwhile as = it prevents future confusion, and typically
welcome = clean-ups.

However, I do not support adoption
of = draft-andersson-mpls-moving-iana-registries-00 in its current = form.

The document solves a small part of the potential source of = confusion,
and, to me, it should fix all potential inconsistencies or = leave things
as-is.

Specifically:

 * = draft-andersson-mpls-moving-iana-registries proposes only to move
=    four namespaces currently in [1] from [RFC6374] into a = new heading
   (registry).


However, = there's still the following potential inconsistencies, with all
these = protocol elements from the G-ACH in different places:

 * = The G-ACH Channel Types namespace, although now it's a superset of
=    the original PW-ACH, is still titled "Pseudowire = Associated Channel
   Types" and is hosted in the = pwe3-parameters registry. [2]
 * Other G-ACH namespaces and = assignments from [RFC6427]
   and [RFC6378] reside in = their own mpls-oam-parameters page [3]
 * G-ACh Advertisement = Protocol namespaces are in the pwe3-parameters
=    registry [4] [5] [6], although these are not PWE3.
=  * CC/CV MEP-ID TLV namespace with pwe3-parameters [7]


I = would suggest that either things are left as they are, or all = these
G-ACH/PW-ACH namespaces are moved under a main "Generic = Associated
Channel (G-ACH)" registry *if* there's consensus for the = clean-up.

Thanks,

-- Carlos.

[1]
http://www.iana.org/assignments= /mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml#measurement-timesta= mp
[2]
https://www.iana.org/assignments/pwe3-parameters/pwe3-par= ameters.xhtml#pwe3-parameters-11
[3]
https://www.iana.org/assignment= s/mpls-oam-parameters/mpls-oam-parameters.xhtml
[4]
https://www.iana= .org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gach-application[5]
https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.x= html#gach-tlv
[6]
https://www.iana.org/assignments/pwe3-parameters/p= we3-parameters.xhtml#gach-ethernet
[7]
https://www.iana.org/assignme= nts/pwe3-parameters/pwe3-parameters.xhtml#cc-cv-mep-id


On Aug = 13, 2013, at 2:23 PM, Ross Callon = <rcallon@juniper.net
<mailto:rcallon@juniper.net>> = wrote:

This is to start a "two week" = poll on adopting
draft-andersson-mpls-moving-iana-registries-00
as = an MPLS working group document.
Please send your comments = (support/not support) to the mpls working
group mailing list = (mpls@ietf.org <mailto:mpls@ietf.org>).
This poll will end = August 28, 2013.
Thanks, = Ross
_______________________________________________
mpls mailing = list
mpls@ietf.org = <mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls=



_____________________________________________= __
mpls mailing = list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

--


Loa Andersson =             &n= bsp;          email: = loa@mail01.huawei.com
Senior = MPLS Expert =             &n= bsp;           &nbs= p;loa@pi.nu
Huawei Technologies = (consultant)     phone: +46 739 81 21 = 64


--


Loa Andersson =             &n= bsp;          email: = loa@mail01.huawei.com
Senior = MPLS Expert =             &n= bsp;           &nbs= p;loa@pi.nu
Huawei Technologies = (consultant)     phone: +46 739 81 21 = 64

= --Apple-Mail=_2A8E909B-805D-418C-90E8-E70B1E981C8D-- --Apple-Mail=_92269965-B544-418D-A6E6-AA00877B2D80 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlILt1UACgkQtfDPGTp3USwbYQCfQqPHSXBVoS+O9TNdFeGc+xLE JesAn0tjSpQjUC7Tr5kJuGF9Gdnpvj4J =vfyL -----END PGP SIGNATURE----- --Apple-Mail=_92269965-B544-418D-A6E6-AA00877B2D80-- From nobo@cisco.com Wed Aug 14 15:10:23 2013 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 F2EF421F94FD for ; Wed, 14 Aug 2013 15:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFxwxI47G0x7 for ; Wed, 14 Aug 2013 15:10:17 -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 B12E221F95A6 for ; Wed, 14 Aug 2013 15:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2268; q=dns/txt; s=iport; t=1376518216; x=1377727816; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=9XsxYvlv3WRN4OSAEjJ3rEnDsIbyTBeuNxJRGyCiSRU=; b=E0bGvP4v9sNmTIP4OdIAou89MIuYIwy/lb4tUDBHa69hYdrQP5SFe+m7 UdbkkTgyLfYZN6TI8cgkyR+rEn2hOeiCYUiGdgGKVvuE4uXmfFn323hDd CoDaCchExvoAWFJ3a5j09i6sYHhqsH5DogvoqwIrZS+97FWmRAbhF8l/S o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0GABj/C1KtJXG8/2dsb2JhbABbgmUhgQW/I4EgFm0HgiYBAQM6PxIBKhRCJgEEDg2ICAG5IpAfMYMidwOpNoMbgio X-IronPort-AV: E=Sophos;i="4.89,880,1367971200"; d="scan'208";a="247463356" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 14 Aug 2013 22:10:16 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7EMAGZh003715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Aug 2013 22:10:16 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Wed, 14 Aug 2013 17:10:15 -0500 From: "Nobo Akiya (nobo)" To: "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" Thread-Topic: Comments on draft-ietf-mpls-return-path-specified-lsp-ping-12.txt Thread-Index: Ac6ZIv/azjWY8ahbTN6wXwSKa+Cm7g== Date: Wed, 14 Aug 2013 22:09:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: [mpls] Comments on draft-ietf-mpls-return-path-specified-lsp-ping-12.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, 14 Aug 2013 22:10:23 -0000 Dear Authors, et al, Draft adds new reply mode (5 - Reply via Specified Path) which looks to pro= vide initiator great control on return path. Draft considers bidirectional = LSP, and allows specifying of reverse LSP in a new TLV, but ... for bidirec= tional LSP ping, having reply mode to indicate reverse LSP would appear to = take care of large majority of use, and there'll be no need to encode/decod= e additional TLV. Is there any reason why reply mode to specify reverse LSP= is not added? And reply path TLV allows for initiator to specify a particular return path= , but allows responder to choose different path if initiator specified one = cannot be accommodated. This aspect is very interesting. Reason being that = specifying of the "right" reply mode in echo request seems to be getting mo= re and more complicated these days. For example, bidirectional LSP with some transit nodes non-co-routed: - ping: * IP reply mode works * Reverse LSP reply mode works - ping with TTL terminating on mid: * IP reply mode works * Reverse LSP reply mode may or may not work - traceroute: * IP reply mode works * Reverse LSP reply mode may or may not work In above cases, what I would like to specify in most cases is to say "take = reverse LSP as return path if available, otherwise take IP return path". Ye= s reply path TLV allows this, but I'm thinking if this can be done in a sim= pler way. Reply mode 2: Reply via an IPv4/IPv6 UDP packet Reply mode 4: Reply via application level control channel Reply mode 6: Reply via reverse LSP (assume this exists) Let's say there existed: Reply mode 7: Reply via pre-defined preference When responder receives reply mode 7, then return path is chosen from pre-d= efined preference list (ex: control-channel > reverse LSP > IP). Reply mode= used can be encoded in the reply mode field of echo rely so initiator know= s which was used. I see the new TLV useful for specific scenarios, but I've been trying to se= e how things (implementations and operations) can be simplified for those n= on-specific (majority) of cases. Was something like above considered as par= t of this draft? Regards, Nobo From mach.chen@huawei.com Wed Aug 14 23:13:00 2013 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 1817E21E8114 for ; Wed, 14 Aug 2013 23:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 c1SuNIxpJ7YO for ; Wed, 14 Aug 2013 23:12:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 36EF911E80D3 for ; Wed, 14 Aug 2013 23:12:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AWA69634; Thu, 15 Aug 2013 06:12:52 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 15 Aug 2013 07:12:15 +0100 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 15 Aug 2013 07:12:47 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.128]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.007; Thu, 15 Aug 2013 14:12:43 +0800 From: Mach Chen To: "Nobo Akiya (nobo)" , "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" Thread-Topic: [mpls] Comments on draft-ietf-mpls-return-path-specified-lsp-ping-12.txt Thread-Index: Ac6ZIv/azjWY8ahbTN6wXwSKa+Cm7gAMC0Yw Date: Thu, 15 Aug 2013 06:12:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-ietf-mpls-return-path-specified-lsp-ping-12.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: Thu, 15 Aug 2013 06:13:00 -0000 Hi Nobo, Many thanks for your comments! Please see my reply inline... > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Nobo Akiya (nobo) > Sent: Thursday, August 15, 2013 6:10 AM > To: draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org > Cc: mpls@ietf.org > Subject: [mpls] Comments on > draft-ietf-mpls-return-path-specified-lsp-ping-12.txt >=20 >=20 > Dear Authors, et al, >=20 > Draft adds new reply mode (5 - Reply via Specified Path) which looks to p= rovide > initiator great control on return path. Draft considers bidirectional LSP= , and allows > specifying of reverse LSP in a new TLV, but ... for bidirectional LSP pin= g, having > reply mode to indicate reverse LSP would appear to take care of large maj= ority of > use, and there'll be no need to encode/decode additional TLV. Is there an= y > reason why reply mode to specify reverse LSP is not added? The draft uses the "reply mode 5 + B bit" to achieve this, using a reply mo= de to indicate the reverse LSP is an alternate way, we considered this and = it also works. The reason not using dedicated reply mode is that we don't w= ant to define too many reply modes, indicating reverse LSP is kind of speci= fying reply path and using the same reply mode seems reasonable.=20 >From the implementation point of view, IMHO, the two ways have not too much= differences, from the operation point of view, there should be no differen= ce.=20 >=20 > And reply path TLV allows for initiator to specify a particular return pa= th, but > allows responder to choose different path if initiator specified one cann= ot be > accommodated. This aspect is very interesting. Reason being that specifyi= ng of > the "right" reply mode in echo request seems to be getting more and more > complicated these days. >=20 > For example, bidirectional LSP with some transit nodes non-co-routed: > - ping: > * IP reply mode works > * Reverse LSP reply mode works > - ping with TTL terminating on mid: > * IP reply mode works > * Reverse LSP reply mode may or may not work > - traceroute: > * IP reply mode works > * Reverse LSP reply mode may or may not work >=20 > In above cases, what I would like to specify in most cases is to say "tak= e reverse > LSP as return path if available, otherwise take IP return path". Yes repl= y path TLV > allows this, but I'm thinking if this can be done in a simpler way. As you said, the reply path TLV allows this. In addition, to localize the f= ailure point, sometime it may need to specify an explicit reply path other = than the reverse path and IP return path, that is the main reason why we in= troduce the reply path TLV.=20 >=20 > Reply mode 2: Reply via an IPv4/IPv6 UDP packet > Reply mode 4: Reply via application level control channel > Reply mode 6: Reply via reverse LSP (assume this exists) >=20 > Let's say there existed: >=20 > Reply mode 7: Reply via pre-defined preference >=20 > When responder receives reply mode 7, then return path is chosen from > pre-defined preference list (ex: control-channel > reverse LSP > IP). Rep= ly mode > used can be encoded in the reply mode field of echo rely so initiator kno= ws which > was used. The difficulty is that the responder may not have the ability to judge whet= her the control-channel, reverse LSP and IP is workable or not. For example= , when it thinks that the control-channel is workable, it will always choos= e it but the control-channel may not workable (e.g., a failure in the middl= e of the channel) .=20 Best regards, Mach >=20 > I see the new TLV useful for specific scenarios, but I've been trying to = see how > things (implementations and operations) can be simplified for those non-s= pecific > (majority) of cases. Was something like above considered as part of this = draft? >=20 > Regards, > Nobo >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From huubatwork@gmail.com Thu Aug 15 00:59:46 2013 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 B85A921F9A19 for ; Thu, 15 Aug 2013 00:59:46 -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 Qlhl3BI2XS4X for ; Thu, 15 Aug 2013 00:59:46 -0700 (PDT) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id F066721F9A0C for ; Thu, 15 Aug 2013 00:59:45 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id b45so200966eek.15 for ; Thu, 15 Aug 2013 00:59:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=MRUBY4s0Gt0PF0YCIJ3wpzn7JH33nlsPmye9nid4GgA=; b=WGv0D1dRKRLbY4Tr548IUrYVtdLINAOVUm/Y3cxw5+C6DjGK8XoOoIDw++GfyaVzhh HKV81wVjgjQwWTHm83m+BLvrXu8kMza2V783XEfQK3EZPEdBvuitEp5wRTObbwyDAQKm +hEIF14sDHrEWVes7hGUrYbW4EHXW5+COQxih6tvxjw5FiPs1EtkTmO8i+0D52JtFrM2 3DI45xMkQnEiiJ3VenpENA0LP9Pk5xucKa3mncnydgVs0Sq1LRdVI1H7pdbcofUbUWng Q3w6jCXxntRweu0rMGCUFIyEhHXwscgDBX4qDwHvt1kkSvIldZbFcBBe/vQa4fWrILHr WLXQ== X-Received: by 10.14.251.10 with SMTP id a10mr465375ees.76.1376553584992; Thu, 15 Aug 2013 00:59:44 -0700 (PDT) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id bn13sm82232436eeb.11.2013.08.15.00.59.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Aug 2013 00:59:44 -0700 (PDT) Message-ID: <520C8A72.7010609@gmail.com> Date: Thu, 15 Aug 2013 09:59:46 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "t.petch" References: <62CCD4C52ACDAD4481149BD5D8A72FD316D78B3E@CH1PRD0510MB355.namprd05.prod.outlook.com> <520555DE.6090304@gmail.com> <014201ce981a$34692240$4001a8c0@gateway.2wire.net> In-Reply-To: <014201ce981a$34692240$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Ross Callon , mpls@ietf.org, draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org Subject: Re: [mpls] MPLS WG last call ondraft-ietf-mpls-tp-rosetta-stone-11.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: Thu, 15 Aug 2013 07:59:46 -0000 Hello Tom, Thanks for the nit picking (in the positive sense) in 3.9 PM == Performance Monitoring and indeed in 3.36 /service/server/ I will make sure these are included in the final document. Cheers, Huub. > ----- Original Message ----- > From: "Huub van Helvoort" > To: "Ross Callon" > Cc: ; ; > > Sent: Friday, August 09, 2013 9:49 PM > >> As the editor of this draft I support publication. >> >> Only one comment: I would like to acknowledge the contributions by >> Tom Petch to improve the quality of this draft. > > And I would like to acknowledge all the work that Huub has done to > produce a document worthy of publication. > > I wonder (!) about > > 3.9 First use of PM, worth expanding; I had assumed that Problem > Management is intended, but note that RFC6371, RFC5921 etc would say > that it is Performance Monitoring > > 3.36. Server layer: > A service layer is a layer network > /service/server/? > > Tom Petch > >> >> Cheers, Huub. >> >> >> ======= >>> Working Group, >>> >>> This is to start Working Group last call >>> ondraft-ietf-mpls-tp-rosetta-stone-11.txt >>> >>> Please send your comments to the mpls working groupmailing list >>> (mpls@ietf.org ). >>> >>> Please send both technical comments, and (if you are happywith the >>> document as is) >>> >>> also send indications of support. >>> >>> There are no IPR claims against this draft.The co-authors have > stated >>> that they are not >>> >>> awareof any IPR applicable to this draft.If anyone else in the > working >>> group is aware of >>> >>> IPRs claims againstthis draft, the time to disclose that is now. >>> >>> Due to the upcoming IETF meeting in Berlin, this last call will be >>> extended by an extra week >>> >>> (which implies that the last call will be ongoing during the IETF >>> meeting). This working group >>> >>> last call will end on August 14, 2013. >>> >>> Ross >>> >>> for the wg co-chairs >>>> > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- ***************************************************************** 请记ä½ï¼Œä½ æ˜¯ç‹¬ä¸€æ— äºŒçš„，就åƒå…¶ä»–æ¯ä¸€ä¸ªäººä¸€æ · From nobo@cisco.com Thu Aug 15 04:00:37 2013 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 9355F11E8146 for ; Thu, 15 Aug 2013 04:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbbtpGffoXTz for ; Thu, 15 Aug 2013 04:00:32 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0FB11E812C for ; Thu, 15 Aug 2013 04:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5843; q=dns/txt; s=iport; t=1376564432; x=1377774032; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5WZoWmLBsTXbF0tfad1iPLAjeT1FKnG+07bfi1BXwEk=; b=bB1owvakZkHDuoYC2aSgQbcowZ9RJv00UKZe/D7s2xhz/cREAmd+BXhj YXwJYOa0O6Flcpw5lCE5lFUj//3ts2kZM+dmnuyJ6cS5Hwi9iyiXRpYCt p+fSIMNbkQusR+YDYbEHTEsTUKuepb+xzeS/5o+wUj3H/peWJK37Vaewl I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8FAIO0DFKtJXHA/2dsb2JhbABbgmUhNVC/EIEhFnSCJAEBAQMBAQEBNzQLEAIBCCIUECcLJQIEAQ0FCBOHbwYBC7lmBJAfMQeDG3cDqTaDG4Iq X-IronPort-AV: E=Sophos;i="4.89,885,1367971200"; d="scan'208";a="247716717" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 15 Aug 2013 11:00:31 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7FB0V6L029671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Aug 2013 11:00:31 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 15 Aug 2013 06:00:31 -0500 From: "Nobo Akiya (nobo)" To: Mach Chen , "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" Thread-Topic: [mpls] Comments on draft-ietf-mpls-return-path-specified-lsp-ping-12.txt Thread-Index: AQHOmX6dautCD2CXyU+H2VRtLXBA/pmWBakQ Date: Thu, 15 Aug 2013 11:00:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-ietf-mpls-return-path-specified-lsp-ping-12.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: Thu, 15 Aug 2013 11:00:37 -0000 Hello Mach, Many thanks for quick response. Please see further comments inline. > > Dear Authors, et al, > > > > Draft adds new reply mode (5 - Reply via Specified Path) which looks > > to provide initiator great control on return path. Draft considers > > bidirectional LSP, and allows specifying of reverse LSP in a new TLV, > > but ... for bidirectional LSP ping, having reply mode to indicate > > reverse LSP would appear to take care of large majority of use, and > > there'll be no need to encode/decode additional TLV. Is there any reaso= n > why reply mode to specify reverse LSP is not added? >=20 > The draft uses the "reply mode 5 + B bit" to achieve this, using a reply = mode > to indicate the reverse LSP is an alternate way, we considered this and i= t > also works. The reason not using dedicated reply mode is that we don't > want to define too many reply modes, indicating reverse LSP is kind of > specifying reply path and using the same reply mode seems reasonable. We have 8 bits of reply mode, draft is proposing to take value 5/255. I don= 't think we are crunched to conserve numbers, and reasonable to add another= if it make sense. In this case, I think it make sense to add one for "reve= rse LSP". Regarding "we don't want to define too many reply modes", was tha= t WG rough consensus or was that consensus amongst authors of this draft? =20 >=20 > From the implementation point of view, IMHO, the two ways have not too > much differences, from the operation point of view, there should be no > difference. New value in 8 bit field is certainly much more easier to implement than (n= ew value in 8 bit field + new TLV + logic to handle new TLV). >=20 > > > > And reply path TLV allows for initiator to specify a particular return > > path, but allows responder to choose different path if initiator > > specified one cannot be accommodated. This aspect is very interesting. > > Reason being that specifying of the "right" reply mode in echo request > > seems to be getting more and more complicated these days. > > > > For example, bidirectional LSP with some transit nodes non-co-routed: > > - ping: > > * IP reply mode works > > * Reverse LSP reply mode works > > - ping with TTL terminating on mid: > > * IP reply mode works > > * Reverse LSP reply mode may or may not work > > - traceroute: > > * IP reply mode works > > * Reverse LSP reply mode may or may not work > > > > In above cases, what I would like to specify in most cases is to say > > "take reverse LSP as return path if available, otherwise take IP > > return path". Yes reply path TLV allows this, but I'm thinking if this = can be > done in a simpler way. >=20 > As you said, the reply path TLV allows this. In addition, to localize the= failure > point, sometime it may need to specify an explicit reply path other than = the > reverse path and IP return path, that is the main reason why we introduce > the reply path TLV. Yes, for specific use like fault isolation, I think path TLV adds value. It= can be another technique in addition to traceroute. For most ping/trace th= ough, path TLV really isn't necessary. I'd like to see things kept simple f= or most cases, but allow a mechanism for that tricky few percent of cases. >=20 > > > > Reply mode 2: Reply via an IPv4/IPv6 UDP packet Reply mode 4: Reply > > via application level control channel Reply mode 6: Reply via reverse > > LSP (assume this exists) > > > > Let's say there existed: > > > > Reply mode 7: Reply via pre-defined preference > > > > When responder receives reply mode 7, then return path is chosen from > > pre-defined preference list (ex: control-channel > reverse LSP > IP). > > Reply mode used can be encoded in the reply mode field of echo rely so > > initiator knows which was used. >=20 > The difficulty is that the responder may not have the ability to judge > whether the control-channel, reverse LSP and IP is workable or not. For > example, when it thinks that the control-channel is workable, it will alw= ays > choose it but the control-channel may not workable (e.g., a failure in th= e > middle of the channel) . Responder does not need to judge whether reverse "path" is workable or not,= responder just needs to judge whether reverse "path" is available for use,= and that's not difficult. Reverse LSP reply mode only make sense if something like "pre-defined prefe= rence" reply mode also exists ... since transit nodes or FRR path may not h= ave reverse LSP. But "default reply mode" selection by implementations or o= perators will be simplified if we had something like this. All this to say, can we discuss a simpler solution via adding couple of new= reply modes? :) I have another question. Draft mentions BFD. I understand the motive behind= wanting to control the reverse BFD path on uni-directional LSP. But I don'= t quite see the entire picture by making use of path TLV. Let's say we boot= strap BFD with LSP ping with path TLV with specific RSVP FEC, so that rever= se BFD packets are riding on specified RSVP FEC. That RSVP FEC can become i= nvalid at any time (ex: re-optimization takes place and LSP ID changes). Wh= at happens then? Regards, Nobo >=20 > Best regards, > Mach >=20 > > > > I see the new TLV useful for specific scenarios, but I've been trying > > to see how things (implementations and operations) can be simplified > > for those non-specific > > (majority) of cases. Was something like above considered as part of thi= s > draft? > > > > Regards, > > Nobo > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Thu Aug 15 04:33:14 2013 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 A686E21F9FE5 for ; Thu, 15 Aug 2013 04:33:14 -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 awkK5BPdn49q for ; Thu, 15 Aug 2013 04:33:10 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 81C0D21E804B for ; Thu, 15 Aug 2013 04:33:08 -0700 (PDT) Received: from [192.168.5.57] (81-229-83-119-no65.business.telia.com [81.229.83.119]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id EAF5C1802038; Thu, 15 Aug 2013 13:33:06 +0200 (CEST) Message-ID: <520CBC71.1050806@pi.nu> Date: Thu, 15 Aug 2013 13:33:05 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" References: <5efa5403aab843bdbcc382a8143640ee@BLUPR05MB070.namprd05.prod.outlook.com> <95067C434CE250468B77282634C96ED322DFE5CE@xmb-aln-x02.cisco.com> <520B22D9.5060400@pi.nu> <95067C434CE250468B77282634C96ED322E05236@xmb-aln-x02.cisco.com> <520BB261.7030809@pi.nu> <95067C434CE250468B77282634C96ED322E05628@xmb-aln-x02.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED322E05628@xmb-aln-x02.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "loa@mail01.huawei.com" Subject: Re: [mpls] Poll for Adoption draft-andersson-mpls-moving-iana-registries-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, 15 Aug 2013 11:33:14 -0000 Carlos, I'm not against the idea of moving all mpls-gach allocation registry. Since you ask where the GACh registries in the LSP Ping name space goes, the draft says: These registries are now moved into a new name space under the "Multiprotocol Label Switching Architecture" (MPLS) heading called "MPLS Generic Associated Channel Parameters". I wonder if we can agree on this strategy - go ahead with the current draft as it is, it simplicity makes if easy to move through wgls and iesg to create the new registry and move the existing GACh registries there. - as soon as we have that registry (or whenever the current draft is sufficiently well advanced) we start up a new draft proposing what you say below. One reason that I want this two step strategy is that there is much more of pwe3 registries (yes I know that registries are common) and that there are several RFCs that needs to be updated in the second step. That second draft should possibly also be a pwe3 wg document, so we should work with someone from the pwe3 wg. Is this a way forward? /Loa On 2013-08-14 18:59, Carlos Pignataro (cpignata) wrote: > Loa, > > Yes, what I already suggested: get all the mpls-gach allocations > together in a new registry (from > mpls-lsp-ping-parameters, pwe3-parameters, and mpls-oam-parameters, into > a new one). > > Basically you have hierarchical allocations, that should be together: > there are registries created for many individual values of G-ACH Type > ("Pseudowire Associated Channel Type"). They should follow. > > If you are moving 4 registries from mpls-lsp-ping-parameters, where do > you propose they'd end up? > > BTW: These are the full G-ACH numbers for GACH: > > * Pseudowire Associated Channel Types > * Associated Channel Header TLV Registry // empty to be removed > o MPLS Fault OAM Message Type Registry > o MPLS Fault OAM Flag Registry > o MPLS Fault OAM TLV Registry > o MPLS PSC Request Registry > o MPLS PSC TLV Registry > o G-ACh Advertisement Protocol Application Registry > o G-ACh Advertisement Protocol TLV Registry > o G-ACh Advertisement Protocol: Ethernet Interface Parameters > o CC/CV MEP-ID TLV Registry > o Measurement Timestamp Type > o Loss/Delay Measurement Control Code: Query Codes > o Loss/Delay Measurement Control Code: Response Codes > o MPLS Loss/Delay Measurement TLV Object > > Thanks, > > -- Carlos. > > On Aug 14, 2013, at 12:37 PM, Loa Andersson > > wrote: > >> Carlos, >> >> as long as we move them out of the LSP Ping registry and we can find a >> place where we have consensus that we should move them, I fine with >> that. >> >> Any suggestions? >> >> /Loa >> >> On 2013-08-14 18:25, Carlos Pignataro (cpignata) wrote: >>> Hi, Loa, >>> >>> Please see inline. >>> >>> On Aug 14, 2013, at 2:25 AM, Loa Andersson >> > wrote: >>> >>>> Carlos, >>>> >>>> While I tend to agree that someone (hint) should write-up a document >>>> fixing the G-ACh registries, that is not the purpose of the current >>>> documents. It is looking to clean up the LSP Ping registries. >>>> >>> >>> The title of the current document is "Moving Generic Associated >>> Channel registries to a new name space". >>> >>> This in itself sets up a broader goal than tossing namespaces outside >>> LSP Ping registry over the wall. >>> >>>> We have tried the approach "fixing everything" and failed to get our >>>> heads around it, decided to take a stepwise approach. If we now stumble >>>> on the first step (or rather second, since cleaning up the LSP registy >>>> structure was the first) I'm afraid that nothing will be done. >>>> >>> >>> I wouldn't say "fix everything", but I would say "fix consistently" >>> or "fix atomically". I do understand now that your goal is to clean >>> up the LSP Ping registry. However, since you are "Moving Generic >>> Associated Channel registries to a new name space", "fix modularly" >>> can mean coalesce all the GACH registries, from LSP Ping as well as >>> from the other 2-3 registries. In other words, fix two (LSP Ping and >>> GACH) with potentially very small additional incremental effort. >>> >>>> Since you say (below) "solves a small part" I hope we can do this and >>>> go ahead and do the rest as soon as we have the cycles. >>>> >>> >>> My humble view is that just moving these four falls short of >>> meaningful change. >>> >>> This is just a datapoint, my opinion, and I was too optimistic with >>> "solves a small part". >>> >>> I tried to present a proposal along with my comments that, to me, has >>> more return on cycles: coalesce the G-ACH registries, currently in >>> LSP Ping, PWE3, and MPLS OAM. Since you gave me a "hint" above, I'd >>> be happy to help out with this if the WG consensus is that the work >>> makes sense. >>> >>> Thanks, >>> >>> -- Carlos. >>> >>> >>>> /Loa >>>> >>>> On 2013-08-14 04:53, Carlos Pignataro (cpignata) wrote: >>>>> I believe that fixing and organizing misplaced number registrations is >>>>> useful and worthwhile as it prevents future confusion, and typically >>>>> welcome clean-ups. >>>>> >>>>> However, I do not support adoption >>>>> of draft-andersson-mpls-moving-iana-registries-00 in its current form. >>>>> >>>>> The document solves a small part of the potential source of confusion, >>>>> and, to me, it should fix all potential inconsistencies or leave things >>>>> as-is. >>>>> >>>>> Specifically: >>>>> >>>>> * draft-andersson-mpls-moving-iana-registries proposes only to move >>>>> four namespaces currently in [1] from [RFC6374] into a new heading >>>>> (registry). >>>>> >>>>> >>>>> However, there's still the following potential inconsistencies, >>>>> with all >>>>> these protocol elements from the G-ACH in different places: >>>>> >>>>> * The G-ACH Channel Types namespace, although now it's a superset of >>>>> the original PW-ACH, is still titled "Pseudowire Associated Channel >>>>> Types" and is hosted in the pwe3-parameters registry. [2] >>>>> * Other G-ACH namespaces and assignments from [RFC6427] >>>>> and [RFC6378] reside in their own mpls-oam-parameters page [3] >>>>> * G-ACh Advertisement Protocol namespaces are in the pwe3-parameters >>>>> registry [4] [5] [6], although these are not PWE3. >>>>> * CC/CV MEP-ID TLV namespace with pwe3-parameters [7] >>>>> >>>>> >>>>> I would suggest that either things are left as they are, or all these >>>>> G-ACH/PW-ACH namespaces are moved under a main "Generic Associated >>>>> Channel (G-ACH)" registry *if* there's consensus for the clean-up. >>>>> >>>>> Thanks, >>>>> >>>>> -- Carlos. >>>>> >>>>> [1] >>>>> http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml#measurement-timestamp >>>>> [2] >>>>> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#pwe3-parameters-11 >>>>> [3] >>>>> https://www.iana.org/assignments/mpls-oam-parameters/mpls-oam-parameters.xhtml >>>>> [4] >>>>> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gach-application >>>>> [5] >>>>> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gach-tlv >>>>> [6] >>>>> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gach-ethernet >>>>> [7] >>>>> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#cc-cv-mep-id >>>>> >>>>> >>>>> On Aug 13, 2013, at 2:23 PM, Ross Callon >>>> > wrote: >>>>> >>>>>> This is to start a "two week" poll on adopting >>>>>> draft-andersson-mpls-moving-iana-registries-00 >>>>>> as an MPLS working group document. >>>>>> Please send your comments (support/not support) to the mpls working >>>>>> group mailing list (mpls@ietf.org ). >>>>>> This poll will end August 28, 2013. >>>>>> Thanks, Ross >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> -- >>>> >>>> >>>> Loa Andersson email: loa@mail01.huawei.com >>>> >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>> >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From cpignata@cisco.com Thu Aug 15 05:08:01 2013 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 36B6B11E81A9 for ; Thu, 15 Aug 2013 05:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.101, 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 0BCLX9GtohiA for ; Thu, 15 Aug 2013 05:07:55 -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 0778F11E81A6 for ; Thu, 15 Aug 2013 05:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12119; q=dns/txt; s=iport; t=1376568474; x=1377778074; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bar35Pc/6c0uwQ9eDielNYiIVWmm3kj8djcwOpCtuEY=; b=eO/atAygINk3MRxbnfk0gwMXPMSDLmeCbiblFyQ4e9wI31RNeJl3rfPM BzmthyR3mp4Cz5O9sUju1/cTsa+JsaZJpvq0y2lv/PSk+KoRhEB6RTvwh p8CcICEgTwqJUrzc8wA+Y2jbRxlUfjHDEgCXRUAOoq0Nh1l9ee3uO+I9Q o=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8FALrDDFKtJXHA/2dsb2JhbABbgwY1UL8SgSEWdIIkAQEBAwEBAQFoAwsFCQICAQgSBgodBxsMCxQDDgIEDgUIAQWHfAYMuWMEjn+BHDEHgxt3A5AWgS6XcoMbgXE5 X-IronPort-AV: E=Sophos;i="4.89,885,1367971200"; d="asc'?scan'208";a="247621610" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 15 Aug 2013 12:07:48 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7FC7lsR030242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Aug 2013 12:07:47 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 15 Aug 2013 07:07:47 -0500 From: "Carlos Pignataro (cpignata)" To: Loa Andersson Thread-Topic: [mpls] Poll for Adoption draft-andersson-mpls-moving-iana-registries-00 Thread-Index: AQHOmQygexQei+QGC0qqnPis7dL7Z5mVQN0AgAE3RYCAAAmygA== Date: Thu, 15 Aug 2013 12:07:46 +0000 Message-ID: <95067C434CE250468B77282634C96ED322E09A82@xmb-aln-x02.cisco.com> References: <5efa5403aab843bdbcc382a8143640ee@BLUPR05MB070.namprd05.prod.outlook.com> <95067C434CE250468B77282634C96ED322DFE5CE@xmb-aln-x02.cisco.com> <520B22D9.5060400@pi.nu> <95067C434CE250468B77282634C96ED322E05236@xmb-aln-x02.cisco.com> <520BB261.7030809@pi.nu> <95067C434CE250468B77282634C96ED322E05628@xmb-aln-x02.cisco.com> <520CBC71.1050806@pi.nu> In-Reply-To: <520CBC71.1050806@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.50] Content-Type: multipart/signed; boundary="Apple-Mail=_638F0EF2-2958-445B-B58E-C0B1992D66ED"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "loa@mail01.huawei.com" Subject: Re: [mpls] Poll for Adoption draft-andersson-mpls-moving-iana-registries-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, 15 Aug 2013 12:08:01 -0000 --Apple-Mail=_638F0EF2-2958-445B-B58E-C0B1992D66ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Loa, Thanks for the response -- please see inline. On Aug 15, 2013, at 7:33 AM, Loa Andersson wrote: > Carlos, >=20 > I'm not against the idea of moving all mpls-gach allocation registry. >=20 > Since you ask where the GACh registries in the LSP Ping name space = goes, > the draft says: >=20 > These registries are now moved into a new name space under the > "Multiprotocol Label Switching Architecture" (MPLS) heading called > "MPLS Generic Associated Channel Parameters". >=20 Thanks. I read that but it was not clear to me if you meant a new group = of registries in a new location -- since you are not really requesting = the creation of a "new namespace". I do not believe there is a "Multiprotocol Label Switching Architecture" = heading. There is https://www.iana.org/assignments/mpls-label-values and = https://www.iana.org/assignments/mpls-id-type, the first with one = registry, the second with two. In summary, if you are suggesting the creation of, say = https://www.iana.org/assignments/mpls-gac-parameters/ with a heading of = "Multiprotocol Label Switching Architecture (MPLS) Generic Associated = Channel Parameters" to include all the GACh registries, then I think it = makes more sense to do it all at once. > I wonder if we can agree on this strategy >=20 > - go ahead with the current draft as it is, it simplicity makes if = easy > to move through wgls and iesg to create the new registry and move the > existing GACh registries there. > - as soon as we have that registry (or whenever the current draft is > sufficiently well advanced) we start up a new draft proposing what = you > say below. This would still leave out the GACh registries from = https://www.iana.org/assignments/mpls-oam-parameters/. Is that a 3rd RFC = in this strategy? Or leave these fragmented? > One reason that I want this two step strategy is that there is much > more of pwe3 registries (yes I know that registries are common) and > that there are several RFCs that needs to be updated in the second > step. That second draft should possibly also be a pwe3 wg document, > so we should work with someone from the pwe3 wg. >=20 To me, like I said, the appropriate strategy is to do all of this at = once (or not bother). Most definitely PWE3 needs to be on the critical = path, but my take is that these are MPLS registries as a superset (now) = of PWE3, with MPLS WG docs (co-called on PWE3). Frankly, the top-level = anchor point for all these registrations is the "Pseudowire Associated = Channel Types" (that maybe RFC 5586 should have moved) -- why not start = there? > Is this a way forward? >=20 It would be useful to see what others think -- to me this is not the = most efficient and effective way forward, just as one opinion. Thanks, -- Carlos. > /Loa >=20 > On 2013-08-14 18:59, Carlos Pignataro (cpignata) wrote: >> Loa, >>=20 >> Yes, what I already suggested: get all the mpls-gach allocations >> together in a new registry (from >> mpls-lsp-ping-parameters, pwe3-parameters, and mpls-oam-parameters, = into >> a new one). >>=20 >> Basically you have hierarchical allocations, that should be together: >> there are registries created for many individual values of G-ACH Type >> ("Pseudowire Associated Channel Type"). They should follow. >>=20 >> If you are moving 4 registries from mpls-lsp-ping-parameters, where = do >> you propose they'd end up? >>=20 >> BTW: These are the full G-ACH numbers for GACH: >>=20 >> * Pseudowire Associated Channel Types >> * Associated Channel Header TLV Registry // empty to be removed >> o MPLS Fault OAM Message Type Registry >> o MPLS Fault OAM Flag Registry >> o MPLS Fault OAM TLV Registry >> o MPLS PSC Request Registry >> o MPLS PSC TLV Registry >> o G-ACh Advertisement Protocol Application Registry >> o G-ACh Advertisement Protocol TLV Registry >> o G-ACh Advertisement Protocol: Ethernet Interface Parameters >> o CC/CV MEP-ID TLV Registry >> o Measurement Timestamp Type >> o Loss/Delay Measurement Control Code: Query Codes >> o Loss/Delay Measurement Control Code: Response Codes >> o MPLS Loss/Delay Measurement TLV Object >>=20 >> Thanks, >>=20 >> -- Carlos. >>=20 >> On Aug 14, 2013, at 12:37 PM, Loa Andersson > >> wrote: >>=20 >>> Carlos, >>>=20 >>> as long as we move them out of the LSP Ping registry and we can find = a >>> place where we have consensus that we should move them, I fine with >>> that. >>>=20 >>> Any suggestions? >>>=20 >>> /Loa >>>=20 >>> On 2013-08-14 18:25, Carlos Pignataro (cpignata) wrote: >>>> Hi, Loa, >>>>=20 >>>> Please see inline. >>>>=20 >>>> On Aug 14, 2013, at 2:25 AM, Loa Andersson >>> > wrote: >>>>=20 >>>>> Carlos, >>>>>=20 >>>>> While I tend to agree that someone (hint) should write-up a = document >>>>> fixing the G-ACh registries, that is not the purpose of the = current >>>>> documents. It is looking to clean up the LSP Ping registries. >>>>>=20 >>>>=20 >>>> The title of the current document is "Moving Generic Associated >>>> Channel registries to a new name space". >>>>=20 >>>> This in itself sets up a broader goal than tossing namespaces = outside >>>> LSP Ping registry over the wall. >>>>=20 >>>>> We have tried the approach "fixing everything" and failed to get = our >>>>> heads around it, decided to take a stepwise approach. If we now = stumble >>>>> on the first step (or rather second, since cleaning up the LSP = registy >>>>> structure was the first) I'm afraid that nothing will be done. >>>>>=20 >>>>=20 >>>> I wouldn't say "fix everything", but I would say "fix consistently" >>>> or "fix atomically". I do understand now that your goal is to clean >>>> up the LSP Ping registry. However, since you are "Moving Generic >>>> Associated Channel registries to a new name space", "fix modularly" >>>> can mean coalesce all the GACH registries, from LSP Ping as well as >>>> from the other 2-3 registries. In other words, fix two (LSP Ping = and >>>> GACH) with potentially very small additional incremental effort. >>>>=20 >>>>> Since you say (below) "solves a small part" I hope we can do this = and >>>>> go ahead and do the rest as soon as we have the cycles. >>>>>=20 >>>>=20 >>>> My humble view is that just moving these four falls short of >>>> meaningful change. >>>>=20 >>>> This is just a datapoint, my opinion, and I was too optimistic with >>>> "solves a small part". >>>>=20 >>>> I tried to present a proposal along with my comments that, to me, = has >>>> more return on cycles: coalesce the G-ACH registries, currently in >>>> LSP Ping, PWE3, and MPLS OAM. Since you gave me a "hint" above, I'd >>>> be happy to help out with this if the WG consensus is that the work >>>> makes sense. >>>>=20 >>>> Thanks, >>>>=20 >>>> -- Carlos. >>>>=20 >>>>=20 >>>>> /Loa >>>>>=20 >>>>> On 2013-08-14 04:53, Carlos Pignataro (cpignata) wrote: >>>>>> I believe that fixing and organizing misplaced number = registrations is >>>>>> useful and worthwhile as it prevents future confusion, and = typically >>>>>> welcome clean-ups. >>>>>>=20 >>>>>> However, I do not support adoption >>>>>> of draft-andersson-mpls-moving-iana-registries-00 in its current = form. >>>>>>=20 >>>>>> The document solves a small part of the potential source of = confusion, >>>>>> and, to me, it should fix all potential inconsistencies or leave = things >>>>>> as-is. >>>>>>=20 >>>>>> Specifically: >>>>>>=20 >>>>>> * draft-andersson-mpls-moving-iana-registries proposes only to = move >>>>>> four namespaces currently in [1] from [RFC6374] into a new = heading >>>>>> (registry). >>>>>>=20 >>>>>>=20 >>>>>> However, there's still the following potential inconsistencies, >>>>>> with all >>>>>> these protocol elements from the G-ACH in different places: >>>>>>=20 >>>>>> * The G-ACH Channel Types namespace, although now it's a superset = of >>>>>> the original PW-ACH, is still titled "Pseudowire Associated = Channel >>>>>> Types" and is hosted in the pwe3-parameters registry. [2] >>>>>> * Other G-ACH namespaces and assignments from [RFC6427] >>>>>> and [RFC6378] reside in their own mpls-oam-parameters page [3] >>>>>> * G-ACh Advertisement Protocol namespaces are in the = pwe3-parameters >>>>>> registry [4] [5] [6], although these are not PWE3. >>>>>> * CC/CV MEP-ID TLV namespace with pwe3-parameters [7] >>>>>>=20 >>>>>>=20 >>>>>> I would suggest that either things are left as they are, or all = these >>>>>> G-ACH/PW-ACH namespaces are moved under a main "Generic = Associated >>>>>> Channel (G-ACH)" registry *if* there's consensus for the = clean-up. >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> -- Carlos. >>>>>>=20 >>>>>> [1] >>>>>> = http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-par= ameters.xml#measurement-timestamp >>>>>> [2] >>>>>> = https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#pwe= 3-parameters-11 >>>>>> [3] >>>>>> = https://www.iana.org/assignments/mpls-oam-parameters/mpls-oam-parameters.x= html >>>>>> [4] >>>>>> = https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gac= h-application >>>>>> [5] >>>>>> = https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gac= h-tlv >>>>>> [6] >>>>>> = https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gac= h-ethernet >>>>>> [7] >>>>>> = https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#cc-= cv-mep-id >>>>>>=20 >>>>>>=20 >>>>>> On Aug 13, 2013, at 2:23 PM, Ross Callon >>>>> > wrote: >>>>>>=20 >>>>>>> This is to start a "two week" poll on adopting >>>>>>> draft-andersson-mpls-moving-iana-registries-00 >>>>>>> as an MPLS working group document. >>>>>>> Please send your comments (support/not support) to the mpls = working >>>>>>> group mailing list (mpls@ietf.org ). >>>>>>> This poll will end August 28, 2013. >>>>>>> Thanks, Ross >>>>>>> _______________________________________________ >>>>>>> mpls mailing list >>>>>>> mpls@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>=20 >>>>>=20 >>>>> -- >>>>>=20 >>>>>=20 >>>>> Loa Andersson email: loa@mail01.huawei.com >>>>> >>>>> Senior MPLS Expert loa@pi.nu >>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>=20 >>>=20 >>> -- >>>=20 >>>=20 >>> Loa Andersson email: loa@mail01.huawei.com >>> >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>=20 >=20 > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 --Apple-Mail=_638F0EF2-2958-445B-B58E-C0B1992D66ED Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlIMxJMACgkQtfDPGTp3USwztQCcDHZkebG2fxkRhGE+VBMt8RPv rDAAn30VO+EE+dv+t8vLubAQQkrdEDaF =Iy2/ -----END PGP SIGNATURE----- --Apple-Mail=_638F0EF2-2958-445B-B58E-C0B1992D66ED-- From loa@pi.nu Thu Aug 15 05:11:45 2013 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 6575B11E81A6 for ; Thu, 15 Aug 2013 05:11:45 -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 YuAwxoYKpFp6 for ; Thu, 15 Aug 2013 05:11:40 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5761511E8197 for ; Thu, 15 Aug 2013 05:11:40 -0700 (PDT) Received: from [192.168.5.57] (81-229-83-119-no65.business.telia.com [81.229.83.119]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 0F5FD1802038; Thu, 15 Aug 2013 14:11:38 +0200 (CEST) Message-ID: <520CC579.1040604@pi.nu> Date: Thu, 15 Aug 2013 14:11:37 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Nobo Akiya (nobo)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Comments on draft-ietf-mpls-return-path-specified-lsp-ping-12.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: Thu, 15 Aug 2013 12:11:45 -0000 Nobo, not that it matters too much but since we done a wg last call and request for publication what is in the document is the wg consensus. This wa more than a year ago, it was the LSP Ping TLV and sub-TLV registry that hanged the draft. It should be OK now and our AD should be preparing the document for IETF last call and IESG review. It is of course possible to have comments, but I see it there is nothing in what you suggest that can't go into a new document. /Loa On 2013-08-15 13:00, Nobo Akiya (nobo) wrote: > Hello Mach, > > Many thanks for quick response. Please see further comments inline. > >>> Dear Authors, et al, >>> >>> Draft adds new reply mode (5 - Reply via Specified Path) which looks >>> to provide initiator great control on return path. Draft considers >>> bidirectional LSP, and allows specifying of reverse LSP in a new TLV, >>> but ... for bidirectional LSP ping, having reply mode to indicate >>> reverse LSP would appear to take care of large majority of use, and >>> there'll be no need to encode/decode additional TLV. Is there any reason >> why reply mode to specify reverse LSP is not added? >> >> The draft uses the "reply mode 5 + B bit" to achieve this, using a reply mode >> to indicate the reverse LSP is an alternate way, we considered this and it >> also works. The reason not using dedicated reply mode is that we don't >> want to define too many reply modes, indicating reverse LSP is kind of >> specifying reply path and using the same reply mode seems reasonable. > > We have 8 bits of reply mode, draft is proposing to take value 5/255. I don't think we are crunched to conserve numbers, and reasonable to add another if it make sense. In this case, I think it make sense to add one for "reverse LSP". Regarding "we don't want to define too many reply modes", was that WG rough consensus or was that consensus amongst authors of this draft? > >> >> From the implementation point of view, IMHO, the two ways have not too >> much differences, from the operation point of view, there should be no >> difference. > > New value in 8 bit field is certainly much more easier to implement than (new value in 8 bit field + new TLV + logic to handle new TLV). > >> >>> >>> And reply path TLV allows for initiator to specify a particular return >>> path, but allows responder to choose different path if initiator >>> specified one cannot be accommodated. This aspect is very interesting. >>> Reason being that specifying of the "right" reply mode in echo request >>> seems to be getting more and more complicated these days. >>> >>> For example, bidirectional LSP with some transit nodes non-co-routed: >>> - ping: >>> * IP reply mode works >>> * Reverse LSP reply mode works >>> - ping with TTL terminating on mid: >>> * IP reply mode works >>> * Reverse LSP reply mode may or may not work >>> - traceroute: >>> * IP reply mode works >>> * Reverse LSP reply mode may or may not work >>> >>> In above cases, what I would like to specify in most cases is to say >>> "take reverse LSP as return path if available, otherwise take IP >>> return path". Yes reply path TLV allows this, but I'm thinking if this can be >> done in a simpler way. >> >> As you said, the reply path TLV allows this. In addition, to localize the failure >> point, sometime it may need to specify an explicit reply path other than the >> reverse path and IP return path, that is the main reason why we introduce >> the reply path TLV. > > Yes, for specific use like fault isolation, I think path TLV adds value. It can be another technique in addition to traceroute. For most ping/trace though, path TLV really isn't necessary. I'd like to see things kept simple for most cases, but allow a mechanism for that tricky few percent of cases. > >> >>> >>> Reply mode 2: Reply via an IPv4/IPv6 UDP packet Reply mode 4: Reply >>> via application level control channel Reply mode 6: Reply via reverse >>> LSP (assume this exists) >>> >>> Let's say there existed: >>> >>> Reply mode 7: Reply via pre-defined preference >>> >>> When responder receives reply mode 7, then return path is chosen from >>> pre-defined preference list (ex: control-channel > reverse LSP > IP). >>> Reply mode used can be encoded in the reply mode field of echo rely so >>> initiator knows which was used. >> >> The difficulty is that the responder may not have the ability to judge >> whether the control-channel, reverse LSP and IP is workable or not. For >> example, when it thinks that the control-channel is workable, it will always >> choose it but the control-channel may not workable (e.g., a failure in the >> middle of the channel) . > > Responder does not need to judge whether reverse "path" is workable or not, responder just needs to judge whether reverse "path" is available for use, and that's not difficult. > > Reverse LSP reply mode only make sense if something like "pre-defined preference" reply mode also exists ... since transit nodes or FRR path may not have reverse LSP. But "default reply mode" selection by implementations or operators will be simplified if we had something like this. > > All this to say, can we discuss a simpler solution via adding couple of new reply modes? :) > > I have another question. Draft mentions BFD. I understand the motive behind wanting to control the reverse BFD path on uni-directional LSP. But I don't quite see the entire picture by making use of path TLV. Let's say we bootstrap BFD with LSP ping with path TLV with specific RSVP FEC, so that reverse BFD packets are riding on specified RSVP FEC. That RSVP FEC can become invalid at any time (ex: re-optimization takes place and LSP ID changes). What happens then? > > Regards, > Nobo > >> >> Best regards, >> Mach >> >>> >>> I see the new TLV useful for specific scenarios, but I've been trying >>> to see how things (implementations and operations) can be simplified >>> for those non-specific >>> (majority) of cases. Was something like above considered as part of this >> draft? >>> >>> Regards, >>> Nobo >>> >>> _______________________________________________ >>> 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 > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Thu Aug 15 05:22:49 2013 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 A650921E812D for ; Thu, 15 Aug 2013 05:22:49 -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 5wwSZg4voJSt for ; Thu, 15 Aug 2013 05:22:45 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 68FCF21E812C for ; Thu, 15 Aug 2013 05:22:41 -0700 (PDT) Received: from [192.168.5.57] (81-229-83-119-no65.business.telia.com [81.229.83.119]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id A0E541802038; Thu, 15 Aug 2013 14:22:40 +0200 (CEST) Message-ID: <520CC80F.3090700@pi.nu> Date: Thu, 15 Aug 2013 14:22:39 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" References: <5efa5403aab843bdbcc382a8143640ee@BLUPR05MB070.namprd05.prod.outlook.com> <95067C434CE250468B77282634C96ED322DFE5CE@xmb-aln-x02.cisco.com> <520B22D9.5060400@pi.nu> <95067C434CE250468B77282634C96ED322E05236@xmb-aln-x02.cisco.com> <520BB261.7030809@pi.nu> <95067C434CE250468B77282634C96ED322E05628@xmb-aln-x02.cisco.com> <520CBC71.1050806@pi.nu> <95067C434CE250468B77282634C96ED322E09A82@xmb-aln-x02.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED322E09A82@xmb-aln-x02.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "loa@mail01.huawei.com" Subject: Re: [mpls] Poll for Adoption draft-andersson-mpls-moving-iana-registries-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, 15 Aug 2013 12:22:49 -0000 Carlos, go to http://www.iana.org/protocols look for: Multiprotocol Label Switching Architecture (MPLS) you the "heading" it has no link attach to it, Under that you find something like 16 name spaces each with one or more registries. /Loa On 2013-08-15 14:07, Carlos Pignataro (cpignata) wrote: > Loa, > > Thanks for the response -- please see inline. > > On Aug 15, 2013, at 7:33 AM, Loa Andersson > wrote: > >> Carlos, >> >> I'm not against the idea of moving all mpls-gach allocation registry. >> >> Since you ask where the GACh registries in the LSP Ping name space goes, >> the draft says: >> >> These registries are now moved into a new name space under the >> "Multiprotocol Label Switching Architecture" (MPLS) heading called >> "MPLS Generic Associated Channel Parameters". >> > > Thanks. I read that but it was not clear to me if you meant a new group of registries in a new location -- since you are not really requesting the creation of a "new namespace". > > I do not believe there is a "Multiprotocol Label Switching Architecture" heading. There is https://www.iana.org/assignments/mpls-label-values and https://www.iana.org/assignments/mpls-id-type, the first with one registry, the second with two. > > In summary, if you are suggesting the creation of, say https://www.iana.org/assignments/mpls-gac-parameters/ with a heading of "Multiprotocol Label Switching Architecture (MPLS) Generic Associated Channel Parameters" to include all the GACh registries, then I think it makes more sense to do it all at once. > >> I wonder if we can agree on this strategy >> >> - go ahead with the current draft as it is, it simplicity makes if easy >> to move through wgls and iesg to create the new registry and move the >> existing GACh registries there. >> - as soon as we have that registry (or whenever the current draft is >> sufficiently well advanced) we start up a new draft proposing what you >> say below. > > This would still leave out the GACh registries from https://www.iana.org/assignments/mpls-oam-parameters/. Is that a 3rd RFC in this strategy? Or leave these fragmented? > >> One reason that I want this two step strategy is that there is much >> more of pwe3 registries (yes I know that registries are common) and >> that there are several RFCs that needs to be updated in the second >> step. That second draft should possibly also be a pwe3 wg document, >> so we should work with someone from the pwe3 wg. >> > > To me, like I said, the appropriate strategy is to do all of this at once (or not bother). Most definitely PWE3 needs to be on the critical path, but my take is that these are MPLS registries as a superset (now) of PWE3, with MPLS WG docs (co-called on PWE3). Frankly, the top-level anchor point for all these registrations is the "Pseudowire Associated Channel Types" (that maybe RFC 5586 should have moved) -- why not start there? > >> Is this a way forward? >> > > It would be useful to see what others think -- to me this is not the most efficient and effective way forward, just as one opinion. > > Thanks, > > -- Carlos. > >> /Loa >> >> On 2013-08-14 18:59, Carlos Pignataro (cpignata) wrote: >>> Loa, >>> >>> Yes, what I already suggested: get all the mpls-gach allocations >>> together in a new registry (from >>> mpls-lsp-ping-parameters, pwe3-parameters, and mpls-oam-parameters, into >>> a new one). >>> >>> Basically you have hierarchical allocations, that should be together: >>> there are registries created for many individual values of G-ACH Type >>> ("Pseudowire Associated Channel Type"). They should follow. >>> >>> If you are moving 4 registries from mpls-lsp-ping-parameters, where do >>> you propose they'd end up? >>> >>> BTW: These are the full G-ACH numbers for GACH: >>> >>> * Pseudowire Associated Channel Types >>> * Associated Channel Header TLV Registry // empty to be removed >>> o MPLS Fault OAM Message Type Registry >>> o MPLS Fault OAM Flag Registry >>> o MPLS Fault OAM TLV Registry >>> o MPLS PSC Request Registry >>> o MPLS PSC TLV Registry >>> o G-ACh Advertisement Protocol Application Registry >>> o G-ACh Advertisement Protocol TLV Registry >>> o G-ACh Advertisement Protocol: Ethernet Interface Parameters >>> o CC/CV MEP-ID TLV Registry >>> o Measurement Timestamp Type >>> o Loss/Delay Measurement Control Code: Query Codes >>> o Loss/Delay Measurement Control Code: Response Codes >>> o MPLS Loss/Delay Measurement TLV Object >>> >>> Thanks, >>> >>> -- Carlos. >>> >>> On Aug 14, 2013, at 12:37 PM, Loa Andersson > >>> wrote: >>> >>>> Carlos, >>>> >>>> as long as we move them out of the LSP Ping registry and we can find a >>>> place where we have consensus that we should move them, I fine with >>>> that. >>>> >>>> Any suggestions? >>>> >>>> /Loa >>>> >>>> On 2013-08-14 18:25, Carlos Pignataro (cpignata) wrote: >>>>> Hi, Loa, >>>>> >>>>> Please see inline. >>>>> >>>>> On Aug 14, 2013, at 2:25 AM, Loa Andersson >>>> > wrote: >>>>> >>>>>> Carlos, >>>>>> >>>>>> While I tend to agree that someone (hint) should write-up a document >>>>>> fixing the G-ACh registries, that is not the purpose of the current >>>>>> documents. It is looking to clean up the LSP Ping registries. >>>>>> >>>>> >>>>> The title of the current document is "Moving Generic Associated >>>>> Channel registries to a new name space". >>>>> >>>>> This in itself sets up a broader goal than tossing namespaces outside >>>>> LSP Ping registry over the wall. >>>>> >>>>>> We have tried the approach "fixing everything" and failed to get our >>>>>> heads around it, decided to take a stepwise approach. If we now stumble >>>>>> on the first step (or rather second, since cleaning up the LSP registy >>>>>> structure was the first) I'm afraid that nothing will be done. >>>>>> >>>>> >>>>> I wouldn't say "fix everything", but I would say "fix consistently" >>>>> or "fix atomically". I do understand now that your goal is to clean >>>>> up the LSP Ping registry. However, since you are "Moving Generic >>>>> Associated Channel registries to a new name space", "fix modularly" >>>>> can mean coalesce all the GACH registries, from LSP Ping as well as >>>>> from the other 2-3 registries. In other words, fix two (LSP Ping and >>>>> GACH) with potentially very small additional incremental effort. >>>>> >>>>>> Since you say (below) "solves a small part" I hope we can do this and >>>>>> go ahead and do the rest as soon as we have the cycles. >>>>>> >>>>> >>>>> My humble view is that just moving these four falls short of >>>>> meaningful change. >>>>> >>>>> This is just a datapoint, my opinion, and I was too optimistic with >>>>> "solves a small part". >>>>> >>>>> I tried to present a proposal along with my comments that, to me, has >>>>> more return on cycles: coalesce the G-ACH registries, currently in >>>>> LSP Ping, PWE3, and MPLS OAM. Since you gave me a "hint" above, I'd >>>>> be happy to help out with this if the WG consensus is that the work >>>>> makes sense. >>>>> >>>>> Thanks, >>>>> >>>>> -- Carlos. >>>>> >>>>> >>>>>> /Loa >>>>>> >>>>>> On 2013-08-14 04:53, Carlos Pignataro (cpignata) wrote: >>>>>>> I believe that fixing and organizing misplaced number registrations is >>>>>>> useful and worthwhile as it prevents future confusion, and typically >>>>>>> welcome clean-ups. >>>>>>> >>>>>>> However, I do not support adoption >>>>>>> of draft-andersson-mpls-moving-iana-registries-00 in its current form. >>>>>>> >>>>>>> The document solves a small part of the potential source of confusion, >>>>>>> and, to me, it should fix all potential inconsistencies or leave things >>>>>>> as-is. >>>>>>> >>>>>>> Specifically: >>>>>>> >>>>>>> * draft-andersson-mpls-moving-iana-registries proposes only to move >>>>>>> four namespaces currently in [1] from [RFC6374] into a new heading >>>>>>> (registry). >>>>>>> >>>>>>> >>>>>>> However, there's still the following potential inconsistencies, >>>>>>> with all >>>>>>> these protocol elements from the G-ACH in different places: >>>>>>> >>>>>>> * The G-ACH Channel Types namespace, although now it's a superset of >>>>>>> the original PW-ACH, is still titled "Pseudowire Associated Channel >>>>>>> Types" and is hosted in the pwe3-parameters registry. [2] >>>>>>> * Other G-ACH namespaces and assignments from [RFC6427] >>>>>>> and [RFC6378] reside in their own mpls-oam-parameters page [3] >>>>>>> * G-ACh Advertisement Protocol namespaces are in the pwe3-parameters >>>>>>> registry [4] [5] [6], although these are not PWE3. >>>>>>> * CC/CV MEP-ID TLV namespace with pwe3-parameters [7] >>>>>>> >>>>>>> >>>>>>> I would suggest that either things are left as they are, or all these >>>>>>> G-ACH/PW-ACH namespaces are moved under a main "Generic Associated >>>>>>> Channel (G-ACH)" registry *if* there's consensus for the clean-up. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -- Carlos. >>>>>>> >>>>>>> [1] >>>>>>> http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml#measurement-timestamp >>>>>>> [2] >>>>>>> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#pwe3-parameters-11 >>>>>>> [3] >>>>>>> https://www.iana.org/assignments/mpls-oam-parameters/mpls-oam-parameters.xhtml >>>>>>> [4] >>>>>>> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gach-application >>>>>>> [5] >>>>>>> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gach-tlv >>>>>>> [6] >>>>>>> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gach-ethernet >>>>>>> [7] >>>>>>> https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#cc-cv-mep-id >>>>>>> >>>>>>> >>>>>>> On Aug 13, 2013, at 2:23 PM, Ross Callon >>>>>> > wrote: >>>>>>> >>>>>>>> This is to start a "two week" poll on adopting >>>>>>>> draft-andersson-mpls-moving-iana-registries-00 >>>>>>>> as an MPLS working group document. >>>>>>>> Please send your comments (support/not support) to the mpls working >>>>>>>> group mailing list (mpls@ietf.org ). >>>>>>>> This poll will end August 28, 2013. >>>>>>>> Thanks, Ross >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> Loa Andersson email: loa@mail01.huawei.com >>>>>> >>>>>> Senior MPLS Expert loa@pi.nu >>>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>> >>>> >>>> -- >>>> >>>> >>>> Loa Andersson email: loa@mail01.huawei.com >>>> >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>> >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From cpignata@cisco.com Thu Aug 15 05:54:43 2013 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 F071321F99F4 for ; Thu, 15 Aug 2013 05:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 ILN+1V8p2tqx for ; Thu, 15 Aug 2013 05:54:39 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3F16221F996F for ; Thu, 15 Aug 2013 05:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14265; q=dns/txt; s=iport; t=1376571279; x=1377780879; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0+6A0w3Gx4iiopwsyUrOmU19qsJ9PP8cRVHQitVpPDY=; b=Vv91ug2mPNqrZxpJHqOa2fEz/QncbX/Fc3WuVAb6DWkpBQNrPVydOzWq goyU+UuhVAnzSd+Q9RLgCEaeuNerzoiGl78HQ6kod2tpdi4wVQ3Gdo/rN CWigKUBHGgM8UgMEa1zZiBlzrrCjrwKU41z9WPbxufhCyVC9urUQn4XXi A=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIFAEfODFKtJXG9/2dsb2JhbABbgwY1Sga/EoEiFnSCJAEBAQMBAQEBaAMLBQkCAgEIEgYKHQcbDAsUAw4CBA4FCAEFh3wGBwW5ZgSOf4EcMQeDG3cDkBaBLpJOhSSDG4FxOQ X-IronPort-AV: E=Sophos;i="4.89,885,1367971200"; d="asc'?scan'208";a="247746770" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 15 Aug 2013 12:54:37 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7FCsbTD001123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Aug 2013 12:54:37 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 15 Aug 2013 07:54:36 -0500 From: "Carlos Pignataro (cpignata)" To: Loa Andersson Thread-Topic: [mpls] Poll for Adoption draft-andersson-mpls-moving-iana-registries-00 Thread-Index: AQHOmQygexQei+QGC0qqnPis7dL7Z5mVQN0AgAE3RYCAAAmygIAABCeAgAAI7IA= Date: Thu, 15 Aug 2013 12:54:35 +0000 Message-ID: <95067C434CE250468B77282634C96ED322E0A487@xmb-aln-x02.cisco.com> References: <5efa5403aab843bdbcc382a8143640ee@BLUPR05MB070.namprd05.prod.outlook.com> <95067C434CE250468B77282634C96ED322DFE5CE@xmb-aln-x02.cisco.com> <520B22D9.5060400@pi.nu> <95067C434CE250468B77282634C96ED322E05236@xmb-aln-x02.cisco.com> <520BB261.7030809@pi.nu> <95067C434CE250468B77282634C96ED322E05628@xmb-aln-x02.cisco.com> <520CBC71.1050806@pi.nu> <95067C434CE250468B77282634C96ED322E09A82@xmb-aln-x02.cisco.com> <520CC80F.3090700@pi.nu> In-Reply-To: <520CC80F.3090700@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.50] Content-Type: multipart/signed; boundary="Apple-Mail=_81737F7D-75C1-429B-AE5A-331BE93AA145"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "loa@mail01.huawei.com" Subject: Re: [mpls] Poll for Adoption draft-andersson-mpls-moving-iana-registries-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, 15 Aug 2013 12:54:44 -0000 --Apple-Mail=_81737F7D-75C1-429B-AE5A-331BE93AA145 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Loa, There's some nomenclature conflicts that are perhaps confusing. Under = that "heading" there are no "namespaces" (with the RFC 5226 definition) = -- those are "registries". You are asking to move registries as-is from = a file of parameters to a new file, correct? Or asking for the creation = of a new registry with sub-registries? Just trying to understand: your desired end state is exactly as it is = right now, but with the hyperlinks pointing elsewhere not to the = mpls-lsp-ping-parameters? Also, what about https://www.iana.org/assignments/mpls-oam-parameters/ = which are under the GACh? To me, a hierarchical allocation makes sense in which there's the G-ACH = Types first, and then the registries needed for each type. Thanks for your patience with my questions and comments :-) -- Carlos. On Aug 15, 2013, at 8:22 AM, Loa Andersson wrote: > Carlos, >=20 > go to http://www.iana.org/protocols >=20 > look for: >=20 > Multiprotocol Label Switching Architecture (MPLS) >=20 > you the "heading" it has no link attach to it, >=20 > Under that you find something like 16 name spaces each with one or = more > registries. >=20 > /Loa >=20 > On 2013-08-15 14:07, Carlos Pignataro (cpignata) wrote: >> Loa, >>=20 >> Thanks for the response -- please see inline. >>=20 >> On Aug 15, 2013, at 7:33 AM, Loa Andersson >> wrote: >>=20 >>> Carlos, >>>=20 >>> I'm not against the idea of moving all mpls-gach allocation = registry. >>>=20 >>> Since you ask where the GACh registries in the LSP Ping name space = goes, >>> the draft says: >>>=20 >>> These registries are now moved into a new name space under the >>> "Multiprotocol Label Switching Architecture" (MPLS) heading called >>> "MPLS Generic Associated Channel Parameters". >>>=20 >>=20 >> Thanks. I read that but it was not clear to me if you meant a new = group of registries in a new location -- since you are not really = requesting the creation of a "new namespace". >>=20 >> I do not believe there is a "Multiprotocol Label Switching = Architecture" heading. >=20 > There is https://www.iana.org/assignments/mpls-label-values and >=20 > https://www.iana.org/assignments/mpls-id-type, the first with one = registry, the second with two. >>=20 >> In summary, if you are suggesting the creation of, say = https://www.iana.org/assignments/mpls-gac-parameters/ with a heading of = "Multiprotocol Label Switching Architecture (MPLS) Generic Associated = Channel Parameters" to include all the GACh registries, then I think it = makes more sense to do it all at once. >>=20 >>> I wonder if we can agree on this strategy >>>=20 >>> - go ahead with the current draft as it is, it simplicity makes if = easy >>> to move through wgls and iesg to create the new registry and move = the >>> existing GACh registries there. >>> - as soon as we have that registry (or whenever the current draft is >>> sufficiently well advanced) we start up a new draft proposing what = you >>> say below. >>=20 >> This would still leave out the GACh registries from = https://www.iana.org/assignments/mpls-oam-parameters/. Is that a 3rd RFC = in this strategy? Or leave these fragmented? >>=20 >>> One reason that I want this two step strategy is that there is much >>> more of pwe3 registries (yes I know that registries are common) and >>> that there are several RFCs that needs to be updated in the second >>> step. That second draft should possibly also be a pwe3 wg document, >>> so we should work with someone from the pwe3 wg. >>>=20 >>=20 >> To me, like I said, the appropriate strategy is to do all of this at = once (or not bother). Most definitely PWE3 needs to be on the critical = path, but my take is that these are MPLS registries as a superset (now) = of PWE3, with MPLS WG docs (co-called on PWE3). Frankly, the top-level = anchor point for all these registrations is the "Pseudowire Associated = Channel Types" (that maybe RFC 5586 should have moved) -- why not start = there? >>=20 >>> Is this a way forward? >>>=20 >>=20 >> It would be useful to see what others think -- to me this is not the = most efficient and effective way forward, just as one opinion. >>=20 >> Thanks, >>=20 >> -- Carlos. >>=20 >>> /Loa >>>=20 >>> On 2013-08-14 18:59, Carlos Pignataro (cpignata) wrote: >>>> Loa, >>>>=20 >>>> Yes, what I already suggested: get all the mpls-gach allocations >>>> together in a new registry (from >>>> mpls-lsp-ping-parameters, pwe3-parameters, and mpls-oam-parameters, = into >>>> a new one). >>>>=20 >>>> Basically you have hierarchical allocations, that should be = together: >>>> there are registries created for many individual values of G-ACH = Type >>>> ("Pseudowire Associated Channel Type"). They should follow. >>>>=20 >>>> If you are moving 4 registries from mpls-lsp-ping-parameters, where = do >>>> you propose they'd end up? >>>>=20 >>>> BTW: These are the full G-ACH numbers for GACH: >>>>=20 >>>> * Pseudowire Associated Channel Types >>>> * Associated Channel Header TLV Registry // empty to be removed >>>> o MPLS Fault OAM Message Type Registry >>>> o MPLS Fault OAM Flag Registry >>>> o MPLS Fault OAM TLV Registry >>>> o MPLS PSC Request Registry >>>> o MPLS PSC TLV Registry >>>> o G-ACh Advertisement Protocol Application Registry >>>> o G-ACh Advertisement Protocol TLV Registry >>>> o G-ACh Advertisement Protocol: Ethernet Interface Parameters >>>> o CC/CV MEP-ID TLV Registry >>>> o Measurement Timestamp Type >>>> o Loss/Delay Measurement Control Code: Query Codes >>>> o Loss/Delay Measurement Control Code: Response Codes >>>> o MPLS Loss/Delay Measurement TLV Object >>>>=20 >>>> Thanks, >>>>=20 >>>> -- Carlos. >>>>=20 >>>> On Aug 14, 2013, at 12:37 PM, Loa Andersson > >>>> wrote: >>>>=20 >>>>> Carlos, >>>>>=20 >>>>> as long as we move them out of the LSP Ping registry and we can = find a >>>>> place where we have consensus that we should move them, I fine = with >>>>> that. >>>>>=20 >>>>> Any suggestions? >>>>>=20 >>>>> /Loa >>>>>=20 >>>>> On 2013-08-14 18:25, Carlos Pignataro (cpignata) wrote: >>>>>> Hi, Loa, >>>>>>=20 >>>>>> Please see inline. >>>>>>=20 >>>>>> On Aug 14, 2013, at 2:25 AM, Loa Andersson >>>>> > wrote: >>>>>>=20 >>>>>>> Carlos, >>>>>>>=20 >>>>>>> While I tend to agree that someone (hint) should write-up a = document >>>>>>> fixing the G-ACh registries, that is not the purpose of the = current >>>>>>> documents. It is looking to clean up the LSP Ping registries. >>>>>>>=20 >>>>>>=20 >>>>>> The title of the current document is "Moving Generic Associated >>>>>> Channel registries to a new name space". >>>>>>=20 >>>>>> This in itself sets up a broader goal than tossing namespaces = outside >>>>>> LSP Ping registry over the wall. >>>>>>=20 >>>>>>> We have tried the approach "fixing everything" and failed to get = our >>>>>>> heads around it, decided to take a stepwise approach. If we now = stumble >>>>>>> on the first step (or rather second, since cleaning up the LSP = registy >>>>>>> structure was the first) I'm afraid that nothing will be done. >>>>>>>=20 >>>>>>=20 >>>>>> I wouldn't say "fix everything", but I would say "fix = consistently" >>>>>> or "fix atomically". I do understand now that your goal is to = clean >>>>>> up the LSP Ping registry. However, since you are "Moving Generic >>>>>> Associated Channel registries to a new name space", "fix = modularly" >>>>>> can mean coalesce all the GACH registries, from LSP Ping as well = as >>>>>> from the other 2-3 registries. In other words, fix two (LSP Ping = and >>>>>> GACH) with potentially very small additional incremental effort. >>>>>>=20 >>>>>>> Since you say (below) "solves a small part" I hope we can do = this and >>>>>>> go ahead and do the rest as soon as we have the cycles. >>>>>>>=20 >>>>>>=20 >>>>>> My humble view is that just moving these four falls short of >>>>>> meaningful change. >>>>>>=20 >>>>>> This is just a datapoint, my opinion, and I was too optimistic = with >>>>>> "solves a small part". >>>>>>=20 >>>>>> I tried to present a proposal along with my comments that, to me, = has >>>>>> more return on cycles: coalesce the G-ACH registries, currently = in >>>>>> LSP Ping, PWE3, and MPLS OAM. Since you gave me a "hint" above, = I'd >>>>>> be happy to help out with this if the WG consensus is that the = work >>>>>> makes sense. >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> -- Carlos. >>>>>>=20 >>>>>>=20 >>>>>>> /Loa >>>>>>>=20 >>>>>>> On 2013-08-14 04:53, Carlos Pignataro (cpignata) wrote: >>>>>>>> I believe that fixing and organizing misplaced number = registrations is >>>>>>>> useful and worthwhile as it prevents future confusion, and = typically >>>>>>>> welcome clean-ups. >>>>>>>>=20 >>>>>>>> However, I do not support adoption >>>>>>>> of draft-andersson-mpls-moving-iana-registries-00 in its = current form. >>>>>>>>=20 >>>>>>>> The document solves a small part of the potential source of = confusion, >>>>>>>> and, to me, it should fix all potential inconsistencies or = leave things >>>>>>>> as-is. >>>>>>>>=20 >>>>>>>> Specifically: >>>>>>>>=20 >>>>>>>> * draft-andersson-mpls-moving-iana-registries proposes only to = move >>>>>>>> four namespaces currently in [1] from [RFC6374] into a new = heading >>>>>>>> (registry). >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> However, there's still the following potential inconsistencies, >>>>>>>> with all >>>>>>>> these protocol elements from the G-ACH in different places: >>>>>>>>=20 >>>>>>>> * The G-ACH Channel Types namespace, although now it's a = superset of >>>>>>>> the original PW-ACH, is still titled "Pseudowire Associated = Channel >>>>>>>> Types" and is hosted in the pwe3-parameters registry. [2] >>>>>>>> * Other G-ACH namespaces and assignments from [RFC6427] >>>>>>>> and [RFC6378] reside in their own mpls-oam-parameters page = [3] >>>>>>>> * G-ACh Advertisement Protocol namespaces are in the = pwe3-parameters >>>>>>>> registry [4] [5] [6], although these are not PWE3. >>>>>>>> * CC/CV MEP-ID TLV namespace with pwe3-parameters [7] >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I would suggest that either things are left as they are, or all = these >>>>>>>> G-ACH/PW-ACH namespaces are moved under a main "Generic = Associated >>>>>>>> Channel (G-ACH)" registry *if* there's consensus for the = clean-up. >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>>=20 >>>>>>>> -- Carlos. >>>>>>>>=20 >>>>>>>> [1] >>>>>>>> = http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-par= ameters.xml#measurement-timestamp >>>>>>>> [2] >>>>>>>> = https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#pwe= 3-parameters-11 >>>>>>>> [3] >>>>>>>> = https://www.iana.org/assignments/mpls-oam-parameters/mpls-oam-parameters.x= html >>>>>>>> [4] >>>>>>>> = https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gac= h-application >>>>>>>> [5] >>>>>>>> = https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gac= h-tlv >>>>>>>> [6] >>>>>>>> = https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#gac= h-ethernet >>>>>>>> [7] >>>>>>>> = https://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xhtml#cc-= cv-mep-id >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Aug 13, 2013, at 2:23 PM, Ross Callon >>>>>>> > wrote: >>>>>>>>=20 >>>>>>>>> This is to start a "two week" poll on adopting >>>>>>>>> draft-andersson-mpls-moving-iana-registries-00 >>>>>>>>> as an MPLS working group document. >>>>>>>>> Please send your comments (support/not support) to the mpls = working >>>>>>>>> group mailing list (mpls@ietf.org ). >>>>>>>>> This poll will end August 28, 2013. >>>>>>>>> Thanks, Ross >>>>>>>>> _______________________________________________ >>>>>>>>> mpls mailing list >>>>>>>>> mpls@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> mpls mailing list >>>>>>>> mpls@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>>=20 >>>>>>>=20 >>>>>>> Loa Andersson email: = loa@mail01.huawei.com >>>>>>> >>>>>>> Senior MPLS Expert loa@pi.nu >>>>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>>>=20 >>>>>=20 >>>>> -- >>>>>=20 >>>>>=20 >>>>> Loa Andersson email: loa@mail01.huawei.com >>>>> >>>>> Senior MPLS Expert loa@pi.nu >>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>=20 >>>=20 >>> -- >>>=20 >>>=20 >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>=20 >=20 > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 --Apple-Mail=_81737F7D-75C1-429B-AE5A-331BE93AA145 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlIMz4sACgkQtfDPGTp3USyMCACfZVWtm1+jMabhn/Mwo9AATy4b k7EAoJywrPkm3RIiP6RYK9p7wapQdzFs =X3i5 -----END PGP SIGNATURE----- --Apple-Mail=_81737F7D-75C1-429B-AE5A-331BE93AA145-- From nobo@cisco.com Thu Aug 15 06:10:18 2013 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 D6BFA11E814E for ; Thu, 15 Aug 2013 06:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VEu49jAq8-o for ; Thu, 15 Aug 2013 06:10:12 -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 83F8C21F9CF2 for ; Thu, 15 Aug 2013 06:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7975; q=dns/txt; s=iport; t=1376572212; x=1377781812; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jLTlDZdwF3/sKKAWcw0rJU87f9mbVmTKLyxwksJFyu0=; b=PTA71gknIfkJURhyJNxvi+4rAl93QRobWSxc12gVxCCWa9AtuLWar/cB LYQ/hIFuou6SChCiZyXxZaWZETFEKb16Q74YtIURxd3wYNuw0Gp7oS/oF XAvVuymParXKVZ2GdIBy1XCUyv6I+Ojx39V/uh0iSvtW4rtXFrwNIgvGP 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAErSDFKtJV2c/2dsb2JhbABbgmUhNVC/EoEiFnSCJAEBAQQBAQE3MQMGBQwCAgIBCBEEAQEBChQJBxsMCxQJCAIEDgUIE4d1AQu5cgQEjn+BHDEHBoMVdwOpNoMbgXE5 X-IronPort-AV: E=Sophos;i="4.89,885,1367971200"; d="scan'208";a="247655399" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 15 Aug 2013 13:10:10 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7FDAA7B011853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Aug 2013 13:10:10 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Thu, 15 Aug 2013 08:10:10 -0500 From: "Nobo Akiya (nobo)" To: Loa Andersson Thread-Topic: [mpls] Comments on draft-ietf-mpls-return-path-specified-lsp-ping-12.txt Thread-Index: AQHOmX6dautCD2CXyU+H2VRtLXBA/pmWBakQgAB8WYD//7cRkA== Date: Thu, 15 Aug 2013 13:09:45 +0000 Message-ID: References: <520CC579.1040604@pi.nu> In-Reply-To: <520CC579.1040604@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" Subject: Re: [mpls] Comments on draft-ietf-mpls-return-path-specified-lsp-ping-12.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: Thu, 15 Aug 2013 13:10:18 -0000 Hello Loa, Thank you for the input. Yes I understand that I'm doing this very late in = the draft stage. I will honor WG consensus, but I do want to point out coup= le of things. 1. I'm not arguing against path TLV, I see there's still use for that. I wa= s hoping that we can further discuss another method which is simpler and mu= tually exclusive with path TLV. 2. I'm not sure that we want to specify BFD in this draft, since path TLV r= eally cannot be used for BFD w/o further considerations. Regards, Nobo > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Thursday, August 15, 2013 8:12 AM > To: Nobo Akiya (nobo) > Cc: Mach Chen; draft-ietf-mpls-return-path-specified-lsp- > ping@tools.ietf.org; mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-return-path-specified-lsp= - > ping-12.txt >=20 > Nobo, >=20 > not that it matters too much but since we done a wg last call and request= for > publication what is in the document is the wg consensus. >=20 > This wa more than a year ago, it was the LSP Ping TLV and sub-TLV registr= y > that hanged the draft. It should be OK now and our AD should be preparing > the document for IETF last call and IESG review. >=20 > It is of course possible to have comments, but I see it there is nothing = in > what you suggest that can't go into a new document. >=20 > /Loa >=20 > On 2013-08-15 13:00, Nobo Akiya (nobo) wrote: > > Hello Mach, > > > > Many thanks for quick response. Please see further comments inline. > > > >>> Dear Authors, et al, > >>> > >>> Draft adds new reply mode (5 - Reply via Specified Path) which looks > >>> to provide initiator great control on return path. Draft considers > >>> bidirectional LSP, and allows specifying of reverse LSP in a new > >>> TLV, but ... for bidirectional LSP ping, having reply mode to > >>> indicate reverse LSP would appear to take care of large majority of > >>> use, and there'll be no need to encode/decode additional TLV. Is > >>> there any reason > >> why reply mode to specify reverse LSP is not added? > >> > >> The draft uses the "reply mode 5 + B bit" to achieve this, using a > >> reply mode to indicate the reverse LSP is an alternate way, we > >> considered this and it also works. The reason not using dedicated > >> reply mode is that we don't want to define too many reply modes, > >> indicating reverse LSP is kind of specifying reply path and using the = same > reply mode seems reasonable. > > > > We have 8 bits of reply mode, draft is proposing to take value 5/255. I > don't think we are crunched to conserve numbers, and reasonable to add > another if it make sense. In this case, I think it make sense to add one = for > "reverse LSP". Regarding "we don't want to define too many reply modes", > was that WG rough consensus or was that consensus amongst authors of this > draft? > > > >> > >> From the implementation point of view, IMHO, the two ways have not > >> too much differences, from the operation point of view, there should > >> be no difference. > > > > New value in 8 bit field is certainly much more easier to implement tha= n > (new value in 8 bit field + new TLV + logic to handle new TLV). > > > >> > >>> > >>> And reply path TLV allows for initiator to specify a particular > >>> return path, but allows responder to choose different path if > >>> initiator specified one cannot be accommodated. This aspect is very > interesting. > >>> Reason being that specifying of the "right" reply mode in echo > >>> request seems to be getting more and more complicated these days. > >>> > >>> For example, bidirectional LSP with some transit nodes non-co-routed: > >>> - ping: > >>> * IP reply mode works > >>> * Reverse LSP reply mode works > >>> - ping with TTL terminating on mid: > >>> * IP reply mode works > >>> * Reverse LSP reply mode may or may not work > >>> - traceroute: > >>> * IP reply mode works > >>> * Reverse LSP reply mode may or may not work > >>> > >>> In above cases, what I would like to specify in most cases is to say > >>> "take reverse LSP as return path if available, otherwise take IP > >>> return path". Yes reply path TLV allows this, but I'm thinking if > >>> this can be > >> done in a simpler way. > >> > >> As you said, the reply path TLV allows this. In addition, to localize > >> the failure point, sometime it may need to specify an explicit reply > >> path other than the reverse path and IP return path, that is the main > >> reason why we introduce the reply path TLV. > > > > Yes, for specific use like fault isolation, I think path TLV adds value= . It can > be another technique in addition to traceroute. For most ping/trace thoug= h, > path TLV really isn't necessary. I'd like to see things kept simple for m= ost > cases, but allow a mechanism for that tricky few percent of cases. > > > >> > >>> > >>> Reply mode 2: Reply via an IPv4/IPv6 UDP packet Reply mode 4: Reply > >>> via application level control channel Reply mode 6: Reply via > >>> reverse LSP (assume this exists) > >>> > >>> Let's say there existed: > >>> > >>> Reply mode 7: Reply via pre-defined preference > >>> > >>> When responder receives reply mode 7, then return path is chosen > >>> from pre-defined preference list (ex: control-channel > reverse LSP >= IP). > >>> Reply mode used can be encoded in the reply mode field of echo rely > >>> so initiator knows which was used. > >> > >> The difficulty is that the responder may not have the ability to > >> judge whether the control-channel, reverse LSP and IP is workable or > >> not. For example, when it thinks that the control-channel is > >> workable, it will always choose it but the control-channel may not > >> workable (e.g., a failure in the middle of the channel) . > > > > Responder does not need to judge whether reverse "path" is workable or > not, responder just needs to judge whether reverse "path" is available fo= r > use, and that's not difficult. > > > > Reverse LSP reply mode only make sense if something like "pre-defined > preference" reply mode also exists ... since transit nodes or FRR path ma= y > not have reverse LSP. But "default reply mode" selection by > implementations or operators will be simplified if we had something like > this. > > > > All this to say, can we discuss a simpler solution via adding couple > > of new reply modes? :) > > > > I have another question. Draft mentions BFD. I understand the motive > behind wanting to control the reverse BFD path on uni-directional LSP. Bu= t I > don't quite see the entire picture by making use of path TLV. Let's say w= e > bootstrap BFD with LSP ping with path TLV with specific RSVP FEC, so that > reverse BFD packets are riding on specified RSVP FEC. That RSVP FEC can > become invalid at any time (ex: re-optimization takes place and LSP ID > changes). What happens then? > > > > Regards, > > Nobo > > > >> > >> Best regards, > >> Mach > >> > >>> > >>> I see the new TLV useful for specific scenarios, but I've been > >>> trying to see how things (implementations and operations) can be > >>> simplified for those non-specific > >>> (majority) of cases. Was something like above considered as part of > >>> this > >> draft? > >>> > >>> Regards, > >>> Nobo > >>> > >>> _______________________________________________ > >>> 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 > > >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From stephen.farrell@cs.tcd.ie Thu Aug 15 06:34:35 2013 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 2CC7C21F8EEA; Thu, 15 Aug 2013 06:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 yVfYRzrIs06W; Thu, 15 Aug 2013 06:34:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C217321F8D90; Thu, 15 Aug 2013 06:34:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130815133434.25448.80337.idtracker@ietfa.amsl.com> Date: Thu, 15 Aug 2013 06:34:34 -0700 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: [mpls] Stephen Farrell's Block on charter-ietf-mpls-05-01: (with BLOCK) 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, 15 Aug 2013 13:34:35 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-mpls-05-01: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-mpls/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- Just one little innocent question:-) This says: - Evolve key MPLS protocols, including LDP, tLDP, mLDP, RSVP-TE and LSP Ping to meet new requirements. and - Document mechanisms for securing MPLS networks in coordination with the KARP working group. Karp is precluded from considering confidentiality and its charter doesn't mention privacy. Assuming that MPLS might be used e.g. near the endpoints of transatlantic fibres, (is it?) do you think the WG might be open = to considering work on confidentiality/privacy, perpaps even on opportunistic encryption or the like? I guess one could argue that there are requirements there that have only recently = become clear. If this will go for external review I'm fine with asking the question on ietf@ietf.org and will unblock. If not, I'd appreciate a quick chat about this before I unblock. From adrian@olddog.co.uk Thu Aug 15 07:34:51 2013 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 A393521F999C; Thu, 15 Aug 2013 07:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[AWL=-0.111, 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 cjqS88MTIgch; Thu, 15 Aug 2013 07:34:45 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 645CB21F995B; Thu, 15 Aug 2013 07:34:45 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7FEYhJm014298; Thu, 15 Aug 2013 15:34:43 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7FEYgP5014255 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Aug 2013 15:34:43 +0100 From: "Adrian Farrel" To: "'Pete Resnick'" , "'The IESG'" References: <20130813011330.21644.1820.idtracker@ietfa.amsl.com> In-Reply-To: <20130813011330.21644.1820.idtracker@ietfa.amsl.com> Date: Thu, 15 Aug 2013 15:34:40 +0100 Message-ID: <005a01ce99c4$93a35e00$baea1a00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNOuffI2cB2U0DVtFOm1A3y+muYzpaWEY2Q Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] Pete Resnick's No Objection on charter-ietf-mpls-05-01: (with COMMENT) 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, 15 Aug 2013 14:34:51 -0000 Hi Pete, > "The responsibility includes..." >=20 > What an odd construction. Can better words be chosen? I will make it "The responsibilities of this working group include..." Although since the previous paragraph says "The MPLS working group is = responsible..." I would say it is PDO. > - Maintain existing MPLS requirements, mechanisms, and protocols, > in coordination with other working groups, e.g. CCAMP, PWE3 > and OPSAWG working groups. >=20 > I'm not sure what work item(s) you're talking about here. Is the WG > updating existing requirements documents and/or protocol documents in > response to new requirements from CCAMP, PWE3, and OPSAWG? Not clear > from what's said what is being referred to. We discussed in jabber. The coordination is because many of the protocols and procedures span = WGs, and because the requirements often come from other WGs. I will add "work in overlapping areas" I will add that the things what is maintained is in RFCs. > - Evolve key MPLS protocols, including LDP, tLDP, mLDP, RSVP-TE > and LSP Ping to meet new requirements. >=20 > Same question as above. "Evolve" is an odd word to choose, and I'm > curious if the list of protocols is exhaustive. Please clarify. "Evolve" is a warm and furry word. We should cherish it. The list of protocols is nearly exhaustive, but we got exhausted trying = to list them all. > - Determine MPLS-specific aspects of traffic engineering for > multi-areas/multi-AS in cooperation with the CCAMP WG >=20 > Is there a reason this bullet changed from the previous version? It = seems > to have removed the "and document it" part. The previous version read... | The first generation of the MPLS standards are largely complete,=20 | and the current WG work items are:=20 [snip] | - MPLS-specific aspects of traffic engineering for = multi-areas/multi-AS=20 | in cooperation with the CCAMP WG=20 I think it now says a little more, not less. > I'm not going to block this rechartering, but I would like to hear why > the charter became (apparently) more mushy than it had been. Ciao, Adrian From adrian@olddog.co.uk Thu Aug 15 07:46:04 2013 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 58B5821E8155; Thu, 15 Aug 2013 07:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[AWL=-0.091, 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 clCqvIuLUtvq; Thu, 15 Aug 2013 07:45:58 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3497821F944C; Thu, 15 Aug 2013 07:44:52 -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 r7FEikcn032378; Thu, 15 Aug 2013 15:44:46 +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 r7FEijDE032358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Aug 2013 15:44:45 +0100 From: "Adrian Farrel" To: "'Stephen Farrell'" , "'The IESG'" References: <20130815133434.25448.80337.idtracker@ietfa.amsl.com> In-Reply-To: <20130815133434.25448.80337.idtracker@ietfa.amsl.com> Date: Thu, 15 Aug 2013 15:44:42 +0100 Message-ID: <006201ce99c5$faaea680$f00bf380$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJqU1qHjF53ZSlOpLV3ZgTTXVM7Zphe4zrQ Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] Stephen Farrell's Block on charter-ietf-mpls-05-01: (with BLOCK) 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, 15 Aug 2013 14:46:04 -0000 Hi Stephen, > Just one little innocent question:-) >=20 > This says: >=20 > - Evolve key MPLS protocols, including LDP, tLDP, mLDP, RSVP-TE > and LSP Ping to meet new requirements. >=20 > and >=20 > - Document mechanisms for securing MPLS networks in coordination > with the KARP working group. >=20 > Karp is precluded from considering confidentiality and its charter > doesn't mention privacy.=20 Right. That makes the second bullet in your quote true and accurate. > Assuming that MPLS might be used e.g. near the endpoints of > transatlantic fibres, (is it?) do you think the WG might be open > to considering work on confidentiality/privacy, perpaps even on > opportunistic encryption or the like? I guess one could argue > that there are requirements there that have only recently > become clear. >=20 > If this will go for external review I'm fine with asking the question > on ietf@ietf.org and will unblock. I am asking that this does not go for external review so... > If not, I'd appreciate a quick chat about this before I unblock. The issue of confidentiality and privacy is definitely worth talking = about, both for the control plane and for the data plane.=20 I don't think we can drop a charter task in out of the blue since there = is no evidence the WG wants to work on this. However, if the scenarios = and high-level requirements were written up in an I-D it would: - fit within the first bullet you quoted and so be within scope for=20 WG discussions - possibly lead to a future recharter with a specific action OK? Cheers, Adrian From stephen.farrell@cs.tcd.ie Thu Aug 15 07:50:22 2013 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 AD41521F8FCE; Thu, 15 Aug 2013 07:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 MJxa6Z5byqBT; Thu, 15 Aug 2013 07:50:15 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5D12C21F85D4; Thu, 15 Aug 2013 07:50:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B7718BE53; Thu, 15 Aug 2013 15:50:04 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NA25qlJvyHIZ; Thu, 15 Aug 2013 15:50:04 +0100 (IST) Received: from [134.226.63.225] (cswireless63-225.scss.tcd.ie [134.226.63.225]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8C9D8BE3F; Thu, 15 Aug 2013 15:50:04 +0100 (IST) Message-ID: <520CEA9C.7040909@cs.tcd.ie> Date: Thu, 15 Aug 2013 15:50:04 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <20130815133434.25448.80337.idtracker@ietfa.amsl.com> <006201ce99c5$faaea680$f00bf380$@olddog.co.uk> In-Reply-To: <006201ce99c5$faaea680$f00bf380$@olddog.co.uk> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, 'The IESG' Subject: Re: [mpls] Stephen Farrell's Block on charter-ietf-mpls-05-01: (with BLOCK) 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, 15 Aug 2013 14:50:22 -0000 On 08/15/2013 03:44 PM, Adrian Farrel wrote: > Hi Stephen, > >> Just one little innocent question:-) >> >> This says: >> >> - Evolve key MPLS protocols, including LDP, tLDP, mLDP, RSVP-TE >> and LSP Ping to meet new requirements. >> >> and >> >> - Document mechanisms for securing MPLS networks in coordination >> with the KARP working group. >> >> Karp is precluded from considering confidentiality and its charter >> doesn't mention privacy. > > Right. That makes the second bullet in your quote true and accurate. > >> Assuming that MPLS might be used e.g. near the endpoints of >> transatlantic fibres, (is it?) do you think the WG might be open to >> considering work on confidentiality/privacy, perpaps even on >> opportunistic encryption or the like? I guess one could argue that >> there are requirements there that have only recently become clear. >> >> If this will go for external review I'm fine with asking the >> question on ietf@ietf.org and will unblock. > > I am asking that this does not go for external review so... > >> If not, I'd appreciate a quick chat about this before I unblock. > > The issue of confidentiality and privacy is definitely worth talking > about, both for the control plane and for the data plane. Great. > I don't think we can drop a charter task in out of the blue since > there is no evidence the WG wants to work on this. I agree. > However, if the > scenarios and high-level requirements were written up in an I-D it > would: - fit within the first bullet you quoted and so be within > scope for WG discussions - possibly lead to a future recharter with a > specific action > > OK? Yes. However, I'm sure that I don't know what'd be a good set of even high-level requirements. But I am quite happy to try work with others on that if it helps. I'll s/block/comment/ and we can chat on the call if we're still in chatting mood when we get to that. Or later if we're all chatted out today. Thanks, S. > > Cheers, Adrian > > > > From Malcolm.BETTS@zte.com.cn Thu Aug 15 10:01:15 2013 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 8681811E814C; Thu, 15 Aug 2013 10:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.998 X-Spam-Level: X-Spam-Status: No, score=-101.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kl6jIxgz5m3p; Thu, 15 Aug 2013 10:01:11 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id B204021F9A57; Thu, 15 Aug 2013 10:01:10 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id E4CCE134F4A5; Fri, 16 Aug 2013 01:00:33 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r7FH0jko047520; Fri, 16 Aug 2013 01:00:45 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <20ECF67871905846A80F77F8F4A27572102C229B@xmb-rcd-x09.cisco.com> References: <20ECF67871905846A80F77F8F4A27572102C229B@xmb-rcd-x09.cisco.com> To: "Eric Osborne (eosborne)" MIME-Version: 1.0 X-KeepSent: 99870CCC:73093D39-85257BC8:005BE222; 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, 15 Aug 2013 13:00:37 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-08-16 01:00:40, Serialize complete at 2013-08-16 01:00:40 Content-Type: multipart/alternative; boundary="=_alternative 005D7AE985257BC8_=" X-MAIL: mse01.zte.com.cn r7FH0jko047520 Cc: "mpls@ietf.org" , mpls-bounces@ietf.org Subject: Re: [mpls] Mode negotiation for PSC 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, 15 Aug 2013 17:01:15 -0000 X-List-Received-Date: Thu, 15 Aug 2013 17:01:15 -0000 This is a multipart message in MIME format. --=_alternative 005D7AE985257BC8_= Content-Type: text/plain; charset="US-ASCII" Hi Eric, I have only seen one message on this thread so I will venture an opinion. My preference is for option 1 - no negotiation. My reasons are: Keep it simple! The major reason that network operator's have given for requesting these enhanced capabilities is to maintain compatibility with existing linear protection schemes. Within the network of a single operator my assumption is that they want, above all else, consistent operation. Therefore, I suspect that we will see two "camps" with either all options active or no options active. Interconnection of "transport" connections between network operators is normally only allowed within the frame work of an agreement between the operators. As part of that agreement they would need to define the linear protection options that would be used. The operational differences would be confined to the links that provide the interconnection between networks of the different operators. The appropriate protection options would be configured (as defined by the agreement) when the protected connection is set-up. Negotiation would allow the possibility of a variety of protection options being active in the network which would result in inconsistent behaviour which would create operational complexity. Regards, Malcolm "Eric Osborne (eosborne)" Sent by: mpls-bounces@ietf.org 08/08/2013 08:34 AM To "mpls@ietf.org" cc Subject [mpls] Mode negotiation for PSC As per last Friday's presentation in Berlin ( http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt), we will be adding "ITU Mode" to PSC to allow for behaviors that satisfy both IETF and ITU requirements. This mode will be backward-compatible and negotiated using PSC TLVs. The drafts in that ppt define five capabilities which separate ITU mode from IETF mode. IETF mode is defined as the absence of these five capabilities, and ITU mode is defined as the use of all five of these capabilities. It may help to think of IETF mode as 00000 and ITU mode as 11111. The mechanism to define and negotiate these modes will have room for expansion past five bits, so if we ever decide we need more capabilities negotiation in PSC (shared mesh? m:n? other fancy stuff?) we can. As of right now we are only discussing two modes, but it is possible to define a mode which is some combination of these five things other than 00000 or 11111. So a mode is really the set of negotiated capabilities between two devices. There are two ways we can negotiate the use of one more or the other: 1) Each node announces the mode that it wants, and if the other side doesn't want exactly the same mode then PSC will not function. That is, both nodes say "my mode is 0bxxxxx" (for now, either 00000 or 11111) and if both nodes don't say the same thing then they complain to the operator and refuse to function. Advantage: easy, and if both ends are in a single administrative domain I expect the operator to be able to configure both ends to match. Disadvantage: tricky if we ever start talking about modes other than 00000 or 11111. I don't want a node to say "I support mode 00000, mode 00001, mode 00010, mode 00011, .... mode 11111" because if we add a few more capabilities we could end up announcing the support of hundreds or thousands of modes. Does not allow PSC to come up unless the modes match on both sides, even if there is some common subset they could both agree on. or 2) Each node announces the set of capabilities that it can support along with the ones that it requires, and if the two nodes can find a common subset of features then they will converge on those features in PSC. Advantage: flexible. If two endpoints can find a common feature subset (see example below) then they will come up. Disadvantage: more complex code, easier to get wrong and converge on a undesirable subset. Examples of each negotiation method are below, both for clarity and to demonstrate that method #2 works. My question for the WG is, which one would people prefer, and why? eric --------------------------------- Examples ======== All examples are between two nodes, A and Z. These examples focus on the actual negotiation, not on the necessary TLV bits to enable the negotiation. Example of method 1 ------------------- Node A sends a single TLV to Node Z containg the mode bitmap. Node Z sends the same to A. Call them A.Mode and Z.Mode. If they do not match then some default behavior happens - either PSC doesn't come up or they default to one predetermined mode. A.mode = Z. mode = 00000 A->Z: "I am configured for mode 00000" Z->A: "I am configured for mode 00000" This results in PSC coming up in IETF mode. A.mode = Z.mode = 11111 A->Z: "I am configured for mode 11111" Z->A: "I am configured for mode 11111" This results in PSC coming up in ITU mode. A.mode != Z.mode (say, 00001 and 00010) A->Z: "I am configured for mode 00001" Z->A: "I am configured for mode 00010" PSC does not come up. Example of method 2 ------------------- Both Node A and Node Z announce two things - Capabilities and Mask. Capabilities is a bitmap of the capabilities that are supported. Mask is a mask of don't-care bits against the Capabilities string. A 0 in Mask means "I don't care if we do this capability or not", and a 1 means "we must (or must not) agree on this capability in order to come up". A.capabilities = 00000 A.mask = 00000 This says "I am capable of supporting all capabilities and I don't care if we do any of them or not" A.capabilities = 00000 A.mask = 11111 This says "We must not use any of the optional capabilities" - Capabilities bits are all zero, and Mask bits say "we must agree that the corresponding capability is zero". This is 'IETF mode'. A.capabilities = 11111 A.mask = 11111 This is 'ITU Mode' Where it gets complicated (or awesome, depending on your perspective) is when you have various subsets. Consider: A.Capabilities == 01100 A.Mask == 01100 Z.Capabilities == 01110 Z.Mask == 01110 Negotiation procedures. Each side does: res = (A.Capabilites & Z.Mask) ^ (Z.Capabilities & A.Mask) res = (01100 & 01110) ^ (01110 & 01100) res = (01100) ^ (01100) res = 00000 if res == 0 then it is possible for both sides to find a common subset that they support. This common subset is called the 'negotiated set', and is determined by: negotiated_set = A.Capabilities | B.Capabilities negotiated_set = 01100 | 01110 negotiated_set = 01100 if res != 0 then it is impossible to find a subset that the two ends can agree on, and PSC will never come up. Once each side computes the negotiated set, they signal it and PSC starts to work. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --=_alternative 005D7AE985257BC8_= Content-Type: text/html; charset="US-ASCII" Hi Eric,

I have only seen one message on this thread so I will venture an opinion.

My preference is for option 1 - no negotiation.

My reasons are:

Keep it simple!

The major reason that network operator's have given for requesting these enhanced capabilities is to maintain compatibility with existing linear protection schemes. Within the network of a single operator my assumption is that they want, above all else, consistent operation.  Therefore, I suspect that we will see two "camps" with either all options active or no options active.

Interconnection of "transport" connections between network operators is normally only allowed within the frame work of an agreement between the operators. As part of that agreement they would need to define the linear protection options that would be used. The operational differences would be confined to the links that provide the interconnection between networks of the different operators. The appropriate protection options would be configured (as defined by the agreement) when the protected connection is set-up.

Negotiation would allow the possibility of a variety of protection options being active in the network which would result in inconsistent behaviour which would create operational complexity.

Regards,

Malcolm




"Eric Osborne (eosborne)" <eosborne@cisco.com>
Sent by: mpls-bounces@ietf.org

08/08/2013 08:34 AM

To
"mpls@ietf.org" <mpls@ietf.org>
cc
Subject
[mpls] Mode negotiation for PSC





As per last Friday's presentation in Berlin (http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt), we will be adding "ITU Mode" to PSC to allow for behaviors that satisfy both IETF and ITU requirements.  This mode will be backward-compatible and negotiated using PSC TLVs.  

The drafts in that ppt define five capabilities which separate ITU mode from IETF mode.  IETF mode is defined as the absence of these five capabilities, and ITU mode is defined as the use of all five of these capabilities.  It may help to think of IETF mode as 00000 and ITU mode as 11111.  The mechanism to define and negotiate these modes will have room for expansion past five bits, so if we ever decide we need more capabilities negotiation in PSC (shared mesh?  m:n?  other fancy stuff?) we can.  

As of right now we are only discussing two modes, but it is possible to define a mode which is some combination of these five things other than 00000 or 11111.  So a mode is really the set of negotiated capabilities between two devices.

There are two ways we can negotiate the use of one more or the other:

1) Each node announces the mode that it wants, and if the other side doesn't want exactly the same mode then PSC will not function.  That is, both nodes say "my mode is 0bxxxxx" (for now, either 00000 or 11111) and if both nodes don't say the same thing then they complain to the operator and refuse to function.

Advantage: easy, and if both ends are in a single administrative domain I expect the operator to be able to configure both ends to match.

Disadvantage: tricky if we ever start talking about modes other than 00000 or 11111.  I don't want a node to say "I support mode 00000, mode 00001, mode 00010, mode 00011, .... mode 11111" because if we add a few more capabilities we could end up announcing the support of hundreds or thousands of modes.  Does not allow PSC to come up unless the modes match on both sides, even if there is some common subset they could both agree on.


or


2) Each node announces the set of capabilities that it can support along with the ones that it requires, and if the two nodes can find a common subset of features then they will converge on those features in PSC.

Advantage: flexible.  If two endpoints can find a common feature subset (see example below) then they will come up.

Disadvantage: more complex code, easier to get wrong and converge on a undesirable subset.


Examples of each negotiation method are below, both for clarity and to demonstrate that method #2 works.  My question for the WG is, which one would people prefer, and why?






eric


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


Examples
========
All examples are between two nodes, A and Z.  These examples focus on the actual negotiation, not on the necessary TLV bits to enable the negotiation.

Example of method 1
-------------------
Node A sends a single TLV to Node Z containg the mode bitmap.  Node Z sends the same to A.  Call them A.Mode and Z.Mode.  If they do not match then some default behavior happens - either PSC doesn't come up or they default to one predetermined mode.

A.mode = Z. mode = 00000
A->Z: "I am configured for mode 00000"
Z->A: "I am configured for mode 00000"

This results in PSC coming up in IETF mode.

A.mode = Z.mode = 11111
A->Z: "I am configured for mode 11111"
Z->A: "I am configured for mode 11111"

This results in PSC coming up in ITU mode.

A.mode != Z.mode (say, 00001 and 00010)
A->Z: "I am configured for mode 00001"
Z->A: "I am configured for mode 00010"

PSC does not come up.



Example of method 2
-------------------
Both Node A and Node Z announce two things - Capabilities and Mask.
Capabilities is a bitmap of the capabilities that are supported.
Mask is a mask of don't-care bits against the Capabilities string.  A 0 in Mask means "I don't care if we do this capability or not", and a 1 means "we must (or must not) agree on this capability in order to come up".

A.capabilities = 00000
A.mask         = 00000

This says "I am capable of supporting all capabilities and I don't care if we do any of them or not"

A.capabilities = 00000
A.mask         = 11111

This says "We must not use any of the optional capabilities" - Capabilities bits are all zero, and Mask bits say "we must agree that the corresponding capability is zero".  This is 'IETF mode'.

A.capabilities = 11111
A.mask         = 11111

This is 'ITU Mode'

Where it gets complicated (or awesome, depending on your perspective) is when you have various subsets.  Consider:

A.Capabilities == 01100
A.Mask == 01100

Z.Capabilities == 01110
Z.Mask == 01110


Negotiation procedures.
Each side does:


res = (A.Capabilites & Z.Mask) ^ (Z.Capabilities & A.Mask)
res = (01100 & 01110) ^ (01110 & 01100)
res = (01100) ^ (01100)
res = 00000

if res == 0 then it is possible for both sides to find a common subset that they support.
This common subset is called the 'negotiated set', and is determined by:

negotiated_set = A.Capabilities | B.Capabilities
negotiated_set = 01100 | 01110
negotiated_set = 01100

if res != 0 then it is impossible to find a subset that the two ends can agree on, and PSC will never come up.

Once each side computes the negotiated set, they signal it and PSC starts to work.
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--=_alternative 005D7AE985257BC8_=-- From huubatwork@gmail.com Thu Aug 15 12:12:16 2013 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 E42A411E8213 for ; Thu, 15 Aug 2013 12:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] 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 zd7cK0kJXWZD for ; Thu, 15 Aug 2013 12:12:16 -0700 (PDT) Received: from mail-ee0-x22b.google.com (mail-ee0-x22b.google.com [IPv6:2a00:1450:4013:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B73F211E8156 for ; Thu, 15 Aug 2013 12:12:15 -0700 (PDT) Received: by mail-ee0-f43.google.com with SMTP id e52so552533eek.16 for ; Thu, 15 Aug 2013 12:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=eqB5WVZCQz9+NLMDLJbRC9GJpTc81iUI9e/FbzyR4qc=; b=h2RESWAzw+bRZ2jBish37graDeLKJXFJhS36Sgrjec74R7ZwZ52vy4yK2j6J+uR3Cb h3lcnH2VrdfUFOctUR+e9AmB4TtwpSRvYcmlNpYYLXUbB5yXEPxtztgHKpk7oIGoorGS LhOtRUGT18IYbB9zBUQNyC8yG3B2LfNYrcjChJE6HvUlOyRG20DmEL26ZGKC828+RYvJ NOKU0efkB+jqk7xEdISz9grEw7kOgTrzpoljmMnDKFOjdfHQeaM7yl+/WqcMjY2uxNY4 HX7FhLK5YmLXwM7iJN/eEqNhfLfXSrUpfLceSBoEi1YaooHJt9e5f1SDycxk4uvimSPQ 2UvQ== X-Received: by 10.15.54.199 with SMTP id t47mr24337881eew.46.1376593934839; Thu, 15 Aug 2013 12:12:14 -0700 (PDT) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id d8sm878825eeh.8.2013.08.15.12.12.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Aug 2013 12:12:14 -0700 (PDT) Message-ID: <520D280D.1080206@gmail.com> Date: Thu, 15 Aug 2013 21:12:13 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mpls@ietf.org References: <20ECF67871905846A80F77F8F4A27572102C229B@xmb-rcd-x09.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mpls] Mode negotiation for PSC 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: Thu, 15 Aug 2013 19:12:17 -0000 Hello Malcolm, I also support the first way of "negotiation" described by Eric. In addition to your reasons: This way is very easy to test, it passes or it fails. If it passes both ends were provisioned correctly, if it fails the provisioning was wrong, the report can include the received set of options for verification. This works also in case the operator provisions only a subset of all supported options. There is also no need to advertise multiple modes as Eric describes. Best regards, Huub. =================== > I have only seen one message on this thread so I will venture an opinion. > > My preference is for option 1 - no negotiation. > > My reasons are: > > Keep it simple! > > The major reason that network operator's have given for requesting these > enhanced capabilities is to maintain compatibility with existing linear > protection schemes. Within the network of a single operator my > assumption is that they want, above all else, consistent operation. > Therefore, I suspect that we will see two "camps" with either all > options active or no options active. > > Interconnection of "transport" connections between network operators is > normally only allowed within the frame work of an agreement between the > operators. As part of that agreement they would need to define the > linear protection options that would be used. The operational > differences would be confined to the links that provide the > interconnection between networks of the different operators. The > appropriate protection options would be configured (as defined by the > agreement) when the protected connection is set-up. > > Negotiation would allow the possibility of a variety of protection > options being active in the network which would result in inconsistent > behaviour which would create operational complexity. > > Regards, > > Malcolm > > > > > *"Eric Osborne (eosborne)" * > Sent by: mpls-bounces@ietf.org > > 08/08/2013 08:34 AM > > > To > "mpls@ietf.org" > cc > > Subject > [mpls] Mode negotiation for PSC > > As per last Friday's presentation in Berlin > (http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt), we > will be adding "ITU Mode" to PSC to allow for behaviors that satisfy > both IETF and ITU requirements. This mode will be backward-compatible > and negotiated using PSC TLVs. > > The drafts in that ppt define five capabilities which separate ITU mode > from IETF mode. IETF mode is defined as the absence of these five > capabilities, and ITU mode is defined as the use of all five of these > capabilities. It may help to think of IETF mode as 00000 and ITU mode > as 11111. The mechanism to define and negotiate these modes will have > room for expansion past five bits, so if we ever decide we need more > capabilities negotiation in PSC (shared mesh? m:n? other fancy stuff?) > we can. > > As of right now we are only discussing two modes, but it is possible to > define a mode which is some combination of these five things other than > 00000 or 11111. So a mode is really the set of negotiated capabilities > between two devices. > > There are two ways we can negotiate the use of one more or the other: > > 1) Each node announces the mode that it wants, and if the other side > doesn't want exactly the same mode then PSC will not function. That is, > both nodes say "my mode is 0bxxxxx" (for now, either 00000 or 11111) and > if both nodes don't say the same thing then they complain to the > operator and refuse to function. > > Advantage: easy, and if both ends are in a single administrative domain > I expect the operator to be able to configure both ends to match. > > Disadvantage: tricky if we ever start talking about modes other than > 00000 or 11111. I don't want a node to say "I support mode 00000, mode > 00001, mode 00010, mode 00011, .... mode 11111" because if we add a few > more capabilities we could end up announcing the support of hundreds or > thousands of modes. Does not allow PSC to come up unless the modes > match on both sides, even if there is some common subset they could both > agree on. > > > or > > > 2) Each node announces the set of capabilities that it can support along > with the ones that it requires, and if the two nodes can find a common > subset of features then they will converge on those features in PSC. > > Advantage: flexible. If two endpoints can find a common feature subset > (see example below) then they will come up. > > Disadvantage: more complex code, easier to get wrong and converge on a > undesirable subset. > > > Examples of each negotiation method are below, both for clarity and to > demonstrate that method #2 works. My question for the WG is, which one > would people prefer, and why? > > > > > > > eric > > > --------------------------------- > > > Examples > ======== > All examples are between two nodes, A and Z. These examples focus on > the actual negotiation, not on the necessary TLV bits to enable the > negotiation. > > Example of method 1 > ------------------- > Node A sends a single TLV to Node Z containg the mode bitmap. Node Z > sends the same to A. Call them A.Mode and Z.Mode. If they do not match > then some default behavior happens - either PSC doesn't come up or they > default to one predetermined mode. > > A.mode = Z. mode = 00000 > A->Z: "I am configured for mode 00000" > Z->A: "I am configured for mode 00000" > > This results in PSC coming up in IETF mode. > > A.mode = Z.mode = 11111 > A->Z: "I am configured for mode 11111" > Z->A: "I am configured for mode 11111" > > This results in PSC coming up in ITU mode. > > A.mode != Z.mode (say, 00001 and 00010) > A->Z: "I am configured for mode 00001" > Z->A: "I am configured for mode 00010" > > PSC does not come up. > > > > Example of method 2 > ------------------- > Both Node A and Node Z announce two things - Capabilities and Mask. > Capabilities is a bitmap of the capabilities that are supported. > Mask is a mask of don't-care bits against the Capabilities string. A 0 > in Mask means "I don't care if we do this capability or not", and a 1 > means "we must (or must not) agree on this capability in order to come up". > > A.capabilities = 00000 > A.mask = 00000 > > This says "I am capable of supporting all capabilities and I don't care > if we do any of them or not" > > A.capabilities = 00000 > A.mask = 11111 > > This says "We must not use any of the optional capabilities" - > Capabilities bits are all zero, and Mask bits say "we must agree that > the corresponding capability is zero". This is 'IETF mode'. > > A.capabilities = 11111 > A.mask = 11111 > > This is 'ITU Mode' > > Where it gets complicated (or awesome, depending on your perspective) is > when you have various subsets. Consider: > > A.Capabilities == 01100 > A.Mask == 01100 > > Z.Capabilities == 01110 > Z.Mask == 01110 > > > Negotiation procedures. > Each side does: > > > res = (A.Capabilites & Z.Mask) ^ (Z.Capabilities & A.Mask) > res = (01100 & 01110) ^ (01110 & 01100) > res = (01100) ^ (01100) > res = 00000 > > if res == 0 then it is possible for both sides to find a common subset > that they support. > This common subset is called the 'negotiated set', and is determined by: > > negotiated_set = A.Capabilities | B.Capabilities > negotiated_set = 01100 | 01110 > negotiated_set = 01100 > > if res != 0 then it is impossible to find a subset that the two ends can > agree on, and PSC will never come up. > > Once each side computes the negotiated set, they signal it and PSC > starts to work. > _______________________________________________ > 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 wyaacov@gmail.com Thu Aug 15 12:40:07 2013 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 2F6D321F9A90 for ; Thu, 15 Aug 2013 12:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7N1-3qYZImh for ; Thu, 15 Aug 2013 12:40:05 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 61E4621F84A8 for ; Thu, 15 Aug 2013 12:40:05 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id c11so886265wgh.8 for ; Thu, 15 Aug 2013 12:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=KMGp0BUH6pJceg1im6eV0D8lTIugkw6sLPTttSKn8vw=; b=NRI/pFqpCGvCIXXFmLmS9XMoW/U+NiAu6sOeWSYIbJvtximrtd2BninI3pjFTeTAns 1D5nsBcymBd7uYBZ6najXlGeh8eydozVuMR3QzvUs5dDxDMRfrudks+l0KDGHAjYvcIp GSFjCuc+hNIZQQFCLLExe/0hKY/9yHV5zgAgcJiZ1trHQAJFKJOSNu2x33L4fuvn2bFS boxjCjdPqrNPNyk3E5rrg7yjaYtr5+hpxV8DkU3z9EdIEPZueNNGroFzHTFdSXnml9/n rlgiMfFYdICGxVkAeNfXjYa3GOILO3fcLh7SncNN6GCAEjyTGeIbe34pG1wlebtGhxeF UrMA== MIME-Version: 1.0 X-Received: by 10.194.173.163 with SMTP id bl3mr11392110wjc.10.1376595592956; Thu, 15 Aug 2013 12:39:52 -0700 (PDT) Received: by 10.194.164.200 with HTTP; Thu, 15 Aug 2013 12:39:52 -0700 (PDT) Date: Thu, 15 Aug 2013 22:39:52 +0300 Message-ID: From: Yaacov Weingarten To: loa@pi.nu, mpls@ietf.org, draft-rhd-mpls-tp-psc-priority@tools.ietf.org, mpls-chairs@tools.ietf.org, martin.vigoureux@alcatel-lucent.com Content-Type: multipart/alternative; boundary=089e013c6220514efd04e401a3cb Subject: [mpls] MPLS-RT review of draft-rhd-mpls-tp-psc-priority 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, 15 Aug 2013 19:40:07 -0000 --089e013c6220514efd04e401a3cb Content-Type: text/plain; charset=ISO-8859-1 Hi, I was requested to conduct an initial review of draft-rhd-mpls-tp-psc-priority-01 as part of the effort to determine if the draft is suited for a WG adoption poll. I have read the draft and have the following notes: 1. I find it rather disconcerting that the draft is referencing a LS that was received from the ITU. While I am sure that the points rasied in the LS as very well thought out and pertinent, I cannot see that the LS should be considered a "standards document" that could be referenced by a future RFC. At best, the LS could be considered a "contribution" at an ITU meeting, and I do not believe that an ITU document would reference a contribution! I therefore think that the authors should transfer into the draft whatever information they feel is appropriate from said LS. 2. In general, the draft is addressing itself to two topics regarding RFC6378, a. Change of relative priority between SF-P and FS - the suggestion is essentially to rollback the relevant changes that were made to the RFC during the final IESG review to the version previous to that review. b. Change of relative priority between ClearSF and SF/SD. This is based on a particular use-case that is mentioned in the referenced LS, and that I suggested be explicitly explained in the draft. c. Introduce (in an appendix) the use of a Freeze command. Not sure what the motivation for this in this context is. In my opinion, all three of the points are valid for work by the WG and should be fully discussed in the WG prior to publication of the draft - but could be discussed as part of a WG draft. 3. The format of the draft is also rather interesting - it seems to be presenting an errata note to RFC6378 rather than describing the desired behavior. I leave it to the WG Chairs to decide what is the best format for the draft moving forward. 4. One other note regarding this draft in the context of several other drafts that are proposing changes to the PSC protocol for MPLS-TP Linear Protection. I think that some of these should be combined into a more robust proposal for the sake of the implementers. Otherwise, there may be a need for a future "reader's guide" for an implementer to figure out what is in PSC and what is no longer there! Bottom line - I think that this draft presents valid points, it should be corrected to not reference the ITU LS prior to acceptance as a WG draft. And the WG should strongly consider consolidating this work with some of the other drafts to make a more complete and consistent definition of PSC available. Hope this helps, -- Thanx and BR, yaacov *Still looking for new opportunity* --089e013c6220514efd04e401a3cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
I was requested to conduc= t an initial review of draft-rhd-mpls-tp-psc-priority-01 as part of the eff= ort to determine if the draft is suited for a WG adoption poll. I have read= the draft and have the following notes:
=A0
1. I find it rather disconcerting that the draft is refe= rencing a LS that was received from the ITU. While I am sure that the point= s rasied in the LS as very well thought out and pertinent, I cannot see tha= t the LS should be considered a "standards document" that could b= e referenced by a future RFC. At best, the LS could be considered a "c= ontribution" at an ITU meeting, and I do not believe that an ITU docum= ent would reference a contribution! I therefore think that the authors shou= ld transfer into the draft whatever information they feel is appropriate fr= om said LS.
=A0
2. In general, the draft is addressing itself to two top= ics regarding RFC6378,
a. Change of relative priority between SF= -P and FS - the suggestion is essentially to rollback the relevant changes = that were made to the RFC during the final IESG review to the version previ= ous to that review.
=A0
b. Change of relative priority between ClearSF and SF/SD= . This is based on a particular use-case that is mentioned in the reference= d LS, and that I suggested be explicitly explained in the draft.
=A0
c. Introduce (in an appendix) the use of a Freeze command. No= t sure what the motivation for this in this context is.
=A0
=
In my opinion, all three of the points are valid for work by the WG an= d should be fully discussed in the WG prior to publication of the draft - b= ut could be discussed as part of a WG draft.
=A0
3. The format of the draft is also rather interesting - = it seems to be presenting an errata note to RFC6378 rather than describing = the desired behavior. I leave it to the WG Chairs to decide what is the bes= t format for the draft moving forward.
=A0
4. One other note regarding this draft in the context of= several other drafts that are proposing changes to the PSC protocol for MP= LS-TP Linear Protection. I think that some of these should be combined into= a more robust proposal for the sake of the implementers. Otherwise, there = may be a need for a future "reader's guide" for an implemente= r to figure out what is in PSC and what is no longer there!
=A0
Bottom line - I think that this draft presents valid poi= nts, it should be corrected to not reference the ITU LS prior to acceptance= as a WG draft. And the WG should strongly consider consolidating this work= with some of the other drafts to make a more complete and consistent defin= ition of PSC available.
=A0
Hope this helps,

--
Thanx and BR,
yaacov

Still look= ing for new opportunity
--089e013c6220514efd04e401a3cb-- From rcallon@juniper.net Thu Aug 15 14:12:08 2013 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 89BE711E818F for ; Thu, 15 Aug 2013 14:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.839 X-Spam-Level: X-Spam-Status: No, score=-99.839 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, 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 BEejWQErxIU1 for ; Thu, 15 Aug 2013 14:12:01 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 958BB11E817E for ; Thu, 15 Aug 2013 14:12:01 -0700 (PDT) Received: from mail88-co1-R.bigfish.com (10.243.78.230) by CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id 14.1.225.22; Thu, 15 Aug 2013 21:12:00 +0000 Received: from mail88-co1 (localhost [127.0.0.1]) by mail88-co1-R.bigfish.com (Postfix) with ESMTP id E328FBE0297; Thu, 15 Aug 2013 21:12:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zz9371Ic85fh4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h1c8fb4h1de096h8275bh8275dh1de097hz2fh2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail88-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(189002)(199002)(164054003)(56816003)(77096001)(65816001)(18717965001)(47446002)(81542001)(47976001)(74366001)(81342001)(83072001)(15202345003)(74502001)(19580395003)(16406001)(16236675002)(19580405001)(81816001)(19580385001)(74662001)(81686001)(19300405004)(83322001)(49866001)(76482001)(76576001)(76786001)(74706001)(4396001)(53806001)(51856001)(33646001)(76796001)(69226001)(31966008)(74876001)(54316002)(54356001)(66066001)(50986001)(79102001)(63696002)(77982001)(47736001)(59766001)(74316001)(80976001)(46102001)(80022001)(56776001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB072; H:BLUPR05MB070.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail88-co1 (localhost.localdomain [127.0.0.1]) by mail88-co1 (MessageSwitch) id 1376601118867535_27799; Thu, 15 Aug 2013 21:11:58 +0000 (UTC) Received: from CO1EHSMHS012.bigfish.com (unknown [10.243.78.248]) by mail88-co1.bigfish.com (Postfix) with ESMTP id C3EEA16004A; Thu, 15 Aug 2013 21:11:58 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS012.bigfish.com (10.243.66.22) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 15 Aug 2013 21:11:58 +0000 Received: from BLUPR05MB072.namprd05.prod.outlook.com (10.255.214.27) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.347.3; Thu, 15 Aug 2013 21:11:35 +0000 Received: from BLUPR05MB070.namprd05.prod.outlook.com (10.255.214.15) by BLUPR05MB072.namprd05.prod.outlook.com (10.255.214.27) with Microsoft SMTP Server (TLS) id 15.0.731.16; Thu, 15 Aug 2013 21:11:32 +0000 Received: from BLUPR05MB070.namprd05.prod.outlook.com ([169.254.15.164]) by BLUPR05MB070.namprd05.prod.outlook.com ([169.254.15.164]) with mapi id 15.00.0731.000; Thu, 15 Aug 2013 21:11:32 +0000 From: Ross Callon To: "mpls@ietf.org" , "draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org" Thread-Topic: CLosed, MPLS WG last call on draft-ietf-mpls-tp-rosetta-stone-11.txt Thread-Index: AQHOiBXOGyaLMJ0V/0ufIkWYEqyzEJmW4Gyg Date: Thu, 15 Aug 2013 21:11:32 +0000 Message-ID: References: <62CCD4C52ACDAD4481149BD5D8A72FD316D78B3E@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316D78B3E@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0939529DE2 Content-Type: multipart/alternative; boundary="_000_c4fe03d62ef44a859f4f2e35f779f6a9BLUPR05MB070namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%ALCATEL-LUCENT.COM$RO%1$TLS%0$FQDN%$TlsDn% Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] CLosed, MPLS WG last call on draft-ietf-mpls-tp-rosetta-stone-11.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: Thu, 15 Aug 2013 21:12:08 -0000 --_000_c4fe03d62ef44a859f4f2e35f779f6a9BLUPR05MB070namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This last call has now ended, with solid support and no opposition. There have been a few comments regarding updates that should be made to the= document before we request publication. Authors, please update the docume= nt according to comments received. After the document is updated I will sub= mit it to our AD for publication. Thanks, Ross From: Ross Callon [mailto:rcallon@juniper.net] Sent: Tuesday, July 23, 2013 10:31 PM To: mpls@ietf.org; draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux Subject: MPLS WG last call on draft-ietf-mpls-tp-rosetta-stone-11.txt Working Group, This is to start Working Group last call on draft-ietf-mpls-tp-rosetta-sto= ne-11.txt Please send your comments to the mpls working group mailing list (mpls@ietf= .org). Please send both technical comments, and (if you are happy with the documen= t as is) also send indications of support. There are no IPR claims against this draft. The co-authors have stated that= they are not aware of any IPR applicable to this draft. If anyone else in the working gr= oup is aware of IPRs claims against this draft, the time to disclose that is now. Due to the upcoming IETF meeting in Berlin, this last call will be extended= by an extra week (which implies that the last call will be ongoing during the IETF meeting).= This working group last call will end on August 14, 2013. Ross for the wg co-chairs --_000_c4fe03d62ef44a859f4f2e35f779f6a9BLUPR05MB070namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This last call has now en= ded, with solid support and no opposition.

 <= /p>

There have been a few com= ments regarding updates that should be made to the document before we reque= st publication.  Authors, please update the document according to comments received. After the document is updated I will submit it to ou= r AD for publication.

 <= /p>

Thanks, Ross

 <= /p>

From: Ross Cal= lon [mailto:rcallon@juniper.net]
Sent: Tuesday, July 23, 2013 10:31 PM
To: mpls@ietf.org; draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux
Subject: MPLS WG last call on draft-ietf-mpls-tp-rosetta-stone-11.tx= t

 

Working Group,

 

This = is to start Working Group last call on  draft-ietf-mpls-tp-rosetta-stone-11.txt

 

Please send your comments to the mpls w= orking group mailing list (mpls@ietf.org).

 

Please send both technical comments, an= d (if you are happy with the document as is)

also send indications of support.

 

There are no IPR claims against this dr= aft. The co-authors have stated that they are not

aware of any IPR applicable to this draft. <= /span>If anyone else in the working group is aware of

IPRs claims against this draft, the time to disclose that is now.

 

Due to the upcoming IETF meeting in Ber= lin, this last call will be extended by an extra week

(which implies that the last call will = be ongoing during the IETF meeting). This working group

last call will end on August 14, 2013.

 

Ross

for the wg co-chairs<= /p>

 <= /p>

--_000_c4fe03d62ef44a859f4f2e35f779f6a9BLUPR05MB070namprd05pro_-- From tochio@jp.fujitsu.com Thu Aug 15 16:16:18 2013 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 C334811E80E8 for ; Thu, 15 Aug 2013 16:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, J_CHICKENPOX_14=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 0VlO6DUHElAE for ; Thu, 15 Aug 2013 16:16:14 -0700 (PDT) Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by ietfa.amsl.com (Postfix) with ESMTP id 2150711E8176 for ; Thu, 15 Aug 2013 16:16:13 -0700 (PDT) Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71]) by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id D7F683EE0AE for ; Fri, 16 Aug 2013 08:16:11 +0900 (JST) Received: from smail (m1 [127.0.0.1]) by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id C6C8845DE59 for ; Fri, 16 Aug 2013 08:16:11 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91]) by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id B0CE045DE55 for ; Fri, 16 Aug 2013 08:16:11 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id A01FDE08001 for ; Fri, 16 Aug 2013 08:16:11 +0900 (JST) Received: from flabmail.flab.fujitsu.co.jp (flabmail.flab.fujitsu.co.jp [10.25.192.37]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 56ACD1DB803F for ; Fri, 16 Aug 2013 08:16:11 +0900 (JST) Received: from vskawa.flab.fujitsu.co.jp (vskawa.flab.fujitsu.co.jp [10.25.192.39]) by flabmail.flab.fujitsu.co.jp (8.14.4/8.14.4/110310-Fujitsu Labs. Domain Mail Master) with ESMTP id r7FNGBLj025283 for ; Fri, 16 Aug 2013 08:16:11 +0900 (JST) X-AuditID: 0a19c027-b7f7a8e000000f25-fd-520d613b2baf Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.105]) by vskawa.flab.fujitsu.co.jp (Symantec Messaging Gateway) with SMTP id 50.19.03877.B316D025; Fri, 16 Aug 2013 08:16:11 +0900 (JST) Received: from [127.0.0.1] (dhcp61.dream.flab.fujitsu.co.jp [10.25.144.194]) by dm.kawasaki.flab.fujitsu.co.jp (8.14.4/8.14.4) with ESMTP id r7FNG8YV030374 for ; Fri, 16 Aug 2013 08:16:11 +0900 X-SecurityPolicyCheck: OK by SHieldMailChecker v1.8.4 Message-ID: <520D60DF.5060404@jp.fujitsu.com> Date: Fri, 16 Aug 2013 08:14:39 +0900 From: Yuji Tochio User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mpls@ietf.org References: <20ECF67871905846A80F77F8F4A27572102C229B@xmb-rcd-x09.cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090003070604010005050902" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsXCJXkgU9c6kTfI4GE7j8WtpStZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0fpjDVvB5U2MFZs6rrM3MP6v7GLk5JAQMJG48+ELK4QtJnHh 3nq2LkYuDiGBx4wSy/+cZAJJCAlcYZTYvRyqwVRi4rpnjF2MHBy8AroS8yeag4RZBFQlNvx5 ClbOJqApcW3mHUYQW1QgWGL342dg83kFBCVOznzCAmKLANnTrh4Fs4UFdCROXd/ACLF3MqNE z6e3YA2cQM0Xnl4GG8QsECYxa8INtgmM/LOQzJqFJAVh60rcPPGRCcKWl9j+dg4zhK0j8b75 Ijuy+AJGtlWMkmXF2YnliXppOYlJemmlWZklxaV6yfl6WQWbGCHBq76D8dkizUOMAhyMSjy8 X+ZxBwmxJpYVV+YeYpTgYFYS4V2nwhskxJuSWFmVWpQfX1Sak1p8iJGJg1OqgTFjWQq/0+5N sfofrFdpT17M8DjlRxLngvXqRqLl/6X1/vJ6mP7gNOwpjFrYrZk88XvV8gdbc1YqyHbVPk4o 1bvHZb2Piev9hIt6mdMYbC4f0T+Yc//lzZL9Ffv8Mx8/E+HKvnXW9WWB8p2ZqkIHKzv5bvPK z2wqE1qZyny42V21K2G2rpqQmRJLcUaioRZzUXEiAL0ajZs8AgAA Subject: Re: [mpls] Mode negotiation for PSC 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, 15 Aug 2013 23:16:18 -0000 This is a multi-part message in MIME format. --------------090003070604010005050902 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi Eric and all My preference is option 1 and I also ask for the No negotioation. Rather than (As well as) negotiation, the configuration to NE can also safisty the case in transport network. Regards, Yuji (2013/08/16 2:00), Malcolm.BETTS@zte.com.cn wrote: > Hi Eric, > > I have only seen one message on this thread so I will venture an opinion. > > My preference is for option 1 - no negotiation. > > My reasons are: > > Keep it simple! > > The major reason that network operator's have given for requesting these enhanced capabilities is to maintain compatibility with existing linear protection > schemes. Within the network of a single operator my assumption is that they want, above all else, consistent operation. Therefore, I suspect that we will see > two "camps" with either all options active or no options active. > > Interconnection of "transport" connections between network operators is normally only allowed within the frame work of an agreement between the operators. As > part of that agreement they would need to define the linear protection options that would be used. The operational differences would be confined to the links > that provide the interconnection between networks of the different operators. The appropriate protection options would be configured (as defined by the > agreement) when the protected connection is set-up. > > Negotiation would allow the possibility of a variety of protection options being active in the network which would result in inconsistent behaviour which > would create operational complexity. > > Regards, > > Malcolm > > > > > *"Eric Osborne (eosborne)" * > Sent by: mpls-bounces@ietf.org > > 08/08/2013 08:34 AM > > > To > "mpls@ietf.org" > cc > > Subject > [mpls] Mode negotiation for PSC > > > > > > > > > > As per last Friday's presentation in Berlin (http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt), we will be adding "ITU Mode" to PSC to allow > for behaviors that satisfy both IETF and ITU requirements. This mode will be backward-compatible and negotiated using PSC TLVs. > > The drafts in that ppt define five capabilities which separate ITU mode from IETF mode. IETF mode is defined as the absence of these five capabilities, and > ITU mode is defined as the use of all five of these capabilities. It may help to think of IETF mode as 00000 and ITU mode as 11111. The mechanism to define > and negotiate these modes will have room for expansion past five bits, so if we ever decide we need more capabilities negotiation in PSC (shared mesh? m:n? > other fancy stuff?) we can. > > As of right now we are only discussing two modes, but it is possible to define a mode which is some combination of these five things other than 00000 or > 11111. So a mode is really the set of negotiated capabilities between two devices. > > There are two ways we can negotiate the use of one more or the other: > > 1) Each node announces the mode that it wants, and if the other side doesn't want exactly the same mode then PSC will not function. That is, both nodes say > "my mode is 0bxxxxx" (for now, either 00000 or 11111) and if both nodes don't say the same thing then they complain to the operator and refuse to function. > > Advantage: easy, and if both ends are in a single administrative domain I expect the operator to be able to configure both ends to match. > > Disadvantage: tricky if we ever start talking about modes other than 00000 or 11111. I don't want a node to say "I support mode 00000, mode 00001, mode 00010, > mode 00011, .... mode 11111" because if we add a few more capabilities we could end up announcing the support of hundreds or thousands of modes. Does not > allow PSC to come up unless the modes match on both sides, even if there is some common subset they could both agree on. > > > or > > > 2) Each node announces the set of capabilities that it can support along with the ones that it requires, and if the two nodes can find a common subset of > features then they will converge on those features in PSC. > > Advantage: flexible. If two endpoints can find a common feature subset (see example below) then they will come up. > > Disadvantage: more complex code, easier to get wrong and converge on a undesirable subset. > > > Examples of each negotiation method are below, both for clarity and to demonstrate that method #2 works. My question for the WG is, which one would people > prefer, and why? > > > > > > > eric > > > --------------------------------- > > > Examples > ======== > All examples are between two nodes, A and Z. These examples focus on the actual negotiation, not on the necessary TLV bits to enable the negotiation. > > Example of method 1 > ------------------- > Node A sends a single TLV to Node Z containg the mode bitmap. Node Z sends the same to A. Call them A.Mode and Z.Mode. If they do not match then some default > behavior happens - either PSC doesn't come up or they default to one predetermined mode. > > A.mode = Z. mode = 00000 > A->Z: "I am configured for mode 00000" > Z->A: "I am configured for mode 00000" > > This results in PSC coming up in IETF mode. > > A.mode = Z.mode = 11111 > A->Z: "I am configured for mode 11111" > Z->A: "I am configured for mode 11111" > > This results in PSC coming up in ITU mode. > > A.mode != Z.mode (say, 00001 and 00010) > A->Z: "I am configured for mode 00001" > Z->A: "I am configured for mode 00010" > > PSC does not come up. > > > > Example of method 2 > ------------------- > Both Node A and Node Z announce two things - Capabilities and Mask. > Capabilities is a bitmap of the capabilities that are supported. > Mask is a mask of don't-care bits against the Capabilities string. A 0 in Mask means "I don't care if we do this capability or not", and a 1 means "we must > (or must not) agree on this capability in order to come up". > > A.capabilities = 00000 > A.mask = 00000 > > This says "I am capable of supporting all capabilities and I don't care if we do any of them or not" > > A.capabilities = 00000 > A.mask = 11111 > > This says "We must not use any of the optional capabilities" - Capabilities bits are all zero, and Mask bits say "we must agree that the corresponding > capability is zero". This is 'IETF mode'. > > A.capabilities = 11111 > A.mask = 11111 > > This is 'ITU Mode' > > Where it gets complicated (or awesome, depending on your perspective) is when you have various subsets. Consider: > > A.Capabilities == 01100 > A.Mask == 01100 > > Z.Capabilities == 01110 > Z.Mask == 01110 > > > Negotiation procedures. > Each side does: > > > res = (A.Capabilites & Z.Mask) ^ (Z.Capabilities & A.Mask) > res = (01100 & 01110) ^ (01110 & 01100) > res = (01100) ^ (01100) > res = 00000 > > if res == 0 then it is possible for both sides to find a common subset that they support. > This common subset is called the 'negotiated set', and is determined by: > > negotiated_set = A.Capabilities | B.Capabilities > negotiated_set = 01100 | 01110 > negotiated_set = 01100 > > if res != 0 then it is impossible to find a subset that the two ends can agree on, and PSC will never come up. > > Once each side computes the negotiated set, they signal it and PSC starts to work. > _______________________________________________ > 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 --------------090003070604010005050902 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit
Hi Eric and all

My preference is option 1 and I also ask for the No negotioation.
Rather than (As well as) negotiation, the configuration to NE can also safisty
the case in transport network.

Regards, Yuji

(2013/08/16 2:00), Malcolm.BETTS@zte.com.cn wrote:
Hi Eric,

I have only seen one message on this thread so I will venture an opinion.

My preference is for option 1 - no negotiation.

My reasons are:

Keep it simple!

The major reason that network operator's have given for requesting these enhanced capabilities is to maintain compatibility with existing linear protection schemes. Within the network of a single operator my assumption is that they want, above all else, consistent operation.  Therefore, I suspect that we will see two "camps" with either all options active or no options active.

Interconnection of "transport" connections between network operators is normally only allowed within the frame work of an agreement between the operators. As part of that agreement they would need to define the linear protection options that would be used. The operational differences would be confined to the links that provide the interconnection between networks of the different operators. The appropriate protection options would be configured (as defined by the agreement) when the protected connection is set-up.

Negotiation would allow the possibility of a variety of protection options being active in the network which would result in inconsistent behaviour which would create operational complexity.

Regards,

Malcolm




"Eric Osborne (eosborne)" <eosborne@cisco.com>
Sent by: mpls-bounces@ietf.org

08/08/2013 08:34 AM

To
 "mpls@ietf.org" <mpls@ietf.org>
cc
Subject
 [mpls] Mode negotiation for PSC







As per last Friday's presentation in Berlin (http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt), we will be adding "ITU Mode" to PSC to allow for behaviors that satisfy both IETF and ITU requirements.  This mode will be backward-compatible and negotiated using PSC TLVs.  

The drafts in that ppt define five capabilities which separate ITU mode from IETF mode.  IETF mode is defined as the absence of these five capabilities, and ITU mode is defined as the use of all five of these capabilities.  It may help to think of IETF mode as 00000 and ITU mode as 11111.  The mechanism to define and negotiate these modes will have room for expansion past five bits, so if we ever decide we need more capabilities negotiation in PSC (shared mesh?  m:n?  other fancy stuff?) we can.  

As of right now we are only discussing two modes, but it is possible to define a mode which is some combination of these five things other than 00000 or 11111.  So a mode is really the set of negotiated capabilities between two devices.

There are two ways we can negotiate the use of one more or the other:

1) Each node announces the mode that it wants, and if the other side doesn't want exactly the same mode then PSC will not function.  That is, both nodes say "my mode is 0bxxxxx" (for now, either 00000 or 11111) and if both nodes don't say the same thing then they complain to the operator and refuse to function.

Advantage: easy, and if both ends are in a single administrative domain I expect the operator to be able to configure both ends to match.

Disadvantage: tricky if we ever start talking about modes other than 00000 or 11111.  I don't want a node to say "I support mode 00000, mode 00001, mode 00010, mode 00011, .... mode 11111" because if we add a few more capabilities we could end up announcing the support of hundreds or thousands of modes.  Does not allow PSC to come up unless the modes match on both sides, even if there is some common subset they could both agree on.


or


2) Each node announces the set of capabilities that it can support along with the ones that it requires, and if the two nodes can find a common subset of features then they will converge on those features in PSC.

Advantage: flexible.  If two endpoints can find a common feature subset (see example below) then they will come up.

Disadvantage: more complex code, easier to get wrong and converge on a undesirable subset.


Examples of each negotiation method are below, both for clarity and to demonstrate that method #2 works.  My question for the WG is, which one would people prefer, and why?






eric


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


Examples
========
All examples are between two nodes, A and Z.  These examples focus on the actual negotiation, not on the necessary TLV bits to enable the negotiation.

Example of method 1
-------------------
Node A sends a single TLV to Node Z containg the mode bitmap.  Node Z sends the same to A.  Call them A.Mode and Z.Mode.  If they do not match then some default behavior happens - either PSC doesn't come up or they default to one predetermined mode.

A.mode = Z. mode = 00000
A->Z: "I am configured for mode 00000"
Z->A: "I am configured for mode 00000"

This results in PSC coming up in IETF mode.

A.mode = Z.mode = 11111
A->Z: "I am configured for mode 11111"
Z->A: "I am configured for mode 11111"

This results in PSC coming up in ITU mode.

A.mode != Z.mode (say, 00001 and 00010)
A->Z: "I am configured for mode 00001"
Z->A: "I am configured for mode 00010"

PSC does not come up.



Example of method 2
-------------------
Both Node A and Node Z announce two things - Capabilities and Mask.
Capabilities is a bitmap of the capabilities that are supported.
Mask is a mask of don't-care bits against the Capabilities string.  A 0 in Mask means "I don't care if we do this capability or not", and a 1 means "we must (or must not) agree on this capability in order to come up".

A.capabilities = 00000
A.mask         = 00000

This says "I am capable of supporting all capabilities and I don't care if we do any of them or not"

A.capabilities = 00000
A.mask         = 11111

This says "We must not use any of the optional capabilities" - Capabilities bits are all zero, and Mask bits say "we must agree that the corresponding capability is zero".  This is 'IETF mode'.

A.capabilities = 11111
A.mask         = 11111

This is 'ITU Mode'

Where it gets complicated (or awesome, depending on your perspective) is when you have various subsets.  Consider:

A.Capabilities == 01100
A.Mask == 01100

Z.Capabilities == 01110
Z.Mask == 01110


Negotiation procedures.
Each side does:


res = (A.Capabilites & Z.Mask) ^ (Z.Capabilities & A.Mask)
res = (01100 & 01110) ^ (01110 & 01100)
res = (01100) ^ (01100)
res = 00000

if res == 0 then it is possible for both sides to find a common subset that they support.
This common subset is called the 'negotiated set', and is determined by:

negotiated_set = A.Capabilities | B.Capabilities
negotiated_set = 01100 | 01110
negotiated_set = 01100

if res != 0 then it is impossible to find a subset that the two ends can agree on, and PSC will never come up.

Once each side computes the negotiated set, they signal it and PSC starts to work.
_______________________________________________
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

--------------090003070604010005050902-- From mach.chen@huawei.com Thu Aug 15 18:24:24 2013 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 93AA611E8248 for ; Thu, 15 Aug 2013 18:24:24 -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=0.000, 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 mvGD5nntsDig for ; Thu, 15 Aug 2013 18:24:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6F96F11E8246 for ; Thu, 15 Aug 2013 18:24:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AWB38077; Fri, 16 Aug 2013 01:24:13 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 16 Aug 2013 02:23:57 +0100 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 16 Aug 2013 02:24:10 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.128]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.007; Fri, 16 Aug 2013 09:24:04 +0800 From: Mach Chen To: "Nobo Akiya (nobo)" , "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" Thread-Topic: [mpls] Comments on draft-ietf-mpls-return-path-specified-lsp-ping-12.txt Thread-Index: Ac6ZIv/azjWY8ahbTN6wXwSKa+Cm7gAMC0YwAAQXw4AALkVAkA== Date: Fri, 16 Aug 2013 01:24:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-ietf-mpls-return-path-specified-lsp-ping-12.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, 16 Aug 2013 01:24:24 -0000 Hi Nobo, As Loa said, regarding the new modes, maybe we could write a new draft to c= over that. > I have another question. Draft mentions BFD. I understand the motive behi= nd > wanting to control the reverse BFD path on uni-directional LSP. But I don= 't quite > see the entire picture by making use of path TLV. Let's say we bootstrap = BFD with > LSP ping with path TLV with specific RSVP FEC, so that reverse BFD packet= s are > riding on specified RSVP FEC. That RSVP FEC can become invalid at any tim= e (ex: > re-optimization takes place and LSP ID changes). What happens then? Regarding the BFD part, actually there is a company draft (http://tools.iet= f.org/html/draft-chen-mpls-bfd-enhancement-01 ) that was submitted to BFD W= G couple years ago. Some of the content may need update. In section 4.2 of the draft, it describes how reply path TLV (particular th= e Tunnel sub-TLVs) is used to bootstrap BFD session hence to control the re= verse BFD path. Specifically, it uses Tunnel ID other than particular LSP I= D to specify the return path of the BFD session, therefore, the BFD session= is transparent to the changes of particular LSP ID. =20 Best regards, Mach > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Thursday, August 15, 2013 7:00 PM > To: Mach Chen; draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.= org > Cc: mpls@ietf.org > Subject: RE: [mpls] Comments on > draft-ietf-mpls-return-path-specified-lsp-ping-12.txt >=20 > Hello Mach, >=20 > Many thanks for quick response. Please see further comments inline. >=20 > > > Dear Authors, et al, > > > > > > Draft adds new reply mode (5 - Reply via Specified Path) which looks > > > to provide initiator great control on return path. Draft considers > > > bidirectional LSP, and allows specifying of reverse LSP in a new TLV, > > > but ... for bidirectional LSP ping, having reply mode to indicate > > > reverse LSP would appear to take care of large majority of use, and > > > there'll be no need to encode/decode additional TLV. Is there any rea= son > > why reply mode to specify reverse LSP is not added? > > > > The draft uses the "reply mode 5 + B bit" to achieve this, using a repl= y mode > > to indicate the reverse LSP is an alternate way, we considered this and= it > > also works. The reason not using dedicated reply mode is that we don't > > want to define too many reply modes, indicating reverse LSP is kind of > > specifying reply path and using the same reply mode seems reasonable. >=20 > We have 8 bits of reply mode, draft is proposing to take value 5/255. I d= on't think > we are crunched to conserve numbers, and reasonable to add another if it = make > sense. In this case, I think it make sense to add one for "reverse LSP". = Regarding > "we don't want to define too many reply modes", was that WG rough consens= us > or was that consensus amongst authors of this draft? >=20 > > > > From the implementation point of view, IMHO, the two ways have not too > > much differences, from the operation point of view, there should be no > > difference. >=20 > New value in 8 bit field is certainly much more easier to implement than = (new > value in 8 bit field + new TLV + logic to handle new TLV). >=20 > > > > > > > > And reply path TLV allows for initiator to specify a particular retur= n > > > path, but allows responder to choose different path if initiator > > > specified one cannot be accommodated. This aspect is very interesting= . > > > Reason being that specifying of the "right" reply mode in echo reques= t > > > seems to be getting more and more complicated these days. > > > > > > For example, bidirectional LSP with some transit nodes non-co-routed: > > > - ping: > > > * IP reply mode works > > > * Reverse LSP reply mode works > > > - ping with TTL terminating on mid: > > > * IP reply mode works > > > * Reverse LSP reply mode may or may not work > > > - traceroute: > > > * IP reply mode works > > > * Reverse LSP reply mode may or may not work > > > > > > In above cases, what I would like to specify in most cases is to say > > > "take reverse LSP as return path if available, otherwise take IP > > > return path". Yes reply path TLV allows this, but I'm thinking if thi= s can be > > done in a simpler way. > > > > As you said, the reply path TLV allows this. In addition, to localize t= he failure > > point, sometime it may need to specify an explicit reply path other tha= n the > > reverse path and IP return path, that is the main reason why we introdu= ce > > the reply path TLV. >=20 > Yes, for specific use like fault isolation, I think path TLV adds value. = It can be > another technique in addition to traceroute. For most ping/trace though, = path > TLV really isn't necessary. I'd like to see things kept simple for most c= ases, but > allow a mechanism for that tricky few percent of cases. >=20 > > > > > > > > Reply mode 2: Reply via an IPv4/IPv6 UDP packet Reply mode 4: Reply > > > via application level control channel Reply mode 6: Reply via reverse > > > LSP (assume this exists) > > > > > > Let's say there existed: > > > > > > Reply mode 7: Reply via pre-defined preference > > > > > > When responder receives reply mode 7, then return path is chosen from > > > pre-defined preference list (ex: control-channel > reverse LSP > IP). > > > Reply mode used can be encoded in the reply mode field of echo rely s= o > > > initiator knows which was used. > > > > The difficulty is that the responder may not have the ability to judge > > whether the control-channel, reverse LSP and IP is workable or not. For > > example, when it thinks that the control-channel is workable, it will a= lways > > choose it but the control-channel may not workable (e.g., a failure in = the > > middle of the channel) . >=20 > Responder does not need to judge whether reverse "path" is workable or no= t, > responder just needs to judge whether reverse "path" is available for use= , and > that's not difficult. >=20 > Reverse LSP reply mode only make sense if something like "pre-defined > preference" reply mode also exists ... since transit nodes or FRR path ma= y not > have reverse LSP. But "default reply mode" selection by implementations o= r > operators will be simplified if we had something like this. >=20 > All this to say, can we discuss a simpler solution via adding couple of n= ew reply > modes? :) >=20 > I have another question. Draft mentions BFD. I understand the motive behi= nd > wanting to control the reverse BFD path on uni-directional LSP. But I don= 't quite > see the entire picture by making use of path TLV. Let's say we bootstrap = BFD with > LSP ping with path TLV with specific RSVP FEC, so that reverse BFD packet= s are > riding on specified RSVP FEC. That RSVP FEC can become invalid at any tim= e (ex: > re-optimization takes place and LSP ID changes). What happens then? >=20 > Regards, > Nobo >=20 > > > > Best regards, > > Mach > > > > > > > > I see the new TLV useful for specific scenarios, but I've been trying > > > to see how things (implementations and operations) can be simplified > > > for those non-specific > > > (majority) of cases. Was something like above considered as part of t= his > > draft? > > > > > > Regards, > > > Nobo > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls From huubatwork@gmail.com Fri Aug 16 02:43:55 2013 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 8D65511E8262 for ; Fri, 16 Aug 2013 02:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 IIM-u8xryGyj for ; Fri, 16 Aug 2013 02:43:54 -0700 (PDT) Received: from mail-ea0-x234.google.com (mail-ea0-x234.google.com [IPv6:2a00:1450:4013:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7F21311E812F for ; Fri, 16 Aug 2013 02:43:52 -0700 (PDT) Received: by mail-ea0-f180.google.com with SMTP id h10so878973eaj.25 for ; Fri, 16 Aug 2013 02:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=Wl2qnKmoTgh2YViK62v1x+HO1f4a0ApDWmUecOHEcMk=; b=YqZ35TEsz0SbjQ8bAWwmVQtCZra6g+9WwwivnLEZ9EVSZy1nIHU6Ib2YLGFXD5rKLK BIaFd42uV7+gAhYw7aLPv8XdM7ARtSsUnWEa3k2LBykmeHCgm3ep3rdoR8I+ejvQyzPY iOkkFc1VxDzPH602BqJlShPu8oNWJEfgyhXpkGiYHMoiuGwb7HvdcuX5rwqJDE4fbJR2 vjs++nlppUEaTCRvlU8c9haqh7n8EnxLxmxnZdsbLbEMJTs+Kzrc4nATn/sSkNewMoWA VzDNX2svu9hkItPV+dmejsJbPHsaIBg0yqN9fKFTEEMOae7hkPhYjEc08/PAIxLhpz2O ED/g== X-Received: by 10.14.212.6 with SMTP id x6mr92110eeo.67.1376646231618; Fri, 16 Aug 2013 02:43:51 -0700 (PDT) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id a1sm1427890eem.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Aug 2013 02:43:51 -0700 (PDT) Message-ID: <520DF459.2010904@gmail.com> Date: Fri, 16 Aug 2013 11:43:53 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ross Callon References: <62CCD4C52ACDAD4481149BD5D8A72FD316C76D83@CH1PRD0510MB355.namprd05.prod.outlook.com> <62CCD4C52ACDAD4481149BD5D8A72FD316D6D7D6@CH1PRD0510MB355.namprd05.prod.outlook.com> <18dba3497ae64dd1b884767acc961696@BLUPR05MB070.namprd05.prod.outlook.com> In-Reply-To: <18dba3497ae64dd1b884767acc961696@BLUPR05MB070.namprd05.prod.outlook.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 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: Fri, 16 Aug 2013 09:43:55 -0000 All, I have read this draft, and in general support it. One comment for the draft itself: It would be useful to add a link to the IANA registry: http://www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml And, because OAM alert label 14 is used in ITU-T Y.1711 it would be good to send a liaison for information to ITU-T SG15. Regards, Huub. > *From:*Ross Callon [mailto:rcallon@juniper.net] > *Sent:* Tuesday, July 16, 2013 1:00 PM > *To:* mpls@ietf.org; draft-ietf-mpls-special-purpose-labels@tools.ietf.org > *Cc:* mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) > *Subject:* MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 > > Working Group, > > This is to start Working Group last call > ondraft-ietf-mpls-special-purpose-labels-03 > > Please send your comments to the mpls working groupmailing list > (mpls@ietf.org ). > > Please send both technical comments, and (if you are happywith the > document as is) > > also send indications of support. > > There are no IPR claims against this draft.The co-authors have earlier > stated that they > > are not awareof any IPR applicable to this draft. > > If anyone else in the working group is aware of IPRs claims against > > this draft, the time to disclose that is now. > > Due to the upcoming IETF meeting in Berlin, this last call will be > extended by an extra week > > (which implies that the last call will be ongoing during the IETF > meeting). This working group > > last call will end on August 6, 2013. > > Ross > > for the wg co-chairs > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- ***************************************************************** 请记ä½ï¼Œä½ æ˜¯ç‹¬ä¸€æ— äºŒçš„，就åƒå…¶ä»–æ¯ä¸€ä¸ªäººä¸€æ · From iesg-secretary@ietf.org Fri Aug 16 08:17:44 2013 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 2576811E8290; Fri, 16 Aug 2013 08:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.094, 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 AKylWNYRKYsG; Fri, 16 Aug 2013 08:17:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3074411E8298; Fri, 16 Aug 2013 08:17:40 -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: 4.70.p1 Message-ID: <20130816151740.1087.55208.idtracker@ietfa.amsl.com> Date: Fri, 16 Aug 2013 08:17:40 -0700 Cc: mpls WG Subject: [mpls] WG Action: Rechartered Multiprotocol Label Switching (mpls) 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, 16 Aug 2013 15:17:44 -0000 The Multiprotocol Label Switching (mpls) working group in the Routing Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Multiprotocol Label Switching (mpls) ------------------------------------------------ Current Status: Active WG Chairs: Loa Andersson George Swallow Ross Callon Secretaries: Martin Vigoureux Assigned Area Director: Adrian Farrel Mailing list Address: mpls@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mpls Archive: http://www.ietf.org/mail-archive/web/mpls/ Charter: The MPLS working group is responsible for standardizing technology for label switching and for the implementation of label-switched paths over packet based link-level technologies. The working group's responsibilities include procedures and protocols for the distribution of labels between Label Switching Routers (LSRs), MPLS packet encapsulation, and for Operation, Administration, and Maintenance (OAM) (including the necessary management objects expressed as MIB modules or using other techniques). The current WG focus areas and work items are: - Maintain existing MPLS requirements, mechanisms, and protocols, as currently documented in RFCs, in coordination with other working groups that work in overlapping areas e.g., CCAMP, PWE3, and OPSAWG working groups. - Evolve key MPLS protocols, including LDP, tLDP, mLDP, RSVP-TE and LSP Ping to meet new requirements. - Define an overall OAM framework for topology-driven, traffic engineered, and transport profile MPLS applications. - Determine MPLS-specific aspects of traffic engineering for multi-areas/multi-AS in cooperation with the CCAMP WG - Define necessary extensions for MPLS key protocols for dual-stack and IPv6 only networks - Coordinate with the CCAMP working group on the extensions of MPLS and GMPLS protocols - Document current implementation practices for MPLS load sharing. - Document mechanisms for securing MPLS networks in coordination with the KARP working group. - Document mechanisms for adding multi-topology support to existing MPLS protocols. - Document use cases for MPLS protocols. Milestones: Done - Submit documents from original MPLS effort to IESG Done - Framework for IP multicast over label-switched paths ready for advancement. Done - LDP fault tolerance specification ready for advancement to Proposed Standard. Done - Submit Definitions of Managed Objects for MultoiProtocol Label Switching, Label Distribution Protocol (LDP) to the IESG for publication as Proposed Standards Done - Specification for MPLS-specific recovery ready for advancement. Done - Submit Multiprotocol Label Switching (MPLS) Forward Equivalency Class-To-Next Hop Label Forwarding Entry Management Information Base to the IESG for publication as Proposed Standards Done - Submit Multiprotocol Label Switching (MPLS) Label Switching Router (LSR), Management Information Base to the IESG for publication as Proposed Standards Done - Submit Multiprotocol Label Switching (MPLS) Management Overview to the IESG for publication as Proposed Standards Done - Submit Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management to the IESG for publication as Proposed Standards Done - Submit Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base to the IESG for publication as Proposed Standards Done - Submit the Traffic Engineering Link MIB to the IESG for as a Proposed Standard Done - Submit a specification on Encapsulations to carry MPLS over IP and GRE to the IESG for as a Proposed Standard Done - Submit specification on LSP Ping to the IESG for publication as a Proposed Standard Done - Submit a document defining the scope, requirements, and issues to resolve for setup of P2MP TE LSPs (MPLS and GMPLS) Done - Submit an OAM Framework Document to the IESG for publication as an Informational RFC Done - Submit a BCP on MPLS load sharing to the IESG Done - Submit specification on LSR Self Test to the IESG for publication as a Proposed Standard Done - Submit document(s) specifying protocol extensions, enhancements and mechanisms for setup of P2MP TE LSPs Done - Submit point to multipoint TE MIB to IESG as proposed standard Done - Submit EXP field clarification document to IESG as proposed standard Done - Submit a specification on Soft Pre-emption of LSP Tunnels to the IESG for publication as a Proposed Standard Done - Submit LDP extensions for P2MP LSPs Done - Submit MPLS security framework for publication as an informational RFC Done - Submit requirements for point-to-multipoint extensions to LDP Done - Submit draft-ietf-mpls-ldp-gtsm for publication Done - Submit draft-ietf-mpls-tp-itu-t-identifiers for publication Done - Submit draft-ietf-mpls-entropy-label for publication Done - Submit draft-ietf-mpls-tp-security-framework for publication Done - Submit draft-ietf-mpls-ipv6-pw-lsp-ping for publication Done - Submit draft-ietf-mpls-mldp-in-band-signaling for publication Done - Submit draft-ietf-mpls-tp-ethernet-addressing for publication Done - Submit draft-ietf-mpls-tp-ring-protection for publication Done - Submit draft-ietf-mpls-tp-use-cases-and-design for publication Done - Submit draft-ietf-mpls-gach-adv for publication Aug 2013 - Submit draft-ietf-mpls-seamless-mpls for publication Sep 2013 - Submit draft-ietf-mpls-ldp-multi-topology for publication Sep 2013 - Submit draft-ietf-mpls-mldp-hsmp for publication Oct 2013 - Submit draft-ietf-mpls-seamless-mcast for publication Nov 2013 - Submit draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf for publication Nov 2013 - Submit draft-ietf-mpls-tp-1ton-protection for publication Nov 2013 - Submit draft-ietf-mpls-tp-oam-id-mib for publication Nov 2013 - Submit draft-ietf-mpls-ldp-ip-pw-capability for publication Nov 2013 - Submit draft-ietf-mpls-retire-ach-tlv for publication Dec 2013 - Submit draft-ietf-mpls-tp-mip-mep-map for publication Dec 2013 - Submit draft-ietf-mpls-tp-te-mib for publication Dec 2013 - Submit draft-ietf-mpls-tp-temporal-hitless-psm for publication Dec 2013 - Submit draft-ietf-mpls-tp-rosetta-stone for publication Dec 2013 - Submit draft-ietf-mpls-ldp-ipv6 for publication Dec 2013 - Submit draft-ietf-mpls-ldp-applicability-label-adv for publication Dec 2013 - Submit draft-ietf-mpls-ldp-dod for publication Dec 2013 - Submit draft-ietf-mpls-ldp-hello-crypto-auth for publication Dec 2013 - Submit draft-ietf-mpls-lsp-ping-ttl-tlv for publication Dec 2013 - Submit draft-ietf-mpls-return-path-specified-lsp-ping for publication Dec 2013 - Submit draft-ietf-mpls-targeted-mldp for publication From eosborne@cisco.com Fri Aug 16 13:48:56 2013 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 C4D6E11E8187 for ; Fri, 16 Aug 2013 13:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9P-htXN9xWC for ; Fri, 16 Aug 2013 13:48:51 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 434CC11E8175 for ; Fri, 16 Aug 2013 13:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1960; q=dns/txt; s=iport; t=1376686131; x=1377895731; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kORNrB6It08jUCcA3qlOYc4WdV/rqFU+0jXuk4qb6PY=; b=dP25Cba3jumKVAGQtaQvQ8a4J3WmDSIu1h/6ZnHc7AfxRsTi4dd407oF 1nUMPQFkvX4namlUR5Q0FD+JfKKv4A2N0jPr8Ctf7TEbb1seF4v6v1ZD+ bxkXkPCbM+anl9IcX9m7k5wu7EP/F6CuWYsNodfc4haw0cm1l7/jnIYYc 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAM2PDlKtJV2a/2dsb2JhbABbgwaBBr8ggSsWdIIkAQEBBDoxDgwCAgIBCBEEAQEBChQJBxsXFAkIAQEEDgUIiAi5RwSOf4EcMQcGgxV3A5QNlSyDHIFxOQ X-IronPort-AV: E=Sophos;i="4.89,897,1367971200"; d="scan'208";a="248399166" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 16 Aug 2013 20:48:50 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7GKmnG7005080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 16 Aug 2013 20:48:49 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.136]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Fri, 16 Aug 2013 15:48:49 -0500 From: "Eric Osborne (eosborne)" To: Loa Andersson Thread-Topic: [mpls] Mode negotiation for PSC Thread-Index: Ac6ULYh0Wz1ulMCERKa7JFuZBxS/GADMiSEAAMqE0IA= Date: Fri, 16 Aug 2013 20:48:49 +0000 Message-ID: <20ECF67871905846A80F77F8F4A27572102EB9BD@xmb-rcd-x09.cisco.com> References: <20ECF67871905846A80F77F8F4A27572102C229B@xmb-rcd-x09.cisco.com> <52089C6A.1060104@pi.nu> In-Reply-To: <52089C6A.1060104@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.66.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Mode negotiation for PSC 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, 16 Aug 2013 20:48:56 -0000 Hi Loa-=20 See inline > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Monday, August 12, 2013 1:27 AM > To: Eric Osborne (eosborne) > Cc: mpls@ietf.org > Subject: Re: [mpls] Mode negotiation for PSC >=20 > Eric, >=20 >=20 >=20 > On 2013-08-08 14:34, Eric Osborne (eosborne) wrote: > >=20 > > Example of method 2 > > ------------------- > > Both Node A and Node Z announce two things - Capabilities and Mask. > > Capabilities is a bitmap of the capabilities that are supported. > > Mask is a mask of don't-care bits against the Capabilities string. A > 0 in Mask means "I don't care if we do this capability or not", and a 1 > means "we must (or must not) agree on this capability in order to come > up". > > > > A.capabilities =3D 00000 > > A.mask =3D 00000 >=20 > Why is this not >=20 > A.capabilities =3D 11111 > A.mask =3D 00000 >=20 Althought I didn't put it in my email, a capabilties of 1 and mask of 0 is = illegal. This is partly because it makes no sense ("I require this capabil= ity but I don't care if we do it or not") and partly because there's a case= which doesn't converge right: If I have 11111/00000 on one side and 00000/00000 on the other I end up wit= h A.cap =3D 11111, A.mask =3D 00000 Z.cap =3D 00000, Z.mask =3D 00000 res =3D (111111 & 00000) ^ (00000 & 00000) res =3D 11111 ^ 00000 =3D 11111 and if res !=3D 0 then the nodes can't converge on a common subset, even th= ough there are 2^5 combinations that would work for both nodes. eric > ? >=20 > /Loa >=20 > > > > This says "I am capable of supporting all capabilities and I don't > care if we do any of them or not" > >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From eosborne@cisco.com Fri Aug 16 13:48:57 2013 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 DBEA111E80FF; Fri, 16 Aug 2013 13:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.699 X-Spam-Level: X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2+02a1UG-5o; Fri, 16 Aug 2013 13:48:53 -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 5F12411E8178; Fri, 16 Aug 2013 13:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9174; q=dns/txt; s=iport; t=1376686132; x=1377895732; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iVIkl6XluCKqvFSbpNeYRusPAJdw4uZ+u27S4yTgWbk=; b=AsVhOAvuts0wfRvs7yBJn0Y02EEm6qeW69ZN2XIb2EkWKRGd5iQn25FD tMnT4MASfbQ/P/9BXuOHh0lqXTgbHr0YDUZ0YreBw48NZpRz107Q4gNNO eEdxt58mQst8HZ5/s7jI8CUAP/Qx+SbWCYHGL33QohEVKDn6EkWVHHGDe 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMHAB2PDlKtJV2d/2dsb2JhbABbgwY1Ub8ggSsWbQeCJAEBAQMBAQEBJBMaGgsFBwQCAQgRBAEBCxQJBycLFAkIAQEEDgUIAYgBBgy5OJAfMQcGgxV3A5QNlSyDHIIq X-IronPort-AV: E=Sophos;i="4.89,897,1367971200"; d="scan'208";a="248334340" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 16 Aug 2013 20:48:51 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7GKmp3D026068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 16 Aug 2013 20:48:51 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.136]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Fri, 16 Aug 2013 15:48:51 -0500 From: "Eric Osborne (eosborne)" To: "Malcolm.BETTS@zte.com.cn" Thread-Topic: [mpls] Mode negotiation for PSC Thread-Index: Ac6ULYh0Wz1ulMCERKa7JFuZBxS/GAF1VcCAACImz/A= Date: Fri, 16 Aug 2013 20:48:50 +0000 Message-ID: <20ECF67871905846A80F77F8F4A27572102EB9C5@xmb-rcd-x09.cisco.com> References: <20ECF67871905846A80F77F8F4A27572102C229B@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.66.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject: Re: [mpls] Mode negotiation for PSC 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, 16 Aug 2013 20:48:58 -0000 Hi Malcolm- Thanks for this. A few comments inline. > -----Original Message----- > From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] > Sent: Thursday, August 15, 2013 1:01 PM > To: Eric Osborne (eosborne) > Cc: mpls@ietf.org; mpls-bounces@ietf.org > Subject: Re: [mpls] Mode negotiation for PSC >=20 > Hi Eric, >=20 > I have only seen one message on this thread so I will venture an > opinion. >=20 > My preference is for option 1 - no negotiation. >=20 > My reasons are: >=20 > Keep it simple! >=20 > The major reason that network operator's have given for requesting these > enhanced capabilities is to maintain compatibility with existing linear > protection schemes. Within the network of a single operator my > assumption is that they want, above all else, consistent operation. > Therefore, I suspect that we will see two "camps" with either all > options active or no options active. >=20 That's what it looks like now. But I'm not terribly good at predicting wha= t people will never, ever do. I could see an implementation which wants to= support, say, MS-W but none of the other options. > Interconnection of "transport" connections between network operators is > normally only allowed within the frame work of an agreement between the > operators. As part of that agreement they would need to define the > linear protection options that would be used. The operational > differences would be confined to the links that provide the > interconnection between networks of the different operators. The > appropriate protection options would be configured (as defined by the > agreement) when the protected connection is set-up. PSC has bits to indicate the protection type and revertive mode, and the lo= gic we're going to add n draft-osborne explains what happens if two sides d= isagree. Is this not a form of negotiatoin? >=20 > Negotiation would allow the possibility of a variety of protection > options being active in the network which would result in inconsistent > behaviour which would create operational complexity. It is possible for one side to declare intransigence by setting the mask bi= ts to all 1s. This indicates that the Capabilities advertised by that node= must match exactly in order for things to work. The two modes I think we'= ll see first are: Cap=3D00000, Mask=3D11111 Cap=3D11111, Mask=3D11111 and these two will never agree on a mode since the mask of all 1s gives nei= ther side any room to move. I'm not against the simpler mode, I just want to make sure that you underst= and that it is possible to achieve that using the proposed negotiation meth= od. eric >=20 > Regards, >=20 > Malcolm >=20 >=20 >=20 >=20 >=20 > "Eric Osborne (eosborne)" > Sent by: mpls-bounces@ietf.org >=20 > 08/08/2013 08:34 AM To > "mpls@ietf.org" > cc > Subject > [mpls] Mode negotiation for PSC >=20 >=20 >=20 >=20 >=20 >=20 > As per last Friday's presentation in Berlin > (http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt > ), we > will be adding "ITU Mode" to PSC to allow for behaviors that satisfy > both IETF and ITU requirements. This mode will be backward-compatible > and negotiated using PSC TLVs. >=20 > The drafts in that ppt define five capabilities which separate ITU mode > from IETF mode. IETF mode is defined as the absence of these five > capabilities, and ITU mode is defined as the use of all five of these > capabilities. It may help to think of IETF mode as 00000 and ITU mode > as 11111. The mechanism to define and negotiate these modes will have > room for expansion past five bits, so if we ever decide we need more > capabilities negotiation in PSC (shared mesh? m:n? other fancy stuff?) > we can. >=20 > As of right now we are only discussing two modes, but it is possible to > define a mode which is some combination of these five things other than > 00000 or 11111. So a mode is really the set of negotiated capabilities > between two devices. >=20 > There are two ways we can negotiate the use of one more or the other: >=20 > 1) Each node announces the mode that it wants, and if the other side > doesn't want exactly the same mode then PSC will not function. That is, > both nodes say "my mode is 0bxxxxx" (for now, either 00000 or 11111) and > if both nodes don't say the same thing then they complain to the > operator and refuse to function. >=20 > Advantage: easy, and if both ends are in a single administrative domain > I expect the operator to be able to configure both ends to match. >=20 > Disadvantage: tricky if we ever start talking about modes other than > 00000 or 11111. I don't want a node to say "I support mode 00000, mode > 00001, mode 00010, mode 00011, .... mode 11111" because if we add a few > more capabilities we could end up announcing the support of hundreds or > thousands of modes. Does not allow PSC to come up unless the modes > match on both sides, even if there is some common subset they could both > agree on. >=20 >=20 > or >=20 >=20 > 2) Each node announces the set of capabilities that it can support along > with the ones that it requires, and if the two nodes can find a common > subset of features then they will converge on those features in PSC. >=20 > Advantage: flexible. If two endpoints can find a common feature subset > (see example below) then they will come up. >=20 > Disadvantage: more complex code, easier to get wrong and converge on a > undesirable subset. >=20 >=20 > Examples of each negotiation method are below, both for clarity and to > demonstrate that method #2 works. My question for the WG is, which one > would people prefer, and why? >=20 >=20 >=20 >=20 >=20 >=20 > eric >=20 >=20 > --------------------------------- >=20 >=20 > Examples > =3D=3D=3D=3D=3D=3D=3D=3D > All examples are between two nodes, A and Z. These examples focus on > the actual negotiation, not on the necessary TLV bits to enable the > negotiation. >=20 > Example of method 1 > ------------------- > Node A sends a single TLV to Node Z containg the mode bitmap. Node Z > sends the same to A. Call them A.Mode and Z.Mode. If they do not match > then some default behavior happens - either PSC doesn't come up or they > default to one predetermined mode. >=20 > A.mode =3D Z. mode =3D 00000 > A->Z: "I am configured for mode 00000" > Z->A: "I am configured for mode 00000" >=20 > This results in PSC coming up in IETF mode. >=20 > A.mode =3D Z.mode =3D 11111 > A->Z: "I am configured for mode 11111" > Z->A: "I am configured for mode 11111" >=20 > This results in PSC coming up in ITU mode. >=20 > A.mode !=3D Z.mode (say, 00001 and 00010) > A->Z: "I am configured for mode 00001" > Z->A: "I am configured for mode 00010" >=20 > PSC does not come up. >=20 >=20 >=20 > Example of method 2 > ------------------- > Both Node A and Node Z announce two things - Capabilities and Mask. > Capabilities is a bitmap of the capabilities that are supported. > Mask is a mask of don't-care bits against the Capabilities string. A 0 > in Mask means "I don't care if we do this capability or not", and a 1 > means "we must (or must not) agree on this capability in order to come > up". >=20 > A.capabilities =3D 00000 > A.mask =3D 00000 >=20 > This says "I am capable of supporting all capabilities and I don't care > if we do any of them or not" >=20 > A.capabilities =3D 00000 > A.mask =3D 11111 >=20 > This says "We must not use any of the optional capabilities" - > Capabilities bits are all zero, and Mask bits say "we must agree that > the corresponding capability is zero". This is 'IETF mode'. >=20 > A.capabilities =3D 11111 > A.mask =3D 11111 >=20 > This is 'ITU Mode' >=20 > Where it gets complicated (or awesome, depending on your perspective) is > when you have various subsets. Consider: >=20 > A.Capabilities =3D=3D 01100 > A.Mask =3D=3D 01100 >=20 > Z.Capabilities =3D=3D 01110 > Z.Mask =3D=3D 01110 >=20 >=20 > Negotiation procedures. > Each side does: >=20 >=20 > res =3D (A.Capabilites & Z.Mask) ^ (Z.Capabilities & A.Mask) > res =3D (01100 & 01110) ^ (01110 & 01100) > res =3D (01100) ^ (01100) > res =3D 00000 >=20 > if res =3D=3D 0 then it is possible for both sides to find a common subse= t > that they support. > This common subset is called the 'negotiated set', and is determined by: >=20 > negotiated_set =3D A.Capabilities | B.Capabilities > negotiated_set =3D 01100 | 01110 > negotiated_set =3D 01100 >=20 > if res !=3D 0 then it is impossible to find a subset that the two ends ca= n > agree on, and PSC will never come up. >=20 > Once each side computes the negotiated set, they signal it and PSC > starts to work. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > >=20 From nobo@cisco.com Fri Aug 16 18:25:31 2013 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 61BFE21F8790 for ; Fri, 16 Aug 2013 18:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rw5Zu3VWNYHM for ; Fri, 16 Aug 2013 18:25:26 -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 60A3C21F871B for ; Fri, 16 Aug 2013 18:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8084; q=dns/txt; s=iport; t=1376702726; x=1377912326; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=G73quyyLtg8kbbXL0IEo1XZ65BCecYqdIT5btFqavec=; b=DCAOOpOIXFK2TqEXiyCcMQsa+ynKvWDUlbR8TqOmjZ5p/KVJLkHqvTaO gOXBzSRd3FIMyEZ0iSak5YIdgOsmHjYBo09KzM24irpNQY6j79k5G+XZC ZqFhciYaHEK/GndxmJ4hGZrGtD94Rqv5yEVbRNtPmvbsSDO2Vbb98XYZw w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAAvQDlKtJV2c/2dsb2JhbABbgmUhNVG/JIEpFnSCJAEBAQMBAQEBNzQLBQcEAgEIEQQBAQsUCQcnCxQJCAIEAQ0FCBOHbwYBC7kbkB8xBwaDFXcDmRGQKIMcgio X-IronPort-AV: E=Sophos;i="4.89,898,1367971200"; d="scan'208";a="248181492" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 17 Aug 2013 01:25:25 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7H1PPsp022383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 17 Aug 2013 01:25:25 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Fri, 16 Aug 2013 20:25:25 -0500 From: "Nobo Akiya (nobo)" To: Mach Chen , "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" Thread-Topic: [mpls] Comments on draft-ietf-mpls-return-path-specified-lsp-ping-12.txt Thread-Index: AQHOmX6dautCD2CXyU+H2VRtLXBA/pmWBakQgAFZwgCAATnUAA== Date: Sat, 17 Aug 2013 01:24:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.213] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-ietf-mpls-return-path-specified-lsp-ping-12.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, 17 Aug 2013 01:25:31 -0000 Hello Mach, > As Loa said, regarding the new modes, maybe we could write a new draft to > cover that. Perhaps that will be the best approach. >=20 > > I have another question. Draft mentions BFD. I understand the motive > > behind wanting to control the reverse BFD path on uni-directional LSP. > > But I don't quite see the entire picture by making use of path TLV. > > Let's say we bootstrap BFD with LSP ping with path TLV with specific > > RSVP FEC, so that reverse BFD packets are riding on specified RSVP FEC. > That RSVP FEC can become invalid at any time (ex: > > re-optimization takes place and LSP ID changes). What happens then? >=20 > Regarding the BFD part, actually there is a company draft > (http://tools.ietf.org/html/draft-chen-mpls-bfd-enhancement-01 ) that was > submitted to BFD WG couple years ago. Some of the content may need > update. >=20 > In section 4.2 of the draft, it describes how reply path TLV (particular = the > Tunnel sub-TLVs) is used to bootstrap BFD session hence to control the > reverse BFD path. Specifically, it uses Tunnel ID other than particular L= SP ID > to specify the return path of the BFD session, therefore, the BFD session= is > transparent to the changes of particular LSP ID. I see what you described is documented in 3.3.1 of path TLV draft, sorry I = missed that part earlier. Regards, Nobo >=20 > Best regards, > Mach >=20 > > -----Original Message----- > > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > > Sent: Thursday, August 15, 2013 7:00 PM > > To: Mach Chen; > > draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org > > Cc: mpls@ietf.org > > Subject: RE: [mpls] Comments on > > draft-ietf-mpls-return-path-specified-lsp-ping-12.txt > > > > Hello Mach, > > > > Many thanks for quick response. Please see further comments inline. > > > > > > Dear Authors, et al, > > > > > > > > Draft adds new reply mode (5 - Reply via Specified Path) which > > > > looks to provide initiator great control on return path. Draft > > > > considers bidirectional LSP, and allows specifying of reverse LSP > > > > in a new TLV, but ... for bidirectional LSP ping, having reply > > > > mode to indicate reverse LSP would appear to take care of large > > > > majority of use, and there'll be no need to encode/decode > > > > additional TLV. Is there any reason > > > why reply mode to specify reverse LSP is not added? > > > > > > The draft uses the "reply mode 5 + B bit" to achieve this, using a > > > reply mode to indicate the reverse LSP is an alternate way, we > > > considered this and it also works. The reason not using dedicated > > > reply mode is that we don't want to define too many reply modes, > > > indicating reverse LSP is kind of specifying reply path and using the= same > reply mode seems reasonable. > > > > We have 8 bits of reply mode, draft is proposing to take value 5/255. > > I don't think we are crunched to conserve numbers, and reasonable to > > add another if it make sense. In this case, I think it make sense to > > add one for "reverse LSP". Regarding "we don't want to define too many > > reply modes", was that WG rough consensus or was that consensus > amongst authors of this draft? > > > > > > > > From the implementation point of view, IMHO, the two ways have not > > > too much differences, from the operation point of view, there should > > > be no difference. > > > > New value in 8 bit field is certainly much more easier to implement > > than (new value in 8 bit field + new TLV + logic to handle new TLV). > > > > > > > > > > > > > And reply path TLV allows for initiator to specify a particular > > > > return path, but allows responder to choose different path if > > > > initiator specified one cannot be accommodated. This aspect is very > interesting. > > > > Reason being that specifying of the "right" reply mode in echo > > > > request seems to be getting more and more complicated these days. > > > > > > > > For example, bidirectional LSP with some transit nodes non-co-route= d: > > > > - ping: > > > > * IP reply mode works > > > > * Reverse LSP reply mode works > > > > - ping with TTL terminating on mid: > > > > * IP reply mode works > > > > * Reverse LSP reply mode may or may not work > > > > - traceroute: > > > > * IP reply mode works > > > > * Reverse LSP reply mode may or may not work > > > > > > > > In above cases, what I would like to specify in most cases is to > > > > say "take reverse LSP as return path if available, otherwise take > > > > IP return path". Yes reply path TLV allows this, but I'm thinking > > > > if this can be > > > done in a simpler way. > > > > > > As you said, the reply path TLV allows this. In addition, to > > > localize the failure point, sometime it may need to specify an > > > explicit reply path other than the reverse path and IP return path, > > > that is the main reason why we introduce the reply path TLV. > > > > Yes, for specific use like fault isolation, I think path TLV adds > > value. It can be another technique in addition to traceroute. For most > > ping/trace though, path TLV really isn't necessary. I'd like to see > > things kept simple for most cases, but allow a mechanism for that trick= y > few percent of cases. > > > > > > > > > > > > > Reply mode 2: Reply via an IPv4/IPv6 UDP packet Reply mode 4: > > > > Reply via application level control channel Reply mode 6: Reply > > > > via reverse LSP (assume this exists) > > > > > > > > Let's say there existed: > > > > > > > > Reply mode 7: Reply via pre-defined preference > > > > > > > > When responder receives reply mode 7, then return path is chosen > > > > from pre-defined preference list (ex: control-channel > reverse LSP= > > IP). > > > > Reply mode used can be encoded in the reply mode field of echo > > > > rely so initiator knows which was used. > > > > > > The difficulty is that the responder may not have the ability to > > > judge whether the control-channel, reverse LSP and IP is workable or > > > not. For example, when it thinks that the control-channel is > > > workable, it will always choose it but the control-channel may not > > > workable (e.g., a failure in the middle of the channel) . > > > > Responder does not need to judge whether reverse "path" is workable or > > not, responder just needs to judge whether reverse "path" is available > > for use, and that's not difficult. > > > > Reverse LSP reply mode only make sense if something like "pre-defined > > preference" reply mode also exists ... since transit nodes or FRR path > > may not have reverse LSP. But "default reply mode" selection by > > implementations or operators will be simplified if we had something lik= e > this. > > > > All this to say, can we discuss a simpler solution via adding couple > > of new reply modes? :) > > > > I have another question. Draft mentions BFD. I understand the motive > > behind wanting to control the reverse BFD path on uni-directional LSP. > > But I don't quite see the entire picture by making use of path TLV. > > Let's say we bootstrap BFD with LSP ping with path TLV with specific > > RSVP FEC, so that reverse BFD packets are riding on specified RSVP FEC. > That RSVP FEC can become invalid at any time (ex: > > re-optimization takes place and LSP ID changes). What happens then? > > > > Regards, > > Nobo > > > > > > > > Best regards, > > > Mach > > > > > > > > > > > I see the new TLV useful for specific scenarios, but I've been > > > > trying to see how things (implementations and operations) can be > > > > simplified for those non-specific > > > > (majority) of cases. Was something like above considered as part > > > > of this > > > draft? > > > > > > > > Regards, > > > > Nobo > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls From ryoo@etri.re.kr Mon Aug 19 06:20:36 2013 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 77EAB11E8249 for ; Mon, 19 Aug 2013 06:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.398 X-Spam-Level: X-Spam-Status: No, score=-101.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ygTdY-1gkZ8 for ; Mon, 19 Aug 2013 06:20:30 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3689311E810D for ; Mon, 19 Aug 2013 06:20:29 -0700 (PDT) Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 19 Aug 2013 22:20:25 +0900 Received: from SMTP2.etri.info ([169.254.2.105]) by SMTP1.etri.info ([129.254.28.71]) with mapi id 14.01.0355.002; Mon, 19 Aug 2013 22:20:22 +0900 From: "Ryoo, Jeong-dong" To: "Eric Osborne (eosborne)" , Loa Andersson Thread-Topic: [mpls] Mode negotiation for PSC Thread-Index: Ac6ULYh0Wz1ulMCERKa7JFuZBxS/GACvMvEAAOMPfoAAmb+rXQ== Date: Mon, 19 Aug 2013 13:20:22 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A28663D52@SMTP2.etri.info> References: <20ECF67871905846A80F77F8F4A27572102C229B@xmb-rcd-x09.cisco.com> <52089C6A.1060104@pi.nu>, <20ECF67871905846A80F77F8F4A27572102EB9BD@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A27572102EB9BD@xmb-rcd-x09.cisco.com> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.45] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28663D52SMTP2etriinfo_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Mode negotiation for PSC 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, 19 Aug 2013 13:20:36 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28663D52SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpFcmljLCBpdCBpcyBhIGxpdHRsZSBiaXQgY29uZnVzaW5nLg0KDQpTZWUgW0pSXSBpbmxpbmUu Li4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbSA6ICJFcmljIE9z Ym9ybmUgKGVvc2Jvcm5lKSIgPGVvc2Jvcm5lQGNpc2NvLmNvbT4NClNlbnQgOiAyMDEzLTA4LTE3 IDA1OjQ5OjE2ICggKzA5OjAwICkNClRvIDogTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51Pg0KQ2Mg OiBtcGxzQGlldGYub3JnIDxtcGxzQGlldGYub3JnPg0KU3ViamVjdCA6IFJlOiBbbXBsc10gTW9k ZSBuZWdvdGlhdGlvbiBmb3IgUFNDDQoNCg0KSGkgTG9hLQ0KDQpTZWUgaW5saW5lDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTG9hIEFuZGVyc3NvbiBbbWFpbHRvOmxv YUBwaS5udV0NCj4gU2VudDogTW9uZGF5LCBBdWd1c3QgMTIsIDIwMTMgMToyNyBBTQ0KPiBUbzog RXJpYyBPc2Jvcm5lIChlb3Nib3JuZSkNCj4gQ2M6IG1wbHNAaWV0Zi5vcmcNCj4gU3ViamVjdDog UmU6IFttcGxzXSBNb2RlIG5lZ290aWF0aW9uIGZvciBQU0MNCj4NCj4gRXJpYywNCj4NCj4NCj4N Cj4gT24gMjAxMy0wOC0wOCAxNDozNCwgRXJpYyBPc2Jvcm5lIChlb3Nib3JuZSkgd3JvdGU6DQo+ DQo+DQo+ID4gRXhhbXBsZSBvZiBtZXRob2QgMg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g PiBCb3RoIE5vZGUgQSBhbmQgTm9kZSBaIGFubm91bmNlIHR3byB0aGluZ3MgLSBDYXBhYmlsaXRp ZXMgYW5kIE1hc2suDQo+ID4gQ2FwYWJpbGl0aWVzIGlzIGEgYml0bWFwIG9mIHRoZSBjYXBhYmls aXRpZXMgdGhhdCBhcmUgc3VwcG9ydGVkLg0KPiA+IE1hc2sgaXMgYSBtYXNrIG9mIGRvbid0LWNh cmUgYml0cyBhZ2FpbnN0IHRoZSBDYXBhYmlsaXRpZXMgc3RyaW5nLiBBDQo+IDAgaW4gTWFzayBt ZWFucyAiSSBkb24ndCBjYXJlIGlmIHdlIGRvIHRoaXMgY2FwYWJpbGl0eSBvciBub3QiLCBhbmQg YSAxDQo+IG1lYW5zICJ3ZSBtdXN0IChvciBtdXN0IG5vdCkgYWdyZWUgb24gdGhpcyBjYXBhYmls aXR5IGluIG9yZGVyIHRvIGNvbWUNCj4gdXAiLg0KPiA+DQo+ID4gQS5jYXBhYmlsaXRpZXMgPSAw MDAwMA0KPiA+IEEubWFzayA9IDAwMDAwDQo+DQo+IFdoeSBpcyB0aGlzIG5vdA0KPg0KPiBBLmNh cGFiaWxpdGllcyA9IDExMTExDQo+IEEubWFzayA9IDAwMDAwDQo+DQoNCkFsdGhvdWdodCBJIGRp ZG4ndCBwdXQgaXQgaW4gbXkgZW1haWwsIGEgY2FwYWJpbHRpZXMgb2YgMSBhbmQgbWFzayBvZiAw IGlzIGlsbGVnYWwuIFRoaXMgaXMgcGFydGx5IGJlY2F1c2UgaXQgbWFrZXMgbm8gc2Vuc2UgKCJJ IHJlcXVpcmUgdGhpcyBjYXBhYmlsaXR5IGJ1dCBJIGRvbid0IGNhcmUgaWYgd2UgZG8gaXQgb3Ig bm90IikgYW5kIHBhcnRseSBiZWNhdXNlIHRoZXJlJ3MgYSBjYXNlIHdoaWNoIGRvZXNuJ3QgY29u dmVyZ2UgcmlnaHQ6DQpbSlJdIFRoZSBtZWFuaW5nIG9mIGNhcD0xMTExMSBhbmQgbWFzaz0wMDAw MCB3b3VsZCBiZSAiSSBhbSBjYXBhYmxlIG9mIGFsbCBmaXZlIHRoaW5ncyBidXQgSSBkb24ndCBj YXJlIGlmIHdlIGRvIGl0IG9yIG5vdCINCg0KSWYgSSBoYXZlIDExMTExLzAwMDAwIG9uIG9uZSBz aWRlIGFuZCAwMDAwMC8wMDAwMCBvbiB0aGUgb3RoZXIgSSBlbmQgdXAgd2l0aA0KDQpBLmNhcCA9 IDExMTExLCBBLm1hc2sgPSAwMDAwMA0KWi5jYXAgPSAwMDAwMCwgWi5tYXNrID0gMDAwMDANCg0K DQpyZXMgPSAoMTExMTExICYgMDAwMDApIF4gKDAwMDAwICYgMDAwMDApDQpyZXMgPSAxMTExMSBe IDAwMDAwID0gMTExMTENCltKUl0gVGhlIGFuc3dlciBmb3IgKDExMTExICYgMDAwMDApIHNob3Vs ZCBiZSAwMDAwMC4gQW5kIHRoZSBmaW5hbCByZXN1bHQgb2YgMDAwMDAgXiAwMDAwMCB3aWxsIGJl IDAwMDAwLg0KDQphbmQgaWYgcmVzICE9IDAgdGhlbiB0aGUgbm9kZXMgY2FuJ3QgY29udmVyZ2Ug b24gYSBjb21tb24gc3Vic2V0LCBldmVuIHRob3VnaCB0aGVyZSBhcmUgMl41IGNvbWJpbmF0aW9u cyB0aGF0IHdvdWxkIHdvcmsgZm9yIGJvdGggbm9kZXMuDQoNCg0KW0pSXSBOb3csIHR3byBlbmRz IHdpbGwgb3BlcmF0ZSB3aXRob3V0IGFueSBjYXBhYmlsaXRpZXMuDQoNCmVyaWMNCg0KPiA/DQo+ DQo+IC9Mb2ENCj4NCj4gPg0KPiA+IFRoaXMgc2F5cyAiSSBhbSBjYXBhYmxlIG9mIHN1cHBvcnRp bmcgYWxsIGNhcGFiaWxpdGllcyBhbmQgSSBkb24ndA0KPiBjYXJlIGlmIHdlIGRvIGFueSBvZiB0 aGVtIG9yIG5vdCINCj4NCj4NCj4gLS0NCj4NCj4NCj4gTG9hIEFuZGVyc3NvbiBlbWFpbDogbG9h QG1haWwwMS5odWF3ZWkuY29tDQo+IFNlbmlvciBNUExTIEV4cGVydCBsb2FAcGkubnUNCj4gSHVh d2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxp bmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzDQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28663D52SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJ TkUtSEVJR0hUOiAxNXB0Ij5FcmljLCBpdCBpcyBhIGxpdHRsZSBiaXQgY29uZnVzaW5nLjwvZGl2 Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHls ZT0iTElORS1IRUlHSFQ6IDE1cHQiPlNlZSBbSlJdIGlubGluZS4uLjxicj4NCjxicj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGlkPSJNYWlsU2lnbiI+PGJyPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+DQo8aHIgdGFiaW5kZXg9Ii0xIj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPjxiPkZyb20gOiA8L2I+JnF1 b3Q7RXJpYyBPc2Jvcm5lIChlb3Nib3JuZSkmcXVvdDsgJmx0O2Vvc2Jvcm5lQGNpc2NvLmNvbSZn dDs8YnI+DQo8Yj5TZW50IDogPC9iPjIwMTMtMDgtMTcgMDU6NDk6MTYgKCAmIzQzOzA5OjAwICk8 YnI+DQo8Yj5UbyA6IDwvYj5Mb2EgQW5kZXJzc29uICZsdDtsb2FAcGkubnUmZ3Q7PGJyPg0KPGI+ Q2MgOiA8L2I+bXBsc0BpZXRmLm9yZyAmbHQ7bXBsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq ZWN0IDogPC9iPlJlOiBbbXBsc10gTW9kZSBuZWdvdGlhdGlvbiBmb3IgUFNDPGJyPg0KPGJyPg0K PGJyPg0KSGkgTG9hLSA8YnI+DQo8YnI+DQpTZWUgaW5saW5lPGJyPg0KPGJyPg0KJmd0OyAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogTG9hIEFuZGVyc3NvbiBbbWFp bHRvOmxvYUBwaS5udV08YnI+DQomZ3Q7IFNlbnQ6IE1vbmRheSwgQXVndXN0IDEyLCAyMDEzIDE6 MjcgQU08YnI+DQomZ3Q7IFRvOiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKTxicj4NCiZndDsgQ2M6 IG1wbHNAaWV0Zi5vcmc8YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbbXBsc10gTW9kZSBuZWdvdGlh dGlvbiBmb3IgUFNDPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEVyaWMsPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiAyMDEzLTA4LTA4IDE0OjM0LCBFcmljIE9zYm9y bmUgKGVvc2Jvcm5lKSB3cm90ZTo8YnI+DQomZ3Q7IDxTTklQPjxicj4NCiZndDsgPGJyPg0KJmd0 OyAmZ3Q7IEV4YW1wbGUgb2YgbWV0aG9kIDI8YnI+DQomZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0t LS0tLTxicj4NCiZndDsgJmd0OyBCb3RoIE5vZGUgQSBhbmQgTm9kZSBaIGFubm91bmNlIHR3byB0 aGluZ3MgLSBDYXBhYmlsaXRpZXMgYW5kIE1hc2suPGJyPg0KJmd0OyAmZ3Q7IENhcGFiaWxpdGll cyBpcyBhIGJpdG1hcCBvZiB0aGUgY2FwYWJpbGl0aWVzIHRoYXQgYXJlIHN1cHBvcnRlZC48YnI+ DQomZ3Q7ICZndDsgTWFzayBpcyBhIG1hc2sgb2YgZG9uJ3QtY2FyZSBiaXRzIGFnYWluc3QgdGhl IENhcGFiaWxpdGllcyBzdHJpbmcuIEE8YnI+DQomZ3Q7IDAgaW4gTWFzayBtZWFucyAmcXVvdDtJ IGRvbid0IGNhcmUgaWYgd2UgZG8gdGhpcyBjYXBhYmlsaXR5IG9yIG5vdCZxdW90OywgYW5kIGEg MTxicj4NCiZndDsgbWVhbnMgJnF1b3Q7d2UgbXVzdCAob3IgbXVzdCBub3QpIGFncmVlIG9uIHRo aXMgY2FwYWJpbGl0eSBpbiBvcmRlciB0byBjb21lPGJyPg0KJmd0OyB1cCZxdW90Oy48YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQS5jYXBhYmlsaXRpZXMgPSAwMDAwMDxicj4NCiZndDsg Jmd0OyBBLm1hc2sgPSAwMDAwMDxicj4NCiZndDsgPGJyPg0KJmd0OyBXaHkgaXMgdGhpcyBub3Q8 YnI+DQomZ3Q7IDxicj4NCiZndDsgQS5jYXBhYmlsaXRpZXMgPSAxMTExMTxicj4NCiZndDsgQS5t YXNrID0gMDAwMDA8YnI+DQomZ3Q7IDxicj4NCjxicj4NCkFsdGhvdWdodCBJIGRpZG4ndCBwdXQg aXQgaW4gbXkgZW1haWwsIGEgY2FwYWJpbHRpZXMgb2YgMSBhbmQgbWFzayBvZiAwIGlzIGlsbGVn YWwuIFRoaXMgaXMgcGFydGx5IGJlY2F1c2UgaXQgbWFrZXMgbm8gc2Vuc2UgKCZxdW90O0kgcmVx dWlyZSB0aGlzIGNhcGFiaWxpdHkgYnV0IEkgZG9uJ3QgY2FyZSBpZiB3ZSBkbyBpdCBvciBub3Qm cXVvdDspIGFuZCBwYXJ0bHkgYmVjYXVzZSB0aGVyZSdzIGEgY2FzZSB3aGljaCBkb2Vzbid0IGNv bnZlcmdlIHJpZ2h0Ojxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQi Pjxmb250IGNvbG9yPSIjMDAwMGZmIj5bSlJdIFRoZSBtZWFuaW5nIG9mIGNhcD0xMTExMSBhbmQg bWFzaz0wMDAwMCB3b3VsZCBiZSAmcXVvdDtJIGFtIGNhcGFibGUgb2YgYWxsIGZpdmUgdGhpbmdz Jm5ic3A7YnV0IEkgZG9uJ3QgY2FyZSBpZiB3ZSBkbyBpdCBvciBub3QmcXVvdDs8L2ZvbnQ+PC9k aXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PGJyPg0KSWYgSSBoYXZlIDExMTEx LzAwMDAwIG9uIG9uZSBzaWRlIGFuZCAwMDAwMC8wMDAwMCBvbiB0aGUgb3RoZXIgSSBlbmQgdXAg d2l0aDxicj4NCjxicj4NCkEuY2FwID0gMTExMTEsIEEubWFzayA9IDAwMDAwPGJyPg0KWi5jYXAg PSAwMDAwMCwgWi5tYXNrID0gMDAwMDA8YnI+DQo8YnI+DQo8YnI+DQpyZXMgPSAoMTExMTExICZh bXA7IDAwMDAwKSBeICgwMDAwMCAmYW1wOyAwMDAwMCk8YnI+DQpyZXMgPSAxMTExMSBeIDAwMDAw ID0gMTExMTE8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij48Zm9u dCBjb2xvcj0iIzAwMDBmZiI+W0pSXSBUaGUgYW5zd2VyIGZvciAoMTExMTEgJmFtcDsgMDAwMDAp IHNob3VsZCBiZSAwMDAwMC4gQW5kIHRoZSBmaW5hbCByZXN1bHQgb2YgMDAwMDAgXiAwMDAwMCB3 aWxsIGJlIDAwMDAwLjwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0 Ij48YnI+DQphbmQgaWYgcmVzICE9IDAgdGhlbiB0aGUgbm9kZXMgY2FuJ3QgY29udmVyZ2Ugb24g YSBjb21tb24gc3Vic2V0LCBldmVuIHRob3VnaCB0aGVyZSBhcmUgMl41IGNvbWJpbmF0aW9ucyB0 aGF0IHdvdWxkIHdvcmsgZm9yIGJvdGggbm9kZXMuPGJyPg0KPGJyPg0KJm5ic3A7DQo8ZGl2IHN0 eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PGZvbnQgY29sb3I9IiMwMDAwZmYiPltKUl0gTm93LCB0 d28gZW5kcyB3aWxsIG9wZXJhdGUgd2l0aG91dCBhbnkgY2FwYWJpbGl0aWVzLjwvZm9udD48YnI+ DQo8YnI+DQplcmljPGJyPg0KPGJyPg0KJmd0OyA/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC9Mb2E8 YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGlzIHNheXMgJnF1b3Q7 SSBhbSBjYXBhYmxlIG9mIHN1cHBvcnRpbmcgYWxsIGNhcGFiaWxpdGllcyBhbmQgSSBkb24ndDxi cj4NCiZndDsgY2FyZSBpZiB3ZSBkbyBhbnkgb2YgdGhlbSBvciBub3QmcXVvdDs8YnI+DQomZ3Q7 IDxTTklQPjxicj4NCiZndDsgPGJyPg0KJmd0OyAtLTxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IExvYSBBbmRlcnNzb24gZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbTxicj4NCiZn dDsgU2VuaW9yIE1QTFMgRXhwZXJ0IGxvYUBwaS5udTxicj4NCiZndDsgSHVhd2VpIFRlY2hub2xv Z2llcyAoY29uc3VsdGFudCkgcGhvbmU6ICYjNDM7NDYgNzM5IDgxIDIxIDY0PGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptcGxzIG1haWxp bmcgbGlzdDxicj4NCm1wbHNAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHM8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28663D52SMTP2etriinfo_-- From ryoo@etri.re.kr Mon Aug 19 07:41:50 2013 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 F1AD111E8106 for ; Mon, 19 Aug 2013 07:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.698 X-Spam-Level: X-Spam-Status: No, score=-101.698 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DNkAK5mJqrg for ; Mon, 19 Aug 2013 07:41:45 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3138721F9B18 for ; Mon, 19 Aug 2013 07:41:44 -0700 (PDT) Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 19 Aug 2013 23:41:37 +0900 Received: from SMTP2.etri.info ([169.254.2.105]) by SMTP1.etri.info ([129.254.28.71]) with mapi id 14.01.0355.002; Mon, 19 Aug 2013 23:41:35 +0900 From: "Ryoo, Jeong-dong" To: "Eric Osborne (eosborne)" , "mpls@ietf.org" Thread-Topic: Mode negotiation for PSC Thread-Index: Ac6ULYh0Wz1ulMCERKa7JFuZBxS/GAIuVFyZ Date: Mon, 19 Aug 2013 14:41:34 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A28663D9D@SMTP2.etri.info> References: <20ECF67871905846A80F77F8F4A27572102C229B@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A27572102C229B@xmb-rcd-x09.cisco.com> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.45] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28663D9DSMTP2etriinfo_" MIME-Version: 1.0 Subject: Re: [mpls] Mode negotiation for PSC 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, 19 Aug 2013 14:41:50 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28663D9DSMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpFcmljLA0KDQpJbiB0aGUgbmVnb3RpYXRpb24gcHJvY2VkdXJlIG9mIE1ldGhvZCAyLCB5b3Ug c2VlbSB0byBiZSBhc3N1bWluZyB0aGF0IGlmIG9uZSBzaWRlIGhhcyBhIGNhcGFiaWxpdHksIHRo ZW4gaXQgY2FuIGFsc28gb3BlcmF0ZSB3aXRob3V0IHRoYXQgcGFydGljdWxhciBjYXBhYmlsaXR5 LCBiZWNhdXNlIHdpdGggdGhlIGZvbGxvd2luZyBjYXBzL21hc2tzIGZvciBBIGFuZCBaOg0KIkEu Q2FwYWJpbGl0aWVzID09IDAxMTAwDQpBLk1hc2sgPT0gMDExMDANClouQ2FwYWJpbGl0aWVzID09 IDAxMTEwDQpaLk1hc2sgPT0gMDExMTAiDQp5b3UgY29uY2x1ZGVkICJuZWdvdGlhdGVkX3NldCA9 IDAxMTAwIg0KDQpIb3dldmVyLCB0aGF0IGFzc3VtcHRpb24gaXMgbm90IHRydWUgaW4gZ2VuZXJh bC4NCkRlcGVuZGluZyBvbiB0aGUgbmF0dXJlIG9mIHRoZSBjYXBhYmlsaXR5LCB3ZSB3b3VsZCBu ZWVkIGEgY29tcGxldGVseSBkaWZmZXJlbnQgc2V0IG9mIHN0YXRlIG1hY2hpbmVzIHRvIHN1cHBv cnQgdGhlIGNhc2UgdGhhdCBkaXNhYmxlcyB0aGUgY2FwYWJpbGl0eS4NCg0KQmVzdCByZWdhcmRz LA0KDQpKZW9uZy1kb25nDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K RnJvbSA6ICJFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSIgPGVvc2Jvcm5lQGNpc2NvLmNvbT4NClNl bnQgOiAyMDEzLTA4LTA4IDIxOjM0OjU1ICggKzA5OjAwICkNClRvIDogbXBsc0BpZXRmLm9yZyA8 bXBsc0BpZXRmLm9yZz4NCkNjIDoNClN1YmplY3QgOiBbbXBsc10gTW9kZSBuZWdvdGlhdGlvbiBm b3IgUFNDDQoNCg0KQXMgcGVyIGxhc3QgRnJpZGF5J3MgcHJlc2VudGF0aW9uIGluIEJlcmxpbiAo aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84Ny9zbGlkZXMvc2xpZGVzLTg3LW1wbHMt MTUucHB0KSwgd2Ugd2lsbCBiZSBhZGRpbmcgIklUVSBNb2RlIiB0byBQU0MgdG8gYWxsb3cgZm9y IGJlaGF2aW9ycyB0aGF0IHNhdGlzZnkgYm90aCBJRVRGIGFuZCBJVFUgcmVxdWlyZW1lbnRzLiBU aGlzIG1vZGUgd2lsbCBiZSBiYWNrd2FyZC1jb21wYXRpYmxlIGFuZCBuZWdvdGlhdGVkIHVzaW5n IFBTQyBUTFZzLg0KDQpUaGUgZHJhZnRzIGluIHRoYXQgcHB0IGRlZmluZSBmaXZlIGNhcGFiaWxp dGllcyB3aGljaCBzZXBhcmF0ZSBJVFUgbW9kZSBmcm9tIElFVEYgbW9kZS4gSUVURiBtb2RlIGlz IGRlZmluZWQgYXMgdGhlIGFic2VuY2Ugb2YgdGhlc2UgZml2ZSBjYXBhYmlsaXRpZXMsIGFuZCBJ VFUgbW9kZSBpcyBkZWZpbmVkIGFzIHRoZSB1c2Ugb2YgYWxsIGZpdmUgb2YgdGhlc2UgY2FwYWJp bGl0aWVzLiBJdCBtYXkgaGVscCB0byB0aGluayBvZiBJRVRGIG1vZGUgYXMgMDAwMDAgYW5kIElU VSBtb2RlIGFzIDExMTExLiBUaGUgbWVjaGFuaXNtIHRvIGRlZmluZSBhbmQgbmVnb3RpYXRlIHRo ZXNlIG1vZGVzIHdpbGwgaGF2ZSByb29tIGZvciBleHBhbnNpb24gcGFzdCBmaXZlIGJpdHMsIHNv IGlmIHdlIGV2ZXIgZGVjaWRlIHdlIG5lZWQgbW9yZSBjYXBhYmlsaXRpZXMgbmVnb3RpYXRpb24g aW4gUFNDIChzaGFyZWQgbWVzaD8gbTpuPyBvdGhlciBmYW5jeSBzdHVmZj8pIHdlIGNhbi4NCg0K QXMgb2YgcmlnaHQgbm93IHdlIGFyZSBvbmx5IGRpc2N1c3NpbmcgdHdvIG1vZGVzLCBidXQgaXQg aXMgcG9zc2libGUgdG8gZGVmaW5lIGEgbW9kZSB3aGljaCBpcyBzb21lIGNvbWJpbmF0aW9uIG9m IHRoZXNlIGZpdmUgdGhpbmdzIG90aGVyIHRoYW4gMDAwMDAgb3IgMTExMTEuIFNvIGEgbW9kZSBp cyByZWFsbHkgdGhlIHNldCBvZiBuZWdvdGlhdGVkIGNhcGFiaWxpdGllcyBiZXR3ZWVuIHR3byBk ZXZpY2VzLg0KDQpUaGVyZSBhcmUgdHdvIHdheXMgd2UgY2FuIG5lZ290aWF0ZSB0aGUgdXNlIG9m IG9uZSBtb3JlIG9yIHRoZSBvdGhlcjoNCg0KMSkgRWFjaCBub2RlIGFubm91bmNlcyB0aGUgbW9k ZSB0aGF0IGl0IHdhbnRzLCBhbmQgaWYgdGhlIG90aGVyIHNpZGUgZG9lc24ndCB3YW50IGV4YWN0 bHkgdGhlIHNhbWUgbW9kZSB0aGVuIFBTQyB3aWxsIG5vdCBmdW5jdGlvbi4gVGhhdCBpcywgYm90 aCBub2RlcyBzYXkgIm15IG1vZGUgaXMgMGJ4eHh4eCIgKGZvciBub3csIGVpdGhlciAwMDAwMCBv ciAxMTExMSkgYW5kIGlmIGJvdGggbm9kZXMgZG9uJ3Qgc2F5IHRoZSBzYW1lIHRoaW5nIHRoZW4g dGhleSBjb21wbGFpbiB0byB0aGUgb3BlcmF0b3IgYW5kIHJlZnVzZSB0byBmdW5jdGlvbi4NCg0K QWR2YW50YWdlOiBlYXN5LCBhbmQgaWYgYm90aCBlbmRzIGFyZSBpbiBhIHNpbmdsZSBhZG1pbmlz dHJhdGl2ZSBkb21haW4gSSBleHBlY3QgdGhlIG9wZXJhdG9yIHRvIGJlIGFibGUgdG8gY29uZmln dXJlIGJvdGggZW5kcyB0byBtYXRjaC4NCg0KRGlzYWR2YW50YWdlOiB0cmlja3kgaWYgd2UgZXZl ciBzdGFydCB0YWxraW5nIGFib3V0IG1vZGVzIG90aGVyIHRoYW4gMDAwMDAgb3IgMTExMTEuIEkg ZG9uJ3Qgd2FudCBhIG5vZGUgdG8gc2F5ICJJIHN1cHBvcnQgbW9kZSAwMDAwMCwgbW9kZSAwMDAw MSwgbW9kZSAwMDAxMCwgbW9kZSAwMDAxMSwgLi4uLiBtb2RlIDExMTExIiBiZWNhdXNlIGlmIHdl IGFkZCBhIGZldyBtb3JlIGNhcGFiaWxpdGllcyB3ZSBjb3VsZCBlbmQgdXAgYW5ub3VuY2luZyB0 aGUgc3VwcG9ydCBvZiBodW5kcmVkcyBvciB0aG91c2FuZHMgb2YgbW9kZXMuIERvZXMgbm90IGFs bG93IFBTQyB0byBjb21lIHVwIHVubGVzcyB0aGUgbW9kZXMgbWF0Y2ggb24gYm90aCBzaWRlcywg ZXZlbiBpZiB0aGVyZSBpcyBzb21lIGNvbW1vbiBzdWJzZXQgdGhleSBjb3VsZCBib3RoIGFncmVl IG9uLg0KDQoNCm9yDQoNCg0KMikgRWFjaCBub2RlIGFubm91bmNlcyB0aGUgc2V0IG9mIGNhcGFi aWxpdGllcyB0aGF0IGl0IGNhbiBzdXBwb3J0IGFsb25nIHdpdGggdGhlIG9uZXMgdGhhdCBpdCBy ZXF1aXJlcywgYW5kIGlmIHRoZSB0d28gbm9kZXMgY2FuIGZpbmQgYSBjb21tb24gc3Vic2V0IG9m IGZlYXR1cmVzIHRoZW4gdGhleSB3aWxsIGNvbnZlcmdlIG9uIHRob3NlIGZlYXR1cmVzIGluIFBT Qy4NCg0KQWR2YW50YWdlOiBmbGV4aWJsZS4gSWYgdHdvIGVuZHBvaW50cyBjYW4gZmluZCBhIGNv bW1vbiBmZWF0dXJlIHN1YnNldCAoc2VlIGV4YW1wbGUgYmVsb3cpIHRoZW4gdGhleSB3aWxsIGNv bWUgdXAuDQoNCkRpc2FkdmFudGFnZTogbW9yZSBjb21wbGV4IGNvZGUsIGVhc2llciB0byBnZXQg d3JvbmcgYW5kIGNvbnZlcmdlIG9uIGEgdW5kZXNpcmFibGUgc3Vic2V0Lg0KDQoNCkV4YW1wbGVz IG9mIGVhY2ggbmVnb3RpYXRpb24gbWV0aG9kIGFyZSBiZWxvdywgYm90aCBmb3IgY2xhcml0eSBh bmQgdG8gZGVtb25zdHJhdGUgdGhhdCBtZXRob2QgIzIgd29ya3MuIE15IHF1ZXN0aW9uIGZvciB0 aGUgV0cgaXMsIHdoaWNoIG9uZSB3b3VsZCBwZW9wbGUgcHJlZmVyLCBhbmQgd2h5Pw0KDQoNCg0K DQoNCg0KZXJpYw0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCkV4 YW1wbGVzDQo9PT09PT09PQ0KQWxsIGV4YW1wbGVzIGFyZSBiZXR3ZWVuIHR3byBub2RlcywgQSBh bmQgWi4gVGhlc2UgZXhhbXBsZXMgZm9jdXMgb24gdGhlIGFjdHVhbCBuZWdvdGlhdGlvbiwgbm90 IG9uIHRoZSBuZWNlc3NhcnkgVExWIGJpdHMgdG8gZW5hYmxlIHRoZSBuZWdvdGlhdGlvbi4NCg0K RXhhbXBsZSBvZiBtZXRob2QgMQ0KLS0tLS0tLS0tLS0tLS0tLS0tLQ0KTm9kZSBBIHNlbmRzIGEg c2luZ2xlIFRMViB0byBOb2RlIFogY29udGFpbmcgdGhlIG1vZGUgYml0bWFwLiBOb2RlIFogc2Vu ZHMgdGhlIHNhbWUgdG8gQS4gQ2FsbCB0aGVtIEEuTW9kZSBhbmQgWi5Nb2RlLiBJZiB0aGV5IGRv IG5vdCBtYXRjaCB0aGVuIHNvbWUgZGVmYXVsdCBiZWhhdmlvciBoYXBwZW5zIC0gZWl0aGVyIFBT QyBkb2Vzbid0IGNvbWUgdXAgb3IgdGhleSBkZWZhdWx0IHRvIG9uZSBwcmVkZXRlcm1pbmVkIG1v ZGUuDQoNCkEubW9kZSA9IFouIG1vZGUgPSAwMDAwMA0KQS0+WjogIkkgYW0gY29uZmlndXJlZCBm b3IgbW9kZSAwMDAwMCINClotPkE6ICJJIGFtIGNvbmZpZ3VyZWQgZm9yIG1vZGUgMDAwMDAiDQoN ClRoaXMgcmVzdWx0cyBpbiBQU0MgY29taW5nIHVwIGluIElFVEYgbW9kZS4NCg0KQS5tb2RlID0g Wi5tb2RlID0gMTExMTENCkEtPlo6ICJJIGFtIGNvbmZpZ3VyZWQgZm9yIG1vZGUgMTExMTEiDQpa LT5BOiAiSSBhbSBjb25maWd1cmVkIGZvciBtb2RlIDExMTExIg0KDQpUaGlzIHJlc3VsdHMgaW4g UFNDIGNvbWluZyB1cCBpbiBJVFUgbW9kZS4NCg0KQS5tb2RlICE9IFoubW9kZSAoc2F5LCAwMDAw MSBhbmQgMDAwMTApDQpBLT5aOiAiSSBhbSBjb25maWd1cmVkIGZvciBtb2RlIDAwMDAxIg0KWi0+ QTogIkkgYW0gY29uZmlndXJlZCBmb3IgbW9kZSAwMDAxMCINCg0KUFNDIGRvZXMgbm90IGNvbWUg dXAuDQoNCg0KDQpFeGFtcGxlIG9mIG1ldGhvZCAyDQotLS0tLS0tLS0tLS0tLS0tLS0tDQpCb3Ro IE5vZGUgQSBhbmQgTm9kZSBaIGFubm91bmNlIHR3byB0aGluZ3MgLSBDYXBhYmlsaXRpZXMgYW5k IE1hc2suDQpDYXBhYmlsaXRpZXMgaXMgYSBiaXRtYXAgb2YgdGhlIGNhcGFiaWxpdGllcyB0aGF0 IGFyZSBzdXBwb3J0ZWQuDQpNYXNrIGlzIGEgbWFzayBvZiBkb24ndC1jYXJlIGJpdHMgYWdhaW5z dCB0aGUgQ2FwYWJpbGl0aWVzIHN0cmluZy4gQSAwIGluIE1hc2sgbWVhbnMgIkkgZG9uJ3QgY2Fy ZSBpZiB3ZSBkbyB0aGlzIGNhcGFiaWxpdHkgb3Igbm90IiwgYW5kIGEgMSBtZWFucyAid2UgbXVz dCAob3IgbXVzdCBub3QpIGFncmVlIG9uIHRoaXMgY2FwYWJpbGl0eSBpbiBvcmRlciB0byBjb21l IHVwIi4NCg0KQS5jYXBhYmlsaXRpZXMgPSAwMDAwMA0KQS5tYXNrID0gMDAwMDANCg0KVGhpcyBz YXlzICJJIGFtIGNhcGFibGUgb2Ygc3VwcG9ydGluZyBhbGwgY2FwYWJpbGl0aWVzIGFuZCBJIGRv bid0IGNhcmUgaWYgd2UgZG8gYW55IG9mIHRoZW0gb3Igbm90Ig0KDQpBLmNhcGFiaWxpdGllcyA9 IDAwMDAwDQpBLm1hc2sgPSAxMTExMQ0KDQpUaGlzIHNheXMgIldlIG11c3Qgbm90IHVzZSBhbnkg b2YgdGhlIG9wdGlvbmFsIGNhcGFiaWxpdGllcyIgLSBDYXBhYmlsaXRpZXMgYml0cyBhcmUgYWxs IHplcm8sIGFuZCBNYXNrIGJpdHMgc2F5ICJ3ZSBtdXN0IGFncmVlIHRoYXQgdGhlIGNvcnJlc3Bv bmRpbmcgY2FwYWJpbGl0eSBpcyB6ZXJvIi4gVGhpcyBpcyAnSUVURiBtb2RlJy4NCg0KQS5jYXBh YmlsaXRpZXMgPSAxMTExMQ0KQS5tYXNrID0gMTExMTENCg0KVGhpcyBpcyAnSVRVIE1vZGUnDQoN CldoZXJlIGl0IGdldHMgY29tcGxpY2F0ZWQgKG9yIGF3ZXNvbWUsIGRlcGVuZGluZyBvbiB5b3Vy IHBlcnNwZWN0aXZlKSBpcyB3aGVuIHlvdSBoYXZlIHZhcmlvdXMgc3Vic2V0cy4gQ29uc2lkZXI6 DQoNCkEuQ2FwYWJpbGl0aWVzID09IDAxMTAwDQpBLk1hc2sgPT0gMDExMDANCg0KWi5DYXBhYmls aXRpZXMgPT0gMDExMTANClouTWFzayA9PSAwMTExMA0KDQoNCk5lZ290aWF0aW9uIHByb2NlZHVy ZXMuDQpFYWNoIHNpZGUgZG9lczoNCg0KDQpyZXMgPSAoQS5DYXBhYmlsaXRlcyAmIFouTWFzaykg XiAoWi5DYXBhYmlsaXRpZXMgJiBBLk1hc2spDQpyZXMgPSAoMDExMDAgJiAwMTExMCkgXiAoMDEx MTAgJiAwMTEwMCkNCnJlcyA9ICgwMTEwMCkgXiAoMDExMDApDQpyZXMgPSAwMDAwMA0KDQppZiBy ZXMgPT0gMCB0aGVuIGl0IGlzIHBvc3NpYmxlIGZvciBib3RoIHNpZGVzIHRvIGZpbmQgYSBjb21t b24gc3Vic2V0IHRoYXQgdGhleSBzdXBwb3J0Lg0KVGhpcyBjb21tb24gc3Vic2V0IGlzIGNhbGxl ZCB0aGUgJ25lZ290aWF0ZWQgc2V0JywgYW5kIGlzIGRldGVybWluZWQgYnk6DQoNCm5lZ290aWF0 ZWRfc2V0ID0gQS5DYXBhYmlsaXRpZXMgfCBCLkNhcGFiaWxpdGllcw0KbmVnb3RpYXRlZF9zZXQg PSAwMTEwMCB8IDAxMTEwDQpuZWdvdGlhdGVkX3NldCA9IDAxMTAwDQoNCmlmIHJlcyAhPSAwIHRo ZW4gaXQgaXMgaW1wb3NzaWJsZSB0byBmaW5kIGEgc3Vic2V0IHRoYXQgdGhlIHR3byBlbmRzIGNh biBhZ3JlZSBvbiwgYW5kIFBTQyB3aWxsIG5ldmVyIGNvbWUgdXAuDQoNCk9uY2UgZWFjaCBzaWRl IGNvbXB1dGVzIHRoZSBuZWdvdGlhdGVkIHNldCwgdGhleSBzaWduYWwgaXQgYW5kIFBTQyBzdGFy dHMgdG8gd29yay4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28663D9DSMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij48YnI+DQpFcmljLDwvZGl2Pg0KPGRpdiBzdHls ZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlH SFQ6IDE1cHQiPkluIHRoZSBuZWdvdGlhdGlvbiBwcm9jZWR1cmUgb2YmbmJzcDtNZXRob2QgMiwg eW91IHNlZW0gdG8gYmUgYXNzdW1pbmcgdGhhdCBpZiBvbmUgc2lkZSBoYXMgYSBjYXBhYmlsaXR5 LCB0aGVuIGl0IGNhbiBhbHNvIG9wZXJhdGUgd2l0aG91dCB0aGF0IHBhcnRpY3VsYXIgY2FwYWJp bGl0eSwgYmVjYXVzZSB3aXRoIHRoZSBmb2xsb3dpbmcgY2Fwcy9tYXNrcyBmb3IgQSBhbmQgWjo8 L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mcXVvdDtBLkNhcGFiaWxpdGll cyA9PSAwMTEwMDxicj4NCkEuTWFzayA9PSAwMTEwMDxicj4NClouQ2FwYWJpbGl0aWVzID09IDAx MTEwPGJyPg0KWi5NYXNrID09IDAxMTEwJnF1b3Q7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhF SUdIVDogMTVwdCI+eW91IGNvbmNsdWRlZCAmcXVvdDtuZWdvdGlhdGVkX3NldCA9IDAxMTAwJnF1 b3Q7PGJyPg0KPGJyPg0KSG93ZXZlciwgdGhhdCBhc3N1bXB0aW9uIGlzIG5vdCB0cnVlIGluIGdl bmVyYWwuPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+RGVwZW5kaW5nIG9u IHRoZSBuYXR1cmUgb2YmbmJzcDt0aGUgY2FwYWJpbGl0eSwgd2UmbmJzcDt3b3VsZCBuZWVkIGEg Y29tcGxldGVseSBkaWZmZXJlbnQgc2V0IG9mIHN0YXRlJm5ic3A7bWFjaGluZXMgdG8gc3VwcG9y dCB0aGUgY2FzZSB0aGF0IGRpc2FibGVzIHRoZSBjYXBhYmlsaXR5LjwvZGl2Pg0KPGRpdiBzdHls ZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlH SFQ6IDE1cHQiPkJlc3QgcmVnYXJkcyw8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAx NXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5KZW9uZy1k b25nPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8 ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJM SU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDog MTVwdCI+DQo8aHIgdGFiaW5kZXg9Ii0xIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlH SFQ6IDE1cHQiPjxiPkZyb20gOiA8L2I+JnF1b3Q7RXJpYyBPc2Jvcm5lIChlb3Nib3JuZSkmcXVv dDsgJmx0O2Vvc2Jvcm5lQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5TZW50IDogPC9iPjIwMTMtMDgt MDggMjE6MzQ6NTUgKCAmIzQzOzA5OjAwICk8YnI+DQo8Yj5UbyA6IDwvYj5tcGxzQGlldGYub3Jn ICZsdDttcGxzQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjIDogPC9iPjxicj4NCjxiPlN1YmplY3Qg OiA8L2I+W21wbHNdIE1vZGUgbmVnb3RpYXRpb24gZm9yIFBTQzxicj4NCjxicj4NCjxicj4NCkFz IHBlciBsYXN0IEZyaWRheSdzIHByZXNlbnRhdGlvbiBpbiBCZXJsaW4gKGh0dHA6Ly93d3cuaWV0 Zi5vcmcvcHJvY2VlZGluZ3MvODcvc2xpZGVzL3NsaWRlcy04Ny1tcGxzLTE1LnBwdCksIHdlIHdp bGwgYmUgYWRkaW5nICZxdW90O0lUVSBNb2RlJnF1b3Q7IHRvIFBTQyB0byBhbGxvdyBmb3IgYmVo YXZpb3JzIHRoYXQgc2F0aXNmeSBib3RoIElFVEYgYW5kIElUVSByZXF1aXJlbWVudHMuIFRoaXMg bW9kZSB3aWxsIGJlIGJhY2t3YXJkLWNvbXBhdGlibGUgYW5kDQogbmVnb3RpYXRlZCB1c2luZyBQ U0MgVExWcy4gPGJyPg0KPGJyPg0KVGhlIGRyYWZ0cyBpbiB0aGF0IHBwdCBkZWZpbmUgZml2ZSBj YXBhYmlsaXRpZXMgd2hpY2ggc2VwYXJhdGUgSVRVIG1vZGUgZnJvbSBJRVRGIG1vZGUuIElFVEYg bW9kZSBpcyBkZWZpbmVkIGFzIHRoZSBhYnNlbmNlIG9mIHRoZXNlIGZpdmUgY2FwYWJpbGl0aWVz LCBhbmQgSVRVIG1vZGUgaXMgZGVmaW5lZCBhcyB0aGUgdXNlIG9mIGFsbCBmaXZlIG9mIHRoZXNl IGNhcGFiaWxpdGllcy4gSXQgbWF5IGhlbHAgdG8gdGhpbmsgb2YgSUVURiBtb2RlIGFzDQogMDAw MDAgYW5kIElUVSBtb2RlIGFzIDExMTExLiBUaGUgbWVjaGFuaXNtIHRvIGRlZmluZSBhbmQgbmVn b3RpYXRlIHRoZXNlIG1vZGVzIHdpbGwgaGF2ZSByb29tIGZvciBleHBhbnNpb24gcGFzdCBmaXZl IGJpdHMsIHNvIGlmIHdlIGV2ZXIgZGVjaWRlIHdlIG5lZWQgbW9yZSBjYXBhYmlsaXRpZXMgbmVn b3RpYXRpb24gaW4gUFNDIChzaGFyZWQgbWVzaD8gbTpuPyBvdGhlciBmYW5jeSBzdHVmZj8pIHdl IGNhbi4NCjxicj4NCjxicj4NCkFzIG9mIHJpZ2h0IG5vdyB3ZSBhcmUgb25seSBkaXNjdXNzaW5n IHR3byBtb2RlcywgYnV0IGl0IGlzIHBvc3NpYmxlIHRvIGRlZmluZSBhIG1vZGUgd2hpY2ggaXMg c29tZSBjb21iaW5hdGlvbiBvZiB0aGVzZSBmaXZlIHRoaW5ncyBvdGhlciB0aGFuIDAwMDAwIG9y IDExMTExLiBTbyBhIG1vZGUgaXMgcmVhbGx5IHRoZSBzZXQgb2YgbmVnb3RpYXRlZCBjYXBhYmls aXRpZXMgYmV0d2VlbiB0d28gZGV2aWNlcy48YnI+DQo8YnI+DQpUaGVyZSBhcmUgdHdvIHdheXMg d2UgY2FuIG5lZ290aWF0ZSB0aGUgdXNlIG9mIG9uZSBtb3JlIG9yIHRoZSBvdGhlcjo8YnI+DQo8 YnI+DQoxKSBFYWNoIG5vZGUgYW5ub3VuY2VzIHRoZSBtb2RlIHRoYXQgaXQgd2FudHMsIGFuZCBp ZiB0aGUgb3RoZXIgc2lkZSBkb2Vzbid0IHdhbnQgZXhhY3RseSB0aGUgc2FtZSBtb2RlIHRoZW4g UFNDIHdpbGwgbm90IGZ1bmN0aW9uLiBUaGF0IGlzLCBib3RoIG5vZGVzIHNheSAmcXVvdDtteSBt b2RlIGlzIDBieHh4eHgmcXVvdDsgKGZvciBub3csIGVpdGhlciAwMDAwMCBvciAxMTExMSkgYW5k IGlmIGJvdGggbm9kZXMgZG9uJ3Qgc2F5IHRoZSBzYW1lIHRoaW5nIHRoZW4NCiB0aGV5IGNvbXBs YWluIHRvIHRoZSBvcGVyYXRvciBhbmQgcmVmdXNlIHRvIGZ1bmN0aW9uLjxicj4NCjxicj4NCkFk dmFudGFnZTogZWFzeSwgYW5kIGlmIGJvdGggZW5kcyBhcmUgaW4gYSBzaW5nbGUgYWRtaW5pc3Ry YXRpdmUgZG9tYWluIEkgZXhwZWN0IHRoZSBvcGVyYXRvciB0byBiZSBhYmxlIHRvIGNvbmZpZ3Vy ZSBib3RoIGVuZHMgdG8gbWF0Y2guPGJyPg0KPGJyPg0KRGlzYWR2YW50YWdlOiB0cmlja3kgaWYg d2UgZXZlciBzdGFydCB0YWxraW5nIGFib3V0IG1vZGVzIG90aGVyIHRoYW4gMDAwMDAgb3IgMTEx MTEuIEkgZG9uJ3Qgd2FudCBhIG5vZGUgdG8gc2F5ICZxdW90O0kgc3VwcG9ydCBtb2RlIDAwMDAw LCBtb2RlIDAwMDAxLCBtb2RlIDAwMDEwLCBtb2RlIDAwMDExLCAuLi4uIG1vZGUgMTExMTEmcXVv dDsgYmVjYXVzZSBpZiB3ZSBhZGQgYSBmZXcgbW9yZSBjYXBhYmlsaXRpZXMgd2UgY291bGQgZW5k IHVwIGFubm91bmNpbmcNCiB0aGUgc3VwcG9ydCBvZiBodW5kcmVkcyBvciB0aG91c2FuZHMgb2Yg bW9kZXMuIERvZXMgbm90IGFsbG93IFBTQyB0byBjb21lIHVwIHVubGVzcyB0aGUgbW9kZXMgbWF0 Y2ggb24gYm90aCBzaWRlcywgZXZlbiBpZiB0aGVyZSBpcyBzb21lIGNvbW1vbiBzdWJzZXQgdGhl eSBjb3VsZCBib3RoIGFncmVlIG9uLjxicj4NCjxicj4NCjxicj4NCm9yPGJyPg0KPGJyPg0KPGJy Pg0KMikgRWFjaCBub2RlIGFubm91bmNlcyB0aGUgc2V0IG9mIGNhcGFiaWxpdGllcyB0aGF0IGl0 IGNhbiBzdXBwb3J0IGFsb25nIHdpdGggdGhlIG9uZXMgdGhhdCBpdCByZXF1aXJlcywgYW5kIGlm IHRoZSB0d28gbm9kZXMgY2FuIGZpbmQgYSBjb21tb24gc3Vic2V0IG9mIGZlYXR1cmVzIHRoZW4g dGhleSB3aWxsIGNvbnZlcmdlIG9uIHRob3NlIGZlYXR1cmVzIGluIFBTQy48YnI+DQo8YnI+DQpB ZHZhbnRhZ2U6IGZsZXhpYmxlLiBJZiB0d28gZW5kcG9pbnRzIGNhbiBmaW5kIGEgY29tbW9uIGZl YXR1cmUgc3Vic2V0IChzZWUgZXhhbXBsZSBiZWxvdykgdGhlbiB0aGV5IHdpbGwgY29tZSB1cC48 YnI+DQo8YnI+DQpEaXNhZHZhbnRhZ2U6IG1vcmUgY29tcGxleCBjb2RlLCBlYXNpZXIgdG8gZ2V0 IHdyb25nIGFuZCBjb252ZXJnZSBvbiBhIHVuZGVzaXJhYmxlIHN1YnNldC48YnI+DQo8YnI+DQo8 YnI+DQpFeGFtcGxlcyBvZiBlYWNoIG5lZ290aWF0aW9uIG1ldGhvZCBhcmUgYmVsb3csIGJvdGgg Zm9yIGNsYXJpdHkgYW5kIHRvIGRlbW9uc3RyYXRlIHRoYXQgbWV0aG9kICMyIHdvcmtzLiBNeSBx dWVzdGlvbiBmb3IgdGhlIFdHIGlzLCB3aGljaCBvbmUgd291bGQgcGVvcGxlIHByZWZlciwgYW5k IHdoeT88YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQplcmljPGJyPg0K PGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0K PGJyPg0KRXhhbXBsZXM8YnI+DQo9PT09PT09PTxicj4NCkFsbCBleGFtcGxlcyBhcmUgYmV0d2Vl biB0d28gbm9kZXMsIEEgYW5kIFouIFRoZXNlIGV4YW1wbGVzIGZvY3VzIG9uIHRoZSBhY3R1YWwg bmVnb3RpYXRpb24sIG5vdCBvbiB0aGUgbmVjZXNzYXJ5IFRMViBiaXRzIHRvIGVuYWJsZSB0aGUg bmVnb3RpYXRpb24uPGJyPg0KPGJyPg0KRXhhbXBsZSBvZiBtZXRob2QgMTxicj4NCi0tLS0tLS0t LS0tLS0tLS0tLS08YnI+DQpOb2RlIEEgc2VuZHMgYSBzaW5nbGUgVExWIHRvIE5vZGUgWiBjb250 YWluZyB0aGUgbW9kZSBiaXRtYXAuIE5vZGUgWiBzZW5kcyB0aGUgc2FtZSB0byBBLiBDYWxsIHRo ZW0gQS5Nb2RlIGFuZCBaLk1vZGUuIElmIHRoZXkgZG8gbm90IG1hdGNoIHRoZW4gc29tZSBkZWZh dWx0IGJlaGF2aW9yIGhhcHBlbnMgLSBlaXRoZXIgUFNDIGRvZXNuJ3QgY29tZSB1cCBvciB0aGV5 IGRlZmF1bHQgdG8gb25lIHByZWRldGVybWluZWQgbW9kZS48YnI+DQo8YnI+DQpBLm1vZGUgPSBa LiBtb2RlID0gMDAwMDA8YnI+DQpBLSZndDtaOiAmcXVvdDtJIGFtIGNvbmZpZ3VyZWQgZm9yIG1v ZGUgMDAwMDAmcXVvdDs8YnI+DQpaLSZndDtBOiAmcXVvdDtJIGFtIGNvbmZpZ3VyZWQgZm9yIG1v ZGUgMDAwMDAmcXVvdDs8YnI+DQo8YnI+DQpUaGlzIHJlc3VsdHMgaW4gUFNDIGNvbWluZyB1cCBp biBJRVRGIG1vZGUuPGJyPg0KPGJyPg0KQS5tb2RlID0gWi5tb2RlID0gMTExMTE8YnI+DQpBLSZn dDtaOiAmcXVvdDtJIGFtIGNvbmZpZ3VyZWQgZm9yIG1vZGUgMTExMTEmcXVvdDs8YnI+DQpaLSZn dDtBOiAmcXVvdDtJIGFtIGNvbmZpZ3VyZWQgZm9yIG1vZGUgMTExMTEmcXVvdDs8YnI+DQo8YnI+ DQpUaGlzIHJlc3VsdHMgaW4gUFNDIGNvbWluZyB1cCBpbiBJVFUgbW9kZS48YnI+DQo8YnI+DQpB Lm1vZGUgIT0gWi5tb2RlIChzYXksIDAwMDAxIGFuZCAwMDAxMCk8YnI+DQpBLSZndDtaOiAmcXVv dDtJIGFtIGNvbmZpZ3VyZWQgZm9yIG1vZGUgMDAwMDEmcXVvdDs8YnI+DQpaLSZndDtBOiAmcXVv dDtJIGFtIGNvbmZpZ3VyZWQgZm9yIG1vZGUgMDAwMTAmcXVvdDs8YnI+DQo8YnI+DQpQU0MgZG9l cyBub3QgY29tZSB1cC48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpFeGFtcGxlIG9mIG1ldGhvZCAy PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCkJvdGggTm9kZSBBIGFuZCBOb2RlIFogYW5u b3VuY2UgdHdvIHRoaW5ncyAtIENhcGFiaWxpdGllcyBhbmQgTWFzay48YnI+DQpDYXBhYmlsaXRp ZXMgaXMgYSBiaXRtYXAgb2YgdGhlIGNhcGFiaWxpdGllcyB0aGF0IGFyZSBzdXBwb3J0ZWQuPGJy Pg0KTWFzayBpcyBhIG1hc2sgb2YgZG9uJ3QtY2FyZSBiaXRzIGFnYWluc3QgdGhlIENhcGFiaWxp dGllcyBzdHJpbmcuIEEgMCBpbiBNYXNrIG1lYW5zICZxdW90O0kgZG9uJ3QgY2FyZSBpZiB3ZSBk byB0aGlzIGNhcGFiaWxpdHkgb3Igbm90JnF1b3Q7LCBhbmQgYSAxIG1lYW5zICZxdW90O3dlIG11 c3QgKG9yIG11c3Qgbm90KSBhZ3JlZSBvbiB0aGlzIGNhcGFiaWxpdHkgaW4gb3JkZXIgdG8gY29t ZSB1cCZxdW90Oy48YnI+DQo8YnI+DQpBLmNhcGFiaWxpdGllcyA9IDAwMDAwPGJyPg0KQS5tYXNr ID0gMDAwMDA8YnI+DQo8YnI+DQpUaGlzIHNheXMgJnF1b3Q7SSBhbSBjYXBhYmxlIG9mIHN1cHBv cnRpbmcgYWxsIGNhcGFiaWxpdGllcyBhbmQgSSBkb24ndCBjYXJlIGlmIHdlIGRvIGFueSBvZiB0 aGVtIG9yIG5vdCZxdW90Ozxicj4NCjxicj4NCkEuY2FwYWJpbGl0aWVzID0gMDAwMDA8YnI+DQpB Lm1hc2sgPSAxMTExMTxicj4NCjxicj4NClRoaXMgc2F5cyAmcXVvdDtXZSBtdXN0IG5vdCB1c2Ug YW55IG9mIHRoZSBvcHRpb25hbCBjYXBhYmlsaXRpZXMmcXVvdDsgLSBDYXBhYmlsaXRpZXMgYml0 cyBhcmUgYWxsIHplcm8sIGFuZCBNYXNrIGJpdHMgc2F5ICZxdW90O3dlIG11c3QgYWdyZWUgdGhh dCB0aGUgY29ycmVzcG9uZGluZyBjYXBhYmlsaXR5IGlzIHplcm8mcXVvdDsuIFRoaXMgaXMgJ0lF VEYgbW9kZScuPGJyPg0KPGJyPg0KQS5jYXBhYmlsaXRpZXMgPSAxMTExMTxicj4NCkEubWFzayA9 IDExMTExPGJyPg0KPGJyPg0KVGhpcyBpcyAnSVRVIE1vZGUnPGJyPg0KPGJyPg0KV2hlcmUgaXQg Z2V0cyBjb21wbGljYXRlZCAob3IgYXdlc29tZSwgZGVwZW5kaW5nIG9uIHlvdXIgcGVyc3BlY3Rp dmUpIGlzIHdoZW4geW91IGhhdmUgdmFyaW91cyBzdWJzZXRzLiBDb25zaWRlcjo8YnI+DQo8YnI+ DQpBLkNhcGFiaWxpdGllcyA9PSAwMTEwMDxicj4NCkEuTWFzayA9PSAwMTEwMDxicj4NCjxicj4N ClouQ2FwYWJpbGl0aWVzID09IDAxMTEwPGJyPg0KWi5NYXNrID09IDAxMTEwPGJyPg0KPGJyPg0K PGJyPg0KTmVnb3RpYXRpb24gcHJvY2VkdXJlcy48YnI+DQpFYWNoIHNpZGUgZG9lczo8YnI+DQo8 YnI+DQo8YnI+DQpyZXMgPSAoQS5DYXBhYmlsaXRlcyAmYW1wOyBaLk1hc2spIF4gKFouQ2FwYWJp bGl0aWVzICZhbXA7IEEuTWFzayk8YnI+DQpyZXMgPSAoMDExMDAgJmFtcDsgMDExMTApIF4gKDAx MTEwICZhbXA7IDAxMTAwKTxicj4NCnJlcyA9ICgwMTEwMCkgXiAoMDExMDApPGJyPg0KcmVzID0g MDAwMDA8YnI+DQo8YnI+DQppZiByZXMgPT0gMCB0aGVuIGl0IGlzIHBvc3NpYmxlIGZvciBib3Ro IHNpZGVzIHRvIGZpbmQgYSBjb21tb24gc3Vic2V0IHRoYXQgdGhleSBzdXBwb3J0Ljxicj4NClRo aXMgY29tbW9uIHN1YnNldCBpcyBjYWxsZWQgdGhlICduZWdvdGlhdGVkIHNldCcsIGFuZCBpcyBk ZXRlcm1pbmVkIGJ5Ojxicj4NCjxicj4NCm5lZ290aWF0ZWRfc2V0ID0gQS5DYXBhYmlsaXRpZXMg fCBCLkNhcGFiaWxpdGllczxicj4NCm5lZ290aWF0ZWRfc2V0ID0gMDExMDAgfCAwMTExMCA8YnI+ DQpuZWdvdGlhdGVkX3NldCA9IDAxMTAwPGJyPg0KPGJyPg0KaWYgcmVzICE9IDAgdGhlbiBpdCBp cyBpbXBvc3NpYmxlIHRvIGZpbmQgYSBzdWJzZXQgdGhhdCB0aGUgdHdvIGVuZHMgY2FuIGFncmVl IG9uLCBhbmQgUFNDIHdpbGwgbmV2ZXIgY29tZSB1cC48YnI+DQo8YnI+DQpPbmNlIGVhY2ggc2lk ZSBjb21wdXRlcyB0aGUgbmVnb3RpYXRlZCBzZXQsIHRoZXkgc2lnbmFsIGl0IGFuZCBQU0Mgc3Rh cnRzIHRvIHdvcmsuPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQptcGxzIG1haWxpbmcgbGlzdDxicj4NCm1wbHNAaWV0Zi5vcmc8YnI+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8YnI+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28663D9DSMTP2etriinfo_-- From iesg-secretary@ietf.org Mon Aug 19 09:28:53 2013 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 71D7811E82A6; Mon, 19 Aug 2013 09:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.135, 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 nwlZvyzZC6qM; Mon, 19 Aug 2013 09:28:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6A411E82BA; Mon, 19 Aug 2013 09:28:39 -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: 4.70.p1 Message-ID: <20130819162839.16431.61790.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2013 09:28:39 -0700 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel' to Proposed Standard (draft-ietf-mpls-retire-ach-tlv-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, 19 Aug 2013 16:28:53 -0000 The IESG has approved the following document: - 'Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel' (draft-ietf-mpls-retire-ach-tlv-03.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact person is Spencer Dawkins. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-retire-ach-tlv/ Technical Summary The MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the Pseudowire (PW) Associated Channel Header (ACH). RFC 5586 defines the concept of TLV constructs that can be carried in messages on the G-ACh by placing them in the Associated Channel Header (ACH) between the fixed header fields and the G-ACh message. These TLVs are called ACH TLVs No Associated Channel Type yet defined uses an ACH TLV. Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast-path, and since G-ACh messages are intended to be processed substantially in hardware, the use of ACH TLVs is undesirable. This document updates RFC 5586 by retiring ACH TLVs and removing the associated IANA registry. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There is a strong support for this document in the working group and it has been has been well reviewed. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? Since this is removing an unused "feature" from RFC 5586 the responsible AD believes that the *absence* of implementations is required for approval of the draft - if there were implementations, we shouldn't approve the draft. The responsible AD believes (without practicing unlicensed law) that it's not possible to have IPR on not implementing part of an approved standards-track specification (and if IPR was claimed on not implementing parts of a standards-track specification, the prior art would be overwhelming). Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' Loa Andersson is the document shepherd. Spencer Dawkins is the responsible AD, since both Routing ADs are co-authors on this document. From rcallon@juniper.net Mon Aug 19 11:47:31 2013 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 BD78E11E82B8 for ; Mon, 19 Aug 2013 11:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.769 X-Spam-Level: X-Spam-Status: No, score=-101.769 tagged_above=-999 required=5 tests=[AWL=0.829, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PARbGOdShhN for ; Mon, 19 Aug 2013 11:47:25 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0253.outbound.messaging.microsoft.com [213.199.154.253]) by ietfa.amsl.com (Postfix) with ESMTP id E3BD911E82C2 for ; Mon, 19 Aug 2013 11:47:21 -0700 (PDT) Received: from mail149-db9-R.bigfish.com (10.174.16.251) by DB9EHSOBE012.bigfish.com (10.174.14.75) with Microsoft SMTP Server id 14.1.225.22; Mon, 19 Aug 2013 18:47:20 +0000 Received: from mail149-db9 (localhost [127.0.0.1]) by mail149-db9-R.bigfish.com (Postfix) with ESMTP id 08406220251; Mon, 19 Aug 2013 18:47:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zz9371Ic85fh4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h1c8fb4h1de096h8275bh8275dh1de097hz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail149-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(377454003)(164054003)(51856001)(18717965001)(74366001)(19300405004)(65816001)(80022001)(59766001)(77982001)(19580405001)(19580385001)(19580395003)(76796001)(76576001)(83072001)(33646001)(16236675002)(81686001)(81816001)(83322001)(76786001)(46102001)(63696002)(47976001)(50986001)(49866001)(47736001)(79102001)(15202345003)(4396001)(81542001)(74316001)(74876001)(69226001)(53806001)(54316002)(56776001)(54356001)(66066001)(74706001)(56816003)(77096001)(80976001)(47446002)(76482001)(74662001)(74502001)(81342001)(31966008)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB118; H:BLUPR05MB070.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail149-db9 (localhost.localdomain [127.0.0.1]) by mail149-db9 (MessageSwitch) id 1376938038401654_29520; Mon, 19 Aug 2013 18:47:18 +0000 (UTC) Received: from DB9EHSMHS014.bigfish.com (unknown [10.174.16.244]) by mail149-db9.bigfish.com (Postfix) with ESMTP id 54CA416007B; Mon, 19 Aug 2013 18:47:18 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS014.bigfish.com (10.174.14.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 19 Aug 2013 18:47:16 +0000 Received: from BLUPR05MB118.namprd05.prod.outlook.com (10.255.214.16) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.347.3; Mon, 19 Aug 2013 18:47:15 +0000 Received: from BLUPR05MB070.namprd05.prod.outlook.com (10.255.214.15) by BLUPR05MB118.namprd05.prod.outlook.com (10.255.214.16) with Microsoft SMTP Server (TLS) id 15.0.745.25; Mon, 19 Aug 2013 18:47:14 +0000 Received: from BLUPR05MB070.namprd05.prod.outlook.com ([169.254.15.212]) by BLUPR05MB070.namprd05.prod.outlook.com ([169.254.15.212]) with mapi id 15.00.0745.000; Mon, 19 Aug 2013 18:47:14 +0000 From: Ross Callon To: "mpls@ietf.org" , Kireeti Kompella , Loa Andersson , Adrian Farrel Thread-Topic: Closed, MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 Thread-Index: AQHOgkXk/5e12m2TNkeFcdzsBEiRqZmdFH1Q Date: Mon, 19 Aug 2013 18:47:13 +0000 Message-ID: References: <62CCD4C52ACDAD4481149BD5D8A72FD316C76D83@CH1PRD0510MB355.namprd05.prod.outlook.com> <62CCD4C52ACDAD4481149BD5D8A72FD316D6D7D6@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316D6D7D6@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 09435FCA72 Content-Type: multipart/alternative; boundary="_000_bfc50cde2d9a49738177add2dd3cc843BLUPR05MB070namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Kireeti Kompella , "mpls-chairs@tools.ietf.org" Subject: [mpls] Closed, MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 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, 19 Aug 2013 18:47:31 -0000 --_000_bfc50cde2d9a49738177add2dd3cc843BLUPR05MB070namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This last call has now ended with solid support. There have been comments r= egarding updates that should be made to the document before we request publ= ication. Authors, please update the document according to comments receive= d. After the document is updated I will submit it to our AD for publication= . Thanks, Ross From: Ross Callon [mailto:rcallon@juniper.net] Sent: Tuesday, July 16, 2013 1:00 PM To: mpls@ietf.org; draft-ietf-mpls-special-purpose-labels@tools.ietf.org Cc: mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) Subject: MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 Working Group, This is to start Working Group last call on draft-ietf-mpls-special-purpos= e-labels-03 Please send your comments to the mpls working group mailing list (mpls@ietf= .org). Please send both technical comments, and (if you are happy with the documen= t as is) also send indications of support. There are no IPR claims against this draft. The co-authors have earlier sta= ted that they are not aware of any IPR applicable to this draft. If anyone else in the working group is aware of IPRs claims against this draft, the time to disclose that is now. Due to the upcoming IETF meeting in Berlin, this last call will be extended= by an extra week (which implies that the last call will be ongoing during the IETF meeting).= This working group last call will end on August 6, 2013. Ross for the wg co-chairs --_000_bfc50cde2d9a49738177add2dd3cc843BLUPR05MB070namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This last call has now en= ded with solid support. There have been comments regarding updates that sho= uld be made to the document before we request publication.  Authors, please update the document according to comments received. After = the document is updated I will submit it to our AD for publication.

 <= /p>

Thanks, Ross

 <= /p>

From: Ross Cal= lon [mailto:rcallon@juniper.net]
Sent: Tuesday, July 16, 2013 1:00 PM
To: mpls@ietf.org; draft-ietf-mpls-special-purpose-labels@tools.ietf= .org
Cc: mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN)
Subject: MPLS WG last call on draft-ietf-mpls-special-purpose-labels= -03

 

Working Group,

 

This = is to start Working Group last call on  draft-ietf-mpls-special-purpose-labels-03

 

Please send your comments to the mpls w= orking group mailing list (mpls@ietf.org).

 

Please send both technical comments, an= d (if you are happy with the document as is)

also send indications of support.

 

There are no IPR claims against this dr= aft. The co-authors have earlier stated that they

are not aware of any IPR applicable to this draft.

 

If anyone else in the working group is aware of IPRs claims against

this draft, the time to disclose that i= s now.

 

Due to the upcoming IETF meeting in Ber= lin, this last call will be extended by an extra week

(which implies that the last call will = be ongoing during the IETF meeting). This working group

last call will end on August 6, 2013.

 

Ross

for the wg co-chairs<= /p>

 <= /p>

--_000_bfc50cde2d9a49738177add2dd3cc843BLUPR05MB070namprd05pro_-- From adrian@olddog.co.uk Mon Aug 19 11:58:35 2013 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 AE73011E82BA for ; Mon, 19 Aug 2013 11:58:34 -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.001, 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 Xqut+0rTo8Ew for ; Mon, 19 Aug 2013 11:58:28 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id D7B7111E8185 for ; Mon, 19 Aug 2013 11:58:27 -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 r7JIwGRe029504; Mon, 19 Aug 2013 19:58:17 +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 r7JIwDuM029466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Aug 2013 19:58:13 +0100 From: "Adrian Farrel" To: "'Ross Callon'" , , "'Kireeti Kompella'" , "'Loa Andersson'" References: <62CCD4C52ACDAD4481149BD5D8A72FD316C76D83@CH1PRD0510MB355.namprd05.prod.outlook.com> <62CCD4C52ACDAD4481149BD5D8A72FD316D6D7D6@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: Date: Mon, 19 Aug 2013 19:58:12 +0100 Message-ID: <061401ce9d0e$0ea747f0$2bf5d7d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0615_01CE9D16.706E20F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHMDKeoFfRAZVE2wLG+gCviT5U7EwL2HCO4AU4hDD+Zf+A3IA== Content-Language: en-gb Cc: 'Kireeti Kompella' , mpls-chairs@tools.ietf.org Subject: Re: [mpls] Closed, MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 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, 19 Aug 2013 18:58:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0615_01CE9D16.706E20F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Feel free to submit the publication request to me, but I will pass it straight over the wall to Stewart (without even reading it :-) because I have to recuse as co-author. A From: Ross Callon [mailto:rcallon@juniper.net] Sent: 19 August 2013 19:47 To: mpls@ietf.org; Kireeti Kompella; Loa Andersson; Adrian Farrel Cc: mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); Kireeti Kompella Subject: Closed, MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 This last call has now ended with solid support. There have been comments regarding updates that should be made to the document before we request publication. Authors, please update the document according to comments received. After the document is updated I will submit it to our AD for publication. Thanks, Ross From: Ross Callon [mailto:rcallon@juniper.net] Sent: Tuesday, July 16, 2013 1:00 PM To: mpls@ietf.org; draft-ietf-mpls-special-purpose-labels@tools.ietf.org Cc: mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN) Subject: MPLS WG last call on draft-ietf-mpls-special-purpose-labels-03 Working Group, This is to start Working Group last call on draft-ietf-mpls-special-purpose-labels-03 Please send your comments to the mpls working group mailing list ( mpls@ietf.org). Please send both technical comments, and (if you are happy with the document as is) also send indications of support. There are no IPR claims against this draft. The co-authors have earlier stated that they are not aware of any IPR applicable to this draft. If anyone else in the working group is aware of IPRs claims against this draft, the time to disclose that is now. Due to the upcoming IETF meeting in Berlin, this last call will be extended by an extra week (which implies that the last call will be ongoing during the IETF meeting). This working group last call will end on August 6, 2013. Ross for the wg co-chairs ------=_NextPart_000_0615_01CE9D16.706E20F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Feel free to submit the = publication request to me, but I will pass it straight over the wall to = Stewart (without even reading it :-) because I have to recuse as = co-author.

 

A

 

From: Ross Callon = [mailto:rcallon@juniper.net]
Sent: 19 August 2013 = 19:47
To: mpls@ietf.org; Kireeti Kompella; Loa Andersson; = Adrian Farrel
Cc: mpls-chairs@tools.ietf.org; VIGOUREUX, = MARTIN (MARTIN); Kireeti Kompella
Subject: Closed, MPLS WG = last call on = draft-ietf-mpls-special-purpose-labels-03

 

This last call has now ended with solid = support. There have been comments regarding updates that should be made = to the document before we request publication.  Authors, please = update the document according to comments received. After the document = is updated I will submit it to our AD for publication. =

 

Thanks, Ross

 

From: Ross Callon [mailto:rcallon@juniper.net]
Sent: = Tuesday, July 16, 2013 1:00 PM
To: mpls@ietf.org; = draft-ietf-mpls-special-purpose-labels@tools.ietf.org
Cc: = mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN = (MARTIN)
Subject: MPLS WG last call on = draft-ietf-mpls-special-purpose-labels-03

 

Working Group,

 

This is to start Working Group last call on  = draft-ietf-mpls-special-purpose-labels-03

 

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

 

Please send both technical comments, and (if you are = happy with the document as is) =

also send indications of support.

 

There are no IPR claims against this draft. The co-authors have earlier stated that = they

are not aware of any = IPR applicable to this draft.

 

If anyone else in the working group is aware of IPRs claims = against

this draft, the time to disclose that is = now.

 

Due to the upcoming IETF meeting in Berlin, this last call = will be extended by an extra week

(which implies that the last call will be ongoing during = the IETF meeting). This working group

last call will end on August 6, = 2013.

 

Ross

for the wg co-chairs

 

= ------=_NextPart_000_0615_01CE9D16.706E20F0-- From loa@pi.nu Tue Aug 20 02:58:27 2013 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 63E5011E8128 for ; Tue, 20 Aug 2013 02:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33kX+ZmIhDgy for ; Tue, 20 Aug 2013 02:58:21 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 740B211E81F4 for ; Tue, 20 Aug 2013 02:58:21 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 824B718000AA; Tue, 20 Aug 2013 11:58:20 +0200 (CEST) Message-ID: <52133DBE.8000301@pi.nu> Date: Tue, 20 Aug 2013 11:58:22 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ross Callon References: <5efa5403aab843bdbcc382a8143640ee@BLUPR05MB070.namprd05.prod.outlook.com> In-Reply-To: <5efa5403aab843bdbcc382a8143640ee@BLUPR05MB070.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "loa@mail01.huawei.com" Subject: Re: [mpls] Poll for Adoption draft-andersson-mpls-moving-iana-registries-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, 20 Aug 2013 09:58:27 -0000 Ross, (my chair hat off) I've discussed the proposal from from Carlos, basically do a wider clean up on the G-ACh registries, and not limit this to tidying up the LSP Ping registry. We have therefore published a new draft: draft-lcap-mpls-moving-iana-registries Could you therefore close the poll on draft-andersson-mpls-moving- iana-registries without any further actions. Start the process on making draft-lcap-mpls-moving-iana-registries an MPLS working group document. Since the new draft are proposing changes to "PWE3 registries" the PWE3 should be notified as this process is started. /Loa On 2013-08-13 20:23, Ross Callon wrote: > This is to start a "two week" poll on adopting > draft-andersson-mpls-moving-iana-registries-00 > as an MPLS working group document. > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). > This poll will end August 28, 2013. > Thanks, Ross -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From rcallon@juniper.net Tue Aug 20 06:59:28 2013 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 501E911E80E4 for ; Tue, 20 Aug 2013 06:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=1.018, 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 Fq+90Cyf3UIl for ; Tue, 20 Aug 2013 06:59:22 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id C6C3021F9BB4 for ; Tue, 20 Aug 2013 06:59:21 -0700 (PDT) Received: from mail217-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Tue, 20 Aug 2013 13:59:21 +0000 Received: from mail217-va3 (localhost [127.0.0.1]) by mail217-va3-R.bigfish.com (Postfix) with ESMTP id 10D581800D9; Tue, 20 Aug 2013 13:59:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz62a3I98dI9371I936eI542I4015Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh1de097hz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail217-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(199002)(189002)(252514010)(24454002)(377424004)(377454003)(164054003)(51856001)(74366001)(65816001)(77982001)(59766001)(19580395003)(76796001)(19580405001)(81686001)(76786001)(83322001)(83072001)(81816001)(33646001)(76576001)(46102001)(50986001)(63696002)(47976001)(49866001)(80022001)(561944002)(47736001)(79102001)(4396001)(81542001)(74316001)(74876001)(69226001)(53806001)(76482001)(54316002)(56776001)(80976001)(77096001)(54356001)(74706001)(56816003)(66066001)(74662001)(47446002)(31966008)(81342001)(74502001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB072; H:BLUPR05MB070.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail217-va3 (localhost.localdomain [127.0.0.1]) by mail217-va3 (MessageSwitch) id 1377007159460421_7342; Tue, 20 Aug 2013 13:59:19 +0000 (UTC) Received: from VA3EHSMHS008.bigfish.com (unknown [10.7.14.248]) by mail217-va3.bigfish.com (Postfix) with ESMTP id 62E1D78003F; Tue, 20 Aug 2013 13:59:19 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS008.bigfish.com (10.7.99.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 20 Aug 2013 13:59:19 +0000 Received: from BLUPR05MB072.namprd05.prod.outlook.com (10.255.214.27) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.347.3; Tue, 20 Aug 2013 13:59:17 +0000 Received: from BLUPR05MB070.namprd05.prod.outlook.com (10.255.214.15) by BLUPR05MB072.namprd05.prod.outlook.com (10.255.214.27) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 20 Aug 2013 13:59:16 +0000 Received: from BLUPR05MB070.namprd05.prod.outlook.com ([169.254.15.212]) by BLUPR05MB070.namprd05.prod.outlook.com ([169.254.15.212]) with mapi id 15.00.0745.000; Tue, 20 Aug 2013 13:59:16 +0000 From: Ross Callon To: Loa Andersson , "mpls@ietf.org" Thread-Topic: Poll for Adoption draft-andersson-mpls-moving-iana-registries-00 Thread-Index: Ac6YUkBh7zV9g+sGRCSLJd3RtsoDnwFOY14AAAg+qRA= Date: Tue, 20 Aug 2013 13:59:16 +0000 Message-ID: <34a23f8947e644ae8a89878cfe62ce41@BLUPR05MB070.namprd05.prod.outlook.com> References: <5efa5403aab843bdbcc382a8143640ee@BLUPR05MB070.namprd05.prod.outlook.com> <52133DBE.8000301@pi.nu> In-Reply-To: <52133DBE.8000301@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 09443CAA7E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls-chairs@tools.ietf.org" , "loa@mail01.huawei.com" Subject: Re: [mpls] Poll for Adoption draft-andersson-mpls-moving-iana-registries-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, 20 Aug 2013 13:59:28 -0000 Okay. The poll for adoption of draft-andersson-mpls-moving-iana-registries-= 00 is closed, and the document is withdrawn from consideration as a WG docu= ment.=20 I will take a look at the new document.=20 Thanks, Ross -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Tuesday, August 20, 2013 5:58 AM To: Ross Callon Cc: mpls@ietf.org; loa@mail01.huawei.com; mpls-chairs@tools.ietf.org; Carlo= s Pignataro (cpignata) Subject: Re: Poll for Adoption draft-andersson-mpls-moving-iana-registries-= 00 Ross, (my chair hat off) I've discussed the proposal from from Carlos, basically do a wider clean up on the G-ACh registries, and not limit this to tidying up the LSP Ping registry. We have therefore published a new draft: draft-lcap-mpls-moving-iana-registries Could you therefore close the poll on draft-andersson-mpls-moving- iana-registries without any further actions. Start the process on making draft-lcap-mpls-moving-iana-registries an MPLS working group document. Since the new draft are proposing changes to "PWE3 registries" the PWE3 should be notified as this process is started. /Loa On 2013-08-13 20:23, Ross Callon wrote: > This is to start a "two week" poll on adopting > draft-andersson-mpls-moving-iana-registries-00 > as an MPLS working group document. > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). > This poll will end August 28, 2013. > Thanks, Ross --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From yakov@juniper.net Tue Aug 20 09:08:20 2013 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 A8B5D11E80E1 for ; Tue, 20 Aug 2013 09:08:20 -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 0TX+F6G0TzHF for ; Tue, 20 Aug 2013 09:08:15 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id C472911E8123 for ; Tue, 20 Aug 2013 09:08:15 -0700 (PDT) Received: from mail9-co9-R.bigfish.com (10.236.132.242) by CO9EHSOBE016.bigfish.com (10.236.130.79) with Microsoft SMTP Server id 14.1.225.22; Tue, 20 Aug 2013 16:07:32 +0000 Received: from mail9-co9 (localhost [127.0.0.1]) by mail9-co9-R.bigfish.com (Postfix) with ESMTP id 298DE7400B5; Tue, 20 Aug 2013 16:07:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz936eIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz1de098h1033IL17326ah1de096h8275dh1de097hz2fh2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h1155h) Received-SPF: pass (mail9-co9: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=yakov@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail9-co9 (localhost.localdomain [127.0.0.1]) by mail9-co9 (MessageSwitch) id 1377014796489845_26176; Tue, 20 Aug 2013 16:06:36 +0000 (UTC) Received: from CO9EHSMHS029.bigfish.com (unknown [10.236.132.237]) by mail9-co9.bigfish.com (Postfix) with ESMTP id 61F798C005D; Tue, 20 Aug 2013 16:06:17 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.51) by CO9EHSMHS029.bigfish.com (10.236.130.39) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 20 Aug 2013 16:06:16 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 20 Aug 2013 09:06:15 -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 r7KG6CL65192; Tue, 20 Aug 2013 09:06:12 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201308201606.r7KG6CL65192@magenta.juniper.net> To: , , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25295.1377014772.1@juniper.net> Date: Tue, 20 Aug 2013 09:06:12 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: mpls@ietf.org Subject: [mpls] draft-rekhter-mpls-pim-sm-over-mldp-05.txt as 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: Tue, 20 Aug 2013 16:08:20 -0000 Dear chairs of MPLS WG, The authors of draft-rekhter-mpls-pim-sm-over-mldp-05.txt would like to ask MPLS WG to accept draft-rekhter-mpls-pim-sm-over-mldp-05.txt as an MPLS WG document. On behalf of all the authors, Yakov. ------- Forwarded Message Date: Tue, 20 Aug 2013 07:29:58 -0700 From: To: Subject: I-D Action: draft-rekhter-mpls-pim-sm-over-mldp-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs Author(s) : Yakov Rekhter Rahul Aggarwal Wim Henderickx Quintin Zhao Richard Li Filename : draft-rekhter-mpls-pim-sm-over-mldp-05.txt Pages : 9 Date : 2013-08-20 Abstract: When IP multicast trees created by PIM-SM in ASM mode need to pass through an MPLS domain, it may be desirable to map such trees to Point-to-Multipoint Label Switched Paths. This document describes how to accomplish this in the case where such Point-to-Multipoint Label Switches Paths are established using mLDP. Specification of Requirements The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-rekhter-mpls-pim-sm-over-mldp There's also a htmlized version available at: http://tools.ietf.org/html/draft-rekhter-mpls-pim-sm-over-mldp-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-rekhter-mpls-pim-sm-over-mldp-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 ------- End of Forwarded Message From stbryant@cisco.com Tue Aug 20 09:28:05 2013 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 514F511E812C; Tue, 20 Aug 2013 09:28:05 -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 27c4TH9UkWxI; Tue, 20 Aug 2013 09:28:00 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id B487B11E80E4; Tue, 20 Aug 2013 09:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=79744; q=dns/txt; s=iport; t=1377016079; x=1378225679; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pBPUw7dQhvNfFR+bza+wfJUV3NQHWdfTkqAGRvyFqpw=; b=hiH+IIeFUN27rrKLhJ7MueYijEXZ9rS0dIBzcvls1yKo5AzdvmlcWEcw tmO8/b08jELPJfGCz9Xe/oxtA4iGoZBzSurF/sgc/hH9hxLjiHsMbn4bI d314wy20J3igH8yA/NadEWHLD4e2kZIZLkFJ0gMaw/j4vC6uzxUdjNcPf A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFADOYE1KQ/khM/2dsb2JhbABQCoMFNcAqgSQWdIIkAQEBAwEBAQEXAR0uAQcKAQwECxEBAwEBAQkMCggHCQMCAQIBFR8DBggGCgMBBQIBAReHbwYMrS6PAQIJBgUFgRciBwYEhAoDjESHCEGDWIEthXGKOIMdgWgIFw X-IronPort-AV: E=Sophos;i="4.89,921,1367971200"; d="scan'208";a="16852392" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 20 Aug 2013 16:27:54 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7KGRqbB016277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Aug 2013 16:27:52 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r7KGRlAL026894; Tue, 20 Aug 2013 17:27:47 +0100 (BST) Message-ID: <52139903.8040801@cisco.com> Date: Tue, 20 Aug 2013 17:27:47 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "S. Davari" References: <51FB7543.801@cisco.com> <51FF7068.9080600@cisco.com> <4A6CE49E6084B141B15C0713B8993F281BEC731A@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] Comments on draft-ietf-tictoc-1588overmpls 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, 20 Aug 2013 16:28:05 -0000 On 06/08/2013 14:35, S. Davari wrote: > Sasha, > > If a router is not 1588 aware we want it to switch the packet with minimum jitter and delay via high priority queue. Yes, but you can explicitly tunnel across such island of incompatibility Stewart > > > Sending it to CPU creates large jitter and delay since the CPUs are generally busy doing other things. Time stamping or updating CF in the CPU won't help since it does not cover the variable delay that is incurred from the time the packet enters the router to the time the packet gets processed by CPU. > > I wish it was that easy! > > Regards, > Shahram > > > On Aug 6, 2013, at 12:38 AM, Alexander Vainshtein wrote: > >> Shahram, >> I agree with you that the routers that do not recognize a Timing Alert label would send the packet to the CPU. (This would be easy to arrange since we are speaking about a reserved label.) >> >> I do not, however, see this as a serious issue, because the SW running on this CPU would (hopefully) be upgradable to handle the packet correctly i.e., to forward it to where it should be forwarded and, if it is forwarded as a labeled packet, to prepend the Timing Alert Label on top of its label stack. It could even record the residence time (as observed by the CPU in the proper place in the packet. This would mean that introducing additional error to whatever timing information is associated with this packet - but this is what you should anyway expect if there are non-compliant routers on your path, right? >> >> Regards, >> Sasha >> >>> -----Original Message----- >>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of >>> Shahram Davari >>> Sent: Monday, August 05, 2013 11:29 PM >>> To: stbryant@cisco.com; S. Davari >>> Cc: mpls@ietf.org; tictoc@ietf.org >>> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls >>> >>> Hi Stewart, >>> >>> Your suggestion of " I suggested an LSP type that has the properties "timestamp >>> and pass to application", is a subset of the existing draft and should work. It >>> basically limits the time stamping and correction field update to LERs (while the >>> draft supports time stamping at LER and LSR). >>> >>> However Sasha's suggestion of using a reserved label (RAL, GAL or any other >>> reserved label) does not satisfy one of the major requirements, which is >>> backward compatibility. Routers that don't understand this reserved label will >>> drop or copy to CPU such packets. >>> >>> Regards, >>> Shahram >>> >>> -----Original Message----- >>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of >>> Stewart Bryant >>> Sent: Monday, August 05, 2013 2:29 AM >>> To: S. Davari >>> Cc: mpls@ietf.org; tictoc@ietf.org >>> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls >>> >>> My concern is that we are creating a new LSP type in MPLS >>> (which is a architectural change and thus needs to be very carefully >>> considered) without asking the question "how can I do this >>> in the most general way, to maximize flexibility/reuse" >>> >>> I suggested an LSP type that has the properties "timestamp >>> and pass to application", but I think that Sasha raises a good >>> point about using router alert. However RA has no implicit >>> timestamp, so maybe we need a new type of RA that has the >>> properties "timestamp, and pass top application indicated by >>> the next label". That would be quite useful in a number >>> of OAM applications. There is possibly some GAL variant >>> of that design that should also be considered. >>> >>> The application could worry about the path and where it >>> was necessary to skip some hops a hierarchical LSP would >>> accomplish that, with the specific benefit that the application >>> would consciously do this, and may be able to apply some >>> form of compensation within the network. >>> >>> - Stewart >>> >>> On 04/08/2013 10:40, S. Davari wrote: >>>> Hi Sasha >>>> >>>> Perhaps you have not understood the draft well. The main reason that the >>> draft chose to use a dedicated LSP that is signaled via RSVPTE indicating it is a >>> timing LSP is to be backward compatible with non-1588 nodes. Such nodes >>> simply just switch the packet. >>>> Your proposal had been considered and was rejected since it was not >>> backward compatible. Nodes receiving alert label or TTL = 1 send the packet to >>> CPU. You can refer to the meeting notes. >>>> Regards, >>>> Shahram >>>> >>>> >>>> On Aug 4, 2013, at 1:21 AM, Alexander Vainshtein >>> wrote: >>>>> Stewart and all, >>>>> I concur with Stewart's statement that the draft does not define "full >>> interaction with MPLS architecture". >>>>> E.g., one of the objectives of the draft is to provide a technique that would >>> be backward-compatible with old LSRs that cannot provide on-path support for >>> timing distribution, while the other objective is to make every LSR on the path >>> aware that some MPLS packets are carrying timing-related messages and hence >>> require on-path support. >>>>> IMHO and FWIW, the MPLS data plane architecture allows just two methods >>> for making a transit LSR to provide special processing to a labeled packet: >>>>> - It would carry some kind of an "alert label" on top of the label stack and, >>> specifically, on top of any labels used for actual forwarding >>>>> OR, >>>>> - The TTL in the top label stack entry has been set to 1. >>>>> >>>>> >>>>> The draft does not follow any of these approaches. >>>>> >>>>> I must also admit that Section 12 "OAM, Control and Management" of the >>> draft looks somewhat in >>>>> E.g., I could not understand from the text whether BFD, LSP-Ping etc. OAM >>> messages would be subjected to on-path support procedures for timing >>> messages or not. >>>>> My 2c, >>>>> Sasha >>>>> >>>>>> -----Original Message----- >>>>>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf >>> Of >>>>>> Stewart Bryant >>>>>> Sent: Friday, August 02, 2013 12:01 PM >>>>>> To: mpls-chairs@tools.ietf.org; tictoc-chairs@tools.ietf.org; int- >>>>>> ads@tools.ietf.org; rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; >>> draft- >>>>>> ietf-tictoc-1588overmpls@tools.ietf.org >>>>>> Cc: mpls@ietf.org; tictoc@ietf.org >>>>>> Subject: [TICTOC] Comments on draft-ietf-tictoc-1588overmpls >>>>>> >>>>>> SB> This draft does not seem to provide a precise definition >>>>>> SB> the properties of the new LSP type that it wishes to >>>>>> SB> define, in particular it does it define the PHB of those >>>>>> SB> LSPs, nor the full interaction with the MPLS >>>>>> SB> architecture. >>>>>> SB> >>>>>> SB> I have not tracked TICTOC for a while but I thought that >>>>>> SB> the original plan was to define the concept of an offset >>>>>> SB> into a packet to do the correction. >>>>>> SB> >>>>>> SB> It is disappointing that the opportunity was not taken >>>>>> SB> to define a timing shim inside the timing LSP so that >>>>>> SB> a time correction could be added to any packet such that >>>>>> SB> the MPLS system was isolated from the details of the >>>>>> SB> complexity of the particular time transfer type. >>>>>> >>>>>> SB> I think that much more clarify is needed in terms of >>>>>> SB> definition of the new LSP type, since it is unclear >>>>>> SB> from this text how to implement one. >>>>>> SB> >>>>>> SB> There are a lot of other MPLS services such as >>>>>> SB> LSP ping that need to be considered. >>>>>> SB> >>>>>> SB> Please see inline for more comments. However these >>>>>> SB> comments are made in the context of the text as written >>>>>> SB> whilst I have a fundamental concern that this approach >>>>>> SB> lacks an MPLS architectural soundness that need >>>>>> SB> greater thought with significant impact on the >>>>>> SB> draft. >>>>>> >>>>>> - Stewart >>>>>> >>>>>> >>>>>> TICTOC Working Group S. Davari >>>>>> Internet-Draft A. Oren >>>>>> Intended status: Standards Track Broadcom Corp. >>>>>> Expires: December 17, 2013 M. Bhatia >>>>>> P. Roberts >>>>>> Alcatel-Lucent >>>>>> L. Montini >>>>>> L. Martini >>>>>> Cisco Systems >>>>>> June 15, 2013 >>>>>> >>>>>> >>>>>> Transporting Timing messages over MPLS Networks >>>>>> draft-ietf-tictoc-1588overmpls-05 >>>>>> >>>>>> Abstract >>>>>> >>>>>> This document defines the method for transporting Timing messages >>>>>> such as PTP and NTP over an MPLS network. The method allows for the >>>>>> easy identification of these PDUs at the port level to allow for port >>>>>> >>>>>> SB> What is a port >>>>>> >>>>>> level processing of these PDUs in both LERs and LSRs. >>>>>> >>>>>> The basic idea is to transport Timing messages inside dedicated MPLS >>>>>> LSPs. These LSPs only carry Timing messages and possibly Control and >>>>>> Management packets, but they do not carry customer traffic. >>>>>> >>>>>> SB> More specifically they only carry traffic associated with the >>>>>> SB> timing service and its support. >>>>>> SB> The question arose WRT BFD - surely BFD is allowed, BUT surely >>>>>> SB> also it gets carried in a structure that causes it to get >>>>>> SB> timestamped. >>>>>> >>>>>> Two methods for transporting Timing messages over MPLS are defined. >>>>>> >>>>>> SB> Perhaps the right approach is to define the new LSP type and then >>>>>> SB> seperately to define the mapping of the various timing services >>>>>> SB> over that LSP type. >>>>>> >>>>>> The first method is to transport Timing messages directly over the >>>>>> dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for >>>>>> MPLS networks. The second method is to transport Timing messages >>>>>> inside a PW via Ethernet encapsulation. >>>>>> >>>>>> SB> I think that we should note that there are some >>>>>> SB> h/w reasons for this preference. A clean sheet approach >>>>>> SB> would have been to use PTP over MPLS with no intermediate >>>>>> SB> layers. >>>>>> >>>>>> Status of this Memo >>>>>> >>>>>> This Internet-Draft is submitted in full conformance with the >>>>>> provisions of BCP 78 and BCP 79. >>>>>> >>>>>> Internet-Drafts are working documents of the Internet Engineering >>>>>> Task Force (IETF). Note that other groups may also distribute >>>>>> working documents as Internet-Drafts. The list of current Internet- >>>>>> Drafts is at http://datatracker.ietf.org/drafts/current/. >>>>>> >>>>>> Internet-Drafts are draft documents valid for a maximum of six months >>>>>> and may be updated, replaced, or obsoleted by other documents at any >>>>>> time. It is inappropriate to use Internet-Drafts as reference >>>>>> material or to cite them other than as "work in progress." >>>>>> >>>>>> This Internet-Draft will expire on December 17, 2013. >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 1] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> Copyright Notice >>>>>> >>>>>> Copyright (c) 2013 IETF Trust and the persons identified as the >>>>>> document authors. All rights reserved. >>>>>> >>>>>> This document is subject to BCP 78 and the IETF Trust's Legal >>>>>> Provisions Relating to IETF Documents >>>>>> (http://trustee.ietf.org/license-info) in effect on the date of >>>>>> publication of this document. Please review these documents >>>>>> carefully, as they describe your rights and restrictions with respect >>>>>> to this document. Code Components extracted from this document must >>>>>> include Simplified BSD License text as described in Section 4.e of >>>>>> the Trust Legal Provisions and are provided without warranty as >>>>>> described in the Simplified BSD License. >>>>>> >>>>>> >>>>>> Table of Contents >>>>>> >>>>>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 >>>>>> >>>>>> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 >>>>>> >>>>>> 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 >>>>>> >>>>>> 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . 9 >>>>>> >>>>>> 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . . 12 >>>>>> >>>>>> 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . 13 >>>>>> 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . . 13 >>>>>> 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . . 13 >>>>>> 6.3. Other Timing Encapsulation methods . . . . . . . . . . . . 14 >>>>>> >>>>>> 7. Timing message Processing . . . . . . . . . . . . . . . . . . 15 >>>>>> >>>>>> 8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 16 >>>>>> >>>>>> 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 >>>>>> >>>>>> 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 >>>>>> >>>>>> 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 >>>>>> >>>>>> 12. OAM, Control and Management . . . . . . . . . . . . . . . . . 20 >>>>>> >>>>>> 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 21 >>>>>> >>>>>> 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . . 22 >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 2] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 23 >>>>>> 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . . 23 >>>>>> 15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . . 23 >>>>>> 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . . 24 >>>>>> >>>>>> 16. Other considerations . . . . . . . . . . . . . . . . . . . . . 25 >>>>>> >>>>>> 17. Security Considerations . . . . . . . . . . . . . . . . . . . 26 >>>>>> >>>>>> 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 >>>>>> >>>>>> 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 >>>>>> >>>>>> 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 >>>>>> 20.1. Normative References . . . . . . . . . . . . . . . . . . . 29 >>>>>> 20.2. Informative References . . . . . . . . . . . . . . . . . . 29 >>>>>> >>>>>> Appendix 1. Routing extensions for Timing-aware Routers . . . . . 32 >>>>>> >>>>>> Appendix 2. Signaling Extensions for Creating Timing LSPs . . . . 33 >>>>>> >>>>>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 3] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >>> NOT", >>>>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" >>> in >>>>>> this >>>>>> document are to be interpreted as described in RFC2119 [RFC2119]. >>>>>> >>>>>> When used in lower case, these words convey their typical use in >>>>>> common language, and are not to be interpreted as described in >>>>>> RFC2119 [RFC2119]. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 4] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 1. Introduction >>>>>> >>>>>> The objective of Precision Time Protocol (PTP) and Network Timing >>>>>> Protocol (NTP) are to synchronize independent clocks running on >>>>>> separate nodes of a distributed system. >>>>>> >>>>>> [IEEE-1588] defines PTP messages for frequency, phase and time >>>>>> synchronization. The PTP messages include PTP PDUs over UDP/IP >>>>>> (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex F of >>>>>> [IEEE-1588]). >>>>>> >>>>>> SB> Sure BUT it is acknowledged that IEEE is open to the definition >>>>>> SB> of other PTP mappings if they provide better optimisation. >>>>>> >>>>>> This document defines mapping and transport of the PTP >>>>>> messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP >>>>>> defines several clock types: ordinary clocks, boundary clocks, end- >>>>>> to-end transparent clocks, and peer-to-peer transparent clocks. >>>>>> Transparent clocks require intermediate nodes to update correction >>>>>> field inside PTP message that reflects the transit time in the node. >>>>>> >>>>>> [RFC5905] defines NTP messages for clock and time synchronization. >>>>>> The PTP messages (PDUs) are transported over UDP/IP. This document >>>>>> SB> Should that be NTP messages? >>>>>> SB> It needs to be made clear as soon as you introduce NTP that >>>>>> SB> they use different time representations. >>>>>> >>>>>> defines mapping and transport of the NTP messages defined in >>>>>> [RFC5905] over MPLS networks. >>>>>> >>>>>> One key attribute of all of these Timing messages is that the Time >>>>>> stamp processing should occur as close as possible to the actual >>>>>> transmission and reception at the physical port interface. This >>>>>> targets optimal time and/or frequency recovery by avoiding variable >>>>>> delay introduced by queues internal to the clocks. >>>>>> >>>>>> SB> As I recall NTP has no epoch point defined, and I am not sure >>>>>> SB> where that point is in the case of PTP in this mapping >>>>>> SB> Hopefully this will get defined in due course. >>>>>> >>>>>> To facilitate the fast and efficient recognition of Timing messages >>>>>> at the port level when the Timing messages are carried over MPLS >>>>>> LSPs, >>>>>> >>>>>> SB> Over a new LSP type with time optimied characteristics >>>>>> >>>>>> this document defines the specific encapsulations that should >>>>>> be used. >>>>>> SB> Hopefully it will also define the PHP >>>>>> >>>>>> In addition, it can be expected that there will exist LSR/ >>>>>> LERs where only a subset of the physical ports will have the port- >>>>>> based Timing message processing capabilities. >>>>>> SB> Do you need to clarify that this only works at base and not in >>>>>> SB> a label heirarchy. >>>>>> >>>>>> >>>>>> In order to ensure >>>>>> that the LSPs carrying Timing packets always enter and exit ports >>>>>> with this capability, routing extensions are defined to advertise >>>>>> this capability on a port basis and to allow for the establishment of >>>>>> LSPs that only transit such ports. While this path establishment >>>>>> restriction may be applied only at the LER Ingress and/or egress >>>>>> ports, it becomes more important when using transparent clock capable >>>>>> LSRs in the path. >>>>>> SB> I do not understand the implications of the last >>>>>> SB> sentences - starting ", it becomes" >>>>>> >>>>>> >>>>>> Port based Timing message processing involves Timing message >>>>>> recognition. Once the Timing messages are recognized they can be >>>>>> modified based on the reception or transmission Time-stamp. >>>>>> >>>>>> This document provides two methods for transporting Timing messages >>>>>> over MPLS. One is applicable to MPLS environment and the other one >>>>>> is applicable to MPLS/MPLS-TP environment >>>>>> >>>>>> SB> I think the sentence is incomplete. >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 5] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> The solution involves transporting Timing messages over dedicated >>>>>> LSPs called Timing LSPs. These LSPs carry Timing messages and MAY >>>>>> carry Management and control messages, but not data plane client >>>>>> traffic. >>>>>> >>>>>> SB> It is not clear why this restriction applies. >>>>>> >>>>>> Timing LSPs can be established statically or via signaling. >>>>>> SB> s/statically/by provisioning/network management/ >>>>>> >>>>>> Extensions to control plane (OSPF, ISIS, etc.) is required to enable >>>>>> routers to distribute their Timing processing capabilities over MPLS >>>>>> to other routers. However such extensions are outside the scope of >>>>>> this document. >>>>>> >>>>>> When signaling is used to setup the PTP LSP, Extensions to signaling >>>>>> SB> is it a PTP LSP or a Timing LSP? >>>>>> >>>>>> protocols (e.g., RSVP-TE) are required for establishing PTP LSPs. >>>>>> However such extensions are outside the scope of this document. >>>>>> >>>>>> SB> for mpls-tp GMPLS is the signalling protocol >>>>>> >>>>>> While the techniques included herein allow for the establishment of >>>>>> paths optimized to include Time-stamping capable links, the >>>>>> performance of the Slave clocks is outside the scope of this >>>>>> document. >>>>>> >>>>>> At the time of publishing this specification, Transparent Clocking >>>>>> (TC) is only defined for PTP. Therefore at this time any part of >>>>>> this specification that talks about Transparent Clocking applies only >>>>>> to PTP. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 6] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 2. Terminology >>>>>> >>>>>> 1588: The timing and synchronization as defined by IEEE 1588. >>>>>> >>>>>> SB> I think that there is a more formal name for the 1588 group >>>>>> SB> that needs to be used here. >>>>>> SB> Also do we need to talk about 1588-200? as there is >>>>>> SB> an update in progress >>>>>> >>>>>> NTP: The timing and synchronization protocol defined by IETF RFC-1305 >>>>>> and RFC-5905. >>>>>> >>>>>> PTP: The timing and synchronization protocol used by 1588. >>>>>> SB> need the proper name for 1588 >>>>>> >>>>>> Master Clock: The source of 1588 timing to a set of slave clocks. >>>>>> >>>>>> Master Port: A port on a ordinary or boundary clock that is in Master >>>>>> state. This is the source of timing toward slave ports. >>>>>> >>>>>> SB> I am not sure the reader knows what a port is >>>>>> >>>>>> Slave Clock: A receiver of 1588 timing from a master clock. >>>>>> >>>>>> Slave Port: A port on a boundary clock or ordinary clock that is >>>>>> receiving timing from a master clock. >>>>>> >>>>>> Ordinary Clock: A device with a single PTP port. >>>>>> >>>>>> Transparent Clock. A device that measures the time taken for a PTP >>>>>> event message to transit the device and then updates the >>>>>> correctionField of the message with this transit time. >>>>>> >>>>>> Boundary Clock: A device with more than one PTP port. Generally >>>>>> boundary clocks will have one port in slave state to receive timing >>>>>> and then other ports in master state to re-distribute the timing. >>>>>> >>>>>> PTP LSP: An LSP dedicated to carry PTP messages >>>>>> >>>>>> SB> PTP or timing? >>>>>> >>>>>> >>>>>> PTP PW: A PW within a PTP LSP that is dedicated to carry PTP >>>>>> messages. >>>>>> >>>>>> SB> Ah I don't think that PWE3 know what one of these is >>>>>> >>>>>> CW: Pseudowire Control Word >>>>>> >>>>>> LAG: Link Aggregation >>>>>> >>>>>> ECMP: Equal Cost Multipath >>>>>> >>>>>> CF: Correction Field, a field inside certain PTP messages (message >>>>>> type 0-3)that holds the accumulative transit time inside intermediate >>>>>> switches >>>>>> >>>>>> Timing messages: Timing Protocol messages that are exchanged >>> between >>>>>> routers in order to establish a synchronized clock. >>>>>> >>>>>> SB> A number of these definitions look like copies of IEEE1588 >>>>>> SB> definitions. We need to provide references and note the >>>>>> SB> priority of the IEEE base reference. >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 7] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 3. Problem Statement >>>>>> >>>>>> [IEEE-1588] has defined methods for transporting PTP messages over >>>>>> Ethernet and IP networks. [RFC5905] has defined the method of >>>>>> transporting NTP messages over IP networks. There is a need to >>>>>> transport Timing messages over MPLS networks while supporting the >>>>>> Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC) >>>>>> functionality in the LER and LSRs in the MPLS network. >>>>>> >>>>>> There are multiple ways of transporting Timing over MPLS. However, >>>>>> there is a requirement to limit the possible encapsulation options to >>>>>> simplify the Timing message identification and processing required at >>>>>> the port level. >>>>>> >>>>>> When Timing-awareness is needed, Timing messages should not be >>>>>> transported over LSPs or PWs that are carrying customer traffic >>>>>> because LSRs perform Label switching based on the top label in the >>>>>> stack. >>>>>> >>>>>> SB> Have you explained why? >>>>>> >>>>>> To detect Timing messages inside such LSPs require special >>>>>> hardware to do deep packet inspection at line rate. Even if such >>>>>> hardware exists, the payload can't be deterministically identified by >>>>>> LSRs because the payload type is a context of the PW label, and the >>>>>> PW label and its context are only known to the Edge routers (PEs/ >>>>>> LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, CES, >>>>>> etc). Even if one restricts an LSP to only carry Ethernet PWs, the >>>>>> LSRs dont have the knowledge of whether PW Control Word (CW) is >>>>>> present or not and therefore can not deterministically identify the >>>>>> payload. >>>>>> >>>>>> A generic method is defined in this document that does not require >>>>>> deep packet inspection at line rate, and can deterministically >>>>>> identify Timing messages. This method can be used to detect Timing >>>>>> Messages in both one-step and two-step clock implementations of >>>>>> ordinary, boundary and transparent clocks. >>>>>> >>>>>> SB> Needs a ref and I am sure many MPLS specialists will not understand >>>>>> SB> the msg types. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 8] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 4. Timing over MPLS Architecture >>>>>> >>>>>> Timing messages are exchange between Timing ports on ordinary and >>>>>> >>>>>> SB> Have you defined a timing port? >>>>>> >>>>>> boundary clocks. Boundary clocks terminate the Timing messages and >>>>>> act as master for other boundary clocks or for slave clocks. End-to- >>>>>> End Transparent clocks do not terminate the Timing messages but they >>>>>> do modify the contents of the Timing messages as they transit across >>>>>> the transparent clock. >>>>>> >>>>>> Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent Clock >>>>>> >>>>>> (TC) could be implemented in either LERs or LSRs. >>>>>> >>>>>> SB> LER and LSR need to be expanded >>>>>> >>>>>> An example is shown in Figure 1, where the LERs act as Ordinary Clock >>>>>> (OC) and are the initiating/terminating point for Timing messages. >>>>>> The ingress LER encapsulates the Timing messages in Timing LSP and >>>>>> the Egress LER terminates the Timing LSP. The LSRs act as >>>>>> Transparent Clock (TC) and just update the Timing field in the Timing >>>>>> messages. >>>>>> >>>>>> >>>>>> +--------+ +-------+ +-------+ +-------+ +--------+ >>>>>> |Switch, | | | | | | | |Switch, | >>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Router | >>>>>> | | | OC | | TC | | OC | | | >>>>>> +--------+ +-------+ +-------+ +-------+ +--------+ >>>>>> / \ >>>>>> +-------+ / \ +-------+ >>>>>> | LER | / \ | LER | >>>>>> | Master|---/ \---| Slave | >>>>>> | Clock | | Clock | >>>>>> +-------+ +-------+ >>>>>> >>>>>> Figure (1) - Deployment example 1 of timing over MPLS network >>>>>> >>>>>> Another example is shown in Figure2, where LERs terminate the Timing >>>>>> messages received from switch/routers that are outside of the MPLS >>>>>> network acting as OC or BC. In this example LERs regenerate the >>>>>> clock and initiate timing messages encapsulated in Timing LSP toward >>>>>> the MPLS network, while the LSRs act as Transparent Clock (TC) and >>>>>> just update the Timing field in the Timing messages, which are >>>>>> already encapsulated in Timing LSPs. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 9] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> +--------+ +-------+ +-------+ +-------+ +--------+ >>>>>> |Switch, | | | | | | | |Switch, | >>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Router | >>>>>> | OC/BC | | BC | | TC | | BC | | OC/BC | >>>>>> +--------+ +-------+ +-------+ +-------+ +--------+ >>>>>> >>>>>> Figure (2) - Deployment example 2 of timing over MPLS network >>>>>> >>>>>> >>>>>> Another example is shown in Figure 3, where LERs do not terminate the >>>>>> Timing messages received from switch/routers that are outside of the >>>>>> MPLS network acting as OC, TC or BC. The LERs act as TC and update >>>>>> the Timing field in the Timing messages as they transit the LER, >>>>>> while encapsulating them in timing LSP. The LSRs also act as >>>>>> Transparent Clock (TC) and just update the Timing field in the Timing >>>>>> messages which are already encapsulated in Timing LSPs. >>>>>> >>>>>> +--------+ +-------+ +-------+ +-------+ +--------+ >>>>>> |Switch, | | | | | | | |Switch, | >>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Router | >>>>>> |OC/TC/BC| | TC | | TC | | TC | |OC/TC/BC| >>>>>> +--------+ +-------+ +-------+ +-------+ +--------+ >>>>>> >>>>>> Figure (3) - Deployment example 3 of timing over MPLS network >>>>>> >>>>>> Another example is shown in Figure 4, where LERs and LSRs support >>>>>> Boundary Clocks. A single-hop LSP is created between two adjacent >>>>>> LSRs engaged in BC operation. Other methods such as PTP transport >>>>>> over Ethernet MAY be used for transporting timing messages if the >>>>>> link between the two routers is Ethernet. >>>>>> >>>>>> +--------+ +-------+ +-------+ +-------+ +--------+ >>>>>> |Switch, | | | | | | | |Switch, | >>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Router | >>>>>> | OC/BC | | BC | | BC | | BC | | OC/BC | >>>>>> +--------+ +-------+ +-------+ +-------+ +--------+ >>>>>> >>>>>> Figure (4) - Deployment example 3 of timing over MPLS network >>>>>> >>>>>> An MPLS domain MAY serve multiple customers. In these cases the >>> MPLS >>>>>> domain (maintained by a service provider) may provide timing services >>>>>> to multiple customers, each having their own Timing domain. >>>>>> >>>>>> The Timing over MPLS architecture assumes full mesh of Timing LSPs >>>>>> between all LERs supporting this specification. >>>>>> >>>>>> SB> Note sure this is right - the salves surely do not need to >>>>>> SB> exchange timing amongst themselves >>>>>> >>>>>> It supports >>>>>> Point-to- point (VPWS) and Multipoint (VPLS) services. >>>>>> >>>>>> SB> What does that mean? You do not carry user data traffic? >>>>>> SB> Maybe it's the ordering of the statemnets that is causing >>>>>> SB> confusion. >>>>>> >>>>>> This means >>>>>> that a customer may purchase a Point-to-point Timing service between >>>>>> two customer sites or a Multipoint Timing service between more than >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 10] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> two customer sites. >>>>>> >>>>>> The Timing over MPLS architecture supports P2P or P2MP Timing LSPs. >>>>>> This means that the Timing Multicast messages such as PTP Multicast >>>>>> event messages can be transported over P2MP Timing LSP or be >>>>>> replicated and transported over many P2P Timing LSPs. >>>>>> >>>>>> SB> Note we do not yet have a definition of a P2MP mpls-tp LSP >>>>>> SB> nor a P2MP PW, although we are close. >>>>>> >>>>>> Timing messages, that do not require Time stamping or Correction >>>>>> Field update MAY be transported over Timing LSPs to simplify hardware >>>>>> and software. >>>>>> >>>>>> PTP Announce messages that determine the Timing LSP terminating >>> point >>>>>> behavior such as BC/OC/TC SHOULD be transported over the Timing LSP >>>>>> to simplify hardware and software. >>>>>> >>>>>> SB> have you defined and referenced PTP announce msgs? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 11] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 5. Dedicated LSPs for Timing messages >>>>>> >>>>>> Many methods have been considered for identifying the Timing >>> messages >>>>>> when they are encapsulated in MPLS such as using GAL/G-ACH or a new >>>>>> reserved label. These methods were not attractive since they either >>>>>> required deep packet inspection at line rate in the intermediate LSRs >>>>>> or they required use of a scarce new reserved label. Also one of the >>>>>> goals was to reuse existing OAM mechanisms. >>>>>> >>>>>> SB> RLs = SPLs are not so rare now. In any case needs a ref. >>>>>> >>>>>> The method defined in this document can be used by LER and LSRs to >>>>>> identify Timing messages in MPLS tunnels by just looking at the top >>>>>> label in the MPLS label stack, which only carry Timing messages as >>>>>> well as OAM, but not data plane client traffic. >>>>>> >>>>>> Compliant implementations MUST use dedicated LSPs to carry Timing >>>>>> messages over MPLS. >>>>>> >>>>>> SB> I think that we need a definition of the properies of these LSPs >>>>>> >>>>>> These LSPs are herein referred to as "Timing >>>>>> LSPs" and the labels associated with these LSPs as "Timing LSP >>>>>> labels". The Timing LSPs that runs between Ingress and Egress LERs >>>>>> MUST be co-routed. Alternatively, a single bidirectional co-routed >>>>>> LSP can be used. >>>>>> >>>>>> SB> I though that you said you could use M2MP LSPs - these are not >>>>>> SB> bidirectional. >>>>>> >>>>>> Co-routing of the two directions is required to limit the difference >>>>>> in the delays in the Master clock to Slave clock direction compared >>>>>> to the Slave clock to Master clock direction. The Timing LSP MAY be >>>>>> MPLS/MPLS-TP LSP. >>>>>> >>>>>> The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS. >>>>>> New Extensions to RSVP-TE/GMPLS TLVs are required; however they are >>>>>> outside the scope of this document. >>>>>> >>>>>> The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such as >>>>>> BFD and LSP Ping but the LSP data plane client plane traffic MUST be >>>>>> Timing packets only. >>>>>> >>>>>> SB> Why? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 12] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 6. Timing over LSP Encapsulation >>>>>> >>>>>> The encapsulations is not LSP is it? >>>>>> >>>>>> This document defines two methods for carrying Timing messages over >>>>>> MPLS. The first method is carrying UDP/IP encapsulated Timing >>>>>> messages over Timing LSPs, and the second method, is carrying >>>>>> Ethernet encapsulated Timing messages over Ethernet PWs inside >>> Timing >>>>>> LSPs. >>>>>> >>>>>> 6.1. Timing over UDP/IP over MPLS Encapsulation >>>>>> >>>>>> The simplest method of transporting Timing messages over MPLS is to >>>>>> encapsulate Timing PDUs in UDP/IP and then encapsulate them in >>> Timing >>>>>> LSP. This format is shown in Figure 4. >>>>>> >>>>>> >>>>>> +----------------------+ >>>>>> | Timing LSP Label | >>>>>> +----------------------+ >>>>>> | IPv4/6 | >>>>>> +----------------------+ >>>>>> | UDP | >>>>>> +----------------------+ >>>>>> | Timing PDU | >>>>>> +----------------------+ >>>>>> >>>>>> Figure (4) - Timing over UDP/IP over MPLS Encapsulation >>>>>> >>>>>> >>>>>> This encapsulation is very simple and is useful when the network >>>>>> between Timing Master Clock and Slave Clock is MPLS network. >>>>>> >>>>>> SB> Simple is a judgement call >>>>>> >>>>>> In order for an LER/LSR to process Timing messages, the Timing LSP >>>>>> Label must be at the top label of the label stack. The LER/LSR MUST >>>>>> know that the Timing LSP Label is used for carrying Timing messages. >>>>>> This can be accomplished via static configuration or via RSVP-TE >>>>>> signaling. >>>>>> >>>>>> The UDP/IP encapsulation of PTP MUST follow Annex D and E of >>>>>> [IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow >>>>>> [RFC5905]. >>>>>> >>>>>> 6.2. Timing over PW Encapsulation >>>>>> >>>>>> Another method of transporting Timing over MPLS networks is by >>>>>> encapsulating Timing PDUs in PW which in turn is transported over >>>>>> Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448], >>>>>> shown in Fig 5(A) MUST be used and the Ethernet encapsulation of PTP >>>>>> MUST follow Annex F of [IEEE-1588]. >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 13] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> The RAW mode or Tagged mode defined in [RFC4448] MAY be used and >>> the >>>>>> Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The >>>>>> Timing over PW encapsulation MUST use the Control Word (CW) as >>>>>> specified in [RFC4448] to ensure proper detection of PTP messages >>>>>> inside the MPLS packets for Timing over LSP and Timing over PW >>>>>> encapsulation. >>>>>> >>>>>> SB> That needs explanation >>>>>> >>>>>> The use of Sequence Number in the CW is optional. >>>>>> >>>>>> SB> Given that s/n are never in practice deployed, you could probably >>>>>> SB> simplify things by sayig that they are not used. >>>>>> >>>>>> Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over >>> PW >>>>>> (the IP PW discussed in [RFC4447]) shown in Fig 5(B). >>>>>> >>>>>> +----------------+ +----------------+ >>>>>> |Timing LSP Label| |Timing LSP Label| >>>>>> +----------------+ +----------------+ >>>>>> | PW Label | | PW Label | >>>>>> +----------------+ +----------------+ >>>>>> | Control Word | | IP | >>>>>> +----------------+ +----------------+ >>>>>> | Ethernet | | UDP | >>>>>> | Header | +----------------+ >>>>>> +----------------+ | Timing PDU | >>>>>> |S-VLAN(Optional)| | | >>>>>> +----------------+ +----------------+ >>>>>> |C-VLAN(Optional)| (B) >>>>>> +----------------+ >>>>>> | Timing PDU | >>>>>> | | >>>>>> +----------------+ >>>>>> (A) >>>>>> >>>>>> Figure (5) - Timing over PW Encapsulations >>>>>> >>>>>> In order for an LSR to process PTP messages, the top label of the >>>>>> label stack (the Tunnel Label) MUST be a Timing label. >>>>>> >>>>>> S> You said that before. >>>>>> >>>>>> 6.3. Other Timing Encapsulation methods >>>>>> >>>>>> In future other timing encapsulation methods may be introduced, such >>>>>> as a new shim header after the Bottom of Stack to carry the Timing >>>>>> information. Such new encapsulations are outside the scope of this >>>>>> document. >>>>>> >>>>>> >>>>>> SB> Taking a pure MPLS pov, you can simplify a lot of the text >>>>>> SB> out of the definition of the LSP >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 14] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> SB> I think we need a section on LSP processing >>>>>> >>>>>> 7. Timing message Processing >>>>>> >>>>>> Each Timing protocol such as PTP and NTP, define their set of Timing >>>>>> messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, >>>>>> FOLLOW_UP, etc messages. >>>>>> >>>>>> Some of the Timing messages require time stamping or correction field >>>>>> update at port level and some dont. It is the job of the LER/LSR to >>>>>> parse the timing message and find out the type of the Timing message >>>>>> and decide whether and how to Time- stamp it (e.g., BC) or update >>>>>> correction field(e.g., TC). >>>>>> >>>>>> >>>>>> SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing >>>>>> SB> function rather than the LER? >>>>>> >>>>>> For example the following PTP messages (called Event messages) >>>>>> require time-stamping or correction field update: >>>>>> >>>>>> o SYNC >>>>>> >>>>>> o DELAY_REQ (Delay Request) >>>>>> >>>>>> o PDELAY_REQ (Peer Delay Request) >>>>>> >>>>>> o PDELAY_RESP (Peer Delay Response) >>>>>> >>>>>> SYNC and DELAY_REQ are exchanged between Master Clock and Slave >>> Clock >>>>>> and MUST be transported over PTP LSPs. PDELAY_REQ and >>> PDELAY_RESP >>>>>> are exchanged between adjacent PTP clocks (i.e. Master, Slave, >>>>>> Boundary, or Transparent) and SHOULD be transported over single hop >>>>>> PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP, >>>>>> and PDELAY_RESP_FOLLOW_UP messages MUST also be transported >>> over >>>>>> the >>>>>> PTP LSPs. >>>>>> >>>>>> For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be >>>>>> transported over two PTP LSPs that are in opposite directions. These >>>>>> PTP LSPs, which are in opposite directions MUST be congruent and co- >>>>>> routed. Alternatively, a single bidirectional co-routed LSP can be >>>>>> used. >>>>>> >>>>>> Except as indicated above for the two-step PTP clocks, Non-Event PTP >>>>>> message types do not need to be processed by intermediate routers. >>>>>> These message types MAY be carried in PTP Tunnel LSPs. >>>>>> >>>>>> SB> Are you saying that a timing P router has to be msg type sensitive? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 15] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 8. Protection and Redundancy >>>>>> >>>>>> >>>>>> SB> This is a bit of a jump - I don't know how the LSP itself works yet! >>>>>> >>>>>> In order to ensure continuous uninterrupted operation of slave >>>>>> clocks, usually as a general practice, slave clocks (or ports) track >>>>>> redundant master clocks. >>>>>> >>>>>> It is the responsibility of the network operator to ensure that >>>>>> physically disjoint Timing LSPs are established between a slave clock >>>>>> (or port) and redundant master clocks (or ports). >>>>>> >>>>>> When a slave clock (or port) listens to redundant master clocks or >>>>>> ports, any prolonged Timing LSP outage will trigger the slave clock >>>>>> or port to switch to a redundant master clock or port. >>>>>> >>>>>> LSP/PW protection such as Linear protection Switching (1:1, 1+1), >>>>>> Ring protection switching or MPLS Fast Reroute (FRR) generally switch >>>>>> alternative path that usually cause a change in delay, which if >>>>>> undetected by slave clock can reduce accuracy of the slave clock. >>>>>> >>>>>> Therefore protection switching MAY be used, as long as phase jumps >>>>>> upon switchover due to differences in path latency are detected and >>>>>> compensated for (such compensation not being required if BCs or peer- >>>>>> peer TCs are used throughout). >>>>>> >>>>>> Note that any protection or reroute mechanism that adds additional >>>>>> MPLS label to the label stack, such as Facility Backup Fast Reroute, >>>>>> MUST ensure that the pushed label is also a Timing Label to ensure >>>>>> recognition of the MPLS frame as containing Timing messages, as it >>>>>> transits the backup path. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 16] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 9. ECMP >>>>>> >>>>>> To ensure the optimal operation of slave clocks and avoid error >>>>>> introduced by forward and reverse path delay asymmetry, the physical >>>>>> path for Timing messages from master clock to slave Clock and vice >>>>>> versa must be the same for all Event Timing messages listed in >>>>>> section 7. >>>>>> >>>>>> Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost >>>>>> Multipath). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 17] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 10. PHP >>>>>> >>>>>> To ensure that the label on the top of the label stack is the Timing >>>>>> LSP Label, PHP MUST not be used. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 18] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 11. Entropy >>>>>> >>>>>> To ensure all Timing messages in a Timing LSP take the same path, >>>>>> Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and >>>>>> Entropy Label MUST NOT be used for the PWs that are carried inside >>>>>> Timing LSP [RFC6391]. >>>>>> >>>>>> SB> This is incorrect - you mean that all msgs of the same timing >>>>>> SB> flow need to have the same EL value. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 19] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 12. OAM, Control and Management >>>>>> >>>>>> In order to monitor Timing LSPs and their encapsulated PWs, they MUST >>>>>> be able to carry OAM and management messages. These management >>>>>> messages MUST be differentiated from Timing messages via already >>>>>> defined IETF methods. >>>>>> >>>>>> For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY run >>>>>> over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These >>>>>> Management protocols can easily be identified by the UDP Destination >>>>>> Port number or by GAL/G-ACH respectively. >>>>>> >>>>>> Also BFD, LSP-Ping and other management messages MAY run over the >>> PWs >>>>>> encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3 or >>>>>> 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is going >>>>>> to be deprecated by IETF). In this case G-ACH, PW label (TTL=1) or >>>>>> GAL-ACH are used to identify such management messages. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 20] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 13. QoS Considerations >>>>>> >>>>>> In network deployments where not every LSR/LER is Timing-aware, it is >>>>>> important to reduce the impact of the non-Timing-aware LSR/LERs on >>>>>> the timing recovery in the slave clock. The Timing messages are time >>>>>> critical and must be treated with the highest priority. Therefore >>>>>> Timing over MPLS messages must be treated with the highest priority >>>>>> in the routers. This can be achieved by proper setup of Timing LSPs. >>>>>> >>>>>> It is recommended that the Timing LSPs are setup or configured >>>>>> properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC2697] >>>>>> for drop eligibility. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 21] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 14. FCS and Checksum Recalculation >>>>>> >>>>>> When time-stamp generation and timing packet adjustment is performed >>>>>> near the physical port hardware, the process MUST include >>>>>> recalculation of the Ethernet FCS. >>>>>> >>>>>> SB> The above is confusing - an LSR always recomputes the link layer >>>>>> SB> CRC which may or may not be Ethernet. >>>>>> >>>>>> Also FCS retention for the >>>>>> payload Ethernet described in [RFC4720] MUST NOT be used. >>>>>> >>>>>> For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum >>>>>> may be required as per UDP transport standards. >>>>>> >>>>>> SB> You really need to be working on getting the IPv6 C?S computation >>>>>> SB> removed from PTP msgs. >>>>>> >>>>>> When UDP checksum is used, each Timing-aware LER/LSR must either >>>>>> incrementally update the UDP checksum after Time stamping or >>>>>> Correction Field update or verify the UDP checksum on reception from >>>>>> upstream and recalculate the checksum completely on transmission to >>>>>> downstream node after Time stamping or Correction Field update. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 22] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 15. Behavior of LER/LSR >>>>>> >>>>>> Timing-capable/aware LERs and LSRs are routers that have one or more >>>>>> >>>>>> SB> You mean physical interfaces? >>>>>> >>>>>> interfaces that can perform Timing operations (OC/BC/TC) on Timing >>>>>> packets and are configured to do so. Timing-capable/aware LERs and >>>>>> LSRs can advertise their Timing-capability per-interface via control >>>>>> plane such as OSPF or IS-IS. >>>>>> SB> ISIS and OSPF are routing protocols. >>>>>> >>>>>> The Timing-capable/aware LERs can then >>>>>> signals Timing LSPs via RSVP-TE signaling. Alternatively the Timing >>>>>> capability of LER and LSRs may be configured in a centralized >>>>>> controller and the Timing LSP may be setup using manual configuration >>>>>> or other methods such as SDN. >>>>>> >>>>>> SB> it can also be configured individually rather then through >>>>>> SB> a cebtral controllwe >>>>>> >>>>>> 15.1. Behavior of Timing-capable/aware LER >>>>>> >>>>>> When a Timing-capable/aware LER behaves as a Transparent clock and >>>>>> receives a Timing message from a Timing-capable/aware non-MPLS >>>>>> interface, the LER updates the Correction Field (CF) and encapsulates >>>>>> and forwards the timing message over previously established Timing >>>>>> LSP. >>>>>> >>>>>> SB> You need to call out the details so that people properly >>>>>> SB> understand the definition of the new LSP. >>>>>> >>>>>> Also when a Timing message is received from a Timing-capable/ >>>>>> aware MPLS interface, LER updates the Correction Filed (CF) and >>>>>> decapsulates the MPLS encapsulation and forwards the timing message >>>>>> to a non-MPLS interface. >>>>>> >>>>>> When a Timing-capable/aware LER behaves as a Boundary clock and >>>>>> receives a Timing message from a Timing-capable/aware non MPLS >>>>>> interface, the LER Timestamps the Timing packet and sends it to the >>>>>> LERs Boundary clock processing module. Also when a Timing message is >>>>>> received from a Timing- capable/aware MPLS interface, the LER >>>>>> Timestamps the Timing packet and sends it to the LERs Boundary clock >>>>>> processing module. >>>>>> >>>>>> When a Timing-capable/aware LER behaves as an Ordinary Clock toward >>>>>> the MPLS network, and receives a Timing message from a Timing- >>>>>> capable/aware MPLS interface, the LER Timestamps the Timing packet >>>>>> and sends it to the LERs Ordinary clock processing module. >>>>>> >>>>>> 15.2. Behavior of Timing-capable/aware LSR >>>>>> >>>>>> When a Timing-capable/aware LSR behaves as a Transparent clock and >>>>>> receives a Timing message from a Timing-capable/aware MPLS >>> interface, >>>>>> The LSR updates the Correction Filed (CF) and forwards the timing >>>>>> message over another MPLS interface. >>>>>> >>>>>> When a Timing-capable/aware LSR behaves as a Boundary clock and >>>>>> receives a Timing message from a Timing-capable/aware MPLS >>> interface. >>>>>> The LSR performs the functions of a Boundary Clock in terminating the >>>>>> received Timing message and re-generating a new timing message over >>>>>> another (or the same) MPLS interface. >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 23] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 15.3. Behavior of non-Timing-capable/aware LSR >>>>>> >>>>>> It is most beneficial when all LSRs in the path of a Timing LSP be >>>>>> timing-Capable/aware LSRs. This would ensure the highest quality >>>>>> time and clock synchronization by Timing Slave Clocks. However, this >>>>>> specification does not mandate that all LSRs in path of a Timing LSP >>>>>> be Timing- capable/aware. >>>>>> >>>>>> Non-Timing-capable/aware LSRs just switch the packets encapsulated in >>>>>> Timing LSPs and dont perform any Timing operation (TC or BC). >>>>>> However as explained in QoS section the Timing over MPLS packets >>> MUST >>>>>> be still be treated with the highest priority based on their Traffic >>>>>> Class (TC) marking. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 24] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 16. Other considerations >>>>>> >>>>>> [IEEE-1588] defines an optional peer-to-peer Transparent clocking >>>>>> that requires peer delay measurement between two adjacent Timing- >>>>>> capable/ aware routers/switches. Peer delay measurement messages >>>>>> need to be time stamped and terminated by the Timing-capable/aware >>>>>> routers/ switches. This means that two adjacent LSRs may be engaged >>>>>> in a peer delay measurement. >>>>>> >>>>>> For transporting such peer delay measurement messages a single-hop >>>>>> LSP SHOULD to be created between the two adjacent LSRs engaged in >>>>>> peer delay measurement to carry peer delay measurement messages. >>>>>> Other methods such as PTP transport over Ethernet MAY be used for >>>>>> transporting peer delay measurement messages if the link between the >>>>>> two routers is Ethernet. >>>>>> >>>>>> In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ ware >>>>>> routers/switches MUST maintain a list of all the neighbors it needs >>>>>> to send a PDelay_Req to, where each neighbor corresponds to a timing >>>>>> LSP. >>>>>> >>>>>> The use of Explicit Null Label (Label= 0 or 2) is acceptable as long >>>>>> as either the Explicit Null label is the bottom of stack label >>>>>> (applicable only to UDP/IP encapsulation) or the label below the >>>>>> Explicit Null label is a PTP label. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 25] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 17. Security Considerations >>>>>> >>>>>> MPLS PW security considerations in general are discussed in [RFC3985] >>>>>> and [RFC4447],and those considerations also apply to this document. >>>>>> >>>>>> An experimental security protocol is defined in [IEEE-1588].The PTP >>>>>> security extension and protocol provides group source authentication, >>>>>> message integrity, and replay attack protection for PTP messages. >>>>>> >>>>>> When the MPLS network (provider network) serves multiple customers, >>>>>> it is important to maintain and process each customers clock and >>>>>> Timing messages separately from other customers to ensure there is no >>>>>> cross- customer effect. For example if an LER BC is synchronized to >>>>>> a specific grandmaster, belonging to customer A, then the LER MUST >>>>>> use that BC clock only for customer A to ensure that customer A >>>>>> cannot attack other customers by manipulating its time. >>>>>> >>>>>> Timing messages MAY be encrypted or authenticated, provided that the >>>>>> LERs/LSRs that are Timing capable/aware can authenticate/ decrypt the >>>>>> timing messages. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 26] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 18. Acknowledgements >>>>>> >>>>>> The authors would like to thank Ron Cohen, Yaakov Stein, Tal Mizrahi, >>>>>> Stefano Ruffini, Peter Meyer, and other members of IETF for reviewing >>>>>> and providing feedback on this draft. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 27] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 19. IANA Considerations >>>>>> >>>>>> There are no IANA requirements in this specification. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 28] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 20. References >>>>>> >>>>>> 20.1. Normative References >>>>>> >>>>>> [IEEE-1588] >>>>>> IEEE 1588-2008, "IEEE Standard for a Precision Clock >>>>>> Synchronization Protocol for Networked Measurement and >>>>>> Control Systems". >>>>>> >>>>>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >>>>>> Requirement Levels", BCP 14, RFC 2119, March 1997. >>>>>> >>>>>> [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- >>>>>> Edge (PWE3) Architecture", RFC 3985, March 2005. >>>>>> >>>>>> [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery >>>>>> Proxies (ND Proxy)", RFC 4389, April 2006. >>>>>> >>>>>> [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. >>>>>> Heron, "Pseudowire Setup and Maintenance Using the Label >>>>>> Distribution Protocol (LDP)", RFC 4447, April 2006. >>>>>> >>>>>> [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, >>>>>> "Encapsulation Methods for Transport of Ethernet over MPLS >>>>>> Networks", RFC 4448, April 2006. >>>>>> >>>>>> [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire >>>>>> Emulation Edge-to-Edge (PWE3) Frame Check Sequence >>>>>> Retention", RFC 4720, November 2006. >>>>>> >>>>>> [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit >>>>>> Connectivity Verification (VCCV): A Control Channel for >>>>>> Pseudowires", RFC 5085, December 2007. >>>>>> >>>>>> [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection >>>>>> (BFD)", RFC 5880, June 2010. >>>>>> >>>>>> [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, >>>>>> "Bidirectional Forwarding Detection (BFD) for MPLS Label >>>>>> Switched Paths (LSPs)", RFC 5884, June 2010. >>>>>> >>>>>> 20.2. Informative References >>>>>> >>>>>> [I-D.ietf-pwe3-fat-pw] >>>>>> Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, >>>>>> J., and S. Amante, "Flow Aware Transport of Pseudowires >>>>>> over an MPLS Packet Switched Network", >>>>>> draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011. >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 29] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate >>>>>> system routeing information exchange protocol for use in >>>>>> conjunction with the Protocol for providing the >>>>>> Connectionless-mode Network Service (ISO 8473)". >>>>>> >>>>>> [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and >>>>>> dual environments", RFC 1195, December 1990. >>>>>> >>>>>> [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. >>>>>> >>>>>> [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color >>>>>> Marker", RFC 2697, September 1999. >>>>>> >>>>>> [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, >>>>>> J., Courtney, W., Davari, S., Firoiu, V., and D. >>>>>> Stiliadis, "An Expedited Forwarding PHB (Per-Hop >>>>>> Behavior)", RFC 3246, March 2002. >>>>>> >>>>>> [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering >>>>>> (TE) Extensions to OSPF Version 2", RFC 3630, >>>>>> September 2003. >>>>>> >>>>>> [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate >>>>>> System (IS-IS) Extensions for Traffic Engineering (TE)", >>>>>> RFC 3784, June 2004. >>>>>> >>>>>> [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. >>>>>> Shaffer, "Extensions to OSPF for Advertising Optional >>>>>> Router Capabilities", RFC 4970, July 2007. >>>>>> >>>>>> [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate >>>>>> System to Intermediate System (IS-IS) Extensions for >>>>>> Advertising Router Information", RFC 4971, July 2007. >>>>>> >>>>>> [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi >>>>>> Topology (MT) Routing in Intermediate System to >>>>>> Intermediate Systems (IS-ISs)", RFC 5120, February 2008. >>>>>> >>>>>> [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic >>>>>> Engineering", RFC 5305, October 2008. >>>>>> >>>>>> [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, >>>>>> "Traffic Engineering Extensions to OSPF Version 3", >>>>>> RFC 5329, September 2008. >>>>>> >>>>>> [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF >>>>>> for IPv6", RFC 5340, July 2008. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 30] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network >>>>>> Time Protocol Version 4: Protocol and Algorithms >>>>>> Specification", RFC 5905, June 2010. >>>>>> >>>>>> [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, >>>>>> J., and S. Amante, "Flow-Aware Transport of Pseudowires >>>>>> over an MPLS Packet Switched Network", RFC 6391, >>>>>> November 2011. >>>>>> >>>>>> [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and >>>>>> L. Yong, "The Use of Entropy Labels in MPLS Forwarding", >>>>>> RFC 6790, November 2012. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 31] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 1. Routing extensions for Timing-aware Routers >>>>>> >>>>>> MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and >>>>>> IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE) >>>>>> link information used for constraint-based routing. >>>>>> >>>>>> Indeed, it is useful to advertise data plane TE router link >>>>>> capabilities, such as the capability for a router to be Timing-aware. >>>>>> This capability MUST then be taken into account during path >>>>>> computation to prefer or even require links that advertise themselves >>>>>> as Timing-aware. In this way the path can ensure the entry and exit >>>>>> points into the LERs and, if desired, the links into the LSRs are >>>>>> able to perform port based time-stamping thus minimizing their impact >>>>>> on the performance of the slave clock. >>>>>> >>>>>> extensions are required to OSPF and IS-IS in order to advertise >>>>>> Timing-aware capabilities of a link. Such extensions are outside the >>>>>> scope of this document; however such extension SHOULD be able to >>>>>> signal the following information per Router Link: >>>>>> >>>>>> o Capable of processing PTP, NTP or other Timing flows >>>>>> >>>>>> o Capable of performing Transparent Clock operation >>>>>> >>>>>> o Capable of performing Boundary Clock operation >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 32] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> 2. Signaling Extensions for Creating Timing LSPs >>>>>> >>>>>> RSVP-TE signaling MAY be used to setup the timing LSPs. When RSVP-TE >>>>>> is used to setup Timing LSPs, some information that indicates that >>>>>> the LSP is carrying Timing flows MUST be included in the new >>>>>> Extensions to RSVP-TE: >>>>>> >>>>>> The following information MAY also be included in the new Extensions >>>>>> to RSVP-TE: >>>>>> >>>>>> o Offset from Bottom of Stack (BoS) to the start of the Time-stamp >>>>>> field >>>>>> >>>>>> o Number of VLANs in case of PW encapsulation >>>>>> >>>>>> o Timestamp field Type >>>>>> >>>>>> * Correction Field, Timestamp >>>>>> >>>>>> o Timestamp Field format >>>>>> >>>>>> * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit >>>>>> NTP, etc. >>>>>> >>>>>> Note that in case the above optional information is signaled with >>>>>> RSVP-TE for a Timing LSP, all the Timing packets carried in that LSP >>>>>> must have the same signaled characteristics. For example if >>>>>> Timestamp format is signaled as 64-bit PTPv1, then all Timing packets >>>>>> must use 64-bit PTPv1 time-stamp. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 33] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> Authors' Addresses >>>>>> >>>>>> Shahram Davari >>>>>> Broadcom Corp. >>>>>> San Jose, CA 95134 >>>>>> USA >>>>>> >>>>>> Email: davari@broadcom.com >>>>>> >>>>>> >>>>>> Amit Oren >>>>>> Broadcom Corp. >>>>>> San Jose, CA 95134 >>>>>> USA >>>>>> >>>>>> Email: amito@broadcom.com >>>>>> >>>>>> >>>>>> Manav Bhatia >>>>>> Alcatel-Lucent >>>>>> Bangalore, >>>>>> India >>>>>> >>>>>> Email: manav.bhatia@alcatel-lucent.com >>>>>> >>>>>> >>>>>> Peter Roberts >>>>>> Alcatel-Lucent >>>>>> Kanata, >>>>>> Canada >>>>>> >>>>>> Email: peter.roberts@alcatel-lucent.com >>>>>> >>>>>> >>>>>> Laurent Montini >>>>>> Cisco Systems >>>>>> San Jose CA >>>>>> USA >>>>>> >>>>>> Email: lmontini@cisco.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 34] >>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>> >>>>>> >>>>>> Luca >>>>>> Cisco Systems >>>>>> San Jose CA >>>>>> USA >>>>>> >>>>>> Email: lmartini@cisco.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page 35] >>>>>> -- >>>>>> For corporate legal information go to: >>>>>> >>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>> >>>>>> _______________________________________________ >>>>>> TICTOC mailing list >>>>>> TICTOC@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tictoc >>>>> 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 >>>> . >>> >>> -- >>> For corporate legal information go to: >>> >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>> >>> _______________________________________________ >>> TICTOC mailing list >>> TICTOC@ietf.org >>> https://www.ietf.org/mailman/listinfo/tictoc >>> >>> >>> _______________________________________________ >>> TICTOC mailing list >>> TICTOC@ietf.org >>> https://www.ietf.org/mailman/listinfo/tictoc >> >> 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. >> > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From davarish@yahoo.com Tue Aug 20 09:50:08 2013 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 37B9011E8251 for ; Tue, 20 Aug 2013 09:50:08 -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=[BAYES_00=-2.599, 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 Gs905ESMS+my for ; Tue, 20 Aug 2013 09:50:03 -0700 (PDT) Received: from nm43-vm5.bullet.mail.bf1.yahoo.com (nm43-vm5.bullet.mail.bf1.yahoo.com [216.109.114.236]) by ietfa.amsl.com (Postfix) with ESMTP id D7ED111E825D for ; Tue, 20 Aug 2013 09:49:42 -0700 (PDT) Received: from [98.139.212.150] by nm43.bullet.mail.bf1.yahoo.com with NNFMP; 20 Aug 2013 16:49:40 -0000 Received: from [98.139.211.192] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 20 Aug 2013 16:49:40 -0000 Received: from [127.0.0.1] by smtp201.mail.bf1.yahoo.com with NNFMP; 20 Aug 2013 16:49:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1377017380; bh=gQcetVzAzrB5HjM0s50W+cCFVDk/x189lM6m53hK5kU=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=oXoNeVagRu3M3VoLkW9a62esCE8FbTLc/xkw7Xabx6UksLgHCdIMg8y1c4dw76HrnW31j1SKwXKz02p3J41OnliYYbvoIv4P/rDhGO+TrM5J8lg8r4cQT8eEOC0qDJcMOCfcF5YG7ONjoP5rygvdEE2EmaZWJvJaf0cuRwLI/To= X-Yahoo-Newman-Id: 597071.38204.bm@smtp201.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: nQ.vlFMVM1nCrFqlgKNSmFwGxmFIdLIw73xQzeJnseZnYmx vrBcxsLEHr.BoDL._Ppr577pNxwEi705HXSU6UQuHUhGc.yQxNxMpxvKN2dM BVXTalyCnrtY.xjMaj.PRFjCuOtZk.G1ldDqCKvip6I0uHXyvJ68pKp6z2SP szoLs63Lfq_hxQW0wLqi69dzWVha0ZDCvpCOGHsmlDM94YQL0Oy3zmE7GJx1 0g8beTCc.C8yTO_wa_BQHstsIZhN7BdHB0nwg6m.9Pl8bYVQeXhHBqj.a3X9 wv6Y1hRNYNcTwXQT5yZ_UBOcXUYwdqEQKxQoPICwkzKHbcIwhmPTTBj6mmmU E2sZJ6e.rKJ2FZ1Aoy8WAjmmWYNY6uLZuBxm9Ux0zFHL82rsh9qapUb7mazL I877NWsAA18CmecvYKoifsUC1hjJYWKpg87EFB3yXoMSfz02QSIlt6S5q7_v hODSP25cM7jrVHukCGCIkQjMLno1BkY95pdqVIGB5tgLd1T7ih_GWnZhY1b2 8HkK79TSCsO9Ip3q0fOdNt_znVsqtWNdvncVWlnNAdA71Y_SF X-Yahoo-SMTP: ygPrP9CswBCWPbPtKJlJyLY0KMlg X-Rocket-Received: from [192.168.0.103] (davarish@98.248.42.143 with ) by smtp201.mail.bf1.yahoo.com with SMTP; 20 Aug 2013 09:49:40 -0700 PDT References: <51FB7543.801@cisco.com> <51FF7068.9080600@cisco.com> <4A6CE49E6084B141B15C0713B8993F281BEC731A@SJEXCHMB12.corp.ad.broadcom.com> <52139903.8040801@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <52139903.8040801@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9A8CF696-5D44-4C6C-925B-2DC670374671@yahoo.com> X-Mailer: iPhone Mail (10A403) From: "S. Davari" Date: Tue, 20 Aug 2013 09:49:31 -0700 To: "stbryant@cisco.com" Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] Comments on draft-ietf-tictoc-1588overmpls 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, 20 Aug 2013 16:50:09 -0000 Hi Stewart, Agree that can be done, but not with a reserved label on top if the stack. Regards, Shahram On Aug 20, 2013, at 9:27 AM, Stewart Bryant wrote: > On 06/08/2013 14:35, S. Davari wrote: >> Sasha, >>=20 >> If a router is not 1588 aware we want it to switch the packet with minimu= m jitter and delay via high priority queue. > Yes, but you can explicitly tunnel across such island of incompatibility >=20 > Stewart >=20 >> =20 >> Sending it to CPU creates large jitter and delay since the CPUs are gener= ally busy doing other things. Time stamping or updating CF in the CPU won't h= elp since it does not cover the variable delay that is incurred from the tim= e the packet enters the router to the time the packet gets processed by CPU.= >>=20 >> I wish it was that easy! >>=20 >> Regards, >> Shahram >>=20 >>=20 >> On Aug 6, 2013, at 12:38 AM, Alexander Vainshtein wrote: >>=20 >>> Shahram, >>> I agree with you that the routers that do not recognize a Timing Alert l= abel would send the packet to the CPU. (This would be easy to arrange since w= e are speaking about a reserved label.) >>>=20 >>> I do not, however, see this as a serious issue, because the SW running o= n this CPU would (hopefully) be upgradable to handle the packet correctly i.= e., to forward it to where it should be forwarded and, if it is forwarded as= a labeled packet, to prepend the Timing Alert Label on top of its label sta= ck. It could even record the residence time (as observed by the CPU in the p= roper place in the packet. This would mean that introducing additional error= to whatever timing information is associated with this packet - but this is= what you should anyway expect if there are non-compliant routers on your pa= th, right? >>>=20 >>> Regards, >>> Sasha >>>=20 >>>> -----Original Message----- >>>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behal= f Of >>>> Shahram Davari >>>> Sent: Monday, August 05, 2013 11:29 PM >>>> To: stbryant@cisco.com; S. Davari >>>> Cc: mpls@ietf.org; tictoc@ietf.org >>>> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls= >>>>=20 >>>> Hi Stewart, >>>>=20 >>>> Your suggestion of " I suggested an LSP type that has the properties "t= imestamp >>>> and pass to application", is a subset of the existing draft and should w= ork. It >>>> basically limits the time stamping and correction field update to LERs (= while the >>>> draft supports time stamping at LER and LSR). >>>>=20 >>>> However Sasha's suggestion of using a reserved label (RAL, GAL or any o= ther >>>> reserved label) does not satisfy one of the major requirements, which i= s >>>> backward compatibility. Routers that don't understand this reserved lab= el will >>>> drop or copy to CPU such packets. >>>>=20 >>>> Regards, >>>> Shahram >>>>=20 >>>> -----Original Message----- >>>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behal= f Of >>>> Stewart Bryant >>>> Sent: Monday, August 05, 2013 2:29 AM >>>> To: S. Davari >>>> Cc: mpls@ietf.org; tictoc@ietf.org >>>> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls= >>>>=20 >>>> My concern is that we are creating a new LSP type in MPLS >>>> (which is a architectural change and thus needs to be very carefully >>>> considered) without asking the question "how can I do this >>>> in the most general way, to maximize flexibility/reuse" >>>>=20 >>>> I suggested an LSP type that has the properties "timestamp >>>> and pass to application", but I think that Sasha raises a good >>>> point about using router alert. However RA has no implicit >>>> timestamp, so maybe we need a new type of RA that has the >>>> properties "timestamp, and pass top application indicated by >>>> the next label". That would be quite useful in a number >>>> of OAM applications. There is possibly some GAL variant >>>> of that design that should also be considered. >>>>=20 >>>> The application could worry about the path and where it >>>> was necessary to skip some hops a hierarchical LSP would >>>> accomplish that, with the specific benefit that the application >>>> would consciously do this, and may be able to apply some >>>> form of compensation within the network. >>>>=20 >>>> - Stewart >>>>=20 >>>> On 04/08/2013 10:40, S. Davari wrote: >>>>> Hi Sasha >>>>>=20 >>>>> Perhaps you have not understood the draft well. The main reason that t= he >>>> draft chose to use a dedicated LSP that is signaled via RSVPTE indicati= ng it is a >>>> timing LSP is to be backward compatible with non-1588 nodes. Such nodes= >>>> simply just switch the packet. >>>>> Your proposal had been considered and was rejected since it was not >>>> backward compatible. Nodes receiving alert label or TTL =3D 1 send the p= acket to >>>> CPU. You can refer to the meeting notes. >>>>> Regards, >>>>> Shahram >>>>>=20 >>>>>=20 >>>>> On Aug 4, 2013, at 1:21 AM, Alexander Vainshtein >>>> wrote: >>>>>> Stewart and all, >>>>>> I concur with Stewart's statement that the draft does not define "ful= l >>>> interaction with MPLS architecture". >>>>>> E.g., one of the objectives of the draft is to provide a technique th= at would >>>> be backward-compatible with old LSRs that cannot provide on-path suppor= t for >>>> timing distribution, while the other objective is to make every LSR on t= he path >>>> aware that some MPLS packets are carrying timing-related messages and h= ence >>>> require on-path support. >>>>>> IMHO and FWIW, the MPLS data plane architecture allows just two metho= ds >>>> for making a transit LSR to provide special processing to a labeled pac= ket: >>>>>> - It would carry some kind of an "alert label" on top of the label st= ack and, >>>> specifically, on top of any labels used for actual forwarding >>>>>> OR, >>>>>> - The TTL in the top label stack entry has been set to 1. >>>>>>=20 >>>>>>=20 >>>>>> The draft does not follow any of these approaches. >>>>>>=20 >>>>>> I must also admit that Section 12 "OAM, Control and Management" of th= e >>>> draft looks somewhat in >>>>>> E.g., I could not understand from the text whether BFD, LSP-Ping etc.= OAM >>>> messages would be subjected to on-path support procedures for timing >>>> messages or not. >>>>>> My 2c, >>>>>> Sasha >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Be= half >>>> Of >>>>>>> Stewart Bryant >>>>>>> Sent: Friday, August 02, 2013 12:01 PM >>>>>>> To: mpls-chairs@tools.ietf.org; tictoc-chairs@tools.ietf.org; int- >>>>>>> ads@tools.ietf.org; rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.o= rg; >>>> draft- >>>>>>> ietf-tictoc-1588overmpls@tools.ietf.org >>>>>>> Cc: mpls@ietf.org; tictoc@ietf.org >>>>>>> Subject: [TICTOC] Comments on draft-ietf-tictoc-1588overmpls >>>>>>>=20 >>>>>>> SB> This draft does not seem to provide a precise definition >>>>>>> SB> the properties of the new LSP type that it wishes to >>>>>>> SB> define, in particular it does it define the PHB of those >>>>>>> SB> LSPs, nor the full interaction with the MPLS >>>>>>> SB> architecture. >>>>>>> SB> >>>>>>> SB> I have not tracked TICTOC for a while but I thought that >>>>>>> SB> the original plan was to define the concept of an offset >>>>>>> SB> into a packet to do the correction. >>>>>>> SB> >>>>>>> SB> It is disappointing that the opportunity was not taken >>>>>>> SB> to define a timing shim inside the timing LSP so that >>>>>>> SB> a time correction could be added to any packet such that >>>>>>> SB> the MPLS system was isolated from the details of the >>>>>>> SB> complexity of the particular time transfer type. >>>>>>>=20 >>>>>>> SB> I think that much more clarify is needed in terms of >>>>>>> SB> definition of the new LSP type, since it is unclear >>>>>>> SB> from this text how to implement one. >>>>>>> SB> >>>>>>> SB> There are a lot of other MPLS services such as >>>>>>> SB> LSP ping that need to be considered. >>>>>>> SB> >>>>>>> SB> Please see inline for more comments. However these >>>>>>> SB> comments are made in the context of the text as written >>>>>>> SB> whilst I have a fundamental concern that this approach >>>>>>> SB> lacks an MPLS architectural soundness that need >>>>>>> SB> greater thought with significant impact on the >>>>>>> SB> draft. >>>>>>>=20 >>>>>>> - Stewart >>>>>>>=20 >>>>>>>=20 >>>>>>> TICTOC Working Group S. Da= vari >>>>>>> Internet-Draft A. O= ren >>>>>>> Intended status: Standards Track Broadcom C= orp. >>>>>>> Expires: December 17, 2013 M. Bh= atia >>>>>>> P. Rob= erts >>>>>>> Alcatel-Lu= cent >>>>>>> L. Mon= tini >>>>>>> L. Mar= tini >>>>>>> Cisco Sys= tems >>>>>>> June 15, 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> Transporting Timing messages over MPLS Networks >>>>>>> draft-ietf-tictoc-1588overmpls-05 >>>>>>>=20 >>>>>>> Abstract >>>>>>>=20 >>>>>>> This document defines the method for transporting Timing messages= >>>>>>> such as PTP and NTP over an MPLS network. The method allows for t= he >>>>>>> easy identification of these PDUs at the port level to allow for p= ort >>>>>>>=20 >>>>>>> SB> What is a port >>>>>>>=20 >>>>>>> level processing of these PDUs in both LERs and LSRs. >>>>>>>=20 >>>>>>> The basic idea is to transport Timing messages inside dedicated M= PLS >>>>>>> LSPs. These LSPs only carry Timing messages and possibly Control= and >>>>>>> Management packets, but they do not carry customer traffic. >>>>>>>=20 >>>>>>> SB> More specifically they only carry traffic associated with the >>>>>>> SB> timing service and its support. >>>>>>> SB> The question arose WRT BFD - surely BFD is allowed, BUT surely >>>>>>> SB> also it gets carried in a structure that causes it to get >>>>>>> SB> timestamped. >>>>>>>=20 >>>>>>> Two methods for transporting Timing messages over MPLS are define= d. >>>>>>>=20 >>>>>>> SB> Perhaps the right approach is to define the new LSP type and the= n >>>>>>> SB> seperately to define the mapping of the various timing services= >>>>>>> SB> over that LSP type. >>>>>>>=20 >>>>>>> The first method is to transport Timing messages directly over th= e >>>>>>> dedicated MPLS LSP via UDP/IP encapsulation, which is suitable fo= r >>>>>>> MPLS networks. The second method is to transport Timing messages= >>>>>>> inside a PW via Ethernet encapsulation. >>>>>>>=20 >>>>>>> SB> I think that we should note that there are some >>>>>>> SB> h/w reasons for this preference. A clean sheet approach >>>>>>> SB> would have been to use PTP over MPLS with no intermediate >>>>>>> SB> layers. >>>>>>>=20 >>>>>>> Status of this Memo >>>>>>>=20 >>>>>>> This Internet-Draft is submitted in full conformance with the >>>>>>> provisions of BCP 78 and BCP 79. >>>>>>>=20 >>>>>>> Internet-Drafts are working documents of the Internet Engineering= >>>>>>> Task Force (IETF). Note that other groups may also distribute >>>>>>> working documents as Internet-Drafts. The list of current Intern= et- >>>>>>> Drafts is at http://datatracker.ietf.org/drafts/current/. >>>>>>>=20 >>>>>>> Internet-Drafts are draft documents valid for a maximum of six mo= nths >>>>>>> and may be updated, replaced, or obsoleted by other documents at a= ny >>>>>>> time. It is inappropriate to use Internet-Drafts as reference >>>>>>> material or to cite them other than as "work in progress." >>>>>>>=20 >>>>>>> This Internet-Draft will expire on December 17, 2013. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 1] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> Copyright Notice >>>>>>>=20 >>>>>>> Copyright (c) 2013 IETF Trust and the persons identified as the >>>>>>> document authors. All rights reserved. >>>>>>>=20 >>>>>>> This document is subject to BCP 78 and the IETF Trust's Legal >>>>>>> Provisions Relating to IETF Documents >>>>>>> (http://trustee.ietf.org/license-info) in effect on the date of >>>>>>> publication of this document. Please review these documents >>>>>>> carefully, as they describe your rights and restrictions with res= pect >>>>>>> to this document. Code Components extracted from this document m= ust >>>>>>> include Simplified BSD License text as described in Section 4.e o= f >>>>>>> the Trust Legal Provisions and are provided without warranty as >>>>>>> described in the Simplified BSD License. >>>>>>>=20 >>>>>>>=20 >>>>>>> Table of Contents >>>>>>>=20 >>>>>>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .= 5 >>>>>>>=20 >>>>>>> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .= 7 >>>>>>>=20 >>>>>>> 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . .= 8 >>>>>>>=20 >>>>>>> 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . .= 9 >>>>>>>=20 >>>>>>> 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . .= 12 >>>>>>>=20 >>>>>>> 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . .= 13 >>>>>>> 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . .= 13 >>>>>>> 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . .= 13 >>>>>>> 6.3. Other Timing Encapsulation methods . . . . . . . . . . . .= 14 >>>>>>>=20 >>>>>>> 7. Timing message Processing . . . . . . . . . . . . . . . . . .= 15 >>>>>>>=20 >>>>>>> 8. Protection and Redundancy . . . . . . . . . . . . . . . . . .= 16 >>>>>>>=20 >>>>>>> 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .= 17 >>>>>>>=20 >>>>>>> 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .= 18 >>>>>>>=20 >>>>>>> 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . .= 19 >>>>>>>=20 >>>>>>> 12. OAM, Control and Management . . . . . . . . . . . . . . . . .= 20 >>>>>>>=20 >>>>>>> 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . .= 21 >>>>>>>=20 >>>>>>> 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . .= 22 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 2] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . .= 23 >>>>>>> 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . .= 23 >>>>>>> 15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . .= 23 >>>>>>> 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . .= 24 >>>>>>>=20 >>>>>>> 16. Other considerations . . . . . . . . . . . . . . . . . . . . .= 25 >>>>>>>=20 >>>>>>> 17. Security Considerations . . . . . . . . . . . . . . . . . . .= 26 >>>>>>>=20 >>>>>>> 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .= 27 >>>>>>>=20 >>>>>>> 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . .= 28 >>>>>>>=20 >>>>>>> 20. References . . . . . . . . . . . . . . . . . . . . . . . . . .= 29 >>>>>>> 20.1. Normative References . . . . . . . . . . . . . . . . . . .= 29 >>>>>>> 20.2. Informative References . . . . . . . . . . . . . . . . . .= 29 >>>>>>>=20 >>>>>>> Appendix 1. Routing extensions for Timing-aware Routers . . . . .= 32 >>>>>>>=20 >>>>>>> Appendix 2. Signaling Extensions for Creating Timing LSPs . . . .= 33 >>>>>>>=20 >>>>>>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .= 34 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 3] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >>>> NOT", >>>>>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" >>>> in >>>>>>> this >>>>>>> document are to be interpreted as described in RFC2119 [RFC2119].= >>>>>>>=20 >>>>>>> When used in lower case, these words convey their typical use in >>>>>>> common language, and are not to be interpreted as described in >>>>>>> RFC2119 [RFC2119]. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 4] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 1. Introduction >>>>>>>=20 >>>>>>> The objective of Precision Time Protocol (PTP) and Network Timing= >>>>>>> Protocol (NTP) are to synchronize independent clocks running on >>>>>>> separate nodes of a distributed system. >>>>>>>=20 >>>>>>> [IEEE-1588] defines PTP messages for frequency, phase and time >>>>>>> synchronization. The PTP messages include PTP PDUs over UDP/IP >>>>>>> (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex = F of >>>>>>> [IEEE-1588]). >>>>>>>=20 >>>>>>> SB> Sure BUT it is acknowledged that IEEE is open to the definition >>>>>>> SB> of other PTP mappings if they provide better optimisation. >>>>>>>=20 >>>>>>> This document defines mapping and transport of the PTP >>>>>>> messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP >>>>>>> defines several clock types: ordinary clocks, boundary clocks, en= d- >>>>>>> to-end transparent clocks, and peer-to-peer transparent clocks. >>>>>>> Transparent clocks require intermediate nodes to update correctio= n >>>>>>> field inside PTP message that reflects the transit time in the no= de. >>>>>>>=20 >>>>>>> [RFC5905] defines NTP messages for clock and time synchronization= . >>>>>>> The PTP messages (PDUs) are transported over UDP/IP. This docume= nt >>>>>>> SB> Should that be NTP messages? >>>>>>> SB> It needs to be made clear as soon as you introduce NTP that >>>>>>> SB> they use different time representations. >>>>>>>=20 >>>>>>> defines mapping and transport of the NTP messages defined in >>>>>>> [RFC5905] over MPLS networks. >>>>>>>=20 >>>>>>> One key attribute of all of these Timing messages is that the Tim= e >>>>>>> stamp processing should occur as close as possible to the actual >>>>>>> transmission and reception at the physical port interface. This >>>>>>> targets optimal time and/or frequency recovery by avoiding variab= le >>>>>>> delay introduced by queues internal to the clocks. >>>>>>>=20 >>>>>>> SB> As I recall NTP has no epoch point defined, and I am not sure >>>>>>> SB> where that point is in the case of PTP in this mapping >>>>>>> SB> Hopefully this will get defined in due course. >>>>>>>=20 >>>>>>> To facilitate the fast and efficient recognition of Timing messag= es >>>>>>> at the port level when the Timing messages are carried over MPLS >>>>>>> LSPs, >>>>>>>=20 >>>>>>> SB> Over a new LSP type with time optimied characteristics >>>>>>>=20 >>>>>>> this document defines the specific encapsulations that should >>>>>>> be used. >>>>>>> SB> Hopefully it will also define the PHP >>>>>>>=20 >>>>>>> In addition, it can be expected that there will exist LSR/ >>>>>>> LERs where only a subset of the physical ports will have the port= - >>>>>>> based Timing message processing capabilities. >>>>>>> SB> Do you need to clarify that this only works at base and not in >>>>>>> SB> a label heirarchy. >>>>>>>=20 >>>>>>>=20 >>>>>>> In order to ensure >>>>>>> that the LSPs carrying Timing packets always enter and exit ports= >>>>>>> with this capability, routing extensions are defined to advertise= >>>>>>> this capability on a port basis and to allow for the establishmen= t of >>>>>>> LSPs that only transit such ports. While this path establishment= >>>>>>> restriction may be applied only at the LER Ingress and/or egress >>>>>>> ports, it becomes more important when using transparent clock cap= able >>>>>>> LSRs in the path. >>>>>>> SB> I do not understand the implications of the last >>>>>>> SB> sentences - starting ", it becomes" >>>>>>>=20 >>>>>>>=20 >>>>>>> Port based Timing message processing involves Timing message >>>>>>> recognition. Once the Timing messages are recognized they can be= >>>>>>> modified based on the reception or transmission Time-stamp. >>>>>>>=20 >>>>>>> This document provides two methods for transporting Timing messag= es >>>>>>> over MPLS. One is applicable to MPLS environment and the other o= ne >>>>>>> is applicable to MPLS/MPLS-TP environment >>>>>>>=20 >>>>>>> SB> I think the sentence is incomplete. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 5] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> The solution involves transporting Timing messages over dedicated= >>>>>>> LSPs called Timing LSPs. These LSPs carry Timing messages and MA= Y >>>>>>> carry Management and control messages, but not data plane client >>>>>>> traffic. >>>>>>>=20 >>>>>>> SB> It is not clear why this restriction applies. >>>>>>>=20 >>>>>>> Timing LSPs can be established statically or via signaling. >>>>>>> SB> s/statically/by provisioning/network management/ >>>>>>>=20 >>>>>>> Extensions to control plane (OSPF, ISIS, etc.) is required to ena= ble >>>>>>> routers to distribute their Timing processing capabilities over M= PLS >>>>>>> to other routers. However such extensions are outside the scope o= f >>>>>>> this document. >>>>>>>=20 >>>>>>> When signaling is used to setup the PTP LSP, Extensions to signal= ing >>>>>>> SB> is it a PTP LSP or a Timing LSP? >>>>>>>=20 >>>>>>> protocols (e.g., RSVP-TE) are required for establishing PTP LSPs.= >>>>>>> However such extensions are outside the scope of this document. >>>>>>>=20 >>>>>>> SB> for mpls-tp GMPLS is the signalling protocol >>>>>>>=20 >>>>>>> While the techniques included herein allow for the establishment o= f >>>>>>> paths optimized to include Time-stamping capable links, the >>>>>>> performance of the Slave clocks is outside the scope of this >>>>>>> document. >>>>>>>=20 >>>>>>> At the time of publishing this specification, Transparent Clockin= g >>>>>>> (TC) is only defined for PTP. Therefore at this time any part of= >>>>>>> this specification that talks about Transparent Clocking applies o= nly >>>>>>> to PTP. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 6] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 2. Terminology >>>>>>>=20 >>>>>>> 1588: The timing and synchronization as defined by IEEE 1588. >>>>>>>=20 >>>>>>> SB> I think that there is a more formal name for the 1588 group >>>>>>> SB> that needs to be used here. >>>>>>> SB> Also do we need to talk about 1588-200? as there is >>>>>>> SB> an update in progress >>>>>>>=20 >>>>>>> NTP: The timing and synchronization protocol defined by IETF RFC-= 1305 >>>>>>> and RFC-5905. >>>>>>>=20 >>>>>>> PTP: The timing and synchronization protocol used by 1588. >>>>>>> SB> need the proper name for 1588 >>>>>>>=20 >>>>>>> Master Clock: The source of 1588 timing to a set of slave clocks.= >>>>>>>=20 >>>>>>> Master Port: A port on a ordinary or boundary clock that is in Ma= ster >>>>>>> state. This is the source of timing toward slave ports. >>>>>>>=20 >>>>>>> SB> I am not sure the reader knows what a port is >>>>>>>=20 >>>>>>> Slave Clock: A receiver of 1588 timing from a master clock. >>>>>>>=20 >>>>>>> Slave Port: A port on a boundary clock or ordinary clock that is >>>>>>> receiving timing from a master clock. >>>>>>>=20 >>>>>>> Ordinary Clock: A device with a single PTP port. >>>>>>>=20 >>>>>>> Transparent Clock. A device that measures the time taken for a P= TP >>>>>>> event message to transit the device and then updates the >>>>>>> correctionField of the message with this transit time. >>>>>>>=20 >>>>>>> Boundary Clock: A device with more than one PTP port. Generally >>>>>>> boundary clocks will have one port in slave state to receive timi= ng >>>>>>> and then other ports in master state to re-distribute the timing.= >>>>>>>=20 >>>>>>> PTP LSP: An LSP dedicated to carry PTP messages >>>>>>>=20 >>>>>>> SB> PTP or timing? >>>>>>>=20 >>>>>>>=20 >>>>>>> PTP PW: A PW within a PTP LSP that is dedicated to carry PTP >>>>>>> messages. >>>>>>>=20 >>>>>>> SB> Ah I don't think that PWE3 know what one of these is >>>>>>>=20 >>>>>>> CW: Pseudowire Control Word >>>>>>>=20 >>>>>>> LAG: Link Aggregation >>>>>>>=20 >>>>>>> ECMP: Equal Cost Multipath >>>>>>>=20 >>>>>>> CF: Correction Field, a field inside certain PTP messages (messag= e >>>>>>> type 0-3)that holds the accumulative transit time inside intermed= iate >>>>>>> switches >>>>>>>=20 >>>>>>> Timing messages: Timing Protocol messages that are exchanged >>>> between >>>>>>> routers in order to establish a synchronized clock. >>>>>>>=20 >>>>>>> SB> A number of these definitions look like copies of IEEE1588 >>>>>>> SB> definitions. We need to provide references and note the >>>>>>> SB> priority of the IEEE base reference. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 7] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 3. Problem Statement >>>>>>>=20 >>>>>>> [IEEE-1588] has defined methods for transporting PTP messages ove= r >>>>>>> Ethernet and IP networks. [RFC5905] has defined the method of >>>>>>> transporting NTP messages over IP networks. There is a need to >>>>>>> transport Timing messages over MPLS networks while supporting the= >>>>>>> Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (O= C) >>>>>>> functionality in the LER and LSRs in the MPLS network. >>>>>>>=20 >>>>>>> There are multiple ways of transporting Timing over MPLS. Howeve= r, >>>>>>> there is a requirement to limit the possible encapsulation option= s to >>>>>>> simplify the Timing message identification and processing require= d at >>>>>>> the port level. >>>>>>>=20 >>>>>>> When Timing-awareness is needed, Timing messages should not be >>>>>>> transported over LSPs or PWs that are carrying customer traffic >>>>>>> because LSRs perform Label switching based on the top label in th= e >>>>>>> stack. >>>>>>>=20 >>>>>>> SB> Have you explained why? >>>>>>>=20 >>>>>>> To detect Timing messages inside such LSPs require special >>>>>>> hardware to do deep packet inspection at line rate. Even if such= >>>>>>> hardware exists, the payload can't be deterministically identifie= d by >>>>>>> LSRs because the payload type is a context of the PW label, and t= he >>>>>>> PW label and its context are only known to the Edge routers (PEs/= >>>>>>> LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, C= ES, >>>>>>> etc). Even if one restricts an LSP to only carry Ethernet PWs, t= he >>>>>>> LSRs dont have the knowledge of whether PW Control Word (CW) is >>>>>>> present or not and therefore can not deterministically identify t= he >>>>>>> payload. >>>>>>>=20 >>>>>>> A generic method is defined in this document that does not requir= e >>>>>>> deep packet inspection at line rate, and can deterministically >>>>>>> identify Timing messages. This method can be used to detect Timi= ng >>>>>>> Messages in both one-step and two-step clock implementations of >>>>>>> ordinary, boundary and transparent clocks. >>>>>>>=20 >>>>>>> SB> Needs a ref and I am sure many MPLS specialists will not underst= and >>>>>>> SB> the msg types. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 8] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 4. Timing over MPLS Architecture >>>>>>>=20 >>>>>>> Timing messages are exchange between Timing ports on ordinary and= >>>>>>>=20 >>>>>>> SB> Have you defined a timing port? >>>>>>>=20 >>>>>>> boundary clocks. Boundary clocks terminate the Timing messages a= nd >>>>>>> act as master for other boundary clocks or for slave clocks. End= -to- >>>>>>> End Transparent clocks do not terminate the Timing messages but t= hey >>>>>>> do modify the contents of the Timing messages as they transit acr= oss >>>>>>> the transparent clock. >>>>>>>=20 >>>>>>> Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent C= lock >>>>>>>=20 >>>>>>> (TC) could be implemented in either LERs or LSRs. >>>>>>>=20 >>>>>>> SB> LER and LSR need to be expanded >>>>>>>=20 >>>>>>> An example is shown in Figure 1, where the LERs act as Ordinary C= lock >>>>>>> (OC) and are the initiating/terminating point for Timing messages= . >>>>>>> The ingress LER encapsulates the Timing messages in Timing LSP an= d >>>>>>> the Egress LER terminates the Timing LSP. The LSRs act as >>>>>>> Transparent Clock (TC) and just update the Timing field in the Ti= ming >>>>>>> messages. >>>>>>>=20 >>>>>>>=20 >>>>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ >>>>>>> |Switch, | | | | | | | |Swit= ch, | >>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rou= ter | >>>>>>> | | | OC | | TC | | OC | | = | >>>>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ >>>>>>> / \ >>>>>>> +-------+ / \ +-----= --+ >>>>>>> | LER | / \ | LER= | >>>>>>> | Master|---/ \---| Slav= e | >>>>>>> | Clock | | Cloc= k | >>>>>>> +-------+ +-----= --+ >>>>>>>=20 >>>>>>> Figure (1) - Deployment example 1 of timing over MPLS network >>>>>>>=20 >>>>>>> Another example is shown in Figure2, where LERs terminate the Tim= ing >>>>>>> messages received from switch/routers that are outside of the MPL= S >>>>>>> network acting as OC or BC. In this example LERs regenerate the >>>>>>> clock and initiate timing messages encapsulated in Timing LSP tow= ard >>>>>>> the MPLS network, while the LSRs act as Transparent Clock (TC) an= d >>>>>>> just update the Timing field in the Timing messages, which are >>>>>>> already encapsulated in Timing LSPs. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 9] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ >>>>>>> |Switch, | | | | | | | |Switc= h, | >>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rout= er | >>>>>>> | OC/BC | | BC | | TC | | BC | | OC/B= C | >>>>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ >>>>>>>=20 >>>>>>> Figure (2) - Deployment example 2 of timing over MPLS network >>>>>>>=20 >>>>>>>=20 >>>>>>> Another example is shown in Figure 3, where LERs do not terminate= the >>>>>>> Timing messages received from switch/routers that are outside of t= he >>>>>>> MPLS network acting as OC, TC or BC. The LERs act as TC and upda= te >>>>>>> the Timing field in the Timing messages as they transit the LER, >>>>>>> while encapsulating them in timing LSP. The LSRs also act as >>>>>>> Transparent Clock (TC) and just update the Timing field in the Ti= ming >>>>>>> messages which are already encapsulated in Timing LSPs. >>>>>>>=20 >>>>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ >>>>>>> |Switch, | | | | | | | |Swit= ch, | >>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rou= ter | >>>>>>> |OC/TC/BC| | TC | | TC | | TC | |OC/T= C/BC| >>>>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ >>>>>>>=20 >>>>>>> Figure (3) - Deployment example 3 of timing over MPLS network >>>>>>>=20 >>>>>>> Another example is shown in Figure 4, where LERs and LSRs support= >>>>>>> Boundary Clocks. A single-hop LSP is created between two adjacen= t >>>>>>> LSRs engaged in BC operation. Other methods such as PTP transpor= t >>>>>>> over Ethernet MAY be used for transporting timing messages if the= >>>>>>> link between the two routers is Ethernet. >>>>>>>=20 >>>>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ >>>>>>> |Switch, | | | | | | | |Switc= h, | >>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rout= er | >>>>>>> | OC/BC | | BC | | BC | | BC | | OC/B= C | >>>>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ >>>>>>>=20 >>>>>>> Figure (4) - Deployment example 3 of timing over MPLS network >>>>>>>=20 >>>>>>> An MPLS domain MAY serve multiple customers. In these cases the >>>> MPLS >>>>>>> domain (maintained by a service provider) may provide timing serv= ices >>>>>>> to multiple customers, each having their own Timing domain. >>>>>>>=20 >>>>>>> The Timing over MPLS architecture assumes full mesh of Timing LSP= s >>>>>>> between all LERs supporting this specification. >>>>>>>=20 >>>>>>> SB> Note sure this is right - the salves surely do not need to >>>>>>> SB> exchange timing amongst themselves >>>>>>>=20 >>>>>>> It supports >>>>>>> Point-to- point (VPWS) and Multipoint (VPLS) services. >>>>>>>=20 >>>>>>> SB> What does that mean? You do not carry user data traffic? >>>>>>> SB> Maybe it's the ordering of the statemnets that is causing >>>>>>> SB> confusion. >>>>>>>=20 >>>>>>> This means >>>>>>> that a customer may purchase a Point-to-point Timing service betw= een >>>>>>> two customer sites or a Multipoint Timing service between more th= an >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 10] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> two customer sites. >>>>>>>=20 >>>>>>> The Timing over MPLS architecture supports P2P or P2MP Timing LSP= s. >>>>>>> This means that the Timing Multicast messages such as PTP Multica= st >>>>>>> event messages can be transported over P2MP Timing LSP or be >>>>>>> replicated and transported over many P2P Timing LSPs. >>>>>>>=20 >>>>>>> SB> Note we do not yet have a definition of a P2MP mpls-tp LSP >>>>>>> SB> nor a P2MP PW, although we are close. >>>>>>>=20 >>>>>>> Timing messages, that do not require Time stamping or Correction >>>>>>> Field update MAY be transported over Timing LSPs to simplify hard= ware >>>>>>> and software. >>>>>>>=20 >>>>>>> PTP Announce messages that determine the Timing LSP terminating >>>> point >>>>>>> behavior such as BC/OC/TC SHOULD be transported over the Timing L= SP >>>>>>> to simplify hardware and software. >>>>>>>=20 >>>>>>> SB> have you defined and referenced PTP announce msgs? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 11] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 5. Dedicated LSPs for Timing messages >>>>>>>=20 >>>>>>> Many methods have been considered for identifying the Timing >>>> messages >>>>>>> when they are encapsulated in MPLS such as using GAL/G-ACH or a n= ew >>>>>>> reserved label. These methods were not attractive since they eit= her >>>>>>> required deep packet inspection at line rate in the intermediate L= SRs >>>>>>> or they required use of a scarce new reserved label. Also one of= the >>>>>>> goals was to reuse existing OAM mechanisms. >>>>>>>=20 >>>>>>> SB> RLs =3D SPLs are not so rare now. In any case needs a ref. >>>>>>>=20 >>>>>>> The method defined in this document can be used by LER and LSRs t= o >>>>>>> identify Timing messages in MPLS tunnels by just looking at the t= op >>>>>>> label in the MPLS label stack, which only carry Timing messages a= s >>>>>>> well as OAM, but not data plane client traffic. >>>>>>>=20 >>>>>>> Compliant implementations MUST use dedicated LSPs to carry Timing= >>>>>>> messages over MPLS. >>>>>>>=20 >>>>>>> SB> I think that we need a definition of the properies of these LSPs= >>>>>>>=20 >>>>>>> These LSPs are herein referred to as "Timing >>>>>>> LSPs" and the labels associated with these LSPs as "Timing LSP >>>>>>> labels". The Timing LSPs that runs between Ingress and Egress LE= Rs >>>>>>> MUST be co-routed. Alternatively, a single bidirectional co-rout= ed >>>>>>> LSP can be used. >>>>>>>=20 >>>>>>> SB> I though that you said you could use M2MP LSPs - these are not >>>>>>> SB> bidirectional. >>>>>>>=20 >>>>>>> Co-routing of the two directions is required to limit the differe= nce >>>>>>> in the delays in the Master clock to Slave clock direction compar= ed >>>>>>> to the Slave clock to Master clock direction. The Timing LSP MAY= be >>>>>>> MPLS/MPLS-TP LSP. >>>>>>>=20 >>>>>>> The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS= . >>>>>>> New Extensions to RSVP-TE/GMPLS TLVs are required; however they a= re >>>>>>> outside the scope of this document. >>>>>>>=20 >>>>>>> The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such= as >>>>>>> BFD and LSP Ping but the LSP data plane client plane traffic MUST= be >>>>>>> Timing packets only. >>>>>>>=20 >>>>>>> SB> Why? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 12] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 6. Timing over LSP Encapsulation >>>>>>>=20 >>>>>>> The encapsulations is not LSP is it? >>>>>>>=20 >>>>>>> This document defines two methods for carrying Timing messages ov= er >>>>>>> MPLS. The first method is carrying UDP/IP encapsulated Timing >>>>>>> messages over Timing LSPs, and the second method, is carrying >>>>>>> Ethernet encapsulated Timing messages over Ethernet PWs inside >>>> Timing >>>>>>> LSPs. >>>>>>>=20 >>>>>>> 6.1. Timing over UDP/IP over MPLS Encapsulation >>>>>>>=20 >>>>>>> The simplest method of transporting Timing messages over MPLS is t= o >>>>>>> encapsulate Timing PDUs in UDP/IP and then encapsulate them in >>>> Timing >>>>>>> LSP. This format is shown in Figure 4. >>>>>>>=20 >>>>>>>=20 >>>>>>> +----------------------+ >>>>>>> | Timing LSP Label | >>>>>>> +----------------------+ >>>>>>> | IPv4/6 | >>>>>>> +----------------------+ >>>>>>> | UDP | >>>>>>> +----------------------+ >>>>>>> | Timing PDU | >>>>>>> +----------------------+ >>>>>>>=20 >>>>>>> Figure (4) - Timing over UDP/IP over MPLS Encapsulation >>>>>>>=20 >>>>>>>=20 >>>>>>> This encapsulation is very simple and is useful when the network >>>>>>> between Timing Master Clock and Slave Clock is MPLS network. >>>>>>>=20 >>>>>>> SB> Simple is a judgement call >>>>>>>=20 >>>>>>> In order for an LER/LSR to process Timing messages, the Timing LS= P >>>>>>> Label must be at the top label of the label stack. The LER/LSR M= UST >>>>>>> know that the Timing LSP Label is used for carrying Timing messag= es. >>>>>>> This can be accomplished via static configuration or via RSVP-TE >>>>>>> signaling. >>>>>>>=20 >>>>>>> The UDP/IP encapsulation of PTP MUST follow Annex D and E of >>>>>>> [IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow >>>>>>> [RFC5905]. >>>>>>>=20 >>>>>>> 6.2. Timing over PW Encapsulation >>>>>>>=20 >>>>>>> Another method of transporting Timing over MPLS networks is by >>>>>>> encapsulating Timing PDUs in PW which in turn is transported over= >>>>>>> Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448]= , >>>>>>> shown in Fig 5(A) MUST be used and the Ethernet encapsulation of P= TP >>>>>>> MUST follow Annex F of [IEEE-1588]. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 13] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> The RAW mode or Tagged mode defined in [RFC4448] MAY be used and >>>> the >>>>>>> Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The >>>>>>> Timing over PW encapsulation MUST use the Control Word (CW) as >>>>>>> specified in [RFC4448] to ensure proper detection of PTP messages= >>>>>>> inside the MPLS packets for Timing over LSP and Timing over PW >>>>>>> encapsulation. >>>>>>>=20 >>>>>>> SB> That needs explanation >>>>>>>=20 >>>>>>> The use of Sequence Number in the CW is optional. >>>>>>>=20 >>>>>>> SB> Given that s/n are never in practice deployed, you could probabl= y >>>>>>> SB> simplify things by sayig that they are not used. >>>>>>>=20 >>>>>>> Timing over PW encapsulation for NTP MUST use NTP over UDP/IP ove= r >>>> PW >>>>>>> (the IP PW discussed in [RFC4447]) shown in Fig 5(B). >>>>>>>=20 >>>>>>> +----------------+ +----------------+ >>>>>>> |Timing LSP Label| |Timing LSP Label| >>>>>>> +----------------+ +----------------+ >>>>>>> | PW Label | | PW Label | >>>>>>> +----------------+ +----------------+ >>>>>>> | Control Word | | IP | >>>>>>> +----------------+ +----------------+ >>>>>>> | Ethernet | | UDP | >>>>>>> | Header | +----------------+ >>>>>>> +----------------+ | Timing PDU | >>>>>>> |S-VLAN(Optional)| | | >>>>>>> +----------------+ +----------------+ >>>>>>> |C-VLAN(Optional)| (B) >>>>>>> +----------------+ >>>>>>> | Timing PDU | >>>>>>> | | >>>>>>> +----------------+ >>>>>>> (A) >>>>>>>=20 >>>>>>> Figure (5) - Timing over PW Encapsulations >>>>>>>=20 >>>>>>> In order for an LSR to process PTP messages, the top label of the= >>>>>>> label stack (the Tunnel Label) MUST be a Timing label. >>>>>>>=20 >>>>>>> S> You said that before. >>>>>>>=20 >>>>>>> 6.3. Other Timing Encapsulation methods >>>>>>>=20 >>>>>>> In future other timing encapsulation methods may be introduced, s= uch >>>>>>> as a new shim header after the Bottom of Stack to carry the Timin= g >>>>>>> information. Such new encapsulations are outside the scope of th= is >>>>>>> document. >>>>>>>=20 >>>>>>>=20 >>>>>>> SB> Taking a pure MPLS pov, you can simplify a lot of the text >>>>>>> SB> out of the definition of the LSP >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 14] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> SB> I think we need a section on LSP processing >>>>>>>=20 >>>>>>> 7. Timing message Processing >>>>>>>=20 >>>>>>> Each Timing protocol such as PTP and NTP, define their set of Tim= ing >>>>>>> messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, >>>>>>> FOLLOW_UP, etc messages. >>>>>>>=20 >>>>>>> Some of the Timing messages require time stamping or correction f= ield >>>>>>> update at port level and some dont. It is the job of the LER/LSR= to >>>>>>> parse the timing message and find out the type of the Timing mess= age >>>>>>> and decide whether and how to Time- stamp it (e.g., BC) or update= >>>>>>> correction field(e.g., TC). >>>>>>>=20 >>>>>>>=20 >>>>>>> SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing >>>>>>> SB> function rather than the LER? >>>>>>>=20 >>>>>>> For example the following PTP messages (called Event messages) >>>>>>> require time-stamping or correction field update: >>>>>>>=20 >>>>>>> o SYNC >>>>>>>=20 >>>>>>> o DELAY_REQ (Delay Request) >>>>>>>=20 >>>>>>> o PDELAY_REQ (Peer Delay Request) >>>>>>>=20 >>>>>>> o PDELAY_RESP (Peer Delay Response) >>>>>>>=20 >>>>>>> SYNC and DELAY_REQ are exchanged between Master Clock and Slave >>>> Clock >>>>>>> and MUST be transported over PTP LSPs. PDELAY_REQ and >>>> PDELAY_RESP >>>>>>> are exchanged between adjacent PTP clocks (i.e. Master, Slave, >>>>>>> Boundary, or Transparent) and SHOULD be transported over single h= op >>>>>>> PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP= , >>>>>>> and PDELAY_RESP_FOLLOW_UP messages MUST also be transported >>>> over >>>>>>> the >>>>>>> PTP LSPs. >>>>>>>=20 >>>>>>> For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be= >>>>>>> transported over two PTP LSPs that are in opposite directions. T= hese >>>>>>> PTP LSPs, which are in opposite directions MUST be congruent and c= o- >>>>>>> routed. Alternatively, a single bidirectional co-routed LSP can b= e >>>>>>> used. >>>>>>>=20 >>>>>>> Except as indicated above for the two-step PTP clocks, Non-Event P= TP >>>>>>> message types do not need to be processed by intermediate routers= . >>>>>>> These message types MAY be carried in PTP Tunnel LSPs. >>>>>>>=20 >>>>>>> SB> Are you saying that a timing P router has to be msg type sensiti= ve? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 15] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 8. Protection and Redundancy >>>>>>>=20 >>>>>>>=20 >>>>>>> SB> This is a bit of a jump - I don't know how the LSP itself works y= et! >>>>>>>=20 >>>>>>> In order to ensure continuous uninterrupted operation of slave >>>>>>> clocks, usually as a general practice, slave clocks (or ports) tr= ack >>>>>>> redundant master clocks. >>>>>>>=20 >>>>>>> It is the responsibility of the network operator to ensure that >>>>>>> physically disjoint Timing LSPs are established between a slave c= lock >>>>>>> (or port) and redundant master clocks (or ports). >>>>>>>=20 >>>>>>> When a slave clock (or port) listens to redundant master clocks o= r >>>>>>> ports, any prolonged Timing LSP outage will trigger the slave clo= ck >>>>>>> or port to switch to a redundant master clock or port. >>>>>>>=20 >>>>>>> LSP/PW protection such as Linear protection Switching (1:1, 1+1),= >>>>>>> Ring protection switching or MPLS Fast Reroute (FRR) generally sw= itch >>>>>>> alternative path that usually cause a change in delay, which if >>>>>>> undetected by slave clock can reduce accuracy of the slave clock.= >>>>>>>=20 >>>>>>> Therefore protection switching MAY be used, as long as phase jump= s >>>>>>> upon switchover due to differences in path latency are detected a= nd >>>>>>> compensated for (such compensation not being required if BCs or p= eer- >>>>>>> peer TCs are used throughout). >>>>>>>=20 >>>>>>> Note that any protection or reroute mechanism that adds additiona= l >>>>>>> MPLS label to the label stack, such as Facility Backup Fast Rerou= te, >>>>>>> MUST ensure that the pushed label is also a Timing Label to ensur= e >>>>>>> recognition of the MPLS frame as containing Timing messages, as i= t >>>>>>> transits the backup path. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 16] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 9. ECMP >>>>>>>=20 >>>>>>> To ensure the optimal operation of slave clocks and avoid error >>>>>>> introduced by forward and reverse path delay asymmetry, the physi= cal >>>>>>> path for Timing messages from master clock to slave Clock and vic= e >>>>>>> versa must be the same for all Event Timing messages listed in >>>>>>> section 7. >>>>>>>=20 >>>>>>> Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost= >>>>>>> Multipath). >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 17] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 10. PHP >>>>>>>=20 >>>>>>> To ensure that the label on the top of the label stack is the Tim= ing >>>>>>> LSP Label, PHP MUST not be used. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 18] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 11. Entropy >>>>>>>=20 >>>>>>> To ensure all Timing messages in a Timing LSP take the same path,= >>>>>>> Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and >>>>>>> Entropy Label MUST NOT be used for the PWs that are carried insid= e >>>>>>> Timing LSP [RFC6391]. >>>>>>>=20 >>>>>>> SB> This is incorrect - you mean that all msgs of the same timing >>>>>>> SB> flow need to have the same EL value. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 19] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 12. OAM, Control and Management >>>>>>>=20 >>>>>>> In order to monitor Timing LSPs and their encapsulated PWs, they M= UST >>>>>>> be able to carry OAM and management messages. These management >>>>>>> messages MUST be differentiated from Timing messages via already >>>>>>> defined IETF methods. >>>>>>>=20 >>>>>>> For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY r= un >>>>>>> over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These >>>>>>> Management protocols can easily be identified by the UDP Destinat= ion >>>>>>> Port number or by GAL/G-ACH respectively. >>>>>>>=20 >>>>>>> Also BFD, LSP-Ping and other management messages MAY run over the= >>>> PWs >>>>>>> encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3= or >>>>>>> 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is g= oing >>>>>>> to be deprecated by IETF). In this case G-ACH, PW label (TTL=3D1= ) or >>>>>>> GAL-ACH are used to identify such management messages. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 20] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 13. QoS Considerations >>>>>>>=20 >>>>>>> In network deployments where not every LSR/LER is Timing-aware, i= t is >>>>>>> important to reduce the impact of the non-Timing-aware LSR/LERs o= n >>>>>>> the timing recovery in the slave clock. The Timing messages are t= ime >>>>>>> critical and must be treated with the highest priority. Therefor= e >>>>>>> Timing over MPLS messages must be treated with the highest priori= ty >>>>>>> in the routers. This can be achieved by proper setup of Timing L= SPs. >>>>>>>=20 >>>>>>> It is recommended that the Timing LSPs are setup or configured >>>>>>> properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC26= 97] >>>>>>> for drop eligibility. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 21] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 14. FCS and Checksum Recalculation >>>>>>>=20 >>>>>>> When time-stamp generation and timing packet adjustment is perfor= med >>>>>>> near the physical port hardware, the process MUST include >>>>>>> recalculation of the Ethernet FCS. >>>>>>>=20 >>>>>>> SB> The above is confusing - an LSR always recomputes the link layer= >>>>>>> SB> CRC which may or may not be Ethernet. >>>>>>>=20 >>>>>>> Also FCS retention for the >>>>>>> payload Ethernet described in [RFC4720] MUST NOT be used. >>>>>>>=20 >>>>>>> For UDP/IP encapsulation mode of Timing over MPLS, the UDP checks= um >>>>>>> may be required as per UDP transport standards. >>>>>>>=20 >>>>>>> SB> You really need to be working on getting the IPv6 C?S computatio= n >>>>>>> SB> removed from PTP msgs. >>>>>>>=20 >>>>>>> When UDP checksum is used, each Timing-aware LER/LSR must either >>>>>>> incrementally update the UDP checksum after Time stamping or >>>>>>> Correction Field update or verify the UDP checksum on reception f= rom >>>>>>> upstream and recalculate the checksum completely on transmission t= o >>>>>>> downstream node after Time stamping or Correction Field update. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 22] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 15. Behavior of LER/LSR >>>>>>>=20 >>>>>>> Timing-capable/aware LERs and LSRs are routers that have one or m= ore >>>>>>>=20 >>>>>>> SB> You mean physical interfaces? >>>>>>>=20 >>>>>>> interfaces that can perform Timing operations (OC/BC/TC) on Timin= g >>>>>>> packets and are configured to do so. Timing-capable/aware LERs a= nd >>>>>>> LSRs can advertise their Timing-capability per-interface via cont= rol >>>>>>> plane such as OSPF or IS-IS. >>>>>>> SB> ISIS and OSPF are routing protocols. >>>>>>>=20 >>>>>>> The Timing-capable/aware LERs can then >>>>>>> signals Timing LSPs via RSVP-TE signaling. Alternatively the Tim= ing >>>>>>> capability of LER and LSRs may be configured in a centralized >>>>>>> controller and the Timing LSP may be setup using manual configura= tion >>>>>>> or other methods such as SDN. >>>>>>>=20 >>>>>>> SB> it can also be configured individually rather then through >>>>>>> SB> a cebtral controllwe >>>>>>>=20 >>>>>>> 15.1. Behavior of Timing-capable/aware LER >>>>>>>=20 >>>>>>> When a Timing-capable/aware LER behaves as a Transparent clock an= d >>>>>>> receives a Timing message from a Timing-capable/aware non-MPLS >>>>>>> interface, the LER updates the Correction Field (CF) and encapsul= ates >>>>>>> and forwards the timing message over previously established Timin= g >>>>>>> LSP. >>>>>>>=20 >>>>>>> SB> You need to call out the details so that people properly >>>>>>> SB> understand the definition of the new LSP. >>>>>>>=20 >>>>>>> Also when a Timing message is received from a Timing-capable/ >>>>>>> aware MPLS interface, LER updates the Correction Filed (CF) and >>>>>>> decapsulates the MPLS encapsulation and forwards the timing messa= ge >>>>>>> to a non-MPLS interface. >>>>>>>=20 >>>>>>> When a Timing-capable/aware LER behaves as a Boundary clock and >>>>>>> receives a Timing message from a Timing-capable/aware non MPLS >>>>>>> interface, the LER Timestamps the Timing packet and sends it to t= he >>>>>>> LERs Boundary clock processing module. Also when a Timing messag= e is >>>>>>> received from a Timing- capable/aware MPLS interface, the LER >>>>>>> Timestamps the Timing packet and sends it to the LERs Boundary cl= ock >>>>>>> processing module. >>>>>>>=20 >>>>>>> When a Timing-capable/aware LER behaves as an Ordinary Clock towa= rd >>>>>>> the MPLS network, and receives a Timing message from a Timing- >>>>>>> capable/aware MPLS interface, the LER Timestamps the Timing packe= t >>>>>>> and sends it to the LERs Ordinary clock processing module. >>>>>>>=20 >>>>>>> 15.2. Behavior of Timing-capable/aware LSR >>>>>>>=20 >>>>>>> When a Timing-capable/aware LSR behaves as a Transparent clock an= d >>>>>>> receives a Timing message from a Timing-capable/aware MPLS >>>> interface, >>>>>>> The LSR updates the Correction Filed (CF) and forwards the timing= >>>>>>> message over another MPLS interface. >>>>>>>=20 >>>>>>> When a Timing-capable/aware LSR behaves as a Boundary clock and >>>>>>> receives a Timing message from a Timing-capable/aware MPLS >>>> interface. >>>>>>> The LSR performs the functions of a Boundary Clock in terminating= the >>>>>>> received Timing message and re-generating a new timing message ov= er >>>>>>> another (or the same) MPLS interface. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 23] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 15.3. Behavior of non-Timing-capable/aware LSR >>>>>>>=20 >>>>>>> It is most beneficial when all LSRs in the path of a Timing LSP b= e >>>>>>> timing-Capable/aware LSRs. This would ensure the highest quality= >>>>>>> time and clock synchronization by Timing Slave Clocks. However, t= his >>>>>>> specification does not mandate that all LSRs in path of a Timing L= SP >>>>>>> be Timing- capable/aware. >>>>>>>=20 >>>>>>> Non-Timing-capable/aware LSRs just switch the packets encapsulate= d in >>>>>>> Timing LSPs and dont perform any Timing operation (TC or BC). >>>>>>> However as explained in QoS section the Timing over MPLS packets >>>> MUST >>>>>>> be still be treated with the highest priority based on their Traf= fic >>>>>>> Class (TC) marking. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 24] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 16. Other considerations >>>>>>>=20 >>>>>>> [IEEE-1588] defines an optional peer-to-peer Transparent clocking= >>>>>>> that requires peer delay measurement between two adjacent Timing-= >>>>>>> capable/ aware routers/switches. Peer delay measurement messages= >>>>>>> need to be time stamped and terminated by the Timing-capable/awar= e >>>>>>> routers/ switches. This means that two adjacent LSRs may be enga= ged >>>>>>> in a peer delay measurement. >>>>>>>=20 >>>>>>> For transporting such peer delay measurement messages a single-ho= p >>>>>>> LSP SHOULD to be created between the two adjacent LSRs engaged in= >>>>>>> peer delay measurement to carry peer delay measurement messages. >>>>>>> Other methods such as PTP transport over Ethernet MAY be used for= >>>>>>> transporting peer delay measurement messages if the link between t= he >>>>>>> two routers is Ethernet. >>>>>>>=20 >>>>>>> In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ w= are >>>>>>> routers/switches MUST maintain a list of all the neighbors it nee= ds >>>>>>> to send a PDelay_Req to, where each neighbor corresponds to a tim= ing >>>>>>> LSP. >>>>>>>=20 >>>>>>> The use of Explicit Null Label (Label=3D 0 or 2) is acceptable as= long >>>>>>> as either the Explicit Null label is the bottom of stack label >>>>>>> (applicable only to UDP/IP encapsulation) or the label below the >>>>>>> Explicit Null label is a PTP label. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 25] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 17. Security Considerations >>>>>>>=20 >>>>>>> MPLS PW security considerations in general are discussed in [RFC3= 985] >>>>>>> and [RFC4447],and those considerations also apply to this documen= t. >>>>>>>=20 >>>>>>> An experimental security protocol is defined in [IEEE-1588].The P= TP >>>>>>> security extension and protocol provides group source authenticat= ion, >>>>>>> message integrity, and replay attack protection for PTP messages.= >>>>>>>=20 >>>>>>> When the MPLS network (provider network) serves multiple customer= s, >>>>>>> it is important to maintain and process each customers clock and >>>>>>> Timing messages separately from other customers to ensure there i= s no >>>>>>> cross- customer effect. For example if an LER BC is synchronized= to >>>>>>> a specific grandmaster, belonging to customer A, then the LER MUS= T >>>>>>> use that BC clock only for customer A to ensure that customer A >>>>>>> cannot attack other customers by manipulating its time. >>>>>>>=20 >>>>>>> Timing messages MAY be encrypted or authenticated, provided that t= he >>>>>>> LERs/LSRs that are Timing capable/aware can authenticate/ decrypt= the >>>>>>> timing messages. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 26] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 18. Acknowledgements >>>>>>>=20 >>>>>>> The authors would like to thank Ron Cohen, Yaakov Stein, Tal Mizr= ahi, >>>>>>> Stefano Ruffini, Peter Meyer, and other members of IETF for revie= wing >>>>>>> and providing feedback on this draft. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 27] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 19. IANA Considerations >>>>>>>=20 >>>>>>> There are no IANA requirements in this specification. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 28] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 20. References >>>>>>>=20 >>>>>>> 20.1. Normative References >>>>>>>=20 >>>>>>> [IEEE-1588] >>>>>>> IEEE 1588-2008, "IEEE Standard for a Precision Clock >>>>>>> Synchronization Protocol for Networked Measurement and= >>>>>>> Control Systems". >>>>>>>=20 >>>>>>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >>>>>>> Requirement Levels", BCP 14, RFC 2119, March 1997. >>>>>>>=20 >>>>>>> [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to= - >>>>>>> Edge (PWE3) Architecture", RFC 3985, March 2005. >>>>>>>=20 >>>>>>> [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discov= ery >>>>>>> Proxies (ND Proxy)", RFC 4389, April 2006. >>>>>>>=20 >>>>>>> [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G= . >>>>>>> Heron, "Pseudowire Setup and Maintenance Using the Lab= el >>>>>>> Distribution Protocol (LDP)", RFC 4447, April 2006. >>>>>>>=20 >>>>>>> [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, >>>>>>> "Encapsulation Methods for Transport of Ethernet over M= PLS >>>>>>> Networks", RFC 4448, April 2006. >>>>>>>=20 >>>>>>> [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire >>>>>>> Emulation Edge-to-Edge (PWE3) Frame Check Sequence >>>>>>> Retention", RFC 4720, November 2006. >>>>>>>=20 >>>>>>> [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circu= it >>>>>>> Connectivity Verification (VCCV): A Control Channel fo= r >>>>>>> Pseudowires", RFC 5085, December 2007. >>>>>>>=20 >>>>>>> [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detect= ion >>>>>>> (BFD)", RFC 5880, June 2010. >>>>>>>=20 >>>>>>> [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow= , >>>>>>> "Bidirectional Forwarding Detection (BFD) for MPLS Lab= el >>>>>>> Switched Paths (LSPs)", RFC 5884, June 2010. >>>>>>>=20 >>>>>>> 20.2. Informative References >>>>>>>=20 >>>>>>> [I-D.ietf-pwe3-fat-pw] >>>>>>> Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Reg= an, >>>>>>> J., and S. Amante, "Flow Aware Transport of Pseudowire= s >>>>>>> over an MPLS Packet Switched Network", >>>>>>> draft-ietf-pwe3-fat-pw-07 (work in progress), July 201= 1. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 29] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermedia= te >>>>>>> system routeing information exchange protocol for use i= n >>>>>>> conjunction with the Protocol for providing the >>>>>>> Connectionless-mode Network Service (ISO 8473)". >>>>>>>=20 >>>>>>> [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP an= d >>>>>>> dual environments", RFC 1195, December 1990. >>>>>>>=20 >>>>>>> [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 199= 8. >>>>>>>=20 >>>>>>> [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color= >>>>>>> Marker", RFC 2697, September 1999. >>>>>>>=20 >>>>>>> [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boud= ec, >>>>>>> J., Courtney, W., Davari, S., Firoiu, V., and D. >>>>>>> Stiliadis, "An Expedited Forwarding PHB (Per-Hop >>>>>>> Behavior)", RFC 3246, March 2002. >>>>>>>=20 >>>>>>> [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Enginee= ring >>>>>>> (TE) Extensions to OSPF Version 2", RFC 3630, >>>>>>> September 2003. >>>>>>>=20 >>>>>>> [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermedia= te >>>>>>> System (IS-IS) Extensions for Traffic Engineering (TE)= ", >>>>>>> RFC 3784, June 2004. >>>>>>>=20 >>>>>>> [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S= . >>>>>>> Shaffer, "Extensions to OSPF for Advertising Optional >>>>>>> Router Capabilities", RFC 4970, July 2007. >>>>>>>=20 >>>>>>> [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate= >>>>>>> System to Intermediate System (IS-IS) Extensions for >>>>>>> Advertising Router Information", RFC 4971, July 2007. >>>>>>>=20 >>>>>>> [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi= >>>>>>> Topology (MT) Routing in Intermediate System to >>>>>>> Intermediate Systems (IS-ISs)", RFC 5120, February 200= 8. >>>>>>>=20 >>>>>>> [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic >>>>>>> Engineering", RFC 5305, October 2008. >>>>>>>=20 >>>>>>> [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, >>>>>>> "Traffic Engineering Extensions to OSPF Version 3", >>>>>>> RFC 5329, September 2008. >>>>>>>=20 >>>>>>> [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSP= F >>>>>>> for IPv6", RFC 5340, July 2008. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 30] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Net= work >>>>>>> Time Protocol Version 4: Protocol and Algorithms >>>>>>> Specification", RFC 5905, June 2010. >>>>>>>=20 >>>>>>> [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Reg= an, >>>>>>> J., and S. Amante, "Flow-Aware Transport of Pseudowire= s >>>>>>> over an MPLS Packet Switched Network", RFC 6391, >>>>>>> November 2011. >>>>>>>=20 >>>>>>> [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., a= nd >>>>>>> L. Yong, "The Use of Entropy Labels in MPLS Forwarding= ", >>>>>>> RFC 6790, November 2012. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 31] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 1. Routing extensions for Timing-aware Routers >>>>>>>=20 >>>>>>> MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] a= nd >>>>>>> IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (= TE) >>>>>>> link information used for constraint-based routing. >>>>>>>=20 >>>>>>> Indeed, it is useful to advertise data plane TE router link >>>>>>> capabilities, such as the capability for a router to be Timing-aw= are. >>>>>>> This capability MUST then be taken into account during path >>>>>>> computation to prefer or even require links that advertise themse= lves >>>>>>> as Timing-aware. In this way the path can ensure the entry and e= xit >>>>>>> points into the LERs and, if desired, the links into the LSRs are= >>>>>>> able to perform port based time-stamping thus minimizing their im= pact >>>>>>> on the performance of the slave clock. >>>>>>>=20 >>>>>>> extensions are required to OSPF and IS-IS in order to advertise >>>>>>> Timing-aware capabilities of a link. Such extensions are outside= the >>>>>>> scope of this document; however such extension SHOULD be able to >>>>>>> signal the following information per Router Link: >>>>>>>=20 >>>>>>> o Capable of processing PTP, NTP or other Timing flows >>>>>>>=20 >>>>>>> o Capable of performing Transparent Clock operation >>>>>>>=20 >>>>>>> o Capable of performing Boundary Clock operation >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 32] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 2. Signaling Extensions for Creating Timing LSPs >>>>>>>=20 >>>>>>> RSVP-TE signaling MAY be used to setup the timing LSPs. When RSV= P-TE >>>>>>> is used to setup Timing LSPs, some information that indicates tha= t >>>>>>> the LSP is carrying Timing flows MUST be included in the new >>>>>>> Extensions to RSVP-TE: >>>>>>>=20 >>>>>>> The following information MAY also be included in the new Extensi= ons >>>>>>> to RSVP-TE: >>>>>>>=20 >>>>>>> o Offset from Bottom of Stack (BoS) to the start of the Time-sta= mp >>>>>>> field >>>>>>>=20 >>>>>>> o Number of VLANs in case of PW encapsulation >>>>>>>=20 >>>>>>> o Timestamp field Type >>>>>>>=20 >>>>>>> * Correction Field, Timestamp >>>>>>>=20 >>>>>>> o Timestamp Field format >>>>>>>=20 >>>>>>> * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit= >>>>>>> NTP, etc. >>>>>>>=20 >>>>>>> Note that in case the above optional information is signaled with= >>>>>>> RSVP-TE for a Timing LSP, all the Timing packets carried in that L= SP >>>>>>> must have the same signaled characteristics. For example if >>>>>>> Timestamp format is signaled as 64-bit PTPv1, then all Timing pac= kets >>>>>>> must use 64-bit PTPv1 time-stamp. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 33] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> Authors' Addresses >>>>>>>=20 >>>>>>> Shahram Davari >>>>>>> Broadcom Corp. >>>>>>> San Jose, CA 95134 >>>>>>> USA >>>>>>>=20 >>>>>>> Email: davari@broadcom.com >>>>>>>=20 >>>>>>>=20 >>>>>>> Amit Oren >>>>>>> Broadcom Corp. >>>>>>> San Jose, CA 95134 >>>>>>> USA >>>>>>>=20 >>>>>>> Email: amito@broadcom.com >>>>>>>=20 >>>>>>>=20 >>>>>>> Manav Bhatia >>>>>>> Alcatel-Lucent >>>>>>> Bangalore, >>>>>>> India >>>>>>>=20 >>>>>>> Email: manav.bhatia@alcatel-lucent.com >>>>>>>=20 >>>>>>>=20 >>>>>>> Peter Roberts >>>>>>> Alcatel-Lucent >>>>>>> Kanata, >>>>>>> Canada >>>>>>>=20 >>>>>>> Email: peter.roberts@alcatel-lucent.com >>>>>>>=20 >>>>>>>=20 >>>>>>> Laurent Montini >>>>>>> Cisco Systems >>>>>>> San Jose CA >>>>>>> USA >>>>>>>=20 >>>>>>> Email: lmontini@cisco.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 34] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> Luca >>>>>>> Cisco Systems >>>>>>> San Jose CA >>>>>>> USA >>>>>>>=20 >>>>>>> Email: lmartini@cisco.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 35] >>>>>>> -- >>>>>>> For corporate legal information go to: >>>>>>>=20 >>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> TICTOC mailing list >>>>>>> TICTOC@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/tictoc >>>>>> 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 >>>>> . >>>>=20 >>>> -- >>>> For corporate legal information go to: >>>>=20 >>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>=20 >>>> _______________________________________________ >>>> TICTOC mailing list >>>> TICTOC@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tictoc >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> TICTOC mailing list >>>> TICTOC@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tictoc >>>=20 >>> This e-mail message is intended for the recipient only and contains info= rmation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. >> . >=20 >=20 > --=20 > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 From sriganesh.kini@ericsson.com Tue Aug 20 09:52:51 2013 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 4856C11E8113 for ; Tue, 20 Aug 2013 09:52: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 yBvfCAuBCf8w for ; Tue, 20 Aug 2013 09:52:44 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 77CD821F8947 for ; Tue, 20 Aug 2013 09:52:44 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-7a-52139edb788d Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id BA.00.09414.BDE93125; Tue, 20 Aug 2013 18:52:43 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Tue, 20 Aug 2013 12:52:43 -0400 From: Sriganesh Kini To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-kini-mpls-entropy-label-src-stacked-tunnels-00.txt Thread-Index: AQHOncWwCJle2cFEb0uOeU7sgi36ng== Date: Tue, 20 Aug 2013 16:52:43 +0000 Message-ID: <95453A37E413464E93B5ABC0F8164C4D02E6F5BF@eusaamb101.ericsson.se> In-Reply-To: <20130819161013.3873.85214.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyuXRPgu7tecJBBhd3WVjcWrqS1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGZNX3WAvOMJT0bzqInsD4z/OLkZODgkBE4n+b3PYIWwxiQv3 1rN1MXJxCAkcZZR4dfQbI4SznFFi3qFJrCBVbAJGEhfuzmcBsUUElCWOTOwGiwsLpEg82/eF GSKeKtG8diU7hK0nseZCG5jNIqAqcX/nDbAaXgFfiUUvesHinAKOEmtOPQSbwwh0xfdTa5hA bGYBcYlbT+YzQVwnILFkz3lmCFtU4uXjf2D1okDz246dgfpAWWLJk/0sEL06Egt2fwL6hgPI tpb4fbIKIqwtsWzha6gTBCVOznzCMoFRbBaSbbOQdM9C6J6FpHsWku4FjKyrGDlKi1PLctON DDYxAuPkmASb7g7GPS8tDzFKc7AoifOu0jsTKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFx 3YONr0R8+bOtr/mIbjN+Nql2+oLqgxqXNqk3H/XknTKpjC958UxhlmNCgdO8tGy8lp6J+vw9 etZ24TN7Jx0K+ND6WqZAoFLJcrqUS3uytfexx7P7FeZm3V9ftyjZYpbxle7z4i1JC5aEnWMp Z6r4xitQWrTQ8pK0jIXq1fAfjG+OuNuwJM1SYinOSDTUYi4qTgQA2OpljGECAAA= Subject: [mpls] FW: New Version Notification for draft-kini-mpls-entropy-label-src-stacked-tunnels-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: Tue, 20 Aug 2013 16:52:51 -0000 We have submitted a draft to highlight some of the issues when using entropy labels in stacked tunnels. - Sri On 8/19/13 9:10 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, >draft-kini-mpls-entropy-label-src-stacked-tunnels-00.txt >has been successfully submitted by Sriganesh Kini and posted to the >IETF repository. > >Filename: draft-kini-mpls-entropy-label-src-stacked-tunnels >Revision: 00 >Title: Entropy labels for source routed stacked tunnels >Creation date: 2013-08-19 >Group: Individual Submission >Number of pages: 6 >URL: =20 >http://www.ietf.org/internet-drafts/draft-kini-mpls-entropy-label-src-stac >ked-tunnels-00.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-kini-mpls-entropy-label-src-stacked- >tunnels >Htmlized: =20 >http://tools.ietf.org/html/draft-kini-mpls-entropy-label-src-stacked-tunne >ls-00 > > >Abstract: > Source routed tunnel stacking is a technique that can be leveraged to > provide a method to steer a packet through a controlled set of > segments. This can be applied to the Multi Protocol Label Switching > (MPLS) data plane. Entropy label (EL) is a technique used in MPLS to > improve load balancing. This document examines how ELs are to be > applied to source routed stacked tunnels. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From Alexander.Vainshtein@ecitele.com Tue Aug 20 09:53:27 2013 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 65E1421F8948; Tue, 20 Aug 2013 09:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 049bivCKOzWW; Tue, 20 Aug 2013 09:53:22 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.169]) by ietfa.amsl.com (Postfix) with ESMTP id 58D2B21F888F; Tue, 20 Aug 2013 09:53:18 -0700 (PDT) Received: from [85.158.137.68:17382] by server-9.bemta-3.messagelabs.com id 06/E1-15303-CFE93125; Tue, 20 Aug 2013 16:53:16 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-11.tower-31.messagelabs.com!1377017593!2818503!1 X-Originating-IP: [147.234.242.234] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23282 invoked from network); 20 Aug 2013 16:53:14 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Aug 2013 16:53:14 -0000 X-AuditID: 93eaf2e7-b7f0e6d000004f79-b0-52139ef49565 Received: from ILPTWPVEXCA02.ecitele.com ( [172.31.244.232]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 58.63.20345.4FE93125; Tue, 20 Aug 2013 19:53:08 +0300 (IDT) Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA02.ecitele.com ([fe80::c473:490d:3a7e:e34a%12]) with mapi id 14.03.0123.003; Tue, 20 Aug 2013 19:53:07 +0300 From: Alexander Vainshtein To: "stbryant@cisco.com" , "S. Davari" Thread-Topic: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls Thread-Index: AQHOkhqJ+XHALQ/MzkWnZzr9BEl1M5mHyTyggBaXBuSAAAM16Q== Date: Tue, 20 Aug 2013 16:53:07 +0000 Message-ID: References: <51FB7543.801@cisco.com> <51FF7068.9080600@cisco.com> <4A6CE49E6084B141B15C0713B8993F281BEC731A@SJEXCHMB12.corp.ad.broadcom.com> , <52139903.8040801@cisco.com> In-Reply-To: <52139903.8040801@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.1] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42KZ/OrTF92f84SDDJpXKFocfN7EaHFr6UpW i7/NPewOzB5Llvxk8pg16zBTAFNUA6NNYl5efkliSapCSmpxsq1SQFFmWWJypZJCZoqtkqGS QkFOYnJqbmpeia1SYkFBal6Kkh2XAgawASrLzFNIzUvOT8nMS7dV8gz217WwMLXUNVSyU1M2 NLbmCsnILFZI1c1NzMxRyE0tLk5MT1UAiiRsYc5YfHUNS8GHdtaKqz8/szYw3rjD3MXIySEh YCKxYdomJghbTOLCvfVsXYxcHEICBxklvsz9BuUcZZRYvnkGWBWbgK3EptV32UBsEYFAia7j b1hBbGaBAonnm18D1XBwCAu4Sxz+4QdR4iHROfU8I0hYRMBJ4sY/LZAwi4CqxMJVV1hBwrwC ARI3l+RBbFrILDHh31Y2kDingKbE+R4ZkHJGoNO+n1rDBLFIXOLWk/lQJwtILNlzHuoVUYmX j/+xQtjyEhc/PICq15FYsPsTG4StLbFs4Wuwel4BQYmTM5+wQNRLShxccYNlAqP4LCQrZiFp n4WkfRaS9gWMLKsYRTNzCkqSctMNDPVSkzNLUnNS9ZLzczcxQhLK8x2Mv+arHGJ0BXp7IrMU d3I+MCHllcQbGxjg5iiJ8y5vCPcXEkgHppvs1NSC1KL4otKc1OJDjEwcnFINjNrrwhWDkyLC rjieSv5v6mWUuzAv79xmrkAJ+wO/HazP/zEMmiRXUm4c3Drn17ojBf+5hAtj8hcefCe1Klxf tK/h5Kwzu7bJpHqdtPuwR/nMtM+8VTeqFIqYnu5YePLyxZeqff/CgiScq35kf9BO79Peznld ch3bmjlP25/f/rX3sCzv8o2Lm5VYijMSDbWYi4oTAeplDWMgAwAA Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] Comments on draft-ietf-tictoc-1588overmpls 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, 20 Aug 2013 16:53:27 -0000 Stewart, Shahram and all, A couple of (hopefully, last) comments: 1. Supporting a "Timing Alert" label at the top of the label stack introduce= s a backward compatibility problem. We differ in our estimate of the importa= nce of this problem, but we all agree that it exists. 2. On the other hand, this problem does not exist if the "Timing Alert" labe= l is inserted at the bottom of the label stack. At the same time, HW that an= alyzes the label stack hopefully could analyze the bottom label (almost) as= easily as it would analyze the top label. Thus we could both provide backwa= rd compatibility (incompatible transit LSRs simply would not notice the "Tim= ing Alert" label") and avoid the need for dedicated "Timing-only" LSPs. In p= articular, all the MPLS OAM tools (including MPLS-TP) would work without any= changes. 3. A "timing shim header" (between the bottom of the label stack and the beg= inning of the timing packet) has been mentioned by Stewart as an already pr= oposed mechanism. IMHO and FWIW its usage would eliminate the need to unders= tand format of the specific timing distribution protocol in the transit LSRs= . It would further solve the problem of secure transport of timing packets= since security mechanisms would be applied to its original encapsulation (o= ver IP or over Ethernet) without involving the transit LSRs. Did I miss something substantial? Regards, and lots of thanks in advance, Sasha ________________________________________ From: Stewart Bryant [stbryant@cisco.com] Sent: Tuesday, August 20, 2013 6:27 PM To: S. Davari Cc: Alexander Vainshtein; Shahram Davari; mpls@ietf.org; tictoc@ietf.org Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls On 06/08/2013 14:35, S. Davari wrote: > Sasha, > > If a router is not 1588 aware we want it to switch the packet with minimum= jitter and delay via high priority queue. Yes, but you can explicitly tunnel across such island of incompatibility Stewart > > > Sending it to CPU creates large jitter and delay since the CPUs are genera= lly busy doing other things. Time stamping or updating CF in the CPU won't h= elp since it does not cover the variable delay that is incurred from the tim= e the packet enters the router to the time the packet gets processed by CPU. > > I wish it was that easy! > > Regards, > Shahram > > > On Aug 6, 2013, at 12:38 AM, Alexander Vainshtein wrote: > >> Shahram, >> I agree with you that the routers that do not recognize a Timing Alert la= bel would send the packet to the CPU. (This would be easy to arrange since w= e are speaking about a reserved label.) >> >> I do not, however, see this as a serious issue, because the SW running on= this CPU would (hopefully) be upgradable to handle the packet correctly i.e= ., to forward it to where it should be forwarded and, if it is forwarded as= a labeled packet, to prepend the Timing Alert Label on top of its label sta= ck. It could even record the residence time (as observed by the CPU in the p= roper place in the packet. This would mean that introducing additional error= to whatever timing information is associated with this packet - but this is= what you should anyway expect if there are non-compliant routers on your pa= th, right? >> >> Regards, >> Sasha >> >>> -----Original Message----- >>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf= Of >>> Shahram Davari >>> Sent: Monday, August 05, 2013 11:29 PM >>> To: stbryant@cisco.com; S. Davari >>> Cc: mpls@ietf.org; tictoc@ietf.org >>> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls >>> >>> Hi Stewart, >>> >>> Your suggestion of " I suggested an LSP type that has the properties "ti= mestamp >>> and pass to application", is a subset of the existing draft and should w= ork. It >>> basically limits the time stamping and correction field update to LERs (= while the >>> draft supports time stamping at LER and LSR). >>> >>> However Sasha's suggestion of using a reserved label (RAL, GAL or any ot= her >>> reserved label) does not satisfy one of the major requirements, which is >>> backward compatibility. Routers that don't understand this reserved labe= l will >>> drop or copy to CPU such packets. >>> >>> Regards, >>> Shahram >>> >>> -----Original Message----- >>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf= Of >>> Stewart Bryant >>> Sent: Monday, August 05, 2013 2:29 AM >>> To: S. Davari >>> Cc: mpls@ietf.org; tictoc@ietf.org >>> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls >>> >>> My concern is that we are creating a new LSP type in MPLS >>> (which is a architectural change and thus needs to be very carefully >>> considered) without asking the question "how can I do this >>> in the most general way, to maximize flexibility/reuse" >>> >>> I suggested an LSP type that has the properties "timestamp >>> and pass to application", but I think that Sasha raises a good >>> point about using router alert. However RA has no implicit >>> timestamp, so maybe we need a new type of RA that has the >>> properties "timestamp, and pass top application indicated by >>> the next label". That would be quite useful in a number >>> of OAM applications. There is possibly some GAL variant >>> of that design that should also be considered. >>> >>> The application could worry about the path and where it >>> was necessary to skip some hops a hierarchical LSP would >>> accomplish that, with the specific benefit that the application >>> would consciously do this, and may be able to apply some >>> form of compensation within the network. >>> >>> - Stewart >>> >>> On 04/08/2013 10:40, S. Davari wrote: >>>> Hi Sasha >>>> >>>> Perhaps you have not understood the draft well. The main reason that th= e >>> draft chose to use a dedicated LSP that is signaled via RSVPTE indicatin= g it is a >>> timing LSP is to be backward compatible with non-1588 nodes. Such nodes >>> simply just switch the packet. >>>> Your proposal had been considered and was rejected since it was not >>> backward compatible. Nodes receiving alert label or TTL =3D 1 send the p= acket to >>> CPU. You can refer to the meeting notes. >>>> Regards, >>>> Shahram >>>> >>>> >>>> On Aug 4, 2013, at 1:21 AM, Alexander Vainshtein >>> wrote: >>>>> Stewart and all, >>>>> I concur with Stewart's statement that the draft does not define "full >>> interaction with MPLS architecture". >>>>> E.g., one of the objectives of the draft is to provide a technique tha= t would >>> be backward-compatible with old LSRs that cannot provide on-path support= for >>> timing distribution, while the other objective is to make every LSR on t= he path >>> aware that some MPLS packets are carrying timing-related messages and he= nce >>> require on-path support. >>>>> IMHO and FWIW, the MPLS data plane architecture allows just two method= s >>> for making a transit LSR to provide special processing to a labeled pack= et: >>>>> - It would carry some kind of an "alert label" on top of the label sta= ck and, >>> specifically, on top of any labels used for actual forwarding >>>>> OR, >>>>> - The TTL in the top label stack entry has been set to 1. >>>>> >>>>> >>>>> The draft does not follow any of these approaches. >>>>> >>>>> I must also admit that Section 12 "OAM, Control and Management" of the >>> draft looks somewhat in >>>>> E.g., I could not understand from the text whether BFD, LSP-Ping etc.= OAM >>> messages would be subjected to on-path support procedures for timing >>> messages or not. >>>>> My 2c, >>>>> Sasha >>>>> >>>>>> -----Original Message----- >>>>>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Beh= alf >>> Of >>>>>> Stewart Bryant >>>>>> Sent: Friday, August 02, 2013 12:01 PM >>>>>> To: mpls-chairs@tools.ietf.org; tictoc-chairs@tools.ietf.org; int- >>>>>> ads@tools.ietf.org; rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.or= g; >>> draft- >>>>>> ietf-tictoc-1588overmpls@tools.ietf.org >>>>>> Cc: mpls@ietf.org; tictoc@ietf.org >>>>>> Subject: [TICTOC] Comments on draft-ietf-tictoc-1588overmpls >>>>>> >>>>>> SB> This draft does not seem to provide a precise definition >>>>>> SB> the properties of the new LSP type that it wishes to >>>>>> SB> define, in particular it does it define the PHB of those >>>>>> SB> LSPs, nor the full interaction with the MPLS >>>>>> SB> architecture. >>>>>> SB> >>>>>> SB> I have not tracked TICTOC for a while but I thought that >>>>>> SB> the original plan was to define the concept of an offset >>>>>> SB> into a packet to do the correction. >>>>>> SB> >>>>>> SB> It is disappointing that the opportunity was not taken >>>>>> SB> to define a timing shim inside the timing LSP so that >>>>>> SB> a time correction could be added to any packet such that >>>>>> SB> the MPLS system was isolated from the details of the >>>>>> SB> complexity of the particular time transfer type. >>>>>> >>>>>> SB> I think that much more clarify is needed in terms of >>>>>> SB> definition of the new LSP type, since it is unclear >>>>>> SB> from this text how to implement one. >>>>>> SB> >>>>>> SB> There are a lot of other MPLS services such as >>>>>> SB> LSP ping that need to be considered. >>>>>> SB> >>>>>> SB> Please see inline for more comments. However these >>>>>> SB> comments are made in the context of the text as written >>>>>> SB> whilst I have a fundamental concern that this approach >>>>>> SB> lacks an MPLS architectural soundness that need >>>>>> SB> greater thought with significant impact on the >>>>>> SB> draft. >>>>>> >>>>>> - Stewart >>>>>> >>>>>> >>>>>> TICTOC Working Group S. Dav= ari >>>>>> Internet-Draft A. O= ren >>>>>> Intended status: Standards Track Broadcom Co= rp. >>>>>> Expires: December 17, 2013 M. Bha= tia >>>>>> P. Rob= erts >>>>>> Alcatel-Lu= cent >>>>>> L. Mon= tini >>>>>> L. Mar= tini >>>>>> Cisco Sys= tems >>>>>> June 15,= 2013 >>>>>> >>>>>> >>>>>> Transporting Timing messages over MPLS Networks >>>>>> draft-ietf-tictoc-1588overmpls-05 >>>>>> >>>>>> Abstract >>>>>> >>>>>> This document defines the method for transporting Timing messages >>>>>> such as PTP and NTP over an MPLS network. The method allows for= the >>>>>> easy identification of these PDUs at the port level to allow for= port >>>>>> >>>>>> SB> What is a port >>>>>> >>>>>> level processing of these PDUs in both LERs and LSRs. >>>>>> >>>>>> The basic idea is to transport Timing messages inside dedicated M= PLS >>>>>> LSPs. These LSPs only carry Timing messages and possibly Control= and >>>>>> Management packets, but they do not carry customer traffic. >>>>>> >>>>>> SB> More specifically they only carry traffic associated with the >>>>>> SB> timing service and its support. >>>>>> SB> The question arose WRT BFD - surely BFD is allowed, BUT surely >>>>>> SB> also it gets carried in a structure that causes it to get >>>>>> SB> timestamped. >>>>>> >>>>>> Two methods for transporting Timing messages over MPLS are define= d. >>>>>> >>>>>> SB> Perhaps the right approach is to define the new LSP type and then >>>>>> SB> seperately to define the mapping of the various timing services >>>>>> SB> over that LSP type. >>>>>> >>>>>> The first method is to transport Timing messages directly over th= e >>>>>> dedicated MPLS LSP via UDP/IP encapsulation, which is suitable fo= r >>>>>> MPLS networks. The second method is to transport Timing messages >>>>>> inside a PW via Ethernet encapsulation. >>>>>> >>>>>> SB> I think that we should note that there are some >>>>>> SB> h/w reasons for this preference. A clean sheet approach >>>>>> SB> would have been to use PTP over MPLS with no intermediate >>>>>> SB> layers. >>>>>> >>>>>> Status of this Memo >>>>>> >>>>>> This Internet-Draft is submitted in full conformance with the >>>>>> provisions of BCP 78 and BCP 79. >>>>>> >>>>>> Internet-Drafts are working documents of the Internet Engineering >>>>>> Task Force (IETF). Note that other groups may also distribute >>>>>> working documents as Internet-Drafts. The list of current Intern= et- >>>>>> Drafts is at http://datatracker.ietf.org/drafts/current/. >>>>>> >>>>>> Internet-Drafts are draft documents valid for a maximum of six mo= nths >>>>>> and may be updated, replaced, or obsoleted by other documents at= any >>>>>> time. It is inappropriate to use Internet-Drafts as reference >>>>>> material or to cite them other than as "work in progress." >>>>>> >>>>>> This Internet-Draft will expire on December 17, 2013. >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 1] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> Copyright Notice >>>>>> >>>>>> Copyright (c) 2013 IETF Trust and the persons identified as the >>>>>> document authors. All rights reserved. >>>>>> >>>>>> This document is subject to BCP 78 and the IETF Trust's Legal >>>>>> Provisions Relating to IETF Documents >>>>>> (http://trustee.ietf.org/license-info) in effect on the date of >>>>>> publication of this document. Please review these documents >>>>>> carefully, as they describe your rights and restrictions with res= pect >>>>>> to this document. Code Components extracted from this document m= ust >>>>>> include Simplified BSD License text as described in Section 4.e o= f >>>>>> the Trust Legal Provisions and are provided without warranty as >>>>>> described in the Simplified BSD License. >>>>>> >>>>>> >>>>>> Table of Contents >>>>>> >>>>>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .= . 5 >>>>>> >>>>>> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . .= . 7 >>>>>> >>>>>> 3. Problem Statement . . . . . . . . . . . . . . . . . . . . .= . 8 >>>>>> >>>>>> 4. Timing over MPLS Architecture . . . . . . . . . . . . . . .= . 9 >>>>>> >>>>>> 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . .= . 12 >>>>>> >>>>>> 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . .= . 13 >>>>>> 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . .= . 13 >>>>>> 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . .= . 13 >>>>>> 6.3. Other Timing Encapsulation methods . . . . . . . . . . .= . 14 >>>>>> >>>>>> 7. Timing message Processing . . . . . . . . . . . . . . . . .= . 15 >>>>>> >>>>>> 8. Protection and Redundancy . . . . . . . . . . . . . . . . .= . 16 >>>>>> >>>>>> 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . .= . 17 >>>>>> >>>>>> 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . .= . 18 >>>>>> >>>>>> 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . .= . 19 >>>>>> >>>>>> 12. OAM, Control and Management . . . . . . . . . . . . . . . .= . 20 >>>>>> >>>>>> 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . .= . 21 >>>>>> >>>>>> 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . .= . 22 >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 2] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . .= . 23 >>>>>> 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . .= . 23 >>>>>> 15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . .= . 23 >>>>>> 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . .= . 24 >>>>>> >>>>>> 16. Other considerations . . . . . . . . . . . . . . . . . . . .= . 25 >>>>>> >>>>>> 17. Security Considerations . . . . . . . . . . . . . . . . . .= . 26 >>>>>> >>>>>> 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .= . 27 >>>>>> >>>>>> 19. IANA Considerations . . . . . . . . . . . . . . . . . . . .= . 28 >>>>>> >>>>>> 20. References . . . . . . . . . . . . . . . . . . . . . . . . .= . 29 >>>>>> 20.1. Normative References . . . . . . . . . . . . . . . . . .= . 29 >>>>>> 20.2. Informative References . . . . . . . . . . . . . . . . .= . 29 >>>>>> >>>>>> Appendix 1. Routing extensions for Timing-aware Routers . . . .= . 32 >>>>>> >>>>>> Appendix 2. Signaling Extensions for Creating Timing LSPs . . .= . 33 >>>>>> >>>>>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .= . 34 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 3] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >>> NOT", >>>>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" >>> in >>>>>> this >>>>>> document are to be interpreted as described in RFC2119 [RFC2119]. >>>>>> >>>>>> When used in lower case, these words convey their typical use in >>>>>> common language, and are not to be interpreted as described in >>>>>> RFC2119 [RFC2119]. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 4] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 1. Introduction >>>>>> >>>>>> The objective of Precision Time Protocol (PTP) and Network Timing >>>>>> Protocol (NTP) are to synchronize independent clocks running on >>>>>> separate nodes of a distributed system. >>>>>> >>>>>> [IEEE-1588] defines PTP messages for frequency, phase and time >>>>>> synchronization. The PTP messages include PTP PDUs over UDP/IP >>>>>> (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex= F of >>>>>> [IEEE-1588]). >>>>>> >>>>>> SB> Sure BUT it is acknowledged that IEEE is open to the definition >>>>>> SB> of other PTP mappings if they provide better optimisation. >>>>>> >>>>>> This document defines mapping and transport of the PTP >>>>>> messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP >>>>>> defines several clock types: ordinary clocks, boundary clocks, en= d- >>>>>> to-end transparent clocks, and peer-to-peer transparent clocks. >>>>>> Transparent clocks require intermediate nodes to update correctio= n >>>>>> field inside PTP message that reflects the transit time in the no= de. >>>>>> >>>>>> [RFC5905] defines NTP messages for clock and time synchronization= . >>>>>> The PTP messages (PDUs) are transported over UDP/IP. This docume= nt >>>>>> SB> Should that be NTP messages? >>>>>> SB> It needs to be made clear as soon as you introduce NTP that >>>>>> SB> they use different time representations. >>>>>> >>>>>> defines mapping and transport of the NTP messages defined in >>>>>> [RFC5905] over MPLS networks. >>>>>> >>>>>> One key attribute of all of these Timing messages is that the Tim= e >>>>>> stamp processing should occur as close as possible to the actual >>>>>> transmission and reception at the physical port interface. This >>>>>> targets optimal time and/or frequency recovery by avoiding variab= le >>>>>> delay introduced by queues internal to the clocks. >>>>>> >>>>>> SB> As I recall NTP has no epoch point defined, and I am not sure >>>>>> SB> where that point is in the case of PTP in this mapping >>>>>> SB> Hopefully this will get defined in due course. >>>>>> >>>>>> To facilitate the fast and efficient recognition of Timing messag= es >>>>>> at the port level when the Timing messages are carried over MPLS >>>>>> LSPs, >>>>>> >>>>>> SB> Over a new LSP type with time optimied characteristics >>>>>> >>>>>> this document defines the specific encapsulations that should >>>>>> be used. >>>>>> SB> Hopefully it will also define the PHP >>>>>> >>>>>> In addition, it can be expected that there will exist LSR/ >>>>>> LERs where only a subset of the physical ports will have the port= - >>>>>> based Timing message processing capabilities. >>>>>> SB> Do you need to clarify that this only works at base and not in >>>>>> SB> a label heirarchy. >>>>>> >>>>>> >>>>>> In order to ensure >>>>>> that the LSPs carrying Timing packets always enter and exit ports >>>>>> with this capability, routing extensions are defined to advertise >>>>>> this capability on a port basis and to allow for the establishmen= t of >>>>>> LSPs that only transit such ports. While this path establishment >>>>>> restriction may be applied only at the LER Ingress and/or egress >>>>>> ports, it becomes more important when using transparent clock cap= able >>>>>> LSRs in the path. >>>>>> SB> I do not understand the implications of the last >>>>>> SB> sentences - starting ", it becomes" >>>>>> >>>>>> >>>>>> Port based Timing message processing involves Timing message >>>>>> recognition. Once the Timing messages are recognized they can be >>>>>> modified based on the reception or transmission Time-stamp. >>>>>> >>>>>> This document provides two methods for transporting Timing messag= es >>>>>> over MPLS. One is applicable to MPLS environment and the other o= ne >>>>>> is applicable to MPLS/MPLS-TP environment >>>>>> >>>>>> SB> I think the sentence is incomplete. >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 5] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> The solution involves transporting Timing messages over dedicated >>>>>> LSPs called Timing LSPs. These LSPs carry Timing messages and MA= Y >>>>>> carry Management and control messages, but not data plane client >>>>>> traffic. >>>>>> >>>>>> SB> It is not clear why this restriction applies. >>>>>> >>>>>> Timing LSPs can be established statically or via signaling. >>>>>> SB> s/statically/by provisioning/network management/ >>>>>> >>>>>> Extensions to control plane (OSPF, ISIS, etc.) is required to ena= ble >>>>>> routers to distribute their Timing processing capabilities over M= PLS >>>>>> to other routers. However such extensions are outside the scope= of >>>>>> this document. >>>>>> >>>>>> When signaling is used to setup the PTP LSP, Extensions to signal= ing >>>>>> SB> is it a PTP LSP or a Timing LSP? >>>>>> >>>>>> protocols (e.g., RSVP-TE) are required for establishing PTP LSPs. >>>>>> However such extensions are outside the scope of this document. >>>>>> >>>>>> SB> for mpls-tp GMPLS is the signalling protocol >>>>>> >>>>>> While the techniques included herein allow for the establishment= of >>>>>> paths optimized to include Time-stamping capable links, the >>>>>> performance of the Slave clocks is outside the scope of this >>>>>> document. >>>>>> >>>>>> At the time of publishing this specification, Transparent Clockin= g >>>>>> (TC) is only defined for PTP. Therefore at this time any part of >>>>>> this specification that talks about Transparent Clocking applies= only >>>>>> to PTP. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 6] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 2. Terminology >>>>>> >>>>>> 1588: The timing and synchronization as defined by IEEE 1588. >>>>>> >>>>>> SB> I think that there is a more formal name for the 1588 group >>>>>> SB> that needs to be used here. >>>>>> SB> Also do we need to talk about 1588-200? as there is >>>>>> SB> an update in progress >>>>>> >>>>>> NTP: The timing and synchronization protocol defined by IETF RFC-= 1305 >>>>>> and RFC-5905. >>>>>> >>>>>> PTP: The timing and synchronization protocol used by 1588. >>>>>> SB> need the proper name for 1588 >>>>>> >>>>>> Master Clock: The source of 1588 timing to a set of slave clocks. >>>>>> >>>>>> Master Port: A port on a ordinary or boundary clock that is in Ma= ster >>>>>> state. This is the source of timing toward slave ports. >>>>>> >>>>>> SB> I am not sure the reader knows what a port is >>>>>> >>>>>> Slave Clock: A receiver of 1588 timing from a master clock. >>>>>> >>>>>> Slave Port: A port on a boundary clock or ordinary clock that is >>>>>> receiving timing from a master clock. >>>>>> >>>>>> Ordinary Clock: A device with a single PTP port. >>>>>> >>>>>> Transparent Clock. A device that measures the time taken for a P= TP >>>>>> event message to transit the device and then updates the >>>>>> correctionField of the message with this transit time. >>>>>> >>>>>> Boundary Clock: A device with more than one PTP port. Generally >>>>>> boundary clocks will have one port in slave state to receive timi= ng >>>>>> and then other ports in master state to re-distribute the timing. >>>>>> >>>>>> PTP LSP: An LSP dedicated to carry PTP messages >>>>>> >>>>>> SB> PTP or timing? >>>>>> >>>>>> >>>>>> PTP PW: A PW within a PTP LSP that is dedicated to carry PTP >>>>>> messages. >>>>>> >>>>>> SB> Ah I don't think that PWE3 know what one of these is >>>>>> >>>>>> CW: Pseudowire Control Word >>>>>> >>>>>> LAG: Link Aggregation >>>>>> >>>>>> ECMP: Equal Cost Multipath >>>>>> >>>>>> CF: Correction Field, a field inside certain PTP messages (messag= e >>>>>> type 0-3)that holds the accumulative transit time inside intermed= iate >>>>>> switches >>>>>> >>>>>> Timing messages: Timing Protocol messages that are exchanged >>> between >>>>>> routers in order to establish a synchronized clock. >>>>>> >>>>>> SB> A number of these definitions look like copies of IEEE1588 >>>>>> SB> definitions. We need to provide references and note the >>>>>> SB> priority of the IEEE base reference. >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 7] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 3. Problem Statement >>>>>> >>>>>> [IEEE-1588] has defined methods for transporting PTP messages ove= r >>>>>> Ethernet and IP networks. [RFC5905] has defined the method of >>>>>> transporting NTP messages over IP networks. There is a need to >>>>>> transport Timing messages over MPLS networks while supporting the >>>>>> Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (O= C) >>>>>> functionality in the LER and LSRs in the MPLS network. >>>>>> >>>>>> There are multiple ways of transporting Timing over MPLS. Howeve= r, >>>>>> there is a requirement to limit the possible encapsulation option= s to >>>>>> simplify the Timing message identification and processing require= d at >>>>>> the port level. >>>>>> >>>>>> When Timing-awareness is needed, Timing messages should not be >>>>>> transported over LSPs or PWs that are carrying customer traffic >>>>>> because LSRs perform Label switching based on the top label in th= e >>>>>> stack. >>>>>> >>>>>> SB> Have you explained why? >>>>>> >>>>>> To detect Timing messages inside such LSPs require special >>>>>> hardware to do deep packet inspection at line rate. Even if such >>>>>> hardware exists, the payload can't be deterministically identifie= d by >>>>>> LSRs because the payload type is a context of the PW label, and t= he >>>>>> PW label and its context are only known to the Edge routers (PEs/ >>>>>> LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, C= ES, >>>>>> etc). Even if one restricts an LSP to only carry Ethernet PWs, t= he >>>>>> LSRs dont have the knowledge of whether PW Control Word (CW) is >>>>>> present or not and therefore can not deterministically identify t= he >>>>>> payload. >>>>>> >>>>>> A generic method is defined in this document that does not requir= e >>>>>> deep packet inspection at line rate, and can deterministically >>>>>> identify Timing messages. This method can be used to detect Timi= ng >>>>>> Messages in both one-step and two-step clock implementations of >>>>>> ordinary, boundary and transparent clocks. >>>>>> >>>>>> SB> Needs a ref and I am sure many MPLS specialists will not understa= nd >>>>>> SB> the msg types. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 8] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 4. Timing over MPLS Architecture >>>>>> >>>>>> Timing messages are exchange between Timing ports on ordinary and >>>>>> >>>>>> SB> Have you defined a timing port? >>>>>> >>>>>> boundary clocks. Boundary clocks terminate the Timing messages a= nd >>>>>> act as master for other boundary clocks or for slave clocks. End= -to- >>>>>> End Transparent clocks do not terminate the Timing messages but t= hey >>>>>> do modify the contents of the Timing messages as they transit acr= oss >>>>>> the transparent clock. >>>>>> >>>>>> Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent C= lock >>>>>> >>>>>> (TC) could be implemented in either LERs or LSRs. >>>>>> >>>>>> SB> LER and LSR need to be expanded >>>>>> >>>>>> An example is shown in Figure 1, where the LERs act as Ordinary C= lock >>>>>> (OC) and are the initiating/terminating point for Timing messages= . >>>>>> The ingress LER encapsulates the Timing messages in Timing LSP an= d >>>>>> the Egress LER terminates the Timing LSP. The LSRs act as >>>>>> Transparent Clock (TC) and just update the Timing field in the Ti= ming >>>>>> messages. >>>>>> >>>>>> >>>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ >>>>>> |Switch, | | | | | | | |Swit= ch, | >>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rou= ter | >>>>>> | | | OC | | TC | | OC | | = | >>>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ >>>>>> / \ >>>>>> +-------+ / \ +-----= --+ >>>>>> | LER | / \ | LER= | >>>>>> | Master|---/ \---| Slav= e | >>>>>> | Clock | | Cloc= k | >>>>>> +-------+ +-----= --+ >>>>>> >>>>>> Figure (1) - Deployment example 1 of timing over MPLS network >>>>>> >>>>>> Another example is shown in Figure2, where LERs terminate the Tim= ing >>>>>> messages received from switch/routers that are outside of the MPL= S >>>>>> network acting as OC or BC. In this example LERs regenerate the >>>>>> clock and initiate timing messages encapsulated in Timing LSP tow= ard >>>>>> the MPLS network, while the LSRs act as Transparent Clock (TC) an= d >>>>>> just update the Timing field in the Timing messages, which are >>>>>> already encapsulated in Timing LSPs. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 9] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ >>>>>> |Switch, | | | | | | | |Switc= h, | >>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rout= er | >>>>>> | OC/BC | | BC | | TC | | BC | | OC/B= C | >>>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ >>>>>> >>>>>> Figure (2) - Deployment example 2 of timing over MPLS network >>>>>> >>>>>> >>>>>> Another example is shown in Figure 3, where LERs do not terminate= the >>>>>> Timing messages received from switch/routers that are outside of= the >>>>>> MPLS network acting as OC, TC or BC. The LERs act as TC and upda= te >>>>>> the Timing field in the Timing messages as they transit the LER, >>>>>> while encapsulating them in timing LSP. The LSRs also act as >>>>>> Transparent Clock (TC) and just update the Timing field in the Ti= ming >>>>>> messages which are already encapsulated in Timing LSPs. >>>>>> >>>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ >>>>>> |Switch, | | | | | | | |Swit= ch, | >>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rou= ter | >>>>>> |OC/TC/BC| | TC | | TC | | TC | |OC/T= C/BC| >>>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ >>>>>> >>>>>> Figure (3) - Deployment example 3 of timing over MPLS network >>>>>> >>>>>> Another example is shown in Figure 4, where LERs and LSRs support >>>>>> Boundary Clocks. A single-hop LSP is created between two adjacen= t >>>>>> LSRs engaged in BC operation. Other methods such as PTP transpor= t >>>>>> over Ethernet MAY be used for transporting timing messages if the >>>>>> link between the two routers is Ethernet. >>>>>> >>>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ >>>>>> |Switch, | | | | | | | |Switc= h, | >>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rout= er | >>>>>> | OC/BC | | BC | | BC | | BC | | OC/B= C | >>>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ >>>>>> >>>>>> Figure (4) - Deployment example 3 of timing over MPLS network >>>>>> >>>>>> An MPLS domain MAY serve multiple customers. In these cases the >>> MPLS >>>>>> domain (maintained by a service provider) may provide timing serv= ices >>>>>> to multiple customers, each having their own Timing domain. >>>>>> >>>>>> The Timing over MPLS architecture assumes full mesh of Timing LSP= s >>>>>> between all LERs supporting this specification. >>>>>> >>>>>> SB> Note sure this is right - the salves surely do not need to >>>>>> SB> exchange timing amongst themselves >>>>>> >>>>>> It supports >>>>>> Point-to- point (VPWS) and Multipoint (VPLS) services. >>>>>> >>>>>> SB> What does that mean? You do not carry user data traffic? >>>>>> SB> Maybe it's the ordering of the statemnets that is causing >>>>>> SB> confusion. >>>>>> >>>>>> This means >>>>>> that a customer may purchase a Point-to-point Timing service betw= een >>>>>> two customer sites or a Multipoint Timing service between more th= an >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 10] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> two customer sites. >>>>>> >>>>>> The Timing over MPLS architecture supports P2P or P2MP Timing LSP= s. >>>>>> This means that the Timing Multicast messages such as PTP Multica= st >>>>>> event messages can be transported over P2MP Timing LSP or be >>>>>> replicated and transported over many P2P Timing LSPs. >>>>>> >>>>>> SB> Note we do not yet have a definition of a P2MP mpls-tp LSP >>>>>> SB> nor a P2MP PW, although we are close. >>>>>> >>>>>> Timing messages, that do not require Time stamping or Correction >>>>>> Field update MAY be transported over Timing LSPs to simplify hard= ware >>>>>> and software. >>>>>> >>>>>> PTP Announce messages that determine the Timing LSP terminating >>> point >>>>>> behavior such as BC/OC/TC SHOULD be transported over the Timing L= SP >>>>>> to simplify hardware and software. >>>>>> >>>>>> SB> have you defined and referenced PTP announce msgs? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 11] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 5. Dedicated LSPs for Timing messages >>>>>> >>>>>> Many methods have been considered for identifying the Timing >>> messages >>>>>> when they are encapsulated in MPLS such as using GAL/G-ACH or a n= ew >>>>>> reserved label. These methods were not attractive since they eit= her >>>>>> required deep packet inspection at line rate in the intermediate= LSRs >>>>>> or they required use of a scarce new reserved label. Also one of= the >>>>>> goals was to reuse existing OAM mechanisms. >>>>>> >>>>>> SB> RLs =3D SPLs are not so rare now. In any case needs a ref. >>>>>> >>>>>> The method defined in this document can be used by LER and LSRs t= o >>>>>> identify Timing messages in MPLS tunnels by just looking at the t= op >>>>>> label in the MPLS label stack, which only carry Timing messages a= s >>>>>> well as OAM, but not data plane client traffic. >>>>>> >>>>>> Compliant implementations MUST use dedicated LSPs to carry Timing >>>>>> messages over MPLS. >>>>>> >>>>>> SB> I think that we need a definition of the properies of these LSPs >>>>>> >>>>>> These LSPs are herein referred to as "Timing >>>>>> LSPs" and the labels associated with these LSPs as "Timing LSP >>>>>> labels". The Timing LSPs that runs between Ingress and Egress LE= Rs >>>>>> MUST be co-routed. Alternatively, a single bidirectional co-rout= ed >>>>>> LSP can be used. >>>>>> >>>>>> SB> I though that you said you could use M2MP LSPs - these are not >>>>>> SB> bidirectional. >>>>>> >>>>>> Co-routing of the two directions is required to limit the differe= nce >>>>>> in the delays in the Master clock to Slave clock direction compar= ed >>>>>> to the Slave clock to Master clock direction. The Timing LSP MAY= be >>>>>> MPLS/MPLS-TP LSP. >>>>>> >>>>>> The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS= . >>>>>> New Extensions to RSVP-TE/GMPLS TLVs are required; however they a= re >>>>>> outside the scope of this document. >>>>>> >>>>>> The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such= as >>>>>> BFD and LSP Ping but the LSP data plane client plane traffic MUST= be >>>>>> Timing packets only. >>>>>> >>>>>> SB> Why? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 12] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 6. Timing over LSP Encapsulation >>>>>> >>>>>> The encapsulations is not LSP is it? >>>>>> >>>>>> This document defines two methods for carrying Timing messages ov= er >>>>>> MPLS. The first method is carrying UDP/IP encapsulated Timing >>>>>> messages over Timing LSPs, and the second method, is carrying >>>>>> Ethernet encapsulated Timing messages over Ethernet PWs inside >>> Timing >>>>>> LSPs. >>>>>> >>>>>> 6.1. Timing over UDP/IP over MPLS Encapsulation >>>>>> >>>>>> The simplest method of transporting Timing messages over MPLS is= to >>>>>> encapsulate Timing PDUs in UDP/IP and then encapsulate them in >>> Timing >>>>>> LSP. This format is shown in Figure 4. >>>>>> >>>>>> >>>>>> +----------------------+ >>>>>> | Timing LSP Label | >>>>>> +----------------------+ >>>>>> | IPv4/6 | >>>>>> +----------------------+ >>>>>> | UDP | >>>>>> +----------------------+ >>>>>> | Timing PDU | >>>>>> +----------------------+ >>>>>> >>>>>> Figure (4) - Timing over UDP/IP over MPLS Encapsulation >>>>>> >>>>>> >>>>>> This encapsulation is very simple and is useful when the network >>>>>> between Timing Master Clock and Slave Clock is MPLS network. >>>>>> >>>>>> SB> Simple is a judgement call >>>>>> >>>>>> In order for an LER/LSR to process Timing messages, the Timing LS= P >>>>>> Label must be at the top label of the label stack. The LER/LSR M= UST >>>>>> know that the Timing LSP Label is used for carrying Timing messag= es. >>>>>> This can be accomplished via static configuration or via RSVP-TE >>>>>> signaling. >>>>>> >>>>>> The UDP/IP encapsulation of PTP MUST follow Annex D and E of >>>>>> [IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow >>>>>> [RFC5905]. >>>>>> >>>>>> 6.2. Timing over PW Encapsulation >>>>>> >>>>>> Another method of transporting Timing over MPLS networks is by >>>>>> encapsulating Timing PDUs in PW which in turn is transported over >>>>>> Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448]= , >>>>>> shown in Fig 5(A) MUST be used and the Ethernet encapsulation of= PTP >>>>>> MUST follow Annex F of [IEEE-1588]. >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 13] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> The RAW mode or Tagged mode defined in [RFC4448] MAY be used and >>> the >>>>>> Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The >>>>>> Timing over PW encapsulation MUST use the Control Word (CW) as >>>>>> specified in [RFC4448] to ensure proper detection of PTP messages >>>>>> inside the MPLS packets for Timing over LSP and Timing over PW >>>>>> encapsulation. >>>>>> >>>>>> SB> That needs explanation >>>>>> >>>>>> The use of Sequence Number in the CW is optional. >>>>>> >>>>>> SB> Given that s/n are never in practice deployed, you could probably >>>>>> SB> simplify things by sayig that they are not used. >>>>>> >>>>>> Timing over PW encapsulation for NTP MUST use NTP over UDP/IP ove= r >>> PW >>>>>> (the IP PW discussed in [RFC4447]) shown in Fig 5(B). >>>>>> >>>>>> +----------------+ +----------------+ >>>>>> |Timing LSP Label| |Timing LSP Label| >>>>>> +----------------+ +----------------+ >>>>>> | PW Label | | PW Label | >>>>>> +----------------+ +----------------+ >>>>>> | Control Word | | IP | >>>>>> +----------------+ +----------------+ >>>>>> | Ethernet | | UDP | >>>>>> | Header | +----------------+ >>>>>> +----------------+ | Timing PDU | >>>>>> |S-VLAN(Optional)| | | >>>>>> +----------------+ +----------------+ >>>>>> |C-VLAN(Optional)| (B) >>>>>> +----------------+ >>>>>> | Timing PDU | >>>>>> | | >>>>>> +----------------+ >>>>>> (A) >>>>>> >>>>>> Figure (5) - Timing over PW Encapsulations >>>>>> >>>>>> In order for an LSR to process PTP messages, the top label of the >>>>>> label stack (the Tunnel Label) MUST be a Timing label. >>>>>> >>>>>> S> You said that before. >>>>>> >>>>>> 6.3. Other Timing Encapsulation methods >>>>>> >>>>>> In future other timing encapsulation methods may be introduced, s= uch >>>>>> as a new shim header after the Bottom of Stack to carry the Timin= g >>>>>> information. Such new encapsulations are outside the scope of th= is >>>>>> document. >>>>>> >>>>>> >>>>>> SB> Taking a pure MPLS pov, you can simplify a lot of the text >>>>>> SB> out of the definition of the LSP >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 14] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> SB> I think we need a section on LSP processing >>>>>> >>>>>> 7. Timing message Processing >>>>>> >>>>>> Each Timing protocol such as PTP and NTP, define their set of Tim= ing >>>>>> messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, >>>>>> FOLLOW_UP, etc messages. >>>>>> >>>>>> Some of the Timing messages require time stamping or correction f= ield >>>>>> update at port level and some dont. It is the job of the LER/LSR= to >>>>>> parse the timing message and find out the type of the Timing mess= age >>>>>> and decide whether and how to Time- stamp it (e.g., BC) or update >>>>>> correction field(e.g., TC). >>>>>> >>>>>> >>>>>> SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing >>>>>> SB> function rather than the LER? >>>>>> >>>>>> For example the following PTP messages (called Event messages) >>>>>> require time-stamping or correction field update: >>>>>> >>>>>> o SYNC >>>>>> >>>>>> o DELAY_REQ (Delay Request) >>>>>> >>>>>> o PDELAY_REQ (Peer Delay Request) >>>>>> >>>>>> o PDELAY_RESP (Peer Delay Response) >>>>>> >>>>>> SYNC and DELAY_REQ are exchanged between Master Clock and Slave >>> Clock >>>>>> and MUST be transported over PTP LSPs. PDELAY_REQ and >>> PDELAY_RESP >>>>>> are exchanged between adjacent PTP clocks (i.e. Master, Slave, >>>>>> Boundary, or Transparent) and SHOULD be transported over single h= op >>>>>> PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP= , >>>>>> and PDELAY_RESP_FOLLOW_UP messages MUST also be transported >>> over >>>>>> the >>>>>> PTP LSPs. >>>>>> >>>>>> For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be >>>>>> transported over two PTP LSPs that are in opposite directions. T= hese >>>>>> PTP LSPs, which are in opposite directions MUST be congruent and= co- >>>>>> routed. Alternatively, a single bidirectional co-routed LSP can= be >>>>>> used. >>>>>> >>>>>> Except as indicated above for the two-step PTP clocks, Non-Event= PTP >>>>>> message types do not need to be processed by intermediate routers= . >>>>>> These message types MAY be carried in PTP Tunnel LSPs. >>>>>> >>>>>> SB> Are you saying that a timing P router has to be msg type sensitiv= e? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 15] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 8. Protection and Redundancy >>>>>> >>>>>> >>>>>> SB> This is a bit of a jump - I don't know how the LSP itself works y= et! >>>>>> >>>>>> In order to ensure continuous uninterrupted operation of slave >>>>>> clocks, usually as a general practice, slave clocks (or ports) tr= ack >>>>>> redundant master clocks. >>>>>> >>>>>> It is the responsibility of the network operator to ensure that >>>>>> physically disjoint Timing LSPs are established between a slave c= lock >>>>>> (or port) and redundant master clocks (or ports). >>>>>> >>>>>> When a slave clock (or port) listens to redundant master clocks o= r >>>>>> ports, any prolonged Timing LSP outage will trigger the slave clo= ck >>>>>> or port to switch to a redundant master clock or port. >>>>>> >>>>>> LSP/PW protection such as Linear protection Switching (1:1, 1+1), >>>>>> Ring protection switching or MPLS Fast Reroute (FRR) generally sw= itch >>>>>> alternative path that usually cause a change in delay, which if >>>>>> undetected by slave clock can reduce accuracy of the slave clock. >>>>>> >>>>>> Therefore protection switching MAY be used, as long as phase jump= s >>>>>> upon switchover due to differences in path latency are detected a= nd >>>>>> compensated for (such compensation not being required if BCs or p= eer- >>>>>> peer TCs are used throughout). >>>>>> >>>>>> Note that any protection or reroute mechanism that adds additiona= l >>>>>> MPLS label to the label stack, such as Facility Backup Fast Rerou= te, >>>>>> MUST ensure that the pushed label is also a Timing Label to ensur= e >>>>>> recognition of the MPLS frame as containing Timing messages, as i= t >>>>>> transits the backup path. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 16] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 9. ECMP >>>>>> >>>>>> To ensure the optimal operation of slave clocks and avoid error >>>>>> introduced by forward and reverse path delay asymmetry, the physi= cal >>>>>> path for Timing messages from master clock to slave Clock and vic= e >>>>>> versa must be the same for all Event Timing messages listed in >>>>>> section 7. >>>>>> >>>>>> Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost >>>>>> Multipath). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 17] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 10. PHP >>>>>> >>>>>> To ensure that the label on the top of the label stack is the Tim= ing >>>>>> LSP Label, PHP MUST not be used. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 18] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 11. Entropy >>>>>> >>>>>> To ensure all Timing messages in a Timing LSP take the same path, >>>>>> Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and >>>>>> Entropy Label MUST NOT be used for the PWs that are carried insid= e >>>>>> Timing LSP [RFC6391]. >>>>>> >>>>>> SB> This is incorrect - you mean that all msgs of the same timing >>>>>> SB> flow need to have the same EL value. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 19] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 12. OAM, Control and Management >>>>>> >>>>>> In order to monitor Timing LSPs and their encapsulated PWs, they= MUST >>>>>> be able to carry OAM and management messages. These management >>>>>> messages MUST be differentiated from Timing messages via already >>>>>> defined IETF methods. >>>>>> >>>>>> For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY r= un >>>>>> over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These >>>>>> Management protocols can easily be identified by the UDP Destinat= ion >>>>>> Port number or by GAL/G-ACH respectively. >>>>>> >>>>>> Also BFD, LSP-Ping and other management messages MAY run over the >>> PWs >>>>>> encapsulated in Timing LSP via one of the defined VCCVs (Type 1,= 3 or >>>>>> 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is g= oing >>>>>> to be deprecated by IETF). In this case G-ACH, PW label (TTL=3D1= ) or >>>>>> GAL-ACH are used to identify such management messages. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 20] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 13. QoS Considerations >>>>>> >>>>>> In network deployments where not every LSR/LER is Timing-aware, i= t is >>>>>> important to reduce the impact of the non-Timing-aware LSR/LERs o= n >>>>>> the timing recovery in the slave clock. The Timing messages are= time >>>>>> critical and must be treated with the highest priority. Therefor= e >>>>>> Timing over MPLS messages must be treated with the highest priori= ty >>>>>> in the routers. This can be achieved by proper setup of Timing L= SPs. >>>>>> >>>>>> It is recommended that the Timing LSPs are setup or configured >>>>>> properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC26= 97] >>>>>> for drop eligibility. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 21] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 14. FCS and Checksum Recalculation >>>>>> >>>>>> When time-stamp generation and timing packet adjustment is perfor= med >>>>>> near the physical port hardware, the process MUST include >>>>>> recalculation of the Ethernet FCS. >>>>>> >>>>>> SB> The above is confusing - an LSR always recomputes the link layer >>>>>> SB> CRC which may or may not be Ethernet. >>>>>> >>>>>> Also FCS retention for the >>>>>> payload Ethernet described in [RFC4720] MUST NOT be used. >>>>>> >>>>>> For UDP/IP encapsulation mode of Timing over MPLS, the UDP checks= um >>>>>> may be required as per UDP transport standards. >>>>>> >>>>>> SB> You really need to be working on getting the IPv6 C?S computation >>>>>> SB> removed from PTP msgs. >>>>>> >>>>>> When UDP checksum is used, each Timing-aware LER/LSR must either >>>>>> incrementally update the UDP checksum after Time stamping or >>>>>> Correction Field update or verify the UDP checksum on reception f= rom >>>>>> upstream and recalculate the checksum completely on transmission= to >>>>>> downstream node after Time stamping or Correction Field update. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 22] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 15. Behavior of LER/LSR >>>>>> >>>>>> Timing-capable/aware LERs and LSRs are routers that have one or m= ore >>>>>> >>>>>> SB> You mean physical interfaces? >>>>>> >>>>>> interfaces that can perform Timing operations (OC/BC/TC) on Timin= g >>>>>> packets and are configured to do so. Timing-capable/aware LERs a= nd >>>>>> LSRs can advertise their Timing-capability per-interface via cont= rol >>>>>> plane such as OSPF or IS-IS. >>>>>> SB> ISIS and OSPF are routing protocols. >>>>>> >>>>>> The Timing-capable/aware LERs can then >>>>>> signals Timing LSPs via RSVP-TE signaling. Alternatively the Tim= ing >>>>>> capability of LER and LSRs may be configured in a centralized >>>>>> controller and the Timing LSP may be setup using manual configura= tion >>>>>> or other methods such as SDN. >>>>>> >>>>>> SB> it can also be configured individually rather then through >>>>>> SB> a cebtral controllwe >>>>>> >>>>>> 15.1. Behavior of Timing-capable/aware LER >>>>>> >>>>>> When a Timing-capable/aware LER behaves as a Transparent clock an= d >>>>>> receives a Timing message from a Timing-capable/aware non-MPLS >>>>>> interface, the LER updates the Correction Field (CF) and encapsul= ates >>>>>> and forwards the timing message over previously established Timin= g >>>>>> LSP. >>>>>> >>>>>> SB> You need to call out the details so that people properly >>>>>> SB> understand the definition of the new LSP. >>>>>> >>>>>> Also when a Timing message is received from a Timing-capable/ >>>>>> aware MPLS interface, LER updates the Correction Filed (CF) and >>>>>> decapsulates the MPLS encapsulation and forwards the timing messa= ge >>>>>> to a non-MPLS interface. >>>>>> >>>>>> When a Timing-capable/aware LER behaves as a Boundary clock and >>>>>> receives a Timing message from a Timing-capable/aware non MPLS >>>>>> interface, the LER Timestamps the Timing packet and sends it to t= he >>>>>> LERs Boundary clock processing module. Also when a Timing messag= e is >>>>>> received from a Timing- capable/aware MPLS interface, the LER >>>>>> Timestamps the Timing packet and sends it to the LERs Boundary cl= ock >>>>>> processing module. >>>>>> >>>>>> When a Timing-capable/aware LER behaves as an Ordinary Clock towa= rd >>>>>> the MPLS network, and receives a Timing message from a Timing- >>>>>> capable/aware MPLS interface, the LER Timestamps the Timing packe= t >>>>>> and sends it to the LERs Ordinary clock processing module. >>>>>> >>>>>> 15.2. Behavior of Timing-capable/aware LSR >>>>>> >>>>>> When a Timing-capable/aware LSR behaves as a Transparent clock an= d >>>>>> receives a Timing message from a Timing-capable/aware MPLS >>> interface, >>>>>> The LSR updates the Correction Filed (CF) and forwards the timing >>>>>> message over another MPLS interface. >>>>>> >>>>>> When a Timing-capable/aware LSR behaves as a Boundary clock and >>>>>> receives a Timing message from a Timing-capable/aware MPLS >>> interface. >>>>>> The LSR performs the functions of a Boundary Clock in terminating= the >>>>>> received Timing message and re-generating a new timing message ov= er >>>>>> another (or the same) MPLS interface. >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 23] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 15.3. Behavior of non-Timing-capable/aware LSR >>>>>> >>>>>> It is most beneficial when all LSRs in the path of a Timing LSP b= e >>>>>> timing-Capable/aware LSRs. This would ensure the highest quality >>>>>> time and clock synchronization by Timing Slave Clocks. However,= this >>>>>> specification does not mandate that all LSRs in path of a Timing= LSP >>>>>> be Timing- capable/aware. >>>>>> >>>>>> Non-Timing-capable/aware LSRs just switch the packets encapsulate= d in >>>>>> Timing LSPs and dont perform any Timing operation (TC or BC). >>>>>> However as explained in QoS section the Timing over MPLS packets >>> MUST >>>>>> be still be treated with the highest priority based on their Traf= fic >>>>>> Class (TC) marking. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 24] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 16. Other considerations >>>>>> >>>>>> [IEEE-1588] defines an optional peer-to-peer Transparent clocking >>>>>> that requires peer delay measurement between two adjacent Timing- >>>>>> capable/ aware routers/switches. Peer delay measurement messages >>>>>> need to be time stamped and terminated by the Timing-capable/awar= e >>>>>> routers/ switches. This means that two adjacent LSRs may be enga= ged >>>>>> in a peer delay measurement. >>>>>> >>>>>> For transporting such peer delay measurement messages a single-ho= p >>>>>> LSP SHOULD to be created between the two adjacent LSRs engaged in >>>>>> peer delay measurement to carry peer delay measurement messages. >>>>>> Other methods such as PTP transport over Ethernet MAY be used for >>>>>> transporting peer delay measurement messages if the link between= the >>>>>> two routers is Ethernet. >>>>>> >>>>>> In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/= ware >>>>>> routers/switches MUST maintain a list of all the neighbors it nee= ds >>>>>> to send a PDelay_Req to, where each neighbor corresponds to a tim= ing >>>>>> LSP. >>>>>> >>>>>> The use of Explicit Null Label (Label=3D 0 or 2) is acceptable as= long >>>>>> as either the Explicit Null label is the bottom of stack label >>>>>> (applicable only to UDP/IP encapsulation) or the label below the >>>>>> Explicit Null label is a PTP label. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 25] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 17. Security Considerations >>>>>> >>>>>> MPLS PW security considerations in general are discussed in [RFC3= 985] >>>>>> and [RFC4447],and those considerations also apply to this documen= t. >>>>>> >>>>>> An experimental security protocol is defined in [IEEE-1588].The P= TP >>>>>> security extension and protocol provides group source authenticat= ion, >>>>>> message integrity, and replay attack protection for PTP messages. >>>>>> >>>>>> When the MPLS network (provider network) serves multiple customer= s, >>>>>> it is important to maintain and process each customers clock and >>>>>> Timing messages separately from other customers to ensure there i= s no >>>>>> cross- customer effect. For example if an LER BC is synchronized= to >>>>>> a specific grandmaster, belonging to customer A, then the LER MUS= T >>>>>> use that BC clock only for customer A to ensure that customer A >>>>>> cannot attack other customers by manipulating its time. >>>>>> >>>>>> Timing messages MAY be encrypted or authenticated, provided that= the >>>>>> LERs/LSRs that are Timing capable/aware can authenticate/ decrypt= the >>>>>> timing messages. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 26] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 18. Acknowledgements >>>>>> >>>>>> The authors would like to thank Ron Cohen, Yaakov Stein, Tal Mizr= ahi, >>>>>> Stefano Ruffini, Peter Meyer, and other members of IETF for revie= wing >>>>>> and providing feedback on this draft. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 27] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 19. IANA Considerations >>>>>> >>>>>> There are no IANA requirements in this specification. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 28] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 20. References >>>>>> >>>>>> 20.1. Normative References >>>>>> >>>>>> [IEEE-1588] >>>>>> IEEE 1588-2008, "IEEE Standard for a Precision Clock >>>>>> Synchronization Protocol for Networked Measurement and >>>>>> Control Systems". >>>>>> >>>>>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >>>>>> Requirement Levels", BCP 14, RFC 2119, March 1997. >>>>>> >>>>>> [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to= - >>>>>> Edge (PWE3) Architecture", RFC 3985, March 2005. >>>>>> >>>>>> [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discov= ery >>>>>> Proxies (ND Proxy)", RFC 4389, April 2006. >>>>>> >>>>>> [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G= . >>>>>> Heron, "Pseudowire Setup and Maintenance Using the Lab= el >>>>>> Distribution Protocol (LDP)", RFC 4447, April 2006. >>>>>> >>>>>> [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, >>>>>> "Encapsulation Methods for Transport of Ethernet over= MPLS >>>>>> Networks", RFC 4448, April 2006. >>>>>> >>>>>> [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire >>>>>> Emulation Edge-to-Edge (PWE3) Frame Check Sequence >>>>>> Retention", RFC 4720, November 2006. >>>>>> >>>>>> [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circu= it >>>>>> Connectivity Verification (VCCV): A Control Channel fo= r >>>>>> Pseudowires", RFC 5085, December 2007. >>>>>> >>>>>> [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detect= ion >>>>>> (BFD)", RFC 5880, June 2010. >>>>>> >>>>>> [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow= , >>>>>> "Bidirectional Forwarding Detection (BFD) for MPLS Lab= el >>>>>> Switched Paths (LSPs)", RFC 5884, June 2010. >>>>>> >>>>>> 20.2. Informative References >>>>>> >>>>>> [I-D.ietf-pwe3-fat-pw] >>>>>> Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Reg= an, >>>>>> J., and S. Amante, "Flow Aware Transport of Pseudowire= s >>>>>> over an MPLS Packet Switched Network", >>>>>> draft-ietf-pwe3-fat-pw-07 (work in progress), July 201= 1. >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 29] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermedia= te >>>>>> system routeing information exchange protocol for use= in >>>>>> conjunction with the Protocol for providing the >>>>>> Connectionless-mode Network Service (ISO 8473)". >>>>>> >>>>>> [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP an= d >>>>>> dual environments", RFC 1195, December 1990. >>>>>> >>>>>> [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 199= 8. >>>>>> >>>>>> [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color >>>>>> Marker", RFC 2697, September 1999. >>>>>> >>>>>> [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boud= ec, >>>>>> J., Courtney, W., Davari, S., Firoiu, V., and D. >>>>>> Stiliadis, "An Expedited Forwarding PHB (Per-Hop >>>>>> Behavior)", RFC 3246, March 2002. >>>>>> >>>>>> [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Enginee= ring >>>>>> (TE) Extensions to OSPF Version 2", RFC 3630, >>>>>> September 2003. >>>>>> >>>>>> [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermedia= te >>>>>> System (IS-IS) Extensions for Traffic Engineering (TE)= ", >>>>>> RFC 3784, June 2004. >>>>>> >>>>>> [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and= S. >>>>>> Shaffer, "Extensions to OSPF for Advertising Optional >>>>>> Router Capabilities", RFC 4970, July 2007. >>>>>> >>>>>> [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate >>>>>> System to Intermediate System (IS-IS) Extensions for >>>>>> Advertising Router Information", RFC 4971, July 2007. >>>>>> >>>>>> [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi >>>>>> Topology (MT) Routing in Intermediate System to >>>>>> Intermediate Systems (IS-ISs)", RFC 5120, February 200= 8. >>>>>> >>>>>> [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic >>>>>> Engineering", RFC 5305, October 2008. >>>>>> >>>>>> [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, >>>>>> "Traffic Engineering Extensions to OSPF Version 3", >>>>>> RFC 5329, September 2008. >>>>>> >>>>>> [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSP= F >>>>>> for IPv6", RFC 5340, July 2008. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 30] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Net= work >>>>>> Time Protocol Version 4: Protocol and Algorithms >>>>>> Specification", RFC 5905, June 2010. >>>>>> >>>>>> [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Reg= an, >>>>>> J., and S. Amante, "Flow-Aware Transport of Pseudowire= s >>>>>> over an MPLS Packet Switched Network", RFC 6391, >>>>>> November 2011. >>>>>> >>>>>> [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., a= nd >>>>>> L. Yong, "The Use of Entropy Labels in MPLS Forwarding= ", >>>>>> RFC 6790, November 2012. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 31] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 1. Routing extensions for Timing-aware Routers >>>>>> >>>>>> MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340]= and >>>>>> IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (= TE) >>>>>> link information used for constraint-based routing. >>>>>> >>>>>> Indeed, it is useful to advertise data plane TE router link >>>>>> capabilities, such as the capability for a router to be Timing-aw= are. >>>>>> This capability MUST then be taken into account during path >>>>>> computation to prefer or even require links that advertise themse= lves >>>>>> as Timing-aware. In this way the path can ensure the entry and e= xit >>>>>> points into the LERs and, if desired, the links into the LSRs are >>>>>> able to perform port based time-stamping thus minimizing their im= pact >>>>>> on the performance of the slave clock. >>>>>> >>>>>> extensions are required to OSPF and IS-IS in order to advertise >>>>>> Timing-aware capabilities of a link. Such extensions are outside= the >>>>>> scope of this document; however such extension SHOULD be able to >>>>>> signal the following information per Router Link: >>>>>> >>>>>> o Capable of processing PTP, NTP or other Timing flows >>>>>> >>>>>> o Capable of performing Transparent Clock operation >>>>>> >>>>>> o Capable of performing Boundary Clock operation >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 32] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> 2. Signaling Extensions for Creating Timing LSPs >>>>>> >>>>>> RSVP-TE signaling MAY be used to setup the timing LSPs. When RSV= P-TE >>>>>> is used to setup Timing LSPs, some information that indicates tha= t >>>>>> the LSP is carrying Timing flows MUST be included in the new >>>>>> Extensions to RSVP-TE: >>>>>> >>>>>> The following information MAY also be included in the new Extensi= ons >>>>>> to RSVP-TE: >>>>>> >>>>>> o Offset from Bottom of Stack (BoS) to the start of the Time-sta= mp >>>>>> field >>>>>> >>>>>> o Number of VLANs in case of PW encapsulation >>>>>> >>>>>> o Timestamp field Type >>>>>> >>>>>> * Correction Field, Timestamp >>>>>> >>>>>> o Timestamp Field format >>>>>> >>>>>> * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit >>>>>> NTP, etc. >>>>>> >>>>>> Note that in case the above optional information is signaled with >>>>>> RSVP-TE for a Timing LSP, all the Timing packets carried in that= LSP >>>>>> must have the same signaled characteristics. For example if >>>>>> Timestamp format is signaled as 64-bit PTPv1, then all Timing pac= kets >>>>>> must use 64-bit PTPv1 time-stamp. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 33] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> Authors' Addresses >>>>>> >>>>>> Shahram Davari >>>>>> Broadcom Corp. >>>>>> San Jose, CA 95134 >>>>>> USA >>>>>> >>>>>> Email: davari@broadcom.com >>>>>> >>>>>> >>>>>> Amit Oren >>>>>> Broadcom Corp. >>>>>> San Jose, CA 95134 >>>>>> USA >>>>>> >>>>>> Email: amito@broadcom.com >>>>>> >>>>>> >>>>>> Manav Bhatia >>>>>> Alcatel-Lucent >>>>>> Bangalore, >>>>>> India >>>>>> >>>>>> Email: manav.bhatia@alcatel-lucent.com >>>>>> >>>>>> >>>>>> Peter Roberts >>>>>> Alcatel-Lucent >>>>>> Kanata, >>>>>> Canada >>>>>> >>>>>> Email: peter.roberts@alcatel-lucent.com >>>>>> >>>>>> >>>>>> Laurent Montini >>>>>> Cisco Systems >>>>>> San Jose CA >>>>>> USA >>>>>> >>>>>> Email: lmontini@cisco.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 34] >>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>> >>>>>> >>>>>> Luca >>>>>> Cisco Systems >>>>>> San Jose CA >>>>>> USA >>>>>> >>>>>> Email: lmartini@cisco.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Davari, et al. Expires December 17, 2013 [Page= 35] >>>>>> -- >>>>>> For corporate legal information go to: >>>>>> >>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>> >>>>>> _______________________________________________ >>>>>> TICTOC mailing list >>>>>> TICTOC@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tictoc >>>>> 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 >>>> . >>> >>> -- >>> For corporate legal information go to: >>> >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>> >>> _______________________________________________ >>> TICTOC mailing list >>> TICTOC@ietf.org >>> https://www.ietf.org/mailman/listinfo/tictoc >>> >>> >>> _______________________________________________ >>> TICTOC mailing list >>> TICTOC@ietf.org >>> https://www.ietf.org/mailman/listinfo/tictoc >> >> This e-mail message is intended for the recipient only and contains infor= mation 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, p= hone or fax, and then delete the original and all copies thereof. >> > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html 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 davarish@yahoo.com Tue Aug 20 10:01:05 2013 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 63A6421F8F97 for ; Tue, 20 Aug 2013 10:01:05 -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=[BAYES_00=-2.599, 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 vGw7CDxh1zBu for ; Tue, 20 Aug 2013 10:01:00 -0700 (PDT) Received: from nm18-vm3.bullet.mail.ne1.yahoo.com (nm18-vm3.bullet.mail.ne1.yahoo.com [98.138.91.148]) by ietfa.amsl.com (Postfix) with ESMTP id EF9F321F8CB4 for ; Tue, 20 Aug 2013 10:00:59 -0700 (PDT) Received: from [98.138.90.49] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 20 Aug 2013 17:00:57 -0000 Received: from [98.138.226.60] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 20 Aug 2013 17:00:57 -0000 Received: from [127.0.0.1] by smtp211.mail.ne1.yahoo.com with NNFMP; 20 Aug 2013 17:00:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1377018057; bh=M0bf6LnX77wu2l/Yao9cgZiMVg5N6yW9OnOa9AClIhU=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=pmwnsOf7H3U8mEDAY16GhCQm5kHWl9m2Iai1kzAJBFlRw9X0z5NhIZHd8XfHerukmF0p9D6HPVLTb+fbAahIvaQ2nJKC2Id/FvemKGpKLng2+9IQR51mEnY4SK2+v3uu56/EdSVqHTuIXvdmrVwQF83be4mTn2B/kTVs++1Rv08= X-Yahoo-Newman-Id: 221381.57402.bm@smtp211.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ojNBIeAVM1mcvuHGcrWrxotzD54cneuv3UZd_vPT1alj2ZB GSnPkLIkrPuKO8tnrHADdIE9b253rOzbxIj37zkwhCGrt44Oz.jlbs5FKKZq NhDsscpKYFtFZyGInk1EJmJZdosIkoh26m.vnhunr29YPlWt1l_DYGYs9rcL N4_4nXmnejDcJvhN8aqcsXBIne5pUUy5N2Mm9klrPb2nKlFgsYX0bbtBbMlX diZQsPiQtD77Pzj.rC2hthEvBRY2LagIxFBhDMZfNQ1Tm5SdzG5wqp1aQcqp 7l3qQVyXFEqtMp.qzZOJt.bIDkEpbwX5E_EmSyU_alQSQQaqRT_qKvo4hZZm uHicQYiv8ry.paTje5AElFocLYXh35VhX2jDtPzDfcsUYFT05M2ypUuKCSHG uMncv6nt5dJaMke_n2Zpgnx5YD8ANv1XlUsbqF5Fe7Gucb_3haeeyCtwhAi. IC3g7oe4cxvaJjf40wgpJEiMRhULa.6HZ0vs3er5P4lKDP5flMGtUBmPAAwd xS8wn9vcRpGwreBBCNxWDjcQEwi7dsJUA0z8k.S0g2dZ0tipLhR1hgQ-- X-Yahoo-SMTP: ygPrP9CswBCWPbPtKJlJyLY0KMlg X-Rocket-Received: from [192.168.0.103] (davarish@98.248.42.143 with ) by smtp211.mail.ne1.yahoo.com with SMTP; 20 Aug 2013 10:00:57 -0700 PDT References: <51FB7543.801@cisco.com> <51FF7068.9080600@cisco.com> <4A6CE49E6084B141B15C0713B8993F281BEC731A@SJEXCHMB12.corp.ad.broadcom.com> <52139903.8040801@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A403) From: "S. Davari" Date: Tue, 20 Aug 2013 10:00:41 -0700 To: Alexander Vainshtein Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] Comments on draft-ietf-tictoc-1588overmpls 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, 20 Aug 2013 17:01:05 -0000 Sasha In (2) are you proposing to create multiple segment LSPs, where each if thos= e segment LSPs span between two Timing aware LSR? So if I have 10 timing awa= re LSR in the path I would need 9 LSPs? Regards, Shahram On Aug 20, 2013, at 9:53 AM, Alexander Vainshtein wrote: > Stewart, Shahram and all, >=20 > A couple of (hopefully, last) comments: >=20 > 1. Supporting a "Timing Alert" label at the top of the label stack introdu= ces a backward compatibility problem. We differ in our estimate of the impor= tance of this problem, but we all agree that it exists. >=20 > 2. On the other hand, this problem does not exist if the "Timing Alert" la= bel is inserted at the bottom of the label stack. At the same time, HW that a= nalyzes the label stack hopefully could analyze the bottom label (almost) as= easily as it would analyze the top label. Thus we could both provide backwa= rd compatibility (incompatible transit LSRs simply would not notice the "Tim= ing Alert" label") and avoid the need for dedicated "Timing-only" LSPs. In p= articular, all the MPLS OAM tools (including MPLS-TP) would work without any= changes.=20 >=20 > 3. A "timing shim header" (between the bottom of the label stack and the b= eginning of the timing packet) has been mentioned by Stewart as an already p= roposed mechanism. IMHO and FWIW its usage would eliminate the need to under= stand format of the specific timing distribution protocol in the transit LSR= s. It would further solve the problem of secure transport of timing packets= since security mechanisms would be applied to its original encapsulation (o= ver IP or over Ethernet) without involving the transit LSRs. >=20 > Did I miss something substantial? >=20 > Regards, and lots of thanks in advance, > Sasha >=20 >=20 > ________________________________________ > From: Stewart Bryant [stbryant@cisco.com] > Sent: Tuesday, August 20, 2013 6:27 PM > To: S. Davari > Cc: Alexander Vainshtein; Shahram Davari; mpls@ietf.org; tictoc@ietf.org > Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls >=20 > On 06/08/2013 14:35, S. Davari wrote: >> Sasha, >>=20 >> If a router is not 1588 aware we want it to switch the packet with minimu= m jitter and delay via high priority queue. > Yes, but you can explicitly tunnel across such island of incompatibility >=20 > Stewart >=20 >>=20 >>=20 >> Sending it to CPU creates large jitter and delay since the CPUs are gener= ally busy doing other things. Time stamping or updating CF in the CPU won't h= elp since it does not cover the variable delay that is incurred from the tim= e the packet enters the router to the time the packet gets processed by CPU.= >>=20 >> I wish it was that easy! >>=20 >> Regards, >> Shahram >>=20 >>=20 >> On Aug 6, 2013, at 12:38 AM, Alexander Vainshtein wrote: >>=20 >>> Shahram, >>> I agree with you that the routers that do not recognize a Timing Alert l= abel would send the packet to the CPU. (This would be easy to arrange since w= e are speaking about a reserved label.) >>>=20 >>> I do not, however, see this as a serious issue, because the SW running o= n this CPU would (hopefully) be upgradable to handle the packet correctly i.= e., to forward it to where it should be forwarded and, if it is forwarded as= a labeled packet, to prepend the Timing Alert Label on top of its label sta= ck. It could even record the residence time (as observed by the CPU in the p= roper place in the packet. This would mean that introducing additional error= to whatever timing information is associated with this packet - but this is= what you should anyway expect if there are non-compliant routers on your pa= th, right? >>>=20 >>> Regards, >>> Sasha >>>=20 >>>> -----Original Message----- >>>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behal= f Of >>>> Shahram Davari >>>> Sent: Monday, August 05, 2013 11:29 PM >>>> To: stbryant@cisco.com; S. Davari >>>> Cc: mpls@ietf.org; tictoc@ietf.org >>>> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls= >>>>=20 >>>> Hi Stewart, >>>>=20 >>>> Your suggestion of " I suggested an LSP type that has the properties "t= imestamp >>>> and pass to application", is a subset of the existing draft and should w= ork. It >>>> basically limits the time stamping and correction field update to LERs (= while the >>>> draft supports time stamping at LER and LSR). >>>>=20 >>>> However Sasha's suggestion of using a reserved label (RAL, GAL or any o= ther >>>> reserved label) does not satisfy one of the major requirements, which i= s >>>> backward compatibility. Routers that don't understand this reserved lab= el will >>>> drop or copy to CPU such packets. >>>>=20 >>>> Regards, >>>> Shahram >>>>=20 >>>> -----Original Message----- >>>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behal= f Of >>>> Stewart Bryant >>>> Sent: Monday, August 05, 2013 2:29 AM >>>> To: S. Davari >>>> Cc: mpls@ietf.org; tictoc@ietf.org >>>> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls= >>>>=20 >>>> My concern is that we are creating a new LSP type in MPLS >>>> (which is a architectural change and thus needs to be very carefully >>>> considered) without asking the question "how can I do this >>>> in the most general way, to maximize flexibility/reuse" >>>>=20 >>>> I suggested an LSP type that has the properties "timestamp >>>> and pass to application", but I think that Sasha raises a good >>>> point about using router alert. However RA has no implicit >>>> timestamp, so maybe we need a new type of RA that has the >>>> properties "timestamp, and pass top application indicated by >>>> the next label". That would be quite useful in a number >>>> of OAM applications. There is possibly some GAL variant >>>> of that design that should also be considered. >>>>=20 >>>> The application could worry about the path and where it >>>> was necessary to skip some hops a hierarchical LSP would >>>> accomplish that, with the specific benefit that the application >>>> would consciously do this, and may be able to apply some >>>> form of compensation within the network. >>>>=20 >>>> - Stewart >>>>=20 >>>> On 04/08/2013 10:40, S. Davari wrote: >>>>> Hi Sasha >>>>>=20 >>>>> Perhaps you have not understood the draft well. The main reason that t= he >>>> draft chose to use a dedicated LSP that is signaled via RSVPTE indicati= ng it is a >>>> timing LSP is to be backward compatible with non-1588 nodes. Such nodes= >>>> simply just switch the packet. >>>>> Your proposal had been considered and was rejected since it was not >>>> backward compatible. Nodes receiving alert label or TTL =3D 1 send the p= acket to >>>> CPU. You can refer to the meeting notes. >>>>> Regards, >>>>> Shahram >>>>>=20 >>>>>=20 >>>>> On Aug 4, 2013, at 1:21 AM, Alexander Vainshtein >>>> wrote: >>>>>> Stewart and all, >>>>>> I concur with Stewart's statement that the draft does not define "ful= l >>>> interaction with MPLS architecture". >>>>>> E.g., one of the objectives of the draft is to provide a technique th= at would >>>> be backward-compatible with old LSRs that cannot provide on-path suppor= t for >>>> timing distribution, while the other objective is to make every LSR on t= he path >>>> aware that some MPLS packets are carrying timing-related messages and h= ence >>>> require on-path support. >>>>>> IMHO and FWIW, the MPLS data plane architecture allows just two metho= ds >>>> for making a transit LSR to provide special processing to a labeled pac= ket: >>>>>> - It would carry some kind of an "alert label" on top of the label st= ack and, >>>> specifically, on top of any labels used for actual forwarding >>>>>> OR, >>>>>> - The TTL in the top label stack entry has been set to 1. >>>>>>=20 >>>>>>=20 >>>>>> The draft does not follow any of these approaches. >>>>>>=20 >>>>>> I must also admit that Section 12 "OAM, Control and Management" of th= e >>>> draft looks somewhat in >>>>>> E.g., I could not understand from the text whether BFD, LSP-Ping etc.= OAM >>>> messages would be subjected to on-path support procedures for timing >>>> messages or not. >>>>>> My 2c, >>>>>> Sasha >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Be= half >>>> Of >>>>>>> Stewart Bryant >>>>>>> Sent: Friday, August 02, 2013 12:01 PM >>>>>>> To: mpls-chairs@tools.ietf.org; tictoc-chairs@tools.ietf.org; int- >>>>>>> ads@tools.ietf.org; rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.o= rg; >>>> draft- >>>>>>> ietf-tictoc-1588overmpls@tools.ietf.org >>>>>>> Cc: mpls@ietf.org; tictoc@ietf.org >>>>>>> Subject: [TICTOC] Comments on draft-ietf-tictoc-1588overmpls >>>>>>>=20 >>>>>>> SB> This draft does not seem to provide a precise definition >>>>>>> SB> the properties of the new LSP type that it wishes to >>>>>>> SB> define, in particular it does it define the PHB of those >>>>>>> SB> LSPs, nor the full interaction with the MPLS >>>>>>> SB> architecture. >>>>>>> SB> >>>>>>> SB> I have not tracked TICTOC for a while but I thought that >>>>>>> SB> the original plan was to define the concept of an offset >>>>>>> SB> into a packet to do the correction. >>>>>>> SB> >>>>>>> SB> It is disappointing that the opportunity was not taken >>>>>>> SB> to define a timing shim inside the timing LSP so that >>>>>>> SB> a time correction could be added to any packet such that >>>>>>> SB> the MPLS system was isolated from the details of the >>>>>>> SB> complexity of the particular time transfer type. >>>>>>>=20 >>>>>>> SB> I think that much more clarify is needed in terms of >>>>>>> SB> definition of the new LSP type, since it is unclear >>>>>>> SB> from this text how to implement one. >>>>>>> SB> >>>>>>> SB> There are a lot of other MPLS services such as >>>>>>> SB> LSP ping that need to be considered. >>>>>>> SB> >>>>>>> SB> Please see inline for more comments. However these >>>>>>> SB> comments are made in the context of the text as written >>>>>>> SB> whilst I have a fundamental concern that this approach >>>>>>> SB> lacks an MPLS architectural soundness that need >>>>>>> SB> greater thought with significant impact on the >>>>>>> SB> draft. >>>>>>>=20 >>>>>>> - Stewart >>>>>>>=20 >>>>>>>=20 >>>>>>> TICTOC Working Group S. Da= vari >>>>>>> Internet-Draft A. O= ren >>>>>>> Intended status: Standards Track Broadcom C= orp. >>>>>>> Expires: December 17, 2013 M. Bh= atia >>>>>>> P. Rob= erts >>>>>>> Alcatel-Lu= cent >>>>>>> L. Mon= tini >>>>>>> L. Mar= tini >>>>>>> Cisco Sys= tems >>>>>>> June 15, 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> Transporting Timing messages over MPLS Networks >>>>>>> draft-ietf-tictoc-1588overmpls-05 >>>>>>>=20 >>>>>>> Abstract >>>>>>>=20 >>>>>>> This document defines the method for transporting Timing messages= >>>>>>> such as PTP and NTP over an MPLS network. The method allows for t= he >>>>>>> easy identification of these PDUs at the port level to allow for p= ort >>>>>>>=20 >>>>>>> SB> What is a port >>>>>>>=20 >>>>>>> level processing of these PDUs in both LERs and LSRs. >>>>>>>=20 >>>>>>> The basic idea is to transport Timing messages inside dedicated M= PLS >>>>>>> LSPs. These LSPs only carry Timing messages and possibly Control= and >>>>>>> Management packets, but they do not carry customer traffic. >>>>>>>=20 >>>>>>> SB> More specifically they only carry traffic associated with the >>>>>>> SB> timing service and its support. >>>>>>> SB> The question arose WRT BFD - surely BFD is allowed, BUT surely >>>>>>> SB> also it gets carried in a structure that causes it to get >>>>>>> SB> timestamped. >>>>>>>=20 >>>>>>> Two methods for transporting Timing messages over MPLS are define= d. >>>>>>>=20 >>>>>>> SB> Perhaps the right approach is to define the new LSP type and the= n >>>>>>> SB> seperately to define the mapping of the various timing services= >>>>>>> SB> over that LSP type. >>>>>>>=20 >>>>>>> The first method is to transport Timing messages directly over th= e >>>>>>> dedicated MPLS LSP via UDP/IP encapsulation, which is suitable fo= r >>>>>>> MPLS networks. The second method is to transport Timing messages= >>>>>>> inside a PW via Ethernet encapsulation. >>>>>>>=20 >>>>>>> SB> I think that we should note that there are some >>>>>>> SB> h/w reasons for this preference. A clean sheet approach >>>>>>> SB> would have been to use PTP over MPLS with no intermediate >>>>>>> SB> layers. >>>>>>>=20 >>>>>>> Status of this Memo >>>>>>>=20 >>>>>>> This Internet-Draft is submitted in full conformance with the >>>>>>> provisions of BCP 78 and BCP 79. >>>>>>>=20 >>>>>>> Internet-Drafts are working documents of the Internet Engineering= >>>>>>> Task Force (IETF). Note that other groups may also distribute >>>>>>> working documents as Internet-Drafts. The list of current Intern= et- >>>>>>> Drafts is at http://datatracker.ietf.org/drafts/current/. >>>>>>>=20 >>>>>>> Internet-Drafts are draft documents valid for a maximum of six mo= nths >>>>>>> and may be updated, replaced, or obsoleted by other documents at a= ny >>>>>>> time. It is inappropriate to use Internet-Drafts as reference >>>>>>> material or to cite them other than as "work in progress." >>>>>>>=20 >>>>>>> This Internet-Draft will expire on December 17, 2013. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 1] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> Copyright Notice >>>>>>>=20 >>>>>>> Copyright (c) 2013 IETF Trust and the persons identified as the >>>>>>> document authors. All rights reserved. >>>>>>>=20 >>>>>>> This document is subject to BCP 78 and the IETF Trust's Legal >>>>>>> Provisions Relating to IETF Documents >>>>>>> (http://trustee.ietf.org/license-info) in effect on the date of >>>>>>> publication of this document. Please review these documents >>>>>>> carefully, as they describe your rights and restrictions with res= pect >>>>>>> to this document. Code Components extracted from this document m= ust >>>>>>> include Simplified BSD License text as described in Section 4.e o= f >>>>>>> the Trust Legal Provisions and are provided without warranty as >>>>>>> described in the Simplified BSD License. >>>>>>>=20 >>>>>>>=20 >>>>>>> Table of Contents >>>>>>>=20 >>>>>>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .= 5 >>>>>>>=20 >>>>>>> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .= 7 >>>>>>>=20 >>>>>>> 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . .= 8 >>>>>>>=20 >>>>>>> 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . .= 9 >>>>>>>=20 >>>>>>> 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . .= 12 >>>>>>>=20 >>>>>>> 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . .= 13 >>>>>>> 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . .= 13 >>>>>>> 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . .= 13 >>>>>>> 6.3. Other Timing Encapsulation methods . . . . . . . . . . . .= 14 >>>>>>>=20 >>>>>>> 7. Timing message Processing . . . . . . . . . . . . . . . . . .= 15 >>>>>>>=20 >>>>>>> 8. Protection and Redundancy . . . . . . . . . . . . . . . . . .= 16 >>>>>>>=20 >>>>>>> 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .= 17 >>>>>>>=20 >>>>>>> 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .= 18 >>>>>>>=20 >>>>>>> 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . .= 19 >>>>>>>=20 >>>>>>> 12. OAM, Control and Management . . . . . . . . . . . . . . . . .= 20 >>>>>>>=20 >>>>>>> 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . .= 21 >>>>>>>=20 >>>>>>> 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . .= 22 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 2] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . .= 23 >>>>>>> 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . .= 23 >>>>>>> 15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . .= 23 >>>>>>> 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . .= 24 >>>>>>>=20 >>>>>>> 16. Other considerations . . . . . . . . . . . . . . . . . . . . .= 25 >>>>>>>=20 >>>>>>> 17. Security Considerations . . . . . . . . . . . . . . . . . . .= 26 >>>>>>>=20 >>>>>>> 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .= 27 >>>>>>>=20 >>>>>>> 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . .= 28 >>>>>>>=20 >>>>>>> 20. References . . . . . . . . . . . . . . . . . . . . . . . . . .= 29 >>>>>>> 20.1. Normative References . . . . . . . . . . . . . . . . . . .= 29 >>>>>>> 20.2. Informative References . . . . . . . . . . . . . . . . . .= 29 >>>>>>>=20 >>>>>>> Appendix 1. Routing extensions for Timing-aware Routers . . . . .= 32 >>>>>>>=20 >>>>>>> Appendix 2. Signaling Extensions for Creating Timing LSPs . . . .= 33 >>>>>>>=20 >>>>>>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .= 34 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 3] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >>>> NOT", >>>>>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" >>>> in >>>>>>> this >>>>>>> document are to be interpreted as described in RFC2119 [RFC2119].= >>>>>>>=20 >>>>>>> When used in lower case, these words convey their typical use in >>>>>>> common language, and are not to be interpreted as described in >>>>>>> RFC2119 [RFC2119]. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 4] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 1. Introduction >>>>>>>=20 >>>>>>> The objective of Precision Time Protocol (PTP) and Network Timing= >>>>>>> Protocol (NTP) are to synchronize independent clocks running on >>>>>>> separate nodes of a distributed system. >>>>>>>=20 >>>>>>> [IEEE-1588] defines PTP messages for frequency, phase and time >>>>>>> synchronization. The PTP messages include PTP PDUs over UDP/IP >>>>>>> (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex = F of >>>>>>> [IEEE-1588]). >>>>>>>=20 >>>>>>> SB> Sure BUT it is acknowledged that IEEE is open to the definition >>>>>>> SB> of other PTP mappings if they provide better optimisation. >>>>>>>=20 >>>>>>> This document defines mapping and transport of the PTP >>>>>>> messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP >>>>>>> defines several clock types: ordinary clocks, boundary clocks, en= d- >>>>>>> to-end transparent clocks, and peer-to-peer transparent clocks. >>>>>>> Transparent clocks require intermediate nodes to update correctio= n >>>>>>> field inside PTP message that reflects the transit time in the no= de. >>>>>>>=20 >>>>>>> [RFC5905] defines NTP messages for clock and time synchronization= . >>>>>>> The PTP messages (PDUs) are transported over UDP/IP. This docume= nt >>>>>>> SB> Should that be NTP messages? >>>>>>> SB> It needs to be made clear as soon as you introduce NTP that >>>>>>> SB> they use different time representations. >>>>>>>=20 >>>>>>> defines mapping and transport of the NTP messages defined in >>>>>>> [RFC5905] over MPLS networks. >>>>>>>=20 >>>>>>> One key attribute of all of these Timing messages is that the Tim= e >>>>>>> stamp processing should occur as close as possible to the actual >>>>>>> transmission and reception at the physical port interface. This >>>>>>> targets optimal time and/or frequency recovery by avoiding variab= le >>>>>>> delay introduced by queues internal to the clocks. >>>>>>>=20 >>>>>>> SB> As I recall NTP has no epoch point defined, and I am not sure >>>>>>> SB> where that point is in the case of PTP in this mapping >>>>>>> SB> Hopefully this will get defined in due course. >>>>>>>=20 >>>>>>> To facilitate the fast and efficient recognition of Timing messag= es >>>>>>> at the port level when the Timing messages are carried over MPLS >>>>>>> LSPs, >>>>>>>=20 >>>>>>> SB> Over a new LSP type with time optimied characteristics >>>>>>>=20 >>>>>>> this document defines the specific encapsulations that should >>>>>>> be used. >>>>>>> SB> Hopefully it will also define the PHP >>>>>>>=20 >>>>>>> In addition, it can be expected that there will exist LSR/ >>>>>>> LERs where only a subset of the physical ports will have the port= - >>>>>>> based Timing message processing capabilities. >>>>>>> SB> Do you need to clarify that this only works at base and not in >>>>>>> SB> a label heirarchy. >>>>>>>=20 >>>>>>>=20 >>>>>>> In order to ensure >>>>>>> that the LSPs carrying Timing packets always enter and exit ports= >>>>>>> with this capability, routing extensions are defined to advertise= >>>>>>> this capability on a port basis and to allow for the establishmen= t of >>>>>>> LSPs that only transit such ports. While this path establishment= >>>>>>> restriction may be applied only at the LER Ingress and/or egress >>>>>>> ports, it becomes more important when using transparent clock cap= able >>>>>>> LSRs in the path. >>>>>>> SB> I do not understand the implications of the last >>>>>>> SB> sentences - starting ", it becomes" >>>>>>>=20 >>>>>>>=20 >>>>>>> Port based Timing message processing involves Timing message >>>>>>> recognition. Once the Timing messages are recognized they can be= >>>>>>> modified based on the reception or transmission Time-stamp. >>>>>>>=20 >>>>>>> This document provides two methods for transporting Timing messag= es >>>>>>> over MPLS. One is applicable to MPLS environment and the other o= ne >>>>>>> is applicable to MPLS/MPLS-TP environment >>>>>>>=20 >>>>>>> SB> I think the sentence is incomplete. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 5] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> The solution involves transporting Timing messages over dedicated= >>>>>>> LSPs called Timing LSPs. These LSPs carry Timing messages and MA= Y >>>>>>> carry Management and control messages, but not data plane client >>>>>>> traffic. >>>>>>>=20 >>>>>>> SB> It is not clear why this restriction applies. >>>>>>>=20 >>>>>>> Timing LSPs can be established statically or via signaling. >>>>>>> SB> s/statically/by provisioning/network management/ >>>>>>>=20 >>>>>>> Extensions to control plane (OSPF, ISIS, etc.) is required to ena= ble >>>>>>> routers to distribute their Timing processing capabilities over M= PLS >>>>>>> to other routers. However such extensions are outside the scope o= f >>>>>>> this document. >>>>>>>=20 >>>>>>> When signaling is used to setup the PTP LSP, Extensions to signal= ing >>>>>>> SB> is it a PTP LSP or a Timing LSP? >>>>>>>=20 >>>>>>> protocols (e.g., RSVP-TE) are required for establishing PTP LSPs.= >>>>>>> However such extensions are outside the scope of this document. >>>>>>>=20 >>>>>>> SB> for mpls-tp GMPLS is the signalling protocol >>>>>>>=20 >>>>>>> While the techniques included herein allow for the establishment o= f >>>>>>> paths optimized to include Time-stamping capable links, the >>>>>>> performance of the Slave clocks is outside the scope of this >>>>>>> document. >>>>>>>=20 >>>>>>> At the time of publishing this specification, Transparent Clockin= g >>>>>>> (TC) is only defined for PTP. Therefore at this time any part of= >>>>>>> this specification that talks about Transparent Clocking applies o= nly >>>>>>> to PTP. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 6] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 2. Terminology >>>>>>>=20 >>>>>>> 1588: The timing and synchronization as defined by IEEE 1588. >>>>>>>=20 >>>>>>> SB> I think that there is a more formal name for the 1588 group >>>>>>> SB> that needs to be used here. >>>>>>> SB> Also do we need to talk about 1588-200? as there is >>>>>>> SB> an update in progress >>>>>>>=20 >>>>>>> NTP: The timing and synchronization protocol defined by IETF RFC-= 1305 >>>>>>> and RFC-5905. >>>>>>>=20 >>>>>>> PTP: The timing and synchronization protocol used by 1588. >>>>>>> SB> need the proper name for 1588 >>>>>>>=20 >>>>>>> Master Clock: The source of 1588 timing to a set of slave clocks.= >>>>>>>=20 >>>>>>> Master Port: A port on a ordinary or boundary clock that is in Ma= ster >>>>>>> state. This is the source of timing toward slave ports. >>>>>>>=20 >>>>>>> SB> I am not sure the reader knows what a port is >>>>>>>=20 >>>>>>> Slave Clock: A receiver of 1588 timing from a master clock. >>>>>>>=20 >>>>>>> Slave Port: A port on a boundary clock or ordinary clock that is >>>>>>> receiving timing from a master clock. >>>>>>>=20 >>>>>>> Ordinary Clock: A device with a single PTP port. >>>>>>>=20 >>>>>>> Transparent Clock. A device that measures the time taken for a P= TP >>>>>>> event message to transit the device and then updates the >>>>>>> correctionField of the message with this transit time. >>>>>>>=20 >>>>>>> Boundary Clock: A device with more than one PTP port. Generally >>>>>>> boundary clocks will have one port in slave state to receive timi= ng >>>>>>> and then other ports in master state to re-distribute the timing.= >>>>>>>=20 >>>>>>> PTP LSP: An LSP dedicated to carry PTP messages >>>>>>>=20 >>>>>>> SB> PTP or timing? >>>>>>>=20 >>>>>>>=20 >>>>>>> PTP PW: A PW within a PTP LSP that is dedicated to carry PTP >>>>>>> messages. >>>>>>>=20 >>>>>>> SB> Ah I don't think that PWE3 know what one of these is >>>>>>>=20 >>>>>>> CW: Pseudowire Control Word >>>>>>>=20 >>>>>>> LAG: Link Aggregation >>>>>>>=20 >>>>>>> ECMP: Equal Cost Multipath >>>>>>>=20 >>>>>>> CF: Correction Field, a field inside certain PTP messages (messag= e >>>>>>> type 0-3)that holds the accumulative transit time inside intermed= iate >>>>>>> switches >>>>>>>=20 >>>>>>> Timing messages: Timing Protocol messages that are exchanged >>>> between >>>>>>> routers in order to establish a synchronized clock. >>>>>>>=20 >>>>>>> SB> A number of these definitions look like copies of IEEE1588 >>>>>>> SB> definitions. We need to provide references and note the >>>>>>> SB> priority of the IEEE base reference. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 7] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 3. Problem Statement >>>>>>>=20 >>>>>>> [IEEE-1588] has defined methods for transporting PTP messages ove= r >>>>>>> Ethernet and IP networks. [RFC5905] has defined the method of >>>>>>> transporting NTP messages over IP networks. There is a need to >>>>>>> transport Timing messages over MPLS networks while supporting the= >>>>>>> Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (O= C) >>>>>>> functionality in the LER and LSRs in the MPLS network. >>>>>>>=20 >>>>>>> There are multiple ways of transporting Timing over MPLS. Howeve= r, >>>>>>> there is a requirement to limit the possible encapsulation option= s to >>>>>>> simplify the Timing message identification and processing require= d at >>>>>>> the port level. >>>>>>>=20 >>>>>>> When Timing-awareness is needed, Timing messages should not be >>>>>>> transported over LSPs or PWs that are carrying customer traffic >>>>>>> because LSRs perform Label switching based on the top label in th= e >>>>>>> stack. >>>>>>>=20 >>>>>>> SB> Have you explained why? >>>>>>>=20 >>>>>>> To detect Timing messages inside such LSPs require special >>>>>>> hardware to do deep packet inspection at line rate. Even if such= >>>>>>> hardware exists, the payload can't be deterministically identifie= d by >>>>>>> LSRs because the payload type is a context of the PW label, and t= he >>>>>>> PW label and its context are only known to the Edge routers (PEs/= >>>>>>> LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, C= ES, >>>>>>> etc). Even if one restricts an LSP to only carry Ethernet PWs, t= he >>>>>>> LSRs dont have the knowledge of whether PW Control Word (CW) is >>>>>>> present or not and therefore can not deterministically identify t= he >>>>>>> payload. >>>>>>>=20 >>>>>>> A generic method is defined in this document that does not requir= e >>>>>>> deep packet inspection at line rate, and can deterministically >>>>>>> identify Timing messages. This method can be used to detect Timi= ng >>>>>>> Messages in both one-step and two-step clock implementations of >>>>>>> ordinary, boundary and transparent clocks. >>>>>>>=20 >>>>>>> SB> Needs a ref and I am sure many MPLS specialists will not underst= and >>>>>>> SB> the msg types. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 8] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 4. Timing over MPLS Architecture >>>>>>>=20 >>>>>>> Timing messages are exchange between Timing ports on ordinary and= >>>>>>>=20 >>>>>>> SB> Have you defined a timing port? >>>>>>>=20 >>>>>>> boundary clocks. Boundary clocks terminate the Timing messages a= nd >>>>>>> act as master for other boundary clocks or for slave clocks. End= -to- >>>>>>> End Transparent clocks do not terminate the Timing messages but t= hey >>>>>>> do modify the contents of the Timing messages as they transit acr= oss >>>>>>> the transparent clock. >>>>>>>=20 >>>>>>> Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent C= lock >>>>>>>=20 >>>>>>> (TC) could be implemented in either LERs or LSRs. >>>>>>>=20 >>>>>>> SB> LER and LSR need to be expanded >>>>>>>=20 >>>>>>> An example is shown in Figure 1, where the LERs act as Ordinary C= lock >>>>>>> (OC) and are the initiating/terminating point for Timing messages= . >>>>>>> The ingress LER encapsulates the Timing messages in Timing LSP an= d >>>>>>> the Egress LER terminates the Timing LSP. The LSRs act as >>>>>>> Transparent Clock (TC) and just update the Timing field in the Ti= ming >>>>>>> messages. >>>>>>>=20 >>>>>>>=20 >>>>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ >>>>>>> |Switch, | | | | | | | |Swit= ch, | >>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rou= ter | >>>>>>> | | | OC | | TC | | OC | | = | >>>>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ >>>>>>> / \ >>>>>>> +-------+ / \ +-----= --+ >>>>>>> | LER | / \ | LER= | >>>>>>> | Master|---/ \---| Slav= e | >>>>>>> | Clock | | Cloc= k | >>>>>>> +-------+ +-----= --+ >>>>>>>=20 >>>>>>> Figure (1) - Deployment example 1 of timing over MPLS network >>>>>>>=20 >>>>>>> Another example is shown in Figure2, where LERs terminate the Tim= ing >>>>>>> messages received from switch/routers that are outside of the MPL= S >>>>>>> network acting as OC or BC. In this example LERs regenerate the >>>>>>> clock and initiate timing messages encapsulated in Timing LSP tow= ard >>>>>>> the MPLS network, while the LSRs act as Transparent Clock (TC) an= d >>>>>>> just update the Timing field in the Timing messages, which are >>>>>>> already encapsulated in Timing LSPs. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 9] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ >>>>>>> |Switch, | | | | | | | |Switc= h, | >>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rout= er | >>>>>>> | OC/BC | | BC | | TC | | BC | | OC/B= C | >>>>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ >>>>>>>=20 >>>>>>> Figure (2) - Deployment example 2 of timing over MPLS network >>>>>>>=20 >>>>>>>=20 >>>>>>> Another example is shown in Figure 3, where LERs do not terminate= the >>>>>>> Timing messages received from switch/routers that are outside of t= he >>>>>>> MPLS network acting as OC, TC or BC. The LERs act as TC and upda= te >>>>>>> the Timing field in the Timing messages as they transit the LER, >>>>>>> while encapsulating them in timing LSP. The LSRs also act as >>>>>>> Transparent Clock (TC) and just update the Timing field in the Ti= ming >>>>>>> messages which are already encapsulated in Timing LSPs. >>>>>>>=20 >>>>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ >>>>>>> |Switch, | | | | | | | |Swit= ch, | >>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rou= ter | >>>>>>> |OC/TC/BC| | TC | | TC | | TC | |OC/T= C/BC| >>>>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ >>>>>>>=20 >>>>>>> Figure (3) - Deployment example 3 of timing over MPLS network >>>>>>>=20 >>>>>>> Another example is shown in Figure 4, where LERs and LSRs support= >>>>>>> Boundary Clocks. A single-hop LSP is created between two adjacen= t >>>>>>> LSRs engaged in BC operation. Other methods such as PTP transpor= t >>>>>>> over Ethernet MAY be used for transporting timing messages if the= >>>>>>> link between the two routers is Ethernet. >>>>>>>=20 >>>>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ >>>>>>> |Switch, | | | | | | | |Switc= h, | >>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rout= er | >>>>>>> | OC/BC | | BC | | BC | | BC | | OC/B= C | >>>>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ >>>>>>>=20 >>>>>>> Figure (4) - Deployment example 3 of timing over MPLS network >>>>>>>=20 >>>>>>> An MPLS domain MAY serve multiple customers. In these cases the >>>> MPLS >>>>>>> domain (maintained by a service provider) may provide timing serv= ices >>>>>>> to multiple customers, each having their own Timing domain. >>>>>>>=20 >>>>>>> The Timing over MPLS architecture assumes full mesh of Timing LSP= s >>>>>>> between all LERs supporting this specification. >>>>>>>=20 >>>>>>> SB> Note sure this is right - the salves surely do not need to >>>>>>> SB> exchange timing amongst themselves >>>>>>>=20 >>>>>>> It supports >>>>>>> Point-to- point (VPWS) and Multipoint (VPLS) services. >>>>>>>=20 >>>>>>> SB> What does that mean? You do not carry user data traffic? >>>>>>> SB> Maybe it's the ordering of the statemnets that is causing >>>>>>> SB> confusion. >>>>>>>=20 >>>>>>> This means >>>>>>> that a customer may purchase a Point-to-point Timing service betw= een >>>>>>> two customer sites or a Multipoint Timing service between more th= an >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 10] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> two customer sites. >>>>>>>=20 >>>>>>> The Timing over MPLS architecture supports P2P or P2MP Timing LSP= s. >>>>>>> This means that the Timing Multicast messages such as PTP Multica= st >>>>>>> event messages can be transported over P2MP Timing LSP or be >>>>>>> replicated and transported over many P2P Timing LSPs. >>>>>>>=20 >>>>>>> SB> Note we do not yet have a definition of a P2MP mpls-tp LSP >>>>>>> SB> nor a P2MP PW, although we are close. >>>>>>>=20 >>>>>>> Timing messages, that do not require Time stamping or Correction >>>>>>> Field update MAY be transported over Timing LSPs to simplify hard= ware >>>>>>> and software. >>>>>>>=20 >>>>>>> PTP Announce messages that determine the Timing LSP terminating >>>> point >>>>>>> behavior such as BC/OC/TC SHOULD be transported over the Timing L= SP >>>>>>> to simplify hardware and software. >>>>>>>=20 >>>>>>> SB> have you defined and referenced PTP announce msgs? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 11] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 5. Dedicated LSPs for Timing messages >>>>>>>=20 >>>>>>> Many methods have been considered for identifying the Timing >>>> messages >>>>>>> when they are encapsulated in MPLS such as using GAL/G-ACH or a n= ew >>>>>>> reserved label. These methods were not attractive since they eit= her >>>>>>> required deep packet inspection at line rate in the intermediate L= SRs >>>>>>> or they required use of a scarce new reserved label. Also one of= the >>>>>>> goals was to reuse existing OAM mechanisms. >>>>>>>=20 >>>>>>> SB> RLs =3D SPLs are not so rare now. In any case needs a ref. >>>>>>>=20 >>>>>>> The method defined in this document can be used by LER and LSRs t= o >>>>>>> identify Timing messages in MPLS tunnels by just looking at the t= op >>>>>>> label in the MPLS label stack, which only carry Timing messages a= s >>>>>>> well as OAM, but not data plane client traffic. >>>>>>>=20 >>>>>>> Compliant implementations MUST use dedicated LSPs to carry Timing= >>>>>>> messages over MPLS. >>>>>>>=20 >>>>>>> SB> I think that we need a definition of the properies of these LSPs= >>>>>>>=20 >>>>>>> These LSPs are herein referred to as "Timing >>>>>>> LSPs" and the labels associated with these LSPs as "Timing LSP >>>>>>> labels". The Timing LSPs that runs between Ingress and Egress LE= Rs >>>>>>> MUST be co-routed. Alternatively, a single bidirectional co-rout= ed >>>>>>> LSP can be used. >>>>>>>=20 >>>>>>> SB> I though that you said you could use M2MP LSPs - these are not >>>>>>> SB> bidirectional. >>>>>>>=20 >>>>>>> Co-routing of the two directions is required to limit the differe= nce >>>>>>> in the delays in the Master clock to Slave clock direction compar= ed >>>>>>> to the Slave clock to Master clock direction. The Timing LSP MAY= be >>>>>>> MPLS/MPLS-TP LSP. >>>>>>>=20 >>>>>>> The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS= . >>>>>>> New Extensions to RSVP-TE/GMPLS TLVs are required; however they a= re >>>>>>> outside the scope of this document. >>>>>>>=20 >>>>>>> The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such= as >>>>>>> BFD and LSP Ping but the LSP data plane client plane traffic MUST= be >>>>>>> Timing packets only. >>>>>>>=20 >>>>>>> SB> Why? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 12] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 6. Timing over LSP Encapsulation >>>>>>>=20 >>>>>>> The encapsulations is not LSP is it? >>>>>>>=20 >>>>>>> This document defines two methods for carrying Timing messages ov= er >>>>>>> MPLS. The first method is carrying UDP/IP encapsulated Timing >>>>>>> messages over Timing LSPs, and the second method, is carrying >>>>>>> Ethernet encapsulated Timing messages over Ethernet PWs inside >>>> Timing >>>>>>> LSPs. >>>>>>>=20 >>>>>>> 6.1. Timing over UDP/IP over MPLS Encapsulation >>>>>>>=20 >>>>>>> The simplest method of transporting Timing messages over MPLS is t= o >>>>>>> encapsulate Timing PDUs in UDP/IP and then encapsulate them in >>>> Timing >>>>>>> LSP. This format is shown in Figure 4. >>>>>>>=20 >>>>>>>=20 >>>>>>> +----------------------+ >>>>>>> | Timing LSP Label | >>>>>>> +----------------------+ >>>>>>> | IPv4/6 | >>>>>>> +----------------------+ >>>>>>> | UDP | >>>>>>> +----------------------+ >>>>>>> | Timing PDU | >>>>>>> +----------------------+ >>>>>>>=20 >>>>>>> Figure (4) - Timing over UDP/IP over MPLS Encapsulation >>>>>>>=20 >>>>>>>=20 >>>>>>> This encapsulation is very simple and is useful when the network >>>>>>> between Timing Master Clock and Slave Clock is MPLS network. >>>>>>>=20 >>>>>>> SB> Simple is a judgement call >>>>>>>=20 >>>>>>> In order for an LER/LSR to process Timing messages, the Timing LS= P >>>>>>> Label must be at the top label of the label stack. The LER/LSR M= UST >>>>>>> know that the Timing LSP Label is used for carrying Timing messag= es. >>>>>>> This can be accomplished via static configuration or via RSVP-TE >>>>>>> signaling. >>>>>>>=20 >>>>>>> The UDP/IP encapsulation of PTP MUST follow Annex D and E of >>>>>>> [IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow >>>>>>> [RFC5905]. >>>>>>>=20 >>>>>>> 6.2. Timing over PW Encapsulation >>>>>>>=20 >>>>>>> Another method of transporting Timing over MPLS networks is by >>>>>>> encapsulating Timing PDUs in PW which in turn is transported over= >>>>>>> Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448]= , >>>>>>> shown in Fig 5(A) MUST be used and the Ethernet encapsulation of P= TP >>>>>>> MUST follow Annex F of [IEEE-1588]. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 13] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> The RAW mode or Tagged mode defined in [RFC4448] MAY be used and >>>> the >>>>>>> Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The >>>>>>> Timing over PW encapsulation MUST use the Control Word (CW) as >>>>>>> specified in [RFC4448] to ensure proper detection of PTP messages= >>>>>>> inside the MPLS packets for Timing over LSP and Timing over PW >>>>>>> encapsulation. >>>>>>>=20 >>>>>>> SB> That needs explanation >>>>>>>=20 >>>>>>> The use of Sequence Number in the CW is optional. >>>>>>>=20 >>>>>>> SB> Given that s/n are never in practice deployed, you could probabl= y >>>>>>> SB> simplify things by sayig that they are not used. >>>>>>>=20 >>>>>>> Timing over PW encapsulation for NTP MUST use NTP over UDP/IP ove= r >>>> PW >>>>>>> (the IP PW discussed in [RFC4447]) shown in Fig 5(B). >>>>>>>=20 >>>>>>> +----------------+ +----------------+ >>>>>>> |Timing LSP Label| |Timing LSP Label| >>>>>>> +----------------+ +----------------+ >>>>>>> | PW Label | | PW Label | >>>>>>> +----------------+ +----------------+ >>>>>>> | Control Word | | IP | >>>>>>> +----------------+ +----------------+ >>>>>>> | Ethernet | | UDP | >>>>>>> | Header | +----------------+ >>>>>>> +----------------+ | Timing PDU | >>>>>>> |S-VLAN(Optional)| | | >>>>>>> +----------------+ +----------------+ >>>>>>> |C-VLAN(Optional)| (B) >>>>>>> +----------------+ >>>>>>> | Timing PDU | >>>>>>> | | >>>>>>> +----------------+ >>>>>>> (A) >>>>>>>=20 >>>>>>> Figure (5) - Timing over PW Encapsulations >>>>>>>=20 >>>>>>> In order for an LSR to process PTP messages, the top label of the= >>>>>>> label stack (the Tunnel Label) MUST be a Timing label. >>>>>>>=20 >>>>>>> S> You said that before. >>>>>>>=20 >>>>>>> 6.3. Other Timing Encapsulation methods >>>>>>>=20 >>>>>>> In future other timing encapsulation methods may be introduced, s= uch >>>>>>> as a new shim header after the Bottom of Stack to carry the Timin= g >>>>>>> information. Such new encapsulations are outside the scope of th= is >>>>>>> document. >>>>>>>=20 >>>>>>>=20 >>>>>>> SB> Taking a pure MPLS pov, you can simplify a lot of the text >>>>>>> SB> out of the definition of the LSP >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 14] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> SB> I think we need a section on LSP processing >>>>>>>=20 >>>>>>> 7. Timing message Processing >>>>>>>=20 >>>>>>> Each Timing protocol such as PTP and NTP, define their set of Tim= ing >>>>>>> messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, >>>>>>> FOLLOW_UP, etc messages. >>>>>>>=20 >>>>>>> Some of the Timing messages require time stamping or correction f= ield >>>>>>> update at port level and some dont. It is the job of the LER/LSR= to >>>>>>> parse the timing message and find out the type of the Timing mess= age >>>>>>> and decide whether and how to Time- stamp it (e.g., BC) or update= >>>>>>> correction field(e.g., TC). >>>>>>>=20 >>>>>>>=20 >>>>>>> SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing >>>>>>> SB> function rather than the LER? >>>>>>>=20 >>>>>>> For example the following PTP messages (called Event messages) >>>>>>> require time-stamping or correction field update: >>>>>>>=20 >>>>>>> o SYNC >>>>>>>=20 >>>>>>> o DELAY_REQ (Delay Request) >>>>>>>=20 >>>>>>> o PDELAY_REQ (Peer Delay Request) >>>>>>>=20 >>>>>>> o PDELAY_RESP (Peer Delay Response) >>>>>>>=20 >>>>>>> SYNC and DELAY_REQ are exchanged between Master Clock and Slave >>>> Clock >>>>>>> and MUST be transported over PTP LSPs. PDELAY_REQ and >>>> PDELAY_RESP >>>>>>> are exchanged between adjacent PTP clocks (i.e. Master, Slave, >>>>>>> Boundary, or Transparent) and SHOULD be transported over single h= op >>>>>>> PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP= , >>>>>>> and PDELAY_RESP_FOLLOW_UP messages MUST also be transported >>>> over >>>>>>> the >>>>>>> PTP LSPs. >>>>>>>=20 >>>>>>> For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be= >>>>>>> transported over two PTP LSPs that are in opposite directions. T= hese >>>>>>> PTP LSPs, which are in opposite directions MUST be congruent and c= o- >>>>>>> routed. Alternatively, a single bidirectional co-routed LSP can b= e >>>>>>> used. >>>>>>>=20 >>>>>>> Except as indicated above for the two-step PTP clocks, Non-Event P= TP >>>>>>> message types do not need to be processed by intermediate routers= . >>>>>>> These message types MAY be carried in PTP Tunnel LSPs. >>>>>>>=20 >>>>>>> SB> Are you saying that a timing P router has to be msg type sensiti= ve? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 15] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 8. Protection and Redundancy >>>>>>>=20 >>>>>>>=20 >>>>>>> SB> This is a bit of a jump - I don't know how the LSP itself works y= et! >>>>>>>=20 >>>>>>> In order to ensure continuous uninterrupted operation of slave >>>>>>> clocks, usually as a general practice, slave clocks (or ports) tr= ack >>>>>>> redundant master clocks. >>>>>>>=20 >>>>>>> It is the responsibility of the network operator to ensure that >>>>>>> physically disjoint Timing LSPs are established between a slave c= lock >>>>>>> (or port) and redundant master clocks (or ports). >>>>>>>=20 >>>>>>> When a slave clock (or port) listens to redundant master clocks o= r >>>>>>> ports, any prolonged Timing LSP outage will trigger the slave clo= ck >>>>>>> or port to switch to a redundant master clock or port. >>>>>>>=20 >>>>>>> LSP/PW protection such as Linear protection Switching (1:1, 1+1),= >>>>>>> Ring protection switching or MPLS Fast Reroute (FRR) generally sw= itch >>>>>>> alternative path that usually cause a change in delay, which if >>>>>>> undetected by slave clock can reduce accuracy of the slave clock.= >>>>>>>=20 >>>>>>> Therefore protection switching MAY be used, as long as phase jump= s >>>>>>> upon switchover due to differences in path latency are detected a= nd >>>>>>> compensated for (such compensation not being required if BCs or p= eer- >>>>>>> peer TCs are used throughout). >>>>>>>=20 >>>>>>> Note that any protection or reroute mechanism that adds additiona= l >>>>>>> MPLS label to the label stack, such as Facility Backup Fast Rerou= te, >>>>>>> MUST ensure that the pushed label is also a Timing Label to ensur= e >>>>>>> recognition of the MPLS frame as containing Timing messages, as i= t >>>>>>> transits the backup path. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 16] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 9. ECMP >>>>>>>=20 >>>>>>> To ensure the optimal operation of slave clocks and avoid error >>>>>>> introduced by forward and reverse path delay asymmetry, the physi= cal >>>>>>> path for Timing messages from master clock to slave Clock and vic= e >>>>>>> versa must be the same for all Event Timing messages listed in >>>>>>> section 7. >>>>>>>=20 >>>>>>> Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost= >>>>>>> Multipath). >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 17] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 10. PHP >>>>>>>=20 >>>>>>> To ensure that the label on the top of the label stack is the Tim= ing >>>>>>> LSP Label, PHP MUST not be used. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 18] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 11. Entropy >>>>>>>=20 >>>>>>> To ensure all Timing messages in a Timing LSP take the same path,= >>>>>>> Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and >>>>>>> Entropy Label MUST NOT be used for the PWs that are carried insid= e >>>>>>> Timing LSP [RFC6391]. >>>>>>>=20 >>>>>>> SB> This is incorrect - you mean that all msgs of the same timing >>>>>>> SB> flow need to have the same EL value. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 19] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 12. OAM, Control and Management >>>>>>>=20 >>>>>>> In order to monitor Timing LSPs and their encapsulated PWs, they M= UST >>>>>>> be able to carry OAM and management messages. These management >>>>>>> messages MUST be differentiated from Timing messages via already >>>>>>> defined IETF methods. >>>>>>>=20 >>>>>>> For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY r= un >>>>>>> over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These >>>>>>> Management protocols can easily be identified by the UDP Destinat= ion >>>>>>> Port number or by GAL/G-ACH respectively. >>>>>>>=20 >>>>>>> Also BFD, LSP-Ping and other management messages MAY run over the= >>>> PWs >>>>>>> encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3= or >>>>>>> 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is g= oing >>>>>>> to be deprecated by IETF). In this case G-ACH, PW label (TTL=3D1= ) or >>>>>>> GAL-ACH are used to identify such management messages. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 20] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 13. QoS Considerations >>>>>>>=20 >>>>>>> In network deployments where not every LSR/LER is Timing-aware, i= t is >>>>>>> important to reduce the impact of the non-Timing-aware LSR/LERs o= n >>>>>>> the timing recovery in the slave clock. The Timing messages are t= ime >>>>>>> critical and must be treated with the highest priority. Therefor= e >>>>>>> Timing over MPLS messages must be treated with the highest priori= ty >>>>>>> in the routers. This can be achieved by proper setup of Timing L= SPs. >>>>>>>=20 >>>>>>> It is recommended that the Timing LSPs are setup or configured >>>>>>> properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC26= 97] >>>>>>> for drop eligibility. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 21] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 14. FCS and Checksum Recalculation >>>>>>>=20 >>>>>>> When time-stamp generation and timing packet adjustment is perfor= med >>>>>>> near the physical port hardware, the process MUST include >>>>>>> recalculation of the Ethernet FCS. >>>>>>>=20 >>>>>>> SB> The above is confusing - an LSR always recomputes the link layer= >>>>>>> SB> CRC which may or may not be Ethernet. >>>>>>>=20 >>>>>>> Also FCS retention for the >>>>>>> payload Ethernet described in [RFC4720] MUST NOT be used. >>>>>>>=20 >>>>>>> For UDP/IP encapsulation mode of Timing over MPLS, the UDP checks= um >>>>>>> may be required as per UDP transport standards. >>>>>>>=20 >>>>>>> SB> You really need to be working on getting the IPv6 C?S computatio= n >>>>>>> SB> removed from PTP msgs. >>>>>>>=20 >>>>>>> When UDP checksum is used, each Timing-aware LER/LSR must either >>>>>>> incrementally update the UDP checksum after Time stamping or >>>>>>> Correction Field update or verify the UDP checksum on reception f= rom >>>>>>> upstream and recalculate the checksum completely on transmission t= o >>>>>>> downstream node after Time stamping or Correction Field update. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 22] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 15. Behavior of LER/LSR >>>>>>>=20 >>>>>>> Timing-capable/aware LERs and LSRs are routers that have one or m= ore >>>>>>>=20 >>>>>>> SB> You mean physical interfaces? >>>>>>>=20 >>>>>>> interfaces that can perform Timing operations (OC/BC/TC) on Timin= g >>>>>>> packets and are configured to do so. Timing-capable/aware LERs a= nd >>>>>>> LSRs can advertise their Timing-capability per-interface via cont= rol >>>>>>> plane such as OSPF or IS-IS. >>>>>>> SB> ISIS and OSPF are routing protocols. >>>>>>>=20 >>>>>>> The Timing-capable/aware LERs can then >>>>>>> signals Timing LSPs via RSVP-TE signaling. Alternatively the Tim= ing >>>>>>> capability of LER and LSRs may be configured in a centralized >>>>>>> controller and the Timing LSP may be setup using manual configura= tion >>>>>>> or other methods such as SDN. >>>>>>>=20 >>>>>>> SB> it can also be configured individually rather then through >>>>>>> SB> a cebtral controllwe >>>>>>>=20 >>>>>>> 15.1. Behavior of Timing-capable/aware LER >>>>>>>=20 >>>>>>> When a Timing-capable/aware LER behaves as a Transparent clock an= d >>>>>>> receives a Timing message from a Timing-capable/aware non-MPLS >>>>>>> interface, the LER updates the Correction Field (CF) and encapsul= ates >>>>>>> and forwards the timing message over previously established Timin= g >>>>>>> LSP. >>>>>>>=20 >>>>>>> SB> You need to call out the details so that people properly >>>>>>> SB> understand the definition of the new LSP. >>>>>>>=20 >>>>>>> Also when a Timing message is received from a Timing-capable/ >>>>>>> aware MPLS interface, LER updates the Correction Filed (CF) and >>>>>>> decapsulates the MPLS encapsulation and forwards the timing messa= ge >>>>>>> to a non-MPLS interface. >>>>>>>=20 >>>>>>> When a Timing-capable/aware LER behaves as a Boundary clock and >>>>>>> receives a Timing message from a Timing-capable/aware non MPLS >>>>>>> interface, the LER Timestamps the Timing packet and sends it to t= he >>>>>>> LERs Boundary clock processing module. Also when a Timing messag= e is >>>>>>> received from a Timing- capable/aware MPLS interface, the LER >>>>>>> Timestamps the Timing packet and sends it to the LERs Boundary cl= ock >>>>>>> processing module. >>>>>>>=20 >>>>>>> When a Timing-capable/aware LER behaves as an Ordinary Clock towa= rd >>>>>>> the MPLS network, and receives a Timing message from a Timing- >>>>>>> capable/aware MPLS interface, the LER Timestamps the Timing packe= t >>>>>>> and sends it to the LERs Ordinary clock processing module. >>>>>>>=20 >>>>>>> 15.2. Behavior of Timing-capable/aware LSR >>>>>>>=20 >>>>>>> When a Timing-capable/aware LSR behaves as a Transparent clock an= d >>>>>>> receives a Timing message from a Timing-capable/aware MPLS >>>> interface, >>>>>>> The LSR updates the Correction Filed (CF) and forwards the timing= >>>>>>> message over another MPLS interface. >>>>>>>=20 >>>>>>> When a Timing-capable/aware LSR behaves as a Boundary clock and >>>>>>> receives a Timing message from a Timing-capable/aware MPLS >>>> interface. >>>>>>> The LSR performs the functions of a Boundary Clock in terminating= the >>>>>>> received Timing message and re-generating a new timing message ov= er >>>>>>> another (or the same) MPLS interface. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 23] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 15.3. Behavior of non-Timing-capable/aware LSR >>>>>>>=20 >>>>>>> It is most beneficial when all LSRs in the path of a Timing LSP b= e >>>>>>> timing-Capable/aware LSRs. This would ensure the highest quality= >>>>>>> time and clock synchronization by Timing Slave Clocks. However, t= his >>>>>>> specification does not mandate that all LSRs in path of a Timing L= SP >>>>>>> be Timing- capable/aware. >>>>>>>=20 >>>>>>> Non-Timing-capable/aware LSRs just switch the packets encapsulate= d in >>>>>>> Timing LSPs and dont perform any Timing operation (TC or BC). >>>>>>> However as explained in QoS section the Timing over MPLS packets >>>> MUST >>>>>>> be still be treated with the highest priority based on their Traf= fic >>>>>>> Class (TC) marking. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 24] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 16. Other considerations >>>>>>>=20 >>>>>>> [IEEE-1588] defines an optional peer-to-peer Transparent clocking= >>>>>>> that requires peer delay measurement between two adjacent Timing-= >>>>>>> capable/ aware routers/switches. Peer delay measurement messages= >>>>>>> need to be time stamped and terminated by the Timing-capable/awar= e >>>>>>> routers/ switches. This means that two adjacent LSRs may be enga= ged >>>>>>> in a peer delay measurement. >>>>>>>=20 >>>>>>> For transporting such peer delay measurement messages a single-ho= p >>>>>>> LSP SHOULD to be created between the two adjacent LSRs engaged in= >>>>>>> peer delay measurement to carry peer delay measurement messages. >>>>>>> Other methods such as PTP transport over Ethernet MAY be used for= >>>>>>> transporting peer delay measurement messages if the link between t= he >>>>>>> two routers is Ethernet. >>>>>>>=20 >>>>>>> In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ w= are >>>>>>> routers/switches MUST maintain a list of all the neighbors it nee= ds >>>>>>> to send a PDelay_Req to, where each neighbor corresponds to a tim= ing >>>>>>> LSP. >>>>>>>=20 >>>>>>> The use of Explicit Null Label (Label=3D 0 or 2) is acceptable as= long >>>>>>> as either the Explicit Null label is the bottom of stack label >>>>>>> (applicable only to UDP/IP encapsulation) or the label below the >>>>>>> Explicit Null label is a PTP label. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 25] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 17. Security Considerations >>>>>>>=20 >>>>>>> MPLS PW security considerations in general are discussed in [RFC3= 985] >>>>>>> and [RFC4447],and those considerations also apply to this documen= t. >>>>>>>=20 >>>>>>> An experimental security protocol is defined in [IEEE-1588].The P= TP >>>>>>> security extension and protocol provides group source authenticat= ion, >>>>>>> message integrity, and replay attack protection for PTP messages.= >>>>>>>=20 >>>>>>> When the MPLS network (provider network) serves multiple customer= s, >>>>>>> it is important to maintain and process each customers clock and >>>>>>> Timing messages separately from other customers to ensure there i= s no >>>>>>> cross- customer effect. For example if an LER BC is synchronized= to >>>>>>> a specific grandmaster, belonging to customer A, then the LER MUS= T >>>>>>> use that BC clock only for customer A to ensure that customer A >>>>>>> cannot attack other customers by manipulating its time. >>>>>>>=20 >>>>>>> Timing messages MAY be encrypted or authenticated, provided that t= he >>>>>>> LERs/LSRs that are Timing capable/aware can authenticate/ decrypt= the >>>>>>> timing messages. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 26] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 18. Acknowledgements >>>>>>>=20 >>>>>>> The authors would like to thank Ron Cohen, Yaakov Stein, Tal Mizr= ahi, >>>>>>> Stefano Ruffini, Peter Meyer, and other members of IETF for revie= wing >>>>>>> and providing feedback on this draft. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 27] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 19. IANA Considerations >>>>>>>=20 >>>>>>> There are no IANA requirements in this specification. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 28] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 20. References >>>>>>>=20 >>>>>>> 20.1. Normative References >>>>>>>=20 >>>>>>> [IEEE-1588] >>>>>>> IEEE 1588-2008, "IEEE Standard for a Precision Clock >>>>>>> Synchronization Protocol for Networked Measurement and= >>>>>>> Control Systems". >>>>>>>=20 >>>>>>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >>>>>>> Requirement Levels", BCP 14, RFC 2119, March 1997. >>>>>>>=20 >>>>>>> [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to= - >>>>>>> Edge (PWE3) Architecture", RFC 3985, March 2005. >>>>>>>=20 >>>>>>> [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discov= ery >>>>>>> Proxies (ND Proxy)", RFC 4389, April 2006. >>>>>>>=20 >>>>>>> [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G= . >>>>>>> Heron, "Pseudowire Setup and Maintenance Using the Lab= el >>>>>>> Distribution Protocol (LDP)", RFC 4447, April 2006. >>>>>>>=20 >>>>>>> [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, >>>>>>> "Encapsulation Methods for Transport of Ethernet over M= PLS >>>>>>> Networks", RFC 4448, April 2006. >>>>>>>=20 >>>>>>> [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire >>>>>>> Emulation Edge-to-Edge (PWE3) Frame Check Sequence >>>>>>> Retention", RFC 4720, November 2006. >>>>>>>=20 >>>>>>> [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circu= it >>>>>>> Connectivity Verification (VCCV): A Control Channel fo= r >>>>>>> Pseudowires", RFC 5085, December 2007. >>>>>>>=20 >>>>>>> [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detect= ion >>>>>>> (BFD)", RFC 5880, June 2010. >>>>>>>=20 >>>>>>> [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow= , >>>>>>> "Bidirectional Forwarding Detection (BFD) for MPLS Lab= el >>>>>>> Switched Paths (LSPs)", RFC 5884, June 2010. >>>>>>>=20 >>>>>>> 20.2. Informative References >>>>>>>=20 >>>>>>> [I-D.ietf-pwe3-fat-pw] >>>>>>> Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Reg= an, >>>>>>> J., and S. Amante, "Flow Aware Transport of Pseudowire= s >>>>>>> over an MPLS Packet Switched Network", >>>>>>> draft-ietf-pwe3-fat-pw-07 (work in progress), July 201= 1. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 29] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermedia= te >>>>>>> system routeing information exchange protocol for use i= n >>>>>>> conjunction with the Protocol for providing the >>>>>>> Connectionless-mode Network Service (ISO 8473)". >>>>>>>=20 >>>>>>> [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP an= d >>>>>>> dual environments", RFC 1195, December 1990. >>>>>>>=20 >>>>>>> [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 199= 8. >>>>>>>=20 >>>>>>> [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color= >>>>>>> Marker", RFC 2697, September 1999. >>>>>>>=20 >>>>>>> [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boud= ec, >>>>>>> J., Courtney, W., Davari, S., Firoiu, V., and D. >>>>>>> Stiliadis, "An Expedited Forwarding PHB (Per-Hop >>>>>>> Behavior)", RFC 3246, March 2002. >>>>>>>=20 >>>>>>> [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Enginee= ring >>>>>>> (TE) Extensions to OSPF Version 2", RFC 3630, >>>>>>> September 2003. >>>>>>>=20 >>>>>>> [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermedia= te >>>>>>> System (IS-IS) Extensions for Traffic Engineering (TE)= ", >>>>>>> RFC 3784, June 2004. >>>>>>>=20 >>>>>>> [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S= . >>>>>>> Shaffer, "Extensions to OSPF for Advertising Optional >>>>>>> Router Capabilities", RFC 4970, July 2007. >>>>>>>=20 >>>>>>> [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate= >>>>>>> System to Intermediate System (IS-IS) Extensions for >>>>>>> Advertising Router Information", RFC 4971, July 2007. >>>>>>>=20 >>>>>>> [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi= >>>>>>> Topology (MT) Routing in Intermediate System to >>>>>>> Intermediate Systems (IS-ISs)", RFC 5120, February 200= 8. >>>>>>>=20 >>>>>>> [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic >>>>>>> Engineering", RFC 5305, October 2008. >>>>>>>=20 >>>>>>> [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, >>>>>>> "Traffic Engineering Extensions to OSPF Version 3", >>>>>>> RFC 5329, September 2008. >>>>>>>=20 >>>>>>> [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSP= F >>>>>>> for IPv6", RFC 5340, July 2008. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 30] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Net= work >>>>>>> Time Protocol Version 4: Protocol and Algorithms >>>>>>> Specification", RFC 5905, June 2010. >>>>>>>=20 >>>>>>> [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Reg= an, >>>>>>> J., and S. Amante, "Flow-Aware Transport of Pseudowire= s >>>>>>> over an MPLS Packet Switched Network", RFC 6391, >>>>>>> November 2011. >>>>>>>=20 >>>>>>> [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., a= nd >>>>>>> L. Yong, "The Use of Entropy Labels in MPLS Forwarding= ", >>>>>>> RFC 6790, November 2012. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 31] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 1. Routing extensions for Timing-aware Routers >>>>>>>=20 >>>>>>> MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] a= nd >>>>>>> IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (= TE) >>>>>>> link information used for constraint-based routing. >>>>>>>=20 >>>>>>> Indeed, it is useful to advertise data plane TE router link >>>>>>> capabilities, such as the capability for a router to be Timing-aw= are. >>>>>>> This capability MUST then be taken into account during path >>>>>>> computation to prefer or even require links that advertise themse= lves >>>>>>> as Timing-aware. In this way the path can ensure the entry and e= xit >>>>>>> points into the LERs and, if desired, the links into the LSRs are= >>>>>>> able to perform port based time-stamping thus minimizing their im= pact >>>>>>> on the performance of the slave clock. >>>>>>>=20 >>>>>>> extensions are required to OSPF and IS-IS in order to advertise >>>>>>> Timing-aware capabilities of a link. Such extensions are outside= the >>>>>>> scope of this document; however such extension SHOULD be able to >>>>>>> signal the following information per Router Link: >>>>>>>=20 >>>>>>> o Capable of processing PTP, NTP or other Timing flows >>>>>>>=20 >>>>>>> o Capable of performing Transparent Clock operation >>>>>>>=20 >>>>>>> o Capable of performing Boundary Clock operation >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 32] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 2. Signaling Extensions for Creating Timing LSPs >>>>>>>=20 >>>>>>> RSVP-TE signaling MAY be used to setup the timing LSPs. When RSV= P-TE >>>>>>> is used to setup Timing LSPs, some information that indicates tha= t >>>>>>> the LSP is carrying Timing flows MUST be included in the new >>>>>>> Extensions to RSVP-TE: >>>>>>>=20 >>>>>>> The following information MAY also be included in the new Extensi= ons >>>>>>> to RSVP-TE: >>>>>>>=20 >>>>>>> o Offset from Bottom of Stack (BoS) to the start of the Time-sta= mp >>>>>>> field >>>>>>>=20 >>>>>>> o Number of VLANs in case of PW encapsulation >>>>>>>=20 >>>>>>> o Timestamp field Type >>>>>>>=20 >>>>>>> * Correction Field, Timestamp >>>>>>>=20 >>>>>>> o Timestamp Field format >>>>>>>=20 >>>>>>> * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit= >>>>>>> NTP, etc. >>>>>>>=20 >>>>>>> Note that in case the above optional information is signaled with= >>>>>>> RSVP-TE for a Timing LSP, all the Timing packets carried in that L= SP >>>>>>> must have the same signaled characteristics. For example if >>>>>>> Timestamp format is signaled as 64-bit PTPv1, then all Timing pac= kets >>>>>>> must use 64-bit PTPv1 time-stamp. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 33] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> Authors' Addresses >>>>>>>=20 >>>>>>> Shahram Davari >>>>>>> Broadcom Corp. >>>>>>> San Jose, CA 95134 >>>>>>> USA >>>>>>>=20 >>>>>>> Email: davari@broadcom.com >>>>>>>=20 >>>>>>>=20 >>>>>>> Amit Oren >>>>>>> Broadcom Corp. >>>>>>> San Jose, CA 95134 >>>>>>> USA >>>>>>>=20 >>>>>>> Email: amito@broadcom.com >>>>>>>=20 >>>>>>>=20 >>>>>>> Manav Bhatia >>>>>>> Alcatel-Lucent >>>>>>> Bangalore, >>>>>>> India >>>>>>>=20 >>>>>>> Email: manav.bhatia@alcatel-lucent.com >>>>>>>=20 >>>>>>>=20 >>>>>>> Peter Roberts >>>>>>> Alcatel-Lucent >>>>>>> Kanata, >>>>>>> Canada >>>>>>>=20 >>>>>>> Email: peter.roberts@alcatel-lucent.com >>>>>>>=20 >>>>>>>=20 >>>>>>> Laurent Montini >>>>>>> Cisco Systems >>>>>>> San Jose CA >>>>>>> USA >>>>>>>=20 >>>>>>> Email: lmontini@cisco.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 34] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> Luca >>>>>>> Cisco Systems >>>>>>> San Jose CA >>>>>>> USA >>>>>>>=20 >>>>>>> Email: lmartini@cisco.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 35] >>>>>>> -- >>>>>>> For corporate legal information go to: >>>>>>>=20 >>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> TICTOC mailing list >>>>>>> TICTOC@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/tictoc >>>>>> 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 >>>>> . >>>>=20 >>>> -- >>>> For corporate legal information go to: >>>>=20 >>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>=20 >>>> _______________________________________________ >>>> TICTOC mailing list >>>> TICTOC@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tictoc >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> TICTOC mailing list >>>> TICTOC@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tictoc >>>=20 >>> This e-mail message is intended for the recipient only and contains info= rmation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. >> . >=20 >=20 > -- > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 > This e-mail message is intended for the recipient only and contains inform= ation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If y= ou have received this transmission in error, please inform us by e-mail, pho= ne or fax, and then delete the original and all copies thereof. >=20 From eric.gray@ericsson.com Tue Aug 20 11:41:56 2013 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 4EB5521F9A06; Tue, 20 Aug 2013 11:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6] 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 Ifrr34kbwOrs; Tue, 20 Aug 2013 11:41:51 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id A61DA21F99AC; Tue, 20 Aug 2013 11:41:50 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-f2-5213b86d5d9e Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id FA.F6.09414.D68B3125; Tue, 20 Aug 2013 20:41:50 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Tue, 20 Aug 2013 14:41:49 -0400 From: Eric Gray To: "Eric Osborne (eosborne)" , "Malcolm.BETTS@zte.com.cn" Thread-Topic: [mpls] Mode negotiation for PSC Thread-Index: Ac6ULYh0Wz1ulMCERKa7JFuZBxS/GAFzPU+AADpDBQAAu+T3MA== Date: Tue, 20 Aug 2013 18:41:49 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF642C376@eusaamb107.ericsson.se> References: <20ECF67871905846A80F77F8F4A27572102C229B@xmb-rcd-x09.cisco.com> <20ECF67871905846A80F77F8F4A27572102EB9C5@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A27572102EB9C5@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyuXRPoG7eDuEgg7k97BZNczYzWrR3PWW3 2L3/CrvFraUrWR1YPKb83sjqsWTJTyaPNft+sAQwR3HZpKTmZJalFunbJXBl/Gl6wFjwOqLi 3IkbjA2Mr9y6GDk4JARMJFZ2KHYxcgKZYhIX7q1n62Lk4hASOMoosWLdVBYIZzmjxL7GpSwg VWwCGhLH7qxlBLFFBLIlPl+dxgxiMwuESTR/aGEDGSosoCPxaq85RImuxIZ169ggbCeJro0P wWwWAVWJf5f/g9m8At4Sny8/ZYLYdQNo196P7CAJTgFfiTM7roLtZQS67vupNUwQu8Qlbj2Z zwRxtYDEkj3nmSFsUYmXj/+xQtjKEkue7GeBqNeRWLD7ExuErS2xbOFrZojFghInZz5hmcAo NgvJ2FlIWmYhaZmFpGUBI8sqRo7S4tSy3HQjg02MwBg6JsGmu4Nxz0vLQ4zSHCxK4ryr9M4E CgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamAsMZ11VFrI/+UdYwWFv+xzqzJ526u2T/okuXKz V0WXiZz06y8Pjx0PSvfS2nHLd9ZPUaaiivCcrxEBM6fm3HDmMy19PGPn9rqNMakabt27mWdv ENh1KzrqqoCiSd+zxoryIytc1qxVv/zDO2jD51epzB0sIVLfjpgoPt+0ZWPw109rt556d36h EktxRqKhFnNRcSIAiSufZG8CAAA= Cc: "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject: Re: [mpls] Mode negotiation for PSC 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, 20 Aug 2013 18:41:56 -0000 Eric (Osborne), While I agree that we don't want to try to predict what will never ever happen, there is more than a little bit of an issue with designing for all = possible cases. Before we can really get away with any approach that could conceivably include N^2 combinations of options, we need to describe what each of these possibilities means, and how devices with arbitrary disagreement for the op= tions resolve the differences. And - while we're trying to cover the possible cases for known modes,=20 should we also try to allow for coverage of future (thus unknown) modes? Is this worth the trouble? Are there use cases to support this, or are we embarking on an academic exercise? What we really need now is a simple binary indicator. If we feel that any negotiation is required, then it should be trivial. If there is disagreeme= nt, then everbody falls-back to a default mode. But I am not convinced that any form of negotiation is required. In this discussion, I am reminded that at least part of the discussion tha= t got us on the road of having two modes had to do with limited negotiation i= n the case where PSC parameters did not match. I believe that the decision was t= hat reporting the inconsistency to the operator was sufficient from the perspec= tive=20 of any of us in the IETF, and that this was not sufficient to folks used to= dealing=20 with APS. So, are we switching from what was essentially non-negotiation of PSC parameters to negotiation of PSC modes? Seems counter-intuitive to me... -- Eric (Gray) -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eri= c Osborne (eosborne) Sent: Friday, August 16, 2013 4:49 PM To: Malcolm.BETTS@zte.com.cn Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] Mode negotiation for PSC Hi Malcolm- Thanks for this. A few comments inline. > -----Original Message----- > From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] > Sent: Thursday, August 15, 2013 1:01 PM > To: Eric Osborne (eosborne) > Cc: mpls@ietf.org; mpls-bounces@ietf.org > Subject: Re: [mpls] Mode negotiation for PSC >=20 > Hi Eric, >=20 > I have only seen one message on this thread so I will venture an=20 > opinion. >=20 > My preference is for option 1 - no negotiation. >=20 > My reasons are: >=20 > Keep it simple! >=20 > The major reason that network operator's have given for requesting=20 > these enhanced capabilities is to maintain compatibility with existing=20 > linear protection schemes. Within the network of a single operator my=20 > assumption is that they want, above all else, consistent operation. > Therefore, I suspect that we will see two "camps" with either all=20 > options active or no options active. >=20 That's what it looks like now. But I'm not terribly good at predicting wha= t people will never, ever do. I could see an implementation which wants to= support, say, MS-W but none of the other options. > Interconnection of "transport" connections between network operators=20 > is normally only allowed within the frame work of an agreement between=20 > the operators. As part of that agreement they would need to define the=20 > linear protection options that would be used. The operational=20 > differences would be confined to the links that provide the=20 > interconnection between networks of the different operators. The=20 > appropriate protection options would be configured (as defined by the > agreement) when the protected connection is set-up. PSC has bits to indicate the protection type and revertive mode, and the lo= gic we're going to add n draft-osborne explains what happens if two sides d= isagree. Is this not a form of negotiatoin? >=20 > Negotiation would allow the possibility of a variety of protection=20 > options being active in the network which would result in inconsistent=20 > behaviour which would create operational complexity. It is possible for one side to declare intransigence by setting the mask bi= ts to all 1s. This indicates that the Capabilities advertised by that node= must match exactly in order for things to work. The two modes I think we'= ll see first are: Cap=3D00000, Mask=3D11111 Cap=3D11111, Mask=3D11111 and these two will never agree on a mode since the mask of all 1s gives nei= ther side any room to move. I'm not against the simpler mode, I just want to make sure that you underst= and that it is possible to achieve that using the proposed negotiation meth= od. eric >=20 > Regards, >=20 > Malcolm >=20 >=20 >=20 >=20 >=20 > "Eric Osborne (eosborne)" Sent by:=20 > mpls-bounces@ietf.org >=20 > 08/08/2013 08:34 AM To > "mpls@ietf.org" > cc > Subject > [mpls] Mode negotiation for PSC >=20 >=20 >=20 >=20 >=20 >=20 > As per last Friday's presentation in Berlin=20 > (http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt > ),=20 > we will be adding "ITU Mode" to PSC to allow for behaviors that=20 > satisfy both IETF and ITU requirements. This mode will be=20 > backward-compatible and negotiated using PSC TLVs. >=20 > The drafts in that ppt define five capabilities which separate ITU=20 > mode from IETF mode. IETF mode is defined as the absence of these=20 > five capabilities, and ITU mode is defined as the use of all five of=20 > these capabilities. It may help to think of IETF mode as 00000 and=20 > ITU mode as 11111. The mechanism to define and negotiate these modes=20 > will have room for expansion past five bits, so if we ever decide we=20 > need more capabilities negotiation in PSC (shared mesh? m:n? other=20 > fancy stuff?) we can. >=20 > As of right now we are only discussing two modes, but it is possible=20 > to define a mode which is some combination of these five things other=20 > than > 00000 or 11111. So a mode is really the set of negotiated=20 > capabilities between two devices. >=20 > There are two ways we can negotiate the use of one more or the other: >=20 > 1) Each node announces the mode that it wants, and if the other side=20 > doesn't want exactly the same mode then PSC will not function. That=20 > is, both nodes say "my mode is 0bxxxxx" (for now, either 00000 or=20 > 11111) and if both nodes don't say the same thing then they complain=20 > to the operator and refuse to function. >=20 > Advantage: easy, and if both ends are in a single administrative=20 > domain I expect the operator to be able to configure both ends to match. >=20 > Disadvantage: tricky if we ever start talking about modes other than > 00000 or 11111. I don't want a node to say "I support mode 00000,=20 > mode 00001, mode 00010, mode 00011, .... mode 11111" because if we add=20 > a few more capabilities we could end up announcing the support of=20 > hundreds or thousands of modes. Does not allow PSC to come up unless=20 > the modes match on both sides, even if there is some common subset=20 > they could both agree on. >=20 >=20 > or >=20 >=20 > 2) Each node announces the set of capabilities that it can support=20 > along with the ones that it requires, and if the two nodes can find a=20 > common subset of features then they will converge on those features in PS= C. >=20 > Advantage: flexible. If two endpoints can find a common feature=20 > subset (see example below) then they will come up. >=20 > Disadvantage: more complex code, easier to get wrong and converge on a=20 > undesirable subset. >=20 >=20 > Examples of each negotiation method are below, both for clarity and to=20 > demonstrate that method #2 works. My question for the WG is, which=20 > one would people prefer, and why? >=20 >=20 >=20 >=20 >=20 >=20 > eric >=20 >=20 > --------------------------------- >=20 >=20 > Examples > =3D=3D=3D=3D=3D=3D=3D=3D > All examples are between two nodes, A and Z. These examples focus on=20 > the actual negotiation, not on the necessary TLV bits to enable the=20 > negotiation. >=20 > Example of method 1 > ------------------- > Node A sends a single TLV to Node Z containg the mode bitmap. Node Z=20 > sends the same to A. Call them A.Mode and Z.Mode. If they do not=20 > match then some default behavior happens - either PSC doesn't come up=20 > or they default to one predetermined mode. >=20 > A.mode =3D Z. mode =3D 00000 > A->Z: "I am configured for mode 00000" > Z->A: "I am configured for mode 00000" >=20 > This results in PSC coming up in IETF mode. >=20 > A.mode =3D Z.mode =3D 11111 > A->Z: "I am configured for mode 11111" > Z->A: "I am configured for mode 11111" >=20 > This results in PSC coming up in ITU mode. >=20 > A.mode !=3D Z.mode (say, 00001 and 00010) > A->Z: "I am configured for mode 00001" > Z->A: "I am configured for mode 00010" >=20 > PSC does not come up. >=20 >=20 >=20 > Example of method 2 > ------------------- > Both Node A and Node Z announce two things - Capabilities and Mask. > Capabilities is a bitmap of the capabilities that are supported. > Mask is a mask of don't-care bits against the Capabilities string. A=20 > 0 in Mask means "I don't care if we do this capability or not", and a=20 > 1 means "we must (or must not) agree on this capability in order to=20 > come up". >=20 > A.capabilities =3D 00000 > A.mask =3D 00000 >=20 > This says "I am capable of supporting all capabilities and I don't=20 > care if we do any of them or not" >=20 > A.capabilities =3D 00000 > A.mask =3D 11111 >=20 > This says "We must not use any of the optional capabilities" -=20 > Capabilities bits are all zero, and Mask bits say "we must agree that=20 > the corresponding capability is zero". This is 'IETF mode'. >=20 > A.capabilities =3D 11111 > A.mask =3D 11111 >=20 > This is 'ITU Mode' >=20 > Where it gets complicated (or awesome, depending on your perspective)=20 > is when you have various subsets. Consider: >=20 > A.Capabilities =3D=3D 01100 > A.Mask =3D=3D 01100 >=20 > Z.Capabilities =3D=3D 01110 > Z.Mask =3D=3D 01110 >=20 >=20 > Negotiation procedures. > Each side does: >=20 >=20 > res =3D (A.Capabilites & Z.Mask) ^ (Z.Capabilities & A.Mask) res =3D=20 > (01100 & 01110) ^ (01110 & 01100) res =3D (01100) ^ (01100) res =3D 00000 >=20 > if res =3D=3D 0 then it is possible for both sides to find a common subse= t=20 > that they support. > This common subset is called the 'negotiated set', and is determined by: >=20 > negotiated_set =3D A.Capabilities | B.Capabilities negotiated_set =3D=20 > 01100 | 01110 negotiated_set =3D 01100 >=20 > if res !=3D 0 then it is impossible to find a subset that the two ends=20 > can agree on, and PSC will never come up. >=20 > Once each side computes the negotiated set, they signal it and PSC=20 > starts to work. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > >=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From Alexander.Vainshtein@ecitele.com Tue Aug 20 12:08:16 2013 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 4F09F21F85A1 for ; Tue, 20 Aug 2013 12:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.702 X-Spam-Level: X-Spam-Status: No, score=-3.702 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 hUsW3i7ibhg5 for ; Tue, 20 Aug 2013 12:08:11 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.107]) by ietfa.amsl.com (Postfix) with ESMTP id 6E95F11E8131 for ; Tue, 20 Aug 2013 12:07:27 -0700 (PDT) Received: from [193.109.254.147:19733] by server-3.bemta-14.messagelabs.com id 88/7C-11293-66EB3125; Tue, 20 Aug 2013 19:07:18 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1377025631!5037718!3 X-Originating-IP: [147.234.242.234] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1698 invoked from network); 20 Aug 2013 19:07:17 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Aug 2013 19:07:17 -0000 X-AuditID: 93eaf2e7-b7f0e6d000004f79-06-5213bac3d386 Received: from ILPTWPVEXCA02.ecitele.com ( [172.31.244.232]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id D9.D4.20345.3CAB3125; Tue, 20 Aug 2013 21:51:48 +0300 (IDT) Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA02.ecitele.com ([fe80::c473:490d:3a7e:e34a%12]) with mapi id 14.03.0123.003; Tue, 20 Aug 2013 21:51:47 +0300 From: Alexander Vainshtein To: "S. Davari" Thread-Topic: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls Thread-Index: AQHOkhqJ+XHALQ/MzkWnZzr9BEl1M5mHyTyggBaXBuSAAAM16f//06OAgABOFGw= Date: Tue, 20 Aug 2013 18:51:46 +0000 Message-ID: References: <51FB7543.801@cisco.com> <51FF7068.9080600@cisco.com> <4A6CE49E6084B141B15C0713B8993F281BEC731A@SJEXCHMB12.corp.ad.broadcom.com> <52139903.8040801@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.1] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42KZ/OrTK92UfcJBBouPalocfN7EaHFr6UpW i3NP5zA6MHtM+b2R1WPJkp9MHrNmHWYKYI5qYLRJzMvLL0ksSVVISS1OtlUKKMosS0yuVFLI TLFVMlRSKMhJTE7NTc0rsVVKLChIzUtRsuNSwAA2QGWZeQqpecn5KZl56bZKnsH+uhYWppa6 hkp2asqGxtZcIRmZxQqpurmJmTkKuanFxYnpqQpAkYQtzBl355UX/FzGWtF04RZ7A+Pev8xd jJwcEgImEs+7e6FsMYkL99azdTFycQgJHGSU+PTgBSuEc5RRYk7fdxaQKjYBW4lNq++ygdgi AioSS7cvBYszC8wF6vjt38XIwSEs4C5x+IcfRImHROfU84wQtp/EvouzwZaxCKhK/P69lR3E 5hUIkNh2+z4LxK7ZLBK/eh+DzecE2jX1wl+wZkag676fWsMEsUtc4taT+UwQVwtILNlzHuoD UYmXj/+xQtjyEhc/PICq15FYsPsTG4StLbFs4WtmiMWCEidnPmGZwCg2C8nYWUhaZiFpmYWk ZQEjyypG0cycgpKk3HQDQ73U5MyS1JxUveT83E2MkDTyfAfjr/kqhxhdgZ6dyCzFnZwPTEN5 JfHGBga4OUrivMsbwv2FBNKBqSU7NbUgtSi+qDQntfgQIxMHp1QDY8T9rqMLOp02pe/zPVyh t9xR/IxmokbhQf36cz35SoVbUo4YGt1x7pb+csziopHDyvIVFdP+PjFYMGP/soe6v+tYZjfV hO4tPVNXt2ONEPvi5UyRSz49PJLzbPrdGMcl35/+fdTnu3F7zPtPmZEzQ+8oS6reS45boFYq qi42UXmNbM3lX9I9LEosxRmJhlrMRcWJALROILEbAwAA Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] Comments on draft-ietf-tictoc-1588overmpls 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, 20 Aug 2013 19:08:16 -0000 Shahram, No I am not proposing anything of the kind. At the MPLS data plane level the only the head-end and the tail-end LERs hav= e to be aware of the BoS Timing Alert labels. Transit LSRs simply will ignor= e them. At the on-path assistance level each transit LSR (and the tail-end LER) can= do one of the following: - It may ignore the Timing Alert label at the BoS and just forward the packe= t based the labels at the top of the stack. - It may identify the packet as a timing one based on the Timing Alert label= at the bottom of the label stack, and perform the required operations. The= result of these operations will be stored in the "timing shim header" and n= ot in the packet itself. (E.g., an E2E TC clock would note the packet reside= nce time and add it to the value already carried in the shim header). Non-timing packets would not have the Timing Alert label at the BoS and henc= e would travel thru he LSP travel along the LSP in the usual way. The tail-end LER would take the reception timestamp and forward this timesta= mp, the protocol packet and the shim header to the entity that processes the= appropriate timing distribution protocol based on the Timing Alert label. Hopefully this clarifies my proposal. My gut feeling is that similar ideas h= ave been proposed by many people earlier... Regards, Sasha ________________________________________ From: S. Davari [davarish@yahoo.com] Sent: Tuesday, August 20, 2013 7:00 PM To: Alexander Vainshtein Cc: stbryant@cisco.com; Shahram Davari; mpls@ietf.org; tictoc@ietf.org Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls Sasha In (2) are you proposing to create multiple segment LSPs, where each if thos= e segment LSPs span between two Timing aware LSR? So if I have 10 timing awa= re LSR in the path I would need 9 LSPs? Regards, Shahram On Aug 20, 2013, at 9:53 AM, Alexander Vainshtein wrote: > Stewart, Shahram and all, > > A couple of (hopefully, last) comments: > > 1. Supporting a "Timing Alert" label at the top of the label stack introdu= ces a backward compatibility problem. We differ in our estimate of the impor= tance of this problem, but we all agree that it exists. > > 2. On the other hand, this problem does not exist if the "Timing Alert" la= bel is inserted at the bottom of the label stack. At the same time, HW that= analyzes the label stack hopefully could analyze the bottom label (almost)= as easily as it would analyze the top label. Thus we could both provide bac= kward compatibility (incompatible transit LSRs simply would not notice the "= Timing Alert" label") and avoid the need for dedicated "Timing-only" LSPs. I= n particular, all the MPLS OAM tools (including MPLS-TP) would work without= any changes. > > 3. A "timing shim header" (between the bottom of the label stack and the b= eginning of the timing packet) has been mentioned by Stewart as an already= proposed mechanism. IMHO and FWIW its usage would eliminate the need to und= erstand format of the specific timing distribution protocol in the transit L= SRs. It would further solve the problem of secure transport of timing packe= ts since security mechanisms would be applied to its original encapsulation= (over IP or over Ethernet) without involving the transit LSRs. > > Did I miss something substantial? > > Regards, and lots of thanks in advance, > Sasha > > > ________________________________________ > From: Stewart Bryant [stbryant@cisco.com] > Sent: Tuesday, August 20, 2013 6:27 PM > To: S. Davari > Cc: Alexander Vainshtein; Shahram Davari; mpls@ietf.org; tictoc@ietf.org > Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls > > On 06/08/2013 14:35, S. Davari wrote: >> Sasha, >> >> If a router is not 1588 aware we want it to switch the packet with minimu= m jitter and delay via high priority queue. > Yes, but you can explicitly tunnel across such island of incompatibility > > Stewart > >> >> >> Sending it to CPU creates large jitter and delay since the CPUs are gener= ally busy doing other things. Time stamping or updating CF in the CPU won't= help since it does not cover the variable delay that is incurred from the t= ime the packet enters the router to the time the packet gets processed by CP= U. >> >> I wish it was that easy! >> >> Regards, >> Shahram >> >> >> On Aug 6, 2013, at 12:38 AM, Alexander Vainshtein wrote: >> >>> Shahram, >>> I agree with you that the routers that do not recognize a Timing Alert l= abel would send the packet to the CPU. (This would be easy to arrange since= we are speaking about a reserved label.) >>> >>> I do not, however, see this as a serious issue, because the SW running o= n this CPU would (hopefully) be upgradable to handle the packet correctly i.= e., to forward it to where it should be forwarded and, if it is forwarded as= a labeled packet, to prepend the Timing Alert Label on top of its label sta= ck. It could even record the residence time (as observed by the CPU in the p= roper place in the packet. This would mean that introducing additional error= to whatever timing information is associated with this packet - but this is= what you should anyway expect if there are non-compliant routers on your pa= th, right? >>> >>> Regards, >>> Sasha >>> >>>> -----Original Message----- >>>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behal= f Of >>>> Shahram Davari >>>> Sent: Monday, August 05, 2013 11:29 PM >>>> To: stbryant@cisco.com; S. Davari >>>> Cc: mpls@ietf.org; tictoc@ietf.org >>>> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls >>>> >>>> Hi Stewart, >>>> >>>> Your suggestion of " I suggested an LSP type that has the properties "t= imestamp >>>> and pass to application", is a subset of the existing draft and should= work. It >>>> basically limits the time stamping and correction field update to LERs= (while the >>>> draft supports time stamping at LER and LSR). >>>> >>>> However Sasha's suggestion of using a reserved label (RAL, GAL or any o= ther >>>> reserved label) does not satisfy one of the major requirements, which i= s >>>> backward compatibility. Routers that don't understand this reserved lab= el will >>>> drop or copy to CPU such packets. >>>> >>>> Regards, >>>> Shahram >>>> >>>> -----Original Message----- >>>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behal= f Of >>>> Stewart Bryant >>>> Sent: Monday, August 05, 2013 2:29 AM >>>> To: S. Davari >>>> Cc: mpls@ietf.org; tictoc@ietf.org >>>> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls >>>> >>>> My concern is that we are creating a new LSP type in MPLS >>>> (which is a architectural change and thus needs to be very carefully >>>> considered) without asking the question "how can I do this >>>> in the most general way, to maximize flexibility/reuse" >>>> >>>> I suggested an LSP type that has the properties "timestamp >>>> and pass to application", but I think that Sasha raises a good >>>> point about using router alert. However RA has no implicit >>>> timestamp, so maybe we need a new type of RA that has the >>>> properties "timestamp, and pass top application indicated by >>>> the next label". That would be quite useful in a number >>>> of OAM applications. There is possibly some GAL variant >>>> of that design that should also be considered. >>>> >>>> The application could worry about the path and where it >>>> was necessary to skip some hops a hierarchical LSP would >>>> accomplish that, with the specific benefit that the application >>>> would consciously do this, and may be able to apply some >>>> form of compensation within the network. >>>> >>>> - Stewart >>>> >>>> On 04/08/2013 10:40, S. Davari wrote: >>>>> Hi Sasha >>>>> >>>>> Perhaps you have not understood the draft well. The main reason that t= he >>>> draft chose to use a dedicated LSP that is signaled via RSVPTE indicati= ng it is a >>>> timing LSP is to be backward compatible with non-1588 nodes. Such nodes >>>> simply just switch the packet. >>>>> Your proposal had been considered and was rejected since it was not >>>> backward compatible. Nodes receiving alert label or TTL =3D 1 send the= packet to >>>> CPU. You can refer to the meeting notes. >>>>> Regards, >>>>> Shahram >>>>> >>>>> >>>>> On Aug 4, 2013, at 1:21 AM, Alexander Vainshtein >>>> wrote: >>>>>> Stewart and all, >>>>>> I concur with Stewart's statement that the draft does not define "ful= l >>>> interaction with MPLS architecture". >>>>>> E.g., one of the objectives of the draft is to provide a technique th= at would >>>> be backward-compatible with old LSRs that cannot provide on-path suppor= t for >>>> timing distribution, while the other objective is to make every LSR on= the path >>>> aware that some MPLS packets are carrying timing-related messages and h= ence >>>> require on-path support. >>>>>> IMHO and FWIW, the MPLS data plane architecture allows just two metho= ds >>>> for making a transit LSR to provide special processing to a labeled pac= ket: >>>>>> - It would carry some kind of an "alert label" on top of the label st= ack and, >>>> specifically, on top of any labels used for actual forwarding >>>>>> OR, >>>>>> - The TTL in the top label stack entry has been set to 1. >>>>>> >>>>>> >>>>>> The draft does not follow any of these approaches. >>>>>> >>>>>> I must also admit that Section 12 "OAM, Control and Management" of th= e >>>> draft looks somewhat in >>>>>> E.g., I could not understand from the text whether BFD, LSP-Ping etc.= OAM >>>> messages would be subjected to on-path support procedures for timing >>>> messages or not. >>>>>> My 2c, >>>>>> Sasha >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Be= half >>>> Of >>>>>>> Stewart Bryant >>>>>>> Sent: Friday, August 02, 2013 12:01 PM >>>>>>> To: mpls-chairs@tools.ietf.org; tictoc-chairs@tools.ietf.org; int- >>>>>>> ads@tools.ietf.org; rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.o= rg; >>>> draft- >>>>>>> ietf-tictoc-1588overmpls@tools.ietf.org >>>>>>> Cc: mpls@ietf.org; tictoc@ietf.org >>>>>>> Subject: [TICTOC] Comments on draft-ietf-tictoc-1588overmpls >>>>>>> >>>>>>> SB> This draft does not seem to provide a precise definition >>>>>>> SB> the properties of the new LSP type that it wishes to >>>>>>> SB> define, in particular it does it define the PHB of those >>>>>>> SB> LSPs, nor the full interaction with the MPLS >>>>>>> SB> architecture. >>>>>>> SB> >>>>>>> SB> I have not tracked TICTOC for a while but I thought that >>>>>>> SB> the original plan was to define the concept of an offset >>>>>>> SB> into a packet to do the correction. >>>>>>> SB> >>>>>>> SB> It is disappointing that the opportunity was not taken >>>>>>> SB> to define a timing shim inside the timing LSP so that >>>>>>> SB> a time correction could be added to any packet such that >>>>>>> SB> the MPLS system was isolated from the details of the >>>>>>> SB> complexity of the particular time transfer type. >>>>>>> >>>>>>> SB> I think that much more clarify is needed in terms of >>>>>>> SB> definition of the new LSP type, since it is unclear >>>>>>> SB> from this text how to implement one. >>>>>>> SB> >>>>>>> SB> There are a lot of other MPLS services such as >>>>>>> SB> LSP ping that need to be considered. >>>>>>> SB> >>>>>>> SB> Please see inline for more comments. However these >>>>>>> SB> comments are made in the context of the text as written >>>>>>> SB> whilst I have a fundamental concern that this approach >>>>>>> SB> lacks an MPLS architectural soundness that need >>>>>>> SB> greater thought with significant impact on the >>>>>>> SB> draft. >>>>>>> >>>>>>> - Stewart >>>>>>> >>>>>>> >>>>>>> TICTOC Working Group S. Da= vari >>>>>>> Internet-Draft A.= Oren >>>>>>> Intended status: Standards Track Broadcom C= orp. >>>>>>> Expires: December 17, 2013 M. Bh= atia >>>>>>> P. Rob= erts >>>>>>> Alcatel-Lu= cent >>>>>>> L. Mon= tini >>>>>>> L. Mar= tini >>>>>>> Cisco Sys= tems >>>>>>> June 15,= 2013 >>>>>>> >>>>>>> >>>>>>> Transporting Timing messages over MPLS Networks >>>>>>> draft-ietf-tictoc-1588overmpls-05 >>>>>>> >>>>>>> Abstract >>>>>>> >>>>>>> This document defines the method for transporting Timing messages >>>>>>> such as PTP and NTP over an MPLS network. The method allows for= the >>>>>>> easy identification of these PDUs at the port level to allow for= port >>>>>>> >>>>>>> SB> What is a port >>>>>>> >>>>>>> level processing of these PDUs in both LERs and LSRs. >>>>>>> >>>>>>> The basic idea is to transport Timing messages inside dedicated M= PLS >>>>>>> LSPs. These LSPs only carry Timing messages and possibly Control= and >>>>>>> Management packets, but they do not carry customer traffic. >>>>>>> >>>>>>> SB> More specifically they only carry traffic associated with the >>>>>>> SB> timing service and its support. >>>>>>> SB> The question arose WRT BFD - surely BFD is allowed, BUT surely >>>>>>> SB> also it gets carried in a structure that causes it to get >>>>>>> SB> timestamped. >>>>>>> >>>>>>> Two methods for transporting Timing messages over MPLS are define= d. >>>>>>> >>>>>>> SB> Perhaps the right approach is to define the new LSP type and the= n >>>>>>> SB> seperately to define the mapping of the various timing services >>>>>>> SB> over that LSP type. >>>>>>> >>>>>>> The first method is to transport Timing messages directly over th= e >>>>>>> dedicated MPLS LSP via UDP/IP encapsulation, which is suitable fo= r >>>>>>> MPLS networks. The second method is to transport Timing messages >>>>>>> inside a PW via Ethernet encapsulation. >>>>>>> >>>>>>> SB> I think that we should note that there are some >>>>>>> SB> h/w reasons for this preference. A clean sheet approach >>>>>>> SB> would have been to use PTP over MPLS with no intermediate >>>>>>> SB> layers. >>>>>>> >>>>>>> Status of this Memo >>>>>>> >>>>>>> This Internet-Draft is submitted in full conformance with the >>>>>>> provisions of BCP 78 and BCP 79. >>>>>>> >>>>>>> Internet-Drafts are working documents of the Internet Engineering >>>>>>> Task Force (IETF). Note that other groups may also distribute >>>>>>> working documents as Internet-Drafts. The list of current Intern= et- >>>>>>> Drafts is at http://datatracker.ietf.org/drafts/current/. >>>>>>> >>>>>>> Internet-Drafts are draft documents valid for a maximum of six mo= nths >>>>>>> and may be updated, replaced, or obsoleted by other documents at= any >>>>>>> time. It is inappropriate to use Internet-Drafts as reference >>>>>>> material or to cite them other than as "work in progress." >>>>>>> >>>>>>> This Internet-Draft will expire on December 17, 2013. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 1] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> Copyright Notice >>>>>>> >>>>>>> Copyright (c) 2013 IETF Trust and the persons identified as the >>>>>>> document authors. All rights reserved. >>>>>>> >>>>>>> This document is subject to BCP 78 and the IETF Trust's Legal >>>>>>> Provisions Relating to IETF Documents >>>>>>> (http://trustee.ietf.org/license-info) in effect on the date of >>>>>>> publication of this document. Please review these documents >>>>>>> carefully, as they describe your rights and restrictions with res= pect >>>>>>> to this document. Code Components extracted from this document m= ust >>>>>>> include Simplified BSD License text as described in Section 4.e o= f >>>>>>> the Trust Legal Provisions and are provided without warranty as >>>>>>> described in the Simplified BSD License. >>>>>>> >>>>>>> >>>>>>> Table of Contents >>>>>>> >>>>>>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .= . 5 >>>>>>> >>>>>>> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . .= . 7 >>>>>>> >>>>>>> 3. Problem Statement . . . . . . . . . . . . . . . . . . . . .= . 8 >>>>>>> >>>>>>> 4. Timing over MPLS Architecture . . . . . . . . . . . . . . .= . 9 >>>>>>> >>>>>>> 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . .= . 12 >>>>>>> >>>>>>> 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . .= . 13 >>>>>>> 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . .= . 13 >>>>>>> 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . .= . 13 >>>>>>> 6.3. Other Timing Encapsulation methods . . . . . . . . . . .= . 14 >>>>>>> >>>>>>> 7. Timing message Processing . . . . . . . . . . . . . . . . .= . 15 >>>>>>> >>>>>>> 8. Protection and Redundancy . . . . . . . . . . . . . . . . .= . 16 >>>>>>> >>>>>>> 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . .= . 17 >>>>>>> >>>>>>> 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . .= . 18 >>>>>>> >>>>>>> 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . .= . 19 >>>>>>> >>>>>>> 12. OAM, Control and Management . . . . . . . . . . . . . . . .= . 20 >>>>>>> >>>>>>> 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . .= . 21 >>>>>>> >>>>>>> 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . .= . 22 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 2] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . .= . 23 >>>>>>> 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . .= . 23 >>>>>>> 15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . .= . 23 >>>>>>> 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . .= . 24 >>>>>>> >>>>>>> 16. Other considerations . . . . . . . . . . . . . . . . . . . .= . 25 >>>>>>> >>>>>>> 17. Security Considerations . . . . . . . . . . . . . . . . . .= . 26 >>>>>>> >>>>>>> 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .= . 27 >>>>>>> >>>>>>> 19. IANA Considerations . . . . . . . . . . . . . . . . . . . .= . 28 >>>>>>> >>>>>>> 20. References . . . . . . . . . . . . . . . . . . . . . . . . .= . 29 >>>>>>> 20.1. Normative References . . . . . . . . . . . . . . . . . .= . 29 >>>>>>> 20.2. Informative References . . . . . . . . . . . . . . . . .= . 29 >>>>>>> >>>>>>> Appendix 1. Routing extensions for Timing-aware Routers . . . .= . 32 >>>>>>> >>>>>>> Appendix 2. Signaling Extensions for Creating Timing LSPs . . .= . 33 >>>>>>> >>>>>>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .= . 34 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 3] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >>>> NOT", >>>>>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" >>>> in >>>>>>> this >>>>>>> document are to be interpreted as described in RFC2119 [RFC2119]. >>>>>>> >>>>>>> When used in lower case, these words convey their typical use in >>>>>>> common language, and are not to be interpreted as described in >>>>>>> RFC2119 [RFC2119]. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 4] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 1. Introduction >>>>>>> >>>>>>> The objective of Precision Time Protocol (PTP) and Network Timing >>>>>>> Protocol (NTP) are to synchronize independent clocks running on >>>>>>> separate nodes of a distributed system. >>>>>>> >>>>>>> [IEEE-1588] defines PTP messages for frequency, phase and time >>>>>>> synchronization. The PTP messages include PTP PDUs over UDP/IP >>>>>>> (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex= F of >>>>>>> [IEEE-1588]). >>>>>>> >>>>>>> SB> Sure BUT it is acknowledged that IEEE is open to the definition >>>>>>> SB> of other PTP mappings if they provide better optimisation. >>>>>>> >>>>>>> This document defines mapping and transport of the PTP >>>>>>> messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP >>>>>>> defines several clock types: ordinary clocks, boundary clocks, en= d- >>>>>>> to-end transparent clocks, and peer-to-peer transparent clocks. >>>>>>> Transparent clocks require intermediate nodes to update correctio= n >>>>>>> field inside PTP message that reflects the transit time in the no= de. >>>>>>> >>>>>>> [RFC5905] defines NTP messages for clock and time synchronization= . >>>>>>> The PTP messages (PDUs) are transported over UDP/IP. This docume= nt >>>>>>> SB> Should that be NTP messages? >>>>>>> SB> It needs to be made clear as soon as you introduce NTP that >>>>>>> SB> they use different time representations. >>>>>>> >>>>>>> defines mapping and transport of the NTP messages defined in >>>>>>> [RFC5905] over MPLS networks. >>>>>>> >>>>>>> One key attribute of all of these Timing messages is that the Tim= e >>>>>>> stamp processing should occur as close as possible to the actual >>>>>>> transmission and reception at the physical port interface. This >>>>>>> targets optimal time and/or frequency recovery by avoiding variab= le >>>>>>> delay introduced by queues internal to the clocks. >>>>>>> >>>>>>> SB> As I recall NTP has no epoch point defined, and I am not sure >>>>>>> SB> where that point is in the case of PTP in this mapping >>>>>>> SB> Hopefully this will get defined in due course. >>>>>>> >>>>>>> To facilitate the fast and efficient recognition of Timing messag= es >>>>>>> at the port level when the Timing messages are carried over MPLS >>>>>>> LSPs, >>>>>>> >>>>>>> SB> Over a new LSP type with time optimied characteristics >>>>>>> >>>>>>> this document defines the specific encapsulations that should >>>>>>> be used. >>>>>>> SB> Hopefully it will also define the PHP >>>>>>> >>>>>>> In addition, it can be expected that there will exist LSR/ >>>>>>> LERs where only a subset of the physical ports will have the port= - >>>>>>> based Timing message processing capabilities. >>>>>>> SB> Do you need to clarify that this only works at base and not in >>>>>>> SB> a label heirarchy. >>>>>>> >>>>>>> >>>>>>> In order to ensure >>>>>>> that the LSPs carrying Timing packets always enter and exit ports >>>>>>> with this capability, routing extensions are defined to advertise >>>>>>> this capability on a port basis and to allow for the establishmen= t of >>>>>>> LSPs that only transit such ports. While this path establishment >>>>>>> restriction may be applied only at the LER Ingress and/or egress >>>>>>> ports, it becomes more important when using transparent clock cap= able >>>>>>> LSRs in the path. >>>>>>> SB> I do not understand the implications of the last >>>>>>> SB> sentences - starting ", it becomes" >>>>>>> >>>>>>> >>>>>>> Port based Timing message processing involves Timing message >>>>>>> recognition. Once the Timing messages are recognized they can be >>>>>>> modified based on the reception or transmission Time-stamp. >>>>>>> >>>>>>> This document provides two methods for transporting Timing messag= es >>>>>>> over MPLS. One is applicable to MPLS environment and the other o= ne >>>>>>> is applicable to MPLS/MPLS-TP environment >>>>>>> >>>>>>> SB> I think the sentence is incomplete. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 5] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> The solution involves transporting Timing messages over dedicated >>>>>>> LSPs called Timing LSPs. These LSPs carry Timing messages and MA= Y >>>>>>> carry Management and control messages, but not data plane client >>>>>>> traffic. >>>>>>> >>>>>>> SB> It is not clear why this restriction applies. >>>>>>> >>>>>>> Timing LSPs can be established statically or via signaling. >>>>>>> SB> s/statically/by provisioning/network management/ >>>>>>> >>>>>>> Extensions to control plane (OSPF, ISIS, etc.) is required to ena= ble >>>>>>> routers to distribute their Timing processing capabilities over M= PLS >>>>>>> to other routers. However such extensions are outside the scope= of >>>>>>> this document. >>>>>>> >>>>>>> When signaling is used to setup the PTP LSP, Extensions to signal= ing >>>>>>> SB> is it a PTP LSP or a Timing LSP? >>>>>>> >>>>>>> protocols (e.g., RSVP-TE) are required for establishing PTP LSPs. >>>>>>> However such extensions are outside the scope of this document. >>>>>>> >>>>>>> SB> for mpls-tp GMPLS is the signalling protocol >>>>>>> >>>>>>> While the techniques included herein allow for the establishment= of >>>>>>> paths optimized to include Time-stamping capable links, the >>>>>>> performance of the Slave clocks is outside the scope of this >>>>>>> document. >>>>>>> >>>>>>> At the time of publishing this specification, Transparent Clockin= g >>>>>>> (TC) is only defined for PTP. Therefore at this time any part of >>>>>>> this specification that talks about Transparent Clocking applies= only >>>>>>> to PTP. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 6] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 2. Terminology >>>>>>> >>>>>>> 1588: The timing and synchronization as defined by IEEE 1588. >>>>>>> >>>>>>> SB> I think that there is a more formal name for the 1588 group >>>>>>> SB> that needs to be used here. >>>>>>> SB> Also do we need to talk about 1588-200? as there is >>>>>>> SB> an update in progress >>>>>>> >>>>>>> NTP: The timing and synchronization protocol defined by IETF RFC-= 1305 >>>>>>> and RFC-5905. >>>>>>> >>>>>>> PTP: The timing and synchronization protocol used by 1588. >>>>>>> SB> need the proper name for 1588 >>>>>>> >>>>>>> Master Clock: The source of 1588 timing to a set of slave clocks. >>>>>>> >>>>>>> Master Port: A port on a ordinary or boundary clock that is in Ma= ster >>>>>>> state. This is the source of timing toward slave ports. >>>>>>> >>>>>>> SB> I am not sure the reader knows what a port is >>>>>>> >>>>>>> Slave Clock: A receiver of 1588 timing from a master clock. >>>>>>> >>>>>>> Slave Port: A port on a boundary clock or ordinary clock that is >>>>>>> receiving timing from a master clock. >>>>>>> >>>>>>> Ordinary Clock: A device with a single PTP port. >>>>>>> >>>>>>> Transparent Clock. A device that measures the time taken for a P= TP >>>>>>> event message to transit the device and then updates the >>>>>>> correctionField of the message with this transit time. >>>>>>> >>>>>>> Boundary Clock: A device with more than one PTP port. Generally >>>>>>> boundary clocks will have one port in slave state to receive timi= ng >>>>>>> and then other ports in master state to re-distribute the timing. >>>>>>> >>>>>>> PTP LSP: An LSP dedicated to carry PTP messages >>>>>>> >>>>>>> SB> PTP or timing? >>>>>>> >>>>>>> >>>>>>> PTP PW: A PW within a PTP LSP that is dedicated to carry PTP >>>>>>> messages. >>>>>>> >>>>>>> SB> Ah I don't think that PWE3 know what one of these is >>>>>>> >>>>>>> CW: Pseudowire Control Word >>>>>>> >>>>>>> LAG: Link Aggregation >>>>>>> >>>>>>> ECMP: Equal Cost Multipath >>>>>>> >>>>>>> CF: Correction Field, a field inside certain PTP messages (messag= e >>>>>>> type 0-3)that holds the accumulative transit time inside intermed= iate >>>>>>> switches >>>>>>> >>>>>>> Timing messages: Timing Protocol messages that are exchanged >>>> between >>>>>>> routers in order to establish a synchronized clock. >>>>>>> >>>>>>> SB> A number of these definitions look like copies of IEEE1588 >>>>>>> SB> definitions. We need to provide references and note the >>>>>>> SB> priority of the IEEE base reference. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 7] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 3. Problem Statement >>>>>>> >>>>>>> [IEEE-1588] has defined methods for transporting PTP messages ove= r >>>>>>> Ethernet and IP networks. [RFC5905] has defined the method of >>>>>>> transporting NTP messages over IP networks. There is a need to >>>>>>> transport Timing messages over MPLS networks while supporting the >>>>>>> Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (O= C) >>>>>>> functionality in the LER and LSRs in the MPLS network. >>>>>>> >>>>>>> There are multiple ways of transporting Timing over MPLS. Howeve= r, >>>>>>> there is a requirement to limit the possible encapsulation option= s to >>>>>>> simplify the Timing message identification and processing require= d at >>>>>>> the port level. >>>>>>> >>>>>>> When Timing-awareness is needed, Timing messages should not be >>>>>>> transported over LSPs or PWs that are carrying customer traffic >>>>>>> because LSRs perform Label switching based on the top label in th= e >>>>>>> stack. >>>>>>> >>>>>>> SB> Have you explained why? >>>>>>> >>>>>>> To detect Timing messages inside such LSPs require special >>>>>>> hardware to do deep packet inspection at line rate. Even if such >>>>>>> hardware exists, the payload can't be deterministically identifie= d by >>>>>>> LSRs because the payload type is a context of the PW label, and t= he >>>>>>> PW label and its context are only known to the Edge routers (PEs/ >>>>>>> LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, C= ES, >>>>>>> etc). Even if one restricts an LSP to only carry Ethernet PWs, t= he >>>>>>> LSRs dont have the knowledge of whether PW Control Word (CW) is >>>>>>> present or not and therefore can not deterministically identify t= he >>>>>>> payload. >>>>>>> >>>>>>> A generic method is defined in this document that does not requir= e >>>>>>> deep packet inspection at line rate, and can deterministically >>>>>>> identify Timing messages. This method can be used to detect Timi= ng >>>>>>> Messages in both one-step and two-step clock implementations of >>>>>>> ordinary, boundary and transparent clocks. >>>>>>> >>>>>>> SB> Needs a ref and I am sure many MPLS specialists will not underst= and >>>>>>> SB> the msg types. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 8] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 4. Timing over MPLS Architecture >>>>>>> >>>>>>> Timing messages are exchange between Timing ports on ordinary and >>>>>>> >>>>>>> SB> Have you defined a timing port? >>>>>>> >>>>>>> boundary clocks. Boundary clocks terminate the Timing messages a= nd >>>>>>> act as master for other boundary clocks or for slave clocks. End= -to- >>>>>>> End Transparent clocks do not terminate the Timing messages but t= hey >>>>>>> do modify the contents of the Timing messages as they transit acr= oss >>>>>>> the transparent clock. >>>>>>> >>>>>>> Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent C= lock >>>>>>> >>>>>>> (TC) could be implemented in either LERs or LSRs. >>>>>>> >>>>>>> SB> LER and LSR need to be expanded >>>>>>> >>>>>>> An example is shown in Figure 1, where the LERs act as Ordinary C= lock >>>>>>> (OC) and are the initiating/terminating point for Timing messages= . >>>>>>> The ingress LER encapsulates the Timing messages in Timing LSP an= d >>>>>>> the Egress LER terminates the Timing LSP. The LSRs act as >>>>>>> Transparent Clock (TC) and just update the Timing field in the Ti= ming >>>>>>> messages. >>>>>>> >>>>>>> >>>>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ >>>>>>> |Switch, | | | | | | | |Swit= ch, | >>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rou= ter | >>>>>>> | | | OC | | TC | | OC | | = | >>>>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ >>>>>>> / \ >>>>>>> +-------+ / \ +-----= --+ >>>>>>> | LER | / \ | LER= | >>>>>>> | Master|---/ \---| Slav= e | >>>>>>> | Clock | | Cloc= k | >>>>>>> +-------+ +-----= --+ >>>>>>> >>>>>>> Figure (1) - Deployment example 1 of timing over MPLS network >>>>>>> >>>>>>> Another example is shown in Figure2, where LERs terminate the Tim= ing >>>>>>> messages received from switch/routers that are outside of the MPL= S >>>>>>> network acting as OC or BC. In this example LERs regenerate the >>>>>>> clock and initiate timing messages encapsulated in Timing LSP tow= ard >>>>>>> the MPLS network, while the LSRs act as Transparent Clock (TC) an= d >>>>>>> just update the Timing field in the Timing messages, which are >>>>>>> already encapsulated in Timing LSPs. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 9] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ >>>>>>> |Switch, | | | | | | | |Switc= h, | >>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rout= er | >>>>>>> | OC/BC | | BC | | TC | | BC | | OC/B= C | >>>>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ >>>>>>> >>>>>>> Figure (2) - Deployment example 2 of timing over MPLS network >>>>>>> >>>>>>> >>>>>>> Another example is shown in Figure 3, where LERs do not terminate= the >>>>>>> Timing messages received from switch/routers that are outside of= the >>>>>>> MPLS network acting as OC, TC or BC. The LERs act as TC and upda= te >>>>>>> the Timing field in the Timing messages as they transit the LER, >>>>>>> while encapsulating them in timing LSP. The LSRs also act as >>>>>>> Transparent Clock (TC) and just update the Timing field in the Ti= ming >>>>>>> messages which are already encapsulated in Timing LSPs. >>>>>>> >>>>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ >>>>>>> |Switch, | | | | | | | |Swit= ch, | >>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rou= ter | >>>>>>> |OC/TC/BC| | TC | | TC | | TC | |OC/T= C/BC| >>>>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ >>>>>>> >>>>>>> Figure (3) - Deployment example 3 of timing over MPLS network >>>>>>> >>>>>>> Another example is shown in Figure 4, where LERs and LSRs support >>>>>>> Boundary Clocks. A single-hop LSP is created between two adjacen= t >>>>>>> LSRs engaged in BC operation. Other methods such as PTP transpor= t >>>>>>> over Ethernet MAY be used for transporting timing messages if the >>>>>>> link between the two routers is Ethernet. >>>>>>> >>>>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ >>>>>>> |Switch, | | | | | | | |Switc= h, | >>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rout= er | >>>>>>> | OC/BC | | BC | | BC | | BC | | OC/B= C | >>>>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ >>>>>>> >>>>>>> Figure (4) - Deployment example 3 of timing over MPLS network >>>>>>> >>>>>>> An MPLS domain MAY serve multiple customers. In these cases the >>>> MPLS >>>>>>> domain (maintained by a service provider) may provide timing serv= ices >>>>>>> to multiple customers, each having their own Timing domain. >>>>>>> >>>>>>> The Timing over MPLS architecture assumes full mesh of Timing LSP= s >>>>>>> between all LERs supporting this specification. >>>>>>> >>>>>>> SB> Note sure this is right - the salves surely do not need to >>>>>>> SB> exchange timing amongst themselves >>>>>>> >>>>>>> It supports >>>>>>> Point-to- point (VPWS) and Multipoint (VPLS) services. >>>>>>> >>>>>>> SB> What does that mean? You do not carry user data traffic? >>>>>>> SB> Maybe it's the ordering of the statemnets that is causing >>>>>>> SB> confusion. >>>>>>> >>>>>>> This means >>>>>>> that a customer may purchase a Point-to-point Timing service betw= een >>>>>>> two customer sites or a Multipoint Timing service between more th= an >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 10] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> two customer sites. >>>>>>> >>>>>>> The Timing over MPLS architecture supports P2P or P2MP Timing LSP= s. >>>>>>> This means that the Timing Multicast messages such as PTP Multica= st >>>>>>> event messages can be transported over P2MP Timing LSP or be >>>>>>> replicated and transported over many P2P Timing LSPs. >>>>>>> >>>>>>> SB> Note we do not yet have a definition of a P2MP mpls-tp LSP >>>>>>> SB> nor a P2MP PW, although we are close. >>>>>>> >>>>>>> Timing messages, that do not require Time stamping or Correction >>>>>>> Field update MAY be transported over Timing LSPs to simplify hard= ware >>>>>>> and software. >>>>>>> >>>>>>> PTP Announce messages that determine the Timing LSP terminating >>>> point >>>>>>> behavior such as BC/OC/TC SHOULD be transported over the Timing L= SP >>>>>>> to simplify hardware and software. >>>>>>> >>>>>>> SB> have you defined and referenced PTP announce msgs? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 11] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 5. Dedicated LSPs for Timing messages >>>>>>> >>>>>>> Many methods have been considered for identifying the Timing >>>> messages >>>>>>> when they are encapsulated in MPLS such as using GAL/G-ACH or a n= ew >>>>>>> reserved label. These methods were not attractive since they eit= her >>>>>>> required deep packet inspection at line rate in the intermediate= LSRs >>>>>>> or they required use of a scarce new reserved label. Also one of= the >>>>>>> goals was to reuse existing OAM mechanisms. >>>>>>> >>>>>>> SB> RLs =3D SPLs are not so rare now. In any case needs a ref. >>>>>>> >>>>>>> The method defined in this document can be used by LER and LSRs t= o >>>>>>> identify Timing messages in MPLS tunnels by just looking at the t= op >>>>>>> label in the MPLS label stack, which only carry Timing messages a= s >>>>>>> well as OAM, but not data plane client traffic. >>>>>>> >>>>>>> Compliant implementations MUST use dedicated LSPs to carry Timing >>>>>>> messages over MPLS. >>>>>>> >>>>>>> SB> I think that we need a definition of the properies of these LSPs >>>>>>> >>>>>>> These LSPs are herein referred to as "Timing >>>>>>> LSPs" and the labels associated with these LSPs as "Timing LSP >>>>>>> labels". The Timing LSPs that runs between Ingress and Egress LE= Rs >>>>>>> MUST be co-routed. Alternatively, a single bidirectional co-rout= ed >>>>>>> LSP can be used. >>>>>>> >>>>>>> SB> I though that you said you could use M2MP LSPs - these are not >>>>>>> SB> bidirectional. >>>>>>> >>>>>>> Co-routing of the two directions is required to limit the differe= nce >>>>>>> in the delays in the Master clock to Slave clock direction compar= ed >>>>>>> to the Slave clock to Master clock direction. The Timing LSP MAY= be >>>>>>> MPLS/MPLS-TP LSP. >>>>>>> >>>>>>> The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS= . >>>>>>> New Extensions to RSVP-TE/GMPLS TLVs are required; however they a= re >>>>>>> outside the scope of this document. >>>>>>> >>>>>>> The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such= as >>>>>>> BFD and LSP Ping but the LSP data plane client plane traffic MUST= be >>>>>>> Timing packets only. >>>>>>> >>>>>>> SB> Why? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 12] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 6. Timing over LSP Encapsulation >>>>>>> >>>>>>> The encapsulations is not LSP is it? >>>>>>> >>>>>>> This document defines two methods for carrying Timing messages ov= er >>>>>>> MPLS. The first method is carrying UDP/IP encapsulated Timing >>>>>>> messages over Timing LSPs, and the second method, is carrying >>>>>>> Ethernet encapsulated Timing messages over Ethernet PWs inside >>>> Timing >>>>>>> LSPs. >>>>>>> >>>>>>> 6.1. Timing over UDP/IP over MPLS Encapsulation >>>>>>> >>>>>>> The simplest method of transporting Timing messages over MPLS is= to >>>>>>> encapsulate Timing PDUs in UDP/IP and then encapsulate them in >>>> Timing >>>>>>> LSP. This format is shown in Figure 4. >>>>>>> >>>>>>> >>>>>>> +----------------------+ >>>>>>> | Timing LSP Label | >>>>>>> +----------------------+ >>>>>>> | IPv4/6 | >>>>>>> +----------------------+ >>>>>>> | UDP | >>>>>>> +----------------------+ >>>>>>> | Timing PDU | >>>>>>> +----------------------+ >>>>>>> >>>>>>> Figure (4) - Timing over UDP/IP over MPLS Encapsulation >>>>>>> >>>>>>> >>>>>>> This encapsulation is very simple and is useful when the network >>>>>>> between Timing Master Clock and Slave Clock is MPLS network. >>>>>>> >>>>>>> SB> Simple is a judgement call >>>>>>> >>>>>>> In order for an LER/LSR to process Timing messages, the Timing LS= P >>>>>>> Label must be at the top label of the label stack. The LER/LSR M= UST >>>>>>> know that the Timing LSP Label is used for carrying Timing messag= es. >>>>>>> This can be accomplished via static configuration or via RSVP-TE >>>>>>> signaling. >>>>>>> >>>>>>> The UDP/IP encapsulation of PTP MUST follow Annex D and E of >>>>>>> [IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow >>>>>>> [RFC5905]. >>>>>>> >>>>>>> 6.2. Timing over PW Encapsulation >>>>>>> >>>>>>> Another method of transporting Timing over MPLS networks is by >>>>>>> encapsulating Timing PDUs in PW which in turn is transported over >>>>>>> Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448]= , >>>>>>> shown in Fig 5(A) MUST be used and the Ethernet encapsulation of= PTP >>>>>>> MUST follow Annex F of [IEEE-1588]. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 13] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> The RAW mode or Tagged mode defined in [RFC4448] MAY be used and >>>> the >>>>>>> Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The >>>>>>> Timing over PW encapsulation MUST use the Control Word (CW) as >>>>>>> specified in [RFC4448] to ensure proper detection of PTP messages >>>>>>> inside the MPLS packets for Timing over LSP and Timing over PW >>>>>>> encapsulation. >>>>>>> >>>>>>> SB> That needs explanation >>>>>>> >>>>>>> The use of Sequence Number in the CW is optional. >>>>>>> >>>>>>> SB> Given that s/n are never in practice deployed, you could probabl= y >>>>>>> SB> simplify things by sayig that they are not used. >>>>>>> >>>>>>> Timing over PW encapsulation for NTP MUST use NTP over UDP/IP ove= r >>>> PW >>>>>>> (the IP PW discussed in [RFC4447]) shown in Fig 5(B). >>>>>>> >>>>>>> +----------------+ +----------------+ >>>>>>> |Timing LSP Label| |Timing LSP Label| >>>>>>> +----------------+ +----------------+ >>>>>>> | PW Label | | PW Label | >>>>>>> +----------------+ +----------------+ >>>>>>> | Control Word | | IP | >>>>>>> +----------------+ +----------------+ >>>>>>> | Ethernet | | UDP | >>>>>>> | Header | +----------------+ >>>>>>> +----------------+ | Timing PDU | >>>>>>> |S-VLAN(Optional)| | | >>>>>>> +----------------+ +----------------+ >>>>>>> |C-VLAN(Optional)| (B) >>>>>>> +----------------+ >>>>>>> | Timing PDU | >>>>>>> | | >>>>>>> +----------------+ >>>>>>> (A) >>>>>>> >>>>>>> Figure (5) - Timing over PW Encapsulations >>>>>>> >>>>>>> In order for an LSR to process PTP messages, the top label of the >>>>>>> label stack (the Tunnel Label) MUST be a Timing label. >>>>>>> >>>>>>> S> You said that before. >>>>>>> >>>>>>> 6.3. Other Timing Encapsulation methods >>>>>>> >>>>>>> In future other timing encapsulation methods may be introduced, s= uch >>>>>>> as a new shim header after the Bottom of Stack to carry the Timin= g >>>>>>> information. Such new encapsulations are outside the scope of th= is >>>>>>> document. >>>>>>> >>>>>>> >>>>>>> SB> Taking a pure MPLS pov, you can simplify a lot of the text >>>>>>> SB> out of the definition of the LSP >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 14] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> SB> I think we need a section on LSP processing >>>>>>> >>>>>>> 7. Timing message Processing >>>>>>> >>>>>>> Each Timing protocol such as PTP and NTP, define their set of Tim= ing >>>>>>> messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, >>>>>>> FOLLOW_UP, etc messages. >>>>>>> >>>>>>> Some of the Timing messages require time stamping or correction f= ield >>>>>>> update at port level and some dont. It is the job of the LER/LSR= to >>>>>>> parse the timing message and find out the type of the Timing mess= age >>>>>>> and decide whether and how to Time- stamp it (e.g., BC) or update >>>>>>> correction field(e.g., TC). >>>>>>> >>>>>>> >>>>>>> SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing >>>>>>> SB> function rather than the LER? >>>>>>> >>>>>>> For example the following PTP messages (called Event messages) >>>>>>> require time-stamping or correction field update: >>>>>>> >>>>>>> o SYNC >>>>>>> >>>>>>> o DELAY_REQ (Delay Request) >>>>>>> >>>>>>> o PDELAY_REQ (Peer Delay Request) >>>>>>> >>>>>>> o PDELAY_RESP (Peer Delay Response) >>>>>>> >>>>>>> SYNC and DELAY_REQ are exchanged between Master Clock and Slave >>>> Clock >>>>>>> and MUST be transported over PTP LSPs. PDELAY_REQ and >>>> PDELAY_RESP >>>>>>> are exchanged between adjacent PTP clocks (i.e. Master, Slave, >>>>>>> Boundary, or Transparent) and SHOULD be transported over single h= op >>>>>>> PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP= , >>>>>>> and PDELAY_RESP_FOLLOW_UP messages MUST also be transported >>>> over >>>>>>> the >>>>>>> PTP LSPs. >>>>>>> >>>>>>> For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be >>>>>>> transported over two PTP LSPs that are in opposite directions. T= hese >>>>>>> PTP LSPs, which are in opposite directions MUST be congruent and= co- >>>>>>> routed. Alternatively, a single bidirectional co-routed LSP can= be >>>>>>> used. >>>>>>> >>>>>>> Except as indicated above for the two-step PTP clocks, Non-Event= PTP >>>>>>> message types do not need to be processed by intermediate routers= . >>>>>>> These message types MAY be carried in PTP Tunnel LSPs. >>>>>>> >>>>>>> SB> Are you saying that a timing P router has to be msg type sensiti= ve? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 15] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 8. Protection and Redundancy >>>>>>> >>>>>>> >>>>>>> SB> This is a bit of a jump - I don't know how the LSP itself works= yet! >>>>>>> >>>>>>> In order to ensure continuous uninterrupted operation of slave >>>>>>> clocks, usually as a general practice, slave clocks (or ports) tr= ack >>>>>>> redundant master clocks. >>>>>>> >>>>>>> It is the responsibility of the network operator to ensure that >>>>>>> physically disjoint Timing LSPs are established between a slave c= lock >>>>>>> (or port) and redundant master clocks (or ports). >>>>>>> >>>>>>> When a slave clock (or port) listens to redundant master clocks o= r >>>>>>> ports, any prolonged Timing LSP outage will trigger the slave clo= ck >>>>>>> or port to switch to a redundant master clock or port. >>>>>>> >>>>>>> LSP/PW protection such as Linear protection Switching (1:1, 1+1), >>>>>>> Ring protection switching or MPLS Fast Reroute (FRR) generally sw= itch >>>>>>> alternative path that usually cause a change in delay, which if >>>>>>> undetected by slave clock can reduce accuracy of the slave clock. >>>>>>> >>>>>>> Therefore protection switching MAY be used, as long as phase jump= s >>>>>>> upon switchover due to differences in path latency are detected a= nd >>>>>>> compensated for (such compensation not being required if BCs or p= eer- >>>>>>> peer TCs are used throughout). >>>>>>> >>>>>>> Note that any protection or reroute mechanism that adds additiona= l >>>>>>> MPLS label to the label stack, such as Facility Backup Fast Rerou= te, >>>>>>> MUST ensure that the pushed label is also a Timing Label to ensur= e >>>>>>> recognition of the MPLS frame as containing Timing messages, as i= t >>>>>>> transits the backup path. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 16] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 9. ECMP >>>>>>> >>>>>>> To ensure the optimal operation of slave clocks and avoid error >>>>>>> introduced by forward and reverse path delay asymmetry, the physi= cal >>>>>>> path for Timing messages from master clock to slave Clock and vic= e >>>>>>> versa must be the same for all Event Timing messages listed in >>>>>>> section 7. >>>>>>> >>>>>>> Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost >>>>>>> Multipath). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 17] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 10. PHP >>>>>>> >>>>>>> To ensure that the label on the top of the label stack is the Tim= ing >>>>>>> LSP Label, PHP MUST not be used. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 18] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 11. Entropy >>>>>>> >>>>>>> To ensure all Timing messages in a Timing LSP take the same path, >>>>>>> Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and >>>>>>> Entropy Label MUST NOT be used for the PWs that are carried insid= e >>>>>>> Timing LSP [RFC6391]. >>>>>>> >>>>>>> SB> This is incorrect - you mean that all msgs of the same timing >>>>>>> SB> flow need to have the same EL value. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 19] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 12. OAM, Control and Management >>>>>>> >>>>>>> In order to monitor Timing LSPs and their encapsulated PWs, they= MUST >>>>>>> be able to carry OAM and management messages. These management >>>>>>> messages MUST be differentiated from Timing messages via already >>>>>>> defined IETF methods. >>>>>>> >>>>>>> For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY r= un >>>>>>> over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These >>>>>>> Management protocols can easily be identified by the UDP Destinat= ion >>>>>>> Port number or by GAL/G-ACH respectively. >>>>>>> >>>>>>> Also BFD, LSP-Ping and other management messages MAY run over the >>>> PWs >>>>>>> encapsulated in Timing LSP via one of the defined VCCVs (Type 1,= 3 or >>>>>>> 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is g= oing >>>>>>> to be deprecated by IETF). In this case G-ACH, PW label (TTL=3D1= ) or >>>>>>> GAL-ACH are used to identify such management messages. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 20] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 13. QoS Considerations >>>>>>> >>>>>>> In network deployments where not every LSR/LER is Timing-aware, i= t is >>>>>>> important to reduce the impact of the non-Timing-aware LSR/LERs o= n >>>>>>> the timing recovery in the slave clock. The Timing messages are= time >>>>>>> critical and must be treated with the highest priority. Therefor= e >>>>>>> Timing over MPLS messages must be treated with the highest priori= ty >>>>>>> in the routers. This can be achieved by proper setup of Timing L= SPs. >>>>>>> >>>>>>> It is recommended that the Timing LSPs are setup or configured >>>>>>> properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC26= 97] >>>>>>> for drop eligibility. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 21] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 14. FCS and Checksum Recalculation >>>>>>> >>>>>>> When time-stamp generation and timing packet adjustment is perfor= med >>>>>>> near the physical port hardware, the process MUST include >>>>>>> recalculation of the Ethernet FCS. >>>>>>> >>>>>>> SB> The above is confusing - an LSR always recomputes the link layer >>>>>>> SB> CRC which may or may not be Ethernet. >>>>>>> >>>>>>> Also FCS retention for the >>>>>>> payload Ethernet described in [RFC4720] MUST NOT be used. >>>>>>> >>>>>>> For UDP/IP encapsulation mode of Timing over MPLS, the UDP checks= um >>>>>>> may be required as per UDP transport standards. >>>>>>> >>>>>>> SB> You really need to be working on getting the IPv6 C?S computatio= n >>>>>>> SB> removed from PTP msgs. >>>>>>> >>>>>>> When UDP checksum is used, each Timing-aware LER/LSR must either >>>>>>> incrementally update the UDP checksum after Time stamping or >>>>>>> Correction Field update or verify the UDP checksum on reception f= rom >>>>>>> upstream and recalculate the checksum completely on transmission= to >>>>>>> downstream node after Time stamping or Correction Field update. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 22] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 15. Behavior of LER/LSR >>>>>>> >>>>>>> Timing-capable/aware LERs and LSRs are routers that have one or m= ore >>>>>>> >>>>>>> SB> You mean physical interfaces? >>>>>>> >>>>>>> interfaces that can perform Timing operations (OC/BC/TC) on Timin= g >>>>>>> packets and are configured to do so. Timing-capable/aware LERs a= nd >>>>>>> LSRs can advertise their Timing-capability per-interface via cont= rol >>>>>>> plane such as OSPF or IS-IS. >>>>>>> SB> ISIS and OSPF are routing protocols. >>>>>>> >>>>>>> The Timing-capable/aware LERs can then >>>>>>> signals Timing LSPs via RSVP-TE signaling. Alternatively the Tim= ing >>>>>>> capability of LER and LSRs may be configured in a centralized >>>>>>> controller and the Timing LSP may be setup using manual configura= tion >>>>>>> or other methods such as SDN. >>>>>>> >>>>>>> SB> it can also be configured individually rather then through >>>>>>> SB> a cebtral controllwe >>>>>>> >>>>>>> 15.1. Behavior of Timing-capable/aware LER >>>>>>> >>>>>>> When a Timing-capable/aware LER behaves as a Transparent clock an= d >>>>>>> receives a Timing message from a Timing-capable/aware non-MPLS >>>>>>> interface, the LER updates the Correction Field (CF) and encapsul= ates >>>>>>> and forwards the timing message over previously established Timin= g >>>>>>> LSP. >>>>>>> >>>>>>> SB> You need to call out the details so that people properly >>>>>>> SB> understand the definition of the new LSP. >>>>>>> >>>>>>> Also when a Timing message is received from a Timing-capable/ >>>>>>> aware MPLS interface, LER updates the Correction Filed (CF) and >>>>>>> decapsulates the MPLS encapsulation and forwards the timing messa= ge >>>>>>> to a non-MPLS interface. >>>>>>> >>>>>>> When a Timing-capable/aware LER behaves as a Boundary clock and >>>>>>> receives a Timing message from a Timing-capable/aware non MPLS >>>>>>> interface, the LER Timestamps the Timing packet and sends it to t= he >>>>>>> LERs Boundary clock processing module. Also when a Timing messag= e is >>>>>>> received from a Timing- capable/aware MPLS interface, the LER >>>>>>> Timestamps the Timing packet and sends it to the LERs Boundary cl= ock >>>>>>> processing module. >>>>>>> >>>>>>> When a Timing-capable/aware LER behaves as an Ordinary Clock towa= rd >>>>>>> the MPLS network, and receives a Timing message from a Timing- >>>>>>> capable/aware MPLS interface, the LER Timestamps the Timing packe= t >>>>>>> and sends it to the LERs Ordinary clock processing module. >>>>>>> >>>>>>> 15.2. Behavior of Timing-capable/aware LSR >>>>>>> >>>>>>> When a Timing-capable/aware LSR behaves as a Transparent clock an= d >>>>>>> receives a Timing message from a Timing-capable/aware MPLS >>>> interface, >>>>>>> The LSR updates the Correction Filed (CF) and forwards the timing >>>>>>> message over another MPLS interface. >>>>>>> >>>>>>> When a Timing-capable/aware LSR behaves as a Boundary clock and >>>>>>> receives a Timing message from a Timing-capable/aware MPLS >>>> interface. >>>>>>> The LSR performs the functions of a Boundary Clock in terminating= the >>>>>>> received Timing message and re-generating a new timing message ov= er >>>>>>> another (or the same) MPLS interface. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 23] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 15.3. Behavior of non-Timing-capable/aware LSR >>>>>>> >>>>>>> It is most beneficial when all LSRs in the path of a Timing LSP b= e >>>>>>> timing-Capable/aware LSRs. This would ensure the highest quality >>>>>>> time and clock synchronization by Timing Slave Clocks. However,= this >>>>>>> specification does not mandate that all LSRs in path of a Timing= LSP >>>>>>> be Timing- capable/aware. >>>>>>> >>>>>>> Non-Timing-capable/aware LSRs just switch the packets encapsulate= d in >>>>>>> Timing LSPs and dont perform any Timing operation (TC or BC). >>>>>>> However as explained in QoS section the Timing over MPLS packets >>>> MUST >>>>>>> be still be treated with the highest priority based on their Traf= fic >>>>>>> Class (TC) marking. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 24] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 16. Other considerations >>>>>>> >>>>>>> [IEEE-1588] defines an optional peer-to-peer Transparent clocking >>>>>>> that requires peer delay measurement between two adjacent Timing- >>>>>>> capable/ aware routers/switches. Peer delay measurement messages >>>>>>> need to be time stamped and terminated by the Timing-capable/awar= e >>>>>>> routers/ switches. This means that two adjacent LSRs may be enga= ged >>>>>>> in a peer delay measurement. >>>>>>> >>>>>>> For transporting such peer delay measurement messages a single-ho= p >>>>>>> LSP SHOULD to be created between the two adjacent LSRs engaged in >>>>>>> peer delay measurement to carry peer delay measurement messages. >>>>>>> Other methods such as PTP transport over Ethernet MAY be used for >>>>>>> transporting peer delay measurement messages if the link between= the >>>>>>> two routers is Ethernet. >>>>>>> >>>>>>> In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/= ware >>>>>>> routers/switches MUST maintain a list of all the neighbors it nee= ds >>>>>>> to send a PDelay_Req to, where each neighbor corresponds to a tim= ing >>>>>>> LSP. >>>>>>> >>>>>>> The use of Explicit Null Label (Label=3D 0 or 2) is acceptable as= long >>>>>>> as either the Explicit Null label is the bottom of stack label >>>>>>> (applicable only to UDP/IP encapsulation) or the label below the >>>>>>> Explicit Null label is a PTP label. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 25] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 17. Security Considerations >>>>>>> >>>>>>> MPLS PW security considerations in general are discussed in [RFC3= 985] >>>>>>> and [RFC4447],and those considerations also apply to this documen= t. >>>>>>> >>>>>>> An experimental security protocol is defined in [IEEE-1588].The P= TP >>>>>>> security extension and protocol provides group source authenticat= ion, >>>>>>> message integrity, and replay attack protection for PTP messages. >>>>>>> >>>>>>> When the MPLS network (provider network) serves multiple customer= s, >>>>>>> it is important to maintain and process each customers clock and >>>>>>> Timing messages separately from other customers to ensure there i= s no >>>>>>> cross- customer effect. For example if an LER BC is synchronized= to >>>>>>> a specific grandmaster, belonging to customer A, then the LER MUS= T >>>>>>> use that BC clock only for customer A to ensure that customer A >>>>>>> cannot attack other customers by manipulating its time. >>>>>>> >>>>>>> Timing messages MAY be encrypted or authenticated, provided that= the >>>>>>> LERs/LSRs that are Timing capable/aware can authenticate/ decrypt= the >>>>>>> timing messages. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 26] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 18. Acknowledgements >>>>>>> >>>>>>> The authors would like to thank Ron Cohen, Yaakov Stein, Tal Mizr= ahi, >>>>>>> Stefano Ruffini, Peter Meyer, and other members of IETF for revie= wing >>>>>>> and providing feedback on this draft. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 27] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 19. IANA Considerations >>>>>>> >>>>>>> There are no IANA requirements in this specification. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 28] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 20. References >>>>>>> >>>>>>> 20.1. Normative References >>>>>>> >>>>>>> [IEEE-1588] >>>>>>> IEEE 1588-2008, "IEEE Standard for a Precision Clock >>>>>>> Synchronization Protocol for Networked Measurement and >>>>>>> Control Systems". >>>>>>> >>>>>>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >>>>>>> Requirement Levels", BCP 14, RFC 2119, March 1997. >>>>>>> >>>>>>> [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to= - >>>>>>> Edge (PWE3) Architecture", RFC 3985, March 2005. >>>>>>> >>>>>>> [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discov= ery >>>>>>> Proxies (ND Proxy)", RFC 4389, April 2006. >>>>>>> >>>>>>> [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G= . >>>>>>> Heron, "Pseudowire Setup and Maintenance Using the Lab= el >>>>>>> Distribution Protocol (LDP)", RFC 4447, April 2006. >>>>>>> >>>>>>> [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, >>>>>>> "Encapsulation Methods for Transport of Ethernet over= MPLS >>>>>>> Networks", RFC 4448, April 2006. >>>>>>> >>>>>>> [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire >>>>>>> Emulation Edge-to-Edge (PWE3) Frame Check Sequence >>>>>>> Retention", RFC 4720, November 2006. >>>>>>> >>>>>>> [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circu= it >>>>>>> Connectivity Verification (VCCV): A Control Channel fo= r >>>>>>> Pseudowires", RFC 5085, December 2007. >>>>>>> >>>>>>> [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detect= ion >>>>>>> (BFD)", RFC 5880, June 2010. >>>>>>> >>>>>>> [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow= , >>>>>>> "Bidirectional Forwarding Detection (BFD) for MPLS Lab= el >>>>>>> Switched Paths (LSPs)", RFC 5884, June 2010. >>>>>>> >>>>>>> 20.2. Informative References >>>>>>> >>>>>>> [I-D.ietf-pwe3-fat-pw] >>>>>>> Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Reg= an, >>>>>>> J., and S. Amante, "Flow Aware Transport of Pseudowire= s >>>>>>> over an MPLS Packet Switched Network", >>>>>>> draft-ietf-pwe3-fat-pw-07 (work in progress), July 201= 1. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 29] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermedia= te >>>>>>> system routeing information exchange protocol for use= in >>>>>>> conjunction with the Protocol for providing the >>>>>>> Connectionless-mode Network Service (ISO 8473)". >>>>>>> >>>>>>> [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP an= d >>>>>>> dual environments", RFC 1195, December 1990. >>>>>>> >>>>>>> [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 199= 8. >>>>>>> >>>>>>> [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color >>>>>>> Marker", RFC 2697, September 1999. >>>>>>> >>>>>>> [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boud= ec, >>>>>>> J., Courtney, W., Davari, S., Firoiu, V., and D. >>>>>>> Stiliadis, "An Expedited Forwarding PHB (Per-Hop >>>>>>> Behavior)", RFC 3246, March 2002. >>>>>>> >>>>>>> [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Enginee= ring >>>>>>> (TE) Extensions to OSPF Version 2", RFC 3630, >>>>>>> September 2003. >>>>>>> >>>>>>> [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermedia= te >>>>>>> System (IS-IS) Extensions for Traffic Engineering (TE)= ", >>>>>>> RFC 3784, June 2004. >>>>>>> >>>>>>> [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and= S. >>>>>>> Shaffer, "Extensions to OSPF for Advertising Optional >>>>>>> Router Capabilities", RFC 4970, July 2007. >>>>>>> >>>>>>> [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate >>>>>>> System to Intermediate System (IS-IS) Extensions for >>>>>>> Advertising Router Information", RFC 4971, July 2007. >>>>>>> >>>>>>> [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi >>>>>>> Topology (MT) Routing in Intermediate System to >>>>>>> Intermediate Systems (IS-ISs)", RFC 5120, February 200= 8. >>>>>>> >>>>>>> [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic >>>>>>> Engineering", RFC 5305, October 2008. >>>>>>> >>>>>>> [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, >>>>>>> "Traffic Engineering Extensions to OSPF Version 3", >>>>>>> RFC 5329, September 2008. >>>>>>> >>>>>>> [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSP= F >>>>>>> for IPv6", RFC 5340, July 2008. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 30] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Net= work >>>>>>> Time Protocol Version 4: Protocol and Algorithms >>>>>>> Specification", RFC 5905, June 2010. >>>>>>> >>>>>>> [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Reg= an, >>>>>>> J., and S. Amante, "Flow-Aware Transport of Pseudowire= s >>>>>>> over an MPLS Packet Switched Network", RFC 6391, >>>>>>> November 2011. >>>>>>> >>>>>>> [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., a= nd >>>>>>> L. Yong, "The Use of Entropy Labels in MPLS Forwarding= ", >>>>>>> RFC 6790, November 2012. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 31] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 1. Routing extensions for Timing-aware Routers >>>>>>> >>>>>>> MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340]= and >>>>>>> IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (= TE) >>>>>>> link information used for constraint-based routing. >>>>>>> >>>>>>> Indeed, it is useful to advertise data plane TE router link >>>>>>> capabilities, such as the capability for a router to be Timing-aw= are. >>>>>>> This capability MUST then be taken into account during path >>>>>>> computation to prefer or even require links that advertise themse= lves >>>>>>> as Timing-aware. In this way the path can ensure the entry and e= xit >>>>>>> points into the LERs and, if desired, the links into the LSRs are >>>>>>> able to perform port based time-stamping thus minimizing their im= pact >>>>>>> on the performance of the slave clock. >>>>>>> >>>>>>> extensions are required to OSPF and IS-IS in order to advertise >>>>>>> Timing-aware capabilities of a link. Such extensions are outside= the >>>>>>> scope of this document; however such extension SHOULD be able to >>>>>>> signal the following information per Router Link: >>>>>>> >>>>>>> o Capable of processing PTP, NTP or other Timing flows >>>>>>> >>>>>>> o Capable of performing Transparent Clock operation >>>>>>> >>>>>>> o Capable of performing Boundary Clock operation >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 32] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> 2. Signaling Extensions for Creating Timing LSPs >>>>>>> >>>>>>> RSVP-TE signaling MAY be used to setup the timing LSPs. When RSV= P-TE >>>>>>> is used to setup Timing LSPs, some information that indicates tha= t >>>>>>> the LSP is carrying Timing flows MUST be included in the new >>>>>>> Extensions to RSVP-TE: >>>>>>> >>>>>>> The following information MAY also be included in the new Extensi= ons >>>>>>> to RSVP-TE: >>>>>>> >>>>>>> o Offset from Bottom of Stack (BoS) to the start of the Time-sta= mp >>>>>>> field >>>>>>> >>>>>>> o Number of VLANs in case of PW encapsulation >>>>>>> >>>>>>> o Timestamp field Type >>>>>>> >>>>>>> * Correction Field, Timestamp >>>>>>> >>>>>>> o Timestamp Field format >>>>>>> >>>>>>> * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit >>>>>>> NTP, etc. >>>>>>> >>>>>>> Note that in case the above optional information is signaled with >>>>>>> RSVP-TE for a Timing LSP, all the Timing packets carried in that= LSP >>>>>>> must have the same signaled characteristics. For example if >>>>>>> Timestamp format is signaled as 64-bit PTPv1, then all Timing pac= kets >>>>>>> must use 64-bit PTPv1 time-stamp. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 33] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> Authors' Addresses >>>>>>> >>>>>>> Shahram Davari >>>>>>> Broadcom Corp. >>>>>>> San Jose, CA 95134 >>>>>>> USA >>>>>>> >>>>>>> Email: davari@broadcom.com >>>>>>> >>>>>>> >>>>>>> Amit Oren >>>>>>> Broadcom Corp. >>>>>>> San Jose, CA 95134 >>>>>>> USA >>>>>>> >>>>>>> Email: amito@broadcom.com >>>>>>> >>>>>>> >>>>>>> Manav Bhatia >>>>>>> Alcatel-Lucent >>>>>>> Bangalore, >>>>>>> India >>>>>>> >>>>>>> Email: manav.bhatia@alcatel-lucent.com >>>>>>> >>>>>>> >>>>>>> Peter Roberts >>>>>>> Alcatel-Lucent >>>>>>> Kanata, >>>>>>> Canada >>>>>>> >>>>>>> Email: peter.roberts@alcatel-lucent.com >>>>>>> >>>>>>> >>>>>>> Laurent Montini >>>>>>> Cisco Systems >>>>>>> San Jose CA >>>>>>> USA >>>>>>> >>>>>>> Email: lmontini@cisco.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 34] >>>>>>> Internet-Draft Transporting Timing over MPLS June= 2013 >>>>>>> >>>>>>> >>>>>>> Luca >>>>>>> Cisco Systems >>>>>>> San Jose CA >>>>>>> USA >>>>>>> >>>>>>> Email: lmartini@cisco.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 35] >>>>>>> -- >>>>>>> For corporate legal information go to: >>>>>>> >>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>>> >>>>>>> _______________________________________________ >>>>>>> TICTOC mailing list >>>>>>> TICTOC@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/tictoc >>>>>> 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 >>>>> . >>>> >>>> -- >>>> For corporate legal information go to: >>>> >>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>> >>>> _______________________________________________ >>>> TICTOC mailing list >>>> TICTOC@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tictoc >>>> >>>> >>>> _______________________________________________ >>>> TICTOC mailing list >>>> TICTOC@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tictoc >>> >>> This e-mail message is intended for the recipient only and contains info= rmation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f 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. >> . > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > This e-mail message is intended for the recipient only and contains inform= ation 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, p= hone or fax, and then delete the original and all copies thereof. > 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 iesg-secretary@ietf.org Tue Aug 20 15:24:03 2013 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 2F5BF11E8337; Tue, 20 Aug 2013 15:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.127, 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 tk433Bt53fzU; Tue, 20 Aug 2013 15:23:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F4D11E8310; Tue, 20 Aug 2013 15:23:05 -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: 4.70.p1 Sender: Message-ID: <20130820222250.23775.77113.idtracker@ietfa.amsl.com> Date: Tue, 20 Aug 2013 15:22:50 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: (Using LDP Multipoint Extensions on Targeted LDP Sessions) 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, 20 Aug 2013 22:24:03 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Using LDP Multipoint Extensions on Targeted LDP Sessions' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-03. 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 As specified in RFC 6388, Label Distribution Protocol (LDP) can be used to set up Point-to-Multipoint (P2MP) and Multipoint-to- Multipoint (MP2MP) Label Switched Paths. However, RFC 6388 presupposes that the two endpoints of an LDP session are directly connected. The LDP base specification (RFC 5036) allows for the case where the two endpoints of an LDP session are not directly connected; such a session is known as a "Targeted LDP" session. This document provides the specification for using the LDP P2MP/MP2MP extensions over a Targeted LDP session. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-targeted-mldp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-targeted-mldp/ballot/ No IPR declarations have been submitted directly on this I-D. From loa@pi.nu Wed Aug 21 01:09:14 2013 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 4A51E11E81E3 for ; Wed, 21 Aug 2013 01:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id molqq8BKXJpY for ; Wed, 21 Aug 2013 01:09:08 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 657A511E81CB for ; Wed, 21 Aug 2013 01:09:08 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 771171802038; Wed, 21 Aug 2013 10:09:07 +0200 (CEST) Message-ID: <521475A6.7080002@pi.nu> Date: Wed, 21 Aug 2013 10:09:10 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] IPR poll on draft-rekhter-mpls-pim-sm-over-mldp 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, 21 Aug 2013 08:09:14 -0000 Working Group, The authors of draft-rekhter-mpls-pim-sm-over-mldp has told the working group chairs that the draft is ready to be adopted as a working group document. Before we start the mpls-rt review and the poll for adoption we will do an IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-rekhter-mpls-pim- sm-over-mldp? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The documents will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From ryoo@etri.re.kr Wed Aug 21 02:01:22 2013 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 E4BC411E81F3 for ; Wed, 21 Aug 2013 02:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.48 X-Spam-Level: X-Spam-Status: No, score=-101.48 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 2qyAoW-IygP2 for ; Wed, 21 Aug 2013 02:01:17 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id 59A4F11E838E for ; Wed, 21 Aug 2013 02:01:17 -0700 (PDT) Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 21 Aug 2013 18:01:06 +0900 Received: from SMTP2.etri.info ([169.254.2.105]) by SMTP1.etri.info ([129.254.28.71]) with mapi id 14.01.0355.002; Wed, 21 Aug 2013 18:01:03 +0900 From: =?utf-8?B?66WY7KCV64+Z?= To: Yaacov Weingarten , "loa@pi.nu" , "mpls@ietf.org" , "draft-rhd-mpls-tp-psc-priority@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "martin.vigoureux@alcatel-lucent.com" Thread-Topic: [mpls] MPLS-RT review of draft-rhd-mpls-tp-psc-priority Thread-Index: AQHOme9PtFLu03g9EE2vW/csAUwXqZmfY/fY Date: Wed, 21 Aug 2013 09:01:03 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A2866A35E@SMTP2.etri.info> References: In-Reply-To: Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A2866A35ESMTP2etriinfo_" MIME-Version: 1.0 Subject: [mpls] =?utf-8?b?7ZqM7IugOiAgTVBMUy1SVCByZXZpZXcgb2YgZHJhZnQtcmhk?= =?utf-8?q?-mpls-tp-psc-priority?= 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, 21 Aug 2013 09:01:23 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A2866A35ESMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpZYWFjb3YsIHRoYW5rIHlvdSBmb3IgcHJvdmlkaW5nIHRoZSBjb21tZW50cy4NCg0KSSBkaXNj dXNzZWQgeW91ciBjb21tZW50cyB3aXRoIHRoZSBvdGhlciBjby1hdXRob3JzIG9mIHRoaXMgZHJh ZnQsIGFuZCB0aGUgcmV2aXNlZCBkcmFmdCB0aGF0IGhhcyBiZWVuIHVwbG9hZGVkIGp1c3QgYSBm ZXcgbWludXRlcyBhZ28gY29udGFpbnMgdGhlIHVwZGF0ZXMgcmVmbGVjdGluZyB5b3VyIGNvbW1l bnRzLg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcmhkLW1wbHMt dHAtcHNjLXByaW9yaXR5LTAxLnR4dA0KDQpUaGUgZm9sbG93aW5ncyBhcmUgdGhlIHJlc29sdXRp b24gb2YgdGhlIGNvbW1lbnRzLCBhbmQgaW5jb3Jwb3JhdGVkIGluIHRoZSBuZXcgZHJhZnQ6DQpD b21tZW50IDE6IEFsbCB0aGUgTFNzIGhhdmUgYmVlbiByZW1vdmVkIGZyb20gdGhlIHJlZmVyZW5j ZXMsIGFuZCBhbnkgbmVjZXNzYXJ5IG1hdGVyaWFscyBoYXZlIGJlZW4gdHJhbnNmZXJyZWQgaW50 byB0aGUgZHJhZnQuDQpDb21tZW50IDI6IFRoZSBwYXJ0aWN1bGFyIGV4YW1wbGUgcmVsYXRlZCB0 byB0aGUgcHJpb3JpdHkgbGV2ZWwgb2YgQ2xlYXIgU0YgaXMgbW92ZWQgZnJvbSB0aGUgTFMgdG8g dGhlIGRyYWZ0LiBUaGUgbW90aXZhdGlvbiBvZiBGcmVlemUgaGFzIGJlZW4gZXhwbGFpbmVkIGlu IHRoZSBjb250ZXh0IG9mIHByaW9yaXR5IG1vZGlmaWNhdGlvbi4NCkNvbW1lbnQgMzogVGhpcyBj b21tZW50IHdhcyBub3QgZm9yIHRoZSBhdXRob3JzIG9mIHRoaXMgZHJhZnQuDQpDb21tZW50IDQ6 IEkgYW0gbm90IHN1cmUgaWYgeW91IGFyZSBhd2FyZSBvZiB0aGUgcmVzdWx0IG9mIGRpc2N1c3Np b25zIGluIHRoZSBsYXN0IElFVEYgbWVldGluZy4gVGhlcmUgd2FzIGEgZ2VuZXJhbCBhZ3JlZW1l bnQgb24gdGhlIG5lZWQgb2YgYSBuZXcgZHJhZnQgdG8gcHJvdmlkZSBhIG1ldGhvZCB0byBpbnRl Z3JhdGUgYWxsIHRoZSBkcmFmdHMgaW50byBQU0MgaW4gYSBiYWNrd2FyZCBjb21wYXRpYmxlIG1h bm5lciBhbmQgdG8gcHJvdmlkZSB0aGUgc3RhdGUgbWFjaGluZSBkZXNjcmlwdGlvbiB3aGVuIGFs bCB0aGUgZmVhdHVyZXMgYXJlIGVuYWJsZWQgdG8gc2F0aXNmeSB0aGUgSVRVLVQgdHJhbnNwb3J0 IHJlcXVpcmVtZW50cy4gVGhpcyBuZXcgZHJhZnQgaXMgbm93IGJlaW5nIHByZXBhcmVkLg0KDQpJ ZiB0aGVyZSBpcyBhbnkgbWlzdW5kZXJzdGFuZGluZyBvbiB5b3VyIGNvbW1lbnRzIG9yIGFueSBx dWVzdGlvbiBvbiB0aGUgdXBkYXRlcywgcGxlYXNlIGxldCBtZSBrbm93Lg0KDQpJIGFwcHJlY2lh dGUgeW91ciBoZWxwIGFuZCBzdXBwb3J0IG9uIHRoaXMgZHJhZnQuDQoNCkJlc3QgcmVnYXJkcywN Cg0KSmVvbmctZG9uZw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9t IDogIllhYWNvdiBXZWluZ2FydGVuIiA8d3lhYWNvdkBnbWFpbC5jb20+DQpTZW50IDogMjAxMy0w OC0xNiAwNDo0MDozNCAoICswOTowMCApDQpUbyA6IGxvYUBwaS5udSA8bG9hQHBpLm51PiwgbXBs c0BpZXRmLm9yZyA8bXBsc0BpZXRmLm9yZz4sIGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1wcmlvcml0 eUB0b29scy5pZXRmLm9yZyA8ZHJhZnQtcmhkLW1wbHMtdHAtcHNjLXByaW9yaXR5QHRvb2xzLmll dGYub3JnPiwgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcgPG1wbHMtY2hhaXJzQHRvb2xzLmll dGYub3JnPiwgbWFydGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2VudC5jb20gPG1hcnRpbi52aWdv dXJldXhAYWxjYXRlbC1sdWNlbnQuY29tPg0KQ2MgOg0KU3ViamVjdCA6IFttcGxzXSBNUExTLVJU IHJldmlldyBvZiBkcmFmdC1yaGQtbXBscy10cC1wc2MtcHJpb3JpdHkNCg0KSGksDQoNCkkgd2Fz IHJlcXVlc3RlZCB0byBjb25kdWN0IGFuIGluaXRpYWwgcmV2aWV3IG9mIGRyYWZ0LXJoZC1tcGxz LXRwLXBzYy1wcmlvcml0eS0wMSBhcyBwYXJ0IG9mIHRoZSBlZmZvcnQgdG8gZGV0ZXJtaW5lIGlm IHRoZSBkcmFmdCBpcyBzdWl0ZWQgZm9yIGEgV0cgYWRvcHRpb24gcG9sbC4gSSBoYXZlIHJlYWQg dGhlIGRyYWZ0IGFuZCBoYXZlIHRoZSBmb2xsb3dpbmcgbm90ZXM6DQoNCjEuIEkgZmluZCBpdCBy YXRoZXIgZGlzY29uY2VydGluZyB0aGF0IHRoZSBkcmFmdCBpcyByZWZlcmVuY2luZyBhIExTIHRo YXQgd2FzIHJlY2VpdmVkIGZyb20gdGhlIElUVS4gV2hpbGUgSSBhbSBzdXJlIHRoYXQgdGhlIHBv aW50cyByYXNpZWQgaW4gdGhlIExTIGFzIHZlcnkgd2VsbCB0aG91Z2h0IG91dCBhbmQgcGVydGlu ZW50LCBJIGNhbm5vdCBzZWUgdGhhdCB0aGUgTFMgc2hvdWxkIGJlIGNvbnNpZGVyZWQgYSAic3Rh bmRhcmRzIGRvY3VtZW50IiB0aGF0IGNvdWxkIGJlIHJlZmVyZW5jZWQgYnkgYSBmdXR1cmUgUkZD LiBBdCBiZXN0LCB0aGUgTFMgY291bGQgYmUgY29uc2lkZXJlZCBhICJjb250cmlidXRpb24iIGF0 IGFuIElUVSBtZWV0aW5nLCBhbmQgSSBkbyBub3QgYmVsaWV2ZSB0aGF0IGFuIElUVSBkb2N1bWVu dCB3b3VsZCByZWZlcmVuY2UgYSBjb250cmlidXRpb24hIEkgdGhlcmVmb3JlIHRoaW5rIHRoYXQg dGhlIGF1dGhvcnMgc2hvdWxkIHRyYW5zZmVyIGludG8gdGhlIGRyYWZ0IHdoYXRldmVyIGluZm9y bWF0aW9uIHRoZXkgZmVlbCBpcyBhcHByb3ByaWF0ZSBmcm9tIHNhaWQgTFMuDQoNCjIuIEluIGdl bmVyYWwsIHRoZSBkcmFmdCBpcyBhZGRyZXNzaW5nIGl0c2VsZiB0byB0d28gdG9waWNzIHJlZ2Fy ZGluZyBSRkM2Mzc4LA0KYS4gQ2hhbmdlIG9mIHJlbGF0aXZlIHByaW9yaXR5IGJldHdlZW4gU0Yt UCBhbmQgRlMgLSB0aGUgc3VnZ2VzdGlvbiBpcyBlc3NlbnRpYWxseSB0byByb2xsYmFjayB0aGUg cmVsZXZhbnQgY2hhbmdlcyB0aGF0IHdlcmUgbWFkZSB0byB0aGUgUkZDIGR1cmluZyB0aGUgZmlu YWwgSUVTRyByZXZpZXcgdG8gdGhlIHZlcnNpb24gcHJldmlvdXMgdG8gdGhhdCByZXZpZXcuDQoN CmIuIENoYW5nZSBvZiByZWxhdGl2ZSBwcmlvcml0eSBiZXR3ZWVuIENsZWFyU0YgYW5kIFNGL1NE LiBUaGlzIGlzIGJhc2VkIG9uIGEgcGFydGljdWxhciB1c2UtY2FzZSB0aGF0IGlzIG1lbnRpb25l ZCBpbiB0aGUgcmVmZXJlbmNlZCBMUywgYW5kIHRoYXQgSSBzdWdnZXN0ZWQgYmUgZXhwbGljaXRs eSBleHBsYWluZWQgaW4gdGhlIGRyYWZ0Lg0KDQpjLiBJbnRyb2R1Y2UgKGluIGFuIGFwcGVuZGl4 KSB0aGUgdXNlIG9mIGEgRnJlZXplIGNvbW1hbmQuIE5vdCBzdXJlIHdoYXQgdGhlIG1vdGl2YXRp b24gZm9yIHRoaXMgaW4gdGhpcyBjb250ZXh0IGlzLg0KDQpJbiBteSBvcGluaW9uLCBhbGwgdGhy ZWUgb2YgdGhlIHBvaW50cyBhcmUgdmFsaWQgZm9yIHdvcmsgYnkgdGhlIFdHIGFuZCBzaG91bGQg YmUgZnVsbHkgZGlzY3Vzc2VkIGluIHRoZSBXRyBwcmlvciB0byBwdWJsaWNhdGlvbiBvZiB0aGUg ZHJhZnQgLSBidXQgY291bGQgYmUgZGlzY3Vzc2VkIGFzIHBhcnQgb2YgYSBXRyBkcmFmdC4NCg0K My4gVGhlIGZvcm1hdCBvZiB0aGUgZHJhZnQgaXMgYWxzbyByYXRoZXIgaW50ZXJlc3RpbmcgLSBp dCBzZWVtcyB0byBiZSBwcmVzZW50aW5nIGFuIGVycmF0YSBub3RlIHRvIFJGQzYzNzggcmF0aGVy IHRoYW4gZGVzY3JpYmluZyB0aGUgZGVzaXJlZCBiZWhhdmlvci4gSSBsZWF2ZSBpdCB0byB0aGUg V0cgQ2hhaXJzIHRvIGRlY2lkZSB3aGF0IGlzIHRoZSBiZXN0IGZvcm1hdCBmb3IgdGhlIGRyYWZ0 IG1vdmluZyBmb3J3YXJkLg0KDQo0LiBPbmUgb3RoZXIgbm90ZSByZWdhcmRpbmcgdGhpcyBkcmFm dCBpbiB0aGUgY29udGV4dCBvZiBzZXZlcmFsIG90aGVyIGRyYWZ0cyB0aGF0IGFyZSBwcm9wb3Np bmcgY2hhbmdlcyB0byB0aGUgUFNDIHByb3RvY29sIGZvciBNUExTLVRQIExpbmVhciBQcm90ZWN0 aW9uLiBJIHRoaW5rIHRoYXQgc29tZSBvZiB0aGVzZSBzaG91bGQgYmUgY29tYmluZWQgaW50byBh IG1vcmUgcm9idXN0IHByb3Bvc2FsIGZvciB0aGUgc2FrZSBvZiB0aGUgaW1wbGVtZW50ZXJzLiBP dGhlcndpc2UsIHRoZXJlIG1heSBiZSBhIG5lZWQgZm9yIGEgZnV0dXJlICJyZWFkZXIncyBndWlk ZSIgZm9yIGFuIGltcGxlbWVudGVyIHRvIGZpZ3VyZSBvdXQgd2hhdCBpcyBpbiBQU0MgYW5kIHdo YXQgaXMgbm8gbG9uZ2VyIHRoZXJlIQ0KDQpCb3R0b20gbGluZSAtIEkgdGhpbmsgdGhhdCB0aGlz IGRyYWZ0IHByZXNlbnRzIHZhbGlkIHBvaW50cywgaXQgc2hvdWxkIGJlIGNvcnJlY3RlZCB0byBu b3QgcmVmZXJlbmNlIHRoZSBJVFUgTFMgcHJpb3IgdG8gYWNjZXB0YW5jZSBhcyBhIFdHIGRyYWZ0 LiBBbmQgdGhlIFdHIHNob3VsZCBzdHJvbmdseSBjb25zaWRlciBjb25zb2xpZGF0aW5nIHRoaXMg d29yayB3aXRoIHNvbWUgb2YgdGhlIG90aGVyIGRyYWZ0cyB0byBtYWtlIGEgbW9yZSBjb21wbGV0 ZSBhbmQgY29uc2lzdGVudCBkZWZpbml0aW9uIG9mIFBTQyBhdmFpbGFibGUuDQoNCkhvcGUgdGhp cyBoZWxwcywNCg0KLS0NClRoYW54IGFuZCBCUiwNCnlhYWNvdg0KDQpTdGlsbCBsb29raW5nIGZv ciBuZXcgb3Bwb3J0dW5pdHkNCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A2866A35ESMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTog6rW066a8OyBGT05ULVNJWkU6IDEwcHQiIGlkPSJlekZvcm1Qcm9jX2RpdiI+ DQo8ZGl2IGlkPSJtc2dib2R5Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCI+PGJyPg0KPHAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+WWFhY292LCB0 aGFuayB5b3UgZm9yIHByb3ZpZGluZyB0aGUgY29tbWVudHMuPC9mb250Pjwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwv cD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPkkgZGlzY3Vzc2VkIHlv dXIgY29tbWVudHMgd2l0aCB0aGUgb3RoZXIgY28tYXV0aG9ycyBvZiB0aGlzIGRyYWZ0LCBhbmQg dGhlIHJldmlzZWQgZHJhZnQgdGhhdCBoYXMgYmVlbiB1cGxvYWRlZCBqdXN0IGEgZmV3IG1pbnV0 ZXMgYWdvIGNvbnRhaW5zIHRoZSB1cGRhdGVzIHJlZmxlY3RpbmcgeW91cg0KIGNvbW1lbnRzLiA8 L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcmhkLW1w bHMtdHAtcHNjLXByaW9yaXR5LTAxLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPjxmb250IGNvbG9yPSIj MDAwMGZmIiBmYWNlPSLrp5HsnYAg6rOg65SVIj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1yaGQtbXBscy10cC1wc2MtcHJpb3JpdHktMDEudHh0PC9mb250PjwvYT48 L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5U aGUgZm9sbG93aW5ncyBhcmUgdGhlIHJlc29sdXRpb24gb2YgdGhlIGNvbW1lbnRzLCBhbmQmbmJz cDtpbmNvcnBvcmF0ZWQgaW4gdGhlIG5ldyBkcmFmdDo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0 eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPkNvbW1lbnQgMTogQWxsIHRoZSBMU3Mg aGF2ZSBiZWVuIHJlbW92ZWQgZnJvbSB0aGUgcmVmZXJlbmNlcywgYW5kIGFueSBuZWNlc3Nhcnkg bWF0ZXJpYWxzIGhhdmUgYmVlbiB0cmFuc2ZlcnJlZCBpbnRvIHRoZSBkcmFmdC4NCjwvZm9udD48 L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+Q29tbWVu dCAyOiBUaGUgcGFydGljdWxhciBleGFtcGxlIHJlbGF0ZWQgdG8gdGhlIHByaW9yaXR5IGxldmVs IG9mIENsZWFyIFNGIGlzIG1vdmVkIGZyb20gdGhlIExTIHRvIHRoZSBkcmFmdC4gVGhlIG1vdGl2 YXRpb24gb2YgRnJlZXplIGhhcyBiZWVuIGV4cGxhaW5lZCBpbiB0aGUgY29udGV4dA0KIG9mIHBy aW9yaXR5IG1vZGlmaWNhdGlvbi48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU46 IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250 IGZhY2U9IuunkeydgCDqs6DrlJUiPkNvbW1lbnQgMzogVGhpcyBjb21tZW50IHdhcyBub3QgZm9y IHRoZSBhdXRob3JzIG9mIHRoaXMgZHJhZnQuDQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxl PSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPkNvbW1lbnQgNDogSSBhbSBub3Qgc3VyZSBp ZiB5b3UgYXJlIGF3YXJlIG9mIHRoZSByZXN1bHQgb2YgZGlzY3Vzc2lvbnMgaW4gdGhlIGxhc3Qg SUVURiBtZWV0aW5nLiBUaGVyZSB3YXMgYSBnZW5lcmFsIGFncmVlbWVudCBvbiB0aGUgbmVlZCBv ZiBhIG5ldyBkcmFmdCB0byBwcm92aWRlIGEgbWV0aG9kDQogdG8gaW50ZWdyYXRlIGFsbCB0aGUg ZHJhZnRzIGludG8gUFNDIGluIGEgYmFja3dhcmQgY29tcGF0aWJsZSBtYW5uZXIgYW5kIHRvIHBy b3ZpZGUgdGhlIHN0YXRlIG1hY2hpbmUgZGVzY3JpcHRpb24gd2hlbiBhbGwgdGhlIGZlYXR1cmVz IGFyZSBlbmFibGVkIHRvIHNhdGlzZnkgdGhlIElUVS1UIHRyYW5zcG9ydCByZXF1aXJlbWVudHMu IFRoaXMgbmV3IGRyYWZ0IGlzIG5vdyBiZWluZyBwcmVwYXJlZC4NCjwvZm9udD48L3NwYW4+PC9w Pg0KPHAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+PC9mb250Pjwvc3Bhbj4m bmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5JZiB0aGVy ZSBpcyBhbnkgbWlzdW5kZXJzdGFuZGluZyBvbiB5b3VyIGNvbW1lbnRzIG9yIGFueSBxdWVzdGlv biBvbiB0aGUgdXBkYXRlcywgcGxlYXNlIGxldCBtZSBrbm93LjwvZm9udD48L3NwYW4+PC9wPg0K PHAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5JIGFwcHJlY2lhdGUg eW91ciBoZWxwIGFuZCBzdXBwb3J0IG9uIHRoaXMgZHJhZnQuPC9mb250Pjwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwv cD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPkJlc3QgcmVnYXJkcyw8 L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0IiBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqz oOuUlSI+SmVvbmctZG9uZzwvZm9udD48L3NwYW4+PC9wPg0KPGJyPg0KPGRpdiBpZD0iTWFpbFNp Z25TZW50Ij48YnI+DQo8L2Rpdj4NCjxociB0YWJpbmRleD0iLTEiPg0KPGI+RnJvbSA6IDwvYj4m cXVvdDtZYWFjb3YgV2VpbmdhcnRlbiZxdW90OyAmbHQ7d3lhYWNvdkBnbWFpbC5jb20mZ3Q7PGJy Pg0KPGI+U2VudCA6IDwvYj4yMDEzLTA4LTE2IDA0OjQwOjM0ICggJiM0MzswOTowMCApPGJyPg0K PGI+VG8gOiA8L2I+bG9hQHBpLm51ICZsdDtsb2FAcGkubnUmZ3Q7LCBtcGxzQGlldGYub3JnICZs dDttcGxzQGlldGYub3JnJmd0OywgZHJhZnQtcmhkLW1wbHMtdHAtcHNjLXByaW9yaXR5QHRvb2xz LmlldGYub3JnICZsdDtkcmFmdC1yaGQtbXBscy10cC1wc2MtcHJpb3JpdHlAdG9vbHMuaWV0Zi5v cmcmZ3Q7LCBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyAmbHQ7bXBscy1jaGFpcnNAdG9vbHMu aWV0Zi5vcmcmZ3Q7LCBtYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwtbHVjZW50LmNvbSAmbHQ7bWFy dGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2VudC5jb20mZ3Q7PGJyPg0KPGI+Q2MgOiA8L2I+PGJy Pg0KPGI+U3ViamVjdCA6IDwvYj5bbXBsc10gTVBMUy1SVCByZXZpZXcgb2YgZHJhZnQtcmhkLW1w bHMtdHAtcHNjLXByaW9yaXR5PGJyPg0KPGJyPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2PkhpLDwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SSB3YXMgcmVxdWVzdGVkIHRvIGNvbmR1Y3Qg YW4gaW5pdGlhbCByZXZpZXcgb2YgZHJhZnQtcmhkLW1wbHMtdHAtcHNjLXByaW9yaXR5LTAxIGFz IHBhcnQgb2YgdGhlIGVmZm9ydCB0byBkZXRlcm1pbmUgaWYgdGhlIGRyYWZ0IGlzIHN1aXRlZCBm b3IgYSBXRyBhZG9wdGlvbiBwb2xsLiBJIGhhdmUgcmVhZCB0aGUgZHJhZnQgYW5kIGhhdmUgdGhl IGZvbGxvd2luZyBub3Rlczo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PjEuIEkgZmlu ZCBpdCByYXRoZXIgZGlzY29uY2VydGluZyB0aGF0IHRoZSBkcmFmdCBpcyByZWZlcmVuY2luZyBh IExTIHRoYXQgd2FzIHJlY2VpdmVkIGZyb20gdGhlIElUVS4gV2hpbGUgSSBhbSBzdXJlIHRoYXQg dGhlIHBvaW50cyByYXNpZWQgaW4gdGhlIExTIGFzIHZlcnkgd2VsbCB0aG91Z2h0IG91dCBhbmQg cGVydGluZW50LCBJIGNhbm5vdCBzZWUgdGhhdCB0aGUgTFMgc2hvdWxkIGJlIGNvbnNpZGVyZWQg YSAmcXVvdDtzdGFuZGFyZHMgZG9jdW1lbnQmcXVvdDsNCiB0aGF0IGNvdWxkIGJlIHJlZmVyZW5j ZWQgYnkgYSBmdXR1cmUgUkZDLiBBdCBiZXN0LCB0aGUgTFMgY291bGQgYmUgY29uc2lkZXJlZCBh ICZxdW90O2NvbnRyaWJ1dGlvbiZxdW90OyBhdCBhbiBJVFUgbWVldGluZywgYW5kIEkgZG8gbm90 IGJlbGlldmUgdGhhdCBhbiBJVFUgZG9jdW1lbnQgd291bGQgcmVmZXJlbmNlIGEgY29udHJpYnV0 aW9uISBJIHRoZXJlZm9yZSB0aGluayB0aGF0IHRoZSBhdXRob3JzIHNob3VsZCB0cmFuc2ZlciBp bnRvIHRoZSBkcmFmdCB3aGF0ZXZlcg0KIGluZm9ybWF0aW9uIHRoZXkgZmVlbCBpcyBhcHByb3By aWF0ZSBmcm9tIHNhaWQgTFMuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4yLiBJbiBn ZW5lcmFsLCB0aGUgZHJhZnQgaXMgYWRkcmVzc2luZyBpdHNlbGYgdG8gdHdvIHRvcGljcyByZWdh cmRpbmcgUkZDNjM3OCwNCjwvZGl2Pg0KPGRpdj5hLiBDaGFuZ2Ugb2YgcmVsYXRpdmUgcHJpb3Jp dHkgYmV0d2VlbiBTRi1QIGFuZCBGUyAtIHRoZSBzdWdnZXN0aW9uIGlzIGVzc2VudGlhbGx5IHRv IHJvbGxiYWNrIHRoZSByZWxldmFudCBjaGFuZ2VzIHRoYXQgd2VyZSBtYWRlIHRvIHRoZSBSRkMg ZHVyaW5nIHRoZSBmaW5hbCBJRVNHIHJldmlldyB0byB0aGUgdmVyc2lvbiBwcmV2aW91cyB0byB0 aGF0IHJldmlldy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PmIuIENoYW5nZSBvZiBy ZWxhdGl2ZSBwcmlvcml0eSBiZXR3ZWVuIENsZWFyU0YgYW5kIFNGL1NELiBUaGlzIGlzIGJhc2Vk IG9uIGEgcGFydGljdWxhciB1c2UtY2FzZSB0aGF0IGlzIG1lbnRpb25lZCBpbiB0aGUgcmVmZXJl bmNlZCBMUywgYW5kIHRoYXQgSSBzdWdnZXN0ZWQgYmUgZXhwbGljaXRseSBleHBsYWluZWQgaW4g dGhlIGRyYWZ0LjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Yy4gSW50cm9kdWNlIChp biBhbiBhcHBlbmRpeCkgdGhlIHVzZSBvZiBhIEZyZWV6ZSBjb21tYW5kLiBOb3Qgc3VyZSB3aGF0 IHRoZSBtb3RpdmF0aW9uIGZvciB0aGlzIGluIHRoaXMgY29udGV4dCBpcy48L2Rpdj4NCjxkaXY+ Jm5ic3A7PC9kaXY+DQo8ZGl2PkluIG15IG9waW5pb24sIGFsbCB0aHJlZSBvZiB0aGUgcG9pbnRz IGFyZSB2YWxpZCBmb3Igd29yayBieSB0aGUgV0cgYW5kIHNob3VsZCBiZSBmdWxseSBkaXNjdXNz ZWQgaW4gdGhlIFdHIHByaW9yIHRvIHB1YmxpY2F0aW9uIG9mIHRoZSBkcmFmdCAtIGJ1dCBjb3Vs ZCBiZSBkaXNjdXNzZWQgYXMgcGFydCBvZiBhIFdHIGRyYWZ0LjwvZGl2Pg0KPGRpdj4mbmJzcDs8 L2Rpdj4NCjxkaXY+My4gVGhlIGZvcm1hdCBvZiB0aGUgZHJhZnQgaXMgYWxzbyByYXRoZXIgaW50 ZXJlc3RpbmcgLSBpdCBzZWVtcyB0byBiZSBwcmVzZW50aW5nIGFuIGVycmF0YSBub3RlIHRvIFJG QzYzNzggcmF0aGVyIHRoYW4gZGVzY3JpYmluZyB0aGUgZGVzaXJlZCBiZWhhdmlvci4gSSBsZWF2 ZSBpdCB0byB0aGUgV0cgQ2hhaXJzIHRvIGRlY2lkZSB3aGF0IGlzIHRoZSBiZXN0IGZvcm1hdCBm b3IgdGhlIGRyYWZ0IG1vdmluZyBmb3J3YXJkLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxk aXY+NC4gT25lIG90aGVyIG5vdGUgcmVnYXJkaW5nIHRoaXMgZHJhZnQgaW4gdGhlIGNvbnRleHQg b2Ygc2V2ZXJhbCBvdGhlciBkcmFmdHMgdGhhdCBhcmUgcHJvcG9zaW5nIGNoYW5nZXMgdG8gdGhl IFBTQyBwcm90b2NvbCBmb3IgTVBMUy1UUCBMaW5lYXIgUHJvdGVjdGlvbi4gSSB0aGluayB0aGF0 IHNvbWUgb2YgdGhlc2Ugc2hvdWxkIGJlIGNvbWJpbmVkIGludG8gYSBtb3JlIHJvYnVzdCBwcm9w b3NhbCBmb3IgdGhlIHNha2Ugb2YgdGhlIGltcGxlbWVudGVycy4NCiBPdGhlcndpc2UsIHRoZXJl IG1heSBiZSBhIG5lZWQgZm9yIGEgZnV0dXJlICZxdW90O3JlYWRlcidzIGd1aWRlJnF1b3Q7IGZv ciBhbiBpbXBsZW1lbnRlciB0byBmaWd1cmUgb3V0IHdoYXQgaXMgaW4gUFNDIGFuZCB3aGF0IGlz IG5vIGxvbmdlciB0aGVyZSE8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkJvdHRvbSBs aW5lIC0gSSB0aGluayB0aGF0IHRoaXMgZHJhZnQgcHJlc2VudHMgdmFsaWQgcG9pbnRzLCBpdCBz aG91bGQgYmUgY29ycmVjdGVkIHRvIG5vdCByZWZlcmVuY2UgdGhlIElUVSBMUyBwcmlvciB0byBh Y2NlcHRhbmNlIGFzIGEgV0cgZHJhZnQuIEFuZCB0aGUgV0cgc2hvdWxkIHN0cm9uZ2x5IGNvbnNp ZGVyIGNvbnNvbGlkYXRpbmcgdGhpcyB3b3JrIHdpdGggc29tZSBvZiB0aGUgb3RoZXIgZHJhZnRz IHRvIG1ha2UgYSBtb3JlDQogY29tcGxldGUgYW5kIGNvbnNpc3RlbnQgZGVmaW5pdGlvbiBvZiBQ U0MgYXZhaWxhYmxlLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SG9wZSB0aGlzIGhl bHBzLDxiciBjbGVhcj0iYWxsIj4NCjxicj4NCi0tIDxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0 ciI+VGhhbnggYW5kIEJSLA0KPGRpdj55YWFjb3Y8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PjxpPlN0aWxsIGxvb2tpbmcgZm9yIG5ldyBvcHBvcnR1bml0eTwvaT48L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A2866A35ESMTP2etriinfo_-- From ryoo@etri.re.kr Wed Aug 21 02:53:19 2013 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 C05CA11E81C4 for ; Wed, 21 Aug 2013 02:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.633 X-Spam-Level: X-Spam-Status: No, score=-101.633 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfEjHUXZEo9E for ; Wed, 21 Aug 2013 02:53:14 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0627111E81BA for ; Wed, 21 Aug 2013 02:53:14 -0700 (PDT) Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 21 Aug 2013 18:53:06 +0900 Received: from SMTP2.etri.info ([169.254.2.105]) by SMTP1.etri.info ([129.254.28.71]) with mapi id 14.01.0355.002; Wed, 21 Aug 2013 18:53:04 +0900 From: "Ryoo, Jeong-dong" To: Yaacov Weingarten , "loa@pi.nu" , "mpls@ietf.org" , "draft-rhd-mpls-tp-psc-priority@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "martin.vigoureux@alcatel-lucent.com" Thread-Topic: [mpls] MPLS-RT review of draft-rhd-mpls-tp-psc-priority Thread-Index: AQHOme9PtFLu03g9EE2vW/csAUwXqZmfY/fYgAAPPQU= Date: Wed, 21 Aug 2013 09:53:03 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A2866B3AA@SMTP2.etri.info> References: , <5B4A6CBE3924BB41A3BEE462A8E0B75A2866A35E@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A2866A35E@SMTP2.etri.info> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A2866B3AASMTP2etriinfo_" MIME-Version: 1.0 Subject: Re: [mpls] MPLS-RT review of draft-rhd-mpls-tp-psc-priority 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, 21 Aug 2013 09:53:19 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A2866B3AASMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9hLA0KDQpBZnRlciB1cGxvYWRpbmcgYSBuZXcgdmVyc2lvbiwgSSByZWFsaXplZCB0aGF0IEkg d2FzIG5vdCBzdXBwb3NlZCB0byB1cGRhdGUgdGhlIGRvY3VtZW50IGR1cmluZyB0aGUgTVBMUy1S VCByZXZpZXcgcGVyaW9kLg0KU2luY2UgdGhpcyBwYXJ0aWN1bGFyIGRyYWZ0IHdhcyBzdXBwb3Nl ZCB0byBleHBpcmUgdG9tb3Jyb3csIEkgbmVlZGVkIHRvIHVwbG9hZCBhIG5ldyB2ZXJzaW9uIGFu ZCBqdXN0IGhhcHBlbmQgdG8gaW5jb3Jwb3JhdGUgdGhlIGNvbW1lbnRzIGZyb20gWWFhY292LiBT b3JyeSBhYm91dCB0aGlzLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkplb25nLWRvbmcNCg0KDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb20gOiAiUnlvbywgSmVvbmctZG9u ZyIgPHJ5b29AZXRyaS5yZS5rcj4NClNlbnQgOiAyMDEzLTA4LTIxIDE4OjAxOjAzICggKzA5OjAw ICkNClRvIDogWWFhY292IFdlaW5nYXJ0ZW4gPHd5YWFjb3ZAZ21haWwuY29tPiwgbG9hQHBpLm51 IDxsb2FAcGkubnU+LCBtcGxzQGlldGYub3JnIDxtcGxzQGlldGYub3JnPiwgZHJhZnQtcmhkLW1w bHMtdHAtcHNjLXByaW9yaXR5QHRvb2xzLmlldGYub3JnIDxkcmFmdC1yaGQtbXBscy10cC1wc2Mt cHJpb3JpdHlAdG9vbHMuaWV0Zi5vcmc+LCBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyA8bXBs cy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+LCBtYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwtbHVjZW50 LmNvbSA8bWFydGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2VudC5jb20+DQpDYyA6DQpTdWJqZWN0 IDog7ZqM7IugOiBbbXBsc10gTVBMUy1SVCByZXZpZXcgb2YgZHJhZnQtcmhkLW1wbHMtdHAtcHNj LXByaW9yaXR5DQoNCg0KWWFhY292LCB0aGFuayB5b3UgZm9yIHByb3ZpZGluZyB0aGUgY29tbWVu dHMuDQoNCkkgZGlzY3Vzc2VkIHlvdXIgY29tbWVudHMgd2l0aCB0aGUgb3RoZXIgY28tYXV0aG9y cyBvZiB0aGlzIGRyYWZ0LCBhbmQgdGhlIHJldmlzZWQgZHJhZnQgdGhhdCBoYXMgYmVlbiB1cGxv YWRlZCBqdXN0IGEgZmV3IG1pbnV0ZXMgYWdvIGNvbnRhaW5zIHRoZSB1cGRhdGVzIHJlZmxlY3Rp bmcgeW91ciBjb21tZW50cy4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LXJoZC1tcGxzLXRwLXBzYy1wcmlvcml0eS0wMS50eHQNCg0KVGhlIGZvbGxvd2luZ3MgYXJl IHRoZSByZXNvbHV0aW9uIG9mIHRoZSBjb21tZW50cywgYW5kIGluY29ycG9yYXRlZCBpbiB0aGUg bmV3IGRyYWZ0Og0KQ29tbWVudCAxOiBBbGwgdGhlIExTcyBoYXZlIGJlZW4gcmVtb3ZlZCBmcm9t IHRoZSByZWZlcmVuY2VzLCBhbmQgYW55IG5lY2Vzc2FyeSBtYXRlcmlhbHMgaGF2ZSBiZWVuIHRy YW5zZmVycmVkIGludG8gdGhlIGRyYWZ0Lg0KQ29tbWVudCAyOiBUaGUgcGFydGljdWxhciBleGFt cGxlIHJlbGF0ZWQgdG8gdGhlIHByaW9yaXR5IGxldmVsIG9mIENsZWFyIFNGIGlzIG1vdmVkIGZy b20gdGhlIExTIHRvIHRoZSBkcmFmdC4gVGhlIG1vdGl2YXRpb24gb2YgRnJlZXplIGhhcyBiZWVu IGV4cGxhaW5lZCBpbiB0aGUgY29udGV4dCBvZiBwcmlvcml0eSBtb2RpZmljYXRpb24uDQpDb21t ZW50IDM6IFRoaXMgY29tbWVudCB3YXMgbm90IGZvciB0aGUgYXV0aG9ycyBvZiB0aGlzIGRyYWZ0 Lg0KQ29tbWVudCA0OiBJIGFtIG5vdCBzdXJlIGlmIHlvdSBhcmUgYXdhcmUgb2YgdGhlIHJlc3Vs dCBvZiBkaXNjdXNzaW9ucyBpbiB0aGUgbGFzdCBJRVRGIG1lZXRpbmcuIFRoZXJlIHdhcyBhIGdl bmVyYWwgYWdyZWVtZW50IG9uIHRoZSBuZWVkIG9mIGEgbmV3IGRyYWZ0IHRvIHByb3ZpZGUgYSBt ZXRob2QgdG8gaW50ZWdyYXRlIGFsbCB0aGUgZHJhZnRzIGludG8gUFNDIGluIGEgYmFja3dhcmQg Y29tcGF0aWJsZSBtYW5uZXIgYW5kIHRvIHByb3ZpZGUgdGhlIHN0YXRlIG1hY2hpbmUgZGVzY3Jp cHRpb24gd2hlbiBhbGwgdGhlIGZlYXR1cmVzIGFyZSBlbmFibGVkIHRvIHNhdGlzZnkgdGhlIElU VS1UIHRyYW5zcG9ydCByZXF1aXJlbWVudHMuIFRoaXMgbmV3IGRyYWZ0IGlzIG5vdyBiZWluZyBw cmVwYXJlZC4NCg0KSWYgdGhlcmUgaXMgYW55IG1pc3VuZGVyc3RhbmRpbmcgb24geW91ciBjb21t ZW50cyBvciBhbnkgcXVlc3Rpb24gb24gdGhlIHVwZGF0ZXMsIHBsZWFzZSBsZXQgbWUga25vdy4N Cg0KSSBhcHByZWNpYXRlIHlvdXIgaGVscCBhbmQgc3VwcG9ydCBvbiB0aGlzIGRyYWZ0Lg0KDQpC ZXN0IHJlZ2FyZHMsDQoNCkplb25nLWRvbmcNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KRnJvbSA6ICJZYWFjb3YgV2VpbmdhcnRlbiIgPHd5YWFjb3ZAZ21haWwuY29tPg0K U2VudCA6IDIwMTMtMDgtMTYgMDQ6NDA6MzQgKCArMDk6MDAgKQ0KVG8gOiBsb2FAcGkubnUgPGxv YUBwaS5udT4sIG1wbHNAaWV0Zi5vcmcgPG1wbHNAaWV0Zi5vcmc+LCBkcmFmdC1yaGQtbXBscy10 cC1wc2MtcHJpb3JpdHlAdG9vbHMuaWV0Zi5vcmcgPGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1wcmlv cml0eUB0b29scy5pZXRmLm9yZz4sIG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIDxtcGxzLWNo YWlyc0B0b29scy5pZXRmLm9yZz4sIG1hcnRpbi52aWdvdXJldXhAYWxjYXRlbC1sdWNlbnQuY29t IDxtYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwtbHVjZW50LmNvbT4NCkNjIDoNClN1YmplY3QgOiBb bXBsc10gTVBMUy1SVCByZXZpZXcgb2YgZHJhZnQtcmhkLW1wbHMtdHAtcHNjLXByaW9yaXR5DQoN CkhpLA0KDQpJIHdhcyByZXF1ZXN0ZWQgdG8gY29uZHVjdCBhbiBpbml0aWFsIHJldmlldyBvZiBk cmFmdC1yaGQtbXBscy10cC1wc2MtcHJpb3JpdHktMDEgYXMgcGFydCBvZiB0aGUgZWZmb3J0IHRv IGRldGVybWluZSBpZiB0aGUgZHJhZnQgaXMgc3VpdGVkIGZvciBhIFdHIGFkb3B0aW9uIHBvbGwu IEkgaGF2ZSByZWFkIHRoZSBkcmFmdCBhbmQgaGF2ZSB0aGUgZm9sbG93aW5nIG5vdGVzOg0KDQox LiBJIGZpbmQgaXQgcmF0aGVyIGRpc2NvbmNlcnRpbmcgdGhhdCB0aGUgZHJhZnQgaXMgcmVmZXJl bmNpbmcgYSBMUyB0aGF0IHdhcyByZWNlaXZlZCBmcm9tIHRoZSBJVFUuIFdoaWxlIEkgYW0gc3Vy ZSB0aGF0IHRoZSBwb2ludHMgcmFzaWVkIGluIHRoZSBMUyBhcyB2ZXJ5IHdlbGwgdGhvdWdodCBv dXQgYW5kIHBlcnRpbmVudCwgSSBjYW5ub3Qgc2VlIHRoYXQgdGhlIExTIHNob3VsZCBiZSBjb25z aWRlcmVkIGEgInN0YW5kYXJkcyBkb2N1bWVudCIgdGhhdCBjb3VsZCBiZSByZWZlcmVuY2VkIGJ5 IGEgZnV0dXJlIFJGQy4gQXQgYmVzdCwgdGhlIExTIGNvdWxkIGJlIGNvbnNpZGVyZWQgYSAiY29u dHJpYnV0aW9uIiBhdCBhbiBJVFUgbWVldGluZywgYW5kIEkgZG8gbm90IGJlbGlldmUgdGhhdCBh biBJVFUgZG9jdW1lbnQgd291bGQgcmVmZXJlbmNlIGEgY29udHJpYnV0aW9uISBJIHRoZXJlZm9y ZSB0aGluayB0aGF0IHRoZSBhdXRob3JzIHNob3VsZCB0cmFuc2ZlciBpbnRvIHRoZSBkcmFmdCB3 aGF0ZXZlciBpbmZvcm1hdGlvbiB0aGV5IGZlZWwgaXMgYXBwcm9wcmlhdGUgZnJvbSBzYWlkIExT Lg0KDQoyLiBJbiBnZW5lcmFsLCB0aGUgZHJhZnQgaXMgYWRkcmVzc2luZyBpdHNlbGYgdG8gdHdv IHRvcGljcyByZWdhcmRpbmcgUkZDNjM3OCwNCmEuIENoYW5nZSBvZiByZWxhdGl2ZSBwcmlvcml0 eSBiZXR3ZWVuIFNGLVAgYW5kIEZTIC0gdGhlIHN1Z2dlc3Rpb24gaXMgZXNzZW50aWFsbHkgdG8g cm9sbGJhY2sgdGhlIHJlbGV2YW50IGNoYW5nZXMgdGhhdCB3ZXJlIG1hZGUgdG8gdGhlIFJGQyBk dXJpbmcgdGhlIGZpbmFsIElFU0cgcmV2aWV3IHRvIHRoZSB2ZXJzaW9uIHByZXZpb3VzIHRvIHRo YXQgcmV2aWV3Lg0KDQpiLiBDaGFuZ2Ugb2YgcmVsYXRpdmUgcHJpb3JpdHkgYmV0d2VlbiBDbGVh clNGIGFuZCBTRi9TRC4gVGhpcyBpcyBiYXNlZCBvbiBhIHBhcnRpY3VsYXIgdXNlLWNhc2UgdGhh dCBpcyBtZW50aW9uZWQgaW4gdGhlIHJlZmVyZW5jZWQgTFMsIGFuZCB0aGF0IEkgc3VnZ2VzdGVk IGJlIGV4cGxpY2l0bHkgZXhwbGFpbmVkIGluIHRoZSBkcmFmdC4NCg0KYy4gSW50cm9kdWNlIChp biBhbiBhcHBlbmRpeCkgdGhlIHVzZSBvZiBhIEZyZWV6ZSBjb21tYW5kLiBOb3Qgc3VyZSB3aGF0 IHRoZSBtb3RpdmF0aW9uIGZvciB0aGlzIGluIHRoaXMgY29udGV4dCBpcy4NCg0KSW4gbXkgb3Bp bmlvbiwgYWxsIHRocmVlIG9mIHRoZSBwb2ludHMgYXJlIHZhbGlkIGZvciB3b3JrIGJ5IHRoZSBX RyBhbmQgc2hvdWxkIGJlIGZ1bGx5IGRpc2N1c3NlZCBpbiB0aGUgV0cgcHJpb3IgdG8gcHVibGlj YXRpb24gb2YgdGhlIGRyYWZ0IC0gYnV0IGNvdWxkIGJlIGRpc2N1c3NlZCBhcyBwYXJ0IG9mIGEg V0cgZHJhZnQuDQoNCjMuIFRoZSBmb3JtYXQgb2YgdGhlIGRyYWZ0IGlzIGFsc28gcmF0aGVyIGlu dGVyZXN0aW5nIC0gaXQgc2VlbXMgdG8gYmUgcHJlc2VudGluZyBhbiBlcnJhdGEgbm90ZSB0byBS RkM2Mzc4IHJhdGhlciB0aGFuIGRlc2NyaWJpbmcgdGhlIGRlc2lyZWQgYmVoYXZpb3IuIEkgbGVh dmUgaXQgdG8gdGhlIFdHIENoYWlycyB0byBkZWNpZGUgd2hhdCBpcyB0aGUgYmVzdCBmb3JtYXQg Zm9yIHRoZSBkcmFmdCBtb3ZpbmcgZm9yd2FyZC4NCg0KNC4gT25lIG90aGVyIG5vdGUgcmVnYXJk aW5nIHRoaXMgZHJhZnQgaW4gdGhlIGNvbnRleHQgb2Ygc2V2ZXJhbCBvdGhlciBkcmFmdHMgdGhh dCBhcmUgcHJvcG9zaW5nIGNoYW5nZXMgdG8gdGhlIFBTQyBwcm90b2NvbCBmb3IgTVBMUy1UUCBM aW5lYXIgUHJvdGVjdGlvbi4gSSB0aGluayB0aGF0IHNvbWUgb2YgdGhlc2Ugc2hvdWxkIGJlIGNv bWJpbmVkIGludG8gYSBtb3JlIHJvYnVzdCBwcm9wb3NhbCBmb3IgdGhlIHNha2Ugb2YgdGhlIGlt cGxlbWVudGVycy4gT3RoZXJ3aXNlLCB0aGVyZSBtYXkgYmUgYSBuZWVkIGZvciBhIGZ1dHVyZSAi cmVhZGVyJ3MgZ3VpZGUiIGZvciBhbiBpbXBsZW1lbnRlciB0byBmaWd1cmUgb3V0IHdoYXQgaXMg aW4gUFNDIGFuZCB3aGF0IGlzIG5vIGxvbmdlciB0aGVyZSENCg0KQm90dG9tIGxpbmUgLSBJIHRo aW5rIHRoYXQgdGhpcyBkcmFmdCBwcmVzZW50cyB2YWxpZCBwb2ludHMsIGl0IHNob3VsZCBiZSBj b3JyZWN0ZWQgdG8gbm90IHJlZmVyZW5jZSB0aGUgSVRVIExTIHByaW9yIHRvIGFjY2VwdGFuY2Ug YXMgYSBXRyBkcmFmdC4gQW5kIHRoZSBXRyBzaG91bGQgc3Ryb25nbHkgY29uc2lkZXIgY29uc29s aWRhdGluZyB0aGlzIHdvcmsgd2l0aCBzb21lIG9mIHRoZSBvdGhlciBkcmFmdHMgdG8gbWFrZSBh IG1vcmUgY29tcGxldGUgYW5kIGNvbnNpc3RlbnQgZGVmaW5pdGlvbiBvZiBQU0MgYXZhaWxhYmxl Lg0KDQpIb3BlIHRoaXMgaGVscHMsDQoNCi0tDQpUaGFueCBhbmQgQlIsDQp5YWFjb3YNCg0KU3Rp bGwgbG9va2luZyBmb3IgbmV3IG9wcG9ydHVuaXR5DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A2866B3AASMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5Mb2EsPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVw dCI+QWZ0ZXIgdXBsb2FkaW5nIGEgbmV3IHZlcnNpb24sIEkgcmVhbGl6ZWQgdGhhdCBJIHdhcyBu b3Qgc3VwcG9zZWQgdG8gdXBkYXRlIHRoZSBkb2N1bWVudCBkdXJpbmcgdGhlIE1QTFMtUlQgcmV2 aWV3IHBlcmlvZC48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5TaW5jZSB0 aGlzIHBhcnRpY3VsYXIgZHJhZnQgd2FzIHN1cHBvc2VkIHRvIGV4cGlyZSB0b21vcnJvdywgSSBu ZWVkZWQgdG8gdXBsb2FkIGEgbmV3IHZlcnNpb24gYW5kIGp1c3QgaGFwcGVuZCB0byBpbmNvcnBv cmF0ZSB0aGUgY29tbWVudHMgZnJvbSBZYWFjb3YuIFNvcnJ5Jm5ic3A7YWJvdXQgdGhpcy48L2Rp dj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5 bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5CZXN0IHJlZ2FyZHMsPC9kaXY+DQo8ZGl2IHN0eWxlPSJM SU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDog MTVwdCI+SmVvbmctZG9uZzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPjxi cj4NCjxicj4NCiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGlk PSJNYWlsU2lnbiI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+ DQo8aHIgdGFiaW5kZXg9Ii0xIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1 cHQiPjxiPkZyb20gOiA8L2I+JnF1b3Q7UnlvbywgSmVvbmctZG9uZyZxdW90OyAmbHQ7cnlvb0Bl dHJpLnJlLmtyJmd0Ozxicj4NCjxiPlNlbnQgOiA8L2I+MjAxMy0wOC0yMSAxODowMTowMyAoICYj NDM7MDk6MDAgKTxicj4NCjxiPlRvIDogPC9iPllhYWNvdiBXZWluZ2FydGVuICZsdDt3eWFhY292 QGdtYWlsLmNvbSZndDssIGxvYUBwaS5udSAmbHQ7bG9hQHBpLm51Jmd0OywgbXBsc0BpZXRmLm9y ZyAmbHQ7bXBsc0BpZXRmLm9yZyZndDssIGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1wcmlvcml0eUB0 b29scy5pZXRmLm9yZyAmbHQ7ZHJhZnQtcmhkLW1wbHMtdHAtcHNjLXByaW9yaXR5QHRvb2xzLmll dGYub3JnJmd0OywgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcgJmx0O21wbHMtY2hhaXJzQHRv b2xzLmlldGYub3JnJmd0OywNCiBtYXJ0aW4udmlnb3VyZXV4QGFsY2F0ZWwtbHVjZW50LmNvbSAm bHQ7bWFydGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2VudC5jb20mZ3Q7PGJyPg0KPGI+Q2MgOiA8 L2I+PGJyPg0KPGI+U3ViamVjdCA6IDwvYj7tmozsi6A6IFttcGxzXSBNUExTLVJUIHJldmlldyBv ZiBkcmFmdC1yaGQtbXBscy10cC1wc2MtcHJpb3JpdHk8YnI+DQo8YnI+DQo8L2Rpdj4NCjxzdHls ZT5QIHsKCU1BUkdJTi1UT1A6IDBtbTsgTUFSR0lOLUJPVFRPTTogMG1tCn0KPC9zdHlsZT4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0OyBGT05ULUZBTUlMWTog6rW066a8OyBGT05ULVNJ WkU6IDEwcHQiIGlkPSJlekZvcm1Qcm9jX2RpdiI+DQo8ZGl2IGlkPSJtc2dib2R5Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PGJyPg0KPHAgc3R5bGU9Ik1BUkdJTjog MGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQg ZmFjZT0i66eR7J2AIOqzoOuUlSI+WWFhY292LCB0aGFuayB5b3UgZm9yIHByb3ZpZGluZyB0aGUg Y29tbWVudHMuPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEw cHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAw Y20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9 IuunkeydgCDqs6DrlJUiPkkgZGlzY3Vzc2VkIHlvdXIgY29tbWVudHMgd2l0aCB0aGUgb3RoZXIg Y28tYXV0aG9ycyBvZiB0aGlzIGRyYWZ0LCBhbmQgdGhlIHJldmlzZWQgZHJhZnQgdGhhdCBoYXMg YmVlbiB1cGxvYWRlZCBqdXN0IGEgZmV3IG1pbnV0ZXMgYWdvIGNvbnRhaW5zIHRoZSB1cGRhdGVz IHJlZmxlY3RpbmcgeW91cg0KIGNvbW1lbnRzLiA8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxl PSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcmhkLW1wbHMtdHAtcHNjLXByaW9yaXR5LTAxLnR4dCIg dGFyZ2V0PSJfYmxhbmsiPjxmb250IGNvbG9yPSIjMDAwMGZmIiBmYWNlPSLrp5HsnYAg6rOg65SV Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yaGQtbXBscy10cC1w c2MtcHJpb3JpdHktMDEudHh0PC9mb250PjwvYT48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJ TjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBzdHlsZT0i TUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5UaGUgZm9sbG93aW5ncyBhcmUgdGhlIHJlc29s dXRpb24gb2YgdGhlIGNvbW1lbnRzLCBhbmQmbmJzcDtpbmNvcnBvcmF0ZWQgaW4gdGhlIG5ldyBk cmFmdDo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDq s6DrlJUiPkNvbW1lbnQgMTogQWxsIHRoZSBMU3MgaGF2ZSBiZWVuIHJlbW92ZWQgZnJvbSB0aGUg cmVmZXJlbmNlcywgYW5kIGFueSBuZWNlc3NhcnkgbWF0ZXJpYWxzIGhhdmUgYmVlbiB0cmFuc2Zl cnJlZCBpbnRvIHRoZSBkcmFmdC4NCjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJ TjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZv bnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+Q29tbWVudCAyOiBUaGUgcGFydGljdWxhciBleGFtcGxl IHJlbGF0ZWQgdG8gdGhlIHByaW9yaXR5IGxldmVsIG9mIENsZWFyIFNGIGlzIG1vdmVkIGZyb20g dGhlIExTIHRvIHRoZSBkcmFmdC4gVGhlIG1vdGl2YXRpb24gb2YgRnJlZXplIGhhcyBiZWVuIGV4 cGxhaW5lZCBpbiB0aGUgY29udGV4dA0KIG9mIHByaW9yaXR5IG1vZGlmaWNhdGlvbi48L2ZvbnQ+ PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPkNvbW1l bnQgMzogVGhpcyBjb21tZW50IHdhcyBub3QgZm9yIHRoZSBhdXRob3JzIG9mIHRoaXMgZHJhZnQu DQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6Dr lJUiPkNvbW1lbnQgNDogSSBhbSBub3Qgc3VyZSBpZiB5b3UgYXJlIGF3YXJlIG9mIHRoZSByZXN1 bHQgb2YgZGlzY3Vzc2lvbnMgaW4gdGhlIGxhc3QgSUVURiBtZWV0aW5nLiBUaGVyZSB3YXMgYSBn ZW5lcmFsIGFncmVlbWVudCBvbiB0aGUgbmVlZCBvZiBhIG5ldyBkcmFmdCB0byBwcm92aWRlIGEg bWV0aG9kDQogdG8gaW50ZWdyYXRlIGFsbCB0aGUgZHJhZnRzIGludG8gUFNDIGluIGEgYmFja3dh cmQgY29tcGF0aWJsZSBtYW5uZXIgYW5kIHRvIHByb3ZpZGUgdGhlIHN0YXRlIG1hY2hpbmUgZGVz Y3JpcHRpb24gd2hlbiBhbGwgdGhlIGZlYXR1cmVzIGFyZSBlbmFibGVkIHRvIHNhdGlzZnkgdGhl IElUVS1UIHRyYW5zcG9ydCByZXF1aXJlbWVudHMuIFRoaXMgbmV3IGRyYWZ0IGlzIG5vdyBiZWlu ZyBwcmVwYXJlZC4NCjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTjogMGNtIDBj bSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i 66eR7J2AIOqzoOuUlSI+PC9mb250Pjwvc3Bhbj4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lO OiAwY20gMGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9u dCBmYWNlPSLrp5HsnYAg6rOg65SVIj5JZiB0aGVyZSBpcyBhbnkgbWlzdW5kZXJzdGFuZGluZyBv biB5b3VyIGNvbW1lbnRzIG9yIGFueSBxdWVzdGlvbiBvbiB0aGUgdXBkYXRlcywgcGxlYXNlIGxl dCBtZSBrbm93LjwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAx MHB0IiBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20g MGNtIDEwcHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNl PSLrp5HsnYAg6rOg65SVIj5JIGFwcHJlY2lhdGUgeW91ciBoZWxwIGFuZCBzdXBwb3J0IG9uIHRo aXMgZHJhZnQuPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEw cHQiIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBjbSAw Y20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9 IuunkeydgCDqs6DrlJUiPkJlc3QgcmVnYXJkcyw8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxl PSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAg c3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+SmVvbmctZG9uZzwvZm9udD48L3Nw YW4+PC9wPg0KPGJyPg0KPGRpdiBpZD0iTWFpbFNpZ25TZW50U2VudCI+PGJyPg0KPC9kaXY+DQo8 aHIgdGFiaW5kZXg9Ii0xIj4NCjxiPkZyb20gOiA8L2I+JnF1b3Q7WWFhY292IFdlaW5nYXJ0ZW4m cXVvdDsgJmx0O3d5YWFjb3ZAZ21haWwuY29tJmd0Ozxicj4NCjxiPlNlbnQgOiA8L2I+MjAxMy0w OC0xNiAwNDo0MDozNCAoICYjNDM7MDk6MDAgKTxicj4NCjxiPlRvIDogPC9iPmxvYUBwaS5udSAm bHQ7bG9hQHBpLm51Jmd0OywgbXBsc0BpZXRmLm9yZyAmbHQ7bXBsc0BpZXRmLm9yZyZndDssIGRy YWZ0LXJoZC1tcGxzLXRwLXBzYy1wcmlvcml0eUB0b29scy5pZXRmLm9yZyAmbHQ7ZHJhZnQtcmhk LW1wbHMtdHAtcHNjLXByaW9yaXR5QHRvb2xzLmlldGYub3JnJmd0OywgbXBscy1jaGFpcnNAdG9v bHMuaWV0Zi5vcmcgJmx0O21wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnJmd0OywgbWFydGluLnZp Z291cmV1eEBhbGNhdGVsLWx1Y2VudC5jb20gJmx0O21hcnRpbi52aWdvdXJldXhAYWxjYXRlbC1s dWNlbnQuY29tJmd0Ozxicj4NCjxiPkNjIDogPC9iPjxicj4NCjxiPlN1YmplY3QgOiA8L2I+W21w bHNdIE1QTFMtUlQgcmV2aWV3IG9mIGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1wcmlvcml0eTxicj4N Cjxicj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj5IaSw8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+ DQo8ZGl2Pkkgd2FzIHJlcXVlc3RlZCB0byBjb25kdWN0IGFuIGluaXRpYWwgcmV2aWV3IG9mIGRy YWZ0LXJoZC1tcGxzLXRwLXBzYy1wcmlvcml0eS0wMSBhcyBwYXJ0IG9mIHRoZSBlZmZvcnQgdG8g ZGV0ZXJtaW5lIGlmIHRoZSBkcmFmdCBpcyBzdWl0ZWQgZm9yIGEgV0cgYWRvcHRpb24gcG9sbC4g SSBoYXZlIHJlYWQgdGhlIGRyYWZ0IGFuZCBoYXZlIHRoZSBmb2xsb3dpbmcgbm90ZXM6PC9kaXY+ DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4xLiBJIGZpbmQgaXQgcmF0aGVyIGRpc2NvbmNlcnRp bmcgdGhhdCB0aGUgZHJhZnQgaXMgcmVmZXJlbmNpbmcgYSBMUyB0aGF0IHdhcyByZWNlaXZlZCBm cm9tIHRoZSBJVFUuIFdoaWxlIEkgYW0gc3VyZSB0aGF0IHRoZSBwb2ludHMgcmFzaWVkIGluIHRo ZSBMUyBhcyB2ZXJ5IHdlbGwgdGhvdWdodCBvdXQgYW5kIHBlcnRpbmVudCwgSSBjYW5ub3Qgc2Vl IHRoYXQgdGhlIExTIHNob3VsZCBiZSBjb25zaWRlcmVkIGEgJnF1b3Q7c3RhbmRhcmRzIGRvY3Vt ZW50JnF1b3Q7DQogdGhhdCBjb3VsZCBiZSByZWZlcmVuY2VkIGJ5IGEgZnV0dXJlIFJGQy4gQXQg YmVzdCwgdGhlIExTIGNvdWxkIGJlIGNvbnNpZGVyZWQgYSAmcXVvdDtjb250cmlidXRpb24mcXVv dDsgYXQgYW4gSVRVIG1lZXRpbmcsIGFuZCBJIGRvIG5vdCBiZWxpZXZlIHRoYXQgYW4gSVRVIGRv Y3VtZW50IHdvdWxkIHJlZmVyZW5jZSBhIGNvbnRyaWJ1dGlvbiEgSSB0aGVyZWZvcmUgdGhpbmsg dGhhdCB0aGUgYXV0aG9ycyBzaG91bGQgdHJhbnNmZXIgaW50byB0aGUgZHJhZnQgd2hhdGV2ZXIN CiBpbmZvcm1hdGlvbiB0aGV5IGZlZWwgaXMgYXBwcm9wcmlhdGUgZnJvbSBzYWlkIExTLjwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Mi4gSW4gZ2VuZXJhbCwgdGhlIGRyYWZ0IGlzIGFk ZHJlc3NpbmcgaXRzZWxmIHRvIHR3byB0b3BpY3MgcmVnYXJkaW5nIFJGQzYzNzgsDQo8L2Rpdj4N CjxkaXY+YS4gQ2hhbmdlIG9mIHJlbGF0aXZlIHByaW9yaXR5IGJldHdlZW4gU0YtUCBhbmQgRlMg LSB0aGUgc3VnZ2VzdGlvbiBpcyBlc3NlbnRpYWxseSB0byByb2xsYmFjayB0aGUgcmVsZXZhbnQg Y2hhbmdlcyB0aGF0IHdlcmUgbWFkZSB0byB0aGUgUkZDIGR1cmluZyB0aGUgZmluYWwgSUVTRyBy ZXZpZXcgdG8gdGhlIHZlcnNpb24gcHJldmlvdXMgdG8gdGhhdCByZXZpZXcuPC9kaXY+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGRpdj5iLiBDaGFuZ2Ugb2YgcmVsYXRpdmUgcHJpb3JpdHkgYmV0d2Vl biBDbGVhclNGIGFuZCBTRi9TRC4gVGhpcyBpcyBiYXNlZCBvbiBhIHBhcnRpY3VsYXIgdXNlLWNh c2UgdGhhdCBpcyBtZW50aW9uZWQgaW4gdGhlIHJlZmVyZW5jZWQgTFMsIGFuZCB0aGF0IEkgc3Vn Z2VzdGVkIGJlIGV4cGxpY2l0bHkgZXhwbGFpbmVkIGluIHRoZSBkcmFmdC48L2Rpdj4NCjxkaXY+ Jm5ic3A7PC9kaXY+DQo8ZGl2PmMuIEludHJvZHVjZSAoaW4gYW4gYXBwZW5kaXgpIHRoZSB1c2Ug b2YgYSBGcmVlemUgY29tbWFuZC4gTm90IHN1cmUgd2hhdCB0aGUgbW90aXZhdGlvbiBmb3IgdGhp cyBpbiB0aGlzIGNvbnRleHQgaXMuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JbiBt eSBvcGluaW9uLCBhbGwgdGhyZWUgb2YgdGhlIHBvaW50cyBhcmUgdmFsaWQgZm9yIHdvcmsgYnkg dGhlIFdHIGFuZCBzaG91bGQgYmUgZnVsbHkgZGlzY3Vzc2VkIGluIHRoZSBXRyBwcmlvciB0byBw dWJsaWNhdGlvbiBvZiB0aGUgZHJhZnQgLSBidXQgY291bGQgYmUgZGlzY3Vzc2VkIGFzIHBhcnQg b2YgYSBXRyBkcmFmdC48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PjMuIFRoZSBmb3Jt YXQgb2YgdGhlIGRyYWZ0IGlzIGFsc28gcmF0aGVyIGludGVyZXN0aW5nIC0gaXQgc2VlbXMgdG8g YmUgcHJlc2VudGluZyBhbiBlcnJhdGEgbm90ZSB0byBSRkM2Mzc4IHJhdGhlciB0aGFuIGRlc2Ny aWJpbmcgdGhlIGRlc2lyZWQgYmVoYXZpb3IuIEkgbGVhdmUgaXQgdG8gdGhlIFdHIENoYWlycyB0 byBkZWNpZGUgd2hhdCBpcyB0aGUgYmVzdCBmb3JtYXQgZm9yIHRoZSBkcmFmdCBtb3ZpbmcgZm9y d2FyZC48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PjQuIE9uZSBvdGhlciBub3RlIHJl Z2FyZGluZyB0aGlzIGRyYWZ0IGluIHRoZSBjb250ZXh0IG9mIHNldmVyYWwgb3RoZXIgZHJhZnRz IHRoYXQgYXJlIHByb3Bvc2luZyBjaGFuZ2VzIHRvIHRoZSBQU0MgcHJvdG9jb2wgZm9yIE1QTFMt VFAgTGluZWFyIFByb3RlY3Rpb24uIEkgdGhpbmsgdGhhdCBzb21lIG9mIHRoZXNlIHNob3VsZCBi ZSBjb21iaW5lZCBpbnRvIGEgbW9yZSByb2J1c3QgcHJvcG9zYWwgZm9yIHRoZSBzYWtlIG9mIHRo ZSBpbXBsZW1lbnRlcnMuDQogT3RoZXJ3aXNlLCB0aGVyZSBtYXkgYmUgYSBuZWVkIGZvciBhIGZ1 dHVyZSAmcXVvdDtyZWFkZXIncyBndWlkZSZxdW90OyBmb3IgYW4gaW1wbGVtZW50ZXIgdG8gZmln dXJlIG91dCB3aGF0IGlzIGluIFBTQyBhbmQgd2hhdCBpcyBubyBsb25nZXIgdGhlcmUhPC9kaXY+ DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5Cb3R0b20gbGluZSAtIEkgdGhpbmsgdGhhdCB0aGlz IGRyYWZ0IHByZXNlbnRzIHZhbGlkIHBvaW50cywgaXQgc2hvdWxkIGJlIGNvcnJlY3RlZCB0byBu b3QgcmVmZXJlbmNlIHRoZSBJVFUgTFMgcHJpb3IgdG8gYWNjZXB0YW5jZSBhcyBhIFdHIGRyYWZ0 LiBBbmQgdGhlIFdHIHNob3VsZCBzdHJvbmdseSBjb25zaWRlciBjb25zb2xpZGF0aW5nIHRoaXMg d29yayB3aXRoIHNvbWUgb2YgdGhlIG90aGVyIGRyYWZ0cyB0byBtYWtlIGEgbW9yZQ0KIGNvbXBs ZXRlIGFuZCBjb25zaXN0ZW50IGRlZmluaXRpb24gb2YgUFNDIGF2YWlsYWJsZS48L2Rpdj4NCjxk aXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkhvcGUgdGhpcyBoZWxwcyw8YnIgY2xlYXI9ImFsbCI+DQo8 YnI+DQotLSA8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPlRoYW54IGFuZCBCUiwNCjxkaXY+ eWFhY292PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48aT5TdGlsbCBsb29raW5nIGZv ciBuZXcgb3Bwb3J0dW5pdHk8L2k+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A2866B3AASMTP2etriinfo_-- From loa@pi.nu Wed Aug 21 03:05:12 2013 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 E6CEB11E80ED for ; Wed, 21 Aug 2013 03:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTEZnltI6Jwv for ; Wed, 21 Aug 2013 03:05:08 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id B4E0811E814C for ; Wed, 21 Aug 2013 03:05:07 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 94A511802038; Wed, 21 Aug 2013 12:05:06 +0200 (CEST) Message-ID: <521490D5.1060302@pi.nu> Date: Wed, 21 Aug 2013 12:05:09 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Ryoo, Jeong-dong" References: , <5B4A6CBE3924BB41A3BEE462A8E0B75A2866A35E@SMTP2.etri.info> <5B4A6CBE3924BB41A3BEE462A8E0B75A2866B3AA@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A2866B3AA@SMTP2.etri.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-rhd-mpls-tp-psc-priority@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-rhd-mpls-tp-psc-priority 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, 21 Aug 2013 10:05:13 -0000 Jeong-dong, I think this is OK - I'll ask the mpls-rt reviewers to be explicit about which version of the draft they reviewed. /Loa On 2013-08-21 11:53, Ryoo, Jeong-dong wrote: > Loa, > After uploading a new version, I realized that I was not supposed to > update the document during the MPLS-RT review period. > Since this particular draft was supposed to expire tomorrow, I needed to > upload a new version and just happend to incorporate the comments from > Yaacov. Sorry about this. > Best regards, > Jeong-dong > > > > ------------------------------------------------------------------------ > *From : *"Ryoo, Jeong-dong" > *Sent : *2013-08-21 18:01:03 ( +09:00 ) > *To : *Yaacov Weingarten , loa@pi.nu , > mpls@ietf.org , > draft-rhd-mpls-tp-psc-priority@tools.ietf.org > , > mpls-chairs@tools.ietf.org , > martin.vigoureux@alcatel-lucent.com > *Cc : * > *Subject : *회신: [mpls] MPLS-RT review of draft-rhd-mpls-tp-psc-priority > > > Yaacov, thank you for providing the comments. > > I discussed your comments with the other co-authors of this draft, and > the revised draft that has been uploaded just a few minutes ago contains > the updates reflecting your comments. > > http://www.ietf.org/internet-drafts/draft-rhd-mpls-tp-psc-priority-01.txt > > The followings are the resolution of the comments, and incorporated in > the new draft: > > Comment 1: All the LSs have been removed from the references, and any > necessary materials have been transferred into the draft. > > Comment 2: The particular example related to the priority level of Clear > SF is moved from the LS to the draft. The motivation of Freeze has been > explained in the context of priority modification. > > Comment 3: This comment was not for the authors of this draft. > > Comment 4: I am not sure if you are aware of the result of discussions > in the last IETF meeting. There was a general agreement on the need of a > new draft to provide a method to integrate all the drafts into PSC in a > backward compatible manner and to provide the state machine description > when all the features are enabled to satisfy the ITU-T transport > requirements. This new draft is now being prepared. > > If there is any misunderstanding on your comments or any question on the > updates, please let me know. > > I appreciate your help and support on this draft. > > Best regards, > > Jeong-dong > > > > ------------------------------------------------------------------------ > *From : *"Yaacov Weingarten" > *Sent : *2013-08-16 04:40:34 ( +09:00 ) > *To : *loa@pi.nu , mpls@ietf.org , > draft-rhd-mpls-tp-psc-priority@tools.ietf.org > , > mpls-chairs@tools.ietf.org , > martin.vigoureux@alcatel-lucent.com > *Cc : * > *Subject : *[mpls] MPLS-RT review of draft-rhd-mpls-tp-psc-priority > > Hi, > I was requested to conduct an initial review of > draft-rhd-mpls-tp-psc-priority-01 as part of the effort to determine if > the draft is suited for a WG adoption poll. I have read the draft and > have the following notes: > 1. I find it rather disconcerting that the draft is referencing a LS > that was received from the ITU. While I am sure that the points rasied > in the LS as very well thought out and pertinent, I cannot see that the > LS should be considered a "standards document" that could be referenced > by a future RFC. At best, the LS could be considered a "contribution" at > an ITU meeting, and I do not believe that an ITU document would > reference a contribution! I therefore think that the authors should > transfer into the draft whatever information they feel is appropriate > from said LS. > 2. In general, the draft is addressing itself to two topics regarding > RFC6378, > a. Change of relative priority between SF-P and FS - the suggestion is > essentially to rollback the relevant changes that were made to the RFC > during the final IESG review to the version previous to that review. > b. Change of relative priority between ClearSF and SF/SD. This is based > on a particular use-case that is mentioned in the referenced LS, and > that I suggested be explicitly explained in the draft. > c. Introduce (in an appendix) the use of a Freeze command. Not sure what > the motivation for this in this context is. > In my opinion, all three of the points are valid for work by the WG and > should be fully discussed in the WG prior to publication of the draft - > but could be discussed as part of a WG draft. > 3. The format of the draft is also rather interesting - it seems to be > presenting an errata note to RFC6378 rather than describing the desired > behavior. I leave it to the WG Chairs to decide what is the best format > for the draft moving forward. > 4. One other note regarding this draft in the context of several other > drafts that are proposing changes to the PSC protocol for MPLS-TP Linear > Protection. I think that some of these should be combined into a more > robust proposal for the sake of the implementers. Otherwise, there may > be a need for a future "reader's guide" for an implementer to figure out > what is in PSC and what is no longer there! > Bottom line - I think that this draft presents valid points, it should > be corrected to not reference the ITU LS prior to acceptance as a WG > draft. And the WG should strongly consider consolidating this work with > some of the other drafts to make a more complete and consistent > definition of PSC available. > Hope this helps, > > -- > Thanx and BR, > yaacov > > /Still looking for new opportunity/ -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From stbryant@cisco.com Wed Aug 21 03:45:20 2013 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 A18D311E8390; Wed, 21 Aug 2013 03:45: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 v7dxRr0p0tUt; Wed, 21 Aug 2013 03:45:15 -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 CB29111E838F; Wed, 21 Aug 2013 03:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=89361; q=dns/txt; s=iport; t=1377081912; x=1378291512; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=8ebJAqFUKBZYdHWJd3fdLX0OhMQBchgI7tOUQqu5s2E=; b=Qu9ZN26FbX4A8oLT3nV/abxN1UPqHj7V7wKcj9I2kiUxow8Kezha2+kf 8b15agE0XqWRfFiOVmjRZx452DrBTV0jHaJETj3OG2CGL7bNe19MFrml9 K4J0W7X4rFucLvYEu32xx2p3wAM650tkx562HajKa77riI08VZaLQzZRx w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAB6ZFFKQ/khN/2dsb2JhbABQCoMFNa1ukjyBJRZ0giQBAQEEAQEBFwEdLgEHCgEMBAsRAQMBAQEJDAoIBwkDAgECARUeAQMGCAYKAwEFAgEBF4djAw8MrXqNXYEkAgkGBQWBFyIHBgSECgOMRIcIQYFzgWWBLYVxhRCFKIMdgWgIFw X-IronPort-AV: E=Sophos;i="4.89,927,1367971200"; d="scan'208";a="17355467" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 21 Aug 2013 10:45:07 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7LAj5ja023053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Aug 2013 10:45:05 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r7LAj1Eg020042; Wed, 21 Aug 2013 11:45:04 +0100 (BST) Message-ID: <52149A2D.3050109@cisco.com> Date: Wed, 21 Aug 2013 11:45:01 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alexander Vainshtein References: <51FB7543.801@cisco.com> <51FF7068.9080600@cisco.com> <4A6CE49E6084B141B15C0713B8993F281BEC731A@SJEXCHMB12.corp.ad.broadcom.com> <52139903.8040801@cisco.com> , In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] Comments on draft-ietf-tictoc-1588overmpls 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, 21 Aug 2013 10:45:20 -0000 Sasha Note that if the next hop understands the alert, you can put the alert label at the ToS. If it does not understand, you would want to tunnel through it and hence there would be a label on top or the alert label. Shahram, there seems to be some confusion about stitching vs hierarchy, and I have been proposing hierarchy to step over the nodes that are unable to understand the alert label. Stewart On 20/08/2013 19:51, Alexander Vainshtein wrote: > Shahram, > No I am not proposing anything of the kind. > > At the MPLS data plane level the only the head-end and the tail-end LERs have to be aware of the BoS Timing Alert labels. Transit LSRs simply will ignore them. > > At the on-path assistance level each transit LSR (and the tail-end LER) can do one of the following: > - It may ignore the Timing Alert label at the BoS and just forward the packet based the labels at the top of the stack. > - It may identify the packet as a timing one based on the Timing Alert label at the bottom of the label stack, and perform the required operations. The result of these operations will be stored in the "timing shim header" and not in the packet itself. (E.g., an E2E TC clock would note the packet residence time and add it to the value already carried in the shim header). > > Non-timing packets would not have the Timing Alert label at the BoS and hence would travel thru he LSP travel along the LSP in the usual way. > > The tail-end LER would take the reception timestamp and forward this timestamp, the protocol packet and the shim header to the entity that processes the appropriate timing distribution protocol based on the Timing Alert label. > > Hopefully this clarifies my proposal. My gut feeling is that similar ideas have been proposed by many people earlier... > > Regards, > Sasha > > > ________________________________________ > From: S. Davari [davarish@yahoo.com] > Sent: Tuesday, August 20, 2013 7:00 PM > To: Alexander Vainshtein > Cc: stbryant@cisco.com; Shahram Davari; mpls@ietf.org; tictoc@ietf.org > Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls > > Sasha > > In (2) are you proposing to create multiple segment LSPs, where each if those segment LSPs span between two Timing aware LSR? So if I have 10 timing aware LSR in the path I would need 9 LSPs? > > Regards, > Shahram > > > On Aug 20, 2013, at 9:53 AM, Alexander Vainshtein wrote: > >> Stewart, Shahram and all, >> >> A couple of (hopefully, last) comments: >> >> 1. Supporting a "Timing Alert" label at the top of the label stack introduces a backward compatibility problem. We differ in our estimate of the importance of this problem, but we all agree that it exists. >> >> 2. On the other hand, this problem does not exist if the "Timing Alert" label is inserted at the bottom of the label stack. At the same time, HW that analyzes the label stack hopefully could analyze the bottom label (almost) as easily as it would analyze the top label. Thus we could both provide backward compatibility (incompatible transit LSRs simply would not notice the "Timing Alert" label") and avoid the need for dedicated "Timing-only" LSPs. In particular, all the MPLS OAM tools (including MPLS-TP) would work without any changes. >> >> 3. A "timing shim header" (between the bottom of the label stack and the beginning of the timing packet) has been mentioned by Stewart as an already proposed mechanism. IMHO and FWIW its usage would eliminate the need to understand format of the specific timing distribution protocol in the transit LSRs. It would further solve the problem of secure transport of timing packets since security mechanisms would be applied to its original encapsulation (over IP or over Ethernet) without involving the transit LSRs. >> >> Did I miss something substantial? >> >> Regards, and lots of thanks in advance, >> Sasha >> >> >> ________________________________________ >> From: Stewart Bryant [stbryant@cisco.com] >> Sent: Tuesday, August 20, 2013 6:27 PM >> To: S. Davari >> Cc: Alexander Vainshtein; Shahram Davari; mpls@ietf.org; tictoc@ietf.org >> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls >> >> On 06/08/2013 14:35, S. Davari wrote: >>> Sasha, >>> >>> If a router is not 1588 aware we want it to switch the packet with minimum jitter and delay via high priority queue. >> Yes, but you can explicitly tunnel across such island of incompatibility >> >> Stewart >> >>> >>> Sending it to CPU creates large jitter and delay since the CPUs are generally busy doing other things. Time stamping or updating CF in the CPU won't help since it does not cover the variable delay that is incurred from the time the packet enters the router to the time the packet gets processed by CPU. >>> >>> I wish it was that easy! >>> >>> Regards, >>> Shahram >>> >>> >>> On Aug 6, 2013, at 12:38 AM, Alexander Vainshtein wrote: >>> >>>> Shahram, >>>> I agree with you that the routers that do not recognize a Timing Alert label would send the packet to the CPU. (This would be easy to arrange since we are speaking about a reserved label.) >>>> >>>> I do not, however, see this as a serious issue, because the SW running on this CPU would (hopefully) be upgradable to handle the packet correctly i.e., to forward it to where it should be forwarded and, if it is forwarded as a labeled packet, to prepend the Timing Alert Label on top of its label stack. It could even record the residence time (as observed by the CPU in the proper place in the packet. This would mean that introducing additional error to whatever timing information is associated with this packet - but this is what you should anyway expect if there are non-compliant routers on your path, right? >>>> >>>> Regards, >>>> Sasha >>>> >>>>> -----Original Message----- >>>>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of >>>>> Shahram Davari >>>>> Sent: Monday, August 05, 2013 11:29 PM >>>>> To: stbryant@cisco.com; S. Davari >>>>> Cc: mpls@ietf.org; tictoc@ietf.org >>>>> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls >>>>> >>>>> Hi Stewart, >>>>> >>>>> Your suggestion of " I suggested an LSP type that has the properties "timestamp >>>>> and pass to application", is a subset of the existing draft and should work. It >>>>> basically limits the time stamping and correction field update to LERs (while the >>>>> draft supports time stamping at LER and LSR). >>>>> >>>>> However Sasha's suggestion of using a reserved label (RAL, GAL or any other >>>>> reserved label) does not satisfy one of the major requirements, which is >>>>> backward compatibility. Routers that don't understand this reserved label will >>>>> drop or copy to CPU such packets. >>>>> >>>>> Regards, >>>>> Shahram >>>>> >>>>> -----Original Message----- >>>>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of >>>>> Stewart Bryant >>>>> Sent: Monday, August 05, 2013 2:29 AM >>>>> To: S. Davari >>>>> Cc: mpls@ietf.org; tictoc@ietf.org >>>>> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls >>>>> >>>>> My concern is that we are creating a new LSP type in MPLS >>>>> (which is a architectural change and thus needs to be very carefully >>>>> considered) without asking the question "how can I do this >>>>> in the most general way, to maximize flexibility/reuse" >>>>> >>>>> I suggested an LSP type that has the properties "timestamp >>>>> and pass to application", but I think that Sasha raises a good >>>>> point about using router alert. However RA has no implicit >>>>> timestamp, so maybe we need a new type of RA that has the >>>>> properties "timestamp, and pass top application indicated by >>>>> the next label". That would be quite useful in a number >>>>> of OAM applications. There is possibly some GAL variant >>>>> of that design that should also be considered. >>>>> >>>>> The application could worry about the path and where it >>>>> was necessary to skip some hops a hierarchical LSP would >>>>> accomplish that, with the specific benefit that the application >>>>> would consciously do this, and may be able to apply some >>>>> form of compensation within the network. >>>>> >>>>> - Stewart >>>>> >>>>> On 04/08/2013 10:40, S. Davari wrote: >>>>>> Hi Sasha >>>>>> >>>>>> Perhaps you have not understood the draft well. The main reason that the >>>>> draft chose to use a dedicated LSP that is signaled via RSVPTE indicating it is a >>>>> timing LSP is to be backward compatible with non-1588 nodes. Such nodes >>>>> simply just switch the packet. >>>>>> Your proposal had been considered and was rejected since it was not >>>>> backward compatible. Nodes receiving alert label or TTL = 1 send the packet to >>>>> CPU. You can refer to the meeting notes. >>>>>> Regards, >>>>>> Shahram >>>>>> >>>>>> >>>>>> On Aug 4, 2013, at 1:21 AM, Alexander Vainshtein >>>>> wrote: >>>>>>> Stewart and all, >>>>>>> I concur with Stewart's statement that the draft does not define "full >>>>> interaction with MPLS architecture". >>>>>>> E.g., one of the objectives of the draft is to provide a technique that would >>>>> be backward-compatible with old LSRs that cannot provide on-path support for >>>>> timing distribution, while the other objective is to make every LSR on the path >>>>> aware that some MPLS packets are carrying timing-related messages and hence >>>>> require on-path support. >>>>>>> IMHO and FWIW, the MPLS data plane architecture allows just two methods >>>>> for making a transit LSR to provide special processing to a labeled packet: >>>>>>> - It would carry some kind of an "alert label" on top of the label stack and, >>>>> specifically, on top of any labels used for actual forwarding >>>>>>> OR, >>>>>>> - The TTL in the top label stack entry has been set to 1. >>>>>>> >>>>>>> >>>>>>> The draft does not follow any of these approaches. >>>>>>> >>>>>>> I must also admit that Section 12 "OAM, Control and Management" of the >>>>> draft looks somewhat in >>>>>>> E.g., I could not understand from the text whether BFD, LSP-Ping etc. OAM >>>>> messages would be subjected to on-path support procedures for timing >>>>> messages or not. >>>>>>> My 2c, >>>>>>> Sasha >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf >>>>> Of >>>>>>>> Stewart Bryant >>>>>>>> Sent: Friday, August 02, 2013 12:01 PM >>>>>>>> To: mpls-chairs@tools.ietf.org; tictoc-chairs@tools.ietf.org; int- >>>>>>>> ads@tools.ietf.org; rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; >>>>> draft- >>>>>>>> ietf-tictoc-1588overmpls@tools.ietf.org >>>>>>>> Cc: mpls@ietf.org; tictoc@ietf.org >>>>>>>> Subject: [TICTOC] Comments on draft-ietf-tictoc-1588overmpls >>>>>>>> >>>>>>>> SB> This draft does not seem to provide a precise definition >>>>>>>> SB> the properties of the new LSP type that it wishes to >>>>>>>> SB> define, in particular it does it define the PHB of those >>>>>>>> SB> LSPs, nor the full interaction with the MPLS >>>>>>>> SB> architecture. >>>>>>>> SB> >>>>>>>> SB> I have not tracked TICTOC for a while but I thought that >>>>>>>> SB> the original plan was to define the concept of an offset >>>>>>>> SB> into a packet to do the correction. >>>>>>>> SB> >>>>>>>> SB> It is disappointing that the opportunity was not taken >>>>>>>> SB> to define a timing shim inside the timing LSP so that >>>>>>>> SB> a time correction could be added to any packet such that >>>>>>>> SB> the MPLS system was isolated from the details of the >>>>>>>> SB> complexity of the particular time transfer type. >>>>>>>> >>>>>>>> SB> I think that much more clarify is needed in terms of >>>>>>>> SB> definition of the new LSP type, since it is unclear >>>>>>>> SB> from this text how to implement one. >>>>>>>> SB> >>>>>>>> SB> There are a lot of other MPLS services such as >>>>>>>> SB> LSP ping that need to be considered. >>>>>>>> SB> >>>>>>>> SB> Please see inline for more comments. However these >>>>>>>> SB> comments are made in the context of the text as written >>>>>>>> SB> whilst I have a fundamental concern that this approach >>>>>>>> SB> lacks an MPLS architectural soundness that need >>>>>>>> SB> greater thought with significant impact on the >>>>>>>> SB> draft. >>>>>>>> >>>>>>>> - Stewart >>>>>>>> >>>>>>>> >>>>>>>> TICTOC Working Group S. Davari >>>>>>>> Internet-Draft A. Oren >>>>>>>> Intended status: Standards Track Broadcom Corp. >>>>>>>> Expires: December 17, 2013 M. Bhatia >>>>>>>> P. Roberts >>>>>>>> Alcatel-Lucent >>>>>>>> L. Montini >>>>>>>> L. Martini >>>>>>>> Cisco Systems >>>>>>>> June 15, 2013 >>>>>>>> >>>>>>>> >>>>>>>> Transporting Timing messages over MPLS Networks >>>>>>>> draft-ietf-tictoc-1588overmpls-05 >>>>>>>> >>>>>>>> Abstract >>>>>>>> >>>>>>>> This document defines the method for transporting Timing messages >>>>>>>> such as PTP and NTP over an MPLS network. The method allows for the >>>>>>>> easy identification of these PDUs at the port level to allow for port >>>>>>>> >>>>>>>> SB> What is a port >>>>>>>> >>>>>>>> level processing of these PDUs in both LERs and LSRs. >>>>>>>> >>>>>>>> The basic idea is to transport Timing messages inside dedicated MPLS >>>>>>>> LSPs. These LSPs only carry Timing messages and possibly Control and >>>>>>>> Management packets, but they do not carry customer traffic. >>>>>>>> >>>>>>>> SB> More specifically they only carry traffic associated with the >>>>>>>> SB> timing service and its support. >>>>>>>> SB> The question arose WRT BFD - surely BFD is allowed, BUT surely >>>>>>>> SB> also it gets carried in a structure that causes it to get >>>>>>>> SB> timestamped. >>>>>>>> >>>>>>>> Two methods for transporting Timing messages over MPLS are defined. >>>>>>>> >>>>>>>> SB> Perhaps the right approach is to define the new LSP type and then >>>>>>>> SB> seperately to define the mapping of the various timing services >>>>>>>> SB> over that LSP type. >>>>>>>> >>>>>>>> The first method is to transport Timing messages directly over the >>>>>>>> dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for >>>>>>>> MPLS networks. The second method is to transport Timing messages >>>>>>>> inside a PW via Ethernet encapsulation. >>>>>>>> >>>>>>>> SB> I think that we should note that there are some >>>>>>>> SB> h/w reasons for this preference. A clean sheet approach >>>>>>>> SB> would have been to use PTP over MPLS with no intermediate >>>>>>>> SB> layers. >>>>>>>> >>>>>>>> Status of this Memo >>>>>>>> >>>>>>>> This Internet-Draft is submitted in full conformance with the >>>>>>>> provisions of BCP 78 and BCP 79. >>>>>>>> >>>>>>>> Internet-Drafts are working documents of the Internet Engineering >>>>>>>> Task Force (IETF). Note that other groups may also distribute >>>>>>>> working documents as Internet-Drafts. The list of current Internet- >>>>>>>> Drafts is at http://datatracker.ietf.org/drafts/current/. >>>>>>>> >>>>>>>> Internet-Drafts are draft documents valid for a maximum of six months >>>>>>>> and may be updated, replaced, or obsoleted by other documents at any >>>>>>>> time. It is inappropriate to use Internet-Drafts as reference >>>>>>>> material or to cite them other than as "work in progress." >>>>>>>> >>>>>>>> This Internet-Draft will expire on December 17, 2013. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 1] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> Copyright Notice >>>>>>>> >>>>>>>> Copyright (c) 2013 IETF Trust and the persons identified as the >>>>>>>> document authors. All rights reserved. >>>>>>>> >>>>>>>> This document is subject to BCP 78 and the IETF Trust's Legal >>>>>>>> Provisions Relating to IETF Documents >>>>>>>> (http://trustee.ietf.org/license-info) in effect on the date of >>>>>>>> publication of this document. Please review these documents >>>>>>>> carefully, as they describe your rights and restrictions with respect >>>>>>>> to this document. Code Components extracted from this document must >>>>>>>> include Simplified BSD License text as described in Section 4.e of >>>>>>>> the Trust Legal Provisions and are provided without warranty as >>>>>>>> described in the Simplified BSD License. >>>>>>>> >>>>>>>> >>>>>>>> Table of Contents >>>>>>>> >>>>>>>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 >>>>>>>> >>>>>>>> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 >>>>>>>> >>>>>>>> 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 >>>>>>>> >>>>>>>> 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . 9 >>>>>>>> >>>>>>>> 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . . 12 >>>>>>>> >>>>>>>> 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . 13 >>>>>>>> 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . . 13 >>>>>>>> 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . . 13 >>>>>>>> 6.3. Other Timing Encapsulation methods . . . . . . . . . . . . 14 >>>>>>>> >>>>>>>> 7. Timing message Processing . . . . . . . . . . . . . . . . . . 15 >>>>>>>> >>>>>>>> 8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 16 >>>>>>>> >>>>>>>> 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 >>>>>>>> >>>>>>>> 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 >>>>>>>> >>>>>>>> 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 >>>>>>>> >>>>>>>> 12. OAM, Control and Management . . . . . . . . . . . . . . . . . 20 >>>>>>>> >>>>>>>> 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 21 >>>>>>>> >>>>>>>> 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . . 22 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 2] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 23 >>>>>>>> 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . . 23 >>>>>>>> 15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . . 23 >>>>>>>> 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . . 24 >>>>>>>> >>>>>>>> 16. Other considerations . . . . . . . . . . . . . . . . . . . . . 25 >>>>>>>> >>>>>>>> 17. Security Considerations . . . . . . . . . . . . . . . . . . . 26 >>>>>>>> >>>>>>>> 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 >>>>>>>> >>>>>>>> 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 >>>>>>>> >>>>>>>> 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 >>>>>>>> 20.1. Normative References . . . . . . . . . . . . . . . . . . . 29 >>>>>>>> 20.2. Informative References . . . . . . . . . . . . . . . . . . 29 >>>>>>>> >>>>>>>> Appendix 1. Routing extensions for Timing-aware Routers . . . . . 32 >>>>>>>> >>>>>>>> Appendix 2. Signaling Extensions for Creating Timing LSPs . . . . 33 >>>>>>>> >>>>>>>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 3] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >>>>> NOT", >>>>>>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" >>>>> in >>>>>>>> this >>>>>>>> document are to be interpreted as described in RFC2119 [RFC2119]. >>>>>>>> >>>>>>>> When used in lower case, these words convey their typical use in >>>>>>>> common language, and are not to be interpreted as described in >>>>>>>> RFC2119 [RFC2119]. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 4] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 1. Introduction >>>>>>>> >>>>>>>> The objective of Precision Time Protocol (PTP) and Network Timing >>>>>>>> Protocol (NTP) are to synchronize independent clocks running on >>>>>>>> separate nodes of a distributed system. >>>>>>>> >>>>>>>> [IEEE-1588] defines PTP messages for frequency, phase and time >>>>>>>> synchronization. The PTP messages include PTP PDUs over UDP/IP >>>>>>>> (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex F of >>>>>>>> [IEEE-1588]). >>>>>>>> >>>>>>>> SB> Sure BUT it is acknowledged that IEEE is open to the definition >>>>>>>> SB> of other PTP mappings if they provide better optimisation. >>>>>>>> >>>>>>>> This document defines mapping and transport of the PTP >>>>>>>> messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP >>>>>>>> defines several clock types: ordinary clocks, boundary clocks, end- >>>>>>>> to-end transparent clocks, and peer-to-peer transparent clocks. >>>>>>>> Transparent clocks require intermediate nodes to update correction >>>>>>>> field inside PTP message that reflects the transit time in the node. >>>>>>>> >>>>>>>> [RFC5905] defines NTP messages for clock and time synchronization. >>>>>>>> The PTP messages (PDUs) are transported over UDP/IP. This document >>>>>>>> SB> Should that be NTP messages? >>>>>>>> SB> It needs to be made clear as soon as you introduce NTP that >>>>>>>> SB> they use different time representations. >>>>>>>> >>>>>>>> defines mapping and transport of the NTP messages defined in >>>>>>>> [RFC5905] over MPLS networks. >>>>>>>> >>>>>>>> One key attribute of all of these Timing messages is that the Time >>>>>>>> stamp processing should occur as close as possible to the actual >>>>>>>> transmission and reception at the physical port interface. This >>>>>>>> targets optimal time and/or frequency recovery by avoiding variable >>>>>>>> delay introduced by queues internal to the clocks. >>>>>>>> >>>>>>>> SB> As I recall NTP has no epoch point defined, and I am not sure >>>>>>>> SB> where that point is in the case of PTP in this mapping >>>>>>>> SB> Hopefully this will get defined in due course. >>>>>>>> >>>>>>>> To facilitate the fast and efficient recognition of Timing messages >>>>>>>> at the port level when the Timing messages are carried over MPLS >>>>>>>> LSPs, >>>>>>>> >>>>>>>> SB> Over a new LSP type with time optimied characteristics >>>>>>>> >>>>>>>> this document defines the specific encapsulations that should >>>>>>>> be used. >>>>>>>> SB> Hopefully it will also define the PHP >>>>>>>> >>>>>>>> In addition, it can be expected that there will exist LSR/ >>>>>>>> LERs where only a subset of the physical ports will have the port- >>>>>>>> based Timing message processing capabilities. >>>>>>>> SB> Do you need to clarify that this only works at base and not in >>>>>>>> SB> a label heirarchy. >>>>>>>> >>>>>>>> >>>>>>>> In order to ensure >>>>>>>> that the LSPs carrying Timing packets always enter and exit ports >>>>>>>> with this capability, routing extensions are defined to advertise >>>>>>>> this capability on a port basis and to allow for the establishment of >>>>>>>> LSPs that only transit such ports. While this path establishment >>>>>>>> restriction may be applied only at the LER Ingress and/or egress >>>>>>>> ports, it becomes more important when using transparent clock capable >>>>>>>> LSRs in the path. >>>>>>>> SB> I do not understand the implications of the last >>>>>>>> SB> sentences - starting ", it becomes" >>>>>>>> >>>>>>>> >>>>>>>> Port based Timing message processing involves Timing message >>>>>>>> recognition. Once the Timing messages are recognized they can be >>>>>>>> modified based on the reception or transmission Time-stamp. >>>>>>>> >>>>>>>> This document provides two methods for transporting Timing messages >>>>>>>> over MPLS. One is applicable to MPLS environment and the other one >>>>>>>> is applicable to MPLS/MPLS-TP environment >>>>>>>> >>>>>>>> SB> I think the sentence is incomplete. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 5] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> The solution involves transporting Timing messages over dedicated >>>>>>>> LSPs called Timing LSPs. These LSPs carry Timing messages and MAY >>>>>>>> carry Management and control messages, but not data plane client >>>>>>>> traffic. >>>>>>>> >>>>>>>> SB> It is not clear why this restriction applies. >>>>>>>> >>>>>>>> Timing LSPs can be established statically or via signaling. >>>>>>>> SB> s/statically/by provisioning/network management/ >>>>>>>> >>>>>>>> Extensions to control plane (OSPF, ISIS, etc.) is required to enable >>>>>>>> routers to distribute their Timing processing capabilities over MPLS >>>>>>>> to other routers. However such extensions are outside the scope of >>>>>>>> this document. >>>>>>>> >>>>>>>> When signaling is used to setup the PTP LSP, Extensions to signaling >>>>>>>> SB> is it a PTP LSP or a Timing LSP? >>>>>>>> >>>>>>>> protocols (e.g., RSVP-TE) are required for establishing PTP LSPs. >>>>>>>> However such extensions are outside the scope of this document. >>>>>>>> >>>>>>>> SB> for mpls-tp GMPLS is the signalling protocol >>>>>>>> >>>>>>>> While the techniques included herein allow for the establishment of >>>>>>>> paths optimized to include Time-stamping capable links, the >>>>>>>> performance of the Slave clocks is outside the scope of this >>>>>>>> document. >>>>>>>> >>>>>>>> At the time of publishing this specification, Transparent Clocking >>>>>>>> (TC) is only defined for PTP. Therefore at this time any part of >>>>>>>> this specification that talks about Transparent Clocking applies only >>>>>>>> to PTP. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 6] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 2. Terminology >>>>>>>> >>>>>>>> 1588: The timing and synchronization as defined by IEEE 1588. >>>>>>>> >>>>>>>> SB> I think that there is a more formal name for the 1588 group >>>>>>>> SB> that needs to be used here. >>>>>>>> SB> Also do we need to talk about 1588-200? as there is >>>>>>>> SB> an update in progress >>>>>>>> >>>>>>>> NTP: The timing and synchronization protocol defined by IETF RFC-1305 >>>>>>>> and RFC-5905. >>>>>>>> >>>>>>>> PTP: The timing and synchronization protocol used by 1588. >>>>>>>> SB> need the proper name for 1588 >>>>>>>> >>>>>>>> Master Clock: The source of 1588 timing to a set of slave clocks. >>>>>>>> >>>>>>>> Master Port: A port on a ordinary or boundary clock that is in Master >>>>>>>> state. This is the source of timing toward slave ports. >>>>>>>> >>>>>>>> SB> I am not sure the reader knows what a port is >>>>>>>> >>>>>>>> Slave Clock: A receiver of 1588 timing from a master clock. >>>>>>>> >>>>>>>> Slave Port: A port on a boundary clock or ordinary clock that is >>>>>>>> receiving timing from a master clock. >>>>>>>> >>>>>>>> Ordinary Clock: A device with a single PTP port. >>>>>>>> >>>>>>>> Transparent Clock. A device that measures the time taken for a PTP >>>>>>>> event message to transit the device and then updates the >>>>>>>> correctionField of the message with this transit time. >>>>>>>> >>>>>>>> Boundary Clock: A device with more than one PTP port. Generally >>>>>>>> boundary clocks will have one port in slave state to receive timing >>>>>>>> and then other ports in master state to re-distribute the timing. >>>>>>>> >>>>>>>> PTP LSP: An LSP dedicated to carry PTP messages >>>>>>>> >>>>>>>> SB> PTP or timing? >>>>>>>> >>>>>>>> >>>>>>>> PTP PW: A PW within a PTP LSP that is dedicated to carry PTP >>>>>>>> messages. >>>>>>>> >>>>>>>> SB> Ah I don't think that PWE3 know what one of these is >>>>>>>> >>>>>>>> CW: Pseudowire Control Word >>>>>>>> >>>>>>>> LAG: Link Aggregation >>>>>>>> >>>>>>>> ECMP: Equal Cost Multipath >>>>>>>> >>>>>>>> CF: Correction Field, a field inside certain PTP messages (message >>>>>>>> type 0-3)that holds the accumulative transit time inside intermediate >>>>>>>> switches >>>>>>>> >>>>>>>> Timing messages: Timing Protocol messages that are exchanged >>>>> between >>>>>>>> routers in order to establish a synchronized clock. >>>>>>>> >>>>>>>> SB> A number of these definitions look like copies of IEEE1588 >>>>>>>> SB> definitions. We need to provide references and note the >>>>>>>> SB> priority of the IEEE base reference. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 7] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 3. Problem Statement >>>>>>>> >>>>>>>> [IEEE-1588] has defined methods for transporting PTP messages over >>>>>>>> Ethernet and IP networks. [RFC5905] has defined the method of >>>>>>>> transporting NTP messages over IP networks. There is a need to >>>>>>>> transport Timing messages over MPLS networks while supporting the >>>>>>>> Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC) >>>>>>>> functionality in the LER and LSRs in the MPLS network. >>>>>>>> >>>>>>>> There are multiple ways of transporting Timing over MPLS. However, >>>>>>>> there is a requirement to limit the possible encapsulation options to >>>>>>>> simplify the Timing message identification and processing required at >>>>>>>> the port level. >>>>>>>> >>>>>>>> When Timing-awareness is needed, Timing messages should not be >>>>>>>> transported over LSPs or PWs that are carrying customer traffic >>>>>>>> because LSRs perform Label switching based on the top label in the >>>>>>>> stack. >>>>>>>> >>>>>>>> SB> Have you explained why? >>>>>>>> >>>>>>>> To detect Timing messages inside such LSPs require special >>>>>>>> hardware to do deep packet inspection at line rate. Even if such >>>>>>>> hardware exists, the payload can't be deterministically identified by >>>>>>>> LSRs because the payload type is a context of the PW label, and the >>>>>>>> PW label and its context are only known to the Edge routers (PEs/ >>>>>>>> LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, CES, >>>>>>>> etc). Even if one restricts an LSP to only carry Ethernet PWs, the >>>>>>>> LSRs dont have the knowledge of whether PW Control Word (CW) is >>>>>>>> present or not and therefore can not deterministically identify the >>>>>>>> payload. >>>>>>>> >>>>>>>> A generic method is defined in this document that does not require >>>>>>>> deep packet inspection at line rate, and can deterministically >>>>>>>> identify Timing messages. This method can be used to detect Timing >>>>>>>> Messages in both one-step and two-step clock implementations of >>>>>>>> ordinary, boundary and transparent clocks. >>>>>>>> >>>>>>>> SB> Needs a ref and I am sure many MPLS specialists will not understand >>>>>>>> SB> the msg types. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 8] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 4. Timing over MPLS Architecture >>>>>>>> >>>>>>>> Timing messages are exchange between Timing ports on ordinary and >>>>>>>> >>>>>>>> SB> Have you defined a timing port? >>>>>>>> >>>>>>>> boundary clocks. Boundary clocks terminate the Timing messages and >>>>>>>> act as master for other boundary clocks or for slave clocks. End-to- >>>>>>>> End Transparent clocks do not terminate the Timing messages but they >>>>>>>> do modify the contents of the Timing messages as they transit across >>>>>>>> the transparent clock. >>>>>>>> >>>>>>>> Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent Clock >>>>>>>> >>>>>>>> (TC) could be implemented in either LERs or LSRs. >>>>>>>> >>>>>>>> SB> LER and LSR need to be expanded >>>>>>>> >>>>>>>> An example is shown in Figure 1, where the LERs act as Ordinary Clock >>>>>>>> (OC) and are the initiating/terminating point for Timing messages. >>>>>>>> The ingress LER encapsulates the Timing messages in Timing LSP and >>>>>>>> the Egress LER terminates the Timing LSP. The LSRs act as >>>>>>>> Transparent Clock (TC) and just update the Timing field in the Timing >>>>>>>> messages. >>>>>>>> >>>>>>>> >>>>>>>> +--------+ +-------+ +-------+ +-------+ +--------+ >>>>>>>> |Switch, | | | | | | | |Switch, | >>>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Router | >>>>>>>> | | | OC | | TC | | OC | | | >>>>>>>> +--------+ +-------+ +-------+ +-------+ +--------+ >>>>>>>> / \ >>>>>>>> +-------+ / \ +-------+ >>>>>>>> | LER | / \ | LER | >>>>>>>> | Master|---/ \---| Slave | >>>>>>>> | Clock | | Clock | >>>>>>>> +-------+ +-------+ >>>>>>>> >>>>>>>> Figure (1) - Deployment example 1 of timing over MPLS network >>>>>>>> >>>>>>>> Another example is shown in Figure2, where LERs terminate the Timing >>>>>>>> messages received from switch/routers that are outside of the MPLS >>>>>>>> network acting as OC or BC. In this example LERs regenerate the >>>>>>>> clock and initiate timing messages encapsulated in Timing LSP toward >>>>>>>> the MPLS network, while the LSRs act as Transparent Clock (TC) and >>>>>>>> just update the Timing field in the Timing messages, which are >>>>>>>> already encapsulated in Timing LSPs. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 9] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> +--------+ +-------+ +-------+ +-------+ +--------+ >>>>>>>> |Switch, | | | | | | | |Switch, | >>>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Router | >>>>>>>> | OC/BC | | BC | | TC | | BC | | OC/BC | >>>>>>>> +--------+ +-------+ +-------+ +-------+ +--------+ >>>>>>>> >>>>>>>> Figure (2) - Deployment example 2 of timing over MPLS network >>>>>>>> >>>>>>>> >>>>>>>> Another example is shown in Figure 3, where LERs do not terminate the >>>>>>>> Timing messages received from switch/routers that are outside of the >>>>>>>> MPLS network acting as OC, TC or BC. The LERs act as TC and update >>>>>>>> the Timing field in the Timing messages as they transit the LER, >>>>>>>> while encapsulating them in timing LSP. The LSRs also act as >>>>>>>> Transparent Clock (TC) and just update the Timing field in the Timing >>>>>>>> messages which are already encapsulated in Timing LSPs. >>>>>>>> >>>>>>>> +--------+ +-------+ +-------+ +-------+ +--------+ >>>>>>>> |Switch, | | | | | | | |Switch, | >>>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Router | >>>>>>>> |OC/TC/BC| | TC | | TC | | TC | |OC/TC/BC| >>>>>>>> +--------+ +-------+ +-------+ +-------+ +--------+ >>>>>>>> >>>>>>>> Figure (3) - Deployment example 3 of timing over MPLS network >>>>>>>> >>>>>>>> Another example is shown in Figure 4, where LERs and LSRs support >>>>>>>> Boundary Clocks. A single-hop LSP is created between two adjacent >>>>>>>> LSRs engaged in BC operation. Other methods such as PTP transport >>>>>>>> over Ethernet MAY be used for transporting timing messages if the >>>>>>>> link between the two routers is Ethernet. >>>>>>>> >>>>>>>> +--------+ +-------+ +-------+ +-------+ +--------+ >>>>>>>> |Switch, | | | | | | | |Switch, | >>>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Router | >>>>>>>> | OC/BC | | BC | | BC | | BC | | OC/BC | >>>>>>>> +--------+ +-------+ +-------+ +-------+ +--------+ >>>>>>>> >>>>>>>> Figure (4) - Deployment example 3 of timing over MPLS network >>>>>>>> >>>>>>>> An MPLS domain MAY serve multiple customers. In these cases the >>>>> MPLS >>>>>>>> domain (maintained by a service provider) may provide timing services >>>>>>>> to multiple customers, each having their own Timing domain. >>>>>>>> >>>>>>>> The Timing over MPLS architecture assumes full mesh of Timing LSPs >>>>>>>> between all LERs supporting this specification. >>>>>>>> >>>>>>>> SB> Note sure this is right - the salves surely do not need to >>>>>>>> SB> exchange timing amongst themselves >>>>>>>> >>>>>>>> It supports >>>>>>>> Point-to- point (VPWS) and Multipoint (VPLS) services. >>>>>>>> >>>>>>>> SB> What does that mean? You do not carry user data traffic? >>>>>>>> SB> Maybe it's the ordering of the statemnets that is causing >>>>>>>> SB> confusion. >>>>>>>> >>>>>>>> This means >>>>>>>> that a customer may purchase a Point-to-point Timing service between >>>>>>>> two customer sites or a Multipoint Timing service between more than >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 10] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> two customer sites. >>>>>>>> >>>>>>>> The Timing over MPLS architecture supports P2P or P2MP Timing LSPs. >>>>>>>> This means that the Timing Multicast messages such as PTP Multicast >>>>>>>> event messages can be transported over P2MP Timing LSP or be >>>>>>>> replicated and transported over many P2P Timing LSPs. >>>>>>>> >>>>>>>> SB> Note we do not yet have a definition of a P2MP mpls-tp LSP >>>>>>>> SB> nor a P2MP PW, although we are close. >>>>>>>> >>>>>>>> Timing messages, that do not require Time stamping or Correction >>>>>>>> Field update MAY be transported over Timing LSPs to simplify hardware >>>>>>>> and software. >>>>>>>> >>>>>>>> PTP Announce messages that determine the Timing LSP terminating >>>>> point >>>>>>>> behavior such as BC/OC/TC SHOULD be transported over the Timing LSP >>>>>>>> to simplify hardware and software. >>>>>>>> >>>>>>>> SB> have you defined and referenced PTP announce msgs? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 11] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 5. Dedicated LSPs for Timing messages >>>>>>>> >>>>>>>> Many methods have been considered for identifying the Timing >>>>> messages >>>>>>>> when they are encapsulated in MPLS such as using GAL/G-ACH or a new >>>>>>>> reserved label. These methods were not attractive since they either >>>>>>>> required deep packet inspection at line rate in the intermediate LSRs >>>>>>>> or they required use of a scarce new reserved label. Also one of the >>>>>>>> goals was to reuse existing OAM mechanisms. >>>>>>>> >>>>>>>> SB> RLs = SPLs are not so rare now. In any case needs a ref. >>>>>>>> >>>>>>>> The method defined in this document can be used by LER and LSRs to >>>>>>>> identify Timing messages in MPLS tunnels by just looking at the top >>>>>>>> label in the MPLS label stack, which only carry Timing messages as >>>>>>>> well as OAM, but not data plane client traffic. >>>>>>>> >>>>>>>> Compliant implementations MUST use dedicated LSPs to carry Timing >>>>>>>> messages over MPLS. >>>>>>>> >>>>>>>> SB> I think that we need a definition of the properies of these LSPs >>>>>>>> >>>>>>>> These LSPs are herein referred to as "Timing >>>>>>>> LSPs" and the labels associated with these LSPs as "Timing LSP >>>>>>>> labels". The Timing LSPs that runs between Ingress and Egress LERs >>>>>>>> MUST be co-routed. Alternatively, a single bidirectional co-routed >>>>>>>> LSP can be used. >>>>>>>> >>>>>>>> SB> I though that you said you could use M2MP LSPs - these are not >>>>>>>> SB> bidirectional. >>>>>>>> >>>>>>>> Co-routing of the two directions is required to limit the difference >>>>>>>> in the delays in the Master clock to Slave clock direction compared >>>>>>>> to the Slave clock to Master clock direction. The Timing LSP MAY be >>>>>>>> MPLS/MPLS-TP LSP. >>>>>>>> >>>>>>>> The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS. >>>>>>>> New Extensions to RSVP-TE/GMPLS TLVs are required; however they are >>>>>>>> outside the scope of this document. >>>>>>>> >>>>>>>> The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such as >>>>>>>> BFD and LSP Ping but the LSP data plane client plane traffic MUST be >>>>>>>> Timing packets only. >>>>>>>> >>>>>>>> SB> Why? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 12] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 6. Timing over LSP Encapsulation >>>>>>>> >>>>>>>> The encapsulations is not LSP is it? >>>>>>>> >>>>>>>> This document defines two methods for carrying Timing messages over >>>>>>>> MPLS. The first method is carrying UDP/IP encapsulated Timing >>>>>>>> messages over Timing LSPs, and the second method, is carrying >>>>>>>> Ethernet encapsulated Timing messages over Ethernet PWs inside >>>>> Timing >>>>>>>> LSPs. >>>>>>>> >>>>>>>> 6.1. Timing over UDP/IP over MPLS Encapsulation >>>>>>>> >>>>>>>> The simplest method of transporting Timing messages over MPLS is to >>>>>>>> encapsulate Timing PDUs in UDP/IP and then encapsulate them in >>>>> Timing >>>>>>>> LSP. This format is shown in Figure 4. >>>>>>>> >>>>>>>> >>>>>>>> +----------------------+ >>>>>>>> | Timing LSP Label | >>>>>>>> +----------------------+ >>>>>>>> | IPv4/6 | >>>>>>>> +----------------------+ >>>>>>>> | UDP | >>>>>>>> +----------------------+ >>>>>>>> | Timing PDU | >>>>>>>> +----------------------+ >>>>>>>> >>>>>>>> Figure (4) - Timing over UDP/IP over MPLS Encapsulation >>>>>>>> >>>>>>>> >>>>>>>> This encapsulation is very simple and is useful when the network >>>>>>>> between Timing Master Clock and Slave Clock is MPLS network. >>>>>>>> >>>>>>>> SB> Simple is a judgement call >>>>>>>> >>>>>>>> In order for an LER/LSR to process Timing messages, the Timing LSP >>>>>>>> Label must be at the top label of the label stack. The LER/LSR MUST >>>>>>>> know that the Timing LSP Label is used for carrying Timing messages. >>>>>>>> This can be accomplished via static configuration or via RSVP-TE >>>>>>>> signaling. >>>>>>>> >>>>>>>> The UDP/IP encapsulation of PTP MUST follow Annex D and E of >>>>>>>> [IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow >>>>>>>> [RFC5905]. >>>>>>>> >>>>>>>> 6.2. Timing over PW Encapsulation >>>>>>>> >>>>>>>> Another method of transporting Timing over MPLS networks is by >>>>>>>> encapsulating Timing PDUs in PW which in turn is transported over >>>>>>>> Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448], >>>>>>>> shown in Fig 5(A) MUST be used and the Ethernet encapsulation of PTP >>>>>>>> MUST follow Annex F of [IEEE-1588]. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 13] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> The RAW mode or Tagged mode defined in [RFC4448] MAY be used and >>>>> the >>>>>>>> Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The >>>>>>>> Timing over PW encapsulation MUST use the Control Word (CW) as >>>>>>>> specified in [RFC4448] to ensure proper detection of PTP messages >>>>>>>> inside the MPLS packets for Timing over LSP and Timing over PW >>>>>>>> encapsulation. >>>>>>>> >>>>>>>> SB> That needs explanation >>>>>>>> >>>>>>>> The use of Sequence Number in the CW is optional. >>>>>>>> >>>>>>>> SB> Given that s/n are never in practice deployed, you could probably >>>>>>>> SB> simplify things by sayig that they are not used. >>>>>>>> >>>>>>>> Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over >>>>> PW >>>>>>>> (the IP PW discussed in [RFC4447]) shown in Fig 5(B). >>>>>>>> >>>>>>>> +----------------+ +----------------+ >>>>>>>> |Timing LSP Label| |Timing LSP Label| >>>>>>>> +----------------+ +----------------+ >>>>>>>> | PW Label | | PW Label | >>>>>>>> +----------------+ +----------------+ >>>>>>>> | Control Word | | IP | >>>>>>>> +----------------+ +----------------+ >>>>>>>> | Ethernet | | UDP | >>>>>>>> | Header | +----------------+ >>>>>>>> +----------------+ | Timing PDU | >>>>>>>> |S-VLAN(Optional)| | | >>>>>>>> +----------------+ +----------------+ >>>>>>>> |C-VLAN(Optional)| (B) >>>>>>>> +----------------+ >>>>>>>> | Timing PDU | >>>>>>>> | | >>>>>>>> +----------------+ >>>>>>>> (A) >>>>>>>> >>>>>>>> Figure (5) - Timing over PW Encapsulations >>>>>>>> >>>>>>>> In order for an LSR to process PTP messages, the top label of the >>>>>>>> label stack (the Tunnel Label) MUST be a Timing label. >>>>>>>> >>>>>>>> S> You said that before. >>>>>>>> >>>>>>>> 6.3. Other Timing Encapsulation methods >>>>>>>> >>>>>>>> In future other timing encapsulation methods may be introduced, such >>>>>>>> as a new shim header after the Bottom of Stack to carry the Timing >>>>>>>> information. Such new encapsulations are outside the scope of this >>>>>>>> document. >>>>>>>> >>>>>>>> >>>>>>>> SB> Taking a pure MPLS pov, you can simplify a lot of the text >>>>>>>> SB> out of the definition of the LSP >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 14] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> SB> I think we need a section on LSP processing >>>>>>>> >>>>>>>> 7. Timing message Processing >>>>>>>> >>>>>>>> Each Timing protocol such as PTP and NTP, define their set of Timing >>>>>>>> messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, >>>>>>>> FOLLOW_UP, etc messages. >>>>>>>> >>>>>>>> Some of the Timing messages require time stamping or correction field >>>>>>>> update at port level and some dont. It is the job of the LER/LSR to >>>>>>>> parse the timing message and find out the type of the Timing message >>>>>>>> and decide whether and how to Time- stamp it (e.g., BC) or update >>>>>>>> correction field(e.g., TC). >>>>>>>> >>>>>>>> >>>>>>>> SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing >>>>>>>> SB> function rather than the LER? >>>>>>>> >>>>>>>> For example the following PTP messages (called Event messages) >>>>>>>> require time-stamping or correction field update: >>>>>>>> >>>>>>>> o SYNC >>>>>>>> >>>>>>>> o DELAY_REQ (Delay Request) >>>>>>>> >>>>>>>> o PDELAY_REQ (Peer Delay Request) >>>>>>>> >>>>>>>> o PDELAY_RESP (Peer Delay Response) >>>>>>>> >>>>>>>> SYNC and DELAY_REQ are exchanged between Master Clock and Slave >>>>> Clock >>>>>>>> and MUST be transported over PTP LSPs. PDELAY_REQ and >>>>> PDELAY_RESP >>>>>>>> are exchanged between adjacent PTP clocks (i.e. Master, Slave, >>>>>>>> Boundary, or Transparent) and SHOULD be transported over single hop >>>>>>>> PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP, >>>>>>>> and PDELAY_RESP_FOLLOW_UP messages MUST also be transported >>>>> over >>>>>>>> the >>>>>>>> PTP LSPs. >>>>>>>> >>>>>>>> For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be >>>>>>>> transported over two PTP LSPs that are in opposite directions. These >>>>>>>> PTP LSPs, which are in opposite directions MUST be congruent and co- >>>>>>>> routed. Alternatively, a single bidirectional co-routed LSP can be >>>>>>>> used. >>>>>>>> >>>>>>>> Except as indicated above for the two-step PTP clocks, Non-Event PTP >>>>>>>> message types do not need to be processed by intermediate routers. >>>>>>>> These message types MAY be carried in PTP Tunnel LSPs. >>>>>>>> >>>>>>>> SB> Are you saying that a timing P router has to be msg type sensitive? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 15] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 8. Protection and Redundancy >>>>>>>> >>>>>>>> >>>>>>>> SB> This is a bit of a jump - I don't know how the LSP itself works yet! >>>>>>>> >>>>>>>> In order to ensure continuous uninterrupted operation of slave >>>>>>>> clocks, usually as a general practice, slave clocks (or ports) track >>>>>>>> redundant master clocks. >>>>>>>> >>>>>>>> It is the responsibility of the network operator to ensure that >>>>>>>> physically disjoint Timing LSPs are established between a slave clock >>>>>>>> (or port) and redundant master clocks (or ports). >>>>>>>> >>>>>>>> When a slave clock (or port) listens to redundant master clocks or >>>>>>>> ports, any prolonged Timing LSP outage will trigger the slave clock >>>>>>>> or port to switch to a redundant master clock or port. >>>>>>>> >>>>>>>> LSP/PW protection such as Linear protection Switching (1:1, 1+1), >>>>>>>> Ring protection switching or MPLS Fast Reroute (FRR) generally switch >>>>>>>> alternative path that usually cause a change in delay, which if >>>>>>>> undetected by slave clock can reduce accuracy of the slave clock. >>>>>>>> >>>>>>>> Therefore protection switching MAY be used, as long as phase jumps >>>>>>>> upon switchover due to differences in path latency are detected and >>>>>>>> compensated for (such compensation not being required if BCs or peer- >>>>>>>> peer TCs are used throughout). >>>>>>>> >>>>>>>> Note that any protection or reroute mechanism that adds additional >>>>>>>> MPLS label to the label stack, such as Facility Backup Fast Reroute, >>>>>>>> MUST ensure that the pushed label is also a Timing Label to ensure >>>>>>>> recognition of the MPLS frame as containing Timing messages, as it >>>>>>>> transits the backup path. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 16] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 9. ECMP >>>>>>>> >>>>>>>> To ensure the optimal operation of slave clocks and avoid error >>>>>>>> introduced by forward and reverse path delay asymmetry, the physical >>>>>>>> path for Timing messages from master clock to slave Clock and vice >>>>>>>> versa must be the same for all Event Timing messages listed in >>>>>>>> section 7. >>>>>>>> >>>>>>>> Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost >>>>>>>> Multipath). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 17] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 10. PHP >>>>>>>> >>>>>>>> To ensure that the label on the top of the label stack is the Timing >>>>>>>> LSP Label, PHP MUST not be used. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 18] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 11. Entropy >>>>>>>> >>>>>>>> To ensure all Timing messages in a Timing LSP take the same path, >>>>>>>> Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and >>>>>>>> Entropy Label MUST NOT be used for the PWs that are carried inside >>>>>>>> Timing LSP [RFC6391]. >>>>>>>> >>>>>>>> SB> This is incorrect - you mean that all msgs of the same timing >>>>>>>> SB> flow need to have the same EL value. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 19] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 12. OAM, Control and Management >>>>>>>> >>>>>>>> In order to monitor Timing LSPs and their encapsulated PWs, they MUST >>>>>>>> be able to carry OAM and management messages. These management >>>>>>>> messages MUST be differentiated from Timing messages via already >>>>>>>> defined IETF methods. >>>>>>>> >>>>>>>> For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY run >>>>>>>> over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These >>>>>>>> Management protocols can easily be identified by the UDP Destination >>>>>>>> Port number or by GAL/G-ACH respectively. >>>>>>>> >>>>>>>> Also BFD, LSP-Ping and other management messages MAY run over the >>>>> PWs >>>>>>>> encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3 or >>>>>>>> 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is going >>>>>>>> to be deprecated by IETF). In this case G-ACH, PW label (TTL=1) or >>>>>>>> GAL-ACH are used to identify such management messages. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 20] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 13. QoS Considerations >>>>>>>> >>>>>>>> In network deployments where not every LSR/LER is Timing-aware, it is >>>>>>>> important to reduce the impact of the non-Timing-aware LSR/LERs on >>>>>>>> the timing recovery in the slave clock. The Timing messages are time >>>>>>>> critical and must be treated with the highest priority. Therefore >>>>>>>> Timing over MPLS messages must be treated with the highest priority >>>>>>>> in the routers. This can be achieved by proper setup of Timing LSPs. >>>>>>>> >>>>>>>> It is recommended that the Timing LSPs are setup or configured >>>>>>>> properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC2697] >>>>>>>> for drop eligibility. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 21] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 14. FCS and Checksum Recalculation >>>>>>>> >>>>>>>> When time-stamp generation and timing packet adjustment is performed >>>>>>>> near the physical port hardware, the process MUST include >>>>>>>> recalculation of the Ethernet FCS. >>>>>>>> >>>>>>>> SB> The above is confusing - an LSR always recomputes the link layer >>>>>>>> SB> CRC which may or may not be Ethernet. >>>>>>>> >>>>>>>> Also FCS retention for the >>>>>>>> payload Ethernet described in [RFC4720] MUST NOT be used. >>>>>>>> >>>>>>>> For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum >>>>>>>> may be required as per UDP transport standards. >>>>>>>> >>>>>>>> SB> You really need to be working on getting the IPv6 C?S computation >>>>>>>> SB> removed from PTP msgs. >>>>>>>> >>>>>>>> When UDP checksum is used, each Timing-aware LER/LSR must either >>>>>>>> incrementally update the UDP checksum after Time stamping or >>>>>>>> Correction Field update or verify the UDP checksum on reception from >>>>>>>> upstream and recalculate the checksum completely on transmission to >>>>>>>> downstream node after Time stamping or Correction Field update. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 22] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 15. Behavior of LER/LSR >>>>>>>> >>>>>>>> Timing-capable/aware LERs and LSRs are routers that have one or more >>>>>>>> >>>>>>>> SB> You mean physical interfaces? >>>>>>>> >>>>>>>> interfaces that can perform Timing operations (OC/BC/TC) on Timing >>>>>>>> packets and are configured to do so. Timing-capable/aware LERs and >>>>>>>> LSRs can advertise their Timing-capability per-interface via control >>>>>>>> plane such as OSPF or IS-IS. >>>>>>>> SB> ISIS and OSPF are routing protocols. >>>>>>>> >>>>>>>> The Timing-capable/aware LERs can then >>>>>>>> signals Timing LSPs via RSVP-TE signaling. Alternatively the Timing >>>>>>>> capability of LER and LSRs may be configured in a centralized >>>>>>>> controller and the Timing LSP may be setup using manual configuration >>>>>>>> or other methods such as SDN. >>>>>>>> >>>>>>>> SB> it can also be configured individually rather then through >>>>>>>> SB> a cebtral controllwe >>>>>>>> >>>>>>>> 15.1. Behavior of Timing-capable/aware LER >>>>>>>> >>>>>>>> When a Timing-capable/aware LER behaves as a Transparent clock and >>>>>>>> receives a Timing message from a Timing-capable/aware non-MPLS >>>>>>>> interface, the LER updates the Correction Field (CF) and encapsulates >>>>>>>> and forwards the timing message over previously established Timing >>>>>>>> LSP. >>>>>>>> >>>>>>>> SB> You need to call out the details so that people properly >>>>>>>> SB> understand the definition of the new LSP. >>>>>>>> >>>>>>>> Also when a Timing message is received from a Timing-capable/ >>>>>>>> aware MPLS interface, LER updates the Correction Filed (CF) and >>>>>>>> decapsulates the MPLS encapsulation and forwards the timing message >>>>>>>> to a non-MPLS interface. >>>>>>>> >>>>>>>> When a Timing-capable/aware LER behaves as a Boundary clock and >>>>>>>> receives a Timing message from a Timing-capable/aware non MPLS >>>>>>>> interface, the LER Timestamps the Timing packet and sends it to the >>>>>>>> LERs Boundary clock processing module. Also when a Timing message is >>>>>>>> received from a Timing- capable/aware MPLS interface, the LER >>>>>>>> Timestamps the Timing packet and sends it to the LERs Boundary clock >>>>>>>> processing module. >>>>>>>> >>>>>>>> When a Timing-capable/aware LER behaves as an Ordinary Clock toward >>>>>>>> the MPLS network, and receives a Timing message from a Timing- >>>>>>>> capable/aware MPLS interface, the LER Timestamps the Timing packet >>>>>>>> and sends it to the LERs Ordinary clock processing module. >>>>>>>> >>>>>>>> 15.2. Behavior of Timing-capable/aware LSR >>>>>>>> >>>>>>>> When a Timing-capable/aware LSR behaves as a Transparent clock and >>>>>>>> receives a Timing message from a Timing-capable/aware MPLS >>>>> interface, >>>>>>>> The LSR updates the Correction Filed (CF) and forwards the timing >>>>>>>> message over another MPLS interface. >>>>>>>> >>>>>>>> When a Timing-capable/aware LSR behaves as a Boundary clock and >>>>>>>> receives a Timing message from a Timing-capable/aware MPLS >>>>> interface. >>>>>>>> The LSR performs the functions of a Boundary Clock in terminating the >>>>>>>> received Timing message and re-generating a new timing message over >>>>>>>> another (or the same) MPLS interface. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 23] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 15.3. Behavior of non-Timing-capable/aware LSR >>>>>>>> >>>>>>>> It is most beneficial when all LSRs in the path of a Timing LSP be >>>>>>>> timing-Capable/aware LSRs. This would ensure the highest quality >>>>>>>> time and clock synchronization by Timing Slave Clocks. However, this >>>>>>>> specification does not mandate that all LSRs in path of a Timing LSP >>>>>>>> be Timing- capable/aware. >>>>>>>> >>>>>>>> Non-Timing-capable/aware LSRs just switch the packets encapsulated in >>>>>>>> Timing LSPs and dont perform any Timing operation (TC or BC). >>>>>>>> However as explained in QoS section the Timing over MPLS packets >>>>> MUST >>>>>>>> be still be treated with the highest priority based on their Traffic >>>>>>>> Class (TC) marking. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 24] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 16. Other considerations >>>>>>>> >>>>>>>> [IEEE-1588] defines an optional peer-to-peer Transparent clocking >>>>>>>> that requires peer delay measurement between two adjacent Timing- >>>>>>>> capable/ aware routers/switches. Peer delay measurement messages >>>>>>>> need to be time stamped and terminated by the Timing-capable/aware >>>>>>>> routers/ switches. This means that two adjacent LSRs may be engaged >>>>>>>> in a peer delay measurement. >>>>>>>> >>>>>>>> For transporting such peer delay measurement messages a single-hop >>>>>>>> LSP SHOULD to be created between the two adjacent LSRs engaged in >>>>>>>> peer delay measurement to carry peer delay measurement messages. >>>>>>>> Other methods such as PTP transport over Ethernet MAY be used for >>>>>>>> transporting peer delay measurement messages if the link between the >>>>>>>> two routers is Ethernet. >>>>>>>> >>>>>>>> In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ ware >>>>>>>> routers/switches MUST maintain a list of all the neighbors it needs >>>>>>>> to send a PDelay_Req to, where each neighbor corresponds to a timing >>>>>>>> LSP. >>>>>>>> >>>>>>>> The use of Explicit Null Label (Label= 0 or 2) is acceptable as long >>>>>>>> as either the Explicit Null label is the bottom of stack label >>>>>>>> (applicable only to UDP/IP encapsulation) or the label below the >>>>>>>> Explicit Null label is a PTP label. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 25] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 17. Security Considerations >>>>>>>> >>>>>>>> MPLS PW security considerations in general are discussed in [RFC3985] >>>>>>>> and [RFC4447],and those considerations also apply to this document. >>>>>>>> >>>>>>>> An experimental security protocol is defined in [IEEE-1588].The PTP >>>>>>>> security extension and protocol provides group source authentication, >>>>>>>> message integrity, and replay attack protection for PTP messages. >>>>>>>> >>>>>>>> When the MPLS network (provider network) serves multiple customers, >>>>>>>> it is important to maintain and process each customers clock and >>>>>>>> Timing messages separately from other customers to ensure there is no >>>>>>>> cross- customer effect. For example if an LER BC is synchronized to >>>>>>>> a specific grandmaster, belonging to customer A, then the LER MUST >>>>>>>> use that BC clock only for customer A to ensure that customer A >>>>>>>> cannot attack other customers by manipulating its time. >>>>>>>> >>>>>>>> Timing messages MAY be encrypted or authenticated, provided that the >>>>>>>> LERs/LSRs that are Timing capable/aware can authenticate/ decrypt the >>>>>>>> timing messages. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 26] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 18. Acknowledgements >>>>>>>> >>>>>>>> The authors would like to thank Ron Cohen, Yaakov Stein, Tal Mizrahi, >>>>>>>> Stefano Ruffini, Peter Meyer, and other members of IETF for reviewing >>>>>>>> and providing feedback on this draft. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 27] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 19. IANA Considerations >>>>>>>> >>>>>>>> There are no IANA requirements in this specification. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 28] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 20. References >>>>>>>> >>>>>>>> 20.1. Normative References >>>>>>>> >>>>>>>> [IEEE-1588] >>>>>>>> IEEE 1588-2008, "IEEE Standard for a Precision Clock >>>>>>>> Synchronization Protocol for Networked Measurement and >>>>>>>> Control Systems". >>>>>>>> >>>>>>>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >>>>>>>> Requirement Levels", BCP 14, RFC 2119, March 1997. >>>>>>>> >>>>>>>> [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- >>>>>>>> Edge (PWE3) Architecture", RFC 3985, March 2005. >>>>>>>> >>>>>>>> [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery >>>>>>>> Proxies (ND Proxy)", RFC 4389, April 2006. >>>>>>>> >>>>>>>> [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. >>>>>>>> Heron, "Pseudowire Setup and Maintenance Using the Label >>>>>>>> Distribution Protocol (LDP)", RFC 4447, April 2006. >>>>>>>> >>>>>>>> [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, >>>>>>>> "Encapsulation Methods for Transport of Ethernet over MPLS >>>>>>>> Networks", RFC 4448, April 2006. >>>>>>>> >>>>>>>> [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire >>>>>>>> Emulation Edge-to-Edge (PWE3) Frame Check Sequence >>>>>>>> Retention", RFC 4720, November 2006. >>>>>>>> >>>>>>>> [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit >>>>>>>> Connectivity Verification (VCCV): A Control Channel for >>>>>>>> Pseudowires", RFC 5085, December 2007. >>>>>>>> >>>>>>>> [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection >>>>>>>> (BFD)", RFC 5880, June 2010. >>>>>>>> >>>>>>>> [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, >>>>>>>> "Bidirectional Forwarding Detection (BFD) for MPLS Label >>>>>>>> Switched Paths (LSPs)", RFC 5884, June 2010. >>>>>>>> >>>>>>>> 20.2. Informative References >>>>>>>> >>>>>>>> [I-D.ietf-pwe3-fat-pw] >>>>>>>> Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, >>>>>>>> J., and S. Amante, "Flow Aware Transport of Pseudowires >>>>>>>> over an MPLS Packet Switched Network", >>>>>>>> draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 29] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate >>>>>>>> system routeing information exchange protocol for use in >>>>>>>> conjunction with the Protocol for providing the >>>>>>>> Connectionless-mode Network Service (ISO 8473)". >>>>>>>> >>>>>>>> [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and >>>>>>>> dual environments", RFC 1195, December 1990. >>>>>>>> >>>>>>>> [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. >>>>>>>> >>>>>>>> [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color >>>>>>>> Marker", RFC 2697, September 1999. >>>>>>>> >>>>>>>> [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, >>>>>>>> J., Courtney, W., Davari, S., Firoiu, V., and D. >>>>>>>> Stiliadis, "An Expedited Forwarding PHB (Per-Hop >>>>>>>> Behavior)", RFC 3246, March 2002. >>>>>>>> >>>>>>>> [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering >>>>>>>> (TE) Extensions to OSPF Version 2", RFC 3630, >>>>>>>> September 2003. >>>>>>>> >>>>>>>> [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate >>>>>>>> System (IS-IS) Extensions for Traffic Engineering (TE)", >>>>>>>> RFC 3784, June 2004. >>>>>>>> >>>>>>>> [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. >>>>>>>> Shaffer, "Extensions to OSPF for Advertising Optional >>>>>>>> Router Capabilities", RFC 4970, July 2007. >>>>>>>> >>>>>>>> [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate >>>>>>>> System to Intermediate System (IS-IS) Extensions for >>>>>>>> Advertising Router Information", RFC 4971, July 2007. >>>>>>>> >>>>>>>> [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi >>>>>>>> Topology (MT) Routing in Intermediate System to >>>>>>>> Intermediate Systems (IS-ISs)", RFC 5120, February 2008. >>>>>>>> >>>>>>>> [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic >>>>>>>> Engineering", RFC 5305, October 2008. >>>>>>>> >>>>>>>> [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, >>>>>>>> "Traffic Engineering Extensions to OSPF Version 3", >>>>>>>> RFC 5329, September 2008. >>>>>>>> >>>>>>>> [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF >>>>>>>> for IPv6", RFC 5340, July 2008. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 30] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network >>>>>>>> Time Protocol Version 4: Protocol and Algorithms >>>>>>>> Specification", RFC 5905, June 2010. >>>>>>>> >>>>>>>> [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, >>>>>>>> J., and S. Amante, "Flow-Aware Transport of Pseudowires >>>>>>>> over an MPLS Packet Switched Network", RFC 6391, >>>>>>>> November 2011. >>>>>>>> >>>>>>>> [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and >>>>>>>> L. Yong, "The Use of Entropy Labels in MPLS Forwarding", >>>>>>>> RFC 6790, November 2012. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 31] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 1. Routing extensions for Timing-aware Routers >>>>>>>> >>>>>>>> MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and >>>>>>>> IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE) >>>>>>>> link information used for constraint-based routing. >>>>>>>> >>>>>>>> Indeed, it is useful to advertise data plane TE router link >>>>>>>> capabilities, such as the capability for a router to be Timing-aware. >>>>>>>> This capability MUST then be taken into account during path >>>>>>>> computation to prefer or even require links that advertise themselves >>>>>>>> as Timing-aware. In this way the path can ensure the entry and exit >>>>>>>> points into the LERs and, if desired, the links into the LSRs are >>>>>>>> able to perform port based time-stamping thus minimizing their impact >>>>>>>> on the performance of the slave clock. >>>>>>>> >>>>>>>> extensions are required to OSPF and IS-IS in order to advertise >>>>>>>> Timing-aware capabilities of a link. Such extensions are outside the >>>>>>>> scope of this document; however such extension SHOULD be able to >>>>>>>> signal the following information per Router Link: >>>>>>>> >>>>>>>> o Capable of processing PTP, NTP or other Timing flows >>>>>>>> >>>>>>>> o Capable of performing Transparent Clock operation >>>>>>>> >>>>>>>> o Capable of performing Boundary Clock operation >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 32] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> 2. Signaling Extensions for Creating Timing LSPs >>>>>>>> >>>>>>>> RSVP-TE signaling MAY be used to setup the timing LSPs. When RSVP-TE >>>>>>>> is used to setup Timing LSPs, some information that indicates that >>>>>>>> the LSP is carrying Timing flows MUST be included in the new >>>>>>>> Extensions to RSVP-TE: >>>>>>>> >>>>>>>> The following information MAY also be included in the new Extensions >>>>>>>> to RSVP-TE: >>>>>>>> >>>>>>>> o Offset from Bottom of Stack (BoS) to the start of the Time-stamp >>>>>>>> field >>>>>>>> >>>>>>>> o Number of VLANs in case of PW encapsulation >>>>>>>> >>>>>>>> o Timestamp field Type >>>>>>>> >>>>>>>> * Correction Field, Timestamp >>>>>>>> >>>>>>>> o Timestamp Field format >>>>>>>> >>>>>>>> * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit >>>>>>>> NTP, etc. >>>>>>>> >>>>>>>> Note that in case the above optional information is signaled with >>>>>>>> RSVP-TE for a Timing LSP, all the Timing packets carried in that LSP >>>>>>>> must have the same signaled characteristics. For example if >>>>>>>> Timestamp format is signaled as 64-bit PTPv1, then all Timing packets >>>>>>>> must use 64-bit PTPv1 time-stamp. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 33] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> Authors' Addresses >>>>>>>> >>>>>>>> Shahram Davari >>>>>>>> Broadcom Corp. >>>>>>>> San Jose, CA 95134 >>>>>>>> USA >>>>>>>> >>>>>>>> Email: davari@broadcom.com >>>>>>>> >>>>>>>> >>>>>>>> Amit Oren >>>>>>>> Broadcom Corp. >>>>>>>> San Jose, CA 95134 >>>>>>>> USA >>>>>>>> >>>>>>>> Email: amito@broadcom.com >>>>>>>> >>>>>>>> >>>>>>>> Manav Bhatia >>>>>>>> Alcatel-Lucent >>>>>>>> Bangalore, >>>>>>>> India >>>>>>>> >>>>>>>> Email: manav.bhatia@alcatel-lucent.com >>>>>>>> >>>>>>>> >>>>>>>> Peter Roberts >>>>>>>> Alcatel-Lucent >>>>>>>> Kanata, >>>>>>>> Canada >>>>>>>> >>>>>>>> Email: peter.roberts@alcatel-lucent.com >>>>>>>> >>>>>>>> >>>>>>>> Laurent Montini >>>>>>>> Cisco Systems >>>>>>>> San Jose CA >>>>>>>> USA >>>>>>>> >>>>>>>> Email: lmontini@cisco.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 34] >>>>>>>> Internet-Draft Transporting Timing over MPLS June 2013 >>>>>>>> >>>>>>>> >>>>>>>> Luca >>>>>>>> Cisco Systems >>>>>>>> San Jose CA >>>>>>>> USA >>>>>>>> >>>>>>>> Email: lmartini@cisco.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Davari, et al. Expires December 17, 2013 [Page 35] >>>>>>>> -- >>>>>>>> For corporate legal information go to: >>>>>>>> >>>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> TICTOC mailing list >>>>>>>> TICTOC@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/tictoc >>>>>>> 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 >>>>>> . >>>>> -- >>>>> For corporate legal information go to: >>>>> >>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>> >>>>> _______________________________________________ >>>>> TICTOC mailing list >>>>> TICTOC@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tictoc >>>>> >>>>> >>>>> _______________________________________________ >>>>> TICTOC mailing list >>>>> TICTOC@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tictoc >>>> 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. >>> . >> >> -- >> For corporate legal information go to: >> >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> 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. >> > 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. > > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From davarish@yahoo.com Wed Aug 21 07:19:15 2013 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 BC5D311E8217 for ; Wed, 21 Aug 2013 07:19:15 -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=[BAYES_00=-2.599, 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 iYzGCvDxLb3H for ; Wed, 21 Aug 2013 07:19:10 -0700 (PDT) Received: from nm15-vm6.bullet.mail.gq1.yahoo.com (nm15-vm6.bullet.mail.gq1.yahoo.com [98.137.176.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9281211E80F1 for ; Wed, 21 Aug 2013 07:19:10 -0700 (PDT) Received: from [98.137.12.58] by nm15.bullet.mail.gq1.yahoo.com with NNFMP; 21 Aug 2013 14:19:09 -0000 Received: from [208.71.42.198] by tm3.bullet.mail.gq1.yahoo.com with NNFMP; 21 Aug 2013 14:19:09 -0000 Received: from [127.0.0.1] by smtp209.mail.gq1.yahoo.com with NNFMP; 21 Aug 2013 14:19:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1377094749; bh=+/XGrO2Q9iYkcmgb1SavajMGa3p+IyREdHqZe0OCrw8=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=uiM0MS1zDN2FtQMy4IpOiwDybLPk+tnDsFpa/UfTX+j0SFDGzvOfEapGJQB39Nws1Of0b9SPfy8zpzdHBRU/TR9ORwSRHWsfoGa/wm0M6uL6fs3cQumVN+C7TjB8YPAMSP3r/LrtzfQElDzBg3inw2XkpbASrGJNurtG3Zb5aeg= X-Yahoo-Newman-Id: 850883.41072.bm@smtp209.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: .vQ2kHUVM1lVpRyW5gDOMnXQYbULYfgOP9MGF75ObXXAiHt Zncy26HZL.EmeJvr2j8s_31zyhif6RJYoQLJAMC4rbevGQOs0YpyN1.wi4Hu 0ULC5tMX2MYVfX8iPv01LL4QviubYpLe0CdOyZc9EFWrDv2Nh20WrTHq5FXo 9xw03PH8Et6.cc6Qdd4Dx0XjpVCgcBvI4afMgEMRZIvjEJF1q4y1FJQzKJ8B y_sO.cCp.wMM8dw70GgaAkbltIqDyOBk53y6jQuY4cERRntvet_D935OT9mY Y.0IKyQC_NjZDLOOpGul5lBOgsXwVuheBagwv2_tl35V145yFITn5acSfXon xhudT8jKXOw.vdhRAyGxW0LhxX9Vvf6BLqL7beQMcTiisLorCqgmiV95S6L_ jhP3Og0T.D_3_7xxeBq9hCABqOXCK4MgWJksGpuW24U0.JCSnNPq9YECadqu 0CcnbZ98Yna_pA0xPDiz0eJMoJbvnA2BBsmQ.stOwxNU_Ps2ukM6AJPqci.6 xJ8OSy9gsuDkfRfMWEWWIEy0V3lquwXiFps6GG6PhRqjCaP5zZtK_KW2z3Pd VDCPI_4g- X-Yahoo-SMTP: ygPrP9CswBCWPbPtKJlJyLY0KMlg X-Rocket-Received: from [192.168.0.103] (davarish@98.248.42.143 with ) by smtp209.mail.gq1.yahoo.com with SMTP; 21 Aug 2013 07:19:09 -0700 PDT References: <51FB7543.801@cisco.com> <51FF7068.9080600@cisco.com> <4A6CE49E6084B141B15C0713B8993F281BEC731A@SJEXCHMB12.corp.ad.broadcom.com> <52139903.8040801@cisco.com> <52149A2D.3050109@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <52149A2D.3050109@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5ADB2697-BC53-427A-82DB-013B89029343@yahoo.com> X-Mailer: iPhone Mail (10A403) From: "S. Davari" Date: Wed, 21 Aug 2013 07:19:02 -0700 To: "stbryant@cisco.com" Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] Comments on draft-ietf-tictoc-1588overmpls 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, 21 Aug 2013 14:19:15 -0000 Hi Stewart, Your proposal does tunneling between timing aware nodes but I guess it stitc= hes multiple of those tunnels to create and end-2-end connection. Right? Sasha's BoS proposal seems simpler, since it requires a single end-2-end LSP= .=20 Regards, Shahram On Aug 21, 2013, at 3:45 AM, Stewart Bryant wrote: > Sasha >=20 > Note that if the next hop understands the alert, you can put the alert lab= el at the ToS. >=20 > If it does not understand, you would want to tunnel through it and hence t= here would be a label on top or the alert label. >=20 > Shahram, there seems to be some confusion about stitching vs hierarchy, an= d I have been proposing hierarchy to step over the nodes that are unable to u= nderstand the alert label. >=20 > Stewart >=20 >=20 >=20 > On 20/08/2013 19:51, Alexander Vainshtein wrote: >> Shahram, >> No I am not proposing anything of the kind. >>=20 >> At the MPLS data plane level the only the head-end and the tail-end LERs h= ave to be aware of the BoS Timing Alert labels. Transit LSRs simply will ign= ore them. >>=20 >> At the on-path assistance level each transit LSR (and the tail-end LER) c= an do one of the following: >> - It may ignore the Timing Alert label at the BoS and just forward the pa= cket based the labels at the top of the stack. >> - It may identify the packet as a timing one based on the Timing Alert la= bel at the bottom of the label stack, and perform the required operations. T= he result of these operations will be stored in the "timing shim header" and= not in the packet itself. (E.g., an E2E TC clock would note the packet resi= dence time and add it to the value already carried in the shim header). >>=20 >> Non-timing packets would not have the Timing Alert label at the BoS and h= ence would travel thru he LSP travel along the LSP in the usual way. >>=20 >> The tail-end LER would take the reception timestamp and forward this time= stamp, the protocol packet and the shim header to the entity that processes t= he appropriate timing distribution protocol based on the Timing Alert label.= >>=20 >> Hopefully this clarifies my proposal. My gut feeling is that similar idea= s have been proposed by many people earlier... >>=20 >> Regards, >> Sasha >>=20 >>=20 >> ________________________________________ >> From: S. Davari [davarish@yahoo.com] >> Sent: Tuesday, August 20, 2013 7:00 PM >> To: Alexander Vainshtein >> Cc: stbryant@cisco.com; Shahram Davari; mpls@ietf.org; tictoc@ietf.org >> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls >>=20 >> Sasha >>=20 >> In (2) are you proposing to create multiple segment LSPs, where each if t= hose segment LSPs span between two Timing aware LSR? So if I have 10 timing a= ware LSR in the path I would need 9 LSPs? >>=20 >> Regards, >> Shahram >>=20 >>=20 >> On Aug 20, 2013, at 9:53 AM, Alexander Vainshtein wrote: >>=20 >>> Stewart, Shahram and all, >>>=20 >>> A couple of (hopefully, last) comments: >>>=20 >>> 1. Supporting a "Timing Alert" label at the top of the label stack intro= duces a backward compatibility problem. We differ in our estimate of the imp= ortance of this problem, but we all agree that it exists. >>>=20 >>> 2. On the other hand, this problem does not exist if the "Timing Alert" l= abel is inserted at the bottom of the label stack. At the same time, HW that= analyzes the label stack hopefully could analyze the bottom label (almost) a= s easily as it would analyze the top label. Thus we could both provide backw= ard compatibility (incompatible transit LSRs simply would not notice the "Ti= ming Alert" label") and avoid the need for dedicated "Timing-only" LSPs. In p= articular, all the MPLS OAM tools (including MPLS-TP) would work without any= changes. >>>=20 >>> 3. A "timing shim header" (between the bottom of the label stack and the= beginning of the timing packet) has been mentioned by Stewart as an alread= y proposed mechanism. IMHO and FWIW its usage would eliminate the need to un= derstand format of the specific timing distribution protocol in the transit L= SRs. It would further solve the problem of secure transport of timing packe= ts since security mechanisms would be applied to its original encapsulation (= over IP or over Ethernet) without involving the transit LSRs. >>>=20 >>> Did I miss something substantial? >>>=20 >>> Regards, and lots of thanks in advance, >>> Sasha >>>=20 >>>=20 >>> ________________________________________ >>> From: Stewart Bryant [stbryant@cisco.com] >>> Sent: Tuesday, August 20, 2013 6:27 PM >>> To: S. Davari >>> Cc: Alexander Vainshtein; Shahram Davari; mpls@ietf.org; tictoc@ietf.org= >>> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls >>>=20 >>> On 06/08/2013 14:35, S. Davari wrote: >>>> Sasha, >>>>=20 >>>> If a router is not 1588 aware we want it to switch the packet with mini= mum jitter and delay via high priority queue. >>> Yes, but you can explicitly tunnel across such island of incompatibility= >>>=20 >>> Stewart >>>=20 >>>>=20 >>>> Sending it to CPU creates large jitter and delay since the CPUs are gen= erally busy doing other things. Time stamping or updating CF in the CPU won'= t help since it does not cover the variable delay that is incurred from the t= ime the packet enters the router to the time the packet gets processed by CP= U. >>>>=20 >>>> I wish it was that easy! >>>>=20 >>>> Regards, >>>> Shahram >>>>=20 >>>>=20 >>>> On Aug 6, 2013, at 12:38 AM, Alexander Vainshtein wrote: >>>>=20 >>>>> Shahram, >>>>> I agree with you that the routers that do not recognize a Timing Alert= label would send the packet to the CPU. (This would be easy to arrange sinc= e we are speaking about a reserved label.) >>>>>=20 >>>>> I do not, however, see this as a serious issue, because the SW running= on this CPU would (hopefully) be upgradable to handle the packet correctly i= .e., to forward it to where it should be forwarded and, if it is forwarded a= s a labeled packet, to prepend the Timing Alert Label on top of its label st= ack. It could even record the residence time (as observed by the CPU in the p= roper place in the packet. This would mean that introducing additional error= to whatever timing information is associated with this packet - but this is= what you should anyway expect if there are non-compliant routers on your pa= th, right? >>>>>=20 >>>>> Regards, >>>>> Sasha >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Beh= alf Of >>>>>> Shahram Davari >>>>>> Sent: Monday, August 05, 2013 11:29 PM >>>>>> To: stbryant@cisco.com; S. Davari >>>>>> Cc: mpls@ietf.org; tictoc@ietf.org >>>>>> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmp= ls >>>>>>=20 >>>>>> Hi Stewart, >>>>>>=20 >>>>>> Your suggestion of " I suggested an LSP type that has the properties "= timestamp >>>>>> and pass to application", is a subset of the existing draft and shoul= d work. It >>>>>> basically limits the time stamping and correction field update to LER= s (while the >>>>>> draft supports time stamping at LER and LSR). >>>>>>=20 >>>>>> However Sasha's suggestion of using a reserved label (RAL, GAL or any= other >>>>>> reserved label) does not satisfy one of the major requirements, which= is >>>>>> backward compatibility. Routers that don't understand this reserved l= abel will >>>>>> drop or copy to CPU such packets. >>>>>>=20 >>>>>> Regards, >>>>>> Shahram >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Beh= alf Of >>>>>> Stewart Bryant >>>>>> Sent: Monday, August 05, 2013 2:29 AM >>>>>> To: S. Davari >>>>>> Cc: mpls@ietf.org; tictoc@ietf.org >>>>>> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmp= ls >>>>>>=20 >>>>>> My concern is that we are creating a new LSP type in MPLS >>>>>> (which is a architectural change and thus needs to be very carefully >>>>>> considered) without asking the question "how can I do this >>>>>> in the most general way, to maximize flexibility/reuse" >>>>>>=20 >>>>>> I suggested an LSP type that has the properties "timestamp >>>>>> and pass to application", but I think that Sasha raises a good >>>>>> point about using router alert. However RA has no implicit >>>>>> timestamp, so maybe we need a new type of RA that has the >>>>>> properties "timestamp, and pass top application indicated by >>>>>> the next label". That would be quite useful in a number >>>>>> of OAM applications. There is possibly some GAL variant >>>>>> of that design that should also be considered. >>>>>>=20 >>>>>> The application could worry about the path and where it >>>>>> was necessary to skip some hops a hierarchical LSP would >>>>>> accomplish that, with the specific benefit that the application >>>>>> would consciously do this, and may be able to apply some >>>>>> form of compensation within the network. >>>>>>=20 >>>>>> - Stewart >>>>>>=20 >>>>>> On 04/08/2013 10:40, S. Davari wrote: >>>>>>> Hi Sasha >>>>>>>=20 >>>>>>> Perhaps you have not understood the draft well. The main reason that= the >>>>>> draft chose to use a dedicated LSP that is signaled via RSVPTE indica= ting it is a >>>>>> timing LSP is to be backward compatible with non-1588 nodes. Such nod= es >>>>>> simply just switch the packet. >>>>>>> Your proposal had been considered and was rejected since it was not >>>>>> backward compatible. Nodes receiving alert label or TTL =3D 1 send th= e packet to >>>>>> CPU. You can refer to the meeting notes. >>>>>>> Regards, >>>>>>> Shahram >>>>>>>=20 >>>>>>>=20 >>>>>>> On Aug 4, 2013, at 1:21 AM, Alexander Vainshtein >>>>>> wrote: >>>>>>>> Stewart and all, >>>>>>>> I concur with Stewart's statement that the draft does not define "f= ull >>>>>> interaction with MPLS architecture". >>>>>>>> E.g., one of the objectives of the draft is to provide a technique t= hat would >>>>>> be backward-compatible with old LSRs that cannot provide on-path supp= ort for >>>>>> timing distribution, while the other objective is to make every LSR o= n the path >>>>>> aware that some MPLS packets are carrying timing-related messages and= hence >>>>>> require on-path support. >>>>>>>> IMHO and FWIW, the MPLS data plane architecture allows just two met= hods >>>>>> for making a transit LSR to provide special processing to a labeled p= acket: >>>>>>>> - It would carry some kind of an "alert label" on top of the label s= tack and, >>>>>> specifically, on top of any labels used for actual forwarding >>>>>>>> OR, >>>>>>>> - The TTL in the top label stack entry has been set to 1. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The draft does not follow any of these approaches. >>>>>>>>=20 >>>>>>>> I must also admit that Section 12 "OAM, Control and Management" of t= he >>>>>> draft looks somewhat in >>>>>>>> E.g., I could not understand from the text whether BFD, LSP-Ping et= c. OAM >>>>>> messages would be subjected to on-path support procedures for timing >>>>>> messages or not. >>>>>>>> My 2c, >>>>>>>> Sasha >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On B= ehalf >>>>>> Of >>>>>>>>> Stewart Bryant >>>>>>>>> Sent: Friday, August 02, 2013 12:01 PM >>>>>>>>> To: mpls-chairs@tools.ietf.org; tictoc-chairs@tools.ietf.org; int-= >>>>>>>>> ads@tools.ietf.org; rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf= .org; >>>>>> draft- >>>>>>>>> ietf-tictoc-1588overmpls@tools.ietf.org >>>>>>>>> Cc: mpls@ietf.org; tictoc@ietf.org >>>>>>>>> Subject: [TICTOC] Comments on draft-ietf-tictoc-1588overmpls >>>>>>>>>=20 >>>>>>>>> SB> This draft does not seem to provide a precise definition >>>>>>>>> SB> the properties of the new LSP type that it wishes to >>>>>>>>> SB> define, in particular it does it define the PHB of those >>>>>>>>> SB> LSPs, nor the full interaction with the MPLS >>>>>>>>> SB> architecture. >>>>>>>>> SB> >>>>>>>>> SB> I have not tracked TICTOC for a while but I thought that >>>>>>>>> SB> the original plan was to define the concept of an offset >>>>>>>>> SB> into a packet to do the correction. >>>>>>>>> SB> >>>>>>>>> SB> It is disappointing that the opportunity was not taken >>>>>>>>> SB> to define a timing shim inside the timing LSP so that >>>>>>>>> SB> a time correction could be added to any packet such that >>>>>>>>> SB> the MPLS system was isolated from the details of the >>>>>>>>> SB> complexity of the particular time transfer type. >>>>>>>>>=20 >>>>>>>>> SB> I think that much more clarify is needed in terms of >>>>>>>>> SB> definition of the new LSP type, since it is unclear >>>>>>>>> SB> from this text how to implement one. >>>>>>>>> SB> >>>>>>>>> SB> There are a lot of other MPLS services such as >>>>>>>>> SB> LSP ping that need to be considered. >>>>>>>>> SB> >>>>>>>>> SB> Please see inline for more comments. However these >>>>>>>>> SB> comments are made in the context of the text as written >>>>>>>>> SB> whilst I have a fundamental concern that this approach >>>>>>>>> SB> lacks an MPLS architectural soundness that need >>>>>>>>> SB> greater thought with significant impact on the >>>>>>>>> SB> draft. >>>>>>>>>=20 >>>>>>>>> - Stewart >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> TICTOC Working Group S. D= avari >>>>>>>>> Internet-Draft A= . Oren >>>>>>>>> Intended status: Standards Track Broadcom= Corp. >>>>>>>>> Expires: December 17, 2013 M. B= hatia >>>>>>>>> P. R= oberts >>>>>>>>> Alcatel-= Lucent >>>>>>>>> L. M= ontini >>>>>>>>> L. M= artini >>>>>>>>> Cisco S= ystems >>>>>>>>> June 15= , 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Transporting Timing messages over MPLS Networks >>>>>>>>> draft-ietf-tictoc-1588overmpls-05 >>>>>>>>>=20 >>>>>>>>> Abstract >>>>>>>>>=20 >>>>>>>>> This document defines the method for transporting Timing messag= es >>>>>>>>> such as PTP and NTP over an MPLS network. The method allows fo= r the >>>>>>>>> easy identification of these PDUs at the port level to allow fo= r port >>>>>>>>>=20 >>>>>>>>> SB> What is a port >>>>>>>>>=20 >>>>>>>>> level processing of these PDUs in both LERs and LSRs. >>>>>>>>>=20 >>>>>>>>> The basic idea is to transport Timing messages inside dedicated= MPLS >>>>>>>>> LSPs. These LSPs only carry Timing messages and possibly Contr= ol and >>>>>>>>> Management packets, but they do not carry customer traffic. >>>>>>>>>=20 >>>>>>>>> SB> More specifically they only carry traffic associated with the >>>>>>>>> SB> timing service and its support. >>>>>>>>> SB> The question arose WRT BFD - surely BFD is allowed, BUT surely= >>>>>>>>> SB> also it gets carried in a structure that causes it to get >>>>>>>>> SB> timestamped. >>>>>>>>>=20 >>>>>>>>> Two methods for transporting Timing messages over MPLS are defi= ned. >>>>>>>>>=20 >>>>>>>>> SB> Perhaps the right approach is to define the new LSP type and t= hen >>>>>>>>> SB> seperately to define the mapping of the various timing servic= es >>>>>>>>> SB> over that LSP type. >>>>>>>>>=20 >>>>>>>>> The first method is to transport Timing messages directly over t= he >>>>>>>>> dedicated MPLS LSP via UDP/IP encapsulation, which is suitable f= or >>>>>>>>> MPLS networks. The second method is to transport Timing messag= es >>>>>>>>> inside a PW via Ethernet encapsulation. >>>>>>>>>=20 >>>>>>>>> SB> I think that we should note that there are some >>>>>>>>> SB> h/w reasons for this preference. A clean sheet approach >>>>>>>>> SB> would have been to use PTP over MPLS with no intermediate >>>>>>>>> SB> layers. >>>>>>>>>=20 >>>>>>>>> Status of this Memo >>>>>>>>>=20 >>>>>>>>> This Internet-Draft is submitted in full conformance with the >>>>>>>>> provisions of BCP 78 and BCP 79. >>>>>>>>>=20 >>>>>>>>> Internet-Drafts are working documents of the Internet Engineeri= ng >>>>>>>>> Task Force (IETF). Note that other groups may also distribute >>>>>>>>> working documents as Internet-Drafts. The list of current Inte= rnet- >>>>>>>>> Drafts is at http://datatracker.ietf.org/drafts/current/. >>>>>>>>>=20 >>>>>>>>> Internet-Drafts are draft documents valid for a maximum of six m= onths >>>>>>>>> and may be updated, replaced, or obsoleted by other documents a= t any >>>>>>>>> time. It is inappropriate to use Internet-Drafts as reference >>>>>>>>> material or to cite them other than as "work in progress." >>>>>>>>>=20 >>>>>>>>> This Internet-Draft will expire on December 17, 2013. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [P= age 1] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Copyright Notice >>>>>>>>>=20 >>>>>>>>> Copyright (c) 2013 IETF Trust and the persons identified as the= >>>>>>>>> document authors. All rights reserved. >>>>>>>>>=20 >>>>>>>>> This document is subject to BCP 78 and the IETF Trust's Legal >>>>>>>>> Provisions Relating to IETF Documents >>>>>>>>> (http://trustee.ietf.org/license-info) in effect on the date of= >>>>>>>>> publication of this document. Please review these documents >>>>>>>>> carefully, as they describe your rights and restrictions with r= espect >>>>>>>>> to this document. Code Components extracted from this document= must >>>>>>>>> include Simplified BSD License text as described in Section 4.e= of >>>>>>>>> the Trust Legal Provisions and are provided without warranty as= >>>>>>>>> described in the Simplified BSD License. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Table of Contents >>>>>>>>>=20 >>>>>>>>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .= . 5 >>>>>>>>>=20 >>>>>>>>> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . .= . 7 >>>>>>>>>=20 >>>>>>>>> 3. Problem Statement . . . . . . . . . . . . . . . . . . . . .= . 8 >>>>>>>>>=20 >>>>>>>>> 4. Timing over MPLS Architecture . . . . . . . . . . . . . . .= . 9 >>>>>>>>>=20 >>>>>>>>> 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . .= . 12 >>>>>>>>>=20 >>>>>>>>> 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . .= . 13 >>>>>>>>> 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . .= . 13 >>>>>>>>> 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . .= . 13 >>>>>>>>> 6.3. Other Timing Encapsulation methods . . . . . . . . . . .= . 14 >>>>>>>>>=20 >>>>>>>>> 7. Timing message Processing . . . . . . . . . . . . . . . . .= . 15 >>>>>>>>>=20 >>>>>>>>> 8. Protection and Redundancy . . . . . . . . . . . . . . . . .= . 16 >>>>>>>>>=20 >>>>>>>>> 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . .= . 17 >>>>>>>>>=20 >>>>>>>>> 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . .= . 18 >>>>>>>>>=20 >>>>>>>>> 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . .= . 19 >>>>>>>>>=20 >>>>>>>>> 12. OAM, Control and Management . . . . . . . . . . . . . . . .= . 20 >>>>>>>>>=20 >>>>>>>>> 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . .= . 21 >>>>>>>>>=20 >>>>>>>>> 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . .= . 22 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [P= age 2] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . .= . 23 >>>>>>>>> 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . .= . 23 >>>>>>>>> 15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . .= . 23 >>>>>>>>> 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . .= . 24 >>>>>>>>>=20 >>>>>>>>> 16. Other considerations . . . . . . . . . . . . . . . . . . . .= . 25 >>>>>>>>>=20 >>>>>>>>> 17. Security Considerations . . . . . . . . . . . . . . . . . .= . 26 >>>>>>>>>=20 >>>>>>>>> 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .= . 27 >>>>>>>>>=20 >>>>>>>>> 19. IANA Considerations . . . . . . . . . . . . . . . . . . . .= . 28 >>>>>>>>>=20 >>>>>>>>> 20. References . . . . . . . . . . . . . . . . . . . . . . . . .= . 29 >>>>>>>>> 20.1. Normative References . . . . . . . . . . . . . . . . . .= . 29 >>>>>>>>> 20.2. Informative References . . . . . . . . . . . . . . . . .= . 29 >>>>>>>>>=20 >>>>>>>>> Appendix 1. Routing extensions for Timing-aware Routers . . . .= . 32 >>>>>>>>>=20 >>>>>>>>> Appendix 2. Signaling Extensions for Creating Timing LSPs . . .= . 33 >>>>>>>>>=20 >>>>>>>>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .= . 34 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [P= age 3] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >>>>>> NOT", >>>>>>>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" >>>>>> in >>>>>>>>> this >>>>>>>>> document are to be interpreted as described in RFC2119 [RFC2119= ]. >>>>>>>>>=20 >>>>>>>>> When used in lower case, these words convey their typical use i= n >>>>>>>>> common language, and are not to be interpreted as described in >>>>>>>>> RFC2119 [RFC2119]. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [P= age 4] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 1. Introduction >>>>>>>>>=20 >>>>>>>>> The objective of Precision Time Protocol (PTP) and Network Timi= ng >>>>>>>>> Protocol (NTP) are to synchronize independent clocks running on= >>>>>>>>> separate nodes of a distributed system. >>>>>>>>>=20 >>>>>>>>> [IEEE-1588] defines PTP messages for frequency, phase and time >>>>>>>>> synchronization. The PTP messages include PTP PDUs over UDP/IP= >>>>>>>>> (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Anne= x F of >>>>>>>>> [IEEE-1588]). >>>>>>>>>=20 >>>>>>>>> SB> Sure BUT it is acknowledged that IEEE is open to the definitio= n >>>>>>>>> SB> of other PTP mappings if they provide better optimisation. >>>>>>>>>=20 >>>>>>>>> This document defines mapping and transport of the PTP >>>>>>>>> messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PT= P >>>>>>>>> defines several clock types: ordinary clocks, boundary clocks, e= nd- >>>>>>>>> to-end transparent clocks, and peer-to-peer transparent clocks.= >>>>>>>>> Transparent clocks require intermediate nodes to update correct= ion >>>>>>>>> field inside PTP message that reflects the transit time in the n= ode. >>>>>>>>>=20 >>>>>>>>> [RFC5905] defines NTP messages for clock and time synchronizati= on. >>>>>>>>> The PTP messages (PDUs) are transported over UDP/IP. This docu= ment >>>>>>>>> SB> Should that be NTP messages? >>>>>>>>> SB> It needs to be made clear as soon as you introduce NTP that >>>>>>>>> SB> they use different time representations. >>>>>>>>>=20 >>>>>>>>> defines mapping and transport of the NTP messages defined in >>>>>>>>> [RFC5905] over MPLS networks. >>>>>>>>>=20 >>>>>>>>> One key attribute of all of these Timing messages is that the T= ime >>>>>>>>> stamp processing should occur as close as possible to the actua= l >>>>>>>>> transmission and reception at the physical port interface. Thi= s >>>>>>>>> targets optimal time and/or frequency recovery by avoiding vari= able >>>>>>>>> delay introduced by queues internal to the clocks. >>>>>>>>>=20 >>>>>>>>> SB> As I recall NTP has no epoch point defined, and I am not sure >>>>>>>>> SB> where that point is in the case of PTP in this mapping >>>>>>>>> SB> Hopefully this will get defined in due course. >>>>>>>>>=20 >>>>>>>>> To facilitate the fast and efficient recognition of Timing mess= ages >>>>>>>>> at the port level when the Timing messages are carried over MPL= S >>>>>>>>> LSPs, >>>>>>>>>=20 >>>>>>>>> SB> Over a new LSP type with time optimied characteristics >>>>>>>>>=20 >>>>>>>>> this document defines the specific encapsulations that should >>>>>>>>> be used. >>>>>>>>> SB> Hopefully it will also define the PHP >>>>>>>>>=20 >>>>>>>>> In addition, it can be expected that there will exist LSR/ >>>>>>>>> LERs where only a subset of the physical ports will have the po= rt- >>>>>>>>> based Timing message processing capabilities. >>>>>>>>> SB> Do you need to clarify that this only works at base and not in= >>>>>>>>> SB> a label heirarchy. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> In order to ensure >>>>>>>>> that the LSPs carrying Timing packets always enter and exit por= ts >>>>>>>>> with this capability, routing extensions are defined to adverti= se >>>>>>>>> this capability on a port basis and to allow for the establishm= ent of >>>>>>>>> LSPs that only transit such ports. While this path establishme= nt >>>>>>>>> restriction may be applied only at the LER Ingress and/or egres= s >>>>>>>>> ports, it becomes more important when using transparent clock c= apable >>>>>>>>> LSRs in the path. >>>>>>>>> SB> I do not understand the implications of the last >>>>>>>>> SB> sentences - starting ", it becomes" >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Port based Timing message processing involves Timing message >>>>>>>>> recognition. Once the Timing messages are recognized they can b= e >>>>>>>>> modified based on the reception or transmission Time-stamp. >>>>>>>>>=20 >>>>>>>>> This document provides two methods for transporting Timing mess= ages >>>>>>>>> over MPLS. One is applicable to MPLS environment and the other= one >>>>>>>>> is applicable to MPLS/MPLS-TP environment >>>>>>>>>=20 >>>>>>>>> SB> I think the sentence is incomplete. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [P= age 5] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The solution involves transporting Timing messages over dedicat= ed >>>>>>>>> LSPs called Timing LSPs. These LSPs carry Timing messages and M= AY >>>>>>>>> carry Management and control messages, but not data plane clien= t >>>>>>>>> traffic. >>>>>>>>>=20 >>>>>>>>> SB> It is not clear why this restriction applies. >>>>>>>>>=20 >>>>>>>>> Timing LSPs can be established statically or via signaling. >>>>>>>>> SB> s/statically/by provisioning/network management/ >>>>>>>>>=20 >>>>>>>>> Extensions to control plane (OSPF, ISIS, etc.) is required to e= nable >>>>>>>>> routers to distribute their Timing processing capabilities over= MPLS >>>>>>>>> to other routers. However such extensions are outside the scop= e of >>>>>>>>> this document. >>>>>>>>>=20 >>>>>>>>> When signaling is used to setup the PTP LSP, Extensions to sign= aling >>>>>>>>> SB> is it a PTP LSP or a Timing LSP? >>>>>>>>>=20 >>>>>>>>> protocols (e.g., RSVP-TE) are required for establishing PTP LSP= s. >>>>>>>>> However such extensions are outside the scope of this document.= >>>>>>>>>=20 >>>>>>>>> SB> for mpls-tp GMPLS is the signalling protocol >>>>>>>>>=20 >>>>>>>>> While the techniques included herein allow for the establishmen= t of >>>>>>>>> paths optimized to include Time-stamping capable links, the >>>>>>>>> performance of the Slave clocks is outside the scope of this >>>>>>>>> document. >>>>>>>>>=20 >>>>>>>>> At the time of publishing this specification, Transparent Clock= ing >>>>>>>>> (TC) is only defined for PTP. Therefore at this time any part o= f >>>>>>>>> this specification that talks about Transparent Clocking applie= s only >>>>>>>>> to PTP. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [P= age 6] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 2. Terminology >>>>>>>>>=20 >>>>>>>>> 1588: The timing and synchronization as defined by IEEE 1588. >>>>>>>>>=20 >>>>>>>>> SB> I think that there is a more formal name for the 1588 group >>>>>>>>> SB> that needs to be used here. >>>>>>>>> SB> Also do we need to talk about 1588-200? as there is >>>>>>>>> SB> an update in progress >>>>>>>>>=20 >>>>>>>>> NTP: The timing and synchronization protocol defined by IETF RFC= -1305 >>>>>>>>> and RFC-5905. >>>>>>>>>=20 >>>>>>>>> PTP: The timing and synchronization protocol used by 1588. >>>>>>>>> SB> need the proper name for 1588 >>>>>>>>>=20 >>>>>>>>> Master Clock: The source of 1588 timing to a set of slave clock= s. >>>>>>>>>=20 >>>>>>>>> Master Port: A port on a ordinary or boundary clock that is in M= aster >>>>>>>>> state. This is the source of timing toward slave ports. >>>>>>>>>=20 >>>>>>>>> SB> I am not sure the reader knows what a port is >>>>>>>>>=20 >>>>>>>>> Slave Clock: A receiver of 1588 timing from a master clock. >>>>>>>>>=20 >>>>>>>>> Slave Port: A port on a boundary clock or ordinary clock that i= s >>>>>>>>> receiving timing from a master clock. >>>>>>>>>=20 >>>>>>>>> Ordinary Clock: A device with a single PTP port. >>>>>>>>>=20 >>>>>>>>> Transparent Clock. A device that measures the time taken for a= PTP >>>>>>>>> event message to transit the device and then updates the >>>>>>>>> correctionField of the message with this transit time. >>>>>>>>>=20 >>>>>>>>> Boundary Clock: A device with more than one PTP port. Generall= y >>>>>>>>> boundary clocks will have one port in slave state to receive ti= ming >>>>>>>>> and then other ports in master state to re-distribute the timin= g. >>>>>>>>>=20 >>>>>>>>> PTP LSP: An LSP dedicated to carry PTP messages >>>>>>>>>=20 >>>>>>>>> SB> PTP or timing? >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> PTP PW: A PW within a PTP LSP that is dedicated to carry PTP >>>>>>>>> messages. >>>>>>>>>=20 >>>>>>>>> SB> Ah I don't think that PWE3 know what one of these is >>>>>>>>>=20 >>>>>>>>> CW: Pseudowire Control Word >>>>>>>>>=20 >>>>>>>>> LAG: Link Aggregation >>>>>>>>>=20 >>>>>>>>> ECMP: Equal Cost Multipath >>>>>>>>>=20 >>>>>>>>> CF: Correction Field, a field inside certain PTP messages (mess= age >>>>>>>>> type 0-3)that holds the accumulative transit time inside interm= ediate >>>>>>>>> switches >>>>>>>>>=20 >>>>>>>>> Timing messages: Timing Protocol messages that are exchanged >>>>>> between >>>>>>>>> routers in order to establish a synchronized clock. >>>>>>>>>=20 >>>>>>>>> SB> A number of these definitions look like copies of IEEE1588 >>>>>>>>> SB> definitions. We need to provide references and note the >>>>>>>>> SB> priority of the IEEE base reference. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [P= age 7] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 3. Problem Statement >>>>>>>>>=20 >>>>>>>>> [IEEE-1588] has defined methods for transporting PTP messages o= ver >>>>>>>>> Ethernet and IP networks. [RFC5905] has defined the method of >>>>>>>>> transporting NTP messages over IP networks. There is a need to= >>>>>>>>> transport Timing messages over MPLS networks while supporting t= he >>>>>>>>> Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (= OC) >>>>>>>>> functionality in the LER and LSRs in the MPLS network. >>>>>>>>>=20 >>>>>>>>> There are multiple ways of transporting Timing over MPLS. Howe= ver, >>>>>>>>> there is a requirement to limit the possible encapsulation opti= ons to >>>>>>>>> simplify the Timing message identification and processing requi= red at >>>>>>>>> the port level. >>>>>>>>>=20 >>>>>>>>> When Timing-awareness is needed, Timing messages should not be >>>>>>>>> transported over LSPs or PWs that are carrying customer traffic= >>>>>>>>> because LSRs perform Label switching based on the top label in t= he >>>>>>>>> stack. >>>>>>>>>=20 >>>>>>>>> SB> Have you explained why? >>>>>>>>>=20 >>>>>>>>> To detect Timing messages inside such LSPs require special >>>>>>>>> hardware to do deep packet inspection at line rate. Even if su= ch >>>>>>>>> hardware exists, the payload can't be deterministically identif= ied by >>>>>>>>> LSRs because the payload type is a context of the PW label, and= the >>>>>>>>> PW label and its context are only known to the Edge routers (PE= s/ >>>>>>>>> LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR,= CES, >>>>>>>>> etc). Even if one restricts an LSP to only carry Ethernet PWs,= the >>>>>>>>> LSRs dont have the knowledge of whether PW Control Word (CW) is= >>>>>>>>> present or not and therefore can not deterministically identify= the >>>>>>>>> payload. >>>>>>>>>=20 >>>>>>>>> A generic method is defined in this document that does not requ= ire >>>>>>>>> deep packet inspection at line rate, and can deterministically >>>>>>>>> identify Timing messages. This method can be used to detect Ti= ming >>>>>>>>> Messages in both one-step and two-step clock implementations of= >>>>>>>>> ordinary, boundary and transparent clocks. >>>>>>>>>=20 >>>>>>>>> SB> Needs a ref and I am sure many MPLS specialists will not under= stand >>>>>>>>> SB> the msg types. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [P= age 8] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 4. Timing over MPLS Architecture >>>>>>>>>=20 >>>>>>>>> Timing messages are exchange between Timing ports on ordinary a= nd >>>>>>>>>=20 >>>>>>>>> SB> Have you defined a timing port? >>>>>>>>>=20 >>>>>>>>> boundary clocks. Boundary clocks terminate the Timing messages= and >>>>>>>>> act as master for other boundary clocks or for slave clocks. E= nd-to- >>>>>>>>> End Transparent clocks do not terminate the Timing messages but= they >>>>>>>>> do modify the contents of the Timing messages as they transit a= cross >>>>>>>>> the transparent clock. >>>>>>>>>=20 >>>>>>>>> Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent= Clock >>>>>>>>>=20 >>>>>>>>> (TC) could be implemented in either LERs or LSRs. >>>>>>>>>=20 >>>>>>>>> SB> LER and LSR need to be expanded >>>>>>>>>=20 >>>>>>>>> An example is shown in Figure 1, where the LERs act as Ordinary= Clock >>>>>>>>> (OC) and are the initiating/terminating point for Timing messag= es. >>>>>>>>> The ingress LER encapsulates the Timing messages in Timing LSP a= nd >>>>>>>>> the Egress LER terminates the Timing LSP. The LSRs act as >>>>>>>>> Transparent Clock (TC) and just update the Timing field in the T= iming >>>>>>>>> messages. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> +--------+ +-------+ +-------+ +-------+ +--= ------+ >>>>>>>>> |Switch, | | | | | | | |Sw= itch, | >>>>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| R= outer | >>>>>>>>> | | | OC | | TC | | OC | | = | >>>>>>>>> +--------+ +-------+ +-------+ +-------+ +--= ------+ >>>>>>>>> / \ >>>>>>>>> +-------+ / \ +---= ----+ >>>>>>>>> | LER | / \ | L= ER | >>>>>>>>> | Master|---/ \---| Sl= ave | >>>>>>>>> | Clock | | Cl= ock | >>>>>>>>> +-------+ +---= ----+ >>>>>>>>>=20 >>>>>>>>> Figure (1) - Deployment example 1 of timing over MPLS network= >>>>>>>>>=20 >>>>>>>>> Another example is shown in Figure2, where LERs terminate the T= iming >>>>>>>>> messages received from switch/routers that are outside of the M= PLS >>>>>>>>> network acting as OC or BC. In this example LERs regenerate th= e >>>>>>>>> clock and initiate timing messages encapsulated in Timing LSP t= oward >>>>>>>>> the MPLS network, while the LSRs act as Transparent Clock (TC) a= nd >>>>>>>>> just update the Timing field in the Timing messages, which are >>>>>>>>> already encapsulated in Timing LSPs. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [P= age 9] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> +--------+ +-------+ +-------+ +-------+ +---= -----+ >>>>>>>>> |Switch, | | | | | | | |Swi= tch, | >>>>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Ro= uter | >>>>>>>>> | OC/BC | | BC | | TC | | BC | | OC= /BC | >>>>>>>>> +--------+ +-------+ +-------+ +-------+ +---= -----+ >>>>>>>>>=20 >>>>>>>>> Figure (2) - Deployment example 2 of timing over MPLS network= >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Another example is shown in Figure 3, where LERs do not termina= te the >>>>>>>>> Timing messages received from switch/routers that are outside o= f the >>>>>>>>> MPLS network acting as OC, TC or BC. The LERs act as TC and up= date >>>>>>>>> the Timing field in the Timing messages as they transit the LER= , >>>>>>>>> while encapsulating them in timing LSP. The LSRs also act as >>>>>>>>> Transparent Clock (TC) and just update the Timing field in the T= iming >>>>>>>>> messages which are already encapsulated in Timing LSPs. >>>>>>>>>=20 >>>>>>>>> +--------+ +-------+ +-------+ +-------+ +--= ------+ >>>>>>>>> |Switch, | | | | | | | |Sw= itch, | >>>>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| R= outer | >>>>>>>>> |OC/TC/BC| | TC | | TC | | TC | |OC= /TC/BC| >>>>>>>>> +--------+ +-------+ +-------+ +-------+ +--= ------+ >>>>>>>>>=20 >>>>>>>>> Figure (3) - Deployment example 3 of timing over MPLS network >>>>>>>>>=20 >>>>>>>>> Another example is shown in Figure 4, where LERs and LSRs suppo= rt >>>>>>>>> Boundary Clocks. A single-hop LSP is created between two adjac= ent >>>>>>>>> LSRs engaged in BC operation. Other methods such as PTP transp= ort >>>>>>>>> over Ethernet MAY be used for transporting timing messages if t= he >>>>>>>>> link between the two routers is Ethernet. >>>>>>>>>=20 >>>>>>>>> +--------+ +-------+ +-------+ +-------+ +---= -----+ >>>>>>>>> |Switch, | | | | | | | |Swi= tch, | >>>>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Ro= uter | >>>>>>>>> | OC/BC | | BC | | BC | | BC | | OC= /BC | >>>>>>>>> +--------+ +-------+ +-------+ +-------+ +---= -----+ >>>>>>>>>=20 >>>>>>>>> Figure (4) - Deployment example 3 of timing over MPLS network >>>>>>>>>=20 >>>>>>>>> An MPLS domain MAY serve multiple customers. In these cases th= e >>>>>> MPLS >>>>>>>>> domain (maintained by a service provider) may provide timing se= rvices >>>>>>>>> to multiple customers, each having their own Timing domain. >>>>>>>>>=20 >>>>>>>>> The Timing over MPLS architecture assumes full mesh of Timing L= SPs >>>>>>>>> between all LERs supporting this specification. >>>>>>>>>=20 >>>>>>>>> SB> Note sure this is right - the salves surely do not need to >>>>>>>>> SB> exchange timing amongst themselves >>>>>>>>>=20 >>>>>>>>> It supports >>>>>>>>> Point-to- point (VPWS) and Multipoint (VPLS) services. >>>>>>>>>=20 >>>>>>>>> SB> What does that mean? You do not carry user data traffic? >>>>>>>>> SB> Maybe it's the ordering of the statemnets that is causing >>>>>>>>> SB> confusion. >>>>>>>>>=20 >>>>>>>>> This means >>>>>>>>> that a customer may purchase a Point-to-point Timing service be= tween >>>>>>>>> two customer sites or a Multipoint Timing service between more t= han >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 10] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> two customer sites. >>>>>>>>>=20 >>>>>>>>> The Timing over MPLS architecture supports P2P or P2MP Timing L= SPs. >>>>>>>>> This means that the Timing Multicast messages such as PTP Multi= cast >>>>>>>>> event messages can be transported over P2MP Timing LSP or be >>>>>>>>> replicated and transported over many P2P Timing LSPs. >>>>>>>>>=20 >>>>>>>>> SB> Note we do not yet have a definition of a P2MP mpls-tp LSP >>>>>>>>> SB> nor a P2MP PW, although we are close. >>>>>>>>>=20 >>>>>>>>> Timing messages, that do not require Time stamping or Correctio= n >>>>>>>>> Field update MAY be transported over Timing LSPs to simplify ha= rdware >>>>>>>>> and software. >>>>>>>>>=20 >>>>>>>>> PTP Announce messages that determine the Timing LSP terminating= >>>>>> point >>>>>>>>> behavior such as BC/OC/TC SHOULD be transported over the Timing= LSP >>>>>>>>> to simplify hardware and software. >>>>>>>>>=20 >>>>>>>>> SB> have you defined and referenced PTP announce msgs? >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 11] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 5. Dedicated LSPs for Timing messages >>>>>>>>>=20 >>>>>>>>> Many methods have been considered for identifying the Timing >>>>>> messages >>>>>>>>> when they are encapsulated in MPLS such as using GAL/G-ACH or a= new >>>>>>>>> reserved label. These methods were not attractive since they e= ither >>>>>>>>> required deep packet inspection at line rate in the intermediat= e LSRs >>>>>>>>> or they required use of a scarce new reserved label. Also one o= f the >>>>>>>>> goals was to reuse existing OAM mechanisms. >>>>>>>>>=20 >>>>>>>>> SB> RLs =3D SPLs are not so rare now. In any case needs a ref. >>>>>>>>>=20 >>>>>>>>> The method defined in this document can be used by LER and LSRs= to >>>>>>>>> identify Timing messages in MPLS tunnels by just looking at the= top >>>>>>>>> label in the MPLS label stack, which only carry Timing messages= as >>>>>>>>> well as OAM, but not data plane client traffic. >>>>>>>>>=20 >>>>>>>>> Compliant implementations MUST use dedicated LSPs to carry Timi= ng >>>>>>>>> messages over MPLS. >>>>>>>>>=20 >>>>>>>>> SB> I think that we need a definition of the properies of these LS= Ps >>>>>>>>>=20 >>>>>>>>> These LSPs are herein referred to as "Timing >>>>>>>>> LSPs" and the labels associated with these LSPs as "Timing LSP >>>>>>>>> labels". The Timing LSPs that runs between Ingress and Egress L= ERs >>>>>>>>> MUST be co-routed. Alternatively, a single bidirectional co-ro= uted >>>>>>>>> LSP can be used. >>>>>>>>>=20 >>>>>>>>> SB> I though that you said you could use M2MP LSPs - these are not= >>>>>>>>> SB> bidirectional. >>>>>>>>>=20 >>>>>>>>> Co-routing of the two directions is required to limit the diffe= rence >>>>>>>>> in the delays in the Master clock to Slave clock direction comp= ared >>>>>>>>> to the Slave clock to Master clock direction. The Timing LSP M= AY be >>>>>>>>> MPLS/MPLS-TP LSP. >>>>>>>>>=20 >>>>>>>>> The Timing LSPs could be configured or signaled via RSVP-TE/GMP= LS. >>>>>>>>> New Extensions to RSVP-TE/GMPLS TLVs are required; however they= are >>>>>>>>> outside the scope of this document. >>>>>>>>>=20 >>>>>>>>> The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic su= ch as >>>>>>>>> BFD and LSP Ping but the LSP data plane client plane traffic MU= ST be >>>>>>>>> Timing packets only. >>>>>>>>>=20 >>>>>>>>> SB> Why? >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 12] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 6. Timing over LSP Encapsulation >>>>>>>>>=20 >>>>>>>>> The encapsulations is not LSP is it? >>>>>>>>>=20 >>>>>>>>> This document defines two methods for carrying Timing messages o= ver >>>>>>>>> MPLS. The first method is carrying UDP/IP encapsulated Timing >>>>>>>>> messages over Timing LSPs, and the second method, is carrying >>>>>>>>> Ethernet encapsulated Timing messages over Ethernet PWs inside >>>>>> Timing >>>>>>>>> LSPs. >>>>>>>>>=20 >>>>>>>>> 6.1. Timing over UDP/IP over MPLS Encapsulation >>>>>>>>>=20 >>>>>>>>> The simplest method of transporting Timing messages over MPLS i= s to >>>>>>>>> encapsulate Timing PDUs in UDP/IP and then encapsulate them in >>>>>> Timing >>>>>>>>> LSP. This format is shown in Figure 4. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> +----------------------+ >>>>>>>>> | Timing LSP Label | >>>>>>>>> +----------------------+ >>>>>>>>> | IPv4/6 | >>>>>>>>> +----------------------+ >>>>>>>>> | UDP | >>>>>>>>> +----------------------+ >>>>>>>>> | Timing PDU | >>>>>>>>> +----------------------+ >>>>>>>>>=20 >>>>>>>>> Figure (4) - Timing over UDP/IP over MPLS Encapsulation >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> This encapsulation is very simple and is useful when the networ= k >>>>>>>>> between Timing Master Clock and Slave Clock is MPLS network. >>>>>>>>>=20 >>>>>>>>> SB> Simple is a judgement call >>>>>>>>>=20 >>>>>>>>> In order for an LER/LSR to process Timing messages, the Timing L= SP >>>>>>>>> Label must be at the top label of the label stack. The LER/LSR= MUST >>>>>>>>> know that the Timing LSP Label is used for carrying Timing mess= ages. >>>>>>>>> This can be accomplished via static configuration or via RSVP-T= E >>>>>>>>> signaling. >>>>>>>>>=20 >>>>>>>>> The UDP/IP encapsulation of PTP MUST follow Annex D and E of >>>>>>>>> [IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow= >>>>>>>>> [RFC5905]. >>>>>>>>>=20 >>>>>>>>> 6.2. Timing over PW Encapsulation >>>>>>>>>=20 >>>>>>>>> Another method of transporting Timing over MPLS networks is by >>>>>>>>> encapsulating Timing PDUs in PW which in turn is transported ov= er >>>>>>>>> Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC444= 8], >>>>>>>>> shown in Fig 5(A) MUST be used and the Ethernet encapsulation o= f PTP >>>>>>>>> MUST follow Annex F of [IEEE-1588]. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 13] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The RAW mode or Tagged mode defined in [RFC4448] MAY be used an= d >>>>>> the >>>>>>>>> Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). Th= e >>>>>>>>> Timing over PW encapsulation MUST use the Control Word (CW) as >>>>>>>>> specified in [RFC4448] to ensure proper detection of PTP messag= es >>>>>>>>> inside the MPLS packets for Timing over LSP and Timing over PW >>>>>>>>> encapsulation. >>>>>>>>>=20 >>>>>>>>> SB> That needs explanation >>>>>>>>>=20 >>>>>>>>> The use of Sequence Number in the CW is optional. >>>>>>>>>=20 >>>>>>>>> SB> Given that s/n are never in practice deployed, you could proba= bly >>>>>>>>> SB> simplify things by sayig that they are not used. >>>>>>>>>=20 >>>>>>>>> Timing over PW encapsulation for NTP MUST use NTP over UDP/IP o= ver >>>>>> PW >>>>>>>>> (the IP PW discussed in [RFC4447]) shown in Fig 5(B). >>>>>>>>>=20 >>>>>>>>> +----------------+ +----------------+ >>>>>>>>> |Timing LSP Label| |Timing LSP Label| >>>>>>>>> +----------------+ +----------------+ >>>>>>>>> | PW Label | | PW Label | >>>>>>>>> +----------------+ +----------------+ >>>>>>>>> | Control Word | | IP | >>>>>>>>> +----------------+ +----------------+ >>>>>>>>> | Ethernet | | UDP | >>>>>>>>> | Header | +----------------+ >>>>>>>>> +----------------+ | Timing PDU | >>>>>>>>> |S-VLAN(Optional)| | | >>>>>>>>> +----------------+ +----------------+ >>>>>>>>> |C-VLAN(Optional)| (B) >>>>>>>>> +----------------+ >>>>>>>>> | Timing PDU | >>>>>>>>> | | >>>>>>>>> +----------------+ >>>>>>>>> (A) >>>>>>>>>=20 >>>>>>>>> Figure (5) - Timing over PW Encapsulations >>>>>>>>>=20 >>>>>>>>> In order for an LSR to process PTP messages, the top label of t= he >>>>>>>>> label stack (the Tunnel Label) MUST be a Timing label. >>>>>>>>>=20 >>>>>>>>> S> You said that before. >>>>>>>>>=20 >>>>>>>>> 6.3. Other Timing Encapsulation methods >>>>>>>>>=20 >>>>>>>>> In future other timing encapsulation methods may be introduced,= such >>>>>>>>> as a new shim header after the Bottom of Stack to carry the Tim= ing >>>>>>>>> information. Such new encapsulations are outside the scope of t= his >>>>>>>>> document. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> SB> Taking a pure MPLS pov, you can simplify a lot of the text >>>>>>>>> SB> out of the definition of the LSP >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 14] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> SB> I think we need a section on LSP processing >>>>>>>>>=20 >>>>>>>>> 7. Timing message Processing >>>>>>>>>=20 >>>>>>>>> Each Timing protocol such as PTP and NTP, define their set of T= iming >>>>>>>>> messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP,= >>>>>>>>> FOLLOW_UP, etc messages. >>>>>>>>>=20 >>>>>>>>> Some of the Timing messages require time stamping or correction= field >>>>>>>>> update at port level and some dont. It is the job of the LER/L= SR to >>>>>>>>> parse the timing message and find out the type of the Timing me= ssage >>>>>>>>> and decide whether and how to Time- stamp it (e.g., BC) or upda= te >>>>>>>>> correction field(e.g., TC). >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing= >>>>>>>>> SB> function rather than the LER? >>>>>>>>>=20 >>>>>>>>> For example the following PTP messages (called Event messages) >>>>>>>>> require time-stamping or correction field update: >>>>>>>>>=20 >>>>>>>>> o SYNC >>>>>>>>>=20 >>>>>>>>> o DELAY_REQ (Delay Request) >>>>>>>>>=20 >>>>>>>>> o PDELAY_REQ (Peer Delay Request) >>>>>>>>>=20 >>>>>>>>> o PDELAY_RESP (Peer Delay Response) >>>>>>>>>=20 >>>>>>>>> SYNC and DELAY_REQ are exchanged between Master Clock and Slave= >>>>>> Clock >>>>>>>>> and MUST be transported over PTP LSPs. PDELAY_REQ and >>>>>> PDELAY_RESP >>>>>>>>> are exchanged between adjacent PTP clocks (i.e. Master, Slave,= >>>>>>>>> Boundary, or Transparent) and SHOULD be transported over single= hop >>>>>>>>> PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_= UP, >>>>>>>>> and PDELAY_RESP_FOLLOW_UP messages MUST also be transported >>>>>> over >>>>>>>>> the >>>>>>>>> PTP LSPs. >>>>>>>>>=20 >>>>>>>>> For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST b= e >>>>>>>>> transported over two PTP LSPs that are in opposite directions. = These >>>>>>>>> PTP LSPs, which are in opposite directions MUST be congruent an= d co- >>>>>>>>> routed. Alternatively, a single bidirectional co-routed LSP ca= n be >>>>>>>>> used. >>>>>>>>>=20 >>>>>>>>> Except as indicated above for the two-step PTP clocks, Non-Even= t PTP >>>>>>>>> message types do not need to be processed by intermediate route= rs. >>>>>>>>> These message types MAY be carried in PTP Tunnel LSPs. >>>>>>>>>=20 >>>>>>>>> SB> Are you saying that a timing P router has to be msg type sensi= tive? >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 15] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 8. Protection and Redundancy >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> SB> This is a bit of a jump - I don't know how the LSP itself work= s yet! >>>>>>>>>=20 >>>>>>>>> In order to ensure continuous uninterrupted operation of slave >>>>>>>>> clocks, usually as a general practice, slave clocks (or ports) t= rack >>>>>>>>> redundant master clocks. >>>>>>>>>=20 >>>>>>>>> It is the responsibility of the network operator to ensure that= >>>>>>>>> physically disjoint Timing LSPs are established between a slave= clock >>>>>>>>> (or port) and redundant master clocks (or ports). >>>>>>>>>=20 >>>>>>>>> When a slave clock (or port) listens to redundant master clocks= or >>>>>>>>> ports, any prolonged Timing LSP outage will trigger the slave c= lock >>>>>>>>> or port to switch to a redundant master clock or port. >>>>>>>>>=20 >>>>>>>>> LSP/PW protection such as Linear protection Switching (1:1, 1+1= ), >>>>>>>>> Ring protection switching or MPLS Fast Reroute (FRR) generally s= witch >>>>>>>>> alternative path that usually cause a change in delay, which if= >>>>>>>>> undetected by slave clock can reduce accuracy of the slave cloc= k. >>>>>>>>>=20 >>>>>>>>> Therefore protection switching MAY be used, as long as phase ju= mps >>>>>>>>> upon switchover due to differences in path latency are detected= and >>>>>>>>> compensated for (such compensation not being required if BCs or= peer- >>>>>>>>> peer TCs are used throughout). >>>>>>>>>=20 >>>>>>>>> Note that any protection or reroute mechanism that adds additio= nal >>>>>>>>> MPLS label to the label stack, such as Facility Backup Fast Rer= oute, >>>>>>>>> MUST ensure that the pushed label is also a Timing Label to ens= ure >>>>>>>>> recognition of the MPLS frame as containing Timing messages, as= it >>>>>>>>> transits the backup path. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 16] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 9. ECMP >>>>>>>>>=20 >>>>>>>>> To ensure the optimal operation of slave clocks and avoid error= >>>>>>>>> introduced by forward and reverse path delay asymmetry, the phy= sical >>>>>>>>> path for Timing messages from master clock to slave Clock and v= ice >>>>>>>>> versa must be the same for all Event Timing messages listed in >>>>>>>>> section 7. >>>>>>>>>=20 >>>>>>>>> Therefore the Timing LSPs MUST not be subject to ECMP (Equal Co= st >>>>>>>>> Multipath). >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 17] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 10. PHP >>>>>>>>>=20 >>>>>>>>> To ensure that the label on the top of the label stack is the T= iming >>>>>>>>> LSP Label, PHP MUST not be used. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 18] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 11. Entropy >>>>>>>>>=20 >>>>>>>>> To ensure all Timing messages in a Timing LSP take the same pat= h, >>>>>>>>> Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and >>>>>>>>> Entropy Label MUST NOT be used for the PWs that are carried ins= ide >>>>>>>>> Timing LSP [RFC6391]. >>>>>>>>>=20 >>>>>>>>> SB> This is incorrect - you mean that all msgs of the same timing >>>>>>>>> SB> flow need to have the same EL value. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 19] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 12. OAM, Control and Management >>>>>>>>>=20 >>>>>>>>> In order to monitor Timing LSPs and their encapsulated PWs, the= y MUST >>>>>>>>> be able to carry OAM and management messages. These management= >>>>>>>>> messages MUST be differentiated from Timing messages via alread= y >>>>>>>>> defined IETF methods. >>>>>>>>>=20 >>>>>>>>> For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY= run >>>>>>>>> over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These= >>>>>>>>> Management protocols can easily be identified by the UDP Destin= ation >>>>>>>>> Port number or by GAL/G-ACH respectively. >>>>>>>>>=20 >>>>>>>>> Also BFD, LSP-Ping and other management messages MAY run over t= he >>>>>> PWs >>>>>>>>> encapsulated in Timing LSP via one of the defined VCCVs (Type 1= , 3 or >>>>>>>>> 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is= going >>>>>>>>> to be deprecated by IETF). In this case G-ACH, PW label (TTL=3D= 1) or >>>>>>>>> GAL-ACH are used to identify such management messages. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 20] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 13. QoS Considerations >>>>>>>>>=20 >>>>>>>>> In network deployments where not every LSR/LER is Timing-aware,= it is >>>>>>>>> important to reduce the impact of the non-Timing-aware LSR/LERs= on >>>>>>>>> the timing recovery in the slave clock. The Timing messages ar= e time >>>>>>>>> critical and must be treated with the highest priority. Theref= ore >>>>>>>>> Timing over MPLS messages must be treated with the highest prio= rity >>>>>>>>> in the routers. This can be achieved by proper setup of Timing= LSPs. >>>>>>>>>=20 >>>>>>>>> It is recommended that the Timing LSPs are setup or configured >>>>>>>>> properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC= 2697] >>>>>>>>> for drop eligibility. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 21] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 14. FCS and Checksum Recalculation >>>>>>>>>=20 >>>>>>>>> When time-stamp generation and timing packet adjustment is perf= ormed >>>>>>>>> near the physical port hardware, the process MUST include >>>>>>>>> recalculation of the Ethernet FCS. >>>>>>>>>=20 >>>>>>>>> SB> The above is confusing - an LSR always recomputes the link lay= er >>>>>>>>> SB> CRC which may or may not be Ethernet. >>>>>>>>>=20 >>>>>>>>> Also FCS retention for the >>>>>>>>> payload Ethernet described in [RFC4720] MUST NOT be used. >>>>>>>>>=20 >>>>>>>>> For UDP/IP encapsulation mode of Timing over MPLS, the UDP chec= ksum >>>>>>>>> may be required as per UDP transport standards. >>>>>>>>>=20 >>>>>>>>> SB> You really need to be working on getting the IPv6 C?S computat= ion >>>>>>>>> SB> removed from PTP msgs. >>>>>>>>>=20 >>>>>>>>> When UDP checksum is used, each Timing-aware LER/LSR must eithe= r >>>>>>>>> incrementally update the UDP checksum after Time stamping or >>>>>>>>> Correction Field update or verify the UDP checksum on reception= from >>>>>>>>> upstream and recalculate the checksum completely on transmissio= n to >>>>>>>>> downstream node after Time stamping or Correction Field update.= >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 22] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 15. Behavior of LER/LSR >>>>>>>>>=20 >>>>>>>>> Timing-capable/aware LERs and LSRs are routers that have one or= more >>>>>>>>>=20 >>>>>>>>> SB> You mean physical interfaces? >>>>>>>>>=20 >>>>>>>>> interfaces that can perform Timing operations (OC/BC/TC) on Tim= ing >>>>>>>>> packets and are configured to do so. Timing-capable/aware LERs= and >>>>>>>>> LSRs can advertise their Timing-capability per-interface via co= ntrol >>>>>>>>> plane such as OSPF or IS-IS. >>>>>>>>> SB> ISIS and OSPF are routing protocols. >>>>>>>>>=20 >>>>>>>>> The Timing-capable/aware LERs can then >>>>>>>>> signals Timing LSPs via RSVP-TE signaling. Alternatively the T= iming >>>>>>>>> capability of LER and LSRs may be configured in a centralized >>>>>>>>> controller and the Timing LSP may be setup using manual configu= ration >>>>>>>>> or other methods such as SDN. >>>>>>>>>=20 >>>>>>>>> SB> it can also be configured individually rather then through >>>>>>>>> SB> a cebtral controllwe >>>>>>>>>=20 >>>>>>>>> 15.1. Behavior of Timing-capable/aware LER >>>>>>>>>=20 >>>>>>>>> When a Timing-capable/aware LER behaves as a Transparent clock a= nd >>>>>>>>> receives a Timing message from a Timing-capable/aware non-MPLS >>>>>>>>> interface, the LER updates the Correction Field (CF) and encaps= ulates >>>>>>>>> and forwards the timing message over previously established Tim= ing >>>>>>>>> LSP. >>>>>>>>>=20 >>>>>>>>> SB> You need to call out the details so that people properly >>>>>>>>> SB> understand the definition of the new LSP. >>>>>>>>>=20 >>>>>>>>> Also when a Timing message is received from a Timing-capable/ >>>>>>>>> aware MPLS interface, LER updates the Correction Filed (CF) and= >>>>>>>>> decapsulates the MPLS encapsulation and forwards the timing mes= sage >>>>>>>>> to a non-MPLS interface. >>>>>>>>>=20 >>>>>>>>> When a Timing-capable/aware LER behaves as a Boundary clock and= >>>>>>>>> receives a Timing message from a Timing-capable/aware non MPLS >>>>>>>>> interface, the LER Timestamps the Timing packet and sends it to= the >>>>>>>>> LERs Boundary clock processing module. Also when a Timing mess= age is >>>>>>>>> received from a Timing- capable/aware MPLS interface, the LER >>>>>>>>> Timestamps the Timing packet and sends it to the LERs Boundary c= lock >>>>>>>>> processing module. >>>>>>>>>=20 >>>>>>>>> When a Timing-capable/aware LER behaves as an Ordinary Clock to= ward >>>>>>>>> the MPLS network, and receives a Timing message from a Timing- >>>>>>>>> capable/aware MPLS interface, the LER Timestamps the Timing pac= ket >>>>>>>>> and sends it to the LERs Ordinary clock processing module. >>>>>>>>>=20 >>>>>>>>> 15.2. Behavior of Timing-capable/aware LSR >>>>>>>>>=20 >>>>>>>>> When a Timing-capable/aware LSR behaves as a Transparent clock a= nd >>>>>>>>> receives a Timing message from a Timing-capable/aware MPLS >>>>>> interface, >>>>>>>>> The LSR updates the Correction Filed (CF) and forwards the timi= ng >>>>>>>>> message over another MPLS interface. >>>>>>>>>=20 >>>>>>>>> When a Timing-capable/aware LSR behaves as a Boundary clock and= >>>>>>>>> receives a Timing message from a Timing-capable/aware MPLS >>>>>> interface. >>>>>>>>> The LSR performs the functions of a Boundary Clock in terminati= ng the >>>>>>>>> received Timing message and re-generating a new timing message o= ver >>>>>>>>> another (or the same) MPLS interface. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 23] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 15.3. Behavior of non-Timing-capable/aware LSR >>>>>>>>>=20 >>>>>>>>> It is most beneficial when all LSRs in the path of a Timing LSP= be >>>>>>>>> timing-Capable/aware LSRs. This would ensure the highest quali= ty >>>>>>>>> time and clock synchronization by Timing Slave Clocks. However= , this >>>>>>>>> specification does not mandate that all LSRs in path of a Timin= g LSP >>>>>>>>> be Timing- capable/aware. >>>>>>>>>=20 >>>>>>>>> Non-Timing-capable/aware LSRs just switch the packets encapsula= ted in >>>>>>>>> Timing LSPs and dont perform any Timing operation (TC or BC). >>>>>>>>> However as explained in QoS section the Timing over MPLS packet= s >>>>>> MUST >>>>>>>>> be still be treated with the highest priority based on their Tr= affic >>>>>>>>> Class (TC) marking. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 24] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 16. Other considerations >>>>>>>>>=20 >>>>>>>>> [IEEE-1588] defines an optional peer-to-peer Transparent clocki= ng >>>>>>>>> that requires peer delay measurement between two adjacent Timin= g- >>>>>>>>> capable/ aware routers/switches. Peer delay measurement messag= es >>>>>>>>> need to be time stamped and terminated by the Timing-capable/aw= are >>>>>>>>> routers/ switches. This means that two adjacent LSRs may be en= gaged >>>>>>>>> in a peer delay measurement. >>>>>>>>>=20 >>>>>>>>> For transporting such peer delay measurement messages a single-= hop >>>>>>>>> LSP SHOULD to be created between the two adjacent LSRs engaged i= n >>>>>>>>> peer delay measurement to carry peer delay measurement messages= . >>>>>>>>> Other methods such as PTP transport over Ethernet MAY be used f= or >>>>>>>>> transporting peer delay measurement messages if the link betwee= n the >>>>>>>>> two routers is Ethernet. >>>>>>>>>=20 >>>>>>>>> In Peer-to-peer transparent clocking (P2P TC), a Timing-capable= / ware >>>>>>>>> routers/switches MUST maintain a list of all the neighbors it n= eeds >>>>>>>>> to send a PDelay_Req to, where each neighbor corresponds to a t= iming >>>>>>>>> LSP. >>>>>>>>>=20 >>>>>>>>> The use of Explicit Null Label (Label=3D 0 or 2) is acceptable a= s long >>>>>>>>> as either the Explicit Null label is the bottom of stack label >>>>>>>>> (applicable only to UDP/IP encapsulation) or the label below th= e >>>>>>>>> Explicit Null label is a PTP label. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 25] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 17. Security Considerations >>>>>>>>>=20 >>>>>>>>> MPLS PW security considerations in general are discussed in [RFC= 3985] >>>>>>>>> and [RFC4447],and those considerations also apply to this docum= ent. >>>>>>>>>=20 >>>>>>>>> An experimental security protocol is defined in [IEEE-1588].The= PTP >>>>>>>>> security extension and protocol provides group source authentic= ation, >>>>>>>>> message integrity, and replay attack protection for PTP message= s. >>>>>>>>>=20 >>>>>>>>> When the MPLS network (provider network) serves multiple custom= ers, >>>>>>>>> it is important to maintain and process each customers clock an= d >>>>>>>>> Timing messages separately from other customers to ensure there= is no >>>>>>>>> cross- customer effect. For example if an LER BC is synchroniz= ed to >>>>>>>>> a specific grandmaster, belonging to customer A, then the LER M= UST >>>>>>>>> use that BC clock only for customer A to ensure that customer A= >>>>>>>>> cannot attack other customers by manipulating its time. >>>>>>>>>=20 >>>>>>>>> Timing messages MAY be encrypted or authenticated, provided tha= t the >>>>>>>>> LERs/LSRs that are Timing capable/aware can authenticate/ decry= pt the >>>>>>>>> timing messages. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 26] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 18. Acknowledgements >>>>>>>>>=20 >>>>>>>>> The authors would like to thank Ron Cohen, Yaakov Stein, Tal Mi= zrahi, >>>>>>>>> Stefano Ruffini, Peter Meyer, and other members of IETF for rev= iewing >>>>>>>>> and providing feedback on this draft. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 27] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 19. IANA Considerations >>>>>>>>>=20 >>>>>>>>> There are no IANA requirements in this specification. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 28] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 20. References >>>>>>>>>=20 >>>>>>>>> 20.1. Normative References >>>>>>>>>=20 >>>>>>>>> [IEEE-1588] >>>>>>>>> IEEE 1588-2008, "IEEE Standard for a Precision Clock= >>>>>>>>> Synchronization Protocol for Networked Measurement a= nd >>>>>>>>> Control Systems". >>>>>>>>>=20 >>>>>>>>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >>>>>>>>> Requirement Levels", BCP 14, RFC 2119, March 1997. >>>>>>>>>=20 >>>>>>>>> [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-= to- >>>>>>>>> Edge (PWE3) Architecture", RFC 3985, March 2005. >>>>>>>>>=20 >>>>>>>>> [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Disc= overy >>>>>>>>> Proxies (ND Proxy)", RFC 4389, April 2006. >>>>>>>>>=20 >>>>>>>>> [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and= G. >>>>>>>>> Heron, "Pseudowire Setup and Maintenance Using the L= abel >>>>>>>>> Distribution Protocol (LDP)", RFC 4447, April 2006. >>>>>>>>>=20 >>>>>>>>> [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, >>>>>>>>> "Encapsulation Methods for Transport of Ethernet ove= r MPLS >>>>>>>>> Networks", RFC 4448, April 2006. >>>>>>>>>=20 >>>>>>>>> [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire >>>>>>>>> Emulation Edge-to-Edge (PWE3) Frame Check Sequence >>>>>>>>> Retention", RFC 4720, November 2006. >>>>>>>>>=20 >>>>>>>>> [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Cir= cuit >>>>>>>>> Connectivity Verification (VCCV): A Control Channel f= or >>>>>>>>> Pseudowires", RFC 5085, December 2007. >>>>>>>>>=20 >>>>>>>>> [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Dete= ction >>>>>>>>> (BFD)", RFC 5880, June 2010. >>>>>>>>>=20 >>>>>>>>> [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swall= ow, >>>>>>>>> "Bidirectional Forwarding Detection (BFD) for MPLS L= abel >>>>>>>>> Switched Paths (LSPs)", RFC 5884, June 2010. >>>>>>>>>=20 >>>>>>>>> 20.2. Informative References >>>>>>>>>=20 >>>>>>>>> [I-D.ietf-pwe3-fat-pw] >>>>>>>>> Bryant, S., Filsfils, C., Drafz, U., Kompella, V., R= egan, >>>>>>>>> J., and S. Amante, "Flow Aware Transport of Pseudowi= res >>>>>>>>> over an MPLS Packet Switched Network", >>>>>>>>> draft-ietf-pwe3-fat-pw-07 (work in progress), July 2= 011. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 29] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermed= iate >>>>>>>>> system routeing information exchange protocol for us= e in >>>>>>>>> conjunction with the Protocol for providing the >>>>>>>>> Connectionless-mode Network Service (ISO 8473)". >>>>>>>>>=20 >>>>>>>>> [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP a= nd >>>>>>>>> dual environments", RFC 1195, December 1990. >>>>>>>>>=20 >>>>>>>>> [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1= 998. >>>>>>>>>=20 >>>>>>>>> [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Col= or >>>>>>>>> Marker", RFC 2697, September 1999. >>>>>>>>>=20 >>>>>>>>> [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Bo= udec, >>>>>>>>> J., Courtney, W., Davari, S., Firoiu, V., and D. >>>>>>>>> Stiliadis, "An Expedited Forwarding PHB (Per-Hop >>>>>>>>> Behavior)", RFC 3246, March 2002. >>>>>>>>>=20 >>>>>>>>> [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engin= eering >>>>>>>>> (TE) Extensions to OSPF Version 2", RFC 3630, >>>>>>>>> September 2003. >>>>>>>>>=20 >>>>>>>>> [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermed= iate >>>>>>>>> System (IS-IS) Extensions for Traffic Engineering (T= E)", >>>>>>>>> RFC 3784, June 2004. >>>>>>>>>=20 >>>>>>>>> [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., an= d S. >>>>>>>>> Shaffer, "Extensions to OSPF for Advertising Optiona= l >>>>>>>>> Router Capabilities", RFC 4970, July 2007. >>>>>>>>>=20 >>>>>>>>> [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermedia= te >>>>>>>>> System to Intermediate System (IS-IS) Extensions for= >>>>>>>>> Advertising Router Information", RFC 4971, July 2007= . >>>>>>>>>=20 >>>>>>>>> [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Mul= ti >>>>>>>>> Topology (MT) Routing in Intermediate System to >>>>>>>>> Intermediate Systems (IS-ISs)", RFC 5120, February 2= 008. >>>>>>>>>=20 >>>>>>>>> [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic >>>>>>>>> Engineering", RFC 5305, October 2008. >>>>>>>>>=20 >>>>>>>>> [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, >>>>>>>>> "Traffic Engineering Extensions to OSPF Version 3", >>>>>>>>> RFC 5329, September 2008. >>>>>>>>>=20 >>>>>>>>> [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "O= SPF >>>>>>>>> for IPv6", RFC 5340, July 2008. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 30] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "N= etwork >>>>>>>>> Time Protocol Version 4: Protocol and Algorithms >>>>>>>>> Specification", RFC 5905, June 2010. >>>>>>>>>=20 >>>>>>>>> [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., R= egan, >>>>>>>>> J., and S. Amante, "Flow-Aware Transport of Pseudowi= res >>>>>>>>> over an MPLS Packet Switched Network", RFC 6391, >>>>>>>>> November 2011. >>>>>>>>>=20 >>>>>>>>> [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W.,= and >>>>>>>>> L. Yong, "The Use of Entropy Labels in MPLS Forwardi= ng", >>>>>>>>> RFC 6790, November 2012. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 31] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 1. Routing extensions for Timing-aware Routers >>>>>>>>>=20 >>>>>>>>> MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340= ] and >>>>>>>>> IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering= (TE) >>>>>>>>> link information used for constraint-based routing. >>>>>>>>>=20 >>>>>>>>> Indeed, it is useful to advertise data plane TE router link >>>>>>>>> capabilities, such as the capability for a router to be Timing-= aware. >>>>>>>>> This capability MUST then be taken into account during path >>>>>>>>> computation to prefer or even require links that advertise them= selves >>>>>>>>> as Timing-aware. In this way the path can ensure the entry and= exit >>>>>>>>> points into the LERs and, if desired, the links into the LSRs a= re >>>>>>>>> able to perform port based time-stamping thus minimizing their i= mpact >>>>>>>>> on the performance of the slave clock. >>>>>>>>>=20 >>>>>>>>> extensions are required to OSPF and IS-IS in order to advertise= >>>>>>>>> Timing-aware capabilities of a link. Such extensions are outsi= de the >>>>>>>>> scope of this document; however such extension SHOULD be able t= o >>>>>>>>> signal the following information per Router Link: >>>>>>>>>=20 >>>>>>>>> o Capable of processing PTP, NTP or other Timing flows >>>>>>>>>=20 >>>>>>>>> o Capable of performing Transparent Clock operation >>>>>>>>>=20 >>>>>>>>> o Capable of performing Boundary Clock operation >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 32] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 2. Signaling Extensions for Creating Timing LSPs >>>>>>>>>=20 >>>>>>>>> RSVP-TE signaling MAY be used to setup the timing LSPs. When R= SVP-TE >>>>>>>>> is used to setup Timing LSPs, some information that indicates t= hat >>>>>>>>> the LSP is carrying Timing flows MUST be included in the new >>>>>>>>> Extensions to RSVP-TE: >>>>>>>>>=20 >>>>>>>>> The following information MAY also be included in the new Exten= sions >>>>>>>>> to RSVP-TE: >>>>>>>>>=20 >>>>>>>>> o Offset from Bottom of Stack (BoS) to the start of the Time-s= tamp >>>>>>>>> field >>>>>>>>>=20 >>>>>>>>> o Number of VLANs in case of PW encapsulation >>>>>>>>>=20 >>>>>>>>> o Timestamp field Type >>>>>>>>>=20 >>>>>>>>> * Correction Field, Timestamp >>>>>>>>>=20 >>>>>>>>> o Timestamp Field format >>>>>>>>>=20 >>>>>>>>> * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-b= it >>>>>>>>> NTP, etc. >>>>>>>>>=20 >>>>>>>>> Note that in case the above optional information is signaled wi= th >>>>>>>>> RSVP-TE for a Timing LSP, all the Timing packets carried in tha= t LSP >>>>>>>>> must have the same signaled characteristics. For example if >>>>>>>>> Timestamp format is signaled as 64-bit PTPv1, then all Timing p= ackets >>>>>>>>> must use 64-bit PTPv1 time-stamp. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 33] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Authors' Addresses >>>>>>>>>=20 >>>>>>>>> Shahram Davari >>>>>>>>> Broadcom Corp. >>>>>>>>> San Jose, CA 95134 >>>>>>>>> USA >>>>>>>>>=20 >>>>>>>>> Email: davari@broadcom.com >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Amit Oren >>>>>>>>> Broadcom Corp. >>>>>>>>> San Jose, CA 95134 >>>>>>>>> USA >>>>>>>>>=20 >>>>>>>>> Email: amito@broadcom.com >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Manav Bhatia >>>>>>>>> Alcatel-Lucent >>>>>>>>> Bangalore, >>>>>>>>> India >>>>>>>>>=20 >>>>>>>>> Email: manav.bhatia@alcatel-lucent.com >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Peter Roberts >>>>>>>>> Alcatel-Lucent >>>>>>>>> Kanata, >>>>>>>>> Canada >>>>>>>>>=20 >>>>>>>>> Email: peter.roberts@alcatel-lucent.com >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Laurent Montini >>>>>>>>> Cisco Systems >>>>>>>>> San Jose CA >>>>>>>>> USA >>>>>>>>>=20 >>>>>>>>> Email: lmontini@cisco.com >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 34] >>>>>>>>> Internet-Draft Transporting Timing over MPLS Jun= e 2013 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Luca >>>>>>>>> Cisco Systems >>>>>>>>> San Jose CA >>>>>>>>> USA >>>>>>>>>=20 >>>>>>>>> Email: lmartini@cisco.com >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Davari, et al. Expires December 17, 2013 [Pa= ge 35] >>>>>>>>> -- >>>>>>>>> For corporate legal information go to: >>>>>>>>>=20 >>>>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html= >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> TICTOC mailing list >>>>>>>>> TICTOC@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/tictoc >>>>>>>> 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 info= rm us by e- >>>>>> mail, phone or fax, and then delete the original and all copies there= of. >>>>>>>> _______________________________________________ >>>>>>>> mpls mailing list >>>>>>>> mpls@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>> . >>>>>> -- >>>>>> For corporate legal information go to: >>>>>>=20 >>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>>=20 >>>>>> _______________________________________________ >>>>>> TICTOC mailing list >>>>>> TICTOC@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tictoc >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> TICTOC mailing list >>>>>> TICTOC@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tictoc >>>>> This e-mail message is intended for the recipient only and contains in= formation 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 >>> -- >>> For corporate legal information go to: >>>=20 >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>=20 >>> This e-mail message is intended for the recipient only and contains info= rmation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. >> This e-mail message is intended for the recipient only and contains infor= mation 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, p= hone or fax, and then delete the original and all copies thereof. >>=20 >> . >=20 >=20 > --=20 > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 From stbryant@cisco.com Wed Aug 21 08:22:40 2013 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 0764411E8112; Wed, 21 Aug 2013 08:22:40 -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 KJh89uP-Vdm6; Wed, 21 Aug 2013 08:22:34 -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 0851521F9C00; Wed, 21 Aug 2013 08:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=362; q=dns/txt; s=iport; t=1377098554; x=1378308154; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=8atm9my2TbSk2JwQNT/n6LDv+MzBWZSGzQMIOKJgWmI=; b=mBHnIe+n+4Am4yLydb2kmEl/0cuRGV+A1r/SxXBF2NuJhxbJ5vntd54i 4JSvqYRx1q8Wm4iMCELOwOnTXQFfxeVF3P3j1bjcvT6nWbpbzNP2F7veA R9ekada7wgA8Eit8sYYEk2wbbdb+cj2qtXHSQE3z8nXnMVoOTtKbY/ktq U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAHjaFFKQ/khM/2dsb2JhbABagwW9Z4J6gR8WdIIkAQEBBDhAARALGAkWDwkDAgECAUUGDQEHAQGIDK1ckFUHhBQDl2WRVoMd X-IronPort-AV: E=Sophos;i="4.89,928,1367971200"; d="scan'208";a="158727268" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 21 Aug 2013 15:22:27 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7LFMPsG019998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Aug 2013 15:22:26 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r7LFMLEQ007322; Wed, 21 Aug 2013 16:22:21 +0100 (BST) Message-ID: <5214DB2D.2000809@cisco.com> Date: Wed, 21 Aug 2013 16:22:21 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "S. Davari" References: <51FB7543.801@cisco.com> <51FF7068.9080600@cisco.com> <4A6CE49E6084B141B15C0713B8993F281BEC731A@SJEXCHMB12.corp.ad.broadcom.com> <52139903.8040801@cisco.com> <52149A2D.3050109@cisco.com> <5ADB2697-BC53-427A-82DB-013B89029343@yahoo.com> In-Reply-To: <5ADB2697-BC53-427A-82DB-013B89029343@yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] Comments on draft-ietf-tictoc-1588overmpls 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, 21 Aug 2013 15:22:40 -0000 yes, but they are one hop tunnels. S On 21/08/2013 15:19, S. Davari wrote: > Hi Stewart, > > Your proposal does tunneling between timing aware nodes but I guess it stitches multiple of those tunnels to create and end-2-end connection. Right? > > Sasha's BoS proposal seems simpler, since it requires a single end-2-end LSP. > > Regards, > Shahram From stbryant@cisco.com Wed Aug 21 08:27:06 2013 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 398E621F9D28; Wed, 21 Aug 2013 08:27:06 -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 XsiVkH9d-SEb; Wed, 21 Aug 2013 08:27:00 -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 194AE11E8244; Wed, 21 Aug 2013 08:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=347; q=dns/txt; s=iport; t=1377098819; x=1378308419; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=y/+Ur8/yLSt/dJyTVLt0HyzK9KrG8bB9kXkE+bRbhgQ=; b=XmCnZt4U5A/XIJ3hz0LM2RDI7ymrWM5XrUbI4GesqQWA1fwLJ2ADVPAl lyIlDVuQrnBaTl2qs/ga5uXy8oF3ThtS5evHDysETHtcx0nLIfEq7q0zY tPQv3A6v78dJSmAMJHreJNpab298lNnUhgJYtVH322rPEVY+M53JW2rNc o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAJzbFFKQ/khL/2dsb2JhbABagwW9Z4J6gR8WdIIkAQEBBDhAARALGAkWDwkDAgECAUUGDQEHAQGIDK1bkFUHhBQDl2WRVoMd X-IronPort-AV: E=Sophos;i="4.89,928,1367971200"; d="scan'208";a="158727512" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 21 Aug 2013 15:26:56 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7LFQshp018325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Aug 2013 15:26:55 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r7LFQre5007754; Wed, 21 Aug 2013 16:26:54 +0100 (BST) Message-ID: <5214DC3D.6050206@cisco.com> Date: Wed, 21 Aug 2013 16:26:53 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "S. Davari" References: <51FB7543.801@cisco.com> <51FF7068.9080600@cisco.com> <4A6CE49E6084B141B15C0713B8993F281BEC731A@SJEXCHMB12.corp.ad.broadcom.com> <52139903.8040801@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] Comments on draft-ietf-tictoc-1588overmpls 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, 21 Aug 2013 15:27:06 -0000 On 20/08/2013 18:00, S. Davari wrote: > Sasha > > In (2) are you proposing to create multiple segment LSPs, where each if those segment LSPs span between two Timing aware LSR? So if I have 10 timing aware LSR in the path I would need 9 LSPs? > > Regards, > Shahram Maybe, or maybe the path is held in the application payload. Stewart From iwijnand@cisco.com Wed Aug 21 08:44:25 2013 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 9E68F11E8223 for ; Wed, 21 Aug 2013 08:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmX8PuIvuJ8n for ; Wed, 21 Aug 2013 08:44:20 -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 B202111E8107 for ; Wed, 21 Aug 2013 08:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3122; q=dns/txt; s=iport; t=1377099860; x=1378309460; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ro+PINuCEsXpRvHtT+qVIwbWFoQGtipd/18QXy4YjQo=; b=mRpVdJ3vQ3QNNIxZM33fOMb1iGSFLSj5U368FK9NKcf8RtWeP8PBDXiQ /mGgJYqSKJIqqFCW9X/ylTcaDSX6SISxiZG5v3M/58NeVDTnagpQZJmhy KiIpdHq2NGP9wyV9w/23iEodFetpocH+xDCFIxWkztnaPfcgw6R6Tcdu8 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgFAKPfFFKtJXG9/2dsb2JhbABagwU1Ub9kgR8WbQeCJAEBAQMBAQEBNzEDBgUFCQICASoUEBsMCyUCBA4FCBOHbwYMrVoEBI8IEIEIMQeDG3kDqTqDHYFyOQ X-IronPort-AV: E=Sophos;i="4.89,928,1367971200"; d="scan'208";a="250044940" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 21 Aug 2013 15:44:19 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7LFiJJw012718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Aug 2013 15:44:19 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.172]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 21 Aug 2013 10:44:19 -0500 From: "IJsbrand Wijnands (iwijnand)" To: "mpls@ietf.org" Thread-Topic: Comments on draft-rekhter-mpls-pim-sm-over-mldp Thread-Index: AQHOnoVMwyh2C5bFv029J29aw104pQ== Date: Wed, 21 Aug 2013 15:44:18 +0000 Message-ID: References: <521475A6.7080002@pi.nu> In-Reply-To: <521475A6.7080002@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.191.147] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] Comments on draft-rekhter-mpls-pim-sm-over-mldp 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, 21 Aug 2013 15:44:25 -0000 Dear WG, Before deciding whether to accept draft-rekhter-mpls-pim-sm-over-mldp as a = WG draft, we need to understand how it is positioned against several other = drafts that address the same topic. There are several other drafts that address the same topic, see draft-ietf-= mpls-seamless-mcast-04, section 6.3. "PIM-SM in ASM mode for Global Table M= ulticast" and draft-zzhang-l3vpn-mvpn-global-table-mcast-00. These drafts p= rovide full support for both the ASM and SSM modes of PIM, and also support= the use of mLDP in the core. Draft-rekhter-mpls-pim-sm-over-mldp augments the mldp-in-band signalling pr= ocedures so that they can be used in environments where dynamic multicast s= ource discovery is required. It does this by adding back some of the MVPN B= GP signalling, using a combination of BGP signalling and mLDP in-band signa= lling. The question is whether this is really useful. If BGP multicast sign= aling needs to be used anyway, why not just use the solution from the seaml= ess-mcast or global-table-mcast drafts? What's the point of combining it wi= th mLDP in-band signalling? The main advantage of using mLDP in-band signal= ing is that it doesn't require any additional multicast signalling protocol= s in the core.=20 Before we accept draft-rekhter-mpls-pim-sm-over-mldp as a WG document we sh= ould determine whether there are any Service Providers who actually want to= deploy the combination of mLDP in-band signalling and BGP multicast signal= ling. Thx, Ice. On 21 Aug 2013, at 10:09, Loa Andersson wrote: > Working Group, >=20 > The authors of draft-rekhter-mpls-pim-sm-over-mldp has told the > working group chairs that the draft is ready to be adopted as a working > group document. >=20 > Before we start the mpls-rt review and the poll for adoption we will do > an IPR poll. >=20 > This mail starts that IPR poll. >=20 > Are you aware of any IPR that applies to draft-rekhter-mpls-pim- > sm-over-mldp? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The doc= uments will not advance to the next stage until a response > has been received from each author and contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. >=20 >=20 > Thanks, Loa > (as MPLS WG co-chair) > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From Malcolm.BETTS@zte.com.cn Wed Aug 21 08:44:49 2013 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 5EC7111E8240; Wed, 21 Aug 2013 08:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.998 X-Spam-Level: X-Spam-Status: No, score=-101.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSIjH2PmfkiV; Wed, 21 Aug 2013 08:44:42 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id B55E711E8107; Wed, 21 Aug 2013 08:44:41 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 0ADE11319193; Wed, 21 Aug 2013 23:44:07 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r7LFiE2a009274; Wed, 21 Aug 2013 23:44:14 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF642C376@eusaamb107.ericsson.se> References: <20ECF67871905846A80F77F8F4A27572102C229B@xmb-rcd-x09.cisco.com> <20ECF67871905846A80F77F8F4A27572102EB9C5@xmb-rcd-x09.cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF642C376@eusaamb107.ericsson.se> To: Eric Gray MIME-Version: 1.0 X-KeepSent: E27F82E3:4D7CEC71-85257BCE:0056087F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Wed, 21 Aug 2013 11:43:53 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-08-21 23:43:59, Serialize complete at 2013-08-21 23:43:59 Content-Type: multipart/alternative; boundary="=_alternative 0056794E85257BCE_=" X-MAIL: mse02.zte.com.cn r7LFiE2a009274 Cc: "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject: Re: [mpls] Mode negotiation for PSC 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, 21 Aug 2013 15:44:49 -0000 This is a multipart message in MIME format. --=_alternative 0056794E85257BCE_= Content-Type: text/plain; charset="US-ASCII" Hi Eric (Gray), I agree that we should not negotiate PSC modes "on the fly", since selecting different options will result in different behaviour in the network any negotiation should involve a human i..e reporting the miss match is all that we need to do. As I pointed out below "negotiation" of the PSC options should take place before the LSP is set-up, PSC should only check that the options selected match (and report a miss match). Regards, Malcolm Eric Gray 20/08/2013 02:41 PM To "Eric Osborne (eosborne)" , "Malcolm.BETTS@zte.com.cn" cc "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject RE: [mpls] Mode negotiation for PSC Eric (Osborne), While I agree that we don't want to try to predict what will never ever happen, there is more than a little bit of an issue with designing for all possible cases. Before we can really get away with any approach that could conceivably include N^2 combinations of options, we need to describe what each of these possibilities means, and how devices with arbitrary disagreement for the options resolve the differences. And - while we're trying to cover the possible cases for known modes, should we also try to allow for coverage of future (thus unknown) modes? Is this worth the trouble? Are there use cases to support this, or are we embarking on an academic exercise? What we really need now is a simple binary indicator. If we feel that any negotiation is required, then it should be trivial. If there is disagreement, then everbody falls-back to a default mode. But I am not convinced that any form of negotiation is required. In this discussion, I am reminded that at least part of the discussion that got us on the road of having two modes had to do with limited negotiation in the case where PSC parameters did not match. I believe that the decision was that reporting the inconsistency to the operator was sufficient from the perspective of any of us in the IETF, and that this was not sufficient to folks used to dealing with APS. So, are we switching from what was essentially non-negotiation of PSC parameters to negotiation of PSC modes? Seems counter-intuitive to me... -- Eric (Gray) -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Osborne (eosborne) Sent: Friday, August 16, 2013 4:49 PM To: Malcolm.BETTS@zte.com.cn Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] Mode negotiation for PSC Hi Malcolm- Thanks for this. A few comments inline. > -----Original Message----- > From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] > Sent: Thursday, August 15, 2013 1:01 PM > To: Eric Osborne (eosborne) > Cc: mpls@ietf.org; mpls-bounces@ietf.org > Subject: Re: [mpls] Mode negotiation for PSC > > Hi Eric, > > I have only seen one message on this thread so I will venture an > opinion. > > My preference is for option 1 - no negotiation. > > My reasons are: > > Keep it simple! > > The major reason that network operator's have given for requesting > these enhanced capabilities is to maintain compatibility with existing > linear protection schemes. Within the network of a single operator my > assumption is that they want, above all else, consistent operation. > Therefore, I suspect that we will see two "camps" with either all > options active or no options active. > That's what it looks like now. But I'm not terribly good at predicting what people will never, ever do. I could see an implementation which wants to support, say, MS-W but none of the other options. > Interconnection of "transport" connections between network operators > is normally only allowed within the frame work of an agreement between > the operators. As part of that agreement they would need to define the > linear protection options that would be used. The operational > differences would be confined to the links that provide the > interconnection between networks of the different operators. The > appropriate protection options would be configured (as defined by the > agreement) when the protected connection is set-up. PSC has bits to indicate the protection type and revertive mode, and the logic we're going to add n draft-osborne explains what happens if two sides disagree. Is this not a form of negotiatoin? > > Negotiation would allow the possibility of a variety of protection > options being active in the network which would result in inconsistent > behaviour which would create operational complexity. It is possible for one side to declare intransigence by setting the mask bits to all 1s. This indicates that the Capabilities advertised by that node must match exactly in order for things to work. The two modes I think we'll see first are: Cap=00000, Mask=11111 Cap=11111, Mask=11111 and these two will never agree on a mode since the mask of all 1s gives neither side any room to move. I'm not against the simpler mode, I just want to make sure that you understand that it is possible to achieve that using the proposed negotiation method. eric > > Regards, > > Malcolm > > > > > > "Eric Osborne (eosborne)" Sent by: > mpls-bounces@ietf.org > > 08/08/2013 08:34 AM To > "mpls@ietf.org" > cc > Subject > [mpls] Mode negotiation for PSC > > > > > > > As per last Friday's presentation in Berlin > (http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt > ), > we will be adding "ITU Mode" to PSC to allow for behaviors that > satisfy both IETF and ITU requirements. This mode will be > backward-compatible and negotiated using PSC TLVs. > > The drafts in that ppt define five capabilities which separate ITU > mode from IETF mode. IETF mode is defined as the absence of these > five capabilities, and ITU mode is defined as the use of all five of > these capabilities. It may help to think of IETF mode as 00000 and > ITU mode as 11111. The mechanism to define and negotiate these modes > will have room for expansion past five bits, so if we ever decide we > need more capabilities negotiation in PSC (shared mesh? m:n? other > fancy stuff?) we can. > > As of right now we are only discussing two modes, but it is possible > to define a mode which is some combination of these five things other > than > 00000 or 11111. So a mode is really the set of negotiated > capabilities between two devices. > > There are two ways we can negotiate the use of one more or the other: > > 1) Each node announces the mode that it wants, and if the other side > doesn't want exactly the same mode then PSC will not function. That > is, both nodes say "my mode is 0bxxxxx" (for now, either 00000 or > 11111) and if both nodes don't say the same thing then they complain > to the operator and refuse to function. > > Advantage: easy, and if both ends are in a single administrative > domain I expect the operator to be able to configure both ends to match. > > Disadvantage: tricky if we ever start talking about modes other than > 00000 or 11111. I don't want a node to say "I support mode 00000, > mode 00001, mode 00010, mode 00011, .... mode 11111" because if we add > a few more capabilities we could end up announcing the support of > hundreds or thousands of modes. Does not allow PSC to come up unless > the modes match on both sides, even if there is some common subset > they could both agree on. > > > or > > > 2) Each node announces the set of capabilities that it can support > along with the ones that it requires, and if the two nodes can find a > common subset of features then they will converge on those features in PSC. > > Advantage: flexible. If two endpoints can find a common feature > subset (see example below) then they will come up. > > Disadvantage: more complex code, easier to get wrong and converge on a > undesirable subset. > > > Examples of each negotiation method are below, both for clarity and to > demonstrate that method #2 works. My question for the WG is, which > one would people prefer, and why? > > > > > > > eric > > > --------------------------------- > > > Examples > ======== > All examples are between two nodes, A and Z. These examples focus on > the actual negotiation, not on the necessary TLV bits to enable the > negotiation. > > Example of method 1 > ------------------- > Node A sends a single TLV to Node Z containg the mode bitmap. Node Z > sends the same to A. Call them A.Mode and Z.Mode. If they do not > match then some default behavior happens - either PSC doesn't come up > or they default to one predetermined mode. > > A.mode = Z. mode = 00000 > A->Z: "I am configured for mode 00000" > Z->A: "I am configured for mode 00000" > > This results in PSC coming up in IETF mode. > > A.mode = Z.mode = 11111 > A->Z: "I am configured for mode 11111" > Z->A: "I am configured for mode 11111" > > This results in PSC coming up in ITU mode. > > A.mode != Z.mode (say, 00001 and 00010) > A->Z: "I am configured for mode 00001" > Z->A: "I am configured for mode 00010" > > PSC does not come up. > > > > Example of method 2 > ------------------- > Both Node A and Node Z announce two things - Capabilities and Mask. > Capabilities is a bitmap of the capabilities that are supported. > Mask is a mask of don't-care bits against the Capabilities string. A > 0 in Mask means "I don't care if we do this capability or not", and a > 1 means "we must (or must not) agree on this capability in order to > come up". > > A.capabilities = 00000 > A.mask = 00000 > > This says "I am capable of supporting all capabilities and I don't > care if we do any of them or not" > > A.capabilities = 00000 > A.mask = 11111 > > This says "We must not use any of the optional capabilities" - > Capabilities bits are all zero, and Mask bits say "we must agree that > the corresponding capability is zero". This is 'IETF mode'. > > A.capabilities = 11111 > A.mask = 11111 > > This is 'ITU Mode' > > Where it gets complicated (or awesome, depending on your perspective) > is when you have various subsets. Consider: > > A.Capabilities == 01100 > A.Mask == 01100 > > Z.Capabilities == 01110 > Z.Mask == 01110 > > > Negotiation procedures. > Each side does: > > > res = (A.Capabilites & Z.Mask) ^ (Z.Capabilities & A.Mask) res = > (01100 & 01110) ^ (01110 & 01100) res = (01100) ^ (01100) res = 00000 > > if res == 0 then it is possible for both sides to find a common subset > that they support. > This common subset is called the 'negotiated set', and is determined by: > > negotiated_set = A.Capabilities | B.Capabilities negotiated_set = > 01100 | 01110 negotiated_set = 01100 > > if res != 0 then it is impossible to find a subset that the two ends > can agree on, and PSC will never come up. > > Once each side computes the negotiated set, they signal it and PSC > starts to work. > _______________________________________________ > 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 --=_alternative 0056794E85257BCE_= Content-Type: text/html; charset="US-ASCII" Hi Eric (Gray),

I agree that we should not negotiate PSC modes "on the fly", since selecting different options will result in different behaviour in the network any negotiation should involve a human i..e reporting the miss match is all that we need to do.

As I pointed out below "negotiation" of the PSC options should take place before the LSP is set-up, PSC should only check that the options selected match (and report a miss match).

Regards,

Malcolm



Eric Gray <eric.gray@ericsson.com>

20/08/2013 02:41 PM

To
"Eric Osborne (eosborne)" <eosborne@cisco.com>, "Malcolm.BETTS@zte.com.cn" <Malcolm.BETTS@zte.com.cn>
cc
"mpls@ietf.org" <mpls@ietf.org>, "mpls-bounces@ietf.org" <mpls-bounces@ietf.org>
Subject
RE: [mpls] Mode negotiation for PSC





Eric (Osborne),

                While I agree that we don't want to try to predict what will never ever
happen, there is more than a little bit of an issue with designing for all possible
cases.

                Before we can really get away with any approach that could conceivably
include N^2 combinations of options, we need to describe what each of these
possibilities means, and how devices with arbitrary disagreement for the options
resolve the differences.

                And - while we're trying to cover the possible cases for known modes,
should we also try to allow for coverage of future (thus unknown) modes?

                Is this worth the trouble?  Are there use cases to support this, or are we
embarking on an academic exercise?

                What we really need now is a simple binary indicator.  If we feel that any
negotiation is required, then it should be trivial.  If there is disagreement, then
everbody falls-back to a default mode.

                But I am not convinced that any form of negotiation is required.

                In this discussion, I am reminded that at least part of the discussion that
got us on the road of having two modes had to do with limited negotiation in the
case where PSC parameters did not match.  I believe that the decision was that
reporting the inconsistency to the operator was sufficient from the perspective
of any of us in the IETF, and that this was not sufficient to folks used to dealing
with APS.

                So, are we switching from what was essentially non-negotiation of PSC
parameters to negotiation of PSC modes?  Seems counter-intuitive to me...

--
Eric (Gray)

-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Osborne (eosborne)
Sent: Friday, August 16, 2013 4:49 PM
To: Malcolm.BETTS@zte.com.cn
Cc: mpls@ietf.org; mpls-bounces@ietf.org
Subject: Re: [mpls] Mode negotiation for PSC

Hi Malcolm-

 Thanks for this.  A few comments inline.


> -----Original Message-----
> From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn]
> Sent: Thursday, August 15, 2013 1:01 PM
> To: Eric Osborne (eosborne)
> Cc: mpls@ietf.org; mpls-bounces@ietf.org
> Subject: Re: [mpls] Mode negotiation for PSC
>
> Hi Eric,
>
> I have only seen one message on this thread so I will venture an
> opinion.
>
> My preference is for option 1 - no negotiation.
>
> My reasons are:
>
> Keep it simple!
>
> The major reason that network operator's have given for requesting
> these enhanced capabilities is to maintain compatibility with existing
> linear protection schemes. Within the network of a single operator my
> assumption is that they want, above all else, consistent operation.
> Therefore, I suspect that we will see two "camps" with either all
> options active or no options active.
>

That's what it looks like now.  But I'm not terribly good at predicting what people will never, ever do.  I could see an implementation which wants to support, say, MS-W but none of the other options.

> Interconnection of "transport" connections between network operators
> is normally only allowed within the frame work of an agreement between
> the operators. As part of that agreement they would need to define the
> linear protection options that would be used. The operational
> differences would be confined to the links that provide the
> interconnection between networks of the different operators. The
> appropriate protection options would be configured (as defined by the
> agreement) when the protected connection is set-up.

PSC has bits to indicate the protection type and revertive mode, and the logic we're going to add n draft-osborne explains what happens if two sides disagree.  Is this not a form of negotiatoin?

>
> Negotiation would allow the possibility of a variety of protection
> options being active in the network which would result in inconsistent
> behaviour which would create operational complexity.

It is possible for one side to declare intransigence by setting the mask bits to all 1s.  This indicates that the Capabilities advertised by that node must match exactly in order for things to work.  The two modes I think we'll see first are:

Cap=00000, Mask=11111
Cap=11111, Mask=11111

and these two will never agree on a mode since the mask of all 1s gives neither side any room to move.

I'm not against the simpler mode, I just want to make sure that you understand that it is possible to achieve that using the proposed negotiation method.




eric


>
> Regards,
>
> Malcolm
>
>
>
>
>
> "Eric Osborne (eosborne)" <eosborne@cisco.com> Sent by:
> mpls-bounces@ietf.org
>
> 08/08/2013 08:34 AM To
> "mpls@ietf.org" <mpls@ietf.org>
> cc
> Subject
> [mpls] Mode negotiation for PSC
>
>
>
>
>
>
> As per last Friday's presentation in Berlin
> (http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt
> <http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt> ),
> we will be adding "ITU Mode" to PSC to allow for behaviors that
> satisfy both IETF and ITU requirements.  This mode will be
> backward-compatible and negotiated using PSC TLVs.
>
> The drafts in that ppt define five capabilities which separate ITU
> mode from IETF mode.  IETF mode is defined as the absence of these
> five capabilities, and ITU mode is defined as the use of all five of
> these capabilities.  It may help to think of IETF mode as 00000 and
> ITU mode as 11111.  The mechanism to define and negotiate these modes
> will have room for expansion past five bits, so if we ever decide we
> need more capabilities negotiation in PSC (shared mesh?  m:n?  other
> fancy stuff?) we can.
>
> As of right now we are only discussing two modes, but it is possible
> to define a mode which is some combination of these five things other
> than
> 00000 or 11111.  So a mode is really the set of negotiated
> capabilities between two devices.
>
> There are two ways we can negotiate the use of one more or the other:
>
> 1) Each node announces the mode that it wants, and if the other side
> doesn't want exactly the same mode then PSC will not function.  That
> is, both nodes say "my mode is 0bxxxxx" (for now, either 00000 or
> 11111) and if both nodes don't say the same thing then they complain
> to the operator and refuse to function.
>
> Advantage: easy, and if both ends are in a single administrative
> domain I expect the operator to be able to configure both ends to match.
>
> Disadvantage: tricky if we ever start talking about modes other than
> 00000 or 11111.  I don't want a node to say "I support mode 00000,
> mode 00001, mode 00010, mode 00011, .... mode 11111" because if we add
> a few more capabilities we could end up announcing the support of
> hundreds or thousands of modes.  Does not allow PSC to come up unless
> the modes match on both sides, even if there is some common subset
> they could both agree on.
>
>
> or
>
>
> 2) Each node announces the set of capabilities that it can support
> along with the ones that it requires, and if the two nodes can find a
> common subset of features then they will converge on those features in PSC.
>
> Advantage: flexible.  If two endpoints can find a common feature
> subset (see example below) then they will come up.
>
> Disadvantage: more complex code, easier to get wrong and converge on a
> undesirable subset.
>
>
> Examples of each negotiation method are below, both for clarity and to
> demonstrate that method #2 works.  My question for the WG is, which
> one would people prefer, and why?
>
>
>
>
>
>
> eric
>
>
> ---------------------------------
>
>
> Examples
> ========
> All examples are between two nodes, A and Z.  These examples focus on
> the actual negotiation, not on the necessary TLV bits to enable the
> negotiation.
>
> Example of method 1
> -------------------
> Node A sends a single TLV to Node Z containg the mode bitmap.  Node Z
> sends the same to A.  Call them A.Mode and Z.Mode.  If they do not
> match then some default behavior happens - either PSC doesn't come up
> or they default to one predetermined mode.
>
> A.mode = Z. mode = 00000
> A->Z: "I am configured for mode 00000"
> Z->A: "I am configured for mode 00000"
>
> This results in PSC coming up in IETF mode.
>
> A.mode = Z.mode = 11111
> A->Z: "I am configured for mode 11111"
> Z->A: "I am configured for mode 11111"
>
> This results in PSC coming up in ITU mode.
>
> A.mode != Z.mode (say, 00001 and 00010)
> A->Z: "I am configured for mode 00001"
> Z->A: "I am configured for mode 00010"
>
> PSC does not come up.
>
>
>
> Example of method 2
> -------------------
> Both Node A and Node Z announce two things - Capabilities and Mask.
> Capabilities is a bitmap of the capabilities that are supported.
> Mask is a mask of don't-care bits against the Capabilities string.  A
> 0 in Mask means "I don't care if we do this capability or not", and a
> 1 means "we must (or must not) agree on this capability in order to
> come up".
>
> A.capabilities = 00000
> A.mask         = 00000
>
> This says "I am capable of supporting all capabilities and I don't
> care if we do any of them or not"
>
> A.capabilities = 00000
> A.mask         = 11111
>
> This says "We must not use any of the optional capabilities" -
> Capabilities bits are all zero, and Mask bits say "we must agree that
> the corresponding capability is zero".  This is 'IETF mode'.
>
> A.capabilities = 11111
> A.mask         = 11111
>
> This is 'ITU Mode'
>
> Where it gets complicated (or awesome, depending on your perspective)
> is when you have various subsets.  Consider:
>
> A.Capabilities == 01100
> A.Mask == 01100
>
> Z.Capabilities == 01110
> Z.Mask == 01110
>
>
> Negotiation procedures.
> Each side does:
>
>
> res = (A.Capabilites & Z.Mask) ^ (Z.Capabilities & A.Mask) res =
> (01100 & 01110) ^ (01110 & 01100) res = (01100) ^ (01100) res = 00000
>
> if res == 0 then it is possible for both sides to find a common subset
> that they support.
> This common subset is called the 'negotiated set', and is determined by:
>
> negotiated_set = A.Capabilities | B.Capabilities negotiated_set =
> 01100 | 01110 negotiated_set = 01100
>
> if res != 0 then it is impossible to find a subset that the two ends
> can agree on, and PSC will never come up.
>
> Once each side computes the negotiated set, they signal it and PSC
> starts to work.
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> <https://www.ietf.org/mailman/listinfo/mpls>
>

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--=_alternative 0056794E85257BCE_=-- From iesg-secretary@ietf.org Wed Aug 21 11:22:04 2013 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 787CD11E810A; Wed, 21 Aug 2013 11:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.132, 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 SIOMWLN6lPnl; Wed, 21 Aug 2013 11:22:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D3F11E812C; Wed, 21 Aug 2013 11:22:03 -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: 4.70.p1 Sender: Message-ID: <20130821182203.19820.96489.idtracker@ietfa.amsl.com> Date: Wed, 21 Aug 2013 11:22:03 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: (Return Path Specified LSP Ping) 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: Wed, 21 Aug 2013 18:22:04 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Return Path Specified LSP Ping' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-return-path-specified-lsp-ping/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-return-path-specified-lsp-ping/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1491/ From mach.chen@huawei.com Thu Aug 22 02:07:27 2013 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 ACBCD11E8195 for ; Thu, 22 Aug 2013 02:07:27 -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=0.000, 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 OlMi3T-oBW1o for ; Thu, 22 Aug 2013 02:07:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2C38B11E81A1 for ; Thu, 22 Aug 2013 02:07:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUP70306; Thu, 22 Aug 2013 09:07:17 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 22 Aug 2013 10:06:08 +0100 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 22 Aug 2013 10:07:02 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.128]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.007; Thu, 22 Aug 2013 17:05:58 +0800 From: Mach Chen To: "draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org" Thread-Topic: MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents Thread-Index: AQHOlPgOYmWUTb4KMkKsjsIvATSyRJmg65oA Date: Thu, 22 Aug 2013 09:05:58 +0000 Message-ID: References: <5204D9DE.6060405@pi.nu> In-Reply-To: <5204D9DE.6060405@pi.nu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents 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, 22 Aug 2013 09:07:27 -0000 Hi, I have done my MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00, he= re are my comments: I think that modification to Non-revertive mode, adding MS-W and renaming M= S to MS-F are valid points. But I not sure whether there is a need to repla= ce " Protecting administrative state" to "Switching administrative state". Read through the draft, it gives me the feeling that the draft just lists a= set of erratas, I am not sure that this is the right way to progress the d= raft as it be. If the WG have the consensus on the content of the draft, IM= HO, it's better to do a bis to RFC6378. =20 Minor comment: It's better to expand the acronym when first use, for example the MS-F and = MS-W, I have to guess the meaning of until I see the Acronyms section.=20 Best regards, Mach > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Friday, August 09, 2013 8:01 PM > To: Eric Osborne (eosborne); Eric Gray; kenji.fujihira.dj@hitachi.com; Ya= acov > Weingarten; Sam Aldrin; Mach Chen; Kamran Raza (skraza); Henderickx, Wim > (Wim); thomas.morin@orange.com; mjork@juniper.net > Cc: draft-osborne-mpls-psc-updates@tools.ietf.org; > draft-dj-mpls-tp-exer-psc@tools.ietf.org; > draft-rhd-mpls-tp-psc-sd@tools.ietf.org; > draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org; > draft-rhd-mpls-tp-psc-priority@tools.ietf.org; mpls-chairs@tools.ietf.org= ; > VIGOUREUX, MARTIN (MARTIN) > Subject: MPLS-RT review of mpls psc documents >=20 > Eric, Eric, Kenji, Yacoov, Sam, Mach, Kamran, Wim, Thomas and Markus, >=20 > You been selected as MPLS-RT reviewers for a set of psc document that we > will start progress through the mpls working group. >=20 > The normal rules and question for an MPLS-RT apply: >=20 > ---------- quote from a standard mail initiating MPLS-RT review ------- >=20 > Note to authors: You have been CC'd on this email so that you can know > that this review is going on. However, please do not review your own > document. >=20 > Reviews should comment on whether the document is coherent, is it > useful (ie, is it likely to be actually useful in operational > networks), and is the document technically sound? We are interested > in knowing whether the document is ready to be considered for WG > adoption (ie, it doesn't have to be perfect at this point, but should be > a good start). >=20 > Reviews should be sent to the document authors, WG co-chairs and > WG secretary, and CC'd to the MPLS WG email list. If necessary, comments > may be sent privately to only the WG chairs. >=20 > ---------------------- end quote ------------------------- >=20 > The only difference is that we take on more than one document and that > there are such inter-dependencies that we want to coordinate how they > are progressed through IETF. >=20 > Please respond (at least) to the wg chairs and Martin that you are > willing/un-willing to undertake the reviews. >=20 > Since we are starting MPLS-RT reviews of 5 documents, with 4 reviewers > for each document and each reviewer have two documents, you'll need > to send the review with the draft name in the subject line, i.e. do > not respond to this mail with your review comments. >=20 > There is also a "PSC modes" document in the pipe, currently it is our > opinion that this document is necessary when we will start the wglc's > but is not necessary to make the other drafts wg documents. >=20 > Can you please finish your reviews eob August 23, 2013. >=20 > Here is the list of reviewers per document: >=20 > draft-rhd-mpls-tp-psc-priority > ------------------------------ > mach chen > thomas morin > yacoov weingarten > Wim Henderickx >=20 > draft-cdh-mpls-tp-psc-non-revertive > ----------------------------------- > mach chen > eric osborne > eric gray > yacoov weingarten >=20 > draft-rhd-mpls-tp-psc-sd > ------------------------ > eric osborne > sam aldrin > eric gray > kamran raza >=20 > draft-dj-mpls-tp-exer-psc > ------------------------- > sam aldrin > markus jork > kamran raza > kenji fuhira >=20 > draft-osborne-mpls-psc-updates > ------------------------------ > markus jork > thomas morin > kenji fuhira > Wim Henderickx >=20 >=20 > Authors, >=20 > Please do not update the documents during the review period, we will > tell you when the review period has ended. >=20 > When we close the review period you'll need to address the comments > from the reviewers and communicate with them (preferably on the mpls > wg mailing list) to make sure that they are comfortable with how the > comments has been addressed. >=20 >=20 > /Loa > for the mpls wg chairs >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From adrian@olddog.co.uk Thu Aug 22 05:27:41 2013 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 DBD8821F9425; Thu, 22 Aug 2013 05:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6] 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 Z4jnlhu0eS4J; Thu, 22 Aug 2013 05:27:36 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 1836111E81BA; Thu, 22 Aug 2013 05:27:33 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7MCRUOr011278; Thu, 22 Aug 2013 13:27:30 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7MCRS5u011238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Aug 2013 13:27:29 +0100 From: "Adrian Farrel" To: , "'Eric Gray'" References: <20ECF67871905846A80F77F8F4A27572102C229B@xmb-rcd-x09.cisco.com> <20ECF67871905846A80F77F8F4A27572102EB9C5@xmb-rcd-x09.cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF642C376@eusaamb107.ericsson.se> In-Reply-To: Date: Thu, 22 Aug 2013 13:27:25 +0100 Message-ID: <02b001ce9f32$f644ac80$e2ce0580$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02B1_01CE9F3B.580F07F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHvFpvJUI+i/vwQoiGxYzGECpkzeAJWkW7bAkPIw4sBvz6w3QGuJv2WmR/6fmA= Content-Language: en-gb Cc: mpls@ietf.org, mpls-bounces@ietf.org Subject: Re: [mpls] Mode negotiation for PSC 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, 22 Aug 2013 12:27:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02B1_01CE9F3B.580F07F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Maybe don't call it "negotiation" if no negotiation is to be allowed. Call in "mode confirmation" or something? Adrian From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Malcolm.BETTS@zte.com.cn Sent: 21 August 2013 16:44 To: Eric Gray Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] Mode negotiation for PSC Hi Eric (Gray), I agree that we should not negotiate PSC modes "on the fly", since selecting different options will result in different behaviour in the network any negotiation should involve a human i..e reporting the miss match is all that we need to do. As I pointed out below "negotiation" of the PSC options should take place before the LSP is set-up, PSC should only check that the options selected match (and report a miss match). Regards, Malcolm Eric Gray 20/08/2013 02:41 PM To "Eric Osborne (eosborne)" , "Malcolm.BETTS@zte.com.cn" cc "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject RE: [mpls] Mode negotiation for PSC Eric (Osborne), While I agree that we don't want to try to predict what will never ever happen, there is more than a little bit of an issue with designing for all possible cases. Before we can really get away with any approach that could conceivably include N^2 combinations of options, we need to describe what each of these possibilities means, and how devices with arbitrary disagreement for the options resolve the differences. And - while we're trying to cover the possible cases for known modes, should we also try to allow for coverage of future (thus unknown) modes? Is this worth the trouble? Are there use cases to support this, or are we embarking on an academic exercise? What we really need now is a simple binary indicator. If we feel that any negotiation is required, then it should be trivial. If there is disagreement, then everbody falls-back to a default mode. But I am not convinced that any form of negotiation is required. In this discussion, I am reminded that at least part of the discussion that got us on the road of having two modes had to do with limited negotiation in the case where PSC parameters did not match. I believe that the decision was that reporting the inconsistency to the operator was sufficient from the perspective of any of us in the IETF, and that this was not sufficient to folks used to dealing with APS. So, are we switching from what was essentially non-negotiation of PSC parameters to negotiation of PSC modes? Seems counter-intuitive to me... -- Eric (Gray) -----Original Message----- From: mpls-bounces@ietf.org [ mailto:mpls-bounces@ietf.org] On Behalf Of Eric Osborne (eosborne) Sent: Friday, August 16, 2013 4:49 PM To: Malcolm.BETTS@zte.com.cn Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] Mode negotiation for PSC Hi Malcolm- Thanks for this. A few comments inline. > -----Original Message----- > From: Malcolm.BETTS@zte.com.cn [ mailto:Malcolm.BETTS@zte.com.cn] > Sent: Thursday, August 15, 2013 1:01 PM > To: Eric Osborne (eosborne) > Cc: mpls@ietf.org; mpls-bounces@ietf.org > Subject: Re: [mpls] Mode negotiation for PSC > > Hi Eric, > > I have only seen one message on this thread so I will venture an > opinion. > > My preference is for option 1 - no negotiation. > > My reasons are: > > Keep it simple! > > The major reason that network operator's have given for requesting > these enhanced capabilities is to maintain compatibility with existing > linear protection schemes. Within the network of a single operator my > assumption is that they want, above all else, consistent operation. > Therefore, I suspect that we will see two "camps" with either all > options active or no options active. > That's what it looks like now. But I'm not terribly good at predicting what people will never, ever do. I could see an implementation which wants to support, say, MS-W but none of the other options. > Interconnection of "transport" connections between network operators > is normally only allowed within the frame work of an agreement between > the operators. As part of that agreement they would need to define the > linear protection options that would be used. The operational > differences would be confined to the links that provide the > interconnection between networks of the different operators. The > appropriate protection options would be configured (as defined by the > agreement) when the protected connection is set-up. PSC has bits to indicate the protection type and revertive mode, and the logic we're going to add n draft-osborne explains what happens if two sides disagree. Is this not a form of negotiatoin? > > Negotiation would allow the possibility of a variety of protection > options being active in the network which would result in inconsistent > behaviour which would create operational complexity. It is possible for one side to declare intransigence by setting the mask bits to all 1s. This indicates that the Capabilities advertised by that node must match exactly in order for things to work. The two modes I think we'll see first are: Cap=00000, Mask=11111 Cap=11111, Mask=11111 and these two will never agree on a mode since the mask of all 1s gives neither side any room to move. I'm not against the simpler mode, I just want to make sure that you understand that it is possible to achieve that using the proposed negotiation method. eric > > Regards, > > Malcolm > > > > > > "Eric Osborne (eosborne)" Sent by: > mpls-bounces@ietf.org > > 08/08/2013 08:34 AM To > "mpls@ietf.org" > cc > Subject > [mpls] Mode negotiation for PSC > > > > > > > As per last Friday's presentation in Berlin > ( http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt > < http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt> ), > we will be adding "ITU Mode" to PSC to allow for behaviors that > satisfy both IETF and ITU requirements. This mode will be > backward-compatible and negotiated using PSC TLVs. > > The drafts in that ppt define five capabilities which separate ITU > mode from IETF mode. IETF mode is defined as the absence of these > five capabilities, and ITU mode is defined as the use of all five of > these capabilities. It may help to think of IETF mode as 00000 and > ITU mode as 11111. The mechanism to define and negotiate these modes > will have room for expansion past five bits, so if we ever decide we > need more capabilities negotiation in PSC (shared mesh? m:n? other > fancy stuff?) we can. > > As of right now we are only discussing two modes, but it is possible > to define a mode which is some combination of these five things other > than > 00000 or 11111. So a mode is really the set of negotiated > capabilities between two devices. > > There are two ways we can negotiate the use of one more or the other: > > 1) Each node announces the mode that it wants, and if the other side > doesn't want exactly the same mode then PSC will not function. That > is, both nodes say "my mode is 0bxxxxx" (for now, either 00000 or > 11111) and if both nodes don't say the same thing then they complain > to the operator and refuse to function. > > Advantage: easy, and if both ends are in a single administrative > domain I expect the operator to be able to configure both ends to match. > > Disadvantage: tricky if we ever start talking about modes other than > 00000 or 11111. I don't want a node to say "I support mode 00000, > mode 00001, mode 00010, mode 00011, .... mode 11111" because if we add > a few more capabilities we could end up announcing the support of > hundreds or thousands of modes. Does not allow PSC to come up unless > the modes match on both sides, even if there is some common subset > they could both agree on. > > > or > > > 2) Each node announces the set of capabilities that it can support > along with the ones that it requires, and if the two nodes can find a > common subset of features then they will converge on those features in PSC. > > Advantage: flexible. If two endpoints can find a common feature > subset (see example below) then they will come up. > > Disadvantage: more complex code, easier to get wrong and converge on a > undesirable subset. > > > Examples of each negotiation method are below, both for clarity and to > demonstrate that method #2 works. My question for the WG is, which > one would people prefer, and why? > > > > > > > eric > > > --------------------------------- > > > Examples > ======== > All examples are between two nodes, A and Z. These examples focus on > the actual negotiation, not on the necessary TLV bits to enable the > negotiation. > > Example of method 1 > ------------------- > Node A sends a single TLV to Node Z containg the mode bitmap. Node Z > sends the same to A. Call them A.Mode and Z.Mode. If they do not > match then some default behavior happens - either PSC doesn't come up > or they default to one predetermined mode. > > A.mode = Z. mode = 00000 > A->Z: "I am configured for mode 00000" > Z->A: "I am configured for mode 00000" > > This results in PSC coming up in IETF mode. > > A.mode = Z.mode = 11111 > A->Z: "I am configured for mode 11111" > Z->A: "I am configured for mode 11111" > > This results in PSC coming up in ITU mode. > > A.mode != Z.mode (say, 00001 and 00010) > A->Z: "I am configured for mode 00001" > Z->A: "I am configured for mode 00010" > > PSC does not come up. > > > > Example of method 2 > ------------------- > Both Node A and Node Z announce two things - Capabilities and Mask. > Capabilities is a bitmap of the capabilities that are supported. > Mask is a mask of don't-care bits against the Capabilities string. A > 0 in Mask means "I don't care if we do this capability or not", and a > 1 means "we must (or must not) agree on this capability in order to > come up". > > A.capabilities = 00000 > A.mask = 00000 > > This says "I am capable of supporting all capabilities and I don't > care if we do any of them or not" > > A.capabilities = 00000 > A.mask = 11111 > > This says "We must not use any of the optional capabilities" - > Capabilities bits are all zero, and Mask bits say "we must agree that > the corresponding capability is zero". This is 'IETF mode'. > > A.capabilities = 11111 > A.mask = 11111 > > This is 'ITU Mode' > > Where it gets complicated (or awesome, depending on your perspective) > is when you have various subsets. Consider: > > A.Capabilities == 01100 > A.Mask == 01100 > > Z.Capabilities == 01110 > Z.Mask == 01110 > > > Negotiation procedures. > Each side does: > > > res = (A.Capabilites & Z.Mask) ^ (Z.Capabilities & A.Mask) res = > (01100 & 01110) ^ (01110 & 01100) res = (01100) ^ (01100) res = 00000 > > if res == 0 then it is possible for both sides to find a common subset > that they support. > This common subset is called the 'negotiated set', and is determined by: > > negotiated_set = A.Capabilities | B.Capabilities negotiated_set = > 01100 | 01110 negotiated_set = 01100 > > if res != 0 then it is impossible to find a subset that the two ends > can agree on, and PSC will never come up. > > Once each side computes the negotiated set, they signal it and PSC > starts to work. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > < https://www.ietf.org/mailman/listinfo/mpls> > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ------=_NextPart_000_02B1_01CE9F3B.580F07F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Maybe don't call it = "negotiation" if no negotiation is to be = allowed.

 

Call in "mode = confirmation" or something?

 

Adrian

 

From: = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Malcolm.BETTS@zte.com.cn
Sent: 21 August 2013 = 16:44
To: Eric Gray
Cc: mpls@ietf.org; = mpls-bounces@ietf.org
Subject: Re: [mpls] Mode negotiation for = PSC

 

Hi Eric = (Gray),

I agree that = we should not negotiate PSC modes "on the fly", since = selecting different options will result in different behaviour in the = network any negotiation should involve a human i..e reporting the miss = match is all that we need to do.

As I pointed = out below "negotiation" of the PSC options should take place = before the LSP is set-up, PSC should only check that the options = selected match (and report a miss match).

Regards,

Malcolm


Eric Gray = <eric.gray@ericsson.com> =

20/08/2013 = 02:41 PM

To=

"Eric = Osborne (eosborne)" <eosborne@cisco.com>, = "Malcolm.BETTS@zte.com.cn" = <Malcolm.BETTS@zte.com.cn>

cc=

"mpls@iet= f.org" <mpls@ietf.org>, "mpls-bounces@ietf.org" = <mpls-bounces@ietf.org>

Subject=

RE: [mpls] = Mode negotiation for PSC

 




Eric (Osborne),

  =               While I agree that we = don't want to try to predict what will never ever
happen, = there is more than a little bit of an issue with designing for all = possible
cases.

        =         Before we can really get away with any = approach that could conceivably
include N^2 combinations of = options, we need to describe what each of = these
possibilities means, and how devices with arbitrary = disagreement for the options
resolve the = differences.

            =     And - while we're trying to cover the possible cases for = known modes,
should we also try to allow for coverage of = future (thus unknown) modes?

        =         Is this worth the trouble?  Are there = use cases to support this, or are we
embarking on an = academic exercise?

          =       What we really need now is a simple binary = indicator.  If we feel that any
negotiation is = required, then it should be trivial.  If there is disagreement, = then
everbody falls-back to a default = mode.

              =   But I am not convinced that any form of negotiation is = required.

            =     In this discussion, I am reminded that at least part of = the discussion that
got us on the road of having two modes = had to do with limited negotiation in the
case where PSC = parameters did not match.  I believe that the decision was = that
reporting the inconsistency to the operator was = sufficient from the perspective
of any of us in the IETF, = and that this was not sufficient to folks used to dealing =
with APS.

        =         So, are we switching from what was = essentially non-negotiation of PSC
parameters to negotiation = of PSC modes?  Seems counter-intuitive to = me...

--
Eric = (Gray)

-----Original Message-----
From: = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Osborne = (eosborne)
Sent: = Friday, August 16, 2013 4:49 PM
To: = Malcolm.BETTS@zte.com.cn
Cc: mpls@ietf.org; = mpls-bounces@ietf.org
Subject: Re: [mpls] Mode negotiation = for PSC

Hi Malcolm-

 Thanks for = this.  A few comments inline.


> = -----Original Message-----
> From: = Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn]
> Sent: = Thursday, August 15, 2013 1:01 PM
> To: Eric Osborne = (eosborne)
> Cc: mpls@ietf.org; = mpls-bounces@ietf.org
> Subject: Re: [mpls] Mode = negotiation for PSC
>
> Hi = Eric,
>
> I have only seen one message on = this thread so I will venture an
> = opinion.
>
> My preference is for option = 1 - no negotiation.
>
> My reasons = are:
>
> Keep it simple!
> =
> The major reason that network operator's have given = for requesting
> these enhanced capabilities is to = maintain compatibility with existing
> linear protection = schemes. Within the network of a single operator my
> = assumption is that they want, above all else, consistent = operation.
> Therefore, I suspect that we will see two = "camps" with either all
> options active or no = options active.
>

That's what it looks = like now.  But I'm not terribly good at predicting what people will = never, ever do.  I could see an implementation which wants to = support, say, MS-W but none of the other options.

> = Interconnection of "transport" connections between network = operators
> is normally only allowed within the frame = work of an agreement between
> the operators. As part of = that agreement they would need to define the
> linear = protection options that would be used. The operational
> = differences would be confined to the links that provide the =
> interconnection between networks of the different = operators. The
> appropriate protection options would be = configured (as defined by the
> agreement) when the = protected connection is set-up.

PSC has bits to indicate = the protection type and revertive mode, and the logic we're going to add = n draft-osborne explains what happens if two sides disagree.  Is = this not a form of negotiatoin?

>
> = Negotiation would allow the possibility of a variety of protection =
> options being active in the network which would result = in inconsistent
> behaviour which would create = operational complexity.

It is possible for one side to = declare intransigence by setting the mask bits to all 1s.  This = indicates that the Capabilities advertised by that node must match = exactly in order for things to work.  The two modes I think we'll = see first are:

Cap=3D00000, = Mask=3D11111
Cap=3D11111, Mask=3D11111

and = these two will never agree on a mode since the mask of all 1s gives = neither side any room to move.

I'm not against the = simpler mode, I just want to make sure that you understand that it is = possible to achieve that using the proposed negotiation = method.




eric


> =
> Regards,
>
> = Malcolm
>
>
> =
>
>
> "Eric Osborne = (eosborne)" <eosborne@cisco.com> Sent by:
> = mpls-bounces@ietf.org
>
> 08/08/2013 = 08:34 AM To
> "mpls@ietf.org" = <mpls@ietf.org>
> cc
> = Subject
> [mpls] Mode negotiation for = PSC
>
>
> =
>
>
>
> = As per last Friday's presentation in Berlin
> = (= http://www.ietf.org/proceedings/87/slides/slid= es-87-mpls-15.ppt
> = <= http://www.ietf.org/proceedings/87/slides/slid= es-87-mpls-15.ppt> ),
> we = will be adding "ITU Mode" to PSC to allow for behaviors that =
> satisfy both IETF and ITU requirements.  This = mode will be
> backward-compatible and negotiated using = PSC TLVs.
>
> The drafts in that ppt = define five capabilities which separate ITU
> mode from = IETF mode.  IETF mode is defined as the absence of these =
> five capabilities, and ITU mode is defined as the use = of all five of
> these capabilities.  It may help = to think of IETF mode as 00000 and
> ITU mode as 11111. =  The mechanism to define and negotiate these modes =
> will have room for expansion past five bits, so if we = ever decide we
> need more capabilities negotiation in = PSC (shared mesh?  m:n?  other
> fancy stuff?) = we can.
>
> As of right now we are only = discussing two modes, but it is possible
> to define a = mode which is some combination of these five things other =
> than
> 00000 or 11111.  So a mode = is really the set of negotiated
> capabilities between = two devices.
>
> There are two ways we = can negotiate the use of one more or the other:
> =
> 1) Each node announces the mode that it wants, and if = the other side
> doesn't want exactly the same mode then = PSC will not function.  That
> is, both nodes say = "my mode is 0bxxxxx" (for now, either 00000 or =
> 11111) and if both nodes don't say the same thing then = they complain
> to the operator and refuse to = function.
>
> Advantage: easy, and if = both ends are in a single administrative
> domain I = expect the operator to be able to configure both ends to = match.
>
> Disadvantage: tricky if we = ever start talking about modes other than
> 00000 or = 11111.  I don't want a node to say "I support mode 00000, =
> mode 00001, mode 00010, mode 00011, .... mode = 11111" because if we add
> a few more capabilities = we could end up announcing the support of
> hundreds or = thousands of modes.  Does not allow PSC to come up unless =
> the modes match on both sides, even if there is some = common subset
> they could both agree = on.
>
>
> = or
>
>
> 2) Each node = announces the set of capabilities that it can support
> = along with the ones that it requires, and if the two nodes can find a =
> common subset of features then they will converge on = those features in PSC.
>
> Advantage: = flexible.  If two endpoints can find a common feature =
> subset (see example below) then they will come = up.
>
> Disadvantage: more complex code, = easier to get wrong and converge on a
> undesirable = subset.
>
>
> Examples of = each negotiation method are below, both for clarity and to =
> demonstrate that method #2 works.  My question = for the WG is, which
> one would people prefer, and = why?
>
>
> =
>
>
>
> = eric
>
>
> = ---------------------------------
>
> =
> Examples
> = =3D=3D=3D=3D=3D=3D=3D=3D
> All examples are between two = nodes, A and Z.  These examples focus on
> the = actual negotiation, not on the necessary TLV bits to enable the =
> negotiation.
>
> = Example of method 1
> = -------------------
> Node A sends a single TLV to Node Z = containg the mode bitmap.  Node Z
> sends the same = to A.  Call them A.Mode and Z.Mode.  If they do not =
> match then some default behavior happens - either PSC = doesn't come up
> or they default to one predetermined = mode.
>
> A.mode =3D Z. mode =3D = 00000
> A->Z: "I am configured for mode = 00000"
> Z->A: "I am configured for mode = 00000"
>
> This results in PSC = coming up in IETF mode.
>
> A.mode =3D = Z.mode =3D 11111
> A->Z: "I am configured for = mode 11111"
> Z->A: "I am configured for = mode 11111"
>
> This results in PSC = coming up in ITU mode.
>
> A.mode !=3D = Z.mode (say, 00001 and 00010)
> A->Z: "I am = configured for mode 00001"
> Z->A: "I am = configured for mode 00010"
>
> PSC = does not come up.
>
>
> =
> Example of method 2
> = -------------------
> Both Node A and Node Z announce two = things - Capabilities and Mask.
> Capabilities is a = bitmap of the capabilities that are supported.
> Mask is = a mask of don't-care bits against the Capabilities string.  A =
> 0 in Mask means "I don't care if we do this = capability or not", and a
> 1 means "we must = (or must not) agree on this capability in order to
> = come up".
>
> A.capabilities =3D = 00000
> A.mask         =3D = 00000
>
> This says "I am capable of = supporting all capabilities and I don't
> care if we do = any of them or not"
>
> = A.capabilities =3D 00000
> A.mask       =   =3D 11111
>
> This says "We = must not use any of the optional capabilities" -
> = Capabilities bits are all zero, and Mask bits say "we must agree = that
> the corresponding capability is zero". =  This is 'IETF mode'.
>
> = A.capabilities =3D 11111
> A.mask       =   =3D 11111
>
> This is 'ITU = Mode'
>
> Where it gets complicated (or = awesome, depending on your perspective)
> is when you = have various subsets.  Consider:
>
> = A.Capabilities =3D=3D 01100
> A.Mask =3D=3D = 01100
>
> Z.Capabilities =3D=3D = 01110
> Z.Mask =3D=3D 01110
> =
>
> Negotiation = procedures.
> Each side does:
> =
>
> res =3D (A.Capabilites & Z.Mask) = ^ (Z.Capabilities & A.Mask) res =3D
> (01100 & = 01110) ^ (01110 & 01100) res =3D (01100) ^ (01100) res =3D = 00000
>
> if res =3D=3D 0 then it is = possible for both sides to find a common subset
> that = they support.
> This common subset is called the = 'negotiated set', and is determined by:
> =
> negotiated_set =3D A.Capabilities | B.Capabilities = negotiated_set =3D
> 01100 | 01110 negotiated_set =3D = 01100
>
> if res !=3D 0 then it is = impossible to find a subset that the two ends
> can = agree on, and PSC will never come up.
>
> = Once each side computes the negotiated set, they signal it and PSC =
> starts to work.
> = _______________________________________________
> mpls = mailing list
> mpls@ietf.org
> = https://www.ietf.org/mailman/listinfo/mpls
> <https://www.ietf.org/mailman/listinfo/mpls>
> =

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

------=_NextPart_000_02B1_01CE9F3B.580F07F0-- From eric.gray@ericsson.com Thu Aug 22 06:35:57 2013 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 2D66321F9E52; Thu, 22 Aug 2013 06:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6] 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 emaFQQiKKWqa; Thu, 22 Aug 2013 06:35:51 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 378F611E80E2; Thu, 22 Aug 2013 06:35:51 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-84-521613b55dde Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 39.E3.03458.5B316125; Thu, 22 Aug 2013 15:35:50 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Thu, 22 Aug 2013 09:35:49 -0400 From: Eric Gray To: "Malcolm.BETTS@zte.com.cn" Thread-Topic: [mpls] Mode negotiation for PSC Thread-Index: Ac6ULYh0Wz1ulMCERKa7JFuZBxS/GAFzPU+AADpDBQAAu+T3MAA06ZaAACVbvAA= Date: Thu, 22 Aug 2013 13:35:48 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF642DEFC@eusaamb107.ericsson.se> References: <20ECF67871905846A80F77F8F4A27572102C229B@xmb-rcd-x09.cisco.com> <20ECF67871905846A80F77F8F4A27572102EB9C5@xmb-rcd-x09.cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF642C376@eusaamb107.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF642DEFCeusaamb107ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyuXRPlO42YbEggwutYhZNczYzWrR3PWW3 2L3/CrvFraUrWR1YPKb83sjqsWTJTyaPNft+sAQwR3HZpKTmZJalFunbJXBlbH7cxFhw9gBT Ree6vywNjK39TF2MnBwSAiYS7a23oWwxiQv31rN1MXJxCAkcZZSYemgKlLOcUWLe9fcsIFVs AhoSx+6sZQSxRQQsJfrbtzKDFDELtDFKrDlyk7WLkYNDWEBH4tVec4gaXYkN69axQdh+Ev/+ XGYFsVkEVCXOdzwGi/MKeEu8mfSUGWLZYyaJCzs+gy3jFAiWWLb9Ith5jEDnfT+1BsxmFhCX uPVkPtTZAhJL9pxnhrBFJV4+/scKYStLLHmynwWiPl9i5/GJTBDLBCVOznzCMoFRdBaSUbOQ lM1CUgYR15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMXKUFqeW5aYbGW5iBMbeMQk2xx2M Cz5ZHmKU5mBREufdoHcmUEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOj6Urmsh9nrL6/qlny caPjhWwlg+rfcu+/Xoz1vvbl64J3ra8f3XVQ9qtZwpVx/tWRjHv/duz1CTEVOSCf7B3xIyJV kqXM99S0cK9sPiX/LycV1GX1D089IBkUKaMq3Pr7wqPLPAWpMlGaf+6ePaF0T5vf1ybo5Brb XZpbHJMYZq9fJ8B6Wc1BiaU4I9FQi7moOBEA1FYoOYsCAAA= Cc: "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject: Re: [mpls] Mode negotiation for PSC 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, 22 Aug 2013 13:35:57 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF642DEFCeusaamb107ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Malcolm, Agreed. See continuing discussion thread on why we might n= ot want to call this "negotiation." There is no negotiation if an exact match is requ= ired... -- Eric From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] Sent: Wednesday, August 21, 2013 11:44 AM To: Eric Gray Cc: Eric Osborne (eosborne); Malcolm.BETTS@zte.com.cn; mpls@ietf.org; mpls-= bounces@ietf.org Subject: RE: [mpls] Mode negotiation for PSC Importance: High Hi Eric (Gray), I agree that we should not negotiate PSC modes "on the fly", since selectin= g different options will result in different behaviour in the network any n= egotiation should involve a human i..e reporting the miss match is all that= we need to do. As I pointed out below "negotiation" of the PSC options should take place b= efore the LSP is set-up, PSC should only check that the options selected ma= tch (and report a miss match). Regards, Malcolm Eric Gray > 20/08/2013 02:41 PM To "Eric Osborne (eosborne)" >, = "Malcolm.BETTS@zte.com.cn" > cc "mpls@ietf.org" >= , "mpls-bounces@ietf.org" > Subject RE: [mpls] Mode negotiation for PSC Eric (Osborne), While I agree that we don't want to try to predict what wil= l never ever happen, there is more than a little bit of an issue with designing for all = possible cases. Before we can really get away with any approach that could = conceivably include N^2 combinations of options, we need to describe what each of these possibilities means, and how devices with arbitrary disagreement for the op= tions resolve the differences. And - while we're trying to cover the possible cases for kn= own modes, should we also try to allow for coverage of future (thus unknown) modes? Is this worth the trouble? Are there use cases to support = this, or are we embarking on an academic exercise? What we really need now is a simple binary indicator. If w= e feel that any negotiation is required, then it should be trivial. If there is disagreeme= nt, then everbody falls-back to a default mode. But I am not convinced that any form of negotiation is requ= ired. In this discussion, I am reminded that at least part of the= discussion that got us on the road of having two modes had to do with limited negotiation i= n the case where PSC parameters did not match. I believe that the decision was t= hat reporting the inconsistency to the operator was sufficient from the perspec= tive of any of us in the IETF, and that this was not sufficient to folks used to= dealing with APS. So, are we switching from what was essentially non-negotiat= ion of PSC parameters to negotiation of PSC modes? Seems counter-intuitive to me... -- Eric (Gray) -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Eric Osborne (eosborne) Sent: Friday, August 16, 2013 4:49 PM To: Malcolm.BETTS@zte.com.cn Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] Mode negotiation for PSC Hi Malcolm- Thanks for this. A few comments inline. > -----Original Message----- > From: Malcolm.BETTS@zte.com.cn [mailto:M= alcolm.BETTS@zte.com.cn] > Sent: Thursday, August 15, 2013 1:01 PM > To: Eric Osborne (eosborne) > Cc: mpls@ietf.org; mpls-bounces@ietf.org > Subject: Re: [mpls] Mode negotiation for PSC > > Hi Eric, > > I have only seen one message on this thread so I will venture an > opinion. > > My preference is for option 1 - no negotiation. > > My reasons are: > > Keep it simple! > > The major reason that network operator's have given for requesting > these enhanced capabilities is to maintain compatibility with existing > linear protection schemes. Within the network of a single operator my > assumption is that they want, above all else, consistent operation. > Therefore, I suspect that we will see two "camps" with either all > options active or no options active. > That's what it looks like now. But I'm not terribly good at predicting wha= t people will never, ever do. I could see an implementation which wants to= support, say, MS-W but none of the other options. > Interconnection of "transport" connections between network operators > is normally only allowed within the frame work of an agreement between > the operators. As part of that agreement they would need to define the > linear protection options that would be used. The operational > differences would be confined to the links that provide the > interconnection between networks of the different operators. The > appropriate protection options would be configured (as defined by the > agreement) when the protected connection is set-up. PSC has bits to indicate the protection type and revertive mode, and the lo= gic we're going to add n draft-osborne explains what happens if two sides d= isagree. Is this not a form of negotiatoin? > > Negotiation would allow the possibility of a variety of protection > options being active in the network which would result in inconsistent > behaviour which would create operational complexity. It is possible for one side to declare intransigence by setting the mask bi= ts to all 1s. This indicates that the Capabilities advertised by that node= must match exactly in order for things to work. The two modes I think we'= ll see first are: Cap=3D00000, Mask=3D11111 Cap=3D11111, Mask=3D11111 and these two will never agree on a mode since the mask of all 1s gives nei= ther side any room to move. I'm not against the simpler mode, I just want to make sure that you underst= and that it is possible to achieve that using the proposed negotiation meth= od. eric > > Regards, > > Malcolm > > > > > > "Eric Osborne (eosborne)" >= Sent by: > mpls-bounces@ietf.org > > 08/08/2013 08:34 AM To > "mpls@ietf.org" > > cc > Subject > [mpls] Mode negotiation for PSC > > > > > > > As per last Friday's presentation in Berlin > (http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt > ), > we will be adding "ITU Mode" to PSC to allow for behaviors that > satisfy both IETF and ITU requirements. This mode will be > backward-compatible and negotiated using PSC TLVs. > > The drafts in that ppt define five capabilities which separate ITU > mode from IETF mode. IETF mode is defined as the absence of these > five capabilities, and ITU mode is defined as the use of all five of > these capabilities. It may help to think of IETF mode as 00000 and > ITU mode as 11111. The mechanism to define and negotiate these modes > will have room for expansion past five bits, so if we ever decide we > need more capabilities negotiation in PSC (shared mesh? m:n? other > fancy stuff?) we can. > > As of right now we are only discussing two modes, but it is possible > to define a mode which is some combination of these five things other > than > 00000 or 11111. So a mode is really the set of negotiated > capabilities between two devices. > > There are two ways we can negotiate the use of one more or the other: > > 1) Each node announces the mode that it wants, and if the other side > doesn't want exactly the same mode then PSC will not function. That > is, both nodes say "my mode is 0bxxxxx" (for now, either 00000 or > 11111) and if both nodes don't say the same thing then they complain > to the operator and refuse to function. > > Advantage: easy, and if both ends are in a single administrative > domain I expect the operator to be able to configure both ends to match. > > Disadvantage: tricky if we ever start talking about modes other than > 00000 or 11111. I don't want a node to say "I support mode 00000, > mode 00001, mode 00010, mode 00011, .... mode 11111" because if we add > a few more capabilities we could end up announcing the support of > hundreds or thousands of modes. Does not allow PSC to come up unless > the modes match on both sides, even if there is some common subset > they could both agree on. > > > or > > > 2) Each node announces the set of capabilities that it can support > along with the ones that it requires, and if the two nodes can find a > common subset of features then they will converge on those features in PS= C. > > Advantage: flexible. If two endpoints can find a common feature > subset (see example below) then they will come up. > > Disadvantage: more complex code, easier to get wrong and converge on a > undesirable subset. > > > Examples of each negotiation method are below, both for clarity and to > demonstrate that method #2 works. My question for the WG is, which > one would people prefer, and why? > > > > > > > eric > > > --------------------------------- > > > Examples > =3D=3D=3D=3D=3D=3D=3D=3D > All examples are between two nodes, A and Z. These examples focus on > the actual negotiation, not on the necessary TLV bits to enable the > negotiation. > > Example of method 1 > ------------------- > Node A sends a single TLV to Node Z containg the mode bitmap. Node Z > sends the same to A. Call them A.Mode and Z.Mode. If they do not > match then some default behavior happens - either PSC doesn't come up > or they default to one predetermined mode. > > A.mode =3D Z. mode =3D 00000 > A->Z: "I am configured for mode 00000" > Z->A: "I am configured for mode 00000" > > This results in PSC coming up in IETF mode. > > A.mode =3D Z.mode =3D 11111 > A->Z: "I am configured for mode 11111" > Z->A: "I am configured for mode 11111" > > This results in PSC coming up in ITU mode. > > A.mode !=3D Z.mode (say, 00001 and 00010) > A->Z: "I am configured for mode 00001" > Z->A: "I am configured for mode 00010" > > PSC does not come up. > > > > Example of method 2 > ------------------- > Both Node A and Node Z announce two things - Capabilities and Mask. > Capabilities is a bitmap of the capabilities that are supported. > Mask is a mask of don't-care bits against the Capabilities string. A > 0 in Mask means "I don't care if we do this capability or not", and a > 1 means "we must (or must not) agree on this capability in order to > come up". > > A.capabilities =3D 00000 > A.mask =3D 00000 > > This says "I am capable of supporting all capabilities and I don't > care if we do any of them or not" > > A.capabilities =3D 00000 > A.mask =3D 11111 > > This says "We must not use any of the optional capabilities" - > Capabilities bits are all zero, and Mask bits say "we must agree that > the corresponding capability is zero". This is 'IETF mode'. > > A.capabilities =3D 11111 > A.mask =3D 11111 > > This is 'ITU Mode' > > Where it gets complicated (or awesome, depending on your perspective) > is when you have various subsets. Consider: > > A.Capabilities =3D=3D 01100 > A.Mask =3D=3D 01100 > > Z.Capabilities =3D=3D 01110 > Z.Mask =3D=3D 01110 > > > Negotiation procedures. > Each side does: > > > res =3D (A.Capabilites & Z.Mask) ^ (Z.Capabilities & A.Mask) res =3D > (01100 & 01110) ^ (01110 & 01100) res =3D (01100) ^ (01100) res =3D 00000 > > if res =3D=3D 0 then it is possible for both sides to find a common subse= t > that they support. > This common subset is called the 'negotiated set', and is determined by: > > negotiated_set =3D A.Capabilities | B.Capabilities negotiated_set =3D > 01100 | 01110 negotiated_set =3D 01100 > > if res !=3D 0 then it is impossible to find a subset that the two ends > can agree on, and PSC will never come up. > > Once each side computes the negotiated set, they signal it and PSC > starts to work. > _______________________________________________ > 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 --_000_48E1A67CB9CA044EADFEAB87D814BFF642DEFCeusaamb107ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Malcolm,

 <= /p>

    &= nbsp;           Agreed.&n= bsp; See continuing discussion thread on why we might not want to

call this "negotiati= on."  There is no negotiation if an exact match is required…= ;

 <= /p>

--

Eric

 <= /p>

From: Malcolm.= BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn]
Sent: Wednesday, August 21, 2013 11:44 AM
To: Eric Gray
Cc: Eric Osborne (eosborne); Malcolm.BETTS@zte.com.cn; mpls@ietf.org= ; mpls-bounces@ietf.org
Subject: RE: [mpls] Mode negotiation for PSC
Importance: High

 

Hi Eric (G= ray),

I agree that we should not negotiate PSC modes "on the fly&= quot;, since selecting different options will result in different behaviour= in the network any negotiation should involve a human i..e reporting the miss match is all that we need to do.

As I pointed out below "negotiation" of the PSC option= s should take place before the LSP is set-up, PSC should only check that th= e options selected match (and report a miss match).

Regards,

Malcolm


Eric Gray <eric.gray@ericsson.com>

20/08/2013 02:41 PM

To

"Eric Osborne (eosborne)" <eosborne@cisco.com>, "Malcolm.BETTS@zte.com.cn" &= lt;Malcolm.BETTS@zte.com.cn= >

cc

"mpl= s@ietf.org" <mpls@ietf.org= >, "mpls-bounces@ietf.org<= /a>" <mpls-bounces@ietf.or= g>

Subject

RE: [mpls] Mode negotiation for PSC=

 




Eric (Osborne),

                While I agree t= hat we don't want to try to predict what will never ever
happen, there is more than a little bit of an issue with designing for = all possible
cases.

                Before we can r= eally get away with any approach that could conceivably
include N^2 combinations of options, we need to describe what each of t= hese
possibilities means, and how devices with arbitrary disagreement for th= e options
resolve the differences.

                And - while we'= re trying to cover the possible cases for known modes,
should we also try to allow for coverage of future (thus unknown) modes= ?

                Is this worth t= he trouble?  Are there use cases to support this, or are we
embarking on an academic exercise?

                What we really = need now is a simple binary indicator.  If we feel that any
negotiation is required, then it should be trivial.  If there is d= isagreement, then
everbody falls-back to a default mode.

                But I am not co= nvinced that any form of negotiation is required.

                In this discuss= ion, I am reminded that at least part of the discussion that
got us on the road of having two modes had to do with limited negotiati= on in the
case where PSC parameters did not match.  I believe that the decis= ion was that
reporting the inconsistency to the operator was sufficient from the per= spective
of any of us in the IETF, and that this was not sufficient to folks use= d to dealing
with APS.

                So, are we swit= ching from what was essentially non-negotiation of PSC
parameters to negotiation of PSC modes?  Seems counter-intuitive t= o me...

--
Eric (Gray)

-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Osborne (eosborne)
Sent: Friday, August 16, 2013 4:49 PM
To: Malcolm.BETTS@zte.com.c= n
Cc: mpls@ietf.org; mpls-bounces@ietf.org
Subject: Re: [mpls] Mode negotiation for PSC

Hi Malcolm-

 Thanks for this.  A few comments inline.


> -----Original Message-----
> From: Malcolm.BETTS@zt= e.com.cn [<= span style=3D"font-size:10.0pt">mailto:Malcolm.BETTS@zte.com.cn= ]
> Sent: Thursday, August 15, 2013 1:01 PM
> To: Eric Osborne (eosborne)
> Cc: mpls@ietf.org; mpls-bounces@ietf.org
> Subject: Re: [mpls] Mode negotiation for PSC
>
> Hi Eric,
>
> I have only seen one message on this thread so I will venture an <= /tt>
> opinion.
>
> My preference is for option 1 - no negotiation.
>
> My reasons are:
>
> Keep it simple!
>
> The major reason that network operator's have given for requesting=
> these enhanced capabilities is to maintain compatibility with exis= ting
> linear protection schemes. Within the network of a single operator= my
> assumption is that they want, above all else, consistent operation= .
> Therefore, I suspect that we will see two "camps" with e= ither all
> options active or no options active.
>

That's what it looks like now.  But I'm not terribly good at predi= cting what people will never, ever do.  I could see an implementation = which wants to support, say, MS-W but none of the other options.

> Interconnection of "transport" connections between netwo= rk operators
> is normally only allowed within the frame work of an agreement bet= ween
> the operators. As part of that agreement they would need to define= the
> linear protection options that would be used. The operational
> differences would be confined to the links that provide the <= br> > interconnection between networks of the different operators. The <= /tt>
> appropriate protection options would be configured (as defined by = the
> agreement) when the protected connection is set-up.

PSC has bits to indicate the protection type and revertive mode, and th= e logic we're going to add n draft-osborne explains what happens if two sid= es disagree.  Is this not a form of negotiatoin?

>
> Negotiation would allow the possibility of a variety of protection=
> options being active in the network which would result in inconsis= tent
> behaviour which would create operational complexity.

It is possible for one side to declare intransigence by setting the mas= k bits to all 1s.  This indicates that the Capabilities advertised by = that node must match exactly in order for things to work.  The two mod= es I think we'll see first are:

Cap=3D00000, Mask=3D11111
Cap=3D11111, Mask=3D11111

and these two will never agree on a mode since the mask of all 1s gives= neither side any room to move.

I'm not against the simpler mode, I just want to make sure that you und= erstand that it is possible to achieve that using the proposed negotiation = method.




eric


>
> Regards,
>
> Malcolm
>
>
>
>
>
> "Eric Osborne (eosborne)" <eosborne@cisco.com> Sent by:
> mpls-bounces@ietf.org=
>
> 08/08/2013 08:34 AM To
> "mpls@ietf.org" <= ;mpls@ietf.org>
> cc
> Subject
> [mpls] Mode negotiation for PSC
>
>
>
>
>
>
> As per last Friday's presentation in Berlin
> (http://www.ietf= .org/proceedings/87/slides/slides-87-mpls-15.ppt
> <http://www.i= etf.org/proceedings/87/slides/slides-87-mpls-15.ppt> ),
> we will be adding "ITU Mode" to PSC to allow for behavio= rs that
> satisfy both IETF and ITU requirements.  This mode will be
> backward-compatible and negotiated using PSC TLVs.
>
> The drafts in that ppt define five capabilities which separate ITU=
> mode from IETF mode.  IETF mode is defined as the absence of = these
> five capabilities, and ITU mode is defined as the use of all five = of
> these capabilities.  It may help to think of IETF mode as 000= 00 and
> ITU mode as 11111.  The mechanism to define and negotiate the= se modes
> will have room for expansion past five bits, so if we ever decide = we
> need more capabilities negotiation in PSC (shared mesh?  m:n?=  other
> fancy stuff?) we can.
>
> As of right now we are only discussing two modes, but it is possib= le
> to define a mode which is some combination of these five things ot= her
> than
> 00000 or 11111.  So a mode is really the set of negotiated
> capabilities between two devices.
>
> There are two ways we can negotiate the use of one more or the oth= er:
>
> 1) Each node announces the mode that it wants, and if the other si= de
> doesn't want exactly the same mode then PSC will not function. &nb= sp;That
> is, both nodes say "my mode is 0bxxxxx" (for now, either= 00000 or
> 11111) and if both nodes don't say the same thing then they compla= in
> to the operator and refuse to function.
>
> Advantage: easy, and if both ends are in a single administrative <= /tt>
> domain I expect the operator to be able to configure both ends to = match.
>
> Disadvantage: tricky if we ever start talking about modes other th= an
> 00000 or 11111.  I don't want a node to say "I support m= ode 00000,
> mode 00001, mode 00010, mode 00011, .... mode 11111" because = if we add
> a few more capabilities we could end up announcing the support of =
> hundreds or thousands of modes.  Does not allow PSC to come u= p unless
> the modes match on both sides, even if there is some common subset=
> they could both agree on.
>
>
> or
>
>
> 2) Each node announces the set of capabilities that it can support=
> along with the ones that it requires, and if the two nodes can fin= d a
> common subset of features then they will converge on those feature= s in PSC.
>
> Advantage: flexible.  If two endpoints can find a common feat= ure
> subset (see example below) then they will come up.
>
> Disadvantage: more complex code, easier to get wrong and converge = on a
> undesirable subset.
>
>
> Examples of each negotiation method are below, both for clarity an= d to
> demonstrate that method #2 works.  My question for the WG is,= which
> one would people prefer, and why?
>
>
>
>
>
>
> eric
>
>
> ---------------------------------
>
>
> Examples
> =3D=3D=3D=3D=3D=3D=3D=3D
> All examples are between two nodes, A and Z.  These examples = focus on
> the actual negotiation, not on the necessary TLV bits to enable th= e
> negotiation.
>
> Example of method 1
> -------------------
> Node A sends a single TLV to Node Z containg the mode bitmap. &nbs= p;Node Z
> sends the same to A.  Call them A.Mode and Z.Mode.  If t= hey do not
> match then some default behavior happens - either PSC doesn't come= up
> or they default to one predetermined mode.
>
> A.mode =3D Z. mode =3D 00000
> A->Z: "I am configured for mode 00000"
> Z->A: "I am configured for mode 00000"
>
> This results in PSC coming up in IETF mode.
>
> A.mode =3D Z.mode =3D 11111
> A->Z: "I am configured for mode 11111"
> Z->A: "I am configured for mode 11111"
>
> This results in PSC coming up in ITU mode.
>
> A.mode !=3D Z.mode (say, 00001 and 00010)
> A->Z: "I am configured for mode 00001"
> Z->A: "I am configured for mode 00010"
>
> PSC does not come up.
>
>
>
> Example of method 2
> -------------------
> Both Node A and Node Z announce two things - Capabilities and Mask= .
> Capabilities is a bitmap of the capabilities that are supported.
> Mask is a mask of don't-care bits against the Capabilities string.=  A
> 0 in Mask means "I don't care if we do this capability or not= ", and a
> 1 means "we must (or must not) agree on this capability in or= der to
> come up".
>
> A.capabilities =3D 00000
> A.mask         =3D 00000
>
> This says "I am capable of supporting all capabilities and I = don't
> care if we do any of them or not"
>
> A.capabilities =3D 00000
> A.mask         =3D 11111
>
> This says "We must not use any of the optional capabilities&q= uot; -
> Capabilities bits are all zero, and Mask bits say "we must ag= ree that
> the corresponding capability is zero".  This is 'IETF mo= de'.
>
> A.capabilities =3D 11111
> A.mask         =3D 11111
>
> This is 'ITU Mode'
>
> Where it gets complicated (or awesome, depending on your perspecti= ve)
> is when you have various subsets.  Consider:
>
> A.Capabilities =3D=3D 01100
> A.Mask =3D=3D 01100
>
> Z.Capabilities =3D=3D 01110
> Z.Mask =3D=3D 01110
>
>
> Negotiation procedures.
> Each side does:
>
>
> res =3D (A.Capabilites & Z.Mask) ^ (Z.Capabilities & A.Mas= k) res =3D
> (01100 & 01110) ^ (01110 & 01100) res =3D (01100) ^ (01100= ) res =3D 00000
>
> if res =3D=3D 0 then it is possible for both sides to find a commo= n subset
> that they support.
> This common subset is called the 'negotiated set', and is determin= ed by:
>
> negotiated_set =3D A.Capabilities | B.Capabilities negotiated_set = =3D
> 01100 | 01110 negotiated_set =3D 01100
>
> if res !=3D 0 then it is impossible to find a subset that the two = ends
> can agree on, and PSC will never come up.
>
> Once each side computes the negotiated set, they signal it and PSC=
> starts to work.
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo= /mpls
> <https://www.ietf.org/mailman/list= info/mpls> >

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

--_000_48E1A67CB9CA044EADFEAB87D814BFF642DEFCeusaamb107ericsso_-- From Malcolm.BETTS@zte.com.cn Thu Aug 22 07:16:09 2013 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 3930E21F8C9D; Thu, 22 Aug 2013 07:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.998 X-Spam-Level: X-Spam-Status: No, score=-101.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDfXgVu9Wcd3; Thu, 22 Aug 2013 07:16:04 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8584711E80F0; Thu, 22 Aug 2013 07:16:02 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 14B3712B6086; Thu, 22 Aug 2013 22:15:22 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r7MEFWeb095261; Thu, 22 Aug 2013 22:15:32 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF642DEFC@eusaamb107.ericsson.se> References: <20ECF67871905846A80F77F8F4A27572102C229B@xmb-rcd-x09.cisco.com> <20ECF67871905846A80F77F8F4A27572102EB9C5@xmb-rcd-x09.cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF642C376@eusaamb107.ericsson.se> <48E1A67CB9CA044EADFEAB87D814BFF642DEFC@eusaamb107.ericsson.se> To: Eric Gray MIME-Version: 1.0 X-KeepSent: 4CA00EE6:AD8B7DE8-85257BCF:004D81F1; 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, 22 Aug 2013 10:15:07 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-08-22 22:15:15, Serialize complete at 2013-08-22 22:15:15 Content-Type: multipart/alternative; boundary="=_alternative 004E595D85257BCF_=" X-MAIL: mse01.zte.com.cn r7MEFWeb095261 Cc: "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject: Re: [mpls] Mode negotiation for PSC 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, 22 Aug 2013 14:16:09 -0000 This is a multipart message in MIME format. --=_alternative 004E595D85257BCF_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgRXJpYyAoR3JheSkNCg0KSSBhZ3JlZSwgaWYgd2UgY29uY2x1ZGUgdGhhdCB3ZSBkbyBub3Qg d2FudCB0byBzdXBwb3J0IG5lZ290aWF0aW9uIGluIHRoZSANClBTQyBwcm90b2NvbCB3ZSBzaG91 bGQgY2FsbCB0aGlzICJvcHRpb24gY29uZmlybWF0aW9uIiBhcyBBZHJpYW4gDQpzdWdnZXN0ZWQu ICBUaGUgdGVybSAibW9kZSIgaXMgYWxyZWFkeSB1c2VkIGluIFJGQzYzNzggZS5nLiByZXZlcnRp dmUgDQptb2RlLCBub24tcmV2ZXJ0aXZlIG1vZGUgZXRjLg0KDQpSZWdhcmRzLA0KDQpNYWxjb2xt DQoNCg0KDQoNCkVyaWMgR3JheSA8ZXJpYy5ncmF5QGVyaWNzc29uLmNvbT4gDQoyMi8wOC8yMDEz IDA5OjM1IEFNDQoNClRvDQoiTWFsY29sbS5CRVRUU0B6dGUuY29tLmNuIiA8TWFsY29sbS5CRVRU U0B6dGUuY29tLmNuPg0KY2MNCiJFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSIgPGVvc2Jvcm5lQGNp c2NvLmNvbT4sICJtcGxzQGlldGYub3JnIiANCjxtcGxzQGlldGYub3JnPiwgIm1wbHMtYm91bmNl c0BpZXRmLm9yZyIgPG1wbHMtYm91bmNlc0BpZXRmLm9yZz4NClN1YmplY3QNClJFOiBbbXBsc10g TW9kZSBuZWdvdGlhdGlvbiBmb3IgUFNDDQoNCg0KDQoNCg0KDQpNYWxjb2xtLA0KIA0KICAgICAg ICAgICAgICAgIEFncmVlZC4gIFNlZSBjb250aW51aW5nIGRpc2N1c3Npb24gdGhyZWFkIG9uIHdo eSB3ZSBtaWdodCANCm5vdCB3YW50IHRvIA0KY2FsbCB0aGlzICJuZWdvdGlhdGlvbi4iICBUaGVy ZSBpcyBubyBuZWdvdGlhdGlvbiBpZiBhbiBleGFjdCBtYXRjaCBpcyANCnJlcXVpcmVk4oCmDQog DQotLQ0KRXJpYw0KIA0KRnJvbTogTWFsY29sbS5CRVRUU0B6dGUuY29tLmNuIFttYWlsdG86TWFs Y29sbS5CRVRUU0B6dGUuY29tLmNuXSANClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDIxLCAyMDEz IDExOjQ0IEFNDQpUbzogRXJpYyBHcmF5DQpDYzogRXJpYyBPc2Jvcm5lIChlb3Nib3JuZSk7IE1h bGNvbG0uQkVUVFNAenRlLmNvbS5jbjsgbXBsc0BpZXRmLm9yZzsgDQptcGxzLWJvdW5jZXNAaWV0 Zi5vcmcNClN1YmplY3Q6IFJFOiBbbXBsc10gTW9kZSBuZWdvdGlhdGlvbiBmb3IgUFNDDQpJbXBv cnRhbmNlOiBIaWdoDQogDQpIaSBFcmljIChHcmF5KSwgDQoNCkkgYWdyZWUgdGhhdCB3ZSBzaG91 bGQgbm90IG5lZ290aWF0ZSBQU0MgbW9kZXMgIm9uIHRoZSBmbHkiLCBzaW5jZSANCnNlbGVjdGlu ZyBkaWZmZXJlbnQgb3B0aW9ucyB3aWxsIHJlc3VsdCBpbiBkaWZmZXJlbnQgYmVoYXZpb3VyIGlu IHRoZSANCm5ldHdvcmsgYW55IG5lZ290aWF0aW9uIHNob3VsZCBpbnZvbHZlIGEgaHVtYW4gaS4u ZSByZXBvcnRpbmcgdGhlIG1pc3MgDQptYXRjaCBpcyBhbGwgdGhhdCB3ZSBuZWVkIHRvIGRvLiAN Cg0KQXMgSSBwb2ludGVkIG91dCBiZWxvdyAibmVnb3RpYXRpb24iIG9mIHRoZSBQU0Mgb3B0aW9u cyBzaG91bGQgdGFrZSBwbGFjZSANCmJlZm9yZSB0aGUgTFNQIGlzIHNldC11cCwgUFNDIHNob3Vs ZCBvbmx5IGNoZWNrIHRoYXQgdGhlIG9wdGlvbnMgc2VsZWN0ZWQgDQptYXRjaCAoYW5kIHJlcG9y dCBhIG1pc3MgbWF0Y2gpLiANCg0KUmVnYXJkcywgDQoNCk1hbGNvbG0gDQoNCg0KDQpFcmljIEdy YXkgPGVyaWMuZ3JheUBlcmljc3Nvbi5jb20+IA0KMjAvMDgvMjAxMyAwMjo0MSBQTSANCg0KDQpU bw0KIkVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpIiA8ZW9zYm9ybmVAY2lzY28uY29tPiwgIk1hbGNv bG0uQkVUVFNAenRlLmNvbS5jbiIgDQo8TWFsY29sbS5CRVRUU0B6dGUuY29tLmNuPiANCmNjDQoi bXBsc0BpZXRmLm9yZyIgPG1wbHNAaWV0Zi5vcmc+LCAibXBscy1ib3VuY2VzQGlldGYub3JnIiA8 DQptcGxzLWJvdW5jZXNAaWV0Zi5vcmc+IA0KU3ViamVjdA0KUkU6IFttcGxzXSBNb2RlIG5lZ290 aWF0aW9uIGZvciBQU0MNCiANCg0KDQoNCg0KDQoNCg0KDQpFcmljIChPc2Jvcm5lKSwNCg0KICAg ICAgICAgICAgICAgIFdoaWxlIEkgYWdyZWUgdGhhdCB3ZSBkb24ndCB3YW50IHRvIHRyeSB0byBw cmVkaWN0IHdoYXQgDQp3aWxsIG5ldmVyIGV2ZXINCmhhcHBlbiwgdGhlcmUgaXMgbW9yZSB0aGFu IGEgbGl0dGxlIGJpdCBvZiBhbiBpc3N1ZSB3aXRoIGRlc2lnbmluZyBmb3IgYWxsIA0KcG9zc2li bGUNCmNhc2VzLg0KDQogICAgICAgICAgICAgICAgQmVmb3JlIHdlIGNhbiByZWFsbHkgZ2V0IGF3 YXkgd2l0aCBhbnkgYXBwcm9hY2ggdGhhdCBjb3VsZCANCmNvbmNlaXZhYmx5DQppbmNsdWRlIE5e MiBjb21iaW5hdGlvbnMgb2Ygb3B0aW9ucywgd2UgbmVlZCB0byBkZXNjcmliZSB3aGF0IGVhY2gg b2YgDQp0aGVzZQ0KcG9zc2liaWxpdGllcyBtZWFucywgYW5kIGhvdyBkZXZpY2VzIHdpdGggYXJi aXRyYXJ5IGRpc2FncmVlbWVudCBmb3IgdGhlIA0Kb3B0aW9ucw0KcmVzb2x2ZSB0aGUgZGlmZmVy ZW5jZXMuDQoNCiAgICAgICAgICAgICAgICBBbmQgLSB3aGlsZSB3ZSdyZSB0cnlpbmcgdG8gY292 ZXIgdGhlIHBvc3NpYmxlIGNhc2VzIGZvciANCmtub3duIG1vZGVzLCANCnNob3VsZCB3ZSBhbHNv IHRyeSB0byBhbGxvdyBmb3IgY292ZXJhZ2Ugb2YgZnV0dXJlICh0aHVzIHVua25vd24pIG1vZGVz Pw0KDQogICAgICAgICAgICAgICAgSXMgdGhpcyB3b3J0aCB0aGUgdHJvdWJsZT8gIEFyZSB0aGVy ZSB1c2UgY2FzZXMgdG8gc3VwcG9ydCANCnRoaXMsIG9yIGFyZSB3ZQ0KZW1iYXJraW5nIG9uIGFu IGFjYWRlbWljIGV4ZXJjaXNlPw0KDQogICAgICAgICAgICAgICAgV2hhdCB3ZSByZWFsbHkgbmVl ZCBub3cgaXMgYSBzaW1wbGUgYmluYXJ5IGluZGljYXRvci4gIElmIA0Kd2UgZmVlbCB0aGF0IGFu eQ0KbmVnb3RpYXRpb24gaXMgcmVxdWlyZWQsIHRoZW4gaXQgc2hvdWxkIGJlIHRyaXZpYWwuICBJ ZiB0aGVyZSBpcyANCmRpc2FncmVlbWVudCwgdGhlbg0KZXZlcmJvZHkgZmFsbHMtYmFjayB0byBh IGRlZmF1bHQgbW9kZS4NCg0KICAgICAgICAgICAgICAgIEJ1dCBJIGFtIG5vdCBjb252aW5jZWQg dGhhdCBhbnkgZm9ybSBvZiBuZWdvdGlhdGlvbiBpcyANCnJlcXVpcmVkLg0KDQogICAgICAgICAg ICAgICAgSW4gdGhpcyBkaXNjdXNzaW9uLCBJIGFtIHJlbWluZGVkIHRoYXQgYXQgbGVhc3QgcGFy dCBvZiANCnRoZSBkaXNjdXNzaW9uIHRoYXQNCmdvdCB1cyBvbiB0aGUgcm9hZCBvZiBoYXZpbmcg dHdvIG1vZGVzIGhhZCB0byBkbyB3aXRoIGxpbWl0ZWQgbmVnb3RpYXRpb24gDQppbiB0aGUNCmNh c2Ugd2hlcmUgUFNDIHBhcmFtZXRlcnMgZGlkIG5vdCBtYXRjaC4gIEkgYmVsaWV2ZSB0aGF0IHRo ZSBkZWNpc2lvbiB3YXMgDQp0aGF0DQpyZXBvcnRpbmcgdGhlIGluY29uc2lzdGVuY3kgdG8gdGhl IG9wZXJhdG9yIHdhcyBzdWZmaWNpZW50IGZyb20gdGhlIA0KcGVyc3BlY3RpdmUgDQpvZiBhbnkg b2YgdXMgaW4gdGhlIElFVEYsIGFuZCB0aGF0IHRoaXMgd2FzIG5vdCBzdWZmaWNpZW50IHRvIGZv bGtzIHVzZWQgDQp0byBkZWFsaW5nIA0Kd2l0aCBBUFMuDQoNCiAgICAgICAgICAgICAgICBTbywg YXJlIHdlIHN3aXRjaGluZyBmcm9tIHdoYXQgd2FzIGVzc2VudGlhbGx5IA0Kbm9uLW5lZ290aWF0 aW9uIG9mIFBTQw0KcGFyYW1ldGVycyB0byBuZWdvdGlhdGlvbiBvZiBQU0MgbW9kZXM/ICBTZWVt cyBjb3VudGVyLWludHVpdGl2ZSB0byBtZS4uLg0KDQotLQ0KRXJpYyAoR3JheSkNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Om1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIA0KRXJpYyBPc2Jvcm5lIChlb3Ni b3JuZSkNClNlbnQ6IEZyaWRheSwgQXVndXN0IDE2LCAyMDEzIDQ6NDkgUE0NClRvOiBNYWxjb2xt LkJFVFRTQHp0ZS5jb20uY24NCkNjOiBtcGxzQGlldGYub3JnOyBtcGxzLWJvdW5jZXNAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbbXBsc10gTW9kZSBuZWdvdGlhdGlvbiBmb3IgUFNDDQoNCkhpIE1h bGNvbG0tDQoNCiBUaGFua3MgZm9yIHRoaXMuICBBIGZldyBjb21tZW50cyBpbmxpbmUuDQoNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYWxjb2xtLkJFVFRTQHp0ZS5j b20uY24gW21haWx0bzpNYWxjb2xtLkJFVFRTQHp0ZS5jb20uY25dDQo+IFNlbnQ6IFRodXJzZGF5 LCBBdWd1c3QgMTUsIDIwMTMgMTowMSBQTQ0KPiBUbzogRXJpYyBPc2Jvcm5lIChlb3Nib3JuZSkN Cj4gQ2M6IG1wbHNAaWV0Zi5vcmc7IG1wbHMtYm91bmNlc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBS ZTogW21wbHNdIE1vZGUgbmVnb3RpYXRpb24gZm9yIFBTQw0KPiANCj4gSGkgRXJpYywNCj4gDQo+ IEkgaGF2ZSBvbmx5IHNlZW4gb25lIG1lc3NhZ2Ugb24gdGhpcyB0aHJlYWQgc28gSSB3aWxsIHZl bnR1cmUgYW4gDQo+IG9waW5pb24uDQo+IA0KPiBNeSBwcmVmZXJlbmNlIGlzIGZvciBvcHRpb24g MSAtIG5vIG5lZ290aWF0aW9uLg0KPiANCj4gTXkgcmVhc29ucyBhcmU6DQo+IA0KPiBLZWVwIGl0 IHNpbXBsZSENCj4gDQo+IFRoZSBtYWpvciByZWFzb24gdGhhdCBuZXR3b3JrIG9wZXJhdG9yJ3Mg aGF2ZSBnaXZlbiBmb3IgcmVxdWVzdGluZyANCj4gdGhlc2UgZW5oYW5jZWQgY2FwYWJpbGl0aWVz IGlzIHRvIG1haW50YWluIGNvbXBhdGliaWxpdHkgd2l0aCBleGlzdGluZyANCj4gbGluZWFyIHBy b3RlY3Rpb24gc2NoZW1lcy4gV2l0aGluIHRoZSBuZXR3b3JrIG9mIGEgc2luZ2xlIG9wZXJhdG9y IG15IA0KPiBhc3N1bXB0aW9uIGlzIHRoYXQgdGhleSB3YW50LCBhYm92ZSBhbGwgZWxzZSwgY29u c2lzdGVudCBvcGVyYXRpb24uDQo+IFRoZXJlZm9yZSwgSSBzdXNwZWN0IHRoYXQgd2Ugd2lsbCBz ZWUgdHdvICJjYW1wcyIgd2l0aCBlaXRoZXIgYWxsIA0KPiBvcHRpb25zIGFjdGl2ZSBvciBubyBv cHRpb25zIGFjdGl2ZS4NCj4gDQoNClRoYXQncyB3aGF0IGl0IGxvb2tzIGxpa2Ugbm93LiAgQnV0 IEknbSBub3QgdGVycmlibHkgZ29vZCBhdCBwcmVkaWN0aW5nIA0Kd2hhdCBwZW9wbGUgd2lsbCBu ZXZlciwgZXZlciBkby4gIEkgY291bGQgc2VlIGFuIGltcGxlbWVudGF0aW9uIHdoaWNoIA0Kd2Fu dHMgdG8gc3VwcG9ydCwgc2F5LCBNUy1XIGJ1dCBub25lIG9mIHRoZSBvdGhlciBvcHRpb25zLg0K DQo+IEludGVyY29ubmVjdGlvbiBvZiAidHJhbnNwb3J0IiBjb25uZWN0aW9ucyBiZXR3ZWVuIG5l dHdvcmsgb3BlcmF0b3JzIA0KPiBpcyBub3JtYWxseSBvbmx5IGFsbG93ZWQgd2l0aGluIHRoZSBm cmFtZSB3b3JrIG9mIGFuIGFncmVlbWVudCBiZXR3ZWVuIA0KPiB0aGUgb3BlcmF0b3JzLiBBcyBw YXJ0IG9mIHRoYXQgYWdyZWVtZW50IHRoZXkgd291bGQgbmVlZCB0byBkZWZpbmUgdGhlIA0KPiBs aW5lYXIgcHJvdGVjdGlvbiBvcHRpb25zIHRoYXQgd291bGQgYmUgdXNlZC4gVGhlIG9wZXJhdGlv bmFsIA0KPiBkaWZmZXJlbmNlcyB3b3VsZCBiZSBjb25maW5lZCB0byB0aGUgbGlua3MgdGhhdCBw cm92aWRlIHRoZSANCj4gaW50ZXJjb25uZWN0aW9uIGJldHdlZW4gbmV0d29ya3Mgb2YgdGhlIGRp ZmZlcmVudCBvcGVyYXRvcnMuIFRoZSANCj4gYXBwcm9wcmlhdGUgcHJvdGVjdGlvbiBvcHRpb25z IHdvdWxkIGJlIGNvbmZpZ3VyZWQgKGFzIGRlZmluZWQgYnkgdGhlDQo+IGFncmVlbWVudCkgd2hl biB0aGUgcHJvdGVjdGVkIGNvbm5lY3Rpb24gaXMgc2V0LXVwLg0KDQpQU0MgaGFzIGJpdHMgdG8g aW5kaWNhdGUgdGhlIHByb3RlY3Rpb24gdHlwZSBhbmQgcmV2ZXJ0aXZlIG1vZGUsIGFuZCB0aGUg DQpsb2dpYyB3ZSdyZSBnb2luZyB0byBhZGQgbiBkcmFmdC1vc2Jvcm5lIGV4cGxhaW5zIHdoYXQg aGFwcGVucyBpZiB0d28gDQpzaWRlcyBkaXNhZ3JlZS4gIElzIHRoaXMgbm90IGEgZm9ybSBvZiBu ZWdvdGlhdG9pbj8NCg0KPiANCj4gTmVnb3RpYXRpb24gd291bGQgYWxsb3cgdGhlIHBvc3NpYmls aXR5IG9mIGEgdmFyaWV0eSBvZiBwcm90ZWN0aW9uIA0KPiBvcHRpb25zIGJlaW5nIGFjdGl2ZSBp biB0aGUgbmV0d29yayB3aGljaCB3b3VsZCByZXN1bHQgaW4gaW5jb25zaXN0ZW50IA0KPiBiZWhh dmlvdXIgd2hpY2ggd291bGQgY3JlYXRlIG9wZXJhdGlvbmFsIGNvbXBsZXhpdHkuDQoNCkl0IGlz IHBvc3NpYmxlIGZvciBvbmUgc2lkZSB0byBkZWNsYXJlIGludHJhbnNpZ2VuY2UgYnkgc2V0dGlu ZyB0aGUgbWFzayANCmJpdHMgdG8gYWxsIDFzLiAgVGhpcyBpbmRpY2F0ZXMgdGhhdCB0aGUgQ2Fw YWJpbGl0aWVzIGFkdmVydGlzZWQgYnkgdGhhdCANCm5vZGUgbXVzdCBtYXRjaCBleGFjdGx5IGlu IG9yZGVyIGZvciB0aGluZ3MgdG8gd29yay4gIFRoZSB0d28gbW9kZXMgSSANCnRoaW5rIHdlJ2xs IHNlZSBmaXJzdCBhcmU6DQoNCkNhcD0wMDAwMCwgTWFzaz0xMTExMQ0KQ2FwPTExMTExLCBNYXNr PTExMTExDQoNCmFuZCB0aGVzZSB0d28gd2lsbCBuZXZlciBhZ3JlZSBvbiBhIG1vZGUgc2luY2Ug dGhlIG1hc2sgb2YgYWxsIDFzIGdpdmVzIA0KbmVpdGhlciBzaWRlIGFueSByb29tIHRvIG1vdmUu DQoNCkknbSBub3QgYWdhaW5zdCB0aGUgc2ltcGxlciBtb2RlLCBJIGp1c3Qgd2FudCB0byBtYWtl IHN1cmUgdGhhdCB5b3UgDQp1bmRlcnN0YW5kIHRoYXQgaXQgaXMgcG9zc2libGUgdG8gYWNoaWV2 ZSB0aGF0IHVzaW5nIHRoZSBwcm9wb3NlZCANCm5lZ290aWF0aW9uIG1ldGhvZC4NCg0KDQoNCg0K ZXJpYw0KDQoNCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBNYWxjb2xtDQo+IA0KPiANCj4gDQo+IA0K PiANCj4gIkVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpIiA8ZW9zYm9ybmVAY2lzY28uY29tPiBTZW50 IGJ5OiANCj4gbXBscy1ib3VuY2VzQGlldGYub3JnDQo+IA0KPiAwOC8wOC8yMDEzIDA4OjM0IEFN IFRvDQo+ICJtcGxzQGlldGYub3JnIiA8bXBsc0BpZXRmLm9yZz4NCj4gY2MNCj4gU3ViamVjdA0K PiBbbXBsc10gTW9kZSBuZWdvdGlhdGlvbiBmb3IgUFNDDQo+IA0KPiANCj4gDQo+IA0KPiANCj4g DQo+IEFzIHBlciBsYXN0IEZyaWRheSdzIHByZXNlbnRhdGlvbiBpbiBCZXJsaW4gDQo+IChodHRw Oi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzg3L3NsaWRlcy9zbGlkZXMtODctbXBscy0xNS5w cHQNCj4gPGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODcvc2xpZGVzL3NsaWRlcy04 Ny1tcGxzLTE1LnBwdD4gKSwgDQo+IHdlIHdpbGwgYmUgYWRkaW5nICJJVFUgTW9kZSIgdG8gUFND IHRvIGFsbG93IGZvciBiZWhhdmlvcnMgdGhhdCANCj4gc2F0aXNmeSBib3RoIElFVEYgYW5kIElU VSByZXF1aXJlbWVudHMuICBUaGlzIG1vZGUgd2lsbCBiZSANCj4gYmFja3dhcmQtY29tcGF0aWJs ZSBhbmQgbmVnb3RpYXRlZCB1c2luZyBQU0MgVExWcy4NCj4gDQo+IFRoZSBkcmFmdHMgaW4gdGhh dCBwcHQgZGVmaW5lIGZpdmUgY2FwYWJpbGl0aWVzIHdoaWNoIHNlcGFyYXRlIElUVSANCj4gbW9k ZSBmcm9tIElFVEYgbW9kZS4gIElFVEYgbW9kZSBpcyBkZWZpbmVkIGFzIHRoZSBhYnNlbmNlIG9m IHRoZXNlIA0KPiBmaXZlIGNhcGFiaWxpdGllcywgYW5kIElUVSBtb2RlIGlzIGRlZmluZWQgYXMg dGhlIHVzZSBvZiBhbGwgZml2ZSBvZiANCj4gdGhlc2UgY2FwYWJpbGl0aWVzLiAgSXQgbWF5IGhl bHAgdG8gdGhpbmsgb2YgSUVURiBtb2RlIGFzIDAwMDAwIGFuZCANCj4gSVRVIG1vZGUgYXMgMTEx MTEuICBUaGUgbWVjaGFuaXNtIHRvIGRlZmluZSBhbmQgbmVnb3RpYXRlIHRoZXNlIG1vZGVzIA0K PiB3aWxsIGhhdmUgcm9vbSBmb3IgZXhwYW5zaW9uIHBhc3QgZml2ZSBiaXRzLCBzbyBpZiB3ZSBl dmVyIGRlY2lkZSB3ZSANCj4gbmVlZCBtb3JlIGNhcGFiaWxpdGllcyBuZWdvdGlhdGlvbiBpbiBQ U0MgKHNoYXJlZCBtZXNoPyAgbTpuPyAgb3RoZXIgDQo+IGZhbmN5IHN0dWZmPykgd2UgY2FuLg0K PiANCj4gQXMgb2YgcmlnaHQgbm93IHdlIGFyZSBvbmx5IGRpc2N1c3NpbmcgdHdvIG1vZGVzLCBi dXQgaXQgaXMgcG9zc2libGUgDQo+IHRvIGRlZmluZSBhIG1vZGUgd2hpY2ggaXMgc29tZSBjb21i aW5hdGlvbiBvZiB0aGVzZSBmaXZlIHRoaW5ncyBvdGhlciANCj4gdGhhbg0KPiAwMDAwMCBvciAx MTExMS4gIFNvIGEgbW9kZSBpcyByZWFsbHkgdGhlIHNldCBvZiBuZWdvdGlhdGVkIA0KPiBjYXBh YmlsaXRpZXMgYmV0d2VlbiB0d28gZGV2aWNlcy4NCj4gDQo+IFRoZXJlIGFyZSB0d28gd2F5cyB3 ZSBjYW4gbmVnb3RpYXRlIHRoZSB1c2Ugb2Ygb25lIG1vcmUgb3IgdGhlIG90aGVyOg0KPiANCj4g MSkgRWFjaCBub2RlIGFubm91bmNlcyB0aGUgbW9kZSB0aGF0IGl0IHdhbnRzLCBhbmQgaWYgdGhl IG90aGVyIHNpZGUgDQo+IGRvZXNuJ3Qgd2FudCBleGFjdGx5IHRoZSBzYW1lIG1vZGUgdGhlbiBQ U0Mgd2lsbCBub3QgZnVuY3Rpb24uICBUaGF0IA0KPiBpcywgYm90aCBub2RlcyBzYXkgIm15IG1v ZGUgaXMgMGJ4eHh4eCIgKGZvciBub3csIGVpdGhlciAwMDAwMCBvciANCj4gMTExMTEpIGFuZCBp ZiBib3RoIG5vZGVzIGRvbid0IHNheSB0aGUgc2FtZSB0aGluZyB0aGVuIHRoZXkgY29tcGxhaW4g DQo+IHRvIHRoZSBvcGVyYXRvciBhbmQgcmVmdXNlIHRvIGZ1bmN0aW9uLg0KPiANCj4gQWR2YW50 YWdlOiBlYXN5LCBhbmQgaWYgYm90aCBlbmRzIGFyZSBpbiBhIHNpbmdsZSBhZG1pbmlzdHJhdGl2 ZSANCj4gZG9tYWluIEkgZXhwZWN0IHRoZSBvcGVyYXRvciB0byBiZSBhYmxlIHRvIGNvbmZpZ3Vy ZSBib3RoIGVuZHMgdG8gbWF0Y2guDQo+IA0KPiBEaXNhZHZhbnRhZ2U6IHRyaWNreSBpZiB3ZSBl dmVyIHN0YXJ0IHRhbGtpbmcgYWJvdXQgbW9kZXMgb3RoZXIgdGhhbg0KPiAwMDAwMCBvciAxMTEx MS4gIEkgZG9uJ3Qgd2FudCBhIG5vZGUgdG8gc2F5ICJJIHN1cHBvcnQgbW9kZSAwMDAwMCwgDQo+ IG1vZGUgMDAwMDEsIG1vZGUgMDAwMTAsIG1vZGUgMDAwMTEsIC4uLi4gbW9kZSAxMTExMSIgYmVj YXVzZSBpZiB3ZSBhZGQgDQo+IGEgZmV3IG1vcmUgY2FwYWJpbGl0aWVzIHdlIGNvdWxkIGVuZCB1 cCBhbm5vdW5jaW5nIHRoZSBzdXBwb3J0IG9mIA0KPiBodW5kcmVkcyBvciB0aG91c2FuZHMgb2Yg bW9kZXMuICBEb2VzIG5vdCBhbGxvdyBQU0MgdG8gY29tZSB1cCB1bmxlc3MgDQo+IHRoZSBtb2Rl cyBtYXRjaCBvbiBib3RoIHNpZGVzLCBldmVuIGlmIHRoZXJlIGlzIHNvbWUgY29tbW9uIHN1YnNl dCANCj4gdGhleSBjb3VsZCBib3RoIGFncmVlIG9uLg0KPiANCj4gDQo+IG9yDQo+IA0KPiANCj4g MikgRWFjaCBub2RlIGFubm91bmNlcyB0aGUgc2V0IG9mIGNhcGFiaWxpdGllcyB0aGF0IGl0IGNh biBzdXBwb3J0IA0KPiBhbG9uZyB3aXRoIHRoZSBvbmVzIHRoYXQgaXQgcmVxdWlyZXMsIGFuZCBp ZiB0aGUgdHdvIG5vZGVzIGNhbiBmaW5kIGEgDQo+IGNvbW1vbiBzdWJzZXQgb2YgZmVhdHVyZXMg dGhlbiB0aGV5IHdpbGwgY29udmVyZ2Ugb24gdGhvc2UgZmVhdHVyZXMgaW4gDQpQU0MuDQo+IA0K PiBBZHZhbnRhZ2U6IGZsZXhpYmxlLiAgSWYgdHdvIGVuZHBvaW50cyBjYW4gZmluZCBhIGNvbW1v biBmZWF0dXJlIA0KPiBzdWJzZXQgKHNlZSBleGFtcGxlIGJlbG93KSB0aGVuIHRoZXkgd2lsbCBj b21lIHVwLg0KPiANCj4gRGlzYWR2YW50YWdlOiBtb3JlIGNvbXBsZXggY29kZSwgZWFzaWVyIHRv IGdldCB3cm9uZyBhbmQgY29udmVyZ2Ugb24gYSANCj4gdW5kZXNpcmFibGUgc3Vic2V0Lg0KPiAN Cj4gDQo+IEV4YW1wbGVzIG9mIGVhY2ggbmVnb3RpYXRpb24gbWV0aG9kIGFyZSBiZWxvdywgYm90 aCBmb3IgY2xhcml0eSBhbmQgdG8gDQo+IGRlbW9uc3RyYXRlIHRoYXQgbWV0aG9kICMyIHdvcmtz LiAgTXkgcXVlc3Rpb24gZm9yIHRoZSBXRyBpcywgd2hpY2ggDQo+IG9uZSB3b3VsZCBwZW9wbGUg cHJlZmVyLCBhbmQgd2h5Pw0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBlcmljDQo+IA0KPiAN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiANCj4gRXhhbXBsZXMN Cj4gPT09PT09PT0NCj4gQWxsIGV4YW1wbGVzIGFyZSBiZXR3ZWVuIHR3byBub2RlcywgQSBhbmQg Wi4gIFRoZXNlIGV4YW1wbGVzIGZvY3VzIG9uIA0KPiB0aGUgYWN0dWFsIG5lZ290aWF0aW9uLCBu b3Qgb24gdGhlIG5lY2Vzc2FyeSBUTFYgYml0cyB0byBlbmFibGUgdGhlIA0KPiBuZWdvdGlhdGlv bi4NCj4gDQo+IEV4YW1wbGUgb2YgbWV0aG9kIDENCj4gLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBO b2RlIEEgc2VuZHMgYSBzaW5nbGUgVExWIHRvIE5vZGUgWiBjb250YWluZyB0aGUgbW9kZSBiaXRt YXAuICBOb2RlIFogDQo+IHNlbmRzIHRoZSBzYW1lIHRvIEEuICBDYWxsIHRoZW0gQS5Nb2RlIGFu ZCBaLk1vZGUuICBJZiB0aGV5IGRvIG5vdCANCj4gbWF0Y2ggdGhlbiBzb21lIGRlZmF1bHQgYmVo YXZpb3IgaGFwcGVucyAtIGVpdGhlciBQU0MgZG9lc24ndCBjb21lIHVwIA0KPiBvciB0aGV5IGRl ZmF1bHQgdG8gb25lIHByZWRldGVybWluZWQgbW9kZS4NCj4gDQo+IEEubW9kZSA9IFouIG1vZGUg PSAwMDAwMA0KPiBBLT5aOiAiSSBhbSBjb25maWd1cmVkIGZvciBtb2RlIDAwMDAwIg0KPiBaLT5B OiAiSSBhbSBjb25maWd1cmVkIGZvciBtb2RlIDAwMDAwIg0KPiANCj4gVGhpcyByZXN1bHRzIGlu IFBTQyBjb21pbmcgdXAgaW4gSUVURiBtb2RlLg0KPiANCj4gQS5tb2RlID0gWi5tb2RlID0gMTEx MTENCj4gQS0+WjogIkkgYW0gY29uZmlndXJlZCBmb3IgbW9kZSAxMTExMSINCj4gWi0+QTogIkkg YW0gY29uZmlndXJlZCBmb3IgbW9kZSAxMTExMSINCj4gDQo+IFRoaXMgcmVzdWx0cyBpbiBQU0Mg Y29taW5nIHVwIGluIElUVSBtb2RlLg0KPiANCj4gQS5tb2RlICE9IFoubW9kZSAoc2F5LCAwMDAw MSBhbmQgMDAwMTApDQo+IEEtPlo6ICJJIGFtIGNvbmZpZ3VyZWQgZm9yIG1vZGUgMDAwMDEiDQo+ IFotPkE6ICJJIGFtIGNvbmZpZ3VyZWQgZm9yIG1vZGUgMDAwMTAiDQo+IA0KPiBQU0MgZG9lcyBu b3QgY29tZSB1cC4NCj4gDQo+IA0KPiANCj4gRXhhbXBsZSBvZiBtZXRob2QgMg0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tDQo+IEJvdGggTm9kZSBBIGFuZCBOb2RlIFogYW5ub3VuY2UgdHdvIHRoaW5n cyAtIENhcGFiaWxpdGllcyBhbmQgTWFzay4NCj4gQ2FwYWJpbGl0aWVzIGlzIGEgYml0bWFwIG9m IHRoZSBjYXBhYmlsaXRpZXMgdGhhdCBhcmUgc3VwcG9ydGVkLg0KPiBNYXNrIGlzIGEgbWFzayBv ZiBkb24ndC1jYXJlIGJpdHMgYWdhaW5zdCB0aGUgQ2FwYWJpbGl0aWVzIHN0cmluZy4gIEEgDQo+ IDAgaW4gTWFzayBtZWFucyAiSSBkb24ndCBjYXJlIGlmIHdlIGRvIHRoaXMgY2FwYWJpbGl0eSBv ciBub3QiLCBhbmQgYSANCj4gMSBtZWFucyAid2UgbXVzdCAob3IgbXVzdCBub3QpIGFncmVlIG9u IHRoaXMgY2FwYWJpbGl0eSBpbiBvcmRlciB0byANCj4gY29tZSB1cCIuDQo+IA0KPiBBLmNhcGFi aWxpdGllcyA9IDAwMDAwDQo+IEEubWFzayAgICAgICAgID0gMDAwMDANCj4gDQo+IFRoaXMgc2F5 cyAiSSBhbSBjYXBhYmxlIG9mIHN1cHBvcnRpbmcgYWxsIGNhcGFiaWxpdGllcyBhbmQgSSBkb24n dCANCj4gY2FyZSBpZiB3ZSBkbyBhbnkgb2YgdGhlbSBvciBub3QiDQo+IA0KPiBBLmNhcGFiaWxp dGllcyA9IDAwMDAwDQo+IEEubWFzayAgICAgICAgID0gMTExMTENCj4gDQo+IFRoaXMgc2F5cyAi V2UgbXVzdCBub3QgdXNlIGFueSBvZiB0aGUgb3B0aW9uYWwgY2FwYWJpbGl0aWVzIiAtIA0KPiBD YXBhYmlsaXRpZXMgYml0cyBhcmUgYWxsIHplcm8sIGFuZCBNYXNrIGJpdHMgc2F5ICJ3ZSBtdXN0 IGFncmVlIHRoYXQgDQo+IHRoZSBjb3JyZXNwb25kaW5nIGNhcGFiaWxpdHkgaXMgemVybyIuICBU aGlzIGlzICdJRVRGIG1vZGUnLg0KPiANCj4gQS5jYXBhYmlsaXRpZXMgPSAxMTExMQ0KPiBBLm1h c2sgICAgICAgICA9IDExMTExDQo+IA0KPiBUaGlzIGlzICdJVFUgTW9kZScNCj4gDQo+IFdoZXJl IGl0IGdldHMgY29tcGxpY2F0ZWQgKG9yIGF3ZXNvbWUsIGRlcGVuZGluZyBvbiB5b3VyIHBlcnNw ZWN0aXZlKSANCj4gaXMgd2hlbiB5b3UgaGF2ZSB2YXJpb3VzIHN1YnNldHMuICBDb25zaWRlcjoN Cj4gDQo+IEEuQ2FwYWJpbGl0aWVzID09IDAxMTAwDQo+IEEuTWFzayA9PSAwMTEwMA0KPiANCj4g Wi5DYXBhYmlsaXRpZXMgPT0gMDExMTANCj4gWi5NYXNrID09IDAxMTEwDQo+IA0KPiANCj4gTmVn b3RpYXRpb24gcHJvY2VkdXJlcy4NCj4gRWFjaCBzaWRlIGRvZXM6DQo+IA0KPiANCj4gcmVzID0g KEEuQ2FwYWJpbGl0ZXMgJiBaLk1hc2spIF4gKFouQ2FwYWJpbGl0aWVzICYgQS5NYXNrKSByZXMg PSANCj4gKDAxMTAwICYgMDExMTApIF4gKDAxMTEwICYgMDExMDApIHJlcyA9ICgwMTEwMCkgXiAo MDExMDApIHJlcyA9IDAwMDAwDQo+IA0KPiBpZiByZXMgPT0gMCB0aGVuIGl0IGlzIHBvc3NpYmxl IGZvciBib3RoIHNpZGVzIHRvIGZpbmQgYSBjb21tb24gc3Vic2V0IA0KPiB0aGF0IHRoZXkgc3Vw cG9ydC4NCj4gVGhpcyBjb21tb24gc3Vic2V0IGlzIGNhbGxlZCB0aGUgJ25lZ290aWF0ZWQgc2V0 JywgYW5kIGlzIGRldGVybWluZWQgYnk6DQo+IA0KPiBuZWdvdGlhdGVkX3NldCA9IEEuQ2FwYWJp bGl0aWVzIHwgQi5DYXBhYmlsaXRpZXMgbmVnb3RpYXRlZF9zZXQgPSANCj4gMDExMDAgfCAwMTEx MCBuZWdvdGlhdGVkX3NldCA9IDAxMTAwDQo+IA0KPiBpZiByZXMgIT0gMCB0aGVuIGl0IGlzIGlt cG9zc2libGUgdG8gZmluZCBhIHN1YnNldCB0aGF0IHRoZSB0d28gZW5kcyANCj4gY2FuIGFncmVl IG9uLCBhbmQgUFNDIHdpbGwgbmV2ZXIgY29tZSB1cC4NCj4gDQo+IE9uY2UgZWFjaCBzaWRlIGNv bXB1dGVzIHRoZSBuZWdvdGlhdGVkIHNldCwgdGhleSBzaWduYWwgaXQgYW5kIFBTQyANCj4gc3Rh cnRzIHRvIHdvcmsuDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IG1wbHMgbWFpbGluZyBsaXN0DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+IDxodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHM+DQo+IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQo= --=_alternative 004E595D85257BCF_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEVyaWMgKEdyYXkpPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIGFncmVlLCBpZiB3ZSBjb25j bHVkZSB0aGF0IHdlIGRvIG5vdA0Kd2FudCB0byBzdXBwb3J0IG5lZ290aWF0aW9uIGluIHRoZSBQ U0MgcHJvdG9jb2wgd2Ugc2hvdWxkIGNhbGwgdGhpcyAmcXVvdDtvcHRpb24NCmNvbmZpcm1hdGlv biZxdW90OyBhcyBBZHJpYW4gc3VnZ2VzdGVkLiAmbmJzcDtUaGUgdGVybSAmcXVvdDttb2RlJnF1 b3Q7DQppcyBhbHJlYWR5IHVzZWQgaW4gUkZDNjM3OCBlLmcuIHJldmVydGl2ZSBtb2RlLCBub24t cmV2ZXJ0aXZlIG1vZGUgZXRjLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+UmVnYXJkcyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPk1hbGNvbG08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+RXJpYyBHcmF5ICZsdDtlcmljLmdyYXlAZXJpY3Nzb24u Y29tJmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4y Mi8wOC8yMDEzIDA5OjM1IEFNPC9mb250Pg0KPHRkIHdpZHRoPTYzJT4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj5UbzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+JnF1b3Q7TWFsY29sbS5CRVRUU0B6dGUuY29tLmNuJnF1b3Q7DQombHQ7 TWFsY29sbS5CRVRUU0B6dGUuY29tLmNuJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Y2M8L2Zv bnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O0VyaWMg T3Nib3JuZSAoZW9zYm9ybmUpJnF1b3Q7DQombHQ7ZW9zYm9ybmVAY2lzY28uY29tJmd0OywgJnF1 b3Q7bXBsc0BpZXRmLm9yZyZxdW90OyAmbHQ7bXBsc0BpZXRmLm9yZyZndDssDQomcXVvdDttcGxz LWJvdW5jZXNAaWV0Zi5vcmcmcXVvdDsgJmx0O21wbHMtYm91bmNlc0BpZXRmLm9yZyZndDs8L2Zv bnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPlN1YmplY3Q8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPlJFOiBbbXBsc10gTW9kZSBuZWdvdGlhdGlvbiBmb3IgUFNDPC9m b250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48 L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9y PSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+TWFsY29sbSw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEFncmVlZC4gJm5ic3A7U2VlIGNvbnRp bnVpbmcgZGlzY3Vzc2lvbiB0aHJlYWQNCm9uIHdoeSB3ZSBtaWdodCBub3Qgd2FudCB0byA8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+Y2FsbCB0 aGlzICZxdW90O25lZ290aWF0aW9uLiZxdW90Ow0KJm5ic3A7VGhlcmUgaXMgbm8gbmVnb3RpYXRp b24gaWYgYW4gZXhhY3QgbWF0Y2ggaXMgcmVxdWlyZWTigKY8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPi0tPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPkVyaWM8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPkZyb206PC9iPiBNYWxjb2xtLkJFVFRTQHp0 ZS5jb20uY24gWzwvZm9udD48YSBocmVmPW1haWx0bzpNYWxjb2xtLkJFVFRTQHp0ZS5jb20uY24+ PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+bWFpbHRvOk1hbGNvbG0uQkVUVFNAenRlLmNvbS5j bjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+XQ0KPGI+PGJyPg0KU2VudDo8 L2I+IFdlZG5lc2RheSwgQXVndXN0IDIxLCAyMDEzIDExOjQ0IEFNPGI+PGJyPg0KVG86PC9iPiBF cmljIEdyYXk8Yj48YnI+DQpDYzo8L2I+IEVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpOyBNYWxjb2xt LkJFVFRTQHp0ZS5jb20uY247IG1wbHNAaWV0Zi5vcmc7DQptcGxzLWJvdW5jZXNAaWV0Zi5vcmc8 Yj48YnI+DQpTdWJqZWN0OjwvYj4gUkU6IFttcGxzXSBNb2RlIG5lZ290aWF0aW9uIGZvciBQU0M8 Yj48YnI+DQpJbXBvcnRhbmNlOjwvYj4gSGlnaDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkFyaWFsIj5IaSBFcmljIChHcmF5KSw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpJ IGFncmVlIHRoYXQgd2Ugc2hvdWxkIG5vdCBuZWdvdGlhdGUgUFNDIG1vZGVzICZxdW90O29uIHRo ZSBmbHkmcXVvdDssDQpzaW5jZSBzZWxlY3RpbmcgZGlmZmVyZW50IG9wdGlvbnMgd2lsbCByZXN1 bHQgaW4gZGlmZmVyZW50IGJlaGF2aW91ciBpbg0KdGhlIG5ldHdvcmsgYW55IG5lZ290aWF0aW9u IHNob3VsZCBpbnZvbHZlIGEgaHVtYW4gaS4uZSByZXBvcnRpbmcgdGhlIG1pc3MNCm1hdGNoIGlz IGFsbCB0aGF0IHdlIG5lZWQgdG8gZG8uPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0K QXMgSSBwb2ludGVkIG91dCBiZWxvdyAmcXVvdDtuZWdvdGlhdGlvbiZxdW90OyBvZiB0aGUgUFND IG9wdGlvbnMgc2hvdWxkDQp0YWtlIHBsYWNlIGJlZm9yZSB0aGUgTFNQIGlzIHNldC11cCwgUFND IHNob3VsZCBvbmx5IGNoZWNrIHRoYXQgdGhlIG9wdGlvbnMNCnNlbGVjdGVkIG1hdGNoIChhbmQg cmVwb3J0IGEgbWlzcyBtYXRjaCkuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KUmVn YXJkcyw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCjwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCk1hbGNvbG08L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCjxicj4NCjwvZm9udD4NCjxwPg0K PHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNSU+PGZvbnQg c2l6ZT0xIGZhY2U9IkFyaWFsIj48Yj5FcmljIEdyYXkgJmx0OzwvYj48L2ZvbnQ+PGEgaHJlZj1t YWlsdG86ZXJpYy5ncmF5QGVyaWNzc29uLmNvbT48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNl PSJBcmlhbCI+PGI+PHU+ZXJpYy5ncmF5QGVyaWNzc29uLmNvbTwvdT48L2I+PC9mb250PjwvYT48 Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjxiPiZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBz aXplPTEgZmFjZT0iQXJpYWwiPjIwLzA4LzIwMTMgMDI6NDEgUE08L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+DQo8dGQgd2lkdGg9NzQlPg0KPGJyPg0K PHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD02JT4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj5UbzwvZm9udD48L2Rpdj4NCjx0 ZCB3aWR0aD05MyU+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mcXVvdDtFcmljIE9zYm9ybmUg KGVvc2Jvcm5lKSZxdW90Ow0KJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzplb3Nib3JuZUBjaXNj by5jb20+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1PmVvc2Jvcm5lQGNp c2NvLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+Jmd0OywNCiZx dW90OzwvZm9udD48YSBocmVmPW1haWx0bzpNYWxjb2xtLkJFVFRTQHp0ZS5jb20uY24+PGZvbnQg c2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1Pk1hbGNvbG0uQkVUVFNAenRlLmNvbS5j bjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+JnF1b3Q7DQombHQ7PC9m b250PjxhIGhyZWY9bWFpbHRvOk1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbj48Zm9udCBzaXplPTEg Y29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+TWFsY29sbS5CRVRUU0B6dGUuY29tLmNuPC91Pjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mZ3Q7PC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+Y2M8L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mcXVvdDs8L2ZvbnQ+PGEgaHJlZj1t YWlsdG86bXBsc0BpZXRmLm9yZz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+ PHU+bXBsc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+ JnF1b3Q7DQombHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOm1wbHNAaWV0Zi5vcmc+PGZvbnQgc2l6 ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1Pm1wbHNAaWV0Zi5vcmc8L3U+PC9mb250Pjwv YT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZndDssDQomcXVvdDs8L2ZvbnQ+PGEgaHJlZj0i bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFj ZT0iQXJpYWwiPjx1Pm1wbHMtYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNp emU9MSBmYWNlPSJBcmlhbCI+JnF1b3Q7DQombHQ7PC9mb250PjxhIGhyZWY9Im1haWx0bzptcGxz LWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48 dT5tcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0i QXJpYWwiPiZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8 L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9IkFyaWFsIj5TdWJqZWN0PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJBcmlhbCI+UkU6IFttcGxzXSBNb2RlIG5lZ290aWF0aW9uIGZvciBQU0M8L2ZvbnQ+PC90 YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2Zv bnQ+DQo8cD4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFi bGU+DQo8YnI+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+ DQpFcmljIChPc2Jvcm5lKSw8YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1doaWxlIEkgYWdyZWUgdGhhdA0Kd2UgZG9uJ3Qg d2FudCB0byB0cnkgdG8gcHJlZGljdCB3aGF0IHdpbGwgbmV2ZXIgZXZlcjxicj4NCmhhcHBlbiwg dGhlcmUgaXMgbW9yZSB0aGFuIGEgbGl0dGxlIGJpdCBvZiBhbiBpc3N1ZSB3aXRoIGRlc2lnbmlu ZyBmb3INCmFsbCBwb3NzaWJsZTxicj4NCmNhc2VzLjxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QmVmb3JlIHdlIGNhbiBy ZWFsbHkNCmdldCBhd2F5IHdpdGggYW55IGFwcHJvYWNoIHRoYXQgY291bGQgY29uY2VpdmFibHk8 YnI+DQppbmNsdWRlIE5eMiBjb21iaW5hdGlvbnMgb2Ygb3B0aW9ucywgd2UgbmVlZCB0byBkZXNj cmliZSB3aGF0IGVhY2ggb2YgdGhlc2U8YnI+DQpwb3NzaWJpbGl0aWVzIG1lYW5zLCBhbmQgaG93 IGRldmljZXMgd2l0aCBhcmJpdHJhcnkgZGlzYWdyZWVtZW50IGZvciB0aGUNCm9wdGlvbnM8YnI+ DQpyZXNvbHZlIHRoZSBkaWZmZXJlbmNlcy48YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0FuZCAtIHdoaWxlIHdlJ3JlDQp0 cnlpbmcgdG8gY292ZXIgdGhlIHBvc3NpYmxlIGNhc2VzIGZvciBrbm93biBtb2RlcywgPGJyPg0K c2hvdWxkIHdlIGFsc28gdHJ5IHRvIGFsbG93IGZvciBjb3ZlcmFnZSBvZiBmdXR1cmUgKHRodXMg dW5rbm93bikgbW9kZXM/PGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJcyB0aGlzIHdvcnRoIHRoZQ0KdHJvdWJsZT8gJm5i c3A7QXJlIHRoZXJlIHVzZSBjYXNlcyB0byBzdXBwb3J0IHRoaXMsIG9yIGFyZSB3ZTxicj4NCmVt YmFya2luZyBvbiBhbiBhY2FkZW1pYyBleGVyY2lzZT88YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1doYXQgd2UgcmVhbGx5 DQpuZWVkIG5vdyBpcyBhIHNpbXBsZSBiaW5hcnkgaW5kaWNhdG9yLiAmbmJzcDtJZiB3ZSBmZWVs IHRoYXQgYW55PGJyPg0KbmVnb3RpYXRpb24gaXMgcmVxdWlyZWQsIHRoZW4gaXQgc2hvdWxkIGJl IHRyaXZpYWwuICZuYnNwO0lmIHRoZXJlIGlzIGRpc2FncmVlbWVudCwNCnRoZW48YnI+DQpldmVy Ym9keSBmYWxscy1iYWNrIHRvIGEgZGVmYXVsdCBtb2RlLjxicj4NCjxicj4NCiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QnV0IEkgYW0gbm90 IGNvbnZpbmNlZA0KdGhhdCBhbnkgZm9ybSBvZiBuZWdvdGlhdGlvbiBpcyByZXF1aXJlZC48YnI+ DQo8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO0luIHRoaXMgZGlzY3Vzc2lvbiwNCkkgYW0gcmVtaW5kZWQgdGhhdCBhdCBsZWFzdCBw YXJ0IG9mIHRoZSBkaXNjdXNzaW9uIHRoYXQ8YnI+DQpnb3QgdXMgb24gdGhlIHJvYWQgb2YgaGF2 aW5nIHR3byBtb2RlcyBoYWQgdG8gZG8gd2l0aCBsaW1pdGVkIG5lZ290aWF0aW9uDQppbiB0aGU8 YnI+DQpjYXNlIHdoZXJlIFBTQyBwYXJhbWV0ZXJzIGRpZCBub3QgbWF0Y2guICZuYnNwO0kgYmVs aWV2ZSB0aGF0IHRoZSBkZWNpc2lvbg0Kd2FzIHRoYXQ8YnI+DQpyZXBvcnRpbmcgdGhlIGluY29u c2lzdGVuY3kgdG8gdGhlIG9wZXJhdG9yIHdhcyBzdWZmaWNpZW50IGZyb20gdGhlIHBlcnNwZWN0 aXZlDQo8YnI+DQpvZiBhbnkgb2YgdXMgaW4gdGhlIElFVEYsIGFuZCB0aGF0IHRoaXMgd2FzIG5v dCBzdWZmaWNpZW50IHRvIGZvbGtzIHVzZWQNCnRvIGRlYWxpbmcgPGJyPg0Kd2l0aCBBUFMuPGJy Pg0KPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtTbywgYXJlIHdlIHN3aXRjaGluZw0KZnJvbSB3aGF0IHdhcyBlc3NlbnRpYWxseSBu b24tbmVnb3RpYXRpb24gb2YgUFNDPGJyPg0KcGFyYW1ldGVycyB0byBuZWdvdGlhdGlvbiBvZiBQ U0MgbW9kZXM/ICZuYnNwO1NlZW1zIGNvdW50ZXItaW50dWl0aXZlIHRvDQptZS4uLjxicj4NCjxi cj4NCi0tPGJyPg0KRXJpYyAoR3JheSk8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj4NCkZyb206IDwvZm9udD48YSBocmVmPSJtYWlsdG86bXBscy1ib3VuY2VzQGlldGYu b3JnIj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+bXBscy1i b3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij4NCls8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyI+PGZv bnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1Pm1haWx0bzptcGxzLWJv dW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPl0NCk9uIEJlaGFsZiBPZiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKTxicj4NClNlbnQ6IEZy aWRheSwgQXVndXN0IDE2LCAyMDEzIDQ6NDkgUE08YnI+DQpUbzogPC9mb250PjxhIGhyZWY9bWFp bHRvOk1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNl PSJDb3VyaWVyIE5ldyI+PHU+TWFsY29sbS5CRVRUU0B6dGUuY29tLmNuPC91PjwvZm9udD48L2E+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpDYzogPC9mb250PjxhIGhyZWY9 bWFpbHRvOm1wbHNAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmll ciBOZXciPjx1Pm1wbHNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPjsNCjwvZm9udD48YSBocmVmPSJtYWlsdG86bXBscy1ib3VuY2VzQGlldGYu b3JnIj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+bXBscy1i b3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij48YnI+DQpTdWJqZWN0OiBSZTogW21wbHNdIE1vZGUgbmVnb3RpYXRpb24gZm9yIFBTQzxi cj4NCjxicj4NCkhpIE1hbGNvbG0tPGJyPg0KPGJyPg0KIFRoYW5rcyBmb3IgdGhpcy4gJm5ic3A7 QSBmZXcgY29tbWVudHMgaW5saW5lLjxicj4NCjxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IDwvZm9udD48YSBocmVmPW1haWx0bzpNYWxj b2xtLkJFVFRTQHp0ZS5jb20uY24+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmll ciBOZXciPjx1Pk1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+DQpbPC9mb250PjxhIGhyZWY9bWFpbHRvOk1hbGNvbG0u QkVUVFNAenRlLmNvbS5jbj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5l dyI+PHU+bWFpbHRvOk1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+XTxicj4NCiZndDsgU2VudDogVGh1cnNkYXksIEF1 Z3VzdCAxNSwgMjAxMyAxOjAxIFBNPGJyPg0KJmd0OyBUbzogRXJpYyBPc2Jvcm5lIChlb3Nib3Ju ZSk8YnI+DQomZ3Q7IENjOiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86bXBsc0BpZXRmLm9yZz48Zm9u dCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+bXBsc0BpZXRmLm9yZzwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Ow0KPC9mb250Pjxh IGhyZWY9Im1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MiBjb2xvcj1i bHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5tcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250 PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiZndDsgU3ViamVjdDog UmU6IFttcGxzXSBNb2RlIG5lZ290aWF0aW9uIGZvciBQU0M8YnI+DQomZ3Q7IDxicj4NCiZndDsg SGkgRXJpYyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBoYXZlIG9ubHkgc2VlbiBvbmUgbWVzc2Fn ZSBvbiB0aGlzIHRocmVhZCBzbyBJIHdpbGwgdmVudHVyZSBhbiA8YnI+DQomZ3Q7IG9waW5pb24u PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE15IHByZWZlcmVuY2UgaXMgZm9yIG9wdGlvbiAxIC0gbm8g bmVnb3RpYXRpb24uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE15IHJlYXNvbnMgYXJlOjxicj4NCiZn dDsgPGJyPg0KJmd0OyBLZWVwIGl0IHNpbXBsZSE8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIG1h am9yIHJlYXNvbiB0aGF0IG5ldHdvcmsgb3BlcmF0b3IncyBoYXZlIGdpdmVuIGZvciByZXF1ZXN0 aW5nDQo8YnI+DQomZ3Q7IHRoZXNlIGVuaGFuY2VkIGNhcGFiaWxpdGllcyBpcyB0byBtYWludGFp biBjb21wYXRpYmlsaXR5IHdpdGggZXhpc3RpbmcNCjxicj4NCiZndDsgbGluZWFyIHByb3RlY3Rp b24gc2NoZW1lcy4gV2l0aGluIHRoZSBuZXR3b3JrIG9mIGEgc2luZ2xlIG9wZXJhdG9yDQpteSA8 YnI+DQomZ3Q7IGFzc3VtcHRpb24gaXMgdGhhdCB0aGV5IHdhbnQsIGFib3ZlIGFsbCBlbHNlLCBj b25zaXN0ZW50IG9wZXJhdGlvbi48YnI+DQomZ3Q7IFRoZXJlZm9yZSwgSSBzdXNwZWN0IHRoYXQg d2Ugd2lsbCBzZWUgdHdvICZxdW90O2NhbXBzJnF1b3Q7IHdpdGggZWl0aGVyDQphbGwgPGJyPg0K Jmd0OyBvcHRpb25zIGFjdGl2ZSBvciBubyBvcHRpb25zIGFjdGl2ZS48YnI+DQomZ3Q7IDxicj4N Cjxicj4NClRoYXQncyB3aGF0IGl0IGxvb2tzIGxpa2Ugbm93LiAmbmJzcDtCdXQgSSdtIG5vdCB0 ZXJyaWJseSBnb29kIGF0IHByZWRpY3RpbmcNCndoYXQgcGVvcGxlIHdpbGwgbmV2ZXIsIGV2ZXIg ZG8uICZuYnNwO0kgY291bGQgc2VlIGFuIGltcGxlbWVudGF0aW9uIHdoaWNoDQp3YW50cyB0byBz dXBwb3J0LCBzYXksIE1TLVcgYnV0IG5vbmUgb2YgdGhlIG90aGVyIG9wdGlvbnMuPGJyPg0KPGJy Pg0KJmd0OyBJbnRlcmNvbm5lY3Rpb24gb2YgJnF1b3Q7dHJhbnNwb3J0JnF1b3Q7IGNvbm5lY3Rp b25zIGJldHdlZW4gbmV0d29yaw0Kb3BlcmF0b3JzIDxicj4NCiZndDsgaXMgbm9ybWFsbHkgb25s eSBhbGxvd2VkIHdpdGhpbiB0aGUgZnJhbWUgd29yayBvZiBhbiBhZ3JlZW1lbnQgYmV0d2Vlbg0K PGJyPg0KJmd0OyB0aGUgb3BlcmF0b3JzLiBBcyBwYXJ0IG9mIHRoYXQgYWdyZWVtZW50IHRoZXkg d291bGQgbmVlZCB0byBkZWZpbmUNCnRoZSA8YnI+DQomZ3Q7IGxpbmVhciBwcm90ZWN0aW9uIG9w dGlvbnMgdGhhdCB3b3VsZCBiZSB1c2VkLiBUaGUgb3BlcmF0aW9uYWwgPGJyPg0KJmd0OyBkaWZm ZXJlbmNlcyB3b3VsZCBiZSBjb25maW5lZCB0byB0aGUgbGlua3MgdGhhdCBwcm92aWRlIHRoZSA8 YnI+DQomZ3Q7IGludGVyY29ubmVjdGlvbiBiZXR3ZWVuIG5ldHdvcmtzIG9mIHRoZSBkaWZmZXJl bnQgb3BlcmF0b3JzLiBUaGUgPGJyPg0KJmd0OyBhcHByb3ByaWF0ZSBwcm90ZWN0aW9uIG9wdGlv bnMgd291bGQgYmUgY29uZmlndXJlZCAoYXMgZGVmaW5lZCBieQ0KdGhlPGJyPg0KJmd0OyBhZ3Jl ZW1lbnQpIHdoZW4gdGhlIHByb3RlY3RlZCBjb25uZWN0aW9uIGlzIHNldC11cC48YnI+DQo8YnI+ DQpQU0MgaGFzIGJpdHMgdG8gaW5kaWNhdGUgdGhlIHByb3RlY3Rpb24gdHlwZSBhbmQgcmV2ZXJ0 aXZlIG1vZGUsIGFuZCB0aGUNCmxvZ2ljIHdlJ3JlIGdvaW5nIHRvIGFkZCBuIGRyYWZ0LW9zYm9y bmUgZXhwbGFpbnMgd2hhdCBoYXBwZW5zIGlmIHR3byBzaWRlcw0KZGlzYWdyZWUuICZuYnNwO0lz IHRoaXMgbm90IGEgZm9ybSBvZiBuZWdvdGlhdG9pbj88YnI+DQo8YnI+DQomZ3Q7IDxicj4NCiZn dDsgTmVnb3RpYXRpb24gd291bGQgYWxsb3cgdGhlIHBvc3NpYmlsaXR5IG9mIGEgdmFyaWV0eSBv ZiBwcm90ZWN0aW9uDQo8YnI+DQomZ3Q7IG9wdGlvbnMgYmVpbmcgYWN0aXZlIGluIHRoZSBuZXR3 b3JrIHdoaWNoIHdvdWxkIHJlc3VsdCBpbiBpbmNvbnNpc3RlbnQNCjxicj4NCiZndDsgYmVoYXZp b3VyIHdoaWNoIHdvdWxkIGNyZWF0ZSBvcGVyYXRpb25hbCBjb21wbGV4aXR5Ljxicj4NCjxicj4N Ckl0IGlzIHBvc3NpYmxlIGZvciBvbmUgc2lkZSB0byBkZWNsYXJlIGludHJhbnNpZ2VuY2UgYnkg c2V0dGluZyB0aGUgbWFzaw0KYml0cyB0byBhbGwgMXMuICZuYnNwO1RoaXMgaW5kaWNhdGVzIHRo YXQgdGhlIENhcGFiaWxpdGllcyBhZHZlcnRpc2VkIGJ5DQp0aGF0IG5vZGUgbXVzdCBtYXRjaCBl eGFjdGx5IGluIG9yZGVyIGZvciB0aGluZ3MgdG8gd29yay4gJm5ic3A7VGhlIHR3bw0KbW9kZXMg SSB0aGluayB3ZSdsbCBzZWUgZmlyc3QgYXJlOjxicj4NCjxicj4NCkNhcD0wMDAwMCwgTWFzaz0x MTExMTxicj4NCkNhcD0xMTExMSwgTWFzaz0xMTExMTxicj4NCjxicj4NCmFuZCB0aGVzZSB0d28g d2lsbCBuZXZlciBhZ3JlZSBvbiBhIG1vZGUgc2luY2UgdGhlIG1hc2sgb2YgYWxsIDFzIGdpdmVz DQpuZWl0aGVyIHNpZGUgYW55IHJvb20gdG8gbW92ZS48YnI+DQo8YnI+DQpJJ20gbm90IGFnYWlu c3QgdGhlIHNpbXBsZXIgbW9kZSwgSSBqdXN0IHdhbnQgdG8gbWFrZSBzdXJlIHRoYXQgeW91IHVu ZGVyc3RhbmQNCnRoYXQgaXQgaXMgcG9zc2libGUgdG8gYWNoaWV2ZSB0aGF0IHVzaW5nIHRoZSBw cm9wb3NlZCBuZWdvdGlhdGlvbiBtZXRob2QuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K ZXJpYzxicj4NCjxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBSZWdhcmRzLDxicj4NCiZndDsg PGJyPg0KJmd0OyBNYWxjb2xtPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJnF1b3Q7RXJpYyBPc2Jvcm5lIChlb3Nib3JuZSkm cXVvdDsgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzplb3Nib3JuZUBjaXNjby5jb20+PGZvbnQg c2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1PmVvc2Jvcm5lQGNpc2NvLmNv bTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0Ow0KU2Vu dCBieTogPGJyPg0KJmd0OyA8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRm Lm9yZyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1Pm1wbHMt Ym91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDA4LzA4LzIwMTMgMDg6MzQgQU0gVG88YnI+DQom Z3Q7ICZxdW90OzwvZm9udD48YSBocmVmPW1haWx0bzptcGxzQGlldGYub3JnPjxmb250IHNpemU9 MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5tcGxzQGlldGYub3JnPC91PjwvZm9u dD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mcXVvdDsNCiZsdDs8L2ZvbnQ+ PGEgaHJlZj1tYWlsdG86bXBsc0BpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNl PSJDb3VyaWVyIE5ldyI+PHU+bXBsc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0Ozxicj4NCiZndDsgY2M8YnI+DQomZ3Q7IFN1YmplY3Q8 YnI+DQomZ3Q7IFttcGxzXSBNb2RlIG5lZ290aWF0aW9uIGZvciBQU0M8YnI+DQomZ3Q7IDxicj4N CiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEFzIHBlciBsYXN0IEZyaWRheSdzIHByZXNlbnRhdGlvbiBpbiBCZXJsaW4gPGJyPg0KJmd0 OyAoPC9mb250PjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODcvc2xp ZGVzL3NsaWRlcy04Ny1tcGxzLTE1LnBwdCI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0i Q291cmllciBOZXciPjx1Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODcvc2xpZGVz L3NsaWRlcy04Ny1tcGxzLTE1LnBwdDwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PGJyPg0KJmd0OyAmbHQ7PC9mb250PjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0 Zi5vcmcvcHJvY2VlZGluZ3MvODcvc2xpZGVzL3NsaWRlcy04Ny1tcGxzLTE1LnBwdCI+PGZvbnQg c2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1Pmh0dHA6Ly93d3cuaWV0Zi5v cmcvcHJvY2VlZGluZ3MvODcvc2xpZGVzL3NsaWRlcy04Ny1tcGxzLTE1LnBwdDwvdT48L2ZvbnQ+ PC9hPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0Ow0KKSwgPGJyPg0KJmd0OyB3 ZSB3aWxsIGJlIGFkZGluZyAmcXVvdDtJVFUgTW9kZSZxdW90OyB0byBQU0MgdG8gYWxsb3cgZm9y IGJlaGF2aW9ycw0KdGhhdCA8YnI+DQomZ3Q7IHNhdGlzZnkgYm90aCBJRVRGIGFuZCBJVFUgcmVx dWlyZW1lbnRzLiAmbmJzcDtUaGlzIG1vZGUgd2lsbCBiZSA8YnI+DQomZ3Q7IGJhY2t3YXJkLWNv bXBhdGlibGUgYW5kIG5lZ290aWF0ZWQgdXNpbmcgUFNDIFRMVnMuPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IFRoZSBkcmFmdHMgaW4gdGhhdCBwcHQgZGVmaW5lIGZpdmUgY2FwYWJpbGl0aWVzIHdoaWNo IHNlcGFyYXRlIElUVQ0KPGJyPg0KJmd0OyBtb2RlIGZyb20gSUVURiBtb2RlLiAmbmJzcDtJRVRG IG1vZGUgaXMgZGVmaW5lZCBhcyB0aGUgYWJzZW5jZSBvZg0KdGhlc2UgPGJyPg0KJmd0OyBmaXZl IGNhcGFiaWxpdGllcywgYW5kIElUVSBtb2RlIGlzIGRlZmluZWQgYXMgdGhlIHVzZSBvZiBhbGwg Zml2ZQ0Kb2YgPGJyPg0KJmd0OyB0aGVzZSBjYXBhYmlsaXRpZXMuICZuYnNwO0l0IG1heSBoZWxw IHRvIHRoaW5rIG9mIElFVEYgbW9kZSBhcyAwMDAwMA0KYW5kIDxicj4NCiZndDsgSVRVIG1vZGUg YXMgMTExMTEuICZuYnNwO1RoZSBtZWNoYW5pc20gdG8gZGVmaW5lIGFuZCBuZWdvdGlhdGUgdGhl c2UNCm1vZGVzIDxicj4NCiZndDsgd2lsbCBoYXZlIHJvb20gZm9yIGV4cGFuc2lvbiBwYXN0IGZp dmUgYml0cywgc28gaWYgd2UgZXZlciBkZWNpZGUNCndlIDxicj4NCiZndDsgbmVlZCBtb3JlIGNh cGFiaWxpdGllcyBuZWdvdGlhdGlvbiBpbiBQU0MgKHNoYXJlZCBtZXNoPyAmbmJzcDttOm4/DQom bmJzcDtvdGhlciA8YnI+DQomZ3Q7IGZhbmN5IHN0dWZmPykgd2UgY2FuLjxicj4NCiZndDsgPGJy Pg0KJmd0OyBBcyBvZiByaWdodCBub3cgd2UgYXJlIG9ubHkgZGlzY3Vzc2luZyB0d28gbW9kZXMs IGJ1dCBpdCBpcyBwb3NzaWJsZQ0KPGJyPg0KJmd0OyB0byBkZWZpbmUgYSBtb2RlIHdoaWNoIGlz IHNvbWUgY29tYmluYXRpb24gb2YgdGhlc2UgZml2ZSB0aGluZ3Mgb3RoZXINCjxicj4NCiZndDsg dGhhbjxicj4NCiZndDsgMDAwMDAgb3IgMTExMTEuICZuYnNwO1NvIGEgbW9kZSBpcyByZWFsbHkg dGhlIHNldCBvZiBuZWdvdGlhdGVkIDxicj4NCiZndDsgY2FwYWJpbGl0aWVzIGJldHdlZW4gdHdv IGRldmljZXMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZXJlIGFyZSB0d28gd2F5cyB3ZSBjYW4g bmVnb3RpYXRlIHRoZSB1c2Ugb2Ygb25lIG1vcmUgb3IgdGhlIG90aGVyOjxicj4NCiZndDsgPGJy Pg0KJmd0OyAxKSBFYWNoIG5vZGUgYW5ub3VuY2VzIHRoZSBtb2RlIHRoYXQgaXQgd2FudHMsIGFu ZCBpZiB0aGUgb3RoZXIgc2lkZQ0KPGJyPg0KJmd0OyBkb2Vzbid0IHdhbnQgZXhhY3RseSB0aGUg c2FtZSBtb2RlIHRoZW4gUFNDIHdpbGwgbm90IGZ1bmN0aW9uLiAmbmJzcDtUaGF0DQo8YnI+DQom Z3Q7IGlzLCBib3RoIG5vZGVzIHNheSAmcXVvdDtteSBtb2RlIGlzIDBieHh4eHgmcXVvdDsgKGZv ciBub3csIGVpdGhlcg0KMDAwMDAgb3IgPGJyPg0KJmd0OyAxMTExMSkgYW5kIGlmIGJvdGggbm9k ZXMgZG9uJ3Qgc2F5IHRoZSBzYW1lIHRoaW5nIHRoZW4gdGhleSBjb21wbGFpbg0KPGJyPg0KJmd0 OyB0byB0aGUgb3BlcmF0b3IgYW5kIHJlZnVzZSB0byBmdW5jdGlvbi48YnI+DQomZ3Q7IDxicj4N CiZndDsgQWR2YW50YWdlOiBlYXN5LCBhbmQgaWYgYm90aCBlbmRzIGFyZSBpbiBhIHNpbmdsZSBh ZG1pbmlzdHJhdGl2ZSA8YnI+DQomZ3Q7IGRvbWFpbiBJIGV4cGVjdCB0aGUgb3BlcmF0b3IgdG8g YmUgYWJsZSB0byBjb25maWd1cmUgYm90aCBlbmRzIHRvDQptYXRjaC48YnI+DQomZ3Q7IDxicj4N CiZndDsgRGlzYWR2YW50YWdlOiB0cmlja3kgaWYgd2UgZXZlciBzdGFydCB0YWxraW5nIGFib3V0 IG1vZGVzIG90aGVyIHRoYW48YnI+DQomZ3Q7IDAwMDAwIG9yIDExMTExLiAmbmJzcDtJIGRvbid0 IHdhbnQgYSBub2RlIHRvIHNheSAmcXVvdDtJIHN1cHBvcnQgbW9kZQ0KMDAwMDAsIDxicj4NCiZn dDsgbW9kZSAwMDAwMSwgbW9kZSAwMDAxMCwgbW9kZSAwMDAxMSwgLi4uLiBtb2RlIDExMTExJnF1 b3Q7IGJlY2F1c2UNCmlmIHdlIGFkZCA8YnI+DQomZ3Q7IGEgZmV3IG1vcmUgY2FwYWJpbGl0aWVz IHdlIGNvdWxkIGVuZCB1cCBhbm5vdW5jaW5nIHRoZSBzdXBwb3J0IG9mDQo8YnI+DQomZ3Q7IGh1 bmRyZWRzIG9yIHRob3VzYW5kcyBvZiBtb2Rlcy4gJm5ic3A7RG9lcyBub3QgYWxsb3cgUFNDIHRv IGNvbWUgdXANCnVubGVzcyA8YnI+DQomZ3Q7IHRoZSBtb2RlcyBtYXRjaCBvbiBib3RoIHNpZGVz LCBldmVuIGlmIHRoZXJlIGlzIHNvbWUgY29tbW9uIHN1YnNldA0KPGJyPg0KJmd0OyB0aGV5IGNv dWxkIGJvdGggYWdyZWUgb24uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgb3I8YnI+ DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAyKSBFYWNoIG5vZGUgYW5ub3VuY2VzIHRoZSBz ZXQgb2YgY2FwYWJpbGl0aWVzIHRoYXQgaXQgY2FuIHN1cHBvcnQNCjxicj4NCiZndDsgYWxvbmcg d2l0aCB0aGUgb25lcyB0aGF0IGl0IHJlcXVpcmVzLCBhbmQgaWYgdGhlIHR3byBub2RlcyBjYW4g ZmluZA0KYSA8YnI+DQomZ3Q7IGNvbW1vbiBzdWJzZXQgb2YgZmVhdHVyZXMgdGhlbiB0aGV5IHdp bGwgY29udmVyZ2Ugb24gdGhvc2UgZmVhdHVyZXMNCmluIFBTQy48YnI+DQomZ3Q7IDxicj4NCiZn dDsgQWR2YW50YWdlOiBmbGV4aWJsZS4gJm5ic3A7SWYgdHdvIGVuZHBvaW50cyBjYW4gZmluZCBh IGNvbW1vbiBmZWF0dXJlDQo8YnI+DQomZ3Q7IHN1YnNldCAoc2VlIGV4YW1wbGUgYmVsb3cpIHRo ZW4gdGhleSB3aWxsIGNvbWUgdXAuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IERpc2FkdmFudGFnZTog bW9yZSBjb21wbGV4IGNvZGUsIGVhc2llciB0byBnZXQgd3JvbmcgYW5kIGNvbnZlcmdlDQpvbiBh IDxicj4NCiZndDsgdW5kZXNpcmFibGUgc3Vic2V0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IEV4YW1wbGVzIG9mIGVhY2ggbmVnb3RpYXRpb24gbWV0aG9kIGFyZSBiZWxvdywgYm90 aCBmb3IgY2xhcml0eSBhbmQNCnRvIDxicj4NCiZndDsgZGVtb25zdHJhdGUgdGhhdCBtZXRob2Qg IzIgd29ya3MuICZuYnNwO015IHF1ZXN0aW9uIGZvciB0aGUgV0cgaXMsDQp3aGljaCA8YnI+DQom Z3Q7IG9uZSB3b3VsZCBwZW9wbGUgcHJlZmVyLCBhbmQgd2h5Pzxicj4NCiZndDsgPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsg ZXJpYzxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEV4YW1wbGVzPGJy Pg0KJmd0OyA9PT09PT09PTxicj4NCiZndDsgQWxsIGV4YW1wbGVzIGFyZSBiZXR3ZWVuIHR3byBu b2RlcywgQSBhbmQgWi4gJm5ic3A7VGhlc2UgZXhhbXBsZXMNCmZvY3VzIG9uIDxicj4NCiZndDsg dGhlIGFjdHVhbCBuZWdvdGlhdGlvbiwgbm90IG9uIHRoZSBuZWNlc3NhcnkgVExWIGJpdHMgdG8g ZW5hYmxlIHRoZQ0KPGJyPg0KJmd0OyBuZWdvdGlhdGlvbi48YnI+DQomZ3Q7IDxicj4NCiZndDsg RXhhbXBsZSBvZiBtZXRob2QgMTxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZn dDsgTm9kZSBBIHNlbmRzIGEgc2luZ2xlIFRMViB0byBOb2RlIFogY29udGFpbmcgdGhlIG1vZGUg Yml0bWFwLiAmbmJzcDtOb2RlDQpaIDxicj4NCiZndDsgc2VuZHMgdGhlIHNhbWUgdG8gQS4gJm5i c3A7Q2FsbCB0aGVtIEEuTW9kZSBhbmQgWi5Nb2RlLiAmbmJzcDtJZiB0aGV5DQpkbyBub3QgPGJy Pg0KJmd0OyBtYXRjaCB0aGVuIHNvbWUgZGVmYXVsdCBiZWhhdmlvciBoYXBwZW5zIC0gZWl0aGVy IFBTQyBkb2Vzbid0IGNvbWUNCnVwIDxicj4NCiZndDsgb3IgdGhleSBkZWZhdWx0IHRvIG9uZSBw cmVkZXRlcm1pbmVkIG1vZGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEEubW9kZSA9IFouIG1vZGUg PSAwMDAwMDxicj4NCiZndDsgQS0mZ3Q7WjogJnF1b3Q7SSBhbSBjb25maWd1cmVkIGZvciBtb2Rl IDAwMDAwJnF1b3Q7PGJyPg0KJmd0OyBaLSZndDtBOiAmcXVvdDtJIGFtIGNvbmZpZ3VyZWQgZm9y IG1vZGUgMDAwMDAmcXVvdDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhpcyByZXN1bHRzIGluIFBT QyBjb21pbmcgdXAgaW4gSUVURiBtb2RlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBBLm1vZGUgPSBa Lm1vZGUgPSAxMTExMTxicj4NCiZndDsgQS0mZ3Q7WjogJnF1b3Q7SSBhbSBjb25maWd1cmVkIGZv ciBtb2RlIDExMTExJnF1b3Q7PGJyPg0KJmd0OyBaLSZndDtBOiAmcXVvdDtJIGFtIGNvbmZpZ3Vy ZWQgZm9yIG1vZGUgMTExMTEmcXVvdDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhpcyByZXN1bHRz IGluIFBTQyBjb21pbmcgdXAgaW4gSVRVIG1vZGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEEubW9k ZSAhPSBaLm1vZGUgKHNheSwgMDAwMDEgYW5kIDAwMDEwKTxicj4NCiZndDsgQS0mZ3Q7WjogJnF1 b3Q7SSBhbSBjb25maWd1cmVkIGZvciBtb2RlIDAwMDAxJnF1b3Q7PGJyPg0KJmd0OyBaLSZndDtB OiAmcXVvdDtJIGFtIGNvbmZpZ3VyZWQgZm9yIG1vZGUgMDAwMTAmcXVvdDs8YnI+DQomZ3Q7IDxi cj4NCiZndDsgUFNDIGRvZXMgbm90IGNvbWUgdXAuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgPGJyPg0KJmd0OyBFeGFtcGxlIG9mIG1ldGhvZCAyPGJyPg0KJmd0OyAtLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KJmd0OyBCb3RoIE5vZGUgQSBhbmQgTm9kZSBaIGFubm91bmNlIHR3byB0 aGluZ3MgLSBDYXBhYmlsaXRpZXMgYW5kIE1hc2suPGJyPg0KJmd0OyBDYXBhYmlsaXRpZXMgaXMg YSBiaXRtYXAgb2YgdGhlIGNhcGFiaWxpdGllcyB0aGF0IGFyZSBzdXBwb3J0ZWQuPGJyPg0KJmd0 OyBNYXNrIGlzIGEgbWFzayBvZiBkb24ndC1jYXJlIGJpdHMgYWdhaW5zdCB0aGUgQ2FwYWJpbGl0 aWVzIHN0cmluZy4NCiZuYnNwO0EgPGJyPg0KJmd0OyAwIGluIE1hc2sgbWVhbnMgJnF1b3Q7SSBk b24ndCBjYXJlIGlmIHdlIGRvIHRoaXMgY2FwYWJpbGl0eSBvciBub3QmcXVvdDssDQphbmQgYSA8 YnI+DQomZ3Q7IDEgbWVhbnMgJnF1b3Q7d2UgbXVzdCAob3IgbXVzdCBub3QpIGFncmVlIG9uIHRo aXMgY2FwYWJpbGl0eSBpbiBvcmRlcg0KdG8gPGJyPg0KJmd0OyBjb21lIHVwJnF1b3Q7Ljxicj4N CiZndDsgPGJyPg0KJmd0OyBBLmNhcGFiaWxpdGllcyA9IDAwMDAwPGJyPg0KJmd0OyBBLm1hc2sg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ID0gMDAwMDA8YnI+DQomZ3Q7IDxicj4NCiZndDsg VGhpcyBzYXlzICZxdW90O0kgYW0gY2FwYWJsZSBvZiBzdXBwb3J0aW5nIGFsbCBjYXBhYmlsaXRp ZXMgYW5kIEkNCmRvbid0IDxicj4NCiZndDsgY2FyZSBpZiB3ZSBkbyBhbnkgb2YgdGhlbSBvciBu b3QmcXVvdDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgQS5jYXBhYmlsaXRpZXMgPSAwMDAwMDxicj4N CiZndDsgQS5tYXNrICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA9IDExMTExPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IFRoaXMgc2F5cyAmcXVvdDtXZSBtdXN0IG5vdCB1c2UgYW55IG9mIHRoZSBv cHRpb25hbCBjYXBhYmlsaXRpZXMmcXVvdDsNCi0gPGJyPg0KJmd0OyBDYXBhYmlsaXRpZXMgYml0 cyBhcmUgYWxsIHplcm8sIGFuZCBNYXNrIGJpdHMgc2F5ICZxdW90O3dlIG11c3QgYWdyZWUNCnRo YXQgPGJyPg0KJmd0OyB0aGUgY29ycmVzcG9uZGluZyBjYXBhYmlsaXR5IGlzIHplcm8mcXVvdDsu ICZuYnNwO1RoaXMgaXMgJ0lFVEYgbW9kZScuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEEuY2FwYWJp bGl0aWVzID0gMTExMTE8YnI+DQomZ3Q7IEEubWFzayAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgPSAxMTExMTxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGlzIGlzICdJVFUgTW9kZSc8YnI+DQom Z3Q7IDxicj4NCiZndDsgV2hlcmUgaXQgZ2V0cyBjb21wbGljYXRlZCAob3IgYXdlc29tZSwgZGVw ZW5kaW5nIG9uIHlvdXIgcGVyc3BlY3RpdmUpDQo8YnI+DQomZ3Q7IGlzIHdoZW4geW91IGhhdmUg dmFyaW91cyBzdWJzZXRzLiAmbmJzcDtDb25zaWRlcjo8YnI+DQomZ3Q7IDxicj4NCiZndDsgQS5D YXBhYmlsaXRpZXMgPT0gMDExMDA8YnI+DQomZ3Q7IEEuTWFzayA9PSAwMTEwMDxicj4NCiZndDsg PGJyPg0KJmd0OyBaLkNhcGFiaWxpdGllcyA9PSAwMTExMDxicj4NCiZndDsgWi5NYXNrID09IDAx MTEwPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgTmVnb3RpYXRpb24gcHJvY2VkdXJl cy48YnI+DQomZ3Q7IEVhY2ggc2lkZSBkb2VzOjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IHJlcyA9IChBLkNhcGFiaWxpdGVzICZhbXA7IFouTWFzaykgXiAoWi5DYXBhYmlsaXRpZXMg JmFtcDsgQS5NYXNrKQ0KcmVzID0gPGJyPg0KJmd0OyAoMDExMDAgJmFtcDsgMDExMTApIF4gKDAx MTEwICZhbXA7IDAxMTAwKSByZXMgPSAoMDExMDApIF4gKDAxMTAwKQ0KcmVzID0gMDAwMDA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgaWYgcmVzID09IDAgdGhlbiBpdCBpcyBwb3NzaWJsZSBmb3IgYm90 aCBzaWRlcyB0byBmaW5kIGEgY29tbW9uIHN1YnNldA0KPGJyPg0KJmd0OyB0aGF0IHRoZXkgc3Vw cG9ydC48YnI+DQomZ3Q7IFRoaXMgY29tbW9uIHN1YnNldCBpcyBjYWxsZWQgdGhlICduZWdvdGlh dGVkIHNldCcsIGFuZCBpcyBkZXRlcm1pbmVkDQpieTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgbmVn b3RpYXRlZF9zZXQgPSBBLkNhcGFiaWxpdGllcyB8IEIuQ2FwYWJpbGl0aWVzIG5lZ290aWF0ZWRf c2V0ID0NCjxicj4NCiZndDsgMDExMDAgfCAwMTExMCBuZWdvdGlhdGVkX3NldCA9IDAxMTAwPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IGlmIHJlcyAhPSAwIHRoZW4gaXQgaXMgaW1wb3NzaWJsZSB0byBm aW5kIGEgc3Vic2V0IHRoYXQgdGhlIHR3byBlbmRzDQo8YnI+DQomZ3Q7IGNhbiBhZ3JlZSBvbiwg YW5kIFBTQyB3aWxsIG5ldmVyIGNvbWUgdXAuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uY2UgZWFj aCBzaWRlIGNvbXB1dGVzIHRoZSBuZWdvdGlhdGVkIHNldCwgdGhleSBzaWduYWwgaXQgYW5kIFBT Qw0KPGJyPg0KJmd0OyBzdGFydHMgdG8gd29yay48YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBtcGxzIG1haWxpbmcgbGlz dDxicj4NCiZndDsgPC9mb250PjxhIGhyZWY9bWFpbHRvOm1wbHNAaWV0Zi5vcmc+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1Pm1wbHNAaWV0Zi5vcmc8L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiZndDsgPC9mb250 PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPjxmb250 IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxicj4NCiZndDsgJmx0OzwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBm YWNlPSJDb3VyaWVyIE5ldyI+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7 PGJyPg0KJmd0OyA8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PC9mb250Pjxmb250IHNpemU9MiBj b2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9 bWFpbHRvOm1wbHNAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmll ciBOZXciPjx1Pm1wbHNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgY29sb3I9 Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM+PGZvbnQgc2l6ZT0yIGNv bG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbXBsczwvdT48L2ZvbnQ+PC9hPg0KPGJyPg0K --=_alternative 004E595D85257BCF_=-- From loa@pi.nu Thu Aug 22 07:29:41 2013 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 D9B6711E814C; Thu, 22 Aug 2013 07:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJmcbwopa9LC; Thu, 22 Aug 2013 07:29:37 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id C6C5D11E80F0; Thu, 22 Aug 2013 07:29:36 -0700 (PDT) Received: from [192.168.5.58] (81-229-83-119-no65.business.telia.com [81.229.83.119]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 8D7DA18000AA; Thu, 22 Aug 2013 16:29:35 +0200 (CEST) Message-ID: <5216204F.4070707@pi.nu> Date: Thu, 22 Aug 2013 16:29:35 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Malcolm.BETTS@zte.com.cn References: <20ECF67871905846A80F77F8F4A27572102C229B@xmb-rcd-x09.cisco.com> <20ECF67871905846A80F77F8F4A27572102EB9C5@xmb-rcd-x09.cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF642C376@eusaamb107.ericsson.se> <48E1A67CB9CA044EADFEAB87D814BFF642DEFC@eusaamb107.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject: Re: [mpls] Mode negotiation for PSC 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, 22 Aug 2013 14:29:42 -0000 Folks, (chair hat off). This is possible well covered ground, but an innocent question from someone are doing the duck-trick. Would it make sense for a implementation to only support a of the functions? I think I've heard both yes and not to that question. /Loa On 2013-08-22 16:15, Malcolm.BETTS@zte.com.cn wrote: > Hi Eric (Gray) > > I agree, if we conclude that we do not want to support negotiation in > the PSC protocol we should call this "option confirmation" as Adrian > suggested. The term "mode" is already used in RFC6378 e.g. revertive > mode, non-revertive mode etc. > > Regards, > > Malcolm > > > > *Eric Gray * > > 22/08/2013 09:35 AM > > > To > "Malcolm.BETTS@zte.com.cn" > cc > "Eric Osborne (eosborne)" , "mpls@ietf.org" > , "mpls-bounces@ietf.org" > Subject > RE: [mpls] Mode negotiation for PSC > > > > > > > > > Malcolm, > > Agreed. See continuing discussion thread on why we might not > want to > call this "negotiation." There is no negotiation if an exact match is > required… > > -- > Eric > > *From:* Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] * > Sent:* Wednesday, August 21, 2013 11:44 AM* > To:* Eric Gray* > Cc:* Eric Osborne (eosborne); Malcolm.BETTS@zte.com.cn; mpls@ietf.org; > mpls-bounces@ietf.org* > Subject:* RE: [mpls] Mode negotiation for PSC* > Importance:* High > > Hi Eric (Gray), > > I agree that we should not negotiate PSC modes "on the fly", since > selecting different options will result in different behaviour in the > network any negotiation should involve a human i..e reporting the miss > match is all that we need to do. > > As I pointed out below "negotiation" of the PSC options should take > place before the LSP is set-up, PSC should only check that the options > selected match (and report a miss match). > > Regards, > > Malcolm > > *Eric Gray <**_eric.gray@ericsson.com_* *>* > > 20/08/2013 02:41 PM > > > To > "Eric Osborne (eosborne)" <_eosborne@cisco.com_ > >, "_Malcolm.BETTS@zte.com.cn_ > " <_Malcolm.BETTS@zte.com.cn_ > > > cc > "_mpls@ietf.org_ " <_mpls@ietf.org_ > >, "_mpls-bounces@ietf.org_ > " <_mpls-bounces@ietf.org_ > > > Subject > RE: [mpls] Mode negotiation for PSC > > > > > > > > > > > Eric (Osborne), > > While I agree that we don't want to try to predict what > will never ever > happen, there is more than a little bit of an issue with designing for > all possible > cases. > > Before we can really get away with any approach that > could conceivably > include N^2 combinations of options, we need to describe what each of these > possibilities means, and how devices with arbitrary disagreement for the > options > resolve the differences. > > And - while we're trying to cover the possible cases for > known modes, > should we also try to allow for coverage of future (thus unknown) modes? > > Is this worth the trouble? Are there use cases to > support this, or are we > embarking on an academic exercise? > > What we really need now is a simple binary indicator. > If we feel that any > negotiation is required, then it should be trivial. If there is > disagreement, then > everbody falls-back to a default mode. > > But I am not convinced that any form of negotiation is > required. > > In this discussion, I am reminded that at least part of > the discussion that > got us on the road of having two modes had to do with limited > negotiation in the > case where PSC parameters did not match. I believe that the decision > was that > reporting the inconsistency to the operator was sufficient from the > perspective > of any of us in the IETF, and that this was not sufficient to folks used > to dealing > with APS. > > So, are we switching from what was essentially > non-negotiation of PSC > parameters to negotiation of PSC modes? Seems counter-intuitive to me... > > -- > Eric (Gray) > > -----Original Message----- > From: _mpls-bounces@ietf.org_ > [_mailto:mpls-bounces@ietf.org_] On Behalf > Of Eric Osborne (eosborne) > Sent: Friday, August 16, 2013 4:49 PM > To: _Malcolm.BETTS@zte.com.cn_ > Cc: _mpls@ietf.org_ ; _mpls-bounces@ietf.org_ > > Subject: Re: [mpls] Mode negotiation for PSC > > Hi Malcolm- > > Thanks for this. A few comments inline. > > > > -----Original Message----- > > From: _Malcolm.BETTS@zte.com.cn_ > [_mailto:Malcolm.BETTS@zte.com.cn_] > > Sent: Thursday, August 15, 2013 1:01 PM > > To: Eric Osborne (eosborne) > > Cc: _mpls@ietf.org_ ; _mpls-bounces@ietf.org_ > > > Subject: Re: [mpls] Mode negotiation for PSC > > > > Hi Eric, > > > > I have only seen one message on this thread so I will venture an > > opinion. > > > > My preference is for option 1 - no negotiation. > > > > My reasons are: > > > > Keep it simple! > > > > The major reason that network operator's have given for requesting > > these enhanced capabilities is to maintain compatibility with existing > > linear protection schemes. Within the network of a single operator my > > assumption is that they want, above all else, consistent operation. > > Therefore, I suspect that we will see two "camps" with either all > > options active or no options active. > > > > That's what it looks like now. But I'm not terribly good at predicting > what people will never, ever do. I could see an implementation which > wants to support, say, MS-W but none of the other options. > > > Interconnection of "transport" connections between network operators > > is normally only allowed within the frame work of an agreement between > > the operators. As part of that agreement they would need to define the > > linear protection options that would be used. The operational > > differences would be confined to the links that provide the > > interconnection between networks of the different operators. The > > appropriate protection options would be configured (as defined by the > > agreement) when the protected connection is set-up. > > PSC has bits to indicate the protection type and revertive mode, and the > logic we're going to add n draft-osborne explains what happens if two > sides disagree. Is this not a form of negotiatoin? > > > > > Negotiation would allow the possibility of a variety of protection > > options being active in the network which would result in inconsistent > > behaviour which would create operational complexity. > > It is possible for one side to declare intransigence by setting the mask > bits to all 1s. This indicates that the Capabilities advertised by that > node must match exactly in order for things to work. The two modes I > think we'll see first are: > > Cap=00000, Mask=11111 > Cap=11111, Mask=11111 > > and these two will never agree on a mode since the mask of all 1s gives > neither side any room to move. > > I'm not against the simpler mode, I just want to make sure that you > understand that it is possible to achieve that using the proposed > negotiation method. > > > > > eric > > > > > > Regards, > > > > Malcolm > > > > > > > > > > > > "Eric Osborne (eosborne)" <_eosborne@cisco.com_ > > Sent by: > > _mpls-bounces@ietf.org_ > > > > 08/08/2013 08:34 AM To > > "_mpls@ietf.org_ " <_mpls@ietf.org_ > > > > cc > > Subject > > [mpls] Mode negotiation for PSC > > > > > > > > > > > > > > As per last Friday's presentation in Berlin > > (_http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt_ > > <_http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt_> ), > > we will be adding "ITU Mode" to PSC to allow for behaviors that > > satisfy both IETF and ITU requirements. This mode will be > > backward-compatible and negotiated using PSC TLVs. > > > > The drafts in that ppt define five capabilities which separate ITU > > mode from IETF mode. IETF mode is defined as the absence of these > > five capabilities, and ITU mode is defined as the use of all five of > > these capabilities. It may help to think of IETF mode as 00000 and > > ITU mode as 11111. The mechanism to define and negotiate these modes > > will have room for expansion past five bits, so if we ever decide we > > need more capabilities negotiation in PSC (shared mesh? m:n? other > > fancy stuff?) we can. > > > > As of right now we are only discussing two modes, but it is possible > > to define a mode which is some combination of these five things other > > than > > 00000 or 11111. So a mode is really the set of negotiated > > capabilities between two devices. > > > > There are two ways we can negotiate the use of one more or the other: > > > > 1) Each node announces the mode that it wants, and if the other side > > doesn't want exactly the same mode then PSC will not function. That > > is, both nodes say "my mode is 0bxxxxx" (for now, either 00000 or > > 11111) and if both nodes don't say the same thing then they complain > > to the operator and refuse to function. > > > > Advantage: easy, and if both ends are in a single administrative > > domain I expect the operator to be able to configure both ends to match. > > > > Disadvantage: tricky if we ever start talking about modes other than > > 00000 or 11111. I don't want a node to say "I support mode 00000, > > mode 00001, mode 00010, mode 00011, .... mode 11111" because if we add > > a few more capabilities we could end up announcing the support of > > hundreds or thousands of modes. Does not allow PSC to come up unless > > the modes match on both sides, even if there is some common subset > > they could both agree on. > > > > > > or > > > > > > 2) Each node announces the set of capabilities that it can support > > along with the ones that it requires, and if the two nodes can find a > > common subset of features then they will converge on those features > in PSC. > > > > Advantage: flexible. If two endpoints can find a common feature > > subset (see example below) then they will come up. > > > > Disadvantage: more complex code, easier to get wrong and converge on a > > undesirable subset. > > > > > > Examples of each negotiation method are below, both for clarity and to > > demonstrate that method #2 works. My question for the WG is, which > > one would people prefer, and why? > > > > > > > > > > > > > > eric > > > > > > --------------------------------- > > > > > > Examples > > ======== > > All examples are between two nodes, A and Z. These examples focus on > > the actual negotiation, not on the necessary TLV bits to enable the > > negotiation. > > > > Example of method 1 > > ------------------- > > Node A sends a single TLV to Node Z containg the mode bitmap. Node Z > > sends the same to A. Call them A.Mode and Z.Mode. If they do not > > match then some default behavior happens - either PSC doesn't come up > > or they default to one predetermined mode. > > > > A.mode = Z. mode = 00000 > > A->Z: "I am configured for mode 00000" > > Z->A: "I am configured for mode 00000" > > > > This results in PSC coming up in IETF mode. > > > > A.mode = Z.mode = 11111 > > A->Z: "I am configured for mode 11111" > > Z->A: "I am configured for mode 11111" > > > > This results in PSC coming up in ITU mode. > > > > A.mode != Z.mode (say, 00001 and 00010) > > A->Z: "I am configured for mode 00001" > > Z->A: "I am configured for mode 00010" > > > > PSC does not come up. > > > > > > > > Example of method 2 > > ------------------- > > Both Node A and Node Z announce two things - Capabilities and Mask. > > Capabilities is a bitmap of the capabilities that are supported. > > Mask is a mask of don't-care bits against the Capabilities string. A > > 0 in Mask means "I don't care if we do this capability or not", and a > > 1 means "we must (or must not) agree on this capability in order to > > come up". > > > > A.capabilities = 00000 > > A.mask = 00000 > > > > This says "I am capable of supporting all capabilities and I don't > > care if we do any of them or not" > > > > A.capabilities = 00000 > > A.mask = 11111 > > > > This says "We must not use any of the optional capabilities" - > > Capabilities bits are all zero, and Mask bits say "we must agree that > > the corresponding capability is zero". This is 'IETF mode'. > > > > A.capabilities = 11111 > > A.mask = 11111 > > > > This is 'ITU Mode' > > > > Where it gets complicated (or awesome, depending on your perspective) > > is when you have various subsets. Consider: > > > > A.Capabilities == 01100 > > A.Mask == 01100 > > > > Z.Capabilities == 01110 > > Z.Mask == 01110 > > > > > > Negotiation procedures. > > Each side does: > > > > > > res = (A.Capabilites & Z.Mask) ^ (Z.Capabilities & A.Mask) res = > > (01100 & 01110) ^ (01110 & 01100) res = (01100) ^ (01100) res = 00000 > > > > if res == 0 then it is possible for both sides to find a common subset > > that they support. > > This common subset is called the 'negotiated set', and is determined by: > > > > negotiated_set = A.Capabilities | B.Capabilities negotiated_set = > > 01100 | 01110 negotiated_set = 01100 > > > > if res != 0 then it is impossible to find a subset that the two ends > > can agree on, and PSC will never come up. > > > > Once each side computes the negotiated set, they signal it and PSC > > starts to work. > > _______________________________________________ > > mpls mailing list > > _mpls@ietf.org_ > > _https://www.ietf.org/mailman/listinfo/mpls_ > > <_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 > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From gregory.mirsky@ericsson.com Thu Aug 22 08:40:01 2013 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 B183A11E81ED; Thu, 22 Aug 2013 08:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6] 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 6nUAQmzoKdvI; Thu, 22 Aug 2013 08:39:42 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 82D8411E81EC; Thu, 22 Aug 2013 08:39:42 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-9b-521630bda969 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id D2.7C.03458.DB036125; Thu, 22 Aug 2013 17:39:41 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Thu, 22 Aug 2013 11:39:31 -0400 From: Gregory Mirsky To: "adrian@olddog.co.uk" , "Malcolm.BETTS@zte.com.cn" , Eric Gray Thread-Topic: [mpls] Mode negotiation for PSC Thread-Index: Ac6ULYh0Wz1ulMCERKa7JFuZBxS/GAFzPU+AADpDBQAAu+T3MAA06ZaAACtuDoAAAeOVQA== Date: Thu, 22 Aug 2013 15:39:31 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B6E0724@eusaamb103.ericsson.se> References: <20ECF67871905846A80F77F8F4A27572102C229B@xmb-rcd-x09.cisco.com> <20ECF67871905846A80F77F8F4A27572102EB9C5@xmb-rcd-x09.cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF642C376@eusaamb107.ericsson.se> <02b001ce9f32$f644ac80$e2ce0580$@olddog.co.uk> In-Reply-To: <02b001ce9f32$f644ac80$e2ce0580$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B6E0724eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyuXSPn+4+A7Eggwm5Fj96bjBbtHc9ZbfY vf8Ku8WtpStZHVg8liz5yeSxYvNKRo81+36wBDBHcdmkpOZklqUW6dslcGWcub6NteDGPaaK V6vlGxinrmLqYuTkkBAwkdjx+DArhC0mceHeerYuRi4OIYGjjBJHrqxhhXCWM0rca3/IDFLF JmAk8WJjDztIQkSgh1HiacN6dpAEs0CYRPOHFqB2Dg5hAR2JV3vNQcIiAroSG9atY4OwwyRW XjoENodFQFViyb7zYDavgK/E9t9zwK4QEpjCLLHygDzIGE4Ba4klL8DGMAId9/3UGiaITeIS t57Mh3pAQGLJHogxEgKiEi8f/4N6RlliyZP9LBD1+RIf359lh1glKHFy5hOWCYyis5CMmoWk bBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KkaO0OLUsN93IcBMjMOaOSbA57mBc 8MnyEKM0B4uSOO8GvTOBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhtmv72C0Qd9uh48m9F lcWK4gNPD32bHtVdGSh6/JlJ2mfmbwl+k7SVTq2c7FkXaiYZk5zw8HggS8i2pmCBI/Os+P1X iLTvjD172rBbSyZ6YfdPr+homSvV96c//rQ/d38tO7cp87IDD4Qv/n51cfpBC/F/grfn8U4x l24WX/pU7VD3NN3oZRuVWIozEg21mIuKEwF3RMzshwIAAA== Cc: "mpls@ietf.org" , "mpls-bounces@ietf.org" Subject: Re: [mpls] Mode negotiation for PSC 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, 22 Aug 2013 15:40:01 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B6E0724eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adrian, et. al, or perhaps we can call it "mode advertisement if each LER only to announce,= advertise its PSC capabilities. As I understand, in Option 1 an LER would = not inform its peer of whether it thinks that PSC capabilities match. Thus = there might not be "confirmation" part in the process. Regards, Greg From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Adr= ian Farrel Sent: Thursday, August 22, 2013 5:27 AM To: Malcolm.BETTS@zte.com.cn; Eric Gray Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] Mode negotiation for PSC Maybe don't call it "negotiation" if no negotiation is to be allowed. Call in "mode confirmation" or something? Adrian From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Malcolm.BETTS@zte.com.cn Sent: 21 August 2013 16:44 To: Eric Gray Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] Mode negotiation for PSC Hi Eric (Gray), I agree that we should not negotiate PSC modes "on the fly", since selectin= g different options will result in different behaviour in the network any n= egotiation should involve a human i..e reporting the miss match is all that= we need to do. As I pointed out below "negotiation" of the PSC options should take place b= efore the LSP is set-up, PSC should only check that the options selected ma= tch (and report a miss match). Regards, Malcolm Eric Gray > 20/08/2013 02:41 PM To "Eric Osborne (eosborne)" >, = "Malcolm.BETTS@zte.com.cn" > cc "mpls@ietf.org" >= , "mpls-bounces@ietf.org" > Subject RE: [mpls] Mode negotiation for PSC Eric (Osborne), While I agree that we don't want to try to predict what wil= l never ever happen, there is more than a little bit of an issue with designing for all = possible cases. Before we can really get away with any approach that could = conceivably include N^2 combinations of options, we need to describe what each of these possibilities means, and how devices with arbitrary disagreement for the op= tions resolve the differences. And - while we're trying to cover the possible cases for kn= own modes, should we also try to allow for coverage of future (thus unknown) modes? Is this worth the trouble? Are there use cases to support = this, or are we embarking on an academic exercise? What we really need now is a simple binary indicator. If w= e feel that any negotiation is required, then it should be trivial. If there is disagreeme= nt, then everbody falls-back to a default mode. But I am not convinced that any form of negotiation is requ= ired. In this discussion, I am reminded that at least part of the= discussion that got us on the road of having two modes had to do with limited negotiation i= n the case where PSC parameters did not match. I believe that the decision was t= hat reporting the inconsistency to the operator was sufficient from the perspec= tive of any of us in the IETF, and that this was not sufficient to folks used to= dealing with APS. So, are we switching from what was essentially non-negotiat= ion of PSC parameters to negotiation of PSC modes? Seems counter-intuitive to me... -- Eric (Gray) -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Eric Osborne (eosborne) Sent: Friday, August 16, 2013 4:49 PM To: Malcolm.BETTS@zte.com.cn Cc: mpls@ietf.org; mpls-bounces@ietf.org Subject: Re: [mpls] Mode negotiation for PSC Hi Malcolm- Thanks for this. A few comments inline. > -----Original Message----- > From: Malcolm.BETTS@zte.com.cn [mailto:M= alcolm.BETTS@zte.com.cn] > Sent: Thursday, August 15, 2013 1:01 PM > To: Eric Osborne (eosborne) > Cc: mpls@ietf.org; mpls-bounces@ietf.org > Subject: Re: [mpls] Mode negotiation for PSC > > Hi Eric, > > I have only seen one message on this thread so I will venture an > opinion. > > My preference is for option 1 - no negotiation. > > My reasons are: > > Keep it simple! > > The major reason that network operator's have given for requesting > these enhanced capabilities is to maintain compatibility with existing > linear protection schemes. Within the network of a single operator my > assumption is that they want, above all else, consistent operation. > Therefore, I suspect that we will see two "camps" with either all > options active or no options active. > That's what it looks like now. But I'm not terribly good at predicting wha= t people will never, ever do. I could see an implementation which wants to= support, say, MS-W but none of the other options. > Interconnection of "transport" connections between network operators > is normally only allowed within the frame work of an agreement between > the operators. As part of that agreement they would need to define the > linear protection options that would be used. The operational > differences would be confined to the links that provide the > interconnection between networks of the different operators. The > appropriate protection options would be configured (as defined by the > agreement) when the protected connection is set-up. PSC has bits to indicate the protection type and revertive mode, and the lo= gic we're going to add n draft-osborne explains what happens if two sides d= isagree. Is this not a form of negotiatoin? > > Negotiation would allow the possibility of a variety of protection > options being active in the network which would result in inconsistent > behaviour which would create operational complexity. It is possible for one side to declare intransigence by setting the mask bi= ts to all 1s. This indicates that the Capabilities advertised by that node= must match exactly in order for things to work. The two modes I think we'= ll see first are: Cap=3D00000, Mask=3D11111 Cap=3D11111, Mask=3D11111 and these two will never agree on a mode since the mask of all 1s gives nei= ther side any room to move. I'm not against the simpler mode, I just want to make sure that you underst= and that it is possible to achieve that using the proposed negotiation meth= od. eric > > Regards, > > Malcolm > > > > > > "Eric Osborne (eosborne)" >= Sent by: > mpls-bounces@ietf.org > > 08/08/2013 08:34 AM To > "mpls@ietf.org" > > cc > Subject > [mpls] Mode negotiation for PSC > > > > > > > As per last Friday's presentation in Berlin > (http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt > ), > we will be adding "ITU Mode" to PSC to allow for behaviors that > satisfy both IETF and ITU requirements. This mode will be > backward-compatible and negotiated using PSC TLVs. > > The drafts in that ppt define five capabilities which separate ITU > mode from IETF mode. IETF mode is defined as the absence of these > five capabilities, and ITU mode is defined as the use of all five of > these capabilities. It may help to think of IETF mode as 00000 and > ITU mode as 11111. The mechanism to define and negotiate these modes > will have room for expansion past five bits, so if we ever decide we > need more capabilities negotiation in PSC (shared mesh? m:n? other > fancy stuff?) we can. > > As of right now we are only discussing two modes, but it is possible > to define a mode which is some combination of these five things other > than > 00000 or 11111. So a mode is really the set of negotiated > capabilities between two devices. > > There are two ways we can negotiate the use of one more or the other: > > 1) Each node announces the mode that it wants, and if the other side > doesn't want exactly the same mode then PSC will not function. That > is, both nodes say "my mode is 0bxxxxx" (for now, either 00000 or > 11111) and if both nodes don't say the same thing then they complain > to the operator and refuse to function. > > Advantage: easy, and if both ends are in a single administrative > domain I expect the operator to be able to configure both ends to match. > > Disadvantage: tricky if we ever start talking about modes other than > 00000 or 11111. I don't want a node to say "I support mode 00000, > mode 00001, mode 00010, mode 00011, .... mode 11111" because if we add > a few more capabilities we could end up announcing the support of > hundreds or thousands of modes. Does not allow PSC to come up unless > the modes match on both sides, even if there is some common subset > they could both agree on. > > > or > > > 2) Each node announces the set of capabilities that it can support > along with the ones that it requires, and if the two nodes can find a > common subset of features then they will converge on those features in PS= C. > > Advantage: flexible. If two endpoints can find a common feature > subset (see example below) then they will come up. > > Disadvantage: more complex code, easier to get wrong and converge on a > undesirable subset. > > > Examples of each negotiation method are below, both for clarity and to > demonstrate that method #2 works. My question for the WG is, which > one would people prefer, and why? > > > > > > > eric > > > --------------------------------- > > > Examples > =3D=3D=3D=3D=3D=3D=3D=3D > All examples are between two nodes, A and Z. These examples focus on > the actual negotiation, not on the necessary TLV bits to enable the > negotiation. > > Example of method 1 > ------------------- > Node A sends a single TLV to Node Z containg the mode bitmap. Node Z > sends the same to A. Call them A.Mode and Z.Mode. If they do not > match then some default behavior happens - either PSC doesn't come up > or they default to one predetermined mode. > > A.mode =3D Z. mode =3D 00000 > A->Z: "I am configured for mode 00000" > Z->A: "I am configured for mode 00000" > > This results in PSC coming up in IETF mode. > > A.mode =3D Z.mode =3D 11111 > A->Z: "I am configured for mode 11111" > Z->A: "I am configured for mode 11111" > > This results in PSC coming up in ITU mode. > > A.mode !=3D Z.mode (say, 00001 and 00010) > A->Z: "I am configured for mode 00001" > Z->A: "I am configured for mode 00010" > > PSC does not come up. > > > > Example of method 2 > ------------------- > Both Node A and Node Z announce two things - Capabilities and Mask. > Capabilities is a bitmap of the capabilities that are supported. > Mask is a mask of don't-care bits against the Capabilities string. A > 0 in Mask means "I don't care if we do this capability or not", and a > 1 means "we must (or must not) agree on this capability in order to > come up". > > A.capabilities =3D 00000 > A.mask =3D 00000 > > This says "I am capable of supporting all capabilities and I don't > care if we do any of them or not" > > A.capabilities =3D 00000 > A.mask =3D 11111 > > This says "We must not use any of the optional capabilities" - > Capabilities bits are all zero, and Mask bits say "we must agree that > the corresponding capability is zero". This is 'IETF mode'. > > A.capabilities =3D 11111 > A.mask =3D 11111 > > This is 'ITU Mode' > > Where it gets complicated (or awesome, depending on your perspective) > is when you have various subsets. Consider: > > A.Capabilities =3D=3D 01100 > A.Mask =3D=3D 01100 > > Z.Capabilities =3D=3D 01110 > Z.Mask =3D=3D 01110 > > > Negotiation procedures. > Each side does: > > > res =3D (A.Capabilites & Z.Mask) ^ (Z.Capabilities & A.Mask) res =3D > (01100 & 01110) ^ (01110 & 01100) res =3D (01100) ^ (01100) res =3D 00000 > > if res =3D=3D 0 then it is possible for both sides to find a common subse= t > that they support. > This common subset is called the 'negotiated set', and is determined by: > > negotiated_set =3D A.Capabilities | B.Capabilities negotiated_set =3D > 01100 | 01110 negotiated_set =3D 01100 > > if res !=3D 0 then it is impossible to find a subset that the two ends > can agree on, and PSC will never come up. > > Once each side computes the negotiated set, they signal it and PSC > starts to work. > _______________________________________________ > 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 --_000_7347100B5761DC41A166AC17F22DF1121B6E0724eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Adrian, et. al,

or perhaps we can call it= “mode advertisement if each LER only to announce, advertise its PSC = capabilities. As I understand, in Option 1 an LER would not inform its peer of whether it thinks that PSC capabilities match. Thus there migh= t not be “confirmation” part in the process.<= /p>

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Thursday, August 22, 2013 5:27 AM
To: Malcolm.BETTS@zte.com.cn; Eric Gray
Cc: mpls@ietf.org; mpls-bounces@ietf.org
Subject: Re: [mpls] Mode negotiation for PSC

 

Maybe don'= t call it "negotiation" if no negotiation is to be allowed.<= /o:p>

 = ;

Call in &q= uot;mode confirmation" or something?

 = ;

Adrian

 = ;

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Malcolm.BET= TS@zte.com.cn
Sent: 21 August 2013 16:44
To: Eric Gray
Cc: mpls@ietf.org; mpls-bounces@ietf.org
Subject: Re: [mpls] Mode negotiation for PSC

 

Hi Eric (Gray),

I agree that we should not negotiate PSC m= odes "on the fly", since selecting different options will result = in different behaviour in the network any negotiation should involve a human i..e reporting the miss match is all that we need to do.

As I pointed out below "negotiation&q= uot; of the PSC options should take place before the LSP is set-up, PSC sho= uld only check that the options selected match (and report a miss match).

Regards,

Malcolm


Eric Gray <eric.gray@ericsson.com>

20/08/2013 02:41 PM

To

"Eric Osborne (eosborne)" <eosborne@cisco.com>, "Malcolm.BETTS@zte.com.cn" &= lt;Malcolm.BETTS@zte.com.cn= >

cc

"mpl= s@ietf.org" <mpls@ietf.org= >, "mpls-bounces@ietf.org<= /a>" <mpls-bounces@ietf.or= g>

Subject

RE: [mpls] Mode negotiation for PSC=

 

=


Eric (Osborne),<= /span>

                While I agree t= hat we don't want to try to predict what will never ever
happen, there is more than a little bit of an issue with designing for = all possible
cases.

                Before we can r= eally get away with any approach that could conceivably
include N^2 combinations of options, we need to describe what each of t= hese
possibilities means, and how devices with arbitrary disagreement for th= e options
resolve the differences.

                And - while we'= re trying to cover the possible cases for known modes,
should we also try to allow for coverage of future (thus unknown) modes= ?

                Is this worth t= he trouble?  Are there use cases to support this, or are we
embarking on an academic exercise?

                What we really = need now is a simple binary indicator.  If we feel that any
negotiation is required, then it should be trivial.  If there is d= isagreement, then
everbody falls-back to a default mode.

                But I am not co= nvinced that any form of negotiation is required.

                In this discuss= ion, I am reminded that at least part of the discussion that
got us on the road of having two modes had to do with limited negotiati= on in the
case where PSC parameters did not match.  I believe that the decis= ion was that
reporting the inconsistency to the operator was sufficient from the per= spective
of any of us in the IETF, and that this was not sufficient to folks use= d to dealing
with APS.

                So, are we swit= ching from what was essentially non-negotiation of PSC
parameters to negotiation of PSC modes?  Seems counter-intuitive t= o me...

--
Eric (Gray)

-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org<= /tt>] On Behalf Of Eric Osborne (eosborne)
Sent: Friday, August 16, 2013 4:49 PM
To: Malcolm.BETTS@zte.com.c= n
Cc: mpls@ietf.org; mpls-bounces@ietf.org
Subject: Re: [mpls] Mode negotiation for PSC

Hi Malcolm-

 Thanks for this.  A few comments inline.


> -----Original Message-----
> From: Malcolm.BETTS@zt= e.com.cn [mailto:Malcolm.BETTS@z= te.com.cn]
> Sent: Thursday, August 15, 2013 1:01 PM
> To: Eric Osborne (eosborne)
> Cc: mpls@ietf.org; mpls-bounces@ietf.org
> Subject: Re: [mpls] Mode negotiation for PSC
>
> Hi Eric,
>
> I have only seen one message on this thread so I will venture an <= /tt>
> opinion.
>
> My preference is for option 1 - no negotiation.
>
> My reasons are:
>
> Keep it simple!
>
> The major reason that network operator's have given for requesting=
> these enhanced capabilities is to maintain compatibility with exis= ting
> linear protection schemes. Within the network of a single operator= my
> assumption is that they want, above all else, consistent operation= .
> Therefore, I suspect that we will see two "camps" with e= ither all
> options active or no options active.
>

That's what it looks like now.  But I'm not terribly good at predi= cting what people will never, ever do.  I could see an implementation = which wants to support, say, MS-W but none of the other options.

> Interconnection of "transport" connections between netwo= rk operators
> is normally only allowed within the frame work of an agreement bet= ween
> the operators. As part of that agreement they would need to define= the
> linear protection options that would be used. The operational
> differences would be confined to the links that provide the <= br> > interconnection between networks of the different operators. The <= /tt>
> appropriate protection options would be configured (as defined by = the
> agreement) when the protected connection is set-up.

PSC has bits to indicate the protection type and revertive mode, and th= e logic we're going to add n draft-osborne explains what happens if two sid= es disagree.  Is this not a form of negotiatoin?

>
> Negotiation would allow the possibility of a variety of protection=
> options being active in the network which would result in inconsis= tent
> behaviour which would create operational complexity.

It is possible for one side to declare intransigence by setting the mas= k bits to all 1s.  This indicates that the Capabilities advertised by = that node must match exactly in order for things to work.  The two mod= es I think we'll see first are:

Cap=3D00000, Mask=3D11111
Cap=3D11111, Mask=3D11111

and these two will never agree on a mode since the mask of all 1s gives= neither side any room to move.

I'm not against the simpler mode, I just want to make sure that you und= erstand that it is possible to achieve that using the proposed negotiation = method.




eric


>
> Regards,
>
> Malcolm
>
>
>
>
>
> "Eric Osborne (eosborne)" <eosborne@cisco.com> Sent by:
> mpls-bounces@ietf.org=
>
> 08/08/2013 08:34 AM To
> "mpls@ietf.org" <= ;mpls@ietf.org>
> cc
> Subject
> [mpls] Mode negotiation for PSC
>
>
>
>
>
>
> As per last Friday's presentation in Berlin
> (http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt
> <http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt>= ; ),
> we will be adding "ITU Mode" to PSC to allow for behavio= rs that
> satisfy both IETF and ITU requirements.  This mode will be
> backward-compatible and negotiated using PSC TLVs.
>
> The drafts in that ppt define five capabilities which separate ITU=
> mode from IETF mode.  IETF mode is defined as the absence of = these
> five capabilities, and ITU mode is defined as the use of all five = of
> these capabilities.  It may help to think of IETF mode as 000= 00 and
> ITU mode as 11111.  The mechanism to define and negotiate the= se modes
> will have room for expansion past five bits, so if we ever decide = we
> need more capabilities negotiation in PSC (shared mesh?  m:n?=  other
> fancy stuff?) we can.
>
> As of right now we are only discussing two modes, but it is possib= le
> to define a mode which is some combination of these five things ot= her
> than
> 00000 or 11111.  So a mode is really the set of negotiated
> capabilities between two devices.
>
> There are two ways we can negotiate the use of one more or the oth= er:
>
> 1) Each node announces the mode that it wants, and if the other si= de
> doesn't want exactly the same mode then PSC will not function. &nb= sp;That
> is, both nodes say "my mode is 0bxxxxx" (for now, either= 00000 or
> 11111) and if both nodes don't say the same thing then they compla= in
> to the operator and refuse to function.
>
> Advantage: easy, and if both ends are in a single administrative <= /tt>
> domain I expect the operator to be able to configure both ends to = match.
>
> Disadvantage: tricky if we ever start talking about modes other th= an
> 00000 or 11111.  I don't want a node to say "I support m= ode 00000,
> mode 00001, mode 00010, mode 00011, .... mode 11111" because = if we add
> a few more capabilities we could end up announcing the support of =
> hundreds or thousands of modes.  Does not allow PSC to come u= p unless
> the modes match on both sides, even if there is some common subset=
> they could both agree on.
>
>
> or
>
>
> 2) Each node announces the set of capabilities that it can support=
> along with the ones that it requires, and if the two nodes can fin= d a
> common subset of features then they will converge on those feature= s in PSC.
>
> Advantage: flexible.  If two endpoints can find a common feat= ure
> subset (see example below) then they will come up.
>
> Disadvantage: more complex code, easier to get wrong and converge = on a
> undesirable subset.
>
>
> Examples of each negotiation method are below, both for clarity an= d to
> demonstrate that method #2 works.  My question for the WG is,= which
> one would people prefer, and why?
>
>
>
>
>
>
> eric
>
>
> ---------------------------------
>
>
> Examples
> =3D=3D=3D=3D=3D=3D=3D=3D
> All examples are between two nodes, A and Z.  These examples = focus on
> the actual negotiation, not on the necessary TLV bits to enable th= e
> negotiation.
>
> Example of method 1
> -------------------
> Node A sends a single TLV to Node Z containg the mode bitmap. &nbs= p;Node Z
> sends the same to A.  Call them A.Mode and Z.Mode.  If t= hey do not
> match then some default behavior happens - either PSC doesn't come= up
> or they default to one predetermined mode.
>
> A.mode =3D Z. mode =3D 00000
> A->Z: "I am configured for mode 00000"
> Z->A: "I am configured for mode 00000"
>
> This results in PSC coming up in IETF mode.
>
> A.mode =3D Z.mode =3D 11111
> A->Z: "I am configured for mode 11111"
> Z->A: "I am configured for mode 11111"
>
> This results in PSC coming up in ITU mode.
>
> A.mode !=3D Z.mode (say, 00001 and 00010)
> A->Z: "I am configured for mode 00001"
> Z->A: "I am configured for mode 00010"
>
> PSC does not come up.
>
>
>
> Example of method 2
> -------------------
> Both Node A and Node Z announce two things - Capabilities and Mask= .
> Capabilities is a bitmap of the capabilities that are supported.
> Mask is a mask of don't-care bits against the Capabilities string.=  A
> 0 in Mask means "I don't care if we do this capability or not= ", and a
> 1 means "we must (or must not) agree on this capability in or= der to
> come up".
>
> A.capabilities =3D 00000
> A.mask         =3D 00000
>
> This says "I am capable of supporting all capabilities and I = don't
> care if we do any of them or not"
>
> A.capabilities =3D 00000
> A.mask         =3D 11111
>
> This says "We must not use any of the optional capabilities&q= uot; -
> Capabilities bits are all zero, and Mask bits say "we must ag= ree that
> the corresponding capability is zero".  This is 'IETF mo= de'.
>
> A.capabilities =3D 11111
> A.mask         =3D 11111
>
> This is 'ITU Mode'
>
> Where it gets complicated (or awesome, depending on your perspecti= ve)
> is when you have various subsets.  Consider:
>
> A.Capabilities =3D=3D 01100
> A.Mask =3D=3D 01100
>
> Z.Capabilities =3D=3D 01110
> Z.Mask =3D=3D 01110
>
>
> Negotiation procedures.
> Each side does:
>
>
> res =3D (A.Capabilites & Z.Mask) ^ (Z.Capabilities & A.Mas= k) res =3D
> (01100 & 01110) ^ (01110 & 01100) res =3D (01100) ^ (01100= ) res =3D 00000
>
> if res =3D=3D 0 then it is possible for both sides to find a commo= n subset
> that they support.
> This common subset is called the 'negotiated set', and is determin= ed by:
>
> negotiated_set =3D A.Capabilities | B.Capabilities negotiated_set = =3D
> 01100 | 01110 negotiated_set =3D 01100
>
> if res !=3D 0 then it is impossible to find a subset that the two = ends
> can agree on, and PSC will never come up.
>
> Once each side computes the negotiated set, they signal it and PSC=
> starts to work.
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf= .org/mailman/listinfo/mpls
> <https://www.= ietf.org/mailman/listinfo/mpls>
>

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/l= istinfo/mpls

--_000_7347100B5761DC41A166AC17F22DF1121B6E0724eusaamb103erics_-- From wyaacov@gmail.com Thu Aug 22 11:56:13 2013 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 C5C4711E8203 for ; Thu, 22 Aug 2013 11:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMw4yS8kv4JA for ; Thu, 22 Aug 2013 11:56:12 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id A409411E81F5 for ; Thu, 22 Aug 2013 11:56:11 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id c11so1997426wgh.20 for ; Thu, 22 Aug 2013 11:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FzW6cRJaSQcn8+B2H1IHauBLZI7ExC/rAcRk93xCE1w=; b=ihRSn0Hx1oRv7bYIkptD5KPttr8DGAR3+uMvndt16wMSBpkMguNW0V2sA6oyNRE6Q7 jeLi/Bd9QoB9l5PR5qHKX4zc3P29VNt4i8kW2llbFv6OK8uYxl6b7DUQTws0rlYIOZ+T HRth2XgLpfelMpdS6BDnQcsN1gnlLBulu/NMkP0Cs4yJzrAoU8aZ4v1COEOw+Y3ydprF DuJU0nxs+LJ4z9WaT8LbDNqo6lhtLzEAw5t3uYwAQe2KoYkt2ZtrYVe7sPU6+7UD/q3L KhKG5itVnk5ftdzUJ8QrfzAkBhHZejwABEXbCKRp41Ue+1XQ1n1F+F30byBRULysub/j 4FiQ== MIME-Version: 1.0 X-Received: by 10.180.24.234 with SMTP id x10mr10913021wif.47.1377197770580; Thu, 22 Aug 2013 11:56:10 -0700 (PDT) Received: by 10.194.164.200 with HTTP; Thu, 22 Aug 2013 11:56:10 -0700 (PDT) In-Reply-To: References: <5204D9DE.6060405@pi.nu> Date: Thu, 22 Aug 2013 21:56:10 +0300 Message-ID: From: Yaacov Weingarten To: "mpls@ietf.org" Content-Type: multipart/alternative; boundary=f46d044280bee6ac5504e48dd722 Cc: "draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents 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, 22 Aug 2013 18:56:13 -0000 --f46d044280bee6ac5504e48dd722 Content-Type: text/plain; charset=ISO-8859-1 Hi, I have conducted a review of draft-cdh-mpls-tp-psc-non-revertive as requested by the WG Chairs and have the following notes: This draft purports to "update" RFC6378 to change non-revertive behavior of the Linear Protection protocol. The method of updating the protocol is through the addition of a Manual Switch to Working operator command to affect the reversion of traffic to the working path. Along the way the authors propose to change the name of the Manual Switch operator command already defined in RFC6378 and also change the name of the Protecting Administrative State to Switching Administrative State. The format of the draft is in the form of an errata correction document, indicating which paragraphs in the RFC should be replaced and what new text should be substituted in its place. This draft is part of a set of drafts that was discussed at the IETF87 meeting that will include an "overview" document that describes how to incorporate the new functionality described in those drafts. With this introduction I would like to make the following observations: 1. There are accepted methods used in the IETF to update a RFC by adding new functionality to a protocol. Usually, this is done by writing a draft that describes the new functionality on top of the existing functionality rather than the method used here. This is especially strange considering that they are not changing the behavior of the existing functionality but just adding an additional command and describing its behavior. 2. Based on this observation and the fact that all of the suggested "corrections" to the text involving "Manual Switch" are to change the name but not the functionality, I do not see the justification in changing the name of the existing Manual Switch command since its functionality is essentially remaining as defined and there is no cause for confusion with the new "Manual Switch to Working" command. 3. I see problems with the suggestion to change the "Protecting Administrative State" to "Switching Administrative State" since this requires the confusing statement (in Section 4.9) "the user traffic SHALL be transported on either the protection path or the working path" which is certainly always true for traffic that is being transported. Why not create a new State? Or even better, since the MS-W is meant to return the state to Normal why not just use Normal state? 4.An observation that I made to the psc-priority draft is applicable to this draft as well - I do not understand the referencing of an LS from ITU - this is not a standards document, just a contribution for discussion and should not be referenced. 5.Section 4.8 of this document highlights a problem that is raised by this set of drafts and their method of presentation. In this section, a "correction" is proposed for text that appears in RFC6378 section 4.3.3.2. This "corrects" the original text with new text. However, this text is also "corrected" in the psc-priority draft! Now the question that needs to be asked is which correction is the definitive correction - the one in this draft or the one in the other draft? Is this dependent upon the order in which the drafts will be published? 6. Section 4.6 of the draft presents a very lengthy description of an "algorithm" for resolving the priority of inputs "having equal priority". The case of inputs having the same priority are those in which the MS and MS-W inputs are received. I believe that this set of rules are rather confusing and the upshot of the explanation seems to be that either you use the rule of "first-come first-served" or that MS-W has higher priority, except in some very specific conditions. I am certain that this could be more clearly stated or explained. Bottom line, I do not think that this draft is ready for WG acceptance. I would suggest that it be rewritten to update the new functionality that is being proposed while leaving the existing non-changed functionality as is. I also suggest that the format not be based on "corrections" to the existing draft - this is not a contribution to a "living" document, but rather a new document that updates the previous document. Hope this helps, yaacov weingarten On Thu, Aug 22, 2013 at 12:05 PM, Mach Chen wrote: > Hi, > > I have done my MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00, > here are my comments: > > I think that modification to Non-revertive mode, adding MS-W and renaming > MS to MS-F are valid points. But I not sure whether there is a need to > replace " Protecting administrative state" to "Switching administrative > state". > > Read through the draft, it gives me the feeling that the draft just lists > a set of erratas, I am not sure that this is the right way to progress the > draft as it be. If the WG have the consensus on the content of the draft, > IMHO, it's better to do a bis to RFC6378. > > Minor comment: > It's better to expand the acronym when first use, for example the MS-F and > MS-W, I have to guess the meaning of until I see the Acronyms section. > > Best regards, > Mach > > > -----Original Message----- > > From: Loa Andersson [mailto:loa@pi.nu] > > Sent: Friday, August 09, 2013 8:01 PM > > To: Eric Osborne (eosborne); Eric Gray; kenji.fujihira.dj@hitachi.com; > Yaacov > > Weingarten; Sam Aldrin; Mach Chen; Kamran Raza (skraza); Henderickx, Wim > > (Wim); thomas.morin@orange.com; mjork@juniper.net > > Cc: draft-osborne-mpls-psc-updates@tools.ietf.org; > > draft-dj-mpls-tp-exer-psc@tools.ietf.org; > > draft-rhd-mpls-tp-psc-sd@tools.ietf.org; > > draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org; > > draft-rhd-mpls-tp-psc-priority@tools.ietf.org; > mpls-chairs@tools.ietf.org; > > VIGOUREUX, MARTIN (MARTIN) > > Subject: MPLS-RT review of mpls psc documents > > > > Eric, Eric, Kenji, Yacoov, Sam, Mach, Kamran, Wim, Thomas and Markus, > > > > You been selected as MPLS-RT reviewers for a set of psc document that we > > will start progress through the mpls working group. > > > > The normal rules and question for an MPLS-RT apply: > > > > ---------- quote from a standard mail initiating MPLS-RT review ------- > > > > Note to authors: You have been CC'd on this email so that you can know > > that this review is going on. However, please do not review your own > > document. > > > > Reviews should comment on whether the document is coherent, is it > > useful (ie, is it likely to be actually useful in operational > > networks), and is the document technically sound? We are interested > > in knowing whether the document is ready to be considered for WG > > adoption (ie, it doesn't have to be perfect at this point, but should be > > a good start). > > > > Reviews should be sent to the document authors, WG co-chairs and > > WG secretary, and CC'd to the MPLS WG email list. If necessary, comments > > may be sent privately to only the WG chairs. > > > > ---------------------- end quote ------------------------- > > > > The only difference is that we take on more than one document and that > > there are such inter-dependencies that we want to coordinate how they > > are progressed through IETF. > > > > Please respond (at least) to the wg chairs and Martin that you are > > willing/un-willing to undertake the reviews. > > > > Since we are starting MPLS-RT reviews of 5 documents, with 4 reviewers > > for each document and each reviewer have two documents, you'll need > > to send the review with the draft name in the subject line, i.e. do > > not respond to this mail with your review comments. > > > > There is also a "PSC modes" document in the pipe, currently it is our > > opinion that this document is necessary when we will start the wglc's > > but is not necessary to make the other drafts wg documents. > > > > Can you please finish your reviews eob August 23, 2013. > > > > Here is the list of reviewers per document: > > > > draft-rhd-mpls-tp-psc-priority > > ------------------------------ > > mach chen > > thomas morin > > yacoov weingarten > > Wim Henderickx > > > > draft-cdh-mpls-tp-psc-non-revertive > > ----------------------------------- > > mach chen > > eric osborne > > eric gray > > yacoov weingarten > > > > draft-rhd-mpls-tp-psc-sd > > ------------------------ > > eric osborne > > sam aldrin > > eric gray > > kamran raza > > > > draft-dj-mpls-tp-exer-psc > > ------------------------- > > sam aldrin > > markus jork > > kamran raza > > kenji fuhira > > > > draft-osborne-mpls-psc-updates > > ------------------------------ > > markus jork > > thomas morin > > kenji fuhira > > Wim Henderickx > > > > > > Authors, > > > > Please do not update the documents during the review period, we will > > tell you when the review period has ended. > > > > When we close the review period you'll need to address the comments > > from the reviewers and communicate with them (preferably on the mpls > > wg mailing list) to make sure that they are comfortable with how the > > comments has been addressed. > > > > > > /Loa > > for the mpls wg chairs > > > > -- > > > > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Thanx and BR, yaacov *Still looking for new opportunity* --f46d044280bee6ac5504e48dd722 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I have conducted a review of draft-= cdh-mpls-tp-psc= -non-rev= ertive as requested by the WG Chairs and have the following notes:

Thi= s draft purports to "update" RFC6378 to change non-revertive beha= vior of the Linear Protection protocol. The method of updating the protocol= is through the addition of a Manual Switch to Working operator command to = affect the reversion of traffic to the working path. Along the way the auth= ors propose to change the name of the Manual Switch operator command alread= y defined in RFC6378 and also change the name of the Protecting Administrat= ive State to Switching Administrative State.

The= format of the draft is in the form of an errata correction document, indic= ating which paragraphs in the RFC should be replaced and what new text shou= ld be substituted in its place.

Thi= s draft is part of a set of drafts that was discussed at the IETF87 meeting= that will include an "overview" document that describes how to i= ncorporate the new functionality described in those drafts.

Wit= h this introduction I would like to make the following observations:=
1. There a= re accepted methods used in the IETF to update a RFC by adding new function= ality to a protocol. Usually, this is done by writing a draft that describe= s the new functionality on top of the existing functionality rather than th= e method used here. This is especially strange considering that they are no= t changing the behavior of the existing functionality but just adding an ad= ditional command and describing its behavior.=A0

2. = Based on this observation and the fact that all of the suggested "corr= ections" to the text involving "Manual Switch" are to change= the name but not the functionality,=A0I do not see the justification in changing t= he name of the existing Manual Switch command since its functionality is es= sentially remaining as defined and there is no cause for confusion with the= new "Manual Switch to Working" command.

3. I see problems with the sug= gestion to change the "Protecting=A0Administrative=A0State" to &q= uot;Switching=A0Administrative=A0State" since this requires the confus= ing statement (in Section 4.9) "the user traffic SHALL be transported = on either the protection path or the working path" which is certainly = always true for traffic that is being transported. Why not create a new Sta= te? Or even better, since the MS-W is meant to return the state to Normal w= hy not just use Normal state?

4.An observation that I made to the psc-priority draft is= applicable to this draft as well - I do not understand the referencing of = an LS from ITU - this is not a standards document, just a contribution for = discussion and should not be referenced.

5.Section 4.8 of this document highlights a problem that = is raised by this set of drafts and their method of presentation. In this s= ection, a "correction" is proposed for text that appears in RFC63= 78 section 4.3.3.2. This "corrects" the original text with new te= xt. However, this text is also "corrected" in the psc-priority dr= aft! Now the question that needs to be asked is which correction is the def= initive correction - the one in this draft or the one in the other draft? I= s this dependent upon the order in which the drafts will be published?

6. Section 4.6 of the draft presents a very lengthy descr= iption of an "algorithm" for resolving the priority of inputs &qu= ot;having equal priority". The case of inputs having the same priority= are those in which the MS and MS-W inputs are received. I believe that thi= s set of rules are rather confusing and the upshot of the explanation seems= to be that either you use the rule of "first-come first-served" = or that MS-W has higher priority, except in some very specific conditions. = I am certain that this could be more clearly stated or explained.

Bottom line, I do not think that this draft is ready for = WG acceptance. I would suggest that it be rewritten to update the new funct= ionality that is being proposed while leaving the existing non-changed func= tionality as is. I also suggest that the format not be based on "corre= ctions" to the existing draft - this is not a contribution to a "= living" document, but rather a new document that updates the previous = document.

Hope this helps,
yaacov weingarten

On Thu, Aug 22, 2013 at 12:05 PM, Mach Chen <mach.chen@huawei.com> wrote:
Hi,

I have done my MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00, he= re are my comments:

I think that modification to Non-revertive mode, adding MS-W and renaming M= S to MS-F are valid points. But I not sure whether there is a need to repla= ce " Protecting administrative state" to "Switching administ= rative state".

Read through the draft, it gives me the feeling that the draft just lists a= set of erratas, I am not sure that this is the right way to progress the d= raft as it be. If the WG have the consensus on the content of the draft, IM= HO, it's better to do a bis to RFC6378.

Minor comment:
It's better to expand the acronym when first use, for example the MS-F = and MS-W, I have to guess the meaning of until I see the Acronyms section.<= br>
Best regards,
Mach

> -----Original Message-----
> From: Loa Andersson [mailto:loa@pi.nu= ]
> Sent: Friday, August 09, 2013 8:01 PM
> To: Eric Osborne (eosborne); Eric Gray; kenji.fujihira.dj@hitachi.com; Yaacov
> Weingarten; Sam Aldrin; Mach Chen; Kamran Raza (skraza); Henderickx, W= im
> (Wim); thomas.morin@orange.= com; mjork@juniper.net
> Cc: d= raft-osborne-mpls-psc-updates@tools.ietf.org;
> draft-dj-m= pls-tp-exer-psc@tools.ietf.org;
> draft-rhd-m= pls-tp-psc-sd@tools.ietf.org;
> = draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org;
> draft= -rhd-mpls-tp-psc-priority@tools.ietf.org; mpls-chairs@tools.ietf.org;
> VIGOUREUX, MARTIN (MARTIN)
> Subject: MPLS-RT review of mpls psc documents
>
> Eric, Eric, Kenji, Yacoov, Sam, Mach, Kamran, Wim, Thomas and Markus,<= br> >
> You been selected as MPLS-RT reviewers for a set of psc document that = we
> will start progress through the mpls working group.
>
> The normal rules and question for an MPLS-RT apply:
>
> ---------- quote from a standard mail initiating MPLS-RT review ------= -
>
> Note to authors: You have been CC'd on this email so that you can = know
> that this review is going on. However, please do not review your own > document.
>
> Reviews should comment on whether the document is coherent, is it
> useful (ie, is it likely to be actually useful in operational
> networks), and is the document technically sound? =A0We are interested=
> in knowing whether the document is ready to be considered for WG
> adoption (ie, it doesn't have to be perfect at this point, but sho= uld be
> a good start).
>
> Reviews should be sent to the document authors, WG co-chairs and
> WG secretary, and CC'd to the MPLS WG email list. If necessary, co= mments
> may be sent privately to only the WG chairs.
>
> ---------------------- end quote -------------------------
>
> The only difference is that we take on more than one document and that=
> there are such inter-dependencies that we want to coordinate how they<= br> > are progressed through IETF.
>
> Please respond (at least) to the wg chairs and Martin that you are
> willing/un-willing to undertake the reviews.
>
> Since we are starting MPLS-RT reviews of 5 documents, with 4 reviewers=
> for each document and each reviewer have two documents, you'll nee= d
> to send the review with the draft name in the subject line, i.e. do > not respond to this mail with your review comments.
>
> There is also a "PSC modes" document in the pipe, currently = it is our
> opinion that this document is necessary when we will start the wglc= 9;s
> but is not necessary to make the other drafts wg documents.
>
> Can you please finish your reviews eob August 23, 2013.
>
> Here is the list of reviewers per document:
>
> draft-rhd-mpls-tp-psc-priority
> ------------------------------
> mach chen
> thomas morin
> yacoov weingarten
> Wim Henderickx
>
> draft-cdh-mpls-tp-psc-non-revertive
> -----------------------------------
> mach chen
> eric osborne
> eric gray
> yacoov weingarten
>
> draft-rhd-mpls-tp-psc-sd
> ------------------------
> eric osborne
> sam aldrin
> eric gray
> kamran raza
>
> draft-dj-mpls-tp-exer-psc
> -------------------------
> sam aldrin
> markus jork
> kamran raza
> kenji fuhira
>
> draft-osborne-mpls-psc-updates
> ------------------------------
> markus jork
> thomas morin
> kenji fuhira
> Wim Henderickx
>
>
> Authors,
>
> Please do not update the documents during the review period, we will > tell you when the review period has ended.
>
> When we close the review period you'll need to address the comment= s
> from the reviewers and communicate with them (preferably on the mpls > wg mailing list) to make sure that they are comfortable with how the > comments has been addressed.
>
>
> /Loa
> for the mpls wg chairs
>
> --
>
>
> Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: loa@mail01.huawei.com
> Senior MPLS Expert =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= loa@pi.nu
> Huawei Technologies (consultant) =A0 =A0 phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls



--
Thanx and BR,
yaacov

Still looking for= new opportunity
--f46d044280bee6ac5504e48dd722-- From iesg-secretary@ietf.org Thu Aug 22 15:50:56 2013 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 6D0CF11E822C; Thu, 22 Aug 2013 15:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.129, 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 nZqRECVTwwQn; Thu, 22 Aug 2013 15:50:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 528E811E8234; Thu, 22 Aug 2013 15:50:51 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130822225051.5839.66414.idtracker@ietfa.amsl.com> Date: Thu, 22 Aug 2013 15:50:51 -0700 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'LDP Downstream-on-Demand in Seamless MPLS' to Proposed Standard (draft-ietf-mpls-ldp-dod-09.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: Thu, 22 Aug 2013 22:50:57 -0000 The IESG has approved the following document: - 'LDP Downstream-on-Demand in Seamless MPLS' (draft-ietf-mpls-ldp-dod-09.txt) as 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-ldp-dod/ Technical Summary Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand (LDP DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence. Working Group Summary There is a strong support for this document in the working group and it has been has been well reviewed. Draft has been mainly driven and architected by an operator that have specifed the Seamless MPLS, based on opreational experiences. Document Quality There are both existing and intended implementations of this specification. The document has been reviewed as needed, the working group last call was brought to the attention of SG15 in ITU-T. Personnel Loa Andersson is the document shepherd. Adrian Farrel is the responsible AD. RFC Editor Note Please replace "ISIS" with "IS-IS" throughout. On first use, please expand RIB and FIB as Routing Information Base Forwarding Information base Please expand ECMP as Equal-Cost Multipath Please expand LAG as Link Aggregation Group Please expand FEC as Forwarding Equivalence Class Please expand IPFRR as IP Fast-reroute Please expand LFA as Loop-Free Alternate --- Abstract s/specific to access/specific to access networks/ --- Section 1 s/(access ABRs)/ABRs/ --- Section 3.1.1... In order to facilitate ECMP and IPFRR LFA local-repair, the upstream AN/AGN1x also sends LDP DoD label requests to alternate next-hops per its RIB, and install received labels as alternate entries in its LIB and LFIB. As well as expanding the acronyms as requested above, please... s/local-repair/ local-repair [RFC5714]/ --- Section 4.3.2 s/algoritm/algorithm/ --- Section 4.6 To support local-repair with ECMP and IPFRR LFA, access LSR/ABR requests labels on both the best next-hop and the alternate next-hop LDP DoD sessions, as specified in the Label Request procedures in Section 4.3. If remote LFA is enabled, access LSR/ABR needs a label from its alternate next-hop toward the PQ node and needs a label from the remote PQ node toward its FEC/destination. If access LSR/ABR doesn't already know those labels, it requests them. Note that "PQ" has no expansion! s/destination./destination [I-D.ietf-rtgwg-remote-lfa]./ --- Section 9.2 please add [I-D.ietf-rtgwg-remote-lfa] Bryant, S., Filsfils, C., Previdi, S., Shand, M. and N. So, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa, (work in progress. [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, January 2010. From mach.chen@huawei.com Fri Aug 23 01:09:02 2013 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 69EFF11E815E for ; Fri, 23 Aug 2013 01:09:02 -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=0.000, 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 JAtgDFG6BTlW for ; Fri, 23 Aug 2013 01:08:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4F87511E8173 for ; Fri, 23 Aug 2013 01:08:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AWI97379; Fri, 23 Aug 2013 08:08:52 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 23 Aug 2013 09:08:14 +0100 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 23 Aug 2013 09:08:47 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.128]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Fri, 23 Aug 2013 16:08:41 +0800 From: Mach Chen To: "loa@pi.nu" , "mpls@ietf.org" , "draft-rhd-mpls-tp-psc-priority@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "martin.vigoureux@alcatel-lucent.com" Thread-Topic: MPLS-RT review on draft-rhd-mpls-tp-psc-priority-01 Thread-Index: Ac6f1/oEfbWhKMZFQICpbkCZc3Y4HQ== Date: Fri, 23 Aug 2013 08:08:41 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [mpls] MPLS-RT review on draft-rhd-mpls-tp-psc-priority-01 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, 23 Aug 2013 08:09:02 -0000 Hi, I have done my MPLS-RT review on draft-rhd-mpls-tp-psc-priority-01. The draft proposes three changes to RFC6378 1) swap the priority of FS and SF-P: the scenario is valid and this solutio= n to that scenarios is also valid. At the same time, need to consider wheth= er this change will lead to other potential problems. With this change, the= operator will not be able to forth switch the traffic to protection path w= hen signal fail in protection path. This may required in the situation wher= e both working and protection path are failed, and the operator may hope to= forth switch the traffic to the protection path before making sure the wor= king path is recovered, or before determining what caused the working path = failed.=20 2) raise the priority of "Clear SF": the situation described in Appendix B = may occur if the "Clear SF" input is really ignored and dropped after repor= ting to the PSC logic. IMHO, the critical inputs (like SF, Clear SF) should= never be ignored and dropped, but they could be suspended and processed la= ter on. Raise the priority is a potential valid solution to the issue. In = addition, the current Fpath only has two states, 0 and 1, it cannot convey = the situation that both protection and working path are failed. If there is= third state, for example, 2 that indicates the anomaly condition is on bot= h protection and working path, thing may be different. 3) Freeze command, I think it is a valid solution if the priority of FS and= SF-P is swapped. One clarify question about it, does it mean that both end= s need to configure the Freeze command? The format of this draft is similar to draft-cdh-mpls-tp-psc-non-revertive-= 00, the proposed updates look like erratas. So, I do believe the better way= is to do a bis IMHO. Best regards, Mach =20 From kenji.fujihira.dj@hitachi.com Fri Aug 23 03:59:34 2013 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 E6C0711E82D6 for ; Fri, 23 Aug 2013 03:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.523 X-Spam-Level: ** X-Spam-Status: No, score=2.523 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_ISO2022JP=0.413] 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 zCW91CdoV+OA for ; Fri, 23 Aug 2013 03:59:28 -0700 (PDT) Received: from mail9.hitachi.co.jp (mail9.hitachi.co.jp [133.145.228.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9663511E82DD for ; Fri, 23 Aug 2013 03:59:28 -0700 (PDT) Received: from mlsv6.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id 2A63837C89; Fri, 23 Aug 2013 19:59:27 +0900 (JST) Received: from mfilter05.hitachi.co.jp by mlsv6.hitachi.co.jp (8.13.1/8.13.1) id r7NAxRhm015373; Fri, 23 Aug 2013 19:59:27 +0900 Received: from vshuts02.hitachi.co.jp (vshuts02.hitachi.co.jp [10.201.6.84]) by mfilter05.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id r7NAxPQu024603; Fri, 23 Aug 2013 19:59:26 +0900 Received: from gxml06a.ad.clb.hitachi.co.jp (unknown [158.213.157.85]) by vshuts02.hitachi.co.jp (Postfix) with ESMTP id 56643490051; Fri, 23 Aug 2013 19:59:26 +0900 (JST) Received: from [127.0.0.1] by gxml06a.ad.clb.hitachi.co.jp (Switch-3.1.10/Switch-3.1.9) id 57NA2NP3900003D0C; Fri, 23 Aug 2013 19:59:25 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: , From: Date: Fri, 23 Aug 2013 19:59:15 +0900 Priority: normal Importance: normal X400-Content-Identifier: X5217408300000M X400-MTS-Identifier: [/C=JP/ADMD=GMGROUP/PRMD=GMGROUP/;mta7130823195915YCF] Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org Subject: [mpls] =?iso-2022-jp?b?TVBMUy1SVCByZXZpZXcgb24gZHJhZnQtZGotbXBs?= =?iso-2022-jp?b?cy10cC1leGVyLXBzYy0wMQ==?= 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, 23 Aug 2013 10:59:35 -0000 Hi, authors and chairs. I've reviewed draft-dj-mpls-tp-exer-psc-01 as the MPLS-RT process. a. Is the document coherent? It's close to coherent. I noticed an inconsistency between section 2.5. and 2.8. According to section 2.5, FPath and Path values are set to the same as the request that EXER replaces. On the other hand, according to section 2.8, these values are set as follows. E::L EXER(0,0)for revertive, or EXER(0,1)for non-revertive E::R RR(0,0) for revertive, or RR(0,1) for non-revertive I suppose the description in section 2.5. is the intended action. For example, when the state moves from N to E::L, Path value in EXER will be 0. b. Is it useful (ie, is it likely to be actually useful in operational networks)? I suppose it's useful, considering that traditional transport protection protocol (i.e. APS) has the same mechanism, and an operator is involved in the authors list. I have one comment. Taking into account the objective, the management system should be notified when a node receives remote RR or EXER requests. It will be valuable if the authors address this point in the draft, for example in section 2.3. c. Is the document technically sound? I have one question to section 2.7.3. and 2.8. According to these sections, when the current state is E::L and the configuration is non-revertive, a local Clear command causes a state transition to DNR even if user traffic is transmitted on working path. As a result, the traffic will be switched from working path to protection path. Is this the intended action? In my understanding, the state should go into N in this case, according to section 1, "without triggering the actual traffic switching". Dividing state E::L into two states, E::L(working selected), and E::L(protection selected), might clear this point. d. Is the document ready to be considered for WG adoption? I hope the comments above are closed before WG adoption. Best Regards, Kenji. From kenji.fujihira.dj@hitachi.com Fri Aug 23 03:59:45 2013 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 43AF511E82F6 for ; Fri, 23 Aug 2013 03:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.523 X-Spam-Level: ** X-Spam-Status: No, score=2.523 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_ISO2022JP=0.413] 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 qreXZN-1Glf7 for ; Fri, 23 Aug 2013 03:59:39 -0700 (PDT) Received: from mail4.hitachi.co.jp (mail4.hitachi.co.jp [133.145.228.5]) by ietfa.amsl.com (Postfix) with ESMTP id 05D2611E82F3 for ; Fri, 23 Aug 2013 03:59:39 -0700 (PDT) Received: from mlsv1.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id 3EE5533CC7; Fri, 23 Aug 2013 19:59:38 +0900 (JST) Received: from mfilter05.hitachi.co.jp by mlsv1.hitachi.co.jp (8.13.1/8.13.1) id r7NAxcbW001480; Fri, 23 Aug 2013 19:59:38 +0900 Received: from vshuts02.hitachi.co.jp (vshuts02.hitachi.co.jp [10.201.6.84]) by mfilter05.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id r7NAxb0F024662; Fri, 23 Aug 2013 19:59:37 +0900 Received: from gxml06a.ad.clb.hitachi.co.jp (unknown [158.213.157.85]) by vshuts02.hitachi.co.jp (Postfix) with ESMTP id D777749004D; Fri, 23 Aug 2013 19:59:36 +0900 (JST) Received: from [127.0.0.1] by gxml06a.ad.clb.hitachi.co.jp (Switch-3.1.10/Switch-3.1.9) id 57NA2NZQI00008BC4; Fri, 23 Aug 2013 19:59:36 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: , From: Date: Fri, 23 Aug 2013 19:59:27 +0900 Priority: normal Importance: normal X400-Content-Identifier: X5217408F00000M X400-MTS-Identifier: [/C=JP/ADMD=GMGROUP/PRMD=GMGROUP/;mta7130823195927YCU] Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org Subject: [mpls] =?iso-2022-jp?b?TVBMUy1SVCByZXZpZXcgb24gZHJhZnQtb3Nib3Ju?= =?iso-2022-jp?b?ZS1tcGxzLXBzYy11cGRhdGVzLTAx?= 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, 23 Aug 2013 10:59:45 -0000 Hi, I've reviewed draft-osborne-mpls-psc-updates-01 as the MPLS-RT process. a. Is the document coherent? It's almost coherent. I need just one clarification about section 4. "When L(SF-W) is removed but R(SF-W) remains, what does PSC do? A strict reading of the FSM would suggest that PSC transition from PA:F:L into N, and at some future time (perhaps after the remote request refreshes) PSC would transition from N to PA:F:R." PA:F:L/R is Protecting administrative state due to local or Remote FS operator command, so it doesn't match in this context. In my understanding, the strict reading of the FSM leads the following transition. PF:W:L -> DNR -> PF:W:R (for non-revertive operation) PF:W:L -> WTR (for revertive operation) b. Is it useful (ie, is it likely to be actually useful in operational networks)? I believe it's useful. c. Is the document technically sound? Yes, the described mechanism and objective are clear to me. d. Is the document ready to be considered for WG adoption? I hope the comment above is closed before WG adoption. Best Regards, Kenji. From eric.gray@ericsson.com Fri Aug 23 06:16:52 2013 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 9242C11E82F4 for ; Fri, 23 Aug 2013 06:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 Wphn1irrf+-a for ; Fri, 23 Aug 2013 06:16:41 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id A508A11E819E for ; Fri, 23 Aug 2013 06:16:41 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-ae-521760b8d63f Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 0D.86.09414.8B067125; Fri, 23 Aug 2013 15:16:40 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Fri, 23 Aug 2013 09:16:39 -0400 From: Eric Gray To: "Jeong-dong Ryoo " , "Huub van Helvoort (huub.van.helvoort@huawei.com)" , "Alessandro D Alessandro" , "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-rhd-mpls-tp-psc-sd Thread-Index: Ac6fet6EcmRIJFLJRD+Yvx86i1T8kw== Date: Fri, 23 Aug 2013 13:16:39 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF642E5F4@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyuXRPgu6OBPEggzcX1S1OLDvMYrHp7Tcm i39z5zBb3Nn1hdXi1tKVrBZ/V1xhsejv3s5mcXtKE6MDh0frs72sHlN+b2T12Pr5IaNHy5G3 rB5Llvxk8rjedJXdY9b0NjaPlnO97AEcUVw2Kak5mWWpRfp2CVwZh8/PZy/Yb1zReeUyYwPj JM0uRk4OCQETiYP9vWwQtpjEhXvrgWwuDiGBo4wS3051s0M4yxklbjR+YAepYhPQkDh2Zy0j SEJE4AejxNetnawgDrPAL0aJjb+PsoJUCQuYSxz4so4RxBYRsJDYdeMiO4StJ3H70iewfSwC qhITH0DEeQW8JTZNn84EYjMC3fH91Bowm1lAXOLWk/lMEPcJSCzZc54ZwhaVePn4HyuErSyx 5Ml+Foh6HYkFuyHmMwtoSyxb+JoZYr6gxMmZT1gmMIrMQjJ2FpKWWUhaZiFpWcDIsoqRo7Q4 tSw33chgEyMw5o5JsOnuYNzz0vIQozQHi5I47yq9M4FCAumJJanZqakFqUXxRaU5qcWHGJk4 OKUaGHs79Lt/HywPYVvvsGfb/MBFix0FMpy+VyyQMvrQG9+TfKVPdNWWrWqu5bvc9fXexLlu 4+bVXveiV6N2jVDNHvub7svmHK5Uks7sPRFwWW25wbvvH9bHxO3O9f1gtVMyW3KV4S9l3nMx QZLnf9+KZ5Nk4d/y+PbZvHtRe3jNNqtP5Pm7Wkf5oBJLcUaioRZzUXEiAARVZ2CHAgAA Cc: "Ross Callon \(rcallon@juniper.net\)" Subject: Re: [mpls] MPLS-RT review of draft-rhd-mpls-tp-psc-sd 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, 23 Aug 2013 13:16:52 -0000 Hi, I have been asked to review this draft, and to determine if it is in good = enough shape to be adopted by the MPLS working group.=20 Although requested to include the MPLS working group mailing list as a "Cc= ", I have included it as a "To" because of the questions I think need to be reso= lved either=20 by discussion in the working group, or decision by the working group chairs= . In general, I find this draft to be well written and may be ready for adop= tion by the=20 MPLS working group. There are two general questions about what may be acce= ptable to=20 the working group that should be resolved in some way prior to adoption of = this draft by=20 the working group. The questions are included as the first part of my comm= ents below. I have the following comments and/or questions: Major Comments/Questions: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D General questions for the MPLS working Group ---------------------------------------------------------- First Question -- The way that this draft is written is as a "delta" to RFC 6378. I personal= ly do not have any problems with this, assuming that a reader can correctly (re)construct the = resulting text as applied to RFC 6378. =20 However, over the long term, it is significant that this "delta" will not a= ctually be applied to RFC 6378 and may therefore lead to ambiguity and/or confusion if other s= ubsequent "deltas" are produced against the same RFC in the future. When/if this hap= pens, it is likely that the combination of multiple "delta" RFCs will force a re-write = of RFC 6378 to remove ambiguity and/or confusion. As an example, should a subsequent "update" to RFC 6378 suggest renumbering= of the sections affected by this document, there will likely be confusion resultin= g from the order that a reader reads the set of documents, applying the changes in the= order that they read them, as opposed to the order in which they were written and inte= nded. Is the working group generally okay with taking this approach? (Alternatively, this draft could be re-written as a "bis" for RFC 6378, obs= oleting that RFC as opposed to updating it, or it could be re-written as a quasi-stand-alone= document -=20 rather than as a set of deltas to RFC 6378 - referring to RFC 6378 for prot= ection switching=20 behavior not explicitly described in this document.)=20 Second Question -- Is it simpler to deal with this draft as a separate draft, or should it be = combined with the other related drafts that are also (at least primarily) intended to update = RFC 6378? At least with the two drafts I've been asked to review (adding signal degra= de, and making corrections to non-revertive mode), the modifications to RFC 6378 appear to= be distinct, non-overlapping, changes throughout the drafts. Where this is more difficu= lt to be certain of is in the changes to the state-machine tables - which are quite complex. At various points in the process, when reviewing the draft, the best approa= ch to verifying that there is no overlap or inconsistency is to actually merge all of the c= hanges and then review the result. If this turns out to be the case for every reviewer, th= en there is no benefit to having these as separate drafts. Should all of these related drafts be merged? Minor Comments and NITs: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D You need to add "updates RFC 6378 (when published)" to the header of the fi= rst page. The title could be shortened by removing both instances of "the" (neither a= rticle is helpful). In the published form, the Abstract MUST NOT say "contains the updates to [= RFC6378]" as other documents will "contain updates" to RFC 6378 at some point in the fut= ure as well.=20 I note that this is already the case, with other drafts in progress. I suggest omitting "contains the updates to" from the abstract, replacing i= t with "updates" and adding a second comma after "Linear Protection" (the text "MPLS Transpo= rt Profile ... Linear Protection" is a parenthetical description of RFC 6378). The same c= omment applies to the Introduction section as well. In the first paragraph of the Introduction, "a fault condition includes" is= grammatically=20 incorrect. I suggest "fault conditions include" instead. Prior to the second paragraph of the Introduction, you have not yet used/ex= plained that "MPLS Transport Profile (MPLS-TP) Linear Protection" and "PSC" are equivale= nt. I suggest either adding a short paragraph before this paragraph that explains this, o= r not using the Acronym "PSC" until after section 3. Also I am uncertain that it is precisely correct to refer to RFC 6378 as "t= he PSC document." I suggest inserting a new paragraph along the lines of: "The PSC protocol is defined in RFC 6378." And then replace delete "The PSC document" at the start of the next paragra= ph. In the current second paragraph of the Introduction, I suggest replacing "b= ut" with "and" (I believe your point is that these are both inadequacies of RFC 6378 - the= fact that it does not specify how declaration is done for either fault _and_ that it only des= cribes protection switching for the SF case).=20 "PSC" needs to be added to section 3 ("Acronyms"). The "lingua Franca" for IETF drafts and RFCs is _American_ English, so "beh= avior" not=20 "behaviour" (e.g. - section 4, first and fifth lines of the first paragraph= ). As a question, should we be trying to be consistent in the use of capitaliz= ation with the phrase "Signal Degrade" (you have it in lower case at several points in the= draft)? In section 5.2, I have a slight problem with the wording relating to config= uration of the protection domain for revertive behavior. However, the issue existed in th= e original text in RFC 6378, hence I consider this a minor issue at this point. The i= ssue I have is that there are two conditions that are applicable to the behavior: 1) when recovering from ... condition on the working path and 2) when the protection domain has been configured for revertive behavior. It is not clear (probably because of the ordering) that configuring the pro= tection domain for revertive behavior is something that would have been done prior to reco= very from a failure or degradation condition. It is very likely that simply re-ordering the text will clear this up. -- Eric Gray From eric.gray@ericsson.com Fri Aug 23 06:17:12 2013 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 277BE11E81BE for ; Fri, 23 Aug 2013 06:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 Lr363bDsHDJR for ; Fri, 23 Aug 2013 06:17:07 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 797EC11E82FE for ; Fri, 23 Aug 2013 06:17:02 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-c1-521760cddffc Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 85.44.03458.DC067125; Fri, 23 Aug 2013 15:17:01 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Fri, 23 Aug 2013 09:17:01 -0400 From: Eric Gray To: Taesik Cheung , "Huub van Helvoort (huub.van.helvoort@huawei.com)" , "Alessandro D Alessandro" , "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-cdh-mpls-tp-psc-non-revertive Thread-Index: Ac6f+EjrGyQe8u4gS7CQwvcOMFAW0w== Date: Fri, 23 Aug 2013 13:17:01 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF642E609@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyuXSPt+7ZBPEggzvbLSxOLDvMYtG0Wcdi 09tvTBb/5s5htriz6wurxa2lK1kt/q64wmJxe0oTowOHR+uzvaweU35vZPXY+vkho0fLkbes HkuW/GTyuN50ld1j1vQ2No+Wc73sARxRXDYpqTmZZalF+nYJXBlnvrxiLFivW/Hs2C6WBsZt Kl2M7BwSAiYSrxS6GDmBLDGJC/fWs4HYQgJHGSU65lh2MXIB2csZJea96WMGSbAJaEgcu7OW ESQhIvCQUWLX6oXMIA6zwC9GiY2/j7J2MXJwCAs4SXQtSQMxRQScJfY01YL0igjoSRxZegNs DouAqsSRycvBbF4Bb4lv3xazgNiMQEd8P7WGCcRmFhCXuPVkPhPEcQISS/acZ4awRSVePv7H CmErSyx5sp8Fol5HYsHuT2wQtrbEsoWvoeYLSpyc+YRlAqPILCRjZyFpmYWkZRaSlgWMLKsY OUqLU8ty040MNzEC4+yYBJvjDsYFnywPMUpzsCiJ827QOxMoJJCeWJKanZpakFoUX1Sak1p8 iJGJg1OqgXFOQdM6PtGb3nPYNx1f8vep3gqW7Ey2ZarrazeHi9wv5I4L+C923ML24qq3CXr1 rN+87uZnLQ6+0+lYqp/+QNOAt7rQ66VX6Z173nJz2Rh6VvLf/Fp8xkHoQZFs9ZXsF6cr65Zs NUyMsymeOu1x/H3DwMPTt3x+qJCw7v67BTcbLTSCn73Z8EKJpTgj0VCLuag4EQA9b8TggQIA AA== Cc: "Ross Callon \(rcallon@juniper.net\)" Subject: Re: [mpls] MPLS-RT review of draft-cdh-mpls-tp-psc-non-revertive 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, 23 Aug 2013 13:17:12 -0000 Hi, I have been asked to review this draft, and to determine if it is in good = enough shape to be adopted by the MPLS working group. =09 Although requested to include the MPLS working group mailing list as a "Cc= ", I have included it as a "To" because of the questions I think need to be reso= lved either=20 by discussion in the working group, or decision by the working group chairs= . In general, I find this draft to be well written and may be ready for adop= tion by the=20 MPLS working group. There are two general questions about what may be acce= ptable to=20 the working group that should be resolved in some way prior to adoption of = this draft by=20 the working group. The questions are included as the first part of my comm= ents below. I have the following comments and/or questions: Major Comments/Questions: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D General questions for the MPLS working Group ---------------------------------------------------------- First Question -- The way that this draft is written is as a "delta" to RFC 6378. I personal= ly do not have any problems with this, assuming that a reader can correctly (re)construct the = resulting text as applied to RFC 6378. =20 However, over the long term, it is significant that this "delta" will not a= ctually be applied to RFC 6378 and may therefore lead to ambiguity and/or confusion if other s= ubsequent "deltas" are produced against the same RFC in the future. When/if this hap= pens, it is likely that the combination of multiple "delta" RFCs will force a re-write = of RFC 6378 to remove ambiguity and/or confusion. As an example, should a subsequent "update" to RFC 6378 suggest changes tha= t result in renumbering of the sections affected by this document, there will likely= be confusion=20 resulting from the order that a reader reads the set of documents, applying= the changes=20 in the order that they read them, as opposed to the order in which they wer= e written and=20 intended. Is the working group generally okay with taking this approach? (Alternatively, this draft could be re-written as a "bis" for RFC 6378, obs= oleting that RFC as opposed to updating it, or it could be re-written as a quasi-stand-alone= document -=20 rather than as a set of deltas to RFC 6378 - referring to RFC 6378 for prot= ection switching=20 behavior not explicitly described in this document.) Second Question -- Is it simpler to deal with this draft as a separate draft, or should it be = combined with the other related drafts that are also (at least primarily) intended to update = RFC 6378? At least with the two drafts I've been asked to review (adding signal degra= de, and making corrections to non-revertive mode), the modifications to RFC 6378 appear to= be distinct, non-overlapping, changes throughout the drafts. Where this is more difficu= lt to be certain of is in the changes to the state-machine tables - which are quite complex. At various points in the process, when reviewing the draft, the best approa= ch to verifying that there is no overlap or inconsistency is to actually merge all of the c= hanges and then review the result. If this turns out to be the case for every reviewer, th= en there is no benefit to having these as separate drafts. Should all of these related drafts be merged? Minor Comments and NITs: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D You need to add "updates RFC 6378 (when published)" to the header of the fi= rst page. I suggest omitting "contains the updates to" from the abstract, replacing i= t with "updates" and adding a second comma after "Linear Protection" (the text "MPLS Transpo= rt Profile ... Linear Protection" is a parenthetical description of RFC 6378). The same c= omment applies to the last paragraph in the Introduction section as well. In the third paragraph of the Introduction section, the second sentence is = an incomplete sentence and does not make sense as is. I believe the "period" after "Sect= ion 4.3.3.6" is supposed to be a comma. In the fourth paragraph, "missing" should be "omission" (possibly auto-corr= ect?). Abbreviations should be defined at least near where they are used - especia= lly in section=20 headers (see sections 1.1 and 1.2). Preferably they should be defined (or = expanded)=20 before they are used, but this is awkward in section headers (and messes up= the ToC). I suggest adding a new first paragraph in each section where this occurs, w= ith the express purpose of at least expanding these acronyms/abbreviations. The first paragraph in section 1.2 is awkwardly worded, creating an apparen= t inconsistency. Perhaps the authors would consider re-wording the first sentence of the par= agraph along=20 the lines of: "The MS-P and MS-W commands SHALL have the same priority, except in the cas= e where both are received simultaneously." It is worth noting that - possibly - this exception (and the text currently= in the paragraph that "justifies" it) could (and possibly should) be omitted. Because "simu= ltaneity" is not a verifiable occurrence, the scenario this text describes is not testable o= r necessarily=20 observable outside of the implementation. In section 4, "Manual Switch to Working" should be in quotes as it not clea= r how the text in the paragraph would otherwise be grouped to one not familiar with this c= ommand. That is, it is currently possible to read this as "... add 'Manual Switch' = to 'Working operator command' ..." - which makes little sense (forcing the reader to re-read thi= s until they've worked out the intended meaning). -- Eric Gray From yakov@juniper.net Fri Aug 23 09:40:18 2013 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 A5AB111E81E8 for ; Fri, 23 Aug 2013 09:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsItq9qzqEiD for ; Fri, 23 Aug 2013 09:40:12 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id 6045611E81D3 for ; Fri, 23 Aug 2013 09:40:12 -0700 (PDT) Received: from mail60-db8-R.bigfish.com (10.174.8.241) by DB8EHSOBE041.bigfish.com (10.174.4.104) with Microsoft SMTP Server id 14.1.225.22; Fri, 23 Aug 2013 16:40:11 +0000 Received: from mail60-db8 (localhost [127.0.0.1]) by mail60-db8-R.bigfish.com (Postfix) with ESMTP id 14650300378; Fri, 23 Aug 2013 16:40:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h1155h) Received-SPF: pass (mail60-db8: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=yakov@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail60-db8 (localhost.localdomain [127.0.0.1]) by mail60-db8 (MessageSwitch) id 1377276009511840_16291; Fri, 23 Aug 2013 16:40:09 +0000 (UTC) Received: from DB8EHSMHS011.bigfish.com (unknown [10.174.8.240]) by mail60-db8.bigfish.com (Postfix) with ESMTP id 6C04CB80040; Fri, 23 Aug 2013 16:40:09 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.54) by DB8EHSMHS011.bigfish.com (10.174.4.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 23 Aug 2013 16:40:08 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 23 Aug 2013 09:40:07 -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 r7NGe5L78442; Fri, 23 Aug 2013 09:40:06 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201308231640.r7NGe5L78442@magenta.juniper.net> To: Loa Andersson In-Reply-To: <521475A6.7080002@pi.nu> References: <521475A6.7080002@pi.nu> X-MH-In-Reply-To: Loa Andersson message dated "Wed, 21 Aug 2013 10:09:10 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20416.1377276005.1@juniper.net> Date: Fri, 23 Aug 2013 09:40:05 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org Subject: Re: [mpls] IPR poll on draft-rekhter-mpls-pim-sm-over-mldp 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, 23 Aug 2013 16:40:18 -0000 Loa, > Working Group, > > The authors of draft-rekhter-mpls-pim-sm-over-mldp has told the > working group chairs that the draft is ready to be adopted as a working > group document. > > Before we start the mpls-rt review and the poll for adoption we will do > an IPR poll. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to draft-rekhter-mpls-pim- > sm-over-mldp? Yes. > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). Yes. > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > documents will not advance to the next stage until a response > has been received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. Yakov. From sam.aldrin@gmail.com Fri Aug 23 13:37:41 2013 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 D4D8C21F9C4C for ; Fri, 23 Aug 2013 13:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6] 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 2Ud62wxlXLpV for ; Fri, 23 Aug 2013 13:37:41 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0A89C21F9A57 for ; Fri, 23 Aug 2013 13:37:40 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id lb1so1093570pab.40 for ; Fri, 23 Aug 2013 13:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=0Yd66c+vQ4YPoEJDUl5pdTT/JPpVGbn1wu1zc4+AcOk=; b=P/9a0fyJxpKYamkaATz6kbIEfsi8iMMnnA/s65qVs3OoGETc7v61nITwkouLyItTrU 734wh4icb0L6I/UDSYqDh5ZuGz/vCiqRo0nHoxBPsvnGK0vT5ztcaFUnZEM9lbzRahWD 3X6CAcbtg/H44YMky+jAI3sTkm3J2Met0NAMy9c0Ce7Z8WXM7nq1ywhJocJD0QnYNudG YItQPdM4cs+ek20Bm9v7a10MNkaFe2QuX4XoM6gv4F1xvhSIQOzFNn9xVqpu26gxspFD aw4Qjw8Xvo1YwtFL2WxAzk8mWh6lo+GE4qe1eYc3PTjmp7OwUWJLaa7eZW+z9Vrmi7NM 3rIA== X-Received: by 10.68.111.197 with SMTP id ik5mr1476113pbb.171.1377290257381; Fri, 23 Aug 2013 13:37:37 -0700 (PDT) Received: from [192.168.1.8] (c-98-248-237-85.hsd1.ca.comcast.net. [98.248.237.85]) by mx.google.com with ESMTPSA id zi1sm1654513pbb.28.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Aug 2013 13:37:36 -0700 (PDT) From: Sam Aldrin Content-Type: multipart/alternative; boundary="Apple-Mail=_0F369256-6E40-46A6-9B07-1E3A88BD1A79" Date: Fri, 23 Aug 2013 13:37:35 -0700 Message-Id: <78783902-650F-467A-83DF-192773E37923@gmail.com> To: draft-dj-mpls-tp-exer-psc@tools.ietf.org, "mpls-chairs@tools.ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: "" Subject: [mpls] MPLS-RT review on draft-dj-mpls-tp-exer-psc-01 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, 23 Aug 2013 20:37:42 -0000 --Apple-Mail=_0F369256-6E40-46A6-9B07-1E3A88BD1A79 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I have reviewed the draft as part of MPLS-RT review. Here are my = comments regarding the draft, followed by assessment comments. General comments: ------------------------- - I am confused by the wording within the draft. What is the primary = purpose? To modify the RFC6378 as it doesn't have the EXER mode? For ex: It says in sec 2.1 "The following text should be added in = Section 2.1 in [RFC6378] ". Who will be adding, how and where? This comment applies to whole draft. - As this draft is introducing a new mode(not fixing Errata), EXER, = which needed update to the RFC6378, the format chosen is not readable. = As in the earlier comment, this draft is adding text to the RFC in each = of the relevant sections. As a reader it is confusing at best. One will = not be able to understand all the details, unless this draft and RFC are = put side by side. My preference is to update the RFC with the updated = text and issue a new RFCbis or something. Sorry I do not know the IETF = process for updating existing RFC's. WG chairs or WG could provide = better guidance on this. Editorial comments: --------------------------- - I see 'RR' is added as Reverse Request. As the terminology of Remote = Request is already used, using different term is advisable.=20 - Sec 2.3 FPath? Not defined earlier. Could you add in the terminology = or reference to it? - In sec 2.1, PSC request fields, it says, values are set to the same in = both EXER and Reverse directions. Is it correct? Assessment comments: ---------------------------- a. Is the document coherent? > Draft is consistent and coherent, except for one section, identified = in the comment above. b. Is it useful? > Apparently it is already used in transport networks. As this is = identified as missing piece, I feel it is necessary to fill the gap. c. Is the document technically sound? > Yes. The document is written well and addresses all the sections of = RFC6378, to introduce this new mode. d. Is this document ready for WG adoption? > It depends on the answer to the questions in 'general comments'. = Having a separate document is confusing at best, from readability = perspective. As such, it is difficult to continue to be in the context, = while reading the draft, as it refers to missing pieces in the RFC. I = would like WG and chairs to make a call on how to have this documented = i.e. integrate the text into RFC6378 and issue a new version of the RFC? > IMO, as there are other documents which introduces modifications to = the same RFC as well, better to consolidate all the changes and issue a = new version of RFC. > Once the above are addressed, and if the decision is to retain as a = separate document, then a new version could be published with rest of = the comments addressed, prior to adoption. cheers -sam= --Apple-Mail=_0F369256-6E40-46A6-9B07-1E3A88BD1A79 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii RFC6378 as it doesn't have the EXER = mode?
For ex: It says in sec 2.1 "The following text should be added in = Section 2.1 in [RFC6378] ". Who will be adding, how and = where?
This comment applies to whole draft.
- As this draft is introducing a new mode(not fixing Errata), = EXER, which needed update to the RFC6378, the format chosen is not = readable. As in the earlier comment, this draft is adding text to the RFC in each of = the relevant sections. As a reader it is confusing at best. = One will not be able to understand all the details, unless this draft = and RFC are put side by side. My preference is to update the RFC with = the updated text and issue a new RFCbis or something. Sorry I do not = know the IETF process for updating existing RFC's. WG chairs or WG could = provide better guidance on this.
Editorial comments:
---------------------------

- I see 'RR' is added as Reverse Request. As the = terminology of Remote Request is already used, using different term is = advisable. 
- Sec 2.3  FPath? Not defined earlier. Could you add in = the terminology or reference to it?
- In sec 2.1, PSC request fields, it says, = values are set to the same in both EXER and Reverse directions. Is it = correct?

Assessment = comments:
----------------------------
a. Is the = document coherent?
> Draft is consistent and coherent, = except for one section, identified in the comment = above.

b. Is it useful?
> = Apparently it is already used in transport networks. As this is = identified as missing piece, I feel it is necessary to fill the = gap.

c. Is the document technically = sound?
> Yes. The document is written well and addresses = all the sections of RFC6378, to introduce this new = mode.

d. Is this document ready for WG = adoption?
> It depends on the answer to the questions in = 'general comments'. Having a separate document is confusing at best, = from readability perspective. As such, it is difficult to continue to be = in the context, while reading the draft, as it refers to missing pieces = in the RFC. I would like WG and chairs to make a call on how to have = this documented i.e. integrate the text into RFC6378 and issue a new = version of the RFC?
> IMO, as there are other documents = which introduces modifications to the same RFC as well, better to = consolidate all the changes and issue a new version of = RFC.
> Once the above are addressed, and if the decision is = to retain as a separate document, then a new version could be published = with rest of the comments addressed, prior to = adoption.

cheers
-sam
= --Apple-Mail=_0F369256-6E40-46A6-9B07-1E3A88BD1A79-- From aldrin.ietf@gmail.com Fri Aug 23 13:38:38 2013 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 5F3E411E8109 for ; Fri, 23 Aug 2013 13:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6] 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 t-1140Jf+48I for ; Fri, 23 Aug 2013 13:38:37 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9939B11E8108 for ; Fri, 23 Aug 2013 13:38:37 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa1so1094399pad.5 for ; Fri, 23 Aug 2013 13:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=lsayIhAgPKelNBPknRu2Q0fGqH5AlfAhfPVVOJSFS4Y=; b=Zzylk9O6hSQu5pCFFxn0ULlGofqxuxduHMxUGgWV0UCvVXSruHGzWTuDJWX22A3Hq+ 1I63FoPrkfNT+1VknU2KB1Omkrop5piNmxT+TP7NvLbwXywBYEkkn27Ips+hucSzvYbx zxu/H2KQQknHcKdBAaUnqE9ZQq+bLPr0ActLEE82PyNs/766YlqK7oFgEzDEsq97NSBl xizAHA4nx9iZFXDPHRlTzfPEVIOHODk0qT3EbwUC2cXU3m87MlPPv3SgL3aaz+4sEpFm s+BMS5O2IRxWK2xcYtJA/yxHpMlW/pu66L2802czSs63sXH6XTFpIAAIp53yW6ZWMReP pV1g== X-Received: by 10.68.96.130 with SMTP id ds2mr1585355pbb.99.1377290317275; Fri, 23 Aug 2013 13:38:37 -0700 (PDT) Received: from [192.168.1.8] (c-98-248-237-85.hsd1.ca.comcast.net. [98.248.237.85]) by mx.google.com with ESMTPSA id om2sm1655264pbc.30.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Aug 2013 13:38:36 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_68E95ED8-C854-4E1E-86F8-DD9EB559A85A" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Sam Aldrin In-Reply-To: <78783902-650F-467A-83DF-192773E37923@gmail.com> Date: Fri, 23 Aug 2013 13:38:34 -0700 Message-Id: <43CB7BBF-7839-4775-A55A-95FAC23088E7@gmail.com> References: <78783902-650F-467A-83DF-192773E37923@gmail.com> To: draft-dj-mpls-tp-exer-psc@tools.ietf.org, "mpls-chairs@tools.ietf.org" X-Mailer: Apple Mail (2.1508) Cc: "" Subject: [mpls] MPLS-RT review on draft-dj-mpls-tp-exer-psc-01 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, 23 Aug 2013 20:38:38 -0000 --Apple-Mail=_68E95ED8-C854-4E1E-86F8-DD9EB559A85A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I have reviewed the draft as part of MPLS-RT review. Here are my = comments regarding the draft, followed by assessment comments. General comments: ------------------------- - I am confused by the wording within the draft. What is the primary = purpose? To modify the RFC6378 as it doesn't have the EXER mode? For ex: It says in sec 2.1 "The following text should be added in = Section 2.1 in [RFC6378] ". Who will be adding, how and where? This comment applies to whole draft. - As this draft is introducing a new mode(not fixing Errata), EXER, = which needed update to the RFC6378, the format chosen is not readable. = As in the earlier comment, this draft is adding text to the RFC in each = of the relevant sections. As a reader it is confusing at best. One will = not be able to understand all the details, unless this draft and RFC are = put side by side. My preference is to update the RFC with the updated = text and issue a new RFCbis or something. Sorry I do not know the IETF = process for updating existing RFC's. WG chairs or WG could provide = better guidance on this. Editorial comments: --------------------------- - I see 'RR' is added as Reverse Request. As the terminology of Remote = Request is already used, using different term is advisable.=20 - Sec 2.3 FPath? Not defined earlier. Could you add in the terminology = or reference to it? - In sec 2.1, PSC request fields, it says, values are set to the same in = both EXER and Reverse directions. Is it correct? Assessment comments: ---------------------------- a. Is the document coherent? > Draft is consistent and coherent, except for one section, identified = in the comment above. b. Is it useful? > Apparently it is already used in transport networks. As this is = identified as missing piece, I feel it is necessary to fill the gap. c. Is the document technically sound? > Yes. The document is written well and addresses all the sections of = RFC6378, to introduce this new mode. d. Is this document ready for WG adoption? > It depends on the answer to the questions in 'general comments'. = Having a separate document is confusing at best, from readability = perspective. As such, it is difficult to continue to be in the context, = while reading the draft, as it refers to missing pieces in the RFC. I = would like WG and chairs to make a call on how to have this documented = i.e. integrate the text into RFC6378 and issue a new version of the RFC? > IMO, as there are other documents which introduces modifications to = the same RFC as well, better to consolidate all the changes and issue a = new version of RFC. > Once the above are addressed, and if the decision is to retain as a = separate document, then a new version could be published with rest of = the comments addressed, prior to adoption. cheers -sam= --Apple-Mail=_68E95ED8-C854-4E1E-86F8-DD9EB559A85A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii RFC6378 as it doesn't have the EXER = mode?
For ex: It says in sec 2.1 "The following text should be added in = Section 2.1 in [RFC6378] ". Who will be adding, how and = where?
This comment applies to whole draft.
- As this draft is introducing a new mode(not fixing Errata), = EXER, which needed update to the RFC6378, the format chosen is not = readable. As in the earlier comment, this draft is adding text to the RFC in each = of the relevant sections. As a reader it is confusing at best. = One will not be able to understand all the details, unless this draft = and RFC are put side by side. My preference is to update the RFC with = the updated text and issue a new RFCbis or something. Sorry I do not = know the IETF process for updating existing RFC's. WG chairs or WG could = provide better guidance on this.
Editorial comments:

- I see 'RR' is added as Reverse Request. = As the terminology of Remote Request is already used, using different = term is advisable. 
- Sec 2.3  FPath? Not defined = earlier. Could you add in the terminology or reference to = it?
- = In sec 2.1, PSC request fields, it says, values are set to the same in = both EXER and Reverse directions. Is it = correct?

Assessment = comments:
----------------------------
a. Is the = document coherent?
> Draft is consistent and coherent, = except for one section, identified in the comment = above.

b. Is it useful?
> = Apparently it is already used in transport networks. As this is = identified as missing piece, I feel it is necessary to fill the = gap.

c. Is the document technically = sound?
> Yes. The document is written well and addresses = all the sections of RFC6378, to introduce this new = mode.

d. Is this document ready for WG = adoption?
> It depends on the answer to the questions in = 'general comments'. Having a separate document is confusing at best, = from readability perspective. As such, it is difficult to continue to be = in the context, while reading the draft, as it refers to missing pieces = in the RFC. I would like WG and chairs to make a call on how to have = this documented i.e. integrate the text into RFC6378 and issue a new = version of the RFC?
> IMO, as there are other documents = which introduces modifications to the same RFC as well, better to = consolidate all the changes and issue a new version of = RFC.
> Once the above are addressed, and if the decision is = to retain as a separate document, then a new version could be published = with rest of the comments addressed, prior to = adoption.

cheers
-sam
= --Apple-Mail=_68E95ED8-C854-4E1E-86F8-DD9EB559A85A-- From mjork@juniper.net Fri Aug 23 13:46:08 2013 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 E660711E81C5 for ; Fri, 23 Aug 2013 13:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMoy-FikHc1a for ; Fri, 23 Aug 2013 13:45:58 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 78AA811E81F7 for ; Fri, 23 Aug 2013 13:45:53 -0700 (PDT) Received: from mail122-co9-R.bigfish.com (10.236.132.237) by CO9EHSOBE029.bigfish.com (10.236.130.92) with Microsoft SMTP Server id 14.1.225.22; Fri, 23 Aug 2013 20:45:52 +0000 Received: from mail122-co9 (localhost [127.0.0.1]) by mail122-co9-R.bigfish.com (Postfix) with ESMTP id 845BB680262; Fri, 23 Aug 2013 20:45:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zzc85fhzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h17326ah18c673h186068h8275bh8275dh1de097hz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail122-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=mjork@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(74876001)(69226001)(56776001)(53806001)(56816003)(4396001)(15202345003)(79102001)(81542001)(54316002)(74316001)(74662001)(47446002)(15975445006)(74502001)(81342001)(31966008)(76482001)(80976001)(49866001)(54356001)(74706001)(77096001)(66066001)(65816001)(77982001)(59766001)(74366001)(51856001)(19300405004)(76176001)(46102001)(63696002)(47736001)(80022001)(47976001)(50986001)(16236675002)(76796001)(19580395003)(81816001)(81686001)(76576001)(83322001)(76786001)(83072001)(33646001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB229; H:BLUPR05MB230.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail122-co9 (localhost.localdomain [127.0.0.1]) by mail122-co9 (MessageSwitch) id 1377290750157256_21157; Fri, 23 Aug 2013 20:45:50 +0000 (UTC) Received: from CO9EHSMHS005.bigfish.com (unknown [10.236.132.227]) by mail122-co9.bigfish.com (Postfix) with ESMTP id 22A6E8C0049; Fri, 23 Aug 2013 20:45:50 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS005.bigfish.com (10.236.130.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 23 Aug 2013 20:45:50 +0000 Received: from BLUPR05MB229.namprd05.prod.outlook.com (10.255.191.15) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.347.3; Fri, 23 Aug 2013 20:45:49 +0000 Received: from BLUPR05MB230.namprd05.prod.outlook.com (10.255.191.20) by BLUPR05MB229.namprd05.prod.outlook.com (10.255.191.15) with Microsoft SMTP Server (TLS) id 15.0.745.25; Fri, 23 Aug 2013 20:45:48 +0000 Received: from BLUPR05MB230.namprd05.prod.outlook.com ([169.254.12.226]) by BLUPR05MB230.namprd05.prod.outlook.com ([169.254.12.226]) with mapi id 15.00.0745.000; Fri, 23 Aug 2013 20:45:47 +0000 From: Markus Jork To: "draft-osborne-mpls-psc-updates@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" Thread-Topic: MPLS-RT review of draft-osborne-mpls-psc-updates-01 Thread-Index: Ac6gPu7ILLiAj/vaQ8+U1/hS8IvEmA== Date: Fri, 23 Aug 2013 20:45:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 094700CA91 Content-Type: multipart/alternative; boundary="_000_e0300fccfe064c679194dd3d34ecbc19BLUPR05MB230namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls@ietf.org" Subject: [mpls] MPLS-RT review of draft-osborne-mpls-psc-updates-01 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, 23 Aug 2013 20:46:08 -0000 --_000_e0300fccfe064c679194dd3d34ecbc19BLUPR05MB230namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been asked to provide feedback on draft-osborne-mpls-psc-updates-01 = as part of the mpls review team process. I believe the contents of the draft are useful and needed because this draf= t is clarifying and correcting RFC 6378. However, I do have a problem with the overall format of the draft: it is es= sentially a collection of diffs to selected sections of RFC 6378. That is not how the IETF generally updates RFCs and makes it quite cumberso= me to read and understand a protocol specification. So I would much rather see a new version of RFC 6378 that incorporates the = changes specified in this draft. -Markus --_000_e0300fccfe064c679194dd3d34ecbc19BLUPR05MB230namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have been asked to provide feedback on draft-osbor= ne-mpls-psc-updates-01 as part of the mpls review team process.<= /p>

 

I believe the contents of the draft are useful and n= eeded because this draft is clarifying and correcting RFC 6378.<= /p>

However, I do have a problem with the overall format= of the draft: it is essentially a collection of diffs to selected sections= of RFC 6378.

That is not how the IETF generally updates RFCs and = makes it quite cumbersome to read and understand a protocol specification.<= o:p>

 

So I would much rather see a new version of RFC 6378= that incorporates the changes specified in this draft.

 

-Markus

--_000_e0300fccfe064c679194dd3d34ecbc19BLUPR05MB230namprd05pro_-- From mjork@juniper.net Fri Aug 23 13:59:35 2013 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 751E911E8109 for ; Fri, 23 Aug 2013 13:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=-1.499, 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 hfdLZE+yky7K for ; Fri, 23 Aug 2013 13:59:29 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 19B5911E8108 for ; Fri, 23 Aug 2013 13:59:28 -0700 (PDT) Received: from mail196-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.22; Fri, 23 Aug 2013 20:59:27 +0000 Received: from mail196-va3 (localhost [127.0.0.1]) by mail196-va3-R.bigfish.com (Postfix) with ESMTP id 78A31C0070; Fri, 23 Aug 2013 20:59:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zzzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail196-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=mjork@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(69226001)(74876001)(53806001)(56776001)(4396001)(79102001)(74316001)(81542001)(74502001)(74662001)(76482001)(31966008)(47446002)(81342001)(54316002)(77096001)(54356001)(56816003)(74706001)(66066001)(80976001)(65816001)(59766001)(77982001)(74366001)(51856001)(76176001)(50986001)(47976001)(46102001)(80022001)(47736001)(49866001)(33646001)(63696002)(76576001)(76796001)(81686001)(83072001)(83322001)(76786001)(81816001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB231; H:BLUPR05MB230.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail196-va3 (localhost.localdomain [127.0.0.1]) by mail196-va3 (MessageSwitch) id 1377291565834144_32438; Fri, 23 Aug 2013 20:59:25 +0000 (UTC) Received: from VA3EHSMHS025.bigfish.com (unknown [10.7.14.235]) by mail196-va3.bigfish.com (Postfix) with ESMTP id C62EAA0040; Fri, 23 Aug 2013 20:59:25 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS025.bigfish.com (10.7.99.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 23 Aug 2013 20:59:25 +0000 Received: from BLUPR05MB231.namprd05.prod.outlook.com (10.255.191.24) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.347.3; Fri, 23 Aug 2013 20:59:25 +0000 Received: from BLUPR05MB230.namprd05.prod.outlook.com (10.255.191.20) by BLUPR05MB231.namprd05.prod.outlook.com (10.255.191.24) with Microsoft SMTP Server (TLS) id 15.0.745.25; Fri, 23 Aug 2013 20:59:24 +0000 Received: from BLUPR05MB230.namprd05.prod.outlook.com ([169.254.12.226]) by BLUPR05MB230.namprd05.prod.outlook.com ([169.254.12.226]) with mapi id 15.00.0745.000; Fri, 23 Aug 2013 20:59:24 +0000 From: Markus Jork To: "draft-dj-mpls-tp-exer-psc@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" Thread-Topic: MPLS-RT review of draft-dj-mpls-tp-exer-psc-01 Thread-Index: Ac6gQlOsm1bJI6J4RuuQ+Yh0gHGBqA== Date: Fri, 23 Aug 2013 20:59:23 +0000 Message-ID: <87ad2575a2cd4dc8baa7a534e0c67f1a@BLUPR05MB230.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 094700CA91 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls@ietf.org" Subject: [mpls] MPLS-RT review of draft-dj-mpls-tp-exer-psc-01 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, 23 Aug 2013 20:59:35 -0000 I have been asked to provide feedback on draft-dj-mpls-tp-exer-psc-01 as pa= rt of the mpls review team process. Just like draft-osborne-mpls-psc-updates-01, this is an update to RFC 6378 = specified as diffs to selected sections of the RFC. That is not how the IETF generally updates RFCs and makes it quite cumberso= me to read and understand a protocol specification. If adopting this and the other draft as WG documents, it would result in on= e base RFC 6378 with then at least two other RFCs that modify individual pa= ragraphs of the base RFC. This does not seem like a good way to write proto= col specifications. So I would much rather see a new version of RFC 6378 that incorporates the = changes specified in this draft. -Markus From aldrin.ietf@gmail.com Fri Aug 23 15:26:01 2013 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 E4EE111E8139 for ; Fri, 23 Aug 2013 15:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6] 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 LIbVl0ndXIuJ for ; Fri, 23 Aug 2013 15:26:01 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 566FD11E80EF for ; Fri, 23 Aug 2013 15:26:01 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id xb4so1179685pbc.36 for ; Fri, 23 Aug 2013 15:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=Dnlfa4Ay8GnjB1MBmPcpUom3KMCOcndk60qP6+QPldY=; b=TwH2FY4tJSuSOhrYBSC3VtWysdkxUYm2bhuSAwU3/BZ66olwPf1KQzpYi6uxCp1eNh zMvYeZizTsI1RydZ0XCKrOk6Ac99ZG3PN8rBbwbOS1aTRm0LBF55FP2IvO/dX10Ur183 xq06CTVzRzYo1SfsOb0JCVMlk1JUeQPl+taCKzPMPSgrBwgu6TtIa98qYaVyzIgkbjjV gimPBnL0B678M5mq8I5cr5VVVFH6gAgvz7YJTEHQ4K1QSB6g8TAByzZJLuNjNs/Tso4s WzmOh8WJegok8vVIPPXJvqnQbQJmugK7W382lR2rHby4HmUiCbzBVefNLmfVe52B3Qs2 fJ9g== X-Received: by 10.66.161.99 with SMTP id xr3mr1097874pab.172.1377296759076; Fri, 23 Aug 2013 15:25:59 -0700 (PDT) Received: from [192.168.1.8] (c-98-248-237-85.hsd1.ca.comcast.net. [98.248.237.85]) by mx.google.com with ESMTPSA id pu5sm3343210pac.21.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Aug 2013 15:25:57 -0700 (PDT) From: Sam Aldrin Content-Type: multipart/alternative; boundary="Apple-Mail=_F8D6301B-63B9-4A4A-9236-4A8C2458EB8E" Date: Fri, 23 Aug 2013 15:25:55 -0700 Message-Id: <79E5D3D3-6AB4-4CE7-97A9-6D324C053490@gmail.com> To: Jeong-dong Ryoo , "Huub van Helvoort (huub.van.helvoort@huawei.com)" , Alessandro D Alessandro , mpls@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: Ross Callon , "" , "mpls-chairs@tools.ietf.org" Subject: [mpls] MPLS-RT review of draft-rhd-mpls-tp-psc-sd 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, 23 Aug 2013 22:26:02 -0000 --Apple-Mail=_F8D6301B-63B9-4A4A-9236-4A8C2458EB8E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I have done a review of draft-rhd-mpls-tp-psc-sd as part of MPLS RT = process. Please find my comments inline.=20 -sam General comments: ------------------------- - Have similar comment like other drafts. This draft contains the diff = off what is not present in the existing RFC. Is the intention to create = a separate RFC in addition to existing RFC6378, by correcting the = priority scheme? Nitpicks/Editorial: ----------- - Clarity question, Is it mandated to use PSC only as communication = medium or there could be other means, like OAM? - Sec 1.2, Could you please add clarity to the sentence The priority level of Clear SF defined in [RFC6378] can cause traffic disruption when a node that has experienced local signal fails on both working and protection paths is recovering from these failures. - In Sec 4.2 - When you say SHALL, is it interpreted as MUST or SHOULD? Assessment comments: ----------------------------- - Is the document coherent? > Yes, it is coherent and consistent - Is the document useful? > Yes. Correcting the priority as identified in RFC6378 is needed - Is the document technically sound? - Yes - Is is ready for WG adoption - Not in its correct form. This document is mostly identifying changes = to RFC. My preference is to combine all the changes to RFC6378 and = re-issue a new RFCbis. Otherwise, this will be very confusing to refer = two or more documents every time to make sense of what is the correct = behavior for PSC in linear protection.=20 - If that is (creating new RFC bis) something not possible(hope there is = a real strong reason for this), then the document should be edited to be = more stand alone document. i.e. remove add/replace to more assertive = sections for readers to understand without having to go back to RFC, = every time. --Apple-Mail=_F8D6301B-63B9-4A4A-9236-4A8C2458EB8E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii  Clarity question, Is  it mandated to use = PSC only as communication medium or there could be other means, like = OAM?

- Sec 1.2, Could you please add clarity to = the sentence
The priority level of Clear =
SF defined in [RFC6378] can cause traffic
   disruption when a node that has experienced local signal fails on
   both working and protection paths is recovering from these =
failures.

- In Sec 4.2 - When you say = SHALL, is it interpreted as MUST or = SHOULD?

Assessment = comments:
-----------------------------
- Is the = document coherent?
> Yes, it is coherent and = consistent

- Is the document = useful?
> Yes. Correcting the priority as identified in = RFC6378 is needed

- Is the document technically = sound?
- Yes

- Is is ready for WG = adoption
- Not in its correct form. This document is mostly = identifying changes to RFC. My preference is to combine all the changes = to RFC6378 and re-issue a new RFCbis.  Otherwise, this will be very = confusing to refer two or more documents every time to make sense of = what is the correct behavior for PSC in linear = protection. 
- If that is (creating new RFC bis) = something not possible(hope there is a real strong reason for this), = then the document should be edited to be more stand alone document. i.e. = remove add/replace to more assertive sections for readers to understand = without having to go back to RFC, every = time.


= --Apple-Mail=_F8D6301B-63B9-4A4A-9236-4A8C2458EB8E-- From huubatwork@gmail.com Sat Aug 24 01:11:48 2013 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 3AD7F21F9D75 for ; Sat, 24 Aug 2013 01:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=-0.546, 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 HS7dzghzDkcw for ; Sat, 24 Aug 2013 01:11:47 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 96D6221F8956 for ; Sat, 24 Aug 2013 01:11:47 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id k13so1238048wgh.1 for ; Sat, 24 Aug 2013 01:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=rpa1/gQMerioBmB5C/wra6q6krdKSag4B3+T8UG/L3A=; b=Vnvzr45YYFQeX6/WGTXwINyV7PM2azmKSu/oCzTH1GV2rtqOx3G5dGCtj6p/GEaaro wr0Oz++4jWtoRYcg0RWIbkmtfm2phi2auxrnaewgts2vl1ldH0FEFSGjLd9Yok7o52nF vEj4CVsytmmNatJK5nx4fpQLiuZHCILKYPy8Rhc006+8w33M+cyP4GkShfWj6iahOrGh 6p17VogdUNFkhdjLEg+72XvruT/IsgKPjwWapW+5qKCA+mlMp9yAYj1LW6S7t8fEBAbF YO4yPZoJWvhAIsGGOHXTLjl4pmY4knZu/K9dICgHiTYLVpldCaQsnH/2hMgWSF+6hAv5 MUgw== X-Received: by 10.195.12.170 with SMTP id er10mr2723863wjd.5.1377331905584; Sat, 24 Aug 2013 01:11:45 -0700 (PDT) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id r6sm2304283wiw.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 Aug 2013 01:11:44 -0700 (PDT) Message-ID: <52186AC2.8030804@gmail.com> Date: Sat, 24 Aug 2013 10:11:46 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 References: <79E5D3D3-6AB4-4CE7-97A9-6D324C053490@gmail.com> In-Reply-To: <79E5D3D3-6AB4-4CE7-97A9-6D324C053490@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, "mpls-chairs@tools.ietf.org" Subject: [mpls] MPLS-RT review of PSC related drafts 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: Sat, 24 Aug 2013 08:11:48 -0000 All reviewers of the drafts, draft-rhd-mpls-tp-psc-priority draft-rhd-mpls-tp-psc-sd draft-dj-mpls-tp-exer-psc raft-cdh-mpls-tp-psc-non-revertive draft-osborne-mpls-psc-updates and anybody else who wants to contribute: I have noticed your concern regarding the way each of these drafts should be used to address RFC6378. I would like to point you this presentation in the IETF87 meeting which contains a proposed forward path: http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt In this thread the discussion for supporting the options mentioned in the slides has already started: http://www.ietf.org/mail-archive/web/mpls/current/msg10400.html Best regards, Huub. From loa@pi.nu Sat Aug 24 04:30:33 2013 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 C3C2F21F9D89 for ; Sat, 24 Aug 2013 04:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 TzOaKrYGcxEl for ; Sat, 24 Aug 2013 04:30:29 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id A5BC621F9CF1 for ; Sat, 24 Aug 2013 04:30:21 -0700 (PDT) Received: from [192.168.5.58] (81-229-83-119-no65.business.telia.com [81.229.83.119]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 192391802038; Sat, 24 Aug 2013 13:30:20 +0200 (CEST) Message-ID: <5218994D.9020004@pi.nu> Date: Sat, 24 Aug 2013 13:30:21 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "mpls-chairs@tools.ietf.org" References: <20130824102337.20242.29755.idtracker@ietfa.amsl.com> In-Reply-To: <20130824102337.20242.29755.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130824102337.20242.29755.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , draft-lcap-mpls-moving-iana-registries@tools.ietf.org Subject: [mpls] Ready to become a working groups document: I-D Action: draft-lcap-mpls-moving-iana-registries-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: Sat, 24 Aug 2013 11:30:33 -0000 Working Group Chairs, The authors of draft-lcap-mpls-moving-iana-registries believe it is time toi make this document an mpls working group document. /Loa -------- Original Message -------- Subject: I-D Action: draft-lcap-mpls-moving-iana-registries-02.txt Date: Sat, 24 Aug 2013 03:23:37 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Moving Generic Associated Channel (G-ACh) IANA registries to a new registry Author(s) : Loa Andersson Carlos Pignataro Filename : draft-lcap-mpls-moving-iana-registries-02.txt Pages : 7 Date : 2013-08-24 Abstract: RFC 5586 generalized the applicability of the pseudowire Associated Channel Header (PW-ACH) into the Generic Associated Channel G-Ach. However, registries and allocations of G-ACh parameters had been distributed throughout different, sometimes unrelated, registries. This document coalesces these into a new "Generic Associated Channel (G-ACh)" registry under the "Multiprotocol Label Switching Architecture (MPLS)" heading. This is an update to RFC 5586 [RFC5586]. This document also updates RFC 6374, RFC 6428, RFC 6378, RFC 6427, RFC-ietf-mpls-gach-adv-08, and RFC-ietf-mpls-tp-ethernet-addressing-08. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-lcap-mpls-moving-iana-registries There's also a htmlized version available at: http://tools.ietf.org/html/draft-lcap-mpls-moving-iana-registries-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-lcap-mpls-moving-iana-registries-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 From cts@etri.re.kr Sun Aug 25 19:47:07 2013 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 808EC21E804C for ; Sun, 25 Aug 2013 19:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.346 X-Spam-Level: X-Spam-Status: No, score=-97.346 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, 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 LBixYX6i3itT for ; Sun, 25 Aug 2013 19:47:01 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id B50ED11E8138 for ; Sun, 25 Aug 2013 19:46:59 -0700 (PDT) Received: from SMTP2.etri.info (129.254.28.72) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 26 Aug 2013 11:46:48 +0900 Received: from SMTP4.etri.info ([169.254.3.68]) by SMTP2.etri.info ([129.254.28.72]) with mapi id 14.01.0355.002; Mon, 26 Aug 2013 11:46:49 +0900 From: =?ks_c_5601-1987?B?waTFwr3E?= To: Mach Chen , "draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org" Thread-Topic: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents Thread-Index: AQHOlPghtHYllm9ZlUWJChJo0dWyb5mgbNEAgAZzA2A= Date: Mon, 26 Aug 2013 02:46:49 +0000 Message-ID: References: <5204D9DE.6060405@pi.nu> In-Reply-To: Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.73.69] Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents 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, 26 Aug 2013 02:47:07 -0000 SGkgTWFjaCwNCg0KVGhhbmsgeW91IGZvciByZXZpZXdpbmcgZHJhZnQtY2RoLW1wbHMtcHNjLW5v bi1yZXZlcnRpdmUtMDAuDQoNCkFzIG9uZSBvZiBhdXRob3JzIG9mIHRoZSBkcmFmdCwgSSBhbnN3 ZXJlZCB5b3VyIGNvbW1lbnRzLg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkJlc3QgcmVnYXJkcywN ClRhZXNpaw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBtcGxzLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBN YWNoIENoZW4NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjIsIDIwMTMgNjowNiBQTQ0KVG86IGRy YWZ0LWNkaC1tcGxzLXRwLXBzYy1ub24tcmV2ZXJ0aXZlQHRvb2xzLmlldGYub3JnDQpDYzogbXBs c0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFttcGxzXSBN UExTLVJUIHJldmlldyBvbiBkcmFmdC1jZGgtbXBscy10cC1wc2Mtbm9uLXJldmVydGl2ZS0wMC8v UkU6IE1QTFMtUlQgcmV2aWV3IG9mIG1wbHMgcHNjIGRvY3VtZW50cw0KDQoNCkhpLA0KDQpJIGhh dmUgZG9uZSBteSBNUExTLVJUIHJldmlldyBvbiBkcmFmdC1jZGgtbXBscy10cC1wc2Mtbm9uLXJl dmVydGl2ZS0wMCwgaGVyZSBhcmUgbXkgY29tbWVudHM6DQoNCkkgdGhpbmsgdGhhdCBtb2RpZmlj YXRpb24gdG8gTm9uLXJldmVydGl2ZSBtb2RlLCBhZGRpbmcgTVMtVyBhbmQgcmVuYW1pbmcgTVMg dG8gTVMtRiBhcmUgdmFsaWQgcG9pbnRzLiBCdXQgSSBub3Qgc3VyZSB3aGV0aGVyIHRoZXJlIGlz IGEgbmVlZCB0byByZXBsYWNlICIgUHJvdGVjdGluZyBhZG1pbmlzdHJhdGl2ZSBzdGF0ZSIgdG8g IlN3aXRjaGluZyBhZG1pbmlzdHJhdGl2ZSBzdGF0ZSIuDQpbVGFlc2lrXSBJIGd1ZXNzICJNUy1X IiBhcyAiTVMtUCIgYmVjYXVzZSB0aGUgZHJhZnQgZG9lcyBub3QgdXNlIHRoZSB0ZXJtICJNUy1G Ii4gDQpbVGFlc2lrXSBBY2NvcmRpbmcgdG8gU2VjIDMuNiBvZiBSRkM2Mzc4LCChsFByb3RlY3Rp bmcgYWRtaW5pc3RyYXRpdmUgc3RhdGWhsSBtZWFucyB0aGF0IHRoZSBvcGVyYXRvciBoYXMgaXNz dWVkIGEgY29tbWFuZCBzd2l0Y2hpbmcgdGhlIHVzZXIgdHJhZmZpYyB0byB0aGUgobBwcm90ZWN0 aW9uobEgcGF0aC4gU28sIHRoZSBjdXJyZW50IGRlZmluaXRpb24gY2Fubm90IGNvdmVyIHRoZSBj YXNlIHdoZXJlIHRoZSBvcGVyYXRvciBoYXMgaXNzdWVkIGEgTVMtVyBjb21tYW5kIHJlcXVlc3Rp bmcgdG8gc3dpdGNoIHRoZSB1c2VyIHRyYWZmaWMgdG8gdGhlIKGwd29ya2luZ6GxIHBhdGguIEJ5 IHJlcGxhY2luZyChsFByb3RlY3RpbmcgYWRtaW5pc3RyYXRpdmUgc3RhdGWhsSBieSChsFN3aXRj aGluZyBhZG1pbmlzdHJhdGl2ZSBzdGF0ZaGxLCBpdCBjYW4gY292ZXIgYm90aCBjYXNlcy4NCg0K UmVhZCB0aHJvdWdoIHRoZSBkcmFmdCwgaXQgZ2l2ZXMgbWUgdGhlIGZlZWxpbmcgdGhhdCB0aGUg ZHJhZnQganVzdCBsaXN0cyBhIHNldCBvZiBlcnJhdGFzLCBJIGFtIG5vdCBzdXJlIHRoYXQgdGhp cyBpcyB0aGUgcmlnaHQgd2F5IHRvIHByb2dyZXNzIHRoZSBkcmFmdCBhcyBpdCBiZS4gSWYgdGhl IFdHIGhhdmUgdGhlIGNvbnNlbnN1cyBvbiB0aGUgY29udGVudCBvZiB0aGUgZHJhZnQsIElNSE8s IGl0J3MgYmV0dGVyIHRvIGRvIGEgYmlzIHRvIFJGQzYzNzguICANCltUYWVzaWtdIEkgdGhpbmsg dGhhdCB0aGlzIGNvbW1lbnQgaXMgbm90IGZvciB0aGUgYXV0aG9ycyBvZiB0aGUgZHJhZnQuDQoN Ck1pbm9yIGNvbW1lbnQ6DQpJdCdzIGJldHRlciB0byBleHBhbmQgdGhlIGFjcm9ueW0gd2hlbiBm aXJzdCB1c2UsIGZvciBleGFtcGxlIHRoZSBNUy1GIGFuZCBNUy1XLCBJIGhhdmUgdG8gZ3Vlc3Mg dGhlIG1lYW5pbmcgb2YgdW50aWwgSSBzZWUgdGhlIEFjcm9ueW1zIHNlY3Rpb24uIA0KW1RhZXNp a10gTVMtVyBpcyBhbHJlYWR5IGV4cGFuZGVkIGluIGJvdGggQWJzdHJhY3QgYW5kIFNlY3Rpb24g MSBvZiB0aGUgZHJhZnQuIEZvciBNUy1QLCBpdCBjYW4gYmUgZXhwYW5kZWQgaW4gYm90aCBBYnN0 cmFjdCBhbmQgU2VjdGlvbiAxIGluIHRoZSBuZXh0IHJldmlzaW9uIG9mIHRoZSBkcmFmdC4gQnV0 LCBiZWZvcmUgZG9pbmcgdGhpcywgd2UgbmVlZCB0byBhZ3JlZSBvbiB0aGUgcmVuYW1pbmcgYmVj YXVzZSB0aGVyZSBpcyBhbm90aGVyIHJldmlldydzIGNvbW1lbnQgbm90IHN1cHBvcnRpbmcgdGhp cyByZW5hbWluZy4NCg0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogTG9hIEFuZGVyc3NvbiBbbWFpbHRvOmxvYUBwaS5udV0NCj4g U2VudDogRnJpZGF5LCBBdWd1c3QgMDksIDIwMTMgODowMSBQTQ0KPiBUbzogRXJpYyBPc2Jvcm5l IChlb3Nib3JuZSk7IEVyaWMgR3JheTsga2VuamkuZnVqaWhpcmEuZGpAaGl0YWNoaS5jb207IA0K PiBZYWFjb3YgV2VpbmdhcnRlbjsgU2FtIEFsZHJpbjsgTWFjaCBDaGVuOyBLYW1yYW4gUmF6YSAo c2tyYXphKTsgDQo+IEhlbmRlcmlja3gsIFdpbSAoV2ltKTsgdGhvbWFzLm1vcmluQG9yYW5nZS5j b207IG1qb3JrQGp1bmlwZXIubmV0DQo+IENjOiBkcmFmdC1vc2Jvcm5lLW1wbHMtcHNjLXVwZGF0 ZXNAdG9vbHMuaWV0Zi5vcmc7DQo+IGRyYWZ0LWRqLW1wbHMtdHAtZXhlci1wc2NAdG9vbHMuaWV0 Zi5vcmc7DQo+IGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1zZEB0b29scy5pZXRmLm9yZzsNCj4gZHJh ZnQtY2RoLW1wbHMtdHAtcHNjLW5vbi1yZXZlcnRpdmVAdG9vbHMuaWV0Zi5vcmc7DQo+IGRyYWZ0 LXJoZC1tcGxzLXRwLXBzYy1wcmlvcml0eUB0b29scy5pZXRmLm9yZzsgDQo+IG1wbHMtY2hhaXJz QHRvb2xzLmlldGYub3JnOyBWSUdPVVJFVVgsIE1BUlRJTiAoTUFSVElOKQ0KPiBTdWJqZWN0OiBN UExTLVJUIHJldmlldyBvZiBtcGxzIHBzYyBkb2N1bWVudHMNCj4gDQo+IEVyaWMsIEVyaWMsIEtl bmppLCBZYWNvb3YsIFNhbSwgTWFjaCwgS2FtcmFuLCBXaW0sIFRob21hcyBhbmQgTWFya3VzLA0K PiANCj4gWW91IGJlZW4gc2VsZWN0ZWQgYXMgTVBMUy1SVCByZXZpZXdlcnMgZm9yIGEgc2V0IG9m IHBzYyBkb2N1bWVudCB0aGF0IA0KPiB3ZSB3aWxsIHN0YXJ0IHByb2dyZXNzIHRocm91Z2ggdGhl IG1wbHMgd29ya2luZyBncm91cC4NCj4gDQo+IFRoZSBub3JtYWwgcnVsZXMgYW5kIHF1ZXN0aW9u IGZvciBhbiBNUExTLVJUIGFwcGx5Og0KPiANCj4gLS0tLS0tLS0tLSBxdW90ZSBmcm9tIGEgc3Rh bmRhcmQgbWFpbCBpbml0aWF0aW5nIE1QTFMtUlQgcmV2aWV3IA0KPiAtLS0tLS0tDQo+IA0KPiBO b3RlIHRvIGF1dGhvcnM6IFlvdSBoYXZlIGJlZW4gQ0MnZCBvbiB0aGlzIGVtYWlsIHNvIHRoYXQg eW91IGNhbiBrbm93IA0KPiB0aGF0IHRoaXMgcmV2aWV3IGlzIGdvaW5nIG9uLiBIb3dldmVyLCBw bGVhc2UgZG8gbm90IHJldmlldyB5b3VyIG93biANCj4gZG9jdW1lbnQuDQo+IA0KPiBSZXZpZXdz IHNob3VsZCBjb21tZW50IG9uIHdoZXRoZXIgdGhlIGRvY3VtZW50IGlzIGNvaGVyZW50LCBpcyBp dCANCj4gdXNlZnVsIChpZSwgaXMgaXQgbGlrZWx5IHRvIGJlIGFjdHVhbGx5IHVzZWZ1bCBpbiBv cGVyYXRpb25hbCANCj4gbmV0d29ya3MpLCBhbmQgaXMgdGhlIGRvY3VtZW50IHRlY2huaWNhbGx5 IHNvdW5kPyAgV2UgYXJlIGludGVyZXN0ZWQgDQo+IGluIGtub3dpbmcgd2hldGhlciB0aGUgZG9j dW1lbnQgaXMgcmVhZHkgdG8gYmUgY29uc2lkZXJlZCBmb3IgV0cgDQo+IGFkb3B0aW9uIChpZSwg aXQgZG9lc24ndCBoYXZlIHRvIGJlIHBlcmZlY3QgYXQgdGhpcyBwb2ludCwgYnV0IHNob3VsZCAN Cj4gYmUgYSBnb29kIHN0YXJ0KS4NCj4gDQo+IFJldmlld3Mgc2hvdWxkIGJlIHNlbnQgdG8gdGhl IGRvY3VtZW50IGF1dGhvcnMsIFdHIGNvLWNoYWlycyBhbmQgV0cgDQo+IHNlY3JldGFyeSwgYW5k IENDJ2QgdG8gdGhlIE1QTFMgV0cgZW1haWwgbGlzdC4gSWYgbmVjZXNzYXJ5LCBjb21tZW50cyAN Cj4gbWF5IGJlIHNlbnQgcHJpdmF0ZWx5IHRvIG9ubHkgdGhlIFdHIGNoYWlycy4NCj4gDQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0gZW5kIHF1b3RlIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gDQo+IFRoZSBvbmx5IGRpZmZlcmVuY2UgaXMgdGhhdCB3ZSB0YWtlIG9uIG1vcmUgdGhhbiBv bmUgZG9jdW1lbnQgYW5kIHRoYXQgDQo+IHRoZXJlIGFyZSBzdWNoIGludGVyLWRlcGVuZGVuY2ll cyB0aGF0IHdlIHdhbnQgdG8gY29vcmRpbmF0ZSBob3cgdGhleSANCj4gYXJlIHByb2dyZXNzZWQg dGhyb3VnaCBJRVRGLg0KPiANCj4gUGxlYXNlIHJlc3BvbmQgKGF0IGxlYXN0KSB0byB0aGUgd2cg Y2hhaXJzIGFuZCBNYXJ0aW4gdGhhdCB5b3UgYXJlIA0KPiB3aWxsaW5nL3VuLXdpbGxpbmcgdG8g dW5kZXJ0YWtlIHRoZSByZXZpZXdzLg0KPiANCj4gU2luY2Ugd2UgYXJlIHN0YXJ0aW5nIE1QTFMt UlQgcmV2aWV3cyBvZiA1IGRvY3VtZW50cywgd2l0aCA0IHJldmlld2VycyANCj4gZm9yIGVhY2gg ZG9jdW1lbnQgYW5kIGVhY2ggcmV2aWV3ZXIgaGF2ZSB0d28gZG9jdW1lbnRzLCB5b3UnbGwgbmVl ZCB0byANCj4gc2VuZCB0aGUgcmV2aWV3IHdpdGggdGhlIGRyYWZ0IG5hbWUgaW4gdGhlIHN1Ympl Y3QgbGluZSwgaS5lLiBkbyBub3QgDQo+IHJlc3BvbmQgdG8gdGhpcyBtYWlsIHdpdGggeW91ciBy ZXZpZXcgY29tbWVudHMuDQo+IA0KPiBUaGVyZSBpcyBhbHNvIGEgIlBTQyBtb2RlcyIgZG9jdW1l bnQgaW4gdGhlIHBpcGUsIGN1cnJlbnRseSBpdCBpcyBvdXIgDQo+IG9waW5pb24gdGhhdCB0aGlz IGRvY3VtZW50IGlzIG5lY2Vzc2FyeSB3aGVuIHdlIHdpbGwgc3RhcnQgdGhlIHdnbGMncyANCj4g YnV0IGlzIG5vdCBuZWNlc3NhcnkgdG8gbWFrZSB0aGUgb3RoZXIgZHJhZnRzIHdnIGRvY3VtZW50 cy4NCj4gDQo+IENhbiB5b3UgcGxlYXNlIGZpbmlzaCB5b3VyIHJldmlld3MgZW9iIEF1Z3VzdCAy MywgMjAxMy4NCj4gDQo+IEhlcmUgaXMgdGhlIGxpc3Qgb2YgcmV2aWV3ZXJzIHBlciBkb2N1bWVu dDoNCj4gDQo+IGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1wcmlvcml0eQ0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gbWFjaCBjaGVuDQo+IHRob21hcyBtb3Jpbg0KPiB5YWNvb3Yg d2VpbmdhcnRlbg0KPiBXaW0gSGVuZGVyaWNreA0KPiANCj4gZHJhZnQtY2RoLW1wbHMtdHAtcHNj LW5vbi1yZXZlcnRpdmUNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g bWFjaCBjaGVuDQo+IGVyaWMgb3Nib3JuZQ0KPiBlcmljIGdyYXkNCj4geWFjb292IHdlaW5nYXJ0 ZW4NCj4gDQo+IGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1zZA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gZXJpYyBvc2Jvcm5lDQo+IHNhbSBhbGRyaW4NCj4gZXJpYyBncmF5DQo+IGthbXJh biByYXphDQo+IA0KPiBkcmFmdC1kai1tcGxzLXRwLWV4ZXItcHNjDQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gc2FtIGFsZHJpbg0KPiBtYXJrdXMgam9yaw0KPiBrYW1yYW4gcmF6YQ0K PiBrZW5qaSBmdWhpcmENCj4gDQo+IGRyYWZ0LW9zYm9ybmUtbXBscy1wc2MtdXBkYXRlcw0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gbWFya3VzIGpvcmsNCj4gdGhvbWFzIG1v cmluDQo+IGtlbmppIGZ1aGlyYQ0KPiBXaW0gSGVuZGVyaWNreA0KPiANCj4gDQo+IEF1dGhvcnMs DQo+IA0KPiBQbGVhc2UgZG8gbm90IHVwZGF0ZSB0aGUgZG9jdW1lbnRzIGR1cmluZyB0aGUgcmV2 aWV3IHBlcmlvZCwgd2Ugd2lsbCANCj4gdGVsbCB5b3Ugd2hlbiB0aGUgcmV2aWV3IHBlcmlvZCBo YXMgZW5kZWQuDQo+IA0KPiBXaGVuIHdlIGNsb3NlIHRoZSByZXZpZXcgcGVyaW9kIHlvdSdsbCBu ZWVkIHRvIGFkZHJlc3MgdGhlIGNvbW1lbnRzIA0KPiBmcm9tIHRoZSByZXZpZXdlcnMgYW5kIGNv bW11bmljYXRlIHdpdGggdGhlbSAocHJlZmVyYWJseSBvbiB0aGUgbXBscyANCj4gd2cgbWFpbGlu ZyBsaXN0KSB0byBtYWtlIHN1cmUgdGhhdCB0aGV5IGFyZSBjb21mb3J0YWJsZSB3aXRoIGhvdyB0 aGUgDQo+IGNvbW1lbnRzIGhhcyBiZWVuIGFkZHJlc3NlZC4NCj4gDQo+IA0KPiAvTG9hDQo+IGZv ciB0aGUgbXBscyB3ZyBjaGFpcnMNCj4gDQo+IC0tDQo+IA0KPiANCj4gTG9hIEFuZGVyc3NvbiAg ICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb20NCj4gU2Vu aW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnUNCj4gSHVh d2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0 DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBt YWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXBscw0K From mjork@juniper.net Mon Aug 26 08:07:21 2013 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 7238B21F9B57 for ; Mon, 26 Aug 2013 08:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-1.250, 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 8Vul28YBE3QZ for ; Mon, 26 Aug 2013 08:07:16 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0253.outbound.messaging.microsoft.com [213.199.154.253]) by ietfa.amsl.com (Postfix) with ESMTP id C530721F9D2B for ; Mon, 26 Aug 2013 08:07:11 -0700 (PDT) Received: from mail223-DB9-R.bigfish.com (10.174.16.239) by DB9EHSOBE027.bigfish.com (10.174.14.90) with Microsoft SMTP Server id 14.1.225.22; Mon, 26 Aug 2013 15:07:10 +0000 Received: from mail223-DB9 (localhost [127.0.0.1]) by mail223-DB9-R.bigfish.com (Postfix) with ESMTP id BB6BD2C0135; Mon, 26 Aug 2013 15:07:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371I146fI542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hz8dhz1de098h1033IL17326ah186068h8275dh1de097hz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail223-DB9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=mjork@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(52314003)(199002)(13464003)(377454003)(51704005)(189002)(74876001)(69226001)(53806001)(54316002)(81542001)(4396001)(47736001)(15202345003)(79102001)(74316001)(81342001)(47446002)(31966008)(74662001)(74502001)(76482001)(74706001)(56816003)(1411001)(54356001)(56776001)(77096001)(80976001)(66066001)(65816001)(59766001)(77982001)(74366001)(51856001)(46102001)(63696002)(47976001)(80022001)(49866001)(83072001)(50986001)(76576001)(19580405001)(19580395003)(76786001)(76796001)(33646001)(83322001)(81816001)(81686001)(15975445006)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB230; H:BLUPR05MB230.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail223-DB9 (localhost.localdomain [127.0.0.1]) by mail223-DB9 (MessageSwitch) id 1377529628483603_1247; Mon, 26 Aug 2013 15:07:08 +0000 (UTC) Received: from DB9EHSMHS032.bigfish.com (unknown [10.174.16.235]) by mail223-DB9.bigfish.com (Postfix) with ESMTP id 69124100045; Mon, 26 Aug 2013 15:07:08 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS032.bigfish.com (10.174.14.42) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 26 Aug 2013 15:07:05 +0000 Received: from BLUPR05MB230.namprd05.prod.outlook.com (10.255.191.20) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.347.3; Mon, 26 Aug 2013 15:07:05 +0000 Received: from BLUPR05MB230.namprd05.prod.outlook.com (10.255.191.20) by BLUPR05MB230.namprd05.prod.outlook.com (10.255.191.20) with Microsoft SMTP Server (TLS) id 15.0.745.25; Mon, 26 Aug 2013 15:07:03 +0000 Received: from BLUPR05MB230.namprd05.prod.outlook.com ([169.254.12.226]) by BLUPR05MB230.namprd05.prod.outlook.com ([169.254.12.226]) with mapi id 15.00.0745.000; Mon, 26 Aug 2013 15:07:03 +0000 From: Markus Jork To: "huubatwork@gmail.com" Thread-Topic: [mpls] MPLS-RT review of PSC related drafts Thread-Index: AQHOoKGpnByk+rx3CkuUmn4rOjhHlZmnkSbg Date: Mon, 26 Aug 2013 15:07:02 +0000 Message-ID: <8be8a162f75c4c61a48c925b2f294dde@BLUPR05MB230.namprd05.prod.outlook.com> References: <79E5D3D3-6AB4-4CE7-97A9-6D324C053490@gmail.com> <52186AC2.8030804@gmail.com> In-Reply-To: <52186AC2.8030804@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0950706AC1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of PSC related drafts 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, 26 Aug 2013 15:07:21 -0000 I did not attend the Berlin IETF and the minutes don't seem to be out yet, = so I don't know to what extent this was discussed there. But it seems most (all?) reviewers of the resulting drafts did not really l= ike the "diff" approach. That sends a pretty clear message that maybe this = wasn't such a great idea after all. Even after looking at the slides, I'm not clear what the motivation was to = choose the "diff" format. Was having a set of update drafts somehow meant t= o ease coordination with the ITU? Anyway, the main audience for a standards track RFC are the implementers an= d users of the technology. So an RFC should be written to be easily underst= ood and digested by its audience. And in my opinion the format chosen for t= his set of PSC drafts is not ideal in that regard. -Markus > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Huub van Helvoort > Sent: Saturday, August 24, 2013 4:12 AM > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org > Subject: [mpls] MPLS-RT review of PSC related drafts >=20 > All reviewers of the drafts, >=20 > draft-rhd-mpls-tp-psc-priority > draft-rhd-mpls-tp-psc-sd > draft-dj-mpls-tp-exer-psc > raft-cdh-mpls-tp-psc-non-revertive > draft-osborne-mpls-psc-updates >=20 > and anybody else who wants to contribute: >=20 > I have noticed your concern regarding the way each of these drafts should= be > used to address RFC6378. >=20 > I would like to point you this presentation in the IETF87 meeting which > contains a proposed forward path: > http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt >=20 > In this thread the discussion for supporting the options mentioned in the > slides has already started: > http://www.ietf.org/mail-archive/web/mpls/current/msg10400.html >=20 > Best regards, Huub. From wyaacov@gmail.com Mon Aug 26 10:48:25 2013 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 7AF3321E804E for ; Mon, 26 Aug 2013 10:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lGE6wbt10xt for ; Mon, 26 Aug 2013 10:48:24 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 47ACA21E80A5 for ; Mon, 26 Aug 2013 10:48:24 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id t58so2921933wes.24 for ; Mon, 26 Aug 2013 10:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lJyvdKhfIoO2++63hyvW1pNIA60X0znQmpyYhVkhC70=; b=udN6KzXaWdZzaX74rwTHlUayLEVU92sqq/jE8GsFPer6ZA9q3VJAaEK/mqu51wVqDi D8i1MBSbCs7ySaDdGnaLZAyFBh0lqLZVQRFvRyHEsFFhVVagIHwTu7ws5FQ52R4GrVnZ 3fBSnLryyxl+O3B9gqqF2UJFHqwbM6hUMlYpFt+Q7rIHXy8LXb1EUgy8Vol44HE5WdRb U1+lCcXqO56a4ZJHaCDWkdE/8JR0cuZqTQeOxPVuGeiQ9EbX6YuGCUfd60FUb7u6X69a Jl8EyBMo3rW7G+3c/pfp75pkrb1bUhhBgas+XXkJV0vu/mzJHpGjLNM5UEBFZlGLFZrP y74Q== MIME-Version: 1.0 X-Received: by 10.180.91.82 with SMTP id cc18mr8296439wib.7.1377539303437; Mon, 26 Aug 2013 10:48:23 -0700 (PDT) Received: by 10.194.164.200 with HTTP; Mon, 26 Aug 2013 10:48:23 -0700 (PDT) Received: by 10.194.164.200 with HTTP; Mon, 26 Aug 2013 10:48:23 -0700 (PDT) In-Reply-To: <8be8a162f75c4c61a48c925b2f294dde@BLUPR05MB230.namprd05.prod.outlook.com> References: <79E5D3D3-6AB4-4CE7-97A9-6D324C053490@gmail.com> <52186AC2.8030804@gmail.com> <8be8a162f75c4c61a48c925b2f294dde@BLUPR05MB230.namprd05.prod.outlook.com> Date: Mon, 26 Aug 2013 20:48:23 +0300 Message-ID: From: Yaacov Weingarten To: Markus Jork Content-Type: multipart/alternative; boundary=f46d043be244d879b504e4dd5c5b Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "huubatwork@gmail.com" Subject: Re: [mpls] MPLS-RT review of PSC related drafts 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, 26 Aug 2013 17:48:25 -0000 --f46d043be244d879b504e4dd5c5b Content-Type: text/plain; charset=ISO-8859-1 Hi. I fully agree with Markus on this. We should also keep in mind that, at least in theory, each RFC should strive to be a stand-alone document. In addition, as I pointed out in one of my reviews this could lead to contradictory "corrections" that no reader's guide draft could overcome! BR, yaacov On Aug 26, 2013 6:07 PM, "Markus Jork" wrote: > I did not attend the Berlin IETF and the minutes don't seem to be out yet, > so I don't know to what extent this was discussed there. > But it seems most (all?) reviewers of the resulting drafts did not really > like the "diff" approach. That sends a pretty clear message that maybe this > wasn't such a great idea after all. > Even after looking at the slides, I'm not clear what the motivation was to > choose the "diff" format. Was having a set of update drafts somehow meant > to ease coordination with the ITU? > Anyway, the main audience for a standards track RFC are the implementers > and users of the technology. So an RFC should be written to be easily > understood and digested by its audience. And in my opinion the format > chosen for this set of PSC drafts is not ideal in that regard. > > -Markus > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > Huub van Helvoort > > Sent: Saturday, August 24, 2013 4:12 AM > > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org > > Subject: [mpls] MPLS-RT review of PSC related drafts > > > > All reviewers of the drafts, > > > > draft-rhd-mpls-tp-psc-priority > > draft-rhd-mpls-tp-psc-sd > > draft-dj-mpls-tp-exer-psc > > raft-cdh-mpls-tp-psc-non-revertive > > draft-osborne-mpls-psc-updates > > > > and anybody else who wants to contribute: > > > > I have noticed your concern regarding the way each of these drafts > should be > > used to address RFC6378. > > > > I would like to point you this presentation in the IETF87 meeting which > > contains a proposed forward path: > > http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt > > > > In this thread the discussion for supporting the options mentioned in the > > slides has already started: > > http://www.ietf.org/mail-archive/web/mpls/current/msg10400.html > > > > Best regards, Huub. > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --f46d043be244d879b504e4dd5c5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi.
I fully agree with Markus on this. We should also keep in mind that, at le= ast in theory, each RFC should strive to be a stand-alone document. In addi= tion, as I pointed out in one of my reviews this could lead to contradictor= y "corrections" that no reader's guide draft could overcome!<= /p>

BR,
yaacov

On Aug 26, 2013 6:07 PM, "Markus Jork"= <mjork@juniper.net> wrote:<= br type=3D"attribution">
I did not attend the Berlin IETF and the minutes don't seem to be out y= et, so I don't know to what extent this was discussed there.
But it seems most (all?) reviewers of the resulting drafts did not really l= ike the "diff" approach. That sends a pretty clear message that m= aybe this wasn't such a great idea after all.
Even after looking at the slides, I'm not clear what the motivation was= to choose the "diff" format. Was having a set of update drafts s= omehow meant to ease coordination with the ITU?
Anyway, the main audience for a standards track RFC are the implementers an= d users of the technology. So an RFC should be written to be easily underst= ood and digested by its audience. And in my opinion the format chosen for t= his set of PSC drafts is not ideal in that regard.

-Markus

> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> Huub van Helvoort
> Sent: Saturday, August 24, 2013 4:12 AM
> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org
> Subject: [mpls] MPLS-RT review of PSC related drafts
>
> All reviewers of the drafts,
>
> draft-rhd-mpls-tp-psc-priority
> draft-rhd-mpls-tp-psc-sd
> draft-dj-mpls-tp-exer-psc
> raft-cdh-mpls-tp-psc-non-revertive
> draft-osborne-mpls-psc-updates
>
> and anybody else who wants to contribute:
>
> I have noticed your concern regarding the way each of these drafts sho= uld be
> used to address RFC6378.
>
> I would like to point you this presentation in the IETF87 meeting whic= h
> contains a proposed forward path:
> http://www.ietf.org/proceedings/87/slides/slides-87= -mpls-15.ppt
>
> In this thread the discussion for supporting the options mentioned in = the
> slides has already started:
> http://www.ietf.org/mail-archive/web/mpls/current/m= sg10400.html
>
> Best regards, Huub.



_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls
--f46d043be244d879b504e4dd5c5b-- From yakov@juniper.net Mon Aug 26 11:27:20 2013 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 8BD3021F9BAD for ; Mon, 26 Aug 2013 11:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPFWgIcUC6K6 for ; Mon, 26 Aug 2013 11:27:14 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0187.outbound.messaging.microsoft.com [213.199.154.187]) by ietfa.amsl.com (Postfix) with ESMTP id 3C63511E81F5 for ; Mon, 26 Aug 2013 11:27:14 -0700 (PDT) Received: from mail164-db8-R.bigfish.com (10.174.8.240) by DB8EHSOBE029.bigfish.com (10.174.4.92) with Microsoft SMTP Server id 14.1.225.22; Mon, 26 Aug 2013 18:27:12 +0000 Received: from mail164-db8 (localhost [127.0.0.1]) by mail164-db8-R.bigfish.com (Postfix) with ESMTP id C3FBDDA015A; Mon, 26 Aug 2013 18:27:12 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h1155h) Received-SPF: pass (mail164-db8: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=yakov@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail164-db8 (localhost.localdomain [127.0.0.1]) by mail164-db8 (MessageSwitch) id 1377541630859380_24006; Mon, 26 Aug 2013 18:27:10 +0000 (UTC) Received: from DB8EHSMHS013.bigfish.com (unknown [10.174.8.225]) by mail164-db8.bigfish.com (Postfix) with ESMTP id CD785B00040; Mon, 26 Aug 2013 18:27:10 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.50) by DB8EHSMHS013.bigfish.com (10.174.4.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 26 Aug 2013 18:27:10 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 26 Aug 2013 11:27:08 -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 r7QIR8L24922; Mon, 26 Aug 2013 11:27:08 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201308261827.r7QIR8L24922@magenta.juniper.net> To: Loa Andersson In-Reply-To: <521475A6.7080002@pi.nu> References: <521475A6.7080002@pi.nu> X-MH-In-Reply-To: Loa Andersson message dated "Wed, 21 Aug 2013 10:09:10 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <78798.1377541628.1@juniper.net> Date: Mon, 26 Aug 2013 11:27:08 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org Subject: Re: [mpls] IPR poll on draft-rekhter-mpls-pim-sm-over-mldp 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, 26 Aug 2013 18:27:20 -0000 Loa, > Working Group, > > The authors of draft-rekhter-mpls-pim-sm-over-mldp has told the > working group chairs that the draft is ready to be adopted as a working > group document. > > Before we start the mpls-rt review and the poll for adoption we will do > an IPR poll. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to draft-rekhter-mpls-pim- > sm-over-mldp? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). To clarify on my previous response to the question whether I am aware of any IPR that applies to draft-rekhter-mpls-pim-sm-over-mldp, all Juniper IPR disclosed for the underlying RFC 6514 applies to this draft. Please instruct if IETF requires Juniper to amend those IPR disclosures to specifically refer to this draft as well as the underlying RFC. Yakov. From huubatwork@gmail.com Mon Aug 26 13:06:20 2013 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 10BB411E821B for ; Mon, 26 Aug 2013 13:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=-0.409, 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 f5VZfgo0jDHm for ; Mon, 26 Aug 2013 13:06:18 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id CB75A21F9980 for ; Mon, 26 Aug 2013 13:06:03 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x54so3167716wes.32 for ; Mon, 26 Aug 2013 13:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Zth2Gvarl7PWBy5Mlxk3bXr2QF0MZGXYPadSAXmO6FQ=; b=mMnuPpHI7q6xbyCzesOJkL2s8dCFxFuDs4zsPJnqUO4YrGDvikJgWlxB2vdonGt3tZ 97a2g14QxVFUoPElpuPC9wYXO5wfvX3KrPTAZxVEeNzG2yITHFD688wLz/hn82svBsWr woUfRM0rjhpqcn3D6oqI9hjJrYrSpnbLjOpZaZz4AtaeWqNgxHlpKAoBHjkYIdMYJmPb 60kOVWU9fflAPa1OKZ82ioy8Z288aR3U5JrQabHUm7LRO5f0RyNDE+gVVXEdQX09NnH7 UzoWEKUGB67mwc7RS332VIbLNnLtoWqWD/3cfYUgDaTOObWm91gcT3r8Vvw7zaH5m6HH vh3w== X-Received: by 10.180.75.15 with SMTP id y15mr8745510wiv.12.1377547558964; Mon, 26 Aug 2013 13:05:58 -0700 (PDT) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id eb3sm21005200wic.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Aug 2013 13:05:58 -0700 (PDT) Message-ID: <521BB527.6000000@gmail.com> Date: Mon, 26 Aug 2013 22:05:59 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 References: <79E5D3D3-6AB4-4CE7-97A9-6D324C053490@gmail.com> <52186AC2.8030804@gmail.com> <8be8a162f75c4c61a48c925b2f294dde@BLUPR05MB230.namprd05.prod.outlook.com> In-Reply-To: <8be8a162f75c4c61a48c925b2f294dde@BLUPR05MB230.namprd05.prod.outlook.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of PSC related drafts 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, 26 Aug 2013 20:06:20 -0000 Hallo Markus, You wrote: > I did not attend the Berlin IETF and the minutes don't > seem to be out yet, so I don't know to what extent this > was discussed there. The sesion was recorded: http://www.ietf.org/meeting/87/remote-participation.html#audio (Room Potsdam 3). > But it seems most (all?) reviewers of the resulting drafts > did not really like the "diff" approach. Maybe most (all) reviewers did not attend the MPLS session on Friday. And thus were not aware of the proposed roadmap for progressing these drafts. In the slideset slide 20 captures the overall idea: - each of the drafts captures/describes an optional change to RFC6378. - new draft-xxx-mpls-tp-ITU-mode provides the mode in which all the options are supported at the same time. All the changes to the protocol state machine are captured in this draft. - It was agreed that any other sub-set of these options would require its own particular mode draft and state machine. Currently there will be two modes: = none option supported: existing RFC6378 = all options supported: draft ITU mode In this way implementations (currently) have to support two modes. > That sends a pretty clear message that maybe this wasn't > such a great idea after all. Maybe they did not understand the way i which all the options should be supported. > Even after looking at the slides, I'm not clear what the > motivation was to choose the "diff" format. To describe why each of the separate options is required. This was proposed in the liaison sent from IETF to ITU. > Was having a set of update drafts somehow meant to ease > coordination with the ITU? Yes. This was requested in the liaison from IETF to ITU and the concatenation of the options is in draft ITU mode. > Anyway, the main audience for a standards track RFC are > the implementers and users of the technology. So an RFC > should be written to be easily understood and digested > by its audience. And in my opinion the format chosen for > this set of PSC drafts is not ideal in that regard. What is the format you would like to see? Regards, Huub. >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Huub van Helvoort >> Sent: Saturday, August 24, 2013 4:12 AM >> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org >> Subject: [mpls] MPLS-RT review of PSC related drafts >> >> All reviewers of the drafts, >> >> draft-rhd-mpls-tp-psc-priority >> draft-rhd-mpls-tp-psc-sd >> draft-dj-mpls-tp-exer-psc >> raft-cdh-mpls-tp-psc-non-revertive >> draft-osborne-mpls-psc-updates >> >> and anybody else who wants to contribute: >> >> I have noticed your concern regarding the way each of these drafts should be >> used to address RFC6378. >> >> I would like to point you this presentation in the IETF87 meeting which >> contains a proposed forward path: >> http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt >> >> In this thread the discussion for supporting the options mentioned in the >> slides has already started: >> http://www.ietf.org/mail-archive/web/mpls/current/msg10400.html >> >> Best regards, Huub. > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- ***************************************************************** 请记ä½ï¼Œä½ æ˜¯ç‹¬ä¸€æ— äºŒçš„，就åƒå…¶ä»–æ¯ä¸€ä¸ªäººä¸€æ · From cheung.taesik@gmail.com Sun Aug 25 19:55:09 2013 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 712D911E813A for ; Sun, 25 Aug 2013 19:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-iom6Cryej0 for ; Sun, 25 Aug 2013 19:55:08 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 79E6111E8138 for ; Sun, 25 Aug 2013 19:55:08 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx10so2865066pab.41 for ; Sun, 25 Aug 2013 19:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=BTSKQZPsPvrSFrrmJ7hjoHkQFLD8AVNqXW603AcRpyU=; b=0lpPLsWAdzYrZswdawlBLm4L3UfEvB9tfBHQA3D4YxVxMSGoxh7GTV+UJDvdSZ1g1R 77TEOihvMehzUpuooxh9gpqFgwIyr+NxQ6Dfg2NnG3e3WEo2rfRJBO39d+yLXi4btcit OEMO2k/ZGtM5ctTfIwIegElTIkf2B7ecVYeS9t/eLezlB3XRyr1W1eYlhmXl713+Rfuo VuaI6x2ntWi+VdFv/B8r7COqbd8P+EyCJLesmJ72s5ltjTLj4DIEDC0TniU7PIjfq3vV S+2P91C8mnPIOU2jLV8pbIkMq4IOXiFC8wtmbE7HxSRvc7GET0S364QnndgUaBE5s9U+ Octw== X-Received: by 10.66.232.39 with SMTP id tl7mr751691pac.140.1377485707888; Sun, 25 Aug 2013 19:55:07 -0700 (PDT) Received: from D03490001 ([129.254.73.69]) by mx.google.com with ESMTPSA id nj9sm14872309pbc.13.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 25 Aug 2013 19:55:06 -0700 (PDT) From: "Taesik Cheung" To: "'Eric Gray'" , "???" , , "'Alessandro D Alessandro'" , References: <48E1A67CB9CA044EADFEAB87D814BFF642E609@eusaamb107.ericsson.se> In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF642E609@eusaamb107.ericsson.se> Date: Mon, 26 Aug 2013 11:55:02 +0900 Message-ID: <000001cea207$ab8b31a0$02a194e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFHk3fccqiV19TZWY7r+SsFQRMwdpq05ikQ Content-Language: ko X-Mailman-Approved-At: Mon, 26 Aug 2013 15:19:41 -0700 Cc: 'Ross Callon' Subject: Re: [mpls] MPLS-RT review of draft-cdh-mpls-tp-psc-non-revertive 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, 26 Aug 2013 02:55:09 -0000 Hi Eric (Gray), Thank you for reviewing draft-cdh-mpls-psc-non-revertive-00. As one of authors of the draft, I answered your comments. Please see [Taesik] inline. Best regards, Taesik -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Gray Sent: Friday, August 23, 2013 10:17 PM To: Taesik Cheung; Huub van Helvoort (huub.van.helvoort@huawei.com); Alessandro D Alessandro; mpls@ietf.org Cc: Ross Callon (rcallon@juniper.net) Subject: Re: [mpls] MPLS-RT review of draft-cdh-mpls-tp-psc-non-revertive Hi, I have been asked to review this draft, and to determine if it is in good enough shape to be adopted by the MPLS working group. Although requested to include the MPLS working group mailing list as a "Cc", I have included it as a "To" because of the questions I think need to be resolved either by discussion in the working group, or decision by the working group chairs. In general, I find this draft to be well written and may be ready for adoption by the MPLS working group. There are two general questions about what may be acceptable to the working group that should be resolved in some way prior to adoption of this draft by the working group. The questions are included as the first part of my comments below. I have the following comments and/or questions: Major Comments/Questions: ====================== General questions for the MPLS working Group ---------------------------------------------------------- First Question -- The way that this draft is written is as a "delta" to RFC 6378. I personally do not have any problems with this, assuming that a reader can correctly (re)construct the resulting text as applied to RFC 6378. However, over the long term, it is significant that this "delta" will not actually be applied to RFC 6378 and may therefore lead to ambiguity and/or confusion if other subsequent "deltas" are produced against the same RFC in the future. When/if this happens, it is likely that the combination of multiple "delta" RFCs will force a re-write of RFC 6378 to remove ambiguity and/or confusion. As an example, should a subsequent "update" to RFC 6378 suggest changes that result in renumbering of the sections affected by this document, there will likely be confusion resulting from the order that a reader reads the set of documents, applying the changes in the order that they read them, as opposed to the order in which they were written and intended. Is the working group generally okay with taking this approach? (Alternatively, this draft could be re-written as a "bis" for RFC 6378, obsoleting that RFC as opposed to updating it, or it could be re-written as a quasi-stand-alone document - rather than as a set of deltas to RFC 6378 - referring to RFC 6378 for protection switching behavior not explicitly described in this document.) [Taesik] This comment is not for the authors of this draft. Second Question -- Is it simpler to deal with this draft as a separate draft, or should it be combined with the other related drafts that are also (at least primarily) intended to update RFC 6378? At least with the two drafts I've been asked to review (adding signal degrade, and making corrections to non-revertive mode), the modifications to RFC 6378 appear to be distinct, non-overlapping, changes throughout the drafts. Where this is more difficult to be certain of is in the changes to the state-machine tables - which are quite complex. At various points in the process, when reviewing the draft, the best approach to verifying that there is no overlap or inconsistency is to actually merge all of the changes and then review the result. If this turns out to be the case for every reviewer, then there is no benefit to having these as separate drafts. Should all of these related drafts be merged? [Taesik] This comment is not for the authors of this draft. Minor Comments and NITs: ==================== You need to add "updates RFC 6378 (when published)" to the header of the first page. [Taesik] It can be reflected in the next revision of the draft. I suggest omitting "contains the updates to" from the abstract, replacing it with "updates" and adding a second comma after "Linear Protection" (the text "MPLS Transport Profile ... Linear Protection" is a parenthetical description of RFC 6378). The same comment applies to the last paragraph in the Introduction section as well. [Taesik] It can be reflected in the next revision of the draft. In the third paragraph of the Introduction section, the second sentence is an incomplete sentence and does not make sense as is. I believe the "period" after "Section 4.3.3.6" is supposed to be a comma. [Taesik] It can be reflected in the next revision of the draft. In the fourth paragraph, "missing" should be "omission" (possibly auto-correct?). [Taesik] It can be reflected in the next revision of the draft. Abbreviations should be defined at least near where they are used - especially in section headers (see sections 1.1 and 1.2). Preferably they should be defined (or expanded) before they are used, but this is awkward in section headers (and messes up the ToC). I suggest adding a new first paragraph in each section where this occurs, with the express purpose of at least expanding these acronyms/abbreviations. [Taesik] MS-W is already expanded in both Abstract and Section 1 of the draft. For MS-P, it can be expanded in both Abstract and Section 1 in the next revision of the draft. But, before doing this, we need to agree on the renaming because there is another review's comment not supporting this renaming. The first paragraph in section 1.2 is awkwardly worded, creating an apparent inconsistency. Perhaps the authors would consider re-wording the first sentence of the paragraph along the lines of: "The MS-P and MS-W commands SHALL have the same priority, except in the case where both are received simultaneously." [Taesik] I don't think that there is an inconsistency between the first sentence and the rests of the first paragraph. If you see Sec 4.6 of the draft, priorities of MS-P and MS-W are defined to be same. Sec 1.2 describes how to resolve when those two commands are entered to the PSC logic simultaneously. It is worth noting that - possibly - this exception (and the text currently in the paragraph that "justifies" it) could (and possibly should) be omitted. Because "simultaneity" is not a verifiable occurrence, the scenario this text describes is not testable or necessarily observable outside of the implementation. [Taesik] I think that the PSC protocol state machine should be defined to cover all the possible cases regardless of the difficulty in verification. Moreover, this simultaneous condition is not so difficult to test because "simultaneity" considered in this draft does not mean the absolutely same time. Please see item c) in Sec 4.6 of this draft, which describes the meaning of "simultaneous condition". In section 4, "Manual Switch to Working" should be in quotes as it not clear how the text in the paragraph would otherwise be grouped to one not familiar with this command. That is, it is currently possible to read this as "... add 'Manual Switch' to 'Working operator command' ..." - which makes little sense (forcing the reader to re-read this until they've worked out the intended meaning). [Taesik] It can be reflected in the next revision of the draft. -- Eric Gray _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Tue Aug 27 02:32:43 2013 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 8282A21E80C2 for ; Tue, 27 Aug 2013 02:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M07Ms3ZHSHGp for ; Tue, 27 Aug 2013 02:32:37 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 777FA21E80C6 for ; Tue, 27 Aug 2013 02:32:37 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 66E891802038; Tue, 27 Aug 2013 11:32:36 +0200 (CEST) Message-ID: <521C7237.1030007@pi.nu> Date: Tue, 27 Aug 2013 11:32:39 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Yakov Rekhter References: <521475A6.7080002@pi.nu> <201308261827.r7QIR8L24922@magenta.juniper.net> In-Reply-To: <201308261827.r7QIR8L24922@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org Subject: Re: [mpls] IPR poll on draft-rekhter-mpls-pim-sm-over-mldp 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, 27 Aug 2013 09:32:43 -0000 Yakov, I think such a statement from any IPR holder is necessary! This is true also of the IPR *also* applies to another document and is earlier disclosed in relation to that other document. /Loa On 2013-08-26 20:27, Yakov Rekhter wrote: > Loa, > >> Working Group, >> >> The authors of draft-rekhter-mpls-pim-sm-over-mldp has told the >> working group chairs that the draft is ready to be adopted as a working >> group document. >> >> Before we start the mpls-rt review and the poll for adoption we will do >> an IPR poll. >> >> This mail starts that IPR poll. >> >> Are you aware of any IPR that applies to draft-rekhter-mpls-pim- >> sm-over-mldp? >> >> If so, has this IPR been disclosed in compliance with IETF IPR rules >> (see RFCs 3979, 4879, 3669 and 5378 for more details). > > To clarify on my previous response to the question whether I am aware > of any IPR that applies to draft-rekhter-mpls-pim-sm-over-mldp, > all Juniper IPR disclosed for the underlying RFC 6514 applies to > this draft. > > Please instruct if IETF requires Juniper to amend those IPR disclosures > to specifically refer to this draft as well as the underlying RFC. > > Yakov. > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From wim.henderickx@alcatel-lucent.com Tue Aug 27 08:30:21 2013 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 8E2B211E835A for ; Tue, 27 Aug 2013 08:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dh-G0C6drD7c for ; Tue, 27 Aug 2013 08:30:15 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1063A11E8130 for ; Tue, 27 Aug 2013 08:30:14 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r7RFUB14010230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 27 Aug 2013 10:30:13 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r7RFUAWR015969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 27 Aug 2013 17:30:11 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.63]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 27 Aug 2013 17:30:10 +0200 From: "Henderickx, Wim (Wim)" To: "mpls@ietf.org" Thread-Topic: The IPR poll on draft-rekhter-mpls-pim-sm-over-mldp needs to be completed Thread-Index: AQHOowo0ydyG0TA+/UuQgTs8Ne4zFZmpHciA Date: Tue, 27 Aug 2013 15:30:09 +0000 Message-ID: In-Reply-To: <521C7521.4000304@pi.nu> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-ID: <986A52B98A04174C8C0E932F1048B917@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [mpls] The IPR poll on draft-rekhter-mpls-pim-sm-over-mldp needs to be completed 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, 27 Aug 2013 15:30:21 -0000 Not aware of any ipr related to this draft >>> >>>> Working Group, >>>> >>>> The authors of draft-rekhter-mpls-pim-sm-over-mldp has told the >>>> working group chairs that the draft is ready to be adopted as a >>>>working >>>> group document. >>>> >>>> Before we start the mpls-rt review and the poll for adoption we will >>>>do >>>> an IPR poll. >>>> >>>> This mail starts that IPR poll. >>>> >>>> Are you aware of any IPR that applies to draft-rekhter-mpls-pim- >>>> sm-over-mldp? >>>> >>>> If so, has this IPR been disclosed in compliance with IETF IPR rules >>>> (see RFCs 3979, 4879, 3669 and 5378 for more details). >>> >>> To clarify on my previous response to the question whether I am aware >>> of any IPR that applies to draft-rekhter-mpls-pim-sm-over-mldp, >>> all Juniper IPR disclosed for the underlying RFC 6514 applies to >>> this draft. >>> >>> Please instruct if IETF requires Juniper to amend those IPR disclosures >>> to specifically refer to this draft as well as the underlying RFC. >>> >>> Yakov. >>> >> > >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From renwei.li@huawei.com Tue Aug 27 09:22:15 2013 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 BD49F11E835F for ; Tue, 27 Aug 2013 09:22:14 -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 mdaoGXHQ05CX for ; Tue, 27 Aug 2013 09:22:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 86F5C11E82A1 for ; Tue, 27 Aug 2013 09:22:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AWQ40964; Tue, 27 Aug 2013 16:22:07 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 27 Aug 2013 17:21:20 +0100 Received: from SJCEML401-HUB.china.huawei.com (10.212.94.42) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 27 Aug 2013 17:22:04 +0100 Received: from SJCEML501-MBS.china.huawei.com ([169.254.2.175]) by sjceml401-hub.china.huawei.com ([::1]) with mapi id 14.03.0146.000; Tue, 27 Aug 2013 09:22:00 -0700 From: Richard Li To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] IPR poll on draft-rekhter-mpls-pim-sm-over-mldp Thread-Index: AQHOnkXCfbrGyDIE9U2RAe+YxRmVpZmpRhSQ Date: Tue, 27 Aug 2013 16:21:58 +0000 Message-ID: References: <521475A6.7080002@pi.nu> In-Reply-To: <521475A6.7080002@pi.nu> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] IPR poll on draft-rekhter-mpls-pim-sm-over-mldp 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, 27 Aug 2013 16:22:15 -0000 Not aware of any IPR that applies to this draft. Thanks, /RL -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Wednesday, August 21, 2013 1:09 AM To: mpls@ietf.org; mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); = draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org Subject: [mpls] IPR poll on draft-rekhter-mpls-pim-sm-over-mldp Working Group, The authors of draft-rekhter-mpls-pim-sm-over-mldp has told the working gro= up chairs that the draft is ready to be adopted as a working group document= . Before we start the mpls-rt review and the poll for adoption we will do an = IPR poll. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-rekhter-mpls-pim- sm-over-ml= dp? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. *Th= e response needs to be sent to the MPLS wg mailing list.* The documents wil= l not advance to the next stage until a response has been received from eac= h author and contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From ietfc@btconnect.com Tue Aug 27 10:08:35 2013 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 1B7B921E8099 for ; Tue, 27 Aug 2013 10:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=1.183, 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 FX0LAbcn2ojd for ; Tue, 27 Aug 2013 10:08:29 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA7B21E8092 for ; Tue, 27 Aug 2013 10:08:25 -0700 (PDT) Received: from mail34-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE027.bigfish.com (10.3.207.149) with Microsoft SMTP Server id 14.1.225.22; Tue, 27 Aug 2013 17:08:23 +0000 Received: from mail34-am1 (localhost [127.0.0.1]) by mail34-am1-R.bigfish.com (Postfix) with ESMTP id CC3DF6011C; Tue, 27 Aug 2013 17:08:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -13 X-BigFish: PS-13(zz98dI9371Ic89bh146fI542I1432I853kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah186068h8275bh8275dh1de097hz2dh2a8h5a9h839h93fhd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh19f0h1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail34-am1 (localhost.localdomain [127.0.0.1]) by mail34-am1 (MessageSwitch) id 1377623232194244_11830; Tue, 27 Aug 2013 17:07:12 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.247]) by mail34-am1.bigfish.com (Postfix) with ESMTP id 27B7F4A0078; Tue, 27 Aug 2013 17:07:05 +0000 (UTC) Received: from DB3PRD0710HT002.eurprd07.prod.outlook.com (157.56.253.85) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 27 Aug 2013 17:07:04 +0000 Received: from pc6 (86.135.129.242) by pod51017.outlook.com (10.255.75.37) with Microsoft SMTP Server (TLS) id 14.16.347.3; Tue, 27 Aug 2013 17:07:03 +0000 Message-ID: <004001cea347$bd7cc7c0$4001a8c0@gateway.2wire.net> From: t.petch To: References: <79E5D3D3-6AB4-4CE7-97A9-6D324C053490@gmail.com><52186AC2.8030804@gmail.com><8be8a162f75c4c61a48c925b2f294dde@BLUPR05MB230.namprd05.prod.outlook.com> <521BB527.6000000@gmail.com> Date: Tue, 27 Aug 2013 18:06:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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-Originating-IP: [86.135.129.242] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: mpls@ietf.org Subject: Re: [mpls] MPLS-RT review of PSC related drafts 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, 27 Aug 2013 17:08:35 -0000 ----- Original Message ----- From: "Huub van Helvoort" Cc: ; Sent: Monday, August 26, 2013 9:05 PM > Hallo Markus, > > You wrote: > > > I did not attend the Berlin IETF and the minutes don't > > seem to be out yet, so I don't know to what extent this > > was discussed there. > > The sesion was recorded: > http://www.ietf.org/meeting/87/remote-participation.html#audio > (Room Potsdam 3). > > > But it seems most (all?) reviewers of the resulting drafts > > did not really like the "diff" approach. > > Maybe most (all) reviewers did not attend the MPLS session > on Friday. And thus were not aware of the proposed roadmap > for progressing these drafts. > In the slideset slide 20 captures the overall idea: > - each of the drafts captures/describes an optional change > to RFC6378. > - new draft-xxx-mpls-tp-ITU-mode provides the mode in which > all the options are supported at the same time. > All the changes to the protocol state machine are captured > in this draft. > - It was agreed that any other sub-set of these options would > require its own particular mode draft and state machine. Huub It sounds as if it would be clearer if we had a sight of draft-xxx Certainly up to now, my sympathies have been with the reviewers who have found the piecemeal approach a source of possible ambiguity. Tom Petch > > Currently there will be two modes: > =3D none option supported: existing RFC6378 > =3D all options supported: draft ITU mode > > In this way implementations (currently) have to support > two modes. > > > That sends a pretty clear message that maybe this wasn't > > such a great idea after all. > > Maybe they did not understand the way i which all the > options should be supported. > > > Even after looking at the slides, I'm not clear what the > > motivation was to choose the "diff" format. > > To describe why each of the separate options is required. > This was proposed in the liaison sent from IETF to ITU. > > > Was having a set of update drafts somehow meant to ease > > coordination with the ITU? > > Yes. This was requested in the liaison from IETF to ITU > and the concatenation of the options is in draft ITU mode. > > > Anyway, the main audience for a standards track RFC are > > the implementers and users of the technology. So an RFC > > should be written to be easily understood and digested > > by its audience. And in my opinion the format chosen for > > this set of PSC drafts is not ideal in that regard. > > What is the format you would like to see? > > Regards, Huub. > > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > >> Huub van Helvoort > >> Sent: Saturday, August 24, 2013 4:12 AM > >> Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org > >> Subject: [mpls] MPLS-RT review of PSC related drafts > >> > >> All reviewers of the drafts, > >> > >> draft-rhd-mpls-tp-psc-priority > >> draft-rhd-mpls-tp-psc-sd > >> draft-dj-mpls-tp-exer-psc > >> raft-cdh-mpls-tp-psc-non-revertive > >> draft-osborne-mpls-psc-updates > >> > >> and anybody else who wants to contribute: > >> > >> I have noticed your concern regarding the way each of these drafts should be > >> used to address RFC6378. > >> > >> I would like to point you this presentation in the IETF87 meeting which > >> contains a proposed forward path: > >> http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt > >> > >> In this thread the discussion for supporting the options mentioned in the > >> slides has already started: > >> http://www.ietf.org/mail-archive/web/mpls/current/msg10400.html > >> > >> Best regards, Huub. > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > > -- > ***************************************************************** > =E8=AF=B7=E8=AE=B0=E4=BD=8F=EF=BC=8C=E4=BD=A0=E6=98=AF=E7= =8B=AC=E4=B8=80=E6=97=A0=E4=BA=8C=E7=9A=84=EF=BC=8C=E5=B0=B1=E5=83=8F=E5=85= =B6=E4=BB=96=E6=AF=8F=E4=B8=80=E4=B8=AA=E4=BA=BA=E4=B8=80=E6=A0=B7 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From cts@etri.re.kr Tue Aug 27 17:10:35 2013 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 2043E21F8E2A for ; Tue, 27 Aug 2013 17:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.346 X-Spam-Level: X-Spam-Status: No, score=-97.346 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, 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 362aY6oE-Vux for ; Tue, 27 Aug 2013 17:10:30 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id AC30921F8B07 for ; Tue, 27 Aug 2013 17:10:28 -0700 (PDT) Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 28 Aug 2013 09:10:17 +0900 Received: from SMTP4.etri.info ([169.254.3.68]) by SMTP3.etri.info ([129.254.28.73]) with mapi id 14.01.0355.002; Wed, 28 Aug 2013 09:10:20 +0900 From: =?ks_c_5601-1987?B?waTFwr3E?= To: Yaacov Weingarten , "mpls@ietf.org" Thread-Topic: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents Thread-Index: AQHOlPghtHYllm9ZlUWJChJo0dWyb5mgbNEAgACk5gCACMSvQA== Date: Wed, 28 Aug 2013 00:10:19 +0000 Message-ID: References: <5204D9DE.6060405@pi.nu> In-Reply-To: Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.73.69] Content-Type: multipart/alternative; boundary="_000_AD98114A73E97041A2EDDCC3F3D10B031103C3CCSMTP4etriinfo_" MIME-Version: 1.0 Cc: "draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents 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, 28 Aug 2013 00:10:35 -0000 --_000_AD98114A73E97041A2EDDCC3F3D10B031103C3CCSMTP4etriinfo_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgWWFhY292LA0KDQpUaGFuayB5b3UgZm9yIHJldmlld2luZyBkcmFmdC1jZGgtbXBscy10cC1w c2Mtbm9uLXJldmVydGl2ZS0wMC4NCg0KSSBkaXNjdXNzZWQgeW91ciBjb21tZW50cyB3aXRoIHRo ZSBvdGhlciBjby1hdXRob3JzIG9mIHRoaXMgZHJhZnQuDQpTb21lIG9mIHlvdXIgY29tbWVudHMg YXJlIG5vdCBvbmx5IHJlbGF0ZWQgdG8gdGhpcyBkcmFmdCBidXQgYWxzbyByZWxhdGVkIHRvIGFs bCBvdGhlciBwc2MgZHJhZnRzLg0KU28sIEkgd2lsbCBhbnN3ZXIgb25seSB0byB0aGUgY29tbWVu dHMgc3BlY2lmaWMgdG8gdGhpcyBkcmFmdC4gUGxlYXNlIHNlZSBbVGFlc2lrXSBpbmxpbmUuDQoN CkJlc3QgcmVnYXJkcywNClRhZXNpaw0KDQpGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBZYWFjb3YgV2VpbmdhcnRl bg0KU2VudDogRnJpZGF5LCBBdWd1c3QgMjMsIDIwMTMgMzo1NiBBTQ0KVG86IG1wbHNAaWV0Zi5v cmcNCkNjOiBkcmFmdC1jZGgtbXBscy10cC1wc2Mtbm9uLXJldmVydGl2ZUB0b29scy5pZXRmLm9y ZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBsc10gTVBMUy1S VCByZXZpZXcgb24gZHJhZnQtY2RoLW1wbHMtdHAtcHNjLW5vbi1yZXZlcnRpdmUtMDAvL1JFOiBN UExTLVJUIHJldmlldyBvZiBtcGxzIHBzYyBkb2N1bWVudHMNCg0KSGksDQoNCkkgaGF2ZSBjb25k dWN0ZWQgYSByZXZpZXcgb2YgZHJhZnQtY2RoLW1wbHMtdHAtcHNjLW5vbi1yZXZlcnRpdmUgYXMg cmVxdWVzdGVkIGJ5IHRoZSBXRyBDaGFpcnMgYW5kIGhhdmUgdGhlIGZvbGxvd2luZyBub3RlczoN Cg0KVGhpcyBkcmFmdCBwdXJwb3J0cyB0byAidXBkYXRlIiBSRkM2Mzc4IHRvIGNoYW5nZSBub24t cmV2ZXJ0aXZlIGJlaGF2aW9yIG9mIHRoZSBMaW5lYXIgUHJvdGVjdGlvbiBwcm90b2NvbC4gVGhl IG1ldGhvZCBvZiB1cGRhdGluZyB0aGUgcHJvdG9jb2wgaXMgdGhyb3VnaCB0aGUgYWRkaXRpb24g b2YgYSBNYW51YWwgU3dpdGNoIHRvIFdvcmtpbmcgb3BlcmF0b3IgY29tbWFuZCB0byBhZmZlY3Qg dGhlIHJldmVyc2lvbiBvZiB0cmFmZmljIHRvIHRoZSB3b3JraW5nIHBhdGguIEFsb25nIHRoZSB3 YXkgdGhlIGF1dGhvcnMgcHJvcG9zZSB0byBjaGFuZ2UgdGhlIG5hbWUgb2YgdGhlIE1hbnVhbCBT d2l0Y2ggb3BlcmF0b3IgY29tbWFuZCBhbHJlYWR5IGRlZmluZWQgaW4gUkZDNjM3OCBhbmQgYWxz byBjaGFuZ2UgdGhlIG5hbWUgb2YgdGhlIFByb3RlY3RpbmcgQWRtaW5pc3RyYXRpdmUgU3RhdGUg dG8gU3dpdGNoaW5nIEFkbWluaXN0cmF0aXZlIFN0YXRlLg0KDQpUaGUgZm9ybWF0IG9mIHRoZSBk cmFmdCBpcyBpbiB0aGUgZm9ybSBvZiBhbiBlcnJhdGEgY29ycmVjdGlvbiBkb2N1bWVudCwgaW5k aWNhdGluZyB3aGljaCBwYXJhZ3JhcGhzIGluIHRoZSBSRkMgc2hvdWxkIGJlIHJlcGxhY2VkIGFu ZCB3aGF0IG5ldyB0ZXh0IHNob3VsZCBiZSBzdWJzdGl0dXRlZCBpbiBpdHMgcGxhY2UuDQoNClRo aXMgZHJhZnQgaXMgcGFydCBvZiBhIHNldCBvZiBkcmFmdHMgdGhhdCB3YXMgZGlzY3Vzc2VkIGF0 IHRoZSBJRVRGODcgbWVldGluZyB0aGF0IHdpbGwgaW5jbHVkZSBhbiAib3ZlcnZpZXciIGRvY3Vt ZW50IHRoYXQgZGVzY3JpYmVzIGhvdyB0byBpbmNvcnBvcmF0ZSB0aGUgbmV3IGZ1bmN0aW9uYWxp dHkgZGVzY3JpYmVkIGluIHRob3NlIGRyYWZ0cy4NCg0KV2l0aCB0aGlzIGludHJvZHVjdGlvbiBJ IHdvdWxkIGxpa2UgdG8gbWFrZSB0aGUgZm9sbG93aW5nIG9ic2VydmF0aW9uczoNCjEuIFRoZXJl IGFyZSBhY2NlcHRlZCBtZXRob2RzIHVzZWQgaW4gdGhlIElFVEYgdG8gdXBkYXRlIGEgUkZDIGJ5 IGFkZGluZyBuZXcgZnVuY3Rpb25hbGl0eSB0byBhIHByb3RvY29sLiBVc3VhbGx5LCB0aGlzIGlz IGRvbmUgYnkgd3JpdGluZyBhIGRyYWZ0IHRoYXQgZGVzY3JpYmVzIHRoZSBuZXcgZnVuY3Rpb25h bGl0eSBvbiB0b3Agb2YgdGhlIGV4aXN0aW5nIGZ1bmN0aW9uYWxpdHkgcmF0aGVyIHRoYW4gdGhl IG1ldGhvZCB1c2VkIGhlcmUuIFRoaXMgaXMgZXNwZWNpYWxseSBzdHJhbmdlIGNvbnNpZGVyaW5n IHRoYXQgdGhleSBhcmUgbm90IGNoYW5naW5nIHRoZSBiZWhhdmlvciBvZiB0aGUgZXhpc3Rpbmcg ZnVuY3Rpb25hbGl0eSBidXQganVzdCBhZGRpbmcgYW4gYWRkaXRpb25hbCBjb21tYW5kIGFuZCBk ZXNjcmliaW5nIGl0cyBiZWhhdmlvci4NCg0KMi4gQmFzZWQgb24gdGhpcyBvYnNlcnZhdGlvbiBh bmQgdGhlIGZhY3QgdGhhdCBhbGwgb2YgdGhlIHN1Z2dlc3RlZCAiY29ycmVjdGlvbnMiIHRvIHRo ZSB0ZXh0IGludm9sdmluZyAiTWFudWFsIFN3aXRjaCIgYXJlIHRvIGNoYW5nZSB0aGUgbmFtZSBi dXQgbm90IHRoZSBmdW5jdGlvbmFsaXR5LCBJIGRvIG5vdCBzZWUgdGhlIGp1c3RpZmljYXRpb24g aW4gY2hhbmdpbmcgdGhlIG5hbWUgb2YgdGhlIGV4aXN0aW5nIE1hbnVhbCBTd2l0Y2ggY29tbWFu ZCBzaW5jZSBpdHMgZnVuY3Rpb25hbGl0eSBpcyBlc3NlbnRpYWxseSByZW1haW5pbmcgYXMgZGVm aW5lZCBhbmQgdGhlcmUgaXMgbm8gY2F1c2UgZm9yIGNvbmZ1c2lvbiB3aXRoIHRoZSBuZXcgIk1h bnVhbCBTd2l0Y2ggdG8gV29ya2luZyIgY29tbWFuZC4NCltUYWVzaWtdIEZvciB0aGUgc2FrZSBv ZiBjbGFyaXR5IEkgYmVsaWV2ZSBpdCBpcyBiZXR0ZXIgdG8gcmVuYW1lIE1TIHRvIE1TLVAgdG8g Y2xlYXJseSBkaXN0aW5ndWlzaCBpdCBmcm9tIE1TLVcgYW5kIGZvciBoYXZpbmcgobBzeW1tZXRy aWMgbmFtZXOhsS4gQnV0IEkgY2FuIGxpdmUgd2l0aCBjdXJyZW50IG5hbWUuDQoNCjMuIEkgc2Vl IHByb2JsZW1zIHdpdGggdGhlIHN1Z2dlc3Rpb24gdG8gY2hhbmdlIHRoZSAiUHJvdGVjdGluZyBB ZG1pbmlzdHJhdGl2ZSBTdGF0ZSIgdG8gIlN3aXRjaGluZyBBZG1pbmlzdHJhdGl2ZSBTdGF0ZSIg c2luY2UgdGhpcyByZXF1aXJlcyB0aGUgY29uZnVzaW5nIHN0YXRlbWVudCAoaW4gU2VjdGlvbiA0 LjkpICJ0aGUgdXNlciB0cmFmZmljIFNIQUxMIGJlIHRyYW5zcG9ydGVkIG9uIGVpdGhlciB0aGUg cHJvdGVjdGlvbiBwYXRoIG9yIHRoZSB3b3JraW5nIHBhdGgiIHdoaWNoIGlzIGNlcnRhaW5seSBh bHdheXMgdHJ1ZSBmb3IgdHJhZmZpYyB0aGF0IGlzIGJlaW5nIHRyYW5zcG9ydGVkLiBXaHkgbm90 IGNyZWF0ZSBhIG5ldyBTdGF0ZT8gT3IgZXZlbiBiZXR0ZXIsIHNpbmNlIHRoZSBNUy1XIGlzIG1l YW50IHRvIHJldHVybiB0aGUgc3RhdGUgdG8gTm9ybWFsIHdoeSBub3QganVzdCB1c2UgTm9ybWFs IHN0YXRlPw0KW1RhZXNpa10gWWVzLCB0cmFmZmljIGFsd2F5cyBmbG93IG9uIGVpdGhlciB0aGUg d29ya2luZyBvciBwcm90ZWN0aW9uIHBhdGguIEJ1dCwgaXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQg aXQgaXMgobBhZG1pbmlzdHJhdGl2ZWx5obEgY29udHJvbGxlZC4gSW4gdGhhdCBzZW5zZSwgd2Ug Y2Fubm90IHNheSB0aGF0IGEgbm9kZSBpcyBpbiChsE5vcm1hbCBzdGF0ZaGxIHdoZW4gTVMtVyBj b21tYW5kIGlzIGlzc3VlZC4gQnkgcmVwbGFjaW5nIKGwUHJvdGVjdGluZyBhZG1pbmlzdHJhdGl2 ZSBzdGF0ZaGxIGJ5IKGwU3dpdGNoaW5nIGFkbWluaXN0cmF0aXZlIHN0YXRlobEsIGl0IGNhbiBj b3ZlciBib3RoIGNhc2VzOiBhZG1pbmlzdHJhdGl2ZWx5IHN3aXRjaGVkIHRvIHdvcmtpbmcgcGF0 aCAoYnkgTVMtVykgYW5kIGFkbWluaXN0cmF0aXZlbHkgc3dpdGNoZWQgdG8gcHJvdGVjdGlvbiBw YXRoIChieSBNUy1QKS4NCg0KNC5BbiBvYnNlcnZhdGlvbiB0aGF0IEkgbWFkZSB0byB0aGUgcHNj LXByaW9yaXR5IGRyYWZ0IGlzIGFwcGxpY2FibGUgdG8gdGhpcyBkcmFmdCBhcyB3ZWxsIC0gSSBk byBub3QgdW5kZXJzdGFuZCB0aGUgcmVmZXJlbmNpbmcgb2YgYW4gTFMgZnJvbSBJVFUgLSB0aGlz IGlzIG5vdCBhIHN0YW5kYXJkcyBkb2N1bWVudCwganVzdCBhIGNvbnRyaWJ1dGlvbiBmb3IgZGlz Y3Vzc2lvbiBhbmQgc2hvdWxkIG5vdCBiZSByZWZlcmVuY2VkLg0KW1RhZXNpa10gSXQgY2FuIGJl IHJlZmxlY3RlZCBpbiB0aGUgbmV4dCByZXZpc2lvbiBvZiB0aGUgZHJhZnQuDQoNCjUuU2VjdGlv biA0Ljggb2YgdGhpcyBkb2N1bWVudCBoaWdobGlnaHRzIGEgcHJvYmxlbSB0aGF0IGlzIHJhaXNl ZCBieSB0aGlzIHNldCBvZiBkcmFmdHMgYW5kIHRoZWlyIG1ldGhvZCBvZiBwcmVzZW50YXRpb24u IEluIHRoaXMgc2VjdGlvbiwgYSAiY29ycmVjdGlvbiIgaXMgcHJvcG9zZWQgZm9yIHRleHQgdGhh dCBhcHBlYXJzIGluIFJGQzYzNzggc2VjdGlvbiA0LjMuMy4yLiBUaGlzICJjb3JyZWN0cyIgdGhl IG9yaWdpbmFsIHRleHQgd2l0aCBuZXcgdGV4dC4gSG93ZXZlciwgdGhpcyB0ZXh0IGlzIGFsc28g ImNvcnJlY3RlZCIgaW4gdGhlIHBzYy1wcmlvcml0eSBkcmFmdCEgTm93IHRoZSBxdWVzdGlvbiB0 aGF0IG5lZWRzIHRvIGJlIGFza2VkIGlzIHdoaWNoIGNvcnJlY3Rpb24gaXMgdGhlIGRlZmluaXRp dmUgY29ycmVjdGlvbiAtIHRoZSBvbmUgaW4gdGhpcyBkcmFmdCBvciB0aGUgb25lIGluIHRoZSBv dGhlciBkcmFmdD8gSXMgdGhpcyBkZXBlbmRlbnQgdXBvbiB0aGUgb3JkZXIgaW4gd2hpY2ggdGhl IGRyYWZ0cyB3aWxsIGJlIHB1Ymxpc2hlZD8NCg0KNi4gU2VjdGlvbiA0LjYgb2YgdGhlIGRyYWZ0 IHByZXNlbnRzIGEgdmVyeSBsZW5ndGh5IGRlc2NyaXB0aW9uIG9mIGFuICJhbGdvcml0aG0iIGZv ciByZXNvbHZpbmcgdGhlIHByaW9yaXR5IG9mIGlucHV0cyAiaGF2aW5nIGVxdWFsIHByaW9yaXR5 Ii4gVGhlIGNhc2Ugb2YgaW5wdXRzIGhhdmluZyB0aGUgc2FtZSBwcmlvcml0eSBhcmUgdGhvc2Ug aW4gd2hpY2ggdGhlIE1TIGFuZCBNUy1XIGlucHV0cyBhcmUgcmVjZWl2ZWQuIEkgYmVsaWV2ZSB0 aGF0IHRoaXMgc2V0IG9mIHJ1bGVzIGFyZSByYXRoZXIgY29uZnVzaW5nIGFuZCB0aGUgdXBzaG90 IG9mIHRoZSBleHBsYW5hdGlvbiBzZWVtcyB0byBiZSB0aGF0IGVpdGhlciB5b3UgdXNlIHRoZSBy dWxlIG9mICJmaXJzdC1jb21lIGZpcnN0LXNlcnZlZCIgb3IgdGhhdCBNUy1XIGhhcyBoaWdoZXIg cHJpb3JpdHksIGV4Y2VwdCBpbiBzb21lIHZlcnkgc3BlY2lmaWMgY29uZGl0aW9ucy4gSSBhbSBj ZXJ0YWluIHRoYXQgdGhpcyBjb3VsZCBiZSBtb3JlIGNsZWFybHkgc3RhdGVkIG9yIGV4cGxhaW5l ZC4NCltUYWVzaWtdIEl0IGNhbiBiZSByZXZpc2VkIGluIHRoZSBuZXh0IHZlcnNpb24gb2YgdGhl IGRyYWZ0LiBJIHdpbGwgYXBwcmVjaWF0ZSBpZiB5b3UgY2FuIHByb3Bvc2UgYW55IHRleHQgY2hh bmdlcyBmb3IgdGhpcyBzZWN0aW9uLg0KDQpCb3R0b20gbGluZSwgSSBkbyBub3QgdGhpbmsgdGhh dCB0aGlzIGRyYWZ0IGlzIHJlYWR5IGZvciBXRyBhY2NlcHRhbmNlLiBJIHdvdWxkIHN1Z2dlc3Qg dGhhdCBpdCBiZSByZXdyaXR0ZW4gdG8gdXBkYXRlIHRoZSBuZXcgZnVuY3Rpb25hbGl0eSB0aGF0 IGlzIGJlaW5nIHByb3Bvc2VkIHdoaWxlIGxlYXZpbmcgdGhlIGV4aXN0aW5nIG5vbi1jaGFuZ2Vk IGZ1bmN0aW9uYWxpdHkgYXMgaXMuIEkgYWxzbyBzdWdnZXN0IHRoYXQgdGhlIGZvcm1hdCBub3Qg YmUgYmFzZWQgb24gImNvcnJlY3Rpb25zIiB0byB0aGUgZXhpc3RpbmcgZHJhZnQgLSB0aGlzIGlz IG5vdCBhIGNvbnRyaWJ1dGlvbiB0byBhICJsaXZpbmciIGRvY3VtZW50LCBidXQgcmF0aGVyIGEg bmV3IGRvY3VtZW50IHRoYXQgdXBkYXRlcyB0aGUgcHJldmlvdXMgZG9jdW1lbnQuDQoNCkhvcGUg dGhpcyBoZWxwcywNCnlhYWNvdiB3ZWluZ2FydGVuDQoNCk9uIFRodSwgQXVnIDIyLCAyMDEzIGF0 IDEyOjA1IFBNLCBNYWNoIENoZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPG1haWx0bzptYWNoLmNo ZW5AaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGksDQoNCkkgaGF2ZSBkb25lIG15IE1QTFMtUlQgcmV2 aWV3IG9uIGRyYWZ0LWNkaC1tcGxzLXRwLXBzYy1ub24tcmV2ZXJ0aXZlLTAwLCBoZXJlIGFyZSBt eSBjb21tZW50czoNCg0KSSB0aGluayB0aGF0IG1vZGlmaWNhdGlvbiB0byBOb24tcmV2ZXJ0aXZl IG1vZGUsIGFkZGluZyBNUy1XIGFuZCByZW5hbWluZyBNUyB0byBNUy1GIGFyZSB2YWxpZCBwb2lu dHMuIEJ1dCBJIG5vdCBzdXJlIHdoZXRoZXIgdGhlcmUgaXMgYSBuZWVkIHRvIHJlcGxhY2UgIiBQ cm90ZWN0aW5nIGFkbWluaXN0cmF0aXZlIHN0YXRlIiB0byAiU3dpdGNoaW5nIGFkbWluaXN0cmF0 aXZlIHN0YXRlIi4NCg0KUmVhZCB0aHJvdWdoIHRoZSBkcmFmdCwgaXQgZ2l2ZXMgbWUgdGhlIGZl ZWxpbmcgdGhhdCB0aGUgZHJhZnQganVzdCBsaXN0cyBhIHNldCBvZiBlcnJhdGFzLCBJIGFtIG5v dCBzdXJlIHRoYXQgdGhpcyBpcyB0aGUgcmlnaHQgd2F5IHRvIHByb2dyZXNzIHRoZSBkcmFmdCBh cyBpdCBiZS4gSWYgdGhlIFdHIGhhdmUgdGhlIGNvbnNlbnN1cyBvbiB0aGUgY29udGVudCBvZiB0 aGUgZHJhZnQsIElNSE8sIGl0J3MgYmV0dGVyIHRvIGRvIGEgYmlzIHRvIFJGQzYzNzguDQoNCk1p bm9yIGNvbW1lbnQ6DQpJdCdzIGJldHRlciB0byBleHBhbmQgdGhlIGFjcm9ueW0gd2hlbiBmaXJz dCB1c2UsIGZvciBleGFtcGxlIHRoZSBNUy1GIGFuZCBNUy1XLCBJIGhhdmUgdG8gZ3Vlc3MgdGhl IG1lYW5pbmcgb2YgdW50aWwgSSBzZWUgdGhlIEFjcm9ueW1zIHNlY3Rpb24uDQoNCkJlc3QgcmVn YXJkcywNCk1hY2gNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMb2Eg QW5kZXJzc29uIFttYWlsdG86bG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+XQ0KPiBTZW50OiBG cmlkYXksIEF1Z3VzdCAwOSwgMjAxMyA4OjAxIFBNDQo+IFRvOiBFcmljIE9zYm9ybmUgKGVvc2Jv cm5lKTsgRXJpYyBHcmF5OyBrZW5qaS5mdWppaGlyYS5kakBoaXRhY2hpLmNvbTxtYWlsdG86a2Vu amkuZnVqaWhpcmEuZGpAaGl0YWNoaS5jb20+OyBZYWFjb3YNCj4gV2VpbmdhcnRlbjsgU2FtIEFs ZHJpbjsgTWFjaCBDaGVuOyBLYW1yYW4gUmF6YSAoc2tyYXphKTsgSGVuZGVyaWNreCwgV2ltDQo+ IChXaW0pOyB0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbTxtYWlsdG86dGhvbWFzLm1vcmluQG9yYW5n ZS5jb20+OyBtam9ya0BqdW5pcGVyLm5ldDxtYWlsdG86bWpvcmtAanVuaXBlci5uZXQ+DQo+IENj OiBkcmFmdC1vc2Jvcm5lLW1wbHMtcHNjLXVwZGF0ZXNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRy YWZ0LW9zYm9ybmUtbXBscy1wc2MtdXBkYXRlc0B0b29scy5pZXRmLm9yZz47DQo+IGRyYWZ0LWRq LW1wbHMtdHAtZXhlci1wc2NAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWRqLW1wbHMtdHAt ZXhlci1wc2NAdG9vbHMuaWV0Zi5vcmc+Ow0KPiBkcmFmdC1yaGQtbXBscy10cC1wc2Mtc2RAdG9v bHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1zZEB0b29scy5pZXRmLm9y Zz47DQo+IGRyYWZ0LWNkaC1tcGxzLXRwLXBzYy1ub24tcmV2ZXJ0aXZlQHRvb2xzLmlldGYub3Jn PG1haWx0bzpkcmFmdC1jZGgtbXBscy10cC1wc2Mtbm9uLXJldmVydGl2ZUB0b29scy5pZXRmLm9y Zz47DQo+IGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1wcmlvcml0eUB0b29scy5pZXRmLm9yZzxtYWls dG86ZHJhZnQtcmhkLW1wbHMtdHAtcHNjLXByaW9yaXR5QHRvb2xzLmlldGYub3JnPjsgbXBscy1j aGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPjsN Cj4gVklHT1VSRVVYLCBNQVJUSU4gKE1BUlRJTikNCj4gU3ViamVjdDogTVBMUy1SVCByZXZpZXcg b2YgbXBscyBwc2MgZG9jdW1lbnRzDQo+DQo+IEVyaWMsIEVyaWMsIEtlbmppLCBZYWNvb3YsIFNh bSwgTWFjaCwgS2FtcmFuLCBXaW0sIFRob21hcyBhbmQgTWFya3VzLA0KPg0KPiBZb3UgYmVlbiBz ZWxlY3RlZCBhcyBNUExTLVJUIHJldmlld2VycyBmb3IgYSBzZXQgb2YgcHNjIGRvY3VtZW50IHRo YXQgd2UNCj4gd2lsbCBzdGFydCBwcm9ncmVzcyB0aHJvdWdoIHRoZSBtcGxzIHdvcmtpbmcgZ3Jv dXAuDQo+DQo+IFRoZSBub3JtYWwgcnVsZXMgYW5kIHF1ZXN0aW9uIGZvciBhbiBNUExTLVJUIGFw cGx5Og0KPg0KPiAtLS0tLS0tLS0tIHF1b3RlIGZyb20gYSBzdGFuZGFyZCBtYWlsIGluaXRpYXRp bmcgTVBMUy1SVCByZXZpZXcgLS0tLS0tLQ0KPg0KPiBOb3RlIHRvIGF1dGhvcnM6IFlvdSBoYXZl IGJlZW4gQ0MnZCBvbiB0aGlzIGVtYWlsIHNvIHRoYXQgeW91IGNhbiBrbm93DQo+IHRoYXQgdGhp cyByZXZpZXcgaXMgZ29pbmcgb24uIEhvd2V2ZXIsIHBsZWFzZSBkbyBub3QgcmV2aWV3IHlvdXIg b3duDQo+IGRvY3VtZW50Lg0KPg0KPiBSZXZpZXdzIHNob3VsZCBjb21tZW50IG9uIHdoZXRoZXIg dGhlIGRvY3VtZW50IGlzIGNvaGVyZW50LCBpcyBpdA0KPiB1c2VmdWwgKGllLCBpcyBpdCBsaWtl bHkgdG8gYmUgYWN0dWFsbHkgdXNlZnVsIGluIG9wZXJhdGlvbmFsDQo+IG5ldHdvcmtzKSwgYW5k IGlzIHRoZSBkb2N1bWVudCB0ZWNobmljYWxseSBzb3VuZD8gIFdlIGFyZSBpbnRlcmVzdGVkDQo+ IGluIGtub3dpbmcgd2hldGhlciB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgdG8gYmUgY29uc2lkZXJl ZCBmb3IgV0cNCj4gYWRvcHRpb24gKGllLCBpdCBkb2Vzbid0IGhhdmUgdG8gYmUgcGVyZmVjdCBh dCB0aGlzIHBvaW50LCBidXQgc2hvdWxkIGJlDQo+IGEgZ29vZCBzdGFydCkuDQo+DQo+IFJldmll d3Mgc2hvdWxkIGJlIHNlbnQgdG8gdGhlIGRvY3VtZW50IGF1dGhvcnMsIFdHIGNvLWNoYWlycyBh bmQNCj4gV0cgc2VjcmV0YXJ5LCBhbmQgQ0MnZCB0byB0aGUgTVBMUyBXRyBlbWFpbCBsaXN0LiBJ ZiBuZWNlc3NhcnksIGNvbW1lbnRzDQo+IG1heSBiZSBzZW50IHByaXZhdGVseSB0byBvbmx5IHRo ZSBXRyBjaGFpcnMuDQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gZW5kIHF1b3RlIC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4gVGhlIG9ubHkgZGlmZmVyZW5jZSBpcyB0aGF0IHdl IHRha2Ugb24gbW9yZSB0aGFuIG9uZSBkb2N1bWVudCBhbmQgdGhhdA0KPiB0aGVyZSBhcmUgc3Vj aCBpbnRlci1kZXBlbmRlbmNpZXMgdGhhdCB3ZSB3YW50IHRvIGNvb3JkaW5hdGUgaG93IHRoZXkN Cj4gYXJlIHByb2dyZXNzZWQgdGhyb3VnaCBJRVRGLg0KPg0KPiBQbGVhc2UgcmVzcG9uZCAoYXQg bGVhc3QpIHRvIHRoZSB3ZyBjaGFpcnMgYW5kIE1hcnRpbiB0aGF0IHlvdSBhcmUNCj4gd2lsbGlu Zy91bi13aWxsaW5nIHRvIHVuZGVydGFrZSB0aGUgcmV2aWV3cy4NCj4NCj4gU2luY2Ugd2UgYXJl IHN0YXJ0aW5nIE1QTFMtUlQgcmV2aWV3cyBvZiA1IGRvY3VtZW50cywgd2l0aCA0IHJldmlld2Vy cw0KPiBmb3IgZWFjaCBkb2N1bWVudCBhbmQgZWFjaCByZXZpZXdlciBoYXZlIHR3byBkb2N1bWVu dHMsIHlvdSdsbCBuZWVkDQo+IHRvIHNlbmQgdGhlIHJldmlldyB3aXRoIHRoZSBkcmFmdCBuYW1l IGluIHRoZSBzdWJqZWN0IGxpbmUsIGkuZS4gZG8NCj4gbm90IHJlc3BvbmQgdG8gdGhpcyBtYWls IHdpdGggeW91ciByZXZpZXcgY29tbWVudHMuDQo+DQo+IFRoZXJlIGlzIGFsc28gYSAiUFNDIG1v ZGVzIiBkb2N1bWVudCBpbiB0aGUgcGlwZSwgY3VycmVudGx5IGl0IGlzIG91cg0KPiBvcGluaW9u IHRoYXQgdGhpcyBkb2N1bWVudCBpcyBuZWNlc3Nhcnkgd2hlbiB3ZSB3aWxsIHN0YXJ0IHRoZSB3 Z2xjJ3MNCj4gYnV0IGlzIG5vdCBuZWNlc3NhcnkgdG8gbWFrZSB0aGUgb3RoZXIgZHJhZnRzIHdn IGRvY3VtZW50cy4NCj4NCj4gQ2FuIHlvdSBwbGVhc2UgZmluaXNoIHlvdXIgcmV2aWV3cyBlb2Ig QXVndXN0IDIzLCAyMDEzLg0KPg0KPiBIZXJlIGlzIHRoZSBsaXN0IG9mIHJldmlld2VycyBwZXIg ZG9jdW1lbnQ6DQo+DQo+IGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1wcmlvcml0eQ0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gbWFjaCBjaGVuDQo+IHRob21hcyBtb3Jpbg0KPiB5 YWNvb3Ygd2VpbmdhcnRlbg0KPiBXaW0gSGVuZGVyaWNreA0KPg0KPiBkcmFmdC1jZGgtbXBscy10 cC1wc2Mtbm9uLXJldmVydGl2ZQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiBtYWNoIGNoZW4NCj4gZXJpYyBvc2Jvcm5lDQo+IGVyaWMgZ3JheQ0KPiB5YWNvb3Ygd2Vp bmdhcnRlbg0KPg0KPiBkcmFmdC1yaGQtbXBscy10cC1wc2Mtc2QNCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IGVyaWMgb3Nib3JuZQ0KPiBzYW0gYWxkcmluDQo+IGVyaWMgZ3JheQ0KPiBr YW1yYW4gcmF6YQ0KPg0KPiBkcmFmdC1kai1tcGxzLXRwLWV4ZXItcHNjDQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gc2FtIGFsZHJpbg0KPiBtYXJrdXMgam9yaw0KPiBrYW1yYW4gcmF6 YQ0KPiBrZW5qaSBmdWhpcmENCj4NCj4gZHJhZnQtb3Nib3JuZS1tcGxzLXBzYy11cGRhdGVzDQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBtYXJrdXMgam9yaw0KPiB0aG9tYXMg bW9yaW4NCj4ga2VuamkgZnVoaXJhDQo+IFdpbSBIZW5kZXJpY2t4DQo+DQo+DQo+IEF1dGhvcnMs DQo+DQo+IFBsZWFzZSBkbyBub3QgdXBkYXRlIHRoZSBkb2N1bWVudHMgZHVyaW5nIHRoZSByZXZp ZXcgcGVyaW9kLCB3ZSB3aWxsDQo+IHRlbGwgeW91IHdoZW4gdGhlIHJldmlldyBwZXJpb2QgaGFz IGVuZGVkLg0KPg0KPiBXaGVuIHdlIGNsb3NlIHRoZSByZXZpZXcgcGVyaW9kIHlvdSdsbCBuZWVk IHRvIGFkZHJlc3MgdGhlIGNvbW1lbnRzDQo+IGZyb20gdGhlIHJldmlld2VycyBhbmQgY29tbXVu aWNhdGUgd2l0aCB0aGVtIChwcmVmZXJhYmx5IG9uIHRoZSBtcGxzDQo+IHdnIG1haWxpbmcgbGlz dCkgdG8gbWFrZSBzdXJlIHRoYXQgdGhleSBhcmUgY29tZm9ydGFibGUgd2l0aCBob3cgdGhlDQo+ IGNvbW1lbnRzIGhhcyBiZWVuIGFkZHJlc3NlZC4NCj4NCj4NCj4gL0xvYQ0KPiBmb3IgdGhlIG1w bHMgd2cgY2hhaXJzDQo+DQo+IC0tDQo+DQo+DQo+IExvYSBBbmRlcnNzb24gICAgICAgICAgICAg ICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tPG1haWx0bzpsb2FAbWFpbDAx Lmh1YXdlaS5jb20+DQo+IFNlbmlvciBNUExTIEV4cGVydCAgICAgICAgICAgICAgICAgICAgICAg ICAgbG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+DQo+IEh1YXdlaSBUZWNobm9sb2dpZXMgKGNv bnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NDx0ZWw6JTJCNDYlMjA3MzklMjA4 MSUyMDIxJTIwNjQ+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KDQoNCi0t DQpUaGFueCBhbmQgQlIsDQp5YWFjb3YNCg0KU3RpbGwgbG9va2luZyBmb3IgbmV3IG9wcG9ydHVu aXR5DQo= --_000_AD98114A73E97041A2EDDCC3F3D10B031103C3CCSMTP4etriinfo_ Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable

Hi Yaacov,

 

Thank you for reviewing draft-cdh-mpls-tp-psc-non-revert= ive-00.

 

I discussed your comments with the other co-authors of t= his draft.

Some of your comments are not only related to this draft= but also related to all other psc drafts.

So, I will answer only to the comments specific to this = draft. Please see [Taesik] inline.

 

Best regards,

Taesik

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Yaacov Weingarten
Sent: Friday, August 23, 2013 3:56 AM
To: mpls@ietf.org
Cc: draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org; mpls-chairs@= tools.ietf.org
Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-reve= rtive-00//RE: MPLS-RT review of mpls psc documents

 

Hi,

 

I have conducted a review of dr= aft-cdh-mpls-tp-psc-non-revertive as reque= sted by the WG Chairs and have the following notes:

 

This draft purports to &qu= ot;update" RFC6378 to change non-revertive behavior of the Linear Prot= ection protocol. The method of updating the protocol is through the addition of a Manual Switch to Working operator command to affect the reve= rsion of traffic to the working path. Along the way the authors propose to = change the name of the Manual Switch operator command already defined in RF= C6378 and also change the name of the Protecting Administrative State to Switching Administrative State.

 

The format of the draft is= in the form of an errata correction document, indicating which paragraphs = in the RFC should be replaced and what new text should be substituted in its place.

 

This draft is part of a se= t of drafts that was discussed at the IETF87 meeting that will include an &= quot;overview" document that describes how to incorporate the new functionality described in those drafts.<= /o:p>

 

With this introduction I w= ould like to make the following observations:

1. There are accepted meth= ods used in the IETF to update a RFC by adding new functionality to a proto= col. Usually, this is done by writing a draft that describes the new functionality on top of the existing functionality rather than the= method used here. This is especially strange considering that they are not= changing the behavior of the existing functionality but just adding an add= itional command and describing its behavior. 

 

2. Based on this observati= on and the fact that all of the suggested "corrections" to the te= xt involving "Manual Switch" are to change the name but not the f= unctionality, I do not see the justification in changing the name of the existing Manual S= witch command since its functionality is essentially remaining as defined a= nd there is no cause for confusion with the new "Manual Switch to Work= ing" command.

[Taesik= ] For the sake of clarity I believe it is better to rename MS to MS-P to cl= early distinguish it from MS-W and for having =A1=B0symmetric names=A1=B1. = But I can live with current name.

 

3. I see problems with the suggestion to ch= ange the "Protecting Administrative State" to "Swi= tching Administrative State" since this requires the confusi= ng statement (in Section 4.9) "the user traffic SHALL be transported on either the protection = path or the working path" which is certainly always true for traffic t= hat is being transported. Why not create a new State? Or even better, since= the MS-W is meant to return the state to Normal why not just use Normal state?

[Taesik= ] Yes, traffic always flow on either the working or protection path. But, i= t should be noted that it is =A1=B0administratively=A1=B1 controlled. In th= at sense, we cannot say that a node is in =A1=B0Normal state=A1=B1 when MS-W command is issued. By replacing =A1=B0Protecting adm= inistrative state=A1=B1 by =A1=B0Switching administrative state=A1=B1, it c= an cover both cases: administratively switched to working path (by MS-W) an= d administratively switched to protection path (by MS-P).=

 

4.An observation that I made to the psc-pri= ority draft is applicable to this draft as well - I do not understand the r= eferencing of an LS from ITU - this is not a standards document, just a contribution for discussion and should not be referenced.

[Taesik= ] It can be reflected in the next revision of the draft.<= /p>

 

5.Section 4.8 of this document highlights a= problem that is raised by this set of drafts and their method of presentat= ion. In this section, a "correction" is proposed for text that appears in RFC6378 section 4.3.3.2. This "corrects" the ori= ginal text with new text. However, this text is also "corrected" = in the psc-priority draft! Now the question that needs to be asked is which= correction is the definitive correction - the one in this draft or the one in the other draft? Is this dependent upon the order= in which the drafts will be published?

 

6. Section 4.6 of the draft presents a very= lengthy description of an "algorithm" for resolving the priority= of inputs "having equal priority". The case of inputs having the= same priority are those in which the MS and MS-W inputs are received. I believe= that this set of rules are rather confusing and the upshot of the explanat= ion seems to be that either you use the rule of "first-come first-serv= ed" or that MS-W has higher priority, except in some very specific conditions. I am certain that this could be m= ore clearly stated or explained.

[Taesik= ] It can be revised in the next version of the draft. I will appreciate if = you can propose any text changes for this section.

 

Bottom line, I do not think that this draft= is ready for WG acceptance. I would suggest that it be rewritten to update= the new functionality that is being proposed while leaving the existing non-changed functionality as is. I also suggest that the form= at not be based on "corrections" to the existing draft - this is = not a contribution to a "living" document, but rather a new docum= ent that updates the previous document.

 

Hope this helps,

yaacov weingarten

=  

On Thu, Aug 22, 2013 at 12:05 P= M, Mach Chen <= mach.chen@huawei.com> wrote:

Hi,

I have done my MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00, he= re are my comments:

I think that modification to Non-revertive mode, adding MS-W and renaming M= S to MS-F are valid points. But I not sure whether there is a need to repla= ce " Protecting administrative state" to "Switching administ= rative state".

Read through the draft, it gives me the feeling that the draft just lists a= set of erratas, I am not sure that this is the right way to progress the d= raft as it be. If the WG have the consensus on the content of the draft, IM= HO, it's better to do a bis to RFC6378.

Minor comment:
It's better to expand the acronym when first use, for example the MS-F and = MS-W, I have to guess the meaning of until I see the Acronyms section.

Best regards,
Mach

> -----Original Message-----
> From: Loa Andersson [mailto:loa@pi.nu= ]
> Sent: Friday, August 09, 2013 8:01 PM
> To: Eric Osborne (eosborne); Eric Gray; kenji.fujihira.dj@hitachi.com; Yaacov
> Weingarten; Sam Aldrin; Mach Chen; Kamran Raza (skraza); Henderickx, W= im
> (Wim); thomas.morin@orange.= com; mjork@juniper.net
> Cc: d= raft-osborne-mpls-psc-updates@tools.ietf.org;
> draft-dj-m= pls-tp-exer-psc@tools.ietf.org;
> draft-rhd-m= pls-tp-psc-sd@tools.ietf.org;
> = draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org;
> draft= -rhd-mpls-tp-psc-priority@tools.ietf.org; mpls-chairs@tools.ietf.org;
> VIGOUREUX, MARTIN (MARTIN)
> Subject: MPLS-RT review of mpls psc documents
>
> Eric, Eric, Kenji, Yacoov, Sam, Mach, Kamran, Wim, Thomas and Markus,<= br> >
> You been selected as MPLS-RT reviewers for a set of psc document that = we
> will start progress through the mpls working group.
>
> The normal rules and question for an MPLS-RT apply:
>
> ---------- quote from a standard mail initiating MPLS-RT review ------= -
>
> Note to authors: You have been CC'd on this email so that you can know=
> that this review is going on. However, please do not review your own > document.
>
> Reviews should comment on whether the document is coherent, is it
> useful (ie, is it likely to be actually useful in operational
> networks), and is the document technically sound?  We are interes= ted
> in knowing whether the document is ready to be considered for WG
> adoption (ie, it doesn't have to be perfect at this point, but should = be
> a good start).
>
> Reviews should be sent to the document authors, WG co-chairs and
> WG secretary, and CC'd to the MPLS WG email list. If necessary, commen= ts
> may be sent privately to only the WG chairs.
>
> ---------------------- end quote -------------------------
>
> The only difference is that we take on more than one document and that=
> there are such inter-dependencies that we want to coordinate how they<= br> > are progressed through IETF.
>
> Please respond (at least) to the wg chairs and Martin that you are
> willing/un-willing to undertake the reviews.
>
> Since we are starting MPLS-RT reviews of 5 documents, with 4 reviewers=
> for each document and each reviewer have two documents, you'll need > to send the review with the draft name in the subject line, i.e. do > not respond to this mail with your review comments.
>
> There is also a "PSC modes" document in the pipe, currently = it is our
> opinion that this document is necessary when we will start the wglc's<= br> > but is not necessary to make the other drafts wg documents.
>
> Can you please finish your reviews eob August 23, 2013.
>
> Here is the list of reviewers per document:
>
> draft-rhd-mpls-tp-psc-priority
> ------------------------------
> mach chen
> thomas morin
> yacoov weingarten
> Wim Henderickx
>
> draft-cdh-mpls-tp-psc-non-revertive
> -----------------------------------
> mach chen
> eric osborne
> eric gray
> yacoov weingarten
>
> draft-rhd-mpls-tp-psc-sd
> ------------------------
> eric osborne
> sam aldrin
> eric gray
> kamran raza
>
> draft-dj-mpls-tp-exer-psc
> -------------------------
> sam aldrin
> markus jork
> kamran raza
> kenji fuhira
>
> draft-osborne-mpls-psc-updates
> ------------------------------
> markus jork
> thomas morin
> kenji fuhira
> Wim Henderickx
>
>
> Authors,
>
> Please do not update the documents during the review period, we will > tell you when the review period has ended.
>
> When we close the review period you'll need to address the comments > from the reviewers and communicate with them (preferably on the mpls > wg mailing list) to make sure that they are comfortable with how the > comments has been addressed.
>
>
> /Loa
> for the mpls wg chairs
>
> --
>
>
> Loa Andersson                 =        email: loa@mail01.huawei.com
> Senior MPLS Expert               &n= bsp;          loa@pi.= nu
> Huawei Technologies (consultant)     phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls



 

--

Thanx and BR,=

yaacov

 

Still looking for new opport= unity

--_000_AD98114A73E97041A2EDDCC3F3D10B031103C3CCSMTP4etriinfo_-- From wyaacov@gmail.com Wed Aug 28 03:02:38 2013 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 8383D11E817C for ; Wed, 28 Aug 2013 03:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqMvkZtomDwP for ; Wed, 28 Aug 2013 03:02:38 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 37CC011E817B for ; Wed, 28 Aug 2013 03:02:34 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b12so3028725wgh.30 for ; Wed, 28 Aug 2013 03:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2T0+JAwlKIGdc1DAfi7yU0HQr6FWe9Q/RT8PLdkJq4A=; b=VqAMhJNoqzLrfLEN00bW02/27Xv7syAjIDE7DHGffD2A27XR1ifMtiouz5s1LQvDJz jPe6d0HvIbm/anGn55eFaW+IfYv/OuYIDqQWFBH8+TwcFLffxlKrfKExNMJGDqls3Sux +ps7cWkGaMDwgppbKfUYiSjReD+P89qo88tTewa82aYM+GJBN0vYONKgo/C40Cl+xFqn euOb7RrI/e/A9el7+WZHXWllWGZ9/n6n3R3NDkwRAfsIYegjT0AUbrbOvI08TF8lmsf5 Mh84+qUxDg4ubYB87wKr9e7BNhF7n05s8mQ04bHrGb3FXbHESWqfv8/Dx18YtG+mxsrt m/yQ== MIME-Version: 1.0 X-Received: by 10.194.109.68 with SMTP id hq4mr18403872wjb.12.1377684153306; Wed, 28 Aug 2013 03:02:33 -0700 (PDT) Received: by 10.194.164.200 with HTTP; Wed, 28 Aug 2013 03:02:33 -0700 (PDT) In-Reply-To: References: <5204D9DE.6060405@pi.nu> Date: Wed, 28 Aug 2013 13:02:33 +0300 Message-ID: From: Yaacov Weingarten To: =?UTF-8?B?7KCV7YOc7Iud?= Content-Type: multipart/alternative; boundary=089e0102e6da92134904e4ff1651 Cc: "mpls@ietf.org" , "draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents 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, 28 Aug 2013 10:02:38 -0000 --089e0102e6da92134904e4ff1651 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Taesik, hi Thank you for your reply to my comments. While I appreciate the philosophy that is behind the proposed format for this draft - and that some of your considerations (for example, your need to change the name of Manual Switch - something that would not be needed if you just wrote an update that introduced the new operator command) are a direct result of this philosophy= . However, I found one of your replies to be of special interest. On Wed, Aug 28, 2013 at 3:10 AM, =EC=A0=95=ED=83=9C=EC=8B=9D wrote: > Hi Yaacov,**** > > ** ** > > > > ** ** > > 3. I see problems with the suggestion to change the > "Protecting Administrative State" to "Switching Administrative State" sin= ce > this requires the confusing statement (in Section 4.9) "the user traffic > SHALL be transported on either the protection path or the working path" > which is certainly always true for traffic that is being transported. Why > not create a new State? Or even better, since the MS-W is meant to return > the state to Normal why not just use Normal state?**** > > [Taesik] Yes, traffic always flow on either the working or protection > path. But, it should be noted that it is =E2=80=9Cadministratively=E2=80= =9D controlled. In > that sense, we cannot say that a node is in =E2=80=9CNormal state=E2=80= =9D when MS-W > command is issued. By replacing =E2=80=9CProtecting administrative state= =E2=80=9D by > =E2=80=9CSwitching administrative state=E2=80=9D, it can cover both cases= : administratively > switched to working path (by MS-W) and administratively switched to > protection path (by MS-P). > <> When I first read this draft I was under the impression that (as impied by the title of the draft) the main justification for introducing the MS-W command was to solve the problem of reverting traffic from a non-revertive state and returning to the Normal State. However, according to this explanation, using this command does not return you to the Normal State, but rather to some intermediate state, since you are "administartively controlled"! So can you please explain how does the operator revert from the non-revertive situation to the Normal State? (Is it a sequence of MS-W and then immediately Clear? If so, why is this different from LO and immediate Clear?) > **** > > ** ** > > > > -- > Thanx and BR, yaacov *Still looking for new opportunity* --089e0102e6da92134904e4ff1651 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Taesik, hi
=C2=A0
Thank you for y= our reply to my comments.=C2=A0While I appreciate the philosophy that is be= hind the proposed format for this draft - and that some of your considerati= ons (for example, your need to change the name of Manual Switch - something= that would not be needed if you just wrote an update that introduced the n= ew operator command) are a direct result of this philosophy.
=C2=A0
However, I found one of your replies to be of special= interest.
= On Wed, Aug 28, 2013 at 3:10 AM, =EC=A0=95=ED=83=9C=EC=8B=9D <cts@etri.re.kr<= /a>> wrote:

Hi Yaac= ov,

= =C2=A0

<trimmed content>

= =C2=A0

3. I see problems with the suggestion to ch= ange the "Protecting=C2=A0Administrative=C2=A0State" to "Swi= tching=C2=A0Administrative=C2=A0State" since this requires the confusi= ng statement (in Section 4.9) "the user traffic SHALL be transported on either the protection = path or the working path" which is certainly always true for traffic t= hat is being transported. Why not create a new State? Or even better, since= the MS-W is meant to return the state to Normal why not just use Normal state?

= [Taesik] Yes, traffic always flow on either the working or protection path.= But, it should be noted that it is =E2=80=9Cadministratively=E2=80=9D cont= rolled. In that sense, we cannot say that a node is in =E2=80=9CNormal state=E2=80=9D when MS-W command is issued. By replacing =E2=80=9CProtecti= ng administrative state=E2=80=9D by =E2=80=9CSwitching administrative state= =E2=80=9D, it can cover both cases: administratively switched to working pa= th (by MS-W) and administratively switched to protection path (by MS-P).

=C2=A0
<<yw>&g= t; When I first read this draft I was under the impression that (as impied = by the title of the draft)=C2=A0the main justification for introducing the = MS-W command was to solve the problem of reverting traffic from a non-rever= tive state and returning to the Normal State. However, according to this ex= planation, using this command does not return you to the Normal State, but = rather to some intermediate state, since you are "administartively con= trolled"!=C2=A0
=C2=A0
So can you please explain how does the operator rever= t from the non-revertive situation to the Normal State? (Is it a sequence o= f MS-W and then immediately Clear? If so, why is this different from LO and= immediate Clear?)
=

= =C2=A0

<trimmed content>


--
--089e0102e6da92134904e4ff1651-- From cts@etri.re.kr Wed Aug 28 04:37:28 2013 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 3D3C311E817F for ; Wed, 28 Aug 2013 04:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.822 X-Spam-Level: X-Spam-Status: No, score=-99.822 tagged_above=-999 required=5 tests=[AWL=2.476, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 mJ16ASt8UbSK for ; Wed, 28 Aug 2013 04:37:16 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5311711E816F for ; Wed, 28 Aug 2013 04:37:13 -0700 (PDT) Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 28 Aug 2013 20:37:06 +0900 Received: from SMTP4.etri.info ([169.254.3.68]) by SMTP3.etri.info ([129.254.28.73]) with mapi id 14.01.0355.002; Wed, 28 Aug 2013 20:37:02 +0900 From: =?utf-8?B?7KCV7YOc7Iud?= To: Yaacov Weingarten Thread-Topic: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents Thread-Index: AQHOlPghtHYllm9ZlUWJChJo0dWyb5mgbNEAgACk5gCACMSvQIAAFDeAgACpW+A= Date: Wed, 28 Aug 2013 11:37:01 +0000 Message-ID: References: <5204D9DE.6060405@pi.nu> In-Reply-To: Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.73.69] Content-Type: multipart/alternative; boundary="_000_AD98114A73E97041A2EDDCC3F3D10B031103E5D7SMTP4etriinfo_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents 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, 28 Aug 2013 11:37:28 -0000 --_000_AD98114A73E97041A2EDDCC3F3D10B031103E5D7SMTP4etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWWFhY292LA0KDQpJIGFuc3dlcmVkIHRvIHlvdXIgcXVlc3Rpb24uIFBsZWFzZSBzZWUgW1Rh ZXNpazJdIGlubGluZS4NCg0KQmVzdCByZWdhcmRzLA0KVGFlc2lrDQoNCkZyb206IFlhYWNvdiBX ZWluZ2FydGVuIFttYWlsdG86d3lhYWNvdkBnbWFpbC5jb21dDQpTZW50OiBXZWRuZXNkYXksIEF1 Z3VzdCAyOCwgMjAxMyA3OjAzIFBNDQpUbzog7KCV7YOc7IudDQpDYzogbXBsc0BpZXRmLm9yZzsg ZHJhZnQtY2RoLW1wbHMtdHAtcHNjLW5vbi1yZXZlcnRpdmVAdG9vbHMuaWV0Zi5vcmc7IG1wbHMt Y2hhaXJzQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIE1QTFMtUlQgcmV2aWV3 IG9uIGRyYWZ0LWNkaC1tcGxzLXRwLXBzYy1ub24tcmV2ZXJ0aXZlLTAwLy9SRTogTVBMUy1SVCBy ZXZpZXcgb2YgbXBscyBwc2MgZG9jdW1lbnRzDQoNClRhZXNpaywgaGkNCg0KVGhhbmsgeW91IGZv ciB5b3VyIHJlcGx5IHRvIG15IGNvbW1lbnRzLiBXaGlsZSBJIGFwcHJlY2lhdGUgdGhlIHBoaWxv c29waHkgdGhhdCBpcyBiZWhpbmQgdGhlIHByb3Bvc2VkIGZvcm1hdCBmb3IgdGhpcyBkcmFmdCAt IGFuZCB0aGF0IHNvbWUgb2YgeW91ciBjb25zaWRlcmF0aW9ucyAoZm9yIGV4YW1wbGUsIHlvdXIg bmVlZCB0byBjaGFuZ2UgdGhlIG5hbWUgb2YgTWFudWFsIFN3aXRjaCAtIHNvbWV0aGluZyB0aGF0 IHdvdWxkIG5vdCBiZSBuZWVkZWQgaWYgeW91IGp1c3Qgd3JvdGUgYW4gdXBkYXRlIHRoYXQgaW50 cm9kdWNlZCB0aGUgbmV3IG9wZXJhdG9yIGNvbW1hbmQpIGFyZSBhIGRpcmVjdCByZXN1bHQgb2Yg dGhpcyBwaGlsb3NvcGh5Lg0KDQpIb3dldmVyLCBJIGZvdW5kIG9uZSBvZiB5b3VyIHJlcGxpZXMg dG8gYmUgb2Ygc3BlY2lhbCBpbnRlcmVzdC4NCk9uIFdlZCwgQXVnIDI4LCAyMDEzIGF0IDM6MTAg QU0sIOygle2DnOyLnSA8Y3RzQGV0cmkucmUua3I8bWFpbHRvOmN0c0BldHJpLnJlLmtyPj4gd3Jv dGU6DQpIaSBZYWFjb3YsDQoNCjx0cmltbWVkIGNvbnRlbnQ+DQoNCjMuIEkgc2VlIHByb2JsZW1z IHdpdGggdGhlIHN1Z2dlc3Rpb24gdG8gY2hhbmdlIHRoZSAiUHJvdGVjdGluZyBBZG1pbmlzdHJh dGl2ZSBTdGF0ZSIgdG8gIlN3aXRjaGluZyBBZG1pbmlzdHJhdGl2ZSBTdGF0ZSIgc2luY2UgdGhp cyByZXF1aXJlcyB0aGUgY29uZnVzaW5nIHN0YXRlbWVudCAoaW4gU2VjdGlvbiA0LjkpICJ0aGUg dXNlciB0cmFmZmljIFNIQUxMIGJlIHRyYW5zcG9ydGVkIG9uIGVpdGhlciB0aGUgcHJvdGVjdGlv biBwYXRoIG9yIHRoZSB3b3JraW5nIHBhdGgiIHdoaWNoIGlzIGNlcnRhaW5seSBhbHdheXMgdHJ1 ZSBmb3IgdHJhZmZpYyB0aGF0IGlzIGJlaW5nIHRyYW5zcG9ydGVkLiBXaHkgbm90IGNyZWF0ZSBh IG5ldyBTdGF0ZT8gT3IgZXZlbiBiZXR0ZXIsIHNpbmNlIHRoZSBNUy1XIGlzIG1lYW50IHRvIHJl dHVybiB0aGUgc3RhdGUgdG8gTm9ybWFsIHdoeSBub3QganVzdCB1c2UgTm9ybWFsIHN0YXRlPw0K W1RhZXNpa10gWWVzLCB0cmFmZmljIGFsd2F5cyBmbG93IG9uIGVpdGhlciB0aGUgd29ya2luZyBv ciBwcm90ZWN0aW9uIHBhdGguIEJ1dCwgaXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgaXQgaXMg4oCc YWRtaW5pc3RyYXRpdmVseeKAnSBjb250cm9sbGVkLiBJbiB0aGF0IHNlbnNlLCB3ZSBjYW5ub3Qg c2F5IHRoYXQgYSBub2RlIGlzIGluIOKAnE5vcm1hbCBzdGF0ZeKAnSB3aGVuIE1TLVcgY29tbWFu ZCBpcyBpc3N1ZWQuIEJ5IHJlcGxhY2luZyDigJxQcm90ZWN0aW5nIGFkbWluaXN0cmF0aXZlIHN0 YXRl4oCdIGJ5IOKAnFN3aXRjaGluZyBhZG1pbmlzdHJhdGl2ZSBzdGF0ZeKAnSwgaXQgY2FuIGNv dmVyIGJvdGggY2FzZXM6IGFkbWluaXN0cmF0aXZlbHkgc3dpdGNoZWQgdG8gd29ya2luZyBwYXRo IChieSBNUy1XKSBhbmQgYWRtaW5pc3RyYXRpdmVseSBzd2l0Y2hlZCB0byBwcm90ZWN0aW9uIHBh dGggKGJ5IE1TLVApLg0KDQo8PHl3Pj4gV2hlbiBJIGZpcnN0IHJlYWQgdGhpcyBkcmFmdCBJIHdh cyB1bmRlciB0aGUgaW1wcmVzc2lvbiB0aGF0IChhcyBpbXBpZWQgYnkgdGhlIHRpdGxlIG9mIHRo ZSBkcmFmdCkgdGhlIG1haW4ganVzdGlmaWNhdGlvbiBmb3IgaW50cm9kdWNpbmcgdGhlIE1TLVcg Y29tbWFuZCB3YXMgdG8gc29sdmUgdGhlIHByb2JsZW0gb2YgcmV2ZXJ0aW5nIHRyYWZmaWMgZnJv bSBhIG5vbi1yZXZlcnRpdmUgc3RhdGUgYW5kIHJldHVybmluZyB0byB0aGUgTm9ybWFsIFN0YXRl LiBIb3dldmVyLCBhY2NvcmRpbmcgdG8gdGhpcyBleHBsYW5hdGlvbiwgdXNpbmcgdGhpcyBjb21t YW5kIGRvZXMgbm90IHJldHVybiB5b3UgdG8gdGhlIE5vcm1hbCBTdGF0ZSwgYnV0IHJhdGhlciB0 byBzb21lIGludGVybWVkaWF0ZSBzdGF0ZSwgc2luY2UgeW91IGFyZSAiYWRtaW5pc3RhcnRpdmVs eSBjb250cm9sbGVkIiENCg0KU28gY2FuIHlvdSBwbGVhc2UgZXhwbGFpbiBob3cgZG9lcyB0aGUg b3BlcmF0b3IgcmV2ZXJ0IGZyb20gdGhlIG5vbi1yZXZlcnRpdmUgc2l0dWF0aW9uIHRvIHRoZSBO b3JtYWwgU3RhdGU/IChJcyBpdCBhIHNlcXVlbmNlIG9mIE1TLVcgYW5kIHRoZW4gaW1tZWRpYXRl bHkgQ2xlYXI/IElmIHNvLCB3aHkgaXMgdGhpcyBkaWZmZXJlbnQgZnJvbSBMTyBhbmQgaW1tZWRp YXRlIENsZWFyPykNCg0KW1RhZXNpazJdIElmIHlvdSBpc3N1ZSBMTywgeW91IGNhbm5vdCBwcm90 ZWN0IHRyYWZmaWMgd2hlbiBTRiBvciBTRCBpcyBzdWJzZXF1ZW50bHkgZGV0ZWN0ZWQgb24gdGhl IHdvcmtpbmcgcGF0aCB1bnRpbCB0aGUgTE8gaXMgY2xlYXJlZC4gT24gdGhlIG90aGVyIGhhbmQs IGlmIHlvdSB1c2UgTVMtVywgdHJhZmZpYyBjYW4gYmUgcHJvdGVjdGVkIGJlY2F1c2UgdGhlIHBy aW9yaXR5IG9mIE1TLVcgaXMgbG93ZXIgdGhhbiBTRiBvciBTRC4NCg0KPHRyaW1tZWQgY29udGVu dD4NCg0KLS0NClRoYW54IGFuZCBCUiwNCnlhYWNvdg0KDQpTdGlsbCBsb29raW5nIGZvciBuZXcg b3Bwb3J0dW5pdHkNCg== --_000_AD98114A73E97041A2EDDCC3F3D10B031103E5D7SMTP4etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 6rW066a8Ow0KCXBhbm9zZS0xOjIgMTEgNiAwIDAgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk66rW066a8Ow0KCXBhbm9zZS0xOjIgMTEgNiAwIDAgMSAxIDEgMSAxO30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IuunkeydgCDqs6DrlJUiOw0KCXBhbm9zZS0xOjIgMTEg NSAzIDIgMCAwIDIgMCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxA66eR7J2AIOqzoOuUlSI7DQoJcGFub3NlLTE6MiAxMSA1IDMgMiAwIDAgMiAwIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDqtbTrprwiOw0KCXBhbm9zZS0xOjIgMTEgNiAwIDAg MSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6wrlkMcOHNDDCrGUwwrUxNTsN CglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IlxAwrlkMcOHNDDCrGUwwrUxNSI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5Ouq1tOumvDt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToi66eR7J2AIOqzoOuUlSI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LWZhbWlseToi66eR7J2AIOqzoOuUlSI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjozLjBjbSA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IktPIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0id29yZC1icmVhazpicmVhay1oYW5n dWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDvrp5HsnYAg6rOg65SVJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFlhYWNvdiw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0id29yZC1icmVh azpicmVhay1oYW5ndWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDvrp5HsnYAg6rOg65SVJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ3 b3JkLWJyZWFrOmJyZWFrLWhhbmd1bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+unkeydgCDqs6DrlJUmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSBhbnN3ZXJlZCB0byB5b3VyIHF1ZXN0aW9uLiBQbGVhc2Ugc2VlIFtUYWVzaWsyXSBp bmxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 IndvcmQtYnJlYWs6YnJlYWstaGFuZ3VsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q766eR7J2AIOqzoOuUlSZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0id29yZC1icmVhazpicmVhay1oYW5ndWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDvrp5HsnYAg6rOg65SVJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0id29yZC1icmVhazpicmVhay1oYW5ndWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDvrp5Hs nYAg6rOg65SVJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRhZXNpazxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ3b3JkLWJyZWFrOmJyZWFrLWhhbmd1bCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O+unkeydgCDqs6DrlJUmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gWWFhY292IFdlaW5nYXJ0ZW4gW21haWx0bzp3eWFhY292QGdt YWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEF1Z3VzdCAyOCwgMjAxMyA3 OjAzIFBNPGJyPg0KPGI+VG86PC9iPiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPuygle2DnOyLnTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxicj4NCjxiPkNjOjwvYj4gbXBsc0BpZXRmLm9yZzsgZHJhZnQtY2RoLW1wbHMtdHAtcHNj LW5vbi1yZXZlcnRpdmVAdG9vbHMuaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbXBsc10gTVBMUy1SVCByZXZpZXcgb24gZHJhZnQt Y2RoLW1wbHMtdHAtcHNjLW5vbi1yZXZlcnRpdmUtMDAvL1JFOiBNUExTLVJUIHJldmlldyBvZiBt cGxzIHBzYyBkb2N1bWVudHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGFlc2lr LCBoaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhh bmsgeW91IGZvciB5b3VyIHJlcGx5IHRvIG15IGNvbW1lbnRzLiZuYnNwO1doaWxlIEkgYXBwcmVj aWF0ZSB0aGUgcGhpbG9zb3BoeSB0aGF0IGlzIGJlaGluZCB0aGUgcHJvcG9zZWQgZm9ybWF0IGZv ciB0aGlzIGRyYWZ0IC0gYW5kIHRoYXQgc29tZSBvZiB5b3VyIGNvbnNpZGVyYXRpb25zIChmb3Ig ZXhhbXBsZSwgeW91ciBuZWVkIHRvIGNoYW5nZSB0aGUgbmFtZSBvZiBNYW51YWwNCiBTd2l0Y2gg LSBzb21ldGhpbmcgdGhhdCB3b3VsZCBub3QgYmUgbmVlZGVkIGlmIHlvdSBqdXN0IHdyb3RlIGFu IHVwZGF0ZSB0aGF0IGludHJvZHVjZWQgdGhlIG5ldyBvcGVyYXRvciBjb21tYW5kKSBhcmUgYSBk aXJlY3QgcmVzdWx0IG9mIHRoaXMgcGhpbG9zb3BoeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhvd2V2ZXIsIEkgZm91bmQgb25lIG9mIHlvdXIgcmVw bGllcyB0byBiZSBvZiBzcGVjaWFsIGludGVyZXN0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5PbiBXZWQsIEF1ZyAyOCwgMjAxMyBhdCAzOjEwIEFNLCA8L3NwYW4+7KCV7YOc7IudPHNw YW4gbGFuZz0iRU4tVVMiPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmN0c0BldHJpLnJlLmtyIiB0YXJn ZXQ9Il9ibGFuayI+Y3RzQGV0cmkucmUua3I8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O8K5ZDHDhzQw wqxlMMK1MTUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgWWFhY292 LDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZsdDt0cmltbWVkIGNvbnRlbnQm Z3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4zLiBJIHNlZSBwcm9i bGVtcyB3aXRoIHRoZSBzdWdnZXN0aW9uIHRvIGNoYW5nZSB0aGUgJnF1b3Q7UHJvdGVjdGluZyZu YnNwO0FkbWluaXN0cmF0aXZlJm5ic3A7U3RhdGUmcXVvdDsgdG8gJnF1b3Q7U3dpdGNoaW5nJm5i c3A7QWRtaW5pc3RyYXRpdmUmbmJzcDtTdGF0ZSZxdW90Ow0KIHNpbmNlIHRoaXMgcmVxdWlyZXMg dGhlIGNvbmZ1c2luZyBzdGF0ZW1lbnQgKGluIFNlY3Rpb24gNC45KSAmcXVvdDt0aGUgdXNlciB0 cmFmZmljIFNIQUxMIGJlIHRyYW5zcG9ydGVkIG9uIGVpdGhlciB0aGUgcHJvdGVjdGlvbiBwYXRo IG9yIHRoZSB3b3JraW5nIHBhdGgmcXVvdDsgd2hpY2ggaXMgY2VydGFpbmx5IGFsd2F5cyB0cnVl IGZvciB0cmFmZmljIHRoYXQgaXMgYmVpbmcgdHJhbnNwb3J0ZWQuIFdoeSBub3QgY3JlYXRlIGEg bmV3IFN0YXRlPyBPciBldmVuDQogYmV0dGVyLCBzaW5jZSB0aGUgTVMtVyBpcyBtZWFudCB0byBy ZXR1cm4gdGhlIHN0YXRlIHRvIE5vcm1hbCB3aHkgbm90IGp1c3QgdXNlIE5vcm1hbCBzdGF0ZT88 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltUYWVzaWtdIFllcywgdHJhZmZpYyBhbHdheXMgZmxvdyBv biBlaXRoZXIgdGhlIHdvcmtpbmcgb3IgcHJvdGVjdGlvbiBwYXRoLiBCdXQsIGl0IHNob3VsZCBi ZSBub3RlZCB0aGF0IGl0IGlzIOKAnGFkbWluaXN0cmF0aXZlbHnigJ0gY29udHJvbGxlZC4NCiBJ biB0aGF0IHNlbnNlLCB3ZSBjYW5ub3Qgc2F5IHRoYXQgYSBub2RlIGlzIGluIOKAnE5vcm1hbCBz dGF0ZeKAnSB3aGVuIE1TLVcgY29tbWFuZCBpcyBpc3N1ZWQuIEJ5IHJlcGxhY2luZyDigJxQcm90 ZWN0aW5nIGFkbWluaXN0cmF0aXZlIHN0YXRl4oCdIGJ5IOKAnFN3aXRjaGluZyBhZG1pbmlzdHJh dGl2ZSBzdGF0ZeKAnSwgaXQgY2FuIGNvdmVyIGJvdGggY2FzZXM6IGFkbWluaXN0cmF0aXZlbHkg c3dpdGNoZWQgdG8gd29ya2luZyBwYXRoIChieSBNUy1XKSBhbmQNCiBhZG1pbmlzdHJhdGl2ZWx5 IHN3aXRjaGVkIHRvIHByb3RlY3Rpb24gcGF0aCAoYnkgTVMtUCkuPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZsdDsmbHQ7eXcmZ3Q7Jmd0OyBXaGVuIEkgZmlyc3Qg cmVhZCB0aGlzIGRyYWZ0IEkgd2FzIHVuZGVyIHRoZSBpbXByZXNzaW9uIHRoYXQgKGFzIGltcGll ZCBieSB0aGUgdGl0bGUgb2YgdGhlIGRyYWZ0KSZuYnNwO3RoZSBtYWluIGp1c3RpZmljYXRpb24g Zm9yIGludHJvZHVjaW5nIHRoZSBNUy1XIGNvbW1hbmQgd2FzIHRvIHNvbHZlIHRoZSBwcm9ibGVt IG9mIHJldmVydGluZyB0cmFmZmljIGZyb20gYSBub24tcmV2ZXJ0aXZlDQogc3RhdGUgYW5kIHJl dHVybmluZyB0byB0aGUgTm9ybWFsIFN0YXRlLiBIb3dldmVyLCBhY2NvcmRpbmcgdG8gdGhpcyBl eHBsYW5hdGlvbiwgdXNpbmcgdGhpcyBjb21tYW5kIGRvZXMgbm90IHJldHVybiB5b3UgdG8gdGhl IE5vcm1hbCBTdGF0ZSwgYnV0IHJhdGhlciB0byBzb21lIGludGVybWVkaWF0ZSBzdGF0ZSwgc2lu Y2UgeW91IGFyZSAmcXVvdDthZG1pbmlzdGFydGl2ZWx5IGNvbnRyb2xsZWQmcXVvdDshJm5ic3A7 DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNvIGNh biB5b3UgcGxlYXNlIGV4cGxhaW4gaG93IGRvZXMgdGhlIG9wZXJhdG9yIHJldmVydCBmcm9tIHRo ZSBub24tcmV2ZXJ0aXZlIHNpdHVhdGlvbiB0byB0aGUgTm9ybWFsIFN0YXRlPyAoSXMgaXQgYSBz ZXF1ZW5jZSBvZiBNUy1XIGFuZCB0aGVuIGltbWVkaWF0ZWx5IENsZWFyPyBJZiBzbywgd2h5IGlz IHRoaXMgZGlmZmVyZW50IGZyb20gTE8gYW5kIGltbWVkaWF0ZSBDbGVhcj8pPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+unkeydgCDqs6DrlJUmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O+unkeydgCDqs6DrlJUmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1RhZXNpazJd IElmIHlvdSBpc3N1ZSBMTywgeW91IGNhbm5vdCBwcm90ZWN0IHRyYWZmaWMgd2hlbiBTRiBvciBT RCBpcyBzdWJzZXF1ZW50bHkgZGV0ZWN0ZWQgb24gdGhlIHdvcmtpbmcgcGF0aCB1bnRpbCB0aGUg TE8gaXMgY2xlYXJlZC4gT24gdGhlIG90aGVyIGhhbmQsIGlmDQogeW91IHVzZSBNUy1XLCB0cmFm ZmljIGNhbiBiZSBwcm90ZWN0ZWQgYmVjYXVzZSB0aGUgcHJpb3JpdHkgb2YgTVMtVyBpcyBsb3dl ciB0aGFuIFNGIG9yIFNELjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jmx0O3RyaW1tZWQgY29udGVudCZndDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PGJyPg0KLS0gPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW54IGFuZCBCUiw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPnlhYWNvdjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBs YW5nPSJFTi1VUyI+U3RpbGwgbG9va2luZyBmb3IgbmV3IG9wcG9ydHVuaXR5PC9zcGFuPjwvaT48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AD98114A73E97041A2EDDCC3F3D10B031103E5D7SMTP4etriinfo_-- From wyaacov@gmail.com Wed Aug 28 05:17:44 2013 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 0F18821E8050 for ; Wed, 28 Aug 2013 05:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[AWL=-1.337, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwxTYngLvwnI for ; Wed, 28 Aug 2013 05:17:41 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5EA11E8132 for ; Wed, 28 Aug 2013 05:17:41 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id p57so5054536wes.2 for ; Wed, 28 Aug 2013 05:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oDULyCD+3FsSIPPB+m4Lh4Nxvn0kM1TMkdL1+mYT2p8=; b=nXmmpqRsPV6Bfof3jGxnMlE8cfCQAK9/yeBf2QEsFEBGPkshoJ9Yz+a9wzILtgRzd0 q0UcfbqR+QXhOEllbBzyz35qD30rwAMrto6l/pnYCS2Yntbj5lOq0b9BHeg31vhPiKqi ciwqi5zlrhRGeVpAF9AaMWUWatwgE6+sIO00o1iv7LOkxIel5eT9Yy5TBmC6nueMMUCx 16FsokGw7EeM/uirMLDUeIE5QDeXl4fwkvmPaaZqMPBaqAPIC6NzwGRN2h+o8MWA6sn8 6N7ojPkvLg0uL4VPLfzKbKJSfndKgWErrFeKgiH8iIgbOFeH8qecE6QSUwulxI9PVmSb MAcg== MIME-Version: 1.0 X-Received: by 10.194.93.135 with SMTP id cu7mr1469432wjb.73.1377692257921; Wed, 28 Aug 2013 05:17:37 -0700 (PDT) Received: by 10.194.164.200 with HTTP; Wed, 28 Aug 2013 05:17:37 -0700 (PDT) In-Reply-To: References: <5204D9DE.6060405@pi.nu> Date: Wed, 28 Aug 2013 15:17:37 +0300 Message-ID: From: Yaacov Weingarten To: =?UTF-8?B?7KCV7YOc7Iud?= Content-Type: multipart/alternative; boundary=047d7bb03eb6a4b05c04e500f9cf Cc: "mpls@ietf.org" , "draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents 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, 28 Aug 2013 12:17:44 -0000 --047d7bb03eb6a4b05c04e500f9cf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Sorry for being insistent - you answered the secondary question but not the primary question - if this is supposed to be for purposes of reversion from a DNR state, why do we need the intermediary state? I would think it better to not be administratively controlled and revert to Normal State! BR, yaacov On Wed, Aug 28, 2013 at 2:37 PM, =EC=A0=95=ED=83=9C=EC=8B=9D wrote: > Hi Yaacov,**** > > ** ** > > I answered to your question. Please see [Taesik2] inline.**** > > ** ** > > Best regards,**** > > Taesik**** > > ** ** > > *From:* Yaacov Weingarten [mailto:wyaacov@gmail.com] > *Sent:* Wednesday, August 28, 2013 7:03 PM > *To:* =EC=A0=95=ED=83=9C=EC=8B=9D > *Cc:* mpls@ietf.org; draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org; > mpls-chairs@tools.ietf.org > > *Subject:* Re: [mpls] MPLS-RT review on > draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc > documents**** > > ** ** > > Taesik, hi**** > > **** > > Thank you for your reply to my comments. While I appreciate the philosoph= y > that is behind the proposed format for this draft - and that some of your > considerations (for example, your need to change the name of Manual Switc= h > - something that would not be needed if you just wrote an update that > introduced the new operator command) are a direct result of this philosop= hy. > **** > > **** > > However, I found one of your replies to be of special interest. **** > > On Wed, Aug 28, 2013 at 3:10 AM, =EC=A0=95=ED=83=9C=EC=8B=9D wrote:**** > > Hi Yaacov,**** > > **** > > **** > > **** > > 3. I see problems with the suggestion to change the > "Protecting Administrative State" to "Switching Administrative State" sin= ce > this requires the confusing statement (in Section 4.9) "the user traffic > SHALL be transported on either the protection path or the working path" > which is certainly always true for traffic that is being transported. Why > not create a new State? Or even better, since the MS-W is meant to return > the state to Normal why not just use Normal state?**** > > [Taesik] Yes, traffic always flow on either the working or protection > path. But, it should be noted that it is =E2=80=9Cadministratively=E2=80= =9D controlled. In > that sense, we cannot say that a node is in =E2=80=9CNormal state=E2=80= =9D when MS-W > command is issued. By replacing =E2=80=9CProtecting administrative state= =E2=80=9D by > =E2=80=9CSwitching administrative state=E2=80=9D, it can cover both cases= : administratively > switched to working path (by MS-W) and administratively switched to > protection path (by MS-P).**** > > **** > > <> When I first read this draft I was under the impression that (as > impied by the title of the draft) the main justification for introducing > the MS-W command was to solve the problem of reverting traffic from a > non-revertive state and returning to the Normal State. However, according > to this explanation, using this command does not return you to the Normal > State, but rather to some intermediate state, since you are > "administartively controlled"! **** > > **** > > So can you please explain how does the operator revert from the > non-revertive situation to the Normal State? (Is it a sequence of MS-W an= d > then immediately Clear? If so, why is this different from LO and immediat= e > Clear?)**** > > ** ** > > [Taesik2] If you issue LO, you cannot protect traffic when SF or SD is > subsequently detected on the working path until the LO is cleared. On the > other hand, if you use MS-W, traffic can be protected because the priorit= y > of MS-W is lower than SF or SD.**** > > **** > > **** > > > -- **** > > Thanx and BR,**** > > yaacov**** > > ** ** > > *Still looking for new opportunity***** > --=20 Thanx and BR, yaacov *Still looking for new opportunity* --047d7bb03eb6a4b05c04e500f9cf Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: quoted-printable
Hi,
 
Sorry for being insist= ent - you answered the secondary question but not the primary question - if= this is supposed to be for purposes of reversion from a DNR state, why do = we need the intermediary state? I would think it better to not be administr= atively controlled and revert to Normal State!
 
BR,
yaacov


On Wed, Aug 28, 2013 at 2:37 PM, = =C1=A4=C5=C2=BD=C4 <cts@etri.re.kr> wrote:

Hi Yaac= ov,

=  

I answe= red to your question. Please see [Taesik2] inline.

=  

Best re= gards,

Taesik<= u>

=  

From: Yaacov Weingarten [mailto:wyaacov@gmail.com]
Sent: Wednesday, August 28, 2013 7:03 PM
To: =C1=A4=C5=C2=BD=C4<= span style=3D"font-family:"Tahoma","sans-serif";font-si= ze:10pt" lang=3D"EN-US">
Cc: mpls@ietf.org= ; draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org; = mpls-chairs= @tools.ietf.org


Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-reve= rtive-00//RE: MPLS-RT review of mpls psc documents

 

Taesik, hi=

 

Thank you for your reply to my = comments. While I appreciate the philosophy that is behind the propose= d format for this draft - and that some of your considerations (for example= , your need to change the name of Manual Switch - something that would not be needed if you just wrote an update th= at introduced the new operator command) are a direct result of this philoso= phy.

 

However, I found one of your re= plies to be of special interest.

On Wed, Aug 28, 2013 at 3:10 AM= , =C1=A4=C5=C2=BD=C4 <cts@etri.re.kr> wrote:

Hi Yaacov,

 

<tri= mmed content>

 

3. I see problems with the suggestion to ch= ange the "Protecting Administrative State" to "Swi= tching Administrative State" since this requires the confusing statement (in Section 4.9) "the use= r traffic SHALL be transported on either the protection path or the working= path" which is certainly always true for traffic that is being transp= orted. Why not create a new State? Or even better, since the MS-W is meant to return the state to Normal why not just= use Normal state?

= [Taesik] Yes, traffic always flow on either the working or protection path.= But, it should be noted that it is “administratively” controll= ed. In that sense, we cannot say that a node is in “Normal state” = when MS-W command is issued. By replacing “Protecting administrative = state” by “Switching administrative state”, it can cover = both cases: administratively switched to working path (by MS-W) and administratively switched to protection path (by MS-P).

 

<<yw>> When I first= read this draft I was under the impression that (as impied by the title of= the draft) the main justification for introducing the MS-W command wa= s to solve the problem of reverting traffic from a non-revertive state and returning to the Normal State. However, according to this explan= ation, using this command does not return you to the Normal State, but rath= er to some intermediate state, since you are "administartively control= led"! 

 

So can you please explain how d= oes the operator revert from the non-revertive situation to the Normal Stat= e? (Is it a sequence of MS-W and then immediately Clear? If so, why is this= different from LO and immediate Clear?)

=  

[Taesik2] If you issue LO, you cannot protect traffic when SF or SD is= subsequently detected on the working path until the LO is cleared. On the = other hand, if you use MS-W, traffic can be protected because the priority of MS-W is low= er than SF or SD.

 

<trimmed content>


--

Thanx and BR,

yaacov

 

Still looking for new opport= unity




--
Thanx = and BR,
yaacov

Still looking for new opport= unity
--047d7bb03eb6a4b05c04e500f9cf-- From internet-drafts@ietf.org Wed Aug 28 20:56:42 2013 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 710C021F9E52; Wed, 28 Aug 2013 20:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, 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 5+T9sVG7w9jR; Wed, 28 Aug 2013 20:56:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D837321F9E3B; Wed, 28 Aug 2013 20:56:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130829035640.13084.7940.idtracker@ietfa.amsl.com> Date: Wed, 28 Aug 2013 20:56:40 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-hello-crypto-auth-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: Thu, 29 Aug 2013 03:56:42 -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 Gro= up of the IETF. Title : LDP Hello Cryptographic Authentication Author(s) : Lianshu Zheng Mach(Guoyi) Chen Manav Bhatia Filename : draft-ietf-mpls-ldp-hello-crypto-auth-02.txt Pages : 17 Date : 2013-08-28 Abstract: This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-hello-crypto-auth There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello-crypto-auth-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-hello-crypto-auth-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cts@etri.re.kr Thu Aug 29 01:54:44 2013 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 0D8CC21E8093 for ; Thu, 29 Aug 2013 01:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.946 X-Spam-Level: X-Spam-Status: No, score=-96.946 tagged_above=-999 required=5 tests=[AWL=-2.051, 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, 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 k5wth1C4IMb1 for ; Thu, 29 Aug 2013 01:54:37 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2509321E8090 for ; Thu, 29 Aug 2013 01:54:35 -0700 (PDT) Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 29 Aug 2013 17:54:25 +0900 Received: from SMTP4.etri.info ([169.254.3.68]) by SMTP1.etri.info ([129.254.28.71]) with mapi id 14.01.0355.002; Thu, 29 Aug 2013 17:54:27 +0900 From: =?ks_c_5601-1987?B?waTFwr3E?= To: Yaacov Weingarten Thread-Topic: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents Thread-Index: AQHOlPghtHYllm9ZlUWJChJo0dWyb5mgbNEAgACk5gCACMSvQIAAFDeAgACpW+D//3xigIAB6e7A Date: Thu, 29 Aug 2013 08:54:26 +0000 Message-ID: References: <5204D9DE.6060405@pi.nu> In-Reply-To: Accept-Language: en-US, ko-KR Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.73.69] Content-Type: multipart/alternative; boundary="_000_AD98114A73E97041A2EDDCC3F3D10B0311040A3FSMTP4etriinfo_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents 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, 29 Aug 2013 08:54:44 -0000 --_000_AD98114A73E97041A2EDDCC3F3D10B0311040A3FSMTP4etriinfo_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgWWFhY292LA0KDQpZb3VyIHF1ZXN0aW9uIGlzIG5vdCBjbGVhciB0byBtZS4NCkJlZm9yZSBh bnN3ZXJpbmcgeW91ciBxdWVzdGlvbiwgY291bGQgeW91IHBsZWFzZSBjbGFyaWZ5IGZvbGxvd2lu ZyB0d28gc2VudGVuY2VzLCBlc3BlY2lhbGx5IGZvciB0aG9zZSBtYXJrZWQgd2l0aCA8PCA+Pj8N Ci0gd2h5IGRvIHdlIG5lZWQgdGhlIDxpbnRlcm1lZGlhcnk+IHN0YXRlPw0KLSBpdCBiZXR0ZXIg dG8gPG5vdCBiZSBhZG1pbmlzdHJhdGl2ZWx5IGNvbnRyb2xsZWQ+IGFuZCA8cmV2ZXJ0IHRvIE5v cm1hbCBTdGF0ZT4hDQoNCkJlc3QgcmVnYXJkcywNClRhZXNpaw0KDQpGcm9tOiBZYWFjb3YgV2Vp bmdhcnRlbiBbbWFpbHRvOnd5YWFjb3ZAZ21haWwuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1 c3QgMjgsIDIwMTMgOToxOCBQTQ0KVG86IMGkxcK9xA0KQ2M6IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0 LWNkaC1tcGxzLXRwLXBzYy1ub24tcmV2ZXJ0aXZlQHRvb2xzLmlldGYub3JnOyBtcGxzLWNoYWly c0B0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IFttcGxzXSBNUExTLVJUIHJldmlldyBvbiBk cmFmdC1jZGgtbXBscy10cC1wc2Mtbm9uLXJldmVydGl2ZS0wMC8vUkU6IE1QTFMtUlQgcmV2aWV3 IG9mIG1wbHMgcHNjIGRvY3VtZW50cw0KDQpIaSwNCg0KU29ycnkgZm9yIGJlaW5nIGluc2lzdGVu dCAtIHlvdSBhbnN3ZXJlZCB0aGUgc2Vjb25kYXJ5IHF1ZXN0aW9uIGJ1dCBub3QgdGhlIHByaW1h cnkgcXVlc3Rpb24gLSBpZiB0aGlzIGlzIHN1cHBvc2VkIHRvIGJlIGZvciBwdXJwb3NlcyBvZiBy ZXZlcnNpb24gZnJvbSBhIEROUiBzdGF0ZSwgd2h5IGRvIHdlIG5lZWQgdGhlIGludGVybWVkaWFy eSBzdGF0ZT8gSSB3b3VsZCB0aGluayBpdCBiZXR0ZXIgdG8gbm90IGJlIGFkbWluaXN0cmF0aXZl bHkgY29udHJvbGxlZCBhbmQgcmV2ZXJ0IHRvIE5vcm1hbCBTdGF0ZSENCg0KQlIsDQp5YWFjb3YN Cg0KT24gV2VkLCBBdWcgMjgsIDIwMTMgYXQgMjozNyBQTSwgwaTFwr3EIDxjdHNAZXRyaS5yZS5r cjxtYWlsdG86Y3RzQGV0cmkucmUua3I+PiB3cm90ZToNCkhpIFlhYWNvdiwNCg0KSSBhbnN3ZXJl ZCB0byB5b3VyIHF1ZXN0aW9uLiBQbGVhc2Ugc2VlIFtUYWVzaWsyXSBpbmxpbmUuDQoNCkJlc3Qg cmVnYXJkcywNClRhZXNpaw0KDQpGcm9tOiBZYWFjb3YgV2VpbmdhcnRlbiBbbWFpbHRvOnd5YWFj b3ZAZ21haWwuY29tPG1haWx0bzp3eWFhY292QGdtYWlsLmNvbT5dDQpTZW50OiBXZWRuZXNkYXks IEF1Z3VzdCAyOCwgMjAxMyA3OjAzIFBNDQpUbzogwaTFwr3EDQpDYzogbXBsc0BpZXRmLm9yZzxt YWlsdG86bXBsc0BpZXRmLm9yZz47IGRyYWZ0LWNkaC1tcGxzLXRwLXBzYy1ub24tcmV2ZXJ0aXZl QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1jZGgtbXBscy10cC1wc2Mtbm9uLXJldmVydGl2 ZUB0b29scy5pZXRmLm9yZz47IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzptcGxz LWNoYWlyc0B0b29scy5pZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFttcGxzXSBNUExTLVJUIHJl dmlldyBvbiBkcmFmdC1jZGgtbXBscy10cC1wc2Mtbm9uLXJldmVydGl2ZS0wMC8vUkU6IE1QTFMt UlQgcmV2aWV3IG9mIG1wbHMgcHNjIGRvY3VtZW50cw0KDQpUYWVzaWssIGhpDQoNClRoYW5rIHlv dSBmb3IgeW91ciByZXBseSB0byBteSBjb21tZW50cy4gV2hpbGUgSSBhcHByZWNpYXRlIHRoZSBw aGlsb3NvcGh5IHRoYXQgaXMgYmVoaW5kIHRoZSBwcm9wb3NlZCBmb3JtYXQgZm9yIHRoaXMgZHJh ZnQgLSBhbmQgdGhhdCBzb21lIG9mIHlvdXIgY29uc2lkZXJhdGlvbnMgKGZvciBleGFtcGxlLCB5 b3VyIG5lZWQgdG8gY2hhbmdlIHRoZSBuYW1lIG9mIE1hbnVhbCBTd2l0Y2ggLSBzb21ldGhpbmcg dGhhdCB3b3VsZCBub3QgYmUgbmVlZGVkIGlmIHlvdSBqdXN0IHdyb3RlIGFuIHVwZGF0ZSB0aGF0 IGludHJvZHVjZWQgdGhlIG5ldyBvcGVyYXRvciBjb21tYW5kKSBhcmUgYSBkaXJlY3QgcmVzdWx0 IG9mIHRoaXMgcGhpbG9zb3BoeS4NCg0KSG93ZXZlciwgSSBmb3VuZCBvbmUgb2YgeW91ciByZXBs aWVzIHRvIGJlIG9mIHNwZWNpYWwgaW50ZXJlc3QuDQpPbiBXZWQsIEF1ZyAyOCwgMjAxMyBhdCAz OjEwIEFNLCDBpMXCvcQgPGN0c0BldHJpLnJlLmtyPG1haWx0bzpjdHNAZXRyaS5yZS5rcj4+IHdy b3RlOg0KSGkgWWFhY292LA0KDQo8dHJpbW1lZCBjb250ZW50Pg0KDQozLiBJIHNlZSBwcm9ibGVt cyB3aXRoIHRoZSBzdWdnZXN0aW9uIHRvIGNoYW5nZSB0aGUgIlByb3RlY3RpbmcgQWRtaW5pc3Ry YXRpdmUgU3RhdGUiIHRvICJTd2l0Y2hpbmcgQWRtaW5pc3RyYXRpdmUgU3RhdGUiIHNpbmNlIHRo aXMgcmVxdWlyZXMgdGhlIGNvbmZ1c2luZyBzdGF0ZW1lbnQgKGluIFNlY3Rpb24gNC45KSAidGhl IHVzZXIgdHJhZmZpYyBTSEFMTCBiZSB0cmFuc3BvcnRlZCBvbiBlaXRoZXIgdGhlIHByb3RlY3Rp b24gcGF0aCBvciB0aGUgd29ya2luZyBwYXRoIiB3aGljaCBpcyBjZXJ0YWlubHkgYWx3YXlzIHRy dWUgZm9yIHRyYWZmaWMgdGhhdCBpcyBiZWluZyB0cmFuc3BvcnRlZC4gV2h5IG5vdCBjcmVhdGUg YSBuZXcgU3RhdGU/IE9yIGV2ZW4gYmV0dGVyLCBzaW5jZSB0aGUgTVMtVyBpcyBtZWFudCB0byBy ZXR1cm4gdGhlIHN0YXRlIHRvIE5vcm1hbCB3aHkgbm90IGp1c3QgdXNlIE5vcm1hbCBzdGF0ZT8N CltUYWVzaWtdIFllcywgdHJhZmZpYyBhbHdheXMgZmxvdyBvbiBlaXRoZXIgdGhlIHdvcmtpbmcg b3IgcHJvdGVjdGlvbiBwYXRoLiBCdXQsIGl0IHNob3VsZCBiZSBub3RlZCB0aGF0IGl0IGlzIKGw YWRtaW5pc3RyYXRpdmVseaGxIGNvbnRyb2xsZWQuIEluIHRoYXQgc2Vuc2UsIHdlIGNhbm5vdCBz YXkgdGhhdCBhIG5vZGUgaXMgaW4gobBOb3JtYWwgc3RhdGWhsSB3aGVuIE1TLVcgY29tbWFuZCBp cyBpc3N1ZWQuIEJ5IHJlcGxhY2luZyChsFByb3RlY3RpbmcgYWRtaW5pc3RyYXRpdmUgc3RhdGWh sSBieSChsFN3aXRjaGluZyBhZG1pbmlzdHJhdGl2ZSBzdGF0ZaGxLCBpdCBjYW4gY292ZXIgYm90 aCBjYXNlczogYWRtaW5pc3RyYXRpdmVseSBzd2l0Y2hlZCB0byB3b3JraW5nIHBhdGggKGJ5IE1T LVcpIGFuZCBhZG1pbmlzdHJhdGl2ZWx5IHN3aXRjaGVkIHRvIHByb3RlY3Rpb24gcGF0aCAoYnkg TVMtUCkuDQoNCjw8eXc+PiBXaGVuIEkgZmlyc3QgcmVhZCB0aGlzIGRyYWZ0IEkgd2FzIHVuZGVy IHRoZSBpbXByZXNzaW9uIHRoYXQgKGFzIGltcGllZCBieSB0aGUgdGl0bGUgb2YgdGhlIGRyYWZ0 KSB0aGUgbWFpbiBqdXN0aWZpY2F0aW9uIGZvciBpbnRyb2R1Y2luZyB0aGUgTVMtVyBjb21tYW5k IHdhcyB0byBzb2x2ZSB0aGUgcHJvYmxlbSBvZiByZXZlcnRpbmcgdHJhZmZpYyBmcm9tIGEgbm9u LXJldmVydGl2ZSBzdGF0ZSBhbmQgcmV0dXJuaW5nIHRvIHRoZSBOb3JtYWwgU3RhdGUuIEhvd2V2 ZXIsIGFjY29yZGluZyB0byB0aGlzIGV4cGxhbmF0aW9uLCB1c2luZyB0aGlzIGNvbW1hbmQgZG9l cyBub3QgcmV0dXJuIHlvdSB0byB0aGUgTm9ybWFsIFN0YXRlLCBidXQgcmF0aGVyIHRvIHNvbWUg aW50ZXJtZWRpYXRlIHN0YXRlLCBzaW5jZSB5b3UgYXJlICJhZG1pbmlzdGFydGl2ZWx5IGNvbnRy b2xsZWQiIQ0KDQpTbyBjYW4geW91IHBsZWFzZSBleHBsYWluIGhvdyBkb2VzIHRoZSBvcGVyYXRv ciByZXZlcnQgZnJvbSB0aGUgbm9uLXJldmVydGl2ZSBzaXR1YXRpb24gdG8gdGhlIE5vcm1hbCBT dGF0ZT8gKElzIGl0IGEgc2VxdWVuY2Ugb2YgTVMtVyBhbmQgdGhlbiBpbW1lZGlhdGVseSBDbGVh cj8gSWYgc28sIHdoeSBpcyB0aGlzIGRpZmZlcmVudCBmcm9tIExPIGFuZCBpbW1lZGlhdGUgQ2xl YXI/KQ0KDQpbVGFlc2lrMl0gSWYgeW91IGlzc3VlIExPLCB5b3UgY2Fubm90IHByb3RlY3QgdHJh ZmZpYyB3aGVuIFNGIG9yIFNEIGlzIHN1YnNlcXVlbnRseSBkZXRlY3RlZCBvbiB0aGUgd29ya2lu ZyBwYXRoIHVudGlsIHRoZSBMTyBpcyBjbGVhcmVkLiBPbiB0aGUgb3RoZXIgaGFuZCwgaWYgeW91 IHVzZSBNUy1XLCB0cmFmZmljIGNhbiBiZSBwcm90ZWN0ZWQgYmVjYXVzZSB0aGUgcHJpb3JpdHkg b2YgTVMtVyBpcyBsb3dlciB0aGFuIFNGIG9yIFNELg0KDQo8dHJpbW1lZCBjb250ZW50Pg0KDQot LQ0KVGhhbnggYW5kIEJSLA0KeWFhY292DQoNClN0aWxsIGxvb2tpbmcgZm9yIG5ldyBvcHBvcnR1 bml0eQ0KDQoNCg0KLS0NClRoYW54IGFuZCBCUiwNCnlhYWNvdg0KDQpTdGlsbCBsb29raW5nIGZv ciBuZXcgb3Bwb3J0dW5pdHkNCg== --_000_AD98114A73E97041A2EDDCC3F3D10B0311040A3FSMTP4etriinfo_ Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable

Hi Yaacov,

 

Your question is not clear to me.

Before answering your question, could you please clarify= following two sentences, especially for those marked with << >>= ;?

- why do we need the <intermediary> state?

- it better to <not be administratively controlled>= ; and <revert to Normal State>!

 

Best regards,

Taesik

 

From: Yaacov Weingarten [mailto:wyaacov@gmail.com]
Sent: Wednesday, August 28, 2013 9:18 PM
To: =C1=A4=C5=C2=BD=C4
Cc: mpls@ietf.org; draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.or= g; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-reve= rtive-00//RE: MPLS-RT review of mpls psc documents

 

Hi,

 

Sorry for being insistent - you= answered the secondary question but not the primary question - if this is = supposed to be for purposes of reversion from a DNR state, why do we need t= he intermediary state? I would think it better to not be administratively controlled and revert to Normal State= !

 

BR,

yaacov

=  

On Wed, Aug 28, 2013 at 2:37 PM= , =C1=A4=C5=C2=BD=C4 <cts@etri.re.kr> wrote:

H= i Yaacov,

&nbs= p;

I= answered to your question. Please see [Taesik2] inline.

&nbs= p;

B= est regards,

T= aesik

&nbs= p;

From: Yaacov Weingarten [mailto:= wyaacov@gmail.com]
Sent: Wednesday, August 28, 2013 7:03 PM
To: =C1=A4=C5=C2=BD=C4
Cc: mpls@ietf.org= ; draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org; mpls-chairs@tools.ietf.org


Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-reve= rtive-00//RE: MPLS-RT review of mpls psc documents

 

Taesik, hi

 

Thank you for your reply to my comments. = ;While I appreciate the philosophy that is behind the proposed format for t= his draft - and that some of your considerations (for example, your need to change the name of Manual Switch - something th= at would not be needed if you just wrote an update that introduced the new = operator command) are a direct result of this philosophy.=

 

However, I found one of your replies to be of= special interest.

On Wed, Aug 28, 2013 at 3:10 AM, =C1=A4=C5=C2=BD=C4 <cts@etri.re.kr> wrote:=

Hi Yaacov,

&nbs= p;

<trimmed content>

&nbs= p;

3. I see problems with the suggestion to change the "= ;Protecting Administrative State" to "Switching Ad= ministrative State" since this requires the confusing statement (in Section 4.9) "the use= r traffic SHALL be transported on either the protection path or the working= path" which is certainly always true for traffic that is being transp= orted. Why not create a new State? Or even better, since the MS-W is meant to return the state to Normal why not just= use Normal state?

[Taesik] Yes, traffic= always flow on either the working or protection path. But, it should be no= ted that it is =A1=B0administrat= ively=A1=B1 controlled. In that sense, we canno= t say that a node is in =A1=B0Normal state=A1=B1 when MS-W command is issued. By replacing =A1=B0Protecting administrative state=A1= =B1 by =A1=B0Switching administrative state=A1= =B1, it can cover both cases: administratively switche= d to working path (by MS-W) and administratively switched to protection pat= h (by MS-P).

 

<<yw>> When I first read this dra= ft I was under the impression that (as impied by the title of the draft)&nb= sp;the main justification for introducing the MS-W command was to solve the problem of reverting traffic from a non-revertive state a= nd returning to the Normal State. However, according to this explanation, u= sing this command does not return you to the Normal State, but rather to so= me intermediate state, since you are "administartively controlled"! 

 

So can you please explain how does the operat= or revert from the non-revertive situation to the Normal State? (Is it a se= quence of MS-W and then immediately Clear? If so, why is this different from LO and immediate Clear?)

&nbs= p;

[= Taesik2] If you issue LO, you cannot protect traffic when SF or SD is subse= quently detected on the working path until the LO is cleared. On the other hand, i= f you use MS-W, traffic can be protected because the priority of MS-W is lo= wer than SF or SD.

&nbs= p;

<trimmed content><= /o:p>


-- =

Thanx and BR,

yaacov

 

Still looking for new opportunity




--

Thanx and BR,=

yaacov

 

Still looking for new opport= unity

--_000_AD98114A73E97041A2EDDCC3F3D10B0311040A3FSMTP4etriinfo_-- From wyaacov@gmail.com Thu Aug 29 02:18:03 2013 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 3D1A021F9EF4 for ; Thu, 29 Aug 2013 02:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[AWL=-1.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HszVo4JyQBnD for ; Thu, 29 Aug 2013 02:17:59 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6B28521F9E62 for ; Thu, 29 Aug 2013 02:17:58 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id n12so162069wgh.8 for ; Thu, 29 Aug 2013 02:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E0no+we6fmlPR31IE5pSHZHii853YftEiTIDWNZ364I=; b=YwwAHDiQEGVeRpMex1+EIYmw/Xi0PaElxun0042ifFqoyD7WDmvIfNMAyg8mlwHbei TdlcftiCXofzhLSrvRXrPz2rAEWkhE9Fo62+yM+SYrPfHIob6SQ4/CPPZ4avk73eGhYQ uBoj8Pn78Rwnlq+OxKVQob4fBNPFv6qfA34lpc0cTc8XRCtiSQtmEtawKAMLS7Naa56l PwTbYw+vBPShql9LaJDqcvYi29rGuVjsraHvwVgCAMA0/t5192L7jqiNszQEq5j0DCnQ XajRGNDM8amlJy2ealQASwNRQhl4hEuxsI1X2qz92WMcZKqUtuMtpXComtgTr59XWjKV spbw== MIME-Version: 1.0 X-Received: by 10.194.122.129 with SMTP id ls1mr4223722wjb.37.1377767876279; Thu, 29 Aug 2013 02:17:56 -0700 (PDT) Received: by 10.194.164.200 with HTTP; Thu, 29 Aug 2013 02:17:56 -0700 (PDT) In-Reply-To: References: <5204D9DE.6060405@pi.nu> Date: Thu, 29 Aug 2013 12:17:56 +0300 Message-ID: From: Yaacov Weingarten To: =?UTF-8?B?7KCV7YOc7Iud?= Content-Type: multipart/alternative; boundary=089e012299c8d9421704e51294e4 Cc: "mpls@ietf.org" , "draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents 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, 29 Aug 2013 09:18:03 -0000 --089e012299c8d9421704e51294e4 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: quoted-printable Hi, 1. In your reply to my review comment - you explained that after issuing the MS-W command even though the traffic is being transported on the working path it is in "Administartive Switching State" because it is "administratively" controlled - so I think that you need to explain what is meant by "administratively controlled". 2. Regarding the other terms - not sure what is not clear. If the traffic is on the protection path (either as a result of a SF [in RFC6378] or operator command [according to your proposal]) and the system is in non-revertive state. When the switching trigger clears, the traffic remains on the protection path and the system goes into DNR state. Your proposal (at least according to my original understanding) was to introduce a command that would allow the operator to cancel the DNR and revert to Normal State. However, I now understand that this is not the case - but instead by issuing the MS-W command the system goes into an intermediary state, i.e. Administratively Switching State, instead of going back to Normal State. Therefore, my question was: 1. Why do we need this Administrative Switching State, why not go directly (i.e. revert) to Normal State? 2. What is the sequence of commands/operations/triggers that returns the system to Normal State from DNR state? Hope this clarifies, yaacov On Thu, Aug 29, 2013 at 11:54 AM, =C1=A4=C5=C2=BD=C4 wrote= : > Hi Yaacov,**** > > ** ** > > Your question is not clear to me. **** > > Before answering your question, could you please clarify following two > sentences, especially for those marked with << >>?**** > > - why do we need the state?**** > > - it better to and State>!**** > > ** ** > > Best regards,**** > > Taesik**** > > ** ** > > *From:* Yaacov Weingarten [mailto:wyaacov@gmail.com] > *Sent:* Wednesday, August 28, 2013 9:18 PM > *To:* =C1=A4=C5=C2=BD=C4 > > *Cc:* mpls@ietf.org; draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org; > mpls-chairs@tools.ietf.org > *Subject:* Re: [mpls] MPLS-RT review on > draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc > documents**** > > ** ** > > Hi,**** > > **** > > Sorry for being insistent - you answered the secondary question but not > the primary question - if this is supposed to be for purposes of reversio= n > from a DNR state, why do we need the intermediary state? I would think it > better to not be administratively controlled and revert to Normal State!*= * > ** > > **** > > BR,**** > > yaacov**** > > ** ** > > On Wed, Aug 28, 2013 at 2:37 PM, =C1=A4=C5=C2=BD=C4 wrot= e:**** > > Hi Yaacov,**** > > **** > > I answered to your question. Please see [Taesik2] inline.**** > > **** > > Best regards,**** > > Taesik**** > > **** > > *From:* Yaacov Weingarten [mailto:wyaacov@gmail.com] > *Sent:* Wednesday, August 28, 2013 7:03 PM > *To:* =C1=A4=C5=C2=BD=C4 > *Cc:* mpls@ietf.org; draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org; > mpls-chairs@tools.ietf.org**** > > > *Subject:* Re: [mpls] MPLS-RT review on > draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc > documents**** > > **** > > Taesik, hi**** > > **** > > Thank you for your reply to my comments. While I appreciate the philosoph= y > that is behind the proposed format for this draft - and that some of your > considerations (for example, your need to change the name of Manual Switc= h > - something that would not be needed if you just wrote an update that > introduced the new operator command) are a direct result of this philosop= hy. > **** > > **** > > However, I found one of your replies to be of special interest. **** > > On Wed, Aug 28, 2013 at 3:10 AM, =C1=A4=C5=C2=BD=C4 wrot= e:**** > > Hi Yaacov,**** > > **** > > **** > > **** > > 3. I see problems with the suggestion to change the > "Protecting Administrative State" to "Switching Administrative State" sin= ce > this requires the confusing statement (in Section 4.9) "the user traffic > SHALL be transported on either the protection path or the working path" > which is certainly always true for traffic that is being transported. Why > not create a new State? Or even better, since the MS-W is meant to return > the state to Normal why not just use Normal state?**** > > [Taesik] Yes, traffic always flow on either the working or protection > path. But, it should be noted that it is =A1=B0administratively=A1=B1 con= trolled. > In that sense, we cannot say that a node is in =A1=B0Normal state=A1=B1 w= hen MS-W > command is issued. By replacing =A1=B0Protecting administrative state=A1= =B1 by =A1=B0Switching > administrative state=A1=B1, it can cover both cases: administratively swi= tched > to working path (by MS-W) and administratively switched to protection pat= h > (by MS-P).**** > > **** > > <> When I first read this draft I was under the impression that (as > impied by the title of the draft) the main justification for introducing > the MS-W command was to solve the problem of reverting traffic from a > non-revertive state and returning to the Normal State. However, according > to this explanation, using this command does not return you to the Normal > State, but rather to some intermediate state, since you are > "administartively controlled"! **** > > **** > > So can you please explain how does the operator revert from the > non-revertive situation to the Normal State? (Is it a sequence of MS-W an= d > then immediately Clear? If so, why is this different from LO and immediat= e > Clear?)**** > > **** > > [Taesik2] If you issue LO, you cannot protect traffic when SF or SD is > subsequently detected on the working path until the LO is cleared. On the > other hand, if you use MS-W, traffic can be protected because the priorit= y > of MS-W is lower than SF or SD.**** > > **** > > **** > > > -- **** > > Thanx and BR,**** > > yaacov**** > > **** > > *Still looking for new opportunity***** > > > > > -- **** > > Thanx and BR,**** > > yaacov**** > > ** ** > > *Still looking for new opportunity***** > --=20 Thanx and BR, yaacov *Still looking for new opportunity* --089e012299c8d9421704e51294e4 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: quoted-printable
Hi,
 
1. In your reply to my= review comment - you explained that after issuing the MS-W command even th= ough the traffic is being transported on the working path it is in "Ad= ministartive Switching State" because it is "administratively&quo= t; controlled - so I think that you need to explain what is meant by "= administratively controlled".
 
2. Regarding the other terms - not sure what is not c= lear. If the traffic is on the protection path (either as a result of a SF = [in RFC6378] or operator command [according to your proposal]) an= d the system is in non-revertive state. When the switching trigger clears, = the traffic remains on the protection path and the system goes into DNR sta= te. Your proposal (at least according to my original understanding) was to = introduce a command that would allow the operator to cancel the DNR and rev= ert to Normal State. However, I now understand that this is not the case - = but instead by issuing the MS-W command the system goes into an intermediar= y state, i.e. Administratively Switching State, instead of going back to No= rmal State.
 
Therefore, my question was:
1. Why do we ne= ed this Administrative Switching State, why not go directly (i.e. revert)&n= bsp;to Normal State?
2. What is the sequence of commands/operatio= ns/triggers that returns the system to Normal State from DNR state?
 
Hope this clarifies,
yaacov


On Thu, Aug 29, 2= 013 at 11:54 AM, =C1=A4=C5=C2=BD=C4 <cts@etri.re.kr> wrote:

Hi Yaac= ov,

=  

Your qu= estion is not clear to me.

Before = answering your question, could you please clarify following two sentences, = especially for those marked with << >>?

- why d= o we need the <intermediary> state?

-= it better to <not be administratively controlled> and <revert to = Normal State>!

=  

Best re= gards,

Taesik<= u>

=  

From: Yaacov Weingarten [mailto:wyaacov@gmail.com]
Sent: Wednesday, August 28, 2013 9:18 PM
To: =C1=A4=C5=C2=BD=C4<= div>


Cc: mpls@ietf.org= ; draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org; = mpls-chairs= @tools.ietf.org
Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-reve= rtive-00//RE: MPLS-RT review of mpls psc documents

 

Hi,

 

Sorry for being insistent - you= answered the secondary question but not the primary question - if this is = supposed to be for purposes of reversion from a DNR state, why do we need t= he intermediary state? I would think it better to not be administratively controlled and revert to Normal State= !

 

BR,

yaacov

 

On Wed, Aug 28, 2013 at 2:37 PM= , =C1=A4=C5=C2=BD=C4 <cts@etri.re.kr> wrote:

Hi Yaacov,

 

I answered to your question. Please see [Taesik2] inline= .

 

Best regards,<= /span>

Taesik<= /p>

 

From: Yaacov Weingarten [mailto:= wyaacov@gmail.com]
Sent: Wednesday, August 28, 2013 7:03 PM
To: =C1=A4=C5=C2=BD=C4<= span style=3D"font-family:"Tahoma","sans-serif";font-si= ze:10pt" lang=3D"EN-US">
Cc: mpls@ietf.org= ; draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org; mpls-chairs@tools.ietf.org


Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-reve= rtive-00//RE: MPLS-RT review of mpls psc documents

 

Taesik, hi=

 

Thank you for your reply to my = comments. While I appreciate the philosophy that is behind the propose= d format for this draft - and that some of your considerations (for example, your need to change the name of Manual Switch - something th= at would not be needed if you just wrote an update that introduced the new = operator command) are a direct result of this philosophy.

 

However, I found one of your re= plies to be of special interest.

On Wed, Aug 28, 2013 at 3:10 AM= , =C1=A4=C5=C2=BD=C4 <cts@etri.re.kr> wrote:

Hi= Yaacov,

 

<tri= mmed content>

 

3. I see problems with the suggestion to ch= ange the "Protecting Administrative State" to "Swi= tching Administrative State" since this requires the confusing statement (in Section 4.9) "the use= r traffic SHALL be transported on either the protection path or the working= path" which is certainly always true for traffic that is being transp= orted. Why not create a new State? Or even better, since the MS-W is meant to return the state to Normal why not just= use Normal state?

= [Taesik] Yes, traffic always flow on either the working or protection path.= But, it should be noted that it is “adm= inistratively” controlled. In that sense,= we cannot say that a node is in “Normal state” when MS-W command is issued. By replacing “Protecting administrative state&r= dquo; by “Switching administrative state&rd= quo;, it can cover both cases: administratively switch= ed to working path (by MS-W) and administratively switched to protection pa= th (by MS-P).

 

<<yw>> When I first= read this draft I was under the impression that (as impied by the title of= the draft) the main justification for introducing the MS-W command was to solve the problem of reverting traffic from a non-revertive state a= nd returning to the Normal State. However, according to this explanation, u= sing this command does not return you to the Normal State, but rather to so= me intermediate state, since you are "administartively controlled"! 

 

So can you please explain how d= oes the operator revert from the non-revertive situation to the Normal Stat= e? (Is it a sequence of MS-W and then immediately Clear? If so, why is this different from LO and immediate Clear?)

 

[Taesik2] If you issue LO, you cannot protect traffic wh= en SF or SD is subsequently detected on the working path until the LO is cleared. On the other hand, i= f you use MS-W, traffic can be protected because the priority of MS-W is lo= wer than SF or SD.

 

<trimmed content>


--

Thanx and BR,

yaacov

 

Still looking for new opport= unity




--

Thanx and BR,

yaacov

 

Still looking for new opport= unity




--
Thanx = and BR,
yaacov

Still looking for new opport= unity
--089e012299c8d9421704e51294e4-- From swallow@cisco.com Thu Aug 29 10:13:17 2013 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 4C45911E8144 for ; Thu, 29 Aug 2013 10:13:17 -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=[AWL=0.000, 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 18uV18NtgxLG for ; Thu, 29 Aug 2013 10:13:11 -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 6B74611E8143 for ; Thu, 29 Aug 2013 10:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=501; q=dns/txt; s=iport; t=1377796388; x=1379005988; h=from:to:cc:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=L7vS8BoZkQTYt/vW7SoO86Cl1v3Hkv5PW2mHRLRKbyk=; b=bZJyh2XFK9UOAs6cHs3zRAfu0BsxuiEyOfG+lJOU+/YVmsYyl/Lae0sr pwXLpjiq0R/YcW2WQcRKTYG2tsyhNhp5guXzd5GwM0QpKyUt9hff1IMzY DVF+wzfshjDFS8ZNFBcPCH/Yejrk6XPtCcCwaocLX6pCgSOk4tWx+0bbj s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUGADmAH1KtJV2d/2dsb2JhbABagweBBoJgvVmBKBZtB4IkAQEBAwE6PwULAgEZAwECCxQQMhsCCAIEDgUIh3MGuSKOO4EIMQ2DFoEAA6lZgyCBcTk X-IronPort-AV: E=Sophos;i="4.89,984,1367971200"; d="scan'208";a="253267898" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 29 Aug 2013 17:13:08 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7THD7rN006820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Aug 2013 17:13:07 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.8]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 29 Aug 2013 12:13:07 -0500 From: "George Swallow (swallow)" To: "mpls@ietf.org" Thread-Topic: [i2rs] Mail lost yesterday Thread-Index: AQHOpNsHlNCFVqWAN0CiNbQrl6VIEA== Date: Thu, 29 Aug 2013 17:13:07 +0000 Message-ID: <2FE467D3673DCE409A84D67EC2F607BB1408ED3D@xmb-rcd-x10.cisco.com> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.70] Content-Type: text/plain; charset="us-ascii" Content-ID: <32057F4205FEEE48982D60307E312BEC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ross Callon Subject: [mpls] Fwd: [i2rs] Mail lost yesterday 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, 29 Aug 2013 17:13:17 -0000 FYI George Begin forwarded message: > From: Adrian Farrel > Date: Thu, Aug 29, 2013 at 7:46 AM > Subject: FW: Mail lost yesterday >=20 >=20 > For those of you who haven't noticed the message from Steve Young in > your In box, mail to all IETF lists between 15:30 and and 20:55 Pacific > Time yesterday seems to have been lost. Aside from needing to re-send > all mail you personally sent during that time period, you also need to > inform your working groups. From swallow@cisco.com Thu Aug 29 10:17:35 2013 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 1225921E80A1 for ; Thu, 29 Aug 2013 10:17:35 -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=[AWL=0.000, 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 STYcoHnOBini for ; Thu, 29 Aug 2013 10:17:30 -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 0E36121E804E for ; Thu, 29 Aug 2013 10:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1179; q=dns/txt; s=iport; t=1377796648; x=1379006248; h=from:to:cc:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=2AmagtBWU8uwLqxfO22IEkDDf13vT1uyU5icduPOq7E=; b=bU2F3BSEObzyRkiL/droorjGy2xp14tRLcHJUV94g6A2QNKa2MfMLivI jqdSCcJisiWCVZc98RnHKWeeNIPo8MVkunuxZR3putz6Gf05pNEABQvf8 B2uGfET1J1pQoGU5VTyvYi+6PtgxS+9KltX6ke4KBCttmwuD63uhqiyJs Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkGAKGBH1KtJXG+/2dsb2JhbABagwc1UcA5gSgWbQeCJAEBAQQ6NAsQAgEZAwECCxQQMhsCCAEBBA4FCId5uSGOKxCBCDENgxaBAAOYKXmQN4MggWgGAxci X-IronPort-AV: E=Sophos;i="4.89,984,1367971200"; d="scan'208";a="253271449" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 29 Aug 2013 17:17:27 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7THHRhe004828 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Aug 2013 17:17:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.8]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Thu, 29 Aug 2013 12:17:27 -0500 From: "George Swallow (swallow)" To: "mpls@ietf.org" Thread-Topic: And for clarity...: Mail lost yesterday Thread-Index: Ac6kzEgR7WrmlrrDQnaOulINb+/HhA== Date: Thu, 29 Aug 2013 17:17:26 +0000 Message-ID: <2FE467D3673DCE409A84D67EC2F607BB1408EE1D@xmb-rcd-x10.cisco.com> References: <078601cea4cc$4ab51c70$e01f5550$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.70] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ross Callon Subject: [mpls] Fwd: And for clarity...: Mail lost yesterday 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, 29 Aug 2013 17:17:35 -0000 All - Not all mail was lost. Please check the list and resend only messages that= didn't make it. Thanks, George Begin forwarded message: >=20 >> ---------- Forwarded message ---------- >> From: Steve Young >> Date: Thu, Aug 29, 2013 at 3:36 AM >> Subject: Your mail to an IETF mailing list may not have been delivered >> To: Steve Young >>=20 >> Hello, >>=20 >> My name is Steve Young and I am a system administrator for the ietf.org > servers. >>=20 >> I am sorry to report that we experienced a glitch with the Mailman >> system on Wednesday 28th August 2013 between 3.30pm PST and 8.55pm PST >> that resulted in some posts to mailing lists not being delivered. You >> are receiving this email because according to our records you sent an >> email to an IETF mailing list during this time. >>=20 >> If your message to a mailing list has not been sent to you as a list >> member, or has not appeared in the list archive, you will need to >> re-send it. If you need clarification regarding which particular >> message may have been affected please let me know. >>=20 >> Best regards, >> Steve >=20 From internet-drafts@ietf.org Thu Aug 29 14:30:08 2013 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 BFFBE11E8181; Thu, 29 Aug 2013 14:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, 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 0dlg6c7zzvcc; Thu, 29 Aug 2013 14:30:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F23411E817B; Thu, 29 Aug 2013 14:30:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130829213008.21835.99708.idtracker@ietfa.amsl.com> Date: Thu, 29 Aug 2013 14:30:08 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-rekhter-mpls-pim-sm-over-mldp-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: Thu, 29 Aug 2013 21:30:08 -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 Gro= up of the IETF. Title : Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs Author(s) : Yakov Rekhter Rahul Aggarwal Nicolai Leymann Wim Henderickx Quintin Zhao Richard Li Filename : draft-rekhter-mpls-pim-sm-over-mldp-06.txt Pages : 11 Date : 2013-08-29 Abstract: When IP multicast trees created by PIM-SM in Any Source Multicast (ASM) mode need to pass through an MPLS domain, it may be desirable to map such trees to Point-to-Multipoint Label Switched Paths. This document describes how to accomplish this in the case where such Point-to-Multipoint Label Switches Paths are established using mLDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-rekhter-mpls-pim-sm-over-mldp There's also a htmlized version available at: http://tools.ietf.org/html/draft-rekhter-mpls-pim-sm-over-mldp-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-rekhter-mpls-pim-sm-over-mldp-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cts@etri.re.kr Thu Aug 29 18:18:27 2013 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 EBC9F11E8129 for ; Thu, 29 Aug 2013 18:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.433 X-Spam-Level: X-Spam-Status: No, score=-96.433 tagged_above=-999 required=5 tests=[AWL=-1.538, 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, 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 1pXF+caHPTE1 for ; Thu, 29 Aug 2013 18:18:20 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFB411E80D3 for ; Thu, 29 Aug 2013 18:18:19 -0700 (PDT) Received: from SMTP2.etri.info (129.254.28.72) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 30 Aug 2013 10:18:13 +0900 Received: from SMTP4.etri.info ([169.254.3.68]) by SMTP2.etri.info ([129.254.28.72]) with mapi id 14.01.0355.002; Fri, 30 Aug 2013 10:18:10 +0900 From: =?ks_c_5601-1987?B?waTFwr3E?= To: Yaacov Weingarten Thread-Topic: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents Thread-Index: AQHOlPghtHYllm9ZlUWJChJo0dWyb5mgbNEAgACk5gCACMSvQIAAFDeAgACpW+D//3xigIAB6e7A//92MwCAAZAiQA== Date: Fri, 30 Aug 2013 01:18:10 +0000 Message-ID: References: <5204D9DE.6060405@pi.nu> In-Reply-To: Accept-Language: en-US, ko-KR Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.73.69] Content-Type: multipart/alternative; boundary="_000_AD98114A73E97041A2EDDCC3F3D10B0311040B7ESMTP4etriinfo_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents 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, 30 Aug 2013 01:18:27 -0000 --_000_AD98114A73E97041A2EDDCC3F3D10B0311040B7ESMTP4etriinfo_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgWWFhY292LA0KDQpQbGVhc2Ugc2VlIFtUYWVzaWtdIGlubGluZS4NCg0KQmVzdCByZWdhcmRz LA0KVGFlc2lrDQoNCkZyb206IFlhYWNvdiBXZWluZ2FydGVuIFttYWlsdG86d3lhYWNvdkBnbWFp bC5jb21dDQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDI5LCAyMDEzIDY6MTggUE0NClRvOiDBpMXC vcQNCkNjOiBtcGxzQGlldGYub3JnOyBkcmFmdC1jZGgtbXBscy10cC1wc2Mtbm9uLXJldmVydGl2 ZUB0b29scy5pZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbbXBsc10gTVBMUy1SVCByZXZpZXcgb24gZHJhZnQtY2RoLW1wbHMtdHAtcHNjLW5vbi1yZXZl cnRpdmUtMDAvL1JFOiBNUExTLVJUIHJldmlldyBvZiBtcGxzIHBzYyBkb2N1bWVudHMNCg0KSGks DQoNCjEuIEluIHlvdXIgcmVwbHkgdG8gbXkgcmV2aWV3IGNvbW1lbnQgLSB5b3UgZXhwbGFpbmVk IHRoYXQgYWZ0ZXIgaXNzdWluZyB0aGUgTVMtVyBjb21tYW5kIGV2ZW4gdGhvdWdoIHRoZSB0cmFm ZmljIGlzIGJlaW5nIHRyYW5zcG9ydGVkIG9uIHRoZSB3b3JraW5nIHBhdGggaXQgaXMgaW4gIkFk bWluaXN0YXJ0aXZlIFN3aXRjaGluZyBTdGF0ZSIgYmVjYXVzZSBpdCBpcyAiYWRtaW5pc3RyYXRp dmVseSIgY29udHJvbGxlZCAtIHNvIEkgdGhpbmsgdGhhdCB5b3UgbmVlZCB0byBleHBsYWluIHdo YXQgaXMgbWVhbnQgYnkgImFkbWluaXN0cmF0aXZlbHkgY29udHJvbGxlZCIuDQpbVGFlc2lrXSCh sFByb3RlY3RpbmcgYWRtaW5pc3RyYXRpdmUgU3RhdGWhsSBtZWFucyB0aGF0IHRyYWZmaWMgaXMg obBhZG1pbmlzdHJhdGl2ZWx5IGNvbnRyb2xsZWShsSB0byBmbG93IG9uIHRoZSBwcm90ZWN0aW9u IHBhdGguIKGwU3dpdGNoaW5nIGFkbWluaXN0cmF0aXZlIHN0YXRlobEgbWVhbnMgdGhhdCB0aGUg dHJhZmZpYyBpcyChsGFkbWluaXN0cmF0aXZlbHkgY29udHJvbGxlZKGxIHRvIGZsb3cgb24gdGhl IHByb3RlY3Rpb24gcGF0aCBpbiBjYXNlIG9mIEZTIG9yIE1TKC1QKSwgb3Igb24gdGhlIHdvcmtp bmcgcGF0aCBpbiBjYXNlIG9mIE1TLVcuDQoNCjIuIFJlZ2FyZGluZyB0aGUgb3RoZXIgdGVybXMg LSBub3Qgc3VyZSB3aGF0IGlzIG5vdCBjbGVhci4gSWYgdGhlIHRyYWZmaWMgaXMgb24gdGhlIHBy b3RlY3Rpb24gcGF0aCAoZWl0aGVyIGFzIGEgcmVzdWx0IG9mIGEgU0YgW2luIFJGQzYzNzhdIG9y IG9wZXJhdG9yIGNvbW1hbmQgW2FjY29yZGluZyB0byB5b3VyIHByb3Bvc2FsXSkgYW5kIHRoZSBz eXN0ZW0gaXMgaW4gbm9uLXJldmVydGl2ZSBzdGF0ZS4gV2hlbiB0aGUgc3dpdGNoaW5nIHRyaWdn ZXIgY2xlYXJzLCB0aGUgdHJhZmZpYyByZW1haW5zIG9uIHRoZSBwcm90ZWN0aW9uIHBhdGggYW5k IHRoZSBzeXN0ZW0gZ29lcyBpbnRvIEROUiBzdGF0ZS4gWW91ciBwcm9wb3NhbCAoYXQgbGVhc3Qg YWNjb3JkaW5nIHRvIG15IG9yaWdpbmFsIHVuZGVyc3RhbmRpbmcpIHdhcyB0byBpbnRyb2R1Y2Ug YSBjb21tYW5kIHRoYXQgd291bGQgYWxsb3cgdGhlIG9wZXJhdG9yIHRvIGNhbmNlbCB0aGUgRE5S IGFuZCByZXZlcnQgdG8gTm9ybWFsIFN0YXRlLiBIb3dldmVyLCBJIG5vdyB1bmRlcnN0YW5kIHRo YXQgdGhpcyBpcyBub3QgdGhlIGNhc2UgLSBidXQgaW5zdGVhZCBieSBpc3N1aW5nIHRoZSBNUy1X IGNvbW1hbmQgdGhlIHN5c3RlbSBnb2VzIGludG8gYW4gaW50ZXJtZWRpYXJ5IHN0YXRlLCBpLmUu IEFkbWluaXN0cmF0aXZlbHkgU3dpdGNoaW5nIFN0YXRlLCBpbnN0ZWFkIG9mIGdvaW5nIGJhY2sg dG8gTm9ybWFsIFN0YXRlLg0KW1RhZXNpa10gRlMsIE1TKC1QKSBhbmQgTVMtVyBhcmUgYWxsIHNh bWUgaW4gdGhlIHNlbnNlIHRoYXQgdHJhZmZpYyBpcyBjb250cm9sbGVkIGJ5IGFuIG9wZXJhdG9y LiBJZiBJIGZvbGxvdyB5b3VyIGxvZ2ljLCBhbnkgc3RhdGUgY2hhbmdlZCBieSBhbiBleHRlcm5h bCBjb21tYW5kIGNhbiBiZSB2aWV3ZWQgYXMgYW4gaW50ZXJtZWRpYXJ5IHN0YXRlIHVudGlsIHRo YXQgY29tbWFuZCBpcyBjbGVhcmVkLiBCdXQsIEkgZG9uoa90IHdhbnQgdG8gY29uc2lkZXIgaXQg YXMgYW4gaW50ZXJtZWRpYXJ5IHN0YXRlLg0KDQpUaGVyZWZvcmUsIG15IHF1ZXN0aW9uIHdhczoN CjEuIFdoeSBkbyB3ZSBuZWVkIHRoaXMgQWRtaW5pc3RyYXRpdmUgU3dpdGNoaW5nIFN0YXRlLCB3 aHkgbm90IGdvIGRpcmVjdGx5IChpLmUuIHJldmVydCkgdG8gTm9ybWFsIFN0YXRlPw0KW1RhZXNp a10gVGhlIENvcnJlY3QgbmFtZSBwcm9wb3NlZCBpbiB0aGlzIGRyYWZ0IGlzIKGwU3dpdGNoaW5n IEFkbWluaXN0cmF0aXZlIFN0YXRlobEuIKGwUHJvdGVjdGluZyBBZG1pbmlzdHJhdGl2ZSBTdGF0 ZaGxIGlzIGFscmVhZHkgdGhlcmUuIFRoaXMgZHJhZnQgcHJvcG9zZXMgdG8gcmVuYW1lIGl0IHRv IGNvdmVyIE1TLVcgYXMgd2VsbCBhcyBGUyBhbmQgTVMoLVApLg0KW1RhZXNpa10gSWYgeW91IGNo YW5nZSBQU0Mgc3RhdGUgbWFjaGluZSwgeW91IGNhbiBkbyBhbnl0aGluZy4gVGhpcyBkcmFmdCBk b2VzIG5vdCBwcm9wb3NlIHNvbWV0aGluZyBuZXcsIGJ1dCBwcm9wb3NlcyB0byBhZGQgYW4gZXh0 ZXJuYWwgY29tbWFuZCAoTVMtVykgd2hpY2ggaGFzIGJlZW4gaWRlbnRpZmllZCBpbiBsaWFpc29u cyBiZXR3ZWVuIElUVS1UIGFuZCBJRVRGIHRoYXQgaXQgaXMgbWlzc2luZyBmcm9tIFJGQzYzNzgu DQoNCjIuIFdoYXQgaXMgdGhlIHNlcXVlbmNlIG9mIGNvbW1hbmRzL29wZXJhdGlvbnMvdHJpZ2dl cnMgdGhhdCByZXR1cm5zIHRoZSBzeXN0ZW0gdG8gTm9ybWFsIFN0YXRlIGZyb20gRE5SIHN0YXRl Pw0KW1RhZXNpa10gSnVzdCBpc3N1ZSBNUy1XLCBhbmQgdGhlbiBjbGVhciBpdCBhdCBhbnkgdGlt ZSAod2hlbiB5b3Ugd2FudCB0byBnbyB0byBOb3JtYWwpLg0KDQpIb3BlIHRoaXMgY2xhcmlmaWVz LA0KeWFhY292DQoNCk9uIFRodSwgQXVnIDI5LCAyMDEzIGF0IDExOjU0IEFNLCDBpMXCvcQgPGN0 c0BldHJpLnJlLmtyPG1haWx0bzpjdHNAZXRyaS5yZS5rcj4+IHdyb3RlOg0KSGkgWWFhY292LA0K DQpZb3VyIHF1ZXN0aW9uIGlzIG5vdCBjbGVhciB0byBtZS4NCkJlZm9yZSBhbnN3ZXJpbmcgeW91 ciBxdWVzdGlvbiwgY291bGQgeW91IHBsZWFzZSBjbGFyaWZ5IGZvbGxvd2luZyB0d28gc2VudGVu Y2VzLCBlc3BlY2lhbGx5IGZvciB0aG9zZSBtYXJrZWQgd2l0aCA8PCA+Pj8NCi0gd2h5IGRvIHdl IG5lZWQgdGhlIDxpbnRlcm1lZGlhcnk+IHN0YXRlPw0KLSBpdCBiZXR0ZXIgdG8gPG5vdCBiZSBh ZG1pbmlzdHJhdGl2ZWx5IGNvbnRyb2xsZWQ+IGFuZCA8cmV2ZXJ0IHRvIE5vcm1hbCBTdGF0ZT4h DQoNCkJlc3QgcmVnYXJkcywNClRhZXNpaw0KDQpGcm9tOiBZYWFjb3YgV2VpbmdhcnRlbiBbbWFp bHRvOnd5YWFjb3ZAZ21haWwuY29tPG1haWx0bzp3eWFhY292QGdtYWlsLmNvbT5dDQpTZW50OiBX ZWRuZXNkYXksIEF1Z3VzdCAyOCwgMjAxMyA5OjE4IFBNDQpUbzogwaTFwr3EDQoNCkNjOiBtcGxz QGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgZHJhZnQtY2RoLW1wbHMtdHAtcHNjLW5v bi1yZXZlcnRpdmVAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWNkaC1tcGxzLXRwLXBzYy1u b24tcmV2ZXJ0aXZlQHRvb2xzLmlldGYub3JnPjsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8 bWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPg0KU3ViamVjdDogUmU6IFttcGxzXSBN UExTLVJUIHJldmlldyBvbiBkcmFmdC1jZGgtbXBscy10cC1wc2Mtbm9uLXJldmVydGl2ZS0wMC8v UkU6IE1QTFMtUlQgcmV2aWV3IG9mIG1wbHMgcHNjIGRvY3VtZW50cw0KDQpIaSwNCg0KU29ycnkg Zm9yIGJlaW5nIGluc2lzdGVudCAtIHlvdSBhbnN3ZXJlZCB0aGUgc2Vjb25kYXJ5IHF1ZXN0aW9u IGJ1dCBub3QgdGhlIHByaW1hcnkgcXVlc3Rpb24gLSBpZiB0aGlzIGlzIHN1cHBvc2VkIHRvIGJl IGZvciBwdXJwb3NlcyBvZiByZXZlcnNpb24gZnJvbSBhIEROUiBzdGF0ZSwgd2h5IGRvIHdlIG5l ZWQgdGhlIGludGVybWVkaWFyeSBzdGF0ZT8gSSB3b3VsZCB0aGluayBpdCBiZXR0ZXIgdG8gbm90 IGJlIGFkbWluaXN0cmF0aXZlbHkgY29udHJvbGxlZCBhbmQgcmV2ZXJ0IHRvIE5vcm1hbCBTdGF0 ZSENCg0KQlIsDQp5YWFjb3YNCg0KT24gV2VkLCBBdWcgMjgsIDIwMTMgYXQgMjozNyBQTSwgwaTF wr3EIDxjdHNAZXRyaS5yZS5rcjxtYWlsdG86Y3RzQGV0cmkucmUua3I+PiB3cm90ZToNCkhpIFlh YWNvdiwNCg0KSSBhbnN3ZXJlZCB0byB5b3VyIHF1ZXN0aW9uLiBQbGVhc2Ugc2VlIFtUYWVzaWsy XSBpbmxpbmUuDQoNCkJlc3QgcmVnYXJkcywNClRhZXNpaw0KDQpGcm9tOiBZYWFjb3YgV2Vpbmdh cnRlbiBbbWFpbHRvOnd5YWFjb3ZAZ21haWwuY29tPG1haWx0bzp3eWFhY292QGdtYWlsLmNvbT5d DQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyOCwgMjAxMyA3OjAzIFBNDQpUbzogwaTFwr3EDQpD YzogbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz47IGRyYWZ0LWNkaC1tcGxzLXRw LXBzYy1ub24tcmV2ZXJ0aXZlQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1jZGgtbXBscy10 cC1wc2Mtbm9uLXJldmVydGl2ZUB0b29scy5pZXRmLm9yZz47IG1wbHMtY2hhaXJzQHRvb2xzLmll dGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6 IFttcGxzXSBNUExTLVJUIHJldmlldyBvbiBkcmFmdC1jZGgtbXBscy10cC1wc2Mtbm9uLXJldmVy dGl2ZS0wMC8vUkU6IE1QTFMtUlQgcmV2aWV3IG9mIG1wbHMgcHNjIGRvY3VtZW50cw0KDQpUYWVz aWssIGhpDQoNClRoYW5rIHlvdSBmb3IgeW91ciByZXBseSB0byBteSBjb21tZW50cy4gV2hpbGUg SSBhcHByZWNpYXRlIHRoZSBwaGlsb3NvcGh5IHRoYXQgaXMgYmVoaW5kIHRoZSBwcm9wb3NlZCBm b3JtYXQgZm9yIHRoaXMgZHJhZnQgLSBhbmQgdGhhdCBzb21lIG9mIHlvdXIgY29uc2lkZXJhdGlv bnMgKGZvciBleGFtcGxlLCB5b3VyIG5lZWQgdG8gY2hhbmdlIHRoZSBuYW1lIG9mIE1hbnVhbCBT d2l0Y2ggLSBzb21ldGhpbmcgdGhhdCB3b3VsZCBub3QgYmUgbmVlZGVkIGlmIHlvdSBqdXN0IHdy b3RlIGFuIHVwZGF0ZSB0aGF0IGludHJvZHVjZWQgdGhlIG5ldyBvcGVyYXRvciBjb21tYW5kKSBh cmUgYSBkaXJlY3QgcmVzdWx0IG9mIHRoaXMgcGhpbG9zb3BoeS4NCg0KSG93ZXZlciwgSSBmb3Vu ZCBvbmUgb2YgeW91ciByZXBsaWVzIHRvIGJlIG9mIHNwZWNpYWwgaW50ZXJlc3QuDQpPbiBXZWQs IEF1ZyAyOCwgMjAxMyBhdCAzOjEwIEFNLCDBpMXCvcQgPGN0c0BldHJpLnJlLmtyPG1haWx0bzpj dHNAZXRyaS5yZS5rcj4+IHdyb3RlOg0KSGkgWWFhY292LA0KDQo8dHJpbW1lZCBjb250ZW50Pg0K DQozLiBJIHNlZSBwcm9ibGVtcyB3aXRoIHRoZSBzdWdnZXN0aW9uIHRvIGNoYW5nZSB0aGUgIlBy b3RlY3RpbmcgQWRtaW5pc3RyYXRpdmUgU3RhdGUiIHRvICJTd2l0Y2hpbmcgQWRtaW5pc3RyYXRp dmUgU3RhdGUiIHNpbmNlIHRoaXMgcmVxdWlyZXMgdGhlIGNvbmZ1c2luZyBzdGF0ZW1lbnQgKGlu IFNlY3Rpb24gNC45KSAidGhlIHVzZXIgdHJhZmZpYyBTSEFMTCBiZSB0cmFuc3BvcnRlZCBvbiBl aXRoZXIgdGhlIHByb3RlY3Rpb24gcGF0aCBvciB0aGUgd29ya2luZyBwYXRoIiB3aGljaCBpcyBj ZXJ0YWlubHkgYWx3YXlzIHRydWUgZm9yIHRyYWZmaWMgdGhhdCBpcyBiZWluZyB0cmFuc3BvcnRl ZC4gV2h5IG5vdCBjcmVhdGUgYSBuZXcgU3RhdGU/IE9yIGV2ZW4gYmV0dGVyLCBzaW5jZSB0aGUg TVMtVyBpcyBtZWFudCB0byByZXR1cm4gdGhlIHN0YXRlIHRvIE5vcm1hbCB3aHkgbm90IGp1c3Qg dXNlIE5vcm1hbCBzdGF0ZT8NCltUYWVzaWtdIFllcywgdHJhZmZpYyBhbHdheXMgZmxvdyBvbiBl aXRoZXIgdGhlIHdvcmtpbmcgb3IgcHJvdGVjdGlvbiBwYXRoLiBCdXQsIGl0IHNob3VsZCBiZSBu b3RlZCB0aGF0IGl0IGlzIKGwYWRtaW5pc3RyYXRpdmVseaGxIGNvbnRyb2xsZWQuIEluIHRoYXQg c2Vuc2UsIHdlIGNhbm5vdCBzYXkgdGhhdCBhIG5vZGUgaXMgaW4gobBOb3JtYWwgc3RhdGWhsSB3 aGVuIE1TLVcgY29tbWFuZCBpcyBpc3N1ZWQuIEJ5IHJlcGxhY2luZyChsFByb3RlY3RpbmcgYWRt aW5pc3RyYXRpdmUgc3RhdGWhsSBieSChsFN3aXRjaGluZyBhZG1pbmlzdHJhdGl2ZSBzdGF0ZaGx LCBpdCBjYW4gY292ZXIgYm90aCBjYXNlczogYWRtaW5pc3RyYXRpdmVseSBzd2l0Y2hlZCB0byB3 b3JraW5nIHBhdGggKGJ5IE1TLVcpIGFuZCBhZG1pbmlzdHJhdGl2ZWx5IHN3aXRjaGVkIHRvIHBy b3RlY3Rpb24gcGF0aCAoYnkgTVMtUCkuDQoNCjw8eXc+PiBXaGVuIEkgZmlyc3QgcmVhZCB0aGlz IGRyYWZ0IEkgd2FzIHVuZGVyIHRoZSBpbXByZXNzaW9uIHRoYXQgKGFzIGltcGllZCBieSB0aGUg dGl0bGUgb2YgdGhlIGRyYWZ0KSB0aGUgbWFpbiBqdXN0aWZpY2F0aW9uIGZvciBpbnRyb2R1Y2lu ZyB0aGUgTVMtVyBjb21tYW5kIHdhcyB0byBzb2x2ZSB0aGUgcHJvYmxlbSBvZiByZXZlcnRpbmcg dHJhZmZpYyBmcm9tIGEgbm9uLXJldmVydGl2ZSBzdGF0ZSBhbmQgcmV0dXJuaW5nIHRvIHRoZSBO b3JtYWwgU3RhdGUuIEhvd2V2ZXIsIGFjY29yZGluZyB0byB0aGlzIGV4cGxhbmF0aW9uLCB1c2lu ZyB0aGlzIGNvbW1hbmQgZG9lcyBub3QgcmV0dXJuIHlvdSB0byB0aGUgTm9ybWFsIFN0YXRlLCBi dXQgcmF0aGVyIHRvIHNvbWUgaW50ZXJtZWRpYXRlIHN0YXRlLCBzaW5jZSB5b3UgYXJlICJhZG1p bmlzdGFydGl2ZWx5IGNvbnRyb2xsZWQiIQ0KDQpTbyBjYW4geW91IHBsZWFzZSBleHBsYWluIGhv dyBkb2VzIHRoZSBvcGVyYXRvciByZXZlcnQgZnJvbSB0aGUgbm9uLXJldmVydGl2ZSBzaXR1YXRp b24gdG8gdGhlIE5vcm1hbCBTdGF0ZT8gKElzIGl0IGEgc2VxdWVuY2Ugb2YgTVMtVyBhbmQgdGhl biBpbW1lZGlhdGVseSBDbGVhcj8gSWYgc28sIHdoeSBpcyB0aGlzIGRpZmZlcmVudCBmcm9tIExP IGFuZCBpbW1lZGlhdGUgQ2xlYXI/KQ0KDQpbVGFlc2lrMl0gSWYgeW91IGlzc3VlIExPLCB5b3Ug Y2Fubm90IHByb3RlY3QgdHJhZmZpYyB3aGVuIFNGIG9yIFNEIGlzIHN1YnNlcXVlbnRseSBkZXRl Y3RlZCBvbiB0aGUgd29ya2luZyBwYXRoIHVudGlsIHRoZSBMTyBpcyBjbGVhcmVkLiBPbiB0aGUg b3RoZXIgaGFuZCwgaWYgeW91IHVzZSBNUy1XLCB0cmFmZmljIGNhbiBiZSBwcm90ZWN0ZWQgYmVj YXVzZSB0aGUgcHJpb3JpdHkgb2YgTVMtVyBpcyBsb3dlciB0aGFuIFNGIG9yIFNELg0KDQo8dHJp bW1lZCBjb250ZW50Pg0KDQotLQ0KVGhhbnggYW5kIEJSLA0KeWFhY292DQoNClN0aWxsIGxvb2tp bmcgZm9yIG5ldyBvcHBvcnR1bml0eQ0KDQoNCg0KLS0NClRoYW54IGFuZCBCUiwNCnlhYWNvdg0K DQpTdGlsbCBsb29raW5nIGZvciBuZXcgb3Bwb3J0dW5pdHkNCg0KDQoNCi0tDQpUaGFueCBhbmQg QlIsDQp5YWFjb3YNCg0KU3RpbGwgbG9va2luZyBmb3IgbmV3IG9wcG9ydHVuaXR5DQo= --_000_AD98114A73E97041A2EDDCC3F3D10B0311040B7ESMTP4etriinfo_ Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable

Hi Yaacov,

 

Please see [Taesik] inline.

 

Best regards,

Taesik

 

From: Yaacov Weingarten [mailto:wyaacov@gmail.com]
Sent: Thursday, August 29, 2013 6:18 PM
To: =C1=A4=C5=C2=BD=C4
Cc: mpls@ietf.org; draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.or= g; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-reve= rtive-00//RE: MPLS-RT review of mpls psc documents

 

Hi,

 

1. In your reply to my review c= omment - you explained that after issuing the MS-W command even though the = traffic is being transported on the working path it is in "Administart= ive Switching State" because it is "administratively" controlled - so I think that you need to explain what is meant by "ad= ministratively controlled".

[Taesik] =A1=B0Protecting administrative State=A1=B1 mea= ns that traffic is =A1=B0administratively controlled=A1=B1 to flow on the p= rotection path. =A1=B0Switching administrative state=A1=B1 means that the traffic is =A1= =B0administratively controlled=A1=B1 to flow on the protection path in case= of FS or MS(-P), or on the working path in case of MS-W.=

 

2. Regarding the other terms - = not sure what is not clear. If the traffic is on the protection path (eithe= r as a result of a SF [in RFC6378] or operator command [according= to your proposal]) and the system is in non-revertive state. When the switching trigger clears, the traffic remains on the prote= ction path and the system goes into DNR state. Your proposal (at least acco= rding to my original understanding) was to introduce a command that would a= llow the operator to cancel the DNR and revert to Normal State. However, I now understand that this is not= the case - but instead by issuing the MS-W command the system goes into an= intermediary state, i.e. Administratively Switching State, instead of goin= g back to Normal State.

[Taesik] FS, MS(-P) and MS-W are all same in the sense t= hat traffic is controlled by an operator. If I follow your logic, any state changed by an external command can be viewed as an intermediary stat= e until that command is cleared. But, I don=A1=AFt want to consider it as a= n intermediary state.

 

Therefore, my question was:

1. Why do we need this Administ= rative Switching State, why not go directly (i.e. revert) to Normal St= ate?

[Taesik] The Correct name proposed in this draft is =A1= =B0Switching Administrative State=A1=B1. =A1=B0Protecting Administrative St= ate=A1=B1 is already there. This draft proposes to rename it to cover MS-W as well as FS and MS= (-P).

[Taesik] If you change PSC state machine, you can do any= thing. This draft does not propose something new, but proposes to add an external command (MS-W) which has been identified in liaisons between I= TU-T and IETF that it is missing from RFC6378.

 

2. What is the sequence of comm= ands/operations/triggers that returns the system to Normal State from DNR s= tate?

[Taesik] Just issue MS-W, and then clear it at any time = (when you want to go to Normal).

 

Hope this clarifies,=

yaacov

=  

On Thu, Aug 29, 2013 at 11:54 A= M, =C1=A4=C5=C2=BD=C4 <cts@etri.re.kr> wrote:

H= i Yaacov,

&nbs= p;

Y= our question is not clear to me.

B= efore answering your question, could you please clarify following two sente= nces, especially for those marked with << >>?<= /o:p>

-= why do we need the <intermediary> state?=

-= it better to <not be administratively controlled> and <revert to = Normal State>!

&nbs= p;

B= est regards,

T= aesik

&nbs= p;

From: Yaacov Weingarten [mailto:= wyaacov@gmail.com]
Sent: Wednesday, August 28, 2013 9:18 PM
To: =C1=A4=C5=C2=BD=C4


Cc: mpls@ietf.org= ; draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-reve= rtive-00//RE: MPLS-RT review of mpls psc documents

 

Hi,

 

Sorry for being insistent - you answered the = secondary question but not the primary question - if this is supposed to be= for purposes of reversion from a DNR state, why do we need the intermediary state? I would think it better to n= ot be administratively controlled and revert to Normal State!

 

BR,

yaacov

 

On Wed, Aug 28, 2013 at 2:37 PM, =C1=A4=C5=C2=BD=C4 <cts@etri.re.kr> wrote:=

Hi Yaacov,

&nbs= p;

I answered to your qu= estion. Please see [Taesik2] inline.=

&nbs= p;

Best regards,<= span lang=3D"EN-US">

Taesik

&nbs= p;

From: Yaacov Weingarten [mailto:= wyaacov@gmail.com]
Sent: Wednesday, August 28, 2013 7:03 PM
To: =C1=A4=C5=C2=BD=C4
Cc: mpls@ietf.org= ; draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org; mpls-chairs@tools.ietf.org


Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-reve= rtive-00//RE: MPLS-RT review of mpls psc documents

 

Taesik, hi

 

Thank you for your reply to my comments. = ;While I appreciate the philosophy that is behind the proposed format for t= his draft - and that some of your considerations (for example, your need to change the name of Manual Switch - something th= at would not be needed if you just wrote an update that introduced the new = operator command) are a direct result of this philosophy.=

 

However, I found one of your replies to be of= special interest.

On Wed, Aug 28, 2013 at 3:10 AM, =C1=A4=C5=C2=BD=C4 <cts@etri.re.kr> wrote:=

Hi Yaacov,

&nbs= p;

<trimmed content>

&nbs= p;

3. I see problems with the suggestion to change the "= ;Protecting Administrative State" to "Switching Ad= ministrative State" since this requires the confusing statement (in Section 4.9) "the use= r traffic SHALL be transported on either the protection path or the working= path" which is certainly always true for traffic that is being transp= orted. Why not create a new State? Or even better, since the MS-W is meant to return the state to Normal why not just= use Normal state?

[Taesik] Yes, traffic= always flow on either the working or protection path. But, it should be no= ted that it is =A1=B0administrat= ively=A1=B1 controlled. In that sense, we cannot say that a node is in =A1=B0Normal state=A1=B1 when MS-W = command is issued. By replacing =A1=B0Protecting administrative state=A1= =B1 by =A1=B0Switching administrative state=A1= =B1, it can cover both cases: administratively switche= d to working path (by MS-W) and administratively switched to protection pat= h (by MS-P).

 

<<yw>> When I first read this dra= ft I was under the impression that (as impied by the title of the draft)&nb= sp;the main justification for introducing the MS-W command was to solve the problem of reverting traffic from a non-revertive state a= nd returning to the Normal State. However, according to this explanation, u= sing this command does not return you to the Normal State, but rather to so= me intermediate state, since you are "administartively controlled"! 

 

So can you please explain how does the operat= or revert from the non-revertive situation to the Normal State? (Is it a se= quence of MS-W and then immediately Clear? If so, why is this different from LO and immediate Clear?)

&nbs= p;

[Taesik2] If you issu= e LO, you cannot protect traffic when SF or SD is subsequently detected on the working path until the LO is cleared. On the other hand, i= f you use MS-W, traffic can be protected because the priority of MS-W is lo= wer than SF or SD.

&nbs= p;

<trimmed content><= /o:p>


--

Thanx and BR,

yaacov

 

Still looking for new opportunity




--

Thanx and BR,

yaacov

 

Still looking for new opportunity




--

Thanx and BR,=

yaacov

 

Still looking for new opport= unity

--_000_AD98114A73E97041A2EDDCC3F3D10B0311040B7ESMTP4etriinfo_-- From ryoo@etri.re.kr Thu Aug 29 19:38:04 2013 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 6EC2911E815C for ; Thu, 29 Aug 2013 19:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.945 X-Spam-Level: X-Spam-Status: No, score=-101.945 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 Qd6uF4DcCaIL for ; Thu, 29 Aug 2013 19:37:58 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id D73B011E80D5 for ; Thu, 29 Aug 2013 19:37:53 -0700 (PDT) Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 30 Aug 2013 11:37:47 +0900 Received: from SMTP2.etri.info ([169.254.2.105]) by SMTP3.etri.info ([129.254.28.73]) with mapi id 14.01.0355.002; Fri, 30 Aug 2013 11:37:43 +0900 From: "Ryoo, Jeong-dong" To: Yaacov Weingarten , =?utf-8?B?7KCV7YOc7Iud?= Thread-Topic: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents Thread-Index: AQHOlPgtITi9xt/X4EWPMBZVjhu4tZmgbNEAgACk5gCACDNugIAApXiAgAAaZYCAAAtYgIABWZAAgAAGkACAAaqMxQ== Date: Fri, 30 Aug 2013 02:37:41 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A286761C8@SMTP2.etri.info> References: <5204D9DE.6060405@pi.nu> , In-Reply-To: Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286761C8SMTP2etriinfo_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-cdh-mpls-tp-psc-non-revertive@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review on draft-cdh-mpls-tp-psc-non-revertive-00//RE: MPLS-RT review of mpls psc documents 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, 30 Aug 2013 02:38:04 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286761C8SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWFhY292LA0KDQpJZiB3ZSB3YW50IHRvIGNhbmNlbCB0aGUgRE5SIGFuZCByZXZlcnQgdG8gTm9y bWFsIHN0YXRlLCB3ZSBjYW5ub3QgdXNlIGEgIkNhbmNlbC9DbGVhciBETlIiIGNvbW1hbmQgZGly ZWN0bHkuDQoNCkxldCdzIGFzc3VtZSBzdWNoIGEgY2xlYXIgRE5SIGNvbW1hbmQgZXhpc3RzLg0K MS4gSWYgdGhlIGNsZWFyIGNvbW1hbmQgaXMgaXNzdWVkIGF0IG5vZGUgQSBpbiBETlIgc3RhdGUs IHRoZW4gbm9kZSBBIHdpbGwgZW50ZXIgTm9ybWFsIHN0YXRlIGFuZCBnZW5lcmF0ZSBOUiBtZXNz YWdlcy4NCjIuIFdoZW4gbm9kZSBaIHJlY2VpdmVzIHRoZSBOUiBtZXNzYWdlIGluIEROUiBzdGF0 ZSwgaXQgd2lsbCBpZ25vcmUgdGhlIE5SIGZyb20gbm9kZSBBIGFjY29yZGluZyB0byB0aGUgY3Vy cmVudCBQU0Mgc3RhdGUgbWFjaGluZSBpbiBSRkM2Mzc4LiBBbmQgbm9kZSBaIGtlZXBzIHNlbmRp bmcgRE5SIG1lc3NhZ2UuDQozLiBXaGVuIG5vZGUgQSByZWNlaXZlcyB0aGUgRE5SIG1lc3NhZ2Us IGl0IHdpbGwgYmUgaWdub3JlZCBhY2NvcmRpbmcgdG8gdGhlIGN1cnJlbnQgUFNDIHN0YXRlIG1h Y2hpbmUgaW4gUkZDNjM3OC4NCjQuIE5vdywgdGhlIHJldmVyc2lvbiB0byBOb3JtYWwgc3RhdGUg ZmFpbHMuIE1vcmVvdmVyLCB3ZSBoYXZlIG91dCBvZiBzZXJ2aWNlIHNpdHVhdGlvbiBhcyBub2Rl IEEncyBicmlkZ2UgYW5kIHNlbGVjdG9yIGFyZSBwb2ludGluZyB0aGUgd29ya2luZyBwYXRoIGFu ZCBub2RlIEIncyBicmlkZ2UgYW5kIHNlbGVjdG9yIGFyZSBwb2ludCB0aGUgcHJvdGVjdGlvbiBw YXRoLg0KDQpJbiB0aGUgb3RoZXIgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgdGVjaG5vbG9neSwgc3Vj aCBhcyBJVFUtVCdzIEFQUywgdGhlcmUgaXMgbm8gb25lLXNob3QgY2xlYXIgY29tbWFuZCB0aGF0 IGNhbiBjbGVhciBETlIgc3RhdGUgYW5kIHJldmVydCBkaXJlY3RseSB0byBOb3JtYWwgb3IgIk5v IHJlcXVlc3QiIHN0YXRlLg0KDQpTbyB0aGUgc2VxdWVuY2Ugb2YgTVMtVyBmb2xsb3dlZCBieSBD bGVhciBNUy1XIHdpbGwgZG8gdGhlIGpvYiBjb3JyZWN0bHkuDQpIZXJlLCB3ZSBjYW5ub3QgdXNl IE1TLVAgaW5zdGVhZCBvZiBNUy1XLCBhcyBjbGVhcmluZyBNUy1QIHdpbGwgcmVzdWx0IGluIGVu dGVyaW5nIHRoZSBETlIgc3RhdGUgYWdhaW4uDQoNCklmIHRoaXMgaXMgbm90IGFuIGFuc3dlciBm b3IgeW91ciBxdWVzdGlvbiwgcGxlYXNlIGxldCBtZSBrbm93Lg0KDQpCZXN0IHJlZ2FyZHMsDQoN Ckplb25nLWRvbmcNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9t IDogIllhYWNvdiBXZWluZ2FydGVuIiA8d3lhYWNvdkBnbWFpbC5jb20+DQpTZW50IDogMjAxMy0w OC0yOSAxODoxODoxNyAoICswOTowMCApDQpUbyA6IOygle2DnOyLnSA8Y3RzQGV0cmkucmUua3I+ DQpDYyA6IG1wbHNAaWV0Zi5vcmcgPG1wbHNAaWV0Zi5vcmc+LCBkcmFmdC1jZGgtbXBscy10cC1w c2Mtbm9uLXJldmVydGl2ZUB0b29scy5pZXRmLm9yZyA8ZHJhZnQtY2RoLW1wbHMtdHAtcHNjLW5v bi1yZXZlcnRpdmVAdG9vbHMuaWV0Zi5vcmc+LCBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyA8 bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0IDogUmU6IFttcGxzXSBNUExTLVJU IHJldmlldyBvbiBkcmFmdC1jZGgtbXBscy10cC1wc2Mtbm9uLXJldmVydGl2ZS0wMC8vUkU6IE1Q TFMtUlQgcmV2aWV3IG9mIG1wbHMgcHNjIGRvY3VtZW50cw0KDQpIaSwNCg0KMS4gSW4geW91ciBy ZXBseSB0byBteSByZXZpZXcgY29tbWVudCAtIHlvdSBleHBsYWluZWQgdGhhdCBhZnRlciBpc3N1 aW5nIHRoZSBNUy1XIGNvbW1hbmQgZXZlbiB0aG91Z2ggdGhlIHRyYWZmaWMgaXMgYmVpbmcgdHJh bnNwb3J0ZWQgb24gdGhlIHdvcmtpbmcgcGF0aCBpdCBpcyBpbiAiQWRtaW5pc3RhcnRpdmUgU3dp dGNoaW5nIFN0YXRlIiBiZWNhdXNlIGl0IGlzICJhZG1pbmlzdHJhdGl2ZWx5IiBjb250cm9sbGVk IC0gc28gSSB0aGluayB0aGF0IHlvdSBuZWVkIHRvIGV4cGxhaW4gd2hhdCBpcyBtZWFudCBieSAi YWRtaW5pc3RyYXRpdmVseSBjb250cm9sbGVkIi4NCg0KMi4gUmVnYXJkaW5nIHRoZSBvdGhlciB0 ZXJtcyAtIG5vdCBzdXJlIHdoYXQgaXMgbm90IGNsZWFyLiBJZiB0aGUgdHJhZmZpYyBpcyBvbiB0 aGUgcHJvdGVjdGlvbiBwYXRoIChlaXRoZXIgYXMgYSByZXN1bHQgb2YgYSBTRiBbaW4gUkZDNjM3 OF0gb3Igb3BlcmF0b3IgY29tbWFuZCBbYWNjb3JkaW5nIHRvIHlvdXIgcHJvcG9zYWxdKSBhbmQg dGhlIHN5c3RlbSBpcyBpbiBub24tcmV2ZXJ0aXZlIHN0YXRlLiBXaGVuIHRoZSBzd2l0Y2hpbmcg dHJpZ2dlciBjbGVhcnMsIHRoZSB0cmFmZmljIHJlbWFpbnMgb24gdGhlIHByb3RlY3Rpb24gcGF0 aCBhbmQgdGhlIHN5c3RlbSBnb2VzIGludG8gRE5SIHN0YXRlLiBZb3VyIHByb3Bvc2FsIChhdCBs ZWFzdCBhY2NvcmRpbmcgdG8gbXkgb3JpZ2luYWwgdW5kZXJzdGFuZGluZykgd2FzIHRvIGludHJv ZHVjZSBhIGNvbW1hbmQgdGhhdCB3b3VsZCBhbGxvdyB0aGUgb3BlcmF0b3IgdG8gY2FuY2VsIHRo ZSBETlIgYW5kIHJldmVydCB0byBOb3JtYWwgU3RhdGUuIEhvd2V2ZXIsIEkgbm93IHVuZGVyc3Rh bmQgdGhhdCB0aGlzIGlzIG5vdCB0aGUgY2FzZSAtIGJ1dCBpbnN0ZWFkIGJ5IGlzc3VpbmcgdGhl IE1TLVcgY29tbWFuZCB0aGUgc3lzdGVtIGdvZXMgaW50byBhbiBpbnRlcm1lZGlhcnkgc3RhdGUs IGkuZS4gQWRtaW5pc3RyYXRpdmVseSBTd2l0Y2hpbmcgU3RhdGUsIGluc3RlYWQgb2YgZ29pbmcg YmFjayB0byBOb3JtYWwgU3RhdGUuDQoNClRoZXJlZm9yZSwgbXkgcXVlc3Rpb24gd2FzOg0KMS4g V2h5IGRvIHdlIG5lZWQgdGhpcyBBZG1pbmlzdHJhdGl2ZSBTd2l0Y2hpbmcgU3RhdGUsIHdoeSBu b3QgZ28gZGlyZWN0bHkgKGkuZS4gcmV2ZXJ0KSB0byBOb3JtYWwgU3RhdGU/DQoyLiBXaGF0IGlz IHRoZSBzZXF1ZW5jZSBvZiBjb21tYW5kcy9vcGVyYXRpb25zL3RyaWdnZXJzIHRoYXQgcmV0dXJu cyB0aGUgc3lzdGVtIHRvIE5vcm1hbCBTdGF0ZSBmcm9tIEROUiBzdGF0ZT8NCg0KSG9wZSB0aGlz IGNsYXJpZmllcywNCnlhYWNvdg0KDQoNCk9uIFRodSwgQXVnIDI5LCAyMDEzIGF0IDExOjU0IEFN LCDsoJXtg5zsi50gPGN0c0BldHJpLnJlLmtyPG1haWx0bzpjdHNAZXRyaS5yZS5rcj4+IHdyb3Rl Og0KSGkgWWFhY292LA0KDQpZb3VyIHF1ZXN0aW9uIGlzIG5vdCBjbGVhciB0byBtZS4NCkJlZm9y ZSBhbnN3ZXJpbmcgeW91ciBxdWVzdGlvbiwgY291bGQgeW91IHBsZWFzZSBjbGFyaWZ5IGZvbGxv d2luZyB0d28gc2VudGVuY2VzLCBlc3BlY2lhbGx5IGZvciB0aG9zZSBtYXJrZWQgd2l0aCA8PCA+ Pj8NCi0gd2h5IGRvIHdlIG5lZWQgdGhlIDxpbnRlcm1lZGlhcnk+IHN0YXRlPw0KLSBpdCBiZXR0 ZXIgdG8gPG5vdCBiZSBhZG1pbmlzdHJhdGl2ZWx5IGNvbnRyb2xsZWQ+IGFuZCA8cmV2ZXJ0IHRv IE5vcm1hbCBTdGF0ZT4hDQoNCkJlc3QgcmVnYXJkcywNClRhZXNpaw0KDQpGcm9tOiBZYWFjb3Yg V2VpbmdhcnRlbiBbbWFpbHRvOnd5YWFjb3ZAZ21haWwuY29tPG1haWx0bzp3eWFhY292QGdtYWls LmNvbT5dDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyOCwgMjAxMyA5OjE4IFBNDQpUbzog7KCV 7YOc7IudDQoNCkNjOiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgZHJhZnQt Y2RoLW1wbHMtdHAtcHNjLW5vbi1yZXZlcnRpdmVAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0 LWNkaC1tcGxzLXRwLXBzYy1ub24tcmV2ZXJ0aXZlQHRvb2xzLmlldGYub3JnPjsgbXBscy1jaGFp cnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPg0KU3Vi amVjdDogUmU6IFttcGxzXSBNUExTLVJUIHJldmlldyBvbiBkcmFmdC1jZGgtbXBscy10cC1wc2Mt bm9uLXJldmVydGl2ZS0wMC8vUkU6IE1QTFMtUlQgcmV2aWV3IG9mIG1wbHMgcHNjIGRvY3VtZW50 cw0KDQpIaSwNCg0KU29ycnkgZm9yIGJlaW5nIGluc2lzdGVudCAtIHlvdSBhbnN3ZXJlZCB0aGUg c2Vjb25kYXJ5IHF1ZXN0aW9uIGJ1dCBub3QgdGhlIHByaW1hcnkgcXVlc3Rpb24gLSBpZiB0aGlz IGlzIHN1cHBvc2VkIHRvIGJlIGZvciBwdXJwb3NlcyBvZiByZXZlcnNpb24gZnJvbSBhIEROUiBz dGF0ZSwgd2h5IGRvIHdlIG5lZWQgdGhlIGludGVybWVkaWFyeSBzdGF0ZT8gSSB3b3VsZCB0aGlu ayBpdCBiZXR0ZXIgdG8gbm90IGJlIGFkbWluaXN0cmF0aXZlbHkgY29udHJvbGxlZCBhbmQgcmV2 ZXJ0IHRvIE5vcm1hbCBTdGF0ZSENCg0KQlIsDQp5YWFjb3YNCg0KT24gV2VkLCBBdWcgMjgsIDIw MTMgYXQgMjozNyBQTSwg7KCV7YOc7IudIDxjdHNAZXRyaS5yZS5rcjxtYWlsdG86Y3RzQGV0cmku cmUua3I+PiB3cm90ZToNCkhpIFlhYWNvdiwNCg0KSSBhbnN3ZXJlZCB0byB5b3VyIHF1ZXN0aW9u LiBQbGVhc2Ugc2VlIFtUYWVzaWsyXSBpbmxpbmUuDQoNCkJlc3QgcmVnYXJkcywNClRhZXNpaw0K DQpGcm9tOiBZYWFjb3YgV2VpbmdhcnRlbiBbbWFpbHRvOnd5YWFjb3ZAZ21haWwuY29tPG1haWx0 bzp3eWFhY292QGdtYWlsLmNvbT5dDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyOCwgMjAxMyA3 OjAzIFBNDQpUbzog7KCV7YOc7IudDQpDYzogbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRm Lm9yZz47IGRyYWZ0LWNkaC1tcGxzLXRwLXBzYy1ub24tcmV2ZXJ0aXZlQHRvb2xzLmlldGYub3Jn PG1haWx0bzpkcmFmdC1jZGgtbXBscy10cC1wc2Mtbm9uLXJldmVydGl2ZUB0b29scy5pZXRmLm9y Zz47IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5p ZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFttcGxzXSBNUExTLVJUIHJldmlldyBvbiBkcmFmdC1j ZGgtbXBscy10cC1wc2Mtbm9uLXJldmVydGl2ZS0wMC8vUkU6IE1QTFMtUlQgcmV2aWV3IG9mIG1w bHMgcHNjIGRvY3VtZW50cw0KDQpUYWVzaWssIGhpDQoNClRoYW5rIHlvdSBmb3IgeW91ciByZXBs eSB0byBteSBjb21tZW50cy4gV2hpbGUgSSBhcHByZWNpYXRlIHRoZSBwaGlsb3NvcGh5IHRoYXQg aXMgYmVoaW5kIHRoZSBwcm9wb3NlZCBmb3JtYXQgZm9yIHRoaXMgZHJhZnQgLSBhbmQgdGhhdCBz b21lIG9mIHlvdXIgY29uc2lkZXJhdGlvbnMgKGZvciBleGFtcGxlLCB5b3VyIG5lZWQgdG8gY2hh bmdlIHRoZSBuYW1lIG9mIE1hbnVhbCBTd2l0Y2ggLSBzb21ldGhpbmcgdGhhdCB3b3VsZCBub3Qg YmUgbmVlZGVkIGlmIHlvdSBqdXN0IHdyb3RlIGFuIHVwZGF0ZSB0aGF0IGludHJvZHVjZWQgdGhl IG5ldyBvcGVyYXRvciBjb21tYW5kKSBhcmUgYSBkaXJlY3QgcmVzdWx0IG9mIHRoaXMgcGhpbG9z b3BoeS4NCg0KSG93ZXZlciwgSSBmb3VuZCBvbmUgb2YgeW91ciByZXBsaWVzIHRvIGJlIG9mIHNw ZWNpYWwgaW50ZXJlc3QuDQpPbiBXZWQsIEF1ZyAyOCwgMjAxMyBhdCAzOjEwIEFNLCDsoJXtg5zs i50gPGN0c0BldHJpLnJlLmtyPG1haWx0bzpjdHNAZXRyaS5yZS5rcj4+IHdyb3RlOg0KSGkgWWFh Y292LA0KDQo8dHJpbW1lZCBjb250ZW50Pg0KDQozLiBJIHNlZSBwcm9ibGVtcyB3aXRoIHRoZSBz dWdnZXN0aW9uIHRvIGNoYW5nZSB0aGUgIlByb3RlY3RpbmcgQWRtaW5pc3RyYXRpdmUgU3RhdGUi IHRvICJTd2l0Y2hpbmcgQWRtaW5pc3RyYXRpdmUgU3RhdGUiIHNpbmNlIHRoaXMgcmVxdWlyZXMg dGhlIGNvbmZ1c2luZyBzdGF0ZW1lbnQgKGluIFNlY3Rpb24gNC45KSAidGhlIHVzZXIgdHJhZmZp YyBTSEFMTCBiZSB0cmFuc3BvcnRlZCBvbiBlaXRoZXIgdGhlIHByb3RlY3Rpb24gcGF0aCBvciB0 aGUgd29ya2luZyBwYXRoIiB3aGljaCBpcyBjZXJ0YWlubHkgYWx3YXlzIHRydWUgZm9yIHRyYWZm aWMgdGhhdCBpcyBiZWluZyB0cmFuc3BvcnRlZC4gV2h5IG5vdCBjcmVhdGUgYSBuZXcgU3RhdGU/ IE9yIGV2ZW4gYmV0dGVyLCBzaW5jZSB0aGUgTVMtVyBpcyBtZWFudCB0byByZXR1cm4gdGhlIHN0 YXRlIHRvIE5vcm1hbCB3aHkgbm90IGp1c3QgdXNlIE5vcm1hbCBzdGF0ZT8NCltUYWVzaWtdIFll cywgdHJhZmZpYyBhbHdheXMgZmxvdyBvbiBlaXRoZXIgdGhlIHdvcmtpbmcgb3IgcHJvdGVjdGlv biBwYXRoLiBCdXQsIGl0IHNob3VsZCBiZSBub3RlZCB0aGF0IGl0IGlzIOKAnGFkbWluaXN0cmF0 aXZlbHnigJ0gY29udHJvbGxlZC4gSW4gdGhhdCBzZW5zZSwgd2UgY2Fubm90IHNheSB0aGF0IGEg bm9kZSBpcyBpbiDigJxOb3JtYWwgc3RhdGXigJ0gd2hlbiBNUy1XIGNvbW1hbmQgaXMgaXNzdWVk LiBCeSByZXBsYWNpbmcg4oCcUHJvdGVjdGluZyBhZG1pbmlzdHJhdGl2ZSBzdGF0ZeKAnSBieSDi gJxTd2l0Y2hpbmcgYWRtaW5pc3RyYXRpdmUgc3RhdGXigJ0sIGl0IGNhbiBjb3ZlciBib3RoIGNh c2VzOiBhZG1pbmlzdHJhdGl2ZWx5IHN3aXRjaGVkIHRvIHdvcmtpbmcgcGF0aCAoYnkgTVMtVykg YW5kIGFkbWluaXN0cmF0aXZlbHkgc3dpdGNoZWQgdG8gcHJvdGVjdGlvbiBwYXRoIChieSBNUy1Q KS4NCg0KPDx5dz4+IFdoZW4gSSBmaXJzdCByZWFkIHRoaXMgZHJhZnQgSSB3YXMgdW5kZXIgdGhl IGltcHJlc3Npb24gdGhhdCAoYXMgaW1waWVkIGJ5IHRoZSB0aXRsZSBvZiB0aGUgZHJhZnQpIHRo ZSBtYWluIGp1c3RpZmljYXRpb24gZm9yIGludHJvZHVjaW5nIHRoZSBNUy1XIGNvbW1hbmQgd2Fz IHRvIHNvbHZlIHRoZSBwcm9ibGVtIG9mIHJldmVydGluZyB0cmFmZmljIGZyb20gYSBub24tcmV2 ZXJ0aXZlIHN0YXRlIGFuZCByZXR1cm5pbmcgdG8gdGhlIE5vcm1hbCBTdGF0ZS4gSG93ZXZlciwg YWNjb3JkaW5nIHRvIHRoaXMgZXhwbGFuYXRpb24sIHVzaW5nIHRoaXMgY29tbWFuZCBkb2VzIG5v dCByZXR1cm4geW91IHRvIHRoZSBOb3JtYWwgU3RhdGUsIGJ1dCByYXRoZXIgdG8gc29tZSBpbnRl cm1lZGlhdGUgc3RhdGUsIHNpbmNlIHlvdSBhcmUgImFkbWluaXN0YXJ0aXZlbHkgY29udHJvbGxl ZCIhDQoNClNvIGNhbiB5b3UgcGxlYXNlIGV4cGxhaW4gaG93IGRvZXMgdGhlIG9wZXJhdG9yIHJl dmVydCBmcm9tIHRoZSBub24tcmV2ZXJ0aXZlIHNpdHVhdGlvbiB0byB0aGUgTm9ybWFsIFN0YXRl PyAoSXMgaXQgYSBzZXF1ZW5jZSBvZiBNUy1XIGFuZCB0aGVuIGltbWVkaWF0ZWx5IENsZWFyPyBJ ZiBzbywgd2h5IGlzIHRoaXMgZGlmZmVyZW50IGZyb20gTE8gYW5kIGltbWVkaWF0ZSBDbGVhcj8p DQoNCltUYWVzaWsyXSBJZiB5b3UgaXNzdWUgTE8sIHlvdSBjYW5ub3QgcHJvdGVjdCB0cmFmZmlj IHdoZW4gU0Ygb3IgU0QgaXMgc3Vic2VxdWVudGx5IGRldGVjdGVkIG9uIHRoZSB3b3JraW5nIHBh dGggdW50aWwgdGhlIExPIGlzIGNsZWFyZWQuIE9uIHRoZSBvdGhlciBoYW5kLCBpZiB5b3UgdXNl IE1TLVcsIHRyYWZmaWMgY2FuIGJlIHByb3RlY3RlZCBiZWNhdXNlIHRoZSBwcmlvcml0eSBvZiBN Uy1XIGlzIGxvd2VyIHRoYW4gU0Ygb3IgU0QuDQoNCjx0cmltbWVkIGNvbnRlbnQ+DQoNCi0tDQpU aGFueCBhbmQgQlIsDQp5YWFjb3YNCg0KU3RpbGwgbG9va2luZyBmb3IgbmV3IG9wcG9ydHVuaXR5 DQoNCg0KDQotLQ0KVGhhbnggYW5kIEJSLA0KeWFhY292DQoNClN0aWxsIGxvb2tpbmcgZm9yIG5l dyBvcHBvcnR1bml0eQ0KDQoNCg0KLS0NClRoYW54IGFuZCBCUiwNCnlhYWNvdg0KDQpTdGlsbCBs b29raW5nIGZvciBuZXcgb3Bwb3J0dW5pdHkNCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286761C8SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5ZYWFjb3YsPC9kaXY+DQo8ZGl2IHN0eWxlPSJM SU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDog MTVwdCI+SWYgd2Ugd2FudCB0byBjYW5jZWwgdGhlIEROUiBhbmQgcmV2ZXJ0IHRvIE5vcm1hbCBz dGF0ZSwgd2UgY2Fubm90IHVzZSBhICZxdW90O0NhbmNlbC9DbGVhciBETlImcXVvdDsgY29tbWFu ZCBkaXJlY3RseS48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8 L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5MZXQncyBhc3N1bWUgc3VjaCBh IGNsZWFyIEROUiBjb21tYW5kIGV4aXN0cy48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hU OiAxNXB0Ij4xLiBJZiB0aGUgY2xlYXIgY29tbWFuZCBpcyBpc3N1ZWQgYXQgbm9kZSBBIGluIERO UiBzdGF0ZSwgdGhlbiZuYnNwO25vZGUgQSB3aWxsJm5ic3A7ZW50ZXIgTm9ybWFsIHN0YXRlIGFu ZCBnZW5lcmF0ZSBOUiBtZXNzYWdlcy48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAx NXB0Ij4yLiBXaGVuIG5vZGUgWiByZWNlaXZlcyB0aGUgTlIgbWVzc2FnZSBpbiBETlIgc3RhdGUs IGl0IHdpbGwgaWdub3JlIHRoZSBOUiBmcm9tIG5vZGUgQSBhY2NvcmRpbmcgdG8gdGhlIGN1cnJl bnQgUFNDIHN0YXRlIG1hY2hpbmUgaW4gUkZDNjM3OC4gQW5kIG5vZGUgWiBrZWVwcyBzZW5kaW5n IEROUiBtZXNzYWdlLjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPjMuIFdo ZW4gbm9kZSBBIHJlY2VpdmVzIHRoZSBETlIgbWVzc2FnZSwgaXQgd2lsbCBiZSBpZ25vcmVkIGFj Y29yZGluZyB0byB0aGUgY3VycmVudCBQU0Mgc3RhdGUgbWFjaGluZSBpbiBSRkM2Mzc4LjwvZGl2 Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPjQuIE5vdywgdGhlIHJldmVyc2lvbiB0 byBOb3JtYWwgc3RhdGUgZmFpbHMuIE1vcmVvdmVyLCB3ZSBoYXZlIG91dCBvZiBzZXJ2aWNlIHNp dHVhdGlvbiBhcyBub2RlIEEncyBicmlkZ2UgYW5kIHNlbGVjdG9yIGFyZSBwb2ludGluZyB0aGUg d29ya2luZyBwYXRoIGFuZCBub2RlIEIncyBicmlkZ2UgYW5kIHNlbGVjdG9yIGFyZSZuYnNwO3Bv aW50Jm5ic3A7dGhlIHByb3RlY3Rpb24gcGF0aC48L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5J biB0aGUgb3RoZXIgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgdGVjaG5vbG9neSwgc3VjaCBhcyBJVFUt VCdzIEFQUywgdGhlcmUgaXMgbm8gb25lLXNob3QmbmJzcDtjbGVhciBjb21tYW5kIHRoYXQgY2Fu IGNsZWFyJm5ic3A7RE5SIHN0YXRlIGFuZCByZXZlcnQgZGlyZWN0bHkgdG8gTm9ybWFsIG9yICZx dW90O05vIHJlcXVlc3QmcXVvdDsgc3RhdGUuPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdI VDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+U28g dGhlIHNlcXVlbmNlIG9mJm5ic3A7TVMtVyBmb2xsb3dlZCBieSBDbGVhciBNUy1XIHdpbGwgZG8g dGhlIGpvYiBjb3JyZWN0bHkuPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+ SGVyZSwgd2UgY2Fubm90IHVzZSBNUy1QIGluc3RlYWQgb2YgTVMtVywgYXMgY2xlYXJpbmcgTVMt UCB3aWxsIHJlc3VsdCBpbiBlbnRlcmluZyB0aGUgRE5SIHN0YXRlIGFnYWluLjwvZGl2Pg0KPGRp diBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElO RS1IRUlHSFQ6IDE1cHQiPklmIHRoaXMgaXMgbm90Jm5ic3A7YW4gYW5zd2VyIGZvciB5b3VyIHF1 ZXN0aW9uLCBwbGVhc2UgbGV0IG1lIGtub3cuPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdI VDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+QmVz dCByZWdhcmRzLDwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwv ZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkplb25nLWRvbmc8L2Rpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJ TkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAx NXB0IiBpZD0iTWFpbFNpZ24iPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6 IDE1cHQiPg0KPGhyIHRhYmluZGV4PSItMSI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJ R0hUOiAxNXB0Ij48Yj5Gcm9tIDogPC9iPiZxdW90O1lhYWNvdiBXZWluZ2FydGVuJnF1b3Q7ICZs dDt3eWFhY292QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5TZW50IDogPC9iPjIwMTMtMDgtMjkgMTg6 MTg6MTcgKCAmIzQzOzA5OjAwICk8YnI+DQo8Yj5UbyA6IDwvYj7soJXtg5zsi50gJmx0O2N0c0Bl dHJpLnJlLmtyJmd0Ozxicj4NCjxiPkNjIDogPC9iPm1wbHNAaWV0Zi5vcmcgJmx0O21wbHNAaWV0 Zi5vcmcmZ3Q7LCBkcmFmdC1jZGgtbXBscy10cC1wc2Mtbm9uLXJldmVydGl2ZUB0b29scy5pZXRm Lm9yZyAmbHQ7ZHJhZnQtY2RoLW1wbHMtdHAtcHNjLW5vbi1yZXZlcnRpdmVAdG9vbHMuaWV0Zi5v cmcmZ3Q7LCBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyAmbHQ7bXBscy1jaGFpcnNAdG9vbHMu aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdCA6IDwvYj5SZTogW21wbHNdIE1QTFMtUlQgcmV2 aWV3IG9uIGRyYWZ0LWNkaC1tcGxzLXRwLXBzYy1ub24tcmV2ZXJ0aXZlLTAwLy9SRTogTVBMUy1S VCByZXZpZXcgb2YgbXBscyBwc2MgZG9jdW1lbnRzPGJyPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgZGlyPSJsdHIiPg0KPGRpdj5IaSw8L2Rpdj4NCjxkaXY+ Jm5ic3A7PC9kaXY+DQo8ZGl2PjEuIEluIHlvdXIgcmVwbHkgdG8gbXkgcmV2aWV3IGNvbW1lbnQg LSB5b3UgZXhwbGFpbmVkIHRoYXQgYWZ0ZXIgaXNzdWluZyB0aGUgTVMtVyBjb21tYW5kIGV2ZW4g dGhvdWdoIHRoZSB0cmFmZmljIGlzIGJlaW5nIHRyYW5zcG9ydGVkIG9uIHRoZSB3b3JraW5nIHBh dGggaXQgaXMgaW4gJnF1b3Q7QWRtaW5pc3RhcnRpdmUgU3dpdGNoaW5nIFN0YXRlJnF1b3Q7IGJl Y2F1c2UgaXQgaXMgJnF1b3Q7YWRtaW5pc3RyYXRpdmVseSZxdW90OyBjb250cm9sbGVkIC0gc28g SSB0aGluaw0KIHRoYXQgeW91IG5lZWQgdG8gZXhwbGFpbiB3aGF0IGlzIG1lYW50IGJ5ICZxdW90 O2FkbWluaXN0cmF0aXZlbHkgY29udHJvbGxlZCZxdW90Oy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9k aXY+DQo8ZGl2PjIuIFJlZ2FyZGluZyB0aGUgb3RoZXIgdGVybXMgLSBub3Qgc3VyZSB3aGF0IGlz IG5vdCBjbGVhci4gSWYgdGhlIHRyYWZmaWMgaXMgb24gdGhlIHByb3RlY3Rpb24gcGF0aCAoZWl0 aGVyIGFzIGEgcmVzdWx0IG9mIGEgU0YgW2luJm5ic3A7UkZDNjM3OF0mbmJzcDtvciBvcGVyYXRv ciBjb21tYW5kIFthY2NvcmRpbmcgdG8geW91ciBwcm9wb3NhbF0pIGFuZCB0aGUgc3lzdGVtIGlz IGluIG5vbi1yZXZlcnRpdmUgc3RhdGUuIFdoZW4gdGhlIHN3aXRjaGluZw0KIHRyaWdnZXIgY2xl YXJzLCB0aGUgdHJhZmZpYyByZW1haW5zIG9uIHRoZSBwcm90ZWN0aW9uIHBhdGggYW5kIHRoZSBz eXN0ZW0gZ29lcyBpbnRvIEROUiBzdGF0ZS4gWW91ciBwcm9wb3NhbCAoYXQgbGVhc3QgYWNjb3Jk aW5nIHRvIG15IG9yaWdpbmFsIHVuZGVyc3RhbmRpbmcpIHdhcyB0byBpbnRyb2R1Y2UgYSBjb21t YW5kIHRoYXQgd291bGQgYWxsb3cgdGhlIG9wZXJhdG9yIHRvIGNhbmNlbCB0aGUgRE5SIGFuZCBy ZXZlcnQgdG8gTm9ybWFsIFN0YXRlLg0KIEhvd2V2ZXIsIEkgbm93IHVuZGVyc3RhbmQgdGhhdCB0 aGlzIGlzIG5vdCB0aGUgY2FzZSAtIGJ1dCBpbnN0ZWFkIGJ5IGlzc3VpbmcgdGhlIE1TLVcgY29t bWFuZCB0aGUgc3lzdGVtIGdvZXMgaW50byBhbiBpbnRlcm1lZGlhcnkgc3RhdGUsIGkuZS4gQWRt aW5pc3RyYXRpdmVseSBTd2l0Y2hpbmcgU3RhdGUsIGluc3RlYWQgb2YgZ29pbmcgYmFjayB0byBO b3JtYWwgU3RhdGUuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGVyZWZvcmUsIG15 IHF1ZXN0aW9uIHdhczo8L2Rpdj4NCjxkaXY+MS4gV2h5IGRvIHdlIG5lZWQgdGhpcyBBZG1pbmlz dHJhdGl2ZSBTd2l0Y2hpbmcgU3RhdGUsIHdoeSBub3QgZ28gZGlyZWN0bHkgKGkuZS4gcmV2ZXJ0 KSZuYnNwO3RvIE5vcm1hbCBTdGF0ZT88L2Rpdj4NCjxkaXY+Mi4gV2hhdCBpcyB0aGUgc2VxdWVu Y2Ugb2YgY29tbWFuZHMvb3BlcmF0aW9ucy90cmlnZ2VycyB0aGF0IHJldHVybnMgdGhlIHN5c3Rl bSB0byBOb3JtYWwgU3RhdGUgZnJvbSBETlIgc3RhdGU/PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPGRpdj5Ib3BlIHRoaXMgY2xhcmlmaWVzLDwvZGl2Pg0KPGRpdj55YWFjb3Y8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJnbWFpbF9leHRyYSI+ PGJyPg0KPGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFRodSwgQXVnIDI5LCAyMDEz IGF0IDExOjU0IEFNLCDsoJXtg5zsi50gPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWls dG86Y3RzQGV0cmkucmUua3IiIHRhcmdldD0iX2JsYW5rIj5jdHNAZXRyaS5yZS5rcjwvYT4mZ3Q7 PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBzdHlsZT0iQk9SREVSLUxFRlQ6ICNjY2Mg MXB4IHNvbGlkOyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBQQURESU5HLUxFRlQ6IDFleCIg Y2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgbGFuZz0iS08iIHZsaW5rPSJwdXJwbGUiIGxpbms9 ImJsdWUiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZB TUlMWTogJ+unkeydgOqzoOuUlSc7IENPTE9SOiByZ2IoMzEsNzMsMTI1KTsgRk9OVC1TSVpFOiAx MHB0IiBsYW5nPSJFTi1VUyI+SGkgWWFhY292LDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ+unkeydgOqzoOuU lSc7IENPTE9SOiByZ2IoMzEsNzMsMTI1KTsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJFTi1VUyI+ PHU+PC91Pjx1PjwvdT48L3NwYW4+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAn66eR7J2A6rOg65SVJzsgQ09MT1I6IHJnYigzMSw3Mywx MjUpOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9IkVOLVVTIj5Zb3VyIHF1ZXN0aW9uIGlzIG5vdCBj bGVhciB0byBtZS4NCjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ+unkeydgOqzoOuUlSc7IENPTE9SOiByZ2Io MzEsNzMsMTI1KTsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJFTi1VUyI+QmVmb3JlIGFuc3dlcmlu ZyB5b3VyIHF1ZXN0aW9uLCBjb3VsZCB5b3UgcGxlYXNlIGNsYXJpZnkgZm9sbG93aW5nIHR3byBz ZW50ZW5jZXMsIGVzcGVjaWFsbHkgZm9yIHRob3NlIG1hcmtlZCB3aXRoICZsdDsmbHQ7ICZndDsm Z3Q7Pzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxkaXYgY2xhc3M9ImltIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ+unkeydgOqzoOuUlSc7IENP TE9SOiByZ2IoMzEsNzMsMTI1KTsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJFTi1VUyI+LSB3aHkg ZG8gd2UgbmVlZCB0aGUgJmx0O2ludGVybWVkaWFyeSZndDsgc3RhdGU/PHU+PC91Pjx1PjwvdT48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9O VC1GQU1JTFk6ICfrp5HsnYDqs6DrlJUnOyBDT0xPUjogcmdiKDMxLDczLDEyNSk7IEZPTlQtU0la RTogMTBwdCIgbGFuZz0iRU4tVVMiPi0gaXQgYmV0dGVyIHRvICZsdDtub3QgYmUgYWRtaW5pc3Ry YXRpdmVseSBjb250cm9sbGVkJmd0OyBhbmQgJmx0O3JldmVydCB0byBOb3JtYWwgU3RhdGUmZ3Q7 ITx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJGT05ULUZBTUlMWTogJ+unkeydgOqzoOuUlSc7IENPTE9SOiByZ2IoMzEsNzMsMTI1KTsg Rk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJFTi1VUyI+PHU+PC91Pjx1PjwvdT48L3NwYW4+Jm5ic3A7 PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAn66eR 7J2A6rOg65SVJzsgQ09MT1I6IHJnYigzMSw3MywxMjUpOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9 IkVOLVVTIj5CZXN0IHJlZ2FyZHMsPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAn66eR7J2A6rOg65SVJzsgQ09M T1I6IHJnYigzMSw3MywxMjUpOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9IkVOLVVTIj5UYWVzaWs8 dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iRk9OVC1GQU1JTFk6ICfrp5HsnYDqs6DrlJUnOyBDT0xPUjogcmdiKDMxLDczLDEyNSk7IEZP TlQtU0laRTogMTBwdCIgbGFuZz0iRU4tVVMiPjx1PjwvdT48dT48L3U+PC9zcGFuPiZuYnNwOzwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1Rh aG9tYScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9IkVOLVVTIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7 IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iRU4tVVMiPiBZYWFjb3YgV2VpbmdhcnRlbiBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzp3eWFhY292QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnd5YWFj b3ZAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEF1Z3VzdCAy OCwgMjAxMyA5OjE4IFBNPGJyPg0KPGI+VG86PC9iPiA8L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQt U0laRTogMTBwdCI+7KCV7YOc7IudPC9zcGFuPiA8L3A+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iaDUi PjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJ WkU6IDEwcHQiIGxhbmc9IkVOLVVTIj48YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpt cGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9 Im1haWx0bzpkcmFmdC1jZGgtbXBscy10cC1wc2Mtbm9uLXJldmVydGl2ZUB0b29scy5pZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQtY2RoLW1wbHMtdHAtcHNjLW5vbi1yZXZlcnRpdmVA dG9vbHMuaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21wbHNdIE1QTFMtUlQgcmV2aWV3IG9uIGRyYWZ0LWNk aC1tcGxzLXRwLXBzYy1ub24tcmV2ZXJ0aXZlLTAwLy9SRTogTVBMUy1SVCByZXZpZXcgb2YgbXBs cyBwc2MgZG9jdW1lbnRzPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxwPjwv cD4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJoNSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PHU+PC91Pjx1PjwvdT48L3NwYW4+Jm5ic3A7PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGksPHU+PC91Pjx1Pjwv dT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjx1PjwvdT48dT48L3U+PC9zcGFuPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Tb3JyeSBmb3IgYmVp bmcgaW5zaXN0ZW50IC0geW91IGFuc3dlcmVkIHRoZSBzZWNvbmRhcnkgcXVlc3Rpb24gYnV0IG5v dCB0aGUgcHJpbWFyeSBxdWVzdGlvbiAtIGlmIHRoaXMgaXMgc3VwcG9zZWQgdG8gYmUgZm9yIHB1 cnBvc2VzIG9mIHJldmVyc2lvbiBmcm9tIGEgRE5SIHN0YXRlLCB3aHkgZG8gd2UgbmVlZCB0aGUg aW50ZXJtZWRpYXJ5IHN0YXRlPyBJIHdvdWxkIHRoaW5rDQogaXQgYmV0dGVyIHRvIG5vdCBiZSBh ZG1pbmlzdHJhdGl2ZWx5IGNvbnRyb2xsZWQgYW5kIHJldmVydCB0byBOb3JtYWwgU3RhdGUhPHU+ PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjx1PjwvdT48dT48L3U+PC9zcGFuPiZuYnNwOzwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5CUiw8 dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+eWFhY292PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMTJwdCIgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjx1PjwvdT48dT48L3U+PC9zcGFuPiZu YnNwOzwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ T24gV2VkLCBBdWcgMjgsIDIwMTMgYXQgMjozNyBQTSwgPC9zcGFuPuygle2DnOyLnTxzcGFuIGxh bmc9IkVOLVVTIj4gJmx0OzxhIGhyZWY9Im1haWx0bzpjdHNAZXRyaS5yZS5rciIgdGFyZ2V0PSJf YmxhbmsiPmN0c0BldHJpLnJlLmtyPC9hPiZndDsgd3JvdGU6PHU+PC91Pjx1PjwvdT48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9O VC1GQU1JTFk6ICfCuWQxw4c0MMKsZTDCtTE1Jywnc2VyaWYnOyBDT0xPUjogcmdiKDMxLDczLDEy NSk7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iRU4tVVMiPkhpIFlhYWNvdiw8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJDT0xPUjogcmdiKDMxLDczLDEyNSk7IEZPTlQtU0laRTogMTBwdCIg bGFuZz0iRU4tVVMiPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PHU+PC91Pjx1PjwvdT48L3Nw YW4+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFN SUxZOiAnwrlkMcOHNDDCrGUwwrUxNScsJ3NlcmlmJzsgQ09MT1I6IHJnYigzMSw3MywxMjUpOyBG T05ULVNJWkU6IDEwcHQiIGxhbmc9IkVOLVVTIj5JIGFuc3dlcmVkIHRvIHlvdXIgcXVlc3Rpb24u IFBsZWFzZSBzZWUgW1RhZXNpazJdIGlubGluZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjx1 PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJDT0xPUjogcmdiKDMxLDczLDEyNSk7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iRU4tVVMiPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PHU+PC91Pjx1PjwvdT48L3NwYW4+Jm5ic3A7PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnwrlkMcOHNDDC rGUwwrUxNScsJ3NlcmlmJzsgQ09MT1I6IHJnYigzMSw3MywxMjUpOyBGT05ULVNJWkU6IDEwcHQi IGxhbmc9IkVOLVVTIj5CZXN0IHJlZ2FyZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48dT48 L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Rk9OVC1GQU1JTFk6ICfCuWQxw4c0MMKsZTDCtTE1Jywnc2VyaWYnOyBDT0xPUjogcmdiKDMxLDcz LDEyNSk7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iRU4tVVMiPlRhZXNpazwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9IkNPTE9SOiByZ2IoMzEsNzMsMTI1KTsgRk9OVC1TSVpFOiAxMHB0IiBs YW5nPSJFTi1VUyI+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48dT48L3U+PHU+PC91Pjwvc3Bh bj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iRk9OVC1G QU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJFTi1V UyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3Nh bnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9IkVOLVVTIj4gWWFhY292IFdlaW5nYXJ0 ZW4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86d3lhYWNvdkBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj53eWFhY292QGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5 LCBBdWd1c3QgMjgsIDIwMTMgNzowMyBQTTxicj4NCjxiPlRvOjwvYj4gPC9zcGFuPjxzcGFuIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQiPuygle2DnOyLnTwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1G QU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJFTi1V UyI+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtY2RoLW1w bHMtdHAtcHNjLW5vbi1yZXZlcnRpdmVAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4N CmRyYWZ0LWNkaC1tcGxzLXRwLXBzYy1ub24tcmV2ZXJ0aXZlQHRvb2xzLmlldGYub3JnPC9hPjsg PGEgaHJlZj0ibWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+DQptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbXBsc10gTVBM Uy1SVCByZXZpZXcgb24gZHJhZnQtY2RoLW1wbHMtdHAtcHNjLW5vbi1yZXZlcnRpdmUtMDAvL1JF OiBNUExTLVJUIHJldmlldyBvZiBtcGxzIHBzYyBkb2N1bWVudHM8dT48L3U+PHU+PC91Pjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 dT48L3U+PHU+PC91Pjwvc3Bhbj4mbmJzcDs8L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UYWVzaWssIGhpPHU+PC91Pjx1PjwvdT48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PHU+PC91Pjx1PjwvdT48L3NwYW4+Jm5ic3A7PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5r IHlvdSBmb3IgeW91ciByZXBseSB0byBteSBjb21tZW50cy4mbmJzcDtXaGlsZSBJIGFwcHJlY2lh dGUgdGhlIHBoaWxvc29waHkgdGhhdCBpcyBiZWhpbmQgdGhlIHByb3Bvc2VkIGZvcm1hdCBmb3Ig dGhpcyBkcmFmdCAtIGFuZCB0aGF0IHNvbWUgb2YgeW91ciBjb25zaWRlcmF0aW9ucyAoZm9yIGV4 YW1wbGUsIHlvdXIgbmVlZCB0byBjaGFuZ2UgdGhlIG5hbWUgb2YgTWFudWFsDQogU3dpdGNoIC0g c29tZXRoaW5nIHRoYXQgd291bGQgbm90IGJlIG5lZWRlZCBpZiB5b3UganVzdCB3cm90ZSBhbiB1 cGRhdGUgdGhhdCBpbnRyb2R1Y2VkIHRoZSBuZXcgb3BlcmF0b3IgY29tbWFuZCkgYXJlIGEgZGly ZWN0IHJlc3VsdCBvZiB0aGlzIHBoaWxvc29waHkuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjx1 PjwvdT48dT48L3U+PC9zcGFuPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Ib3dldmVyLCBJIGZvdW5kIG9uZSBvZiB5b3Vy IHJlcGxpZXMgdG8gYmUgb2Ygc3BlY2lhbCBpbnRlcmVzdC4NCjx1PjwvdT48dT48L3U+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gV2VkLCBBdWcgMjgs IDIwMTMgYXQgMzoxMCBBTSwgPC9zcGFuPuygle2DnOyLnTxzcGFuIGxhbmc9IkVOLVVTIj4gJmx0 OzxhIGhyZWY9Im1haWx0bzpjdHNAZXRyaS5yZS5rciIgdGFyZ2V0PSJfYmxhbmsiPmN0c0BldHJp LnJlLmtyPC9hPiZndDsgd3JvdGU6PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1l cyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiByZ2IoMzEsNzMsMTI1KTsgRk9OVC1TSVpFOiAx MHB0IiBsYW5nPSJFTi1VUyI+SGkgWWFhY292LDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PHU+ PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 IkNPTE9SOiByZ2IoMzEsNzMsMTI1KTsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJFTi1VUyI+PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48dT48L3U+PHU+PC91Pjwvc3Bhbj4mbmJzcDs8L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3Nh bnMtc2VyaWYnOyBDT0xPUjogcmdiKDMxLDczLDEyNSk7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0i RU4tVVMiPiZsdDt0cmltbWVkIGNvbnRlbnQmZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJDT0xPUjogcmdiKDMxLDczLDEyNSk7IEZPTlQtU0laRTogMTBwdCIg bGFuZz0iRU4tVVMiPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PHU+PC91Pjx1PjwvdT48L3Nw YW4+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZiciIGxhbmc9IkVO LVVTIj4zLiBJIHNlZSBwcm9ibGVtcyB3aXRoIHRoZSBzdWdnZXN0aW9uIHRvIGNoYW5nZSB0aGUg JnF1b3Q7UHJvdGVjdGluZyZuYnNwO0FkbWluaXN0cmF0aXZlJm5ic3A7U3RhdGUmcXVvdDsgdG8g JnF1b3Q7U3dpdGNoaW5nJm5ic3A7QWRtaW5pc3RyYXRpdmUmbmJzcDtTdGF0ZSZxdW90OyBzaW5j ZSB0aGlzIHJlcXVpcmVzIHRoZSBjb25mdXNpbmcgc3RhdGVtZW50IChpbiBTZWN0aW9uDQogNC45 KSAmcXVvdDt0aGUgdXNlciB0cmFmZmljIFNIQUxMIGJlIHRyYW5zcG9ydGVkIG9uIGVpdGhlciB0 aGUgcHJvdGVjdGlvbiBwYXRoIG9yIHRoZSB3b3JraW5nIHBhdGgmcXVvdDsgd2hpY2ggaXMgY2Vy dGFpbmx5IGFsd2F5cyB0cnVlIGZvciB0cmFmZmljIHRoYXQgaXMgYmVpbmcgdHJhbnNwb3J0ZWQu IFdoeSBub3QgY3JlYXRlIGEgbmV3IFN0YXRlPyBPciBldmVuIGJldHRlciwgc2luY2UgdGhlIE1T LVcgaXMgbWVhbnQgdG8gcmV0dXJuIHRoZSBzdGF0ZSB0bw0KIE5vcm1hbCB3aHkgbm90IGp1c3Qg dXNlIE5vcm1hbCBzdGF0ZT88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjx1PjwvdT48dT48L3U+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9IkNPTE9SOiByZ2IoMzEsNzMsMTI1KSIgbGFuZz0iRU4tVVMiPltUYWVzaWtd IFllcywgdHJhZmZpYyBhbHdheXMgZmxvdyBvbiBlaXRoZXIgdGhlIHdvcmtpbmcgb3IgcHJvdGVj dGlvbiBwYXRoLiBCdXQsIGl0IHNob3VsZCBiZSBub3RlZCB0aGF0IGl0IGlzDQo8L3NwYW4+PHNw YW4gc3R5bGU9IkNPTE9SOiByZ2IoMzEsNzMsMTI1KSI+4oCcPHNwYW4gbGFuZz0iRU4tVVMiPmFk bWluaXN0cmF0aXZlbHk8L3NwYW4+4oCdPHNwYW4gbGFuZz0iRU4tVVMiPiBjb250cm9sbGVkLiBJ biB0aGF0IHNlbnNlLCB3ZSBjYW5ub3Qgc2F5IHRoYXQgYSBub2RlIGlzIGluDQo8L3NwYW4+4oCc PHNwYW4gbGFuZz0iRU4tVVMiPk5vcm1hbCBzdGF0ZTwvc3Bhbj7igJ08c3BhbiBsYW5nPSJFTi1V UyI+IHdoZW4gTVMtVyBjb21tYW5kIGlzIGlzc3VlZC4gQnkgcmVwbGFjaW5nDQo8L3NwYW4+4oCc PHNwYW4gbGFuZz0iRU4tVVMiPlByb3RlY3RpbmcgYWRtaW5pc3RyYXRpdmUgc3RhdGU8L3NwYW4+ 4oCdPHNwYW4gbGFuZz0iRU4tVVMiPiBieQ0KPC9zcGFuPuKAnDxzcGFuIGxhbmc9IkVOLVVTIj5T d2l0Y2hpbmcgYWRtaW5pc3RyYXRpdmUgc3RhdGU8L3NwYW4+4oCdPHNwYW4gbGFuZz0iRU4tVVMi PiwgaXQgY2FuIGNvdmVyIGJvdGggY2FzZXM6IGFkbWluaXN0cmF0aXZlbHkgc3dpdGNoZWQgdG8g d29ya2luZyBwYXRoIChieSBNUy1XKSBhbmQgYWRtaW5pc3RyYXRpdmVseSBzd2l0Y2hlZCB0byBw cm90ZWN0aW9uIHBhdGggKGJ5IE1TLVApLjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi Pjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48dT48L3U+ PHU+PC91Pjwvc3Bhbj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmx0OyZsdDt5dyZndDsmZ3Q7IFdoZW4gSSBmaXJzdCBy ZWFkIHRoaXMgZHJhZnQgSSB3YXMgdW5kZXIgdGhlIGltcHJlc3Npb24gdGhhdCAoYXMgaW1waWVk IGJ5IHRoZSB0aXRsZSBvZiB0aGUgZHJhZnQpJm5ic3A7dGhlIG1haW4ganVzdGlmaWNhdGlvbiBm b3IgaW50cm9kdWNpbmcgdGhlIE1TLVcgY29tbWFuZCB3YXMgdG8gc29sdmUgdGhlIHByb2JsZW0g b2YgcmV2ZXJ0aW5nIHRyYWZmaWMgZnJvbSBhIG5vbi1yZXZlcnRpdmUNCiBzdGF0ZSBhbmQgcmV0 dXJuaW5nIHRvIHRoZSBOb3JtYWwgU3RhdGUuIEhvd2V2ZXIsIGFjY29yZGluZyB0byB0aGlzIGV4 cGxhbmF0aW9uLCB1c2luZyB0aGlzIGNvbW1hbmQgZG9lcyBub3QgcmV0dXJuIHlvdSB0byB0aGUg Tm9ybWFsIFN0YXRlLCBidXQgcmF0aGVyIHRvIHNvbWUgaW50ZXJtZWRpYXRlIHN0YXRlLCBzaW5j ZSB5b3UgYXJlICZxdW90O2FkbWluaXN0YXJ0aXZlbHkgY29udHJvbGxlZCZxdW90OyEmbmJzcDsN Cjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48dT48L3U+PHU+PC91Pjwvc3Bhbj4mbmJzcDs8L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U28gY2FuIHlvdSBwbGVhc2UgZXhwbGFpbiBo b3cgZG9lcyB0aGUgb3BlcmF0b3IgcmV2ZXJ0IGZyb20gdGhlIG5vbi1yZXZlcnRpdmUgc2l0dWF0 aW9uIHRvIHRoZSBOb3JtYWwgU3RhdGU/IChJcyBpdCBhIHNlcXVlbmNlIG9mIE1TLVcgYW5kIHRo ZW4gaW1tZWRpYXRlbHkgQ2xlYXI/IElmIHNvLCB3aHkgaXMgdGhpcyBkaWZmZXJlbnQgZnJvbSBM TyBhbmQgaW1tZWRpYXRlIENsZWFyPyk8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iQ09MT1I6IHJnYigzMSw3MywxMjUpOyBGT05ULVNJ WkU6IDEwcHQiIGxhbmc9IkVOLVVTIj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjx1PjwvdT48 dT48L3U+PC9zcGFuPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICfCuWQxw4c0MMKsZTDCtTE1Jywnc2VyaWYn OyBDT0xPUjogcmdiKDMxLDczLDEyNSk7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iRU4tVVMiPltU YWVzaWsyXSBJZiB5b3UgaXNzdWUgTE8sIHlvdSBjYW5ub3QgcHJvdGVjdCB0cmFmZmljIHdoZW4g U0Ygb3IgU0QgaXMgc3Vic2VxdWVudGx5IGRldGVjdGVkIG9uIHRoZSB3b3JraW5nIHBhdGggdW50 aWwgdGhlIExPIGlzIGNsZWFyZWQuDQogT24gdGhlIG90aGVyIGhhbmQsIGlmIHlvdSB1c2UgTVMt VywgdHJhZmZpYyBjYW4gYmUgcHJvdGVjdGVkIGJlY2F1c2UgdGhlIHByaW9yaXR5IG9mIE1TLVcg aXMgbG93ZXIgdGhhbiBTRiBvciBTRC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjx1PjwvdT48 dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9IkJPUkRFUi1CT1RU T006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogMXB0IHNvbGlkOyBQQURESU5HLUJPVFRPTTog MGNtOyBNQVJHSU46IDVwdCAwY20gNXB0IDQuOHB0OyBQQURESU5HLUxFRlQ6IDZwdDsgUEFERElO Ry1SSUdIVDogMGNtOyBCT1JERVItVE9QOiBtZWRpdW0gbm9uZTsgQk9SREVSLVJJR0hUOiBtZWRp dW0gbm9uZTsgUEFERElORy1UT1A6IDBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkNPTE9SOiByZ2IoMzEsNzMsMTI1KTsg Rk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJFTi1VUyI+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 dT48L3U+PHU+PC91Pjwvc3Bhbj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5z LXNlcmlmJyIgbGFuZz0iRU4tVVMiPiZsdDt0cmltbWVkIGNvbnRlbnQmZ3Q7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxzcGFuPjxzcGFuIHN0eWxlPSJDT0xPUjogcmdiKDEz NiwxMzYsMTM2KSI+LS0gPC9zcGFuPjwvc3Bhbj48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPlRoYW54IGFuZCBCUiw8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnlhYWNvdjx1PjwvdT48dT48 L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48dT48L3U+PHU+PC91Pjwvc3Bhbj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1VUyI+U3RpbGwgbG9v a2luZyBmb3IgbmV3IG9wcG9ydHVuaXR5PC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1VUyI+PHU+ PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8YnI+DQotLSA8dT48L3U+PHU+ PC91Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPlRoYW54IGFuZCBCUiw8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnlhYWNvdjx1PjwvdT48dT48L3U+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48dT48L3U+PHU+PC91Pjwvc3Bhbj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1VUyI+U3RpbGwgbG9va2lu ZyBmb3IgbmV3IG9wcG9ydHVuaXR5PC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1VUyI+PHU+PC91 Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4N CjxiciBjbGVhcj0iYWxsIj4NCjxicj4NCi0tIDxicj4NCjxkaXYgZGlyPSJsdHIiPlRoYW54IGFu ZCBCUiwNCjxkaXY+eWFhY292PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48aT5TdGls bCBsb29raW5nIGZvciBuZXcgb3Bwb3J0dW5pdHk8L2k+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A286761C8SMTP2etriinfo_-- From internet-drafts@ietf.org Fri Aug 30 01:41:11 2013 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 E448711E80E4; Fri, 30 Aug 2013 01:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.047, 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 GGmAttyQ2i40; Fri, 30 Aug 2013 01:41:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3250311E80E0; Fri, 30 Aug 2013 01:41: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: 4.70.p1 Message-ID: <20130830084111.21876.55233.idtracker@ietfa.amsl.com> Date: Fri, 30 Aug 2013 01:41:11 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-mip-mep-map-09.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, 30 Aug 2013 08:41:12 -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 Gro= up of the IETF. Title : Per-Interface MIP Addressing Requirements and Design Con= siderations Author(s) : Adrian Farrel Hideki Endo Rolf Winter Yoshinori Koike Manuel Paul Filename : draft-ietf-mpls-tp-mip-mep-map-09.txt Pages : 12 Date : 2013-08-30 Abstract: The Framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how Maintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at the incoming and outgoing interfaces. This document elaborates on important considerations for internal MIP addressing. More precisely it describes important restrictions for any mechanism that specifies a way of forming OAM messages so that they can be targeted at MIPs on incoming or MIPs on outgoing interfaces and forwarded correctly through the forwarding engine. Furthermore, the document includes considerations for node implementations where there is no distinction between the incoming and outgoing MIP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mip-mep-map There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-mip-mep-map-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-mip-mep-map-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Rolf.Winter@neclab.eu Fri Aug 30 01:43:45 2013 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 88EF911E80E0 for ; Fri, 30 Aug 2013 01:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 Xv4hQ9YI26fg for ; Fri, 30 Aug 2013 01:43:35 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 306C511E80E4 for ; Fri, 30 Aug 2013 01:43:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 1DFDA1054A3 for ; Fri, 30 Aug 2013 10:42:32 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjQJIX3lDWOe for ; Fri, 30 Aug 2013 10:42:32 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id ED621104DAA for ; Fri, 30 Aug 2013 10:42:26 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.82]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 30 Aug 2013 10:43:29 +0200 From: Rolf Winter To: "mpls@ietf.org" Thread-Topic: I-D Action: draft-ietf-mpls-tp-mip-mep-map-09.txt Thread-Index: AQHOpVzPjr5+E3fO3kCpE+F1WbZhJ5mtbv1w Date: Fri, 30 Aug 2013 08:43:28 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D556EA2A5@DAPHNIS.office.hd> References: <20130830084111.21876.55233.idtracker@ietfa.amsl.com> In-Reply-To: <20130830084111.21876.55233.idtracker@ietfa.amsl.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.201] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-mip-mep-map-09.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, 30 Aug 2013 08:43:45 -0000 Hi, this version addresses comments received during IETF last call and the Gen = Art review. Best, Rolf NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End= Road, London, HA4 6QE, GB | Registered in England 2832014 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Freitag, 30. August 2013 10:41 > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: I-D Action: draft-ietf-mpls-tp-mip-mep-map-09.txt >=20 >=20 > 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. >=20 > Title : Per-Interface MIP Addressing Requirements and > Design Considerations > Author(s) : Adrian Farrel > Hideki Endo > Rolf Winter > Yoshinori Koike > Manuel Paul > Filename : draft-ietf-mpls-tp-mip-mep-map-09.txt > Pages : 12 > Date : 2013-08-30 >=20 > Abstract: > The Framework for Operations, Administration and Maintenance (OAM) > within the MPLS Transport Profile (MPLS-TP) describes how > Maintenance > Entity Group Intermediate Points (MIPs) may be situated within > network nodes at the incoming and outgoing interfaces. >=20 > This document elaborates on important considerations for internal > MIP > addressing. More precisely it describes important restrictions for > any mechanism that specifies a way of forming OAM messages so that > they can be targeted at MIPs on incoming or MIPs on outgoing > interfaces and forwarded correctly through the forwarding engine. > Furthermore, the document includes considerations for node > implementations where there is no distinction between the incoming > and outgoing MIP. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mip-mep-map >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mpls-tp-mip-mep-map-09 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-mip-mep-map-09 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 From loa@pi.nu Fri Aug 30 05:29:23 2013 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 7BDB521F9E70 for ; Fri, 30 Aug 2013 05:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyC7xd8PB92p for ; Fri, 30 Aug 2013 05:28:49 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCE921F9C6C for ; Fri, 30 Aug 2013 05:21:05 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id B57E01802038; Fri, 30 Aug 2013 14:21:02 +0200 (CEST) Message-ID: <52208E2E.1020007@pi.nu> Date: Fri, 30 Aug 2013 14:21:02 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "VIGOUREUX, MARTIN (MARTIN)" , Adrian Farrel , "Deborah Brungard (dbrungard@att.com)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Working Group Last Call on draft-ietf-mpls-ldp-hello-crypto-auth-02 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, 30 Aug 2013 12:29:27 -0000 Working Group, this is to start a two week working group last call on draft-ietf-mpls-ldp-hello-crypto-auth-02. Please send your comment to working group mailing lists (mpls@ietf.org). We did an IPR poll on this document prior to accepting it as a working group document. All the authors responded to the IPR poll that they are not aware of IPR's relating to this document. There are no IPRs disclosed against this document. The working group last call will end Friday September 13, 2913. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From mjork@juniper.net Fri Aug 30 14:29:19 2013 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 1396D21F9F23 for ; Fri, 30 Aug 2013 14:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 SNIIWl2jGwrE for ; Fri, 30 Aug 2013 14:29:12 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id AF88721F9E6A for ; Fri, 30 Aug 2013 14:29:12 -0700 (PDT) Received: from mail188-co1-R.bigfish.com (10.243.78.231) by CO1EHSOBE013.bigfish.com (10.243.66.76) with Microsoft SMTP Server id 14.1.225.22; Fri, 30 Aug 2013 21:29:12 +0000 Received: from mail188-co1 (localhost [127.0.0.1]) by mail188-co1-R.bigfish.com (Postfix) with ESMTP id 2811DA022B; Fri, 30 Aug 2013 21:29:12 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zz146fI1432I853kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hz8dhz1de097hz2fh2a8h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail188-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=mjork@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(51704005)(52314003)(74706001)(19580395003)(74366001)(81686001)(74316001)(46102001)(69226001)(51856001)(80976001)(80022001)(66066001)(65816001)(83322001)(47976001)(50986001)(47736001)(33646001)(74876001)(81816001)(4396001)(81542001)(49866001)(81342001)(56776001)(76482001)(53806001)(1411001)(83072001)(76796001)(77096001)(76786001)(54356001)(76576001)(59766001)(77982001)(74502001)(79102001)(47446002)(31966008)(74662001)(63696002)(56816003)(54316002)(21314002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB238; H:BY2PR05MB239.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail188-co1 (localhost.localdomain [127.0.0.1]) by mail188-co1 (MessageSwitch) id 1377898149862839_21278; Fri, 30 Aug 2013 21:29:09 +0000 (UTC) Received: from CO1EHSMHS022.bigfish.com (unknown [10.243.78.247]) by mail188-co1.bigfish.com (Postfix) with ESMTP id C54CB980040; Fri, 30 Aug 2013 21:29:09 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS022.bigfish.com (10.243.66.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 30 Aug 2013 21:29:09 +0000 Received: from BY2PR05MB238.namprd05.prod.outlook.com (10.242.41.153) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.353.4; Fri, 30 Aug 2013 21:29:08 +0000 Received: from BY2PR05MB239.namprd05.prod.outlook.com (10.242.41.143) by BY2PR05MB238.namprd05.prod.outlook.com (10.242.41.153) with Microsoft SMTP Server (TLS) id 15.0.745.25; Fri, 30 Aug 2013 21:29:06 +0000 Received: from BY2PR05MB239.namprd05.prod.outlook.com ([169.254.16.103]) by BY2PR05MB239.namprd05.prod.outlook.com ([169.254.16.24]) with mapi id 15.00.0745.000; Fri, 30 Aug 2013 21:29:06 +0000 From: Markus Jork To: "huubatwork@gmail.com" Thread-Topic: [mpls] MPLS-RT review of PSC related drafts Thread-Index: AQHOoKGpnByk+rx3CkuUmn4rOjhHlZmnkSbggABc84CABk6LIA== Date: Fri, 30 Aug 2013 21:29:05 +0000 Message-ID: References: <79E5D3D3-6AB4-4CE7-97A9-6D324C053490@gmail.com> <52186AC2.8030804@gmail.com> <8be8a162f75c4c61a48c925b2f294dde@BLUPR05MB230.namprd05.prod.outlook.com> <521BB527.6000000@gmail.com> In-Reply-To: <521BB527.6000000@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0954EE4910 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of PSC related drafts 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, 30 Aug 2013 21:29:19 -0000 SHV1YiwNCg0KPiAgPiBXYXMgaGF2aW5nIGEgc2V0IG9mIHVwZGF0ZSBkcmFmdHMgc29tZWhvdyBt ZWFudCB0byBlYXNlICA+IGNvb3JkaW5hdGlvbg0KPiB3aXRoIHRoZSBJVFU/DQo+IA0KPiBZZXMu IFRoaXMgd2FzIHJlcXVlc3RlZCBpbiB0aGUgbGlhaXNvbiBmcm9tIElFVEYgdG8gSVRVIGFuZCB0 aGUgY29uY2F0ZW5hdGlvbg0KPiBvZiB0aGUgb3B0aW9ucyBpcyBpbiBkcmFmdCBJVFUgbW9kZS4N Cg0KT2ssIHNvIGFzIEkgc3VzcGVjdGVkIHRoZSBjdXJyZW50IGZvcm1hdCBvZiB0aGUgSS1EcyB3 YXMgY2hvc2VuIGZvciBwcm9jZWR1cmFsIHJlYXNvbnMuDQpXaGlsZSB0aGF0IGlzIHVuZGVyc3Rh bmRhYmxlLCB0aGUgcmVzdWx0aW5nIEktRHMgYXJlIHByZXR0eSBoYXJkIHRvIGRpZ2VzdC4NCkkg dGhpbmsgcHJvZHVjaW5nIGdvb2QgYW5kIHJlYWRhYmxlIFJGQ3Mgc2hvdWxkIGJlIG1vcmUgaW1w b3J0YW50IHRoYW4gbWFraW5nIGl0IGVhc3kgdG8gZ2V0IHRoZW0gdGhyb3VnaCB0aGUgc3RhbmRh cmRpemF0aW9uIHByb2Nlc3MuIA0KDQo+ID4gQW55d2F5LCB0aGUgbWFpbiBhdWRpZW5jZSBmb3Ig YSBzdGFuZGFyZHMgdHJhY2sgUkZDIGFyZQ0KPiAgPiB0aGUgaW1wbGVtZW50ZXJzIGFuZCB1c2Vy cyBvZiB0aGUgdGVjaG5vbG9neS4gU28gYW4gUkZDICA+IHNob3VsZCBiZQ0KPiB3cml0dGVuIHRv IGJlIGVhc2lseSB1bmRlcnN0b29kIGFuZCBkaWdlc3RlZCAgPiBieSBpdHMgYXVkaWVuY2UuIEFu ZCBpbiBteQ0KPiBvcGluaW9uIHRoZSBmb3JtYXQgY2hvc2VuIGZvciAgPiB0aGlzIHNldCBvZiBQ U0MgZHJhZnRzIGlzIG5vdCBpZGVhbCBpbiB0aGF0DQo+IHJlZ2FyZC4NCj4gDQo+IFdoYXQgaXMg dGhlIGZvcm1hdCB5b3Ugd291bGQgbGlrZSB0byBzZWU/DQoNCkkgdGhpbmsgd2UgbmVlZCBvbmUg ZHJhZnQgdGhhdCBpcyBhIG5ldyByZXZpc2lvbiBvZiBSRkMgNjM3OC4gSXQgd291bGQgaW5jb3Jw b3JhdGUgYWxsIHRoZSBjb3JyZWN0aW9ucyBhbmQgbmV3IGZlYXR1cmVzLg0KVGhhdCdzIHdoYXQg eW91IHdhbnQgdG8gZG8gd2l0aCAiZHJhZnQteHh4LW1wbHMtdHAtSVRVLW1vZGUiIGFueXdheToN Cg0KPiBDdXJyZW50bHkgdGhlcmUgd2lsbCBiZSB0d28gbW9kZXM6DQo+ID0gbm9uZSBvcHRpb24g c3VwcG9ydGVkOiBleGlzdGluZyBSRkM2Mzc4ID0gYWxsIG9wdGlvbnMgc3VwcG9ydGVkOiBkcmFm dCBJVFUgbW9kZQ0KPiANCj4gSW4gdGhpcyB3YXkgaW1wbGVtZW50YXRpb25zIChjdXJyZW50bHkp IGhhdmUgdG8gc3VwcG9ydCB0d28gbW9kZXMuDQoNClNvIGlmIHRoZSBjdXJyZW50IHNldCBvZiBk cmFmdHMgZGVzY3JpYmluZyBvcHRpb25hbCBmZWF0dXJlcyBjYW4ndCBiZSBhcmJpdHJhcmlseSBj b21iaW5lZCBhbnl3YXksIHdoeSBub3QgcHJvZHVjZSBvbmUgbmV3IElUVS1tb2RlIGRyYWZ0IHRo YXQgZGVzY3JpYmVzIGFsbCBvZiB0aGlzIHRvZ2V0aGVyPw0KDQpKdXN0IHRvIGlsbHVzdHJhdGUg dGhlIHByb2JsZW0gd2l0aCB0aGUgY3VycmVudCBzZXQgb2YgZHJhZnRzLCBoZXJlIGlzIG9uZSBl eGFtcGxlOiAzIG9mIHRoZSBkcmFmdHMgbW9kaWZ5IHRoZSBzYW1lIHNlY3Rpb24gb2YgUkZDIDYz Nzg6DQoNCiogZHJhZnQtcmhkLW1wbHMtdHAtcHNjLXByaW9yaXR5LTAxLnR4dDoNCg0KICA0LjIu ICBVcGRhdGVzIHRvIFNlY3Rpb24gNC4zLjMuMi4gIFVuYXZhaWxhYmxlIFN0YXRlDQogICAgIFJl bW92ZSB0aGUgZm9sbG93aW5nIGJ1bGxldCBpdGVtcyBhbmQgdGhlaXIgdGV4dDoNCiAgICAgWy4u Ll0NCg0KDQoqIGRyYWZ0LWNkaC1tcGxzLXRwLXBzYy1ub24tcmV2ZXJ0aXZlLTAwLnR4dDoNCg0K ICA0LjguICBVcGRhdGVzIHRvIFNlY3Rpb24gNC4zLjMuMi4gVW5hdmFpbGFibGUgU3RhdGUNCiAg ICAgUmVwbGFjZSB0aGUgZm9sbG93aW5nIGJ1bGxldCBpdGVtIGluIHRoZSByZWFjdGlvbiB0byBs b2NhbCBpbnB1dA0KICAgICBsaXN0Og0KICAgICBbLi4uXQ0KICAgICBXaXRoOg0KICAgICBbLi4u XQ0KDQogICAgIFJlcGxhY2UgdGhlIGZvbGxvd2luZyBidWxsZXQgaXRlbSBpbiB0aGUgcmVhY3Rp b24gdG8gcmVtb3RlIG1lc3NhZ2UNCiAgICAgbGlzdDoNCiAgICAgWy4uLl0NCiAgICAgV2l0aDoN CiAgICAgWy4uLl0NCg0KDQoqIGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1zZC0wMC50eHQ6DQoNCiAg NS45LiAgVXBkYXRlcyB0byBTZWN0aW9uIDQuMy4zLjIgVW5hdmFpbGFibGUgU3RhdGUNCg0KICAg ICBUaGUgc2Vjb25kIHBhcmFncmFwaCBvZiBTZWN0aW9uIDQuMy4zLjIgVW5hdmFpbGFibGUgU3Rh dGUgaW4NCiAgICAgW1JGQzYzNzhdIHNob3dzIHRoZSBpbnRlbnRpb24gb2YgaW5jbHVkaW5nIHRo ZSBzaWduYWwgZGVncmFkZSBvbiB0aGUNCiAgICAgcHJvdGVjdGlvbiBpbiB0aGUgVW5hdmFpbGFi bGUgc3RhdGUuICBUaGlzIGRvY3VtZW50IGZvbGxvd3MgdGhlIHNhbWUNCiAgICAgc3RhdGUgZ3Jv dXBpbmcgYXMgW1JGQzYzNzhdIGZvciBTRC1QLCBldmVuIHRob3VnaCB0aGUgcHJvdGVjdGlvbiBw YXRoDQogICAgIGNhbiBiZSBwYXJ0aWFsbHkgYXZhaWxhYmxlIHVuZGVyIHRoZSBjb25kaXRpb24g b2YgdGhlIHNpZ25hbCBkZWdyYWRlDQogICAgIG9uIHRoZSBwcm90ZWN0aW9uIHBhdGguDQoNCiAg ICAgUmVwbGFjZSB0aGUgZm9sbG93aW5nIHRleHQgaW4gdGhlIGZpcnN0IHBhcmFncmFwaCBvZiBT ZWN0aW9uIDQuMy4zLjINCiAgICAgVW5hdmFpbGFibGUgU3RhdGUgZm9yIGZ1cnRoZXIgY2xhcmlm aWNhdGlvbiBvbiBTRCBvbiB0aGUgcHJvdGVjdGlvbg0KICAgICBwYXRoOg0KICAgICBbLi4uXQ0K ICAgICBXaXRoOg0KICAgICBbLi4uXQ0KDQogICAgIFJlcGxhY2UgdGhlIGZvbGxvd2luZyBidWxs ZXQgaXRlbSB0ZXh0IGluIHRoZSB0cmFuc2l0aW9ucyBpbiByZWFjdGlvbg0KICAgICB0byBhIGxv Y2FsIGlucHV0Og0KICAgICBbLi4uXQ0KICAgICBXaXRoOg0KICAgICBbLi4uXQ0KDQogICAgIFJl cGxhY2UgdGhlIGZvbGxvd2luZyBidWxsZXQgaXRlbSB0ZXh0IGluIHRoZSB0cmFuc2l0aW9ucyBp biByZWFjdGlvbg0KICAgICB0byBhIGxvY2FsIGlucHV0Og0KICAgICBbLi4uXQ0KICAgICBXaXRo Og0KICAgICBbLi4uXQ0KDQoNCkVhY2ggZHJhZnQgd2l0aCBpdHMgImRpZmYiIGZvcm1hdCBpcyBi YWQgZW5vdWdoIG9uIGl0cyBvd24uIEJ1dCBhbnkgY29tYmluYXRpb24gb2YgdGhlc2UgZHJhZnRz IHdvdWxkIGJlIGluY29tcHJlaGVuc2libGUuIFNvIHdoeSBoYXZlIHRoZXNlIHNlcGFyYXRlIFJG Q3M/DQoNCi1NYXJrdXMgDQo=