From nobody Sat Jan 4 14:30:43 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8B91200B7; Sat, 4 Jan 2020 14:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8Utws6EnQ7c; Sat, 4 Jan 2020 14:30:37 -0800 (PST) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31169120099; Sat, 4 Jan 2020 14:30:34 -0800 (PST) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 004MUWsu008875; Sat, 4 Jan 2020 22:30:32 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B51372203A; Sat, 4 Jan 2020 22:30:31 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS id 9FFF422032; Sat, 4 Jan 2020 22:30:31 +0000 (GMT) Received: from LAPTOPK7AS653V (83-215-194-123.stjo.dyn.salzburg-online.at [83.215.194.123]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 004MUUfM030034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 4 Jan 2020 22:30:31 GMT Reply-To: From: "Adrian Farrel" To: Cc: Date: Sat, 4 Jan 2020 22:30:30 -0000 Organization: Old Dog Consulting Message-ID: <02e401d5c34e$92b6da20$b8248e60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdXDTJ6UVH4sFIesQzmG4RqAc3dffg== Content-Language: en-gb X-Originating-IP: 83.215.194.123 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25148.002 X-TM-AS-Result: No--9.841-10.0-31-10 X-imss-scan-details: No--9.841-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25148.002 X-TMASE-Result: 10--9.841400-10.000000 X-TMASE-MatchedRID: 17S8mJdSkmI/9d9Rtcc0Q07yqWc5cVLPp2Uv2mII685a1yhTwm1zucqa e4dFK5zKK5L1vqGrPJSoAhsqyb25GEsKIxV/FggwGUlF/M3Dxp+4e+jtsKnyKg5sitnRwXws2Ag TgKeFuSrFYIRbVnnwVdbpOEegUvH99ypsAEjQDduL6q5RsNhv5FjWwaUPviNZHKx4E/jOf+qU62 zvc1DlozUM1eqf2vRVSWkGbEhSIqQlU7NaBXoJVSfphWrcxCwjV447DNvw38ZilpHN7xKf9YS2o c9zOIJx4vM1YF6AJbZcLc3sLtjOt9CpCFLDTHZU3QfwsVk0UbuGrPnef/I+ekEfGJeCfikh+jcr EOjUjHE0IrO2RfCJ2uoPrQ/hAV+M39Pj2R0rKz4= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [Pce] Shepherd review of draft-ietf-pce-stateful-pce-lsp-scheduling X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2020 22:30:40 -0000 Hi authors, Just doing the shepherd write-up after working group last call and I have a nit in section 10.3 You ask for a new registry of bits, but you don't tell IANA the size of the registry. I think, to be consistent with (e.g.) https://www.iana.org/assignments/pcep/pcep.xhtml#stateful-pce-capability-tlv -flag-field you should have: OLD The following values are defined in this document: Bit Description Reference 0 R-bit This document 1 C-bit This document 2 A-bit This document NEW IANA is requested to populate this registry as follows: Bit Description Reference 0 R-bit This document 1 C-bit This document 2 A-bit This document 3-7 Unassigned END However, please also consider that other TLV bit registries have started assigning bits from the largest number (sometimes 31, sometimes 15) counting downwards. This is not important, just "interesting". Afraid we need a new revision before we can advance the document. While you're at it, can you fix the references noted by idnits. Thanks, Adrian From nobody Sun Jan 5 10:51:48 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEFD1200F4; Sun, 5 Jan 2020 10:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExgFjPBS_EEz; Sun, 5 Jan 2020 10:51:41 -0800 (PST) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027B612007A; Sun, 5 Jan 2020 10:51:37 -0800 (PST) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 005IpZKv029374; Sun, 5 Jan 2020 18:51:35 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 773EE22044; Sun, 5 Jan 2020 18:51:35 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id 6224222042; Sun, 5 Jan 2020 18:51:35 +0000 (GMT) Received: from LAPTOPK7AS653V (83-215-194-123.stjo.dyn.salzburg-online.at [83.215.194.123]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 005IpYGY030136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 5 Jan 2020 18:51:35 GMT Reply-To: From: "Adrian Farrel" To: , Cc: References: <22192_1573830096_5DCEBDD0_22192_23_1_050def8f-dc47-4d5b-1303-2928ef08a041@orange.com> In-Reply-To: <22192_1573830096_5DCEBDD0_22192_23_1_050def8f-dc47-4d5b-1303-2928ef08a041@orange.com> Date: Sun, 5 Jan 2020 18:51:34 -0000 Organization: Old Dog Consulting Message-ID: <001601d5c3f9$277b1b30$76715190$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIVwtKLKN9myvWGQraM0WDlr6TLxKdcPUew Content-Language: en-gb X-Originating-IP: 83.215.194.123 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25150.002 X-TM-AS-Result: No--20.540-10.0-31-10 X-imss-scan-details: No--20.540-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25150.002 X-TMASE-Result: 10--20.540100-10.000000 X-TMASE-MatchedRID: 8HTFlOrbAtGWfDtBOz4q23FPUrVDm6jtUb4EdIZGxuCnRvssirgAK4O3 X3IJL/YZ/NIOugvPDyxgBKW7UCfQnnChPHB61wQjcI7vRACwF0Lg02I3oyGU8GmJ+7V5rRczrr5 TE4GLzk2Q63ZCKLk6vXxHUwRvOwGVcrsHGroIav0dDctFr7spHFB1e7/F/vq58jflxBKMkr5qQK teErN22XQ7ZT3z26Zt+6EpEaCf59Dpw2ocrkGyOKmukiZOfPi2dNmQukSciLi5RTcaZKGriQr0S egbwNvkKgu3wA/rn07zH360QvdSLTGzHcks325JvOAv94sAIMTM8zLNncnslQ3Ls6fBybZtBUz2 Q+xpjHj2YFicxslkX4tELTaaa8xj09VVSm4W+C+KYdYQLbymTQXj39T+BEfAI0YrtQLsSUxUCbx ry6s+wAgME5iwys6jTWMd3IobVTmbp59WF6ZpCmgws6g0ewz2SuH+GfgmQGfNWDA/tkxh/wnzjb MpF4NieV1sjgdoraRcYOwV88XbAve68P7UGSXtN19PjPJahlLOFaObL3St2wlAOTb7jjzgTzVBr RvUvYWJzXzyp3mrjiRyWxTA+zKnqUa/04UfX56Ev01fZOqaQH5NUJRWuWaGR/IzlV+CMbZgUob/ Kbg6S1OXFRSgmYIH8/EriPF7LJ2xvbBx4KUBKFkxnoxnQfVSzlT5a6V0OSPcUlQs8YFKzkD4f8Q tBCGZCzAsZLk6v2TkMPza5anWT2o7kOpAebY/RwGuU/RcW5byR9+fVCb6GGmycYYiBYyZmx64yh YBxcfplb8m3Sz+5gL9tGteQH9JeU+pIViiAQeeAiCmPx4NwFkMvWAuahr8m5N2YHMD0b8MyrfP9 j+C1bxAi7jPoeEQftwZ3X11IV0= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Pce] Shepherd Review of draft-ietf-pce-pcep-flowspec X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2020 18:51:46 -0000 Hi Julien, Long ago you sent your review. Comments in line. At the same time, we see that IDR has basically completed work on = draft-ietf-idr-rfc5575bis and we think we should update this document to = use that as a reference instead of RFC 5575 and RFC 7674. Finally, someone contacted us privately to ask that we add a flag to a = PCEP flowspec to indicate that it should not be installed as a data = plane filter, but should be installed as a 'normal route' with longest = prefix matching. That is a simple change, but nevertheless a change of = technical substance. I'll send a separate email to the list to see = whether anyone else is interested and determine whether we can craft = some text. I'll do a new revision and then start the thread for the additional = point noted above. Best wishes for the New Year, Adrian =3D=3D=3D > I still have one pending question, related to section 8.7. (Priorities > and Overlapping Flow Specifications). I understand this section as > "priorities within PCEP-installed flow specs follow the same ordering > rules as BGP-installed flow specs, i.e. [RFC5575]". Let us now look at = a > device supporting both protocols to install flow specs: > - Is there an implicit scope associated to each set of flow specs = making > them mutually exclusive? > - If both sets can overlap, can we assume that priority rules do not > care about the protocol used to install the flow specs? > Adding a couple of sentences may be enough to clarify that. You raise a very good point. I am not certain how often this is going to = arise, but it seems almost certain that were we to decide it could never = arise, it would immediately become a requirement from the field. So we = should address it. Now, draft-ietf-idr-rfc5575bis-18.txt talks only about BGP, but section = 5.1 gives a description of how flow specifications are ordered for = traffic matching regardless of what order they arrive in BGP. I think we = should assume that all traffic is open to all flowspecs whether = installed by BGP for firewalls or routing, or installed by PCEP for = classification onto traffic paths (LSPs or SR paths). I believe that = similar work is being looked at for classification of traffic onto = service function chains, and I imagine that those flowspecs might also = coincide with BGP and PCEP flowspecs. I think that all we need do is: - call out that both protocols might be simultaneously present and = distributing flowspecs for installation - make the observation that the rules defined in section 5.1 of = draft-ietf-idr-rfc5575bis apply regardless of which protocol distributed = the flowspec. That brings me to the text in 8.7: OLD Flow specifications can overlap. For example, two different flow specifications may be identical except for the length of the prefix in the destination address. In these cases the PCC must determine how to prioritize the flow specifications so as to know to which path to assign packets that match both flow specifications. That is, the PCC must assign a precedence to the flow specifications so that it checks each incoming packet for a match in a predictable order. The processing of BGP Flow Specifications is described in [RFC5575]. Section 5.1 of that document explains the order of traffic filtering rules to be executed by an implementation of that specification. PCCs MUST apply the same ordering rules as defined in [RFC5575]. NEW Flow specifications can overlap. For example, two different flow specifications may be identical except for the length of the prefix in the destination address. In these cases the PCC must determine how to prioritize the flow specifications so as to know to which path to assign packets that match both flow specifications. That is, the PCC must assign a precedence to the flow specifications so that it checks each incoming packet for a match in a predictable order. The processing of BGP Flow Specifications is described in=20 [I-D.ietf-idr-rfc5575bis]. Section 5.1 of that document explains the order of traffic filtering rules to be executed by an implementation of that specification. PCCs MUST apply the same ordering rules as defined in=20 [I-D.ietf-idr-rfc5575bis]. Furthermore, it is possible that Flow Specifications will be = distributed by BGP as well as by PCEP as described in this document. In such=20 cases implementations supporting both approaches MUST apply the prioritization and ordering rules as set out in = [I-D.ietf-idr-rfc5575bis] regardless of which protocol distributed the Flow Specifications, however implementations MAY provide a configuration control to=20 allow one protocol to take precedence over the other as this may be particularly useful if the Flow Specification make identical matches on traffic but have different actions. It is RECOMMENDED that when two Flow Specifications distributed by different protocols overlap, and especially when one acts to replace another, that a message be=20 logged for the operator to understand the behaviour. END > Please find below a few additional nits. > ------ > 1. Introduction > > - The abstract uses "traffic engineered networks", the intro "traffic > engineering networks". I do not have any strong preference, but > consistency would be welcome. (By the way, no hyphen in > "traffic-engineered"?) Yes. "traffic engineering" > - s/to Generalized MPLS (GMPLS) networks/to Generalized MPLS > (GMPLS)-controlled networks/ OK > - s/about the the LSPs/about the LSPs/ oops > - OLD: > The data flows > intended for a tunnel can be described using Flow Specification > Components, and when PCEP is in use for tunnel initiation it makes > sense for that same protocol to be used to distribute the Flow > Specification Components that describe what data is to flow on those > tunnels. > NEW: > The data flows > intended for a tunnel can be described using Flow Specification > Components; when PCEP is in use for tunnel initiation, it makes > sense for that same protocol to be used to distribute the Flow > Specification Components that describe what data is to flow on those > tunnels. Going even further and using a period. > 3.2. Elements of Procedure >=20 > - s/in each case including whether/in each case. This includes = whether/ OK > 6. Flow Filter TLV >=20 > OLD: > Only one Flow Filter TLV can be > present and represents the complete definition of a Flow > Specification for traffic to be placed on the tunnel indicated by = the > PCEP message in which the PCEP Flow Spec Object is carried. > NEW: > Only one Flow Filter TLV can be > present and represents the complete definition of a Flow > Specification for traffic to be placed on a tunnel; this tunnel is > indicated by the PCEP message in which the PCEP Flow Spec Object > is carried. Again, a period. > 7. Flow Specification TLVs > > [Page 14] > "Two bit flags (S and G) are defined. They have the common meanings = for > wildcarding in multicast." > -> At least a reference would be appreciated to teach about what > "common" refers to. I thought I was going to find this in 7761, but it wasn't that easy. Since the text immediately afterwards explains the bits anyway, we can = change this to... Two bit flags (S and G) are defined to describe the multicast = wildcarding in use. > [Page 15] > "if a Multicast Flow > Specification TLV is received with S bit =3D 0 and G bit =3D 1 the > receiver SHOULD respond" > -> Is there a reason why it is not a MUST? Right. I can't think of a "but MAY decide to let off fireworks and drink = prosecco," so we'll use MUST. > 13. Manageability Considerations > > - s/view the the Flow Specifications/view the Flow Specifications/ Again? > - s/implementations MUST support indicating/implementations MUST > indicate/ [Guessing it was wrongly fixed in -06.] Yes From nobody Sun Jan 5 12:45:28 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2C1120020; Sun, 5 Jan 2020 12:45:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <157825712075.4758.12283749661070239820@ietfa.amsl.com> Date: Sun, 05 Jan 2020 12:45:20 -0800 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-pcep-flowspec-07.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2020 20:45:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP Extension for Flow Specification Authors : Dhruv Dhody Adrian Farrel Zhenbin Li Filename : draft-ietf-pce-pcep-flowspec-07.txt Pages : 33 Date : 2020-01-05 Abstract: The Path Computation Element (PCE) is a functional component capable of selecting paths through a traffic engineering network. These paths may be supplied in response to requests for computation, or may be unsolicited instructions issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path. Traffic flows may be categorized and described using "Flow Specifications". RFC XXXX defines the Flow Specification and describes how Flow Specification Components are used to describe traffic flows. RFC XXXX also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes. This document specifies a set of extensions to PCEP to support dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of. RFC Editor Note: Please replace XXXX in the Abstract with the RFC number assigned to draft-ietf-idr-rfc5575bis when it is published. Please remove this note. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-flowspec/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-pcep-flowspec-07 https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-flowspec-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-flowspec-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 5 14:14:06 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B163120089; Sun, 5 Jan 2020 14:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evZWl3no9qIK; Sun, 5 Jan 2020 14:14:02 -0800 (PST) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 524B512006E; Sun, 5 Jan 2020 14:14:01 -0800 (PST) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 005MDxDn020322; Sun, 5 Jan 2020 22:13:59 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CDA6922044; Sun, 5 Jan 2020 22:13:59 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id B8D2B22042; Sun, 5 Jan 2020 22:13:59 +0000 (GMT) Received: from LAPTOPK7AS653V (83-215-194-123.stjo.dyn.salzburg-online.at [83.215.194.123]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 005MDwWp031721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 5 Jan 2020 22:13:59 GMT Reply-To: From: "Adrian Farrel" To: Cc: Date: Sun, 5 Jan 2020 22:13:58 -0000 Organization: Old Dog Consulting Message-ID: <002101d5c415$6e064680$4a12d380$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdXEE+vKLBPLyEBcR+SKFxKkKcvXug== Content-Language: en-gb X-Originating-IP: 83.215.194.123 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25150.003 X-TM-AS-Result: No--15.105-10.0-31-10 X-imss-scan-details: No--15.105-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25150.003 X-TMASE-Result: 10--15.105400-10.000000 X-TMASE-MatchedRID: tmbxcnYtprn2DHDk8DmSSLIGMNfiwa5NfYrr1p9yfCourUcwuzZNE7vR CkjY8noDasn8bgVzRJ/tSq0qk6SvLpRpdkEYVGP5GjzBgnFZvQ7a7r6g8x1D7sFWjX/gaJ2VJMJ XDJjkqdS1/jGQNd8qyaP/Z9MZQbU6P2mkvIawf9iQmLXB14cW2q19jpg9rDdhMfASU90zrfDIM2 a98Xrapa/j4LD5XBj2MIP4KTW9rEeFVWNH9lUU9eLdprnA5EQRF9s8UTYYetV+oVax2yyxN/PnG ScnZhgpt8i63vc8KiiHENd2MrmRZIToZqUCO9J5IjKSH8rlATtIwovbX4T40F3EhR+ObOOfb8sV AYna40JIf+fl/kg3E4nKVfJWqPOf7sb61lXuhtdO8qlnOXFSz3TZkLpEnIi4HDQcqEqNN+lCTVJ a1E1k0j6UYWxOIY5cgQ3Ta8QLtoPL101j42A3vfUwiX15l0tvZbvACQZDzTDEpNekAJHrLbJnPh 8w+R5o5F2cRfWsj9WRk6XtYogiarQ/aqQZTRfKU6baA36eiazEQdG7H66TyOk/y0w7JiZo X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [Pce] A discussion point for draft-ietf-pce-pcep-flowspec X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jan 2020 22:14:04 -0000 Hi WG, I received a couple of private emails about draft-ietf-pce-pcep-flowspec. Since they were private, I will try to be circumspect about who they were from. The sender asked to have a flag attached to a flow specification that indicates that it can be installed as a static route and thus not subject to a firewall rule so the longest prefix matching can be performed to manipulate route resolution for an LSP. The request also said that traditionally flow-specifications result in firewall rules and those rules operate on packets before longest prefix match. We want to install static routes, the equivalent of installing a prefix for an LSP and if we treat a flowspec as a static route we can mess things up like rule ordering and so on. The sender suggested that there are currently some draft(s) regarding this behavior for BGP flowspec as well, but was not able to point me at them. I asked for some clarifications and got back: "What BGP-FS does is install data-plane filters. We handle that by installing RIB entries (that's what BGP carries) into a RIB. Those entries are transformed into firewall filters. What I am asking for is not currently supported by BGP-flowspec. "What I am asking for is an indication that a flow-specification NOT be transformed into a data-plane filter. In other words, installed as a normal route where the route is subject to longest prefix match based forwarding. If you consider how we had to implement the multicast support for PCEP flowspec, it is quite similar. So, in my mind, the 'flag' is an indicator to do LPM for a destination. Presence of the flag also means that no other fields can be present in the flowspec, e.g. source address or dest/src L4 ports, etc." In my view, it should not be too hard to add a flag to the PCEP flow specification. But a couple of questions for the working group and my co-authors: - Does anyone else have interest in this work? - Can anyone else identify the related BGP work? - Does anyone want to suggest text for this? - Is this something we should leave as a future extension that can be proposed if/when someone cares about it? I suspect that the default position is "do nothing" and ask Julien to move the draft forward, so if you care please speak up. Thanks, Adrian From nobody Sun Jan 5 19:29:27 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A235E12001B; Sun, 5 Jan 2020 19:29:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <157828136262.4881.8451728340693377579@ietfa.amsl.com> Date: Sun, 05 Jan 2020 19:29:22 -0800 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-lsp-scheduling-11.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 03:29:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP Extensions for LSP scheduling with stateful PCE Authors : Huaimo Chen Yan Zhuang Qin Wu Daniele Ceccarelli Filename : draft-ietf-pce-stateful-pce-lsp-scheduling-11.txt Pages : 25 Date : 2020-01-05 Abstract: This document defines a set of extensions needed to the stateful Path Computation Element (PCE) communication Protocol (PCEP), so as to enable Labeled Switched Path (LSP) scheduling for path computation and LSP setup/deletion based on the actual network resource usage and the duration of a traffic service in a centralized network environment as stated in RFC 8413. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-scheduling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-lsp-scheduling-11 https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-pce-lsp-scheduling-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-lsp-scheduling-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 5 19:37:30 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8EF12008D; Sun, 5 Jan 2020 19:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6c8_vpZ-Xk5; Sun, 5 Jan 2020 19:37:25 -0800 (PST) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2095.outbound.protection.outlook.com [40.107.237.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB69812001B; Sun, 5 Jan 2020 19:37:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EJM5ZYwkKn8D4jF1Esvjj1nxanBMb6YtYt8pj5Sg1h8Ph3NQ90rmF/ZN/Mu9DrEOzZe5/ScuxJEGhH5aWa2MkqUshRmRYxLpwqYmwGteMiFgMP1ufYIveM4uMS6+nLCWu6GQGd7A4yGd0JUs4Jb63znMI6PsCEzSaWTXOr0QLBAQOqMwJWsfbfDObw3maGBevZtcS9FQf/RLqZVZaAyHUcbMX9xfz2xgRJm9yzN2EKQZRctZFjPlMepW1v9X4kFNWXJwcqDhSmnf0Yw5yQDblV+3D/yIBS62XS6AYGZT/25y7VtGHFcjOcu0oxrE0Vu13m3CteAE2Rc+mLKXstVZXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KXRUBxk5eCkAGwP1dGYAggOJnIufIe2klDu3w+tAHfU=; b=HSWWmLLVHcIBbrwaD5Wr+wGfRNLGCvI9nVkAKt7zKNzCNnSGMsqkJjG2bN+/vh6/5qkyj64cC2oDWWDpHc0kaedM/DwK4vsdJYVM5HJdgaOXbpOwR0ByXHGn8qJABMwWSQMN0t8YRHvgsEnuq09b+AvqUrUPSNDtTs2nqVddbWyJzzT2JffkhGHCcggyDcMnDil7pXZaulcpms3vfaPgOjdFbdS807i01JkTylDuMks6GNz0qlsWiQkVXktidhxfvxKHY3xFqdlWPRUDq7DQp14llPActIEOTUFteTk7i4Rjf3R93so5hTsy0Gk9doypllPD1q1Txt7Ov4QCoFfC/w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KXRUBxk5eCkAGwP1dGYAggOJnIufIe2klDu3w+tAHfU=; b=pDZ4pBbWXVWrTFinxYxn4LYFe7IrqrQ9Z+4P+eijPkvN6A75iYq1HwMxfJ8n8ggf612y1cyDlCsBjSDLz6Vu3m+M3EDqV3EQt4fP8xJUZmOdV5IqdL2Eq6Lvgv4ktowwLYK1Xd59xhMJjiiBw4MY+8+OWylhZEfgKRhmfnS2tV0= Received: from SN6PR13MB2271.namprd13.prod.outlook.com (52.135.93.160) by SN6PR13MB2541.namprd13.prod.outlook.com (52.135.89.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.4; Mon, 6 Jan 2020 03:37:21 +0000 Received: from SN6PR13MB2271.namprd13.prod.outlook.com ([fe80::70b0:78f1:a9bf:4b64]) by SN6PR13MB2271.namprd13.prod.outlook.com ([fe80::70b0:78f1:a9bf:4b64%7]) with mapi id 15.20.2602.015; Mon, 6 Jan 2020 03:37:21 +0000 From: Huaimo Chen To: "draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org" , "adrian@olddog.co.uk" CC: "pce@ietf.org" Thread-Topic: Shepherd review of draft-ietf-pce-stateful-pce-lsp-scheduling Thread-Index: AdXDTJ6UVH4sFIesQzmG4RqAc3dffgA9R4V5 Date: Mon, 6 Jan 2020 03:37:21 +0000 Message-ID: References: <02e401d5c34e$92b6da20$b8248e60$@olddog.co.uk> In-Reply-To: <02e401d5c34e$92b6da20$b8248e60$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huaimo.chen@futurewei.com; x-originating-ip: [73.114.233.24] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c32f29e0-678d-43ef-bfaf-08d79259bcba x-ms-traffictypediagnostic: SN6PR13MB2541: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(136003)(346002)(366004)(39830400003)(396003)(189003)(199004)(26005)(19627405001)(478600001)(2906002)(4326008)(33656002)(52536014)(7696005)(45080400002)(5660300002)(6506007)(53546011)(110136005)(55016002)(9686003)(44832011)(316002)(86362001)(966005)(8936002)(66476007)(76116006)(71200400001)(186003)(81166006)(81156014)(66946007)(66556008)(8676002)(66446008)(64756008); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR13MB2541; H:SN6PR13MB2271.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HWYlg0Fa1gwTpKg3MKGQsKGVlvlYC/FZ65Ww2idle6TgkGiv5FQaNYiZM+wMHQwc8JPIF9LyzWAYDXKXS5MHlIKF01yv9TqBBeywR0GekMeAasvr+Su6Uz0dvIRukX9UiD57SZRXAOBIK1Po9KR5tQjCcOqhb/aWskjji/womLQWHy1MFG2gyOuS8EMkBQgoMUCoOtA0dPqmP3r2HnfOHE6WxTkToi+lZD/78qq9X/Wg+phjbm0rOfgqGOonw+EzGtC/yvZPFYMNF7lv+m2C2UxyTjrSey6GBwHL3SJDOanDN7rqIE666TExLfL+UPb5k6jOMFqa7lGqquSWhWXkTXVv8HGVfr96O3whj6yI5mSeVmn2WqpskUWKbeC7eR2fp0Hi4uX/GjgixiwcrEFvbWSnq9HNRVPFWH8NMjhtp63RSvzneUbbnFvRY0s3zd8zVwzj7qWCRUrfbj8JOJr/l150ItJOGn5T5QCiZqXgZww5QA3xjAEWTEaEvS6HROL6VOCNvCB+TuSgLQzetuy5Cg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SN6PR13MB22717E695E754D7B4A547B42F23C0SN6PR13MB2271namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-Network-Message-Id: c32f29e0-678d-43ef-bfaf-08d79259bcba X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2020 03:37:21.0075 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BIcGRC1CX/Gy3dKVA0u3eBiN2LzDVfldVlL+udmqtfUO/2u9x6lbrj8L53bO2DkeA80JNqoZRPNgdejHQTiHpw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR13MB2541 Archived-At: Subject: Re: [Pce] Shepherd review of draft-ietf-pce-stateful-pce-lsp-scheduling X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 03:37:28 -0000 --_000_SN6PR13MB22717E695E754D7B4A547B42F23C0SN6PR13MB2271namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Adrian, Thank you very much for your comments and suggestions. The document has been updated accordingly. Best Regards, Huaimo ________________________________ From: Adrian Farrel Sent: Saturday, January 4, 2020 5:30 PM To: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org Cc: pce@ietf.org Subject: Shepherd review of draft-ietf-pce-stateful-pce-lsp-scheduling Hi authors, Just doing the shepherd write-up after working group last call and I have a nit in section 10.3 You ask for a new registry of bits, but you don't tell IANA the size of the registry. I think, to be consistent with (e.g.) https://nam03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ian= a.org%2Fassignments%2Fpcep%2Fpcep.xhtml%23stateful-pce-capability-tlv&d= ata=3D02%7C01%7Chuaimo.chen%40futurewei.com%7C233c0ebb38fb4f382d8108d79165b= ac7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637137738448839025&sda= ta=3D06D3YsdOtXIuB2dEhU3Yvn0y8h3bz1TvQITOxArDvig%3D&reserved=3D0 -flag-field you should have: OLD The following values are defined in this document: Bit Description Reference 0 R-bit This document 1 C-bit This document 2 A-bit This document NEW IANA is requested to populate this registry as follows: Bit Description Reference 0 R-bit This document 1 C-bit This document 2 A-bit This document 3-7 Unassigned END HC: Updated the document to contain the unassigned bits. However, please also consider that other TLV bit registries have started assigning bits from the largest number (sometimes 31, sometimes 15) countin= g downwards. This is not important, just "interesting". HC: Revised the document to start assigning bits from the largest one. Afraid we need a new revision before we can advance the document. While you're at it, can you fix the references noted by idnits. Thanks, Adrian --_000_SN6PR13MB22717E695E754D7B4A547B42F23C0SN6PR13MB2271namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Adrian,

    Thank you very much for your comments and suggestions.
    The document has been updated accordingly.

Best Regards,
Huaimo
From: Adrian Farrel <adr= ian@olddog.co.uk>
Sent: Saturday, January 4, 2020 5:30 PM
To: draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org <draft-ie= tf-pce-stateful-pce-lsp-scheduling@ietf.org>
Cc: pce@ietf.org <pce@ietf.org>
Subject: Shepherd review of draft-ietf-pce-stateful-pce-lsp-scheduli= ng
 
Hi authors,

Just doing the shepherd write-up after working group last call and I have a=
nit in section 10.3

You ask for a new registry of bits, but you don't tell IANA the size of the=
registry.

I think, to be consistent with (e.g.)
https://nam03.safelinks.protection.outlook.com/?url=3Dhtt= ps%3A%2F%2Fwww.iana.org%2Fassignments%2Fpcep%2Fpcep.xhtml%23stateful-pce-ca= pability-tlv&amp;data=3D02%7C01%7Chuaimo.chen%40futurewei.com%7C233c0eb= b38fb4f382d8108d79165bac7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6371= 37738448839025&amp;sdata=3D06D3YsdOtXIuB2dEhU3Yvn0y8h3bz1TvQITOxArDvig%= 3D&amp;reserved=3D0
-flag-field you should have:

OLD
   The following values are defined in this document:

   Bit    Description     = ;            &n= bsp;            = ;      Reference
   0      R-bit    &= nbsp;           &nbs= p;            &= nbsp;            Thi= s document
   1      C-bit    &= nbsp;           &nbs= p;            &= nbsp;            Thi= s document
   2      A-bit    &= nbsp;           &nbs= p;            &= nbsp;            Thi= s document
NEW
   IANA is requested to populate this registry as follows:

   Bit    Description     = ;            &n= bsp;            = ;      Reference
   0      R-bit    &= nbsp;           &nbs= p;            &= nbsp;            Thi= s document
   1      C-bit    &= nbsp;           &nbs= p;            &= nbsp;            Thi= s document
   2      A-bit    &= nbsp;           &nbs= p;            &= nbsp;            Thi= s document
   3-7  Unassigned
END

HC: Updated the document to contain the unassigned bits.

However, please also consider that other TLV bit registries have started assigning bits from the largest number (sometimes 31, sometimes 15) countin= g
downwards. This is not important, just "interesting".

HC: Revised the document to start assigning bits f= rom the largest one.

Afraid we need a new revision before we can advance the document. While
you're at it, can you fix the references noted by idnits.

Thanks,
Adrian

--_000_SN6PR13MB22717E695E754D7B4A547B42F23C0SN6PR13MB2271namp_-- From nobody Wed Jan 8 01:07:49 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89C51200E3; Wed, 8 Jan 2020 01:07:47 -0800 (PST) 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=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvuFb6VnNb28; Wed, 8 Jan 2020 01:07:45 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D29712002F; Wed, 8 Jan 2020 01:07:45 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 47t3L80MWdzywT; Wed, 8 Jan 2020 10:07:44 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.57]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 47t3L76XfQzDq7s; Wed, 8 Jan 2020 10:07:43 +0100 (CET) Received: from [10.192.147.100] (10.114.13.245) by OPEXCAUBM6D.corporate.adroot.infra.ftgroup (10.114.13.57) with Microsoft SMTP Server (TLS) id 14.3.468.0; Wed, 8 Jan 2020 10:07:43 +0100 To: CC: , References: <22192_1573830096_5DCEBDD0_22192_23_1_050def8f-dc47-4d5b-1303-2928ef08a041@orange.com> <001601d5c3f9$277b1b30$76715190$@olddog.co.uk> From: Organization: Orange Message-ID: <9ab9aee4-c1ac-49e0-8ddc-c30c4c84e250@orange.com> Date: Wed, 8 Jan 2020 10:07:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <001601d5c3f9$277b1b30$76715190$@olddog.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050308050903060905080109" X-Originating-IP: [10.114.13.245] Archived-At: Subject: Re: [Pce] Shepherd Review of draft-ietf-pce-pcep-flowspec X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 09:07:48 -0000 --------------ms050308050903060905080109 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Adrian, The resolutions below are fine by me. Let's see how the discussion progresses on that filter/route switch and we'll be able to move forward.= Thanks, Julien On 05/01/2020 19:51, Adrian Farrel wrote: > Hi Julien, > > Long ago you sent your review. Comments in line. > > At the same time, we see that IDR has basically completed work on draft= -ietf-idr-rfc5575bis and we think we should update this document to use t= hat as a reference instead of RFC 5575 and RFC 7674. > > Finally, someone contacted us privately to ask that we add a flag to a = PCEP flowspec to indicate that it should not be installed as a data plane= filter, but should be installed as a 'normal route' with longest prefix = matching. That is a simple change, but nevertheless a change of technical= substance. I'll send a separate email to the list to see whether anyone = else is interested and determine whether we can craft some text. > > I'll do a new revision and then start the thread for the additional poi= nt noted above. > > Best wishes for the New Year, > Adrian > > =3D=3D=3D > >> I still have one pending question, related to section 8.7. (Priorities= >> and Overlapping Flow Specifications). I understand this section as >> "priorities within PCEP-installed flow specs follow the same ordering >> rules as BGP-installed flow specs, i.e. [RFC5575]". Let us now look at= a >> device supporting both protocols to install flow specs: >> - Is there an implicit scope associated to each set of flow specs maki= ng >> them mutually exclusive? >> - If both sets can overlap, can we assume that priority rules do not >> care about the protocol used to install the flow specs? >> Adding a couple of sentences may be enough to clarify that. > You raise a very good point. I am not certain how often this is going t= o arise, but it seems almost certain that were we to decide it could neve= r arise, it would immediately become a requirement from the field. So we = should address it. > > Now, draft-ietf-idr-rfc5575bis-18.txt talks only about BGP, but section= 5.1 gives a description of how flow specifications are ordered for traff= ic matching regardless of what order they arrive in BGP. I think we shoul= d assume that all traffic is open to all flowspecs whether installed by B= GP for firewalls or routing, or installed by PCEP for classification onto= traffic paths (LSPs or SR paths). I believe that similar work is being l= ooked at for classification of traffic onto service function chains, and = I imagine that those flowspecs might also coincide with BGP and PCEP flow= specs. > > I think that all we need do is: > - call out that both protocols might be simultaneously present and dist= ributing flowspecs for installation > - make the observation that the rules defined in section 5.1 of draft-i= etf-idr-rfc5575bis apply regardless of which protocol distributed the flo= wspec. > > That brings me to the text in 8.7: > OLD > Flow specifications can overlap. For example, two different flow > specifications may be identical except for the length of the prefix > in the destination address. In these cases the PCC must determine > how to prioritize the flow specifications so as to know to which pat= h > to assign packets that match both flow specifications. That is, the= > PCC must assign a precedence to the flow specifications so that it > checks each incoming packet for a match in a predictable order. > > The processing of BGP Flow Specifications is described in [RFC5575].= > Section 5.1 of that document explains the order of traffic filtering= > rules to be executed by an implementation of that specification. > > PCCs MUST apply the same ordering rules as defined in [RFC5575]. > NEW > Flow specifications can overlap. For example, two different flow > specifications may be identical except for the length of the prefix > in the destination address. In these cases the PCC must determine > how to prioritize the flow specifications so as to know to which pat= h > to assign packets that match both flow specifications. That is, the= > PCC must assign a precedence to the flow specifications so that it > checks each incoming packet for a match in a predictable order. > > The processing of BGP Flow Specifications is described in=20 > [I-D.ietf-idr-rfc5575bis]. Section 5.1 of that document explains th= e > order of traffic filtering rules to be executed by an implementation= > of that specification. > > PCCs MUST apply the same ordering rules as defined in=20 > [I-D.ietf-idr-rfc5575bis]. > > Furthermore, it is possible that Flow Specifications will be distrib= uted > by BGP as well as by PCEP as described in this document. In such=20 > cases implementations supporting both approaches MUST apply the > prioritization and ordering rules as set out in [I-D.ietf-idr-rfc557= 5bis] > regardless of which protocol distributed the Flow Specifications, > however implementations MAY provide a configuration control to=20 > allow one protocol to take precedence over the other as this may be > particularly useful if the Flow Specification make identical matches= > on traffic but have different actions. It is RECOMMENDED that when > two Flow Specifications distributed by different protocols overlap, > and especially when one acts to replace another, that a message be=20 > logged for the operator to understand the behaviour. > END > >> Please find below a few additional nits. >> ------ >> 1. Introduction >> >> - The abstract uses "traffic engineered networks", the intro "traffic >> engineering networks". I do not have any strong preference, but >> consistency would be welcome. (By the way, no hyphen in >> "traffic-engineered"?) > Yes. "traffic engineering" > >> - s/to Generalized MPLS (GMPLS) networks/to Generalized MPLS >> (GMPLS)-controlled networks/ > OK > >> - s/about the the LSPs/about the LSPs/ > oops > >> - OLD: >> The data flows >> intended for a tunnel can be described using Flow Specification >> Components, and when PCEP is in use for tunnel initiation it makes >> sense for that same protocol to be used to distribute the Flow >> Specification Components that describe what data is to flow on those= >> tunnels. >> NEW: >> The data flows >> intended for a tunnel can be described using Flow Specification >> Components; when PCEP is in use for tunnel initiation, it makes >> sense for that same protocol to be used to distribute the Flow >> Specification Components that describe what data is to flow on those= >> tunnels. > Going even further and using a period. > >> 3.2. Elements of Procedure >> >> - s/in each case including whether/in each case. This includes whether= / > OK > >> 6. Flow Filter TLV >> >> OLD: >> Only one Flow Filter TLV can be >> present and represents the complete definition of a Flow >> Specification for traffic to be placed on the tunnel indicated by th= e >> PCEP message in which the PCEP Flow Spec Object is carried. >> NEW: >> Only one Flow Filter TLV can be >> present and represents the complete definition of a Flow >> Specification for traffic to be placed on a tunnel; this tunnel is >> indicated by the PCEP message in which the PCEP Flow Spec Object >> is carried. > Again, a period. > >> 7. Flow Specification TLVs >> >> [Page 14] >> "Two bit flags (S and G) are defined. They have the common meanings f= or >> wildcarding in multicast." >> -> At least a reference would be appreciated to teach about what >> "common" refers to. > I thought I was going to find this in 7761, but it wasn't that easy. > Since the text immediately afterwards explains the bits anyway, we can = change this to... > > Two bit flags (S and G) are defined to describe the multicast wildcardi= ng in use. > >> [Page 15] >> "if a Multicast Flow >> Specification TLV is received with S bit =3D 0 and G bit =3D 1 the >> receiver SHOULD respond" >> -> Is there a reason why it is not a MUST? > Right. I can't think of a "but MAY decide to let off fireworks and drin= k prosecco," so we'll use MUST. > >> 13. Manageability Considerations >> >> - s/view the the Flow Specifications/view the Flow Specifications/ > Again? > >> - s/implementations MUST support indicating/implementations MUST >> indicate/ [Guessing it was wrongly fixed in -06.] > Yes > > --------------ms050308050903060905080109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC EmowggTeMIIDxqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMGoxCzAJBgNVBAYTAkZSMRowGAYD VQQKDBFGcmFuY2UgVGVsZWNvbSBTQTEXMBUGA1UECwwOMDAwMiAzODAxMjk4NjYxJjAkBgNV BAMMHUdyb3VwZSBGcmFuY2UgVGVsZWNvbSBSb290IENBMB4XDTA1MTExNzExMDkzOVoXDTI1 MTExNzExMDkzOVowgZYxCzAJBgNVBAYTAkZSMRowGAYDVQQKDBFGcmFuY2UgVGVsZWNvbSBT QTEkMCIGA1UECwwbV2VzdGVybkVVIE1pZGRsZUVhc3QgQWZyaWNhMRcwFQYDVQQLDA4wMDAy IDM4MDEyOTg2NjEsMCoGA1UEAwwjR3JvdXBlIEZyYW5jZSBUZWxlY29tIEludGVybmFsIENB IDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCw8ytv/3/3nS8Xkfrfv3lWqny4 Gd1V8eVOT7B0WxfJMqfWPbu0aoc4WScRhqIhAH61Gmfa6f3AVq+o3PptjJ459kMp/ACaeRp8 DFzW7iNFm/Qfdk81V9dVLXHsbYwWU373j/ksx1Smmk3vsq4fWapeAOLfds70KO4RWP/YVSmO rAFVMiqV4l9f6a+G8Lr2tOZkWaX+3vb3HE6mDG3la3Y6VDpVpioSrz61KPb8pLyOg7TuhhIx OKTNNefEcDwFKx9zfVJax+PHj6zGbFzdGEMWexwGSi3SXkgAV6/CJNtCHHXE2OprWc30JiCY 18GkvPrRgO1XBSqx0xDIam+WpEh/AgMBAAGjggFgMIIBXDAPBgNVHRMBAf8EBTADAQH/MA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUNhwzZ9MTXPpbn+qLukRmdEbxd3gwdAYDVR0jBG0w a4AUGpJTyM8zG7bypWB94q8kEkGwmmChUIFOQ049R3JvdXBlIEZyYW5jZSBUZWxlY29tIFJv b3QgQ0EsIE9VPTAwMDIgMzgwMTI5ODY2LCBPPUZyYW5jZSBUZWxlY29tIFNBLCBDPUZSggEA MIGOBgNVHR8EgYYwgYMwQ6BBoD+GPWh0dHA6Ly9pZ2NnZnQtcmNhLWh0dHAuc2kuZnJhbmNl dGVsZWNvbS5mci9jcmwvaWdjZ2Z0X3JjYS5jcmwwPKA6oDiGNmh0dHA6Ly9pZ2NnZnQtcmNh LmZyYW5jZXRlbGVjb20uY29tL2NybC9pZ2NnZnRfcmNhLmNybDATBgNVHSAEDDAKMAgGBiqB egEQDDANBgkqhkiG9w0BAQUFAAOCAQEAlt994iqOFDZH/wQfDU6EQ1W1B/xs/k3xwBuBZgi3 NRWvvb8KhfoOVOyeuoO1r4072jo/AFDphvixN8EZiRp+luqZXQEXEaHrZjwRydCuUDwjPQkw A/DU5NzWn0FrKWRIstQa/MBcN9xniazs41Br3oNzlkUbAyuP2s3GRi5uFp7VV5Y5dU8lqdoL nE/TuBV0LFdre0WOdM7CoWVqNlreb7/zmuK2/zfLIaq2QIcWIOulqiIW1xxFWxc0JZi8p7qV zvysS0+8wevgoefks3PHoUMEaIHCpoSOC14JSkKCVuUMPBvu+ftPasJ+NQz1jUbb0kjUkpGn q33GgLPLSvsK5TCCBsAwggWooAMCAQICEhEhrKTzJoGqMVywoqjNXFnwQTANBgkqhkiG9w0B AQUFADCBljELMAkGA1UEBhMCRlIxGjAYBgNVBAoMEUZyYW5jZSBUZWxlY29tIFNBMSQwIgYD VQQLDBtXZXN0ZXJuRVUgTWlkZGxlRWFzdCBBZnJpY2ExFzAVBgNVBAsMDjAwMDIgMzgwMTI5 ODY2MSwwKgYDVQQDDCNHcm91cGUgRnJhbmNlIFRlbGVjb20gSW50ZXJuYWwgQ0EgMTAeFw0x NzAyMjgwOTQyMDhaFw0yMTAyMjgwOTQyMDhaMGoxCzAJBgNVBAYTAkZSMRowGAYDVQQKExFG cmFuY2UgVGVsZWNvbSBTQTEWMBQGA1UEAwwNTWV1cmljIEp1bGllbjEnMCUGCSqGSIb3DQEJ AQwYanVsaWVuLm1ldXJpY0BvcmFuZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA0Pfhby8TRScxVqtTKug3CKgJW1ub3Y7JydhngY8GOXTXy7mUt4aA0V2JsooyqF3+ nO1xcl3D1RZ+l04fRNHCh/CUHhamoNykCFRNoIM/DuzT7NE5h94UR/3RRgZ2qbZoIn5KYIBj bVMacnZnB/qB9DUH61ecMTzrOG0ePtvABWcrhhOZ2S0MvPJkPtAAlL7qvTe9gJwZkBtEuZ0q rJ0D3OXl5ayV7eP9FuRJ/0jf9FdxnmY0Aagm6+r5vsj9dhU9Gf5cA+mh+L7zrCIpTG2GVLLd KaSORJ1cZ+LeZlgpK+hKJ4ho+J/Usqu9Ak8ngAeOgJqTjxRvOimdZZfJ+2E/GQIDAQABo4ID MTCCAy0wDgYDVR0PAQH/BAQDAgbAMBMGA1UdJQQMMAoGCCsGAQUFBwMEMCMGA1UdEQQcMBqB GGp1bGllbi5tZXVyaWNAb3JhbmdlLmNvbTCCAiEGA1UdHwSCAhgwggIUMIHooIHloIHihoHf bGRhcDovLy9jbj1Hcm91cGUlMjBGcmFuY2UlMjBUZWxlY29tJTIwSW50ZXJuYWwlMjBDQSUy MDEsY249aWdjZ2Z0aSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vy dmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1hZCxEQz1mcmFuY2V0ZWxlY29tLERDPWZyP2Nl cnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RjbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludDCBqaCBpqCBo4aBoGxkYXA6Ly9pZ2NnZnRpLWNhMS1sZGFwLnNpLmZyYW5jZXRl bGVjb20uZnIvb3U9aWdjZ2Z0aV9jYTEsb3U9Q0Esb3U9Q1JMRFAsb3U9QUNfT04sb3U9SUdD R3JvdXBlLG89RnJhbmNlVGVsZWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/ b2JqZWN0Y2xhc3M9cGtpQ2EwNKAyoDCGLmh0dHA6Ly9wa2ktY3JsLml0bi5mdGdyb3VwL2Ny bC9pZ2NnZnRpX2NhMS5jcmwwRaBDoEGGP2h0dHA6Ly9pZ2NnZnRpLWNhMS1odHRwLnNpLmZy YW5jZXRlbGVjb20uZnIvY3JsL2lnY2dmdGlfY2ExLmNybDA+BgNVHSAENzA1MDMGCCqBegEQ DAIDMCcwJQYIKwYBBQUHAgEWGWh0dHA6Ly9wa2ktb3JhbmdlLmNvbS9jcHMwPAYIKwYBBQUH AQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpLW9jc3AuaXRuLmZ0Z3JvdXAvb2NzcDAd BgNVHQ4EFgQUEqE2gJM6hxLi6AlLKQ8kT4r1AlUwHwYDVR0jBBgwFoAUNhwzZ9MTXPpbn+qL ukRmdEbxd3gwDQYJKoZIhvcNAQEFBQADggEBAGxsRCzFlIhen5KnTgZDP6e5jd+ff1MoW3jq wiqxg8v33FldytRqsR5ydg4G5s+mdYhtViuuqm+vOo0F+8oSudj2M70zFIzQR2jMvR8P1oFF 2n+aQlZDW/JY5KqsxbUaR1w5QFE4LCj77OlvTTtaHXn6tZINQqD2rE/28S91ShC4H6WfsTve y2CCLvuYzwUkQ/tPC23rWYxO/hZPkOT/MbgijzIFh4Ys8ENfYNTwkrNSj0LmmJREXIXq50UV EpnsI2v5hE8jXkXlWvT6eXJ7RkocfIjwENvOMvA5/WxE9tvpVCSGq+c5YMWEfyT6o+V2LtTG dtJ3dWNCmsmAgBWXnaswggbAMIIFqKADAgECAhIRIb+AKeqA4nD4aGytIumMzn8wDQYJKoZI hvcNAQEFBQAwgZYxCzAJBgNVBAYTAkZSMRowGAYDVQQKDBFGcmFuY2UgVGVsZWNvbSBTQTEk MCIGA1UECwwbV2VzdGVybkVVIE1pZGRsZUVhc3QgQWZyaWNhMRcwFQYDVQQLDA4wMDAyIDM4 MDEyOTg2NjEsMCoGA1UEAwwjR3JvdXBlIEZyYW5jZSBUZWxlY29tIEludGVybmFsIENBIDEw HhcNMTcwMjI4MDk0MjIxWhcNMjEwMjI4MDk0MjIxWjBqMQswCQYDVQQGEwJGUjEaMBgGA1UE ChMRRnJhbmNlIFRlbGVjb20gU0ExFjAUBgNVBAMMDU1ldXJpYyBKdWxpZW4xJzAlBgkqhkiG 9w0BCQEMGGp1bGllbi5tZXVyaWNAb3JhbmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAMYlaLPYjHfuVjqtO9apWcAd2PIK1MyO7sDYhYw0itPsnsSzsMUa+o7Xjwr/ 9JHcyYEehz2uqzpT0L3bFC8ROTGF3l9sZDPGpUlGeYEFCpNxT2Eg5ZIizYHd5feghGDgbnm0 3UaNldIpi5gtuKSSUHJwLgzZwMykwOdGBkl9dJvj2mccxIlViUATimvjuOj8TES9zrNWuWU7 d1LM9SUrKngkMIA5s801vT4FlvpL/ER7Yt6idZ8rGPXsMdFOhiV3AzLBl1ypaVrQ+OGum/sh c56fMCppmz5okaiGJ2DC9MRR0l4e6ZNrg+nKfm7IhIrCn7wED1TJAfuQfz3YYXKEwO8CAwEA AaOCAzEwggMtMA4GA1UdDwEB/wQEAwIFIDATBgNVHSUEDDAKBggrBgEFBQcDBDAjBgNVHREE HDAagRhqdWxpZW4ubWV1cmljQG9yYW5nZS5jb20wggIhBgNVHR8EggIYMIICFDCB6KCB5aCB 4oaB32xkYXA6Ly8vY249R3JvdXBlJTIwRnJhbmNlJTIwVGVsZWNvbSUyMEludGVybmFsJTIw Q0ElMjAxLGNuPWlnY2dmdGksQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9ZnJhbmNldGVsZWNvbSxEQz1m cj9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JMRGlzdHJp YnV0aW9uUG9pbnQwgamggaaggaOGgaBsZGFwOi8vaWdjZ2Z0aS1jYTEtbGRhcC5zaS5mcmFu Y2V0ZWxlY29tLmZyL291PWlnY2dmdGlfY2ExLG91PUNBLG91PUNSTERQLG91PUFDX09OLG91 PUlHQ0dyb3VwZSxvPUZyYW5jZVRlbGVjb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9i YXNlP29iamVjdGNsYXNzPXBraUNhMDSgMqAwhi5odHRwOi8vcGtpLWNybC5pdG4uZnRncm91 cC9jcmwvaWdjZ2Z0aV9jYTEuY3JsMEWgQ6BBhj9odHRwOi8vaWdjZ2Z0aS1jYTEtaHR0cC5z aS5mcmFuY2V0ZWxlY29tLmZyL2NybC9pZ2NnZnRpX2NhMS5jcmwwPgYDVR0gBDcwNTAzBggq gXoBEAwCAjAnMCUGCCsGAQUFBwIBFhlodHRwOi8vcGtpLW9yYW5nZS5jb20vY3BzMDwGCCsG AQUFBwEBBDAwLjAsBggrBgEFBQcwAYYgaHR0cDovL3BraS1vY3NwLml0bi5mdGdyb3VwL29j c3AwHQYDVR0OBBYEFJpO/hkvlNNchTsRMqcXbFKjr7BjMB8GA1UdIwQYMBaAFDYcM2fTE1z6 W5/qi7pEZnRG8Xd4MA0GCSqGSIb3DQEBBQUAA4IBAQCTgsPIg7wni+YEn7NuxicptWVyoYjn XO9UfYTb4t6M1nizQPrL1ctPCqooEAxUhiH+i8YlnUkG5CHMatTwLtnZJvzGqHkY7q/Ctbki DOqfhaM4b9by+CJp9B5GTKeUzCKAt2Fk0TKqlwbGdKiUfPL9AC58UYOKqjlMUPf6suxqA1fM FyCUBu991kEdwSF7iXbSC/QP2EVsr5Yo1WU9856hAD87Lv/hFp5FjVYKFn9iMQvu325XYLvy EhveODX1HsLj0ohm3/GfPYwyIZpG690uSROq7X8+8WUdX/oplOoaxpEkH5tJO51VAQybQPgj daMD+h/Latx+6W9Dz6oPAxw0MYIEODCCBDQCAQEwga0wgZYxCzAJBgNVBAYTAkZSMRowGAYD VQQKDBFGcmFuY2UgVGVsZWNvbSBTQTEkMCIGA1UECwwbV2VzdGVybkVVIE1pZGRsZUVhc3Qg QWZyaWNhMRcwFQYDVQQLDA4wMDAyIDM4MDEyOTg2NjEsMCoGA1UEAwwjR3JvdXBlIEZyYW5j ZSBUZWxlY29tIEludGVybmFsIENBIDECEhEhrKTzJoGqMVywoqjNXFnwQTANBglghkgBZQME AgEFAKCCAlswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAw MTA4MDkwNzQyWjAvBgkqhkiG9w0BCQQxIgQgAU9IAp+BHtadZyUSClTPx9r3OYIro77H87Fy 9EW4LkgwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGwMIGtMIGWMQswCQYDVQQGEwJGUjEaMBgGA1UECgwR RnJhbmNlIFRlbGVjb20gU0ExJDAiBgNVBAsMG1dlc3Rlcm5FVSBNaWRkbGVFYXN0IEFmcmlj YTEXMBUGA1UECwwOMDAwMiAzODAxMjk4NjYxLDAqBgNVBAMMI0dyb3VwZSBGcmFuY2UgVGVs ZWNvbSBJbnRlcm5hbCBDQSAxAhIRIb+AKeqA4nD4aGytIumMzn8wgcAGCyqGSIb3DQEJEAIL MYGwoIGtMIGWMQswCQYDVQQGEwJGUjEaMBgGA1UECgwRRnJhbmNlIFRlbGVjb20gU0ExJDAi BgNVBAsMG1dlc3Rlcm5FVSBNaWRkbGVFYXN0IEFmcmljYTEXMBUGA1UECwwOMDAwMiAzODAx Mjk4NjYxLDAqBgNVBAMMI0dyb3VwZSBGcmFuY2UgVGVsZWNvbSBJbnRlcm5hbCBDQSAxAhIR Ib+AKeqA4nD4aGytIumMzn8wDQYJKoZIhvcNAQEBBQAEggEAZpc2sayM1VbolTHCNuX51/t4 hXbBMnYdYyieQNjM+G0NmUIr+AoU6pg5mf2JRjA8GjwqFzvkRTkTkeKrEEMtY3vvRDmaOk0V /6yd0kbT03RGCKfB+q53a/2NklSdHXHNMXGTNzwUmfESWD5K18o7ny99FuovNC/TsBrjAgcU StgA8kr0/MhOBUq0wIZeeKvj7w5M5xhunW1EbVRSUiwA69Jl8qlfWo26rH9mrYjMhFB9Aszu mCsW0DeBIa0s953jpWW1YMN5ZGkOOhoS7EnLitGl1T1m1R7kO8cv076WIphLZR4mgmUgvncQ vE3SEjTlUsuCs/mkwAze8lNIEXE5VAAAAAAAAA== --------------ms050308050903060905080109-- From nobody Thu Jan 9 21:44:57 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF11120169; Thu, 9 Jan 2020 21:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UliP12kPElYf; Thu, 9 Jan 2020 21:44:53 -0800 (PST) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90ACC1200B3; Thu, 9 Jan 2020 21:44:53 -0800 (PST) Received: by mail-pf1-x42e.google.com with SMTP id w62so574556pfw.8; Thu, 09 Jan 2020 21:44:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T6Q94kiyCznIGSWYoczO4di3YhIPpZWEeHJqUBdYg1o=; b=phe+Q2wA4csn281coxCZvp3Rkc/yS3mTW0PvRFkj1ok6/xIB0vDoaEpK2pYIkUh52l DKM1JIOqegQHxf+Ti09pFQtLkB7qEQBRyc3+OhJOyYg1uM3VjJO5YvUduNhcpIBFo+9J u2XDFjPSfewhjP/TPDAEUmoO7vCwNvc7bBjb1pGtL9xdsghOugXzkP/bNyFCKOihZXrE RQcMNZsqhn2I9JRgp/Z/Pd6+z7dOP32cPbdUzfRwbLMdRQrFOi4KmR+juuhBBXp+WgC9 FDCLe6XCh0+wWixa/UpluONCHMjy0P9I7Hksmi/CEXtJByMH3Zrfy3MdP041Lb9RSNd6 LZeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T6Q94kiyCznIGSWYoczO4di3YhIPpZWEeHJqUBdYg1o=; b=WnzrKcDu378n7/5vQAqqDJeFZqLHXPL1WotWq8IP84dC7uRuQdOPw/OuqCISLvbPQd Rm34ih9OXYaH0XbyGwhFx9/Fj0eXimirtOc6aF9Fpi3e1RUVoqtpYECMXLmkooJUvV9m +GLsA2Eq9ro3esyVgblwQZAC1puGICMu98LGq21pTw7YL8FWCACs9cv4FZhHdXFuN4tG nV69q0fy4E+TNcdG0YK6YGZirTavY7TkqTgvkZDf/zrDRlTs2Dg8xdkRNIF9p4edxJlI mOPDwJDdf/wqf7EF7U6xDofRc1kGBSKZ/BQLvKKPm+K/8L9SK6urJwxxKqZOFrEdkB9O LHpw== X-Gm-Message-State: APjAAAXvjnUErDQfFd88eiHV++S37G/x9UB2nTTvsU+CNAAv4HaqE3PB DXksZV8t5LvMb4qBRHPsTT0o8ffEzgMp9YFx71F2xWY6jM0= X-Google-Smtp-Source: APXvYqzghTdYKAiRVkbgTi4QZ3BBgH+aXKoeXe0/f1TKu+UZ5TM7QQPmU3vVtDRaTg2733c1fli1MJNG1sHfnr5Skao= X-Received: by 2002:aa7:9296:: with SMTP id j22mr1951382pfa.201.1578635093014; Thu, 09 Jan 2020 21:44:53 -0800 (PST) MIME-Version: 1.0 References: <002101d5c415$6e064680$4a12d380$@olddog.co.uk> In-Reply-To: <002101d5c415$6e064680$4a12d380$@olddog.co.uk> From: Vishnu Pavan Beeram Date: Thu, 9 Jan 2020 23:44:41 -0600 Message-ID: To: Adrian Farrel Cc: pce@ietf.org, draft-ietf-pce-pcep-flowspec@ietf.org Content-Type: multipart/alternative; boundary="000000000000f2fe9c059bc29f82" Archived-At: Subject: Re: [Pce] A discussion point for draft-ietf-pce-pcep-flowspec X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 05:44:56 -0000 --000000000000f2fe9c059bc29f82 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Adrian, Hi! Much Thanks for starting this thread! There are multiple implementations that support user-triggered installation/uninstallation of destination-IPv4/IPv6 prefixes bound to a TE Path (installation of routes subject to longest prefix match based forwarding) and it is important to have this behavior covered in PCEP. I=E2=80=99m listing 3 options that were considered for addressing this item= : 1. Add a new sub-section to Section 8 of stating that an implementation receiving a FLOWSPEC object that carries only destination IPv4/IPv6 TLVs may choose to not install any data-plane filters and instead install routes that are subject to longest prefix ma= tch (LPM) based forwarding. With this option, the controller has no say in h= ow the network element processes these destination IPV4/IPv6 TLVs. 2. Introduce a new flag in the FLOWSPEC object to explicitly indicate that routes subject to LPM based forwarding MUST be installed. When this flag is set, the FLOWSPEC object MUST carry only destination IPv4/IPv6 T= LVs. 3. Do not use the FLOWSPEC object at all for this; Use the TE-PATH-BINDING TLV (introduced by draft-ietf-pce-binding-label-sid) instead. This requires the addition of a couple of new Binding Types (BT= ) to indicate destination-IPV4 and destination-IPv6 bindings. This also requires us to add the ability to encode multiple Path Bindings (list) in the same message and the ability to remove specific Path Bindings in = a given message. Based on some offline conversations with interested parties, there is a strong need to have an explicit indication for this type of behavior (avoid ambiguity with respect to filtering) -- so that makes Option 1 undesirable. There is also a requirement to carry a mix of install and uninstall destination prefixes associated with a path in the same message. The way the FLOWSPEC object is currently defined (the R flag is specified per FLOWSPEC object and not per TLV; parity with BGP), you would need one object to carry the install prefixes and one more to carry the uninstall prefixes. Given all this, there is some consensus among interested parties to implement this behavior using the TE-PATH-BINDING TLV. Note that this also means that draft-ietf-pce-pcep-flowspec can proceed as is. @WG -- Any thoughts? Regards, -Pavan On Sun, Jan 5, 2020 at 4:14 PM Adrian Farrel wrote: > Hi WG, > > I received a couple of private emails about draft-ietf-pce-pcep-flowspec. > > Since they were private, I will try to be circumspect about who they were > from. > > The sender asked to have a flag attached to a flow specification that > indicates that it can be installed as a static route and thus not subject > to > a firewall rule so the longest prefix matching can be performed to > manipulate route resolution for an LSP. > > The request also said that traditionally flow-specifications result in > firewall rules and those rules operate on packets before longest prefix > match. We want to install static routes, the equivalent of installing a > prefix for an LSP and if we treat a flowspec as a static route we can mes= s > things up like rule ordering and so on. > > The sender suggested that there are currently some draft(s) regarding thi= s > behavior for BGP flowspec as well, but was not able to point me at them. > > I asked for some clarifications and got back: > > "What BGP-FS does is install data-plane filters. We handle that by > installing RIB entries (that's what BGP carries) into a RIB. Those entrie= s > are transformed into firewall filters. What I am asking for is not > currently supported by BGP-flowspec. > > "What I am asking for is an indication that a flow-specification NOT be > transformed into a data-plane filter. In other words, installed as a > normal > route where the route is subject to longest prefix match based forwarding= . > If you consider how we had to implement the multicast support for PCEP > flowspec, it is quite similar. So, in my mind, the 'flag' is an indicato= r > to do LPM for a destination. Presence of the flag also means that no oth= er > fields can be present in the flowspec, e.g. source address or dest/src L4 > ports, etc." > > In my view, it should not be too hard to add a flag to the PCEP flow > specification. > > But a couple of questions for the working group and my co-authors: > - Does anyone else have interest in this work? > - Can anyone else identify the related BGP work? > - Does anyone want to suggest text for this? > - Is this something we should leave as a future extension that can be > proposed if/when someone cares about it? > > I suspect that the default position is "do nothing" and ask Julien to mov= e > the draft forward, so if you care please speak up. > > Thanks, > Adrian > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --000000000000f2fe9c059bc29f82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Adri= an, Hi!

=C2=A0

Much= Thanks for starting this thread! There are multiple implementations that support user-triggered inst= allation/uninstallation of destination-IPv4/IPv6 prefixes bound to a TE Path (installation of route= s subject to longest prefix match based forwarding) and it is important to have this = behavior covered in PCEP.

=C2=A0

I=E2= =80=99m listing 3 options that were considered for addressing this item:

  1. Add a new sub-section to Section 8 of <draft-ietf-pce-pcep-flowspec= > stating that an implementation receiving a FLOWSPEC object that carrie= s only destination IPv4/IPv6 TLVs may choose to not install any data-pla= ne filters and instead install routes that are subject to longest prefix match (LPM) based forwarding. With this option, the controller has no = say in how the network element processes these destination IPV4/IPv6 TLVs.=
  2. Introduce a new flag in the FLOWSPEC obj= ect to explicitly indicate that routes subject to LPM based forwarding MUST be installed= . When this flag is set, the FLOWSPEC object MUST carry only destination IPv4/IPv6 TLVs.
  3. Do not use the FLOWSPEC object at all for this; Use the TE-PATH-BINDING TLV (introduced by draft-ietf-pc= e-binding-label-sid) instead. This requires the addition of a couple of new Binding Types (= BT) to indicate destination-IPV4 and destination-IPv6 bindings. This also requires us to add the ability t= o encode multiple Path=C2=A0Bindings (list) in the same message and the ability to remove specific Path=C2= =A0Bindings in a given message.

=C2=A0

Based on some offline conversations with interested parties, there is a strong need to have an explicit indicat= ion for this type of behavior (avoid ambiguity with respect to filtering) -- so that makes Option 1 undesirable. There is also a requirement to carry a mix= of install and uninstall destination prefixes associated with a path in the same messa= ge. The way the FLOWSPEC object is currently defined (the R flag is specified p= er FLOWSPEC object and not per TLV; parity with BGP), you would need one objec= t to carry the install prefixes and one more to carry the uninstall prefixes. Gi= ven all this, there is some consensus among interested parties to implement this behavior using the TE-PATH-BINDING TLV. Note that this also means that draft-ietf-pce-pcep-flowspec can proceed = as is.

=C2=A0

@WG -- Any thoughts?

=C2=A0

Regards,

-Pavan


= On Sun, Jan 5, 2020 at 4:14 PM Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi WG,

I received a couple of private emails about draft-ietf-pce-pcep-flowspec.
Since they were private, I will try to be circumspect about who they were from.

The sender asked to have a flag attached to a flow specification that
indicates that it can be installed as a static route and thus not subject t= o
a firewall rule so the longest prefix matching can be performed to
manipulate route resolution for an LSP.

The request also said that traditionally flow-specifications result in
firewall rules and those rules operate on packets before longest prefix
match. We want to install static routes, the equivalent of installing a
prefix for an LSP and if we treat a flowspec as a static route we can mess<= br> things up like rule ordering and so on.

The sender suggested that there are currently some draft(s) regarding this<= br> behavior for BGP flowspec as well, but was not able to point me at them.
I asked for some clarifications and got back:

"What BGP-FS does is install data-plane filters.=C2=A0 We handle that = by
installing RIB entries (that's what BGP carries) into a RIB. Those entr= ies
are transformed into firewall filters.=C2=A0 What I am asking for is not currently supported by BGP-flowspec.

"What I am asking for is an indication that a flow-specification NOT b= e
transformed into a data-plane filter.=C2=A0 In other words, installed as a = normal
route where the route is subject to longest prefix match based forwarding.<= br> If you consider how we had to implement the multicast support for PCEP
flowspec, it is quite similar.=C2=A0 So, in my mind, the 'flag' is = an indicator
to do LPM for a destination.=C2=A0 Presence of the flag also means that no = other
fields can be present in the flowspec, e.g. source address or dest/src L4 ports, etc."

In my view, it should not be too hard to add a flag to the PCEP flow
specification.

But a couple of questions for the working group and my co-authors:
- Does anyone else have interest in this work?
- Can anyone else identify the related BGP work?
- Does anyone want to suggest text for this?
- Is this something we should leave as a future extension that can be
proposed if/when someone cares about it?

I suspect that the default position is "do nothing" and ask Julie= n to move
the draft forward, so if you care please speak up.

Thanks,
Adrian

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
--000000000000f2fe9c059bc29f82-- From nobody Fri Jan 10 08:33:19 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4FF1209DB; Fri, 10 Jan 2020 08:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjiTmBZ-IAtq; Fri, 10 Jan 2020 08:33:13 -0800 (PST) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9E91209CE; Fri, 10 Jan 2020 08:33:00 -0800 (PST) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 00AGWwmv016124; Fri, 10 Jan 2020 16:32:58 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 48DEB2203A; Fri, 10 Jan 2020 16:32:58 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS id 3377622032; Fri, 10 Jan 2020 16:32:58 +0000 (GMT) Received: from LAPTOPK7AS653V (089144208052.atnat0017.highway.a1.net [89.144.208.52]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 00AGWtsD028561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Jan 2020 16:32:56 GMT Reply-To: From: "Adrian Farrel" To: "'Vishnu Pavan Beeram'" Cc: , References: <002101d5c415$6e064680$4a12d380$@olddog.co.uk> In-Reply-To: Date: Fri, 10 Jan 2020 16:32:55 -0000 Organization: Old Dog Consulting Message-ID: <07c501d5c7d3$9d4f3b60$d7edb220$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07C6_01D5C7D3.9D4F3B60" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJY0TFaFNXT/jcA8ggyNpSwKvBeoQD+i/k3ptYKWOA= Content-Language: en-gb X-Originating-IP: 89.144.208.52 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25160.000 X-TM-AS-Result: No--17.844-10.0-31-10 X-imss-scan-details: No--17.844-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25160.000 X-TMASE-Result: 10--17.843700-10.000000 X-TMASE-MatchedRID: 8HTFlOrbAtHxIbpQ8BhdbPVY7U3NX8JgmdndBk1gfyUgUEQTkIWiYq5F Is0KOiYR1Ds81CnrrZqvPAgCvd8b3Mbti5uHJhWfaDCzqDR7DPZaEfFgComdj5l8NETW6pKChYy Lm4ZGzrAMacvE6nqaqQ0KXEcctWDiwZjSXh6GjENLIfps09VJ21dEEmf6TRVBe1OjQ/WyxP6+5F Xa6NpZFMP6JzL63XJ9MXt1vAJFtORLkmJ/TrWyFeXSonB/2H+n+40IoIcVeCJ0rxNYA09+9meGL C9y2ysxpRTsHf1XRjuCdtCXWtHb0/kXSVjp4F0alVHM/F6YkvQ7GNv1BBu35BbozYDXkvVAC2pl MZg3Ot63hwfBkESOXwTewsadbQ+BL/tBTZzO5Q0JAo02KJh2MUjCi9tfhPjQMfASU90zrfBKpIq nO60UFu3hquIdvexs+col1/2+awUsO+kVEfVuQkCMurlkHtfbaPUJ2CQlYPIbgRSVO5fKg8OLWo D10UcckOt2Qii5Or18R1MEbzsBld3aQrftNh+szLo88rvlvYH3+mUqDWUKyFfy7lflgn0UMH1xx 17eFtQoitr6966ULmWtWR8YZtYCeTTsfSq5KdlM0MpnLn+G9PXuWpt5ue19qVMUMZkw+EKBq3pc jNMg+oh3vOK4dONPjVwOiEQlwVNEN0BS8uv90SjX0ag3hagY2LlbtF/6zpC7evdmt3903SMIN1X fvZowaFoY6W5MePuGZb2PgWYjg6upWT4MmSM6HOx1Vder/0tptPVF4L9RM6+WgCcaviqG8+cZJy dmGCneM08+zCv3/qWzJU31bw8B/lVmsZMIkb+eAiCmPx4NwGmRqNBHmBveGtkvK5L7RXGw7M6dy uYKg4VH0dq7wY7u6BetiFDnDZI9zmoVuy5+Ae/miyQPByfq/lVfe46NY6DlGpuOVYCZnA== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Pce] A discussion point for draft-ietf-pce-pcep-flowspec X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 16:33:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_07C6_01D5C7D3.9D4F3B60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks Pavan, It=E2=80=99s good to have this documented clearly. =20 Personally, I am amused/confused that *how* packets are intercepted for = classification (via a routing entry or via a data plane filter) is = important to the specification of this protocol. That is, the protocol = says =E2=80=9Cpackets that match this flowspec MUST be placed on this = LSP/path=E2=80=9D. How an implementation chooses to achieve that is, = IMHO, not material to the on-the-wire behaviour. That is, the packets = will come in and will be placed on the path, and the protocol = instructions to achieve it do not need to tell anyone how to achieve it. =20 This is probably closest to your option 1. That is, an implementation = may choose to implement this however it wants. =20 It would be wrong, also IMHO, to imply that an implementation must = install a data plane filter to handle PCEP flowspecs. That depends (of = course) on how you define a data plane filter. =20 As to draft-ietf-pce-binding-label-sid, I fear I detect mission creep. = What was originally a simple association of a binding SID to a PCEP = message now also has an element of flowspec built in. I wonder whether = that document shouldn=E2=80=99t refer to draft-ietf-pce-flowspec if it = wants to describe what traffic to associate with a path. =20 Like you, I would like to hear more from the working group. =20 Cheers, Adrian =20 From: Vishnu Pavan Beeram =20 Sent: 10 January 2020 05:45 To: Adrian Farrel Cc: pce@ietf.org; draft-ietf-pce-pcep-flowspec@ietf.org Subject: Re: [Pce] A discussion point for draft-ietf-pce-pcep-flowspec =20 Adrian, Hi! =20 Much Thanks for starting this thread! There are multiple implementations = that support user-triggered installation/uninstallation of = destination-IPv4/IPv6 prefixes bound to a TE Path (installation of = routes subject to longest prefix match based forwarding) and it is = important to have this behavior covered in PCEP. =20 I=E2=80=99m listing 3 options that were considered for addressing this = item: 1. Add a new sub-section to Section 8 of = stating that an implementation receiving a FLOWSPEC object that carries = only destination IPv4/IPv6 TLVs may choose to not install any data-plane = filters and instead install routes that are subject to longest prefix = match (LPM) based forwarding. With this option, the controller has no = say in how the network element processes these destination IPV4/IPv6 = TLVs. 2. Introduce a new flag in the FLOWSPEC object to explicitly indicate = that routes subject to LPM based forwarding MUST be installed. When this = flag is set, the FLOWSPEC object MUST carry only destination IPv4/IPv6 = TLVs. 3. Do not use the FLOWSPEC object at all for this; Use the = TE-PATH-BINDING TLV (introduced by draft-ietf-pce-binding-label-sid) = instead. This requires the addition of a couple of new Binding Types = (BT) to indicate destination-IPV4 and destination-IPv6 bindings. This = also requires us to add the ability to encode multiple Path Bindings = (list) in the same message and the ability to remove specific Path = Bindings in a given message.=20 =20 Based on some offline conversations with interested parties, there is a = strong need to have an explicit indication for this type of behavior = (avoid ambiguity with respect to filtering) -- so that makes Option 1 = undesirable. There is also a requirement to carry a mix of install and = uninstall destination prefixes associated with a path in the same = message. The way the FLOWSPEC object is currently defined (the R flag is = specified per FLOWSPEC object and not per TLV; parity with BGP), you = would need one object to carry the install prefixes and one more to = carry the uninstall prefixes. Given all this, there is some consensus = among interested parties to implement this behavior using the = TE-PATH-BINDING TLV. Note that this also means that = draft-ietf-pce-pcep-flowspec can proceed as is. =20 @WG -- Any thoughts? =20 Regards, -Pavan =20 On Sun, Jan 5, 2020 at 4:14 PM Adrian Farrel > wrote: Hi WG, I received a couple of private emails about = draft-ietf-pce-pcep-flowspec. Since they were private, I will try to be circumspect about who they = were from. The sender asked to have a flag attached to a flow specification that indicates that it can be installed as a static route and thus not = subject to a firewall rule so the longest prefix matching can be performed to manipulate route resolution for an LSP. The request also said that traditionally flow-specifications result in firewall rules and those rules operate on packets before longest prefix match. We want to install static routes, the equivalent of installing a prefix for an LSP and if we treat a flowspec as a static route we can = mess things up like rule ordering and so on. The sender suggested that there are currently some draft(s) regarding = this behavior for BGP flowspec as well, but was not able to point me at them. I asked for some clarifications and got back: "What BGP-FS does is install data-plane filters. We handle that by installing RIB entries (that's what BGP carries) into a RIB. Those = entries are transformed into firewall filters. What I am asking for is not currently supported by BGP-flowspec. "What I am asking for is an indication that a flow-specification NOT be transformed into a data-plane filter. In other words, installed as a = normal route where the route is subject to longest prefix match based = forwarding. If you consider how we had to implement the multicast support for PCEP flowspec, it is quite similar. So, in my mind, the 'flag' is an = indicator to do LPM for a destination. Presence of the flag also means that no = other fields can be present in the flowspec, e.g. source address or dest/src = L4 ports, etc." In my view, it should not be too hard to add a flag to the PCEP flow specification. But a couple of questions for the working group and my co-authors: - Does anyone else have interest in this work? - Can anyone else identify the related BGP work? - Does anyone want to suggest text for this? - Is this something we should leave as a future extension that can be proposed if/when someone cares about it? I suspect that the default position is "do nothing" and ask Julien to = move the draft forward, so if you care please speak up. Thanks, Adrian _______________________________________________ Pce mailing list Pce@ietf.org =20 https://www.ietf.org/mailman/listinfo/pce ------=_NextPart_000_07C6_01D5C7D3.9D4F3B60 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Thanks = Pavan,

It=E2=80=99s good to have this = documented clearly.

 

Personally, = I am amused/confused that *how* packets are intercepted for = classification (via a routing entry or via a data plane filter) is = important to the specification of this protocol. That is, the protocol = says =E2=80=9Cpackets that match this flowspec MUST be placed on this = LSP/path=E2=80=9D. How an implementation chooses to achieve that is, = IMHO, not material to the on-the-wire behaviour. That is, the packets = will come in and will be placed on the path, and the protocol = instructions to achieve it do not need to tell anyone how to achieve = it.

 

This is = probably closest to your option 1. That is, an implementation may choose = to implement this however it wants.

 

It would be = wrong, also IMHO, to imply that an implementation must install a data = plane filter to handle PCEP flowspecs. That depends (of course) on how = you define a data plane filter.

 

As to = draft-ietf-pce-binding-label-sid, I fear I detect mission creep. = What was originally a simple association of a binding SID to a PCEP = message now also has an element of flowspec built in. I wonder whether = that document shouldn=E2=80=99t refer to draft-ietf-pce-flowspec if it = wants to describe what traffic to associate with a = path.

 

Like you, I would like to hear more from the working = group.

 

Cheers,

Adrian

 

From: Vishnu Pavan Beeram <vishnupavan@gmail.com> =
Sent: 10 January 2020 05:45
To: Adrian Farrel = <adrian@olddog.co.uk>
Cc: pce@ietf.org; = draft-ietf-pce-pcep-flowspec@ietf.org
Subject: Re: [Pce] A = discussion point for = draft-ietf-pce-pcep-flowspec

 

Adrian, = Hi!

 

Much Thanks for starting this thread! There are = multiple implementations that support user-triggered = installation/uninstallation of destination-IPv4/IPv6 prefixes bound to a = TE Path (installation of routes subject to longest prefix match based = forwarding) and it is important to have this behavior covered in = PCEP.

 

I=E2=80=99m listing 3 options that were considered for = addressing this item:

  1. Add a new sub-section to Section 8 of = <draft-ietf-pce-pcep-flowspec> stating that an implementation = receiving a FLOWSPEC object that carries only destination IPv4/IPv6 TLVs = may choose to not install any data-plane filters and instead install = routes that are subject to longest prefix match (LPM) based forwarding. = With this option, the controller has no say in how the network element = processes these destination IPV4/IPv6 TLVs.
  2. Introduce a new flag in the FLOWSPEC object to = explicitly indicate that routes subject to LPM based forwarding MUST be = installed. When this flag is set, the FLOWSPEC object MUST carry only = destination IPv4/IPv6 TLVs.
  3. Do not use = the FLOWSPEC object at all for this; Use the TE-PATH-BINDING TLV = (introduced by draft-ietf-pce-binding-label-sid) instead. This requires = the addition of a couple of new Binding Types (BT) to indicate = destination-IPV4 and destination-IPv6 bindings. This also requires us to = add the ability to encode multiple Path Bindings (list) in = the same message and the ability to remove specific Path Bindings = in a given message.

 

Based on some offline = conversations with interested parties, there is a strong need to have an = explicit indication for this type of behavior (avoid ambiguity with = respect to filtering) -- so that makes Option 1 undesirable. There is = also a requirement to carry a mix of install and uninstall destination = prefixes associated with a path in the same message. The way the = FLOWSPEC object is currently defined (the R flag is specified per = FLOWSPEC object and not per TLV; parity with BGP), you would need one = object to carry the install prefixes and one more to carry the uninstall = prefixes. Given all this, there is some consensus among interested = parties to implement this behavior using the TE-PATH-BINDING TLV. Note = that this also means that draft-ietf-pce-pcep-flowspec can = proceed as is.

 

@WG -- Any = thoughts?

 

Regards,

-Pavan

 

On = Sun, Jan 5, 2020 at 4:14 PM Adrian Farrel <adrian@olddog.co.uk> = wrote:

Hi = WG,

I received a couple of private emails about = draft-ietf-pce-pcep-flowspec.

Since they were private, I will try = to be circumspect about who they were
from.

The sender asked = to have a flag attached to a flow specification that
indicates that = it can be installed as a static route and thus not subject to
a = firewall rule so the longest prefix matching can be performed = to
manipulate route resolution for an LSP.

The request also = said that traditionally flow-specifications result in
firewall rules = and those rules operate on packets before longest prefix
match. We = want to install static routes, the equivalent of installing a
prefix = for an LSP and if we treat a flowspec as a static route we can = mess
things up like rule ordering and so on.

The sender = suggested that there are currently some draft(s) regarding = this
behavior for BGP flowspec as well, but was not able to point me = at them.

I asked for some clarifications and got = back:

"What BGP-FS does is install data-plane filters.  = We handle that by
installing RIB entries (that's what BGP carries) = into a RIB. Those entries
are transformed into firewall = filters.  What I am asking for is not
currently supported by = BGP-flowspec.

"What I am asking for is an indication that a = flow-specification NOT be
transformed into a data-plane filter.  = In other words, installed as a normal
route where the route is = subject to longest prefix match based forwarding.
If you consider how = we had to implement the multicast support for PCEP
flowspec, it is = quite similar.  So, in my mind, the 'flag' is an indicator
to do = LPM for a destination.  Presence of the flag also means that no = other
fields can be present in the flowspec, e.g. source address or = dest/src L4
ports, etc."

In my view, it should not be too = hard to add a flag to the PCEP flow
specification.

But a = couple of questions for the working group and my co-authors:
- Does = anyone else have interest in this work?
- Can anyone else identify = the related BGP work?
- Does anyone want to suggest text for = this?
- Is this something we should leave as a future extension that = can be
proposed if/when someone cares about it?

I suspect that = the default position is "do nothing" and ask Julien to = move
the draft forward, so if you care please speak = up.

Thanks,
Adrian

_____________________________________= __________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

------=_NextPart_000_07C6_01D5C7D3.9D4F3B60-- From nobody Mon Jan 13 04:23:12 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902E21200F6; Mon, 13 Jan 2020 04:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWgqwvyKh0Hf; Mon, 13 Jan 2020 04:23:07 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D458A1200F3; Mon, 13 Jan 2020 04:23:07 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id 6so4656510pgk.0; Mon, 13 Jan 2020 04:23:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z1QwNRtLY6fmEOFh7mfQ2xyMzzzqrN3L32EYgu7uRq0=; b=rRDFH6tWFzOeNOcC52EgXnSKyrql9JZzJap4G1/LpKRBdJeSqtbVMhSOZannfuWRr3 /AqtogonPClj5MRlEJLcHVN/lUI7CzhjH30mwXn5/8IElN1oBbCGmecMaiUnNT4NRvLS H2UsPx032RCk8PjvgDD1LgotQorG5fJxPFrCRtKLIV+hPgy88WKuhP4wifarOrtVx0OH IkIff914vHlujld1QmuMZeLPlHzTNyj/1JRTctmITbPZ05qmN4ro0Njkwfv1TsXcKXFK hV5wo7hqLRhtl1/dToi70rCQF10zfU2QopN1/QxVq24d/MOSVMQjISV6DCeCJ8TmJWzo dGBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z1QwNRtLY6fmEOFh7mfQ2xyMzzzqrN3L32EYgu7uRq0=; b=PqYiJv6GCZewBZfu7kiDTKApPjosovUMbDfuWBR6VFUjiM37/hrlDnV7Gtn9sLpM9G U0maD0dHbBtI91n/TpmdrChf25WLl2HvN3PnH+aEw92YivtpL8Mp8RwcMPIpjqzLKeuK csVWmDvyUEukrx52bpH82AFKyVlkqsF8ExImPcrc/jF/ZYmvSuvAJXiqzFW371oRcwWS P/xmQQ8jZhHRlGdJtS4KYkQ+KpWtShw1eOzM2q+jQDvY4OVNXb4dBloLkqZaQS78pIse 5WlCuWHzuX2FCGOmqjUJKMYiVUJ43d00UKwCgAAU4QYS3AN7PIl+HzFhnqM5k8V1aPPu 29Jg== X-Gm-Message-State: APjAAAVCopMqLOPmwj5IgRH1COiOHpNUsjF3QhgLRsBf86glCgJV3J4e cy+6zNkq3Nqj9fCIySn0HcTTWJnSigGwOdcuk8GTJqKl X-Google-Smtp-Source: APXvYqxeAHPxhfAfF0VcPZSshwjrPqMRR4EnLNrJF+lbeSa8/zXBWFa70JzByvjGTs00MJW+52j++sIcpjvrJ3T7fBY= X-Received: by 2002:a63:fb05:: with SMTP id o5mr20729660pgh.355.1578918187288; Mon, 13 Jan 2020 04:23:07 -0800 (PST) MIME-Version: 1.0 References: <002101d5c415$6e064680$4a12d380$@olddog.co.uk> <07c501d5c7d3$9d4f3b60$d7edb220$@olddog.co.uk> In-Reply-To: <07c501d5c7d3$9d4f3b60$d7edb220$@olddog.co.uk> From: Vishnu Pavan Beeram Date: Mon, 13 Jan 2020 06:22:56 -0600 Message-ID: To: Adrian Farrel Cc: pce@ietf.org, draft-ietf-pce-pcep-flowspec@ietf.org Content-Type: multipart/alternative; boundary="000000000000aecd46059c0489c8" Archived-At: Subject: Re: [Pce] A discussion point for draft-ietf-pce-pcep-flowspec X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 12:23:11 -0000 --000000000000aecd46059c0489c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Adrian, Hi! Please see inline.. Regards, -Pavan On Fri, Jan 10, 2020 at 10:32 AM Adrian Farrel wrote: > Thanks Pavan, > > It=E2=80=99s good to have this documented clearly. > > > > Personally, I am amused/confused that **how** packets are intercepted for > classification (via a routing entry or via a data plane filter) is > important to the specification of this protocol. That is, the protocol sa= ys > =E2=80=9Cpackets that match this flowspec MUST be placed on this LSP/path= =E2=80=9D. How an > implementation chooses to achieve that is, IMHO, not material to the > on-the-wire behaviour. That is, the packets will come in and will be plac= ed > on the path, and the protocol instructions to achieve it do not need to > tell anyone how to achieve it. > > > > This is probably closest to your option 1. That is, an implementation may > choose to implement this however it wants. > > > > It would be wrong, also IMHO, to imply that an implementation must instal= l > a data plane filter to handle PCEP flowspecs. That depends (of course) on > how you define a data plane filter. > Existing (network element) implementations have config knobs that distinguish between adding a filter rule to steer traffic onto the path of a tunnel and installing a resolver route (LPM based forwarding). And like with most TE-Tunnel/TE-Policy specific config knobs, there seems to be a strong desire to let the Controller push/control these knobs. That is where my options 2 and 3 come in. > > As to draft-ietf-pce-binding-label-sid, I fear I detect mission creep. > What was originally a simple association of a binding SID to a PCEP messa= ge > now also has an element of flowspec built in. I wonder whether that > document shouldn=E2=80=99t refer to draft-ietf-pce-flowspec if it wants t= o describe > what traffic to associate with a path. > I'm not sure about mission creep, but the association of a binding type to a path does (already) describe the type of traffic steered onto the path. It results in the installation of a keyed entry in the forwarding plane with the action of steering the packets matching this entry to the selected path of the policy. Given the precedent, adding a couple of new binding types for destination prefixes seems appropriate. > > Like you, I would like to hear more from the working group. > Yeah, looking forward to see some opinions come in on this. > > > Cheers, > > Adrian > > > > *From:* Vishnu Pavan Beeram > *Sent:* 10 January 2020 05:45 > *To:* Adrian Farrel > *Cc:* pce@ietf.org; draft-ietf-pce-pcep-flowspec@ietf.org > *Subject:* Re: [Pce] A discussion point for draft-ietf-pce-pcep-flowspec > > > > Adrian, Hi! > > > > Much Thanks for starting this thread! There are multiple implementations > that support user-triggered installation/uninstallation of > destination-IPv4/IPv6 prefixes bound to a TE Path (installation of routes > subject to longest prefix match based forwarding) and it is important to > have this behavior covered in PCEP. > > > > I=E2=80=99m listing 3 options that were considered for addressing this it= em: > > 1. Add a new sub-section to Section 8 of > stating that an implementation receivin= g a > FLOWSPEC object that carries only destination IPv4/IPv6 TLVs may choos= e to > not install any data-plane filters and instead install routes that are > subject to longest prefix match (LPM) based forwarding. With this opti= on, > the controller has no say in how the network element processes these > destination IPV4/IPv6 TLVs. > 2. Introduce a new flag in the FLOWSPEC object to explicitly indicate > that routes subject to LPM based forwarding MUST be installed. When th= is > flag is set, the FLOWSPEC object MUST carry only destination IPv4/IPv6= TLVs. > 3. Do not use the FLOWSPEC object at all for this; Use the > TE-PATH-BINDING TLV (introduced by draft-ietf-pce-binding-label-sid) > instead. This requires the addition of a couple of new Binding Types (= BT) > to indicate destination-IPV4 and destination-IPv6 bindings. This also > requires us to add the ability to encode multiple Path Bindings (list) > in the same message and the ability to remove specific Path Bindings i= n a > given message. > > > > Based on some offline conversations with interested parties, there is a > strong need to have an explicit indication for this type of behavior (avo= id > ambiguity with respect to filtering) -- so that makes Option 1 undesirabl= e. > There is also a requirement to carry a mix of install and uninstall > destination prefixes associated with a path in the same message. The way > the FLOWSPEC object is currently defined (the R flag is specified per > FLOWSPEC object and not per TLV; parity with BGP), you would need one > object to carry the install prefixes and one more to carry the uninstall > prefixes. Given all this, there is some consensus among interested partie= s > to implement this behavior using the TE-PATH-BINDING TLV. Note that this > also means that draft-ietf-pce-pcep-flowspec can proceed as is. > > > > @WG -- Any thoughts? > > > > Regards, > > -Pavan > > > > On Sun, Jan 5, 2020 at 4:14 PM Adrian Farrel wrote: > > Hi WG, > > I received a couple of private emails about draft-ietf-pce-pcep-flowspec. > > Since they were private, I will try to be circumspect about who they were > from. > > The sender asked to have a flag attached to a flow specification that > indicates that it can be installed as a static route and thus not subject > to > a firewall rule so the longest prefix matching can be performed to > manipulate route resolution for an LSP. > > The request also said that traditionally flow-specifications result in > firewall rules and those rules operate on packets before longest prefix > match. We want to install static routes, the equivalent of installing a > prefix for an LSP and if we treat a flowspec as a static route we can mes= s > things up like rule ordering and so on. > > The sender suggested that there are currently some draft(s) regarding thi= s > behavior for BGP flowspec as well, but was not able to point me at them. > > I asked for some clarifications and got back: > > "What BGP-FS does is install data-plane filters. We handle that by > installing RIB entries (that's what BGP carries) into a RIB. Those entrie= s > are transformed into firewall filters. What I am asking for is not > currently supported by BGP-flowspec. > > "What I am asking for is an indication that a flow-specification NOT be > transformed into a data-plane filter. In other words, installed as a > normal > route where the route is subject to longest prefix match based forwarding= . > If you consider how we had to implement the multicast support for PCEP > flowspec, it is quite similar. So, in my mind, the 'flag' is an indicato= r > to do LPM for a destination. Presence of the flag also means that no oth= er > fields can be present in the flowspec, e.g. source address or dest/src L4 > ports, etc." > > In my view, it should not be too hard to add a flag to the PCEP flow > specification. > > But a couple of questions for the working group and my co-authors: > - Does anyone else have interest in this work? > - Can anyone else identify the related BGP work? > - Does anyone want to suggest text for this? > - Is this something we should leave as a future extension that can be > proposed if/when someone cares about it? > > I suspect that the default position is "do nothing" and ask Julien to mov= e > the draft forward, so if you care please speak up. > > Thanks, > Adrian > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > --000000000000aecd46059c0489c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Adrian, Hi!

Please see inline..

Regards,
-Pavan
=

On Fri, Jan 10, 2020 at 10:32 AM Adrian Farrel <adrian@olddog.co.uk> wrote:

Thanks = Pavan,

It=E2=80=99s go= od to have this documented clearly.

=C2=A0

P= ersonally, I am amused/confused that *how* packets are intercepted f= or classification (via a routing entry or via a data plane filter) is impor= tant to the specification of this protocol. That is, the protocol says =E2= =80=9Cpackets that match this flowspec MUST be placed on this LSP/path=E2= =80=9D. How an implementation chooses to achieve that is, IMHO, not materia= l to the on-the-wire behaviour. That is, the packets will come in and will = be placed on the path, and the protocol instructions to achieve it do not n= eed to tell anyone how to achieve it.

=C2=A0

This is probably closest to your option 1. That is, an implementation may = choose to implement this however it wants.

=C2=A0

= It would be wrong, also IMHO, to imply that an implementation must in= stall a data plane filter to handle PCEP flowspecs. That depends (of course= ) on how you define a data plane filter.


Existing (network element) implementations have config= knobs that distinguish between adding a filter rule to steer traffic onto = the path of a tunnel and installing a resolver route (LPM based forwarding)= . And like with most TE-Tunnel/TE-Policy specific config knobs, there seems= to be a strong desire to let the Controller push/control these knobs. That= is where my options 2 and 3 come in.

=

=C2=A0

=

As to draft-ietf-pce-binding-label-sid,= I fear I detect mission creep. What was originally a simple association of= a binding SID to a PCEP message now also has an element of flowspec built = in. I wonder whether that document shouldn=E2=80=99t refer to draft-ietf-pc= e-flowspec if it wants to describe what traffic to associate with a path.


I'm not sure about missi= on creep, but the association of a binding type to a path does (already) de= scribe the type of traffic steered onto the path. It results in the install= ation of a keyed entry in the forwarding plane with the action of steering = the packets matching this entry to the selected path of the policy. Given t= he precedent, adding a couple of new binding types for destination prefixes= seems appropriate.

=C2=A0

Like you, I would lik= e to hear more from the working group.

Yeah, looking forward to see some opinions come in on this.
=

=C2=A0

Cheers,

Adrian

=C2=A0=

From:<= span lang=3D"EN-US"> Vishnu Pavan Beeram <vishnupavan@gmail.com>
<= b>Sent: 10 January 2020 05:45
To: Adrian Farrel <adrian@olddog.co.uk&g= t;
Cc: pce@ietf= .org; draft-ietf-pce-pcep-flowspec@ietf.org
Subject: Re= : [Pce] A discussion point for draft-ietf-pce-pcep-flowspec

=C2=A0

Adrian, Hi!

=C2=A0=

Much Thanks for starting this thread! The= re are multiple implementations that support user-triggered installation/un= installation of destination-IPv4/IPv6 prefixes bound to a TE Path (installa= tion of routes subject to longest prefix match based forwarding) and it is = important to have this behavior covered in PCEP.

=C2=A0

I=E2=80=99m l= isting 3 options that were considered for addressing this item:

  1. Add a new sub-sec= tion to Section 8 of <draft-ietf-pce-pcep-flowspec> stating that an i= mplementation receiving a FLOWSPEC object that carries only destination IPv= 4/IPv6 TLVs may choose to not install any data-plane filters and instead in= stall routes that are subject to longest prefix match (LPM) based forwardin= g. With this option, the controller has no say in how the network element p= rocesses these destination IPV4/IPv6 TLVs.
  2. Introduce a new= flag in the FLOWSPEC object to explicitly indicate that routes subject to = LPM based forwarding MUST be installed. When this flag is set, the FLOWSPEC= object MUST carry only destination IPv4/IPv6 TLVs.
  3. Do not use the FLOWSPEC object at al= l for this; Use the TE-PATH-BINDING TLV (introduced by draft-ietf-pce-bindi= ng-label-sid) instead. This requires the addition of a couple of new Bindin= g Types (BT) to indicate destination-IPV4 and destination-IPv6 bindings. Th= is also requires us to add the ability to encode multiple Path=C2=A0= Bindings (list) in the same message and the ability to remove specific Path= =C2=A0Bindings in a given message.

= =C2=A0

Based on some offline conversa= tions with interested parties, there is a strong need to have an explicit i= ndication for this type of behavior (avoid ambiguity with respect to filter= ing) -- so that makes Option 1 undesirable. There is also a requirement to = carry a mix of install and uninstall destination prefixes associated with a= path in the same message. The way the FLOWSPEC object is currently defined= (the R flag is specified per FLOWSPEC object and not per TLV; parity with = BGP), you would need one object to carry the install prefixes and one more = to carry the uninstall prefixes. Given all this, there is some consensus am= ong interested parties to implement this behavior using the TE-PATH-BINDING= TLV. Note that this also means that draft-ietf-pce-pcep-flowspec ca= n proceed as is.

=C2=A0

@WG -- Any thoughts?

=C2=A0

Regards,

-Pavan=

=C2=A0

On Sun, Jan 5, 2020 at 4:14 PM Adrian Farrel <= adrian@olddog.co.u= k> wrote:

Hi WG,

I= received a couple of private emails about draft-ietf-pce-pcep-flowspec.
Since they were private, I will try to be circumspect about who they w= ere
from.

The sender asked to have a flag attached to a flow spec= ification that
indicates that it can be installed as a static route and = thus not subject to
a firewall rule so the longest prefix matching can b= e performed to
manipulate route resolution for an LSP.

The reques= t also said that traditionally flow-specifications result in
firewall ru= les and those rules operate on packets before longest prefix
match. We w= ant to install static routes, the equivalent of installing a
prefix for = an LSP and if we treat a flowspec as a static route we can mess
things u= p like rule ordering and so on.

The sender suggested that there are = currently some draft(s) regarding this
behavior for BGP flowspec as well= , but was not able to point me at them.

I asked for some clarificati= ons and got back:

"What BGP-FS does is install data-plane filte= rs.=C2=A0 We handle that by
installing RIB entries (that's what BGP = carries) into a RIB. Those entries
are transformed into firewall filters= .=C2=A0 What I am asking for is not
currently supported by BGP-flowspec.=

"What I am asking for is an indication that a flow-specificati= on NOT be
transformed into a data-plane filter.=C2=A0 In other words, in= stalled as a normal
route where the route is subject to longest prefix m= atch based forwarding.
If you consider how we had to implement the multi= cast support for PCEP
flowspec, it is quite similar.=C2=A0 So, in my min= d, the 'flag' is an indicator
to do LPM for a destination.=C2=A0= Presence of the flag also means that no other
fields can be present in = the flowspec, e.g. source address or dest/src L4
ports, etc."
In my view, it should not be too hard to add a flag to the PCEP flow
s= pecification.

But a couple of questions for the working group and my= co-authors:
- Does anyone else have interest in this work?
- Can any= one else identify the related BGP work?
- Does anyone want to suggest te= xt for this?
- Is this something we should leave as a future extension t= hat can be
proposed if/when someone cares about it?

I suspect tha= t the default position is "do nothing" and ask Julien to move
= the draft forward, so if you care please speak up.

Thanks,
Adrian=

_______________________________________________
Pce mailing list=
Pce@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/pce" target=3D"_blank">http= s://www.ietf.org/mailman/listinfo/pce

--000000000000aecd46059c0489c8-- From nobody Tue Jan 14 09:10:56 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23884120917; Tue, 14 Jan 2020 08:00:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: Cc: Deborah Brungard , Julien Meuric , Multiprotocol Label Switching Discussion List , Dhruv Dhody , Pseudowire And LDP-enabled Services Discussion List , Andrew Malis , Common Control and Measurement Plane Discussion List , scott.mansfield@ericsson.com, Traffic Engineering Architecture and Signaling Discussion List , Martin Vigoureux , Scott Mansfield , Fatai Zhang , Nicolai Leymann , John Drake , Loa Andersson , Daniele Ceccarelli , Vishnu Beeram , Stewart Bryant , Path Computation Element Discussion List , Lou Berger , Tarek Saad , itu-t-liaison@iab.org, Alvaro Retana X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157901761713.7927.6115600311681411956.idtracker@ietfa.amsl.com> Date: Tue, 14 Jan 2020 08:00:17 -0800 Archived-At: X-Mailman-Approved-At: Tue, 14 Jan 2020 09:10:54 -0800 Subject: [Pce] New Liaison Statement, "Reply to LS on OTNT Standardization Work Plan" X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2020 16:00:17 -0000 Title: Reply to LS on OTNT Standardization Work Plan Submission Date: 2020-01-14 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1669/ From: Scott Mansfield To: hiroshi.ota@itu.int Cc: Deborah Brungard ,Julien Meuric ,Multiprotocol Label Switching Discussion List ,Dhruv Dhody ,Pseudowire And LDP-enabled Services Discussion List ,Andrew Malis ,Common Control and Measurement Plane Discussion List ,Traffic Engineering Architecture and Signaling Discussion List ,Martin Vigoureux ,Scott Mansfield ,Fatai Zhang ,Nicolai Leymann ,John Drake ,Loa Andersson ,Daniele Ceccarelli ,Vishnu Beeram ,Stewart Bryant ,Path Computation Element Discussion List ,Lou Berger ,Tarek Saad ,itu-t-liaison@iab.org,Alvaro Retana ,itu-t-liaison@iab.org Response Contacts: scott.mansfield@ericsson.com Technical Contacts: scott.mansfield@ericsson.com Purpose: For information Body: Thank you for your continued interest in the work of the IETF related to OTNT standardization. Updates to the OTNT Standardization work plan: IETF Working Group Structure Update: + The l2vpn working group and pwe3 working group have completed and the new working group is pals (Pseudowire And LDP-enabled Services). + In the OTNT document, please delete l2vpn and pwe3 and replace them with pals. Updates to Internet Drafts: + Delete https://tools.ietf.org/html/draft-ietf-pce-remote-initiated-gmpls-lsp because it has been merged with https://tools.ietf.org/html/draft-ietf-pce-pcep-stateful-pce-gmpls which is already on the list. New RFCs: + RFC8577 * April 2019 * Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane * https://tools.ietf.org/html/rfc8577 + RFC8595 * June 2019 * An MPLS-Based Forwarding Plane for Service Function Chaining * https://tools.ietf.org/html/rfc8595 + RFC8596 * June 2019 * MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH) * https://tools.ietf.org/html/rfc8596 + RFC8611 * June 2019 * Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces * https://tools.ietf.org/html/rfc8611 + RFC8625 * August 2019 * Ethernet Traffic Parameters with Availability Information * https://tools.ietf.org/html/rfc8625 + RFC8632 * September 2019 * A YANG Data Model for Alarm Management * https://tools.ietf.org/html/rfc8632 The list of upcoming IETF meetings can be found on the IETF website at https://www.ietf.org/how/meetings/upcoming/ Thank You, Daniele Ceccarelli (CCAMP Chair), Fatai Zhang (CCAMP Chair), Dhruv Dhody (PCE Chair), Julien Meuric (PCE Chair), Vishnu Beeram (TEAS Chair), Lou Berger (TEAS Chair), Loa Andersson (MPLS Chair), Nicolai Leymann (MPLS Chair), Tarek Saad (MPLS Chair), Andrew Malis (PALS Chair), Stewart Bryant (PALS Chair), and Scott Mansfield (IETF's ITU-T Liaison) Attachments: No document has been attached From nobody Wed Jan 15 21:18:48 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D8D12086B; Wed, 15 Jan 2020 21:18:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan via Datatracker To: "The IESG" Cc: draft-ietf-pce-association-diversity@ietf.org, Julien Meuric , pce-chairs@ietf.org, julien.meuric@orange.com, pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Suresh Krishnan Message-ID: <157915192693.22436.14462109283651969297.idtracker@ietfa.amsl.com> Date: Wed, 15 Jan 2020 21:18:46 -0800 Archived-At: Subject: [Pce] Suresh Krishnan's No Objection on draft-ietf-pce-association-diversity-13: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 05:18:47 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-pce-association-diversity-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-association-diversity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS and COMMENT points. From nobody Thu Jan 16 13:38:08 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 789B012004A; Thu, 16 Jan 2020 13:38:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <157921068640.26224.5001836844375816945@ietfa.amsl.com> Date: Thu, 16 Jan 2020 13:38:06 -0800 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-lsp-scheduling-12.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 21:38:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP Extensions for LSP scheduling with stateful PCE Authors : Huaimo Chen Yan Zhuang Qin Wu Daniele Ceccarelli Filename : draft-ietf-pce-stateful-pce-lsp-scheduling-12.txt Pages : 25 Date : 2020-01-16 Abstract: This document defines a set of extensions needed to the stateful Path Computation Element (PCE) communication Protocol (PCEP), so as to enable Labeled Switched Path (LSP) scheduling for path computation and LSP setup/deletion based on the actual network resource usage and the duration of a traffic service in a centralized network environment as stated in RFC 8413. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-scheduling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-lsp-scheduling-12 https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-pce-lsp-scheduling-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-lsp-scheduling-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 17 01:40:46 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AFD120236 for ; Fri, 17 Jan 2020 01:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.289 X-Spam-Level: X-Spam-Status: No, score=-0.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Bm6H6RFM4GY for ; Fri, 17 Jan 2020 01:40:41 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD331207FC for ; Fri, 17 Jan 2020 01:40:40 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 47zbdz3TrGz4whQ for ; Fri, 17 Jan 2020 10:40:39 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.104]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 47zbdz2pVLzDq7g for ; Fri, 17 Jan 2020 10:40:39 +0100 (CET) Received: from [10.193.71.21] (10.114.13.245) by OPEXCAUBM5F.corporate.adroot.infra.ftgroup (10.114.13.104) with Microsoft SMTP Server (TLS) id 14.3.468.0; Fri, 17 Jan 2020 10:40:39 +0100 References: <157258943410.30400.5704097028384419347@ietfa.amsl.com> To: "pce@ietf.org" From: Organization: Orange X-Forwarded-Message-Id: <157258943410.30400.5704097028384419347@ietfa.amsl.com> Message-ID: <31171_1579254039_5E218117_31171_145_1_28179a8d-27ad-0ace-8726-aa81ed8930b9@orange.com> Date: Fri, 17 Jan 2020 10:40:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <157258943410.30400.5704097028384419347@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [10.114.13.245] Archived-At: Subject: [Pce] Fwd: [Lsr] I-D Action: draft-ietf-lsr-pce-discovery-security-support-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 09:40:45 -0000 Hi all, The I-D defining the IGP extensions to discover the PCEP security capabilities was presented to the PCE WG during IETF 105. Please be aware that it is progressing as an LSR WG document (https://mailarchive.ietf.org/arch/msg/lsr/1CqjNObC5hoZaKDMrVTGwO0Axd0) and note particularly the agreed wording of section 4: "    The introduction of the additional sub-TLVs should be viewed as an    exception to the [RFC5088][RFC5089] policy justified by the need to    know the new information prior to establishing a PCEP session.  The    restrictions defined in [RFC5089][RFC5089] should still be considered    to be in place. " Cheers, Dhruv & Julien -------- Forwarded Message -------- Date: Thu, 31 Oct 2019 23:23:54 -0700 From: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : IGP extension for PCEP security capability support in the PCE discovery Authors : Diego R. Lopez Qin Wu Dhruv Dhody Michael Wang Daniel King Filename : draft-ietf-lsr-pce-discovery-security-support-03.txt Pages : 9 Date : 2019-10-31 Abstract: When a Path Computation Element (PCE) is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating in IGP, its presence and path computation capabilities can be advertised using IGP flooding. The IGP extensions for PCE discovery (RFC 5088 and RFC 5089) define a method to advertise path computation capabilities using IGP flooding for OSPF and IS-IS respectively. However these specifications lack a method to advertise PCEP security (e.g., Transport Layer Security(TLS), TCP Authentication Option (TCP-AO)) support capability. This document proposes new capability flag bits for PCE-CAP-FLAGS sub-TLV that can be announced as attribute in the IGP advertisement to distribute PCEP security support information. In addition, this document updates RFC 5088 and RFC 5089 to allow advertisement of Key ID or Key Chain Name Sub-TLV to support TCP AO security capability. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsr-pce-discovery-security-support-03 https://datatracker.ietf.org/doc/html/draft-ietf-lsr-pce-discovery-security-support-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-support-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/ _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Fri Jan 17 02:12:49 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCF31207FC for ; Fri, 17 Jan 2020 02:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roovwsSsJ1Ys for ; Fri, 17 Jan 2020 02:12:42 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AF9A120047 for ; Fri, 17 Jan 2020 02:12:42 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 47zcLw0GJwzFq8l for ; Fri, 17 Jan 2020 11:12:40 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.104]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 47zcLv6b3kz5vMq for ; Fri, 17 Jan 2020 11:12:39 +0100 (CET) Received: from [10.193.71.21] (10.114.13.247) by OPEXCAUBM5F.corporate.adroot.infra.ftgroup (10.114.13.104) with Microsoft SMTP Server (TLS) id 14.3.468.0; Fri, 17 Jan 2020 11:12:39 +0100 From: Organization: Orange To: "pce@ietf.org" Message-ID: Date: Fri, 17 Jan 2020 11:12:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070801020101040900020902" X-Originating-IP: [10.114.13.247] Archived-At: Subject: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 10:12:48 -0000 --------------ms070801020101040900020902 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi all, It is time to share your thoughts about draft-li-pce-sr-bidir-path-06. Do you believe the I-D is a right foundation for a PCE WG item? Please use the PCE mailing list to express your comments, support or disagreement, including applicable rationale, especially for the latter. Thanks, Dhruv & Julien --------------ms070801020101040900020902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC EmowggTeMIIDxqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMGoxCzAJBgNVBAYTAkZSMRowGAYD VQQKDBFGcmFuY2UgVGVsZWNvbSBTQTEXMBUGA1UECwwOMDAwMiAzODAxMjk4NjYxJjAkBgNV BAMMHUdyb3VwZSBGcmFuY2UgVGVsZWNvbSBSb290IENBMB4XDTA1MTExNzExMDkzOVoXDTI1 MTExNzExMDkzOVowgZYxCzAJBgNVBAYTAkZSMRowGAYDVQQKDBFGcmFuY2UgVGVsZWNvbSBT QTEkMCIGA1UECwwbV2VzdGVybkVVIE1pZGRsZUVhc3QgQWZyaWNhMRcwFQYDVQQLDA4wMDAy IDM4MDEyOTg2NjEsMCoGA1UEAwwjR3JvdXBlIEZyYW5jZSBUZWxlY29tIEludGVybmFsIENB IDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCw8ytv/3/3nS8Xkfrfv3lWqny4 Gd1V8eVOT7B0WxfJMqfWPbu0aoc4WScRhqIhAH61Gmfa6f3AVq+o3PptjJ459kMp/ACaeRp8 DFzW7iNFm/Qfdk81V9dVLXHsbYwWU373j/ksx1Smmk3vsq4fWapeAOLfds70KO4RWP/YVSmO rAFVMiqV4l9f6a+G8Lr2tOZkWaX+3vb3HE6mDG3la3Y6VDpVpioSrz61KPb8pLyOg7TuhhIx OKTNNefEcDwFKx9zfVJax+PHj6zGbFzdGEMWexwGSi3SXkgAV6/CJNtCHHXE2OprWc30JiCY 18GkvPrRgO1XBSqx0xDIam+WpEh/AgMBAAGjggFgMIIBXDAPBgNVHRMBAf8EBTADAQH/MA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUNhwzZ9MTXPpbn+qLukRmdEbxd3gwdAYDVR0jBG0w a4AUGpJTyM8zG7bypWB94q8kEkGwmmChUIFOQ049R3JvdXBlIEZyYW5jZSBUZWxlY29tIFJv b3QgQ0EsIE9VPTAwMDIgMzgwMTI5ODY2LCBPPUZyYW5jZSBUZWxlY29tIFNBLCBDPUZSggEA MIGOBgNVHR8EgYYwgYMwQ6BBoD+GPWh0dHA6Ly9pZ2NnZnQtcmNhLWh0dHAuc2kuZnJhbmNl dGVsZWNvbS5mci9jcmwvaWdjZ2Z0X3JjYS5jcmwwPKA6oDiGNmh0dHA6Ly9pZ2NnZnQtcmNh LmZyYW5jZXRlbGVjb20uY29tL2NybC9pZ2NnZnRfcmNhLmNybDATBgNVHSAEDDAKMAgGBiqB egEQDDANBgkqhkiG9w0BAQUFAAOCAQEAlt994iqOFDZH/wQfDU6EQ1W1B/xs/k3xwBuBZgi3 NRWvvb8KhfoOVOyeuoO1r4072jo/AFDphvixN8EZiRp+luqZXQEXEaHrZjwRydCuUDwjPQkw A/DU5NzWn0FrKWRIstQa/MBcN9xniazs41Br3oNzlkUbAyuP2s3GRi5uFp7VV5Y5dU8lqdoL nE/TuBV0LFdre0WOdM7CoWVqNlreb7/zmuK2/zfLIaq2QIcWIOulqiIW1xxFWxc0JZi8p7qV zvysS0+8wevgoefks3PHoUMEaIHCpoSOC14JSkKCVuUMPBvu+ftPasJ+NQz1jUbb0kjUkpGn q33GgLPLSvsK5TCCBsAwggWooAMCAQICEhEhrKTzJoGqMVywoqjNXFnwQTANBgkqhkiG9w0B AQUFADCBljELMAkGA1UEBhMCRlIxGjAYBgNVBAoMEUZyYW5jZSBUZWxlY29tIFNBMSQwIgYD VQQLDBtXZXN0ZXJuRVUgTWlkZGxlRWFzdCBBZnJpY2ExFzAVBgNVBAsMDjAwMDIgMzgwMTI5 ODY2MSwwKgYDVQQDDCNHcm91cGUgRnJhbmNlIFRlbGVjb20gSW50ZXJuYWwgQ0EgMTAeFw0x NzAyMjgwOTQyMDhaFw0yMTAyMjgwOTQyMDhaMGoxCzAJBgNVBAYTAkZSMRowGAYDVQQKExFG cmFuY2UgVGVsZWNvbSBTQTEWMBQGA1UEAwwNTWV1cmljIEp1bGllbjEnMCUGCSqGSIb3DQEJ AQwYanVsaWVuLm1ldXJpY0BvcmFuZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA0Pfhby8TRScxVqtTKug3CKgJW1ub3Y7JydhngY8GOXTXy7mUt4aA0V2JsooyqF3+ nO1xcl3D1RZ+l04fRNHCh/CUHhamoNykCFRNoIM/DuzT7NE5h94UR/3RRgZ2qbZoIn5KYIBj bVMacnZnB/qB9DUH61ecMTzrOG0ePtvABWcrhhOZ2S0MvPJkPtAAlL7qvTe9gJwZkBtEuZ0q rJ0D3OXl5ayV7eP9FuRJ/0jf9FdxnmY0Aagm6+r5vsj9dhU9Gf5cA+mh+L7zrCIpTG2GVLLd KaSORJ1cZ+LeZlgpK+hKJ4ho+J/Usqu9Ak8ngAeOgJqTjxRvOimdZZfJ+2E/GQIDAQABo4ID MTCCAy0wDgYDVR0PAQH/BAQDAgbAMBMGA1UdJQQMMAoGCCsGAQUFBwMEMCMGA1UdEQQcMBqB GGp1bGllbi5tZXVyaWNAb3JhbmdlLmNvbTCCAiEGA1UdHwSCAhgwggIUMIHooIHloIHihoHf bGRhcDovLy9jbj1Hcm91cGUlMjBGcmFuY2UlMjBUZWxlY29tJTIwSW50ZXJuYWwlMjBDQSUy MDEsY249aWdjZ2Z0aSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vy dmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1hZCxEQz1mcmFuY2V0ZWxlY29tLERDPWZyP2Nl cnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RjbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludDCBqaCBpqCBo4aBoGxkYXA6Ly9pZ2NnZnRpLWNhMS1sZGFwLnNpLmZyYW5jZXRl bGVjb20uZnIvb3U9aWdjZ2Z0aV9jYTEsb3U9Q0Esb3U9Q1JMRFAsb3U9QUNfT04sb3U9SUdD R3JvdXBlLG89RnJhbmNlVGVsZWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/ b2JqZWN0Y2xhc3M9cGtpQ2EwNKAyoDCGLmh0dHA6Ly9wa2ktY3JsLml0bi5mdGdyb3VwL2Ny bC9pZ2NnZnRpX2NhMS5jcmwwRaBDoEGGP2h0dHA6Ly9pZ2NnZnRpLWNhMS1odHRwLnNpLmZy YW5jZXRlbGVjb20uZnIvY3JsL2lnY2dmdGlfY2ExLmNybDA+BgNVHSAENzA1MDMGCCqBegEQ DAIDMCcwJQYIKwYBBQUHAgEWGWh0dHA6Ly9wa2ktb3JhbmdlLmNvbS9jcHMwPAYIKwYBBQUH AQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpLW9jc3AuaXRuLmZ0Z3JvdXAvb2NzcDAd BgNVHQ4EFgQUEqE2gJM6hxLi6AlLKQ8kT4r1AlUwHwYDVR0jBBgwFoAUNhwzZ9MTXPpbn+qL ukRmdEbxd3gwDQYJKoZIhvcNAQEFBQADggEBAGxsRCzFlIhen5KnTgZDP6e5jd+ff1MoW3jq wiqxg8v33FldytRqsR5ydg4G5s+mdYhtViuuqm+vOo0F+8oSudj2M70zFIzQR2jMvR8P1oFF 2n+aQlZDW/JY5KqsxbUaR1w5QFE4LCj77OlvTTtaHXn6tZINQqD2rE/28S91ShC4H6WfsTve y2CCLvuYzwUkQ/tPC23rWYxO/hZPkOT/MbgijzIFh4Ys8ENfYNTwkrNSj0LmmJREXIXq50UV EpnsI2v5hE8jXkXlWvT6eXJ7RkocfIjwENvOMvA5/WxE9tvpVCSGq+c5YMWEfyT6o+V2LtTG dtJ3dWNCmsmAgBWXnaswggbAMIIFqKADAgECAhIRIb+AKeqA4nD4aGytIumMzn8wDQYJKoZI hvcNAQEFBQAwgZYxCzAJBgNVBAYTAkZSMRowGAYDVQQKDBFGcmFuY2UgVGVsZWNvbSBTQTEk MCIGA1UECwwbV2VzdGVybkVVIE1pZGRsZUVhc3QgQWZyaWNhMRcwFQYDVQQLDA4wMDAyIDM4 MDEyOTg2NjEsMCoGA1UEAwwjR3JvdXBlIEZyYW5jZSBUZWxlY29tIEludGVybmFsIENBIDEw HhcNMTcwMjI4MDk0MjIxWhcNMjEwMjI4MDk0MjIxWjBqMQswCQYDVQQGEwJGUjEaMBgGA1UE ChMRRnJhbmNlIFRlbGVjb20gU0ExFjAUBgNVBAMMDU1ldXJpYyBKdWxpZW4xJzAlBgkqhkiG 9w0BCQEMGGp1bGllbi5tZXVyaWNAb3JhbmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAMYlaLPYjHfuVjqtO9apWcAd2PIK1MyO7sDYhYw0itPsnsSzsMUa+o7Xjwr/ 9JHcyYEehz2uqzpT0L3bFC8ROTGF3l9sZDPGpUlGeYEFCpNxT2Eg5ZIizYHd5feghGDgbnm0 3UaNldIpi5gtuKSSUHJwLgzZwMykwOdGBkl9dJvj2mccxIlViUATimvjuOj8TES9zrNWuWU7 d1LM9SUrKngkMIA5s801vT4FlvpL/ER7Yt6idZ8rGPXsMdFOhiV3AzLBl1ypaVrQ+OGum/sh c56fMCppmz5okaiGJ2DC9MRR0l4e6ZNrg+nKfm7IhIrCn7wED1TJAfuQfz3YYXKEwO8CAwEA AaOCAzEwggMtMA4GA1UdDwEB/wQEAwIFIDATBgNVHSUEDDAKBggrBgEFBQcDBDAjBgNVHREE HDAagRhqdWxpZW4ubWV1cmljQG9yYW5nZS5jb20wggIhBgNVHR8EggIYMIICFDCB6KCB5aCB 4oaB32xkYXA6Ly8vY249R3JvdXBlJTIwRnJhbmNlJTIwVGVsZWNvbSUyMEludGVybmFsJTIw Q0ElMjAxLGNuPWlnY2dmdGksQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9ZnJhbmNldGVsZWNvbSxEQz1m cj9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JMRGlzdHJp YnV0aW9uUG9pbnQwgamggaaggaOGgaBsZGFwOi8vaWdjZ2Z0aS1jYTEtbGRhcC5zaS5mcmFu Y2V0ZWxlY29tLmZyL291PWlnY2dmdGlfY2ExLG91PUNBLG91PUNSTERQLG91PUFDX09OLG91 PUlHQ0dyb3VwZSxvPUZyYW5jZVRlbGVjb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9i YXNlP29iamVjdGNsYXNzPXBraUNhMDSgMqAwhi5odHRwOi8vcGtpLWNybC5pdG4uZnRncm91 cC9jcmwvaWdjZ2Z0aV9jYTEuY3JsMEWgQ6BBhj9odHRwOi8vaWdjZ2Z0aS1jYTEtaHR0cC5z aS5mcmFuY2V0ZWxlY29tLmZyL2NybC9pZ2NnZnRpX2NhMS5jcmwwPgYDVR0gBDcwNTAzBggq gXoBEAwCAjAnMCUGCCsGAQUFBwIBFhlodHRwOi8vcGtpLW9yYW5nZS5jb20vY3BzMDwGCCsG AQUFBwEBBDAwLjAsBggrBgEFBQcwAYYgaHR0cDovL3BraS1vY3NwLml0bi5mdGdyb3VwL29j c3AwHQYDVR0OBBYEFJpO/hkvlNNchTsRMqcXbFKjr7BjMB8GA1UdIwQYMBaAFDYcM2fTE1z6 W5/qi7pEZnRG8Xd4MA0GCSqGSIb3DQEBBQUAA4IBAQCTgsPIg7wni+YEn7NuxicptWVyoYjn XO9UfYTb4t6M1nizQPrL1ctPCqooEAxUhiH+i8YlnUkG5CHMatTwLtnZJvzGqHkY7q/Ctbki DOqfhaM4b9by+CJp9B5GTKeUzCKAt2Fk0TKqlwbGdKiUfPL9AC58UYOKqjlMUPf6suxqA1fM FyCUBu991kEdwSF7iXbSC/QP2EVsr5Yo1WU9856hAD87Lv/hFp5FjVYKFn9iMQvu325XYLvy EhveODX1HsLj0ohm3/GfPYwyIZpG690uSROq7X8+8WUdX/oplOoaxpEkH5tJO51VAQybQPgj daMD+h/Latx+6W9Dz6oPAxw0MYIEODCCBDQCAQEwga0wgZYxCzAJBgNVBAYTAkZSMRowGAYD VQQKDBFGcmFuY2UgVGVsZWNvbSBTQTEkMCIGA1UECwwbV2VzdGVybkVVIE1pZGRsZUVhc3Qg QWZyaWNhMRcwFQYDVQQLDA4wMDAyIDM4MDEyOTg2NjEsMCoGA1UEAwwjR3JvdXBlIEZyYW5j ZSBUZWxlY29tIEludGVybmFsIENBIDECEhEhrKTzJoGqMVywoqjNXFnwQTANBglghkgBZQME AgEFAKCCAlswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAw MTE3MTAxMjM2WjAvBgkqhkiG9w0BCQQxIgQgVeFwWrkwZ4qhyr20vuq3GxImAOkZgvSs3Ia9 mzZcbk4wbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGwMIGtMIGWMQswCQYDVQQGEwJGUjEaMBgGA1UECgwR RnJhbmNlIFRlbGVjb20gU0ExJDAiBgNVBAsMG1dlc3Rlcm5FVSBNaWRkbGVFYXN0IEFmcmlj YTEXMBUGA1UECwwOMDAwMiAzODAxMjk4NjYxLDAqBgNVBAMMI0dyb3VwZSBGcmFuY2UgVGVs ZWNvbSBJbnRlcm5hbCBDQSAxAhIRIb+AKeqA4nD4aGytIumMzn8wgcAGCyqGSIb3DQEJEAIL MYGwoIGtMIGWMQswCQYDVQQGEwJGUjEaMBgGA1UECgwRRnJhbmNlIFRlbGVjb20gU0ExJDAi BgNVBAsMG1dlc3Rlcm5FVSBNaWRkbGVFYXN0IEFmcmljYTEXMBUGA1UECwwOMDAwMiAzODAx Mjk4NjYxLDAqBgNVBAMMI0dyb3VwZSBGcmFuY2UgVGVsZWNvbSBJbnRlcm5hbCBDQSAxAhIR Ib+AKeqA4nD4aGytIumMzn8wDQYJKoZIhvcNAQEBBQAEggEAa1hCqi9VWFp1WeOiX1QRl3S7 iG3MwlfJfhHTTTwwmTTrELAfvJqsWxmDNLJ1unX3mlhaRWqqKKemc7+sXy9dR137xoYUn4aP IDeiU81AoXmzBmvs5BCMWB6Pwe0+rNnvlKfGhMGjvgZnkYSBjsS0KZ/axtE+wz+yZJz5EyfU ifFHnRpXtwSdboCO9qTnRpgn/DEmBM55VH6jQMT4qDorvLrMr1n2QLgOVo4KM6zygDL25hGG KYJ/+yE4+fQ8BbR8yeoM5sCHIeJ0J6b+Vu5OrXpcYhzaLi1vxGNGAHQU7amSW2bQq4xXh7fB WTtO1WeV5zqGHh6LKy93fG6m/XrOqwAAAAAAAA== --------------ms070801020101040900020902-- From nobody Fri Jan 17 02:17:04 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A64C12084A; Fri, 17 Jan 2020 02:17:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157925622149.20230.1212156962836344152.idtracker@ietfa.amsl.com> Date: Fri, 17 Jan 2020 02:17:01 -0800 Archived-At: Subject: [Pce] The PCE WG has placed draft-li-pce-sr-bidir-path in state "Call For Adoption By WG Issued" X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 10:17:01 -0000 The PCE WG has placed draft-li-pce-sr-bidir-path in state Call For Adoption By WG Issued (entered by Julien Meuric) The document is available at https://datatracker.ietf.org/doc/draft-li-pce-sr-bidir-path/ From nobody Fri Jan 17 10:31:56 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D95120043 for ; Fri, 17 Jan 2020 10:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AhvoPeBmWPV for ; Fri, 17 Jan 2020 10:31:53 -0800 (PST) Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2BC0120025 for ; Fri, 17 Jan 2020 10:31:53 -0800 (PST) Received: by mail-vk1-xa35.google.com with SMTP id i4so6916868vkc.3 for ; Fri, 17 Jan 2020 10:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=kcnMbNjvud2JWWuWN/9rrX+V5fLZaR8NuE5Nn9vQg9Y=; b=AjTkkQlLrD03NUk2cklTm/Ap1SwErntR3FyBzc/Ol/B8aruAXj0nazy1m9jS/7W2rN hlx5RCWOIWI2dVL3AdfLaCKQtMhU/X/55wG+XanWTBCwbHHpebtAExWvM/Nmkx8IFe6P wV3ZueAYfBg05bUWur4Yas+Z5vs9W1LumF/R4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=kcnMbNjvud2JWWuWN/9rrX+V5fLZaR8NuE5Nn9vQg9Y=; b=D8fYfT6IEH3OUfScJpD18OIi7OfxDvJQBrDuXNJYTfCwyNRSq8nUoLlmk/H6el8ZHY vyDA3blys/YiZMKujHsTRHLYV+8JQhNc1kX3YjMKfvox1TbUjBxESevaHy4lTVplsghG ZUXCoFcmhfJkp/PcV534TSAjOqHUDm3pCfEu84ijGgE4gN/N/qIOeynNyXIpU4Dy0JSr j4PaFcuv83SNxmja1zNAO8kVcT+T2RgCGsxpE/WTH/rShL2tA0uO8Tg1Ww4EzKzWsv5m wdZqQQEwJIYwTGVdD8gtMMjwiVIzI0geQN2gFEBBg/wD5T9bZGx4l75jEazucbQDakC/ 9sOg== X-Gm-Message-State: APjAAAXsqMN49p141WrE+Tet2b1ZEFcp9beciBU2fJg7kqUyQM2F+Kec 4KVJkTXuZ1T2/PYnCGdaLg8Kj4bQOSfB4FyXnUIqow== X-Google-Smtp-Source: APXvYqxqm6A1ScNYfeqEijQ2l3Jz7lAwpeBHiCywJNlQ9szaIhoV/w+yj8mz5szl1dliQRapnH3eY1yJGWxL+Yfmaw8= X-Received: by 2002:a1f:fccb:: with SMTP id a194mr25054242vki.92.1579285912678; Fri, 17 Jan 2020 10:31:52 -0800 (PST) MIME-Version: 1.0 From: Hariharan Ananthakrishnan Date: Fri, 17 Jan 2020 10:31:35 -0800 Message-ID: To: chengli13@huawei.com, mach.chen@huawei.com, chengweiqiang@chinamobile.com, lizhenbin@huawei.com, jie.dong@huawei.com, rgandhi@cisco.com, xiong.quan@zte.com.cn Cc: pce@ietf.org Content-Type: multipart/alternative; boundary="000000000000d3276d059c5a2740" Archived-At: Subject: [Pce] IPR Poll on draft-li-pce-sr-bidir-path-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 18:31:55 -0000 --000000000000d3276d059c5a2740 Content-Type: text/plain; charset="UTF-8" Hi Authors, In preparation for Working Group adoption on this draft, I'd like all authors and contributors to confirm on the list that they are in compliance with IETF IPR rules. Please respond (copying the mailing list) to say one of: I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. I am aware of IPR applicable to this draft, and it has already been disclosed to the IETF. I am aware of IPR applicable to this draft, but that has not yet been disclosed to the IETF. I will work to ensure that it will be disclosed in a timely manner. Thanks, - Hari --000000000000d3276d059c5a2740 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
Hi Aut=
hors,

In preparation for Working Group adoption on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

I am aware of IPR applicable to this draft, and it has already been
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.

Thanks,
- Hari
--000000000000d3276d059c5a2740-- From nobody Sun Jan 19 14:57:53 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA04B12001E for ; Sun, 19 Jan 2020 14:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRSEbon39xQz for ; Sun, 19 Jan 2020 14:57:48 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20716.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::716]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD984120019 for ; Sun, 19 Jan 2020 14:57:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DoG0BTwLHX+AUayjz4bCcL8vNUXT0/MRLTJ/ikQHAxmUfD/wT47xfs3844VSGMcHXwhqN02eGGiSccmSQNlKy1cIHvbnjjoaQrumBxFg63Jiv4BtbTLiV/z3e+wzHrfTokpAKMizFAzu6dzR/u61VVh7Simz5KZx93DpFjhnEAYoPm+YIx3lCMEOWh37oRNaRBli3vPKW5su3GYHJOrLD2OZLSzFchJuTugT3VTu2YFEZ6+2YFuxYPunrU4SaCW2p8KEbQnXCtBp+2nBQa+T9FB18qDSNcBMTG9G5rIXkSzxktt0bxtr5y9S70X1GrL7yIP2doeoE8DpK6yLC7LQKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oKXHQUNOrMCfsYH32W+Ss4EeSC7RX2jSUleTlYfQQaM=; b=UXU7tnNj9Lfs2d1h1cOw3Za4q9QLuO7xph6gYGdfA1DcM+J+aYeeQRPXpVSD/D9rp7BK7LWtyszuw4Ra8gkWJO8WFe/ltoeIn8tSM5JY6nm/qEgkk2ZL0naCiI7jbth4O42Zij659EYwVL6GFrQtIov75ET9pD6fD4iwj+GIc4vyBP50edEPNXstuvFkjt3RrqQsb0iLUmYQ/5qLjQuTh54CRP39r4lz8iUVllnZyT4wBQO3eXN2PWsHxW8R3M7wGdHZI/SeYQzrIN6hFgWpIhjwFbHU9fOY0Jz/miT7pXYMfroM3XnHZAhQuPPO6KzVYGBCaqOJOi6p9WZb4R1uwg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oKXHQUNOrMCfsYH32W+Ss4EeSC7RX2jSUleTlYfQQaM=; b=Nc3t+sUB28TQNmyR+wigabaUj8ZhqRQdbGiev73eXybblIt6BMuN1TQkL1Vg7lOZQb3MCCzG6qCV6AcFlhEiR41RFMzjaeHavPbvc7NZnuMRIeSgIzmRiEbmvcfv5Z2w30aRv+s35oS4TsPnjYAdZ1rxkc2B19BveRLgwdZugTw= Received: from AM0PR0702MB3619.eurprd07.prod.outlook.com (52.133.46.160) by AM0PR0702MB3649.eurprd07.prod.outlook.com (52.133.43.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.15; Sun, 19 Jan 2020 22:57:45 +0000 Received: from AM0PR0702MB3619.eurprd07.prod.outlook.com ([fe80::4139:54b9:238:669c]) by AM0PR0702MB3619.eurprd07.prod.outlook.com ([fe80::4139:54b9:238:669c%7]) with mapi id 15.20.2665.015; Sun, 19 Jan 2020 22:57:45 +0000 From: "Stone, Andrew (Nokia - CA/Ottawa)" To: "pce@ietf.org" Thread-Topic: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? Thread-Index: AQHVzR6uiqJrBBVhq0SzaEKl30U2oKfvvJyU Date: Sun, 19 Jan 2020 22:57:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.stone@nokia.com; x-originating-ip: [24.53.248.71] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 01a9bf1f-2237-492d-eacd-08d79d32ff47 x-ms-traffictypediagnostic: AM0PR0702MB3649: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0287BBA78D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(346002)(376002)(39860400002)(396003)(136003)(199004)(189003)(66446008)(5660300002)(316002)(26005)(7696005)(6506007)(6916009)(53546011)(478600001)(66946007)(52536014)(64756008)(66476007)(91956017)(76116006)(66556008)(8936002)(81166006)(81156014)(8676002)(9686003)(86362001)(55016002)(19627405001)(71200400001)(33656002)(186003)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0702MB3649; H:AM0PR0702MB3619.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QY4MHHZtsMeZrymkz8pNkudSJpe9/ESIPllAISTzyPsZIJnVodOkzhpqxl1EC9VgjRps/xUkLRKC8uB+kDBM1LzIQCLngLnQPJZvRfU5uYzM2299X1Iq/0udpofiw9V5BVTNc9TxIs0sbbzpdE0SEOKFGycndREQhbvSoI87yCkSQ8Okmy8mb67eSdWLWtyQMyEpg3S9iPBc1Kp8J8djOnJtv59za71Sy0fUCDvTz6pfvwrT/WRa/w9q656ZaJJ6LPkkssjWOP62THgRZ1T7YPohn88kEwX2Ozokk2n5OOgNUyIMSUcGMOjfJ4gRQaWgObgssXQrou3mn6UUatjZcoN2X/MdLJRcWnQuRj26nm+bmISRBzapFJX0jQUfiVMTjRfBlOCPePoqYvXeMiXrZDfUoA09owOLAlE8RwH9VN9p1gUnSx2tJNDWd21QhrTR x-ms-exchange-antispam-messagedata: njefM7O470ELt9Gl0sdxh6WZVoQMEXzl2LRjw6h5tUYhnsURLdi75nmourPUbT5NGo9emApyvivb5BqsjEby0/PvcBqksUncjX3EyvzKwj8S2sFgJLdPHB7Xk/1lJWIUsXLhOJJFp8gRC00ZQr42CQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR0702MB361983EFB33D2C615673225591300AM0PR0702MB3619_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 01a9bf1f-2237-492d-eacd-08d79d32ff47 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2020 22:57:45.2793 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /fxjAJRicLKF5SEURaGzIeLrR9vSzadmtoEmu1g1tlyQ9o3/2LpiJsQBNrVBZ3O0ydc3SFojt1FtvXDlEAd5Ng== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0702MB3649 Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 22:57:51 -0000 --_000_AM0PR0702MB361983EFB33D2C615673225591300AM0PR0702MB3619_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi PCE WG and Authors, It's possible some of these items have been discussed prior to me following= the WG, so apologies in advance if that's the case. Some questions/comment= s regarding the document: * Agree, PCEP definition/support for SR Bi-dir associated LSPs is neede= d feature set and work to be covered by the WG * For bidirectional associating two LSPs, does PCC/PCE need an addition= al way to distinguish whether it's an SR or an RSVP bidirectional associati= on? Would that not be implicit based on the path setup type of the LSPs whi= ch have been associated together? In other words, do we actually need doubl= e-sided bidirectional SR association group object defined? draft-li-pce-sr-= bidir-path-06 seems to imply the behavior is basically the same as MPLS-TE = (minus the RSVP signalling of course) and the object encoding is the same, = so does yet-another object need to be defined? From a PCEP message encoding= p.o.v within an association object structure, are 2 SR LSPs that different= than associating 2 RSVP LSPs? * While I can appreciate the need for textual clarity, and perhaps I'm = missing something, but for some reason I find sections 1, 3, and 4 quite ve= rbose to essentially say at it's core: "use the objects defined in draft-ie= tf-pce-association-bidir, except use this new value type double-sided-bidir= ectional-sr instead. You can also use path segment". * In Section 5 I would prefer the document would say "there are use cas= es which require the PCC to be aware of the reverse direction SR path. A PC= E MAY inform the reverse SR Paths to the ingress PCCs and vice versa in ord= er to provide functionality for those use cases". Associating two LSPs toge= ther and never informing them of each others reverse path is a valid, simpl= e use case. Therefore having PCC informed of the reverse path to achieve fu= rther use cases is truly "OPTIONAL" in my opinion. * Related to previous point, my preference would be for references to p= ce-sr-path-segment be considered as a MAY, as there isn't a need for path-s= egment in a basic case of associating bi-directional LSPs for PCE to manage= /compute bi-directional paths for. * Section 5 I think needs a bit more discussion: * I agree the PCC should not instantiate the reverse path, but it's = not stated how to make this decision. I assume this is easy enough to decid= e with the reverse (r) bit in the association object? Might be worth mentio= n. * indicates PCE needs to allocate a PLSP-ID for the reverse path to = tell the ingress PCC, due to potential PLSPID space collision. RFC 8231 & R= FC8281 has PCC owning the PLSP-ID. At first I was confused, then remembered= about PCE Controlled ID space draft. I suppose this text is a carry over f= rom path segment integration, but li-pce-controlled-id-space is not referen= ced directly, more transitively via path-segment which is only SHOULD as an= inclusion. My question is, is there actually a need to use PCE Controlled = ID space to achieve notifying the PCC about the reverse path? Would the ind= ication of "PCE-init + R bit" be enough to let PCC generate the PLSP-ID and= report it back, while also not instantiating the path? * Possibly depending on the outcome of previous comment, I would rec= ommend the diagrams in 5.1 and 5.2 include example PLSP-IDs. In general this document appears to be a good base to work from to achieve = bi-dir sr association. Support adoption. Thanks Andrew ________________________________ From: Pce on behalf of julien.meuric@orange.com Sent: Friday, January 17, 2020 5:12 AM To: pce@ietf.org Subject: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? Hi all, It is time to share your thoughts about draft-li-pce-sr-bidir-path-06. Do you believe the I-D is a right foundation for a PCE WG item? Please use the PCE mailing list to express your comments, support or disagreement, including applicable rationale, especially for the latter. Thanks, Dhruv & Julien --_000_AM0PR0702MB361983EFB33D2C615673225591300AM0PR0702MB3619_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi PCE WG and Authors,
 
It's possible some of these items have been discussed prior to me foll= owing the WG, so apologies in advance if that's the case. Some questions/co= mments regarding the document:
  • Agree, PCEP definition/support for SR Bi-dir associated LSPs is needed = feature set and work to be covered by the WG
  • For bidirectional associating two LSPs, does PCC/PCE need an addit= ional way to distinguish whether it's an SR or an RSVP bidirectional associ= ation? Would that not be implicit based on the path setup type of the LSPs = which have been associated together? In other words, do we actually need double-sided bidirectional SR associat= ion group object defined? draft-li-pce-sr-bidir-path-06 seems to imply the = behavior is basically the same as MPLS-TE (minus the RSVP signalling of cou= rse) and the object encoding is the same, so does yet-another object need to be defined? From a PCEP messa= ge encoding p.o.v within an association object structure, are 2 SR LSPs tha= t different than associating 2 RSVP LSPs?
  • While I can appreciate the need for textual clarity, and perhaps I= 'm missing something, but for some reason I find sections 1, 3, and 4 quite= verbose to essentially say at it's core: "use the objects defined in = draft-ietf-pce-association-bidir, except use this new value type double-sided-bidirectional-sr instead. You can also us= e path segment".
  • In Section 5 I would prefer the document would say "there = are use cases which require the PCC to be aware of the reverse direction SR= path. A PCE MAY inform the reverse SR Paths to the ingress PCCs and vice v= ersa in order to provide functionality for those use cases". Associating two LSPs together and never informi= ng them of each others reverse path is a valid, simple use case. Therefore = having PCC informed of the reverse path to achieve further use cases is tru= ly "OPTIONAL" in my opinion.
  • Related to previous point, m= y preference would be for references to pce-sr-path-segment be considered a= s a MAY, as there isn't a need for path-segment in a basic case of associat= ing bi-directional LSPs for PCE to manage/compute bi-directional paths for.=
  • Section 5 I think needs a bit more discussion:
    • I agree the PCC should not instantiate the reverse path, but it's not s= tated how to make this decision. I assume this is easy enough to decide wit= h the reverse (r) bit in the association object? Might be worth mention.
    • indicates PCE needs to allocate a PLSP-ID for the reverse path to tel= l the ingress PCC, due to potential PLSPID space collision. RFC 8231 & = RFC8281 has PCC owning the PLSP-ID. At first I was confused, then remembere= d about PCE Controlled ID space draft. I suppose this text is a carry over from path segment integration, but li-= pce-controlled-id-space is not referenced directly, more transitively via p= ath-segment which is only SHOULD as an inclusion. My question is, is there = actually a need to use PCE Controlled ID space to achieve notifying the PCC about the reverse path? Would the in= dication of "PCE-init + R bit" be enough to let PCC generate = the PLSP-ID and report it back, while also not instantiating the path?
    • Possibly depending on the outcome of previous comment, I would rec= ommend the diagrams in 5.1 and 5.2 include example PLSP-IDs.

In general this document appears to be a good base to work from to ach= ieve bi-dir sr association. 

Support adoption.

Thanks
Andrew

From: Pce <pce-bounces= @ietf.org> on behalf of julien.meuric@orange.com <julien.meuric@orang= e.com>
Sent: Friday, January 17, 2020 5:12 AM
To: pce@ietf.org <pce@ietf.org>
Subject: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?
 
Hi all,

It is time to share your thoughts about draft-li-pce-sr-bidir-path-06.
Do you believe the I-D is a right foundation for a PCE WG item? Please
use the PCE mailing list to express your comments, support or
disagreement, including applicable rationale, especially for the latter.
Thanks,

Dhruv & Julien


--_000_AM0PR0702MB361983EFB33D2C615673225591300AM0PR0702MB3619_-- From nobody Sun Jan 19 18:32:48 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9E3120096; Sun, 19 Jan 2020 18:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXjMxguqI9pk; Sun, 19 Jan 2020 18:32:44 -0800 (PST) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7EA120099; Sun, 19 Jan 2020 18:32:42 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.17]) by rmmx-syy-dmz-app08-12008 (RichMail) with SMTP id 2ee85e25112acdf-e1124; Mon, 20 Jan 2020 10:32:10 +0800 (CST) X-RM-TRANSID: 2ee85e25112acdf-e1124 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[10.2.57.80]) by rmsmtp-syy-appsvr09-12009 (RichMail) with SMTP id 2ee95e251128a00-151eb; Mon, 20 Jan 2020 10:32:09 +0800 (CST) X-RM-TRANSID: 2ee95e251128a00-151eb From: "qinfengwei" To: , Cc: Date: Mon, 20 Jan 2020 10:32:13 +0800 Message-ID: <045e01d5cf39$d32ee8d0$798cba70$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_045F_01D5CF7C.E15228D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdXPOdKoJewnbo5CT7e1FF3ftJPsrA== Content-Language: zh-cn Archived-At: Subject: [Pce] =?gb2312?b?tPC4tKO6IEFkb3B0aW9uIG9mIGRyYWZ0LWxpLXBjZS1z?= =?gb2312?b?ci1iaWRpci1wYXRoLTA2o78=?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 02:32:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_045F_01D5CF7C.E15228D0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi all, I have read this document and think it very useful and mature enough to be a WG doc. =20 ---------------------------------------------------------------- Thanks & BR=A3=A1 =20 Fengwei Qin=20 =20 ------=_NextPart_000_045F_01D5CF7C.E15228D0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi = all,

         I have = read this document and think it very useful and mature enough to be a WG = doc.

 

--------------------------------= --------------------------------

Thanks & BR=A3=A1<= /span>

 

Fengwei Qin =

 

------=_NextPart_000_045F_01D5CF7C.E15228D0-- From nobody Sun Jan 19 18:33:47 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14353120096; Sun, 19 Jan 2020 18:33:43 -0800 (PST) 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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tP9g2O9XZANb; Sun, 19 Jan 2020 18:33:41 -0800 (PST) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3173C120098; Sun, 19 Jan 2020 18:33:39 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.13]) by rmmx-syy-dmz-app04-12004 (RichMail) with SMTP id 2ee45e251177dde-e125d; Mon, 20 Jan 2020 10:33:27 +0800 (CST) X-RM-TRANSID: 2ee45e251177dde-e125d X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[10.2.57.80]) by rmsmtp-syy-appsvr07-12007 (RichMail) with SMTP id 2ee75e251175087-12cab; Mon, 20 Jan 2020 10:33:26 +0800 (CST) X-RM-TRANSID: 2ee75e251175087-12cab From: "qinfengwei" To: , Cc: References: <2afd5e250ab0320-0000a.Richmail.00000040546491412971@chinamobile.com> In-Reply-To: <2afd5e250ab0320-0000a.Richmail.00000040546491412971@chinamobile.com> Date: Mon, 20 Jan 2020 10:33:31 +0800 Message-ID: <046301d5cf3a$018dca20$04a95e60$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0464_01D5CF7D.0FB10A20" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdXPNnlytzwPgBMvREW6Dxm3jJROBQAA2cFw Content-Language: zh-cn Archived-At: Subject: [Pce] =?utf-8?b?562U5aSNOiBSZTogIEFkb3B0aW9uIG9mIGRyYWZ0LWxpLXBj?= =?utf-8?q?e-sr-bidir-path-06=3F?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 02:33:43 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0464_01D5CF7D.0FB10A20 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi all, I have read this document and think it very useful and mature enough = to be a WG doc. =20 ---------------------------------------------------------------- Thanks & BR=EF=BC=81 =20 Fengwei Qin=20 _____ =20 From: Pce on behalf of julien.meuric@orange.com = Sent: Friday, January 17, 2020 5:12 AM To: pce@ietf.org Subject: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?=20 =20 Hi all, It is time to share your thoughts about draft-li-pce-sr-bidir-path-06. Do you believe the I-D is a right foundation for a PCE WG item? Please use the PCE mailing list to express your comments, support or disagreement, including applicable rationale, especially for the latter. Thanks, Dhruv & Julien ------=_NextPart_000_0464_01D5CF7D.0FB10A20 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi all,

  I have read this document and think it very useful = and mature enough to be a WG doc.

 

-------------------------------------------------= ---------------

Thanks & BR=EF=BC=81

 

Fengwei Qin =

From: Pce <pce-bounces@ietf.org> on behalf of julien.meuric@orange.com = <julien.meuric@orange.com>
Sent: Friday, January 17, = 2020 5:12 AM
To: pce@ietf.org = <pce@ietf.org>
Subject: [Pce] Adoption of = draft-li-pce-sr-bidir-path-06? =

 

Hi all,

It is time to share your = thoughts about draft-li-pce-sr-bidir-path-06.
Do you believe the I-D = is a right foundation for a PCE WG item? Please
use the PCE mailing = list to express your comments, support or
disagreement, including = applicable rationale, especially for the = latter.

Thanks,

Dhruv & = Julien

= ------=_NextPart_000_0464_01D5CF7D.0FB10A20-- From nobody Sun Jan 19 18:37:22 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44684120096 for ; Sun, 19 Jan 2020 18:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYNYWsreE7uq for ; Sun, 19 Jan 2020 18:37:17 -0800 (PST) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5423C120024 for ; Sun, 19 Jan 2020 18:37:17 -0800 (PST) Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id ED5008494DED479C0C85 for ; Mon, 20 Jan 2020 10:37:14 +0800 (CST) Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id B38CE44F9818F79DFE85; Mon, 20 Jan 2020 10:37:14 +0800 (CST) Received: from njxapp04.zte.com.cn ([10.41.132.203]) by mse-fl1.zte.com.cn with SMTP id 00K2aTLi029299; Mon, 20 Jan 2020 10:36:29 +0800 (GMT-8) (envelope-from xiong.quan@zte.com.cn) Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid201; Mon, 20 Jan 2020 10:36:29 +0800 (CST) Date: Mon, 20 Jan 2020 10:36:29 +0800 (CST) X-Zmail-TransId: 2afa5e25122db94e54d3 X-Mailer: Zmail v1.0 Message-ID: <202001201036295225424@zte.com.cn> In-Reply-To: References: CAL70W4quU0NyqXcaSjnws=6c9fy4fH-3pmjp2qXt9W_ghNXi2w@mail.gmail.com Mime-Version: 1.0 From: To: Cc: , , , , , , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl1.zte.com.cn 00K2aTLi029299 Archived-At: Subject: [Pce] =?utf-8?b?562U5aSNOiBJUFIgUG9sbCBvbiBkcmFmdC1saS1wY2Utc3It?= =?utf-8?q?bidir-path-06?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 02:37:20 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgSGFyaSwNCg0KDQoNCg0KDQoNClRoYW5rcyBmb3IgeW91ciB3b3JrIQ0KDQoNCg0KDQoNCg0K SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiBhcHBsaWNhYmxlIHRvIHRoaXMgZHJhZnQgdGhhdCBz aG91bGQgYmUgZGlzY2xvc2VkIGluIGFjY29yZGFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcy4NCg0K DQoNCg0KDQoNClRoYW5rcywNCg0KDQpRdWFuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQrljp/lp4vpgq7ku7YNCg0KDQoNCuWPkeS7tuS6uu+8mkhhcmloYXJhbkFuYW50aGFr cmlzaG5hbiA8aGFyaUBuZXRmbGl4LmNvbT4NCuaUtuS7tuS6uu+8mmNoZW5nbGkxM0BodWF3ZWku Y29tIDxjaGVuZ2xpMTNAaHVhd2VpLmNvbT47bWFjaC5jaGVuQGh1YXdlaS5jb20gPG1hY2guY2hl bkBodWF3ZWkuY29tPjtjaGVuZ3dlaXFpYW5nQGNoaW5hbW9iaWxlLmNvbSA8Y2hlbmd3ZWlxaWFu Z0BjaGluYW1vYmlsZS5jb20+O2xpemhlbmJpbkBodWF3ZWkuY29tIDxsaXpoZW5iaW5AaHVhd2Vp LmNvbT47amllLmRvbmdAaHVhd2VpLmNvbSA8amllLmRvbmdAaHVhd2VpLmNvbT47cmdhbmRoaUBj aXNjby5jb20gPHJnYW5kaGlAY2lzY28uY29tPjvnhorms4kwMDA5MTA2NTsNCuaKhOmAgeS6uu+8 mnBjZUBpZXRmLm9yZyA8cGNlQGlldGYub3JnPjsNCuaXpSDmnJ8g77yaMjAyMOW5tDAx5pyIMTjm l6UgMDI6MzENCuS4uyDpopgg77yaSVBSIFBvbGwgb24gZHJhZnQtbGktcGNlLXNyLWJpZGlyLXBh dGgtMDYNCg0KDQoNCg0KDQoNCkhpIEF1dGhvcnMsCgpJbiBwcmVwYXJhdGlvbiBmb3IgV29ya2lu ZyBHcm91cCBhZG9wdGlvbiBvbiB0aGlzIGRyYWZ0LCBJJ2QgbGlrZSBhbGwKYXV0aG9ycyBhbmQg Y29udHJpYnV0b3JzIHRvIGNvbmZpcm0gb24gdGhlIGxpc3QgdGhhdCB0aGV5IGFyZSBpbiBjb21w bGlhbmNlCndpdGggSUVURiBJUFIgcnVsZXMuCgpQbGVhc2UgcmVzcG9uZCAoY29weWluZyB0aGUg bWFpbGluZyBsaXN0KSB0byBzYXkgb25lIG9mOgoKSSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiBh cHBsaWNhYmxlIHRvIHRoaXMgZHJhZnQgdGhhdCBzaG91bGQgYmUgZGlzY2xvc2VkCmluIGFjY29y ZGFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcy4KCkkgYW0gYXdhcmUgb2YgSVBSIGFwcGxpY2FibGUg dG8gdGhpcyBkcmFmdCwgYW5kIGl0IGhhcyBhbHJlYWR5IGJlZW4KZGlzY2xvc2VkIHRvIHRoZSBJ RVRGLgoKSSBhbSBhd2FyZSBvZiBJUFIgYXBwbGljYWJsZSB0byB0aGlzIGRyYWZ0LCBidXQgdGhh dCBoYXMgbm90IHlldCBiZWVuCmRpc2Nsb3NlZCB0byB0aGUgSUVURi4gSSB3aWxsIHdvcmsgdG8g ZW5zdXJlIHRoYXQgaXQgd2lsbCBiZSBkaXNjbG9zZWQgaW4gYQp0aW1lbHkgbWFubmVyLgoKVGhh bmtzLAotIEhhcmk= --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MjBweDtmb250LWZh bWlseTphcmlhbDsiPjxicj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToyMHB4O2ZvbnQtZmFtaWx5 OmFyaWFsOyI+SGkgSGFyaSw8L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToyMHB4O2ZvbnQtZmFtaWx5 OmFyaWFsOyI+PGJyPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjIwcHg7Zm9udC1mYW1pbHk6YXJp YWw7Ij5UaGFua3MgZm9yIHlvdXIgd29yayE8L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToyMHB4O2Zv bnQtZmFtaWx5OmFyaWFsOyI+PGJyPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjIwcHg7Zm9udC1m YW1pbHk6YXJpYWw7Ij5JIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIGFwcGxpY2FibGUgdG8gdGhp cyBkcmFmdCB0aGF0IHNob3VsZCBiZSBkaXNjbG9zZWQgaW4gYWNjb3JkYW5jZSB3aXRoIElFVEYg SVBSIHJ1bGVzLjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjIwcHg7Zm9udC1mYW1pbHk6YXJpYWw7 Ij48YnI+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MjBweDtmb250LWZhbWlseTphcmlhbDsiPlRo YW5rcyw8L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToyMHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+UXVh bjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjIwcHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48YnI+PC9w PjxwIHN0eWxlPSJmb250LXNpemU6MjBweDtmb250LWZhbWlseTphcmlhbDsiPjxicj48L3A+PGRp diBjbGFzcz0iek1haWxTaWduIiB1bm9uYW1lY2g9IueGiuaziTAwMDkxMDY1IiB1bm9uYW1lZW49 Inhpb25nIHF1YW4wMDA5MTA2NSI+PGRpdiBjbGFzcz0iek1haWxTaWduQ29udGVudCI+PGRpdj48 L2Rpdj48L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSJ6TWFpbEZyb20iPjwvZGl2PjxkaXY+PGRpdiBj bGFzcz0iemhpc3RvcnlSb3ciIHN0eWxlPSJkaXNwbGF5OmJsb2NrIj48ZGl2IGNsYXNzPSJ6aGlz dG9yeURlcyIgc3R5bGU9IndpZHRoOiAxMDAlOyBoZWlnaHQ6IDI4cHg7IGxpbmUtaGVpZ2h0OiAy OHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiAjRTBFNUU5OyBjb2xvcjogIzEzODhGRjsgdGV4dC1hbGln bjogY2VudGVyOyIgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeU9yZ1R4dCI+5Y6f5aeL6YKu5Lu2PC9k aXY+PGRpdiBpZD0iendyaXRlSGlzdG9yeUNvbnRhaW5lciI+PGRpdiBjbGFzcz0iY29udHJvbC1n cm91cCB6aGlzdG9yeVBhbmVsIj48ZGl2IGNsYXNzPSJ6aGlzdG9yeUhlYWRlciIgc3R5bGU9InBh ZGRpbmc6IDhweDsgYmFja2dyb3VuZC1jb2xvcjogI0Y1RjZGODsiPjxkaXY+PHN0cm9uZyBsYW5n dWFnZS1kYXRhPSJIaXN0b3J5U2VuZGVyVHh0Ij7lj5Hku7bkurrvvJo8L3N0cm9uZz48c3BhbiBj bGFzcz0ienJlYWRVc2VyTmFtZSI+SGFyaWhhcmFuQW5hbnRoYWtyaXNobmFuICZsdDtoYXJpQG5l dGZsaXguY29tJmd0Ozwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlz dG9yeVRPVHh0Ij7mlLbku7bkurrvvJo8L3N0cm9uZz48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFt ZSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZTsiPmNoZW5nbGkxM0BodWF3ZWkuY29tICZsdDtjaGVu Z2xpMTNAaHVhd2VpLmNvbSZndDs7PC9zcGFuPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBz dHlsZT0iZGlzcGxheTogaW5saW5lOyI+bWFjaC5jaGVuQGh1YXdlaS5jb20gJmx0O21hY2guY2hl bkBodWF3ZWkuY29tJmd0Ozs8L3NwYW4+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiIHN0eWxl PSJkaXNwbGF5OiBpbmxpbmU7Ij5jaGVuZ3dlaXFpYW5nQGNoaW5hbW9iaWxlLmNvbSAmbHQ7Y2hl bmd3ZWlxaWFuZ0BjaGluYW1vYmlsZS5jb20mZ3Q7Ozwvc3Bhbj48c3BhbiBjbGFzcz0ienJlYWRV c2VyTmFtZSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZTsiPmxpemhlbmJpbkBodWF3ZWkuY29tICZs dDtsaXpoZW5iaW5AaHVhd2VpLmNvbSZndDs7PC9zcGFuPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJO YW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyI+amllLmRvbmdAaHVhd2VpLmNvbSAmbHQ7amll LmRvbmdAaHVhd2VpLmNvbSZndDs7PC9zcGFuPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBz dHlsZT0iZGlzcGxheTogaW5saW5lOyI+cmdhbmRoaUBjaXNjby5jb20gJmx0O3JnYW5kaGlAY2lz Y28uY29tJmd0Ozs8L3NwYW4+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNw bGF5OiBpbmxpbmU7Ij7nhorms4kwMDA5MTA2NTs8L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25nIGxh bmd1YWdlLWRhdGE9Ikhpc3RvcnlDQ1R4dCI+5oqE6YCB5Lq677yaPC9zdHJvbmc+PHNwYW4gY2xh c3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7Ij5wY2VAaWV0Zi5vcmcg Jmx0O3BjZUBpZXRmLm9yZyZndDs7PC9zcGFuPjwvZGl2PjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1k YXRhPSJIaXN0b3J5RGF0ZVR4dCI+5pelIOacnyDvvJo8L3N0cm9uZz48c3BhbiBjbGFzcz0iIj4y MDIw5bm0MDHmnIgxOOaXpSAwMjozMTwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2Ut ZGF0YT0iSGlzdG9yeVN1YmplY3RUeHQiPuS4uyDpopgg77yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9 InpyZWFkVGl0bGUiPjxzdHJvbmc+SVBSIFBvbGwgb24gZHJhZnQtbGktcGNlLXNyLWJpZGlyLXBh dGgtMDY8L3N0cm9uZz48L3NwYW4+PC9kaXY+PC9kaXY+PGRpdiB6bWFpbGJ1c2luZXNzPSJidXNp bmVzc0V4dGVybmFsIj48L2Rpdj48ZGl2IGNsYXNzPSJ6aGlzdG9yeUNvbnRlbnQiPjxkaXY+PGRp diBkaXI9Imx0ciI+PGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5 OnZlcmRhbmEsc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPjxwcmUgc3R5bGU9IndoaXRlLXNw YWNlOnByZS13cmFwO2JveC1zaXppbmc6Ym9yZGVyLWJveDttYXJnaW4tdG9wOjBweDttYXJnaW4t Ym90dG9tOjFyZW07b3ZlcmZsb3c6YXV0bztjb2xvcjpyZ2IoMzMsMzcsNDEpO3dvcmQtYnJlYWs6 bm9ybWFsO3BhZGRpbmc6MHB4Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6dmVyZGFuYSwgc2Fu cy1zZXJpZiI+SGkgQXV0aG9ycywKCkluIHByZXBhcmF0aW9uIGZvciBXb3JraW5nIEdyb3VwIGFk b3B0aW9uIG9uIHRoaXMgZHJhZnQsIEknZCBsaWtlIGFsbAphdXRob3JzIGFuZCBjb250cmlidXRv cnMgdG8gY29uZmlybSBvbiB0aGUgbGlzdCB0aGF0IHRoZXkgYXJlIGluIGNvbXBsaWFuY2UKd2l0 aCBJRVRGIElQUiBydWxlcy4KClBsZWFzZSByZXNwb25kIChjb3B5aW5nIHRoZSBtYWlsaW5nIGxp c3QpIHRvIHNheSBvbmUgb2Y6CgpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIGFwcGxpY2FibGUg dG8gdGhpcyBkcmFmdCB0aGF0IHNob3VsZCBiZSBkaXNjbG9zZWQKaW4gYWNjb3JkYW5jZSB3aXRo IElFVEYgSVBSIHJ1bGVzLgoKSSBhbSBhd2FyZSBvZiBJUFIgYXBwbGljYWJsZSB0byB0aGlzIGRy YWZ0LCBhbmQgaXQgaGFzIGFscmVhZHkgYmVlbgpkaXNjbG9zZWQgdG8gdGhlIElFVEYuCgpJIGFt IGF3YXJlIG9mIElQUiBhcHBsaWNhYmxlIHRvIHRoaXMgZHJhZnQsIGJ1dCB0aGF0IGhhcyBub3Qg eWV0IGJlZW4KZGlzY2xvc2VkIHRvIHRoZSBJRVRGLiBJIHdpbGwgd29yayB0byBlbnN1cmUgdGhh dCBpdCB3aWxsIGJlIGRpc2Nsb3NlZCBpbiBhCnRpbWVseSBtYW5uZXIuCgpUaGFua3MsCi0gSGFy aTwvc3Bhbj48L3ByZT48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48 L2Rpdj48cD48YnI+PC9wPjwvZGl2Pg== --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Sun Jan 19 21:55:00 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FFD120099; Sun, 19 Jan 2020 21:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZ6de160NBoc; Sun, 19 Jan 2020 21:54:56 -0800 (PST) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 070DD120077; Sun, 19 Jan 2020 21:54:49 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.15]) by rmmx-syy-dmz-app07-12007 (RichMail) with SMTP id 2ee75e25409afa1-e53a5; Mon, 20 Jan 2020 13:54:35 +0800 (CST) X-RM-TRANSID: 2ee75e25409afa1-e53a5 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmcc (unknown[10.2.53.197]) by rmsmtp-syy-appsvr08-12008 (RichMail) with SMTP id 2ee85e254099336-20f20; Mon, 20 Jan 2020 13:54:35 +0800 (CST) X-RM-TRANSID: 2ee85e254099336-20f20 From: "Weiqiang Cheng" To: "'IETF Secretariat'" , , , References: <157925622149.20230.1212156962836344152.idtracker@ietfa.amsl.com> In-Reply-To: <157925622149.20230.1212156962836344152.idtracker@ietfa.amsl.com> Date: Mon, 20 Jan 2020 13:54:34 +0800 Message-ID: <005d01d5cf56$182df5e0$4889e1a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdXNH0Vw8qVG3GAQQUW0HX0gpWWXJwCNpcjw Content-Language: zh-cn Archived-At: Subject: Re: [Pce] The PCE WG has placed draft-li-pce-sr-bidir-path in state "Call For Adoption By WG Issued" X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 05:54:59 -0000 Hi Group, Support as a co-author.=20 B.R. Weiqiang Cheng -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Pce [mailto:pce-bounces@ietf.org] =B4=FA=B1=ED IETF = Secretariat =B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA1=D4=C217=C8=D5 18:17 =CA=D5=BC=FE=C8=CB: draft-li-pce-sr-bidir-path@ietf.org; pce@ietf.org; pce-chairs@ietf.org =D6=F7=CC=E2: [Pce] The PCE WG has placed draft-li-pce-sr-bidir-path in = state "Call For Adoption By WG Issued" The PCE WG has placed draft-li-pce-sr-bidir-path in state Call For Adoption By WG Issued (entered by Julien Meuric) The document is available at https://datatracker.ietf.org/doc/draft-li-pce-sr-bidir-path/ _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From nobody Sun Jan 19 22:23:10 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE31120043 for ; Sun, 19 Jan 2020 22:23:08 -0800 (PST) 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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAx9O-q9cAxA for ; Sun, 19 Jan 2020 22:23:06 -0800 (PST) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id CE8C1120025 for ; Sun, 19 Jan 2020 22:23:05 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.3]) by rmmx-syy-dmz-app09-12009 (RichMail) with SMTP id 2ee95e25473d807-e5c58; Mon, 20 Jan 2020 14:22:54 +0800 (CST) X-RM-TRANSID: 2ee95e25473d807-e5c58 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmcc (unknown[10.2.53.197]) by rmsmtp-syy-appsvr02-12002 (RichMail) with SMTP id 2ee25e25473c15b-24b91; Mon, 20 Jan 2020 14:22:53 +0800 (CST) X-RM-TRANSID: 2ee25e25473c15b-24b91 From: "Weiqiang Cheng" To: "'Hariharan Ananthakrishnan'" , , , , , , Cc: References: In-Reply-To: Date: Mon, 20 Jan 2020 14:22:53 +0800 Message-ID: <005e01d5cf5a$0c650150$252f03f0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01D5CF9D.1A884150" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdXNZX7MrjXrtZRVQPGrmpcZpFtepgB9HVUA Content-Language: zh-cn Archived-At: Subject: Re: [Pce] IPR Poll on draft-li-pce-sr-bidir-path-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 06:23:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005F_01D5CF9D.1A884150 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Hari, I am not aware of any IPR applicable to this draft. =20 B.R. Weiqiang Cheng =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: Hariharan Ananthakrishnan = [mailto:hari@netflix.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B41=E6=9C=8818=E6=97=A5 = 02:32 =E6=94=B6=E4=BB=B6=E4=BA=BA: chengli13@huawei.com; mach.chen@huawei.com; = chengweiqiang@chinamobile.com; lizhenbin@huawei.com; = jie.dong@huawei.com; rgandhi@cisco.com; xiong.quan@zte.com.cn =E6=8A=84=E9=80=81: pce@ietf.org =E4=B8=BB=E9=A2=98: IPR Poll on draft-li-pce-sr-bidir-path-06 =20 Hi Authors, =20 In preparation for Working Group adoption on this draft, I'd like all authors and contributors to confirm on the list that they are in = compliance with IETF IPR rules. =20 Please respond (copying the mailing list) to say one of: =20 I am not aware of any IPR applicable to this draft that should be = disclosed in accordance with IETF IPR rules. =20 I am aware of IPR applicable to this draft, and it has already been disclosed to the IETF. =20 I am aware of IPR applicable to this draft, but that has not yet been disclosed to the IETF. I will work to ensure that it will be disclosed = in a timely manner. =20 Thanks, - Hari ------=_NextPart_000_005F_01D5CF9D.1A884150 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Hari,

I am not aware of any IPR applicable to this = draft.

 

B.R.

Weiqiang Cheng

 

=E5=8F=91=E4=BB=B6=E4=BA=BA: Hariharan Ananthakrishnan = [mailto:hari@netflix.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B41=E6=9C=8818=E6=97=A5 02:32
=E6=94=B6=E4=BB=B6=E4=BA=BA: chengli13@huawei.com; = mach.chen@huawei.com; chengweiqiang@chinamobile.com; = lizhenbin@huawei.com; jie.dong@huawei.com; rgandhi@cisco.com; = xiong.quan@zte.com.cn
=E6=8A=84=E9=80=81: = pce@ietf.org
=E4=B8=BB=E9=A2=98: IPR Poll on = draft-li-pce-sr-bidir-path-06

 

Hi =
Authors,
 
In =
preparation for Working Group adoption on this draft, I'd like =
all
authors and =
contributors to confirm on the list that they are in =
compliance
with IETF IPR =
rules.
 
Please =
respond (copying the mailing list) to say one =
of:
 
I am not =
aware of any IPR applicable to this draft that should be =
disclosed
in accordance =
with IETF IPR rules.
 
I am aware of =
IPR applicable to this draft, and it has already =
been
disclosed to =
the IETF.
 
I am aware of =
IPR applicable to this draft, but that has not yet =
been
disclosed to =
the IETF. I will work to ensure that it will be disclosed in =
a
timely =
manner.
 
Thanks,
- =
Hari
= ------=_NextPart_000_005F_01D5CF9D.1A884150-- From nobody Sun Jan 19 22:50:56 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C96E1200B3; Sun, 19 Jan 2020 22:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dot0RRBkPFd1; Sun, 19 Jan 2020 22:50:48 -0800 (PST) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C472120025; Sun, 19 Jan 2020 22:50:47 -0800 (PST) Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 8C08F47ADB3BDE6805F4; Mon, 20 Jan 2020 14:50:44 +0800 (CST) Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse-fl1.zte.com.cn with SMTP id 00K6o8xB083488; Mon, 20 Jan 2020 14:50:08 +0800 (GMT-8) (envelope-from xiong.quan@zte.com.cn) Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid201; Mon, 20 Jan 2020 14:50:07 +0800 (CST) Date: Mon, 20 Jan 2020 14:50:07 +0800 (CST) X-Zmail-TransId: 2afa5e254d9f47e07c9c X-Mailer: Zmail v1.0 Message-ID: <202001201450078280862@zte.com.cn> Mime-Version: 1.0 From: To: Cc: Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl1.zte.com.cn 00K6o8xB083488 Archived-At: Subject: Re: [Pce] =?utf-8?q?Adoption_of_draft-li-pce-sr-bidir-path-06=3F?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 06:50:53 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RGVhciBDaGFpcnMsDQoNCg0KDQoNCkkgc3VwcG9ydCBhcyBhIGNvLWF1dGhvci4gIA0KDQoNCg0K DQpUaGFua3MsDQoNClF1YW4NCg0KDQoNCg0KDQoNCg0KPDxbUGNlXSBBZG9wdGlvbiBvZiBkcmFm dC1saS1wY2Utc3ItYmlkaXItcGF0aC0wNj8NCjxqdWxpZW4ubWV1cmljQG9yYW5nZS5jb20+IEZy aSwgMTcgSmFudWFyeSAyMDIwIDEwOjEyIFVUQ1Nob3cgaGVhZGVyDQoNCg0KSGkgYWxsLAoKSXQg aXMgdGltZSB0byBzaGFyZSB5b3VyIHRob3VnaHRzIGFib3V0IGRyYWZ0LWxpLXBjZS1zci1iaWRp ci1wYXRoLTA2LgpEbyB5b3UgYmVsaWV2ZSB0aGUgSS1EIGlzIGEgcmlnaHQgZm91bmRhdGlvbiBm b3IgYSBQQ0UgV0cgaXRlbT8gUGxlYXNlCnVzZSB0aGUgUENFIG1haWxpbmcgbGlzdCB0byBleHBy ZXNzIHlvdXIgY29tbWVudHMsIHN1cHBvcnQgb3IKZGlzYWdyZWVtZW50LCBpbmNsdWRpbmcgYXBw bGljYWJsZSByYXRpb25hbGUsIGVzcGVjaWFsbHkgZm9yIHRoZSBsYXR0ZXIuCgpUaGFua3MsCgpE aHJ1diAmIEp1bGllbg== --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxkaXYgY2xhc3M9Inpjb250ZW50Um93Ij48cD48YnI+ PC9wPjxwPkRlYXIgQ2hhaXJzLDwvcD48cD48YnI+PC9wPjxwPkkgc3VwcG9ydCZuYnNwO2FzJm5i c3A7YSZuYnNwO2NvLWF1dGhvci4mbmJzcDsmbmJzcDs8L3A+PHA+PGJyPjwvcD48cD5UaGFua3Ms PC9wPjxwPlF1YW48L3A+PHA+PGJyPjwvcD48cD48YnI+PC9wPjxoMyBzdHlsZT0iYm94LXNpemlu ZzogYm9yZGVyLWJveDsgbWFyZ2luOiAycHggMHB4OyBmb250LWZhbWlseTogLWFwcGxlLXN5c3Rl bSwgQmxpbmtNYWNTeXN0ZW1Gb250LCAnU2Vnb2UgVUknLCBSb2JvdG8sICdIZWx2ZXRpY2EgTmV1 ZScsIEFyaWFsLCBzYW5zLXNlcmlmLCAnQXBwbGUgQ29sb3IgRW1vamknLCAnU2Vnb2UgVUkgRW1v amknLCAnU2Vnb2UgVUkgU3ltYm9sJywgJ05vdG8gQ29sb3IgRW1vamknOyBmb250LXdlaWdodDog bm9ybWFsOyBsaW5lLWhlaWdodDogMS4yOyBjb2xvcjogcmdiKDMzLCAzNywgNDEpOyBmb250LXNp emU6IDE4cHg7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgb3JwaGFuczogMjsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAy NTUsIDI1NSk7Ij4mbHQ7Jmx0O1tQY2VdIEFkb3B0aW9uIG9mIGRyYWZ0LWxpLXBjZS1zci1iaWRp ci1wYXRoLTA2PzwvaDM+PHAgaWQ9Im1zZy1pbmZvIiBjbGFzcz0ibXNnLWhlYWRlciIgc3R5bGU9 ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTog MjBweDsgY29sb3I6IHJnYigxMjgsIDEyOCwgMTI4KTsgZm9udC1mYW1pbHk6IC1hcHBsZS1zeXN0 ZW0sIEJsaW5rTWFjU3lzdGVtRm9udCwgJ1NlZ29lIFVJJywgUm9ib3RvLCAnSGVsdmV0aWNhIE5l dWUnLCBBcmlhbCwgc2Fucy1zZXJpZiwgJ0FwcGxlIENvbG9yIEVtb2ppJywgJ1NlZ29lIFVJIEVt b2ppJywgJ1NlZ29lIFVJIFN5bWJvbCcsICdOb3RvIENvbG9yIEVtb2ppJzsgZm9udC12YXJpYW50 LWxpZ2F0dXJlczogbm9ybWFsOyBvcnBoYW5zOiAyOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IDI7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPjxzcGFuIGlkPSJt c2ctZnJvbSIgY2xhc3M9InBpcGUiIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyI+Jmx0 O2p1bGllbi5tZXVyaWNAb3JhbmdlLmNvbSZndDs8L3NwYW4+Jm5ic3A7PHNwYW4gaWQ9Im1zZy1k YXRlIiBjbGFzcz0icGlwZSIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7Ij5GcmksIDE3 IEphbnVhcnkgMjAyMCAxMDoxMiBVVEM8L3NwYW4+PGEgaWQ9InRvZ2dsZS1tc2ctaGVhZGVyIiBj bGFzcz0idG9nZ2xlIiBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNn L3BjZS9UUmJ1UmNQVmFKekVxMjJ4TFhGM0xlSVVXaUkjIiBzdHlsZT0iYm94LXNpemluZzogYm9y ZGVyLWJveDsgY29sb3I6IHJnYig1MSwgMTIyLCAxODMpOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7 IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyIgdGFyZ2V0PSJfYmxhbmsiPlNob3cgaGVh ZGVyPC9hPjwvcD48ZGl2IGNsYXNzPSJtc2ctcGF5bG9hZCIgc3R5bGU9ImJveC1zaXppbmc6IGJv cmRlci1ib3g7IGNvbG9yOiByZ2IoMzMsIDM3LCA0MSk7IGZvbnQtZmFtaWx5OiAtYXBwbGUtc3lz dGVtLCBCbGlua01hY1N5c3RlbUZvbnQsICdTZWdvZSBVSScsIFJvYm90bywgJ0hlbHZldGljYSBO ZXVlJywgQXJpYWwsIHNhbnMtc2VyaWYsICdBcHBsZSBDb2xvciBFbW9qaScsICdTZWdvZSBVSSBF bW9qaScsICdTZWdvZSBVSSBTeW1ib2wnLCAnTm90byBDb2xvciBFbW9qaSc7IGZvbnQtdmFyaWFu dC1saWdhdHVyZXM6IG5vcm1hbDsgb3JwaGFuczogMjsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiAyOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij48cHJlIGNsYXNz PSJ3b3Jkd3JhcCIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IGZvbnQtZmFtaWx5OiBT Rk1vbm8tUmVndWxhciwgTWVubG8sIE1vbmFjbywgQ29uc29sYXMsICdMaWJlcmF0aW9uIE1vbm8n LCAnQ291cmllciBOZXcnLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTIuMjVweDsgbWFyZ2luLXRv cDogMHB4OyBtYXJnaW4tYm90dG9tOiAxcmVtOyBvdmVyZmxvdzogYXV0bzsgd2hpdGUtc3BhY2U6 IHByZS13cmFwOyBvdmVyZmxvdy13cmFwOiBub3JtYWw7IHdvcmQtYnJlYWs6IG5vcm1hbDsgcGFk ZGluZzogMHB4OyI+SGkgYWxsLAoKSXQgaXMgdGltZSB0byBzaGFyZSB5b3VyIHRob3VnaHRzIGFi b3V0IGRyYWZ0LWxpLXBjZS1zci1iaWRpci1wYXRoLTA2LgpEbyB5b3UgYmVsaWV2ZSB0aGUgSS1E IGlzIGEgcmlnaHQgZm91bmRhdGlvbiBmb3IgYSBQQ0UgV0cgaXRlbT8gUGxlYXNlCnVzZSB0aGUg UENFIG1haWxpbmcgbGlzdCB0byBleHByZXNzIHlvdXIgY29tbWVudHMsIHN1cHBvcnQgb3IKZGlz YWdyZWVtZW50LCBpbmNsdWRpbmcgYXBwbGljYWJsZSByYXRpb25hbGUsIGVzcGVjaWFsbHkgZm9y IHRoZSBsYXR0ZXIuCgpUaGFua3MsCgpEaHJ1diAmYW1wOyBKdWxpZW48L3ByZT48L2Rpdj48cD48 YnI+PC9wPjwvZGl2PjwvZGl2Pg== --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Mon Jan 20 02:00:00 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61C71200E0 for ; Mon, 20 Jan 2020 01:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_xr06IjQ0NQ for ; Mon, 20 Jan 2020 01:59:54 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF9D120077 for ; Mon, 20 Jan 2020 01:59:54 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 39E776A00B34F73D917B for ; Mon, 20 Jan 2020 09:59:50 +0000 (GMT) Received: from lhreml723-chm.china.huawei.com (10.201.108.74) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 20 Jan 2020 09:59:49 +0000 Received: from lhreml723-chm.china.huawei.com (10.201.108.74) by lhreml723-chm.china.huawei.com (10.201.108.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 20 Jan 2020 09:59:49 +0000 Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml723-chm.china.huawei.com (10.201.108.74) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Mon, 20 Jan 2020 09:59:49 +0000 Received: from DGGEML510-MBS.china.huawei.com ([169.254.3.33]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0439.000; Mon, 20 Jan 2020 17:59:39 +0800 From: Mach Chen To: Hariharan Ananthakrishnan , "Chengli (Cheng Li)" , "chengweiqiang@chinamobile.com" , Lizhenbin , "Dongjie (Jimmy)" , "rgandhi@cisco.com" , "xiong.quan@zte.com.cn" CC: "pce@ietf.org" Thread-Topic: IPR Poll on draft-li-pce-sr-bidir-path-06 Thread-Index: AQHVzWRnNZ9Lqc/kLEuP6BvSyZFjvKfzVa5g Date: Mon, 20 Jan 2020 09:59:39 +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.108.203.48] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297846063dggeml510mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] IPR Poll on draft-li-pce-sr-bidir-path-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 10:00:00 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297846063dggeml510mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSGFyaSwNCg0KSSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiBhcHBsaWVzIHRvIHRoaXMgZG9j dW1lbnQuDQoNCkJlc3QgcmVnYXJkcywNCk1hY2gNCg0KRnJvbTogSGFyaWhhcmFuIEFuYW50aGFr cmlzaG5hbiBbbWFpbHRvOmhhcmlAbmV0ZmxpeC5jb21dDQpTZW50OiBTYXR1cmRheSwgSmFudWFy eSAxOCwgMjAyMCAyOjMyIEFNDQpUbzogQ2hlbmdsaSAoQ2hlbmcgTGkpIDxjaGVuZ2xpMTNAaHVh d2VpLmNvbT47IE1hY2ggQ2hlbiA8bWFjaC5jaGVuQGh1YXdlaS5jb20+OyBjaGVuZ3dlaXFpYW5n QGNoaW5hbW9iaWxlLmNvbTsgTGl6aGVuYmluIDxsaXpoZW5iaW5AaHVhd2VpLmNvbT47IERvbmdq aWUgKEppbW15KSA8amllLmRvbmdAaHVhd2VpLmNvbT47IHJnYW5kaGlAY2lzY28uY29tOyB4aW9u Zy5xdWFuQHp0ZS5jb20uY24NCkNjOiBwY2VAaWV0Zi5vcmcNClN1YmplY3Q6IElQUiBQb2xsIG9u IGRyYWZ0LWxpLXBjZS1zci1iaWRpci1wYXRoLTA2DQoNCg0KSGkgQXV0aG9ycywNCg0KDQoNCklu IHByZXBhcmF0aW9uIGZvciBXb3JraW5nIEdyb3VwIGFkb3B0aW9uIG9uIHRoaXMgZHJhZnQsIEkn ZCBsaWtlIGFsbA0KDQphdXRob3JzIGFuZCBjb250cmlidXRvcnMgdG8gY29uZmlybSBvbiB0aGUg bGlzdCB0aGF0IHRoZXkgYXJlIGluIGNvbXBsaWFuY2UNCg0Kd2l0aCBJRVRGIElQUiBydWxlcy4N Cg0KDQoNClBsZWFzZSByZXNwb25kIChjb3B5aW5nIHRoZSBtYWlsaW5nIGxpc3QpIHRvIHNheSBv bmUgb2Y6DQoNCg0KDQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIGFwcGxpY2FibGUgdG8gdGhp cyBkcmFmdCB0aGF0IHNob3VsZCBiZSBkaXNjbG9zZWQNCg0KaW4gYWNjb3JkYW5jZSB3aXRoIElF VEYgSVBSIHJ1bGVzLg0KDQoNCg0KSSBhbSBhd2FyZSBvZiBJUFIgYXBwbGljYWJsZSB0byB0aGlz IGRyYWZ0LCBhbmQgaXQgaGFzIGFscmVhZHkgYmVlbg0KDQpkaXNjbG9zZWQgdG8gdGhlIElFVEYu DQoNCg0KDQpJIGFtIGF3YXJlIG9mIElQUiBhcHBsaWNhYmxlIHRvIHRoaXMgZHJhZnQsIGJ1dCB0 aGF0IGhhcyBub3QgeWV0IGJlZW4NCg0KZGlzY2xvc2VkIHRvIHRoZSBJRVRGLiBJIHdpbGwgd29y ayB0byBlbnN1cmUgdGhhdCBpdCB3aWxsIGJlIGRpc2Nsb3NlZCBpbiBhDQoNCnRpbWVseSBtYW5u ZXIuDQoNCg0KDQpUaGFua3MsDQoNCi0gSGFyaQ0K --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297846063dggeml510mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uSFRN TENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8iOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4w cHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0i Izk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBIYXJpLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5JIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIGFwcGxpZXMgdG8gdGhpcyBkb2N1 bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+TWFjaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+IEhhcmloYXJhbiBBbmFudGhha3Jpc2huYW4gW21haWx0bzpoYXJpQG5ldGZsaXguY29tXQ0K PGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBKYW51YXJ5IDE4LCAyMDIwIDI6MzIgQU08YnI+ DQo8Yj5Ubzo8L2I+IENoZW5nbGkgKENoZW5nIExpKSAmbHQ7Y2hlbmdsaTEzQGh1YXdlaS5jb20m Z3Q7OyBNYWNoIENoZW4gJmx0O21hY2guY2hlbkBodWF3ZWkuY29tJmd0OzsgY2hlbmd3ZWlxaWFu Z0BjaGluYW1vYmlsZS5jb207IExpemhlbmJpbiAmbHQ7bGl6aGVuYmluQGh1YXdlaS5jb20mZ3Q7 OyBEb25namllIChKaW1teSkgJmx0O2ppZS5kb25nQGh1YXdlaS5jb20mZ3Q7OyByZ2FuZGhpQGNp c2NvLmNvbTsgeGlvbmcucXVhbkB6dGUuY29tLmNuPGJyPg0KPGI+Q2M6PC9iPiBwY2VAaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gSVBSIFBvbGwgb24gZHJhZnQtbGktcGNlLXNyLWJpZGly LXBhdGgtMDY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5Ij5IaSBBdXRo b3JzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEy NTI5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzIxMjUyOSI+SW4gcHJlcGFyYXRpb24gZm9yIFdvcmtpbmcgR3JvdXAgYWRvcHRpb24gb24g dGhpcyBkcmFmdCwgSSdkIGxpa2UgYWxsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMyMTI1MjkiPmF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycyB0byBjb25m aXJtIG9uIHRoZSBsaXN0IHRoYXQgdGhleSBhcmUgaW4gY29tcGxpYW5jZTxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5Ij53aXRoIElFVEYgSVBS IHJ1bGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MjEyNTI5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzIxMjUyOSI+UGxlYXNlIHJlc3BvbmQgKGNvcHlpbmcgdGhlIG1haWxpbmcgbGlzdCkg dG8gc2F5IG9uZSBvZjo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzIxMjUyOSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMyMTI1MjkiPkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgYXBwbGljYWJs ZSB0byB0aGlzIGRyYWZ0IHRoYXQgc2hvdWxkIGJlIGRpc2Nsb3NlZDxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5Ij5pbiBhY2NvcmRhbmNlIHdp dGggSUVURiBJUFIgcnVsZXMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMyMTI1MjkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5Ij5JIGFtIGF3YXJlIG9mIElQUiBhcHBsaWNhYmxlIHRv IHRoaXMgZHJhZnQsIGFuZCBpdCBoYXMgYWxyZWFkeSBiZWVuPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMTI1MjkiPmRpc2Nsb3NlZCB0byB0aGUgSUVU Ri48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjUy OSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMyMTI1MjkiPkkgYW0gYXdhcmUgb2YgSVBSIGFwcGxpY2FibGUgdG8gdGhpcyBkcmFmdCwgYnV0 IHRoYXQgaGFzIG5vdCB5ZXQgYmVlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMjEyNTI5Ij5kaXNjbG9zZWQgdG8gdGhlIElFVEYuIEkgd2lsbCB3b3Jr IHRvIGVuc3VyZSB0aGF0IGl0IHdpbGwgYmUgZGlzY2xvc2VkIGluIGE8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjUyOSI+dGltZWx5IG1hbm5lci48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjUyOSI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMy MTI1MjkiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzIxMjUyOSI+LSBIYXJpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6IzIxMjUyOSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297846063dggeml510mbschi_-- From nobody Mon Jan 20 06:50:03 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FB91200B7 for ; Mon, 20 Jan 2020 06:50:00 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZdNyDiACRzc for ; Mon, 20 Jan 2020 06:49:56 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 844C012007A for ; Mon, 20 Jan 2020 06:49:55 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id 203so24265195lfa.12 for ; Mon, 20 Jan 2020 06:49:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=chwE1w0l64v7xKUdHVWtXDTYnwdsJ+zr1fLCJP1uuRw=; b=MjotHUrkbQXXbUmjWH1nk6pz6N0jHb9R5lXHYSp8tLmjsY7B/S4ULI8qo70GtfR009 8nNnfH+HlPL+6u2sA79lRB9dqqo9NR/rUHjB5BU7CtmisClwEM+eaCMQQIlhIO8PEpuM UXYA+hsKEakTxMDvCnjefwFBuq0ipyP4WukA0mitLLNZw5j1Cb4dohIfWtne0uRPfZuN 0atgaBcxs0p3I1JOFvVLALfJAckC86HorKhCmslralNJ59hHSnudmR44MQLX43sjuUBt RBoBhotO15fE3x1Vp13Lyvs4A69hUdcpIa9Se3AziEukmupQgQzr4ajDv6j5EQuBp+DW tSMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=chwE1w0l64v7xKUdHVWtXDTYnwdsJ+zr1fLCJP1uuRw=; b=KLSv2gmvGYQ/WhNKDvOBjp90WEMbmellJ8e1DA+sWHmYot274FDLQ1vgZe8ucexiaZ kmW4UiGzAPL0UwNikHMV8IW/GfjjkLuwPHJr8+DwgPvfuo1oI1aperwf0yXJyZDBN1za Nuq7vXmZVPnd/3AfJspOEOAyPdvR/er87NTBrkm1c1Ch11LEdBBHYqw5hZbMDDlpwTSb bUgZeeGIG/2po5HmnndlzapJqPCaLiZwqp46FIt6BDxaIPvtL1e6KHExosjTyDwTC4Sk WGEBiJPsZwGmBTykZ9w0PhgFKh6WMIVQPmzQN5guD1SyDlj5qn1w3aT+XSwArDe08lwG he9g== X-Gm-Message-State: APjAAAUpfqhMIq8T5cgycSPk/00V/FZ8gd3QWh83YFhtlauj1HWKcgCV IYNuPRztGem8ff6c4nHFBRpq6/kZPIPl9d3Ugg== X-Google-Smtp-Source: APXvYqwuZ3ZAUzgy7rwOiUfQi2annq7ga3z9M+AsAD8QQyK6tHANh87GmbkGMaGTRcIJmusOOyVeUn3E1Iy2kP/ehZ4= X-Received: by 2002:ac2:46dc:: with SMTP id p28mr13622003lfo.23.1579531793530; Mon, 20 Jan 2020 06:49:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rakesh Gandhi Date: Mon, 20 Jan 2020 09:49:41 -0500 Message-ID: To: "Stone, Andrew (Nokia - CA/Ottawa)" Cc: "pce@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007701e6059c93677c" Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 14:50:01 -0000 --0000000000007701e6059c93677c Content-Type: text/plain; charset="UTF-8" Hi Andrew, Thank you for your review comments. Please see some comments inline with . On Sun, Jan 19, 2020 at 5:57 PM Stone, Andrew (Nokia - CA/Ottawa) < andrew.stone@nokia.com> wrote: > Hi PCE WG and Authors, > > It's possible some of these items have been discussed prior to me > following the WG, so apologies in advance if that's the case. Some > questions/comments regarding the document: > > - Agree, PCEP definition/support for SR Bi-dir associated LSPs is > needed feature set and work to be covered by the WG > > Great, thanks. > > - For bidirectional associating two LSPs, does PCC/PCE need an > additional way to distinguish whether it's an SR or an RSVP bidirectional > association? Would that not be implicit based on the path setup type of the > LSPs which have been associated together? In other words, do we actually > need double-sided bidirectional SR association group object defined? > draft-li-pce-sr-bidir-path-06 seems to imply the behavior is basically the > same as MPLS-TE (minus the RSVP signalling of course) and the object > encoding is the same, so does yet-another object need to be defined? From a > PCEP message encoding p.o.v within an association object structure, are 2 > SR LSPs that different than associating 2 RSVP LSPs? > > Main difference is that in case of RSVP-TE, the egress node learns the reverse LSP via RSVP signaling whereas in case of SR, the egress node learns the reverse LSP via PCE. > > - While I can appreciate the need for textual clarity, and perhaps I'm > missing something, but for some reason I find sections 1, 3, and 4 quite > verbose to essentially say at it's core: "use the objects defined in > draft-ietf-pce-association-bidir, except use this new value type > double-sided-bidirectional-sr instead. You can also use path segment". > > > - In Section 5 I would prefer the document would say* "there are use > ca**ses which require the PCC to be aware of the reverse direction SR > path. A PCE MAY inform the reverse SR Paths to the ingress PCCs and vice > versa in order to provide functionality for those use cases"*. > Associating two LSPs together and never informing them of each others > reverse path is a valid, simple use case. Therefore having PCC informed of > the reverse path to achieve further use cases is truly "OPTIONAL" in my > opinion. > > Agree. > - Related to previous point, my preference would be for references to > pce-sr-path-segment be considered as a MAY, as there isn't a need for > path-segment in a basic case of associating bi-directional LSPs for PCE to > manage/compute bi-directional paths for. > > Agree. > > - Section 5 I think needs a bit more discussion: > - I agree the PCC should not instantiate the reverse path, but it's > not stated how to make this decision. I assume this is easy enough to > decide with the reverse (r) bit in the association object? Might be worth > mention. > > Ok. > > - indicates PCE needs to allocate a PLSP-ID for the reverse path to > tell the ingress PCC, due to potential PLSPID space collision. RFC 8231 & > RFC8281 has PCC owning the PLSP-ID. At first I was confused, then > remembered about PCE Controlled ID space draft. I suppose this text is a > carry over from path segment integration, but li-pce-controlled-id-space is > not referenced directly, more transitively via path-segment which is only > SHOULD as an inclusion. My question is, is there actually a need to use PCE > Controlled ID space to achieve notifying the PCC about the reverse path? > Would the indication of "PCE-init + R bit" be enough to let PCC generate > the PLSP-ID and report it back, while also not instantiating the path? > - Possibly depending on the outcome of previous comment, I would > recommend the diagrams in 5.1 and 5.2 include example PLSP-IDs. > > I will let Dhruv and other co-authors comment on this. Thanks for your support. Thanks, Rakesh > - > > > In general this document appears to be a good base to work from to achieve > bi-dir sr association. > > Support adoption. > > Thanks > Andrew > > ------------------------------ > *From:* Pce on behalf of julien.meuric@orange.com < > julien.meuric@orange.com> > *Sent:* Friday, January 17, 2020 5:12 AM > *To:* pce@ietf.org > *Subject:* [Pce] Adoption of draft-li-pce-sr-bidir-path-06? > > Hi all, > > It is time to share your thoughts about draft-li-pce-sr-bidir-path-06. > Do you believe the I-D is a right foundation for a PCE WG item? Please > use the PCE mailing list to express your comments, support or > disagreement, including applicable rationale, especially for the latter. > > Thanks, > > Dhruv & Julien > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --0000000000007701e6059c93677c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Andrew,

Thank you for you= r review comments. Please see some comments inline with <RG>.

On = Sun, Jan 19, 2020 at 5:57 PM Stone, Andrew (Nokia - CA/Ottawa) <andrew.stone@nokia.com> wrote:
Hi PCE WG and Authors,
=C2=A0
It's possible some of these items have been discussed prior to me = following the WG, so apologies in advance if that's the case. Some ques= tions/comments regarding the document:
  • Agree, PCEP definition/support for SR Bi-dir associated LSPs is needed = feature set and work to be covered by the WG
<RG> Great, thanks.
=C2=A0
  • For bidirectional associating two LSPs, does PCC/PCE = need an additional way to distinguish whether it's an SR or an RSVP bid= irectional association? Would that not be implicit based on the path setup = type of the LSPs which have been associated together? In other words, do we actually need double-sided bidirectional SR associat= ion group object defined? draft-li-pce-sr-bidir-path-06 seems to imply the = behavior is basically the same as MPLS-TE (minus the RSVP signalling of cou= rse) and the object encoding is the same, so does yet-another object need to be defined? From a PCEP messa= ge encoding p.o.v within an association object structure, are 2 SR LSPs tha= t different than associating 2 RSVP LSPs?

<RG> Main difference is that in case o= f RSVP-TE, the egress node learns the reverse LSP via RSVP signaling wherea= s in case of SR, the egress node learns the reverse LSP via PCE.
=
  • While I can appreciate the need for textual clarity= , and perhaps I'm missing something, but for some reason I find section= s 1, 3, and 4 quite verbose to essentially say at it's core: "use = the objects defined in draft-ietf-pce-association-bidir, except use this new value type double-sided-bidirectional-sr instead. You can also us= e path segment".
  • In Sec= tion 5 I would prefer the document would say "there are use ca<= i>ses which require the PCC to be aware of the reverse direction SR path. A= PCE MAY inform the reverse SR Paths to the ingress PCCs and vice versa in = order to provide functionality for those use cases". Associating two LSPs together and never informi= ng them of each others reverse path is a valid, simple use case. Therefore = having PCC informed of the reverse path to achieve further use cases is tru= ly "OPTIONAL" in my opinion.

<RG> Agree.

  • Related to previous point, my preference would be for references= to pce-sr-path-segment be considered as a MAY, as there isn't a need f= or path-segment in a basic case of associating bi-directional LSPs for PCE = to manage/compute bi-directional paths for.
=

<RG> Agree.
  • Section 5 I think needs a bit more discussion:
    • I agree the PCC should not instantiate the reverse path, but it's n= ot stated how to make this decision. I assume this is easy enough to decide= with the reverse (r) bit in the association object? Might be worth mention= .

<RG&g= t; Ok.
    • indicates PCE needs to allocat= e a PLSP-ID for the reverse path to tell the ingress PCC, due to potential = PLSPID space collision. RFC 8231 & RFC8281 has PCC owning the PLSP-ID. = At first I was confused, then remembered about PCE Controlled ID space draf= t. I suppose this text is a carry over from path segment integration, but li-= pce-controlled-id-space is not referenced directly, more transitively via p= ath-segment which is only SHOULD as an inclusion. My question is, is there = actually a need to use PCE Controlled ID space to achieve notifying the PCC about the reverse path? Would the in= dication of "PCE-init + R bit" be enough to let PCC generate the = PLSP-ID and report it back, while also not instantiating the path?
    • Possibly depending on the outcome of previous comment, I would rec= ommend the diagrams in 5.1 and 5.2 include example PLSP-IDs.
    <= /ul>

<RG> I will le= t Dhruv and other co-authors comment on this.

Than= ks for your support.

Thanks,
Rakesh<= /div>



In general this document appears to be a good base to work from to ach= ieve bi-dir sr association.=C2=A0

Support adoption.

Thanks
Andrew

Fro= m: Pce <pc= e-bounces@ietf.org> on behalf of julien.meuric@orange.com <julien.meuric@orange.com= >
Sent: Friday, January 17, 2020 5:12 AM
To: pce@ietf.org <pce@ietf.org&g= t;
Subject: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?
=C2=A0
Hi all,

It is time to share your thoughts about draft-li-pce-sr-bidir-path-06.
Do you believe the I-D is a right foundation for a PCE WG item? Please
use the PCE mailing list to express your comments, support or
disagreement, including applicable rationale, especially for the latter.
Thanks,

Dhruv & Julien


_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
--0000000000007701e6059c93677c-- From nobody Mon Jan 20 07:42:05 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9C0120802 for ; Mon, 20 Jan 2020 07:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qr-WIi_ey4wu for ; Mon, 20 Jan 2020 07:41:56 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40091.outbound.protection.outlook.com [40.107.4.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B3412029C for ; Mon, 20 Jan 2020 07:41:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TfWW19v1dIWP+KAqjlzy1zfrBodW57BqlT1O8EP6Kcj9NbzCbLSH/t3FuqGIe9Hu/G8SFYqQoCvSAZ+PUpHPhg1p7uQbYvqHxTEsO8iTMojvoSOPUXcR0gbiSIlzS9n+zutvkED+DC7Y6uuHDqa5iVpHkyCO5kua+pcmm+R+WJNYWJX6b2KFFYuXpcFxNXeC2jcgLciew7x4WcpxQXQbNlKb5ioSBQsCZC9KqQmtBmCMmoRkNGxFZjvtemD2T/RdZAF34EVCmameSz2BTMMmZ2gDm10iZYGWfrs3hGtAr8w3m72JHp1uIq30MTBDdczL2AfOgnOlWKkpS1AI8mTXQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6zhVJOjnBZ3+wZIzg4mPQuCJ2V/QodU6LL4kdjlH6wc=; b=mI7qa3AIDE91WebfzOTest6kZ13dz6vOiysRud/cpnnePGfV79YMsSJALSU31513Ur3w9BskSycHSaES7bfjudfiuSDvw4i87p5mrENxQ/Rg4M2AuB0RGmFT+rW/KsFkiwwLSMiPIYSrK5bGwovmDZyfF4fGw4xUXbD9VkjuvP9K5rpf9vdShoIz6bGzwP3DC5rYXAOfSYKB/L4zbkDGP0cCyw1Mpai26LkvmZjkqzWYgZBOR4MyhcrZhhzvN6zO+L7E9TBdlhwuwNvDxD+yf/LOJNg8MIVR1JDYD28WCVp3FzSf5rSJcQT65ACvW7oAkzWLBv8/yNwB0xzJVCG0BA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6zhVJOjnBZ3+wZIzg4mPQuCJ2V/QodU6LL4kdjlH6wc=; b=DyW11orjACo4InW8AOHhy7GHLGyg/slvLnMX3K7GQSMoCKnwofbpj+PrLcF8pL0CHUoFYEe7IDqhs57el/aQNYeS0DRYNM7HzNuvIynbfEZUsa9G3T09fjtUoOzj/7dVOtWDL2fppWqb5W7Y4TKzfd6GM6Q29YRd+FXXH3jD59A= Received: from AM0PR0702MB3619.eurprd07.prod.outlook.com (52.133.46.160) by AM0PR0702MB3764.eurprd07.prod.outlook.com (52.133.44.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.14; Mon, 20 Jan 2020 15:41:51 +0000 Received: from AM0PR0702MB3619.eurprd07.prod.outlook.com ([fe80::4139:54b9:238:669c]) by AM0PR0702MB3619.eurprd07.prod.outlook.com ([fe80::4139:54b9:238:669c%7]) with mapi id 15.20.2665.015; Mon, 20 Jan 2020 15:41:51 +0000 From: "Stone, Andrew (Nokia - CA/Ottawa)" To: Rakesh Gandhi CC: "pce@ietf.org" Thread-Topic: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? Thread-Index: AQHVzR6uiqJrBBVhq0SzaEKl30U2oKfvvJyUgAPq14D//7q+AA== Date: Mon, 20 Jan 2020 15:41:51 +0000 Message-ID: <4EA592A4-4749-4743-8255-BFE7D296A61C@nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.stone@nokia.com; x-originating-ip: [135.245.20.25] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 4727de03-e485-4344-ece3-08d79dbf44e0 x-ms-traffictypediagnostic: AM0PR0702MB3764: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0288CD37D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(346002)(396003)(366004)(39860400002)(136003)(189003)(199004)(71200400001)(8676002)(316002)(4326008)(2616005)(33656002)(6916009)(6486002)(81166006)(81156014)(6512007)(8936002)(2906002)(186003)(66446008)(64756008)(66556008)(66476007)(91956017)(26005)(53546011)(6506007)(36756003)(9326002)(76116006)(66946007)(966005)(5660300002)(86362001)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0702MB3764; H:AM0PR0702MB3619.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hvMJOc7nCP0rxeh9RzOoqGbhz8EHEvQaG/scgigHezUDg2nXfPYvv7JT6EcHrZfxq5M3ouvU9XCB/9llfyKMomDfMzP+AGxa5RPus6/ZVIjQnK+Yuepz0+L3sxk5SzzuVrDdey/qSHeKxCYk8ZuKThNIRsGszwMB464p50ceUe51gxKqZRR+evmXUWsYCLO+edoWvm3xl2bjC4CbEFFb6EZXMJwVzb30P/NLz3ajZhqlsd+9n+nQ9EjqKtQM4vctqjHtfxRngKEI4aiPYT3VcccRwbQ56wkQJCv8azn4pHuvD8Zs3xSiLlBB4EQCcSUG4GYjKeVSAyJMzgLfNF5mnNSlprd/D7kmssf+SgOI7BxrAmFkEsrjcwhpraOk4RxCsWKErQo5MzZ4jcznkIxeTOAmn2AaJ0EhWKNXU6L68RhW3lH+0obkmsyzgUc2As0E/+4Us8/S2HXhcAOV4GUfsKLfpkiIRCqo5VQtJZRcXTjvD3Bi8rRGLpZFngJn6tjOSO6HhUmnjHNt0RK88oZIqg== x-ms-exchange-antispam-messagedata: zb0ggeCRSt7wfzFahqtNjsfwVKwBtQFniRnTpdPqNeewYkb0Lh45Cc+bNPDLWRUtdIj41xPU8huW09oEwR8+Y81DTMtzS0YDL+Ejcq4NkfXVNiLMF5/6Bfl4EmGrnX3zmR6rPBA2nulXxM3vBIs5UQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_4EA592A4474947438255BFE7D296A61Cnokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4727de03-e485-4344-ece3-08d79dbf44e0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2020 15:41:51.4871 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: unxrc2zSoaxK/w2DWLH02CMUGsmGzytvNx7CzW2pM2JhpBX9bJ9ZSEIzq+ksfMdPAjV+rlgTBih2Q7QalKI9ew== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0702MB3764 Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 15:42:03 -0000 --_000_4EA592A4474947438255BFE7D296A61Cnokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmFrZXNoLA0KDQpUaGFua3MgZm9yIHRoZSBzcGVlZHkgcmVwbHkuIE9uZSBmb2xsb3cgdXAg Y29tbWVudCBiZWxvdy4NCg0KQ2hlZXJzDQpBbmRyZXcNCg0KRnJvbTogUmFrZXNoIEdhbmRoaSA8 cmdhbmRoaS5pZXRmQGdtYWlsLmNvbT4NCkRhdGU6IE1vbmRheSwgSmFudWFyeSAyMCwgMjAyMCBh dCA5OjQ5IEFNDQpUbzogIlN0b25lLCBBbmRyZXcgKE5va2lhIC0gQ0EvT3R0YXdhKSIgPGFuZHJl dy5zdG9uZUBub2tpYS5jb20+DQpDYzogInBjZUBpZXRmLm9yZyIgPHBjZUBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbUGNlXSBBZG9wdGlvbiBvZiBkcmFmdC1saS1wY2Utc3ItYmlkaXItcGF0aC0w Nj8NCg0KSGkgQW5kcmV3LA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3IGNvbW1lbnRzLiBQ bGVhc2Ugc2VlIHNvbWUgY29tbWVudHMgaW5saW5lIHdpdGggPFJHPi4NCg0KT24gU3VuLCBKYW4g MTksIDIwMjAgYXQgNTo1NyBQTSBTdG9uZSwgQW5kcmV3IChOb2tpYSAtIENBL090dGF3YSkgPGFu ZHJldy5zdG9uZUBub2tpYS5jb208bWFpbHRvOmFuZHJldy5zdG9uZUBub2tpYS5jb20+PiB3cm90 ZToNCkhpIFBDRSBXRyBhbmQgQXV0aG9ycywNCg0KSXQncyBwb3NzaWJsZSBzb21lIG9mIHRoZXNl IGl0ZW1zIGhhdmUgYmVlbiBkaXNjdXNzZWQgcHJpb3IgdG8gbWUgZm9sbG93aW5nIHRoZSBXRywg c28gYXBvbG9naWVzIGluIGFkdmFuY2UgaWYgdGhhdCdzIHRoZSBjYXNlLiBTb21lIHF1ZXN0aW9u cy9jb21tZW50cyByZWdhcmRpbmcgdGhlIGRvY3VtZW50Og0KDQogICogICBBZ3JlZSwgUENFUCBk ZWZpbml0aW9uL3N1cHBvcnQgZm9yIFNSIEJpLWRpciBhc3NvY2lhdGVkIExTUHMgaXMgbmVlZGVk IGZlYXR1cmUgc2V0IGFuZCB3b3JrIHRvIGJlIGNvdmVyZWQgYnkgdGhlIFdHDQo8Ukc+IEdyZWF0 LCB0aGFua3MuDQoNCg0KICAqICAgRm9yIGJpZGlyZWN0aW9uYWwgYXNzb2NpYXRpbmcgdHdvIExT UHMsIGRvZXMgUENDL1BDRSBuZWVkIGFuIGFkZGl0aW9uYWwgd2F5IHRvIGRpc3Rpbmd1aXNoIHdo ZXRoZXIgaXQncyBhbiBTUiBvciBhbiBSU1ZQIGJpZGlyZWN0aW9uYWwgYXNzb2NpYXRpb24/IFdv dWxkIHRoYXQgbm90IGJlIGltcGxpY2l0IGJhc2VkIG9uIHRoZSBwYXRoIHNldHVwIHR5cGUgb2Yg dGhlIExTUHMgd2hpY2ggaGF2ZSBiZWVuIGFzc29jaWF0ZWQgdG9nZXRoZXI/IEluIG90aGVyIHdv cmRzLCBkbyB3ZSBhY3R1YWxseSBuZWVkIGRvdWJsZS1zaWRlZCBiaWRpcmVjdGlvbmFsIFNSIGFz c29jaWF0aW9uIGdyb3VwIG9iamVjdCBkZWZpbmVkPyBkcmFmdC1saS1wY2Utc3ItYmlkaXItcGF0 aC0wNiBzZWVtcyB0byBpbXBseSB0aGUgYmVoYXZpb3IgaXMgYmFzaWNhbGx5IHRoZSBzYW1lIGFz IE1QTFMtVEUgKG1pbnVzIHRoZSBSU1ZQIHNpZ25hbGxpbmcgb2YgY291cnNlKSBhbmQgdGhlIG9i amVjdCBlbmNvZGluZyBpcyB0aGUgc2FtZSwgc28gZG9lcyB5ZXQtYW5vdGhlciBvYmplY3QgbmVl ZCB0byBiZSBkZWZpbmVkPyBGcm9tIGEgUENFUCBtZXNzYWdlIGVuY29kaW5nIHAuby52IHdpdGhp biBhbiBhc3NvY2lhdGlvbiBvYmplY3Qgc3RydWN0dXJlLCBhcmUgMiBTUiBMU1BzIHRoYXQgZGlm ZmVyZW50IHRoYW4gYXNzb2NpYXRpbmcgMiBSU1ZQIExTUHM/DQoNCjxSRz4gTWFpbiBkaWZmZXJl bmNlIGlzIHRoYXQgaW4gY2FzZSBvZiBSU1ZQLVRFLCB0aGUgZWdyZXNzIG5vZGUgbGVhcm5zIHRo ZSByZXZlcnNlIExTUCB2aWEgUlNWUCBzaWduYWxpbmcgd2hlcmVhcyBpbiBjYXNlIG9mIFNSLCB0 aGUgZWdyZXNzIG5vZGUgbGVhcm5zIHRoZSByZXZlcnNlIExTUCB2aWEgUENFLg0KDQo8QW5kcmV3 PiBZZXMsIEkgcmVhbGl6ZSB0aGF0LCBob3dldmVyIHRoZSBhc3NvY2lhdGlvbiBzdHJ1Y3R1cmUg aXMgYWJvdXQgaW5mb3JtaW5nIFBDRSB0byBhc3NvY2lhdGUgdHdvIExTUHMgdG9nZXRoZXIsIGlz IGl0IG5vdD8gSXTigJlzIG5vdCByZWxhdGVkIHRvIGhvdyAyIExTUHMgbGVhcm4gZWFjaCBvcHBv c2l0ZSByZXZlcnNlIHBhdGguIFRvIGJlIHNwZWNpZmljLCBteSBjb21tZW50IGlzIHJlZ2FyZGlu ZyBzZWN0aW9uIDMuMS4gVG8gaW5zdHJ1Y3QgUENFIOKAnG1ha2UgdGhlc2UgMiBiaWRpcmVjdGlv bmFs4oCdIGlzIGEgc2VwYXJhdGUgdGFzayB0aGFuIGhvdyB0aGUgTFNQcyBsZWFybiBvZiBlYWNo IG90aGVy4oCZcyByZXZlcnNlIExTUCBhbmQgcGF0aCBpbiBteSBvcGluaW9uLiBTbyB0byBpbmZv cm0gUENFIOKAnHRoZXNlIDIgTFNQcyBhcmUgYmlkaXJlY3Rpb25hbCwgbWFrZSB0aGVtIHNv4oCd IGlzIHRoZSBzYW1lIGluc3RydWN0aW9uIGlycmVsZXZhbnQgb2YgaG93IGVhY2ggTFNQIGxlYXJu cyBvZiBlYWNoIG90aGVycyBwYXRoLiBGb3IgU1IsIHllcyB0aGVyZSBpcyB0aGUgYWRkZWQgcHJv Y2VzcyB3aGVyZSBQQ0UgbWF5IG5lZWQgdG8gdGVsbCB0aGUgUENDIHRoZSBvcHBvc2l0ZSBwYXRo LCBidXQgdGhhdCBkZWNpc2lvbiBpcyBhIGJlaGF2aW91ciBwb3N0LWFzc29jaWF0aW9uIGJlaW5n IHByb3ZpZGVkLCB3aGljaCBjYW4gYmUgZGV0ZXJtaW5lZCBhcyBuZWNlc3NhcnkgYnkgdGhlIExT UCBwYXRoIHNldHVwIHR5cGUgb2YgdGhlIGFzc29jaWF0ZWQgTFNQcy4gU28gaWYgdGhlIGdvYWwg b2YgdG8gaW5zdHJ1Y3QgUENFIOKAnHRoZXNlIDIgTFNQcyBhcmUgYmlkaXJlY3Rpb25hbOKAnSwg dGhhdCBpbnN0cnVjdGlvbiBpcyBjb21tb24gYmV0d2VlbiBMU1BzIHdoZXRoZXIgdGhleSBhcmUg UlNWUCBvciBTUi4gRXNzZW50aWFsbHkgZGVmaW5pbmcgJ0RvdWJsZS1zaWRlZCBCaWRpcmVjdGlv bmFsIFNSIFBhdGggQXNzb2NpYXRpb24gR3JvdXAnIGlzIG5vdCByZXF1aXJlZCAodW5sZXNzIHRo ZXJl4oCZcyBzb21ldGhpbmcgZWxzZSBpbiB0aGF0IG9iamVjdCB3ZSBmb3Jlc2VlIGJlaW5nIHNw ZWNpZmljIHRvIFNSIGluIHRoZSBmdXR1cmUpLg0KDQoNCg0KICAqICAgV2hpbGUgSSBjYW4gYXBw cmVjaWF0ZSB0aGUgbmVlZCBmb3IgdGV4dHVhbCBjbGFyaXR5LCBhbmQgcGVyaGFwcyBJJ20gbWlz c2luZyBzb21ldGhpbmcsIGJ1dCBmb3Igc29tZSByZWFzb24gSSBmaW5kIHNlY3Rpb25zIDEsIDMs IGFuZCA0IHF1aXRlIHZlcmJvc2UgdG8gZXNzZW50aWFsbHkgc2F5IGF0IGl0J3MgY29yZTogInVz ZSB0aGUgb2JqZWN0cyBkZWZpbmVkIGluIGRyYWZ0LWlldGYtcGNlLWFzc29jaWF0aW9uLWJpZGly LCBleGNlcHQgdXNlIHRoaXMgbmV3IHZhbHVlIHR5cGUgZG91YmxlLXNpZGVkLWJpZGlyZWN0aW9u YWwtc3IgaW5zdGVhZC4gWW91IGNhbiBhbHNvIHVzZSBwYXRoIHNlZ21lbnQiLg0KDQogICogICBJ biBTZWN0aW9uIDUgSSB3b3VsZCBwcmVmZXIgdGhlIGRvY3VtZW50IHdvdWxkIHNheSAidGhlcmUg YXJlIHVzZSBjYXNlcyB3aGljaCByZXF1aXJlIHRoZSBQQ0MgdG8gYmUgYXdhcmUgb2YgdGhlIHJl dmVyc2UgZGlyZWN0aW9uIFNSIHBhdGguIEEgUENFIE1BWSBpbmZvcm0gdGhlIHJldmVyc2UgU1Ig UGF0aHMgdG8gdGhlIGluZ3Jlc3MgUENDcyBhbmQgdmljZSB2ZXJzYSBpbiBvcmRlciB0byBwcm92 aWRlIGZ1bmN0aW9uYWxpdHkgZm9yIHRob3NlIHVzZSBjYXNlcyIuIEFzc29jaWF0aW5nIHR3byBM U1BzIHRvZ2V0aGVyIGFuZCBuZXZlciBpbmZvcm1pbmcgdGhlbSBvZiBlYWNoIG90aGVycyByZXZl cnNlIHBhdGggaXMgYSB2YWxpZCwgc2ltcGxlIHVzZSBjYXNlLiBUaGVyZWZvcmUgaGF2aW5nIFBD QyBpbmZvcm1lZCBvZiB0aGUgcmV2ZXJzZSBwYXRoIHRvIGFjaGlldmUgZnVydGhlciB1c2UgY2Fz ZXMgaXMgdHJ1bHkgIk9QVElPTkFMIiBpbiBteSBvcGluaW9uLg0KDQo8Ukc+IEFncmVlLg0KDQoN CiAgKiAgIFJlbGF0ZWQgdG8gcHJldmlvdXMgcG9pbnQsIG15IHByZWZlcmVuY2Ugd291bGQgYmUg Zm9yIHJlZmVyZW5jZXMgdG8gcGNlLXNyLXBhdGgtc2VnbWVudCBiZSBjb25zaWRlcmVkIGFzIGEg TUFZLCBhcyB0aGVyZSBpc24ndCBhIG5lZWQgZm9yIHBhdGgtc2VnbWVudCBpbiBhIGJhc2ljIGNh c2Ugb2YgYXNzb2NpYXRpbmcgYmktZGlyZWN0aW9uYWwgTFNQcyBmb3IgUENFIHRvIG1hbmFnZS9j b21wdXRlIGJpLWRpcmVjdGlvbmFsIHBhdGhzIGZvci4NCg0KPFJHPiBBZ3JlZS4NCg0KICAqICAg U2VjdGlvbiA1IEkgdGhpbmsgbmVlZHMgYSBiaXQgbW9yZSBkaXNjdXNzaW9uOg0KDQogICAgICog ICBJIGFncmVlIHRoZSBQQ0Mgc2hvdWxkIG5vdCBpbnN0YW50aWF0ZSB0aGUgcmV2ZXJzZSBwYXRo LCBidXQgaXQncyBub3Qgc3RhdGVkIGhvdyB0byBtYWtlIHRoaXMgZGVjaXNpb24uIEkgYXNzdW1l IHRoaXMgaXMgZWFzeSBlbm91Z2ggdG8gZGVjaWRlIHdpdGggdGhlIHJldmVyc2UgKHIpIGJpdCBp biB0aGUgYXNzb2NpYXRpb24gb2JqZWN0PyBNaWdodCBiZSB3b3J0aCBtZW50aW9uLg0KDQo8Ukc+ IE9rLg0KDQogICAgICogICBpbmRpY2F0ZXMgUENFIG5lZWRzIHRvIGFsbG9jYXRlIGEgUExTUC1J RCBmb3IgdGhlIHJldmVyc2UgcGF0aCB0byB0ZWxsIHRoZSBpbmdyZXNzIFBDQywgZHVlIHRvIHBv dGVudGlhbCBQTFNQSUQgc3BhY2UgY29sbGlzaW9uLiBSRkMgODIzMSAmIFJGQzgyODEgaGFzIFBD QyBvd25pbmcgdGhlIFBMU1AtSUQuIEF0IGZpcnN0IEkgd2FzIGNvbmZ1c2VkLCB0aGVuIHJlbWVt YmVyZWQgYWJvdXQgUENFIENvbnRyb2xsZWQgSUQgc3BhY2UgZHJhZnQuIEkgc3VwcG9zZSB0aGlz IHRleHQgaXMgYSBjYXJyeSBvdmVyIGZyb20gcGF0aCBzZWdtZW50IGludGVncmF0aW9uLCBidXQg bGktcGNlLWNvbnRyb2xsZWQtaWQtc3BhY2UgaXMgbm90IHJlZmVyZW5jZWQgZGlyZWN0bHksIG1v cmUgdHJhbnNpdGl2ZWx5IHZpYSBwYXRoLXNlZ21lbnQgd2hpY2ggaXMgb25seSBTSE9VTEQgYXMg YW4gaW5jbHVzaW9uLiBNeSBxdWVzdGlvbiBpcywgaXMgdGhlcmUgYWN0dWFsbHkgYSBuZWVkIHRv IHVzZSBQQ0UgQ29udHJvbGxlZCBJRCBzcGFjZSB0byBhY2hpZXZlIG5vdGlmeWluZyB0aGUgUEND IGFib3V0IHRoZSByZXZlcnNlIHBhdGg/IFdvdWxkIHRoZSBpbmRpY2F0aW9uIG9mICJQQ0UtaW5p dCArIFIgYml0IiBiZSBlbm91Z2ggdG8gbGV0IFBDQyBnZW5lcmF0ZSB0aGUgUExTUC1JRCBhbmQg cmVwb3J0IGl0IGJhY2ssIHdoaWxlIGFsc28gbm90IGluc3RhbnRpYXRpbmcgdGhlIHBhdGg/DQog ICAgICogICBQb3NzaWJseSBkZXBlbmRpbmcgb24gdGhlIG91dGNvbWUgb2YgcHJldmlvdXMgY29t bWVudCwgSSB3b3VsZCByZWNvbW1lbmQgdGhlIGRpYWdyYW1zIGluIDUuMSBhbmQgNS4yIGluY2x1 ZGUgZXhhbXBsZSBQTFNQLUlEcy4NCg0KPFJHPiBJIHdpbGwgbGV0IERocnV2IGFuZCBvdGhlciBj by1hdXRob3JzIGNvbW1lbnQgb24gdGhpcy4NCg0KVGhhbmtzIGZvciB5b3VyIHN1cHBvcnQuDQoN ClRoYW5rcywNClJha2VzaA0KDQoNCg0KICAgICAqDQoNCkluIGdlbmVyYWwgdGhpcyBkb2N1bWVu dCBhcHBlYXJzIHRvIGJlIGEgZ29vZCBiYXNlIHRvIHdvcmsgZnJvbSB0byBhY2hpZXZlIGJpLWRp ciBzciBhc3NvY2lhdGlvbi4NCg0KU3VwcG9ydCBhZG9wdGlvbi4NCg0KVGhhbmtzDQpBbmRyZXcN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IFBjZSA8cGNlLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOnBjZS1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIGp1 bGllbi5tZXVyaWNAb3JhbmdlLmNvbTxtYWlsdG86anVsaWVuLm1ldXJpY0BvcmFuZ2UuY29tPiA8 anVsaWVuLm1ldXJpY0BvcmFuZ2UuY29tPG1haWx0bzpqdWxpZW4ubWV1cmljQG9yYW5nZS5jb20+ Pg0KU2VudDogRnJpZGF5LCBKYW51YXJ5IDE3LCAyMDIwIDU6MTIgQU0NClRvOiBwY2VAaWV0Zi5v cmc8bWFpbHRvOnBjZUBpZXRmLm9yZz4gPHBjZUBpZXRmLm9yZzxtYWlsdG86cGNlQGlldGYub3Jn Pj4NClN1YmplY3Q6IFtQY2VdIEFkb3B0aW9uIG9mIGRyYWZ0LWxpLXBjZS1zci1iaWRpci1wYXRo LTA2Pw0KDQpIaSBhbGwsDQoNCkl0IGlzIHRpbWUgdG8gc2hhcmUgeW91ciB0aG91Z2h0cyBhYm91 dCBkcmFmdC1saS1wY2Utc3ItYmlkaXItcGF0aC0wNi4NCkRvIHlvdSBiZWxpZXZlIHRoZSBJLUQg aXMgYSByaWdodCBmb3VuZGF0aW9uIGZvciBhIFBDRSBXRyBpdGVtPyBQbGVhc2UNCnVzZSB0aGUg UENFIG1haWxpbmcgbGlzdCB0byBleHByZXNzIHlvdXIgY29tbWVudHMsIHN1cHBvcnQgb3INCmRp c2FncmVlbWVudCwgaW5jbHVkaW5nIGFwcGxpY2FibGUgcmF0aW9uYWxlLCBlc3BlY2lhbGx5IGZv ciB0aGUgbGF0dGVyLg0KDQpUaGFua3MsDQoNCkRocnV2ICYgSnVsaWVuDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQY2UgbWFpbGluZyBsaXN0DQpQ Y2VAaWV0Zi5vcmc8bWFpbHRvOlBjZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcGNlDQo= --_000_4EA592A4474947438255BFE7D296A61Cnokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6MTAxODA0OTU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0x MTQwMTY3NTQ2O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjQ2MTE5MTcyNzsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6LTEyNDU3OTA2Mzg7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGkt Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMy NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6OTc5NjQ5MDA2Ow0KCW1zby1saXN0LXRlbXBs YXRlLWlkczozNjYyNzA2Mzg7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJp ZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2 ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTA3NTM5ODA4NzsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6MTgzMDg2Mzg2ODt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglt c28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMzpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgw LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsNA0KCXttc28tbGlzdC1pZDoxNDczNjcxOTU5Ow0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczo2NzU0NzM5NDQ7fQ0KQGxpc3QgbDQ6bGV2ZWwxDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDQ6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDQ6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDUNCgl7bXNvLWxpc3QtaWQ6MTU5MjY2MDEyMjsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6ODczMjEzNzEwO30NCkBsaXN0IGw1OmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGw1 OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsNA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGw1OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1Omxl dmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2DQoJe21zby1saXN0LWlkOjE2NDE4MzY2MzM7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzU0MTEzNzgwO30NCkBsaXN0IGw2OmxldmVsMQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDY6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBs aXN0IGw2OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2OmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2OmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoy MTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGw2OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGw2OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2OmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw3DQoJe21zby1saXN0LWlkOjE5Nzc2 ODAzODU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjI2ODc1ODk4Njt9DQpAbGlzdCBsNzpsZXZl bDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9 DQpAbGlzdCBsNzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNzps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNzpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsNzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsNzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNzpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1D QSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUmFrZXNoLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGFua3MgZm9yIHRoZSBzcGVlZHkgcmVwbHkuIE9uZSBmb2xsb3cgdXAgY29tbWVudCBiZWxv dy4gPG86cD4NCjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BbmRyZXc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPlJha2VzaCBHYW5kaGkgJmx0O3JnYW5kaGkuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJy Pg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgSmFudWFyeSAyMCwgMjAyMCBhdCA5OjQ5IEFNPGJyPg0K PGI+VG86IDwvYj4mcXVvdDtTdG9uZSwgQW5kcmV3IChOb2tpYSAtIENBL090dGF3YSkmcXVvdDsg Jmx0O2FuZHJldy5zdG9uZUBub2tpYS5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtwY2VA aWV0Zi5vcmcmcXVvdDsgJmx0O3BjZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ UmU6IFtQY2VdIEFkb3B0aW9uIG9mIGRyYWZ0LWxpLXBjZS1zci1iaWRpci1wYXRoLTA2PzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpIEFuZHJldyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91IGZvciB5b3VyIHJldmlldyBjb21tZW50cy4gUGxlYXNl IHNlZSBzb21lIGNvbW1lbnRzIGlubGluZSB3aXRoICZsdDtSRyZndDsuDQo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwgSmFuIDE5LCAyMDIwIGF0 IDU6NTcgUE0gU3RvbmUsIEFuZHJldyAoTm9raWEgLSBDQS9PdHRhd2EpICZsdDs8YSBocmVmPSJt YWlsdG86YW5kcmV3LnN0b25lQG5va2lhLmNvbSI+YW5kcmV3LnN0b25lQG5va2lhLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+SGkgUENFIFdHIGFuZCBBdXRob3JzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkl0J3MgcG9zc2libGUgc29tZSBvZiB0aGVzZSBpdGVt cyBoYXZlIGJlZW4gZGlzY3Vzc2VkIHByaW9yIHRvIG1lIGZvbGxvd2luZyB0aGUgV0csIHNvIGFw b2xvZ2llcyBpbiBhZHZhbmNlIGlmIHRoYXQncyB0aGUgY2FzZS4gU29tZSBxdWVzdGlvbnMvY29t bWVudHMgcmVnYXJkaW5nIHRoZSBkb2N1bWVudDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0Omw2IGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij5BZ3JlZSwgUENFUCBkZWZpbml0aW9uL3N1cHBvcnQgZm9yIFNSIEJpLWRpciBhc3Nv Y2lhdGVkIExTUHMgaXMgbmVlZGVkIGZlYXR1cmUgc2V0IGFuZCB3b3JrIHRvIGJlIGNvdmVyZWQg YnkgdGhlIFdHPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtSRyZn dDsgR3JlYXQsIHRoYW5rcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsNCBsZXZlbDEgbGZvMiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+Rm9yIGJpZGlyZWN0aW9uYWwgYXNzb2NpYXRpbmcgdHdvIExTUHMs IGRvZXMgUENDL1BDRSBuZWVkIGFuIGFkZGl0aW9uYWwgd2F5IHRvIGRpc3Rpbmd1aXNoIHdoZXRo ZXIgaXQncyBhbiBTUiBvciBhbiBSU1ZQIGJpZGlyZWN0aW9uYWwgYXNzb2NpYXRpb24/IFdvdWxk IHRoYXQgbm90IGJlIGltcGxpY2l0IGJhc2VkIG9uIHRoZSBwYXRoIHNldHVwIHR5cGUgb2YgdGhl IExTUHMgd2hpY2ggaGF2ZQ0KIGJlZW4gYXNzb2NpYXRlZCB0b2dldGhlcj8gSW4gb3RoZXIgd29y ZHMsIGRvIHdlIGFjdHVhbGx5IG5lZWQgZG91YmxlLXNpZGVkIGJpZGlyZWN0aW9uYWwgU1IgYXNz b2NpYXRpb24gZ3JvdXAgb2JqZWN0IGRlZmluZWQ/IGRyYWZ0LWxpLXBjZS1zci1iaWRpci1wYXRo LTA2IHNlZW1zIHRvIGltcGx5IHRoZSBiZWhhdmlvciBpcyBiYXNpY2FsbHkgdGhlIHNhbWUgYXMg TVBMUy1URSAobWludXMgdGhlIFJTVlAgc2lnbmFsbGluZyBvZiBjb3Vyc2UpIGFuZA0KIHRoZSBv YmplY3QgZW5jb2RpbmcgaXMgdGhlIHNhbWUsIHNvIGRvZXMgeWV0LWFub3RoZXIgb2JqZWN0IG5l ZWQgdG8gYmUgZGVmaW5lZD8gRnJvbSBhIFBDRVAgbWVzc2FnZSBlbmNvZGluZyBwLm8udiB3aXRo aW4gYW4gYXNzb2NpYXRpb24gb2JqZWN0IHN0cnVjdHVyZSwgYXJlIDIgU1IgTFNQcyB0aGF0IGRp ZmZlcmVudCB0aGFuIGFzc29jaWF0aW5nIDIgUlNWUCBMU1BzPzxvOnA+PC9vOnA+PC9zcGFuPjwv bGk+PC91bD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtSRyZndDsgTWFpbiBkaWZmZXJlbmNlIGlzIHRoYXQg aW4gY2FzZSBvZiBSU1ZQLVRFLCB0aGUgZWdyZXNzIG5vZGUgbGVhcm5zIHRoZSByZXZlcnNlIExT UCB2aWEgUlNWUCBzaWduYWxpbmcgd2hlcmVhcyBpbiBjYXNlIG9mIFNSLCB0aGUgZWdyZXNzIG5v ZGUgbGVhcm5zIHRoZSByZXZlcnNlIExTUCB2aWEgUENFLg0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZsdDtBbmRyZXcmZ3Q7IFllcywgSSByZWFsaXplIHRoYXQsIGhvd2V2ZXIgdGhlIGFzc29j aWF0aW9uIHN0cnVjdHVyZSBpcyBhYm91dCBpbmZvcm1pbmcgUENFIHRvIGFzc29jaWF0ZSB0d28g TFNQcyB0b2dldGhlciwgaXMgaXQgbm90PyBJdOKAmXMgbm90IHJlbGF0ZWQgdG8gaG93IDIgTFNQ cyBsZWFybiBlYWNoIG9wcG9zaXRlIHJldmVyc2UgcGF0aC4gVG8gYmUgc3BlY2lmaWMsIG15IGNv bW1lbnQgaXMgcmVnYXJkaW5nIHNlY3Rpb24NCiAzLjEuIFRvIGluc3RydWN0IFBDRSDigJxtYWtl IHRoZXNlIDIgYmlkaXJlY3Rpb25hbOKAnSBpcyBhIHNlcGFyYXRlIHRhc2sgdGhhbiBob3cgdGhl IExTUHMgbGVhcm4gb2YgZWFjaCBvdGhlcuKAmXMgcmV2ZXJzZSBMU1AgYW5kIHBhdGggaW4gbXkg b3Bpbmlvbi4gU28gdG8gaW5mb3JtIFBDRSDigJx0aGVzZSAyIExTUHMgYXJlIGJpZGlyZWN0aW9u YWwsIG1ha2UgdGhlbSBzb+KAnSBpcyB0aGUgc2FtZSBpbnN0cnVjdGlvbiBpcnJlbGV2YW50IG9m IGhvdyBlYWNoDQogTFNQIGxlYXJucyBvZiBlYWNoIG90aGVycyBwYXRoLiBGb3IgU1IsIHllcyB0 aGVyZSBpcyB0aGUgYWRkZWQgcHJvY2VzcyB3aGVyZSBQQ0UgbWF5IG5lZWQgdG8gdGVsbCB0aGUg UENDIHRoZSBvcHBvc2l0ZSBwYXRoLCBidXQgdGhhdCBkZWNpc2lvbiBpcyBhIGJlaGF2aW91ciBw b3N0LWFzc29jaWF0aW9uIGJlaW5nIHByb3ZpZGVkLCB3aGljaCBjYW4gYmUgZGV0ZXJtaW5lZCBh cyBuZWNlc3NhcnkgYnkgdGhlIExTUCBwYXRoIHNldHVwIHR5cGUgb2YNCiB0aGUgYXNzb2NpYXRl ZCBMU1BzLiBTbyBpZiB0aGUgZ29hbCBvZiB0byBpbnN0cnVjdCBQQ0Ug4oCcdGhlc2UgMiBMU1Bz IGFyZSBiaWRpcmVjdGlvbmFs4oCdLCB0aGF0IGluc3RydWN0aW9uIGlzIGNvbW1vbiBiZXR3ZWVu IExTUHMgd2hldGhlciB0aGV5IGFyZSBSU1ZQIG9yIFNSLiBFc3NlbnRpYWxseSBkZWZpbmluZyAn RG91YmxlLXNpZGVkIEJpZGlyZWN0aW9uYWwgU1IgUGF0aCBBc3NvY2lhdGlvbiBHcm91cCcgaXMg bm90IHJlcXVpcmVkICh1bmxlc3MNCiB0aGVyZeKAmXMgc29tZXRoaW5nIGVsc2UgaW4gdGhhdCBv YmplY3Qgd2UgZm9yZXNlZSBiZWluZyBzcGVjaWZpYyB0byBTUiBpbiB0aGUgZnV0dXJlKS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw3IGxldmVsMSBsZm8zIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5XaGlsZSBJIGNhbiBhcHByZWNpYXRlIHRoZSBuZWVk IGZvciB0ZXh0dWFsIGNsYXJpdHksIGFuZCBwZXJoYXBzIEknbSBtaXNzaW5nIHNvbWV0aGluZywg YnV0IGZvciBzb21lIHJlYXNvbiBJIGZpbmQgc2VjdGlvbnMgMSwgMywgYW5kIDQgcXVpdGUgdmVy Ym9zZSB0byBlc3NlbnRpYWxseSBzYXkgYXQgaXQncyBjb3JlOiAmcXVvdDt1c2UgdGhlIG9iamVj dHMgZGVmaW5lZCBpbiBkcmFmdC1pZXRmLXBjZS1hc3NvY2lhdGlvbi1iaWRpciwNCiBleGNlcHQg dXNlIHRoaXMgbmV3IHZhbHVlIHR5cGUgZG91YmxlLXNpZGVkLWJpZGlyZWN0aW9uYWwtc3IgaW5z dGVhZC4gWW91IGNhbiBhbHNvIHVzZSBwYXRoIHNlZ21lbnQmcXVvdDsuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsNSBsZXZlbDEgbGZvNCI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SW4gU2VjdGlvbiA1IEkgd291bGQgcHJlZmVy IHRoZSBkb2N1bWVudCB3b3VsZCBzYXk8aT4gJnF1b3Q7dGhlcmUgYXJlIHVzZSBjYXNlcyB3aGlj aCByZXF1aXJlIHRoZSBQQ0MgdG8gYmUgYXdhcmUgb2YgdGhlIHJldmVyc2UgZGlyZWN0aW9uIFNS IHBhdGguIEEgUENFIE1BWSBpbmZvcm0gdGhlIHJldmVyc2UgU1IgUGF0aHMgdG8gdGhlIGluZ3Jl c3MgUENDcyBhbmQgdmljZSB2ZXJzYSBpbiBvcmRlciB0bw0KIHByb3ZpZGUgZnVuY3Rpb25hbGl0 eSBmb3IgdGhvc2UgdXNlIGNhc2VzJnF1b3Q7PC9pPi4gQXNzb2NpYXRpbmcgdHdvIExTUHMgdG9n ZXRoZXIgYW5kIG5ldmVyIGluZm9ybWluZyB0aGVtIG9mIGVhY2ggb3RoZXJzIHJldmVyc2UgcGF0 aCBpcyBhIHZhbGlkLCBzaW1wbGUgdXNlIGNhc2UuIFRoZXJlZm9yZSBoYXZpbmcgUENDIGluZm9y bWVkIG9mIHRoZSByZXZlcnNlIHBhdGggdG8gYWNoaWV2ZSBmdXJ0aGVyIHVzZSBjYXNlcyBpcyB0 cnVseSAmcXVvdDtPUFRJT05BTCZxdW90Ow0KIGluIG15IG9waW5pb24uPG86cD48L286cD48L3Nw YW4+PC9saT48L3VsPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0O1JHJmd0OyBBZ3JlZS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9 ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBs ZXZlbDEgbGZvNSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+UmVsYXRlZCB0byBw cmV2aW91cyBwb2ludCwgbXkgcHJlZmVyZW5jZSB3b3VsZCBiZSBmb3IgcmVmZXJlbmNlcyB0byBw Y2Utc3ItcGF0aC1zZWdtZW50IGJlIGNvbnNpZGVyZWQgYXMgYSBNQVksIGFzIHRoZXJlIGlzbid0 IGEgbmVlZCBmb3IgcGF0aC1zZWdtZW50IGluIGEgYmFzaWMgY2FzZSBvZiBhc3NvY2lhdGluZyBi aS1kaXJlY3Rpb25hbCBMU1BzIGZvciBQQ0UgdG8gbWFuYWdlL2NvbXB1dGUNCiBiaS1kaXJlY3Rp b25hbCBwYXRocyBmb3IuPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jmx0O1JHJmd0OyBBZ3JlZS4gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwzIGxldmVsMSBsZm82Ij4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij5TZWN0aW9uIDUgSSB0aGluayBuZWVkcyBhIGJpdCBtb3JlIGRpc2N1 c3Npb246PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHVsIHR5cGU9ImRpc2MiPg0KPHVs IHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNr O21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0OmwzIGxldmVsMiBsZm82Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5JIGFn cmVlIHRoZSBQQ0Mgc2hvdWxkIG5vdCBpbnN0YW50aWF0ZSB0aGUgcmV2ZXJzZSBwYXRoLCBidXQg aXQncyBub3Qgc3RhdGVkIGhvdyB0byBtYWtlIHRoaXMgZGVjaXNpb24uIEkgYXNzdW1lIHRoaXMg aXMgZWFzeSBlbm91Z2ggdG8gZGVjaWRlIHdpdGggdGhlIHJldmVyc2UgKHIpIGJpdCBpbiB0aGUg YXNzb2NpYXRpb24gb2JqZWN0PyBNaWdodCBiZSB3b3J0aCBtZW50aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvbGk+PC91bD4NCjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7UkcmZ3Q7IE9rLiA8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjx1bCB0 eXBlPSJkaXNjIj4NCjx1bCB0eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDIgbGZvNyI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+aW5kaWNhdGVzIFBDRSBuZWVkcyB0byBhbGxvY2F0ZSBhIFBMU1AtSUQgZm9y IHRoZSByZXZlcnNlIHBhdGggdG8gdGVsbCB0aGUgaW5ncmVzcyBQQ0MsIGR1ZSB0byBwb3RlbnRp YWwgUExTUElEIHNwYWNlIGNvbGxpc2lvbi4gUkZDIDgyMzEgJmFtcDsgUkZDODI4MSBoYXMgUEND IG93bmluZyB0aGUgUExTUC1JRC4gQXQgZmlyc3QgSSB3YXMgY29uZnVzZWQsIHRoZW4gcmVtZW1i ZXJlZCBhYm91dCBQQ0UNCiBDb250cm9sbGVkIElEIHNwYWNlIGRyYWZ0LiBJIHN1cHBvc2UgdGhp cyB0ZXh0IGlzIGEgY2Fycnkgb3ZlciBmcm9tIHBhdGggc2VnbWVudCBpbnRlZ3JhdGlvbiwgYnV0 IGxpLXBjZS1jb250cm9sbGVkLWlkLXNwYWNlIGlzIG5vdCByZWZlcmVuY2VkIGRpcmVjdGx5LCBt b3JlIHRyYW5zaXRpdmVseSB2aWEgcGF0aC1zZWdtZW50IHdoaWNoIGlzIG9ubHkgU0hPVUxEIGFz IGFuIGluY2x1c2lvbi4gTXkgcXVlc3Rpb24gaXMsIGlzIHRoZXJlIGFjdHVhbGx5DQogYSBuZWVk IHRvIHVzZSBQQ0UgQ29udHJvbGxlZCBJRCBzcGFjZSB0byBhY2hpZXZlIG5vdGlmeWluZyB0aGUg UENDIGFib3V0IHRoZSByZXZlcnNlIHBhdGg/IFdvdWxkIHRoZSBpbmRpY2F0aW9uIG9mICZxdW90 O1BDRS1pbml0ICYjNDM7IFIgYml0JnF1b3Q7IGJlIGVub3VnaCB0byBsZXQgUENDIGdlbmVyYXRl IHRoZSBQTFNQLUlEIGFuZCByZXBvcnQgaXQgYmFjaywgd2hpbGUgYWxzbyBub3QgaW5zdGFudGlh dGluZyB0aGUgcGF0aD8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDIgbGZvNyI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+UG9zc2libHkgZGVwZW5kaW5nIG9uIHRoZSBvdXRjb21lIG9mIHBy ZXZpb3VzIGNvbW1lbnQsIEkgd291bGQgcmVjb21tZW5kIHRoZSBkaWFncmFtcyBpbiA1LjEgYW5k IDUuMiBpbmNsdWRlIGV4YW1wbGUgUExTUC1JRHMuPG86cD48L286cD48L3NwYW4+PC9saT48L3Vs Pg0KPC91bD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtSRyZndDsgSSB3aWxsIGxldCBEaHJ1diBhbmQgb3Ro ZXIgY28tYXV0aG9ycyBjb21tZW50IG9uIHRoaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgeW91ciBzdXBwb3J0LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3Ms PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SYWtl c2g8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzgiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvbGk+PC91 bD4NCjwvdWw+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkluIGdlbmVyYWwgdGhpcyBkb2N1bWVudCBhcHBl YXJzIHRvIGJlIGEgZ29vZCBiYXNlIHRvIHdvcmsgZnJvbSB0byBhY2hpZXZlIGJpLWRpciBzciBh c3NvY2lhdGlvbi4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+U3VwcG9ydCBhZG9wdGlvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+QW5kcmV3 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIwIiB3 aWR0aD0iOTUlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV8tNjg5 ODk4NTM1ODcwMzU4MTA4NmRpdlJwbHlGd2RNc2ciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4gUGNlICZsdDs8YSBocmVmPSJtYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5wY2UtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBv Zg0KPGEgaHJlZj0ibWFpbHRvOmp1bGllbi5tZXVyaWNAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmp1bGllbi5tZXVyaWNAb3JhbmdlLmNvbTwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpqdWxp ZW4ubWV1cmljQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5qdWxpZW4ubWV1cmljQG9yYW5n ZS5jb208L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEphbnVhcnkgMTcsIDIwMjAg NToxMiBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnBjZUBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnBjZUBpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpwY2VAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5wY2VAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBbUGNlXSBBZG9wdGlvbiBvZiBkcmFmdC1saS1wY2Utc3ItYmlkaXItcGF0aC0wNj88 L3NwYW4+IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSBhbGwsPGJyPg0KPGJy Pg0KSXQgaXMgdGltZSB0byBzaGFyZSB5b3VyIHRob3VnaHRzIGFib3V0IGRyYWZ0LWxpLXBjZS1z ci1iaWRpci1wYXRoLTA2Ljxicj4NCkRvIHlvdSBiZWxpZXZlIHRoZSBJLUQgaXMgYSByaWdodCBm b3VuZGF0aW9uIGZvciBhIFBDRSBXRyBpdGVtPyBQbGVhc2U8YnI+DQp1c2UgdGhlIFBDRSBtYWls aW5nIGxpc3QgdG8gZXhwcmVzcyB5b3VyIGNvbW1lbnRzLCBzdXBwb3J0IG9yPGJyPg0KZGlzYWdy ZWVtZW50LCBpbmNsdWRpbmcgYXBwbGljYWJsZSByYXRpb25hbGUsIGVzcGVjaWFsbHkgZm9yIHRo ZSBsYXR0ZXIuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCjxicj4NCkRocnV2ICZhbXA7IEp1bGll bjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NClBjZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86UGNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+UGNlQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2U8L2E+PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_4EA592A4474947438255BFE7D296A61Cnokiacom_-- From nobody Mon Jan 20 09:48:40 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D931209F0 for ; Mon, 20 Jan 2020 09:48:38 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxP-gojOXObi for ; Mon, 20 Jan 2020 09:48:32 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5E5F1209F4 for ; Mon, 20 Jan 2020 09:48:31 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id z26so4100614lfg.13 for ; Mon, 20 Jan 2020 09:48:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JdqxdoRkh3548Y+3BHz7vbpKvt2H9G+0p6oFxpY799s=; b=gZtu2/MqS+sSw8cn3vRjZiqm2AQjO4YEQ9JVs7ORFImeWlotV7Hf/F2jaWXdkvi3Vu +272SppTMocVYfSUNnP08lhXw3YfmaPV+vgecJmm9vvaHFfPmYjk+Zo3Xo01U3J0tIKg 4qtGnT6M2jMGvJ3gJHeB8I3EFIKvVxO/Jph8UiBo9o0wgdZOlzObVyP2o5Al64Ax5F6t PyfijKVP5A8KDh/79w7IIGuvgg7tSc796fWW/biLuA6DF4aPKDAVtD8B3BcR74PkoIvL Hvf4Ri+7mOc4zAG4l3GUEOfdQKTkj+vnBILNsZKVeTWM2n+9jHx1/2ez+fDxRG7DMK9W ruRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JdqxdoRkh3548Y+3BHz7vbpKvt2H9G+0p6oFxpY799s=; b=Y3+0H0LJPuO01hlQR42XSjb+7898GAn1hJ9D9aAgeUHyIvdmRXSQ2w1FlbK3b+DqxT S3lbDscFZlXRDRlxPYlmWoavPu/Wu1Kpl49fwOWUdSJ/DRkBIv7uU9Zm7DX/lOMR9WM0 6c+7zCS+GVa54v2Z7LFuD6G6zSUMqUcEfnjL3ePc8Qc39h5VCTjoRpqpJgZIO8GINUuG 0pe3Abq/Kn7gCBoQv7BV4mz3+2wjgTD8ib8ZXbpS/kmc3WH2wSgyD3ecHNrq482dbv6t KUzmJx8KZiLRcH7RfdhbPGqgBBbCZ1eoFHN2X2uKi5fxQMu79bZGU3vV5b2jt7aOIkHk 2y+w== X-Gm-Message-State: APjAAAVas3hqsXyENgf/I+5fTMlITVwI0bxsh0CRA6Vd5LNY9Iwn2EN5 IgOmTn5CM8Dm8grL4SNlg3srwcygi0uqgDm58Qr1vyM= X-Google-Smtp-Source: APXvYqwPQnGUhS5DVMJiHuJbZdZ+RPbWlpBH6YHsorWEOCY9RK0c2wM0lEJ/KjstORXaERsw4fDrZFj6jLJYeqYEx18= X-Received: by 2002:ac2:4109:: with SMTP id b9mr254036lfi.9.1579542510169; Mon, 20 Jan 2020 09:48:30 -0800 (PST) MIME-Version: 1.0 References: <4EA592A4-4749-4743-8255-BFE7D296A61C@nokia.com> In-Reply-To: <4EA592A4-4749-4743-8255-BFE7D296A61C@nokia.com> From: Rakesh Gandhi Date: Mon, 20 Jan 2020 12:48:18 -0500 Message-ID: To: "Stone, Andrew (Nokia - CA/Ottawa)" Cc: "pce@ietf.org" Content-Type: multipart/alternative; boundary="00000000000039f09c059c95e672" Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 17:48:38 -0000 --00000000000039f09c059c95e672 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Andrew, Thank you for your comment. Yes, the point of using PST (SR/RSVP) was discussed during the early stage of the draft and was converged to define a new association type, specifically due to the extra requirements related to the reverse LSP for SR. I will let other co-authors comments further. Thanks, Rakesh On Mon, Jan 20, 2020 at 10:41 AM Stone, Andrew (Nokia - CA/Ottawa) < andrew.stone@nokia.com> wrote: > Hi Rakesh, > > > > Thanks for the speedy reply. One follow up comment below. > > > > Cheers > > Andrew > > > > *From: *Rakesh Gandhi > *Date: *Monday, January 20, 2020 at 9:49 AM > *To: *"Stone, Andrew (Nokia - CA/Ottawa)" > *Cc: *"pce@ietf.org" > *Subject: *Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? > > > > Hi Andrew, > > > > Thank you for your review comments. Please see some comments inline with > . > > > > On Sun, Jan 19, 2020 at 5:57 PM Stone, Andrew (Nokia - CA/Ottawa) < > andrew.stone@nokia.com> wrote: > > Hi PCE WG and Authors, > > > > It's possible some of these items have been discussed prior to me > following the WG, so apologies in advance if that's the case. Some > questions/comments regarding the document: > > - Agree, PCEP definition/support for SR Bi-dir associated LSPs is > needed feature set and work to be covered by the WG > > Great, thanks. > > > > > - For bidirectional associating two LSPs, does PCC/PCE need an > additional way to distinguish whether it's an SR or an RSVP bidirectio= nal > association? Would that not be implicit based on the path setup type o= f the > LSPs which have been associated together? In other words, do we actual= ly > need double-sided bidirectional SR association group object defined? > draft-li-pce-sr-bidir-path-06 seems to imply the behavior is basically= the > same as MPLS-TE (minus the RSVP signalling of course) and the object > encoding is the same, so does yet-another object need to be defined? F= rom a > PCEP message encoding p.o.v within an association object structure, ar= e 2 > SR LSPs that different than associating 2 RSVP LSPs? > > > > Main difference is that in case of RSVP-TE, the egress node learns > the reverse LSP via RSVP signaling whereas in case of SR, the egress node > learns the reverse LSP via PCE. > > > > Yes, I realize that, however the association structure is about > informing PCE to associate two LSPs together, is it not? It=E2=80=99s not= related > to how 2 LSPs learn each opposite reverse path. To be specific, my commen= t > is regarding section 3.1. To instruct PCE =E2=80=9Cmake these 2 bidirecti= onal=E2=80=9D is a > separate task than how the LSPs learn of each other=E2=80=99s reverse LSP= and path > in my opinion. So to inform PCE =E2=80=9Cthese 2 LSPs are bidirectional, = make them > so=E2=80=9D is the same instruction irrelevant of how each LSP learns of = each > others path. For SR, yes there is the added process where PCE may need to > tell the PCC the opposite path, but that decision is a behaviour > post-association being provided, which can be determined as necessary by > the LSP path setup type of the associated LSPs. So if the goal of to > instruct PCE =E2=80=9Cthese 2 LSPs are bidirectional=E2=80=9D, that instr= uction is common > between LSPs whether they are RSVP or SR. Essentially defining > 'Double-sided Bidirectional SR Path Association Group' is not required > (unless there=E2=80=99s something else in that object we foresee being sp= ecific to > SR in the future). > > > > > > > - While I can appreciate the need for textual clarity, and perhaps I'm > missing something, but for some reason I find sections 1, 3, and 4 qui= te > verbose to essentially say at it's core: "use the objects defined in > draft-ietf-pce-association-bidir, except use this new value type > double-sided-bidirectional-sr instead. You can also use path segment". > > > - In Section 5 I would prefer the document would say* "there are use > cases which require the PCC to be aware of the reverse direction SR pa= th. A > PCE MAY inform the reverse SR Paths to the ingress PCCs and vice versa= in > order to provide functionality for those use cases"*. Associating two > LSPs together and never informing them of each others reverse path is = a > valid, simple use case. Therefore having PCC informed of the reverse p= ath > to achieve further use cases is truly "OPTIONAL" in my opinion. > > > > Agree. > > > > > - Related to previous point, my preference would be for references to > pce-sr-path-segment be considered as a MAY, as there isn't a need for > path-segment in a basic case of associating bi-directional LSPs for PC= E to > manage/compute bi-directional paths for. > > > > Agree. > > > - Section 5 I think needs a bit more discussion: > > > - I agree the PCC should not instantiate the reverse path, but it's > not stated how to make this decision. I assume this is easy enough = to > decide with the reverse (r) bit in the association object? Might be= worth > mention. > > > > Ok. > > > - indicates PCE needs to allocate a PLSP-ID for the reverse path to > tell the ingress PCC, due to potential PLSPID space collision. RFC = 8231 & > RFC8281 has PCC owning the PLSP-ID. At first I was confused, then > remembered about PCE Controlled ID space draft. I suppose this text= is a > carry over from path segment integration, but li-pce-controlled-id-= space is > not referenced directly, more transitively via path-segment which i= s only > SHOULD as an inclusion. My question is, is there actually a need to= use PCE > Controlled ID space to achieve notifying the PCC about the reverse = path? > Would the indication of "PCE-init + R bit" be enough to let PCC gen= erate > the PLSP-ID and report it back, while also not instantiating the pa= th? > - Possibly depending on the outcome of previous comment, I would > recommend the diagrams in 5.1 and 5.2 include example PLSP-IDs. > > > > I will let Dhruv and other co-authors comment on this. > > > > Thanks for your support. > > > > Thanks, > > Rakesh > > > > > > > - > > > > In general this document appears to be a good base to work from to achiev= e > bi-dir sr association. > > > > Support adoption. > > > > Thanks > > Andrew > > > ------------------------------ > > *From:* Pce on behalf of julien.meuric@orange.com = < > julien.meuric@orange.com> > *Sent:* Friday, January 17, 2020 5:12 AM > *To:* pce@ietf.org > *Subject:* [Pce] Adoption of draft-li-pce-sr-bidir-path-06? > > > > Hi all, > > It is time to share your thoughts about draft-li-pce-sr-bidir-path-06. > Do you believe the I-D is a right foundation for a PCE WG item? Please > use the PCE mailing list to express your comments, support or > disagreement, including applicable rationale, especially for the latter. > > Thanks, > > Dhruv & Julien > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > --00000000000039f09c059c95e672 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Andrew,
Thank you for your comment. Yes,= the point of using PST (SR/RSVP) was discussed during the early stage of t= he draft and was converged to define a new association type, specifically d= ue to the extra requirements related to the reverse LSP for SR. I will let = other co-authors comments further.

Thanks,
Rakesh


On Mon, Jan 20, 2020 at 10:41 AM Stone, A= ndrew (Nokia - CA/Ottawa) <and= rew.stone@nokia.com> wrote:

Hi Rakesh,

=C2=A0

Thanks for the speedy reply. One follow up comment b= elow.

=C2=A0

Cheers

Andrew

=C2=A0

From: = Rakesh Gandhi <rgandhi.ietf@gmail= .com>
Date: Monday, January 20, 2020 at 9:49 AM
To: "Stone, Andrew (Nokia - CA/Ottawa)" <andrew.stone@nokia.com>= ;
Cc: "pce@ietf= .org" <pce@ie= tf.org>
Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?=

=C2=A0

Hi Andrew,

=C2=A0

Thank you for your review comments. Please see some = comments inline with <RG>.

=C2=A0

On Sun, Jan 19, 2020 at 5:57 PM Stone, Andrew (Nokia= - CA/Ottawa) <andrew.stone@nokia.com> wrote:

Hi PCE WG= and Authors,

=C2=A0=

It's = possible some of these items have been discussed prior to me following the = WG, so apologies in advance if that's the case. Some questions/comments= regarding the document:

  • Agree, PCEP definition/support for SR Bi-dir= associated LSPs is needed feature set and work to be covered by the WG<= /u>

<RG> Great, thanks.

=C2=A0

  • For bidirectional associating two LSPs, does= PCC/PCE need an additional way to distinguish whether it's an SR or an= RSVP bidirectional association? Would that not be implicit based on the pa= th setup type of the LSPs which have been associated together? In other words, do we actually need double-sided= bidirectional SR association group object defined? draft-li-pce-sr-bidir-p= ath-06 seems to imply the behavior is basically the same as MPLS-TE (minus = the RSVP signalling of course) and the object encoding is the same, so does yet-another object need to be def= ined? From a PCEP message encoding p.o.v within an association object struc= ture, are 2 SR LSPs that different than associating 2 RSVP LSPs?<= /u>

=C2=A0

<RG> Main difference is that in case of RSVP-T= E, the egress node learns the reverse LSP via RSVP signaling whereas in cas= e of SR, the egress node learns the reverse LSP via PCE.

=C2=A0

<Andrew> Yes, I realize that, however the asso= ciation structure is about informing PCE to associate two LSPs together, is= it not? It=E2=80=99s not related to how 2 LSPs learn each opposite reverse= path. To be specific, my comment is regarding section 3.1. To instruct PCE =E2=80=9Cmake these 2 bidirectional=E2=80=9D is a sep= arate task than how the LSPs learn of each other=E2=80=99s reverse LSP and = path in my opinion. So to inform PCE =E2=80=9Cthese 2 LSPs are bidirectiona= l, make them so=E2=80=9D is the same instruction irrelevant of how each LSP learns of each others path. For SR, yes there is the added process whe= re PCE may need to tell the PCC the opposite path, but that decision is a b= ehaviour post-association being provided, which can be determined as necess= ary by the LSP path setup type of the associated LSPs. So if the goal of to instruct PCE =E2=80=9Cthese 2 LS= Ps are bidirectional=E2=80=9D, that instruction is common between LSPs whet= her they are RSVP or SR. Essentially defining 'Double-sided Bidirection= al SR Path Association Group' is not required (unless there=E2=80=99s something else in that object we foresee being specific to= SR in the future).

=C2=A0

=C2=A0

  • While I can appreciate the need for textual = clarity, and perhaps I'm missing something, but for some reason I find = sections 1, 3, and 4 quite verbose to essentially say at it's core: &qu= ot;use the objects defined in draft-ietf-pce-association-bidir, except use this new value type double-sided-bidirectional-sr instead. You = can also use path segment".
  • In Section 5 I would prefer the document wou= ld say "there are use cases which require the PCC to be aware of th= e reverse direction SR path. A PCE MAY inform the reverse SR Paths to the i= ngress PCCs and vice versa in order to provide functionality for those use cases". Associating two LSPs = together and never informing them of each others reverse path is a valid, s= imple use case. Therefore having PCC informed of the reverse path to achiev= e further use cases is truly "OPTIONAL" in my opinion.

=C2=A0

<RG> Agree.

=C2=A0

  • Related to previous point, my preference wou= ld be for references to pce-sr-path-segment be considered as a MAY, as ther= e isn't a need for path-segment in a basic case of associating bi-direc= tional LSPs for PCE to manage/compute bi-directional paths for.

=C2=A0

<RG> Agree.

  • Section 5 I think needs a bit more discussio= n:
    • I agree the PCC should not instantiate the r= everse path, but it's not stated how to make this decision. I assume th= is is easy enough to decide with the reverse (r) bit in the association obj= ect? Might be worth mention.

=C2=A0

<RG> Ok.

    • indicates PCE needs to allocate a PLSP-ID fo= r the reverse path to tell the ingress PCC, due to potential PLSPID space c= ollision. RFC 8231 & RFC8281 has PCC owning the PLSP-ID. At first I was= confused, then remembered about PCE Controlled ID space draft. I suppose this text is a carry over from path s= egment integration, but li-pce-controlled-id-space is not referenced direct= ly, more transitively via path-segment which is only SHOULD as an inclusion= . My question is, is there actually a need to use PCE Controlled ID space to achieve notifying the PCC about t= he reverse path? Would the indication of "PCE-init + R bit" be en= ough to let PCC generate the PLSP-ID and report it back, while also not ins= tantiating the path?
    • Possibly depending on the outcome of previou= s comment, I would recommend the diagrams in 5.1 and 5.2 include example PL= SP-IDs.

=C2=A0

<RG> I will let Dhruv and other co-authors com= ment on this.

=C2=A0

Thanks for your support.

=C2=A0

Thanks,

Rakesh

=C2=A0

=C2=A0

    • =C2=A0

= =C2=A0

In genera= l this document appears to be a good base to work from to achieve bi-dir sr= association.=C2=A0

= =C2=A0

Support a= doption.

= =C2=A0

Thanks=

Andrew=

= =C2=A0

From: Pce <pce-bounces@ietf.org> on behalf of julien.meuric= @orange.com <julien.meuric@orange.com>
Sent: Friday, January 17, 2020 5:12 AM
To: pce@ietf.org <pce@ietf.org&g= t;
Subject: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? =

=C2=A0

Hi all,

It is time to share your thoughts about draft-li-pce-sr-bidir-path-06.
Do you believe the I-D is a right foundation for a PCE WG item? Please
use the PCE mailing list to express your comments, support or
disagreement, including applicable rationale, especially for the latter.
Thanks,

Dhruv & Julien

_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce

--00000000000039f09c059c95e672-- From nobody Mon Jan 20 10:16:49 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A99E612013D; Mon, 20 Jan 2020 10:16:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana via Datatracker To: "The IESG" Cc: draft-ietf-pce-stateful-flags@ietf.org, Hariharan Ananthakrishnan , pce-chairs@ietf.org, pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alvaro Retana Message-ID: <157954420268.1489.1166603703118243867.idtracker@ietfa.amsl.com> Date: Mon, 20 Jan 2020 10:16:42 -0800 Archived-At: Subject: [Pce] Alvaro Retana's Discuss on draft-ietf-pce-stateful-flags-00: (with DISCUSS and COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 18:16:43 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-pce-stateful-flags-00: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-flags/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The acknowledgement to the authors of I-D.ietf-pce-lsp-control-request prompted me to go take a look at that document and refresh my mind on the fact that it defines a new flag called LSP-Control Request Flag (C). I find it hard to resolve in my mind when it would make sense for the R (LSP REMOVE from rfc8281) and C flags to be set at the same time. I couldn't find in rfc8231/rfc8281/I-D.ietf-pce-lsp-control-request or this document any discussion about the ability (or not) to set more than one Flag at a time. In line with it's title, I would like to see this document include rules about processing of multiple flags. I know that it is not possible to set out rules for the interaction of yet-to-be-defined flags, but at least adding text to the effect of "documents defining additional flags MUST discuss how they interact with existing flags" would go a long way. I am balloting DISCUSS because even though this document is not introducing new issues, the combination of what is defined in rfc8231/rfc8281/I-D.ietf-pce-lsp-control-request does...and a document titled "Updated Rules for Processing Stateful PCE Request Parameters Flags" is then the optimal place to address them. [Aside: If this DISCUSS is resolved as suggested above, then I-D.ietf-pce-lsp-control-request, which is on the RFC EDitor's queue, will have to be updated.] ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) Compatibility The compatibility issue described at the end of §4 could result in all types of unforeseen errors or more serious issues; even considering just the one flag defined in rfc8281: the R flag = LSP REMOVE. One of the incompatibility results could be for an rfc8231-only implementation to set the R flag (it has unknown functionality to the sender), and then for an rfc8281 implementation to receive the object and remove the LSP. Not only could this result in operational issues by removing an LSP that shouldn't have been removed, but this action could also be considered a denial of service. This is not a new issue created by this document, but given that the latent compatibility issues are presented, then a more robust discussion is needed -- I would like to see it in the Security Considerations, but using the Compatibility Considerations section works for me too. To be clear on my expectation. The current text sounds tentative and even alarming: (paraphrasing) there's an issue that cannot be solved unless we start over! It would be nice to then add some text that talks about the potential effects: taking an unintended action, opening the door for an attacker, etc. (2) Going back to the specification: Flags (32 bits): This document does not define any flags. Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt. Implementations that do not understand any particular flag MUST ignore the flag. Aren't the two Normative sentences redundant? The most likely reason for a receiver to not understand a flag is for it to not have it implemented, which is the same as it considering it not assigned. Are there cases that I'm missing which require both statements? Perhaps s/Unassigned/Unknown and remove the second sentence. From nobody Mon Jan 20 11:32:34 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C851412080E for ; Mon, 20 Jan 2020 11:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oS1nJ2sbEEVI for ; Mon, 20 Jan 2020 11:32:31 -0800 (PST) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B174E12029C for ; Mon, 20 Jan 2020 11:32:30 -0800 (PST) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 00KJWSJh009992; Mon, 20 Jan 2020 19:32:28 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A79792203D; Mon, 20 Jan 2020 19:32:28 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id 9268C2203C; Mon, 20 Jan 2020 19:32:28 +0000 (GMT) Received: from LAPTOPK7AS653V (089144205018.atnat0014.highway.webapn.at [89.144.205.18]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 00KJWRou015733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Jan 2020 19:32:28 GMT Reply-To: From: "Adrian Farrel" To: , References: In-Reply-To: Date: Mon, 20 Jan 2020 19:32:26 -0000 Organization: Old Dog Consulting Message-ID: <00b101d5cfc8$597ab340$0c7019c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI0gUu9XpjujtRzkUKxxLPCC8Txgac2jdYA Content-Language: en-gb X-Originating-IP: 89.144.205.18 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25180.002 X-TM-AS-Result: No--18.828-10.0-31-10 X-imss-scan-details: No--18.828-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25180.002 X-TMASE-Result: 10--18.827800-10.000000 X-TMASE-MatchedRID: H0/uSqZo4D7xIbpQ8BhdbC2416nc3bQlpQH4ogtVQP24gUyzJIDbFvXn V44mE6yUp078PhLmGwxTH43EmpI1cEwY9Z3dse9+dhnFihmbnwWCF6GkB9h+D1rXKFPCbXO5jQb 0ZijHcXBpq/Er9D+P1MrfUyLxvEqvj3sw/AZYvXpO8qlnOXFSz5RRlLuwwc4YGUs9b7xvtJrLN4 d4W89LkTnIGY38z2oQ7divN/tLk8ym1xN/3Bsy6ao2fOuRT7aaMtYevQOP5TrfUZT83lbkECwUt K2Ys2wzs6021IZeYBRDFgc6TARRFplyY+LgWszf0ytzHp3p+JY5iooXtStiHsuSXx71bvSLalfY V8EiHsoZzx7bt3jdIh26ydae9BOyueEnIw0gB7Yk3NzXU7fmelsP0tBwe3qDmbdPE3zcujgnOWh ZYy8qHWTL9vAhYT6xBMzcvqnsksSMcenel/LSerzgL/eLACDEAgvM6h73Btps98Z8fG/6kRCnYZ Emcg0NXhCDErLauAC8yI8m8VRvvHdR7mzeevyFsmly7ZcJ2RwZskwWqoib3Kz+3yK6HknzUDGdb yXu/mbc55SBObubsTZTTnh0pe4Gj2hRzH1UwuA5f9Xw/xqKXVkMvWAuahr8i2QFaYS1v20qtq5d 3cxkNQwWxr7XDKH8lExlQIQeRG0= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 19:32:33 -0000 Hey Julien, WG, I have reviewed draft-li-pce-sr-bidir-path as part of the adoption poll and I have a few comments below. Overall, this seems like a simple combination of two existing functions: - associated bidirectional - SR So it should be straightforward and the function is clearly needed, and the working group should adopt it if there is enough support. Thanks, Adrian === Please (please, please) could author teams sort out their front page author list before requesting WG adoption. If the authors don't reduce themselves to a maximum of five, the chairs will have to do it, and I don't think anyone wants that! --- Abstract This document defines PCEP extensions for grouping two reverse unidirectional SR Paths into an Associated Bidirectional SR Path when using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs as well as when using a Stateless PCE. I don't think it is "two reverse unidirectional SR paths". One of them is normal and the other is reverse. So how about... This document defines PCEP extensions for grouping two unidirectional SR Paths (one in each direction in the network) into a single Associated Bidirectional SR Path. The mechanisms defined in this document can also be applied using a Stateful PCE for both PCE- Initiated and PCC-Initiated LSPs, as well as when using a Stateless PCE. --- Section 1 s/SR supports to steer packets/SR supports steering packets/ --- Section 1 Currently, SR networks only support unidirectional paths. However, bidirectional SR Paths are required in some networks, for example, in mobile backhaul transport networks. The requirement of bidirectional SR Path is specified in [I-D.ietf-spring-mpls-path-segment]. I suggest... SR is specified for unidirectional paths. However, some applications require bidirectional paths in SR networks, for example, in mobile backhaul transport networks. The requirement for bidirectional SR Paths is specified in [I-D.ietf-spring-mpls-path-segment]. --- Section 1 OLD [I-D.ietf-pce-association-bidir] defines PCEP extensions for grouping two reverse unidirectional MPLS TE LSPs into an Associated Bidirectional LSP when using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs as well as when using a Stateless PCE. NEW [I-D.ietf-pce-association-bidir] defines PCEP extensions for grouping two unidirectional MPLS TE LSPs into an Associated Bidirectional LSP when using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs as well as when using a Stateless PCE. END --- 3.1 and 7.1 Why do you need a new Association Type? If draft-ietf-pce-association-bidir was changes as: OLD Value Name Reference --------------------------------------------------------------------- TBD1 Single-sided Bidirectional LSP Association Group [This document] TBD2 Double-sided Bidirectional LSP Association Group [This document] NEW Value Name Reference --------------------------------------------------------------------- TBD1 Single-sided Bidirectional Association Group [This document] TBD2 Double-sided Bidirectional Association Group [This document] END ...then you could use the second of these for your use case. The type of path being associated would/should be the same for both paths in the association (but maybe there would be a future case with an LSP in one direction and an SR path in the other direction? but see section 5.3) and the type of path known from the PCEP message. --- Section 5 The PCE SHOULD inform the reverse SR Paths to the ingress PCCs and vice versa. Under what circumstance MAY the PCE choose to not do this? --- 5.3 and 7.2 Depending on how you handle the point for 3.1, you may need to fine tune this error code. One way approach might be to make a change to draft-ietf-pce-association-bidir as: OLD Error Type Description Reference ------------------------------------------------------------------- 29 Association Error Error value: TBD2 This document Bidirectional LSP Association - Path Setup Type Mismatch NEW Error Type Description Reference ------------------------------------------------------------------- 29 Association Error Error value: TBD2 This document Bidirectional Association - Path Setup Type Mismatch END --- Having made the suggestions for 3.1 and 5.3, I wonder how much is different from draft-ietf-pce-association-bidir. Is this just a small explanation of the use of that draft in the SR network --- You should explicitly reference the figures (by name) from the text. --- Thanks for Section 6. I find it really helpful. --- -----Original Message----- From: Pce On Behalf Of julien.meuric@orange.com Sent: 17 January 2020 10:13 To: pce@ietf.org Subject: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? Hi all, It is time to share your thoughts about draft-li-pce-sr-bidir-path-06. Do you believe the I-D is a right foundation for a PCE WG item? Please use the PCE mailing list to express your comments, support or disagreement, including applicable rationale, especially for the latter. Thanks, Dhruv & Julien From nobody Tue Jan 21 02:01:59 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F812120096 for ; Tue, 21 Jan 2020 02:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqIrhaMq3dLT for ; Tue, 21 Jan 2020 02:01:52 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C771200E6 for ; Tue, 21 Jan 2020 02:01:52 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id n21so2193136ioo.10 for ; Tue, 21 Jan 2020 02:01:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7YFUEqhqCLdovLPPaUmPbQ2neDWH1kcAizifjvziK/o=; b=nkoXAnv2fsrb8ROxGQIpmw+M8AQEnexe5nGVX2MC/nhXkRIZw4bHZgwbRMd5VyUQq0 d02VzQRz4t4fvLnccAudAdeLQT2mobw7JGfTrZokWv0lXceeupL+TwsPXaNrdXYzQLza rG2U/mW+pg9zsizF4sZ0wZ2u7q9v2IDPnxBnne1AEb8YnY09JzVG8pKN8sH3yCJFZcNP erWFI2HfsrpIWqiCl1x4D61uKnHZ4gH1FyuQUGbREfYsoC1Z4bPS/ALq66F+uAjLawMA /xkEel3Igf45B/XnB1wRvvgLoRsLQETIuYQ2BZ+FeMZX2t6+4z6AVY+yqYUgtdSBBObg 4Yow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7YFUEqhqCLdovLPPaUmPbQ2neDWH1kcAizifjvziK/o=; b=QXelHEcOK1NSP/YYGgGYlrBruZ9csUmPuHEuCUZMWNACzxHpjshqUgL0i0Z0YxDgeq YwhPhTMovKdau+ytR+/Jn9YbLvNa9iONzPLxQ1ahyXCTjaHilZtZMRYbFdKTfVHf6VqW cRSDk8Ua3rLTeedFX4fBZohMCCcf4df6h1/lROu3J7wvLfajvlS3d9LgE3kI9zfoBMh7 W9TrpvrONzsKWFTss2csjGLdUXQHBf6XF+vFR8nV9WwvWO3klJWJDOSKvTQZjUY8+jbA Q08snS60Q8XhuO1mcAz6Il0FI89t+XsM610I6VxbRztMASpO8MqID2/cS2JHwCKQFzK0 bDWQ== X-Gm-Message-State: APjAAAXK6HXRH1m1n77n4vxTbtP1fi/2e4sxY+55nn1Jv5YMmfirOGw4 tGpg8rX1hga9S5k4iyaqSiHvljsHw9k7txM/egI= X-Google-Smtp-Source: APXvYqzCeaUZfj81SsYORyTlidLylM/KiMb+WrgRSQ2//5ewpffqc1KZ+1IV5GudphjOVlSRlmrnHJhWbBekUJYN1Cc= X-Received: by 2002:a05:6638:2b7:: with SMTP id d23mr2563902jaq.108.1579600905976; Tue, 21 Jan 2020 02:01:45 -0800 (PST) MIME-Version: 1.0 References: <4EA592A4-4749-4743-8255-BFE7D296A61C@nokia.com> In-Reply-To: <4EA592A4-4749-4743-8255-BFE7D296A61C@nokia.com> From: Dhruv Dhody Date: Tue, 21 Jan 2020 15:31:09 +0530 Message-ID: To: "Stone, Andrew (Nokia - CA/Ottawa)" Cc: Rakesh Gandhi , "pce@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 10:01:58 -0000 Hi Andrew, Speaking as a WG contributor and snipping to - > For bidirectional associating two LSPs, does PCC/PCE need an additional w= ay to distinguish whether it's an SR or an RSVP bidirectional association? = Would that not be implicit based on the path setup type of the LSPs which h= ave been associated together? In other words, do we actually need double-si= ded bidirectional SR association group object defined? draft-li-pce-sr-bidi= r-path-06 seems to imply the behavior is basically the same as MPLS-TE (min= us the RSVP signalling of course) and the object encoding is the same, so d= oes yet-another object need to be defined? From a PCEP message encoding p.o= .v within an association object structure, are 2 SR LSPs that different tha= n associating 2 RSVP LSPs? > > > > Main difference is that in case of RSVP-TE, the egress node learns t= he reverse LSP via RSVP signaling whereas in case of SR, the egress node le= arns the reverse LSP via PCE. > > > > Yes, I realize that, however the association structure is about = informing PCE to associate two LSPs together, is it not? It=E2=80=99s not r= elated to how 2 LSPs learn each opposite reverse path. To be specific, my c= omment is regarding section 3.1. To instruct PCE =E2=80=9Cmake these 2 bidi= rectional=E2=80=9D is a separate task than how the LSPs learn of each other= =E2=80=99s reverse LSP and path in my opinion. So to inform PCE =E2=80=9Cth= ese 2 LSPs are bidirectional, make them so=E2=80=9D is the same instruction= irrelevant of how each LSP learns of each others path. For SR, yes there i= s the added process where PCE may need to tell the PCC the opposite path, b= ut that decision is a behaviour post-association being provided, which can = be determined as necessary by the LSP path setup type of the associated LSP= s. So if the goal of to instruct PCE =E2=80=9Cthese 2 LSPs are bidirectiona= l=E2=80=9D, that instruction is common between LSPs whether they are RSVP o= r SR. Essentially defining 'Double-sided Bidirectional SR Path Association = Group' is not required (unless there=E2=80=99s something else in that objec= t we foresee being specific to SR in the future). > I remember this being discussed in the mailing list, and the decision was that there are enough of a difference between the processing of double-sided bi-directional for RSVP-TE and SR paths to have different association types for the ease of implementation. Implementers were also worried that the PST of the first LSP that joins the associations would decide the next action and could lead to issues. In case one tried to add SR and RSVP-TE path in one association, where one peer may add SR first and reject RSVP-TE and other pcep peer may add RSVP-TE first and reject SR and there could be some mismatch. This was done mainly for the ease of implementations. Thanks! Dhruv From nobody Tue Jan 21 10:36:16 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1126120047 for ; Tue, 21 Jan 2020 10:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGSlr7pAKe94 for ; Tue, 21 Jan 2020 10:36:09 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60121.outbound.protection.outlook.com [40.107.6.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD4E212003F for ; Tue, 21 Jan 2020 10:36:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IFWz8pBRShpQ76n+hxfekVPB3WS0eXBYX5zw4KSXFAIC78HdxWm1hWF0iFB6omTTlu3WBVeEKggo/7WWbCYSYo0QnCN7dF783jyON09o/clc9Cq0GnMHG3xrEfTGB70UDZKUzzYkbyLxgf9pdXQz+VZsVYJit5BtbrvNQueSnoiJ38Y2AtZWCcpow+CdOQAUQ4bmqr7GdcelSu+3JgfXWBpIFIFXv0c53rfHQe+0lnNFtsfENPC+rvOJTJcJq6xl4JwBpo15frB1pgi6LqYVhhCDirE2xtnYHRIj1rV2QYZP7Zk2+N2LBT1Db+BQma8Sat7erHDyWDBqmJJbI6ijnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ykb5ZZ5+Q6OuC9KY/XDMEU9AoYcHo3MAUlT2m1zNonI=; b=SvmLOy2JkJzLZ7SIHg+e3u9YoqsuKN7Za6HH/ALXvdKA8sJH3oIXie8mcRIA9ZPk6yDabuXJLWr6eoZEFkGQJCmk7QHtlOHuQBYgFac6Z4Qw07m3Ev/LYKXY7Joq5jP4fmJa+67SyhPnjri4dIy/GcBX26sDPSdUnc1pM9cn+nI/bngZADOVPbGbHD9oOHXCcEwgAbWrPCIFt5LQErHmw2QjYZVOzPH0+hu5R2pElWQI4TibYYVo3ZkOoNp/1zBMCujI5sl8oy27aSIWEjpatVjysGCy/eR1mDuTrRMOqzhLZX/Mdl3FGbdWLBwjskw5FDFXX3/VDzxuCT5xFZYtaw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ykb5ZZ5+Q6OuC9KY/XDMEU9AoYcHo3MAUlT2m1zNonI=; b=MY4BHlrlBCdR002dHIR7k33Wjg4j+iJ4337NKavpAMLPEUT0WJs5uzDkS9JmnQgAmI5+ngmjVrv8/unTfM9wL89CZsKkv0rzC5hfrMJuZzXro0fhb25aZz1sAA1x26f68MweKyAHfqZcTZN8/qbi1rOTr6ap/j14N+tDu4c+0gQ= Received: from AM0PR0702MB3619.eurprd07.prod.outlook.com (52.133.46.160) by AM0PR0702MB3715.eurprd07.prod.outlook.com (52.133.46.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.14; Tue, 21 Jan 2020 18:36:06 +0000 Received: from AM0PR0702MB3619.eurprd07.prod.outlook.com ([fe80::4139:54b9:238:669c]) by AM0PR0702MB3619.eurprd07.prod.outlook.com ([fe80::4139:54b9:238:669c%7]) with mapi id 15.20.2665.015; Tue, 21 Jan 2020 18:36:06 +0000 From: "Stone, Andrew (Nokia - CA/Ottawa)" To: Dhruv Dhody CC: Rakesh Gandhi , "pce@ietf.org" Thread-Topic: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? Thread-Index: AQHVzR6uiqJrBBVhq0SzaEKl30U2oKfvvJyUgAPq14D//7q+AIABhvmAgAA8DwA= Date: Tue, 21 Jan 2020 18:36:06 +0000 Message-ID: <3587FF7A-97B3-43A4-B6B9-62197935B91F@nokia.com> References: <4EA592A4-4749-4743-8255-BFE7D296A61C@nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.stone@nokia.com; x-originating-ip: [135.245.20.27] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ecad6c8a-6a80-4a47-c97b-08d79ea0c6fe x-ms-traffictypediagnostic: AM0PR0702MB3715: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(376002)(136003)(346002)(39860400002)(366004)(199004)(189003)(478600001)(33656002)(5660300002)(186003)(2616005)(26005)(81156014)(2906002)(81166006)(8676002)(8936002)(54906003)(6512007)(316002)(6506007)(6486002)(64756008)(66446008)(76116006)(91956017)(86362001)(66556008)(71200400001)(6916009)(66946007)(66476007)(4326008)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0702MB3715; H:AM0PR0702MB3619.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /yMy83HWUd1wYxv2B8q7Nuq95FMKXgeZ36wY2XmSP1VYqKA3Hc8E4yeQ9+eN042SoE3d5amuvm0RyLBZh8oo75MCUR+SzATXjuV0yq6WVlV1arkU7KO6UFBAc59ySF5x8XqZOWx73oOWIBQayG4zZmHWDk9JUzoRb0O9CxJbSu5NRSCIH0H7kWNMV0DgAjuPJFcvtqbIDrztjS/EWj+hvKbIh/qTXkRYBRy2DDA9yjQD3Taa7cR7U2AchejZILt/qTePzOGaL6Y6lkHzIrlBBFpftAbC2fU5EJ9AKpqFx40Y5jCVTSVowKQR+BVMEP73OxNe7hnbSj6lxlt2RJaT8XsE8G2sG3Sq1XVc/xeKPYvTek6/5oQD+MYSh05oC8NRmig0te7MVGoU5Xhrr9PPCioUZOfv3ItjSwfJI8ANmzzqBeOiIpNlwLcyk7sHhXU6 x-ms-exchange-antispam-messagedata: 1h7ZAAjAWJSWMiSGuem+xv6BjmpUqTfMffHNkdphcfxV4Z/EQKSd9YCj5SYOCCl1hfPZB8+zZFoaQK+LRtRTiCkfxJUKseR4cMj8rWuK1UnUUkeV1ITzZ6PK/2CBo/vVj/ugHNirRkOC02qislejWg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: ecad6c8a-6a80-4a47-c97b-08d79ea0c6fe X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2020 18:36:06.5237 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jtDIaNeF0pMN8zUoUQV09zkMjBiPLrdxQvjldRFKg+ja8mGgf21OWxnkITSXZ9/IeukihWD5g4Kc0tm8vZ8aRw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0702MB3715 Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 18:36:15 -0000 SGkgRGhydXYsDQoNClRoYW5rcyBmb3IgdGhlIHJlcGx5IGFuZCBmZWVkYmFjay4gDQoNCkNvdWxk IGFuIGltcGxlbWVudGF0aW9uIG9mIFBDRSBub3Qgc2ltcGx5IGp1c3QgcmV0dXJuIGVycm9yIGR1 cmluZyB0aGF0IHNpdHVhdGlvbj8gSW4gZGl2ZXJzaXR5IGlmIHRvbyBtYW55IExTUHMgZ3JvdXBl ZCB0b2dldGhlciBhbmQgUENFIGNvbXB1dGF0aW9uYWxseSBjYW4ndCBzdXBwb3J0IGl0LCBpdCBy ZXR1cm5zIGEgUENFUlIuIFNvIEkgd291bGQgcmVhc29uIHRoYXQgaWYgYmlkaXJlY3Rpb25hbGx5 IGFzc29jaWF0ZWQgYW5kIG5vdGlmeSBQQ0NzIGlzIG5lY2Vzc2FyeSwgYnV0IHdhcyBjb25maWd1 cmVkIGJldHdlZW4gU1IgYW5kIFJTVlAsIHRoYXQncyBhbHNvIGFuIGVycm9yIGR1ZSB0byB0aGUg KGN1cnJlbnQpIHVuc3VwcG9ydGVkIGZlYXR1cmUgc2V0LiBJIHNlZSB0aGlzIGFzIHRyeWluZyB0 byBwcm90ZWN0IGFnYWluc3QgZGF5LTAgbWlzY29uZmlnIGJ5IGNoYW5naW5nIHRoZSB3aXJlIGVu Y29kaW5nIHdpdGhpbiB0aGUgcHJvdG9jb2wgKHdoaWNoIEknbSBub3QgbmVjZXNzYXJpbHkgYWdh aW5zdC4uKS4gV2hpbGUgSSBoYXZlIGRvdWJ0IGlmIGl0J3MgYSB2YWxpZCB1c2UgY2FzZSBvciBy ZXF1aXJlbWVudCBpbiBhIHByb2R1Y3Rpb24gZGVwbG95bWVudCwgYW5kIGl0IG1heSBoYXZlIGJl ZW4gYWNrbm93bGVkZ2VkIGJlZm9yZSwgYnV0IHRoaXMgZXNzZW50aWFsbHkgYmxvY2tzIGFzc29j aWF0aW5nIFNSIExTUCB3aXRoIFJTVlAgTFNQIGJpZGlyZWN0aW9uYWxseSBmb3IgUENFIHRvIGNv bXB1dGUuICANCg0KU2luY2UgdGhlIG92ZXJhbGwgd29ya2Zsb3cgZG9lc24ndCBjaGFuZ2UgYnkg dGhpcyBuZXcgdHlwZSBkZWYsIGFuZCBpZiBTUjwtPlJTVlAgYXNzb2NpYXRlZCBpcyBub3QgcmVh c29uYWJsZSByZXF1aXJlbWVudCwgYW5kIElmIGNvbnNlbnN1cyBoYXMgYWxyZWFkeSBiZWVuIHJl YWNoZWQgb24gdGhpcywgYW5kIGltcGxlbWVudGF0aW9uIGFscmVhZHkgZXhpc3QsIEknbSBva2F5 IHdpdGggcGFya2luZyB0aGlzIHRvcGljLiANCg0KU3RpbGwgaG9waW5nIGZvciBmZWVkYmFjayBy ZWdhcmRpbmcgbXkgY29tbWVudHMgb24gc2VjdGlvbiA1LiBJIHNlZSB0aGF0IGFzIGJlaW5nIG1v cmUgc2lnbmlmaWNhbnQsIHNpbmNlIGl0IGluZmx1ZW5jZXMgdGhlIHdvcmtmbG93IGFuZCBhdCB0 aGUgbW9tZW50IEkgZG9uJ3Qgc2VlIHRoZSBkZXBlbmRlbmN5IG9uIGRyYWZ0LWxpLXBjZS1jb250 cm9sbGVkLWlkLXNwYWNlIGFzIG5lY2Vzc2FyeSB0byBhY2hpZXZlIG5vdGlmeWluZyBQQ0NzIG9m IHJldmVyc2UgcGF0aHMuIA0KDQpUaGFua3MgYWdhaW4sDQpBbmRyZXcNCg0KIA0K77u/T24gMjAy MC0wMS0yMSwgNTowMSBBTSwgIkRocnV2IERob2R5IiA8ZGhydXYuaWV0ZkBnbWFpbC5jb20+IHdy b3RlOg0KDQogICAgSGkgQW5kcmV3LA0KICAgIA0KICAgIFNwZWFraW5nIGFzIGEgV0cgY29udHJp YnV0b3IgYW5kIHNuaXBwaW5nIHRvIC0NCiAgICANCiAgICANCiAgICA+IEZvciBiaWRpcmVjdGlv bmFsIGFzc29jaWF0aW5nIHR3byBMU1BzLCBkb2VzIFBDQy9QQ0UgbmVlZCBhbiBhZGRpdGlvbmFs IHdheSB0byBkaXN0aW5ndWlzaCB3aGV0aGVyIGl0J3MgYW4gU1Igb3IgYW4gUlNWUCBiaWRpcmVj dGlvbmFsIGFzc29jaWF0aW9uPyBXb3VsZCB0aGF0IG5vdCBiZSBpbXBsaWNpdCBiYXNlZCBvbiB0 aGUgcGF0aCBzZXR1cCB0eXBlIG9mIHRoZSBMU1BzIHdoaWNoIGhhdmUgYmVlbiBhc3NvY2lhdGVk IHRvZ2V0aGVyPyBJbiBvdGhlciB3b3JkcywgZG8gd2UgYWN0dWFsbHkgbmVlZCBkb3VibGUtc2lk ZWQgYmlkaXJlY3Rpb25hbCBTUiBhc3NvY2lhdGlvbiBncm91cCBvYmplY3QgZGVmaW5lZD8gZHJh ZnQtbGktcGNlLXNyLWJpZGlyLXBhdGgtMDYgc2VlbXMgdG8gaW1wbHkgdGhlIGJlaGF2aW9yIGlz IGJhc2ljYWxseSB0aGUgc2FtZSBhcyBNUExTLVRFIChtaW51cyB0aGUgUlNWUCBzaWduYWxsaW5n IG9mIGNvdXJzZSkgYW5kIHRoZSBvYmplY3QgZW5jb2RpbmcgaXMgdGhlIHNhbWUsIHNvIGRvZXMg eWV0LWFub3RoZXIgb2JqZWN0IG5lZWQgdG8gYmUgZGVmaW5lZD8gRnJvbSBhIFBDRVAgbWVzc2Fn ZSBlbmNvZGluZyBwLm8udiB3aXRoaW4gYW4gYXNzb2NpYXRpb24gb2JqZWN0IHN0cnVjdHVyZSwg YXJlIDIgU1IgTFNQcyB0aGF0IGRpZmZlcmVudCB0aGFuIGFzc29jaWF0aW5nIDIgUlNWUCBMU1Bz Pw0KICAgID4NCiAgICA+DQogICAgPg0KICAgID4gPFJHPiBNYWluIGRpZmZlcmVuY2UgaXMgdGhh dCBpbiBjYXNlIG9mIFJTVlAtVEUsIHRoZSBlZ3Jlc3Mgbm9kZSBsZWFybnMgdGhlIHJldmVyc2Ug TFNQIHZpYSBSU1ZQIHNpZ25hbGluZyB3aGVyZWFzIGluIGNhc2Ugb2YgU1IsIHRoZSBlZ3Jlc3Mg bm9kZSBsZWFybnMgdGhlIHJldmVyc2UgTFNQIHZpYSBQQ0UuDQogICAgPg0KICAgID4NCiAgICA+ DQogICAgPiA8QW5kcmV3PiBZZXMsIEkgcmVhbGl6ZSB0aGF0LCBob3dldmVyIHRoZSBhc3NvY2lh dGlvbiBzdHJ1Y3R1cmUgaXMgYWJvdXQgaW5mb3JtaW5nIFBDRSB0byBhc3NvY2lhdGUgdHdvIExT UHMgdG9nZXRoZXIsIGlzIGl0IG5vdD8gSXTigJlzIG5vdCByZWxhdGVkIHRvIGhvdyAyIExTUHMg bGVhcm4gZWFjaCBvcHBvc2l0ZSByZXZlcnNlIHBhdGguIFRvIGJlIHNwZWNpZmljLCBteSBjb21t ZW50IGlzIHJlZ2FyZGluZyBzZWN0aW9uIDMuMS4gVG8gaW5zdHJ1Y3QgUENFIOKAnG1ha2UgdGhl c2UgMiBiaWRpcmVjdGlvbmFs4oCdIGlzIGEgc2VwYXJhdGUgdGFzayB0aGFuIGhvdyB0aGUgTFNQ cyBsZWFybiBvZiBlYWNoIG90aGVy4oCZcyByZXZlcnNlIExTUCBhbmQgcGF0aCBpbiBteSBvcGlu aW9uLiBTbyB0byBpbmZvcm0gUENFIOKAnHRoZXNlIDIgTFNQcyBhcmUgYmlkaXJlY3Rpb25hbCwg bWFrZSB0aGVtIHNv4oCdIGlzIHRoZSBzYW1lIGluc3RydWN0aW9uIGlycmVsZXZhbnQgb2YgaG93 IGVhY2ggTFNQIGxlYXJucyBvZiBlYWNoIG90aGVycyBwYXRoLiBGb3IgU1IsIHllcyB0aGVyZSBp cyB0aGUgYWRkZWQgcHJvY2VzcyB3aGVyZSBQQ0UgbWF5IG5lZWQgdG8gdGVsbCB0aGUgUENDIHRo ZSBvcHBvc2l0ZSBwYXRoLCBidXQgdGhhdCBkZWNpc2lvbiBpcyBhIGJlaGF2aW91ciBwb3N0LWFz c29jaWF0aW9uIGJlaW5nIHByb3ZpZGVkLCB3aGljaCBjYW4gYmUgZGV0ZXJtaW5lZCBhcyBuZWNl c3NhcnkgYnkgdGhlIExTUCBwYXRoIHNldHVwIHR5cGUgb2YgdGhlIGFzc29jaWF0ZWQgTFNQcy4g U28gaWYgdGhlIGdvYWwgb2YgdG8gaW5zdHJ1Y3QgUENFIOKAnHRoZXNlIDIgTFNQcyBhcmUgYmlk aXJlY3Rpb25hbOKAnSwgdGhhdCBpbnN0cnVjdGlvbiBpcyBjb21tb24gYmV0d2VlbiBMU1BzIHdo ZXRoZXIgdGhleSBhcmUgUlNWUCBvciBTUi4gRXNzZW50aWFsbHkgZGVmaW5pbmcgJ0RvdWJsZS1z aWRlZCBCaWRpcmVjdGlvbmFsIFNSIFBhdGggQXNzb2NpYXRpb24gR3JvdXAnIGlzIG5vdCByZXF1 aXJlZCAodW5sZXNzIHRoZXJl4oCZcyBzb21ldGhpbmcgZWxzZSBpbiB0aGF0IG9iamVjdCB3ZSBm b3Jlc2VlIGJlaW5nIHNwZWNpZmljIHRvIFNSIGluIHRoZSBmdXR1cmUpLg0KICAgID4NCiAgICAN CiAgICBJIHJlbWVtYmVyIHRoaXMgYmVpbmcgZGlzY3Vzc2VkIGluIHRoZSBtYWlsaW5nIGxpc3Qs IGFuZCB0aGUgZGVjaXNpb24NCiAgICB3YXMgdGhhdCB0aGVyZSBhcmUgZW5vdWdoIG9mIGEgZGlm ZmVyZW5jZSBiZXR3ZWVuIHRoZSBwcm9jZXNzaW5nIG9mDQogICAgZG91YmxlLXNpZGVkIGJpLWRp cmVjdGlvbmFsIGZvciBSU1ZQLVRFIGFuZCBTUiBwYXRocyB0byBoYXZlIGRpZmZlcmVudA0KICAg IGFzc29jaWF0aW9uIHR5cGVzIGZvciB0aGUgZWFzZSBvZiBpbXBsZW1lbnRhdGlvbi4gSW1wbGVt ZW50ZXJzIHdlcmUNCiAgICBhbHNvIHdvcnJpZWQgdGhhdCB0aGUgUFNUIG9mIHRoZSBmaXJzdCBM U1AgdGhhdCBqb2lucyB0aGUgYXNzb2NpYXRpb25zDQogICAgd291bGQgZGVjaWRlIHRoZSBuZXh0 IGFjdGlvbiBhbmQgY291bGQgbGVhZCB0byBpc3N1ZXMuIEluIGNhc2Ugb25lDQogICAgdHJpZWQg dG8gYWRkIFNSIGFuZCBSU1ZQLVRFIHBhdGggaW4gb25lIGFzc29jaWF0aW9uLCB3aGVyZSBvbmUg cGVlcg0KICAgIG1heSBhZGQgU1IgZmlyc3QgYW5kIHJlamVjdCBSU1ZQLVRFIGFuZCBvdGhlciBw Y2VwIHBlZXIgbWF5IGFkZA0KICAgIFJTVlAtVEUgZmlyc3QgYW5kIHJlamVjdCBTUiBhbmQgdGhl cmUgY291bGQgYmUgc29tZSBtaXNtYXRjaC4gVGhpcyB3YXMNCiAgICBkb25lIG1haW5seSBmb3Ig dGhlIGVhc2Ugb2YgaW1wbGVtZW50YXRpb25zLg0KICAgIA0KICAgIFRoYW5rcyENCiAgICBEaHJ1 dg0KICAgIA0KDQo= From nobody Tue Jan 21 10:45:37 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66611209E2; Tue, 21 Jan 2020 10:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=KwwVeywz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=I02hH3xB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ydAQUdC3y5U; Tue, 21 Jan 2020 10:45:19 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52EE12008A; Tue, 21 Jan 2020 10:45:16 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1F0C921E56; Tue, 21 Jan 2020 13:45:16 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 21 Jan 2020 13:45:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=L V+uRJgCzttNimJrZDWPzYSmfd3jcAS5Pq3E96Hc6PE=; b=KwwVeywzoR1Bt26C9 DQxybx53EHESPgDSyr8f3T+aHTBFZoUJGPBGVBLjBxqxexSEYYs+X4o9oXGUVxvL HM0xTW17SP60dTAYJFWoQdjSXImuL1UVqYpAFK0L0xGodGOQH6ahLMwfb1zpKyUH lr3TrM5cuk8G8mpokmOsDKAZbv6+Xo+vZhennitsTUvAXUtnfHTCuaTM5b4Aj6pe d2T6kd60gh+Xui4iB7jhyQnLn7SMSs2kcjxbsRKhTNghJzXAMw7hUuHOuKjDmp9u 8+TgmPwikmgHvgGwEFxdihORtL8OEUEup7IK4eDfXOhHtTPxq0VDyqrAbvhtRGhQ nY0ng== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=LV+uRJgCzttNimJrZDWPzYSmfd3jcAS5Pq3E96Hc6 PE=; b=I02hH3xBAsWMWpCnbOXYOh62fiPObEfJZWNtoPq+iMk8zqiGnoWWun9hh z6lGSOxSXjJ79WYIeVjqpIXlloWrSl+4J13sfsbvk7zawPtBgyMsTn9/jzDGaj07 jR08LAKc7S53YXWYgChlFy/9+RrdnNFZY4fY4aqiYNp+9o3RGqEpY86cE8siFqeM G9csv7zuhgUeHS/xwQoXK7r3TDlDeapQBoA6mGNVZwm6Uz+UnsAmH5B4hBrDIbGA XEKEBVEgyPeOUvYAsA6HTMcoodqmfmoFX1//4sKNE24fXFrzWIrB5wkf9p8Cw/H4 c02Ch/q/oWsmp+H4GlWC1EZbB/1Ww== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudekgdduudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrjeeknecuvehluhhs thgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgrsegtoh hophgvrhifrdhinh X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.78]) by mail.messagingengine.com (Postfix) with ESMTPA id 7F1543280060; Tue, 21 Jan 2020 13:45:15 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <157626524556.12921.1549199517712582504@ietfa.amsl.com> Date: Tue, 21 Jan 2020 13:45:11 -0500 Cc: gen-art@ietf.org, last-call@ietf.org, pce@ietf.org, draft-ietf-pce-stateful-flags.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5792D3A8-7BBF-4840-8789-B6B420C3D3C8@cooperw.in> References: <157626524556.12921.1549199517712582504@ietfa.amsl.com> To: Russ Housley X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Pce] [Gen-art] Genart last call review of draft-ietf-pce-stateful-flags-00 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 18:45:25 -0000 Russ, thank you for your review. I entered a No Objection ballot. Alissa > On Dec 13, 2019, at 2:27 PM, Russ Housley via Datatracker = wrote: >=20 > Reviewer: Russ Housley > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at > . >=20 > Document: draft-ietf-pce-stateful-flags-00 > Reviewer: Russ Housley > Review Date: 2019-12-13 > IETF LC End Date: 2019-12-23 > IESG Telechat date: Unknown >=20 >=20 > Summary: Ready >=20 > Major Concerns: None. >=20 >=20 > Minor Concerns: None. >=20 >=20 > Nits: None. >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Jan 21 16:20:08 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4418E120018; Tue, 21 Jan 2020 16:20:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-pce-stateful-flags@ietf.org, Hariharan Ananthakrishnan , pce-chairs@ietf.org, hari@netflix.com, pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <157965240227.28983.6586692675642034521.idtracker@ietfa.amsl.com> Date: Tue, 21 Jan 2020 16:20:02 -0800 Archived-At: Subject: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-stateful-flags-00: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 00:20:02 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-pce-stateful-flags-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-flags/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this clear and well-written document! I just have a couple of editorial comments that probably don't even need a response. Section 4 There will remain an issue with compatibility between implementations of RFC 8231 that might set any of the unassigned flags, and current (such as [RFC8281]) and future (such as [I-D.ietf-pce-lsp-control-request]) specifications. That problem cannot be fixed in old implementations by any amount of documentation, and can only be handled for future specifications by obsoleting the Flags field and using a new technique. Fortunately, however, most implementations will have been constructed to set unused flags to zero which is consistent with the behavior described in this document. I had a little bit of trouble reading this, as I keep expecting the first sentence to be saying that there is a legitimately-allocated flag value that is set with intent to change behavior, but it doesn't really say anything specifically about a flag value getting allocated (or used). W.r.t. obsoleting Flags vs. relying on "most implementations" to be consistent with this document's recommendations, is it worth being more clear about the conclusion that this document is drawing, namely that the risk of bad interactions is sufficiently small that there is no desire to incur the cost of obsoleting/replacing the Flags field? From nobody Tue Jan 21 16:30:57 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4121200A1 for ; Tue, 21 Jan 2020 16:30:55 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieu0hEIM29su for ; Tue, 21 Jan 2020 16:30:54 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B093D120018 for ; Tue, 21 Jan 2020 16:30:53 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id r14so3900838lfm.5 for ; Tue, 21 Jan 2020 16:30:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q9GjMTSPRRurqMFrRwlQRvl+gV6hnWbvMo00feO3aCY=; b=YtyiKtuHnVpaR12eb6SJlKAwS3qALU7eXsp9vtYfLYh8Xiazs3AGm32qpUxJfLB643 tDplgRFlA2JeyHPHo9cWKSqVcKb3YS11NVB7XeYqNT9s8NbDN3R0N5biPrZsKkTygf7O E3RfaQRx/qUZ92lreuYAEAb/YxuZ0rpMxKlQ2uvry/Cvza6Gg67J1lvIc6M99eDPkmrW q0SUc9Qr8R/bPqKJ06sFiH5jozTjzxanAI7VlBgpSZZnDg2NXeGHWl0Y62+liHmWm0De drohexu24PC2n6FdjlpifMMx+GGPEsngP6UbvPf3hvkQhHbZKu+sMzE12hvblR/IYGQf 55Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q9GjMTSPRRurqMFrRwlQRvl+gV6hnWbvMo00feO3aCY=; b=Vsp85+d0jI/rNpb2gA+TJo+bH6hNRyfrAA4IuDK99B3gnASZtM7MOgK/a2R8tAg2jk pQzwzjbnZS5NRVqgdOzsCgUjnzekX5QyEltGodrA0+LmqBfcAS2AOc4HBUFq6mz6l4Ey 5jTj5CfsJPQxSdIQMgpcIiPaHYIhK4KTi82UkbG59jxcRmNYPfOMCwXtm+xdIdDOQ12w 07vV3QdnYTqaKhr7Y6pwcR/meSI73hDQbDrNG74ovSHCZbNbBfJ3l/swqlp03Z+Zbn/b cPzUVOsnyEU0CItuZtCWzWv4n573BhCwd05PpjVQPtJR5DY/4cwC7fEnD62h5gm0epLw HCAQ== X-Gm-Message-State: APjAAAXEn0T/vvN+ZBCDO4vEIlaw1a2gOlwROPWQ4m/eOFqAK1NNnR4g LBfTVUfvUt/jcPWkoiYMRYXm2ZJhZBZnpTmgew== X-Google-Smtp-Source: APXvYqzQwRlgsnG2XArDJFeXCLytQfqBKfJEygy11R6Jt3MlOfQPGbD9o2I++zdvDoKz6rz698jFck7EcFmxUwqFhgE= X-Received: by 2002:a19:7d04:: with SMTP id y4mr206709lfc.111.1579653051732; Tue, 21 Jan 2020 16:30:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rakesh Gandhi Date: Tue, 21 Jan 2020 19:30:40 -0500 Message-ID: To: Julien Meuric Cc: "pce@ietf.org" Content-Type: multipart/alternative; boundary="000000000000045548059cafa334" Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 00:30:55 -0000 --000000000000045548059cafa334 Content-Type: text/plain; charset="UTF-8" Hi WG, Support (as a co-author) to make this a WG document. Thanks, Rakesh On Fri, Jan 17, 2020 at 5:12 AM wrote: > Hi all, > > It is time to share your thoughts about draft-li-pce-sr-bidir-path-06. > Do you believe the I-D is a right foundation for a PCE WG item? Please > use the PCE mailing list to express your comments, support or > disagreement, including applicable rationale, especially for the latter. > > Thanks, > > Dhruv & Julien > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --000000000000045548059cafa334 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi WG,

Support (as a co-auth= or) to make this a WG document.

Thanks,
= Rakesh


On Fri, Jan 17, 2020 at 5:12 AM <julien.meuric@orange.com> wrote:
=
Hi all,

It is time to share your thoughts about draft-li-pce-sr-bidir-path-06.
Do you believe the I-D is a right foundation for a PCE WG item? Please
use the PCE mailing list to express your comments, support or
disagreement, including applicable rationale, especially for the latter.
Thanks,

Dhruv & Julien


_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
--000000000000045548059cafa334-- From nobody Tue Jan 21 17:08:18 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63CE31200C4; Tue, 21 Jan 2020 17:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xv0eJlj6f2wx; Tue, 21 Jan 2020 17:08:15 -0800 (PST) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C2D01200C3; Tue, 21 Jan 2020 17:08:12 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 00M18APG007638; Wed, 22 Jan 2020 01:08:10 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 832062203B; Wed, 22 Jan 2020 01:08:10 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 6DF242203A; Wed, 22 Jan 2020 01:08:10 +0000 (GMT) Received: from LAPTOPK7AS653V (089144205018.atnat0014.highway.webapn.at [89.144.205.18]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 00M189GI026112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Jan 2020 01:08:09 GMT Reply-To: From: "Adrian Farrel" To: "'Benjamin Kaduk'" , "'The IESG'" Cc: , "'Hariharan Ananthakrishnan'" , , References: <157965240227.28983.6586692675642034521.idtracker@ietfa.amsl.com> In-Reply-To: <157965240227.28983.6586692675642034521.idtracker@ietfa.amsl.com> Date: Wed, 22 Jan 2020 01:08:08 -0000 Organization: Old Dog Consulting Message-ID: <01ab01d5d0c0$694f4a80$3beddf80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGVwRM+aR0Bc0s3Gd8LHtraiajqN6h19eWA Content-Language: en-gb X-Originating-IP: 89.144.205.18 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25182.003 X-TM-AS-Result: No--14.512-10.0-31-10 X-imss-scan-details: No--14.512-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25182.003 X-TMASE-Result: 10--14.511900-10.000000 X-TMASE-MatchedRID: eVEkOcJu0F7xIbpQ8BhdbPHkpkyUphL9ekMgTOQbVFtGM2uNXRqsUm4R Zq5Bvfozw/UM+vlRppuLv76tv2biYCo5AFN8VXjwQz/LkQyz8mY9e7UvbyNKcfOW/sUTBY7L1GW bKN8y66//FTSTt61fe5vKavz+aosbRXNf1eTQ0puqDSBu0tUhrxlKjo8zguyKAv57j5eT9BbX6a ILJJMXlwUBks9NZRM+tfo+cp8qv6v7IXgURPQAHEVOF9zLtdyMzgjA0fz2uiDAJMh4mAwEGyfdT kfaZpbHQOaAfcvrs37xHXxxAO/d2d/+vxvQP253kUvc5mAlMkFt/p7hYq0idEIvWnnxlDGfZS/C gJhZe5bi8zVgXoAltkWL4rBlm20vt7DW3B48kkErN8z0HohG3voLR4+zsDTtJC9jS54qtzVDXjk TIiVB5fsGhO/r7k86go20aeSJzdcWEdnqV6kVYw== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-stateful-flags-00: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 01:08:17 -0000 > Thanks for this clear and well-written document! I just have a couple > of editorial comments that probably don't even need a response. Thanks for reading, Ben. Every review comment deserves a response. > Section 4 > > There will remain an issue with compatibility between implementations > of RFC 8231 that might set any of the unassigned flags, and current > (such as [RFC8281]) and future (such as > [I-D.ietf-pce-lsp-control-request]) specifications. That problem > cannot be fixed in old implementations by any amount of > documentation, and can only be handled for future specifications by > obsoleting the Flags field and using a new technique. Fortunately, > however, most implementations will have been constructed to set > unused flags to zero which is consistent with the behavior described > in this document. > > I had a little bit of trouble reading this, as I keep expecting the > first sentence to be saying that there is a legitimately-allocated flag > value that is set with intent to change behavior, but it doesn't really > say anything specifically about a flag value getting allocated (or > used). How about this becomes... There will remain an issue with compatibility between implementations of RFC 8231 that might set any of the unassigned flags, and current (such as [RFC8281]) and future (such as [I-D.ietf-pce-lsp-control-request]) specifications that assign specific meanings to flags if set. > W.r.t. obsoleting Flags vs. relying on "most implementations" to be > consistent with this document's recommendations, is it worth being more > clear about the conclusion that this document is drawing, namely that > the risk of bad interactions is sufficiently small that there is no > desire to incur the cost of obsoleting/replacing the Flags field? How about OLD Fortunately, however, most implementations will have been constructed to set unused flags to zero which is consistent with the behavior described in this document. NEW Fortunately, however, most implementations will have been constructed to set unused flags to zero which is consistent with the behavior described in this document and so the risk of bad interactions is sufficiently small that there is no need to obsolete the existing Flags field. END Thanks, Adrian From nobody Tue Jan 21 18:32:11 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF9E1200C5 for ; Tue, 21 Jan 2020 18:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQHNFGNLMmds for ; Tue, 21 Jan 2020 18:32:07 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCD611200C4 for ; Tue, 21 Jan 2020 18:32:07 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 0A945F1E159EB920889A for ; Wed, 22 Jan 2020 02:32:02 +0000 (GMT) Received: from lhreml730-chm.china.huawei.com (10.201.108.81) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 22 Jan 2020 02:32:01 +0000 Received: from lhreml730-chm.china.huawei.com (10.201.108.81) by lhreml730-chm.china.huawei.com (10.201.108.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 22 Jan 2020 02:32:01 +0000 Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml730-chm.china.huawei.com (10.201.108.81) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Wed, 22 Jan 2020 02:32:01 +0000 Received: from DGGEML509-MBS.china.huawei.com ([169.254.4.95]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0439.000; Wed, 22 Jan 2020 10:31:55 +0800 From: "Chengli (Cheng Li)" To: "julien.meuric@orange.com" , "pce@ietf.org" Thread-Topic: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? Thread-Index: AQHVzR65Nj5U8qzCtEOh0ZdXLq1sQKf18JOw Date: Wed, 22 Jan 2020 02:31:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.229] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 02:32:09 -0000 SGkgUENFLA0KDQpzdXBwb3J0IGFzIGEgY28tYXV0aG9yLiANCg0KVGhhbmtzLA0KQ2hlbmcNCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGNlIFttYWlsdG86cGNlLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBqdWxpZW4ubWV1cmljQG9yYW5nZS5jb20NClNlbnQ6 IEZyaWRheSwgSmFudWFyeSAxNywgMjAyMCA2OjEzIFBNDQpUbzogcGNlQGlldGYub3JnDQpTdWJq ZWN0OiBbUGNlXSBBZG9wdGlvbiBvZiBkcmFmdC1saS1wY2Utc3ItYmlkaXItcGF0aC0wNj8NCg0K SGkgYWxsLA0KDQpJdCBpcyB0aW1lIHRvIHNoYXJlIHlvdXIgdGhvdWdodHMgYWJvdXQgZHJhZnQt bGktcGNlLXNyLWJpZGlyLXBhdGgtMDYuDQpEbyB5b3UgYmVsaWV2ZSB0aGUgSS1EIGlzIGEgcmln aHQgZm91bmRhdGlvbiBmb3IgYSBQQ0UgV0cgaXRlbT8gUGxlYXNlIHVzZSB0aGUgUENFIG1haWxp bmcgbGlzdCB0byBleHByZXNzIHlvdXIgY29tbWVudHMsIHN1cHBvcnQgb3IgZGlzYWdyZWVtZW50 LCBpbmNsdWRpbmcgYXBwbGljYWJsZSByYXRpb25hbGUsIGVzcGVjaWFsbHkgZm9yIHRoZSBsYXR0 ZXIuDQoNClRoYW5rcywNCg0KRGhydXYgJiBKdWxpZW4NCg0KDQo= From nobody Tue Jan 21 18:36:46 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBB0120178 for ; Tue, 21 Jan 2020 18:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLFEXbJB1B69 for ; Tue, 21 Jan 2020 18:36:42 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F65F1200C3 for ; Tue, 21 Jan 2020 18:36:42 -0800 (PST) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id BFD2BA3C1E13FBFC912B for ; Wed, 22 Jan 2020 02:36:40 +0000 (GMT) Received: from lhreml714-chm.china.huawei.com (10.201.108.65) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 22 Jan 2020 02:36:40 +0000 Received: from lhreml714-chm.china.huawei.com (10.201.108.65) by lhreml714-chm.china.huawei.com (10.201.108.65) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 22 Jan 2020 02:36:40 +0000 Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml714-chm.china.huawei.com (10.201.108.65) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Wed, 22 Jan 2020 02:36:39 +0000 Received: from DGGEML509-MBS.china.huawei.com ([169.254.4.95]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0439.000; Wed, 22 Jan 2020 10:36:36 +0800 From: "Chengli (Cheng Li)" To: Hariharan Ananthakrishnan CC: "pce@ietf.org" Thread-Topic: IPR Poll on draft-li-pce-sr-bidir-path-06 Thread-Index: AQHVzWRoSjGx261ekkaPMb9cJUyMp6fyz8KAgAMutcA= Date: Wed, 22 Jan 2020 02:36:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.229] Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB02897777dggeml509mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] IPR Poll on draft-li-pce-sr-bidir-path-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 02:36:45 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CB02897777dggeml509mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSGFyaSwNCg0KSSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiBhcHBsaWVzIHRvIHRoaXMgZG9j dW1lbnQuDQoNCkJlc3QgcmVnYXJkcywNCkNoZW5nDQoNCkZyb206IE1hY2ggQ2hlbg0KU2VudDog TW9uZGF5LCBKYW51YXJ5IDIwLCAyMDIwIDY6MDAgUE0NClRvOiBIYXJpaGFyYW4gQW5hbnRoYWty aXNobmFuIDxoYXJpQG5ldGZsaXguY29tPjsgQ2hlbmdsaSAoQ2hlbmcgTGkpIDxjaGVuZ2xpMTNA aHVhd2VpLmNvbT47IGNoZW5nd2VpcWlhbmdAY2hpbmFtb2JpbGUuY29tOyBMaXpoZW5iaW4gPGxp emhlbmJpbkBodWF3ZWkuY29tPjsgRG9uZ2ppZSAoSmltbXkpIDxqaWUuZG9uZ0BodWF3ZWkuY29t PjsgcmdhbmRoaUBjaXNjby5jb207IHhpb25nLnF1YW5AenRlLmNvbS5jbg0KQ2M6IHBjZUBpZXRm Lm9yZw0KU3ViamVjdDogUkU6IElQUiBQb2xsIG9uIGRyYWZ0LWxpLXBjZS1zci1iaWRpci1wYXRo LTA2DQoNCkhpIEhhcmksDQoNCkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgYXBwbGllcyB0byB0 aGlzIGRvY3VtZW50Lg0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQoNCkZyb206IEhhcmloYXJhbiBB bmFudGhha3Jpc2huYW4gW21haWx0bzpoYXJpQG5ldGZsaXguY29tXQ0KU2VudDogU2F0dXJkYXks IEphbnVhcnkgMTgsIDIwMjAgMjozMiBBTQ0KVG86IENoZW5nbGkgKENoZW5nIExpKSA8Y2hlbmds aTEzQGh1YXdlaS5jb208bWFpbHRvOmNoZW5nbGkxM0BodWF3ZWkuY29tPj47IE1hY2ggQ2hlbiA8 bWFjaC5jaGVuQGh1YXdlaS5jb208bWFpbHRvOm1hY2guY2hlbkBodWF3ZWkuY29tPj47IGNoZW5n d2VpcWlhbmdAY2hpbmFtb2JpbGUuY29tPG1haWx0bzpjaGVuZ3dlaXFpYW5nQGNoaW5hbW9iaWxl LmNvbT47IExpemhlbmJpbiA8bGl6aGVuYmluQGh1YXdlaS5jb208bWFpbHRvOmxpemhlbmJpbkBo dWF3ZWkuY29tPj47IERvbmdqaWUgKEppbW15KSA8amllLmRvbmdAaHVhd2VpLmNvbTxtYWlsdG86 amllLmRvbmdAaHVhd2VpLmNvbT4+OyByZ2FuZGhpQGNpc2NvLmNvbTxtYWlsdG86cmdhbmRoaUBj aXNjby5jb20+OyB4aW9uZy5xdWFuQHp0ZS5jb20uY248bWFpbHRvOnhpb25nLnF1YW5AenRlLmNv bS5jbj4NCkNjOiBwY2VAaWV0Zi5vcmc8bWFpbHRvOnBjZUBpZXRmLm9yZz4NClN1YmplY3Q6IElQ UiBQb2xsIG9uIGRyYWZ0LWxpLXBjZS1zci1iaWRpci1wYXRoLTA2DQoNCg0KSGkgQXV0aG9ycywN Cg0KDQoNCkluIHByZXBhcmF0aW9uIGZvciBXb3JraW5nIEdyb3VwIGFkb3B0aW9uIG9uIHRoaXMg ZHJhZnQsIEknZCBsaWtlIGFsbA0KDQphdXRob3JzIGFuZCBjb250cmlidXRvcnMgdG8gY29uZmly bSBvbiB0aGUgbGlzdCB0aGF0IHRoZXkgYXJlIGluIGNvbXBsaWFuY2UNCg0Kd2l0aCBJRVRGIElQ UiBydWxlcy4NCg0KDQoNClBsZWFzZSByZXNwb25kIChjb3B5aW5nIHRoZSBtYWlsaW5nIGxpc3Qp IHRvIHNheSBvbmUgb2Y6DQoNCg0KDQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIGFwcGxpY2Fi bGUgdG8gdGhpcyBkcmFmdCB0aGF0IHNob3VsZCBiZSBkaXNjbG9zZWQNCg0KaW4gYWNjb3JkYW5j ZSB3aXRoIElFVEYgSVBSIHJ1bGVzLg0KDQoNCg0KSSBhbSBhd2FyZSBvZiBJUFIgYXBwbGljYWJs ZSB0byB0aGlzIGRyYWZ0LCBhbmQgaXQgaGFzIGFscmVhZHkgYmVlbg0KDQpkaXNjbG9zZWQgdG8g dGhlIElFVEYuDQoNCg0KDQpJIGFtIGF3YXJlIG9mIElQUiBhcHBsaWNhYmxlIHRvIHRoaXMgZHJh ZnQsIGJ1dCB0aGF0IGhhcyBub3QgeWV0IGJlZW4NCg0KZGlzY2xvc2VkIHRvIHRoZSBJRVRGLiBJ IHdpbGwgd29yayB0byBlbnN1cmUgdGhhdCBpdCB3aWxsIGJlIGRpc2Nsb3NlZCBpbiBhDQoNCnRp bWVseSBtYW5uZXIuDQoNCg0KDQpUaGFua3MsDQoNCi0gSGFyaQ0K --_000_C7C2E1C43D652C4E9E49FE7517C236CB02897777dggeml509mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFu b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi XEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uSFRN TENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8iOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5IaSBIYXJpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiBhcHBsaWVzIHRvIHRoaXMgZG9jdW1lbnQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkNoZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBNYWNoIENoZW4NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEphbnVhcnkgMjAsIDIw MjAgNjowMCBQTTxicj4NCjxiPlRvOjwvYj4gSGFyaWhhcmFuIEFuYW50aGFrcmlzaG5hbiAmbHQ7 aGFyaUBuZXRmbGl4LmNvbSZndDs7IENoZW5nbGkgKENoZW5nIExpKSAmbHQ7Y2hlbmdsaTEzQGh1 YXdlaS5jb20mZ3Q7OyBjaGVuZ3dlaXFpYW5nQGNoaW5hbW9iaWxlLmNvbTsgTGl6aGVuYmluICZs dDtsaXpoZW5iaW5AaHVhd2VpLmNvbSZndDs7IERvbmdqaWUgKEppbW15KSAmbHQ7amllLmRvbmdA aHVhd2VpLmNvbSZndDs7IHJnYW5kaGlAY2lzY28uY29tOyB4aW9uZy5xdWFuQHp0ZS5jb20uY248 YnI+DQo8Yj5DYzo8L2I+IHBjZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogSVBS IFBvbGwgb24gZHJhZnQtbGktcGNlLXNyLWJpZGlyLXBhdGgtMDY8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SGkgSGFyaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkg YW0gbm90IGF3YXJlIG9mIGFueSBJUFIgYXBwbGllcyB0byB0aGlzIGRvY3VtZW50LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5NYWNoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSGFyaWhhcmFuIEFuYW50aGFrcmlzaG5hbiBbPGEg aHJlZj0ibWFpbHRvOmhhcmlAbmV0ZmxpeC5jb20iPm1haWx0bzpoYXJpQG5ldGZsaXguY29tPC9h Pl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgSmFudWFyeSAxOCwgMjAyMCAyOjMyIEFN PGJyPg0KPGI+VG86PC9iPiBDaGVuZ2xpIChDaGVuZyBMaSkgJmx0OzxhIGhyZWY9Im1haWx0bzpj aGVuZ2xpMTNAaHVhd2VpLmNvbSI+Y2hlbmdsaTEzQGh1YXdlaS5jb208L2E+Jmd0OzsgTWFjaCBD aGVuICZsdDs8YSBocmVmPSJtYWlsdG86bWFjaC5jaGVuQGh1YXdlaS5jb20iPm1hY2guY2hlbkBo dWF3ZWkuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86Y2hlbmd3ZWlxaWFuZ0BjaGluYW1v YmlsZS5jb20iPmNoZW5nd2VpcWlhbmdAY2hpbmFtb2JpbGUuY29tPC9hPjsgTGl6aGVuYmluICZs dDs8YSBocmVmPSJtYWlsdG86bGl6aGVuYmluQGh1YXdlaS5jb20iPmxpemhlbmJpbkBodWF3ZWku Y29tPC9hPiZndDs7IERvbmdqaWUgKEppbW15KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmppZS5kb25n QGh1YXdlaS5jb20iPmppZS5kb25nQGh1YXdlaS5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0 bzpyZ2FuZGhpQGNpc2NvLmNvbSI+cmdhbmRoaUBjaXNjby5jb208L2E+OyA8YSBocmVmPSJtYWls dG86eGlvbmcucXVhbkB6dGUuY29tLmNuIj4NCnhpb25nLnF1YW5AenRlLmNvbS5jbjwvYT48YnI+ DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpwY2VAaWV0Zi5vcmciPnBjZUBpZXRmLm9yZzwv YT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gSVBSIFBvbGwgb24gZHJhZnQtbGktcGNlLXNyLWJpZGly LXBhdGgtMDY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMjEyNTI5Ij5IaSBBdXRob3JzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMyMTI1MjkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMTI1 MjkiPkluIHByZXBhcmF0aW9uIGZvciBXb3JraW5nIEdyb3VwIGFkb3B0aW9uIG9uIHRoaXMgZHJh ZnQsIEknZCBsaWtlIGFsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMTI1 MjkiPmF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycyB0byBjb25maXJtIG9uIHRoZSBsaXN0IHRoYXQg dGhleSBhcmUgaW4gY29tcGxpYW5jZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMyMTI1MjkiPndpdGggSUVURiBJUFIgcnVsZXMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzIxMjUyOSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzIxMjUyOSI+UGxlYXNlIHJlc3BvbmQgKGNvcHlpbmcgdGhlIG1haWxpbmcgbGlzdCkgdG8g c2F5IG9uZSBvZjo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5Ij5JIGFtIG5v dCBhd2FyZSBvZiBhbnkgSVBSIGFwcGxpY2FibGUgdG8gdGhpcyBkcmFmdCB0aGF0IHNob3VsZCBi ZSBkaXNjbG9zZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5Ij5p biBhY2NvcmRhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMuPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzIxMjUyOSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzIxMjUyOSI+SSBhbSBhd2FyZSBvZiBJUFIgYXBwbGljYWJsZSB0byB0aGlzIGRyYWZ0 LCBhbmQgaXQgaGFzIGFscmVhZHkgYmVlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMyMTI1MjkiPmRpc2Nsb3NlZCB0byB0aGUgSUVURi48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMjEyNTI5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMjEyNTI5Ij5JIGFtIGF3YXJlIG9mIElQUiBhcHBsaWNhYmxlIHRvIHRoaXMgZHJh ZnQsIGJ1dCB0aGF0IGhhcyBub3QgeWV0IGJlZW48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMjEyNTI5Ij5kaXNjbG9zZWQgdG8gdGhlIElFVEYuIEkgd2lsbCB3b3JrIHRvIGVu c3VyZSB0aGF0IGl0IHdpbGwgYmUgZGlzY2xvc2VkIGluIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMjEyNTI5Ij50aW1lbHkgbWFubmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMyMTI1MjkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMyMTI1MjkiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMjEyNTI5Ij4tIEhhcmk8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMTI1MjkiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_C7C2E1C43D652C4E9E49FE7517C236CB02897777dggeml509mbschi_-- From nobody Tue Jan 21 19:43:29 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872F8120013; Tue, 21 Jan 2020 19:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T-jliaZcgsm; Tue, 21 Jan 2020 19:43:18 -0800 (PST) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A98E120044; Tue, 21 Jan 2020 19:43:18 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 00M3hFGp017442; Wed, 22 Jan 2020 03:43:15 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A09DE2203B; Wed, 22 Jan 2020 03:43:15 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 8B0EA2203A; Wed, 22 Jan 2020 03:43:15 +0000 (GMT) Received: from LAPTOPK7AS653V (089144205018.atnat0014.highway.webapn.at [89.144.205.18]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 00M3hEcC010632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Jan 2020 03:43:14 GMT Reply-To: From: "Adrian Farrel" To: "'Alvaro Retana'" , "'The IESG'" Cc: , "'Hariharan Ananthakrishnan'" , , References: <157954420268.1489.1166603703118243867.idtracker@ietfa.amsl.com> In-Reply-To: <157954420268.1489.1166603703118243867.idtracker@ietfa.amsl.com> Date: Wed, 22 Jan 2020 03:43:13 -0000 Organization: Old Dog Consulting Message-ID: <01d901d5d0d6$138a57f0$3a9f07d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIqVvZlxg7Jwid+wVU+4n+L5yJzF6dM1KbA Content-Language: en-gb X-Originating-IP: 89.144.205.18 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25182.004 X-TM-AS-Result: No--15.683-10.0-31-10 X-imss-scan-details: No--15.683-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25182.004 X-TMASE-Result: 10--15.683100-10.000000 X-TMASE-MatchedRID: cxtZ8fwm3r/xIbpQ8BhdbPVY7U3NX8JgIiTd2l7lf6FQdwGfvSIlB5y8 UG+qg0r7kZZdRmdQKjH4yNWqcHw+3fhOa0RWlX7lUPktDdOX0fuPSNdj1JMyAX5Isu006IGG5Jm w4eLTuATbKZq4ZwZRTScf6POBH64YASGDEE8+BGkBnSWdyp4eoWBEcY81Wiod9HUCxwon8acrTQ ogi5FNE6n2XZuwhcpssCy/i4gaSMMZ7Z5t6RByKR23b+lJHvPAblYLQjc/fZJIYjMv+1dDGDeMa vhj0dcxkApdQi3ns1vb7kMHlvhwi2UksqykCGSH1uDM+OtX7BwdLjiwtocA8kr0IQVDq/crimzW YYKiqn+j+Ptw7j0JeW2c8zIhbC63cL43aMFnKPWh7O7qzewu4AaJqOKaiiC5VI7KaIl9Nhd39f9 fxq2qSzdVzMxyzZVz1IBBOTY9FTa3pnygfW0Y746cpbnLdja9zhWjmy90rdvkMnUVL5d0E28jl5 1zVQpqejP4TImXMNk9vUc08rywOhqK3CYtjG3K4t2mucDkRBHkY2blxNFpR8OtrkhuZC9WsjtVF iVKchS4S8oXrr4cwV+24nCsUSFN/fTpDjOELgPdB/CxWTRRuyUIayx+Skid X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Pce] Alvaro Retana's Discuss on draft-ietf-pce-stateful-flags-00: (with DISCUSS and COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 03:43:22 -0000 Hello Alvaro, Thanks for this Discuss. I think you found a hole in = draft-ietf-pce-lsp-control-request. It doesn't look like a big hole = because if you tried to apply both the C and the R flag, presumably the = R flag would get executed making the C flag irrelevant. But I agree that = the clarity of how to handle "conflicting" flags is missing. Now we have to work out how to handle it. The options seem to be: 1. Set a rule, as you suggest, that documents that define new flags MUST = define how to handle the case when the new flags contradict or clash = with existing flags. Fix draft-ietf-pce-lsp-control-request according to = that rule. 2. Fix draft-ietf-pce-lsp-control-request to clarify how the C flag = interacts with other existing flags (specifically the R flag) 3. Define the processing of messages with "conflicting" flags 1.requires a specification and a modification to = draft-ietf-pce-lsp-control-request 2. requires a modification to draft-ietf-pce-lsp-control-request 3. requires a specification (that updates 8231) I agree that this document could be the home for the specification in 1 = or 3. But it could also be argued (especially for 3) that a new document = with some thought and WG consensus on this new point is required. While = the title of this document certainly puts that work in scope, I don't = see that we necessarily have to hold back the simple clarification in = this document in order to work on the other (perfectly valid) point. I would also say that documents that apply 2119 language to future = documents are not necessarily successful. That is, constraining the = authors of future documents is notoriously (but not impossibly) hard.=20 That makes me think that options 2 or 3 are best. Option 2 does not = require a modification to this document, but does require pulling = draft-ietf-pce-lsp-control-request back to fix it. Option 3 does not = necessarily require a change to this document *if* a new document is = written, and does not require pulling draft-ietf-pce-lsp-control-request = back. This is a worthy Discuss! But I don't know how to resolve it as a = document author. Thanks, Adrian ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The acknowledgement to the authors of I-D.ietf-pce-lsp-control-request = prompted me to go take a look at that document and refresh my mind on the fact = that it defines a new flag called LSP-Control Request Flag (C). I find it hard = to resolve in my mind when it would make sense for the R (LSP REMOVE from = rfc8281) and C flags to be set at the same time. I couldn't find in rfc8231/rfc8281/I-D.ietf-pce-lsp-control-request or = this document any discussion about the ability (or not) to set more than one = Flag at a time. In line with it's title, I would like to see this document include rules = about processing of multiple flags. I know that it is not possible to set out = rules for the interaction of yet-to-be-defined flags, but at least adding text = to the effect of "documents defining additional flags MUST discuss how they = interact with existing flags" would go a long way. I am balloting DISCUSS because even though this document is not = introducing new issues, the combination of what is defined in rfc8231/rfc8281/I-D.ietf-pce-lsp-control-request does...and a document = titled "Updated Rules for Processing Stateful PCE Request Parameters Flags" is = then the optimal place to address them. [Aside: If this DISCUSS is resolved as suggested above, then I-D.ietf-pce-lsp-control-request, which is on the RFC EDitor's queue, = will have to be updated.] From nobody Tue Jan 21 19:48:22 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF4B120013; Tue, 21 Jan 2020 19:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukgP-X0diPTu; Tue, 21 Jan 2020 19:47:38 -0800 (PST) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF0F012006D; Tue, 21 Jan 2020 19:47:37 -0800 (PST) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 00M3lZYW027282; Wed, 22 Jan 2020 03:47:35 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B01AA22044; Wed, 22 Jan 2020 03:47:35 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id 994AD22042; Wed, 22 Jan 2020 03:47:35 +0000 (GMT) Received: from LAPTOPK7AS653V (089144205018.atnat0014.highway.webapn.at [89.144.205.18]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 00M3lYYW030115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Jan 2020 03:47:34 GMT Reply-To: From: "Adrian Farrel" To: "'Alvaro Retana'" , "'The IESG'" Cc: , "'Hariharan Ananthakrishnan'" , , Date: Wed, 22 Jan 2020 03:47:33 -0000 Organization: Old Dog Consulting Message-ID: <01da01d5d0d6$ae8a5de0$0b9f19a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdXQ1qTWn+9+7OIpShWvmuWukt10jw== Content-Language: en-gb X-Originating-IP: 89.144.205.18 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25182.004 X-TM-AS-Result: No--14.452-10.0-31-10 X-imss-scan-details: No--14.452-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25182.004 X-TMASE-Result: 10--14.452500-10.000000 X-TMASE-MatchedRID: u6ojmU07PKzxIbpQ8BhdbMVbb3pjW5MnW6IdALvH8VOZt08TfNy6OAPo J7Ws3esJDUvdohVkx3hpfZbbi+Z+q5BuyrHhdqZBRow8EUpfIBQGQwlVHBGoP4PLx3vY4vNimAz bl8iGc5+cdt621J33V2E/2sbp740YdFwK7tfa9PyiXc/ZBk0gb6m9/6ObPjnDfkiy7TTogYaKKq iRyR19ljloO+Sln/bRPbVJ6HzoBwmnPxMLRdJX1LqImyaR0axZXhG7wCQq6N0jRiu1AuxJTJxem /bPuNblXTP38lVJTCcbct6MEzra/lSLej9yd/OAQ1Q0pbURNcF3WGzw1apvHb0rWM4nIpJrHI63 c1a6Q+aTRLghURyZbTFnz6iITdye7d/9z69JooHYeXBrcJgL5CY6ALX8FNLO/ZlT98dhI5kjCDd V372aMK/vNCEa2eMJ9fbCWAY+aqM32uiNuPEGTDdfT4zyWoZS4lzqEpaPQLXcUlQs8YFKzhT7mo X2uLUVkftWLwwvjZpFvRRCBN/HWWK3QrkHqcKM1JdCMvZkkjLy++SyyVe4twDh3PVI5YW97Ofp4 TaCvCcZsk/MbokSI7qMNUHcJro7bXr9ObTHNXP0hv/rD7WVZHhDDPvdmfh4BbJs+dLiqQYYr6ux ryRSe6Xq179Xhm/usGRzEHTW2nG/WXZS/HqJ2kY41YX/o/8Ki2QFaYS1v20qtq5d3cxkNQwWxr7 XDKH8x6AZ45/n3FYWBseuv+9+VQ7AbP5+X6eO1YpTBpHh16ndcqdkPB4oCg== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Pce] Alvaro Retana's Comments on draft-ietf-pce-stateful-flags-00: (with DISCUSS and COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 03:47:40 -0000 Hi again Alvaro A separate thread for your Comments (since your Discuss was so juicy!) > (1) Compatibility > > The compatibility issue described at the end of =C2=A74 could result = in all types of > unforeseen errors or more serious issues; even considering just the = one flag > defined in rfc8281: the R flag =3D LSP REMOVE. One of the = incompatibility > results could be for an rfc8231-only implementation to set the R flag = (it has > unknown functionality to the sender), and then for an rfc8281 = implementation to > receive the object and remove the LSP. Not only could this result in > operational issues by removing an LSP that shouldn't have been = removed, but > this action could also be considered a denial of service. > > This is not a new issue created by this document, but given that the = latent > compatibility issues are presented, then a more robust discussion is = needed -- > I would like to see it in the Security Considerations, but using the > Compatibility Considerations section works for me too. > > To be clear on my expectation. The current text sounds tentative and = even > alarming: (paraphrasing) there's an issue that cannot be solved unless = we start > over! It would be nice to then add some text that talks about the = potential > effects: taking an unintended action, opening the door for an = attacker, etc. You are right to summarise this as "there is an issue that can't be = solved unless we start over". But this has to be caveated by = "examination of existing implementations, ad understanding of how people = normally implement around this type of issue means it is probably not a = problem". You are right that there is an existing security issue, and that by not = publishing this document we perpetuate that issue. As the current = Security section says " by defining the expected behavior of = implementations, this document may improve the stability of networks and = thus reduce the attack surface." We could expand that text to explain the ways in which the stability = might be improved and the attack surface reduced. I.e., we could talk = more about how networks might be unstable without this "fix" and we = could outline the current attack surfaces. Is that what you're looking = for? > (2) Going back to the specification: > > Flags (32 bits): This document does not define any flags. > Unassigned flags MUST be set to zero on transmission and MUST be > ignored on receipt. Implementations that do not understand any > particular flag MUST ignore the flag. > > Aren't the two Normative sentences redundant? The most likely reason = for a > receiver to not understand a flag is for it to not have it = implemented, which > is the same as it considering it not assigned. Are there cases that = I'm > missing which require both statements? Perhaps s/Unassigned/Unknown = and remove > the second sentence. Well, I may be a pedant here, but whether a flag is assigned or not is a = matter of IANA fact. Whether an implementation "considers a flag to be = not assigned" (I paraphrase) is a matter for an implementation. It is = possible that an implementation is aware of the IANA registration but = does not support or has no awareness of the meaning of a flag. That said, even if the statements are redundant, is it actively harmful = to include both? Does it cause confusion or possibly result in broken = implementations? Best, Adrian From nobody Tue Jan 21 20:06:21 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3751200A4; Tue, 21 Jan 2020 20:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJpT4IjbXSvY; Tue, 21 Jan 2020 20:06:16 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F152012006B; Tue, 21 Jan 2020 20:06:15 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00M46BoS012607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jan 2020 23:06:13 -0500 Date: Tue, 21 Jan 2020 20:06:10 -0800 From: Benjamin Kaduk To: Adrian Farrel Cc: "'The IESG'" , draft-ietf-pce-stateful-flags@ietf.org, "'Hariharan Ananthakrishnan'" , pce-chairs@ietf.org, pce@ietf.org Message-ID: <20200122040610.GG80030@kduck.mit.edu> References: <157965240227.28983.6586692675642034521.idtracker@ietfa.amsl.com> <01ab01d5d0c0$694f4a80$3beddf80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01ab01d5d0c0$694f4a80$3beddf80$@olddog.co.uk> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-stateful-flags-00: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 04:06:19 -0000 On Wed, Jan 22, 2020 at 01:08:08AM +0000, Adrian Farrel wrote: > > Thanks for this clear and well-written document! I just have a couple > > of editorial comments that probably don't even need a response. > > Thanks for reading, Ben. > > Every review comment deserves a response. You're too kind! Both proposed changes look good to me :) -Ben > > Section 4 > > > > There will remain an issue with compatibility between implementations > > of RFC 8231 that might set any of the unassigned flags, and current > > (such as [RFC8281]) and future (such as > > [I-D.ietf-pce-lsp-control-request]) specifications. That problem > > cannot be fixed in old implementations by any amount of > > documentation, and can only be handled for future specifications by > > obsoleting the Flags field and using a new technique. Fortunately, > > however, most implementations will have been constructed to set > > unused flags to zero which is consistent with the behavior described > > in this document. > > > > I had a little bit of trouble reading this, as I keep expecting the > > first sentence to be saying that there is a legitimately-allocated flag > > value that is set with intent to change behavior, but it doesn't really > > say anything specifically about a flag value getting allocated (or > > used). > > How about this becomes... > > There will remain an issue with compatibility between implementations > of RFC 8231 that might set any of the unassigned flags, and current > (such as [RFC8281]) and future (such as > [I-D.ietf-pce-lsp-control-request]) specifications that assign specific > meanings to flags if set. > > > W.r.t. obsoleting Flags vs. relying on "most implementations" to be > > consistent with this document's recommendations, is it worth being more > > clear about the conclusion that this document is drawing, namely that > > the risk of bad interactions is sufficiently small that there is no > > desire to incur the cost of obsoleting/replacing the Flags field? > > How about > OLD > Fortunately, > however, most implementations will have been constructed to set > unused flags to zero which is consistent with the behavior described > in this document. > NEW > Fortunately, > however, most implementations will have been constructed to set > unused flags to zero which is consistent with the behavior described > in this document and so the risk of bad interactions is sufficiently > small that there is no need to obsolete the existing Flags field. > END > > Thanks, > Adrian > From nobody Tue Jan 21 20:22:14 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A31A12006B; Tue, 21 Jan 2020 20:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CcoI6E_VikV; Tue, 21 Jan 2020 20:22:03 -0800 (PST) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974FD120013; Tue, 21 Jan 2020 20:22:03 -0800 (PST) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 00M4M1EN019721; Wed, 22 Jan 2020 04:22:01 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 745CE2203A; Wed, 22 Jan 2020 04:22:01 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS id 5F1AA22032; Wed, 22 Jan 2020 04:22:01 +0000 (GMT) Received: from LAPTOPK7AS653V (089144205018.atnat0014.highway.webapn.at [89.144.205.18]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 00M4Lxa9002663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Jan 2020 04:22:00 GMT Reply-To: From: "Adrian Farrel" To: "'Benjamin Kaduk'" Cc: "'The IESG'" , , "'Hariharan Ananthakrishnan'" , , References: <157965240227.28983.6586692675642034521.idtracker@ietfa.amsl.com> <01ab01d5d0c0$694f4a80$3beddf80$@olddog.co.uk> <20200122040610.GG80030@kduck.mit.edu> In-Reply-To: <20200122040610.GG80030@kduck.mit.edu> Date: Wed, 22 Jan 2020 04:21:58 -0000 Organization: Old Dog Consulting Message-ID: <01e101d5d0db$7dd6c4e0$79844ea0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGVwRM+aR0Bc0s3Gd8LHtraiajqNwIpmWYvAT6Mn6eoWvNhYA== Content-Language: en-gb X-Originating-IP: 89.144.205.18 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25182.004 X-TM-AS-Result: No--3.101-10.0-31-10 X-imss-scan-details: No--3.101-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25182.004 X-TMASE-Result: 10--3.101000-10.000000 X-TMASE-MatchedRID: lORh06tOiKjxIbpQ8BhdbPHkpkyUphL9PXu1L28jSnHzlv7FEwWOy7Mf VA5VX2DG59uFbeJb7N0+v1uiXBkw6gzyMxeMEX6wgxsfzkNRlfKYQKsouMfswt5/HgWYxplMPhh qRWZ33iTdB/CxWTRRu+rAZ8KTspSz8C6goKf41354XGXUWuqCk2prWa3K21McqxGxcu+pnojApp DA86U3VqfItuohgjfnw/3NmPJsa4pNWfnUnboMLyBJEZlhLWrQQwymtxuJ6y0= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-stateful-flags-00: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 04:22:06 -0000 >> Every review comment deserves a response. > > You're too kind! Never knowingly =F0=9F=98=89 > Both proposed changes look good to me :) Great, thanks. They are in the buffer. A From nobody Tue Jan 21 21:55:58 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C6A120024; Tue, 21 Jan 2020 21:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, PDS_TONAME_EQ_TOLOCAL_HDRS_LCASE=1.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tlup7CFzapr8; Tue, 21 Jan 2020 21:55:53 -0800 (PST) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.220]) by ietfa.amsl.com (Postfix) with ESMTP id D526A120013; Tue, 21 Jan 2020 21:55:52 -0800 (PST) Received: from clientip-120.88.10.46?logid-5987a7d1f4204302bf5aa631b0590e26 (unknown [172.18.0.92]) by chinatelecom.cn (HERMES) with SMTP id 6C0E5280084; Wed, 22 Jan 2020 13:55:49 +0800 (CST) HMM_ATTACHE_NUM: 0000 HMM_SOURCE_IP: wmail.172.18.0.92.371799780 HMM_SOURCE_TYPE: WEBMAIL Received: from ([172.18.0.254]) by App0021 with ESMTP id 5987a7d1f4204302bf5aa631b0590e26 for pce-bounces@ietf.org; Wed Jan 22 13:55:49 2020 X-Transaction-ID: 5987a7d1f4204302bf5aa631b0590e26 X-filter-score: filter<0> X-Real-From: zhuyq8@chinatelecom.cn X-Receive-IP: 172.18.0.254 X-MEDUSA-Status: 0 Date: Wed, 22 Jan 2020 13:55:48 +0800 (CST) From: zhuyq8@chinatelecom.cn To: pce-bounces Cc: pce Message-ID: <937435771.138363.1579672549762@App0043> MIME-Version: 1.0 Content-type: multipart/mixed; boundary="----=_Part_138362_468374126.1579672548608" HMM_WEBCLN_IP: 172.18.0.176 X-HERMES-SENDMODE: normal X-HERMES-SET: tKSovLfYPg2Q7jEAESng/Bb49PknL3W+NiWCQSA9evQ= Archived-At: Subject: Re: [Pce] FW: Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 05:55:56 -0000 ------=_Part_138362_468374126.1579672548608 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWw+CiA8aGVhZD48L2hlYWQ+CiA8Ym9keT4KICA8ZGl2PgogICAmbmJzcDsKICA8L2Rpdj4K ICA8ZGl2PgogICAmbmJzcDsKICA8L2Rpdj4KICA8ZGl2PgogICAmbmJzcDsKICA8L2Rpdj4KICA8 ZGl2IGlkPSJlZGl0RGl2Ij48L2Rpdj4gCiAgPGRpdiBzdHlsZT0iYm9yZGVyLWxlZnQ6MXB4IHNv bGlkICNEREREREQ7cGFkZGluZy1sZWZ0OjVweDttYXJnaW4tbGVmdDo1cHg7Ij4KICAgPGRpdj4K ICAgICZuYnNwOwogICA8L2Rpdj4gCiAgIDxwPiBTdXBwb3J0LjwvcD4gCiAgIDxwPiBUaGFua3Mu PC9wPiAKICAgPHA+IFpodSBZb25ncWluZzwvcD4gCiAgIDxkaXYgc3R5bGU9ImJvcmRlci1sZWZ0 OiAxLjBweCBzb2xpZCByZ2IoMjIxLDIyMSwyMjEpO3BhZGRpbmctbGVmdDogNS4wcHg7bWFyZ2lu LWxlZnQ6IDUuMHB4OyI+CiAgICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gCiAgICA8YnI+ RnJvbTogUGNlIFttYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBqdWxp ZW4ubWV1cmljQG9yYW5nZS5jb20gCiAgICA8YnI+U2VudDogRnJpZGF5LCBKYW51YXJ5IDE3LCAy MDIwIDY6MTMgUE0gCiAgICA8YnI+VG86IHBjZUBpZXRmLm9yZyAKICAgIDxicj5TdWJqZWN0OiBb UGNlXSBBZG9wdGlvbiBvZiBkcmFmdC1saS1wY2Utc3ItYmlkaXItcGF0aC0wNj8gCiAgICA8YnI+ IAogICAgPGJyPkhpIGFsbCwgCiAgICA8YnI+IAogICAgPGJyPkl0IGlzIHRpbWUgdG8gc2hhcmUg eW91ciB0aG91Z2h0cyBhYm91dCBkcmFmdC1saS1wY2Utc3ItYmlkaXItcGF0aC0wNi4gCiAgICA8 YnI+RG8geW91IGJlbGlldmUgdGhlIEktRCBpcyBhIHJpZ2h0IGZvdW5kYXRpb24gZm9yIGEgUENF IFdHIGl0ZW0/IFBsZWFzZSB1c2UgdGhlIFBDRSBtYWlsaW5nIGxpc3QgdG8gZXhwcmVzcyB5b3Vy IGNvbW1lbnRzLCBzdXBwb3J0IG9yIGRpc2FncmVlbWVudCwgaW5jbHVkaW5nIGFwcGxpY2FibGUg cmF0aW9uYWxlLCBlc3BlY2lhbGx5IGZvciB0aGUgbGF0dGVyLiAKICAgIDxicj4gCiAgICA8YnI+ VGhhbmtzLCAKICAgIDxicj4gCiAgICA8YnI+RGhydXYgJmFtcDsgSnVsaWVuIAogICAgPGJyPiAK ICAgIDxicj4gCiAgICA8YnI+IAogICAgPGJyPiAKICAgPC9kaXY+IAogIDwvZGl2PiAKIDwvYm9k eT4KPC9odG1sPg== ------=_Part_138362_468374126.1579672548608-- From nobody Wed Jan 22 05:01:57 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C716A1200D8 for ; Wed, 22 Jan 2020 05:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfAIPGrpokYA for ; Wed, 22 Jan 2020 05:01:53 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A0F31200D5 for ; Wed, 22 Jan 2020 05:01:53 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id x1so6519073iop.7 for ; Wed, 22 Jan 2020 05:01:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=GkmQpeapHXqCPS/XfkhnRh5WgtdnNf9PEhONWAyY4Vo=; b=XRf1OIfDDJt4cUNeSkoNG7DLaZKYcpITswVa8ZRFAxGyvZMuIP5um/S6x2G/qEZjHT 0OYurE/+0mK5kuWEQc77BYyEz68uEr/ui3DjFVWRXRFz9rzolhZ5VlHCMYKNPgSKUtLf wvHUFn3gJlNYS1IZ0XDKzD5udq0QfRqHJQTyTZAq9ZHlCcw8PSVyZahulig8hEXLHoeD tZgJX6GJxTcFRXpXXsj9oFVl2N3/m1OyQ3kLDZ/m4hJqrq9NjECPAI2Xk00mAJGtBO6g m2K7BB1Hy8aa9cxUy4yf3spQgUs+W76FPcFq0HpThWLl0ihqC3Aln+Yz/sU1t/RSpwhy fKeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=GkmQpeapHXqCPS/XfkhnRh5WgtdnNf9PEhONWAyY4Vo=; b=qiCJX8kXP51PdFMquaF+BTVn3L/9WGSYAAKuBLo/tJzSEeKhbdkwEb1jfemy0q++/G rxZ9IPwOK1qNoIxvHHYOApJ1q/AKVG8bD1S3wySLOzMasedx+q3BypbGseSAx4/DSOKl mDRP53AWwJpoScBUgYoVhzvodcSFutrJ5Zpgf6A1qFP/v0gWvtqDW8AdANSt5BXYqVpV aCK+iWPTRO8nI8dZWYgguJttGV2IeZDj9Qp/O+Z3AB94ZpI88LDR/wKd2FGcqBiMMLOG UifiiRnsKfbhfmBJ2wWAmM1hblOoXiMC+nV+k9Kv3Z0Cu9rRa2yva1qpDMNyyQN8exQn 5THQ== X-Gm-Message-State: APjAAAXkWmZRvBxfPyDt7SOPlkycWJmT02nVPnOb37a7SR3vbOK9Iw/l swMbVCPdWtdYFukGzEufdbu3mtpg9j4xKCOPkRI= X-Google-Smtp-Source: APXvYqx2UGXUT1z3QXkLMe+BjcEsOfQy+9YyZA63ShEDR2W/1Ku4Zx7Tr433reVuvVJmBWKLi0jWlB1FNjFYoPeHXec= X-Received: by 2002:a05:6638:102:: with SMTP id x2mr6898922jao.71.1579698112503; Wed, 22 Jan 2020 05:01:52 -0800 (PST) MIME-Version: 1.0 References: <4EA592A4-4749-4743-8255-BFE7D296A61C@nokia.com> <3587FF7A-97B3-43A4-B6B9-62197935B91F@nokia.com> In-Reply-To: <3587FF7A-97B3-43A4-B6B9-62197935B91F@nokia.com> From: Dhruv Dhody Date: Wed, 22 Jan 2020 18:31:16 +0530 Message-ID: To: "Stone, Andrew (Nokia - CA/Ottawa)" Cc: Rakesh Gandhi , "pce@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 13:01:56 -0000 Hi Andrew, On Wed, Jan 22, 2020 at 12:06 AM Stone, Andrew (Nokia - CA/Ottawa) wrote: > > Hi Dhruv, > > Thanks for the reply and feedback. > > Could an implementation of PCE not simply just return error during that s= ituation? In diversity if too many LSPs grouped together and PCE computatio= nally can't support it, it returns a PCERR. So I would reason that if bidir= ectionally associated and notify PCCs is necessary, but was configured betw= een SR and RSVP, that's also an error due to the (current) unsupported feat= ure set. I see this as trying to protect against day-0 misconfig by changin= g the wire encoding within the protocol (which I'm not necessarily against.= .). While I have doubt if it's a valid use case or requirement in a product= ion deployment, and it may have been acknowledged before, but this essentia= lly blocks associating SR LSP with RSVP LSP bidirectionally for PCE to comp= ute. > > Since the overall workflow doesn't change by this new type def, and if SR= <->RSVP associated is not reasonable requirement, and If consensus has alre= ady been reached on this, and implementation already exist, I'm okay with p= arking this topic. > The SR draft does expect all LSPs to be SR for the new association type and thus easier to handle. If you use a common association type, the behavior would be dependent on the PST for the first LSP that is added to the association. We could end up in a situation where Peer 1 would add LSP 1 (SR) first and reject LSP 2 (RSVP-TE) and peer 2 would add LSP 2 (RSVP-TE) first and reject LSP 1 (SR). Also there might be a use for this mixed cases in future, which would require different processing to be defined. > Still hoping for feedback regarding my comments on section 5. I see that = as being more significant, since it influences the workflow and at the mome= nt I don't see the dependency on draft-li-pce-controlled-id-space as necess= ary to achieve notifying PCCs of reverse paths. > And I was hoping that authors would take a bite :) >From what I understood PLSP-ID remains a PCC allocated ID. The point that section 5 is making is that the same LSP would be identified by two PLSP-IDs, one allocated by Ingress and another by Egress PCCs. There is no proposal for PCE-controlled PLSP-ID. So PCE-init + R bit is enough (as you state) and I am in full agreement with you that figures with PLSP-ID could be useful. Thanks! Dhruv > Thanks again, > Andrew > > > =EF=BB=BFOn 2020-01-21, 5:01 AM, "Dhruv Dhody" wro= te: > > Hi Andrew, > > Speaking as a WG contributor and snipping to - > > > > For bidirectional associating two LSPs, does PCC/PCE need an additi= onal way to distinguish whether it's an SR or an RSVP bidirectional associa= tion? Would that not be implicit based on the path setup type of the LSPs w= hich have been associated together? In other words, do we actually need dou= ble-sided bidirectional SR association group object defined? draft-li-pce-s= r-bidir-path-06 seems to imply the behavior is basically the same as MPLS-T= E (minus the RSVP signalling of course) and the object encoding is the same= , so does yet-another object need to be defined? From a PCEP message encodi= ng p.o.v within an association object structure, are 2 SR LSPs that differe= nt than associating 2 RSVP LSPs? > > > > > > > > Main difference is that in case of RSVP-TE, the egress node le= arns the reverse LSP via RSVP signaling whereas in case of SR, the egress n= ode learns the reverse LSP via PCE. > > > > > > > > Yes, I realize that, however the association structure is = about informing PCE to associate two LSPs together, is it not? It=E2=80=99s= not related to how 2 LSPs learn each opposite reverse path. To be specific= , my comment is regarding section 3.1. To instruct PCE =E2=80=9Cmake these = 2 bidirectional=E2=80=9D is a separate task than how the LSPs learn of each= other=E2=80=99s reverse LSP and path in my opinion. So to inform PCE =E2= =80=9Cthese 2 LSPs are bidirectional, make them so=E2=80=9D is the same ins= truction irrelevant of how each LSP learns of each others path. For SR, yes= there is the added process where PCE may need to tell the PCC the opposite= path, but that decision is a behaviour post-association being provided, wh= ich can be determined as necessary by the LSP path setup type of the associ= ated LSPs. So if the goal of to instruct PCE =E2=80=9Cthese 2 LSPs are bidi= rectional=E2=80=9D, that instruction is common between LSPs whether they ar= e RSVP or SR. Essentially defining 'Double-sided Bidirectional SR Path Asso= ciation Group' is not required (unless there=E2=80=99s something else in th= at object we foresee being specific to SR in the future). > > > > I remember this being discussed in the mailing list, and the decision > was that there are enough of a difference between the processing of > double-sided bi-directional for RSVP-TE and SR paths to have differen= t > association types for the ease of implementation. Implementers were > also worried that the PST of the first LSP that joins the association= s > would decide the next action and could lead to issues. In case one > tried to add SR and RSVP-TE path in one association, where one peer > may add SR first and reject RSVP-TE and other pcep peer may add > RSVP-TE first and reject SR and there could be some mismatch. This wa= s > done mainly for the ease of implementations. > > Thanks! > Dhruv > > From nobody Wed Jan 22 12:59:15 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BEC12083C; Wed, 22 Jan 2020 12:59:08 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HODmXYq6c-vI; Wed, 22 Jan 2020 12:59:06 -0800 (PST) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E1AE120831; Wed, 22 Jan 2020 12:59:06 -0800 (PST) Received: by mail-ed1-x52d.google.com with SMTP id l8so1072909edw.1; Wed, 22 Jan 2020 12:59:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=cnd6FvASa8qoRFCc+VeCrYtploe7+3QE5GIuj0JF2kk=; b=Bl1720SrzWAa3o1vt4lfntDI1sm/5jMO6yhujE9+6hPGSABDIhHWV6uJU6DUM5jQje GHvEAiB+rrRyBKcQYnSz+RL+3mGFELrgxH/Gk6NMMHAfSp6oc0pxao25GjByRyGQv0rs r7hucgjkOSdt/U7Gel6QuMUIsl0QdLYtHGfCdysSOtZfR0zkuMqnJKy8z9dgzQ0H4yma iVytLJT5qnMEbEISAJkeiD3dh/+TeFif25JuwsWc4Bcyj9u0hy5IDFtCDeZbq3sfB3O6 udf5kTearM/RVZTFtrfww6aSyqLXto3uV/n1RuN2502ainPBiAc08989NV/WQhs3NUiq edvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=cnd6FvASa8qoRFCc+VeCrYtploe7+3QE5GIuj0JF2kk=; b=UFIwDwvVF6gAcS7VHTWbmLrXOs1lRM3RSDzfcZcING7185KdSGzLiOlEVmSVT4eL4i gIKFn3WYAdzG3n+a/jawTACDbAtj2PLT2FR5icRTqWYxSoTl39UF+zehLhGRaCpkGhnX eWxyxwh/WCkRPpX3s7LtwQ5biUarQqAgqJfaJ35BOm+1ikxMhb09gU7K+QC0ZJmkanNz kowhhApjuQwNmZ53VADKtXDJmqygNbxB4wcDOYGkCiXkN2OA0sSQ+Y0N5PjsBx64cdLD pQK0abYPMSRDnUWwx+/AH+jZEpktWKwPiPB5l8DgVAUwOOEH6x0/YGMONh/IRztEI0DD dsPg== X-Gm-Message-State: APjAAAXzHWGCDIBWsiR8Ncz4ZSLSbgTAYuqI6c4Cq+J0nM2J9xvaD1uO oQHnINUlKbyfrC4C6mPDKzIW50+TbnV/Gmn0BYr7XQ== X-Google-Smtp-Source: APXvYqxSR8FxVnqAaynLoIKEXAbA1qp7Xzby2hOSjynAA44EjOeTt6KjGpBjOszg7el9d6STplwbXqYH8KJtQGuXP14= X-Received: by 2002:a05:6402:17fb:: with SMTP id t27mr4427840edy.159.1579726744851; Wed, 22 Jan 2020 12:59:04 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 22 Jan 2020 12:59:04 -0800 From: Alvaro Retana In-Reply-To: <01d901d5d0d6$138a57f0$3a9f07d0$@olddog.co.uk> References: <157954420268.1489.1166603703118243867.idtracker@ietfa.amsl.com> <01d901d5d0d6$138a57f0$3a9f07d0$@olddog.co.uk> MIME-Version: 1.0 Date: Wed, 22 Jan 2020 12:59:04 -0800 Message-ID: To: adrian@olddog.co.uk, The IESG Cc: pce-chairs@ietf.org, draft-ietf-pce-stateful-flags@ietf.org, Hariharan Ananthakrishnan , pce@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Pce] Alvaro Retana's Discuss on draft-ietf-pce-stateful-flags-00: (with DISCUSS and COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 20:59:09 -0000 On January 21, 2020 at 10:43:16 PM, Adrian Farrel wrote: Adrian: Hi! > Thanks for this Discuss. I think you found a hole in draft-ietf-pce-lsp-c= ontrol-request. No, I think I found another hole in rfc8231. ;-) > It doesn't look like a big hole because if you tried to apply both the C = and > the R flag, presumably the R flag would get executed making the C flag > irrelevant. But I agree that the clarity of how to handle "conflicting" f= lags > is missing. That's the point, "presumably" is not enough. > Now we have to work out how to handle it. > > The options seem to be: > 1. Set a rule, as you suggest, that documents that define new flags MUST > define how to handle the case when the new flags contradict or clash with > existing flags. Fix draft-ietf-pce-lsp-control-request according to that = rule. > 2. Fix draft-ietf-pce-lsp-control-request to clarify how the C flag inter= acts > with other existing flags (specifically the R flag) > 3. Define the processing of messages with "conflicting" flags > > 1.requires a specification and a modification to draft-ietf-pce-lsp-contr= ol-request > 2. requires a modification to draft-ietf-pce-lsp-control-request > 3. requires a specification (that updates 8231) > > I agree that this document could be the home for the specification in 1 o= r 3. > But it could also be argued (especially for 3) that a new document with s= ome > thought and WG consensus on this new point is required. While the title o= f > this document certainly puts that work in scope, I don't see that we > necessarily have to hold back the simple clarification in this document i= n > order to work on the other (perfectly valid) point. I suggested option 1 because I have a hard time imagining how to set up rules for unknown flags... =C2=A0Of course, the WG may know what those unknown (to me) flags might be, but if that was the case I would have expected something more nuanced than "MUST ignore the flag" in this document. =C2=A0IOW, the case would have already beed discussed. I think that option 2 is shortsighted because it only covers the interaction of the 2 existing flags...and we will end up having this same discussion when/if a third flag is defined. > I would also say that documents that apply 2119 language to future docume= nts > are not necessarily successful. That is, constraining the authors of futu= re > documents is notoriously (but not impossibly) hard. I suggested something along the lines of "MUST discuss how they interact with existing flags", but I'm perfectly fine with "are expected to discuss...". =C2=A0The main request (not a constraint!) is to ask future specifications to consider the interaction -- and to remind future authors/WG members/etc of the need. > That makes me think that options 2 or 3 are best. Option 2 does not requi= re a > modification to this document, but does require pulling > draft-ietf-pce-lsp-control-request back to fix it. Option 3 does not > necessarily require a change to this document *if* a new document is writ= ten, > and does not require pulling draft-ietf-pce-lsp-control-request back. > > This is a worthy Discuss! But I don't know how to resolve it as a documen= t > author. I am making assumptions above -- about the WG not knowing what may come next to be able specify anything longer than a single line, but I may be wrong. =C2=A0I would then want the Chairs/AD to consult the WG. Thanks! Alvaro. From nobody Wed Jan 22 13:02:26 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E79A12087A; Wed, 22 Jan 2020 13:02:25 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iqwu5i1EwDtf; Wed, 22 Jan 2020 13:02:23 -0800 (PST) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A836120876; Wed, 22 Jan 2020 13:02:23 -0800 (PST) Received: by mail-ed1-x530.google.com with SMTP id cy15so1061313edb.4; Wed, 22 Jan 2020 13:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=mI9qHIK+IurdVO3iI+mvuDk/8P3Wy8hG84Wu3XjUQ4A=; b=SaqhpH972tvvv3P39SrN2SlBC2NrWH5IFwLyCm7Wds3SNHHXT7ZYcr4Ce3XzITik2K e+ZkHNW7cac6jbfucwgdv/NA+wGl4JB6Q8Z578EzjUKEFS3/+HFdRPddGswkUZPu1/rb tWPqpi5Ac0D0ADCzKewvp8zbR7a+XYghwziSVPOG2EVVDgDlY+fcM8tlCXldF53UEsFT ARO5YSSImpYQdq/SKWYT3gRZmnDPRuPZQzge+eMJRJ3kFLKU09iiMQAVwrBKRWIJlch4 C72Nyx5cMN6fpayracDd5nfhLRunQRQdOtzmP/o2tMmgA8+x5RICgCsxO6BR90kBObM2 7r7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=mI9qHIK+IurdVO3iI+mvuDk/8P3Wy8hG84Wu3XjUQ4A=; b=WhU9wlmuYb951cl6GHk6DrmL+uQ04xurkY5p441OkQ1n+ZYhn6dExOxb/OmXcdlxws 0B95Rh0fD2RpD4ehyO+xATTWnemCHMTvbr9MEY2WXCs3DnMAHvSScrrLzOQYywvO2r3j IK16KR136B9ZQOIlkcDcEK10EkDBH3o6Ed2L9s4yX8mFdccY1LMKeXKpIlR+XtaHmKsb tuucfLGb71Tppi5MHOuUb4FwosZ06iTshj/gWgOOp2LBV2fCLs2b4ZEi0A7KyhTV2LG8 YmNNKXi2pcP6JKfcaUBiN4A0j5430f7S8FTOckDLI0FTHirSKmrpsneYFbRmjpwsgd+b yctQ== X-Gm-Message-State: APjAAAUp/s/w+z5zgtGQJBRtPHnR4WXXQljs36xasp3ClI/8++wHNNkz 7yi1DhRXHI5QRljZGGVIB1jx/jEBME/YKB7yxijECQ== X-Google-Smtp-Source: APXvYqy69eJvWjZLdoBIzr76Tdbi1icPABxSffnIXiU5YELREw507VXVS3emCCmE6ysx9XulMZx7eF7J4Dl91AS3NaE= X-Received: by 2002:a05:6402:17fb:: with SMTP id t27mr4441458edy.159.1579726942250; Wed, 22 Jan 2020 13:02:22 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 22 Jan 2020 13:02:21 -0800 From: Alvaro Retana In-Reply-To: <01da01d5d0d6$ae8a5de0$0b9f19a0$@olddog.co.uk> References: <01da01d5d0d6$ae8a5de0$0b9f19a0$@olddog.co.uk> MIME-Version: 1.0 Date: Wed, 22 Jan 2020 13:02:21 -0800 Message-ID: To: adrian@olddog.co.uk, The IESG Cc: pce-chairs@ietf.org, draft-ietf-pce-stateful-flags@ietf.org, Hariharan Ananthakrishnan , pce@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Pce] Alvaro Retana's Comments on draft-ietf-pce-stateful-flags-00: (with DISCUSS and COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 21:02:25 -0000 On January 21, 2020 at 10:47:36 PM, Adrian Farrel wrote: Adrian: Hi! ... > You are right that there is an existing security issue, and that by not > publishing this document we perpetuate that issue. As the current Security > section says " by defining the expected behavior of implementations, this > document may improve the stability of networks and thus reduce the attack > surface." > > We could expand that text to explain the ways in which the stability might be > improved and the attack surface reduced. I.e., we could talk more about how > networks might be unstable without this "fix" and we could outline the > current attack surfaces. Is that what you're looking for? Yes, that would be good. Thanks!! Alvaro. From nobody Wed Jan 22 19:53:49 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C92120125 for ; Wed, 22 Jan 2020 19:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_Y7slvtR5cg for ; Wed, 22 Jan 2020 19:53:44 -0800 (PST) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.230]) by ietfa.amsl.com (Postfix) with ESMTP id EB0B7120124 for ; Wed, 22 Jan 2020 19:53:43 -0800 (PST) HMM_SOURCE_IP: 172.18.0.92:43648.474656606 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-121.32.193.71?logid-63D489C9DCC6484181E6BEDA1BE125E7 (unknown [172.18.0.92]) by chinatelecom.cn (HERMES) with SMTP id 7B9F7280090; Thu, 23 Jan 2020 11:53:39 +0800 (CST) X-189-SAVE-TO-SEND: 44093218@chinatelecom.cn Received: from ([172.18.0.92]) by App0021 with ESMTP id 63D489C9DCC6484181E6BEDA1BE125E7 for julien.meuric@orange.com; Thu Jan 23 11:53:40 2020 X-Transaction-ID: 63D489C9DCC6484181E6BEDA1BE125E7 X-filter-score: filter<0> X-Real-From: chenhuan6@chinatelecom.cn X-Receive-IP: 172.18.0.92 X-MEDUSA-Status: 0 Date: Thu, 23 Jan 2020 11:53:40 +0800 From: "chenhuan6@chinatelecom.cn" To: "julien.meuric@orange.com" , "pce@ietf.org" References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.14.410[cn] Mime-Version: 1.0 Message-ID: <2020012311514351840896@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart456243272141_=----" Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 03:53:46 -0000 This is a multi-part message in MIME format. ------=_001_NextPart456243272141_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgV0csDQoNCiAgIFN1cHBvcnQgdGhlIGFkcHRpb24uDQogICBJIGhhdmUgcmVhZCB0aGUgZHJh ZnQsIGl0IGlzIHJlYWR5IHRvIGJlIGEgV0cgZG9jdW1lbnQuDQogICBUaGUgZXh0ZW5zaW9ucyB0 byBQQ0VQIHdlcmUgY2xlYXIgYW5kIHRoZSBwcm9jZWR1cmVzIHRvIHNldHVwIGJpZGlyZWN0aW9u YWwgU1ItTFNQIHdlcmUgZ2l2ZW4gdG9vLg0KICAgT25lIGNvbW1lbnQ6IElmIHdlIG5lZWQgU1It TFNQIHJlZHVuZGFuY3ksIGhvdyBzaG91bGQgd2UgZG8gYXQgdGhlIGJpZGlyZWN0aW9uYWwgU1It TFNQIHNjZW5hcmlvPw0KDQpCZXN0IFJlZ2FyZHMsDQpIdWFuYW4NCg0KRnJvbToganVsaWVuLm1l dXJpY0BvcmFuZ2UuY29tDQpEYXRlOiAyMDIwLTAxLTE3IDE4OjEyDQpUbzogcGNlQGlldGYub3Jn DQpTdWJqZWN0OiBbUGNlXSBBZG9wdGlvbiBvZiBkcmFmdC1saS1wY2Utc3ItYmlkaXItcGF0aC0w Nj8NCkhpIGFsbCwNCiANCkl0IGlzIHRpbWUgdG8gc2hhcmUgeW91ciB0aG91Z2h0cyBhYm91dCBk cmFmdC1saS1wY2Utc3ItYmlkaXItcGF0aC0wNi4NCkRvIHlvdSBiZWxpZXZlIHRoZSBJLUQgaXMg YSByaWdodCBmb3VuZGF0aW9uIGZvciBhIFBDRSBXRyBpdGVtPyBQbGVhc2UNCnVzZSB0aGUgUENF IG1haWxpbmcgbGlzdCB0byBleHByZXNzIHlvdXIgY29tbWVudHMsIHN1cHBvcnQgb3INCmRpc2Fn cmVlbWVudCwgaW5jbHVkaW5nIGFwcGxpY2FibGUgcmF0aW9uYWxlLCBlc3BlY2lhbGx5IGZvciB0 aGUgbGF0dGVyLg0KIA0KVGhhbmtzLA0KIA0KRGhydXYgJiBKdWxpZW4NCiANCiANCiANCiANCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQY2UgbWFpbGlu ZyBsaXN0DQpQY2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcGNlDQo= ------=_001_NextPart456243272141_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
Hi WG,
   Support the adption.
   I ha= ve read the draft, it is ready to be a WG document.
   = ;The extensions to PCEP were clear and the procedures to setup bidirection= al SR-LSP were given too.
   One comment: If we need&n= bsp;SR-LSP redundancy, how should we do at the bidirectional SR-LSP scenario?

=
Best Regards,
Huanan

=
Date: 2020-01-1= 7 18:12
Subject: [Pce] Adoption of draft-li-pc= e-sr-bidir-path-06?
Hi all,
=0A
 =
=0A
It is time to share your thoughts about draft-li-pce-sr-bidi= r-path-06.
=0A
Do you believe the I-D is a right foundation for a= PCE WG item? Please
=0A
use the PCE mailing list to express your= comments, support or
=0A
disagreement, including applicable rati= onale, especially for the latter.
=0A
 
=0A
Thanks,=
=0A
 
=0A
Dhruv & Julien
=0A
 =0A
 
=0A
 
=0A
 
=0A
__= _____________________________________________
=0A
Pce mailing lis= t
=0A
Pce@ietf.org
=0A
https://www.ietf.org/mailman/list= info/pce
=0A
=0A ------=_001_NextPart456243272141_=------ From nobody Wed Jan 22 19:57:29 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F087120125 for ; Wed, 22 Jan 2020 19:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaskcSDx2D5v for ; Wed, 22 Jan 2020 19:57:26 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on0728.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::728]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A53E0120124 for ; Wed, 22 Jan 2020 19:57:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YDYKg4Y3Gt4TuOa7txbOtnzdAX2t7/wgNACQ1XdUA9naOYxjw6O9nWcTFSwIvnaLgc4t56VWnQBTs04nLVgkpaDYs0cDtF/5E2eNb4ZjdA3ACtmUTYM8S3PiuN850u+CY+pYLhqUlEdQpvIwdBpFrOxBpZYSsWucSSgRFmb5lAwDVNb5LEgOtfb59CMM86vDexKWaXBPlPmNv2Pih8HWxvNcx7RNNG1dGSTtphSictQsedPqz3x94IrXxgyI8rAV/OVKHbh4x8pms1Mu1ruolrmJCHui2lWH1YRN1ERpU2Vjm2iyFBWXy98gq0nDGOqKvyNBaN9/txRR7jbwKv+fJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X9jDXu9r7ICVuwcrgWXf7yoiICrD4Du9I7C3u1qMudg=; b=W5qxL6odes3e5hugHqJi3BQooyGV/l6gzVLmKZJJGK2ooENqWy9AP4yHUmv1eJ3YOewVsy6PGWY/SndxIkd71k0iPsGUxxj5DA1ngl6Kj6vgOLJu7svZCMrcQP9tY6rCbyhf4zjwDXYCTBEKMluHa/fDspMNvsr9UXjL53lsxSktfa/adAA2P5YXtBEPUJFrN5pCWLZLjvlMS+jP2yhEKC5X0zwDVIiMJbaeHGHtRByPkazyYwwchmQJ2xL7oPiDpmT/iHu4K9DRqF486wvw08bjFxAUmyYF2NkWrX723qkF+d3iZnr9N+0vbyMTLvPtv2LFbaoA/3OQoZJahDVv3w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X9jDXu9r7ICVuwcrgWXf7yoiICrD4Du9I7C3u1qMudg=; b=Efpy54dn4n/6ffWOrvYCFJ0kjWxdkw1hs6/e0aTtZMNuZiHpsPRWhUymm3hBgeIHdTB7vblT8PaCj5oThyN+G13WN+zCj8g05W3bQy9ZbWEEYyuTE7L3/j6kKrB2vF2n2fSCzP3VFM5XL2R6Z7KM8UUK+Qb1i/qpxk+4aYv4tbQ= Received: from AM0PR0702MB3619.eurprd07.prod.outlook.com (52.133.46.160) by AM0PR0702MB3587.eurprd07.prod.outlook.com (52.133.47.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.12; Thu, 23 Jan 2020 03:57:23 +0000 Received: from AM0PR0702MB3619.eurprd07.prod.outlook.com ([fe80::4139:54b9:238:669c]) by AM0PR0702MB3619.eurprd07.prod.outlook.com ([fe80::4139:54b9:238:669c%7]) with mapi id 15.20.2665.015; Thu, 23 Jan 2020 03:57:23 +0000 From: "Stone, Andrew (Nokia - CA/Ottawa)" To: Dhruv Dhody CC: Rakesh Gandhi , "pce@ietf.org" Thread-Topic: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? Thread-Index: AQHVzR6uiqJrBBVhq0SzaEKl30U2oKfvvJyUgAPq14D//7q+AIABhvmAgAA8DwCAAYiZAIAApowA Date: Thu, 23 Jan 2020 03:57:23 +0000 Message-ID: References: <4EA592A4-4749-4743-8255-BFE7D296A61C@nokia.com> <3587FF7A-97B3-43A4-B6B9-62197935B91F@nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.stone@nokia.com; x-originating-ip: [135.245.20.14] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 4ee138b9-177e-4143-69b1-08d79fb85a3d x-ms-traffictypediagnostic: AM0PR0702MB3587: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 029174C036 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(39860400002)(366004)(136003)(396003)(346002)(199004)(189003)(316002)(53546011)(26005)(6506007)(186003)(6916009)(2616005)(91956017)(76116006)(5660300002)(66476007)(64756008)(66946007)(66446008)(66556008)(71200400001)(478600001)(54906003)(6486002)(6512007)(36756003)(86362001)(4326008)(8936002)(33656002)(8676002)(2906002)(81156014)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0702MB3587; H:AM0PR0702MB3619.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EMKoOjN3GPeh4WLbkAHIn4E7aeT2u/mXTFKGriQT4bCQ2anOJSsuG1jsepJnpi+BkMxp0SR2XBSoy8LzXc57eujYQtrcc+yRFy1200d0Giej4oeKOhaOoG8tbtt4qfsJZ31KC8L8BdweMrl+6xR7AWi2ukySbwxbBSlNweSxlUNp59btR2FXAFf/hyTJC7iczyyTODwNqpmPJkqqUYrtytsNTr5bh5FIgfF1Ql9zxZLOLwMqEXFrfXy4fyjfEBlSilLkgqI6rD+5xEpZjS8Fgr+9ZBuJZW6nfbkrG6UZ+eq7d+RH9UILujabn9xohPVPwzILR1HegeS2rI0lcYHaDYV0+4I8mOZ3EasGddjq/x0N4lir4kJ9qTedUgkIPfGomrk0QGWUVIcpuvKOMv9039MEclFm+sHPy/or/f+pIl/armxQzfZENuRW1kOTs+Gr x-ms-exchange-antispam-messagedata: fkzjJ34MQeUVzdHUZsenYBNSccIZCozz2a1IypnrufbVmU0xac7A/a+zDY+GUE6sjR0it2RKFgkDtKxjfehFKEHsTRKgHfevaqvJtxaonF1m8FJE2klg+QU1pO8XoNqP/Xmrtqu53wFAmUAb7sbXbg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <1BA11B24126DD34C9B25DBCAA18338DB@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4ee138b9-177e-4143-69b1-08d79fb85a3d X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2020 03:57:23.1928 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tETMv9A01XchjaXpvvVz4WjkBsucBvrNKFJo5wzmL3Y9W8NLFU8YkCgCR26OGdmultPR2F2mdkJXrPQCAhD1vQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0702MB3587 Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 03:57:28 -0000 SGkgRGhydXYsDQoNClRoYW5rcyBhZ2FpbiBmb3IgdGhlIHNwZWVkeSByZXBseS4gQ29tbWVudHMg YmVsb3cgdW5kZXIgPGFuZHJldzI+DQoNCkNoZWVycw0KQW5kcmV3DQoNCu+7v09uIDIwMjAtMDEt MjIsIDg6MDEgQU0sICJEaHJ1diBEaG9keSIgPGRocnV2LmlldGZAZ21haWwuY29tPiB3cm90ZToN Cg0KICAgIEhpIEFuZHJldywNCiAgICANCiAgICBPbiBXZWQsIEphbiAyMiwgMjAyMCBhdCAxMjow NiBBTSBTdG9uZSwgQW5kcmV3IChOb2tpYSAtIENBL090dGF3YSkNCiAgICA8YW5kcmV3LnN0b25l QG5va2lhLmNvbT4gd3JvdGU6DQogICAgPg0KICAgID4gSGkgRGhydXYsDQogICAgPg0KICAgID4g VGhhbmtzIGZvciB0aGUgcmVwbHkgYW5kIGZlZWRiYWNrLg0KICAgID4NCiAgICA+IENvdWxkIGFu IGltcGxlbWVudGF0aW9uIG9mIFBDRSBub3Qgc2ltcGx5IGp1c3QgcmV0dXJuIGVycm9yIGR1cmlu ZyB0aGF0IHNpdHVhdGlvbj8gSW4gZGl2ZXJzaXR5IGlmIHRvbyBtYW55IExTUHMgZ3JvdXBlZCB0 b2dldGhlciBhbmQgUENFIGNvbXB1dGF0aW9uYWxseSBjYW4ndCBzdXBwb3J0IGl0LCBpdCByZXR1 cm5zIGEgUENFUlIuIFNvIEkgd291bGQgcmVhc29uIHRoYXQgaWYgYmlkaXJlY3Rpb25hbGx5IGFz c29jaWF0ZWQgYW5kIG5vdGlmeSBQQ0NzIGlzIG5lY2Vzc2FyeSwgYnV0IHdhcyBjb25maWd1cmVk IGJldHdlZW4gU1IgYW5kIFJTVlAsIHRoYXQncyBhbHNvIGFuIGVycm9yIGR1ZSB0byB0aGUgKGN1 cnJlbnQpIHVuc3VwcG9ydGVkIGZlYXR1cmUgc2V0LiBJIHNlZSB0aGlzIGFzIHRyeWluZyB0byBw cm90ZWN0IGFnYWluc3QgZGF5LTAgbWlzY29uZmlnIGJ5IGNoYW5naW5nIHRoZSB3aXJlIGVuY29k aW5nIHdpdGhpbiB0aGUgcHJvdG9jb2wgKHdoaWNoIEknbSBub3QgbmVjZXNzYXJpbHkgYWdhaW5z dC4uKS4gV2hpbGUgSSBoYXZlIGRvdWJ0IGlmIGl0J3MgYSB2YWxpZCB1c2UgY2FzZSBvciByZXF1 aXJlbWVudCBpbiBhIHByb2R1Y3Rpb24gZGVwbG95bWVudCwgYW5kIGl0IG1heSBoYXZlIGJlZW4g YWNrbm93bGVkZ2VkIGJlZm9yZSwgYnV0IHRoaXMgZXNzZW50aWFsbHkgYmxvY2tzIGFzc29jaWF0 aW5nIFNSIExTUCB3aXRoIFJTVlAgTFNQIGJpZGlyZWN0aW9uYWxseSBmb3IgUENFIHRvIGNvbXB1 dGUuDQogICAgPg0KICAgID4gU2luY2UgdGhlIG92ZXJhbGwgd29ya2Zsb3cgZG9lc24ndCBjaGFu Z2UgYnkgdGhpcyBuZXcgdHlwZSBkZWYsIGFuZCBpZiBTUjwtPlJTVlAgYXNzb2NpYXRlZCBpcyBu b3QgcmVhc29uYWJsZSByZXF1aXJlbWVudCwgYW5kIElmIGNvbnNlbnN1cyBoYXMgYWxyZWFkeSBi ZWVuIHJlYWNoZWQgb24gdGhpcywgYW5kIGltcGxlbWVudGF0aW9uIGFscmVhZHkgZXhpc3QsIEkn bSBva2F5IHdpdGggcGFya2luZyB0aGlzIHRvcGljLg0KICAgID4NCiAgICANCiAgICBUaGUgU1Ig ZHJhZnQgZG9lcyBleHBlY3QgYWxsIExTUHMgdG8gYmUgU1IgZm9yIHRoZSBuZXcgYXNzb2NpYXRp b24NCiAgICB0eXBlIGFuZCB0aHVzIGVhc2llciB0byBoYW5kbGUuIElmIHlvdSB1c2UgYSBjb21t b24gYXNzb2NpYXRpb24gdHlwZSwNCiAgICB0aGUgYmVoYXZpb3Igd291bGQgYmUgZGVwZW5kZW50 IG9uIHRoZSBQU1QgZm9yIHRoZSBmaXJzdCBMU1AgdGhhdCBpcw0KICAgIGFkZGVkIHRvIHRoZSBh c3NvY2lhdGlvbi4gV2UgY291bGQgZW5kIHVwIGluIGEgc2l0dWF0aW9uIHdoZXJlIFBlZXIgMQ0K ICAgIHdvdWxkIGFkZCBMU1AgMSAoU1IpIGZpcnN0IGFuZCByZWplY3QgTFNQIDIgKFJTVlAtVEUp IGFuZCBwZWVyIDIgd291bGQNCiAgICBhZGQgTFNQIDIgKFJTVlAtVEUpIGZpcnN0IGFuZCByZWpl Y3QgTFNQIDEgKFNSKS4gQWxzbyB0aGVyZSBtaWdodCBiZSBhDQogICAgdXNlIGZvciB0aGlzIG1p eGVkIGNhc2VzIGluIGZ1dHVyZSwgd2hpY2ggd291bGQgcmVxdWlyZSBkaWZmZXJlbnQNCiAgICBw cm9jZXNzaW5nIHRvIGJlIGRlZmluZWQuDQoNCg0KPEFuZHJldzI+IA0KDQpJIHdpbGwgcG9uZGVy IG9uIHRoaXMgc29tZSBtb3JlLiBJJ20gdW5kZWNpZGVkIHlldCBpZiB0aGUgcmVhc29ucyB0byBw cm90ZWN0IGNvbmZpZy9iZWhhdmlvdXIgbWlzbWF0Y2gsIG91dHdlaWdoIGp1c3QgaGF2aW5nIG9u ZSB0eXBlIGVuY29kaW5nIGFuZCBkZWZpbmluZyB0aGUgaW5kaXZpZHVhbCBiZWhhdmlvdXJzIHNl cGFyYXRlbHksIHdoaWNoIGNvdWxkIGFsc28gYmUgdXAgdG8gdGhlIGxvY2FsIHBvbGljeSBkZWZp bmVkIGJ5IHRoZSBQQ0UgaW1wbGVtZW50YXRpb24uIA0KDQpJdCBjb3VsZCBiZSBwb3NzaWJsZSB0 aGF0IGEgbmV0d29yayBoYXMgbm9kZXMgY3VycmVudGx5IHJ1bm5pbmcgUlNWUCwgd2l0aCBwbGFu cyB0byBtaWdyYXRlIHRvIFNSLVRFIHdoaWNoIGNvdWxkIHRha2UgYSB2ZXJ5IGxvbmcgdGltZSBk dWUgdG8gdGhlIHNpemUgb2YgdGhlIG5ldHdvcmsuIFRoZSBzb2Z0d2FyZSBydW5uaW5nIG9uIHRo ZSBub2RlcyBtYXkgYmUgdXBncmFkZWQsIG9mIHdoaWNoIHRob3NlIFBDQ3MgbWF5IGhhdmUgYW4g aW1wbGVtZW50YXRpb24gb2YgdGhlc2UgYmlkaXJlY3Rpb25hbCBkcmFmdHMsIGJ1dCBoYXZlIHN0 aWxsIG5vdCB5ZXQgbWlncmF0ZWQgdG8gU1ItVEUuIEFuIG9wZXJhdG9yIG1heSB3aXNoIHRvIGxl dmVyYWdlIFBDRSBmZWF0dXJlIHNldHMgb24gbmV3ZXIgY3JlYXRlZCBzZXJ2aWNlcyBzb29uZXIg dGhhbiBsYXRlciAoZm9yIGV4YW1wbGUsIGJpZGlyZWN0aW9uYWwgY2FwYWJpbGl0eSkgc28gdGhl eSBiZWdpbiB1c2luZyBiaWRpcmVjdGlvbmFsIFJTVlAgdG8gaGF2ZSBzeW1tZXRyaWMgcGF0aHMg Zm9yIFNMQSByZWFzb25zIGFuZCBhaWQgaW4gYXZvaWRpbmcgbWFudWFsIHRyYWZmaWMgZW5naW5l ZXJpbmcuIE92ZXIgdGltZSwgYXMgdGhlIG5ldHdvcmsgaXMgbWlncmF0ZWQgdG8gU1ItVEUgdHVu bmVscyB5b3UgaGF2ZSBzb21lIG5vZGVzIHVzaW5nIFNSLVRFIHR1bm5lbHMgYW5kIHRoZSByZXZl cnNlIG5vZGVzIHN0aWxsIG9wZXJhdGluZyB3aXRoIFJTVlAuIEZyb20gYW4gb3BlcmF0b3IgcC5v LnYgdGhlIGJpZGlyZWN0aW9uYWwgbm90aWZpY2F0aW9uIGJlaGF2aW91ciBoZXJlIHdvdWxkbid0 IG1hdHRlciwgdGhleSBqdXN0IHdhbnQgdGhlIExTUHMgdG8gdGFrZSB0aGUgc2FtZSByZXNvdXJj ZXMgc3ltbWV0cmljYWxseS4gVGhlIGZlYXR1cmUgc2V0IG9uIFBDRSwgYXMgcGVyIHRoZSBjdXJy ZW50IGRyYWZ0IHdvcmRpbmcgYW5kIHR5cGVzIHdpbGwgYmUgYnJva2VuLiANCg0KPC9lbmQgYW5k cmV3Mj4NCiAgICANCg0KICAgID4gU3RpbGwgaG9waW5nIGZvciBmZWVkYmFjayByZWdhcmRpbmcg bXkgY29tbWVudHMgb24gc2VjdGlvbiA1LiBJIHNlZSB0aGF0IGFzIGJlaW5nIG1vcmUgc2lnbmlm aWNhbnQsIHNpbmNlIGl0IGluZmx1ZW5jZXMgdGhlIHdvcmtmbG93IGFuZCBhdCB0aGUgbW9tZW50 IEkgZG9uJ3Qgc2VlIHRoZSBkZXBlbmRlbmN5IG9uIGRyYWZ0LWxpLXBjZS1jb250cm9sbGVkLWlk LXNwYWNlIGFzIG5lY2Vzc2FyeSB0byBhY2hpZXZlIG5vdGlmeWluZyBQQ0NzIG9mIHJldmVyc2Ug cGF0aHMuDQogICAgPg0KICAgIA0KICAgIEFuZCBJIHdhcyBob3BpbmcgdGhhdCBhdXRob3JzIHdv dWxkIHRha2UgYSBiaXRlIDopDQogICAgRnJvbSB3aGF0IEkgdW5kZXJzdG9vZCBQTFNQLUlEIHJl bWFpbnMgYSBQQ0MgYWxsb2NhdGVkIElELiBUaGUgcG9pbnQNCiAgICB0aGF0IHNlY3Rpb24gNSBp cyBtYWtpbmcgaXMgdGhhdCB0aGUgc2FtZSBMU1Agd291bGQgYmUgaWRlbnRpZmllZCBieQ0KICAg IHR3byBQTFNQLUlEcywgb25lIGFsbG9jYXRlZCBieSBJbmdyZXNzIGFuZCBhbm90aGVyIGJ5IEVn cmVzcyBQQ0NzLg0KICAgIFRoZXJlIGlzIG5vIHByb3Bvc2FsIGZvciBQQ0UtY29udHJvbGxlZCBQ TFNQLUlELiBTbyBQQ0UtaW5pdCArIFIgYml0DQogICAgaXMgZW5vdWdoICAoYXMgeW91IHN0YXRl KSBhbmQgSSBhbSBpbiBmdWxsIGFncmVlbWVudCB3aXRoIHlvdSB0aGF0DQogICAgZmlndXJlcyB3 aXRoIFBMU1AtSUQgY291bGQgYmUgdXNlZnVsLg0KICAgIA0KDQoNCg0KPEFuZHJldzI+IA0KDQpU aGFua3MgZm9yIHRoZSBjb21tZW50cyBhbmQgYWdyZWVtZW50LiBkcmFmdC1saS1wY2Utc3ItYmlk aXItcGF0aC0wNiBzZWN0aW9uIDUuMSwgc2F5cyAiUENFIG5lZWRzIHRvIGFsbG9jYXRlIGEgUExT UC1JRCIuIFBlcmhhcHMgaXQgd2FzIGp1c3QgYSB0eXBvIGFuZCBzaG91bGQgaGF2ZSBzYWlkIFBD Qy4gDQoNCj09PWN1cnJlbnQNCiAgIFNpbmNlIHRoZSBQTFNQLUlEIHNwYWNlIGlzIGluZGVwZW5k ZW50IGF0IGVhY2ggUENDLCB0aGUgUExTUC1JRA0KICAgYWxsb2NhdGVkIGJ5IHRoZSBlZ3Jlc3Mg UENDIGNhbiBub3QgYmUgdXNlZCBmb3IgdGhlIExTUCBhdCB0aGUNCiAgIGluZ3Jlc3MgUENDIChQ TFNQLUlEIGNvbmZsaWN0IG1heSBvY2N1cikuICBIZW5jZSwgdGhlIFBDRSBuZWVkcyB0bw0KICAg YWxsb2NhdGUgYSBQTFNQLUlEIGZvciBMU1AyIGZyb20gdGhlIGluZ3Jlc3MgUENDJ3MgUExTUC1J RCBzcGFjZSAsDQogICBzYXkgMTAxLiAgU2ltaWxhcmx5IGZvciBMU1AxLCBpdCBoYXMgUExTUC1J RCAxMDAgYXQgdGhlIGluZ3Jlc3MsIGFuZA0KICAgbWF5IGhhdmUgc2F5IFBMU1AtSUQgMjAxIGF0 IHRoZSBlZ3Jlc3Mgbm9kZS4NCj09PT09ZW5kIGN1cnJlbnQNCg0KDQpNYXkgSSBwcm9wb3NlIHRo ZSBmb2xsb3dpbmcgdGV4dCAgKG9yIHNvbWV0aGluZyBsaWtlIGl0KSBpbnN0ZWFkOg0KDQogDQo9 PT1uZXcgcHJvcG9zYWwNCg0KICAgU2luY2UgdGhlIFBMU1AtSUQgc3BhY2UgaXMgaW5kZXBlbmRl bnQgYXQgZWFjaCBQQ0MsIHRoZSBQTFNQLUlEDQogICBhbGxvY2F0ZWQgYnkgdGhlIGVncmVzcyBQ Q0MgY2Fubm90IGJlIHVzZWQgZm9yIHRoZSBMU1AgYXQgdGhlDQogICBpbmdyZXNzIFBDQyAoUExT UC1JRCBjb25mbGljdCBtYXkgb2NjdXIpLiBBcyBwZXIgbm9ybWFsIFBDRS1JTklUIA0KICAgb3Bl cmF0aW9ucywgUENDIGFzc2lnbnMgdGhlIFBMU1AtSURzIGZvciBsb2NhbCBMU1BzLg0KICAgSGVu Y2UsIHdoZW4gdGhlIFBDRSBub3RpZmllcyBhbiBpbmdyZXNzIFBDQyBvZiB0aGUgcmV2ZXJzZSBl Z3Jlc3MgTFNQLCBpdA0KICAgZG9lcyBzbyB1c2luZyBQQ0UtSU5JVCBvcGVyYXRpb25zIGFuZCBz ZXRzIFBMU1AtSUQgdG8gemVybyBhbmQgc2V0cyB0aGUgUiBiaXQgaW4gdGhlIGFzc29jaWF0aW9u IA0KICAgb2JqZWN0IHRvIGluZGljYXRlIHRoYXQgdGhpcyBQQ0UtSU5JVCBMU1AgaXMgYSByZXZl cnNlIExTUC4gVGhlIFBDQyANCiAgIHVwb24gcmVjZWl2aW5nIHRoZSBQQ0UtSU5JVCBNVVNUIGxv Y2FsbHkgYXNzaWduIGEgUExTUC1JRCBhbmQgaXQgTVVTVA0KICAgaXNzdWUgYSBQQ1JFUE9SVCB0 byBQQ0UgZm9yIHRoaXMgTFNQIGNvbnRhaW5pbmcgdGhlIG5ldyBQTFNQLUlELiBUaGlzIA0KICAg TFNQIE1VU1QgTk9UIGJlIGluc3RhbnRpYXRlZCBvbiB0aGUgUENDLiANCg0KICAgRm9yIGV4YW1w bGUsIGluZ3Jlc3MgUENDMSB3YXkgbWF5IHJlcG9ydCB0byBQQ0UgYW4gTFNQIHdpdGggDQogICBQ TFNQLUlEIDEwMC4gRWdyZXNzIFBDQzIgbWF5IHJlcG9ydCB0byBQQ0UgYW4gTFNQIHdpdGggUExT UC1JRCAyMDAuIA0KICAgQm90aCBvZiB0aGVzZSBMU1BzIGFyZSBiaS1kaXJlY3Rpb25hbCBhc3Nv Y2lhdGVkLiBXaGVuIFBDRSANCiAgIG5vdGlmaWVzIFBDQzEgb2YgdGhlIFBDQzIgTFNQLCBpdCBk b2VzIHNvIGJ5IHNlbmRpbmcgYSBQQ0UtSU5JVCB0byBQQ0MxIHdpdGggDQogICBQTFNQLUlEIHNl dCB0byB6ZXJvIGFuZCBSIGJpdCBzZXQuIFBDQzEgdXBvbiByZWNlcHRpb24gb2YgdGhpcyBnZW5l cmF0ZXMgYSBQTFNQLUlEIA0KICAgKGV4YW1wbGUgUExTUC1JRCAzMDApIGFuZCBpc3N1ZXMgYSBQ Q1JFUE9SVCB0byBQQ0UuIA0KDQo9PT09PWVuZCBuZXcgcHJvcG9zYWwNCiAgIA0KDQoNCjwvZW5k IGFuZHJldzI+DQoNCg0KDQogDQoNCg== From nobody Thu Jan 23 07:37:12 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602FF12082D for ; Thu, 23 Jan 2020 07:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGj3eCttWMmO for ; Thu, 23 Jan 2020 07:37:08 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7253A120804 for ; Thu, 23 Jan 2020 07:37:08 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id m26so3898852ljc.13 for ; Thu, 23 Jan 2020 07:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fnXVvlpVWL4+OodCwYWjWP7FNpHE9elvW5hyaBIT+QI=; b=OEvhT4QUfhDPBoCM5XF2BRfTOXWQfwDHFSWRM35NTEbSVI5nPiiBoWMGfB3ONDbnjC 4I+0VUYwChxWVGw/cW6q7sARhF01Q3PTxKaFvadHlQbWSzp0cwtYj3crebAvX30/7lvO f5TR1kIVIpTbL4xHSWkr+eWAP+ycLYk97/UEp4kYe4A3xf/toofnoyXwCNzX6GDwsZ7t An1Nee25WpR3xQSaeipqPDpj9ZJUiOl5lGudp/PW4Y1C9BV2RlZOEtdANIyjGEpbf7O0 4FVU+QjP0HJpFEG0jVks+x7WnF3rbaMqTAIz1E/3au63jn1y52Y2OSAK4Nh6+dEegAqT tQYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fnXVvlpVWL4+OodCwYWjWP7FNpHE9elvW5hyaBIT+QI=; b=PdlfZf6lvi019vG9r/1GYMX/oQRfQ0ul9Ci5ZS76T7SO9n9fWwLxhrkHaPYhVFsWWr /ZUM7JtZAqK0d7RQ9Q8CvVjL9GbOh64u7oIXDGfaH2qWgbcK/SYkMHulU6V/95EhWGGR WVir0Fpw213QRzIzek2PDdchdts19jcqIoT1sJuC3SWGs4sa/0Ed2C56Gg0hV7fHG6cs pv1vUo0jrCIzFmh1GpLUw+btaJaBCcgQ/jDqtdAghpaxRXF4qw7ye9gmKuSGDPUDSkle 7qyA8gs50osKz5tA+O90uct0hB135HI6d+8PtMwP0BdyI4DHIiWKaTJYPQcbKWLurbZL q1vw== X-Gm-Message-State: APjAAAXp4z/yoJg/Oqgr+30scDNSCi+r4kJY9h7McTq2m4aEZjyHsoFv 2B5TyDxPvl+S+3f2Sc+NNkl8uofQM0/omhP+g1vF6biwmQ== X-Google-Smtp-Source: APXvYqzwUqcuOs49tT0rQhvAtHz0tM3lrsUUjIUpngoUCfrJzhLyater+EtG39fnKvjTjua01tL32Dn44unSU3EKVGo= X-Received: by 2002:a2e:e12:: with SMTP id 18mr23382626ljo.123.1579793826743; Thu, 23 Jan 2020 07:37:06 -0800 (PST) MIME-Version: 1.0 References: <2020012311514351840896@chinatelecom.cn> In-Reply-To: <2020012311514351840896@chinatelecom.cn> From: Rakesh Gandhi Date: Thu, 23 Jan 2020 10:36:55 -0500 Message-ID: To: "chenhuan6@chinatelecom.cn" Cc: "julien.meuric@orange.com" , "pce@ietf.org" Content-Type: multipart/alternative; boundary="000000000000dc8cca059cd0695f" Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 15:37:10 -0000 --000000000000dc8cca059cd0695f Content-Type: text/plain; charset="UTF-8" Hi Huanan, Thank you for your support. Do you mean how bidirectional SR would work with path protection as in: https://tools.ietf.org/html/draft-ietf-pce-stateful-path-protection-11 If yes, both are complementary. We can add text to indicate so. Thanks, Rakesh On Wed, Jan 22, 2020 at 10:53 PM chenhuan6@chinatelecom.cn < chenhuan6@chinatelecom.cn> wrote: > Hi WG, > > Support the adption. > I have read the draft, it is ready to be a WG document. > The extensions to PCEP were clear and the procedures to setup > bidirectional SR-LSP were given too. > One comment: If we need SR-LSP redundancy, how should we do at the bidirectional > SR-LSP scenario? > > Best Regards, > Huanan > > *From:* julien.meuric@orange.com > *Date:* 2020-01-17 18:12 > *To:* pce@ietf.org > *Subject:* [Pce] Adoption of draft-li-pce-sr-bidir-path-06? > Hi all, > > It is time to share your thoughts about draft-li-pce-sr-bidir-path-06. > Do you believe the I-D is a right foundation for a PCE WG item? Please > use the PCE mailing list to express your comments, support or > disagreement, including applicable rationale, especially for the latter. > > Thanks, > > Dhruv & Julien > > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --000000000000dc8cca059cd0695f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Huanan,
Thank you for your support.

Do you mean how bidirectional SR would work with path = protection as in:

If yes, bo= th are complementary. We can add text to indicate so.

<= div>Thanks,
Rakesh


On Wed, Jan 22, 2020= at 10:53 PM chenhuan6@chinate= lecom.cn <chenhuan6@chi= natelecom.cn> wrote:
Hi WG,

=C2=A0 =C2=A0Support the = adption.
=C2=A0 =C2=A0I have read the draft, it is ready to be a = WG document.
=C2=A0 =C2=A0The extensions to PCEP were clear and t= he procedures to setup bidirectional SR-LSP were given too.
=C2= =A0 =C2=A0One comment: If we need=C2=A0SR-LSP redundancy, how should we do= at the=C2=A0bidirectional SR-LSP scenario?

<= /span>
Best=C2=A0Regards,
Huanan

Date:=C2=A02020-01-17=C2=A018:12
To:=C2=A0pce@ietf.org
Subject:=C2=A0[Pce] Adoption of draft-li-pce-sr-bidir-path-= 06?
Hi all,
=C2=A0
It is time to share your thoughts about draft-li-pce-sr-bidir-path-06.=
Do you believe the I-D is a right foundation for a PCE WG item? Please=
use the PCE mailing list to express your comments, support or
disagreement, including applicable rationale, especially for the latte= r.
=C2=A0
Thanks,
=C2=A0
Dhruv & Julien
=C2=A0
=C2=A0
=C2=A0
=C2=A0
_______________________________________________
Pce mailing list
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
--000000000000dc8cca059cd0695f-- From nobody Thu Jan 23 08:12:57 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EE2120896 for ; Thu, 23 Jan 2020 08:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f39hGFk2Irsi for ; Thu, 23 Jan 2020 08:12:51 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFB81120887 for ; Thu, 23 Jan 2020 08:12:50 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id o11so4108584ljc.6 for ; Thu, 23 Jan 2020 08:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ICAONpWbne+T4yjfAyhB8fkC3o7vTvYvo2Iy1iEmdng=; b=Xj2cWpo3dGp7BIiTi+dXJnfgY/dx3wXwaNIkLhjh625qN7bjKiNvNV54r8LSurVjMY v2Q9JTXRkwatiuFxG0dovdNyUuo6rdlwjo4yhiH/UVIHxC0jENIfBUxg3PbbNqv4UTsK otaRF7ipm2yqy24YHLk/TWf6N5Pggv6VbXoLRtPPvbfnBpV1VYp4tNZydrENiEBzcNpq NKY6v02GtWhO9zB3JTSoW1F3OLBGco+Vwu16rlFcO/KfzjPoxiBu/UYl3yYcG2HsAvQV qtiAtpPj3bXxaOOCgdV3CNtHHC9139XQS9beUgtuikdyO5oCw6wrPxJjXT+C0rf5gCZg 7I5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ICAONpWbne+T4yjfAyhB8fkC3o7vTvYvo2Iy1iEmdng=; b=t3WZKtAmCRsP8AjO7kOwvLntvVhuu6UI5A23Wb2YbQYZasI+J0MBrZqXIeVm4OrBfY xRWRfv/EXxN8tB520AkAwFccv4o3sxu4+zLUYCvvka+MwW6KJ1UkZEOqWW7Vy/SnCh/t vQe5aH+tt6VLTxKSrgk6l7+Jag4bLQOBC4le4uAhn0L1U+CNjC7dOxNb6Q+MHZKTinqe OD3fTcnIPl4dYrbwH68DCg7FwSyPuSckIaLtgjcbdMPdGqpZhgKHOa3pxBKH+3hZIVsL Il0wcUfHQTSrKH+rfls/DEnZXeBqEQsxiTkIfpS50geOuWO0hMhvrbBQGP/pZnkN6aSE m0BQ== X-Gm-Message-State: APjAAAVoxGeQggKQ2pYeQcLCjt+J6dybxOwQOdI9+GYj4rAg6DQ69/wl 4JK8DXEnLpPFQr//ff7wQ13UyoUm9YRqgXAXCw== X-Google-Smtp-Source: APXvYqxHSelHkfacV760nI/Gf2oq5NrlXO8ikYJJrY577igNUF8QtyL/CeH4LZ0gdAGoT9Iu4qaqG6xqTd9an8LkbHM= X-Received: by 2002:a2e:b6ce:: with SMTP id m14mr2733044ljo.99.1579795968993; Thu, 23 Jan 2020 08:12:48 -0800 (PST) MIME-Version: 1.0 References: <4EA592A4-4749-4743-8255-BFE7D296A61C@nokia.com> <3587FF7A-97B3-43A4-B6B9-62197935B91F@nokia.com> In-Reply-To: From: Rakesh Gandhi Date: Thu, 23 Jan 2020 11:12:37 -0500 Message-ID: To: "Stone, Andrew (Nokia - CA/Ottawa)" Cc: Dhruv Dhody , "pce@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008cacca059cd0e9d4" Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 16:12:54 -0000 --0000000000008cacca059cd0e9d4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Andrew, Many thanks for your review comments. Please see below with .. On Wed, Jan 22, 2020 at 10:57 PM Stone, Andrew (Nokia - CA/Ottawa) < andrew.stone@nokia.com> wrote: > Hi Dhruv, > > Thanks again for the speedy reply. Comments below under > > Cheers > Andrew > > =EF=BB=BFOn 2020-01-22, 8:01 AM, "Dhruv Dhody" wro= te: > > Hi Andrew, > > On Wed, Jan 22, 2020 at 12:06 AM Stone, Andrew (Nokia - CA/Ottawa) > wrote: > > > > Hi Dhruv, > > > > Thanks for the reply and feedback. > > > > Could an implementation of PCE not simply just return error during > that situation? In diversity if too many LSPs grouped together and PCE > computationally can't support it, it returns a PCERR. So I would reason > that if bidirectionally associated and notify PCCs is necessary, but was > configured between SR and RSVP, that's also an error due to the (current) > unsupported feature set. I see this as trying to protect against day-0 > misconfig by changing the wire encoding within the protocol (which I'm no= t > necessarily against..). While I have doubt if it's a valid use case or > requirement in a production deployment, and it may have been acknowledged > before, but this essentially blocks associating SR LSP with RSVP LSP > bidirectionally for PCE to compute. > > > > Since the overall workflow doesn't change by this new type def, and > if SR<->RSVP associated is not reasonable requirement, and If consensus h= as > already been reached on this, and implementation already exist, I'm okay > with parking this topic. > > > > The SR draft does expect all LSPs to be SR for the new association > type and thus easier to handle. If you use a common association type, > the behavior would be dependent on the PST for the first LSP that is > added to the association. We could end up in a situation where Peer 1 > would add LSP 1 (SR) first and reject LSP 2 (RSVP-TE) and peer 2 woul= d > add LSP 2 (RSVP-TE) first and reject LSP 1 (SR). Also there might be = a > use for this mixed cases in future, which would require different > processing to be defined. > > > > > I will ponder on this some more. I'm undecided yet if the reasons to > protect config/behaviour mismatch, outweigh just having one type encoding > and defining the individual behaviours separately, which could also be up > to the local policy defined by the PCE implementation. > > It could be possible that a network has nodes currently running RSVP, wit= h > plans to migrate to SR-TE which could take a very long time due to the si= ze > of the network. The software running on the nodes may be upgraded, of whi= ch > those PCCs may have an implementation of these bidirectional drafts, but > have still not yet migrated to SR-TE. An operator may wish to leverage PC= E > feature sets on newer created services sooner than later (for example, > bidirectional capability) so they begin using bidirectional RSVP to have > symmetric paths for SLA reasons and aid in avoiding manual traffic > engineering. Over time, as the network is migrated to SR-TE tunnels you > have some nodes using SR-TE tunnels and the reverse nodes still operating > with RSVP. From an operator p.o.v the bidirectional notification behaviou= r > here wouldn't matter, they just want the LSPs to take the same resources > symmetrically. The feature set on PCE, as per the current draft wording a= nd > types will be broken. > > > I would think that the migration would happen for the whole bidirectional LSP on both endpoints at the same time. This is because, all nodes would have migrated to be SR aware in order for the forward path to be SR path (I am thinking co-routed). In addition, the complexity to associate the SR and RSVP paths into a bidirectional path is not small, given that SR path ingress node would know the reverse path via signaling whereas RSVP path ingress node would know via PCEP. Which also means, one would need to upgrade the RSVP ingress node anyways to learn the reverse SR path. Traffic steering and other functions for the RSVP path and SR path in the reverse direction (and vice versa) may bring additional work. Having said that, the same association group type can be used for SR and RSVP paths (e.g. both are the same PST) in theory, but given the implementation status in the draft, I will let respective co-authors comment. > > > > Still hoping for feedback regarding my comments on section 5. I see > that as being more significant, since it influences the workflow and at t= he > moment I don't see the dependency on draft-li-pce-controlled-id-space as > necessary to achieve notifying PCCs of reverse paths. > > > > And I was hoping that authors would take a bite :) > From what I understood PLSP-ID remains a PCC allocated ID. The point > that section 5 is making is that the same LSP would be identified by > two PLSP-IDs, one allocated by Ingress and another by Egress PCCs. > There is no proposal for PCE-controlled PLSP-ID. So PCE-init + R bit > is enough (as you state) and I am in full agreement with you that > figures with PLSP-ID could be useful. > > > > > > > Thanks for the comments and agreement. draft-li-pce-sr-bidir-path-06 > section 5.1, says "PCE needs to allocate a PLSP-ID". Perhaps it was just = a > typo and should have said PCC. > > =3D=3D=3Dcurrent > Since the PLSP-ID space is independent at each PCC, the PLSP-ID > allocated by the egress PCC can not be used for the LSP at the > ingress PCC (PLSP-ID conflict may occur). Hence, the PCE needs to > allocate a PLSP-ID for LSP2 from the ingress PCC's PLSP-ID space , > say 101. Similarly for LSP1, it has PLSP-ID 100 at the ingress, and > may have say PLSP-ID 201 at the egress node. > =3D=3D=3D=3D=3Dend current > > > May I propose the following text (or something like it) instead: > > > =3D=3D=3Dnew proposal > > Since the PLSP-ID space is independent at each PCC, the PLSP-ID > allocated by the egress PCC cannot be used for the LSP at the > ingress PCC (PLSP-ID conflict may occur). As per normal PCE-INIT > operations, PCC assigns the PLSP-IDs for local LSPs. > Hence, when the PCE notifies an ingress PCC of the reverse egress LSP, > it > does so using PCE-INIT operations and sets PLSP-ID to zero and sets th= e > R bit in the association > object to indicate that this PCE-INIT LSP is a reverse LSP. The PCC > upon receiving the PCE-INIT MUST locally assign a PLSP-ID and it MUST > issue a PCREPORT to PCE for this LSP containing the new PLSP-ID. This > LSP MUST NOT be instantiated on the PCC. > > For example, ingress PCC1 way may report to PCE an LSP with > PLSP-ID 100. Egress PCC2 may report to PCE an LSP with PLSP-ID 200. > Both of these LSPs are bi-directional associated. When PCE > notifies PCC1 of the PCC2 LSP, it does so by sending a PCE-INIT to PCC= 1 > with > PLSP-ID set to zero and R bit set. PCC1 upon reception of this > generates a PLSP-ID > (example PLSP-ID 300) and issues a PCREPORT to PCE. > > =3D=3D=3D=3D=3Dend new proposal > > Looks good to me. Thanks for the text. Many thanks Dhruv for the inputs. Thanks, Rakesh > > > > > > > --0000000000008cacca059cd0e9d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Andrew,

Many thanks for y= our review comments. Please see below with <RG2>..

On Wed, Jan 22,= 2020 at 10:57 PM Stone, Andrew (Nokia - CA/Ottawa) <andrew.stone@nokia.com> wrote:
Hi Dhruv,

Thanks again for the speedy reply. Comments below under <andrew2>

Cheers
Andrew

=EF=BB=BFOn 2020-01-22, 8:01 AM, "Dhruv Dhody" <dhruv.ietf@gmail.com> wr= ote:

=C2=A0 =C2=A0 Hi Andrew,

=C2=A0 =C2=A0 On Wed, Jan 22, 2020 at 12:06 AM Stone, Andrew (Nokia - CA/Ot= tawa)
=C2=A0 =C2=A0 <andrew.stone@nokia.com> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Hi Dhruv,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Thanks for the reply and feedback.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Could an implementation of PCE not simply just return er= ror during that situation? In diversity if too many LSPs grouped together a= nd PCE computationally can't support it, it returns a PCERR. So I would= reason that if bidirectionally associated and notify PCCs is necessary, bu= t was configured between SR and RSVP, that's also an error due to the (= current) unsupported feature set. I see this as trying to protect against d= ay-0 misconfig by changing the wire encoding within the protocol (which I&#= 39;m not necessarily against..). While I have doubt if it's a valid use= case or requirement in a production deployment, and it may have been ackno= wledged before, but this essentially blocks associating SR LSP with RSVP LS= P bidirectionally for PCE to compute.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Since the overall workflow doesn't change by this ne= w type def, and if SR<->RSVP associated is not reasonable requirement= , and If consensus has already been reached on this, and implementation alr= eady exist, I'm okay with parking this topic.
=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 The SR draft does expect all LSPs to be SR for the new associ= ation
=C2=A0 =C2=A0 type and thus easier to handle. If you use a common associati= on type,
=C2=A0 =C2=A0 the behavior would be dependent on the PST for the first LSP = that is
=C2=A0 =C2=A0 added to the association. We could end up in a situation wher= e Peer 1
=C2=A0 =C2=A0 would add LSP 1 (SR) first and reject LSP 2 (RSVP-TE) and pee= r 2 would
=C2=A0 =C2=A0 add LSP 2 (RSVP-TE) first and reject LSP 1 (SR). Also there m= ight be a
=C2=A0 =C2=A0 use for this mixed cases in future, which would require diffe= rent
=C2=A0 =C2=A0 processing to be defined.


<Andrew2>

I will ponder on this some more. I'm undecided yet if the reasons to pr= otect config/behaviour mismatch, outweigh just having one type encoding and= defining the individual behaviours separately, which could also be up to t= he local policy defined by the PCE implementation.

It could be possible that a network has nodes currently running RSVP, with = plans to migrate to SR-TE which could take a very long time due to the size= of the network. The software running on the nodes may be upgraded, of whic= h those PCCs may have an implementation of these bidirectional drafts, but = have still not yet migrated to SR-TE. An operator may wish to leverage PCE = feature sets on newer created services sooner than later (for example, bidi= rectional capability) so they begin using bidirectional RSVP to have symmet= ric paths for SLA reasons and aid in avoiding manual traffic engineering. O= ver time, as the network is migrated to SR-TE tunnels you have some nodes u= sing SR-TE tunnels and the reverse nodes still operating with RSVP. From an= operator p.o.v the bidirectional notification behaviour here wouldn't = matter, they just want the LSPs to take the same resources symmetrically. T= he feature set on PCE, as per the current draft wording and types will be b= roken.

</end andrew2>


<= ;RG2> I would think that the migration would happen for the whole bidire= ctional LSP on both endpoints at the same time. This is because, all nodes = would have migrated to be SR aware in order for the forward path to be SR p= ath (I am thinking co-routed). In addition, the complexity to associate the= SR and RSVP paths into a bidirectional path is not small, given that SR pa= th ingress node would know the reverse path via signaling whereas RSVP path= ingress node would know via PCEP.=C2=A0 Which also means, one would need t= o upgrade the RSVP ingress node anyways to learn the reverse SR path. Traff= ic steering and other functions for the RSVP path and SR path in the revers= e direction (and vice versa) may bring additional work.

<= /div>
<RG2> Having said that, the same association group type can= be used for SR and RSVP paths (e.g. both are the same PST) in theory, but = given the implementation status in the draft, I will let respective co-auth= ors comment.

=C2=A0


=C2=A0 =C2=A0 > Still hoping for feedback regarding my comments on secti= on 5. I see that as being more significant, since it influences the workflo= w and at the moment I don't see the dependency on draft-li-pce-controll= ed-id-space as necessary to achieve notifying PCCs of reverse paths.
=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 And I was hoping that authors would take a bite :)
=C2=A0 =C2=A0 From what I understood PLSP-ID remains a PCC allocated ID. Th= e point
=C2=A0 =C2=A0 that section 5 is making is that the same LSP would be identi= fied by
=C2=A0 =C2=A0 two PLSP-IDs, one allocated by Ingress and another by Egress = PCCs.
=C2=A0 =C2=A0 There is no proposal for PCE-controlled PLSP-ID. So PCE-init = + R bit
=C2=A0 =C2=A0 is enough=C2=A0 (as you state) and I am in full agreement wit= h you that
=C2=A0 =C2=A0 figures with PLSP-ID could be useful.




<Andrew2>

Thanks for the comments and agreement. draft-li-pce-sr-bidir-path-06 sectio= n 5.1, says "PCE needs to allocate a PLSP-ID". Perhaps it was jus= t a typo and should have said PCC.

=3D=3D=3Dcurrent
=C2=A0 =C2=A0Since the PLSP-ID space is independent at each PCC, the PLSP-I= D
=C2=A0 =C2=A0allocated by the egress PCC can not be used for the LSP at the=
=C2=A0 =C2=A0ingress PCC (PLSP-ID conflict may occur).=C2=A0 Hence, the PCE= needs to
=C2=A0 =C2=A0allocate a PLSP-ID for LSP2 from the ingress PCC's PLSP-ID= space ,
=C2=A0 =C2=A0say 101.=C2=A0 Similarly for LSP1, it has PLSP-ID 100 at the i= ngress, and
=C2=A0 =C2=A0may have say PLSP-ID 201 at the egress node.
=3D=3D=3D=3D=3Dend current


May I propose the following text=C2=A0 (or something like it) instead:


=3D=3D=3Dnew proposal

=C2=A0 =C2=A0Since the PLSP-ID space is independent at each PCC, the PLSP-I= D
=C2=A0 =C2=A0allocated by the egress PCC cannot be used for the LSP at the<= br> =C2=A0 =C2=A0ingress PCC (PLSP-ID conflict may occur). As per normal PCE-IN= IT
=C2=A0 =C2=A0operations, PCC assigns the PLSP-IDs for local LSPs.
=C2=A0 =C2=A0Hence, when the PCE notifies an ingress PCC of the reverse egr= ess LSP, it
=C2=A0 =C2=A0does so using PCE-INIT operations and sets PLSP-ID to zero and= sets the R bit in the association
=C2=A0 =C2=A0object to indicate that this PCE-INIT LSP is a reverse LSP. Th= e PCC
=C2=A0 =C2=A0upon receiving the PCE-INIT MUST locally assign a PLSP-ID and = it MUST
=C2=A0 =C2=A0issue a PCREPORT to PCE for this LSP containing the new PLSP-I= D. This
=C2=A0 =C2=A0LSP MUST NOT be instantiated on the PCC.

=C2=A0 =C2=A0For example, ingress PCC1 way may report to PCE an LSP with =C2=A0 =C2=A0PLSP-ID 100. Egress PCC2 may report to PCE an LSP with PLSP-ID= 200.
=C2=A0 =C2=A0Both of these LSPs are bi-directional associated. When PCE =C2=A0 =C2=A0notifies PCC1 of the PCC2 LSP, it does so by sending a PCE-INI= T to PCC1 with
=C2=A0 =C2=A0PLSP-ID set to zero and R bit set. PCC1 upon reception of this= generates a PLSP-ID
=C2=A0 =C2=A0(example PLSP-ID 300) and issues a PCREPORT to PCE.

=3D=3D=3D=3D=3Dend new proposal


<RG2> Looks good to me. Thanks f= or the text.
<RG2> Many thanks Dhruv for the inputs.

Thanks,
Rakesh

=C2=A0
</end andrew2>





--0000000000008cacca059cd0e9d4-- From nobody Thu Jan 23 09:34:06 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF201209BD; Thu, 23 Jan 2020 09:34:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <157980084004.22893.17013933502679686460@ietfa.amsl.com> Date: Thu, 23 Jan 2020 09:34:00 -0800 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-stateful-flags-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 17:34:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Updated Rules for Processing Stateful PCE Request Parameters Flags Author : Adrian Farrel Filename : draft-ietf-pce-stateful-flags-01.txt Pages : 7 Date : 2020-01-23 Abstract: Extensions to the Path Computation Element Communication Protocol (PCEP) to support stateful Path Computation Elements (PCEs) are defined in RFC 8231. One of the extensions is the Stateful PCE Request Parameters (SRP) object. That object includes a Flags field that is a set of 32 bit flags, and RFC 8281 defines an IANA registry for tracking assigned flags. However, RFC 8231 does not explain how an implementation should set unassigned flags in transmitted messages, nor how an implementation should process unassigned, unknown, or unsupported flags in received messages. This document updates RFC 8231 by defining the correct behaviors. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-flags/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-stateful-flags-01 https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-flags-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-flags-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 23 09:45:20 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823E01208FE for ; Thu, 23 Jan 2020 09:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbIGC7Hc3Okb for ; Thu, 23 Jan 2020 09:45:12 -0800 (PST) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A811208F6 for ; Thu, 23 Jan 2020 09:45:10 -0800 (PST) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 00NHj8FG012377 for ; Thu, 23 Jan 2020 17:45:08 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D916822042 for ; Thu, 23 Jan 2020 17:45:07 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id C3C0222048 for ; Thu, 23 Jan 2020 17:45:07 +0000 (GMT) Received: from LAPTOPK7AS653V (089144205018.atnat0014.highway.webapn.at [89.144.205.18]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 00NHj6H7016032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 23 Jan 2020 17:45:07 GMT Reply-To: From: "Adrian Farrel" To: References: <157980084004.22893.17013933502679686460@ietfa.amsl.com> In-Reply-To: <157980084004.22893.17013933502679686460@ietfa.amsl.com> Date: Thu, 23 Jan 2020 17:45:05 -0000 Organization: Old Dog Consulting Message-ID: <017c01d5d214$d97f5fc0$8c7e1f40$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQMZf6PT44/vZRx4YLpfAa/5l5aG26VxKgag Content-Language: en-gb X-Originating-IP: 89.144.205.18 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25186.000 X-TM-AS-Result: No--15.556-10.0-31-10 X-imss-scan-details: No--15.556-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25186.000 X-TMASE-Result: 10--15.556000-10.000000 X-TMASE-MatchedRID: xcONGPdDH5por4mPA3EMtnFPUrVDm6jtyeUl7aCTy8ggcEd8uJSjxHn9 HfuiScGpQIrDavfhGmzWsRv/PySSm8wrDggcQ6d1sgYw1+LBrk2hhKooH+/fy0Yx760ONDcWiPe lQ03e0/qmfhBPBLxyd301fJG/8na53nEpDU+5f9lTewUuJwIWFc8WrkDqCn1roA1qZKkyr6FBs1 Owil9bHd8nBU6vQ3Wv2nDxWn8ggSUR8xtB0+bQWzahjZPEodkXBuDI4IXfrj9Z+YxyNxdzRzFAn bbGkzx5cckWvCmsyW4Af/HImzvCGL8q1zjO7UWhFcK/QGNGRL2pXdWa4gU0S9rbWin3863fsmc+ HzD5HmiEijVvY3+ENOGzdbsR7OPYcydwnP3Uz7HH9K2ZqHQWltr+zN6MFrLIUYRf+2vAUZCjxYy RBa/qJX3mXSdV7KK4uPItwmogb15TptoDfp6JrMRB0bsfrpPIqxB32o9eGclVaBFytIQUtw== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Pce] I-D Action: draft-ietf-pce-stateful-flags-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 17:45:15 -0000 Hey WG! Changes here are to address comments (and a Discuss) from the IESG. The best thing to do (if you care) is to look at the diffs in the datatracker. Questions and comments are (of course) welcome. Best, Adrian -----Original Message----- From: I-D-Announce On Behalf Of internet-drafts@ietf.org Sent: 23 January 2020 17:34 To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: I-D Action: draft-ietf-pce-stateful-flags-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Updated Rules for Processing Stateful PCE Request Parameters Flags Author : Adrian Farrel Filename : draft-ietf-pce-stateful-flags-01.txt Pages : 7 Date : 2020-01-23 Abstract: Extensions to the Path Computation Element Communication Protocol (PCEP) to support stateful Path Computation Elements (PCEs) are defined in RFC 8231. One of the extensions is the Stateful PCE Request Parameters (SRP) object. That object includes a Flags field that is a set of 32 bit flags, and RFC 8281 defines an IANA registry for tracking assigned flags. However, RFC 8231 does not explain how an implementation should set unassigned flags in transmitted messages, nor how an implementation should process unassigned, unknown, or unsupported flags in received messages. This document updates RFC 8231 by defining the correct behaviors. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-flags/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-stateful-flags-01 https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-flags-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-flags-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/ _______________________________________________ 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 nobody Thu Jan 23 12:46:29 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC8912089B; Thu, 23 Jan 2020 12:46:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: pce@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157981238768.22798.2386861254779724682@ietfa.amsl.com> Date: Thu, 23 Jan 2020 12:46:27 -0800 Archived-At: Subject: [Pce] IPR Disclosure Cisco Systems, Inc.'s Statement about IPR related to draft-li-pce-sr-bidir-path X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 20:46:27 -0000 Dear Cheng Li, Mach Chen, Weiqiang Cheng, Zhenbin Li, Jie Dong, Rakesh Gandhi, Quan Xiong: An IPR disclosure that pertains to your Internet-Draft entitled "PCEP Extensions for Associated Bidirectional Segment Routing (SR) Paths" (draft-li-pce-sr-bidir-path) was submitted to the IETF Secretariat on 2020-01-23 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3978/). The title of the IPR disclosure is "Cisco Systems, Inc.'s Statement about IPR related to draft-li-pce-sr-bidir-path" Thank you IETF Secretariat From nobody Thu Jan 23 12:48:57 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9825912089B; Thu, 23 Jan 2020 12:48:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: pce@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157981253161.22814.17005511026402562682@ietfa.amsl.com> Date: Thu, 23 Jan 2020 12:48:51 -0800 Archived-At: Subject: [Pce] IPR Disclosure Cisco Systems, Inc.'s Statement about IPR related to draft-li-pce-sr-bidir-path X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 20:48:51 -0000 Dear Cheng Li, Mach Chen, Weiqiang Cheng, Zhenbin Li, Jie Dong, Rakesh Gandhi, Quan Xiong: An IPR disclosure that pertains to your Internet-Draft entitled "PCEP Extensions for Associated Bidirectional Segment Routing (SR) Paths" (draft-li-pce-sr-bidir-path) was submitted to the IETF Secretariat on 2020-01-23 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3978/). The title of the IPR disclosure is "Cisco Systems, Inc.'s Statement about IPR related to draft-li-pce-sr-bidir-path" Thank you IETF Secretariat From nobody Thu Jan 23 12:56:56 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49A8120823 for ; Thu, 23 Jan 2020 12:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9KwBffmrT65 for ; Thu, 23 Jan 2020 12:56:52 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 628091200CD for ; Thu, 23 Jan 2020 12:56:52 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id z22so5313061ljg.1 for ; Thu, 23 Jan 2020 12:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2EIH7EZs22QN7K54ekfUV4CuFsHp+AvpUbpnLanci1I=; b=a3j2b+np13CVaS//CP4rkF0lTpAmaDcv0SREkCAG4aco6nH934mSksXKERZ2pk0ArI RWCBfPyHjJraB9+b/NJ0Wa0KuqJrTrys12xHdMrvLhBYg1+LVfu53x4liBfL4m4/p0T7 8buQEidqkAi1hxofM72RayMCQMrQkEaVuRjID6cbz2HPmGleUx7C56NuqjiUVOPcu92E 587wSPqpgO1qNFk94B5ORyBI6htK+KekEyrEzSp5GLEPXukuA8KIJWO7flnSRyo8vnqt Tz6ftiKQEijteggaV/GctCy4sT+KGLSNtUshv7hxc4ZkwTDq15WltkyuEstTUJPNKvlC rskw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2EIH7EZs22QN7K54ekfUV4CuFsHp+AvpUbpnLanci1I=; b=BLg6GBdbPU0ii8+gDfn7PM0+eS/VKn8qaIwI3WjwASN9kzeCl+fc7K5VmNrpB137HZ WJvp43f7c0zjX2sNjvPXdkVBtD1nzsyCAfaq1wqaSoCgKDobsQxssN8vGJPjGYSji65F SWh2pTuhDtW4fr2r4zmBd9O7jBvm9Do5ZfjtMNkzDTLeyRh0kpe4gaDDWMU5S2yk2mG0 Vo4NziPgDB2uAeBpkgXupENwPuEMCwabydfZHpHsQ0HcpnwhfJMFy9AXU/or7Q4un/2P GwmWoinR42u1TFZ/T19xnArhzVRmoHhr/h7a1JRawfDXERJUcHj1pu3wAunvncbQ3doS rdPw== X-Gm-Message-State: APjAAAU1/skHpIVybcN4P/xYpdMQCJvsemdqr/6f2qTEnZiDKSti/MWy 5cyYXDRBrNcRJ3jFAOAO7TTikx0ofL8gMyDGuA== X-Google-Smtp-Source: APXvYqy+U4BoPmM0Y4U+Bl2n1RwhfwJSzxniCz9qN/F7x3R88x6psxTzCOYTGpEMD7z6Qon36abufUd9eRPfi3klKp4= X-Received: by 2002:a2e:58c:: with SMTP id 134mr172388ljf.12.1579813010549; Thu, 23 Jan 2020 12:56:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rakesh Gandhi Date: Thu, 23 Jan 2020 15:56:39 -0500 Message-ID: To: Hariharan Ananthakrishnan Cc: chengli13@huawei.com, Mach Chen , Weiqiang Cheng , lizhenbin@huawei.com, jie.dong@huawei.com, Rakesh Gandhi , xiong.quan@zte.com.cn, pce@ietf.org Content-Type: multipart/alternative; boundary="0000000000004e2eed059cd4e1d6" Archived-At: Subject: Re: [Pce] IPR Poll on draft-li-pce-sr-bidir-path-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 20:56:55 -0000 --0000000000004e2eed059cd4e1d6 Content-Type: text/plain; charset="UTF-8" Hi Hari, I am aware of an IPR applicable to this draft, and it has already been disclosed to the IETF. https://datatracker.ietf.org/ipr/3978/ Thanks, Rakesh On Fri, Jan 17, 2020 at 1:32 PM Hariharan Ananthakrishnan wrote: > Hi Authors, > > In preparation for Working Group adoption on this draft, I'd like all > authors and contributors to confirm on the list that they are in compliance > with IETF IPR rules. > > Please respond (copying the mailing list) to say one of: > > I am not aware of any IPR applicable to this draft that should be disclosed > in accordance with IETF IPR rules. > > I am aware of IPR applicable to this draft, and it has already been > disclosed to the IETF. > > I am aware of IPR applicable to this draft, but that has not yet been > disclosed to the IETF. I will work to ensure that it will be disclosed in a > timely manner. > > Thanks, > - Hari > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --0000000000004e2eed059cd4e1d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hari,
I am aware of an IPR applicable to= this draft, and it has already been disclosed to the IETF.

Thanks,
Rakesh

On Fri, Jan 17, 2020 at 1:32 PM Hariharan Ananthakrishnan <hari=3D40netflix.com@dmarc.ietf.org> wrote:
Hi Authors,

In preparation for Working Group adoption on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

I am aware of IPR applicable to this draft, and it has already been
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.

Thanks,
- Hari
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
--0000000000004e2eed059cd4e1d6-- From nobody Thu Jan 23 18:40:52 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B15120099 for ; Thu, 23 Jan 2020 18:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2deyXGI6oH5R for ; Thu, 23 Jan 2020 18:40:47 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on20731.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e1b::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3B9D120019 for ; Thu, 23 Jan 2020 18:40:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eVYqQLabjDpmk1bp1Hi0/8CQ0SYvM07geKTNQCXAaQznHgJ5JjYRFfPe7UXDkXcaBvO6OpgZYk9/pwl2cwQKR9Wj/cXnnT4x1NIDshzo0lrJNsBblAZVpRQxttPx4S9TzDyq4bbQ76r6V2kegaNR31ocIIvTRWRcHEfdccDDz5outOd7uATVWEIisAcETrx6OB9riS/2hhXDwgRnhSEDHMI6MzxGiS8XF3GGPUQ6eeT1DhAo0G2WcBNXvYlDTeooTozfjvxVc8m0cIAIk8LRfLMNw9OGq9DuDvUhIcE4K42Vp2usw5hI3Umc359fzEN2ngqnqES7QHpCA62asA07jQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6R3x8ytfvXzSHbZDj+wR/eq8ODtATKUXvVVb/40+Tls=; b=bBIcUQcAm8h9ZEIwt7Y1xA/RvFGF6AMa8esVAFWy4vm1ytD4+ZV9x+EM/3WhJI06bnUZHSQ9Mlx2zpQmxVD+x1VyijDobrADmtEuQz9EfCLsiMXarY3F8sSUVeqmk+rYOSUMh0+XWImBgSogG7eOkketUVQ+7ldHakK+8b4TEoOeFGZkvDQ8lCloEEyjYZGWdhhUkWOPwDu4TWHfwdz9zhetEwP/EzNYW6FF5J5XcpWz0S9GhP74M2PjE46NMiHlZ7Jv0YTDqUGkek5wvqRDlr7+qXaFQ21TVCUmjgwu9fO29v4RORZzICKd8W4tDY+JdTmq/ZCdcZGK/MzEEEE18g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6R3x8ytfvXzSHbZDj+wR/eq8ODtATKUXvVVb/40+Tls=; b=vTRERSoEWi6VkDDZG90Ze+o8H8CQwV7YV8EQk8w2VxUtMxA7YB98b7nAS+TSi7x51jEFGjyOxKjjLQZTEZo4HWjgmz3la4/mUuKbOmJwn+GGXf+R7a17wP3YP90x4EAMwaIu2FzvOwexnb83oSUayOvcOgB69cFavRcdmuy/5EI= Received: from AM0PR0702MB3619.eurprd07.prod.outlook.com (52.133.46.160) by AM0PR0702MB3587.eurprd07.prod.outlook.com (52.133.47.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.12; Fri, 24 Jan 2020 02:40:44 +0000 Received: from AM0PR0702MB3619.eurprd07.prod.outlook.com ([fe80::4139:54b9:238:669c]) by AM0PR0702MB3619.eurprd07.prod.outlook.com ([fe80::4139:54b9:238:669c%7]) with mapi id 15.20.2665.015; Fri, 24 Jan 2020 02:40:44 +0000 From: "Stone, Andrew (Nokia - CA/Ottawa)" To: Rakesh Gandhi CC: Dhruv Dhody , "pce@ietf.org" Thread-Topic: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? Thread-Index: AQHVzR6uiqJrBBVhq0SzaEKl30U2oKfvvJyUgAPq14D//7q+AIABhvmAgAA8DwCAAYiZAIAApowAgAEhP4CAAK25AA== Date: Fri, 24 Jan 2020 02:40:44 +0000 Message-ID: References: <4EA592A4-4749-4743-8255-BFE7D296A61C@nokia.com> <3587FF7A-97B3-43A4-B6B9-62197935B91F@nokia.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.stone@nokia.com; x-originating-ip: [24.53.248.71] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a4760f62-ac16-428b-b0d8-08d7a076cf60 x-ms-traffictypediagnostic: AM0PR0702MB3587: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02929ECF07 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(136003)(346002)(366004)(376002)(39860400002)(189003)(199004)(6916009)(6506007)(186003)(26005)(53546011)(7696005)(76116006)(91956017)(316002)(66946007)(66446008)(5660300002)(52536014)(66556008)(19627405001)(66476007)(64756008)(71200400001)(478600001)(55016002)(4326008)(54906003)(86362001)(9686003)(8936002)(2906002)(81156014)(81166006)(8676002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0702MB3587; H:AM0PR0702MB3619.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SMMLgKZbnAPE9frb+ujZM4cd6tUeFDYhZtpnaYlI5NekTIPyLR1jgWxAKNWjxvXznTt8aM5Eii3Ymsa9q62j9jZbQLDf/c9O9Jzn/LVlG1wr2vpy92RUmDRA3DlpwAd4H5Fz9n1HTfmjf0lDSeV0K5mWDAgPzRsl7lkeBTd8QkBGiilmPhuBem/LQw2D+FbO9sbiJhGfwVq3HoikvRiEJDOFJ+5FiZKhssNTP/UJk6HtQJ/iRW3osSzS0w/bG21m8HDf7zXwijjWC2ulX0od2OodepX+q5dNQvdl2U8HphbE2YowCGlArMjr8imU0vlIjMKfbvhZ3Q5aPDqoQfnAlctjKjYcieUSYSpYVHOFifAfIvnleMeGn26JNjao2sD8B32Y+1h3By59gM/rD0W9fup8VWDjzsGG2pjsZbFpPrF4egZ49AkAF9GMbQIDPziL x-ms-exchange-antispam-messagedata: Oip64SRLDx/Qcsu0orHrFDAvToFDPxnDos0uXrYlMZn2PIfBYdyWyCJfNjLSLWKkX4GfGOfs4rH5hAJuaohzqR3/l75Rn7s0oabm9Kh0YlPZOTQ5ws51bQcjEebZGgwa3H9RvOuL2TO455k5gVT4Lw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR0702MB36194BD4D324B79EF2C16932910E0AM0PR0702MB3619_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: a4760f62-ac16-428b-b0d8-08d7a076cf60 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2020 02:40:44.0870 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BquOpOmUMyteT0gfdd4eZBPeXNo0/CHvIvjX3vPp8plsv6i7DZVOFQm0AbrVVShq2YCCnlMa0ZiZthHcctWaVQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0702MB3587 Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 02:40:50 -0000 --_000_AM0PR0702MB36194BD4D324B79EF2C16932910E0AM0PR0702MB3619_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmFrZXNoLA0KDQpUaGFua3MgZm9yIHRoZSByZXBseSBhbmQgaW5wdXQuIEkgaW5pdGlhbGx5 IGhhZCB0aGUgc2FtZSB0aG91Z2h0IGFzIHdlbGw6ICJqdXN0IG1pZ3JhdGUgYm90aCBzaWRlcyBh dCB0aGUgc2FtZSB0aW1lIi4gT25seSBjb25jZXJuIGlzIG9mIGNvdXJzZSBzb21lIG1pZ3JhdGlv biBzdHJhdGVnaWVzIGNob29zZSB0byBtaWdyYXRlIHJlZ2lvbmFsbHkgb3Igbm9kZS1ieS1ub2Rl LCByYXRoZXIgdGhhbiB0dW5uZWwgcGFpcnMuIEluIHRoaXMgY2FzZSwgZGVmaW5pdGVseSB3aWxs IGhhdmUgdG8gZG8gYm90aCBzaWRlcyBhdCB0aGUgc2FtZSB0aW1lLiBJdCBtYXkgbm90IGFjdHVh bGx5IGJlIHRoYXQgdHJvdWJsZXNvbWUsIHNpbmNlIEknbSBub3QgYW4gb3BlcmF0b3IganVzdCBn b2luZyBieSB3aGF0IEkndmUgaGVhcmQgZnJvbSBjb2xsZWFndWVzIGFuZCB0aGVvcml6aW5nIHRo ZSBzaXR1YXRpb24uDQoNCkNoZWVycw0KQW5kcmV3DQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpGcm9tOiBSYWtlc2ggR2FuZGhpIDxyZ2FuZGhpLmlldGZAZ21haWwuY29tPg0K U2VudDogVGh1cnNkYXksIEphbnVhcnkgMjMsIDIwMjAgMTE6MTIgQU0NClRvOiBTdG9uZSwgQW5k cmV3IChOb2tpYSAtIENBL090dGF3YSkgPGFuZHJldy5zdG9uZUBub2tpYS5jb20+DQpDYzogRGhy dXYgRGhvZHkgPGRocnV2LmlldGZAZ21haWwuY29tPjsgcGNlQGlldGYub3JnIDxwY2VAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW1BjZV0gQWRvcHRpb24gb2YgZHJhZnQtbGktcGNlLXNyLWJpZGly LXBhdGgtMDY/DQoNCkhpIEFuZHJldywNCg0KTWFueSB0aGFua3MgZm9yIHlvdXIgcmV2aWV3IGNv bW1lbnRzLiBQbGVhc2Ugc2VlIGJlbG93IHdpdGggPFJHMj4uLg0KDQpPbiBXZWQsIEphbiAyMiwg MjAyMCBhdCAxMDo1NyBQTSBTdG9uZSwgQW5kcmV3IChOb2tpYSAtIENBL090dGF3YSkgPGFuZHJl dy5zdG9uZUBub2tpYS5jb208bWFpbHRvOmFuZHJldy5zdG9uZUBub2tpYS5jb20+PiB3cm90ZToN CkhpIERocnV2LA0KDQpUaGFua3MgYWdhaW4gZm9yIHRoZSBzcGVlZHkgcmVwbHkuIENvbW1lbnRz IGJlbG93IHVuZGVyIDxhbmRyZXcyPg0KDQpDaGVlcnMNCkFuZHJldw0KDQrvu79PbiAyMDIwLTAx LTIyLCA4OjAxIEFNLCAiRGhydXYgRGhvZHkiIDxkaHJ1di5pZXRmQGdtYWlsLmNvbTxtYWlsdG86 ZGhydXYuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCg0KICAgIEhpIEFuZHJldywNCg0KICAgIE9u IFdlZCwgSmFuIDIyLCAyMDIwIGF0IDEyOjA2IEFNIFN0b25lLCBBbmRyZXcgKE5va2lhIC0gQ0Ev T3R0YXdhKQ0KICAgIDxhbmRyZXcuc3RvbmVAbm9raWEuY29tPG1haWx0bzphbmRyZXcuc3RvbmVA bm9raWEuY29tPj4gd3JvdGU6DQogICAgPg0KICAgID4gSGkgRGhydXYsDQogICAgPg0KICAgID4g VGhhbmtzIGZvciB0aGUgcmVwbHkgYW5kIGZlZWRiYWNrLg0KICAgID4NCiAgICA+IENvdWxkIGFu IGltcGxlbWVudGF0aW9uIG9mIFBDRSBub3Qgc2ltcGx5IGp1c3QgcmV0dXJuIGVycm9yIGR1cmlu ZyB0aGF0IHNpdHVhdGlvbj8gSW4gZGl2ZXJzaXR5IGlmIHRvbyBtYW55IExTUHMgZ3JvdXBlZCB0 b2dldGhlciBhbmQgUENFIGNvbXB1dGF0aW9uYWxseSBjYW4ndCBzdXBwb3J0IGl0LCBpdCByZXR1 cm5zIGEgUENFUlIuIFNvIEkgd291bGQgcmVhc29uIHRoYXQgaWYgYmlkaXJlY3Rpb25hbGx5IGFz c29jaWF0ZWQgYW5kIG5vdGlmeSBQQ0NzIGlzIG5lY2Vzc2FyeSwgYnV0IHdhcyBjb25maWd1cmVk IGJldHdlZW4gU1IgYW5kIFJTVlAsIHRoYXQncyBhbHNvIGFuIGVycm9yIGR1ZSB0byB0aGUgKGN1 cnJlbnQpIHVuc3VwcG9ydGVkIGZlYXR1cmUgc2V0LiBJIHNlZSB0aGlzIGFzIHRyeWluZyB0byBw cm90ZWN0IGFnYWluc3QgZGF5LTAgbWlzY29uZmlnIGJ5IGNoYW5naW5nIHRoZSB3aXJlIGVuY29k aW5nIHdpdGhpbiB0aGUgcHJvdG9jb2wgKHdoaWNoIEknbSBub3QgbmVjZXNzYXJpbHkgYWdhaW5z dC4uKS4gV2hpbGUgSSBoYXZlIGRvdWJ0IGlmIGl0J3MgYSB2YWxpZCB1c2UgY2FzZSBvciByZXF1 aXJlbWVudCBpbiBhIHByb2R1Y3Rpb24gZGVwbG95bWVudCwgYW5kIGl0IG1heSBoYXZlIGJlZW4g YWNrbm93bGVkZ2VkIGJlZm9yZSwgYnV0IHRoaXMgZXNzZW50aWFsbHkgYmxvY2tzIGFzc29jaWF0 aW5nIFNSIExTUCB3aXRoIFJTVlAgTFNQIGJpZGlyZWN0aW9uYWxseSBmb3IgUENFIHRvIGNvbXB1 dGUuDQogICAgPg0KICAgID4gU2luY2UgdGhlIG92ZXJhbGwgd29ya2Zsb3cgZG9lc24ndCBjaGFu Z2UgYnkgdGhpcyBuZXcgdHlwZSBkZWYsIGFuZCBpZiBTUjwtPlJTVlAgYXNzb2NpYXRlZCBpcyBu b3QgcmVhc29uYWJsZSByZXF1aXJlbWVudCwgYW5kIElmIGNvbnNlbnN1cyBoYXMgYWxyZWFkeSBi ZWVuIHJlYWNoZWQgb24gdGhpcywgYW5kIGltcGxlbWVudGF0aW9uIGFscmVhZHkgZXhpc3QsIEkn bSBva2F5IHdpdGggcGFya2luZyB0aGlzIHRvcGljLg0KICAgID4NCg0KICAgIFRoZSBTUiBkcmFm dCBkb2VzIGV4cGVjdCBhbGwgTFNQcyB0byBiZSBTUiBmb3IgdGhlIG5ldyBhc3NvY2lhdGlvbg0K ICAgIHR5cGUgYW5kIHRodXMgZWFzaWVyIHRvIGhhbmRsZS4gSWYgeW91IHVzZSBhIGNvbW1vbiBh c3NvY2lhdGlvbiB0eXBlLA0KICAgIHRoZSBiZWhhdmlvciB3b3VsZCBiZSBkZXBlbmRlbnQgb24g dGhlIFBTVCBmb3IgdGhlIGZpcnN0IExTUCB0aGF0IGlzDQogICAgYWRkZWQgdG8gdGhlIGFzc29j aWF0aW9uLiBXZSBjb3VsZCBlbmQgdXAgaW4gYSBzaXR1YXRpb24gd2hlcmUgUGVlciAxDQogICAg d291bGQgYWRkIExTUCAxIChTUikgZmlyc3QgYW5kIHJlamVjdCBMU1AgMiAoUlNWUC1URSkgYW5k IHBlZXIgMiB3b3VsZA0KICAgIGFkZCBMU1AgMiAoUlNWUC1URSkgZmlyc3QgYW5kIHJlamVjdCBM U1AgMSAoU1IpLiBBbHNvIHRoZXJlIG1pZ2h0IGJlIGENCiAgICB1c2UgZm9yIHRoaXMgbWl4ZWQg Y2FzZXMgaW4gZnV0dXJlLCB3aGljaCB3b3VsZCByZXF1aXJlIGRpZmZlcmVudA0KICAgIHByb2Nl c3NpbmcgdG8gYmUgZGVmaW5lZC4NCg0KDQo8QW5kcmV3Mj4NCg0KSSB3aWxsIHBvbmRlciBvbiB0 aGlzIHNvbWUgbW9yZS4gSSdtIHVuZGVjaWRlZCB5ZXQgaWYgdGhlIHJlYXNvbnMgdG8gcHJvdGVj dCBjb25maWcvYmVoYXZpb3VyIG1pc21hdGNoLCBvdXR3ZWlnaCBqdXN0IGhhdmluZyBvbmUgdHlw ZSBlbmNvZGluZyBhbmQgZGVmaW5pbmcgdGhlIGluZGl2aWR1YWwgYmVoYXZpb3VycyBzZXBhcmF0 ZWx5LCB3aGljaCBjb3VsZCBhbHNvIGJlIHVwIHRvIHRoZSBsb2NhbCBwb2xpY3kgZGVmaW5lZCBi eSB0aGUgUENFIGltcGxlbWVudGF0aW9uLg0KDQpJdCBjb3VsZCBiZSBwb3NzaWJsZSB0aGF0IGEg bmV0d29yayBoYXMgbm9kZXMgY3VycmVudGx5IHJ1bm5pbmcgUlNWUCwgd2l0aCBwbGFucyB0byBt aWdyYXRlIHRvIFNSLVRFIHdoaWNoIGNvdWxkIHRha2UgYSB2ZXJ5IGxvbmcgdGltZSBkdWUgdG8g dGhlIHNpemUgb2YgdGhlIG5ldHdvcmsuIFRoZSBzb2Z0d2FyZSBydW5uaW5nIG9uIHRoZSBub2Rl cyBtYXkgYmUgdXBncmFkZWQsIG9mIHdoaWNoIHRob3NlIFBDQ3MgbWF5IGhhdmUgYW4gaW1wbGVt ZW50YXRpb24gb2YgdGhlc2UgYmlkaXJlY3Rpb25hbCBkcmFmdHMsIGJ1dCBoYXZlIHN0aWxsIG5v dCB5ZXQgbWlncmF0ZWQgdG8gU1ItVEUuIEFuIG9wZXJhdG9yIG1heSB3aXNoIHRvIGxldmVyYWdl IFBDRSBmZWF0dXJlIHNldHMgb24gbmV3ZXIgY3JlYXRlZCBzZXJ2aWNlcyBzb29uZXIgdGhhbiBs YXRlciAoZm9yIGV4YW1wbGUsIGJpZGlyZWN0aW9uYWwgY2FwYWJpbGl0eSkgc28gdGhleSBiZWdp biB1c2luZyBiaWRpcmVjdGlvbmFsIFJTVlAgdG8gaGF2ZSBzeW1tZXRyaWMgcGF0aHMgZm9yIFNM QSByZWFzb25zIGFuZCBhaWQgaW4gYXZvaWRpbmcgbWFudWFsIHRyYWZmaWMgZW5naW5lZXJpbmcu IE92ZXIgdGltZSwgYXMgdGhlIG5ldHdvcmsgaXMgbWlncmF0ZWQgdG8gU1ItVEUgdHVubmVscyB5 b3UgaGF2ZSBzb21lIG5vZGVzIHVzaW5nIFNSLVRFIHR1bm5lbHMgYW5kIHRoZSByZXZlcnNlIG5v ZGVzIHN0aWxsIG9wZXJhdGluZyB3aXRoIFJTVlAuIEZyb20gYW4gb3BlcmF0b3IgcC5vLnYgdGhl IGJpZGlyZWN0aW9uYWwgbm90aWZpY2F0aW9uIGJlaGF2aW91ciBoZXJlIHdvdWxkbid0IG1hdHRl ciwgdGhleSBqdXN0IHdhbnQgdGhlIExTUHMgdG8gdGFrZSB0aGUgc2FtZSByZXNvdXJjZXMgc3lt bWV0cmljYWxseS4gVGhlIGZlYXR1cmUgc2V0IG9uIFBDRSwgYXMgcGVyIHRoZSBjdXJyZW50IGRy YWZ0IHdvcmRpbmcgYW5kIHR5cGVzIHdpbGwgYmUgYnJva2VuLg0KDQo8L2VuZCBhbmRyZXcyPg0K DQoNCjxSRzI+IEkgd291bGQgdGhpbmsgdGhhdCB0aGUgbWlncmF0aW9uIHdvdWxkIGhhcHBlbiBm b3IgdGhlIHdob2xlIGJpZGlyZWN0aW9uYWwgTFNQIG9uIGJvdGggZW5kcG9pbnRzIGF0IHRoZSBz YW1lIHRpbWUuIFRoaXMgaXMgYmVjYXVzZSwgYWxsIG5vZGVzIHdvdWxkIGhhdmUgbWlncmF0ZWQg dG8gYmUgU1IgYXdhcmUgaW4gb3JkZXIgZm9yIHRoZSBmb3J3YXJkIHBhdGggdG8gYmUgU1IgcGF0 aCAoSSBhbSB0aGlua2luZyBjby1yb3V0ZWQpLiBJbiBhZGRpdGlvbiwgdGhlIGNvbXBsZXhpdHkg dG8gYXNzb2NpYXRlIHRoZSBTUiBhbmQgUlNWUCBwYXRocyBpbnRvIGEgYmlkaXJlY3Rpb25hbCBw YXRoIGlzIG5vdCBzbWFsbCwgZ2l2ZW4gdGhhdCBTUiBwYXRoIGluZ3Jlc3Mgbm9kZSB3b3VsZCBr bm93IHRoZSByZXZlcnNlIHBhdGggdmlhIHNpZ25hbGluZyB3aGVyZWFzIFJTVlAgcGF0aCBpbmdy ZXNzIG5vZGUgd291bGQga25vdyB2aWEgUENFUC4gIFdoaWNoIGFsc28gbWVhbnMsIG9uZSB3b3Vs ZCBuZWVkIHRvIHVwZ3JhZGUgdGhlIFJTVlAgaW5ncmVzcyBub2RlIGFueXdheXMgdG8gbGVhcm4g dGhlIHJldmVyc2UgU1IgcGF0aC4gVHJhZmZpYyBzdGVlcmluZyBhbmQgb3RoZXIgZnVuY3Rpb25z IGZvciB0aGUgUlNWUCBwYXRoIGFuZCBTUiBwYXRoIGluIHRoZSByZXZlcnNlIGRpcmVjdGlvbiAo YW5kIHZpY2UgdmVyc2EpIG1heSBicmluZyBhZGRpdGlvbmFsIHdvcmsuDQoNCjxSRzI+IEhhdmlu ZyBzYWlkIHRoYXQsIHRoZSBzYW1lIGFzc29jaWF0aW9uIGdyb3VwIHR5cGUgY2FuIGJlIHVzZWQg Zm9yIFNSIGFuZCBSU1ZQIHBhdGhzIChlLmcuIGJvdGggYXJlIHRoZSBzYW1lIFBTVCkgaW4gdGhl b3J5LCBidXQgZ2l2ZW4gdGhlIGltcGxlbWVudGF0aW9uIHN0YXR1cyBpbiB0aGUgZHJhZnQsIEkg d2lsbCBsZXQgcmVzcGVjdGl2ZSBjby1hdXRob3JzIGNvbW1lbnQuDQoNCg0KDQoNCiAgICA+IFN0 aWxsIGhvcGluZyBmb3IgZmVlZGJhY2sgcmVnYXJkaW5nIG15IGNvbW1lbnRzIG9uIHNlY3Rpb24g NS4gSSBzZWUgdGhhdCBhcyBiZWluZyBtb3JlIHNpZ25pZmljYW50LCBzaW5jZSBpdCBpbmZsdWVu Y2VzIHRoZSB3b3JrZmxvdyBhbmQgYXQgdGhlIG1vbWVudCBJIGRvbid0IHNlZSB0aGUgZGVwZW5k ZW5jeSBvbiBkcmFmdC1saS1wY2UtY29udHJvbGxlZC1pZC1zcGFjZSBhcyBuZWNlc3NhcnkgdG8g YWNoaWV2ZSBub3RpZnlpbmcgUENDcyBvZiByZXZlcnNlIHBhdGhzLg0KICAgID4NCg0KICAgIEFu ZCBJIHdhcyBob3BpbmcgdGhhdCBhdXRob3JzIHdvdWxkIHRha2UgYSBiaXRlIDopDQogICAgRnJv bSB3aGF0IEkgdW5kZXJzdG9vZCBQTFNQLUlEIHJlbWFpbnMgYSBQQ0MgYWxsb2NhdGVkIElELiBU aGUgcG9pbnQNCiAgICB0aGF0IHNlY3Rpb24gNSBpcyBtYWtpbmcgaXMgdGhhdCB0aGUgc2FtZSBM U1Agd291bGQgYmUgaWRlbnRpZmllZCBieQ0KICAgIHR3byBQTFNQLUlEcywgb25lIGFsbG9jYXRl ZCBieSBJbmdyZXNzIGFuZCBhbm90aGVyIGJ5IEVncmVzcyBQQ0NzLg0KICAgIFRoZXJlIGlzIG5v IHByb3Bvc2FsIGZvciBQQ0UtY29udHJvbGxlZCBQTFNQLUlELiBTbyBQQ0UtaW5pdCArIFIgYml0 DQogICAgaXMgZW5vdWdoICAoYXMgeW91IHN0YXRlKSBhbmQgSSBhbSBpbiBmdWxsIGFncmVlbWVu dCB3aXRoIHlvdSB0aGF0DQogICAgZmlndXJlcyB3aXRoIFBMU1AtSUQgY291bGQgYmUgdXNlZnVs Lg0KDQoNCg0KDQo8QW5kcmV3Mj4NCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudHMgYW5kIGFncmVl bWVudC4gZHJhZnQtbGktcGNlLXNyLWJpZGlyLXBhdGgtMDYgc2VjdGlvbiA1LjEsIHNheXMgIlBD RSBuZWVkcyB0byBhbGxvY2F0ZSBhIFBMU1AtSUQiLiBQZXJoYXBzIGl0IHdhcyBqdXN0IGEgdHlw byBhbmQgc2hvdWxkIGhhdmUgc2FpZCBQQ0MuDQoNCj09PWN1cnJlbnQNCiAgIFNpbmNlIHRoZSBQ TFNQLUlEIHNwYWNlIGlzIGluZGVwZW5kZW50IGF0IGVhY2ggUENDLCB0aGUgUExTUC1JRA0KICAg YWxsb2NhdGVkIGJ5IHRoZSBlZ3Jlc3MgUENDIGNhbiBub3QgYmUgdXNlZCBmb3IgdGhlIExTUCBh dCB0aGUNCiAgIGluZ3Jlc3MgUENDIChQTFNQLUlEIGNvbmZsaWN0IG1heSBvY2N1cikuICBIZW5j ZSwgdGhlIFBDRSBuZWVkcyB0bw0KICAgYWxsb2NhdGUgYSBQTFNQLUlEIGZvciBMU1AyIGZyb20g dGhlIGluZ3Jlc3MgUENDJ3MgUExTUC1JRCBzcGFjZSAsDQogICBzYXkgMTAxLiAgU2ltaWxhcmx5 IGZvciBMU1AxLCBpdCBoYXMgUExTUC1JRCAxMDAgYXQgdGhlIGluZ3Jlc3MsIGFuZA0KICAgbWF5 IGhhdmUgc2F5IFBMU1AtSUQgMjAxIGF0IHRoZSBlZ3Jlc3Mgbm9kZS4NCj09PT09ZW5kIGN1cnJl bnQNCg0KDQpNYXkgSSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgdGV4dCAgKG9yIHNvbWV0aGluZyBs aWtlIGl0KSBpbnN0ZWFkOg0KDQoNCj09PW5ldyBwcm9wb3NhbA0KDQogICBTaW5jZSB0aGUgUExT UC1JRCBzcGFjZSBpcyBpbmRlcGVuZGVudCBhdCBlYWNoIFBDQywgdGhlIFBMU1AtSUQNCiAgIGFs bG9jYXRlZCBieSB0aGUgZWdyZXNzIFBDQyBjYW5ub3QgYmUgdXNlZCBmb3IgdGhlIExTUCBhdCB0 aGUNCiAgIGluZ3Jlc3MgUENDIChQTFNQLUlEIGNvbmZsaWN0IG1heSBvY2N1cikuIEFzIHBlciBu b3JtYWwgUENFLUlOSVQNCiAgIG9wZXJhdGlvbnMsIFBDQyBhc3NpZ25zIHRoZSBQTFNQLUlEcyBm b3IgbG9jYWwgTFNQcy4NCiAgIEhlbmNlLCB3aGVuIHRoZSBQQ0Ugbm90aWZpZXMgYW4gaW5ncmVz cyBQQ0Mgb2YgdGhlIHJldmVyc2UgZWdyZXNzIExTUCwgaXQNCiAgIGRvZXMgc28gdXNpbmcgUENF LUlOSVQgb3BlcmF0aW9ucyBhbmQgc2V0cyBQTFNQLUlEIHRvIHplcm8gYW5kIHNldHMgdGhlIFIg Yml0IGluIHRoZSBhc3NvY2lhdGlvbg0KICAgb2JqZWN0IHRvIGluZGljYXRlIHRoYXQgdGhpcyBQ Q0UtSU5JVCBMU1AgaXMgYSByZXZlcnNlIExTUC4gVGhlIFBDQw0KICAgdXBvbiByZWNlaXZpbmcg dGhlIFBDRS1JTklUIE1VU1QgbG9jYWxseSBhc3NpZ24gYSBQTFNQLUlEIGFuZCBpdCBNVVNUDQog ICBpc3N1ZSBhIFBDUkVQT1JUIHRvIFBDRSBmb3IgdGhpcyBMU1AgY29udGFpbmluZyB0aGUgbmV3 IFBMU1AtSUQuIFRoaXMNCiAgIExTUCBNVVNUIE5PVCBiZSBpbnN0YW50aWF0ZWQgb24gdGhlIFBD Qy4NCg0KICAgRm9yIGV4YW1wbGUsIGluZ3Jlc3MgUENDMSB3YXkgbWF5IHJlcG9ydCB0byBQQ0Ug YW4gTFNQIHdpdGgNCiAgIFBMU1AtSUQgMTAwLiBFZ3Jlc3MgUENDMiBtYXkgcmVwb3J0IHRvIFBD RSBhbiBMU1Agd2l0aCBQTFNQLUlEIDIwMC4NCiAgIEJvdGggb2YgdGhlc2UgTFNQcyBhcmUgYmkt ZGlyZWN0aW9uYWwgYXNzb2NpYXRlZC4gV2hlbiBQQ0UNCiAgIG5vdGlmaWVzIFBDQzEgb2YgdGhl IFBDQzIgTFNQLCBpdCBkb2VzIHNvIGJ5IHNlbmRpbmcgYSBQQ0UtSU5JVCB0byBQQ0MxIHdpdGgN CiAgIFBMU1AtSUQgc2V0IHRvIHplcm8gYW5kIFIgYml0IHNldC4gUENDMSB1cG9uIHJlY2VwdGlv biBvZiB0aGlzIGdlbmVyYXRlcyBhIFBMU1AtSUQNCiAgIChleGFtcGxlIFBMU1AtSUQgMzAwKSBh bmQgaXNzdWVzIGEgUENSRVBPUlQgdG8gUENFLg0KDQo9PT09PWVuZCBuZXcgcHJvcG9zYWwNCg0K DQo8UkcyPiBMb29rcyBnb29kIHRvIG1lLiBUaGFua3MgZm9yIHRoZSB0ZXh0Lg0KPFJHMj4gTWFu eSB0aGFua3MgRGhydXYgZm9yIHRoZSBpbnB1dHMuDQoNClRoYW5rcywNClJha2VzaA0KDQoNCg0K PC9lbmQgYW5kcmV3Mj4NCg0KDQoNCg0KDQo= --_000_AM0PR0702MB36194BD4D324B79EF2C16932910E0AM0PR0702MB3619_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPiBQIHttYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO30gPC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBD YWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNv bG9yOiByZ2IoMCwgMCwgMCk7Ij4NCkhpIFJha2VzaCw8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6IENhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KVGhhbmtzIGZvciB0aGUgcmVwbHkg YW5kIGlucHV0LiBJIGluaXRpYWxseSBoYWQgdGhlIHNhbWUgdGhvdWdodCBhcyB3ZWxsOiAmcXVv dDtqdXN0IG1pZ3JhdGUgYm90aCBzaWRlcyBhdCB0aGUgc2FtZSB0aW1lJnF1b3Q7LiBPbmx5IGNv bmNlcm4gaXMgb2YgY291cnNlIHNvbWUgbWlncmF0aW9uIHN0cmF0ZWdpZXMgY2hvb3NlIHRvIG1p Z3JhdGUgcmVnaW9uYWxseSBvciBub2RlLWJ5LW5vZGUsIHJhdGhlciB0aGFuIHR1bm5lbCBwYWly cy4gSW4gdGhpcyBjYXNlLCBkZWZpbml0ZWx5DQogd2lsbCBoYXZlIHRvIGRvIGJvdGggc2lkZXMg YXQgdGhlIHNhbWUgdGltZS4gSXQgbWF5IG5vdCBhY3R1YWxseSBiZSB0aGF0IHRyb3VibGVzb21l LCBzaW5jZSBJJ20gbm90IGFuIG9wZXJhdG9yIGp1c3QgZ29pbmcgYnkgd2hhdCBJJ3ZlIGhlYXJk IGZyb20gY29sbGVhZ3VlcyBhbmQgdGhlb3JpemluZyB0aGUgc2l0dWF0aW9uLjxicj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KPGJyPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGlj YSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQpD aGVlcnM8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlh bCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwg MCwgMCk7Ij4NCkFuZHJldzxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9ImFwcGVuZG9uc2Vu ZCI+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGlj YSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTJwdDsgY29sb3I6cmdiKDAsMCwwKSI+DQo8YnI+DQo8 L2Rpdj4NCjxociB0YWJpbmRleD0iLTEiIHN0eWxlPSJkaXNwbGF5OmlubGluZS1ibG9jazsgd2lk dGg6OTglIj4NCjxkaXYgaWQ9ImRpdlJwbHlGd2RNc2ciIGRpcj0ibHRyIj48Zm9udCBzdHlsZT0i Zm9udC1zaXplOjExcHQiIGZhY2U9IkNhbGlicmksIHNhbnMtc2VyaWYiIGNvbG9yPSIjMDAwMDAw Ij48Yj5Gcm9tOjwvYj4gUmFrZXNoIEdhbmRoaSAmbHQ7cmdhbmRoaS5pZXRmQGdtYWlsLmNvbSZn dDs8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEphbnVhcnkgMjMsIDIwMjAgMTE6MTIgQU08 YnI+DQo8Yj5Ubzo8L2I+IFN0b25lLCBBbmRyZXcgKE5va2lhIC0gQ0EvT3R0YXdhKSAmbHQ7YW5k cmV3LnN0b25lQG5va2lhLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IERocnV2IERob2R5ICZsdDtk aHJ1di5pZXRmQGdtYWlsLmNvbSZndDs7IHBjZUBpZXRmLm9yZyAmbHQ7cGNlQGlldGYub3JnJmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1BjZV0gQWRvcHRpb24gb2YgZHJhZnQtbGktcGNl LXNyLWJpZGlyLXBhdGgtMDY/PC9mb250Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj5IaSBBbmRyZXcsPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5NYW55IHRoYW5rcyBmb3IgeW91ciByZXZpZXcgY29tbWVudHMuIFBsZWFzZSBz ZWUgYmVsb3cgd2l0aCAmbHQ7UkcyJmd0Oy4uPGJyPg0KPC9kaXY+DQo8YnI+DQo8ZGl2IGNsYXNz PSJ4X2dtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJ4X2dtYWlsX2F0dHIiPk9u IFdlZCwgSmFuIDIyLCAyMDIwIGF0IDEwOjU3IFBNIFN0b25lLCBBbmRyZXcgKE5va2lhIC0gQ0Ev T3R0YXdhKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHJldy5zdG9uZUBub2tpYS5jb20iPmFuZHJl dy5zdG9uZUBub2tpYS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IGNsYXNzPSJ4X2dtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4OyBi b3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTsgcGFkZGluZy1sZWZ0OjFleCI+ DQpIaSBEaHJ1diw8YnI+DQo8YnI+DQpUaGFua3MgYWdhaW4gZm9yIHRoZSBzcGVlZHkgcmVwbHku IENvbW1lbnRzIGJlbG93IHVuZGVyICZsdDthbmRyZXcyJmd0Ozxicj4NCjxicj4NCkNoZWVyczxi cj4NCkFuZHJldzxicj4NCjxicj4NCu+7v09uIDIwMjAtMDEtMjIsIDg6MDEgQU0sICZxdW90O0Ro cnV2IERob2R5JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZGhydXYuaWV0ZkBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj5kaHJ1di5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDsgSGkgQW5kcmV3LDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsg T24gV2VkLCBKYW4gMjIsIDIwMjAgYXQgMTI6MDYgQU0gU3RvbmUsIEFuZHJldyAoTm9raWEgLSBD QS9PdHRhd2EpPGJyPg0KJm5ic3A7ICZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHJldy5z dG9uZUBub2tpYS5jb20iIHRhcmdldD0iX2JsYW5rIj5hbmRyZXcuc3RvbmVAbm9raWEuY29tPC9h PiZndDsgd3JvdGU6PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAm Z3Q7IEhpIERocnV2LDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsg Jmd0OyBUaGFua3MgZm9yIHRoZSByZXBseSBhbmQgZmVlZGJhY2suPGJyPg0KJm5ic3A7ICZuYnNw OyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IENvdWxkIGFuIGltcGxlbWVudGF0aW9uIG9m IFBDRSBub3Qgc2ltcGx5IGp1c3QgcmV0dXJuIGVycm9yIGR1cmluZyB0aGF0IHNpdHVhdGlvbj8g SW4gZGl2ZXJzaXR5IGlmIHRvbyBtYW55IExTUHMgZ3JvdXBlZCB0b2dldGhlciBhbmQgUENFIGNv bXB1dGF0aW9uYWxseSBjYW4ndCBzdXBwb3J0IGl0LCBpdCByZXR1cm5zIGEgUENFUlIuIFNvIEkg d291bGQgcmVhc29uIHRoYXQgaWYgYmlkaXJlY3Rpb25hbGx5IGFzc29jaWF0ZWQgYW5kIG5vdGlm eQ0KIFBDQ3MgaXMgbmVjZXNzYXJ5LCBidXQgd2FzIGNvbmZpZ3VyZWQgYmV0d2VlbiBTUiBhbmQg UlNWUCwgdGhhdCdzIGFsc28gYW4gZXJyb3IgZHVlIHRvIHRoZSAoY3VycmVudCkgdW5zdXBwb3J0 ZWQgZmVhdHVyZSBzZXQuIEkgc2VlIHRoaXMgYXMgdHJ5aW5nIHRvIHByb3RlY3QgYWdhaW5zdCBk YXktMCBtaXNjb25maWcgYnkgY2hhbmdpbmcgdGhlIHdpcmUgZW5jb2Rpbmcgd2l0aGluIHRoZSBw cm90b2NvbCAod2hpY2ggSSdtIG5vdCBuZWNlc3NhcmlseQ0KIGFnYWluc3QuLikuIFdoaWxlIEkg aGF2ZSBkb3VidCBpZiBpdCdzIGEgdmFsaWQgdXNlIGNhc2Ugb3IgcmVxdWlyZW1lbnQgaW4gYSBw cm9kdWN0aW9uIGRlcGxveW1lbnQsIGFuZCBpdCBtYXkgaGF2ZSBiZWVuIGFja25vd2xlZGdlZCBi ZWZvcmUsIGJ1dCB0aGlzIGVzc2VudGlhbGx5IGJsb2NrcyBhc3NvY2lhdGluZyBTUiBMU1Agd2l0 aCBSU1ZQIExTUCBiaWRpcmVjdGlvbmFsbHkgZm9yIFBDRSB0byBjb21wdXRlLjxicj4NCiZuYnNw OyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBTaW5jZSB0aGUgb3ZlcmFsbCB3 b3JrZmxvdyBkb2Vzbid0IGNoYW5nZSBieSB0aGlzIG5ldyB0eXBlIGRlZiwgYW5kIGlmIFNSJmx0 Oy0mZ3Q7UlNWUCBhc3NvY2lhdGVkIGlzIG5vdCByZWFzb25hYmxlIHJlcXVpcmVtZW50LCBhbmQg SWYgY29uc2Vuc3VzIGhhcyBhbHJlYWR5IGJlZW4gcmVhY2hlZCBvbiB0aGlzLCBhbmQgaW1wbGVt ZW50YXRpb24gYWxyZWFkeSBleGlzdCwgSSdtIG9rYXkgd2l0aCBwYXJraW5nIHRoaXMgdG9waWMu PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGUgU1Ig ZHJhZnQgZG9lcyBleHBlY3QgYWxsIExTUHMgdG8gYmUgU1IgZm9yIHRoZSBuZXcgYXNzb2NpYXRp b248YnI+DQombmJzcDsgJm5ic3A7IHR5cGUgYW5kIHRodXMgZWFzaWVyIHRvIGhhbmRsZS4gSWYg eW91IHVzZSBhIGNvbW1vbiBhc3NvY2lhdGlvbiB0eXBlLDxicj4NCiZuYnNwOyAmbmJzcDsgdGhl IGJlaGF2aW9yIHdvdWxkIGJlIGRlcGVuZGVudCBvbiB0aGUgUFNUIGZvciB0aGUgZmlyc3QgTFNQ IHRoYXQgaXM8YnI+DQombmJzcDsgJm5ic3A7IGFkZGVkIHRvIHRoZSBhc3NvY2lhdGlvbi4gV2Ug Y291bGQgZW5kIHVwIGluIGEgc2l0dWF0aW9uIHdoZXJlIFBlZXIgMTxicj4NCiZuYnNwOyAmbmJz cDsgd291bGQgYWRkIExTUCAxIChTUikgZmlyc3QgYW5kIHJlamVjdCBMU1AgMiAoUlNWUC1URSkg YW5kIHBlZXIgMiB3b3VsZDxicj4NCiZuYnNwOyAmbmJzcDsgYWRkIExTUCAyIChSU1ZQLVRFKSBm aXJzdCBhbmQgcmVqZWN0IExTUCAxIChTUikuIEFsc28gdGhlcmUgbWlnaHQgYmUgYTxicj4NCiZu YnNwOyAmbmJzcDsgdXNlIGZvciB0aGlzIG1peGVkIGNhc2VzIGluIGZ1dHVyZSwgd2hpY2ggd291 bGQgcmVxdWlyZSBkaWZmZXJlbnQ8YnI+DQombmJzcDsgJm5ic3A7IHByb2Nlc3NpbmcgdG8gYmUg ZGVmaW5lZC48YnI+DQo8YnI+DQo8YnI+DQombHQ7QW5kcmV3MiZndDsgPGJyPg0KPGJyPg0KSSB3 aWxsIHBvbmRlciBvbiB0aGlzIHNvbWUgbW9yZS4gSSdtIHVuZGVjaWRlZCB5ZXQgaWYgdGhlIHJl YXNvbnMgdG8gcHJvdGVjdCBjb25maWcvYmVoYXZpb3VyIG1pc21hdGNoLCBvdXR3ZWlnaCBqdXN0 IGhhdmluZyBvbmUgdHlwZSBlbmNvZGluZyBhbmQgZGVmaW5pbmcgdGhlIGluZGl2aWR1YWwgYmVo YXZpb3VycyBzZXBhcmF0ZWx5LCB3aGljaCBjb3VsZCBhbHNvIGJlIHVwIHRvIHRoZSBsb2NhbCBw b2xpY3kgZGVmaW5lZCBieSB0aGUgUENFIGltcGxlbWVudGF0aW9uLg0KPGJyPg0KPGJyPg0KSXQg Y291bGQgYmUgcG9zc2libGUgdGhhdCBhIG5ldHdvcmsgaGFzIG5vZGVzIGN1cnJlbnRseSBydW5u aW5nIFJTVlAsIHdpdGggcGxhbnMgdG8gbWlncmF0ZSB0byBTUi1URSB3aGljaCBjb3VsZCB0YWtl IGEgdmVyeSBsb25nIHRpbWUgZHVlIHRvIHRoZSBzaXplIG9mIHRoZSBuZXR3b3JrLiBUaGUgc29m dHdhcmUgcnVubmluZyBvbiB0aGUgbm9kZXMgbWF5IGJlIHVwZ3JhZGVkLCBvZiB3aGljaCB0aG9z ZSBQQ0NzIG1heSBoYXZlIGFuIGltcGxlbWVudGF0aW9uDQogb2YgdGhlc2UgYmlkaXJlY3Rpb25h bCBkcmFmdHMsIGJ1dCBoYXZlIHN0aWxsIG5vdCB5ZXQgbWlncmF0ZWQgdG8gU1ItVEUuIEFuIG9w ZXJhdG9yIG1heSB3aXNoIHRvIGxldmVyYWdlIFBDRSBmZWF0dXJlIHNldHMgb24gbmV3ZXIgY3Jl YXRlZCBzZXJ2aWNlcyBzb29uZXIgdGhhbiBsYXRlciAoZm9yIGV4YW1wbGUsIGJpZGlyZWN0aW9u YWwgY2FwYWJpbGl0eSkgc28gdGhleSBiZWdpbiB1c2luZyBiaWRpcmVjdGlvbmFsIFJTVlAgdG8g aGF2ZSBzeW1tZXRyaWMNCiBwYXRocyBmb3IgU0xBIHJlYXNvbnMgYW5kIGFpZCBpbiBhdm9pZGlu ZyBtYW51YWwgdHJhZmZpYyBlbmdpbmVlcmluZy4gT3ZlciB0aW1lLCBhcyB0aGUgbmV0d29yayBp cyBtaWdyYXRlZCB0byBTUi1URSB0dW5uZWxzIHlvdSBoYXZlIHNvbWUgbm9kZXMgdXNpbmcgU1It VEUgdHVubmVscyBhbmQgdGhlIHJldmVyc2Ugbm9kZXMgc3RpbGwgb3BlcmF0aW5nIHdpdGggUlNW UC4gRnJvbSBhbiBvcGVyYXRvciBwLm8udiB0aGUgYmlkaXJlY3Rpb25hbCBub3RpZmljYXRpb24N CiBiZWhhdmlvdXIgaGVyZSB3b3VsZG4ndCBtYXR0ZXIsIHRoZXkganVzdCB3YW50IHRoZSBMU1Bz IHRvIHRha2UgdGhlIHNhbWUgcmVzb3VyY2VzIHN5bW1ldHJpY2FsbHkuIFRoZSBmZWF0dXJlIHNl dCBvbiBQQ0UsIGFzIHBlciB0aGUgY3VycmVudCBkcmFmdCB3b3JkaW5nIGFuZCB0eXBlcyB3aWxs IGJlIGJyb2tlbi4NCjxicj4NCjxicj4NCiZsdDsvZW5kIGFuZHJldzImZ3Q7PGJyPg0KPC9ibG9j a3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PiZsdDtS RzImZ3Q7IEkgd291bGQgdGhpbmsgdGhhdCB0aGUgbWlncmF0aW9uIHdvdWxkIGhhcHBlbiBmb3Ig dGhlIHdob2xlIGJpZGlyZWN0aW9uYWwgTFNQIG9uIGJvdGggZW5kcG9pbnRzIGF0IHRoZSBzYW1l IHRpbWUuIFRoaXMgaXMgYmVjYXVzZSwgYWxsIG5vZGVzIHdvdWxkIGhhdmUgbWlncmF0ZWQgdG8g YmUgU1IgYXdhcmUgaW4gb3JkZXIgZm9yIHRoZSBmb3J3YXJkIHBhdGggdG8gYmUgU1IgcGF0aCAo SSBhbSB0aGlua2luZyBjby1yb3V0ZWQpLg0KIEluIGFkZGl0aW9uLCB0aGUgY29tcGxleGl0eSB0 byBhc3NvY2lhdGUgdGhlIFNSIGFuZCBSU1ZQIHBhdGhzIGludG8gYSBiaWRpcmVjdGlvbmFsIHBh dGggaXMgbm90IHNtYWxsLCBnaXZlbiB0aGF0IFNSIHBhdGggaW5ncmVzcyBub2RlIHdvdWxkIGtu b3cgdGhlIHJldmVyc2UgcGF0aCB2aWEgc2lnbmFsaW5nIHdoZXJlYXMgUlNWUCBwYXRoIGluZ3Jl c3Mgbm9kZSB3b3VsZCBrbm93IHZpYSBQQ0VQLiZuYnNwOyBXaGljaCBhbHNvIG1lYW5zLCBvbmUg d291bGQNCiBuZWVkIHRvIHVwZ3JhZGUgdGhlIFJTVlAgaW5ncmVzcyBub2RlIGFueXdheXMgdG8g bGVhcm4gdGhlIHJldmVyc2UgU1IgcGF0aC4gVHJhZmZpYyBzdGVlcmluZyBhbmQgb3RoZXIgZnVu Y3Rpb25zIGZvciB0aGUgUlNWUCBwYXRoIGFuZCBTUiBwYXRoIGluIHRoZSByZXZlcnNlIGRpcmVj dGlvbiAoYW5kIHZpY2UgdmVyc2EpIG1heSBicmluZyBhZGRpdGlvbmFsIHdvcmsuPGJyPg0KPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbHQ7UkcyJmd0OyBIYXZpbmcgc2FpZCB0aGF0 LCB0aGUgc2FtZSBhc3NvY2lhdGlvbiBncm91cCB0eXBlIGNhbiBiZSB1c2VkIGZvciBTUiBhbmQg UlNWUCBwYXRocyAoZS5nLiBib3RoIGFyZSB0aGUgc2FtZSBQU1QpIGluIHRoZW9yeSwgYnV0IGdp dmVuIHRoZSBpbXBsZW1lbnRhdGlvbiBzdGF0dXMgaW4gdGhlIGRyYWZ0LCBJIHdpbGwgbGV0IHJl c3BlY3RpdmUgY28tYXV0aG9ycyBjb21tZW50Ljxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+Jm5ic3A7PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0ieF9nbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQ6MXB4IHNv bGlkIHJnYigyMDQsMjA0LDIwNCk7IHBhZGRpbmctbGVmdDoxZXgiPg0KPGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7IFN0aWxsIGhvcGluZyBmb3IgZmVlZGJhY2sgcmVnYXJkaW5nIG15IGNv bW1lbnRzIG9uIHNlY3Rpb24gNS4gSSBzZWUgdGhhdCBhcyBiZWluZyBtb3JlIHNpZ25pZmljYW50 LCBzaW5jZSBpdCBpbmZsdWVuY2VzIHRoZSB3b3JrZmxvdyBhbmQgYXQgdGhlIG1vbWVudCBJIGRv bid0IHNlZSB0aGUgZGVwZW5kZW5jeSBvbiBkcmFmdC1saS1wY2UtY29udHJvbGxlZC1pZC1zcGFj ZSBhcyBuZWNlc3NhcnkgdG8gYWNoaWV2ZSBub3RpZnlpbmcgUENDcw0KIG9mIHJldmVyc2UgcGF0 aHMuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBBbmQg SSB3YXMgaG9waW5nIHRoYXQgYXV0aG9ycyB3b3VsZCB0YWtlIGEgYml0ZSA6KTxicj4NCiZuYnNw OyAmbmJzcDsgRnJvbSB3aGF0IEkgdW5kZXJzdG9vZCBQTFNQLUlEIHJlbWFpbnMgYSBQQ0MgYWxs b2NhdGVkIElELiBUaGUgcG9pbnQ8YnI+DQombmJzcDsgJm5ic3A7IHRoYXQgc2VjdGlvbiA1IGlz IG1ha2luZyBpcyB0aGF0IHRoZSBzYW1lIExTUCB3b3VsZCBiZSBpZGVudGlmaWVkIGJ5PGJyPg0K Jm5ic3A7ICZuYnNwOyB0d28gUExTUC1JRHMsIG9uZSBhbGxvY2F0ZWQgYnkgSW5ncmVzcyBhbmQg YW5vdGhlciBieSBFZ3Jlc3MgUENDcy48YnI+DQombmJzcDsgJm5ic3A7IFRoZXJlIGlzIG5vIHBy b3Bvc2FsIGZvciBQQ0UtY29udHJvbGxlZCBQTFNQLUlELiBTbyBQQ0UtaW5pdCAmIzQzOyBSIGJp dDxicj4NCiZuYnNwOyAmbmJzcDsgaXMgZW5vdWdoJm5ic3A7IChhcyB5b3Ugc3RhdGUpIGFuZCBJ IGFtIGluIGZ1bGwgYWdyZWVtZW50IHdpdGggeW91IHRoYXQ8YnI+DQombmJzcDsgJm5ic3A7IGZp Z3VyZXMgd2l0aCBQTFNQLUlEIGNvdWxkIGJlIHVzZWZ1bC48YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQombHQ7QW5kcmV3MiZndDsgPGJyPg0KPGJyPg0KVGhhbmtzIGZvciB0aGUgY29tbWVu dHMgYW5kIGFncmVlbWVudC4gZHJhZnQtbGktcGNlLXNyLWJpZGlyLXBhdGgtMDYgc2VjdGlvbiA1 LjEsIHNheXMgJnF1b3Q7UENFIG5lZWRzIHRvIGFsbG9jYXRlIGEgUExTUC1JRCZxdW90Oy4gUGVy aGFwcyBpdCB3YXMganVzdCBhIHR5cG8gYW5kIHNob3VsZCBoYXZlIHNhaWQgUENDLg0KPGJyPg0K PGJyPg0KPT09Y3VycmVudDxicj4NCiZuYnNwOyAmbmJzcDtTaW5jZSB0aGUgUExTUC1JRCBzcGFj ZSBpcyBpbmRlcGVuZGVudCBhdCBlYWNoIFBDQywgdGhlIFBMU1AtSUQ8YnI+DQombmJzcDsgJm5i c3A7YWxsb2NhdGVkIGJ5IHRoZSBlZ3Jlc3MgUENDIGNhbiBub3QgYmUgdXNlZCBmb3IgdGhlIExT UCBhdCB0aGU8YnI+DQombmJzcDsgJm5ic3A7aW5ncmVzcyBQQ0MgKFBMU1AtSUQgY29uZmxpY3Qg bWF5IG9jY3VyKS4mbmJzcDsgSGVuY2UsIHRoZSBQQ0UgbmVlZHMgdG88YnI+DQombmJzcDsgJm5i c3A7YWxsb2NhdGUgYSBQTFNQLUlEIGZvciBMU1AyIGZyb20gdGhlIGluZ3Jlc3MgUENDJ3MgUExT UC1JRCBzcGFjZSAsPGJyPg0KJm5ic3A7ICZuYnNwO3NheSAxMDEuJm5ic3A7IFNpbWlsYXJseSBm b3IgTFNQMSwgaXQgaGFzIFBMU1AtSUQgMTAwIGF0IHRoZSBpbmdyZXNzLCBhbmQ8YnI+DQombmJz cDsgJm5ic3A7bWF5IGhhdmUgc2F5IFBMU1AtSUQgMjAxIGF0IHRoZSBlZ3Jlc3Mgbm9kZS48YnI+ DQo9PT09PWVuZCBjdXJyZW50PGJyPg0KPGJyPg0KPGJyPg0KTWF5IEkgcHJvcG9zZSB0aGUgZm9s bG93aW5nIHRleHQmbmJzcDsgKG9yIHNvbWV0aGluZyBsaWtlIGl0KSBpbnN0ZWFkOjxicj4NCjxi cj4NCjxicj4NCj09PW5ldyBwcm9wb3NhbDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtTaW5jZSB0 aGUgUExTUC1JRCBzcGFjZSBpcyBpbmRlcGVuZGVudCBhdCBlYWNoIFBDQywgdGhlIFBMU1AtSUQ8 YnI+DQombmJzcDsgJm5ic3A7YWxsb2NhdGVkIGJ5IHRoZSBlZ3Jlc3MgUENDIGNhbm5vdCBiZSB1 c2VkIGZvciB0aGUgTFNQIGF0IHRoZTxicj4NCiZuYnNwOyAmbmJzcDtpbmdyZXNzIFBDQyAoUExT UC1JRCBjb25mbGljdCBtYXkgb2NjdXIpLiBBcyBwZXIgbm9ybWFsIFBDRS1JTklUIDxicj4NCiZu YnNwOyAmbmJzcDtvcGVyYXRpb25zLCBQQ0MgYXNzaWducyB0aGUgUExTUC1JRHMgZm9yIGxvY2Fs IExTUHMuPGJyPg0KJm5ic3A7ICZuYnNwO0hlbmNlLCB3aGVuIHRoZSBQQ0Ugbm90aWZpZXMgYW4g aW5ncmVzcyBQQ0Mgb2YgdGhlIHJldmVyc2UgZWdyZXNzIExTUCwgaXQ8YnI+DQombmJzcDsgJm5i c3A7ZG9lcyBzbyB1c2luZyBQQ0UtSU5JVCBvcGVyYXRpb25zIGFuZCBzZXRzIFBMU1AtSUQgdG8g emVybyBhbmQgc2V0cyB0aGUgUiBiaXQgaW4gdGhlIGFzc29jaWF0aW9uDQo8YnI+DQombmJzcDsg Jm5ic3A7b2JqZWN0IHRvIGluZGljYXRlIHRoYXQgdGhpcyBQQ0UtSU5JVCBMU1AgaXMgYSByZXZl cnNlIExTUC4gVGhlIFBDQyA8YnI+DQombmJzcDsgJm5ic3A7dXBvbiByZWNlaXZpbmcgdGhlIFBD RS1JTklUIE1VU1QgbG9jYWxseSBhc3NpZ24gYSBQTFNQLUlEIGFuZCBpdCBNVVNUPGJyPg0KJm5i c3A7ICZuYnNwO2lzc3VlIGEgUENSRVBPUlQgdG8gUENFIGZvciB0aGlzIExTUCBjb250YWluaW5n IHRoZSBuZXcgUExTUC1JRC4gVGhpcyA8YnI+DQombmJzcDsgJm5ic3A7TFNQIE1VU1QgTk9UIGJl IGluc3RhbnRpYXRlZCBvbiB0aGUgUENDLiA8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7Rm9yIGV4 YW1wbGUsIGluZ3Jlc3MgUENDMSB3YXkgbWF5IHJlcG9ydCB0byBQQ0UgYW4gTFNQIHdpdGggPGJy Pg0KJm5ic3A7ICZuYnNwO1BMU1AtSUQgMTAwLiBFZ3Jlc3MgUENDMiBtYXkgcmVwb3J0IHRvIFBD RSBhbiBMU1Agd2l0aCBQTFNQLUlEIDIwMC4gPGJyPg0KJm5ic3A7ICZuYnNwO0JvdGggb2YgdGhl c2UgTFNQcyBhcmUgYmktZGlyZWN0aW9uYWwgYXNzb2NpYXRlZC4gV2hlbiBQQ0UgPGJyPg0KJm5i c3A7ICZuYnNwO25vdGlmaWVzIFBDQzEgb2YgdGhlIFBDQzIgTFNQLCBpdCBkb2VzIHNvIGJ5IHNl bmRpbmcgYSBQQ0UtSU5JVCB0byBQQ0MxIHdpdGggPGJyPg0KJm5ic3A7ICZuYnNwO1BMU1AtSUQg c2V0IHRvIHplcm8gYW5kIFIgYml0IHNldC4gUENDMSB1cG9uIHJlY2VwdGlvbiBvZiB0aGlzIGdl bmVyYXRlcyBhIFBMU1AtSUQNCjxicj4NCiZuYnNwOyAmbmJzcDsoZXhhbXBsZSBQTFNQLUlEIDMw MCkgYW5kIGlzc3VlcyBhIFBDUkVQT1JUIHRvIFBDRS4gPGJyPg0KPGJyPg0KPT09PT1lbmQgbmV3 IHByb3Bvc2FsPGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+Jmx0O1JHMiZndDsgTG9va3MgZ29vZCB0byBtZS4gVGhhbmtzIGZvciB0aGUgdGV4dC48L2Rp dj4NCjxkaXY+Jmx0O1JHMiZndDsgTWFueSB0aGFua3MgRGhydXYgZm9yIHRoZSBpbnB1dHMuPGJy Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2PlJh a2VzaDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PiZu YnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9InhfZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46MHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwy MDQpOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCiZsdDsvZW5kIGFuZHJldzImZ3Q7PGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM0PR0702MB36194BD4D324B79EF2C16932910E0AM0PR0702MB3619_-- From nobody Thu Jan 23 20:14:26 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D9512006F for ; Thu, 23 Jan 2020 20:14:24 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvszARQnCTF0 for ; Thu, 23 Jan 2020 20:14:23 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97EA212002E for ; Thu, 23 Jan 2020 20:14:22 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id q8so849533ljj.11 for ; Thu, 23 Jan 2020 20:14:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QIOjJVkXxzQAOh8EBVReCNfjFGeRQMiOj3GzP+dlOEs=; b=AwwAdQ+WjqFGZ+BXs8EElEaaAGOo2J501myXLDgzhRkQ87AG7ZmCaT1AY8n8Fp5nJe NfwxieD7JSuFd9aUkj3/8a2YTOLYNz/CqlpBsusQfi0cWTv/it5D5qVxURFAIEbmf3fH uhS1hXcO8IFt+TQGo2nHoE1yAEvhH+t0RV9jbbvQe4MxfcfUTLhHaeBjomkfKL7Muulm D330S5juFPKeTq/mkaMCIP/LHAInmwWDrNtoivnN0P9RC8fXr9DOprkJ9A8madP8Juvu rlftt3glHUHFONCASyfrggU4iDTzK2GwaRPwJnCIB2luy14EMm+ybPHI+NlWBUvvn9Pa +xiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QIOjJVkXxzQAOh8EBVReCNfjFGeRQMiOj3GzP+dlOEs=; b=XR/g2d3AhOVebkXjuoA3IYWtjYF40qRbC+jcXOaRkXnd7LM6FFVCQ26UUsH5PEbggL cF4skWumCBv6fAQjg8+s4Lc+PnifEJws0V8cdahO98FTzNp5GF1ffK5jEM2FaF16QpcL /xNWFljCWVhHVeFy0TVOECnK3oRsAG+FsF8ui3VhKoleyk2B9RKBzqs0dvSN2Dx3pECm MKblslsSp8cl+sRQEHdvTCLhfQPuXELsir/HZxW5ixPpm3ym50vOJ8iSBzbMRsKCPKJz VfTgHyccozDnUDOQFBx/FfWL29PNYgKKuh2UGLaPKNPjNEkn8UNo78jj0VnNA3m9A8tj kINQ== X-Gm-Message-State: APjAAAWfh5fuyoSpz+GkcpcgHScyPmsMatIXKXvvv3r8j90Smd+ZK7ks ZzEkJ9Xstm8dJSPwkoBtBM5G3Tlbz7wM92IZO+aFvQ== X-Google-Smtp-Source: APXvYqwrObac/Qs+mapa3p2g/EV4TZTdWzkUBwYwrD4ARWMs8r/jBN4SmXW0pIdYAUPdP0o61AHHtbc605fulYdWkAc= X-Received: by 2002:a2e:9f52:: with SMTP id v18mr951186ljk.30.1579839260839; Thu, 23 Jan 2020 20:14:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Thu, 23 Jan 2020 20:14:09 -0800 Message-ID: To: julien.meuric@orange.com Cc: "pce@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f1d333059cdafd47" Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 04:14:25 -0000 --000000000000f1d333059cdafd47 Content-Type: text/plain; charset="UTF-8" Dear All, I've read the draft and support its adoption. Regards, Greg On Fri, Jan 17, 2020 at 2:12 AM wrote: > Hi all, > > It is time to share your thoughts about draft-li-pce-sr-bidir-path-06. > Do you believe the I-D is a right foundation for a PCE WG item? Please > use the PCE mailing list to express your comments, support or > disagreement, including applicable rationale, especially for the latter. > > Thanks, > > Dhruv & Julien > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --000000000000f1d333059cdafd47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
I've read the draft and support its adop= tion.

Regards,
Greg

On Fri, Jan 17,= 2020 at 2:12 AM <julien.meu= ric@orange.com> wrote:
Hi all,

It is time to share your thoughts about draft-li-pce-sr-bidir-path-06.
Do you believe the I-D is a right foundation for a PCE WG item? Please
use the PCE mailing list to express your comments, support or
disagreement, including applicable rationale, especially for the latter.
Thanks,

Dhruv & Julien


_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
--000000000000f1d333059cdafd47-- From nobody Thu Jan 23 22:28:04 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDDC12004F for ; Thu, 23 Jan 2020 22:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, INVALID_MSGID=0.568, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KT1HZvM4Yfv4 for ; Thu, 23 Jan 2020 22:28:01 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F192120044 for ; Thu, 23 Jan 2020 22:28:01 -0800 (PST) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 8A8CD17243792CF3581D for ; Fri, 24 Jan 2020 06:27:55 +0000 (GMT) Received: from nkgeml701-chm.china.huawei.com (10.98.57.156) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 24 Jan 2020 06:27:55 +0000 Received: from nkgeml701-chm.china.huawei.com (10.98.57.156) by nkgeml701-chm.china.huawei.com (10.98.57.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 24 Jan 2020 14:27:52 +0800 Received: from nkgeml701-chm.china.huawei.com ([10.98.57.156]) by nkgeml701-chm.china.huawei.com ([10.98.57.156]) with mapi id 15.01.1713.004; Fri, 24 Jan 2020 14:27:52 +0800 From: "Dongjie (Jimmy)" To: Hariharan Ananthakrishnan , "Chengli (Cheng Li)" , Mach Chen , Weiqiang Cheng , Lizhenbin , "Rakesh Gandhi" , xiong.quan CC: pce Thread-Topic: IPR Poll on draft-li-pce-sr-bidir-path-06 Thread-Index: AQHVzWRn0yNgBvf4tUy5g4yqvYH4uKf5ZAfw Date: Fri, 24 Jan 2020 06:27:52 +0000 Message-ID: 3097010B-DF02-414F-A115-ED68A8C5C2D6 References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3097010BDF02414FA115ED68A8C5C2D6_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] IPR Poll on draft-li-pce-sr-bidir-path-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 06:28:03 -0000 --_000_3097010BDF02414FA115ED68A8C5C2D6_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSGFyaSwNCg0KSSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiBhcHBsaWVzIHRvIHRoaXMgZG9j dW1lbnQuDQoNCkJlc3QgcmVnYXJkcywNCkppZQ0KDQoNCg0K5Y+R5Lu25Lq677yaSGFyaWhhcmFu IEFuYW50aGFrcmlzaG5hbiA8aGFyaUBuZXRmbGl4LmNvbT4NCuaUtuS7tuS6uu+8mkNoZW5nbGkg KENoZW5nIExpKSA8Y2hlbmdsaTEzQGh1YXdlaS5jb20+O01hY2ggQ2hlbiA8bWFjaC5jaGVuQGh1 YXdlaS5jb20+O1dlaXFpYW5nIENoZW5nIDxjaGVuZ3dlaXFpYW5nQGNoaW5hbW9iaWxlLmNvbT47 TGl6aGVuYmluIDxsaXpoZW5iaW5AaHVhd2VpLmNvbT47RG9uZ2ppZSAoSmltbXkpIDxqaWUuZG9u Z0BodWF3ZWkuY29tPjtSYWtlc2ggR2FuZGhpIDxyZ2FuZGhpQGNpc2NvLmNvbT47eGlvbmcucXVh biA8eGlvbmcucXVhbkB6dGUuY29tLmNuPg0K5oqE4oCD6YCB77yacGNlIDxwY2VAaWV0Zi5vcmc+ DQrml7bigIPpl7TvvJoyMDIwLTAxLTE4IDAyOjMxOjU5DQrkuLvigIPpopjvvJpJUFIgUG9sbCBv biBkcmFmdC1saS1wY2Utc3ItYmlkaXItcGF0aC0wNg0KDQoNCkhpIEF1dGhvcnMsDQoNCkluIHBy ZXBhcmF0aW9uIGZvciBXb3JraW5nIEdyb3VwIGFkb3B0aW9uIG9uIHRoaXMgZHJhZnQsIEknZCBs aWtlIGFsbA0KYXV0aG9ycyBhbmQgY29udHJpYnV0b3JzIHRvIGNvbmZpcm0gb24gdGhlIGxpc3Qg dGhhdCB0aGV5IGFyZSBpbiBjb21wbGlhbmNlDQp3aXRoIElFVEYgSVBSIHJ1bGVzLg0KDQpQbGVh c2UgcmVzcG9uZCAoY29weWluZyB0aGUgbWFpbGluZyBsaXN0KSB0byBzYXkgb25lIG9mOg0KDQpJ IGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIGFwcGxpY2FibGUgdG8gdGhpcyBkcmFmdCB0aGF0IHNo b3VsZCBiZSBkaXNjbG9zZWQNCmluIGFjY29yZGFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcy4NCg0K SSBhbSBhd2FyZSBvZiBJUFIgYXBwbGljYWJsZSB0byB0aGlzIGRyYWZ0LCBhbmQgaXQgaGFzIGFs cmVhZHkgYmVlbg0KZGlzY2xvc2VkIHRvIHRoZSBJRVRGLg0KDQpJIGFtIGF3YXJlIG9mIElQUiBh cHBsaWNhYmxlIHRvIHRoaXMgZHJhZnQsIGJ1dCB0aGF0IGhhcyBub3QgeWV0IGJlZW4NCmRpc2Ns b3NlZCB0byB0aGUgSUVURi4gSSB3aWxsIHdvcmsgdG8gZW5zdXJlIHRoYXQgaXQgd2lsbCBiZSBk aXNjbG9zZWQgaW4gYQ0KdGltZWx5IG1hbm5lci4NCg0KVGhhbmtzLA0KLSBIYXJpDQo= --_000_3097010BDF02414FA115ED68A8C5C2D6_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8L2hlYWQ+DQo8Ym9keT4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+DQo8 IS0tDQoqDQoJe30NCmJvZHkNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaX0NCi0tPg0KPC9zdHlsZT4N CjxkaXY+SGkgSGFyaSw8YnI+DQo8YnI+DQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIGFwcGxp ZXMgdG8gdGhpcyBkb2N1bWVudC48YnI+DQo8YnI+DQpCZXN0IHJlZ2FyZHMsPGJyPg0KSmllPGJy Pg0KPC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj4NCjxwPjxicj4NCjxicj4NCjwvcD4NCjwvZGl2 Pg0KPGRpdiBuYW1lPSJBbnlPZmZpY2UtQmFja2dyb3VuZC1JbWFnZSIgc3R5bGU9ImJvcmRlci10 b3A6MXB4IHNvbGlkICNCNUM0REY7IHBhZGRpbmc6OHB4Ij4NCjxkaXYgc3R5bGU9IndvcmQtYnJl YWs6YnJlYWstYWxsIj48Yj7lj5Hku7bkurrvvJo8L2I+SGFyaWhhcmFuIEFuYW50aGFrcmlzaG5h biAmbHQ7aGFyaUBuZXRmbGl4LmNvbSZndDs8L2Rpdj4NCjxkaXYgc3R5bGU9IndvcmQtYnJlYWs6 YnJlYWstYWxsIj48Yj7mlLbku7bkurrvvJo8L2I+Q2hlbmdsaSAoQ2hlbmcgTGkpICZsdDtjaGVu Z2xpMTNAaHVhd2VpLmNvbSZndDs7TWFjaCBDaGVuICZsdDttYWNoLmNoZW5AaHVhd2VpLmNvbSZn dDs7V2VpcWlhbmcgQ2hlbmcgJmx0O2NoZW5nd2VpcWlhbmdAY2hpbmFtb2JpbGUuY29tJmd0OztM aXpoZW5iaW4gJmx0O2xpemhlbmJpbkBodWF3ZWkuY29tJmd0OztEb25namllIChKaW1teSkgJmx0 O2ppZS5kb25nQGh1YXdlaS5jb20mZ3Q7O1Jha2VzaCBHYW5kaGkgJmx0O3JnYW5kaGlAY2lzY28u Y29tJmd0Ozt4aW9uZy5xdWFuDQogJmx0O3hpb25nLnF1YW5AenRlLmNvbS5jbiZndDs8L2Rpdj4N CjxkaXYgc3R5bGU9IndvcmQtYnJlYWs6YnJlYWstYWxsIj48Yj7mioTigIPpgIHvvJo8L2I+cGNl ICZsdDtwY2VAaWV0Zi5vcmcmZ3Q7PC9kaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLWJyZWFrOmJyZWFr LWFsbCI+PGI+5pe24oCD6Ze077yaPC9iPjIwMjAtMDEtMTggMDI6MzE6NTk8L2Rpdj4NCjxkaXYg c3R5bGU9IndvcmQtYnJlYWs6YnJlYWstYWxsIj48Yj7kuLvigIPpopjvvJo8L2I+SVBSIFBvbGwg b24gZHJhZnQtbGktcGNlLXNyLWJpZGlyLXBhdGgtMDY8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1 bHQiIHN0eWxlPSJmb250LWZhbWlseTp2ZXJkYW5hLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFs bCI+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcDsgbWFyZ2luLXRvcDowcHg7IG1h cmdpbi1ib3R0b206MXJlbTsgb3ZlcmZsb3c6YXV0bzsgY29sb3I6cmdiKDMzLDM3LDQxKTsgd29y ZC1icmVhazpub3JtYWw7IHBhZGRpbmc6MHB4Ij48Zm9udCBmYWNlPSJ2ZXJkYW5hLCBzYW5zLXNl cmlmIj5IaSBBdXRob3JzLA0KDQpJbiBwcmVwYXJhdGlvbiBmb3IgV29ya2luZyBHcm91cCBhZG9w dGlvbiBvbiB0aGlzIGRyYWZ0LCBJJ2QgbGlrZSBhbGwNCmF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9y cyB0byBjb25maXJtIG9uIHRoZSBsaXN0IHRoYXQgdGhleSBhcmUgaW4gY29tcGxpYW5jZQ0Kd2l0 aCBJRVRGIElQUiBydWxlcy4NCg0KUGxlYXNlIHJlc3BvbmQgKGNvcHlpbmcgdGhlIG1haWxpbmcg bGlzdCkgdG8gc2F5IG9uZSBvZjoNCg0KSSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiBhcHBsaWNh YmxlIHRvIHRoaXMgZHJhZnQgdGhhdCBzaG91bGQgYmUgZGlzY2xvc2VkDQppbiBhY2NvcmRhbmNl IHdpdGggSUVURiBJUFIgcnVsZXMuDQoNCkkgYW0gYXdhcmUgb2YgSVBSIGFwcGxpY2FibGUgdG8g dGhpcyBkcmFmdCwgYW5kIGl0IGhhcyBhbHJlYWR5IGJlZW4NCmRpc2Nsb3NlZCB0byB0aGUgSUVU Ri4NCg0KSSBhbSBhd2FyZSBvZiBJUFIgYXBwbGljYWJsZSB0byB0aGlzIGRyYWZ0LCBidXQgdGhh dCBoYXMgbm90IHlldCBiZWVuDQpkaXNjbG9zZWQgdG8gdGhlIElFVEYuIEkgd2lsbCB3b3JrIHRv IGVuc3VyZSB0aGF0IGl0IHdpbGwgYmUgZGlzY2xvc2VkIGluIGENCnRpbWVseSBtYW5uZXIuDQoN ClRoYW5rcywNCi0gSGFyaTwvZm9udD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_3097010BDF02414FA115ED68A8C5C2D6_-- From nobody Thu Jan 23 22:35:37 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36DE120137 for ; Thu, 23 Jan 2020 22:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.632 X-Spam-Level: X-Spam-Status: No, score=-3.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMeOroyRLPkA for ; Thu, 23 Jan 2020 22:35:28 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50D8C1200FD for ; Thu, 23 Jan 2020 22:35:28 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 0F512BEE62A08E500D1D for ; Fri, 24 Jan 2020 06:35:26 +0000 (GMT) Received: from nkgeml703-chm.china.huawei.com (10.98.57.159) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 24 Jan 2020 06:35:25 +0000 Received: from nkgeml701-chm.china.huawei.com (10.98.57.156) by nkgeml703-chm.china.huawei.com (10.98.57.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 24 Jan 2020 14:35:23 +0800 Received: from nkgeml701-chm.china.huawei.com ([10.98.57.156]) by nkgeml701-chm.china.huawei.com ([10.98.57.156]) with mapi id 15.01.1713.004; Fri, 24 Jan 2020 14:35:23 +0800 From: "Dongjie (Jimmy)" To: julien.meuric , pce Thread-Topic: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? Thread-Index: AQHVzR65+4UBGCEbCE2P1bjHb4fJH6f5Zqvl Date: Fri, 24 Jan 2020 06:35:23 +0000 Message-ID: 6E43AD77-5A4F-425D-96D5-642B363D5007 References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6E43AD775A4F425D96D5642B363D5007_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 06:35:36 -0000 --_000_6E43AD775A4F425D96D5642B363D5007_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgV0csDQoNCkkgKGFzIGEgY29hdXRob3IpIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMg ZG9jdW1lbnQuDQoNCkJlc3QgcmVnYXJkcywNCkppZQ0KDQoNCg0K5Y+R5Lu25Lq677yaanVsaWVu Lm1ldXJpYyA8anVsaWVuLm1ldXJpY0BvcmFuZ2UuY29tPg0K5pS25Lu25Lq677yacGNlIDxwY2VA aWV0Zi5vcmc+DQrml7bigIPpl7TvvJoyMDIwLTAxLTE3IDE4OjEzOjEyDQrkuLvigIPpopjvvJpb UGNlXSBBZG9wdGlvbiBvZiBkcmFmdC1saS1wY2Utc3ItYmlkaXItcGF0aC0wNj8NCg0KSGkgYWxs LA0KDQpJdCBpcyB0aW1lIHRvIHNoYXJlIHlvdXIgdGhvdWdodHMgYWJvdXQgZHJhZnQtbGktcGNl LXNyLWJpZGlyLXBhdGgtMDYuDQpEbyB5b3UgYmVsaWV2ZSB0aGUgSS1EIGlzIGEgcmlnaHQgZm91 bmRhdGlvbiBmb3IgYSBQQ0UgV0cgaXRlbT8gUGxlYXNlDQp1c2UgdGhlIFBDRSBtYWlsaW5nIGxp c3QgdG8gZXhwcmVzcyB5b3VyIGNvbW1lbnRzLCBzdXBwb3J0IG9yDQpkaXNhZ3JlZW1lbnQsIGlu Y2x1ZGluZyBhcHBsaWNhYmxlIHJhdGlvbmFsZSwgZXNwZWNpYWxseSBmb3IgdGhlIGxhdHRlci4N Cg0KVGhhbmtzLA0KDQpEaHJ1diAmIEp1bGllbg0KDQoNCg== --_000_6E43AD775A4F425D96D5642B363D5007_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+DQo8IS0tDQpib2R5DQoJe2Zv bnQtZmFtaWx5OkNhbGlicml9DQotLT4NCjwvc3R5bGU+DQo8ZGl2Pg0KPGRpdj5IaSBXRyw8YnI+ DQo8YnI+DQpJIChhcyBhIGNvYXV0aG9yKSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRv Y3VtZW50Ljxicj4NCjxicj4NCkJlc3QgcmVnYXJkcyw8YnI+DQpKaWU8YnI+DQo8L2Rpdj4NCjxk aXY+PC9kaXY+DQo8ZGl2Pg0KPHA+PGJyPg0KPGJyPg0KPC9wPg0KPC9kaXY+DQo8ZGl2IG5hbWU9 InhfQW55T2ZmaWNlLUJhY2tncm91bmQtSW1hZ2UiIHN0eWxlPSJib3JkZXItdG9wOjFweCBzb2xp ZCAjQjVDNERGOyBwYWRkaW5nOjhweCI+DQo8ZGl2IHN0eWxlPSJ3b3JkLWJyZWFrOmJyZWFrLWFs bCI+PGI+5Y+R5Lu25Lq677yaPC9iPmp1bGllbi5tZXVyaWMgJmx0O2p1bGllbi5tZXVyaWNAb3Jh bmdlLmNvbSZndDs8L2Rpdj4NCjxkaXYgc3R5bGU9IndvcmQtYnJlYWs6YnJlYWstYWxsIj48Yj7m lLbku7bkurrvvJo8L2I+cGNlICZsdDtwY2VAaWV0Zi5vcmcmZ3Q7PC9kaXY+DQo8ZGl2IHN0eWxl PSJ3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PGI+5pe24oCD6Ze077yaPC9iPjIwMjAtMDEtMTcgMTg6 MTM6MTI8L2Rpdj4NCjxkaXYgc3R5bGU9IndvcmQtYnJlYWs6YnJlYWstYWxsIj48Yj7kuLvigIPp opjvvJo8L2I+W1BjZV0gQWRvcHRpb24gb2YgZHJhZnQtbGktcGNlLXNyLWJpZGlyLXBhdGgtMDY/ PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxmb250IHNpemU9IjIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDsiPg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij5I aSBhbGwsPGJyPg0KPGJyPg0KSXQgaXMgdGltZSB0byBzaGFyZSB5b3VyIHRob3VnaHRzIGFib3V0 IGRyYWZ0LWxpLXBjZS1zci1iaWRpci1wYXRoLTA2Ljxicj4NCkRvIHlvdSBiZWxpZXZlIHRoZSBJ LUQgaXMgYSByaWdodCBmb3VuZGF0aW9uIGZvciBhIFBDRSBXRyBpdGVtPyBQbGVhc2U8YnI+DQp1 c2UgdGhlIFBDRSBtYWlsaW5nIGxpc3QgdG8gZXhwcmVzcyB5b3VyIGNvbW1lbnRzLCBzdXBwb3J0 IG9yPGJyPg0KZGlzYWdyZWVtZW50LCBpbmNsdWRpbmcgYXBwbGljYWJsZSByYXRpb25hbGUsIGVz cGVjaWFsbHkgZm9yIHRoZSBsYXR0ZXIuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCjxicj4NCkRo cnV2ICZhbXA7IEp1bGllbjxicj4NCjxicj4NCjxicj4NCjwvZGl2Pg0KPC9zcGFuPjwvZm9udD4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6E43AD775A4F425D96D5642B363D5007_-- From nobody Fri Jan 24 04:45:01 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B29512003E for ; Fri, 24 Jan 2020 04:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.498 X-Spam-Level: X-Spam-Status: No, score=-14.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=hngIEpOo; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kRn8R63J Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQ8r0Lf3BZvF for ; Fri, 24 Jan 2020 04:44:57 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096D612001E for ; Fri, 24 Jan 2020 04:44:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5479; q=dns/txt; s=iport; t=1579869896; x=1581079496; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=b2su260IiHuvnHUxNxQMuKSLZibuz3OyKpIwt3V7UKw=; b=hngIEpOo0tkXvnPmSOEG6mq5gn7lh4IGLnk7eCj8VmQlGsaV7H/NcGc7 +Im/V6GLDmJgacx/isnJkQzyQmQaJNHedh9Zl0BOQ7y9PYUVEbEqilW/r dkZkpd/JyDQFAZSAKGJji2Lr/XC49WWRVC0fJCP5KSRM7sBHqtDIo+cvU Q=; IronPort-PHdr: =?us-ascii?q?9a23=3A/MIuYBaInyodKDooGaH8X+n/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20QKbRp3VvvRDjeee87vtX2AN+96giDgDa9QNHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuPvfubgQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAQBz5ipe/5xdJa1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWkFAQELAYEkL1AFbFggBAsqhBKDRgOLEYI6JZMthGKBLoEkA1Q?= =?us-ascii?q?JAQEBDAEBLQIBAYRAAheCCyQ2Bw4CAw0BAQQBAQECAQUEbYU3DIVeAQEBAQM?= =?us-ascii?q?SER0BASwLAQ8CAQgEDQMBAisCAgIwHQgCBAENBSKDBAGBfU0DLgECoW4CgTm?= =?us-ascii?q?IYXWBMoJ/AQEFgkSCSRiCDAmBOAGMFhqBQT+BOAwUgkw+hGmCcDKCLJBVhV6?= =?us-ascii?q?JdY5PZQqCOZY2G4JIiAqQKo5gmwwCBAIEBQIOAQEFgVkIKoFYcBU7KgGCQVA?= =?us-ascii?q?YDYgBg3OKU3SBKYwAAQE?= X-IronPort-AV: E=Sophos;i="5.70,357,1574121600"; d="scan'208,217";a="701069157" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jan 2020 12:44:55 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 00OCit0U027395 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Jan 2020 12:44:55 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 24 Jan 2020 06:44:54 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 24 Jan 2020 07:44:53 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 24 Jan 2020 06:44:53 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MnCXwlsy52HYpR0VE4rTx0p8VeDTntYpIwGSg4prcVwCkvajaNrVriYOHKcDmMAyMSLSRDlIhtEHklmJvjoC29lTSwsJDVpVmTvdYWTcx/I5ElHwPUO+qhbTM+p2GkKnG92D9NNFSwu2Bne/NV2nUm0mvUVp42NQxnyHFWqCVul+kZwRP6JCZnlzHyJQOtyFZ8NCKt7DgbgpdomhUbU2jXGWLfQzoeNSefDMEuKKblLvzpjFO9jjyT6R8gLwtKfgd2qWPKWq748tRnMg3+0xShANXlhGLhPAQuhvfSsROL41wBl2Buj8wuQBE9hSR+KzxwxUPYfYK5Ee9Ich//yTog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b2su260IiHuvnHUxNxQMuKSLZibuz3OyKpIwt3V7UKw=; b=KXbkj989LcvmHDlMYQLQX6Wpz2lzKLmOrtWeJpQsZpICgELsNPu+F7jc0Sh/ne6TPjnZf+jaRJWfCfzuvoeymF1mtjrUGjqTf9t+y6yti7C08hKlkZiMURLM5qbjfqIG96YoFFBbFhPkgKIUUIeKOdViJtOQj87a7cO/FIFaL8p69PvOG9Z7f6JiL7e/XO3nL3R99V8QWit781xgC00W9cFerf0lj1Fnet/5u9m/YJ9cLkbNF/ka66lUSDG+hOOxc41sGevDNVy5j7Z+AbB70XIWTe9AD0d7umetxUZGpDJy5wNcHcmVKSqVXRiYV67kyksbo/lIASEKZtnmT3mdKw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b2su260IiHuvnHUxNxQMuKSLZibuz3OyKpIwt3V7UKw=; b=kRn8R63JqSivm50d9jWMtU9/NmNaG9aSoIaf2itFXRY9Y1k60PBvuYzdvi0H48iQmuH3Z0s0/1J5lqsTMoCnmMEyYIFnLc7hGSNIxNGsqE2Hv+EMoFJB3vXK5eS5ZtHWr8giHW7I7jbVRuBYTTBfAnQ1Q/ZJ1dzlm5w9mhfG0F4= Received: from MN2PR11MB3710.namprd11.prod.outlook.com (20.178.252.147) by MN2PR11MB3949.namprd11.prod.outlook.com (20.179.150.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Fri, 24 Jan 2020 12:44:52 +0000 Received: from MN2PR11MB3710.namprd11.prod.outlook.com ([fe80::41f4:f9c9:fca6:8ba2]) by MN2PR11MB3710.namprd11.prod.outlook.com ([fe80::41f4:f9c9:fca6:8ba2%4]) with mapi id 15.20.2644.028; Fri, 24 Jan 2020 12:44:52 +0000 From: "Zafar Ali (zali)" To: "julien.meuric@orange.com" , "pce@ietf.org" Thread-Topic: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? Thread-Index: AQHVzR7KWU0vwS5cNkaDyMKktVno7af5ehUA Date: Fri, 24 Jan 2020 12:44:52 +0000 Message-ID: <0D63E9AC-20AF-4048-B9B6-67E4D3D6C808@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 authentication-results: spf=none (sender IP is ) smtp.mailfrom=zali@cisco.com; x-originating-ip: [2001:420:c0cc:1002::2b5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e1b3138a-b640-44be-e54b-08d7a0cb3547 x-ms-traffictypediagnostic: MN2PR11MB3949: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 02929ECF07 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(366004)(396003)(39860400002)(346002)(199004)(189003)(6486002)(4326008)(107886003)(36756003)(4744005)(5660300002)(6512007)(66446008)(2616005)(478600001)(316002)(2906002)(186003)(110136005)(81156014)(81166006)(66476007)(91956017)(66946007)(76116006)(71200400001)(8676002)(33656002)(64756008)(86362001)(66556008)(8936002)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3949; H:MN2PR11MB3710.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: B3fyky93o+vBSNd0pymTUmafWyZU9IOz7NRM9VGiWV7NEuGZm/VslUp2zdkghF/P2ph1qpEjShXaOe6eKe1B7PjCdfQ4ImmOCitqEPhwsu+v6n46xWu7KMzFHuSo3FSVzJXEMS/+XNVe8UzOmQDP8oETRPrfGaTr6/t7iuaZfrOYpWtepIlR6UDJkZPziPxuLVhY5dXdb1wRZ/9MjacNhPGU8qDwhK6GxEsxFrLkZvPpN1i3St0HO/7nfuBmCqXEGzeCDzoZWdUQJwu7uwb5IYOqNNH0i/Kf0NDVD93PndszTvZ3F9ZCdO9idgMGNDK1jK7G4rrh5ZN1yHlaMgYHB60YzarkECm+QQeZ+QWCQo/GiXPmPby5ipV+hO64scvYqBLp0xdjbQb3IJjJRfDVLFUUNNyhfF7hiHHnPI4wsGPOj0TR2GldzFVRSY8g9Swa Content-Type: multipart/alternative; boundary="_000_0D63E9AC20AF4048B9B667E4D3D6C808ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e1b3138a-b640-44be-e54b-08d7a0cb3547 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2020 12:44:52.7374 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TvSOuzs9Dd9t8sOOi/eGaawo+Zhzw4cgDsniHFFOLfuFwPIiGidRDjZQDKXAot1b X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3949 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 12:45:00 -0000 --_000_0D63E9AC20AF4048B9B667E4D3D6C808ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCENCg0KVGhhbmtzDQoNClJlZ2FyZHMg4oCmIFphZmFyDQoNCkZyb206IFBjZSA8cGNl LWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiAianVsaWVuLm1ldXJpY0BvcmFuZ2UuY29t IiA8anVsaWVuLm1ldXJpY0BvcmFuZ2UuY29tPg0KT3JnYW5pemF0aW9uOiBPcmFuZ2UNCkRhdGU6 IEZyaWRheSwgSmFudWFyeSAxNywgMjAyMCBhdCA1OjEzIEFNDQpUbzogInBjZUBpZXRmLm9yZyIg PHBjZUBpZXRmLm9yZz4NClN1YmplY3Q6IFtQY2VdIEFkb3B0aW9uIG9mIGRyYWZ0LWxpLXBjZS1z ci1iaWRpci1wYXRoLTA2Pw0KDQpIaSBhbGwsDQoNCkl0IGlzIHRpbWUgdG8gc2hhcmUgeW91ciB0 aG91Z2h0cyBhYm91dCBkcmFmdC1saS1wY2Utc3ItYmlkaXItcGF0aC0wNi4NCkRvIHlvdSBiZWxp ZXZlIHRoZSBJLUQgaXMgYSByaWdodCBmb3VuZGF0aW9uIGZvciBhIFBDRSBXRyBpdGVtPyBQbGVh c2UNCnVzZSB0aGUgUENFIG1haWxpbmcgbGlzdCB0byBleHByZXNzIHlvdXIgY29tbWVudHMsIHN1 cHBvcnQgb3INCmRpc2FncmVlbWVudCwgaW5jbHVkaW5nIGFwcGxpY2FibGUgcmF0aW9uYWxlLCBl c3BlY2lhbGx5IGZvciB0aGUgbGF0dGVyLg0KDQpUaGFua3MsDQoNCkRocnV2ICYgSnVsaWVuDQoN Cg0KDQo= --_000_0D63E9AC20AF4048B9B667E4D3D6C808ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VwcG9ydCEgPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5SZWdhcmRzIOKApiBaYWZhciA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPlBjZSAmbHQ7cGNlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiAmcXVv dDtqdWxpZW4ubWV1cmljQG9yYW5nZS5jb20mcXVvdDsgJmx0O2p1bGllbi5tZXVyaWNAb3Jhbmdl LmNvbSZndDs8YnI+DQo8Yj5Pcmdhbml6YXRpb246IDwvYj5PcmFuZ2U8YnI+DQo8Yj5EYXRlOiA8 L2I+RnJpZGF5LCBKYW51YXJ5IDE3LCAyMDIwIGF0IDU6MTMgQU08YnI+DQo8Yj5UbzogPC9iPiZx dW90O3BjZUBpZXRmLm9yZyZxdW90OyAmbHQ7cGNlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1Ympl Y3Q6IDwvYj5bUGNlXSBBZG9wdGlvbiBvZiBkcmFmdC1saS1wY2Utc3ItYmlkaXItcGF0aC0wNj88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkhpIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SXQgaXMgdGltZSB0byBzaGFyZSB5b3VyIHRob3VnaHRzIGFib3V0IGRyYWZ0LWxp LXBjZS1zci1iaWRpci1wYXRoLTA2LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+RG8geW91IGJlbGlldmUgdGhlIEktRCBpcyBhIHJpZ2h0IGZvdW5k YXRpb24gZm9yIGEgUENFIFdHIGl0ZW0/IFBsZWFzZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dXNlIHRoZSBQQ0UgbWFpbGluZyBsaXN0IHRvIGV4 cHJlc3MgeW91ciBjb21tZW50cywgc3VwcG9ydCBvcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZGlzYWdyZWVtZW50LCBpbmNsdWRpbmcgYXBwbGlj YWJsZSByYXRpb25hbGUsIGVzcGVjaWFsbHkgZm9yIHRoZSBsYXR0ZXIuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGhydXYgJmFtcDsg SnVsaWVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_0D63E9AC20AF4048B9B667E4D3D6C808ciscocom_-- From nobody Fri Jan 24 10:51:56 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F5512099B; Fri, 24 Jan 2020 10:51:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-pce-association-diversity@ietf.org, Julien Meuric , pce-chairs@ietf.org, julien.meuric@orange.com, pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <157989190835.22112.4459420015658931253.idtracker@ietfa.amsl.com> Date: Fri, 24 Jan 2020 10:51:48 -0800 Archived-At: Subject: [Pce] Alissa Cooper's No Objection on draft-ietf-pce-association-diversity-13: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 18:51:48 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-pce-association-diversity-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-association-diversity/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing the Gen-ART review comments. From nobody Sun Jan 26 01:40:39 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14B5120019 for ; Sun, 26 Jan 2020 01:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.632 X-Spam-Level: X-Spam-Status: No, score=-3.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Emmamvpw7pjZ for ; Sun, 26 Jan 2020 01:40:35 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56173120018 for ; Sun, 26 Jan 2020 01:40:35 -0800 (PST) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id EDC92CDA4F58B1F3F7AF for ; Sun, 26 Jan 2020 09:40:33 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 26 Jan 2020 09:40:33 +0000 Received: from DGGEMM532-MBX.china.huawei.com ([169.254.7.77]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0439.000; Sun, 26 Jan 2020 17:40:31 +0800 From: Lizhenbin To: julien.meuric , pce Thread-Topic: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? Thread-Index: AQHVzR6504bzvVh8Uka038puQPlXoKf5R8oAgAN3QzE= Date: Sun, 26 Jan 2020 09:40:30 +0000 Message-ID: 990ACCB5-CA37-4BEC-A3C0-7E8174FE77BA References: , <0D63E9AC-20AF-4048-B9B6-67E4D3D6C808@cisco.com> In-Reply-To: <0D63E9AC-20AF-4048-B9B6-67E4D3D6C808@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_990ACCB5CA374BECA3C07E8174FE77BA_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 09:40:37 -0000 --_000_990ACCB5CA374BECA3C07E8174FE77BA_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgV0csDQoNCkkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudC4NCg0KQmVz dCByZWdhcmRzLA0KWmhlbmJpbiAoUm9iaW4pDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQrmnY7mjK/mlowgTGkgWmhlbmJpbg0KTW9iaWxlOiAr ODYtMTM2NTEwMTc3NDUvKzk2OC05MTc5NzA2OA0KRW1haWw6IGxpemhlbmJpbkBodWF3ZWkuY29t PG1haWx0bzpsaXpoZW5iaW5AaHVhd2VpLmNvbT4NCg0K5Y+R5Lu25Lq677yaWmFmYXIgQWxpICh6 YWxpKSA8emFsaUBjaXNjby5jb20+DQrmlLbku7bkurrvvJpqdWxpZW4ubWV1cmljIDxqdWxpZW4u bWV1cmljQG9yYW5nZS5jb20+O3BjZSA8cGNlQGlldGYub3JnPg0K5pe24oCD6Ze077yaMjAyMC0w MS0yNCAyMDo0NToyNQ0K5Li74oCD6aKY77yaUmU6IFtQY2VdIEFkb3B0aW9uIG9mIGRyYWZ0LWxp LXBjZS1zci1iaWRpci1wYXRoLTA2Pw0KDQpTdXBwb3J0IQ0KDQpUaGFua3MNCg0KUmVnYXJkcyDi gKYgWmFmYXINCg0KRnJvbTogUGNlIDxwY2UtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9m ICJqdWxpZW4ubWV1cmljQG9yYW5nZS5jb20iIDxqdWxpZW4ubWV1cmljQG9yYW5nZS5jb20+DQpP cmdhbml6YXRpb246IE9yYW5nZQ0KRGF0ZTogRnJpZGF5LCBKYW51YXJ5IDE3LCAyMDIwIGF0IDU6 MTMgQU0NClRvOiAicGNlQGlldGYub3JnIiA8cGNlQGlldGYub3JnPg0KU3ViamVjdDogW1BjZV0g QWRvcHRpb24gb2YgZHJhZnQtbGktcGNlLXNyLWJpZGlyLXBhdGgtMDY/DQoNCkhpIGFsbCwNCg0K SXQgaXMgdGltZSB0byBzaGFyZSB5b3VyIHRob3VnaHRzIGFib3V0IGRyYWZ0LWxpLXBjZS1zci1i aWRpci1wYXRoLTA2Lg0KRG8geW91IGJlbGlldmUgdGhlIEktRCBpcyBhIHJpZ2h0IGZvdW5kYXRp b24gZm9yIGEgUENFIFdHIGl0ZW0/IFBsZWFzZQ0KdXNlIHRoZSBQQ0UgbWFpbGluZyBsaXN0IHRv IGV4cHJlc3MgeW91ciBjb21tZW50cywgc3VwcG9ydCBvcg0KZGlzYWdyZWVtZW50LCBpbmNsdWRp bmcgYXBwbGljYWJsZSByYXRpb25hbGUsIGVzcGVjaWFsbHkgZm9yIHRoZSBsYXR0ZXIuDQoNClRo YW5rcywNCg0KRGhydXYgJiBKdWxpZW4NCg0KDQoNCg== --_000_990ACCB5CA374BECA3C07E8174FE77BA_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT4NCjwhLS0NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCJ9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNh bGlicml9DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWZ9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0fQ0KLk1zb0No cERlZmF1bHQNCgl7Zm9udC1zaXplOjEwLjBwdH0NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXttYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW59DQpkaXYuV29yZFNlY3Rpb24xDQoJe30NCi0tPg0K PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGlu az0iIzk1NEY3MiI+DQo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPg0KPCEtLQ0KKg0KCXt9DQpib2R5 DQoJe2ZvbnQtZmFtaWx5OkNhbGlicml9DQotLT4NCjwvc3R5bGU+DQo8ZGl2PkhpIFdHLDxicj4N Cjxicj4NCkkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudC48YnI+DQo8YnI+ DQpCZXN0IHJlZ2FyZHMsPGJyPg0KWmhlbmJpbiAoUm9iaW4pPGJyPg0KPC9kaXY+DQo8ZGl2Pjwv ZGl2Pg0KPGRpdj4NCjxwIGRpcj0ibHRyIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCuadjuaMr+aWjCBMaSBaaGVuYmluPGJyPg0KTW9iaWxl OiAmIzQzOzg2LTEzNjUxMDE3NzQ1LyYjNDM7OTY4LTkxNzk3MDY4PGJyPg0KRW1haWw6IDxhIGhy ZWY9Im1haWx0bzpsaXpoZW5iaW5AaHVhd2VpLmNvbSI+bGl6aGVuYmluQGh1YXdlaS5jb208L2E+ PC9wPg0KPC9kaXY+DQo8ZGl2IG5hbWU9IkFueU9mZmljZS1CYWNrZ3JvdW5kLUltYWdlIiBzdHls ZT0iYm9yZGVyLXRvcDoxcHggc29saWQgI0I1QzRERjsgcGFkZGluZzo4cHgiPg0KPGRpdiBzdHls ZT0id29yZC1icmVhazpicmVhay1hbGwiPjxiPuWPkeS7tuS6uu+8mjwvYj5aYWZhciBBbGkgKHph bGkpICZsdDt6YWxpQGNpc2NvLmNvbSZndDs8L2Rpdj4NCjxkaXYgc3R5bGU9IndvcmQtYnJlYWs6 YnJlYWstYWxsIj48Yj7mlLbku7bkurrvvJo8L2I+anVsaWVuLm1ldXJpYyAmbHQ7anVsaWVuLm1l dXJpY0BvcmFuZ2UuY29tJmd0OztwY2UgJmx0O3BjZUBpZXRmLm9yZyZndDs8L2Rpdj4NCjxkaXYg c3R5bGU9IndvcmQtYnJlYWs6YnJlYWstYWxsIj48Yj7ml7bigIPpl7TvvJo8L2I+MjAyMC0wMS0y NCAyMDo0NToyNTwvZGl2Pg0KPGRpdiBzdHlsZT0id29yZC1icmVhazpicmVhay1hbGwiPjxiPuS4 u+KAg+mimO+8mjwvYj5SZTogW1BjZV0gQWRvcHRpb24gb2YgZHJhZnQtbGktcGNlLXNyLWJpZGly LXBhdGgtMDY/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1cHBvcnQhIDwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGFua3M8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMg4oCmIFphZmFyIDwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lOyBib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7IHBhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7IGNvbG9yOmJs YWNrIj5Gcm9tOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7IGNv bG9yOmJsYWNrIj5QY2UgJmx0O3BjZS1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2Yg JnF1b3Q7anVsaWVuLm1ldXJpY0BvcmFuZ2UuY29tJnF1b3Q7ICZsdDtqdWxpZW4ubWV1cmljQG9y YW5nZS5jb20mZ3Q7PGJyPg0KPGI+T3JnYW5pemF0aW9uOiA8L2I+T3JhbmdlPGJyPg0KPGI+RGF0 ZTogPC9iPkZyaWRheSwgSmFudWFyeSAxNywgMjAyMCBhdCA1OjEzIEFNPGJyPg0KPGI+VG86IDwv Yj4mcXVvdDtwY2VAaWV0Zi5vcmcmcXVvdDsgJmx0O3BjZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OiA8L2I+W1BjZV0gQWRvcHRpb24gb2YgZHJhZnQtbGktcGNlLXNyLWJpZGlyLXBhdGgt MDY/PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIGFsbCw8L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyB0aW1lIHRvIHNoYXJlIHlvdXIgdGhvdWdo dHMgYWJvdXQgZHJhZnQtbGktcGNlLXNyLWJpZGlyLXBhdGgtMDYuPC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG8geW91IGJlbGlldmUgdGhlIEktRCBpcyBhIHJpZ2h0 IGZvdW5kYXRpb24gZm9yIGEgUENFIFdHIGl0ZW0/IFBsZWFzZTwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnVzZSB0aGUgUENFIG1haWxpbmcgbGlzdCB0byBleHByZXNz IHlvdXIgY29tbWVudHMsIHN1cHBvcnQgb3I8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5kaXNhZ3JlZW1lbnQsIGluY2x1ZGluZyBhcHBsaWNhYmxlIHJhdGlvbmFsZSwg ZXNwZWNpYWxseSBmb3IgdGhlIGxhdHRlci48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGFua3MsPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGhydXYgJmFtcDsgSnVs aWVuPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_990ACCB5CA374BECA3C07E8174FE77BA_-- From nobody Sun Jan 26 04:12:20 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2E4120018 for ; Sun, 26 Jan 2020 04:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hc5aMfYCl138 for ; Sun, 26 Jan 2020 04:12:17 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8BFC120019 for ; Sun, 26 Jan 2020 04:12:16 -0800 (PST) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 6E62A2C7B6F180012D0F for ; Sun, 26 Jan 2020 12:12:13 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 26 Jan 2020 12:12:12 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0439.000; Sun, 26 Jan 2020 20:11:57 +0800 From: Zhuangshunwan To: "julien.meuric@orange.com" , "pce@ietf.org" Thread-Topic: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? Thread-Index: AQHVzR7K1lgkTXJf50m/CMmI0ls8P6f5ehUAgANu6yA= Date: Sun, 26 Jan 2020 12:11:56 +0000 Message-ID: <19AB2A007F56DB4E8257F949A2FB9858E5F99BC0@NKGEML515-MBX.china.huawei.com> References: <0D63E9AC-20AF-4048-B9B6-67E4D3D6C808@cisco.com> In-Reply-To: <0D63E9AC-20AF-4048-B9B6-67E4D3D6C808@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.166.160] Content-Type: multipart/alternative; boundary="_000_19AB2A007F56DB4E8257F949A2FB9858E5F99BC0NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 12:12:18 -0000 --_000_19AB2A007F56DB4E8257F949A2FB9858E5F99BC0NKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpTdXBwb3J0Lg0KDQpUaGFua3MNClNodW53YW4NCg0KRnJvbTogUGNlIDxwY2UtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgImp1bGll bi5tZXVyaWNAb3JhbmdlLmNvbTxtYWlsdG86anVsaWVuLm1ldXJpY0BvcmFuZ2UuY29tPiIgPGp1 bGllbi5tZXVyaWNAb3JhbmdlLmNvbTxtYWlsdG86anVsaWVuLm1ldXJpY0BvcmFuZ2UuY29tPj4N Ck9yZ2FuaXphdGlvbjogT3JhbmdlDQpEYXRlOiBGcmlkYXksIEphbnVhcnkgMTcsIDIwMjAgYXQg NToxMyBBTQ0KVG86ICJwY2VAaWV0Zi5vcmc8bWFpbHRvOnBjZUBpZXRmLm9yZz4iIDxwY2VAaWV0 Zi5vcmc8bWFpbHRvOnBjZUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbUGNlXSBBZG9wdGlvbiBvZiBk cmFmdC1saS1wY2Utc3ItYmlkaXItcGF0aC0wNj8NCg0KSGkgYWxsLA0KDQpJdCBpcyB0aW1lIHRv IHNoYXJlIHlvdXIgdGhvdWdodHMgYWJvdXQgZHJhZnQtbGktcGNlLXNyLWJpZGlyLXBhdGgtMDYu DQpEbyB5b3UgYmVsaWV2ZSB0aGUgSS1EIGlzIGEgcmlnaHQgZm91bmRhdGlvbiBmb3IgYSBQQ0Ug V0cgaXRlbT8gUGxlYXNlDQp1c2UgdGhlIFBDRSBtYWlsaW5nIGxpc3QgdG8gZXhwcmVzcyB5b3Vy IGNvbW1lbnRzLCBzdXBwb3J0IG9yDQpkaXNhZ3JlZW1lbnQsIGluY2x1ZGluZyBhcHBsaWNhYmxl IHJhdGlvbmFsZSwgZXNwZWNpYWxseSBmb3IgdGhlIGxhdHRlci4NCg0KVGhhbmtzLA0KDQpEaHJ1 diAmIEp1bGllbg0KDQoNCg0K --_000_19AB2A007F56DB4E8257F949A2FB9858E5F99BC0NKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSIjMDU2M0Mx IiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5TdXBwb3J0LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+U2h1bndhbiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+UGNlICZsdDs8YSBocmVmPSJtYWlsdG86cGNlLWJvdW5j ZXNAaWV0Zi5vcmciPnBjZS1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mICZx dW90OzxhIGhyZWY9Im1haWx0bzpqdWxpZW4ubWV1cmljQG9yYW5nZS5jb20iPmp1bGllbi5tZXVy aWNAb3JhbmdlLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqdWxpZW4ubWV1cmlj QG9yYW5nZS5jb20iPmp1bGllbi5tZXVyaWNAb3JhbmdlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+T3Jn YW5pemF0aW9uOiA8L2I+T3JhbmdlPGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgSmFudWFyeSAx NywgMjAyMCBhdCA1OjEzIEFNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86 cGNlQGlldGYub3JnIj5wY2VAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 cGNlQGlldGYub3JnIj5wY2VAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5b UGNlXSBBZG9wdGlvbiBvZiBkcmFmdC1saS1wY2Utc3ItYmlkaXItcGF0aC0wNj88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIGFsbCw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkl0IGlzIHRpbWUgdG8gc2hh cmUgeW91ciB0aG91Z2h0cyBhYm91dCBkcmFmdC1saS1wY2Utc3ItYmlkaXItcGF0aC0wNi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+RG8geW91IGJlbGlldmUgdGhlIEktRCBpcyBhIHJpZ2h0IGZvdW5k YXRpb24gZm9yIGEgUENFIFdHIGl0ZW0/IFBsZWFzZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj51c2Ug dGhlIFBDRSBtYWlsaW5nIGxpc3QgdG8gZXhwcmVzcyB5b3VyIGNvbW1lbnRzLCBzdXBwb3J0IG9y PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPmRpc2FncmVlbWVudCwgaW5jbHVkaW5nIGFwcGxpY2FibGUg cmF0aW9uYWxlLCBlc3BlY2lhbGx5IGZvciB0aGUgbGF0dGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RGhydXYgJmFtcDsgSnVsaWVuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_19AB2A007F56DB4E8257F949A2FB9858E5F99BC0NKGEML515MBXchi_-- From nobody Sun Jan 26 06:17:24 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5B9120058 for ; Sun, 26 Jan 2020 06:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mm2E0pMRvAky for ; Sun, 26 Jan 2020 06:17:20 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A82F120043 for ; Sun, 26 Jan 2020 06:17:20 -0800 (PST) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 94FA14E3F5F944E9B8CB for ; Sun, 26 Jan 2020 14:17:14 +0000 (GMT) Received: from lhreml743-chm.china.huawei.com (10.201.108.193) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 26 Jan 2020 14:17:12 +0000 Received: from lhreml743-chm.china.huawei.com (10.201.108.193) by lhreml743-chm.china.huawei.com (10.201.108.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Sun, 26 Jan 2020 14:17:14 +0000 Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml743-chm.china.huawei.com (10.201.108.193) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Sun, 26 Jan 2020 14:17:14 +0000 Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.115]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0439.000; Sun, 26 Jan 2020 22:17:11 +0800 From: Zhenghaomian To: "julien.meuric@orange.com" , "pce@ietf.org" Thread-Topic: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? Thread-Index: AQHVzR65KH9CMZLatk6xE66AAy5MSKf9DEwA Date: Sun, 26 Jan 2020 14:17:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.97.231] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Pce] =?utf-8?b?562U5aSNOiAgQWRvcHRpb24gb2YgZHJhZnQtbGktcGNlLXNy?= =?utf-8?q?-bidir-path-06=3F?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 14:17:22 -0000 WWVzL1N1cHBvcnQuIA0KDQpCZXN0IHdpc2hlcywNCkhhb21pYW4NCg0KLS0tLS3pgq7ku7bljp/k u7YtLS0tLQ0K5Y+R5Lu25Lq6OiBQY2UgW21haWx0bzpwY2UtYm91bmNlc0BpZXRmLm9yZ10g5Luj 6KGoIGp1bGllbi5tZXVyaWNAb3JhbmdlLmNvbQ0K5Y+R6YCB5pe26Ze0OiAyMDIw5bm0MeaciDE3 5pelIDE4OjEzDQrmlLbku7bkuro6IHBjZUBpZXRmLm9yZw0K5Li76aKYOiBbUGNlXSBBZG9wdGlv biBvZiBkcmFmdC1saS1wY2Utc3ItYmlkaXItcGF0aC0wNj8NCg0KSGkgYWxsLA0KDQpJdCBpcyB0 aW1lIHRvIHNoYXJlIHlvdXIgdGhvdWdodHMgYWJvdXQgZHJhZnQtbGktcGNlLXNyLWJpZGlyLXBh dGgtMDYuDQpEbyB5b3UgYmVsaWV2ZSB0aGUgSS1EIGlzIGEgcmlnaHQgZm91bmRhdGlvbiBmb3Ig YSBQQ0UgV0cgaXRlbT8gUGxlYXNlIHVzZSB0aGUgUENFIG1haWxpbmcgbGlzdCB0byBleHByZXNz IHlvdXIgY29tbWVudHMsIHN1cHBvcnQgb3IgZGlzYWdyZWVtZW50LCBpbmNsdWRpbmcgYXBwbGlj YWJsZSByYXRpb25hbGUsIGVzcGVjaWFsbHkgZm9yIHRoZSBsYXR0ZXIuDQoNClRoYW5rcywNCg0K RGhydXYgJiBKdWxpZW4NCg0KDQo= From nobody Sun Jan 26 20:40:52 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAB41200B3 for ; Sun, 26 Jan 2020 13:04:15 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -0.985 X-Spam-Level: X-Spam-Status: No, score=-0.985 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t16VCe7wvCkW for ; Sun, 26 Jan 2020 13:04:13 -0800 (PST) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DC4E120052 for ; Sun, 26 Jan 2020 13:04:12 -0800 (PST) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-05v.sys.comcast.net with ESMTP id vopZilQZM9yxwvp4liqzia; Sun, 26 Jan 2020 21:04:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1580072651; bh=PK608k5tYarUnsRlXGObPpIiHomPIAv7i58JFli/w3U=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=hHPmunFyIck83N4EMf8Zy1g0I4XjlYJ/wHp+sHl3OzYdAMgoPGCdDbmryLkbM//eM zYi1G+v9PO0w+TlEUQz8+NejlL4NzM6MJW7Fupq/9O5o6XBf3rbCWtTH0VevlrfnOB rkeDMsE15TQOWzyrn6qYmrUHhJCOBrSvVr13hi38QtJu2VzBheY8icRTnYXB+tNNlR QOT0aVRxQ/g3kWws6zQZm8TEandlJ56S2YqYlkmLIdhVa4wSVI2/GWrj/L9FMubtP7 yLvk2euehS/XTjRl8HcaduuuULhs5zIXPsGlmmesoBULIRVcPP+sfzksSgnXuIL9/v kiLwSJlnaNQtA== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4600:c190:222:fbff:fe91:d396]) by resomta-ch2-11v.sys.comcast.net with ESMTPA id vp4jirW9fHD5Kvp4kid9Bg; Sun, 26 Jan 2020 21:04:11 +0000 X-Xfinity-VMeta: sc=0.00;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 00QL49Hi027840; Sun, 26 Jan 2020 16:04:09 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 00QL48YC027837; Sun, 26 Jan 2020 16:04:08 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Dhruv Dhody Cc: draft-ietf-pce-association-diversity.all@ietf.org, mahend.ietf@gmail.com, pce-chairs@ietf.org, alissa@cooperw.in, julien.meuric@orange.com, db3546@att.com Cc: The IESG , Julien Meuric , pce@ietf.org In-Reply-To: (dhruv.ietf@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 26 Jan 2020 16:04:08 -0500 Message-ID: <87muaadj5j.fsf@hobgoblin.ariadne.com> Archived-At: X-Mailman-Approved-At: Sun, 26 Jan 2020 20:40:51 -0800 Subject: Re: [Pce] Genart last call review of draft-ietf-pce-association-diversity-10 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 21:04:16 -0000 > Sections 5.4.1 and 5.5 address your comments. > https://tools.ietf.org/html/draft-ietf-pce-association-diversity-12#section-5.4.1 > https://tools.ietf.org/html/draft-ietf-pce-association-diversity-12#section-5.5 > Thanks. Dale, could you take a look? My apologies for not responding sooner. Comparing the latest version, -13, to the one that I reviewed, -10: Recapitulating my review, the major items were: - Clarifying the use of the TLV; in particular that non-identical copies are attached to multiple LSPs. This is substantially improved. - The effect of multiple LSPs with P=1 within a group. This is clarified. In particular, I see that my previous understanding was incorrect. - Interaction with SVEC. This discussion is considerably expanded. I do not fully understand it (most likely because I have not read the SVEC specification), but it's likely that the authors have covered it well. I note that the new text explains that there may be situations that are so complicated that the path computation can not be done. * However, in regard to the new example: o PCReq with SVEC object with link-diverse bit=1 (LSP1,LSP2) and DAG with L=1 (LSP1,LSP3) - link diverse paths between LSP1, LSP2, LSP3. But any future change in LSP2 will have no impact. As far as I can tell, there is a diversity constraint between LSP1 and LSP2, and a diversity constraint between LSP1 and LSP3, but there is none between LSP2 and LAP3 -- this is not quite the same as "link diverse paths between LSP1, LSP2, LSP3". In particular, LSP2 and LSP3 might be identical. The final sentence is unclear to me (probably due to my inexperience); is it possible to be more exact regarding the reason/manner that such a change "will have no impact"? These revisions reasonably resolve my concerns. Dale From nobody Sun Jan 26 21:19:11 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D411200F4; Sun, 26 Jan 2020 21:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VysnN4lw7tKh; Sun, 26 Jan 2020 21:19:03 -0800 (PST) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 919E212008A; Sun, 26 Jan 2020 21:19:02 -0800 (PST) Received: by mail-il1-x12c.google.com with SMTP id b15so6459754iln.3; Sun, 26 Jan 2020 21:19:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OeV8ArPaHKWLOUni87jDPdKF1kvT4Rto5KLS0ZX5eP8=; b=lRWG/YkDBDfpt8T3CyoKI75bYZLQhQd2rHfZ3aQBX4XQbE4Y+TIes92jMTdbRDD8Qe 1enPVb/yB0ZapHTLKkujoia/0Gt4VYeMLaAo3udeIS/OVmJ0l6na3jWNwE+yjgotNj4p u3v5FWIe35baIWS44w3N9vOB0ia+qPWkQrncziBQZBIPoDicDbt7fg1TuLJ8JxTj/huU mhLEoXMTFBIKUoDq+7iOWRSL94acS7tBE/8EuygA8A9Newoa9WyAEPc+ttc2JsN30gIb t+6SP6+D9/qv2e5QQiAXvgzT5WNpJBytqb2epqKxjJiXeNcdGI+T+tmYVWJvFveXjd6s SfRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OeV8ArPaHKWLOUni87jDPdKF1kvT4Rto5KLS0ZX5eP8=; b=CJIgtya/3ZZ0pm2YjAqSyWJluDvFf2ZmV+rDAZaJZ6qe+4/cxScv6JwAZGzHSToi0I BNFj/vx/9Fd1UaKaFf6jpqLwDpmBsjh4YK5dKfOFnvJzZnKc8xlnh/92uXpdpnpgFMHl MFGZkK90YYotZdAMmQRAEbUu3HNOrGdKy++0tVW0vSoLUA6Q0O5hHHxQpVh4KHb1jQ5v jqh2lNXGnoR5dp6uFNK+2MNy4/iN9Xxw50NZRZGsESTumCDUhR+HEdoyPZ1XhCrOe3o3 u7qy3ZJl2Qf5GXAEd+YyEFXBdE0kUldqRJYYQLEZnioptD/rDIlvJecq7cedxyPCEUOM 79kA== X-Gm-Message-State: APjAAAVlhFzsmq+XTfgSphmyxYVUwBNq6POfXKSkyu7p76kga9XoCO0c Mn1yw103pk1RvvMzZ0R9JrVjpx4NbpZgWRPlwgk= X-Google-Smtp-Source: APXvYqznYu2PFZnqyWD/iDbFsfbDbqcxdtfR8f4wwYzuLhk1yT7a56F6TPpAgyWRtwW0Wr/iBZBeOmcSoyslpJoIH6w= X-Received: by 2002:a92:1b51:: with SMTP id b78mr10767995ilb.14.1580102341687; Sun, 26 Jan 2020 21:19:01 -0800 (PST) MIME-Version: 1.0 References: <87muaadj5j.fsf@hobgoblin.ariadne.com> In-Reply-To: <87muaadj5j.fsf@hobgoblin.ariadne.com> From: Dhruv Dhody Date: Mon, 27 Jan 2020 10:48:25 +0530 Message-ID: To: "Dale R. Worley" Cc: draft-ietf-pce-association-diversity.all@ietf.org, Mahend Negi , pce-chairs , Alissa Cooper , Julien Meuric , "BRUNGARD, DEBORAH A" , The IESG , pce@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Pce] Genart last call review of draft-ietf-pce-association-diversity-10 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 05:19:04 -0000 Hi Dale, Thanks for confirmation. Regarding the example - > > * However, in regard to the new example: > > o PCReq with SVEC object with link-diverse bit=1 (LSP1,LSP2) and DAG > with L=1 (LSP1,LSP3) - link diverse paths between LSP1, LSP2, > LSP3. But any future change in LSP2 will have no impact. > > As far as I can tell, there is a diversity constraint between LSP1 and > LSP2, and a diversity constraint between LSP1 and LSP3, but there is > none between LSP2 and LAP3 -- this is not quite the same as "link > diverse paths between LSP1, LSP2, LSP3". In particular, LSP2 and LSP3 > might be identical. > > The final sentence is unclear to me (probably due to my inexperience); > is it possible to be more exact regarding the reason/manner that such a > change "will have no impact"? > I suggest following change to make it clear - o PCReq with SVEC object with link-diverse bit=1 (LSP1,LSP2) and DAG with L=1 (LSP1,LSP3) - link diverse paths between LSP1 & LSP2, and LSP1 & LSP3. If the DAG is part of the stateful database, any future change in LSP3 will have an impact on LSP1. But any future change in LSP2 will have no impact on LSP1, as LSP2 is part of SVEC object (which is considered once on receipt of the PCReq message only). Thanks! Dhruv From nobody Sun Jan 26 21:28:40 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50870120045; Sun, 26 Jan 2020 21:28:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <158010291813.30598.8706560762184304352@ietfa.amsl.com> Date: Sun, 26 Jan 2020 21:28:38 -0800 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-association-diversity-14.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 05:28:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Path Computation Element Communication Protocol (PCEP) Extension for LSP Diversity Constraint Signaling Authors : Stephane Litkowski Siva Sivabalan Colby Barth Mahendra Singh Negi Filename : draft-ietf-pce-association-diversity-14.txt Pages : 24 Date : 2020-01-26 Abstract: This document introduces a simple mechanism to associate a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element (PCE) communication Protocol (PCEP) with the purpose of computing diverse (disjointed) paths for those LSPs. The proposed extension allows a Path Computation Client (PCC) to advertise to a PCE that a particular LSP belongs to a particular disjoint-group, thus the PCE knows that the LSPs in the same group need to be disjoint from each other. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-association-diversity/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-association-diversity-14 https://datatracker.ietf.org/doc/html/draft-ietf-pce-association-diversity-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-diversity-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 27 08:05:13 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA29120831; Mon, 27 Jan 2020 08:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.289 X-Spam-Level: X-Spam-Status: No, score=-0.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cci_RQHfXWN; Mon, 27 Jan 2020 08:03:52 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A8A12080A; Mon, 27 Jan 2020 08:03:52 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 485vgT3jqQzFqLk; Mon, 27 Jan 2020 17:03:49 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.104]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 485vgT2w3Gz1xpm; Mon, 27 Jan 2020 17:03:49 +0100 (CET) Received: from [10.193.71.21] (10.114.13.245) by OPEXCAUBM5F.corporate.adroot.infra.ftgroup (10.114.13.104) with Microsoft SMTP Server (TLS) id 14.3.468.0; Mon, 27 Jan 2020 17:03:49 +0100 From: References: X-Priority: 4 (Low) Organization: Orange Message-ID: <2514_1580141029_5E2F09E5_2514_404_1_9a99f3d3-464d-5dc4-59aa-67ad7cc17818@orange.com> Date: Mon, 27 Jan 2020 17:03:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 To: undisclosed-recipients:; In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [10.114.13.245] Archived-At: X-Mailman-Approved-At: Mon, 27 Jan 2020 08:05:12 -0800 Subject: [Pce] CFP for the 16th International Conference on IP + Optical Network (iPOP 2020) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 16:03:54 -0000 Hi all, The CFP is available at:  https://www.pilab.jp/ipop2020/proposals/cfp.html. The important dates are the following;                 Submission deadline of one-page abstract:  February 28, 2020                 Notification of acceptance:  April 2, 2020                 Submission deadline of final presentation slides:  May 8, 2020 Cheers, Julien _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Tue Jan 28 05:12:41 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721F012006B for ; Tue, 28 Jan 2020 05:12:38 -0800 (PST) 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=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOe2jYjgv_6D for ; Tue, 28 Jan 2020 05:12:36 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD05120058 for ; Tue, 28 Jan 2020 05:12:36 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 486RqQ6pthz8tFH for ; Tue, 28 Jan 2020 14:12:34 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.104]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 486RqQ5xB3zCql7 for ; Tue, 28 Jan 2020 14:12:34 +0100 (CET) Received: from [10.193.71.21] (10.114.13.247) by OPEXCAUBM5F.corporate.adroot.infra.ftgroup (10.114.13.104) with Microsoft SMTP Server (TLS) id 14.3.468.0; Tue, 28 Jan 2020 14:12:34 +0100 References: To: "pce@ietf.org" From: Organization: Orange X-Forwarded-Message-Id: Message-ID: Date: Tue, 28 Jan 2020 14:12:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000403010208010405050609" X-Originating-IP: [10.114.13.247] Archived-At: Subject: [Pce] Fwd: New server failure X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 13:12:39 -0000 --------------ms000403010208010405050609 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Language: en-US FYI -------- Forwarded Message -------- Date: Tue, 28 Jan 2020 03:38:01 -0800 From: Glen All - It is with deep regret that I announce that we encountered a system failure on the new server overnight. Three hours ago, at 00:15 Pacific time, several key data directories on the new server were wiped out, almost as if a synchronization job had failed or was overwriting data. The damage was not in an identifiable pattern. An initial investigation was performed without an immediate result. Missing directories seemed to be random. After consulting with Henrik, we felt we had no choice but to bring the old server back online, and we have done so. Although this doesn't appear to be a hacker/attack, I have not dismissed that possibility, and have taken appropriate precautions on the old server in the event foul play was involved. Instead I suspect that something pertaining to our software upgrade work was the culprit here, but it may take a while before we identify the cause. What this means, for now, unfortunately, is that actions taken yesterday, within the past 14 hours from the time of this message, including emails sent and files uploaded, are lost. If you uploaded a draft yesterday, or took any other Datatracker action, you will need to repeat those actions today. Unfortunately whatever occurred was immediately propagated to the backup machines, since the servers didn't crash. But in addition to those things, I have a secondary backup system that runs daily. We have files and email archive messages up to about 4 hours ago, and we'll be working to restore those as soon as we can. In the meantime, the old servers are back up and running, and we will investigate and determine a way forward as soon as possible. Thank you for your patience. Glen -- Glen Barney IT Director AMS (IETF Secretariat) _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------ms000403010208010405050609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC EmowggTeMIIDxqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMGoxCzAJBgNVBAYTAkZSMRowGAYD VQQKDBFGcmFuY2UgVGVsZWNvbSBTQTEXMBUGA1UECwwOMDAwMiAzODAxMjk4NjYxJjAkBgNV BAMMHUdyb3VwZSBGcmFuY2UgVGVsZWNvbSBSb290IENBMB4XDTA1MTExNzExMDkzOVoXDTI1 MTExNzExMDkzOVowgZYxCzAJBgNVBAYTAkZSMRowGAYDVQQKDBFGcmFuY2UgVGVsZWNvbSBT QTEkMCIGA1UECwwbV2VzdGVybkVVIE1pZGRsZUVhc3QgQWZyaWNhMRcwFQYDVQQLDA4wMDAy IDM4MDEyOTg2NjEsMCoGA1UEAwwjR3JvdXBlIEZyYW5jZSBUZWxlY29tIEludGVybmFsIENB IDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCw8ytv/3/3nS8Xkfrfv3lWqny4 Gd1V8eVOT7B0WxfJMqfWPbu0aoc4WScRhqIhAH61Gmfa6f3AVq+o3PptjJ459kMp/ACaeRp8 DFzW7iNFm/Qfdk81V9dVLXHsbYwWU373j/ksx1Smmk3vsq4fWapeAOLfds70KO4RWP/YVSmO rAFVMiqV4l9f6a+G8Lr2tOZkWaX+3vb3HE6mDG3la3Y6VDpVpioSrz61KPb8pLyOg7TuhhIx OKTNNefEcDwFKx9zfVJax+PHj6zGbFzdGEMWexwGSi3SXkgAV6/CJNtCHHXE2OprWc30JiCY 18GkvPrRgO1XBSqx0xDIam+WpEh/AgMBAAGjggFgMIIBXDAPBgNVHRMBAf8EBTADAQH/MA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUNhwzZ9MTXPpbn+qLukRmdEbxd3gwdAYDVR0jBG0w a4AUGpJTyM8zG7bypWB94q8kEkGwmmChUIFOQ049R3JvdXBlIEZyYW5jZSBUZWxlY29tIFJv b3QgQ0EsIE9VPTAwMDIgMzgwMTI5ODY2LCBPPUZyYW5jZSBUZWxlY29tIFNBLCBDPUZSggEA MIGOBgNVHR8EgYYwgYMwQ6BBoD+GPWh0dHA6Ly9pZ2NnZnQtcmNhLWh0dHAuc2kuZnJhbmNl dGVsZWNvbS5mci9jcmwvaWdjZ2Z0X3JjYS5jcmwwPKA6oDiGNmh0dHA6Ly9pZ2NnZnQtcmNh LmZyYW5jZXRlbGVjb20uY29tL2NybC9pZ2NnZnRfcmNhLmNybDATBgNVHSAEDDAKMAgGBiqB egEQDDANBgkqhkiG9w0BAQUFAAOCAQEAlt994iqOFDZH/wQfDU6EQ1W1B/xs/k3xwBuBZgi3 NRWvvb8KhfoOVOyeuoO1r4072jo/AFDphvixN8EZiRp+luqZXQEXEaHrZjwRydCuUDwjPQkw A/DU5NzWn0FrKWRIstQa/MBcN9xniazs41Br3oNzlkUbAyuP2s3GRi5uFp7VV5Y5dU8lqdoL nE/TuBV0LFdre0WOdM7CoWVqNlreb7/zmuK2/zfLIaq2QIcWIOulqiIW1xxFWxc0JZi8p7qV zvysS0+8wevgoefks3PHoUMEaIHCpoSOC14JSkKCVuUMPBvu+ftPasJ+NQz1jUbb0kjUkpGn q33GgLPLSvsK5TCCBsAwggWooAMCAQICEhEhrKTzJoGqMVywoqjNXFnwQTANBgkqhkiG9w0B AQUFADCBljELMAkGA1UEBhMCRlIxGjAYBgNVBAoMEUZyYW5jZSBUZWxlY29tIFNBMSQwIgYD VQQLDBtXZXN0ZXJuRVUgTWlkZGxlRWFzdCBBZnJpY2ExFzAVBgNVBAsMDjAwMDIgMzgwMTI5 ODY2MSwwKgYDVQQDDCNHcm91cGUgRnJhbmNlIFRlbGVjb20gSW50ZXJuYWwgQ0EgMTAeFw0x NzAyMjgwOTQyMDhaFw0yMTAyMjgwOTQyMDhaMGoxCzAJBgNVBAYTAkZSMRowGAYDVQQKExFG cmFuY2UgVGVsZWNvbSBTQTEWMBQGA1UEAwwNTWV1cmljIEp1bGllbjEnMCUGCSqGSIb3DQEJ AQwYanVsaWVuLm1ldXJpY0BvcmFuZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA0Pfhby8TRScxVqtTKug3CKgJW1ub3Y7JydhngY8GOXTXy7mUt4aA0V2JsooyqF3+ nO1xcl3D1RZ+l04fRNHCh/CUHhamoNykCFRNoIM/DuzT7NE5h94UR/3RRgZ2qbZoIn5KYIBj bVMacnZnB/qB9DUH61ecMTzrOG0ePtvABWcrhhOZ2S0MvPJkPtAAlL7qvTe9gJwZkBtEuZ0q rJ0D3OXl5ayV7eP9FuRJ/0jf9FdxnmY0Aagm6+r5vsj9dhU9Gf5cA+mh+L7zrCIpTG2GVLLd KaSORJ1cZ+LeZlgpK+hKJ4ho+J/Usqu9Ak8ngAeOgJqTjxRvOimdZZfJ+2E/GQIDAQABo4ID MTCCAy0wDgYDVR0PAQH/BAQDAgbAMBMGA1UdJQQMMAoGCCsGAQUFBwMEMCMGA1UdEQQcMBqB GGp1bGllbi5tZXVyaWNAb3JhbmdlLmNvbTCCAiEGA1UdHwSCAhgwggIUMIHooIHloIHihoHf bGRhcDovLy9jbj1Hcm91cGUlMjBGcmFuY2UlMjBUZWxlY29tJTIwSW50ZXJuYWwlMjBDQSUy MDEsY249aWdjZ2Z0aSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vy dmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1hZCxEQz1mcmFuY2V0ZWxlY29tLERDPWZyP2Nl cnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RjbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludDCBqaCBpqCBo4aBoGxkYXA6Ly9pZ2NnZnRpLWNhMS1sZGFwLnNpLmZyYW5jZXRl bGVjb20uZnIvb3U9aWdjZ2Z0aV9jYTEsb3U9Q0Esb3U9Q1JMRFAsb3U9QUNfT04sb3U9SUdD R3JvdXBlLG89RnJhbmNlVGVsZWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/ b2JqZWN0Y2xhc3M9cGtpQ2EwNKAyoDCGLmh0dHA6Ly9wa2ktY3JsLml0bi5mdGdyb3VwL2Ny bC9pZ2NnZnRpX2NhMS5jcmwwRaBDoEGGP2h0dHA6Ly9pZ2NnZnRpLWNhMS1odHRwLnNpLmZy YW5jZXRlbGVjb20uZnIvY3JsL2lnY2dmdGlfY2ExLmNybDA+BgNVHSAENzA1MDMGCCqBegEQ DAIDMCcwJQYIKwYBBQUHAgEWGWh0dHA6Ly9wa2ktb3JhbmdlLmNvbS9jcHMwPAYIKwYBBQUH AQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpLW9jc3AuaXRuLmZ0Z3JvdXAvb2NzcDAd BgNVHQ4EFgQUEqE2gJM6hxLi6AlLKQ8kT4r1AlUwHwYDVR0jBBgwFoAUNhwzZ9MTXPpbn+qL ukRmdEbxd3gwDQYJKoZIhvcNAQEFBQADggEBAGxsRCzFlIhen5KnTgZDP6e5jd+ff1MoW3jq wiqxg8v33FldytRqsR5ydg4G5s+mdYhtViuuqm+vOo0F+8oSudj2M70zFIzQR2jMvR8P1oFF 2n+aQlZDW/JY5KqsxbUaR1w5QFE4LCj77OlvTTtaHXn6tZINQqD2rE/28S91ShC4H6WfsTve y2CCLvuYzwUkQ/tPC23rWYxO/hZPkOT/MbgijzIFh4Ys8ENfYNTwkrNSj0LmmJREXIXq50UV EpnsI2v5hE8jXkXlWvT6eXJ7RkocfIjwENvOMvA5/WxE9tvpVCSGq+c5YMWEfyT6o+V2LtTG dtJ3dWNCmsmAgBWXnaswggbAMIIFqKADAgECAhIRIb+AKeqA4nD4aGytIumMzn8wDQYJKoZI hvcNAQEFBQAwgZYxCzAJBgNVBAYTAkZSMRowGAYDVQQKDBFGcmFuY2UgVGVsZWNvbSBTQTEk MCIGA1UECwwbV2VzdGVybkVVIE1pZGRsZUVhc3QgQWZyaWNhMRcwFQYDVQQLDA4wMDAyIDM4 MDEyOTg2NjEsMCoGA1UEAwwjR3JvdXBlIEZyYW5jZSBUZWxlY29tIEludGVybmFsIENBIDEw HhcNMTcwMjI4MDk0MjIxWhcNMjEwMjI4MDk0MjIxWjBqMQswCQYDVQQGEwJGUjEaMBgGA1UE ChMRRnJhbmNlIFRlbGVjb20gU0ExFjAUBgNVBAMMDU1ldXJpYyBKdWxpZW4xJzAlBgkqhkiG 9w0BCQEMGGp1bGllbi5tZXVyaWNAb3JhbmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAMYlaLPYjHfuVjqtO9apWcAd2PIK1MyO7sDYhYw0itPsnsSzsMUa+o7Xjwr/ 9JHcyYEehz2uqzpT0L3bFC8ROTGF3l9sZDPGpUlGeYEFCpNxT2Eg5ZIizYHd5feghGDgbnm0 3UaNldIpi5gtuKSSUHJwLgzZwMykwOdGBkl9dJvj2mccxIlViUATimvjuOj8TES9zrNWuWU7 d1LM9SUrKngkMIA5s801vT4FlvpL/ER7Yt6idZ8rGPXsMdFOhiV3AzLBl1ypaVrQ+OGum/sh c56fMCppmz5okaiGJ2DC9MRR0l4e6ZNrg+nKfm7IhIrCn7wED1TJAfuQfz3YYXKEwO8CAwEA AaOCAzEwggMtMA4GA1UdDwEB/wQEAwIFIDATBgNVHSUEDDAKBggrBgEFBQcDBDAjBgNVHREE HDAagRhqdWxpZW4ubWV1cmljQG9yYW5nZS5jb20wggIhBgNVHR8EggIYMIICFDCB6KCB5aCB 4oaB32xkYXA6Ly8vY249R3JvdXBlJTIwRnJhbmNlJTIwVGVsZWNvbSUyMEludGVybmFsJTIw Q0ElMjAxLGNuPWlnY2dmdGksQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9ZnJhbmNldGVsZWNvbSxEQz1m cj9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JMRGlzdHJp YnV0aW9uUG9pbnQwgamggaaggaOGgaBsZGFwOi8vaWdjZ2Z0aS1jYTEtbGRhcC5zaS5mcmFu Y2V0ZWxlY29tLmZyL291PWlnY2dmdGlfY2ExLG91PUNBLG91PUNSTERQLG91PUFDX09OLG91 PUlHQ0dyb3VwZSxvPUZyYW5jZVRlbGVjb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9i YXNlP29iamVjdGNsYXNzPXBraUNhMDSgMqAwhi5odHRwOi8vcGtpLWNybC5pdG4uZnRncm91 cC9jcmwvaWdjZ2Z0aV9jYTEuY3JsMEWgQ6BBhj9odHRwOi8vaWdjZ2Z0aS1jYTEtaHR0cC5z aS5mcmFuY2V0ZWxlY29tLmZyL2NybC9pZ2NnZnRpX2NhMS5jcmwwPgYDVR0gBDcwNTAzBggq gXoBEAwCAjAnMCUGCCsGAQUFBwIBFhlodHRwOi8vcGtpLW9yYW5nZS5jb20vY3BzMDwGCCsG AQUFBwEBBDAwLjAsBggrBgEFBQcwAYYgaHR0cDovL3BraS1vY3NwLml0bi5mdGdyb3VwL29j c3AwHQYDVR0OBBYEFJpO/hkvlNNchTsRMqcXbFKjr7BjMB8GA1UdIwQYMBaAFDYcM2fTE1z6 W5/qi7pEZnRG8Xd4MA0GCSqGSIb3DQEBBQUAA4IBAQCTgsPIg7wni+YEn7NuxicptWVyoYjn XO9UfYTb4t6M1nizQPrL1ctPCqooEAxUhiH+i8YlnUkG5CHMatTwLtnZJvzGqHkY7q/Ctbki DOqfhaM4b9by+CJp9B5GTKeUzCKAt2Fk0TKqlwbGdKiUfPL9AC58UYOKqjlMUPf6suxqA1fM FyCUBu991kEdwSF7iXbSC/QP2EVsr5Yo1WU9856hAD87Lv/hFp5FjVYKFn9iMQvu325XYLvy EhveODX1HsLj0ohm3/GfPYwyIZpG690uSROq7X8+8WUdX/oplOoaxpEkH5tJO51VAQybQPgj daMD+h/Latx+6W9Dz6oPAxw0MYIEODCCBDQCAQEwga0wgZYxCzAJBgNVBAYTAkZSMRowGAYD VQQKDBFGcmFuY2UgVGVsZWNvbSBTQTEkMCIGA1UECwwbV2VzdGVybkVVIE1pZGRsZUVhc3Qg QWZyaWNhMRcwFQYDVQQLDA4wMDAyIDM4MDEyOTg2NjEsMCoGA1UEAwwjR3JvdXBlIEZyYW5j ZSBUZWxlY29tIEludGVybmFsIENBIDECEhEhrKTzJoGqMVywoqjNXFnwQTANBglghkgBZQME AgEFAKCCAlswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAw MTI4MTMxMjM0WjAvBgkqhkiG9w0BCQQxIgQgUd8e5uvHPTSn8fsLwwomceHurdrQmbe9emrv U442N0EwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGwMIGtMIGWMQswCQYDVQQGEwJGUjEaMBgGA1UECgwR RnJhbmNlIFRlbGVjb20gU0ExJDAiBgNVBAsMG1dlc3Rlcm5FVSBNaWRkbGVFYXN0IEFmcmlj YTEXMBUGA1UECwwOMDAwMiAzODAxMjk4NjYxLDAqBgNVBAMMI0dyb3VwZSBGcmFuY2UgVGVs ZWNvbSBJbnRlcm5hbCBDQSAxAhIRIb+AKeqA4nD4aGytIumMzn8wgcAGCyqGSIb3DQEJEAIL MYGwoIGtMIGWMQswCQYDVQQGEwJGUjEaMBgGA1UECgwRRnJhbmNlIFRlbGVjb20gU0ExJDAi BgNVBAsMG1dlc3Rlcm5FVSBNaWRkbGVFYXN0IEFmcmljYTEXMBUGA1UECwwOMDAwMiAzODAx Mjk4NjYxLDAqBgNVBAMMI0dyb3VwZSBGcmFuY2UgVGVsZWNvbSBJbnRlcm5hbCBDQSAxAhIR Ib+AKeqA4nD4aGytIumMzn8wDQYJKoZIhvcNAQEBBQAEggEAwUkb+rK1RGzAa1OHmDJS2vPB w6ttHYUnfDT/PbNqu52X718hG/Vc1UJa+nSsyMmXSqOi48704WcNJep83y4gQOq6Puq7of4F ZTPTwACTYjgGx60sUtuQfjVTJG9Q4iRyok6U67C8LuAsX99Pj3uLCYQDkg6JsFDX5OJASxEO NGwd+/N9v9oryHWr22p2TCvGDEqZqwEyqUewbH3PKhQXu/b4N2OgpOTA6pY6lejLXJ2+/H3K JpSAOJu1zgOf6ayDat3mczZDAZ6ZeYull7UQMo0UMgEeSMlI1KnDaeTfpzX2RnNlX9OA30oi 9t0NxEEC6OHd2Ndvca8Zd6tu0j8KSQAAAAAAAA== --------------ms000403010208010405050609-- From nobody Wed Jan 29 08:41:57 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5506E1208AD; Wed, 29 Jan 2020 08:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telefonica.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plwYhaDheAqw; Wed, 29 Jan 2020 08:41:38 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20704.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::704]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80CE120883; Wed, 29 Jan 2020 08:41:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O5JfRan98SgJdlvB2GxV5fDQpqjYjdvZ1omIcsS5Ed0GMreS0dWGgEk8sJdlp/8flHdooW0Go+6QXKIgHXc7Irbiq1Fn6n3me3W4zW9mMjRkH5hrLupMwLI/OKE+6TGkRzfZh1Bw9EXnmBVgBijkfVIE7wyYKcHlpH029fqVkD1pUNkBjJ0NgnB/ojU8xxfT0/fogmR2M3JNZTWjHKSRQd+AZF5uBSbzcDgoaDGRGjGJrr0hKrzX7ult0elGBS4onYNe4Jkc7eU0qTaIFUNBALM5rNde0wejw2WOaq6AxR0M++B2RylzaKsfN6GDb98f455omc+N0ZlAvdyCIqM8HA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RueV/XdFcp5s6VaJOVR09HMm2qKOXW3ACvP0EL+a+r4=; b=C1M9b6LFZeqiFWw9UeOKBGnd+6V5RPLY5xhigb5U0ugWJWPgMtBpBnynyipYcpMkWIoksh6Ym43qvPxpmRlgYjenkXRQPBll7t3AIARkQc8JAMfMBNAMbnoHpgCTx+/YBx2PSlUrd8e59AMAmBitpieZ3BR0XZAMR1zr4kb2bG589Hh/U+8+hY2O/MKOm0SLL1HtKAiy9T4O7rYyHwtwc6Sdz3lPFKuudZ2A/mmXeAo+BNktx0NToZryYAyK5GU0lyFormF9TsPKAa4SX5mVyj3XyrZOgbGk5/5VXUi+FtadZ1woqrBiEp4pki1vc6aua2AlBqB7Hrc2qiNEBvoelQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telefonica.com; dmarc=pass action=none header.from=telefonica.com; dkim=pass header.d=telefonica.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telefonica.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RueV/XdFcp5s6VaJOVR09HMm2qKOXW3ACvP0EL+a+r4=; b=RV3EKUhSuriGxIOlwmoTAFFB3Om8w2lrs8lFttIKp8PuN0KAcrGHvehoV/NB+zLSb0VyHqshGwN9u2xV8BgK80L6fJztwVjh+6plLzLgLeDCMeSNEMYkhDOHfBXPYTvJxn0R/Zsg3cCEPyFGfviS1QbPm7CKUITqg0GdXpBXC4k= Received: from AM6PR06MB5653.eurprd06.prod.outlook.com (20.178.93.90) by AM6PR06MB4663.eurprd06.prod.outlook.com (20.177.198.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.20; Wed, 29 Jan 2020 16:41:32 +0000 Received: from AM6PR06MB5653.eurprd06.prod.outlook.com ([fe80::4d14:ef4b:8837:87c5]) by AM6PR06MB5653.eurprd06.prod.outlook.com ([fe80::4d14:ef4b:8837:87c5%7]) with mapi id 15.20.2665.027; Wed, 29 Jan 2020 16:41:32 +0000 From: =?iso-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= To: "adrian@olddog.co.uk" , 'Benjamin Kaduk' , 'The IESG' CC: "draft-ietf-pce-gmpls-pcep-extensions@ietf.org" , "pce@ietf.org" , "pce-chairs@ietf.org" Thread-Topic: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-gmpls-pcep-extensions-15: (with COMMENT) Thread-Index: AQHVmbTRp2A7kjpQmUaBk93N2I68aae3HHKAgEs1gkA= Date: Wed, 29 Jan 2020 16:41:32 +0000 Message-ID: References: <157360299209.31818.3432820168600441007.idtracker@ietfa.amsl.com> <080101d5b127$f0d48c80$d27da580$@olddog.co.uk> In-Reply-To: <080101d5b127$f0d48c80$d27da580$@olddog.co.uk> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=oscar.gonzalezdedios@telefonica.com; x-originating-ip: [190.60.234.237] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 0a3bfb8a-9d5d-4dee-04f0-08d7a4da18e4 x-ms-traffictypediagnostic: AM6PR06MB4663: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(39860400002)(376002)(346002)(136003)(366004)(189003)(199004)(9686003)(55016002)(786003)(316002)(54906003)(110136005)(4326008)(66446008)(26005)(76116006)(66556008)(186003)(52536014)(64756008)(5660300002)(66574012)(66476007)(66946007)(8676002)(6506007)(81156014)(8936002)(81166006)(7696005)(2906002)(33656002)(71200400001)(86362001)(478600001)(9010500006); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR06MB4663; H:AM6PR06MB5653.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1XLAleLD43aoqyyuDc1uGxwmTAI97K+nRXa99sTd8y1M/gHWCweO6H0J0+xV29oQ1CoN4JdNL8ttb4n/3XI/IVcK4pEaxoifD4YPaPtZVS6LXJGXKZ4kZKqd+Pxrh08GpXxTZngJRKBJgQkc5R82SbL+ntKnoplj7Ek3LtKCPWYBLj0poZWmFB5pgFz2+W0Q8bjp9/lQ97ufyc109fkV9+XKGCJCcjqtEgRgXJz6x31+B55Sd9ardpbf6jHcZN0W8geUo64CcV0vy2NhJwPivpjfj3k7fJLtVTf8qUpMWI3X4fiZxQYr4NBARM2p4Ikd+gJsdg6xQJFzIOo3ATYf4tpvgsE2SAsJueiulE8iRMEbe1zwlsYcN1eAwZpf5lHjBlJsvX7WZQqfx7fhIkW7waBsUidsW/GcapN7cNnH4CxMqNFAnxzXPhMyt+u/RiPtfXPF5KbdJlYJStdKgLvZGaTUY0FZ0J2TtDgo1UUjfzhGcrQ9tJBFRJZa3SdK6Zhh x-ms-exchange-antispam-messagedata: VVwv2bUtlszNNzyuygGa/Fn8r/IJ3tTPXO0s82f+KpTmu6jN99bXbpDgC7oKm80B8lnsdNC5pUP7ZOw1WE/mfA13z/XFFdbXM/SOOha8Y3ey2fZBOVZKv5X6JLXGQtnY3kB8ANrD16Ez21SN7cdUIw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0a3bfb8a-9d5d-4dee-04f0-08d7a4da18e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2020 16:41:32.2067 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tv774If7g3EB0gClpKYIyamYNQOAys8pf4CclZMtF2muHFZ/Y09Kxt4c3DB8ftkNwdj2w9UwUPYY708BUs0bEm3pIqAjHwFnyqK1tc98lnpINGF8ielFU0VwlLNO3hVX X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR06MB4663 Archived-At: Subject: Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-gmpls-pcep-extensions-15: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 16:41:51 -0000 Hi Adrian, I can take care of posting (as one of the main editors). Minor thing, current posted version is -16, so I guess this one should be -= 17 right? Oscar -----Mensaje original----- De: Adrian Farrel Enviado el: jueves, 12 de diciembre de 2019 21:09 Para: 'Benjamin Kaduk' ; 'The IESG' CC: draft-ietf-pce-gmpls-pcep-extensions@ietf.org; pce@ietf.org; pce-chairs= @ietf.org Asunto: RE: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-gmpls-pce= p-extensions-15: (with COMMENT) Hi Ben, In the absence of a response from the authors this last month, I'm jumping = in because I want to see this published. Authors/shepherd/chairs/AD: attached is an xml file that makes these change= s. I can't post it cos I'm not an author. Cheers, Adrian =3D=3D=3D > Thank you for addressing my Discuss points! Thanks for clearing. > I do have some additional comments on the -15. Perfect. I'm trying to answer them below. > Section 2.3 > > I'm still a bit concerned that the references linked from Table 4 may > not provide a clear description of what count as Traffic Parameters > for our purposes (and how they are encoded), but not in a way that I > can express more concretely. Perhaps this is made clear by some > RSVP-TE documents with which I am not familiar. Agree that it is pretty convoluted. But I just checked all of the reference= s and they are clear how to encode the traffic parameters for each of the d= ifferent technology types in RSVP-TE. And since the PCEP objects are direct= copies of the RSVP-TE ones, and since they are describing the same things,= I think we are safe. It's true that it's a lot of reading, but the PCE that supports one of thes= e bandwidth types must understand the technology as well as an RSVP-TE impl= ementation that signals one. I think we're OK on this point. > Section 2.5.1 > > root and other endpoints TLVs are the leaves. The root endpoint MUST > be the same for all END-POINTS objects. If the root endpoint is not > > I'm not sure how broadly scoped this restriction is -- it is, e.g., per-LSP? This is all in the scope of a single PCEP request message for a path. So, y= es, per LSP, but multiple END-POINT objects can be present on one request. So... OLD The root endpoint MUST be the same for all END-POINTS objects. NEW The root endpoint MUST be the same for all END-POINTS objects carried in a single PCEP request message. END > Section 2.5.2.5 > > with L bit cleared. At most 2 LABEL_SET TLVs MAY be present with the > O bit set, with at most one of these having the U bit set and at most > one of these having the U bit cleared. For a given U bit value, if > > This went MUST->MAY in this rev, though I think it might be fine to > just use > a lowercase "may", since the requirements language doesn't map > terribly well > to the restriction we're making. I would prefer to make this definitive. I think the language is all mixed a= round. How about we do: OLD At most 2 LABEL_SET TLVs MAY be present with the O bit set, with at most one of these having the U bit set and at most one of these having the U bit cleared. NEW There MUST NOT be more than two LABEL_SET TLVs present with the O bit set. If there are two LABEL_SET TLVs present, there MUST NOT be more than one with the U bit set, and there MUST NOT be more than one with the U bit cleared. END ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o From nobody Wed Jan 29 08:46:43 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2E8120861; Wed, 29 Jan 2020 08:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telefonica.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BucOTfZlHVgz; Wed, 29 Jan 2020 08:46:30 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70094.outbound.protection.outlook.com [40.107.7.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 381A012089D; Wed, 29 Jan 2020 08:46:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jfz05lS41zjW40UDDdumL/td/MyahCiA7Ze0OOh5P4aKfNid7goiSN4tBLbGzwmnZX4Bgq0r/Vh1OMykpzkfSABFcimm719TrAWYd8i66JXYyi9wL9jvV8oEPg3zPkfzlDFaoL8zU0fQJUVcHx7ee542dmqn1XZXK7cS/9M/hjVd3GxdP53NAfT4d9PIwjazr7xNOHlgQtBjRKlYUPXokerEZQMLo7c7W28edvGs77T2UBbmzPUghksK4GnEctJ25ZdStK8KZEZnFF+r8jXofeC+4H0+ofkFnfPWcLSjAUI6b9APYWcxRNsEqYPsKnX8QpTDklcETNj22IYb1+GWjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SgeiYFPAXyYdyCryb0KQ21URFy9o1Sd1UzTc60Txc7I=; b=NSbdtPH0PcRpZ8SR2eFusBtWSABx9fRfBtwlGP23DaA7w5b0+tyRS6jGUpF8gON7hXiF/7hXzAIgWjmY1Wi2zwKy8xMuuP1LkihKU7MmtlTlo5R92P0qkuoZ2B28svuUkdyykSumACTKJbFwN7yVdAMDQAzxSkzkd1AQdKJx4Uo+u9aJewK1ExjoEQAwZz7/7kh4iqstOqvWjpxwcNKMUyyC4MkyZamCDCU9zabH8ZjWmIQGi9VhKDmYQoX2HTMMMnuDnIjB8g7uq1zgcSCPSZaqxY08EMjC5LscyLgZocQxwXqxgur5n4BrQ3At/o0FALEHSu/WrfqPsNUj9xU55Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telefonica.com; dmarc=pass action=none header.from=telefonica.com; dkim=pass header.d=telefonica.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telefonica.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SgeiYFPAXyYdyCryb0KQ21URFy9o1Sd1UzTc60Txc7I=; b=rVG61lFBCrG7lLdUlakJ+kpY+ePRl9WihxHKg9FjKvukBZrQjqmFwzU6J2gjxFbD/NCCndSneQ86CiIyjasR+6WekPaqYquRzBGgy+PJM+bzIpeLUcxxTLhDNI6YhTb5Vz+jvpT+ZNR/2hWzkcLv/V79/JKmtJJ5dNRufIWcJZg= Received: from AM6PR06MB5653.eurprd06.prod.outlook.com (20.178.93.90) by AM6PR06MB4567.eurprd06.prod.outlook.com (20.177.196.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.20; Wed, 29 Jan 2020 16:46:15 +0000 Received: from AM6PR06MB5653.eurprd06.prod.outlook.com ([fe80::4d14:ef4b:8837:87c5]) by AM6PR06MB5653.eurprd06.prod.outlook.com ([fe80::4d14:ef4b:8837:87c5%7]) with mapi id 15.20.2665.027; Wed, 29 Jan 2020 16:46:15 +0000 From: =?iso-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= To: "adrian@olddog.co.uk" , 'Benjamin Kaduk' , 'The IESG' CC: "draft-ietf-pce-gmpls-pcep-extensions@ietf.org" , "pce@ietf.org" , "pce-chairs@ietf.org" Thread-Topic: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-gmpls-pcep-extensions-15: (with COMMENT) Thread-Index: AQHVmbTRp2A7kjpQmUaBk93N2I68aae3HHKAgEs1gkCAAAG/0A== Date: Wed, 29 Jan 2020 16:46:15 +0000 Message-ID: References: <157360299209.31818.3432820168600441007.idtracker@ietfa.amsl.com> <080101d5b127$f0d48c80$d27da580$@olddog.co.uk> In-Reply-To: Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=oscar.gonzalezdedios@telefonica.com; x-originating-ip: [190.60.234.237] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 1ed6b669-0ecb-4821-1d7f-08d7a4dac1df x-ms-traffictypediagnostic: AM6PR06MB4567: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(39860400002)(376002)(346002)(136003)(366004)(189003)(199004)(9686003)(55016002)(786003)(316002)(54906003)(110136005)(4326008)(66446008)(26005)(76116006)(66556008)(186003)(52536014)(64756008)(5660300002)(66574012)(66476007)(66946007)(8676002)(6506007)(2940100002)(81156014)(8936002)(81166006)(7696005)(2906002)(33656002)(71200400001)(86362001)(478600001)(9010500006); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR06MB4567; H:AM6PR06MB5653.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8GHE7Glks24JGCvdk1ifWxUyBcyURrf/dfPwiQwA4DL5xt2wJhZ+0YGt4T/zCu0BVHw9Sze1CwkiJF2IRAPLTSc0Pu5OZ9D4dNPuAF61nfyu5vxBWrzUjxV2/uoRdgzbSq1OTZRSIeXxd6bU59Z3LDICIFN7L/ug3uOzGxIe1A3gb2WlO8Ef1VIGCvdcfTI6ruVmxJDM0+J7ooGdwbX+T++kI9qQdKi2k1ZjDgmiJ80Qd3+wnvjRfynsAT3Hra2C3AiElKKli4I7ltTkOJ7Vkbt95xS4AJtVDvBDMQ5994KOhqQ4Or1dQsYNBsfi/ZeHOHh2QrTYIdHrVnFDeBLhLpLHsZGJAKA7n0WoXA3VTH2vCUtJrWQKl4Z/+gjZcbKfwcheOa+0OnnlS3YlsjkO4WQeHrtsXhh6i5lPpQDVmQpvnC3s9tonPPFpbPqRxJBLAstTnYAdBfM4wu6lmTHTAeMS/dHbvijotcS0w+/1DPyFIKZkL9/sNdXutk/Gu4vw x-ms-exchange-antispam-messagedata: jBvn9CrlASnTR8SHnwv5P9REjQ9eAhzXLA/GMRrAjmBwp07RI/KyulUeP49UN9klwg/ZSMQkuaZ2swqptvfXfmgbgfR0NlZ6goJUPrltjIzAwpXCKBoUIDxe5PoSM9u+PtguapJKaoeBfMzRKbxRAA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1ed6b669-0ecb-4821-1d7f-08d7a4dac1df X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2020 16:46:15.7095 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: i4pv4aEnm1MdCyuKWgSCtRtJiueIGOgzs/1yIKnWEb3LxFX+7KZOYtBuTfKPKCa9wNwRfjz1ed+xcLGkW63+/nNxuCR6j696zoAXfj6DK1RMNogqp17pM+yLW0T61tfR X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR06MB4567 Archived-At: Subject: Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-gmpls-pcep-extensions-15: (with COMMENT) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 16:46:40 -0000 Forget about last email.. My computer started to get old emails... -----Mensaje original----- De: Oscar Gonz=E1lez de Dios Enviado el: mi=E9rcoles, 29 de enero de 2020 17:42 Para: adrian@olddog.co.uk; 'Benjamin Kaduk' ; 'The IESG' CC: draft-ietf-pce-gmpls-pcep-extensions@ietf.org; pce@ietf.org; pce-chairs= @ietf.org Asunto: RE: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-gmpls-pce= p-extensions-15: (with COMMENT) Hi Adrian, I can take care of posting (as one of the main editors). Minor thing, current posted version is -16, so I guess this one should be -= 17 right? Oscar -----Mensaje original----- De: Adrian Farrel Enviado el: jueves, 12 de diciembre= de 2019 21:09 Para: 'Benjamin Kaduk' ; 'The IESG' CC: draft-ietf-pce-gmpls-pcep-extensions@ietf.org; pce@ietf.org; pce-chairs= @ietf.org Asunto: RE: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-gmpls-pce= p-extensions-15: (with COMMENT) Hi Ben, In the absence of a response from the authors this last month, I'm jumping = in because I want to see this published. Authors/shepherd/chairs/AD: attached is an xml file that makes these change= s. I can't post it cos I'm not an author. Cheers, Adrian =3D=3D=3D > Thank you for addressing my Discuss points! Thanks for clearing. > I do have some additional comments on the -15. Perfect. I'm trying to answer them below. > Section 2.3 > > I'm still a bit concerned that the references linked from Table 4 may > not provide a clear description of what count as Traffic Parameters > for our purposes (and how they are encoded), but not in a way that I > can express more concretely. Perhaps this is made clear by some > RSVP-TE documents with which I am not familiar. Agree that it is pretty convoluted. But I just checked all of the reference= s and they are clear how to encode the traffic parameters for each of the d= ifferent technology types in RSVP-TE. And since the PCEP objects are direct= copies of the RSVP-TE ones, and since they are describing the same things,= I think we are safe. It's true that it's a lot of reading, but the PCE that supports one of thes= e bandwidth types must understand the technology as well as an RSVP-TE impl= ementation that signals one. I think we're OK on this point. > Section 2.5.1 > > root and other endpoints TLVs are the leaves. The root endpoint MUST > be the same for all END-POINTS objects. If the root endpoint is not > > I'm not sure how broadly scoped this restriction is -- it is, e.g., per-LSP? This is all in the scope of a single PCEP request message for a path. So, y= es, per LSP, but multiple END-POINT objects can be present on one request. So... OLD The root endpoint MUST be the same for all END-POINTS objects. NEW The root endpoint MUST be the same for all END-POINTS objects carried in a single PCEP request message. END > Section 2.5.2.5 > > with L bit cleared. At most 2 LABEL_SET TLVs MAY be present with the > O bit set, with at most one of these having the U bit set and at most > one of these having the U bit cleared. For a given U bit value, if > > This went MUST->MAY in this rev, though I think it might be fine to > just use > a lowercase "may", since the requirements language doesn't map > terribly well > to the restriction we're making. I would prefer to make this definitive. I think the language is all mixed a= round. How about we do: OLD At most 2 LABEL_SET TLVs MAY be present with the O bit set, with at most one of these having the U bit set and at most one of these having the U bit cleared. NEW There MUST NOT be more than two LABEL_SET TLVs present with the O bit set. If there are two LABEL_SET TLVs present, there MUST NOT be more than one with the U bit set, and there MUST NOT be more than one with the U bit cleared. END ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o From nobody Wed Jan 29 19:32:36 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07016120044 for ; Wed, 29 Jan 2020 19:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X_RtoaC7PFbv for ; Wed, 29 Jan 2020 19:32:33 -0800 (PST) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255020.outbound.protection.outlook.com [40.92.255.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA2F012003E for ; Wed, 29 Jan 2020 19:32:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fCqE/Yw8yU3VGWv+XmvePIRQJPKfeu5tGXNmU/jxF321KaZdvRLD6GfGEU3+ghsVpkfZY2u4Kf6HJX1RsH2Ex6dxOHLlSt81NzQsEL/xxLiu9zU5g9bpSN2Z6fa0EZ+DPl+Am5PkIE60PaRGBTVmk5o+IiBNsV2s5j8hXIuZBDz2QOQeWmSL/tlZIn5uhtniHFzf1ksvHJ/UoiXrV8NtAexpKG3f4CwvZhvlJLEto/bz7jJOgOuawRVdXpKPHZh5U4npcxV+HMeR7rCkGjwnyrB7j7GBcblelamawJIWNXcXzoGHmWDwJkU+9nWIdxGRDmmCkDbMhp4rLMzZJoqSFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VWIN7WbUYnfw1V8WumeU6rRTPObBSEAm23Eo/bqsvx8=; b=iZH/5ZYnk7KPFL/RvHAHF5lvMcpFR6oYLz+Mqd9KDZuET/BtVRVzCMejAmARi+IvJGZXwX74VbSjYeEQ5rJ3h1I36mUkKP4Xg/pubV14OnL5rhY3DyYUt+w8F/3OWF5WfZiHR1L2E1a8kkzIY57p5Jkd3GAEcaLXHMHAIujUMfF5/wTwoYMeDQcJwQj+yJ2rNAVaKyRp1dXnX31hw93LgYO5AZqGUd/ZMT6J/lYz+kDb01j22Ew9u3Ndv8H9OecDq0f6i0Sc6mlZa/QIPhAlxuSwVLdzVZS87wkXloSUBLRkyQF9j4ltY5YD5C6Da4nzO/N0O1WqMUIWGDaPFU8Ytw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hotmail.com; dmarc=pass action=none header.from=hotmail.com; dkim=pass header.d=hotmail.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VWIN7WbUYnfw1V8WumeU6rRTPObBSEAm23Eo/bqsvx8=; b=M8+vtfFIcciZksN0xowd3ZiHp82KEmy0y7wE1dcv8ey9/TIxOMHB/5rlkDqVHcRuhpqAmQhKXGkPzZWftyqZ4FIQjpVXdqrnm+MswzWhlCWCwk1709ikaL+nnI5mdean1/k/Os9L+a9POr/mxYjvxaS6Q2p0ZiEE5RWRjXBBusWQ0dVRcs6vYsOeJ/0QKN/ycKtif+H2T16qGwPvVsxX2Yg3XHw7OEHRrsTvA6PUusQ2PMQjDEDXLrtZtfOgnbvI5pTZybjc7H/fkUqzA6+N5EKQ66ubjR+x+2DQIHlU2un1lnCdk1UPd5uQ5+VOoH1fpRasFP0Sujqbn5GkEdK9Gw== Received: from PU1APC01FT058.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::33) by PU1APC01HT106.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::278) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.25; Thu, 30 Jan 2020 03:32:29 +0000 Received: from HK0PR03MB4066.apcprd03.prod.outlook.com (10.152.252.52) by PU1APC01FT058.mail.protection.outlook.com (10.152.253.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.25 via Frontend Transport; Thu, 30 Jan 2020 03:32:29 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:0A818781E2E7265116CD9180EAB32E945F93029301FFECE99CF1B6E8993F89D0; UpperCasedChecksum:DF4A0C003CE9C89B7C1E23C0C84FA89B7863C053271D773825252C4C6D6AA0AC; SizeAsReceived:8674; Count:49 Received: from HK0PR03MB4066.apcprd03.prod.outlook.com ([fe80::4c01:badc:eb0c:acd3]) by HK0PR03MB4066.apcprd03.prod.outlook.com ([fe80::4c01:badc:eb0c:acd3%6]) with mapi id 15.20.2686.025; Thu, 30 Jan 2020 03:32:29 +0000 Date: Thu, 30 Jan 2020 11:32:51 +0800 From: "li_zhenqiang@hotmail.com" To: "julien.meuric@orange.com" , "pce@ietf.org" References: X-Has-Attach: no X-Mailer: Foxmail 7.2.9.156[cn] Message-ID: Content-Type: multipart/alternative; boundary="----=_001_NextPart673813136827_=----" X-ClientProxiedBy: HK2PR04CA0090.apcprd04.prod.outlook.com (2603:1096:202:15::34) To HK0PR03MB4066.apcprd03.prod.outlook.com (2603:1096:203:9d::21) X-Microsoft-Original-Message-ID: <2020013011325040207618@hotmail.com> MIME-Version: 1.0 Received: from cmcc-PC (183.243.249.78) by HK2PR04CA0090.apcprd04.prod.outlook.com (2603:1096:202:15::34) with Microsoft SMTP Server (version=TLS1_1, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) id 15.20.2665.22 via Frontend Transport; Thu, 30 Jan 2020 03:32:28 +0000 X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.9.156[cn] X-Microsoft-Original-Message-ID: <2020013011325040207618@hotmail.com> X-TMN: [sBXGfsIJ0PX4d7YZifhFT8/l7rqlAVJs] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 49 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 679755c4-a355-4b02-16d7-08d7a5350836 X-MS-TrafficTypeDiagnostic: PU1APC01HT106: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: lv9vmxMfoeK+sKm9kHHNZf1b4H80uyRvldrtWW2HmMPVmv9wCYqvPlo9+Qt7wKtgAQsQU/7a4RPnwl9T177O62hYXdd5wgKb4dKJbyz5oMbhI2i1zN8a+m6gKIu3AX7BikO+pakOT4yeUgqjrYXspSeEBdtpyR+xyvKA2Oca5pdaCGUeCWZtF1eIQDeRdEpPJzAiqVhanz7MtLMgtyFKxNwQeJUE6p2dWvlf6W6U8Mg= X-MS-Exchange-AntiSpam-MessageData: 7fo6d+ge6RGjJvkz5RhoPHktG/DOH3NB0zS3rhoeBas3DZMYMRqPPAyl8doSIkbJLniWwStnXM2j1QJ7eBdxyoJw6cdha2vbxt2ChlmZB/4bFU8MEo57fhf9QeO9MlWrk3KUMGpfj1CTaniMEwhEKw== X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 679755c4-a355-4b02-16d7-08d7a5350836 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2020 03:32:29.0474 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT106 Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 03:32:35 -0000 ------=_001_NextPart673813136827_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 c3VwcG9ydCENCg0KQmVzdCBSZWdhcmRzLA0KWmhlbnFpYW5nIExpDQoNCg0KbGlfemhlbnFpYW5n QGhvdG1haWwuY29tDQogDQpGcm9tOiBqdWxpZW4ubWV1cmljQG9yYW5nZS5jb20NCkRhdGU6IDIw MjAtMDEtMTcgMTg6MTINClRvOiBwY2VAaWV0Zi5vcmcNClN1YmplY3Q6IFtQY2VdIEFkb3B0aW9u IG9mIGRyYWZ0LWxpLXBjZS1zci1iaWRpci1wYXRoLTA2Pw0KSGkgYWxsLA0KIA0KSXQgaXMgdGlt ZSB0byBzaGFyZSB5b3VyIHRob3VnaHRzIGFib3V0IGRyYWZ0LWxpLXBjZS1zci1iaWRpci1wYXRo LTA2Lg0KRG8geW91IGJlbGlldmUgdGhlIEktRCBpcyBhIHJpZ2h0IGZvdW5kYXRpb24gZm9yIGEg UENFIFdHIGl0ZW0/IFBsZWFzZQ0KdXNlIHRoZSBQQ0UgbWFpbGluZyBsaXN0IHRvIGV4cHJlc3Mg eW91ciBjb21tZW50cywgc3VwcG9ydCBvcg0KZGlzYWdyZWVtZW50LCBpbmNsdWRpbmcgYXBwbGlj YWJsZSByYXRpb25hbGUsIGVzcGVjaWFsbHkgZm9yIHRoZSBsYXR0ZXIuDQogDQpUaGFua3MsDQog DQpEaHJ1diAmIEp1bGllbg0KIA0KIA0KIA0KIA0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NClBjZSBtYWlsaW5nIGxpc3QNClBjZUBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY2UNCg== ------=_001_NextPart673813136827_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable body { line-height: 1.5; }blockquote { margin-top: 0px; margin-bottom:= 0px; margin-left: 0.5em; }body { font-size: 10.5pt; font-family: =E5=BE=AE= =E8=BD=AF=E9=9B=85=E9=BB=91; color: rgb(0, 0, 0); line-height: 1.5; }=0A=
support!
=0A=

Best Regards,
Zhenqiang Li
=0A=
li_zhenqiang@hotmail.com
=0A=
 
Date: 2020-01-17 18:12
Subject: [Pce] = Adoption of draft-li-pce-sr-bidir-path-06?
Hi al= l,
=0A=
 
=0A=
It is time to share your thoughts about draft-li-pce-sr-bidir-path-06.=
=0A=
Do you believe the I-D is a right foundation for a PCE WG item? Please=
=0A=
use the PCE mailing list to express your comments, support or
=0A=
disagreement, including applicable rationale, especially for the latte= r.
=0A=
 
=0A=
Thanks,
=0A=
 
=0A=
Dhruv & Julien
=0A=
 
=0A=
 
=0A=
 
=0A=
 
=0A=
_______________________________________________
=0A=
Pce mailing list
=0A=
Pce@ietf.org
=0A=
https://www.ietf.org/mailman/listinfo/pce
=0A=
=0A= = ------=_001_NextPart673813136827_=------ From nobody Thu Jan 30 08:07:18 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504C612016E for ; Thu, 30 Jan 2020 08:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, INVALID_MSGID=0.568, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UaMRZUFrq51 for ; Thu, 30 Jan 2020 08:07:14 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78FA91201DB for ; Thu, 30 Jan 2020 08:07:14 -0800 (PST) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 5C81F693A7295DBAB377 for ; Thu, 30 Jan 2020 16:07:12 +0000 (GMT) Received: from lhreml735-chm.china.huawei.com (10.201.108.86) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 30 Jan 2020 16:07:12 +0000 Received: from lhreml735-chm.china.huawei.com (10.201.108.86) by lhreml735-chm.china.huawei.com (10.201.108.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 30 Jan 2020 16:07:12 +0000 Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml735-chm.china.huawei.com (10.201.108.86) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Thu, 30 Jan 2020 16:07:11 +0000 Received: from DGGEMM532-MBX.china.huawei.com ([169.254.7.77]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0439.000; Fri, 31 Jan 2020 00:07:03 +0800 From: Lizhenbin To: Hariharan Ananthakrishnan CC: "Chengli (Cheng Li)" , Mach Chen , Weiqiang Cheng , "Dongjie (Jimmy)" , Rakesh Gandhi , xiong.quan , pce Thread-Topic: [Pce] IPR Poll on draft-li-pce-sr-bidir-path-06 Thread-Index: AQHVzWRmpQPQmEzWxEeyQXm3p8iLGaf4PlGAgAs1hdw= Date: Thu, 30 Jan 2020 16:07:03 +0000 Message-ID: 9909EAED-DF6A-431C-B956-85C620A0EFEA References: , In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_9909EAEDDF6A431CB95685C620A0EFEA_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pce] IPR Poll on draft-li-pce-sr-bidir-path-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 16:07:17 -0000 --_000_9909EAEDDF6A431CB95685C620A0EFEA_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIGV4Y2VwdCB0aGUgZGlzY2xvc2VkIG9uZS4NCg0K QmVzdCBSZWdhcmRzLA0KWmhlbmJpbihSb2JpbikNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCuadjuaMr+aWjCBMaSBaaGVuYmluDQpNb2JpbGU6 ICs4Ni0xMzY1MTAxNzc0NS8rOTY4LTkxNzk3MDY4DQpFbWFpbDogbGl6aGVuYmluQGh1YXdlaS5j b208bWFpbHRvOmxpemhlbmJpbkBodWF3ZWkuY29tPg0KDQrlj5Hku7bkurrvvJpSYWtlc2ggR2Fu ZGhpIDxyZ2FuZGhpLmlldGZAZ21haWwuY29tPg0K5pS25Lu25Lq677yaSGFyaWhhcmFuIEFuYW50 aGFrcmlzaG5hbiA8aGFyaT00MG5ldGZsaXguY29tQGRtYXJjLmlldGYub3JnPg0K5oqE4oCD6YCB 77yaQ2hlbmdsaSAoQ2hlbmcgTGkpIDxjaGVuZ2xpMTNAaHVhd2VpLmNvbT47TWFjaCBDaGVuIDxt YWNoLmNoZW5AaHVhd2VpLmNvbT47V2VpcWlhbmcgQ2hlbmcgPGNoZW5nd2VpcWlhbmdAY2hpbmFt b2JpbGUuY29tPjtMaXpoZW5iaW4gPGxpemhlbmJpbkBodWF3ZWkuY29tPjtEb25namllIChKaW1t eSkgPGppZS5kb25nQGh1YXdlaS5jb20+O1Jha2VzaCBHYW5kaGkgPHJnYW5kaGlAY2lzY28uY29t Pjt4aW9uZy5xdWFuIDx4aW9uZy5xdWFuQHp0ZS5jb20uY24+O3BjZSA8cGNlQGlldGYub3JnPg0K 5pe24oCD6Ze077yaMjAyMC0wMS0yNCAwNDo1NzowMA0K5Li74oCD6aKY77yaUmU6IFtQY2VdIElQ UiBQb2xsIG9uIGRyYWZ0LWxpLXBjZS1zci1iaWRpci1wYXRoLTA2DQoNCkhpIEhhcmksDQpJIGFt IGF3YXJlIG9mIGFuIElQUiBhcHBsaWNhYmxlIHRvIHRoaXMgZHJhZnQsIGFuZCBpdCBoYXMgYWxy ZWFkeSBiZWVuIGRpc2Nsb3NlZCB0byB0aGUgSUVURi4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvaXByLzM5NzgvDQoNClRoYW5rcywNClJha2VzaA0KDQoNCk9uIEZyaSwgSmFuIDE3LCAy MDIwIGF0IDE6MzIgUE0gSGFyaWhhcmFuIEFuYW50aGFrcmlzaG5hbiA8aGFyaT00MG5ldGZsaXgu Y29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MG5ldGZsaXguY29tQGRtYXJjLmlldGYub3JnPj4g d3JvdGU6DQoNCkhpIEF1dGhvcnMsDQoNCkluIHByZXBhcmF0aW9uIGZvciBXb3JraW5nIEdyb3Vw IGFkb3B0aW9uIG9uIHRoaXMgZHJhZnQsIEknZCBsaWtlIGFsbA0KYXV0aG9ycyBhbmQgY29udHJp YnV0b3JzIHRvIGNvbmZpcm0gb24gdGhlIGxpc3QgdGhhdCB0aGV5IGFyZSBpbiBjb21wbGlhbmNl DQp3aXRoIElFVEYgSVBSIHJ1bGVzLg0KDQpQbGVhc2UgcmVzcG9uZCAoY29weWluZyB0aGUgbWFp bGluZyBsaXN0KSB0byBzYXkgb25lIG9mOg0KDQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIGFw cGxpY2FibGUgdG8gdGhpcyBkcmFmdCB0aGF0IHNob3VsZCBiZSBkaXNjbG9zZWQNCmluIGFjY29y ZGFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcy4NCg0KSSBhbSBhd2FyZSBvZiBJUFIgYXBwbGljYWJs ZSB0byB0aGlzIGRyYWZ0LCBhbmQgaXQgaGFzIGFscmVhZHkgYmVlbg0KZGlzY2xvc2VkIHRvIHRo ZSBJRVRGLg0KDQpJIGFtIGF3YXJlIG9mIElQUiBhcHBsaWNhYmxlIHRvIHRoaXMgZHJhZnQsIGJ1 dCB0aGF0IGhhcyBub3QgeWV0IGJlZW4NCmRpc2Nsb3NlZCB0byB0aGUgSUVURi4gSSB3aWxsIHdv cmsgdG8gZW5zdXJlIHRoYXQgaXQgd2lsbCBiZSBkaXNjbG9zZWQgaW4gYQ0KdGltZWx5IG1hbm5l ci4NCg0KVGhhbmtzLA0KLSBIYXJpDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpQY2UgbWFpbGluZyBsaXN0DQpQY2VAaWV0Zi5vcmc8bWFpbHRvOlBj ZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQo= --_000_9909EAEDDF6A431CB95685C620A0EFEA_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHN0eWxlIHR5cGU9 InRleHQvY3NzIj4NCjwhLS0NCioNCgl7fQ0KYm9keQ0KCXtmb250LWZhbWlseTpDYWxpYnJpfQ0K LS0+DQo8L3N0eWxlPg0KPGRpdj48YnI+DQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIGV4Y2Vw dCB0aGUgZGlzY2xvc2VkIG9uZS48YnI+DQo8YnI+DQpCZXN0IFJlZ2FyZHMsPGJyPg0KWmhlbmJp bihSb2Jpbik8L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2Pg0KPHAgZGlyPSJsdHIiPi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0K5p2O5oyv5paM IExpIFpoZW5iaW48YnI+DQpNb2JpbGU6ICYjNDM7ODYtMTM2NTEwMTc3NDUvJiM0Mzs5NjgtOTE3 OTcwNjg8YnI+DQpFbWFpbDogPGEgaHJlZj0ibWFpbHRvOmxpemhlbmJpbkBodWF3ZWkuY29tIj5s aXpoZW5iaW5AaHVhd2VpLmNvbTwvYT48L3A+DQo8L2Rpdj4NCjxkaXYgbmFtZT0iQW55T2ZmaWNl LUJhY2tncm91bmQtSW1hZ2UiIHN0eWxlPSJib3JkZXItdG9wOjFweCBzb2xpZCAjQjVDNERGOyBw YWRkaW5nOjhweCI+DQo8ZGl2IHN0eWxlPSJ3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PGI+5Y+R5Lu2 5Lq677yaPC9iPlJha2VzaCBHYW5kaGkgJmx0O3JnYW5kaGkuaWV0ZkBnbWFpbC5jb20mZ3Q7PC9k aXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PGI+5pS25Lu25Lq677yaPC9i PkhhcmloYXJhbiBBbmFudGhha3Jpc2huYW4gJmx0O2hhcmk9NDBuZXRmbGl4LmNvbUBkbWFyYy5p ZXRmLm9yZyZndDs8L2Rpdj4NCjxkaXYgc3R5bGU9IndvcmQtYnJlYWs6YnJlYWstYWxsIj48Yj7m ioTigIPpgIHvvJo8L2I+Q2hlbmdsaSAoQ2hlbmcgTGkpICZsdDtjaGVuZ2xpMTNAaHVhd2VpLmNv bSZndDs7TWFjaCBDaGVuICZsdDttYWNoLmNoZW5AaHVhd2VpLmNvbSZndDs7V2VpcWlhbmcgQ2hl bmcgJmx0O2NoZW5nd2VpcWlhbmdAY2hpbmFtb2JpbGUuY29tJmd0OztMaXpoZW5iaW4gJmx0O2xp emhlbmJpbkBodWF3ZWkuY29tJmd0OztEb25namllIChKaW1teSkgJmx0O2ppZS5kb25nQGh1YXdl aS5jb20mZ3Q7O1Jha2VzaCBHYW5kaGkgJmx0O3JnYW5kaGlAY2lzY28uY29tJmd0Ozt4aW9uZy5x dWFuDQogJmx0O3hpb25nLnF1YW5AenRlLmNvbS5jbiZndDs7cGNlICZsdDtwY2VAaWV0Zi5vcmcm Z3Q7PC9kaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PGI+5pe24oCD6Ze0 77yaPC9iPjIwMjAtMDEtMjQgMDQ6NTc6MDA8L2Rpdj4NCjxkaXYgc3R5bGU9IndvcmQtYnJlYWs6 YnJlYWstYWxsIj48Yj7kuLvigIPpopjvvJo8L2I+UmU6IFtQY2VdIElQUiBQb2xsIG9uIGRyYWZ0 LWxpLXBjZS1zci1iaWRpci1wYXRoLTA2PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2PkhpIEhhcmksPC9kaXY+DQo8ZGl2PkkgYW0g YXdhcmUgb2YgYW4gSVBSIGFwcGxpY2FibGUgdG8gdGhpcyBkcmFmdCwgYW5kIGl0IGhhcyBhbHJl YWR5IGJlZW4gZGlzY2xvc2VkIHRvIHRoZSBJRVRGLjwvZGl2Pg0KPGRpdj48YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8zOTc4LyIgdGl0bGU9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvaXByLzM5NzgvIiBzdHlsZT0iZm9udC1zdHlsZTpub3JtYWw7IGZvbnQt d2VpZ2h0Om5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6bm9ybWFsOyB0ZXh0LWFsaWduOnN0YXJ0OyB0 ZXh0LWluZGVudDowcHg7IHRleHQtdHJhbnNmb3JtOm5vbmU7IHdoaXRlLXNwYWNlOm5vcm1hbDsg d29yZC1zcGFjaW5nOjBweCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMzk3OC88 L2E+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2PlJh a2VzaDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBGcmksIEphbiAxNywg MjAyMCBhdCAxOjMyIFBNIEhhcmloYXJhbiBBbmFudGhha3Jpc2huYW4gJmx0O2hhcmk9PGEgaHJl Zj0ibWFpbHRvOjQwbmV0ZmxpeC5jb21AZG1hcmMuaWV0Zi5vcmciPjQwbmV0ZmxpeC5jb21AZG1h cmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNz PSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxl ZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7IHBhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBk aXI9Imx0ciI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTp2ZXJkYW5hLHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTpzbWFsbCI+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcDsgbWFyZ2lu LXRvcDowcHg7IG1hcmdpbi1ib3R0b206MXJlbTsgb3ZlcmZsb3c6YXV0bzsgY29sb3I6cmdiKDMz LDM3LDQxKTsgd29yZC1icmVhazpub3JtYWw7IHBhZGRpbmc6MHB4Ij48Zm9udCBmYWNlPSJ2ZXJk YW5hLCBzYW5zLXNlcmlmIj5IaSBBdXRob3JzLA0KDQpJbiBwcmVwYXJhdGlvbiBmb3IgV29ya2lu ZyBHcm91cCBhZG9wdGlvbiBvbiB0aGlzIGRyYWZ0LCBJJ2QgbGlrZSBhbGwNCmF1dGhvcnMgYW5k IGNvbnRyaWJ1dG9ycyB0byBjb25maXJtIG9uIHRoZSBsaXN0IHRoYXQgdGhleSBhcmUgaW4gY29t cGxpYW5jZQ0Kd2l0aCBJRVRGIElQUiBydWxlcy4NCg0KUGxlYXNlIHJlc3BvbmQgKGNvcHlpbmcg dGhlIG1haWxpbmcgbGlzdCkgdG8gc2F5IG9uZSBvZjoNCg0KSSBhbSBub3QgYXdhcmUgb2YgYW55 IElQUiBhcHBsaWNhYmxlIHRvIHRoaXMgZHJhZnQgdGhhdCBzaG91bGQgYmUgZGlzY2xvc2VkDQpp biBhY2NvcmRhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMuDQoNCkkgYW0gYXdhcmUgb2YgSVBSIGFw cGxpY2FibGUgdG8gdGhpcyBkcmFmdCwgYW5kIGl0IGhhcyBhbHJlYWR5IGJlZW4NCmRpc2Nsb3Nl ZCB0byB0aGUgSUVURi4NCg0KSSBhbSBhd2FyZSBvZiBJUFIgYXBwbGljYWJsZSB0byB0aGlzIGRy YWZ0LCBidXQgdGhhdCBoYXMgbm90IHlldCBiZWVuDQpkaXNjbG9zZWQgdG8gdGhlIElFVEYuIEkg d2lsbCB3b3JrIHRvIGVuc3VyZSB0aGF0IGl0IHdpbGwgYmUgZGlzY2xvc2VkIGluIGENCnRpbWVs eSBtYW5uZXIuDQoNClRoYW5rcywNCi0gSGFyaTwvZm9udD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClBj ZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86UGNlQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+UGNlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcGNlIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZTwvYT48YnI+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9909EAEDDF6A431CB95685C620A0EFEA_-- From nobody Thu Jan 30 13:28:11 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D944F12001A; Thu, 30 Jan 2020 13:28:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-pce-stateful-flags@ietf.org, db3546@att.com, Hariharan Ananthakrishnan , hari@netflix.com, pce@ietf.org, pce-chairs@ietf.org, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <158041968488.10202.14894735320933923999.idtracker@ietfa.amsl.com> Date: Thu, 30 Jan 2020 13:28:04 -0800 Archived-At: Subject: [Pce] Protocol Action: 'Updated Rules for Processing Stateful PCE Request Parameters Flags' to Proposed Standard (draft-ietf-pce-stateful-flags-01.txt) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 21:28:05 -0000 The IESG has approved the following document: - 'Updated Rules for Processing Stateful PCE Request Parameters Flags' (draft-ietf-pce-stateful-flags-01.txt) as Proposed Standard This document is the product of the Path Computation Element Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-flags/ Technical Summary Extensions to the Path Computation Element communications Protocol (PCEP) to support stateful Path Computation Elements (PCEs) are defined in RFC 8231. One of the extensions is the Stateful PCE Request Parameters (SRP) object. That object includes a Flags field that is a set of 32 bit flags, and RFC 8281 defines an IANA registry for tracking assigned flags. However, RFC 8231 does not explain how an implementation should set unassigned flags in transmitted messages, nor how an implementation should process unassigned, unknown, or unsupported flags in received messages. This document updates RFC 8231 by defining the correct behaviors. Working Group Summary This I-D being a very focused and uncontroversial fix, it has been moved directly from individual draft to WGLC and submitted to the AD. Based on the direction from the AD, the file name was changed to reflect the WG output and to garner more visibility within the WG. Document Quality A private and unscientific poll of implementers of RFC 8231 conducted by the author suggests that existing implementations already abide by the modification set out in this document. Personnel Who is the Document Shepherd for this document? Hariharan Ananthakrishnan Who is the Responsible Area Director? Deborah Brungard From nobody Fri Jan 31 02:07:55 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6212A1200D6 for ; Fri, 31 Jan 2020 02:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gX2F6naW9z0 for ; Fri, 31 Jan 2020 02:06:24 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D8B120026 for ; Fri, 31 Jan 2020 02:06:24 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 67FCFF406F7; Fri, 31 Jan 2020 02:06:16 -0800 (PST) To: edward.crabbe@oracle.com, inaminei@google.com, jmedved@cisco.com, robert.varga@pantheon.tech, db3546@att.com, aretana.ietf@gmail.com, martin.vigoureux@nokia.com, dhruv.ietf@gmail.com, julien.meuric@orange.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: sburnwal@juniper.net, pce@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200131100616.67FCFF406F7@rfc-editor.org> Date: Fri, 31 Jan 2020 02:06:16 -0800 (PST) Archived-At: X-Mailman-Approved-At: Fri, 31 Jan 2020 02:07:55 -0800 Subject: [Pce] [Technical Errata Reported] RFC8231 (5970) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 10:06:25 -0000 The following errata report has been submitted for RFC8231, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5970 -------------------------------------- Type: Technical Reported by: Subham Burnwal Section: 8.5 Original Text ------------- 19 Invalid Operation Error-value 1: Attempted LSP Update Request for a non-delegated LSP. The PCEP-ERROR object is followed by the LSP object that identifies the LSP. Corrected Text -------------- 19 Invalid Operation Error-value 1: Attempted LSP Update Request for a non-delegated LSP. OR 19 Invalid Operation Error-value 1: Attempted LSP Update Request for a non-delegated LSP. The PCEP-ERROR object is followed by the SRP object. Notes ----- By referring RFC 8231 Section 6.3. The PCErr Message: LSP Object is not part of PCErr message so for Error Type:19, Error value:1 string need to be changed to either of the following. "Attempted LSP Update Request for a non-delegated LSP." OR "Attempted LSP Update Request for a non-delegated LSP. The PCEP-ERROR object is followed by the SRP object." Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8231 (draft-ietf-pce-stateful-pce-21) -------------------------------------- Title : Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE Publication Date : September 2017 Author(s) : E. Crabbe, I. Minei, J. Medved, R. Varga Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Jan 31 10:59:00 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4478120BBD; Fri, 31 Jan 2020 10:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIeFCS9lJ4_x; Fri, 31 Jan 2020 10:58:57 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01233120BA4; Fri, 31 Jan 2020 10:58:57 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E6DDAF4070F; Fri, 31 Jan 2020 10:58:48 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, pce@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20200131185848.E6DDAF4070F@rfc-editor.org> Date: Fri, 31 Jan 2020 10:58:48 -0800 (PST) Archived-At: Subject: [Pce] =?utf-8?q?RFC_8697_on_Path_Computation_Element_Communicati?= =?utf-8?q?on_Protocol_=28PCEP=29_Extensions_for_Establishing_Relationship?= =?utf-8?q?s_between_Sets_of_Label_Switched_Paths_=28LSPs=29?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 18:58:59 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8697 Title: Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs) Author: I. Minei, E. Crabbe, S. Sivabalan, H. Ananthakrishnan, D. Dhody, Y. Tanaka Status: Standards Track Stream: IETF Date: January 2020 Mailbox: inaminei@google.com, edward.crabbe@gmail.com, msiva@cisco.com, hari@netflix.com, dhruv.ietf@gmail.com, yosuke.tanaka@ntt.com Pages: 28 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pce-association-group-10.txt URL: https://www.rfc-editor.org/info/rfc8697 DOI: 10.17487/RFC8697 This document introduces a generic mechanism to create a grouping of Label Switched Paths (LSPs) in the context of a Path Computation Element (PCE). This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and it is equally applicable to the stateful PCE (active and passive modes) and the stateless PCE. This document is a product of the Path Computation Element Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Jan 31 13:06:08 2020 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C4D120020 for ; Fri, 31 Jan 2020 13:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSjIdNm0MkOh for ; Fri, 31 Jan 2020 13:06:05 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6654120041 for ; Fri, 31 Jan 2020 13:06:04 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id f25so8481436ljg.12 for ; Fri, 31 Jan 2020 13:06:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5VFnCaGJOwrjeJAbHumo7R6dUClYN2TSBPjTuX7eVQg=; b=SyKpQSX7RiNFDikhGrbBN0xV9lqkqLHl0P3lHTBQYUcpITWdZpC2ejPm6Gjzowkb42 AMWArxvSE3ShMN2NRcSY6hxbupJFMNxEcxSwyoCbYKX7s80P1jrnRh3IQk4SdLnW0ouT viy502xlCxCpekK0a4LHA36K8Edzt5YkR+ydlZ6JGDuydI0OpnCBCmfigzGG0PLEhujp 8V3fOPlMf+67qCIuApxQwrU6w3EIf3GZ7kxMMSssnHICYe46z3zYSeIf+mL5lh0bGUwV 9AAO1gmJ1Xu4rpySect5OM1Y9jesh/VKYF9Zamp7ZprPuFxwOC055r1pSZCZoGkHZXdp yCIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5VFnCaGJOwrjeJAbHumo7R6dUClYN2TSBPjTuX7eVQg=; b=tWUsnFmkU0XtOmvYhoML0p8bw/Y2ShRaXZz7WT8mnsnEYL3TvDDx1sPTyRgluxoDMH 84z/23sQ+fNxThJUpB+/FOwfrqF7VDJ2tCF44mVozxYwl/URg9RGeweaXBgQmvCq43rB 9cn318FwaRW+iZaUa4az9brrp0+/W6wFlIIXrJS61pK8tB0T/w6ii78vqd2+zfvqiRPF dZMTKzYCXyABBncPS+spndmYMv2WKgQi7m6EzQehNyBcslNVP3Pvt2bzyK9Uf1AFfJjI sJW7zDcKuLZkz8kro23z76Oi3yoKh/9YCr5T7Kf9mPC+j/FHQMBTpenZSzD/MdandSkS GkvQ== X-Gm-Message-State: APjAAAW2RqfAl3nX0nvawUhFZMycgNaBR8EmNokh34MRhB0SwLp3NHTc 6PHWjvA8HiSkfNa0+M2F5qdrBE1/y7sTtH1fuA== X-Google-Smtp-Source: APXvYqyOX752ydVsw5RJ8f77yrTkkZ+vPQDNgrBkscsbLh9Iw1xmzJi6WCec2oHYslfY8Is3NjqWkxrmmg0UriODxKQ= X-Received: by 2002:a2e:730e:: with SMTP id o14mr6444424ljc.51.1580504763119; Fri, 31 Jan 2020 13:06:03 -0800 (PST) MIME-Version: 1.0 References: <00b101d5cfc8$597ab340$0c7019c0$@olddog.co.uk> In-Reply-To: <00b101d5cfc8$597ab340$0c7019c0$@olddog.co.uk> From: Rakesh Gandhi Date: Fri, 31 Jan 2020 16:05:53 -0500 Message-ID: To: Farrel Adrian Cc: Julien Meuric , pce@ietf.org Content-Type: multipart/alternative; boundary="000000000000f8be5e059d75f0f5" Archived-At: Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 21:06:07 -0000 --000000000000f8be5e059d75f0f5 Content-Type: text/plain; charset="UTF-8" Thank you Adrian for the review comments. Please see inline with ... On Mon, Jan 20, 2020 at 2:32 PM Adrian Farrel wrote: > Hey Julien, WG, > > I have reviewed draft-li-pce-sr-bidir-path as part of the adoption poll > and I have a few comments below. > > Overall, this seems like a simple combination of two existing functions: > - associated bidirectional > - SR > So it should be straightforward and the function is clearly needed, and > the working group should adopt it if there is enough support. > > Thanks, > Adrian > > === > > Please (please, please) could author teams sort out their front page > author list before requesting WG adoption. If the authors don't reduce > themselves to a maximum of five, the chairs will have to do it, and I > don't think anyone wants that! > > --- > > Abstract > > This document defines PCEP extensions for grouping two reverse > unidirectional SR Paths into an Associated Bidirectional SR Path when > using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs as > well as when using a Stateless PCE. > > I don't think it is "two reverse unidirectional SR paths". One of them > is normal and the other is reverse. So how about... > > This document defines PCEP extensions for grouping two unidirectional > SR Paths (one in each direction in the network) into a single > Associated Bidirectional SR Path. The mechanisms defined in this > document can also be applied using a Stateful PCE for both PCE- > Initiated and PCC-Initiated LSPs, as well as when using a Stateless > PCE. > > --- > Ack. > Section 1 > > s/SR supports to steer packets/SR supports steering packets/ > > --- > Ack. > Section 1 > > Currently, SR networks only support unidirectional paths. However, > bidirectional SR Paths are required in some networks, for example, in > mobile backhaul transport networks. The requirement of bidirectional > SR Path is specified in [I-D.ietf-spring-mpls-path-segment]. > > I suggest... > > SR is specified for unidirectional paths. However, some applications > require bidirectional paths in SR networks, for example, in mobile > backhaul transport networks. The requirement for bidirectional > SR Paths is specified in [I-D.ietf-spring-mpls-path-segment]. > > --- > Section 1 > > OLD > [I-D.ietf-pce-association-bidir] defines PCEP extensions for grouping > two reverse unidirectional MPLS TE LSPs into an Associated > Bidirectional LSP when using a Stateful PCE for both PCE-Initiated > and PCC-Initiated LSPs as well as when using a Stateless PCE. > NEW > [I-D.ietf-pce-association-bidir] defines PCEP extensions for grouping > two unidirectional MPLS TE LSPs into an Associated Bidirectional LSP > when using a Stateful PCE for both PCE-Initiated and PCC-Initiated > LSPs as well as when using a Stateless PCE. > END > > --- > Ack. > 3.1 and 7.1 > > Why do you need a new Association Type? > If draft-ietf-pce-association-bidir was changes as: > OLD > Value Name Reference > --------------------------------------------------------------------- > TBD1 Single-sided Bidirectional LSP Association Group [This document] > TBD2 Double-sided Bidirectional LSP Association Group [This document] > NEW > Value Name Reference > --------------------------------------------------------------------- > TBD1 Single-sided Bidirectional Association Group [This document] > TBD2 Double-sided Bidirectional Association Group [This document] > END > ....then you could use the second of these for your use case. The type of > path being associated would/should be the same for both paths in the > association (but maybe there would be a future case with an LSP in one > direction and an SR path in the other direction? but see section 5.3) > and the type of path known from the PCEP message. > > --- > There was an email discussion on this topic on the list. Please see following threads. Please let us know if you have additional thoughts on this. https://mailarchive.ietf.org/arch/msg/pce/LnTR_PfHlNG4BRyKLvkQuGdAmbU https://mailarchive.ietf.org/arch/msg/pce/APYWjr7vzXsHkD9Sj3G6Y_cNYwg > > Section 5 > > The PCE SHOULD inform the reverse SR Paths to > the ingress PCCs and vice versa. > > Under what circumstance MAY the PCE choose to not do this? > > --- > OAM use-cases require reverse path but simple traffic steering use-case on co-routed path on two ingress nodes may not need to know the reverse SR path. Not sure if this SHOULD be MUST. > > 5.3 and 7.2 > > Depending on how you handle the point for 3.1, you may need to fine tune > this error code. One way approach might be to make a change to > draft-ietf-pce-association-bidir as: > OLD > Error Type Description Reference > ------------------------------------------------------------------- > 29 Association Error > > Error value: TBD2 This document > Bidirectional LSP Association - > Path Setup Type Mismatch > NEW > Error Type Description Reference > ------------------------------------------------------------------- > 29 Association Error > > Error value: TBD2 This document > Bidirectional Association - > Path Setup Type Mismatch > END > > --- > Ok, will change the names in draft-ietf-pce-association-bidir. > Having made the suggestions for 3.1 and 5.3, I wonder how much is > different from draft-ietf-pce-association-bidir. Is this just a small > explanation of the use of that draft in the SR network > > --- > > You should explicitly reference the figures (by name) from the text. > > --- > Ack. > Thanks for Section 6. I find it really helpful. > > --- > Thanks Adrian. Regards, Rakesh > -----Original Message----- > From: Pce On Behalf Of julien.meuric@orange.com > Sent: 17 January 2020 10:13 > To: pce@ietf.org > Subject: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? > > Hi all, > > It is time to share your thoughts about draft-li-pce-sr-bidir-path-06. > Do you believe the I-D is a right foundation for a PCE WG item? Please > use the PCE mailing list to express your comments, support or > disagreement, including applicable rationale, especially for the latter. > > Thanks, > > Dhruv & Julien > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --000000000000f8be5e059d75f0f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Adrian for the review comments. Please see = inline with <RG>...

On Mon, Jan 20, 2020 at 2:32 PM Adrian = Farrel <adrian@olddog.co.uk&g= t; wrote:
Hey Ju= lien, WG,

I have reviewed draft-li-pce-sr-bidir-path as part of the adoption poll
and I have a few comments below.

Overall, this seems like a simple combination of two existing functions: - associated bidirectional
- SR
So it should be straightforward and the function is clearly needed, and
the working group should adopt it if there is enough support.

Thanks,
Adrian

=3D=3D=3D

Please (please, please) could author teams sort out their front page
author list before requesting WG adoption. If the authors don't reduce<= br> themselves to a maximum of five, the chairs will have to do it, and I
don't think anyone wants that!

---

Abstract

=C2=A0 =C2=A0This document defines PCEP extensions for grouping two reverse=
=C2=A0 =C2=A0unidirectional SR Paths into an Associated Bidirectional SR Pa= th when
=C2=A0 =C2=A0using a Stateful PCE for both PCE-Initiated and PCC-Initiated = LSPs as
=C2=A0 =C2=A0well as when using a Stateless PCE.

I don't think it is "two reverse unidirectional SR paths". On= e of them
is normal and the other is reverse. So how about...

=C2=A0 =C2=A0This document defines PCEP extensions for grouping two unidire= ctional
=C2=A0 =C2=A0SR Paths (one in each direction in the network) into a single<= br> =C2=A0 =C2=A0Associated Bidirectional SR Path.=C2=A0 The mechanisms defined= in this
=C2=A0 =C2=A0document can also be applied using a Stateful PCE for both PCE= -
=C2=A0 =C2=A0Initiated and PCC-Initiated LSPs, as well as when using a Stat= eless
=C2=A0 =C2=A0PCE.

---

<RG> Ack.


Section 1

s/SR supports to steer packets/SR supports steering packets/

---

<RG> Ack.


Section 1

=C2=A0 =C2=A0Currently, SR networks only support unidirectional paths.=C2= =A0 However,
=C2=A0 =C2=A0bidirectional SR Paths are required in some networks, for exam= ple, in
=C2=A0 =C2=A0mobile backhaul transport networks.=C2=A0 The requirement of b= idirectional
=C2=A0 =C2=A0SR Path is specified in [I-D.ietf-spring-mpls-path-segment].
I suggest...

=C2=A0 =C2=A0SR is specified for unidirectional paths.=C2=A0 However, some = applications
=C2=A0 =C2=A0require bidirectional paths in SR networks, for example, in mo= bile
=C2=A0 =C2=A0backhaul transport networks.=C2=A0 The requirement for bidirec= tional
=C2=A0 =C2=A0SR Paths is specified in [I-D.ietf-spring-mpls-path-segment].<= br>
---

<RG. Ack.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Section 1

OLD
=C2=A0 =C2=A0[I-D.ietf-pce-association-bidir] defines PCEP extensions for g= rouping
=C2=A0 =C2=A0two reverse unidirectional MPLS TE LSPs into an Associated
=C2=A0 =C2=A0Bidirectional LSP when using a Stateful PCE for both PCE-Initi= ated
=C2=A0 =C2=A0and PCC-Initiated LSPs as well as when using a Stateless PCE.<= br> NEW
=C2=A0 =C2=A0[I-D.ietf-pce-association-bidir] defines PCEP extensions for g= rouping
=C2=A0 =C2=A0two unidirectional MPLS TE LSPs into an Associated Bidirection= al LSP
=C2=A0 =C2=A0when using a Stateful PCE for both PCE-Initiated and PCC-Initi= ated
=C2=A0 =C2=A0LSPs as well as when using a Stateless PCE.
END

---

<RG> Ack.


3.1 and 7.1

Why do you need a new Association Type?
If draft-ietf-pce-association-bidir was changes as:
OLD
=C2=A0 =C2=A0Value Name=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Reference
=C2=A0 =C2=A0--------------------------------------------------------------= -------
=C2=A0 =C2=A0TBD1 Single-sided Bidirectional LSP Association Group [This do= cument]
=C2=A0 =C2=A0TBD2 Double-sided Bidirectional LSP Association Group [This do= cument]
NEW
=C2=A0 =C2=A0Value Name=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Reference
=C2=A0 =C2=A0--------------------------------------------------------------= -------
=C2=A0 =C2=A0TBD1 Single-sided Bidirectional Association Group [This docume= nt]
=C2=A0 =C2=A0TBD2 Double-sided Bidirectional Association Group [This docume= nt]
END
....then you could use the second of these for your use case. The type of path being associated would/should be the same for both paths in the
association (but maybe there would be a future case with an LSP in one
direction and an SR path in the other direction? but see section 5.3)
and the type of path known from the PCEP message.

---

<RG> There was an email discu= ssion on this topic on the list. Please see following threads. Please let u= s know if you have additional thoughts on this.

https://mailarchive.ietf.org/arch/msg/pce/LnTR_PfHlNG4BRyKLvkQuGdA= mbU


=C2=A0

Section 5

=C2=A0 =C2=A0The PCE SHOULD inform the reverse SR Paths to
=C2=A0 =C2=A0the ingress PCCs and vice versa.

Under what circumstance MAY the PCE choose to not do this?

---

<RG> OAM use-cases require re= verse path but simple traffic steering use-case on co-routed path on two in= gress nodes may not need to know the reverse SR path. Not sure if this SHOU= LD be MUST.
=C2=A0

5.3 and 7.2

Depending on how you handle the point for 3.1, you may need to fine tune this error code.=C2=A0 One way approach might be to make a change to
draft-ietf-pce-association-bidir as:
OLD
=C2=A0 =C2=A0Error Type=C2=A0 Description=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Refe= rence
=C2=A0 =C2=A0--------------------------------------------------------------= -----
=C2=A0 =C2=A0 29=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Association Error

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Error value: TBD2=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 This document
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Bidirectional LSP As= sociation -
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Path Setup Type Mism= atch
NEW
=C2=A0 =C2=A0Error Type=C2=A0 Description=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Refe= rence
=C2=A0 =C2=A0--------------------------------------------------------------= -----
=C2=A0 =C2=A0 29=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Association Error

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Error value: TBD2=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 This document
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Bidirectional Associ= ation -
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Path Setup Type Mism= atch
END

---

<RG> Ok, will change the name= s in draft-ietf-pce-association-bidir.


Having made the suggestions for 3.1 and 5.3, I wonder how much is
different from draft-ietf-pce-association-bidir. Is this just a small
explanation of the use of that draft in the SR network

---

You should explicitly reference the figures (by name) from the text.

---
<RG> Ack.


Thanks for Section 6. I find it really helpful.

---

<RG> Thanks Adrian.

Regards,
Rakesh



-----Original Message-----
From: Pce <pce= -bounces@ietf.org> On Behalf Of julien.meuric@orange.com
Sent: 17 January 2020 10:13
To: pce@ietf.org
Subject: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?

Hi all,

It is time to share your thoughts about draft-li-pce-sr-bidir-path-06.
Do you believe the I-D is a right foundation for a PCE WG item? Please
use the PCE mailing list to express your comments, support or
disagreement, including applicable rationale, especially for the latter.
Thanks,

Dhruv & Julien



_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
--000000000000f8be5e059d75f0f5--