From nobody Fri Mar 1 06:55:11 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6378C130E90; Fri, 1 Mar 2019 06:55:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mpls@ietf.org Message-ID: <155145210436.6135.5550493800692077977@ietfa.amsl.com> Date: Fri, 01 Mar 2019 06:55:04 -0800 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-sfc-encapsulation-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 14:55:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching WG of the IETF. Title : MPLS Transport Encapsulation For The SFC NSH Authors : Andrew G. Malis Stewart Bryant Joel M. Halpern Wim Henderickx Filename : draft-ietf-mpls-sfc-encapsulation-03.txt Pages : 9 Date : 2019-03-01 Abstract: This document describes how to use a Service Function Forwarder (SFF) Label (similar to a pseudowire label or VPN label) to indicate the presence of a Service Function Chaining (SFC) Network Service Header (NSH) between an MPLS label stack and the packet original packet/ frame. This allows SFC packets using the NSH to be forwarded between SFFs over an MPLS network, and to select one of multiple SFFs in the destination MPLS node. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-sfc-encapsulation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mpls-sfc-encapsulation-03 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-sfc-encapsulation-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-sfc-encapsulation-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 1 06:57:12 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E396130E9D for ; Fri, 1 Mar 2019 06:57:10 -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_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 u6PErC0TQ24u for ; Fri, 1 Mar 2019 06:57:07 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 5B50F130E90 for ; Fri, 1 Mar 2019 06:57:07 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id v139so14390554qkb.12 for ; Fri, 01 Mar 2019 06:57: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=U9v8Jgnsz4dXPfn79CvysYJOxj0lqn+8uym0ILUO6yM=; b=QX276fOXeon2+5+o56HRQLD/MwPnDu1KOg+D+aRjtptrQ2+x6KKy4ZgCOuaTmOK1bV YIcsor2rYI775Br45kvYOAIXAeh5r/D+tuy9xJ0MTZbMDMPOHKwPgV21rxu9fy7gYv5H V/yt3/dcPEe4Qt7oxBv4+Y2oZQolnNFBSktfpD4raotoc0Q2C+DYKu+8LHXk6Tj+Xor7 hwXuWnEGEg39DHEOtopKiCS/wIJ0tn9Uko1VuUupV+SUqqc8U9nhBkmWrf94pQrLrfEv WLOlEWyy/YhbHdR51PcTyW/CLR8jE73VkizBoj3eheatY+UQKVVfC98SBR7mzny+YdXV uRGA== 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=U9v8Jgnsz4dXPfn79CvysYJOxj0lqn+8uym0ILUO6yM=; b=t4pscUUBPJWD6Rx+yfhg6g33Y+0tfxGlMjabw5LOefMNx9rIqXYT5QZZo0OwvkgoE2 8aKG38xXhZjzp+MueqcQ/YSr/ZMsb/v94CQBqBFvlzZgeMUo6MQA3nbZCn25gSc4A5qd qVAmA6yZjASpGN3Yy8XYiPv2p+tGNCfyH5JFHHO1T0HK6YooJ0OyVoiOJ2Gbv25TfBgu he+C8zyWoM+/eAc7vHQw+q2QEpjGIVFdqyN+3RXbo4bA48Lm7JpF/FwXLN79sChhpj6P +XvmECCFCe6P/QiIg+A0pLG8g82/fpVegwnKLXJlk433EhDruzXC4o7e1AKHzw9vX+SS rVZQ== X-Gm-Message-State: APjAAAUymrlzKoIEUlajDNjOhUaWKJmqA7nmAcHuCNVO8Z2Z5HHVHQ7i VJkQlrf26JNA1sjhjWOFD5ZWqPdL8d2/HTnJ8fMtcIGk X-Google-Smtp-Source: APXvYqybGGX9OEyjYA1oCECjQUGIphTDpF6l5YjPYkINN3UMd/K3ITbIXzmwR/xtwEVWF9dgAX8x/KhordiY4DmLw3Y= X-Received: by 2002:ae9:c308:: with SMTP id n8mr4013343qkg.10.1551452225855; Fri, 01 Mar 2019 06:57:05 -0800 (PST) MIME-Version: 1.0 References: <155145210436.6135.5550493800692077977@ietfa.amsl.com> In-Reply-To: <155145210436.6135.5550493800692077977@ietfa.amsl.com> From: "Andrew G. Malis" Date: Fri, 1 Mar 2019 09:56:54 -0500 Message-ID: To: mpls Content-Type: multipart/alternative; boundary="000000000000cee72d0583099ec6" Archived-At: Subject: [mpls] Fwd: I-D Action: draft-ietf-mpls-sfc-encapsulation-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 14:57:11 -0000 --000000000000cee72d0583099ec6 Content-Type: text/plain; charset="UTF-8" This revision incorporates all comments received during IETF last call. Cheers, Andy ---------- Forwarded message --------- From: Date: Fri, Mar 1, 2019 at 9:55 AM Subject: I-D Action: draft-ietf-mpls-sfc-encapsulation-03.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching WG of the IETF. Title : MPLS Transport Encapsulation For The SFC NSH Authors : Andrew G. Malis Stewart Bryant Joel M. Halpern Wim Henderickx Filename : draft-ietf-mpls-sfc-encapsulation-03.txt Pages : 9 Date : 2019-03-01 Abstract: This document describes how to use a Service Function Forwarder (SFF) Label (similar to a pseudowire label or VPN label) to indicate the presence of a Service Function Chaining (SFC) Network Service Header (NSH) between an MPLS label stack and the packet original packet/ frame. This allows SFC packets using the NSH to be forwarded between SFFs over an MPLS network, and to select one of multiple SFFs in the destination MPLS node. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-sfc-encapsulation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mpls-sfc-encapsulation-03 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-sfc-encapsulation-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-sfc-encapsulation-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/ _______________________________________________ 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 --000000000000cee72d0583099ec6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This revision incorporates all comments received during IE= TF last call.

Cheers,
Andy

---------- Forwarded= message ---------
From: <internet-drafts@ietf.org>
Date: Fri, Ma= r 1, 2019 at 9:55 AM
Subject: I-D Action: draft-ietf-mpls-sfc-encapsulat= ion-03.txt
To: <i-d-announce= @ietf.org>
Cc: <mpls@ietf.org= >



A New Internet-Draft is available from the on= -line Internet-Drafts directories.
This draft is a work item of the Mult= iprotocol Label Switching WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: MPLS Transport Encapsulation For The SFC NSH
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Andrew G. Malis
=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 Stewart Bryant
=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 Joel M. Halpern
=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 Wim Henderickx
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 = =C2=A0 =C2=A0 : draft-ietf-mpls-sfc-encapsulation-03.txt
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 9
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2019-0= 3-01

Abstract:
=C2=A0 =C2=A0This document describes how to use a Service = Function Forwarder (SFF)
=C2=A0 =C2=A0Label (similar to a pseudowire lab= el or VPN label) to indicate the
=C2=A0 =C2=A0presence of a Service Func= tion Chaining (SFC) Network Service Header
=C2=A0 =C2=A0(NSH) between an= MPLS label stack and the packet original packet/
=C2=A0 =C2=A0frame.=C2= =A0 This allows SFC packets using the NSH to be forwarded between
=C2=A0= =C2=A0SFFs over an MPLS network, and to select one of multiple SFFs in the=
=C2=A0 =C2=A0destination MPLS node.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/= draft-ietf-mpls-sfc-encapsulation/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ie= tf-mpls-sfc-encapsulation-03
https://datatracker.ietf.o= rg/doc/html/draft-ietf-mpls-sfc-encapsulation-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff= ?url2=3Ddraft-ietf-mpls-sfc-encapsulation-03


Please note that it may take a couple of minutes from the time of submi= ssion
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@iet= f.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
--000000000000cee72d0583099ec6-- From nobody Fri Mar 1 13:15:04 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E22131168; Fri, 1 Mar 2019 13:10:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: mpls@ietf.org, db3546@att.com X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155147460820.6101.4638243194737980947.idtracker@ietfa.amsl.com> Date: Fri, 01 Mar 2019 13:10:08 -0800 Archived-At: Subject: [mpls] mpls - Requested session has been scheduled for IETF 104 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 21:10:21 -0000 Dear Tarek Saad, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. mpls Session 1 (2:00 requested) Wednesday, 27 March 2019, Morning Session II 1120-1320 Room Name: Congress Hall 1 size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/104/sessions/mpls.ics Request Information: --------------------------------------------------------- Working Group Name: Multiprotocol Label Switching Area Name: Routing Area Session Requester: Tarek Saad Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: detnet bier pals idr bfd bess spring pce ccamp teas sfc Second Priority: lsr lsvr rtgwg rtgarea i2rs nvo3 People who must be present: Tarek Saad Nicolai Leymann Deborah Brungard Loa Andersson Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Mar 2 12:09:36 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D27124C04; Sat, 2 Mar 2019 12:09:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mpls@ietf.org Message-ID: <155155736768.27158.1653954565392604255@ietfa.amsl.com> Date: Sat, 02 Mar 2019 12:09:27 -0800 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-static-yang-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2019 20:09:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching WG of the IETF. Title : A YANG Data Model for MPLS Static LSPs Authors : Tarek Saad Rakesh Gandhi Xufeng Liu Vishnu Pavan Beeram Igor Bryskin Filename : draft-ietf-mpls-static-yang-08.txt Pages : 18 Date : 2019-03-02 Abstract: This document contains the specification for the MPLS Static Label Switched Paths (LSPs) YANG model. The model allows for the provisioning of static LSP(s) on Label Edge Router(s) LER(s) and Label Switched Router(s) LSR(s) devices along a LSP path without the dependency on any signaling protocol. The MPLS Static LSP model augments the MPLS base YANG model with specific data to configure and manage MPLS Static LSP(s). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-static-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mpls-static-yang-08 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-static-yang-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-static-yang-08 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 Sat Mar 2 12:37:27 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C177130EEF; Sat, 2 Mar 2019 12:37:21 -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_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 mFVqDoxJIaC7; Sat, 2 Mar 2019 12:37:18 -0800 (PST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 6EB7B130EA2; Sat, 2 Mar 2019 12:37:18 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id x9so796341qkf.0; Sat, 02 Mar 2019 12:37:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=35ip6Q0+us5ENxnZtXAxAuCoXt8MaDdJQSAmkPs+4Ls=; b=blj4bYiSmrrEMcq80ZHh4yZfKzBiVdCqlAnjoc57jqYCCht4E5mAGZer9wHIYp7Wb9 alftI/KyO/QX+knbyVpCZIguHIArNCGFoK3dRok3M6TNzLfb+lgxzcSTMzxVPOMeNSfk xzwDsEWujuH79k2X7J8JuuUa+nyMVrvgRAUnzRKasJ3rBLTRUNz8slPcUTTPAMxizE0w wDiqdNoaFXW2eoeWdKhqVTWf3IXdmIaUe5BsO8el8EJsh2wtHuhcSF4OBkkLlxj81Rsm y7Xm5d9oFqH8YrOQ441KKRyV/Ebg8jXoIzp1me+/Jj7AbHzmyx369t2FUqDSmWdv8uDz 3NCw== 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=35ip6Q0+us5ENxnZtXAxAuCoXt8MaDdJQSAmkPs+4Ls=; b=o3GDDKyveGwsxwEgJFSsjuGE5rOyEnhES+g3cVQFQuUwV7lov+C2tjhwuPNm820UVI FRIqKXNR/T+Tu2FiCqnkwtcqDhDTXT6gq7AjrNi7GL2lij7rWNvJ6+2kxOH9+ZhvWKEx k0bN1e768m7xECFFPuqD68q0zXkqIP3dl05picQxoOLmNnoOvrn1oypWx5Guz8UVWftI xxx0SAsej4v6HZ5Pufo6A91VGd7TOrr5CqjX22yz7kp25KRfFkSTi7CYhlx3DxMw5t67 DGeVeSf+BUxq+k+lWUC8AGShNZmgc0D0BfI2vta9ccA7Knxwk9Iead3iv5g3YKJIGoCc F6RQ== X-Gm-Message-State: APjAAAVB3tnlGALpsx0y7F1LUvLGn9r1pXg/xS9V8t5P8ekJnQT9GKM0 OkG1B7+Z2xsfbObHpKjTu8XK/THyEwkx+iI8ap2eHFgw X-Google-Smtp-Source: APXvYqx2c7FEgS+lwU4ELrEwXK1tuiAEZfW2OjciZYPhh1cDJOmrLfzfzcqIkjcEUsQCplKG2JSZNJbQDg754ZeIwic= X-Received: by 2002:a37:a783:: with SMTP id q125mr8381993qke.264.1551559037133; Sat, 02 Mar 2019 12:37:17 -0800 (PST) MIME-Version: 1.0 From: Tarek Saad Date: Sat, 2 Mar 2019 15:37:06 -0500 Message-ID: To: mpls@ietf.org Cc: mpls-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000041a67a0583227d43" Archived-At: Subject: [mpls] MPLS agenda requests for IETF 104 in Prague X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2019 20:37:25 -0000 --00000000000041a67a0583227d43 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, We are building the MPLS WG session=E2=80=99s agenda for IETF104 in Prague.= The preliminary agenda is available at: https://datatracker.ietf.org/meeting/104/agenda.html The MPLS WG session is scheduled for the session below: Wednesday, March 27, 2019 (CET) 11:20-13:20 - Wednesday Morning session II Please send slot requests for presenting at the MPLS session copying myself and the WG chairs - indicate draft name, speaker and desired duration. If presenting, your slides will be due by Friday March 22. Please send slides to myself and the WG chairs. A reminder to authors/editors of WG drafts that will not be discussed/presented at IET104 to send a status report to the WG list by Friday March 22 so it can be included in the MPLS WG progress report. *Important dates:* 2019-03-01 (Friday): Final agenda to be published. 2019-03-11 (Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59. Upload using the ID Submission Tool. 2019-03-11 (Monday): Standard rate registration and payment cut-off at UTC 23:59.. 2019-03-13 (Wednesday): Draft Working Group agendas due by UTC 23:59. Upload using the Meeting Materials Management Tool. 2019-03-18 (Monday): Registration cancellation cut-off at UTC 23:59. 2019-03-18 (Monday): Revised Working Group agendas due by UTC 23:59. Upload using the Meeting Materials Management Tool. 2019-04-19 (Friday): Proceedings submission cutoff date by UTC 23:59. Upload using the Meeting Materials Management Tool. 2019-05-13 (Monday): Proceedings submission corrections cutoff date by UTC 23:59. Regards, Tarek and MPLS WG chairs --00000000000041a67a0583227d43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,=

We are building the MPLS WG session=E2=80=99s agenda for IETF104 in= Prague. The preliminary agenda is available at:
https://datatracker.ietf.org/meet= ing/104/agenda.html

The MPLS WG session is scheduled for the se= ssion below:
Wednesday, March 27, 2019 (CET)=C2=A011:20-13:20 - Wed= nesday Morning session II

Please send slot requests for presenting= at the MPLS session copying myself and the WG chairs - indicate draft name= , speaker and desired duration.
If presenting, your slides will be due b= y Friday March 22. Please send slides to myself and the WG chairs.

A= reminder to authors/editors of WG drafts that will not be discussed/presen= ted at IET104 to send a status report to the WG list by Friday March 22 so = it can be included in the MPLS WG progress report.

Important date= s:
2019-03-01 (Friday): Final agenda to be published.
2019-03-11 (Monday): Internet Draft submission cut-off (for all drafts, in= cluding -00) by UTC 23:59. Upload using the ID Submission Tool.
2= 019-03-11 (Monday): Standard rate registration and payment cut-off at UTC 2= 3:59..
2019-03-13 (Wednesday): Draft Working Group agendas due by= UTC 23:59. Upload using the Meeting Materials Management Tool.
2= 019-03-18 (Monday): Registration cancellation cut-off at UTC 23:59.
2019-03-18 (Monday): Revised Working Group agendas due by UTC 23:59. Upl= oad using the Meeting Materials Management Tool.
2019-04-19 (Frid= ay): Proceedings submission cutoff date by UTC 23:59. Upload using the Meet= ing Materials Management Tool.
2019-05-13 (Monday): Proceedings s= ubmission corrections cutoff date by UTC 23:59.

Regards= ,
Tarek and MPLS WG chairs
--00000000000041a67a0583227d43-- From nobody Sun Mar 3 11:05:16 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B5BE7130DE7; Sun, 3 Mar 2019 11:05:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mpls@ietf.org Message-ID: <155163991368.829.8678064973275400818@ietfa.amsl.com> Date: Sun, 03 Mar 2019 11:05:13 -0800 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-sr-over-ip-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2019 19:05:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching WG of the IETF. Title : SR-MPLS over IP Authors : Xiaohu Xu Stewart Bryant Adrian Farrel Syed Hassan Wim Henderickx Zhenbin Li Filename : draft-ietf-mpls-sr-over-ip-03.txt Pages : 16 Date : 2019-03-03 Abstract: MPLS Segment Routing (SR-MPLS) is an MPLS data plane-based source routing paradigm in which the sender of a packet is allowed to partially or completely specify the route the packet takes through the network by imposing stacked MPLS labels on the packet. SR-MPLS could be leveraged to realize a source routing mechanism across MPLS, IPv4, and IPv6 data planes by using an MPLS label stack as a source routing instruction set while preserving backward compatibility with SR-MPLS. This document describes how SR-MPLS capable routers and IP-only routers can seamlessly co-exist and interoperate through the use of SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-in- UDP as defined in RFC 7510. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-sr-over-ip/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mpls-sr-over-ip-03 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-sr-over-ip-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-sr-over-ip-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 3 11:42:20 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE96130DE9 for ; Sun, 3 Mar 2019 11:42:18 -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] 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 q-r8UEYFiYyM for ; Sun, 3 Mar 2019 11:42:15 -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 0F172130DE7 for ; Sun, 3 Mar 2019 11:42:14 -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 x23JgCWs006450 for ; Sun, 3 Mar 2019 19:42:12 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A0DF42203B for ; Sun, 3 Mar 2019 19:42:11 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id 8BE472203A for ; Sun, 3 Mar 2019 19:42:11 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id x23Jg9nN032611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 3 Mar 2019 19:42:11 GMT Reply-To: From: "Adrian Farrel" To: References: <155163991368.829.8678064973275400818@ietfa.amsl.com> In-Reply-To: <155163991368.829.8678064973275400818@ietfa.amsl.com> Date: Sun, 3 Mar 2019 19:42:08 -0000 Organization: Old Dog Consulting Message-ID: <0a0701d4d1f9$311700c0$93450240$@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: AQJ+UOQcv11md9ld1R17Pv7ozWXXAKSnTKxg Content-Language: en-gb X-Originating-IP: 87.112.237.8 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-24468.002 X-TM-AS-Result: No--4.428-10.0-31-10 X-imss-scan-details: No--4.428-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24468.002 X-TMASE-Result: 10--4.427900-10.000000 X-TMASE-MatchedRID: 6lay9u8oTUPxIbpQ8BhdbEBylsUaLJ7sA9UhA/EMrwPFJnEpmt9OE39M UW3noMgmepYdDkfIivrQ6avGafooztzH3tllVlwyb/5HBZ6dvRghotH7bEpEMqvM+zzl/BSTROz dcn4CHIvnjmT3vqmhOfGxLQyk54v7zCsOCBxDp3W4jAucHcCqnVF5adRR2Ej12dP9ypSe+feK61 Q63RemBLy+K0fDzPdzpw2+/nDPnnH2v8tc+AA4/mtGlKM15tA2lnrMq7Sriu1rEoFtNYg0C5Xed LakhtIrqIGy3LUo/P/ZA97+E8FEEnstocCIqrwTnJ5tL+LbGOOFKXsoBdprwmjliw+xvItdahP/ 1jRJ6pzp1b7KiZSVPg5gsVv7cmyxDyszNV8ahX2puD25aEtgt3WT6A/Vdqa0myiLZetSf8nJ4y0 wP1A6AJy/CPd12p6Jh9eWnlL1x8DdB/CxWTRRu/558CedkGIvzP4Frv6e/e5eT6zcJPzj/RAY9G cAHRLW8vmJflyQmOMMKRrNRhHlBn7cGd19dSFd X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] I-D Action: draft-ietf-mpls-sr-over-ip-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2019 19:42:19 -0000 Hi, This version catches the reviews during IETF last call. Thanks to Andy Malis, Robert Sparks, and Al Morton. Changes are mainly minor editorial. In a few places, descriptive text has been changed from lower case to use normative language. This does not make any change to the technical content, but makes more clear how implementations must behave. Adrian -----Original Message----- From: mpls On Behalf Of internet-drafts@ietf.org Sent: 03 March 2019 19:05 To: i-d-announce@ietf.org Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-sr-over-ip-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching WG of the IETF. Title : SR-MPLS over IP Authors : Xiaohu Xu Stewart Bryant Adrian Farrel Syed Hassan Wim Henderickx Zhenbin Li Filename : draft-ietf-mpls-sr-over-ip-03.txt Pages : 16 Date : 2019-03-03 Abstract: MPLS Segment Routing (SR-MPLS) is an MPLS data plane-based source routing paradigm in which the sender of a packet is allowed to partially or completely specify the route the packet takes through the network by imposing stacked MPLS labels on the packet. SR-MPLS could be leveraged to realize a source routing mechanism across MPLS, IPv4, and IPv6 data planes by using an MPLS label stack as a source routing instruction set while preserving backward compatibility with SR-MPLS. This document describes how SR-MPLS capable routers and IP-only routers can seamlessly co-exist and interoperate through the use of SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-in- UDP as defined in RFC 7510. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-sr-over-ip/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mpls-sr-over-ip-03 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-sr-over-ip-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-sr-over-ip-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/ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Mon Mar 4 13:02:47 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD4E1294FA; Mon, 4 Mar 2019 13:02:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-mpls-sfc@ietf.org, Loa Andersson , mpls-chairs@ietf.org, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155173336630.5245.15422916059733100748.idtracker@ietfa.amsl.com> Date: Mon, 04 Mar 2019 13:02:46 -0800 Archived-At: Subject: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-sfc-05: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 21:02:47 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-mpls-sfc-05: 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-mpls-sfc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for a very clear document! I think that the only NSH functionality not included in this document is the O bit (OAM packet). I know that, even in rfc8300, the operation (beyond setting the bit) is not defined...and that work is still in progress in the SFC WG. However, given that this document describes a "logical representation of the NSH", I think it is necessary to point out why the coverage is not complete. In looking through the mail archive, I like the thoughts posted by one of the authors [1] and would like to see something like that reflected in the document. [1] https://mailarchive.ietf.org/arch/msg/mpls/b9Duw-9ShdCrIRyis3TOJWw-_pw nits: s/(as described in Section 4.1/(as described in Section 4.1) s/(see [I-D.ietf-bess-nsh-bgp-control-plane]/(see [I-D.ietf-bess-nsh-bgp-control-plane]) s/TC: The TC bits have no meaning./TC: The TC bits have no meaning in this case. s/to determine to which SFF or instance of an SF (an SFI) to deliver the packet./to determine which SFF or instance of an SF (an SFI) to deliver the packet to. From nobody Mon Mar 4 13:46:14 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C22A1310EE; Mon, 4 Mar 2019 13:46:12 -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, 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 nsR5B0NFcpVb; Mon, 4 Mar 2019 13:46:09 -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 64D7513110E; Mon, 4 Mar 2019 13:46:09 -0800 (PST) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id x24Lk6LM016919; Mon, 4 Mar 2019 21:46:06 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 58E5522044; Mon, 4 Mar 2019 21:46:06 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id 435D922042; Mon, 4 Mar 2019 21:46:06 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id x24Lk5hk021646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 Mar 2019 21:46:05 GMT Reply-To: From: "Adrian Farrel" To: "'Alvaro Retana'" , "'The IESG'" Cc: , "'Loa Andersson'" , , References: <155173336630.5245.15422916059733100748.idtracker@ietfa.amsl.com> In-Reply-To: <155173336630.5245.15422916059733100748.idtracker@ietfa.amsl.com> Date: Mon, 4 Mar 2019 21:46:04 -0000 Organization: Old Dog Consulting Message-ID: <006601d4d2d3$ab324d80$0196e880$@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: AQE4Pj88Z8uExW8zBiIiHsOiIi2NJ6c1KgxQ Content-Language: en-gb X-Originating-IP: 87.112.237.8 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-24470.003 X-TM-AS-Result: No--4.275-10.0-31-10 X-imss-scan-details: No--4.275-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24470.003 X-TMASE-Result: 10--4.275300-10.000000 X-TMASE-MatchedRID: pBwXUM+nCwvxIbpQ8BhdbOYAh37ZsBDCC/ExpXrHizydI/DikZ1UPB+C hDHqFy+NFnrnG5LOkLa9S3uxUWmw2UIw4Xa9LAtMdPM8veyrICY0AKed0u9fByBzIZ6+1+0no8W MkQWv6iUD0yuKrQIMCOYv5V7WeGfs0C1sQRfQzEHEQdG7H66TyHEqm8QYBtMOnNWUimsHFUdZ5Z W3cNNKGiHMYqhe4KaahztC9cQGOkRaFfkzUg+uV4RzgVbhBHQr/2x1qX+voABUxvQlVqtEEmwgp tkQpvICxCoeW0dT2BaH/JCvitQD6SHK6aCMTbp1P5auqMpnWCs= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-sfc-05: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 21:46:13 -0000 Thanks Alvaro! > I like the thoughts posted by one of the authors [1] and would like to > see something like that reflected in the document. > > [1] https://mailarchive.ietf.org/arch/msg/mpls/b9Duw-9ShdCrIRyis3TOJWw-_pw I also like what that author wrote. We can find a way to include it. > nits: Thanks for these. On the last one. I agree: never let correct grammar get in the way of clear meaning. Cheers, Adrian From nobody Mon Mar 4 13:58:21 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B5C131084; Mon, 4 Mar 2019 13:58:19 -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_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 ZPzMDW0agh4H; Mon, 4 Mar 2019 13:58:17 -0800 (PST) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 D1D6C1310EE; Mon, 4 Mar 2019 13:58:16 -0800 (PST) Received: by mail-qt1-x844.google.com with SMTP id w4so6880972qtc.1; Mon, 04 Mar 2019 13:58:16 -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=y/gLnnO1LNugmpSUybaispSrpy5zQKRLUaEMfPDRRgo=; b=ugGqYX0SUhSD9LCA0svFWJYirnIsoaQYbf+35sB608OsA397qQgiQOdd35lIZm+1dp q8tMK8wMhmrBlavNuxx6awXlcVKl0YNR84//rIRhLgqObIRBys8hYUPeqy5IUlzsmi11 eUCeQbPEjsLhtFugxnm8gC6g3nJcSG+Z4JBd35xbV2mV5aDBUkftvCtYPvahiHaZ/78W nuZFvOhNpQv+RzUG3i4gx8pXBKVJAk1pw07/KZ/oQNniVJFDCbJCYNEUogZbWxc6Feeb 2ZlPzxLfCVBvESnoIEQ4i4CNY3D+nuC7LKJE8IaNBT44sXshKVRcjMJZmamd3XkDKx6B 6ggQ== 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=y/gLnnO1LNugmpSUybaispSrpy5zQKRLUaEMfPDRRgo=; b=nwW5sdavSo70AcHYDFNSuXIxLls3Fqk3qbvJz0ESLfTfFNKzvp973AQmwQXvQ1uJbs 7NV0PDNeDO1691DxUO4RSrccpRekUjhR/pCH7Xgl1sDfu5K3ZI1CKzI2Z5MPTaagJLSY LI75dMdm16eWXtZUg64+Dpl7L03NdKYcgf0KrEANWPzFdm62/ZlLV7uHUW0uCbvQYsxJ 6t+9QV1wuewg4eFV8dBizL3LWZsDlk2SHs4d/34065F6mkuUdlvFseH0HJpr0PJVNrqO 3EUj1LZq67bEFtSCsZNtgkHqt9zzqtAf3lU/uwZbRigXQvfZ2Rra5SrPlTR52LwqI0wS 9zMw== X-Gm-Message-State: APjAAAUNEJyu0jBdA7AqL7n+0HAv84TLB9+IwFSynKo1Ebximeg83mJy XF7uB1JutZStqitAtDUR9sWD5AxcmOL8FUt8wcgKYQ== X-Google-Smtp-Source: APXvYqw45g3dXyHlQrxpq8fdMmDVBkaT5+knZIJ0JGBunNxo+fUWUov/LvxBunOeKJTcCY+kG9ZlxojGul82kU6j67s= X-Received: by 2002:ac8:32ef:: with SMTP id a44mr16476863qtb.334.1551736695758; Mon, 04 Mar 2019 13:58:15 -0800 (PST) MIME-Version: 1.0 References: <155173336630.5245.15422916059733100748.idtracker@ietfa.amsl.com> In-Reply-To: <155173336630.5245.15422916059733100748.idtracker@ietfa.amsl.com> From: "Andrew G. Malis" Date: Mon, 4 Mar 2019 16:58:04 -0500 Message-ID: To: Alvaro Retana Cc: The IESG , mpls , mpls-chairs , draft-ietf-mpls-sfc@ietf.org Content-Type: multipart/alternative; boundary="00000000000089253405834bdacc" Archived-At: Subject: Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-sfc-05: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 21:58:20 -0000 --00000000000089253405834bdacc Content-Type: text/plain; charset="UTF-8" Alvaro, Per-packet metadata is also missing NSH functionality, and that is already pointed out in section 12. Cheers, Andy On Mon, Mar 4, 2019 at 4:02 PM Alvaro Retana wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-mpls-sfc-05: 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-mpls-sfc/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for a very clear document! > > I think that the only NSH functionality not included in this document is > the O > bit (OAM packet). I know that, even in rfc8300, the operation (beyond > setting > the bit) is not defined...and that work is still in progress in the SFC > WG. > However, given that this document describes a "logical representation of > the > NSH", I think it is necessary to point out why the coverage is not > complete. > In looking through the mail archive, I like the thoughts posted by one of > the > authors [1] and would like to see something like that reflected in the > document. > > [1] https://mailarchive.ietf.org/arch/msg/mpls/b9Duw-9ShdCrIRyis3TOJWw-_pw > > nits: > > s/(as described in Section 4.1/(as described in Section 4.1) > > s/(see [I-D.ietf-bess-nsh-bgp-control-plane]/(see > [I-D.ietf-bess-nsh-bgp-control-plane]) > > s/TC: The TC bits have no meaning./TC: The TC bits have no meaning in > this > case. > > s/to determine to which SFF or instance of an SF (an SFI) to deliver the > packet./to determine which SFF or instance of an SF (an SFI) to deliver the > packet to. > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --00000000000089253405834bdacc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alvaro,

Per-packet metadata is also mis= sing NSH functionality, and that is already pointed out in section 12.

Cheers,
Andy


<= div class=3D"gmail_quote">
On Mon, Mar= 4, 2019 at 4:02 PM Alvaro Retana <aretana.ietf@gmail.com> wrote:
Alvaro Retana has entered the following ballot p= osition for
draft-ietf-mpls-sfc-05: 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/s= tatement/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-mpl= s-sfc/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for a very clear document!

I think that the only NSH functionality not included in this document is th= e O
bit (OAM packet).=C2=A0 I know that, even in rfc8300, the operation (beyond= setting
the bit) is not defined...and that work is still in progress in the SFC WG.=
However, given that this document describes a "logical representation = of the
NSH", I think it is necessary to point out why the coverage is not com= plete.
In looking through the mail archive, I like the thoughts posted by one of t= he
authors [1] and would like to see something like that reflected in the docu= ment.

[1] https://mailarchive.ietf.o= rg/arch/msg/mpls/b9Duw-9ShdCrIRyis3TOJWw-_pw

nits:

s/(as described in Section 4.1/(as described in Section 4.1)

s/(see [I-D.ietf-bess-nsh-bgp-control-plane]/(see
[I-D.ietf-bess-nsh-bgp-control-plane])

s/TC:=C2=A0 The TC bits have no meaning./TC:=C2=A0 The TC bits have no mean= ing in this
case.

s/to determine to which SFF or instance of an SF (an SFI) to deliver the packet./to determine which SFF or instance of an SF (an SFI) to deliver the=
packet to.


_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--00000000000089253405834bdacc-- From nobody Tue Mar 5 09:36:15 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535E0130EF3 for ; Tue, 5 Mar 2019 09:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.246 X-Spam-Level: X-Spam-Status: No, score=0.246 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 wnmsM_p0MfHE for ; Tue, 5 Mar 2019 09:36:12 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30096.outbound.protection.outlook.com [40.107.3.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938FD130DD8 for ; Tue, 5 Mar 2019 09:36:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HWxW3uqueyngYQ/3uCqCXLCm3WU3XeaILBPwuNdT7kw=; b=kRoh4oBn3/qOGdlre3mGWEZ729otj/dgZ52OYF0Y0ZWkLkb1wgTskftDVs//noCehLd/nI9XklyLwE8sa9VS6h904eLdL0V3jmKy2Evd+vEW3DP7SFFSbOeqwoZHqQ+HqaLWO3OAb5Kao3QLN6KsLoF9mthK5qEYG13MFMB0gCk= Received: from VI1PR07MB4768.eurprd07.prod.outlook.com (20.177.57.155) by VI1PR07MB5758.eurprd07.prod.outlook.com (20.177.202.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.9; Tue, 5 Mar 2019 17:36:08 +0000 Received: from VI1PR07MB4768.eurprd07.prod.outlook.com ([fe80::a8c3:4982:8378:9a45]) by VI1PR07MB4768.eurprd07.prod.outlook.com ([fe80::a8c3:4982:8378:9a45%3]) with mapi id 15.20.1686.016; Tue, 5 Mar 2019 17:36:08 +0000 From: tom petch To: "mpls@ietf.org" Thread-Topic: I-D Action: draft-ietf-mpls-static-yang-08.txt Thread-Index: AQHU03nqrT5RoCK7iEOJgW5Sst/P5g== Date: Tue, 5 Mar 2019 17:36:08 +0000 Message-ID: <016901d4d379$a1e91e60$4001a8c0@gateway.2wire.net> References: <155155736768.27158.1653954565392604255@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0179.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a::23) To VI1PR07MB4768.eurprd07.prod.outlook.com (2603:10a6:803:76::27) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.156.84.54] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 88f3433d-3798-4063-a903-08d6a1910d3e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB5758; x-ms-traffictypediagnostic: VI1PR07MB5758: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-forefront-prvs: 0967749BC1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(376002)(366004)(346002)(136003)(189003)(199004)(13464003)(4720700003)(9686003)(6436002)(71190400001)(256004)(71200400001)(6512007)(66574012)(2501003)(8936002)(53936002)(966005)(14496001)(50226002)(5660300002)(61296003)(106356001)(478600001)(5640700003)(68736007)(6486002)(476003)(6306002)(86152003)(486006)(2351001)(44736005)(305945005)(446003)(86362001)(229853002)(105586002)(8676002)(76176011)(52116002)(186003)(386003)(99286004)(7736002)(2906002)(6116002)(81686011)(102836004)(6506007)(316002)(6916009)(84392002)(66066001)(81816011)(25786009)(6246003)(1556002)(97736004)(3846002)(26005)(14454004)(81156014)(1730700003)(44716002)(81166006)(62236002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5758; H:VI1PR07MB4768.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-microsoft-exchange-diagnostics: =?iso-8859-1?Q?1; VI1PR07MB5758; 23:BAYhp41VaAeoVJUA0byVuVBygZwK+ScM4OFZon7?= =?iso-8859-1?Q?Cy82aZHSTReTP+6lQ6us20QWXQmxEa4YXNrN1xBf8lpqztPYPojvtjL46o?= =?iso-8859-1?Q?+TcaLx3kSmXRIMwpKk600UkK6R2m97Ai74NDD00VfPnVUYlwA4JGVhHy7i?= =?iso-8859-1?Q?eXaWKqlJe3PDwP1m/4nL4L5x13FPq3OhiKFuOBLB0FuLAhLMGMdJtyDcHf?= =?iso-8859-1?Q?cEwufe0w0s52RwC/zgwE7NDVr/FBgjuYSCV1wFCkJU/yqiv1vjVXU+b1VU?= =?iso-8859-1?Q?kBjM8CdOYmYSnQktN7SrTE3RSvCV18rJ23Vg+XxYXH78uQswRLQ59jj7mN?= =?iso-8859-1?Q?xvhLPEfvMZ+KYu97LpzaEhaAbwXBTtDK1m4Fgks6gnPQDcPpLbVxfYJfmZ?= =?iso-8859-1?Q?hgc+E8+kPDgh22sb+tQiCAKCh+nvGsCDWgD6YaKyZjZ+5A8/Qgcpsb4Vrx?= =?iso-8859-1?Q?bQkeAgtt5P3cAQdT6mB9FlJ0uR82LBmgMTLLVnrwgnSqdgbTXctpfVcfDq?= =?iso-8859-1?Q?l3nTgjL/Ti294KvIm22csJBd/Wb4heaIcUmDcPrafZ053vgRMke1AvfQmw?= =?iso-8859-1?Q?bpzmWH5jCNS+De743nDcUlOff4duswOLHvp0lLBx2f6qiLV92gXoHYx+sp?= =?iso-8859-1?Q?P5LXCFIZA/fajYPuGaTsdsLXrCCUpgnNiv9lTZy0JRKUz5WmJTtAPxdN2v?= =?iso-8859-1?Q?LC/wIK3SxetG3axRD7o/7BXvd/3WEy4rEg+hRa4KJgTEp5jnVU/hhoaysr?= =?iso-8859-1?Q?AD/bTbVI4widDRzmrZzD+AVop80b9Mr8il4aKQaDNscaIp79Tt5MvBxRpT?= =?iso-8859-1?Q?eo6fI2gLzwh3x+y9S5BdprUSd9RX3SUgllBhSFVzCd+TV6hWNvCGbePnqi?= =?iso-8859-1?Q?/togpAGFAtHM+YOuvQJ5KLmhyu4rrLIEYkCXDn8xpz6GsDcCZ/pSNGTmn5?= =?iso-8859-1?Q?LMxeG3oToV0Ywb936roIOFuvVddo/5HZa83w1oUOU0DUPDd8dRkCHKDODO?= =?iso-8859-1?Q?53L9JYdxM+OJTymVohLgGbq8KaA4VUvXeMlKQFrt/1cupdJkBE3FBYAaLV?= =?iso-8859-1?Q?M2FSy6EKnvYa2gt9JNKVpYcLVzqe1OsfEHZ5+nf0SmUbXEwdLdLp3tOQrm?= =?iso-8859-1?Q?EeOl8m4QPYW5yR2A23H8YEiSxMysxjkPwi/cknrwHdQJP5gM1e17gj3ExR?= =?iso-8859-1?Q?NkkqOcxtgUIu1oHubGCV08F1qaU9od3n0qbPAX9BcHLEl2z9ainT2Yiutp?= =?iso-8859-1?Q?M60fVA7/Nle3a5IGhZ80SimZgNE6jzJDRWSDj9Y+yCzEQqn1LXtk6BvQfg?= =?iso-8859-1?Q?ZTSQRUaZg6Gko7I+90MJshM4Z96KU087zvqi3HjU9t8qHXd+ARZMwmA2/L?= =?iso-8859-1?Q?jbbTaE1+Yda8FcOi6XCB80bqATYAcVq9p0XbB6rp1oOUDnUqpck+GRH+uO?= =?iso-8859-1?Q?qJtxvMYIOcEz1DNdcBVYrK87HJrFCXnuYwfU+ejXeYBM+pmg2LvnwdD4Kl?= =?iso-8859-1?Q?7T68QE+DspR9v4FqI5Eh/8esf3JlvQkzrDFos4g/bWZtiMlq+bzCRcJ0Fz?= =?iso-8859-1?Q?XQvcFIXK0y1vqZhawsEwZTaRRUwKbRrj+tvvgovxjRpyQ3m0C8nAla0fqG?= =?iso-8859-1?Q?ZSbokZ5gInK8G/mBiO5vy5ceVrjuapcYKbhnZZCNVSZzvxdodCoH5?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: kuIXHZhi2xCC5mFUDpGFV9DcxQub69YP5Ew6nNaHV4AMHLP6XvYqfEJP3dxKLT9MlHLkxNcd/aNzLIrYqM7o0TlygBJDHGu1iTU0iRF3JCwwp30u56klbP7uio1CUNYsW0NHKw7eXzPqu58uVRoQmBUz4hU2+sOiJ2j/udh/zt8RqLnH5TCqcGuHHDdUyjAe7rLyclJWltSR23kAFlNpM341LsDV9oa6sTat/ylrbVive2m7pfpTWJ1xB0eiDmGPCIaoWkz+AzYAVTSPS+HiJNp7HOSAtqqBIFFHjwxU40ik6/iztjEOQlFxvnqEzcwfe5JOI+lswAE+EhkjUic1ZG+lMzuaypCcmfXBG1g4APXMadOq8bkgMAjrgwTwQdNPPTKSNHjdA5+A4kU8bptTflhd+oXAJ4QbyUfWbREAVWQ= Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 88f3433d-3798-4063-a903-08d6a1910d3e X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2019 17:36:08.6165 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5758 Archived-At: Subject: Re: [mpls] I-D Action: draft-ietf-mpls-static-yang-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 17:36:14 -0000 A long and winding road! module ietf-mpls-static { .... import ietf-routing-types { prefix "rt-types"; reference "RFC8294: Common YANG Data Types"; I see, in the RFC Index, 8294 Common YANG Data Types for the Routing Area. i.e. a different title module ietf-mpls-static-extended { ... import ietf-routing { prefix "rt"; reference "RFC6991: Common YANG Data Types"; I suggest reference "RFC8349: A YANG Data Model for Routing Management"; reference "RFC XXXX: Extended YANG Data Model for MPLS Static LSPs"; um - I see this I-D as titled A YANG Data Model for MPLS Static LSPs Tom Petch ----- Original Message ----- From: To: Cc: Sent: Saturday, March 02, 2019 8:09 PM > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiprotocol Label Switching WG of the IETF. > > Title : A YANG Data Model for MPLS Static LSPs > Authors : Tarek Saad > Rakesh Gandhi > Xufeng Liu > Vishnu Pavan Beeram > Igor Bryskin > Filename : draft-ietf-mpls-static-yang-08.txt > Pages : 18 > Date : 2019-03-02 > > Abstract: > This document contains the specification for the MPLS Static Label > Switched Paths (LSPs) YANG model. The model allows for the > provisioning of static LSP(s) on Label Edge Router(s) LER(s) and > Label Switched Router(s) LSR(s) devices along a LSP path without the > dependency on any signaling protocol. The MPLS Static LSP model > augments the MPLS base YANG model with specific data to configure and > manage MPLS Static LSP(s). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-static-yang/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-mpls-static-yang-08 > https://datatracker.ietf.org/doc/html/draft-ietf-mpls-static-yang-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-static-yang-08 > > > 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 Tue Mar 5 13:24:00 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D138C130F0E; Tue, 5 Mar 2019 13:23:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Datatracker on behalf of Martin Stiemerling To: Cc: mpls@ietf.org, ietf@ietf.org, draft-ietf-mpls-sr-over-ip.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155182102765.27824.6348634481043936612@ietfa.amsl.com> Date: Tue, 05 Mar 2019 13:23:47 -0800 Archived-At: Subject: [mpls] Tsvart last call review of draft-ietf-mpls-sr-over-ip-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 21:23:53 -0000 Reviewer: Martin Stiemerling Review result: Ready This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. A good document and I have only one request: From a Transport Area perspective, it would be good to emphasize RFC 7510 and its details about MPLS over UDP. From nobody Tue Mar 5 13:35:32 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B61131065; Tue, 5 Mar 2019 13:35:15 -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] 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 kfITMclLoLBY; Tue, 5 Mar 2019 13:35:12 -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 2BDB3130DEF; Tue, 5 Mar 2019 13:35:12 -0800 (PST) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id x25LZAeU006377; Tue, 5 Mar 2019 21:35:10 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 000B722044; Tue, 5 Mar 2019 21:35:09 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id DDD6E22042; Tue, 5 Mar 2019 21:35:09 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id x25LZ8dw022149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 Mar 2019 21:35:09 GMT Reply-To: From: "Adrian Farrel" To: "'Datatracker on behalf of Martin Stiemerling'" , Cc: , , References: <155182102765.27824.6348634481043936612@ietfa.amsl.com> In-Reply-To: <155182102765.27824.6348634481043936612@ietfa.amsl.com> Date: Tue, 5 Mar 2019 21:35:08 -0000 Organization: Old Dog Consulting Message-ID: <020a01d4d39b$4e92c460$ebb84d20$@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: AQH2Qj+Sv2A2/J/rvZAZjZIPktu+aaW6r8DA Content-Language: en-gb X-Originating-IP: 87.112.237.8 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-24472.002 X-TM-AS-Result: No--4.173-10.0-31-10 X-imss-scan-details: No--4.173-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24472.002 X-TMASE-Result: 10--4.172700-10.000000 X-TMASE-MatchedRID: lORh06tOiKjxIbpQ8BhdbPHkpkyUphL9Fpw9gj8mywo52X8YwVUEWxqi pukRkz4u+mTbVsoklFeUQ8nzPXHtTuDBvYycsJwVngIgpj8eDcCcIZLVZAQa0BKSkUyWikw9FBp uM64i9KELbigRnpKlKZx+7GyJjhAUaSj54VAn/5vnTTdgJYYhO5neZpYxgHMsYh+/8OhfEZmP3P jSR0yw/2OkFJC+fvEeBsDbsTIQB53IdOzc+bscEwXurkMBOOtl5D9smqVBD9yilnnVDECPd/H7A vsTxZMb7DafdH0+BI6wFMlIPaIBbQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] Tsvart last call review of draft-ietf-mpls-sr-over-ip-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 21:35:16 -0000 Hi Martin, Good to hear from you. > I have only one request: From a Transport Area perspective, > it would be good to emphasize RFC 7510 and its details about > MPLS over UDP. Happy to accommodate this request. But what do you have in mind? There are references to 7510, in the Introduction and in the first two = use cases in Section 2. Then, the packet forwarding procedures in Section 3.2 begin with a = reference to 7510 as well. And there a couple more references in the document. Thanks, Adrian From nobody Tue Mar 5 17:30:11 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEF2124BF6; Tue, 5 Mar 2019 17:30:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mpls@ietf.org Message-ID: <155183580967.27896.1411454709231123122@ietfa.amsl.com> Date: Tue, 05 Mar 2019 17:30:09 -0800 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-lag-multipath-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 01:30:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching WG of the IETF. Title : Label Switched Path (LSP) Ping/Trace Multipath Support for Link Aggregation Group (LAG) Interfaces Authors : Nobo Akiya George Swallow Stephane Litkowski Bruno Decraene John E. Drake Mach(Guoyi) Chen Filename : draft-ietf-mpls-lsp-ping-lag-multipath-06.txt Pages : 27 Date : 2019-03-04 Abstract: This document defines extensions to the MPLS Label Switched Path (LSP) Ping and Traceroute mechanisms as specified in RFC 8029. The extensions allow the MPLS LSP Ping and Traceroute mechanisms to discover and exercise specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. Additionally, a mechanism is defined to enable determination of the capabilities of an LSR supported. This document updates RFC8029. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-lag-multipath/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-lag-multipath-06 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-lsp-ping-lag-multipath-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-lag-multipath-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 6 02:19:38 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4A4127598; Wed, 6 Mar 2019 02:19:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Datatracker on behalf of Martin Vigoureux To: "The IESG" Cc: draft-ietf-mpls-sfc@ietf.org, Loa Andersson , mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155186757563.24618.8284642177706375034.idtracker@ietfa.amsl.com> Date: Wed, 06 Mar 2019 02:19:35 -0800 Archived-At: Subject: [mpls] Martin Vigoureux's Yes on draft-ietf-mpls-sfc-05: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 10:19:36 -0000 Martin Vigoureux has entered the following ballot position for draft-ietf-mpls-sfc-05: Yes 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-mpls-sfc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hello thank you for this document. I know I'm being too pernickety: You say: o An SFF MUST decrement the TTL by one each time it performs a forwarding lookup. but in the examples you also say: b. When the packet arrives at SFFa it strips any labels associated with the tunnel that runs from the classifier to SFFa. SFFa examines the top labels and matches the SPI/SI to identify that the packet should be forwarded to SFa. The packet is forwarded to SFa unmodified. and d. SFFa modifies the SI in the lower label stack entry (to 254) and uses the SPI/SI to look up the forwarding instructions. It could look as two forwarding lookup, which, according to the requirement, could lead to two TTL decrements. I do read in step b that the packet is forwarded unmodified, and read in Section 6 "The TTL in SF label stack entry is decremented once for each forwarding hop in the SFP" but still I wonder if some clarification wouldn't be beneficial. nits: TTL: The TTL fields in the SFC Context label stack entry SF label stack entry SHOULD be set to 1 as stated in Section 5, Do you mean: SFC Context label stack entry *and* SF label stack entry ? s/document)./document./ From nobody Wed Mar 6 06:53:18 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F110A124BA8 for ; Wed, 6 Mar 2019 06:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[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_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 Nizhu57WFDpI for ; Wed, 6 Mar 2019 06:53:14 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 6DC60126E5C for ; Wed, 6 Mar 2019 06:53:14 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id u7so13080311qtg.9 for ; Wed, 06 Mar 2019 06:53:14 -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=oLOjl2qtFXa9EsRv6JLguO1XQSw9svAalGrT9zqXFWY=; b=W+RhJBUpFA5ujsEkEWOVzDvrzmnPZ8giRN1E+Bt1T94Tl2nAvCB34LvpMZacXKqzK0 LdwNH68DWWNmb1OHtMqouMjhy5nE5TGsATthn/M5I9S9gmmhjG/AI9PnatTmQGwpNpS7 vD16ejiwmWufHKQiK50pGN08rwh3cPXA2mdljwA9eXf4OhMWcMoyl/j3+bOa6c3HhJuE rvwV0kqnuCkZrrx7PWDbKrFKGsnrvyyJfUomC90xCXVpIF+W0JAX+cpWCCfm0TSy2d9P HSWKyoyA60n/Qy8qbscQjzJA3CTmfGALErmWW+N5NfndR9+SZTwxMyhd/n5BMQvN1Fns ksNg== 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=oLOjl2qtFXa9EsRv6JLguO1XQSw9svAalGrT9zqXFWY=; b=BEIfeVZUBj+adVrtqbEnplJ7mUJYG2Rn6eM9pywJaoJ6uGyDhlHZR8IwTmxkxkVq0X qqTtUOwJQFroErsHpQQvPFv3FRPUk1YNZxh2XOLzwkZF0gaF+Oij6BPO8WFBMi0Yoeu9 dNTWGV+1xgMXeSeTvTcOecY9lmFlC070sfEeQEQORWLMqmkm9ZdDRkqq6I6+V1TNdaVY 9qlxK2uCMkGXRASYYC4R7DLT+USetizXRFK85coaiV/9+O4IWKwEwBmEtxnfWc0xagfr DhTxftlLBNqKjG+CXuIcbK6PQgNZ9QWehx7sUAdzFXGPiPTcC5dcz15Dk9UGcLKXbZir rDXg== X-Gm-Message-State: APjAAAWo++nmF/tf8E5KLs3j4HhMV1YYXn8Uwlu4RRLUITgBSJt5RKWn B8RmtDZJqlN+df/PmpCdM9sjFKnlIL46bWnoPWg= X-Google-Smtp-Source: APXvYqy5Br1nxSeVe+A4yNGM6pBThYyh4OXl9REEuTl69MnxESkAHXO77FUuZBxeVR9rDHRk84wpCxrheA67S6YlShw= X-Received: by 2002:a0c:92a9:: with SMTP id b38mr6273836qvb.70.1551883993526; Wed, 06 Mar 2019 06:53:13 -0800 (PST) MIME-Version: 1.0 References: <155155736768.27158.1653954565392604255@ietfa.amsl.com> <016901d4d379$a1e91e60$4001a8c0@gateway.2wire.net> In-Reply-To: <016901d4d379$a1e91e60$4001a8c0@gateway.2wire.net> From: Tarek Saad Date: Wed, 6 Mar 2019 09:53:02 -0500 Message-ID: To: tom petch Cc: "mpls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002ab5f705836e265e" Archived-At: Subject: Re: [mpls] I-D Action: draft-ietf-mpls-static-yang-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 14:53:17 -0000 --0000000000002ab5f705836e265e Content-Type: text/plain; charset="UTF-8" Hi Tom, As usual, thanks for your review on this one and for your patience. More Inline.. On Tue, Mar 5, 2019 at 12:36 PM tom petch wrote: > A long and winding road! > > module ietf-mpls-static { > ..... > import ietf-routing-types { > prefix "rt-types"; > reference "RFC8294: Common YANG Data Types"; > > I see, in the RFC Index, > > 8294 Common YANG Data Types for the Routing Area. > i.e. a different title > > [TS]: yes, unfortunately a deja vu (fixed in another module). We'll take care of this in the new version. > > module ietf-mpls-static-extended { > .... > import ietf-routing { prefix "rt"; > reference "RFC6991: Common YANG Data Types"; > I suggest > reference "RFC8349: A YANG Data Model for Routing Management"; > > [TS]: yes, will take of this. reference "RFC XXXX: Extended YANG Data Model for MPLS Static LSPs"; > um - I see this I-D as titled > A YANG Data Model for MPLS Static LSPs > > [TS]: OK for this one too. Regards, Tarek > > Tom Petch > > > ----- Original Message ----- > From: > To: > Cc: > Sent: Saturday, March 02, 2019 8:09 PM > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Multiprotocol Label Switching WG of > the IETF. > > > > Title : A YANG Data Model for MPLS Static LSPs > > Authors : Tarek Saad > > Rakesh Gandhi > > Xufeng Liu > > Vishnu Pavan Beeram > > Igor Bryskin > > Filename : draft-ietf-mpls-static-yang-08.txt > > Pages : 18 > > Date : 2019-03-02 > > > > Abstract: > > This document contains the specification for the MPLS Static Label > > Switched Paths (LSPs) YANG model. The model allows for the > > provisioning of static LSP(s) on Label Edge Router(s) LER(s) and > > Label Switched Router(s) LSR(s) devices along a LSP path without > the > > dependency on any signaling protocol. The MPLS Static LSP model > > augments the MPLS base YANG model with specific data to configure > and > > manage MPLS Static LSP(s). > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-mpls-static-yang/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-mpls-static-yang-08 > > https://datatracker.ietf.org/doc/html/draft-ietf-mpls-static-yang-08 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-static-yang-08 > > > > > > 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 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --0000000000002ab5f705836e265e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,

As usual, thanks for= your review on this one and for your patience. More Inline..

On Tue, Mar 5,= 2019 at 12:36 PM tom petch <ietf= c@btconnect.com> wrote:
A long and winding road!

=C2=A0module ietf-mpls-static {
.....
=C2=A0 =C2=A0import ietf-routing-types {
=C2=A0 =C2=A0 =C2=A0prefix "rt-types";
=C2=A0 =C2=A0 =C2=A0reference "RFC8294: Common YANG Data Types";<= br>
I see, in the RFC Index,

8294 Common YANG Data Types for the Routing Area.
i.e. a different title

[TS]: yes, unfortunately a deja vu (fixed in another = module). We'll take care of this in the new version.=C2=A0

module ietf-mpls-static-extended {
....
=C2=A0 import ietf-routing {=C2=A0 =C2=A0 prefix "rt";
=C2=A0 =C2=A0 reference "RFC6991: Common YANG Data Types";
I suggest
=C2=A0 =C2=A0 =C2=A0reference "RFC8349: A YANG Data Model for Routing = Management";

[TS]: yes, will take of this.

=C2=A0reference "RFC XXXX: Extended YANG Data Model for MPLS Static LS= Ps";
um - I see this I-D as titled
A YANG Data Model for MPLS Static LSPs

[TS]: OK for this one too.

R= egards,
Tarek
=C2=A0

Tom Petch


----- Original Message -----
From: <int= ernet-drafts@ietf.org>
To: <i-d-anno= unce@ietf.org>
Cc: <mpls@ietf.org>
Sent: Saturday, March 02, 2019 8:09 PM

> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Multiprotocol Label Switching WG of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: A YANG Data Model for MPLS Static LSPs
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Tarek Saad
>=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=A0Rakesh Gandhi
>=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=A0Xufeng Liu
>=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=A0Vishnu Pavan Beeram
>=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=A0Igor Bryskin
> Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-mpls-static-yang-08.t= xt
> Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 18
> Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2019-03-02
>
> Abstract:
>=C2=A0 =C2=A0 This document contains the specification for the MPLS Sta= tic Label
>=C2=A0 =C2=A0 Switched Paths (LSPs) YANG model.=C2=A0 The model allows = for the
>=C2=A0 =C2=A0 provisioning of static LSP(s) on Label Edge Router(s) LER= (s) and
>=C2=A0 =C2=A0 Label Switched Router(s) LSR(s) devices along a LSP path = without
the
>=C2=A0 =C2=A0 dependency on any signaling protocol.=C2=A0 The MPLS Stat= ic LSP model
>=C2=A0 =C2=A0 augments the MPLS base YANG model with specific data to c= onfigure
and
>=C2=A0 =C2=A0 manage MPLS Static LSP(s).
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/d= raft-ietf-mpls-static-yang/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-iet= f-mpls-static-yang-08
> https://datatracker.ietf.or= g/doc/html/draft-ietf-mpls-static-yang-08
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?= url2=3Ddraft-ietf-mpls-static-yang-08
>
>
> 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-Announc= e@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-ann= ounce
> Internet-Draft directories: http://www.ietf.org/shadow.html<= br> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--0000000000002ab5f705836e265e-- From nobody Wed Mar 6 07:58:15 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 164F5127287; Wed, 6 Mar 2019 07:58:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Datatracker_on_behalf_of_Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-mpls-sfc@ietf.org, Loa Andersson , mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155188788708.5267.7389555320597491610.idtracker@ietfa.amsl.com> Date: Wed, 06 Mar 2019 07:58:07 -0800 Archived-At: Subject: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-mpls-sfc-05=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 15:58:07 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-mpls-sfc-05: 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-mpls-sfc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One minor editorial comment: The abstract is quite long (compared to usual RFC abstracts). I recommend to only have the last paragraph (or a slightly extended version of the last paragraph). From nobody Wed Mar 6 08:00:30 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBCF128678; Wed, 6 Mar 2019 08:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 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, KHOP_DYNAMIC=1.468, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.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 EkrTKj84Bfcn; Wed, 6 Mar 2019 08:00:20 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 B732712786D; Wed, 6 Mar 2019 08:00:20 -0800 (PST) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x26G0KFv008770; Wed, 6 Mar 2019 08:00:20 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=lPBcxdTkkzwjrjopEr6Oj+sW6Q2DVrNcfqBB9KpVJxA=; b=WUaEWjbe6HjImawNIpKx3jd8NJ5eVyfeXkzCZS3WnC+v6WKbUu2FOL0xHMRLm1OzG0xQ lqQ2EacEglLjOpyGyT8V3EqwDGu1wuJS/FaIOI9ce6nhty46xvDIJAzGBmMSeJ5v0ojw pVR6UhLdzTAxbA/g2+1mf06fjRQ/aLxEfBTEX5EhyXZjDgjhcD7sGWCD/DnhowcPjqgZ eSnuqWpemqLMVYeVJlclaEu+nersy3ZA5bjKYo+vLoXZ+m2KEcuAtBClNT+Ry4kePDo2 wEUkWQQXTp27BQQWn31UzzhvBTVTPTD2JBPKhfoSllDenn1xRKilJws3DYjt+HR4OmZT 1Q== Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp2059.outbound.protection.outlook.com [104.47.45.59]) by mx0a-00273201.pphosted.com with ESMTP id 2r2c5x0ghe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 06 Mar 2019 08:00:19 -0800 Received: from BYAPR05MB5029.namprd05.prod.outlook.com (20.177.230.211) by BYAPR05MB6245.namprd05.prod.outlook.com (20.178.196.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.10; Wed, 6 Mar 2019 16:00:11 +0000 Received: from BYAPR05MB5029.namprd05.prod.outlook.com ([fe80::b58f:10f1:a40b:abf7]) by BYAPR05MB5029.namprd05.prod.outlook.com ([fe80::b58f:10f1:a40b:abf7%4]) with mapi id 15.20.1686.016; Wed, 6 Mar 2019 16:00:11 +0000 From: John E Drake To: =?utf-8?B?RGF0YXRyYWNrZXIgb24gYmVoYWxmIG9mIE1pcmphIEvDvGhsZXdpbmQ=?= , The IESG CC: "draft-ietf-mpls-sfc@ietf.org" , Loa Andersson , "mpls-chairs@ietf.org" , "loa@pi.nu" , "mpls@ietf.org" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-mpls-sfc-05:_(with_COMMENT)?= Thread-Index: AQHU1DVqXPo+nqciaEa8t/QoBDxmJKX+wssQ Date: Wed, 6 Mar 2019 16:00:11 +0000 Message-ID: References: <155188788708.5267.7389555320597491610.idtracker@ietfa.amsl.com> In-Reply-To: <155188788708.5267.7389555320597491610.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: acb08240-0b94-432c-4e93-08d6a24cd026 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB6245; x-ms-traffictypediagnostic: BYAPR05MB6245: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjA1TUI2MjQ1OzIzOjZZajBwN0hYRVl3WTRQcG1uSUVDSCtJT1lR?= =?utf-8?B?TUZ0aE9YWXpLcVlLZFJtWkU2UktBVDNYM3AwUTlianh1S1pqaTA5V0tQUjMv?= =?utf-8?B?bytBK3cxVkhyOVArSjBJOFY5Tzg2M3hrS2ZFUzZuUU9ldWNLY0s2aERPUzJ0?= =?utf-8?B?bGlzUC9FbkY1RmdqZERTdWMrNUhzUnBPeHVQR05kQVhZRlYvb1R5dCsxM1M0?= =?utf-8?B?T056MW9XUlVUd0xIWTJXZHVqWG45K0IwMzNMdDhFa2JqQUs5dmsxTUR6amFy?= =?utf-8?B?bXJsTXdWQ2t2d1A1Wko1MFVTaU5DUWVFRHUxdjFEMFJjaHpNVDVqTmVmU2VM?= =?utf-8?B?SjhqbFRveTBTWVd0bVdlR3ZOanh4aTMxdXVBQnlKZGVoL2lybXpHc3loQWZm?= =?utf-8?B?SjNKb3EySTVLSUl2bDExdW1wRWRSWjR1cndXbkVOT3lISDlBeC9mT2FkdEE2?= =?utf-8?B?Wll4S0QxZlNacGhFeXVmUXdDVTkzWGFvSlRlT0tNS0JKZkFqYnJucmdrSjRz?= =?utf-8?B?Y1RPSVR4V0xRc1NxTDlQcjFVZjJweHhGaHE5RmdMUVVyNGN1UVp5ODZWcVgy?= =?utf-8?B?MEVXS2UzZXNhUWlwSlAwU3hwbzhxYkUzbXZnR2lKQTFxNjFmMVFMdmFiWi92?= =?utf-8?B?eFJuSDN6dldza2NpV01PSFVQbWM3S2NvQlpvLzhGL3VQZ2hrZ3p6WEtUTEhv?= =?utf-8?B?MDhZaWZLM24xekFKeWJQOEZ6QWtidUo3dWk2TDQ3N1IzQU80Mm5aVEp5Ykdp?= =?utf-8?B?Wm4zbnJUNERpMTdrUlhzd0dhK251elphS2xTYW5Ud2l2T1JMZXo1UHVDa3Zz?= =?utf-8?B?RmZsM3p4TTJwaDZBTnZxS0pvNlAwNndDR09RUCsxYlJTcms0bFdNYU9zTGVs?= =?utf-8?B?OFVHUmdsY1VnQjEycU82OFVGOWxTNS9INDN6Z3RxOHZrdWc5c2FvSG5xUHc5?= =?utf-8?B?Wm9iSG9MTzZ1WDdlZWRYWnV4OWFTWkRDR3JkdzhCS1pNRnE2NFd4QVE2UEtr?= =?utf-8?B?RGI4K29hMCtjTHhLOE9ubU9QWTZYVG1Mb0dvSFF3ZDZjd2hlQXJpQ1dRcWpr?= =?utf-8?B?TGUxNERiN2JCWjdUdDBuY2ZJS1lyWDVyUmU5WTNBeGRXdk5keE5UM0NsT0tJ?= =?utf-8?B?cGFJYWFyMW1CM3g0UVdrL3YyRmlUd1Rxb3BaYjl5RXBiNEtvOXAweEJzeUFt?= =?utf-8?B?WEVkS24rbTU2TllhTVhSa0hSWHU5dk1xaGNPU3JTbk5VajhteVpBZGZ2SzVr?= =?utf-8?B?N2RWMDg0NGpWSlNYSzBvYzEvRkR3eEx1NXJ0MHlBR1NRZmVtUm9pVDZGQ0tr?= =?utf-8?B?K01wZDFwNThQZlBzVm1PTTJzNU5LUVgvRXp3NlE1dDJyRWlXUndvWWV3dUV6?= =?utf-8?B?OHh1R0FmOEZyWHZJNG8rdVhJUE5TZVM1czBlTzMza2EyS2hKMGdDajZjejhS?= =?utf-8?B?RXNHb2dVeFFwS2RlU21uVTRiZ2JEMmZqVGVEWnVnUXZ6a0NmQndoS2twcmhS?= =?utf-8?B?TDdURGZvMUJRbUdqN1ZtVFBxSG1DSnB6WW1xWFdEYXJRUmt1K0NFa3daU0tM?= =?utf-8?B?dGhUdkNJaEgxd3BBei9ISXliektTUGRPYzd2TFJtVDJFeDBESTQxQTJqZXNu?= =?utf-8?B?Z3Z6R1o0Wkw0OGZGK0g4QU5MN0lZL2lyc2NGM3diajhpd3NWRHJwcFZ3a0JB?= =?utf-8?B?eVRoS01LaS8vMmMxRWtCbi9rUFl4Z3IyY0hDVVNzTEM1TVE5OFZZcGVhcS9r?= =?utf-8?Q?Ic1DPo+P/zEW09iJVkmRrTE+UUd91Zu7GTVJ0=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(346002)(136003)(366004)(39860400002)(13464003)(199004)(189003)(6506007)(53546011)(25786009)(4326008)(316002)(446003)(11346002)(486006)(476003)(6246003)(5660300002)(33656002)(52536013)(8936002)(81166006)(81156014)(2906002)(102836004)(55016002)(71190400001)(71200400001)(6116002)(3846002)(9686003)(53936002)(19627235002)(99286004)(68736007)(54906003)(66066001)(110136005)(74316002)(76176011)(7696005)(106356001)(224303003)(14454004)(105586002)(966005)(6306002)(86362001)(478600001)(6436002)(26005)(186003)(305945005)(7736002)(97736004)(256004)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB6245; H:BYAPR05MB5029.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /OOuuj6kaCpSuXFrFrwkeykmsYOpb1LocH+0pbnYi8v+c6sGzQwhJWUv6xyziPHCtqI9dwsLAF0YeFZ7ynRsV2GZx0Gu7YBY9yX74r75d4Ep2ZboKO/fMQC5eNx2nkznjEt2zrZQBOiSaMJ4S6qPOj6b70YLA0aG/bTius8WM6i5gMEgbUqWe159tq/gf0BbWflD21b+8HR12n1GtKDEmcnZf3xI0ncAQWzmAX9QUA4/ptq3BfusC5Q0ThltYMJFsIu4lg1NptPe4pLM7oJbwzOL++LFD7YuyqnKjIJQhfQl/IlS6jfB39uiqWT1wadt0qb3wpG/MKfF5h+eo994SYRwZEgVvcv3PW6NryQ2YL/8Rm4eW3YxHjSjl22RGImHoo2tW05ODRu3h410p3+Ww3YLcpigwPnRrXzW/y3qY5s= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: acb08240-0b94-432c-4e93-08d6a24cd026 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2019 16:00:11.1998 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB6245 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-06_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903060111 Archived-At: Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-mpls-sfc-05=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 16:00:28 -0000 TWlyamEsDQoNCkFuIGV4Y2VsbGVudCBzdWdnZXN0aW9uLg0KDQpZb3VycyBJcnJlc3BlY3RpdmVs eSwNCg0KSm9obg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERhdGF0 cmFja2VyIG9uIGJlaGFsZiBvZiBNaXJqYSBLw7xobGV3aW5kIDxpZXRmLXNlY3JldGFyaWF0LQ0K PiByZXBseUBpZXRmLm9yZz4NCj4gU2VudDogV2VkbmVzZGF5LCBNYXJjaCA2LCAyMDE5IDEwOjU4 IEFNDQo+IFRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6IGRyYWZ0LWlldGYtbXBs cy1zZmNAaWV0Zi5vcmc7IExvYSBBbmRlcnNzb24gPGxvYUBwaS5udT47IG1wbHMtDQo+IGNoYWly c0BpZXRmLm9yZzsgbG9hQHBpLm51OyBtcGxzQGlldGYub3JnDQo+IFN1YmplY3Q6IE1pcmphIEvD vGhsZXdpbmQncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1tcGxzLXNmYy0wNTogKHdpdGgN Cj4gQ09NTUVOVCkNCj4gDQo+IE1pcmphIEvDvGhsZXdpbmQgaGFzIGVudGVyZWQgdGhlIGZvbGxv d2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtbXBscy1zZmMtMDU6IE5vIE9i amVjdGlvbg0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBs aW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsDQo+IGFkZHJlc3NlcyBpbmNsdWRlZCBp biB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9y eQ0KPiBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX193d3cu aWV0Zi5vcmdfaWVzZ19zdGF0ZW1lbnRfZGlzY3Vzcy0NCj4gMkRjcml0ZXJpYS5odG1sJmQ9RHdJ RGFRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLQ0KPiBuZGIzdm9EVFhjV3pvQ0kmcj1D UkIydEppUWVQazBjVC1oNUxHaEVXSC0NCj4gc194WFh1cDNIenZCU01SajVWRSZtPUxsbG83Qm4y Z0F5T3NHSWliM0FnY1V2MXV2YXVJT2ptX3c0YWZiR3Y5Rm8NCj4gJnM9QmttNV9JVmtiOGVxRVJj dUE5X0lSSWVwWlA5ZlhrTE1GTnRpOUcwSTNNNCZlPQ0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBh Ym91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBk b2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQg aGVyZToNCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LQ0KPiAzQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEaWV0Zi0yRG1wbHMtDQo+ IDJEc2ZjXyZkPUR3SURhUSZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy0NCj4gbmRiM3Zv RFRYY1d6b0NJJnI9Q1JCMnRKaVFlUGswY1QtaDVMR2hFV0gtDQo+IHNfeFhYdXAzSHp2QlNNUmo1 VkUmbT1MbGxvN0JuMmdBeU9zR0lpYjNBZ2NVdjF1dmF1SU9qbV93NGFmYkd2OUZvDQo+ICZzPTUy UTZDTDNxQUxWM3FkVHM2eVBRSlRxMFViMUxrNkV5ZXBkMlNYQ01SaGsmZT0NCj4gDQo+IA0KPiAN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBPbmUg bWlub3IgZWRpdG9yaWFsIGNvbW1lbnQ6DQo+IFRoZSBhYnN0cmFjdCBpcyBxdWl0ZSBsb25nIChj b21wYXJlZCB0byB1c3VhbCBSRkMgYWJzdHJhY3RzKS4gSSByZWNvbW1lbmQgdG8NCj4gb25seSBo YXZlIHRoZSBsYXN0IHBhcmFncmFwaCAob3IgYSBzbGlnaHRseSBleHRlbmRlZCB2ZXJzaW9uIG9m IHRoZSBsYXN0DQo+IHBhcmFncmFwaCkuDQo+IA0KDQo= From nobody Wed Mar 6 13:00:42 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88DAD126F72; Wed, 6 Mar 2019 13:00:40 -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_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 X-0uqFgov93E; Wed, 6 Mar 2019 13:00:35 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D140126C15; Wed, 6 Mar 2019 13:00:35 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id d14so12212265ljl.9; Wed, 06 Mar 2019 13:00:35 -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=Yf+mJRTQovBF6MjOhKk8Y0FGyOT7ochOwWis+lI9+yw=; b=mlMnO3E0NHiH756eOcCYoTcPHYO9eB/GJVA/jaCLg6xuRcoNoGoJDdwtjAw+2PQmsh k8lV9RdHBQl57YYTutF/+wiq9jUOjKMyaIBWCv2yh4QE2/FP09b/Dz7/KttLkrwMcSCi YRYwIwAgj2fgz/r3hd2RdNr/CCeYw6A19mItV06ixez7tmTkWkOhm/LxK4RIEgksZ7XX fvLCZksVhQ6XRoYBl+GtsVK8pAonpju00L9oaYwahlkKfgm1OsrbWiU69dpXrhw4YS2U FxtvncVs9lmxHZzBmfiOrQRMxzKUrRcSXz0Fl0W9XD9nh5ZfgkzV092JR3yXG5VQJ3MH +c0Q== 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=Yf+mJRTQovBF6MjOhKk8Y0FGyOT7ochOwWis+lI9+yw=; b=LPfZ+oxw056LVu5ycY06uNvReBNcX5k21zH2eZt/jid2N2IJWAsIbIEiiKuxqoPoIN lCbWn2/vMDemJ/CjVt0NkxSnBP25kgHPSlUxYwo7ISzc/+5OFS0EMxtWeGdAqKj6HRiC FHii19wI/m0RlcWhxEjqMPki0lobHjMQvSiBkvHa9bzGzlYTDwDx6VkFgtIdNCMOpvOb yQT3eAwc+CPKL45mCe9fofZ09oj7IxPu2rnV1KZy6IwUFfrswYDUK+5D8tA4thq7Xnnu yPkjT8hdfUa/gTgYrnIMCfLUiJx0gZw7uyDLCjHV0XWSYYGZjciuEX0gO8FbwfcsXtaU ZjiA== X-Gm-Message-State: APjAAAVdOIdRUQLS7vAZh2Xa5cU1+iv4nyfT4uvm9aPDFdS3PIRCqicJ VLWYmsRCD4nGvzfr8O86aYpqTms0siDTgPRZI4FlW14= X-Google-Smtp-Source: APXvYqyfG4u9HM+otn0NnqHGOXWB0iVQEHuY5jt4knbW2YQXlOu3u3uCrUN+hU+U1oEvWM11ll+fOeBEeddFOT3QMLw= X-Received: by 2002:a2e:2165:: with SMTP id h98mr3617231ljh.117.1551906033014; Wed, 06 Mar 2019 13:00:33 -0800 (PST) MIME-Version: 1.0 References: <19124c2d-c53b-5826-e7fa-b16616e7ef01@pi.nu> In-Reply-To: <19124c2d-c53b-5826-e7fa-b16616e7ef01@pi.nu> From: Rakesh Gandhi Date: Wed, 6 Mar 2019 16:00:21 -0500 Message-ID: To: Loa Andersson Cc: "mpls@ietf.org" , "mpls-chairs@ietf.org" , draft-nainar-mpls-rfc8287-len-clarification@ietf.org Content-Type: multipart/alternative; boundary="000000000000d29e10058373471e" Archived-At: Subject: Re: [mpls] working group adoption poll X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 21:00:40 -0000 --000000000000d29e10058373471e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes/support. Thanks, Rakesh On Wed, Feb 27, 2019 at 3:41 AM Loa Andersson wrote: > Working Group, > > This is to start a two week poll on adopting > draft-nainar-mpls-rfc8287-len-clarification > as a MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > We have done an IPR poll for this document. All the co-authors and > contributors have responded to the IPR poll that they are unaware of any > IPRs that relates to this draft. > > There are no IPR disclosures against this document. > > There has also been a discussion on adding text at the end of section 4 > that says: > > =E2=80=9CThe Figures in Sections 4.1, 4.2, and 4.3 replace the correspond= ing > Figures in RFC 8029 Sections 5.1, 5.2, and 5.3 respectively. The > updated figures contain explicitly defined length.=E2=80=9D > > There has also been an agreement to add this after the adoption. > > The working group adoption poll ends March 10, 2019. > > /Loa > > mpls wg co-chair > -- > > > Loa Andersson email: loa@pi.nu > Senior MPLS Expert > Bronze Dragon Consulting phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --000000000000d29e10058373471e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes/support.

Thanks,
Rakesh


On Wed, Feb 27, 2019 at 3:41 AM Loa Andersson= <loa@pi.nu> wrote:
Working Group,

This is to start a two week poll on adopting
draft-nainar-mpls-rfc8287-len-clarification
as a MPLS working group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls= @ietf.org). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

We have done an IPR poll for this document. All the co-authors and
contributors have responded to the IPR poll that they are unaware of any IPRs that relates to this draft.

There are no IPR disclosures against this document.

There has also been a discussion on adding text at the end of section 4
that says:

=E2=80=9CThe Figures in Sections 4.1, 4.2, and 4.3 replace the correspondin= g
Figures in RFC 8029=C2=A0 Sections 5.1, 5.2, and 5.3 respectively. The
updated figures contain explicitly defined length.=E2=80=9D

There has also been an agreement to add this after the adoption.

The working group adoption poll ends March 10, 2019.

/Loa

mpls wg co-chair
--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pho= ne: +46 739 81 21 64

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--000000000000d29e10058373471e-- From nobody Wed Mar 6 14:11:54 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991F0129508; Wed, 6 Mar 2019 14:11:52 -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_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 1QVEGqrgdlrP; Wed, 6 Mar 2019 14:11:50 -0800 (PST) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 9EC53124D68; Wed, 6 Mar 2019 14:11:50 -0800 (PST) Received: by mail-pg1-x52a.google.com with SMTP id r124so9518739pgr.3; Wed, 06 Mar 2019 14:11:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ekXFr6lUhxqqM/y2OqJSw5dVw9gnuCex9IJJmwktd1U=; b=e/2XGZSg0DNlSqhQxtONJfTNsv69LaVs3/abOEfrFeJUQXkDrEWNCCnMMBKEVabRAS oQaogAj0K1pPlmvHjVMjSmbiJUDpYnACmQMDuuf6Z45MZRIo6Zwbg1t9EYpArF9LG1E4 jWyTjaoBkmN8CDHkcDagF7cEFvENw1d3hIbOgJgAKQ1JMevZrFP1G5aBuEM019dyZoW+ 4SkfoD/PsH0nE3xirGu0Ucf4fVKee5X8UMVmqhvPSWMdRMjsCKiNXstWsUdl1iSooi9S fWKjIvBwJauhHYjwGkQK7vvYpt9jgYDtOgfsIMvxZhRL09gppKBeU+NShRtafonocz26 GcIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ekXFr6lUhxqqM/y2OqJSw5dVw9gnuCex9IJJmwktd1U=; b=UqFCVjm8y2/9b4K0Vr2tvRbHAiEZZ2dDFY8gZZDfQRnWtDFmUnK5+QoTbnvqj7E4Eg tkkL1W/EjSNgf10+6tzn+rb1SLCAtzFW58CbRpjZ66znZ8OuoqPBO3hCPm6wtqtt2j21 OCRlNhuc4xmOOM6n0KeNyVbIeWl+nVNrvGXbq4WZEUV91HeNFYbpZ/OEAs36YKa8rqSj kMurNSOnsthzvHNXjRN8uogi8nO7v3+1GGXfsKA2odcxBf543RZ6V5IpBnsKaOdaUxdt C1G8iIdtDZXYUrF1UjmYYqGea8oNo8KVMNM75Gt+M1t6mveuz6Xeg48FDszEU/jFIhjR FHAw== X-Gm-Message-State: APjAAAXl7C5lemOyBVOZXt9vJi/6l39pgjt1Q7Tdnoin7t8yIVkFGhq+ MrSQzAQPG1MsLk9quljCvRZ5jP3iPD0= X-Google-Smtp-Source: APXvYqxoJiIHb/CD1D/BHPw4rpnqpL+tXXZc8c5gLCY9/bvotd4f82A61TotDCVcXCj6NjvqZR0+zw== X-Received: by 2002:a63:4e05:: with SMTP id c5mr8469164pgb.393.1551910310252; Wed, 06 Mar 2019 14:11:50 -0800 (PST) Received: from [10.80.8.163] ([208.66.251.34]) by smtp.gmail.com with ESMTPSA id y14sm6089817pgs.47.2019.03.06.14.11.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Mar 2019 14:11:49 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Faisal Iqbal In-Reply-To: <19124c2d-c53b-5826-e7fa-b16616e7ef01@pi.nu> Date: Wed, 6 Mar 2019 14:11:48 -0800 Cc: "mpls@ietf.org" , "mpls-chairs@ietf.org" , draft-nainar-mpls-rfc8287-len-clarification@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3E59FB3A-79FB-497B-950E-AB92D708488F@gmail.com> References: <19124c2d-c53b-5826-e7fa-b16616e7ef01@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [mpls] working group adoption poll X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 22:11:53 -0000 Hi Loa, Support as co-author. Thanks, Faisal > On Feb 27, 2019, at 12:41 AM, Loa Andersson wrote: >=20 > Working Group, >=20 > This is to start a two week poll on adopting > draft-nainar-mpls-rfc8287-len-clarification > as a MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. >=20 > We have done an IPR poll for this document. All the co-authors and > contributors have responded to the IPR poll that they are unaware of = any > IPRs that relates to this draft. >=20 > There are no IPR disclosures against this document. >=20 > There has also been a discussion on adding text at the end of section = 4 > that says: >=20 > =E2=80=9CThe Figures in Sections 4.1, 4.2, and 4.3 replace the = corresponding > Figures in RFC 8029 Sections 5.1, 5.2, and 5.3 respectively. The > updated figures contain explicitly defined length.=E2=80=9D >=20 > There has also been an agreement to add this after the adoption. >=20 > The working group adoption poll ends March 10, 2019. >=20 > /Loa >=20 > mpls wg co-chair > --=20 >=20 >=20 > Loa Andersson email: loa@pi.nu > Senior MPLS Expert > Bronze Dragon Consulting phone: +46 739 81 21 64 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Mar 7 01:49:30 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F14D613135F for ; Thu, 7 Mar 2019 01:48:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1551952133; bh=BkmvfaIY5qD1ktxRyg57UPpe9pbUHX7j/oxMg9cx4xw=; h=From:To:Cc:Subject:Date; b=qDDW7Wo8M3MEAI5DqEOwnLOSrYS0V8nUUxOvR/QayZZ4YHOYPMFOXUNIQw2MQCrAf 1+D2nSfa6KK8XOzBPK1kXjkCKozm4EouOtGIly201FAXSE5ErhfeQXpJzCf7cYTeBn VpJ4TmuVHkrKPeKxmtD6UhOajp5alNAUIlMWzQQU= X-Original-To: mpls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Datatracker on behalf of Alissa Cooper To: "The IESG" Cc: draft-ietf-mpls-sfc@ietf.org, Loa Andersson , mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155192871009.13670.17888476379224873419.idtracker@ietfa.amsl.com> Date: Wed, 06 Mar 2019 19:18:30 -0800 Archived-At: Subject: [mpls] Alissa Cooper's Discuss on draft-ietf-mpls-sfc-05: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 09:48:57 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-mpls-sfc-05: 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-mpls-sfc/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Comparing the requirements in RFC 8300 Section 8.1 under "Single Domain Boundary" and the text in Section 15 of this document, it seems that the mechanism specified in this document is not subject to the same normative requirements as specified for the administrative boundaries of a network where MPLS is used as the transport encapsulation for NSH. What is the reasoning for that? I would have expected to see similar normative requirements here as in RFC 8300 Section 8.1. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Section 4.5 = OLD The application of SR to SFC was considered in early versions of the SR architecture [RFC8402] and the MPLS-SR specification [I-D.ietf-spring-segment-routing-mpls], but has since been moved out of those documents. NEW The application of SR to SFC was considered in early versions of the SR architecture [RFC8402] and the MPLS-SR specification [I-D.ietf-spring-segment-routing-mpls], but was not ultimately adopted. (I think this is about the ideas, not the organization of documents.) From nobody Thu Mar 7 01:50:08 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51892131417 for ; Thu, 7 Mar 2019 01:49:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1551952140; bh=BkmvfaIY5qD1ktxRyg57UPpe9pbUHX7j/oxMg9cx4xw=; h=From:To:Cc:Subject:Date; b=E639QEES9oyLJi17WgVaNJVVMzO1tR3ASZm8RhvST8lE1hBQsDXNipfv0hLZKcSgZ DG/v1mWFW9afvdQYnusGCBV6K+ui5yOeszmEgrBxTPel7kwnoTIFetYkZcbKC+EbcC tJZHLqwG1EcOBjr3eYaxhtOpfx3GcWGDzhdXDBc4= X-Original-To: mpls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Datatracker on behalf of Alissa Cooper To: "The IESG" Cc: draft-ietf-mpls-sfc@ietf.org, Loa Andersson , mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155193160518.13682.12438232337705583343.idtracker@ietfa.amsl.com> Date: Wed, 06 Mar 2019 20:06:45 -0800 Archived-At: Subject: [mpls] Alissa Cooper's Discuss on draft-ietf-mpls-sfc-05: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 09:49:04 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-mpls-sfc-05: 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-mpls-sfc/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Comparing the requirements in RFC 8300 Section 8.1 under "Single Domain Boundary" and the text in Section 15 of this document, it seems that the mechanism specified in this document is not subject to the same normative requirements as specified for the administrative boundaries of a network where MPLS is used as the transport encapsulation for NSH. What is the reasoning for that? I would have expected to see similar normative requirements here as in RFC 8300 Section 8.1. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Section 4.5 = OLD The application of SR to SFC was considered in early versions of the SR architecture [RFC8402] and the MPLS-SR specification [I-D.ietf-spring-segment-routing-mpls], but has since been moved out of those documents. NEW The application of SR to SFC was considered in early versions of the SR architecture [RFC8402] and the MPLS-SR specification [I-D.ietf-spring-segment-routing-mpls], but was not ultimately adopted. (I think this is about the ideas, not the organization of documents.) From nobody Thu Mar 7 01:50:56 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E931313C4 for ; Thu, 7 Mar 2019 01:49:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1551952148; bh=kPI8UUb3iu42mmXIXIcaezAO7lgk7D4TZTBLQeDZjqY=; h=From:To:Cc:Subject:Date; b=yvd1sf76cblP6MAQh5PpwdTHCTf94CIODzsh6cWT4plWewUY8UREDdZnY/aiPAMHu /fH47Psnp835n3oSc9s68o1fZVFdbpgp/2FrKnpnau4bNUFpzxzaoDEo9235mpGWmH UVHAAAqZQxftJDwqv4nkY6mYNjnSxGLgQVMWOuww= X-Original-To: mpls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Datatracker on behalf of Benjamin Kaduk To: "The IESG" Cc: draft-ietf-mpls-sfc@ietf.org, Loa Andersson , mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155193436776.13798.13710472280487229144.idtracker@ietfa.amsl.com> Date: Wed, 06 Mar 2019 20:52:47 -0800 Archived-At: Subject: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-sfc-05: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 09:49:13 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-mpls-sfc-05: 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-mpls-sfc/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for this easy-to-read document! The design is pretty elegant, but I think there are a few places that remain insufficiently specified so as to admit interoperable implementation. In particular, I don't think the TTL-handling behavior for the SF Label in the "label stacking" case is completely specified, though an apparent typo in Section 7 (see COMMENT) makes it hard to tell what was intended. In Section 8, we see that: When an SFF receives a packet containing an MPLS label stack, it checks whether it is processing an {SFP, SI} label pair for label swapping or a {context label, SFI index} label pair for label stacking. [...] What data source is consulted to make this check? The control plane? Is this distinction made on a per-node basis or a per-packet basis or otherwise? My first thought was that it's per-SFC-Context-Label, but we're not guaranteed that those values will be interpretable equivalently in the swapping or stacking usages, IIUC. I also support Alissa's DISCUSS (and the secdir reviewer makes similar comments). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Am I supposed to assume that the control plane sufficiently informs everyone whether they're an SFF, SFI, or neither? (Or does any given (virtual) device just inherently know?) Abstract (and Introduction) Multiprotocol Label Switching (MPLS) is a widely deployed forwarding technology that uses labels placed in a packet in a label stack to identify the forwarding actions to be taken at each hop through a network. Actions may include swapping or popping the labels as well, as using the labels to determine the next hop for forwarding the packet. [...] nit: no comma after "as well". This document describes how Service Function Chaining can be achieved in an MPLS network by means of a logical representation of the NSH in an MPLS label stack. That is, the NSH is not used, but the fields of the NSH are mapped to fields in the MPLS label stack. It does not deprecate or replace the NSH, but acknowledges that there may be a need for an interim deployment of SFC functionality in brownfield networks. Am I supposed to read this as that the NSH is the way of the future, and this mechanism is just a temporary interim measure? Section 4.3 It may be that a service function chain (as described in Section 4.1 allows some leeway in the choice of service function instances along the chain. However, it may be that a service classifier wishes to constrain the choice and this can be achieved using chain concatenation so that the first chain ends at the point of choice, This does not give any motivation for why a classifier might wish to constrain the choice. Section 5 The decision to use the control plane to indicate "label stacking" vs. "label swapping" semantics as opposed to an in-band signal seems to create a new opportunity for misconfiguration and consequent service misbehavior. I suppose it's not appreciably worse than any other way to configure the interpretation of the label field, though. S: The bottom of stack bit has its usual meaning in MPLS. It MUST be clear in the SFC Context label stack entry and MAY be set in the SF label stack entry depending on whether the label is the bottom of stack. I don't understand why this is only a MAY. Section 6 Under normal circumstances (with the exception of branching and reclassification - see [I-D.ietf-bess-nsh-bgp-control-plane]) the The word "reclassification" does not appear in the indicated reference. The following processing rules apply to the TTL field of the SF label stack entry, and are derived from section 2.2 of [RFC8300]: nit: we seem to capitalize "SF Label" Section 7 It's a bit unusual, style-wise, to have Section 6 introduce new terms for the SPI Label and SI Label that are specific to the swapping usage, and then have Section 7 just reuse the nominally generic terms from Section 5 as its own for the stacking usage. SFC Context Label: The Label field of the SFC Context label stack entry contains a label that delivers SFC context. This label may be used to indicate the SPI encoded as a 20 bit integer using the semantics of the SPI is exactly as defined in [RFC8300] and noting that in this case a system using MPLS representation of the logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or less than 16. This label may also be used to convey other SFC context-speific semantics such as indicating how to interpret the SF Label or how to forward the packet to the node that offers the SF. This "may also be used" behavior seems rather under-specified. TTL: The TTL fields in the SFC Context label stack entry SF label stack entry SHOULD be set to 1 as stated in Section 5, but MAY be set to larger values if the label indicated a forwarding operation towards the node that hosts the SF. What is "SFC Context label stack entry SF label stack entry"? It seems like there's a missing word or something. I note that section 5 defers to here for the TTL of the SF Label and we are either not saying anything or attempting to defer to Section 5, so this seems under-specified. Section 8 o If the current hop requires an {SFP, SI} and the next hop requires an {SFP, SI}, it selects an instance of the SF to be executed at the next hop, sets the SI label to the SI value of the next hop, and tunnels the packet to the SFF for that SFI. nit: I know the default behavior is to use the same SFP value, but (1) this should probably be stated explicitly, and (2) we've already talked about branching/etc. that could cause it to change. * If the top of the MPLS label stack contains a {context label, SFI label}, it tunnels the packet to the SFF indicated by the context label. nit: probably best to use "new top" for consistency with the preceding sub-bullet. Section 12.1 The SFC Metadata Label (as a set of three labels as indicated in Figure 4) may be present zero, one, or more times in an MPLS SFC packet. For MPLS label swapping, the SFC Metadata Labels are placed immediately after the basic unit of MPLS label stack for SFC as shown in Figure 5. For MPLS label stacking, the SFC Metadata Labels can be present zero, one, or more times and are placed at the bottom of the label stack as shown in Figure 6. The "may be present zero, one, or more times" appears twice. (I actually don't mind the internal redundancy of that phrase here, though, since all three cases are potentially relevant.) Section 12.2 Metadata Type: The type of the metadata present. Values for this field are taken from the "MD Types" registry maintained by IANA and defined in [RFC8300]. The "MD Types" registry I'm finding in RFC 8300 is defined to hold four-bit values; why do we need a 16-bit field to hold it here in the TLV? (I mean, "to keep the metadata itself aligned", sure, but having 12 reserved bits would do that, too.) Section 15 I agree with the secdir reviewer that the "trusted" nature of the classifier as a "trusted resource" could be further clarified. Where an SF is not encapsulation aware the encapsulation may be stripped by an SFC proxy nit: "encapsulation-aware" Thank you for the new text in the -05 prompted by the secdir review; it is a huge improvement! In addition to encryption, I'd probably also note that MPLS at present doesn't provide any cryptographic integrity protection on the headers. o The SFC-capable devices participating in an SFC system are responsible for verifying and protecting packets and their contents as well as providing other security capabilities that might be required in the particular system. Do I recall correctly that we currently don't specify any mechanisms for them to do so? If so, we probably need to note that this is currently in implementation-specific territory. I'd also suggest OLD: Thus, the security vulnerabilities are addressed (or should be addressed) in all the underlying technologies used by this design. NEW: Thus, this design relies on the component underlying technologies to address the potential security vulnerabilities, and documents the necessary protections (or risk of their absence) above. It does not include any native security mechanisms in-band with the MPLS encoding of the NSH functionality. (since "are addressed (or should be addressed)" is rather wishy-washy language). No known new security vulnerabilities are introduced by this design, It's probably worth stating what the reference point for the comparison is, just for clarity. (I assume it's the RFC8300 NSH.) Section 19.2 It seems that RFC 6790 needs to be a normative reference, since we are RECOMMENDED to insert Entropy Labels. From nobody Thu Mar 7 03:25:06 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C369713139D; Thu, 7 Mar 2019 03:24:57 -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] 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 rWOwpVkQiEhq; Thu, 7 Mar 2019 03:24:55 -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 082B5131391; Thu, 7 Mar 2019 03:24:54 -0800 (PST) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id x27BOq3k027539; Thu, 7 Mar 2019 11:24:52 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6091B22048; Thu, 7 Mar 2019 11:24:52 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id 539B422042; Thu, 7 Mar 2019 11:24:52 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id x27BOomX026264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Mar 2019 11:24:51 GMT Reply-To: From: "Adrian Farrel" To: "'Datatracker on behalf of Alissa Cooper'" , "'The IESG'" Cc: , "'Loa Andersson'" , , , References: <155193160518.13682.12438232337705583343.idtracker@ietfa.amsl.com> In-Reply-To: <155193160518.13682.12438232337705583343.idtracker@ietfa.amsl.com> Date: Thu, 7 Mar 2019 11:24:49 -0000 Organization: Old Dog Consulting Message-ID: <012901d4d4d8$60ea0180$22be0480$@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 Content-Language: en-gb Thread-Index: AQKlxTLn07BEOiTD/WT4iw2b8j2jOaReDCZA X-Originating-IP: 87.112.237.8 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-24474.007 X-TM-AS-Result: No--11.482-10.0-31-10 X-imss-scan-details: No--11.482-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24474.007 X-TMASE-Result: 10--11.481800-10.000000 X-TMASE-MatchedRID: 0dFPYP4mu5TxIbpQ8BhdbOYAh37ZsBDCC/ExpXrHizzW9R0dU1eYdALy tDvV39h+Nk2/rvTUAYa2XNLappcQzB6Hacd6Ohq7xZQoGMRGhhNK770EEUlgD1c/CedjlcvklpS lktUUlXlVvFaQ0zblDqN2rmJdCO/8Ueg0+48uLr3XIwmz2YEJxSTbbsi+pqSF31GU/N5W5BAzwy 2/CE6qxkqIvR+8MbK8ur9ofzgGMq9Iaqdfjxt0yu/nrSnCkbauh8Ytn75ClDOInvV8Dy0ZaGYpV UZH+UourbX6OmZCX9lmfpHOo37dNpHy7oM4lvOnICsP4rpeGcel9VzHf0qr7oiUfQ1FpaXVkj94 Ct/jm/3zA4zwo/bfKbZ2aoc5SUMBL3m5ejCdaFESuhBXNJb1dPHumXHGbVI8nQqircTOm4dvAi4 DK4Hn3FUeZ3rAJGMQB+I75w7Uv8q/WXZS/HqJ2kY41YX/o/8Ki2QFaYS1v20qtq5d3cxkNQwWxr 7XDKH83t7PzxvLBCgIZSYc7nORg86PGyuGkDA99vlbFrSfofEmDOjbC9Svdg== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] Alissa Cooper's Discuss on draft-ietf-mpls-sfc-05: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 11:24:58 -0000 Hey Alissa, Thanks for reading. > DISCUSS: > > Comparing the requirements in RFC 8300 Section 8.1 under "Single = Domain > Boundary" and the text in Section 15 of this document, it seems that = the > mechanism specified in this document is not subject to the same = normative > requirements as specified for the administrative boundaries of a = network where > MPLS is used as the transport encapsulation for NSH. What is the = reasoning for > that? I would have expected to see similar normative requirements here = as in > RFC 8300 Section 8.1. RFC 8300 is concerned with the forwarding plane, so (obviously) includes = normative language about packet handling. But it is worth noting that the term used in 8.1 is "NSH domain". However, the reference is back to the general SFC architecture in RFC = 7665. That's a more appropriate place to look for the constraints on = deploying SFC systems. 7665 defines an SFC-Enabled Domain as "A network or region of a network = that implements SFC. An SFC-enabled domain is limited to a single = network administrative domain." We should note that an "administrative = domain" is (probably?) not the same as a single AS: an administrative = domain is often partitioned into multiple ASes. We do say that "Discussion of the security properties of SFC networks = can be found in [RFC7665]. Further security discussion for the NSH and = its use is present in [RFC8300]." So we intend to inherit all the = security and deployment constraints. We also have... o The MPLS network is often considered to be a closed network such that insertion, modification, or inspection of packets by an outside party is not possible. This is particularly pertinent in the SFC context because [RFC7665] notes that "The architecture described herein is assumed to be applicable to a single network administrative domain." We could maybe tighten this by clarifying the concept of a closed = network. For example, o The MPLS network is often considered to be a closed network such that insertion, modification, or inspection of packets by an outside party is not possible. MPLS networks are operated with closed boundaries so that MPLS encapsulated packets are not=20 admitted to the network, and MPLS headers are stripped before=20 packets are forwarded from the network. This is particularly=20 pertinent in the SFC context because [RFC7665] notes that "The architecture described herein is assumed to be applicable to a single network administrative domain." Furthermore, [RFC8300] states that packets originating outside the SFC-enabled domain MUST be dropped if they contain an NSH and packets exiting the=20 SFC-enabled domain MUST be dropped if they contain an NSH. These constraints apply equally to the use of MPLS to encode a logical representation of the NSH. > COMMENT: > > =3D Section 4.5 =3D > > OLD > The application of SR to SFC was considered in early versions of the > SR architecture [RFC8402] and the MPLS-SR specification > [I-D.ietf-spring-segment-routing-mpls], but has since been moved out > of those documents. > > NEW > The application of SR to SFC was considered in early versions of the > SR architecture [RFC8402] and the MPLS-SR specification > [I-D.ietf-spring-segment-routing-mpls], but was not ultimately = adopted. > > (I think this is about the ideas, not the organization of documents.) Well, yes and no. There are, in fact, a number of drafts working their = way through the system that discuss the use of SR for SFC. Most of these = documents are not fully mature, but their proponents remain confident = that they will be adopted and become RFCs in the fullness of time. I = could list... - draft-filsfils-spring-srv6-network-programming - draft-guichard-spring-nsh-sr - draft-xuclad-spring-sr-service-programming There are probably others. So, SFC is clearly in scope for SR and the SPRING charter explicitly = says: o Source-routed stateless service chaining using SR-MPLS and SRv6 dataplanes. We included the reference to draft-xuclad-spring-sr-service-chaining = (now replaced by draft-xuclad-spring-sr-service-programming - we need to = make an update!) and believe that and the text cover the point. Cheers, Adrian From nobody Thu Mar 7 04:48:50 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3D013139D for ; Thu, 7 Mar 2019 04:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.247 X-Spam-Level: X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 tbZqwFA1i4J1 for ; Thu, 7 Mar 2019 04:48:33 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60134.outbound.protection.outlook.com [40.107.6.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C99D31313B8 for ; Thu, 7 Mar 2019 04:48:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zmYnBU7qiML1+48+9Jn3QGREC3LBRnbgUdFtenim6nw=; b=gl+T3ShMlvcRUPFhAAfM3iAmRMcHxlMsGbZh8DjREZ9GcogC5NXX6jqX86KFF/ysq4W9q1227KbEJ8cTYcTP5az60FiSLlabYbWRKAx9JmK2PzlzcAIET1d12M6P3QzcR+7A14/ufMpkueUBQs2lSuJ3VFvQyHRO8tfuXcCiq7w= Received: from VI1PR07MB4768.eurprd07.prod.outlook.com (20.177.57.155) by VI1PR07MB3885.eurprd07.prod.outlook.com (52.134.26.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.8; Thu, 7 Mar 2019 12:48:29 +0000 Received: from VI1PR07MB4768.eurprd07.prod.outlook.com ([fe80::a8c3:4982:8378:9a45]) by VI1PR07MB4768.eurprd07.prod.outlook.com ([fe80::a8c3:4982:8378:9a45%3]) with mapi id 15.20.1709.005; Thu, 7 Mar 2019 12:48:29 +0000 From: tom petch To: Tarek Saad CC: "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-static-yang-08.txt Thread-Index: AQHU03nqrT5RoCK7iEOJgW5Sst/P5g== Date: Thu, 7 Mar 2019 12:48:29 +0000 Message-ID: <068601d4d4e3$c5dc4980$4001a8c0@gateway.2wire.net> References: <155155736768.27158.1653954565392604255@ietfa.amsl.com> <016901d4d379$a1e91e60$4001a8c0@gateway.2wire.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0132.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9f::24) To VI1PR07MB4768.eurprd07.prod.outlook.com (2603:10a6:803:76::27) x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.156.84.54] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: db0bfd81-0aeb-47a8-696a-08d6a2fb32ca x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB3885; x-ms-traffictypediagnostic: VI1PR07MB3885: x-ms-exchange-purlcount: 7 x-microsoft-antispam-prvs: x-forefront-prvs: 096943F07A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(396003)(366004)(136003)(199004)(189003)(13464003)(6486002)(6512007)(86152003)(6306002)(44736005)(6436002)(26005)(9686003)(81816011)(76176011)(102836004)(6346003)(186003)(97736004)(81686011)(14454004)(966005)(478600001)(229853002)(25786009)(6116002)(476003)(86362001)(446003)(14496001)(3846002)(4326008)(53546011)(386003)(486006)(4720700003)(6916009)(6506007)(71190400001)(62236002)(44716002)(71200400001)(6246003)(53936002)(5660300002)(105586002)(61296003)(106356001)(68736007)(81156014)(52116002)(84392002)(50226002)(7736002)(305945005)(81166006)(8676002)(2906002)(8936002)(66574012)(256004)(1556002)(316002)(99286004)(66066001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB3885; H:VI1PR07MB4768.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: LCx0BeEwnIVMnly6ogoHrGH0CwVJSrzFi6ZWQyxB+sNvwTwQQWXiKoWG1vlr6mBtjjt4tX+0niOFhtnhkK/6ekqwSQlJ2wX0RomLiPup7SXDQylIHLJRb9R3a8S1VUeen7w6HM61IoS1IdBzXOfBVIBrGLzQd4gGEQuLuISCqNPFYK8SKqMJ7S5C1cscvDgfGG1U8NzDkWwQ/GfNAJ2I6FS+peVYdXzJ+c+kIsy0BZXscsbvnrCn2ZZUJIcY37B7AFN0B4ppBS3v444qs/LyOYhtZ9UkRdtn8KD8JqCAlbUw3oz8b4QYZMTtkhyMlze8DUtSYg3MBoHtZQwOM9kVR2lUMl+KKiG9roGDevUvsEjdJqp7REd0B1jQaPgKLYbld1VlFAcfC3hbY5HDye27kuHfTTN6Prkw0Dct4GR4/28= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: db0bfd81-0aeb-47a8-696a-08d6a2fb32ca X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2019 12:48:29.5663 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3885 Archived-At: Subject: Re: [mpls] I-D Action: draft-ietf-mpls-static-yang-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 12:48:35 -0000 VGFyZWsNCg0KT25lIHBvaW50IEkga2VlcCBub3RpY2luZyBidXQgZG8gbm90IHRoaW5rIEkgaGF2 ZSByYWlzZWQgYmVmb3JlIGlzDQoNCiAgICAgIHVuaXRzIG1icHM7DQogICAgICBkZXNjcmlwdGlv bg0KICAgICAgICAiQmFuZHdpZHRoIGluIE1icHMsDQoNCkkgaGF2ZSBrbm93biBzeXN0ZW1zIGZh aWwgYmVjYXVzZSBvbmUgcGFydHkgd2FzIHVzaW5nIG1icHMsIGFub3RoZXINCk1icHMsIHNvIHNl ZWluZyBhIG1peCBvZiB0aGUgdHdvLCBhcyBoZXJlLCByYWlzZXMgYSBmbGFnIGZvciBtZS4gIEkg bm90ZQ0KdGhhdA0KZHJhZnQtaWV0Zi10ZWFzLXlhbmctdGUtdHlwZXMNCmhhcw0KICAgICAgIHVu aXRzICJNYnBzIjsNCndoaWNoIEkgcHJlZmVyIC0gaWYgdGhleSByZWFsbHkgbWVhbiBNYnBzIGFu ZCBub3QgbWJwczsgSSBoYXZlIG15DQpkb3VidHMhIC0gYnV0IHRoZW4NCiBkcmFmdC1pZXRmLWwy c20tbDJ2cG4tc2VydmljZS1tb2RlbC0xMA0KaGFzDQogICAgICAgIHVuaXRzICJtYnBzIjsNCiAg ICAgICAgZGVmYXVsdCAiMTAiOyAgZGVzY3JpcHRpb24NCiAgICAgICAgICAiTEFDUCBzcGVlZC4g QnkgZGVmYXVsdCwgdGhlIGxhY3Agc3BlZWQgaXMgMTBNYnBzLiI7DQoNClBlcmhhcHMgaW4gdGhl IGNvbnRleHQgb2YgTVBMUyB0aGVyZSBpcyBubyBhbWJpZ3VpdHkgYnV0IGl0IHdvdWxkIGJlDQpu aWNlIHRvIGhhdmUgY29uc2lzdGVuY3kgYXQgbGVhc3Qgd2l0aGluIGFuIEktRC4NCg0KVG9tIFBl dGNoDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206ICJUYXJlayBTYWFkIiA8 dHNhYWQubmV0QGdtYWlsLmNvbT4NClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMDYsIDIwMTkgMjo1 MyBQTQ0KDQoNCj4gSGkgVG9tLA0KPg0KPiBBcyB1c3VhbCwgdGhhbmtzIGZvciB5b3VyIHJldmll dyBvbiB0aGlzIG9uZSBhbmQgZm9yIHlvdXIgcGF0aWVuY2UuDQpNb3JlDQo+IElubGluZS4uDQo+ DQo+IE9uIFR1ZSwgTWFyIDUsIDIwMTkgYXQgMTI6MzYgUE0gdG9tIHBldGNoIDxpZXRmY0BidGNv bm5lY3QuY29tPiB3cm90ZToNCj4NCj4gPiBBIGxvbmcgYW5kIHdpbmRpbmcgcm9hZCENCj4gPg0K PiA+ICBtb2R1bGUgaWV0Zi1tcGxzLXN0YXRpYyB7DQo+ID4gLi4uLi4NCj4gPiAgICBpbXBvcnQg aWV0Zi1yb3V0aW5nLXR5cGVzIHsNCj4gPiAgICAgIHByZWZpeCAicnQtdHlwZXMiOw0KPiA+ICAg ICAgcmVmZXJlbmNlICJSRkM4Mjk0OiBDb21tb24gWUFORyBEYXRhIFR5cGVzIjsNCj4gPg0KPiA+ IEkgc2VlLCBpbiB0aGUgUkZDIEluZGV4LA0KPiA+DQo+ID4gODI5NCBDb21tb24gWUFORyBEYXRh IFR5cGVzIGZvciB0aGUgUm91dGluZyBBcmVhLg0KPiA+IGkuZS4gYSBkaWZmZXJlbnQgdGl0bGUN Cj4gPg0KPiA+IFtUU106IHllcywgdW5mb3J0dW5hdGVseSBhIGRlamEgdnUgKGZpeGVkIGluIGFu b3RoZXIgbW9kdWxlKS4gV2UnbGwNCnRha2UNCj4gY2FyZSBvZiB0aGlzIGluIHRoZSBuZXcgdmVy c2lvbi4NCj4NCj4gPg0KPiA+IG1vZHVsZSBpZXRmLW1wbHMtc3RhdGljLWV4dGVuZGVkIHsNCj4g PiAuLi4uDQo+ID4gICBpbXBvcnQgaWV0Zi1yb3V0aW5nIHsgICAgcHJlZml4ICJydCI7DQo+ID4g ICAgIHJlZmVyZW5jZSAiUkZDNjk5MTogQ29tbW9uIFlBTkcgRGF0YSBUeXBlcyI7DQo+ID4gSSBz dWdnZXN0DQo+ID4gICAgICByZWZlcmVuY2UgIlJGQzgzNDk6IEEgWUFORyBEYXRhIE1vZGVsIGZv ciBSb3V0aW5nIE1hbmFnZW1lbnQiOw0KPiA+DQo+ID4gW1RTXTogeWVzLCB3aWxsIHRha2Ugb2Yg dGhpcy4NCj4NCj4gIHJlZmVyZW5jZSAiUkZDIFhYWFg6IEV4dGVuZGVkIFlBTkcgRGF0YSBNb2Rl bCBmb3IgTVBMUyBTdGF0aWMgTFNQcyI7DQo+ID4gdW0gLSBJIHNlZSB0aGlzIEktRCBhcyB0aXRs ZWQNCj4gPiBBIFlBTkcgRGF0YSBNb2RlbCBmb3IgTVBMUyBTdGF0aWMgTFNQcw0KPiA+DQo+ID4g W1RTXTogT0sgZm9yIHRoaXMgb25lIHRvby4NCj4NCj4gUmVnYXJkcywNCj4gVGFyZWsNCj4NCj4N Cj4gPg0KPiA+IFRvbSBQZXRjaA0KPiA+DQo+ID4NCj4gPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdl IC0tLS0tDQo+ID4gRnJvbTogPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCj4gPiBUbzogPGkt ZC1hbm5vdW5jZUBpZXRmLm9yZz4NCj4gPiBDYzogPG1wbHNAaWV0Zi5vcmc+DQo+ID4gU2VudDog U2F0dXJkYXksIE1hcmNoIDAyLCAyMDE5IDg6MDkgUE0NCj4gPg0KPiA+ID4gQSBOZXcgSW50ZXJu ZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+ ID4gZGlyZWN0b3JpZXMuDQo+ID4gPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBN dWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyBXRw0Kb2YNCj4gPiB0aGUgSUVURi4NCj4gPiA+ DQo+ID4gPiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IEEgWUFORyBEYXRhIE1vZGVsIGZvciBN UExTIFN0YXRpYyBMU1BzDQo+ID4gPiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IFRhcmVrIFNh YWQNCj4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgUmFrZXNoIEdhbmRoaQ0KPiA+ID4g ICAgICAgICAgICAgICAgICAgICAgICAgICBYdWZlbmcgTGl1DQo+ID4gPiAgICAgICAgICAgICAg ICAgICAgICAgICAgIFZpc2hudSBQYXZhbiBCZWVyYW0NCj4gPiA+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgSWdvciBCcnlza2luDQo+ID4gPiBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRm LW1wbHMtc3RhdGljLXlhbmctMDgudHh0DQo+ID4gPiBQYWdlcyAgICAgICAgICAgOiAxOA0KPiA+ ID4gRGF0ZSAgICAgICAgICAgIDogMjAxOS0wMy0wMg0KPiA+ID4NCj4gPiA+IEFic3RyYWN0Og0K PiA+ID4gICAgVGhpcyBkb2N1bWVudCBjb250YWlucyB0aGUgc3BlY2lmaWNhdGlvbiBmb3IgdGhl IE1QTFMgU3RhdGljDQpMYWJlbA0KPiA+ID4gICAgU3dpdGNoZWQgUGF0aHMgKExTUHMpIFlBTkcg bW9kZWwuICBUaGUgbW9kZWwgYWxsb3dzIGZvciB0aGUNCj4gPiA+ICAgIHByb3Zpc2lvbmluZyBv ZiBzdGF0aWMgTFNQKHMpIG9uIExhYmVsIEVkZ2UgUm91dGVyKHMpIExFUihzKQ0KYW5kDQo+ID4g PiAgICBMYWJlbCBTd2l0Y2hlZCBSb3V0ZXIocykgTFNSKHMpIGRldmljZXMgYWxvbmcgYSBMU1Ag cGF0aA0Kd2l0aG91dA0KPiA+IHRoZQ0KPiA+ID4gICAgZGVwZW5kZW5jeSBvbiBhbnkgc2lnbmFs aW5nIHByb3RvY29sLiAgVGhlIE1QTFMgU3RhdGljIExTUA0KbW9kZWwNCj4gPiA+ICAgIGF1Z21l bnRzIHRoZSBNUExTIGJhc2UgWUFORyBtb2RlbCB3aXRoIHNwZWNpZmljIGRhdGEgdG8NCmNvbmZp Z3VyZQ0KPiA+IGFuZA0KPiA+ID4gICAgbWFuYWdlIE1QTFMgU3RhdGljIExTUChzKS4NCj4gPiA+ DQo+ID4gPg0KPiA+ID4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMg ZHJhZnQgaXM6DQo+ID4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLW1wbHMtc3RhdGljLXlhbmcvDQo+ID4gPg0KPiA+ID4gVGhlcmUgYXJlIGFsc28gaHRtbGl6 ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPiA+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtbXBscy1zdGF0aWMteWFuZy0wOA0KPiA+ID4NCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1tcGxzLXN0YXRpYy15YW5nLTA4DQo+ ID4gPg0KPiA+ID4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxl IGF0Og0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYt bXBscy1zdGF0aWMteWFuZy0wOA0KPiA+ID4NCj4gPiA+DQo+ID4gPiBQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiA+IHN1 Ym1pc3Npb24NCj4gPiA+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQNCnRvb2xzLmlldGYub3JnLg0KPiA+ID4NCj4gPiA+IEludGVybmV0LURyYWZ0 cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPiA+IGZ0cDovL2Z0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IEktRC1Bbm5vdW5jZSBtYWls aW5nIGxpc3QNCj4gPiA+IEktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCj4gPiA+IEludGVybmV0LURy YWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQo+ID4gPiBv ciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPiA+DQo+ID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBtcGxzIG1h aWxpbmcgbGlzdA0KPiA+IG1wbHNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gPg0KPg0KDQo= From nobody Thu Mar 7 06:08:01 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A95E1288AB; Thu, 7 Mar 2019 06:08:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Datatracker on behalf of Eric Rescorla To: "The IESG" Cc: mpls@ietf.org, Loa Andersson , mpls-chairs@ietf.org, draft-ietf-mpls-sfc@ietf.org, loa@pi.nu X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155196768016.15999.10585144327198396679.idtracker@ietfa.amsl.com> Date: Thu, 07 Mar 2019 06:08:00 -0800 Archived-At: Subject: [mpls] Eric Rescorla's Discuss on draft-ietf-mpls-sfc-05: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 14:08:00 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-mpls-sfc-05: 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-mpls-sfc/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D5624 I have what may be a simple question or a real interop problem, as noted below. Hopefully it's the former and we can resolve it quickly. DETAIL S 13. > and defined in [RFC8300]. > > Metadata: The actual metadata formatted as described in whatever > document defines the metadata. This field is end-padded with zero > to three octets of zeroes to take it up to a four octet boundary. > What happens if the packet gets lost? Is there an ACK? How often should I send it? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- S 12.1. > --------------- > > Figure 4: The MPLS SFC Metadata Label > > The Metadata Label value is an index into a table of metadata that is > programmed into the network using in-band or out-of-band mechanisms. You note below that the network needs to be secure. You should also note that access to this table needs to be secure. From nobody Thu Mar 7 07:01:54 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F252212788F; Thu, 7 Mar 2019 07:01:45 -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] 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 eXbPXoH7LoYN; Thu, 7 Mar 2019 07:01:42 -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 194A2124B19; Thu, 7 Mar 2019 07:01:41 -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 x27F1cIb015305; Thu, 7 Mar 2019 15:01:38 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A4D9E22048; Thu, 7 Mar 2019 15:01:38 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id 97F8D22050; Thu, 7 Mar 2019 15:01:38 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id x27F1awV030878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Mar 2019 15:01:37 GMT Reply-To: From: "Adrian Farrel" To: "'Datatracker on behalf of Benjamin Kaduk'" , "'The IESG'" Cc: , "'Loa Andersson'" , , , References: <155193436776.13798.13710472280487229144.idtracker@ietfa.amsl.com> In-Reply-To: <155193436776.13798.13710472280487229144.idtracker@ietfa.amsl.com> Date: Thu, 7 Mar 2019 15:01:34 -0000 Organization: Old Dog Consulting Message-ID: <016201d4d4f6$a91e5e10$fb5b1a30$@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 Content-Language: en-gb Thread-Index: AQJzZtNl8vYRQS0gmn+2QKKbTlRPSqTC6nkw X-Originating-IP: 87.112.237.8 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-24476.000 X-TM-AS-Result: No--14.862-10.0-31-10 X-imss-scan-details: No--14.862-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24476.000 X-TMASE-Result: 10--14.861900-10.000000 X-TMASE-MatchedRID: IeZYkn8zfFrxIbpQ8BhdbOYAh37ZsBDC4PxBuU3oo1VnnK6mXN72m4Xa KD3s/mOLX381PW63B5R3Ujz9Y2wFbv/qdXNk/x2CSEQN/D/3cG5D3kXYiJVSRGtPyIJPorIP/WN Hyoh/70JATBuuLHMJM94iSPt7D56Cx6itxkruJHueEco05hssvpZ6zKu0q4rtCVuEXtlNqcsWDG fKwstuO7FURUnPT9poYklZyHW6Io9Lc0v2hlJrc0hwlOfYeSqxpPZLm8rbDqL/MiRbve4ADmpHK tkQBynK1gmgH2BfZB9SZ35rifQIkEcEDUwCfLjBdMz8d6rgprf0IUHuSVWDhyfO9H6Y/dy+gW0g uPJuEMgkWm+Lrc1V3D25TAv6dW8egZi/ORh+nqDIpMSwJEh3JfmDoOtMnt41TDoylMQmcK84OJj GEod9DcNiqkhxQHrcIThB18cWramst3r4DzbynW0PWqD0pliRu2rcU2ygxCDMcZL/toKwUjKC++ TafYORJ7wMgcRo6adGvh8ozKAwsvh6oIsjCAtnxqZyCOmsQ/MIgWIk/VdnUm2Bc3xI+NwYn8nvM xMvT29CUKtIVPUsaq6V8+F/tHZwmjmuEzwoMy27bScJeyAvlkrCzBY4ZVGj7ynGrUv2DpRaapAz RzPL/khBxDp1GjrTO/OBelOfHeMmMPeO88gK4HxTDivx6nwGq8zHTxACKxbFHcwKL6UE/yBXsL8 Q5BFBcDYnLMG33ck5FeaVnwctxcwrDggcQ6d1TVa+L3Zgqc4ZKp0SZ4P+dbKMPhGFsui/166Xb3 /Hw4PTRaQ8SsYqIGOeTis4ExHJcyF6DsnU3FWeAiCmPx4NwFkMvWAuahr8m5N2YHMD0b8MyrfP9 j+C1d934/rDAK3zhG2qikEpQGU7asfoVDS3WmqZRGot6djOX28JHK2uRZV3T9Mv2BpCilOInFnJ 4pFI X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-sfc-05: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 15:01:46 -0000 Hi Ben, Thanks for the detailed and thoughtful review. It's helpful. Answers below, and a new revision in my buffer. Adrian > DISCUSS: >=20 > Thank you for this easy-to-read document! The design is pretty > elegant, but I think there are a few places that remain insufficiently > specified so as to admit interoperable implementation. > > In particular, I don't think the TTL-handling behavior for the SF > Label in the "label stacking" case is completely specified, though > an apparent typo in Section 7 (see COMMENT) makes it hard to > tell what was intended. Fixing the typo would give us TTL: The TTL fields in the SFC Context label stack entry and in the=20 SF label stack entry SHOULD be set to 1 as stated in Section 5, but MAY be set to larger values if the label indicated a=20 forwarding operation towards the node that hosts the SF. In the SR case, it might not be necessary to tunnel the packets. In that = case the SFC Context label provides sufficient information to route the = packet through the SR network to the next SFF, but the TTL needs to = reflect the distance between SFFs. Do you think we need to add text to explain that? > In Section 8, we see that: > When an SFF receives a packet containing an MPLS label stack, it > checks whether it is processing an {SFP, SI} label pair for label > swapping or a {context label, SFI index} label pair for label > stacking. [...] > > What data source is consulted to make this check? The control > plane? Is this distinction made on a per-node basis or a per-packet > basis or otherwise? My first thought was that it's per-SFC-Context- > Label, but we're not guaranteed that those values will be = interpretable > equivalently in the swapping or stacking usages, IIUC. All SFFs are programmed with context for SFC labels. So they know, from = the top label (the SFP label or SFC context label) what form of = processing is involved. But, additionally, this is not going to be a rabid free-for-all. As = section 8 says a bit higher up... it is also possible that different parts of the network utilize swapping or popping such that an end-to-end service chain has to utilize a combination of both techniques. This "different parts of the network" is going to manifest as different = interfaces to the SFF. Lets upgrade the text to... When an SFF receives a packet containing an MPLS label stack, it checks from the context of the incoming interface, and from the SFP indicated by the top label whether it is processing an {SFP, SI}=20 label pair for label swapping or a {context label, SFI index} label pair for label stacking. It then selects the appropriate SFI to which to send the packet. When it receives the packet back from the SFI, it has four cases to consider. > I also support Alissa's DISCUSS (and the secdir reviewer makes > similar comments). OK. Did you see my response to Alissa? Does that solve it for you? > COMMENT: > > Am I supposed to assume that the control plane sufficiently informs > everyone whether they're an SFF, SFI, or neither? (Or does any given > (virtual) device just inherently know?) They know. Like a router knows it is not a telephone box. If (improbable) a device could be hawk or a handsaw depending on the = direction of the wind, then it would need to be configured to know what = it was doing. > Abstract (and Introduction) > > nit: no comma after "as well". Ack > This document describes how Service Function Chaining can be achieved > in an MPLS network by means of a logical representation of the NSH in > an MPLS label stack. That is, the NSH is not used, but the fields of > the NSH are mapped to fields in the MPLS label stack. It does not > deprecate or replace the NSH, but acknowledges that there may be a > need for an interim deployment of SFC functionality in brownfield > networks. > > Am I supposed to read this as that the NSH is the way of the=20 > future, and this mechanism is just a temporary interim measure? It is unclear. The full use of the NSH may require upgrades to some = forwarding plane devices. The IETF, through consensus, has approved the = NSH on the standards track via RFC 8300, and this document is not = intended to displace that or argue against that consensus. On the other = hand, there is a desire to achieve SFC function largely equivalent to = that provided by the NSH for more immediate deployment using existing = hardware. > Section 4.3 > > It may be that a service function chain (as described in Section 4.1 > allows some leeway in the choice of service function instances along > the chain. However, it may be that a service classifier wishes to > constrain the choice and this can be achieved using chain > concatenation so that the first chain ends at the point of choice, > > This does not give any motivation for why a classifier might wish to > constrain the choice. Yes. And I'm not sure that we should repeat the SFC architecture here, = nor develop some of the use cases. I would offer three possible reasons off the top of my head: - The tool constructing the SFP does not trust (or knows better than) = the SFF what SFI load-balancing decisions to make.=20 - The SFIs are stateful, but the SFF is not capable of maintaining state = as to which SFI is used for each SFP. - There is a bidirectional SFP and the same SFI must be used in each = direction. I'm not inclined to put into this document a description of reasons why = an SFP might or might not specify precise choice of SFIs. We just = describe how it can be done. > Section 5 > > The decision to use the control plane to indicate "label stacking" vs. > "label swapping" semantics as opposed to an in-band signal seems to > create a new opportunity for misconfiguration and consequent service > misbehavior. I suppose it's not appreciably worse than any other way = to > configure the interpretation of the label field, though. Not sure the comment applies to Section 5. But you're right, the use of = a control plane is subject to misconfiguration. However, I think we only = have the MPLS shim header to work with and unless we partition the label = space (which the MPLS architects would scream about) I think we are = stuck with what we have. > S: The bottom of stack bit has its usual meaning in MPLS. It MUST be > clear in the SFC Context label stack entry and MAY be set in the > SF label stack entry depending on whether the label is the bottom > of stack. > > I don't understand why this is only a MAY. This is probably why the use of requirements language sucks sometimes = =F0=9F=98=8A Perhaps we should expand this a bit and write... S: The bottom of stack bit has its usual meaning in MPLS. It MUST be clear in the SFC Context label stack entry. In the SF label stack entry it MUST be clear in all cases except when the label is the=20 bottom of stack, when it MUST be set. > Section 6 > > Under normal circumstances (with the exception of branching and > reclassification - see [I-D.ietf-bess-nsh-bgp-control-plane]) the > > The word "reclassification" does not appear in the indicated = reference. Dang! It's hyphenated in the other draft. Fixing it here. > The following processing rules apply to the TTL field of the SF = label > stack entry, and are derived from section 2.2 of [RFC8300]: > > nit: we seem to capitalize "SF Label" Yeah, hmmm/ Seem to have consistent use as: "SF Label" "SF label stack entry" The label stack entry is a construct of its own (and thus a compound = noun). > Section 7 > > It's a bit unusual, style-wise, to have Section 6 introduce new terms > for the SPI Label and SI Label that are specific to the swapping = usage, > and then have Section 7 just reuse the nominally generic terms from > Section 5 as its own for the stacking usage. I think this the consequence of some politics =E2=98=B9 Two concepts and drafts were merged, and no one wanted to give up their = language. We might sort that out, but I don't know anyone with the energy! I think the resultant text is clear enough, although as you say = "unusual". > SFC Context Label: The Label field of the SFC Context label stack > entry contains a label that delivers SFC context. This label may > be used to indicate the SPI encoded as a 20 bit integer using the > semantics of the SPI is exactly as defined in [RFC8300] and noting > that in this case a system using MPLS representation of the > logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or > less than 16. This label may also be used to convey other SFC > context-specific semantics such as indicating how to interpret the > SF Label or how to forward the packet to the node that offers the > SF. > > This "may also be used" behavior seems rather under-specified. Yeah. Adding "if so configured and coordinated with the controller that = programs the labels for the SFP." > TTL: The TTL fields in the SFC Context label stack entry SF label > stack entry SHOULD be set to 1 as stated in Section 5, but MAY be > set to larger values if the label indicated a forwarding operation > towards the node that hosts the SF. > > What is "SFC Context label stack entry SF label stack entry"? It = seems > like there's a missing word or something. I note that section 5 = defers > to here for the TTL of the SF Label and we are either not saying > anything or attempting to defer to Section 5, so this seems > under-specified. See your Discuss for resolution of both of these. > Section 8 > > o If the current hop requires an {SFP, SI} and the next hop requires > an {SFP, SI}, it selects an instance of the SF to be executed at > the next hop, sets the SI label to the SI value of the next hop, > and tunnels the packet to the SFF for that SFI. > > nit: I know the default behavior is to use the same SFP value, but (1) > this should probably be stated explicitly, and (2) we've already = talked > about branching/etc. that could cause it to change. OK o If the current hop requires an {SPI, SI} and the next hop requires an {SPI, SI}, it sets the SPI label according to the SFP to be traversed, selects an instance of the SF to be executed at the=20 next hop, sets the SI label to the SI value of the next hop, and tunnels the packet to the SFF for that SFI. > * If the top of the MPLS label stack contains a {context label, > SFI label}, it tunnels the packet to the SFF indicated by the > context label. > > nit: probably best to use "new top" for consistency with the preceding > sub-bullet. Sure > Section 12.1 > > The SFC Metadata Label (as a set of three labels as indicated in > Figure 4) may be present zero, one, or more times in an MPLS SFC > packet. For MPLS label swapping, the SFC Metadata Labels are placed > immediately after the basic unit of MPLS label stack for SFC as shown > in Figure 5. For MPLS label stacking, the SFC Metadata Labels can be > present zero, one, or more times and are placed at the bottom of the > label stack as shown in Figure 6. > > The "may be present zero, one, or more times" appears twice. > (I actually don't mind the internal redundancy of that phrase here, = though, > since all three cases are potentially relevant.) Yeah, but it's tacky. Tidied it up. > Section 12.2 > > Metadata Type: The type of the metadata present. Values for this > field are taken from the "MD Types" registry maintained by IANA > and defined in [RFC8300]. > > The "MD Types" registry I'm finding in RFC 8300 is defined to hold > four-bit values; why do we need a 16-bit field to hold it here in the > TLV? (I mean, "to keep the metadata itself aligned", sure, but having > 12 reserved bits would do that, too.) It's true.=20 We could have jumped either way. This way aligns with "normal" LTV processing. > Section 15 > > I agree with the secdir reviewer that the "trusted" nature of the > classifier as a "trusted resource" could be further clarified. I am having some trouble with the subtleties here. I suppose this means that a trusted resource is one that will not behave = in a way intended to cause harm to the network or to the payload data. = That means that when a classifier puts a packet onto an SFP (by applying = labels) its actions are not designed to cause the packet to avoid = particular SFPs or be blackholed or be diverted to other parts of the = network or SFs. The point here, I think, is that there is no way for the rest of the = network to have any visibility into the behaviour of the classifier, but = must accept packets as they are forwarded. Thus, the classifier is seen as within the MPLS trusted zone [RFC5920]. If you can suggest ways we could explain that to everyone's = satisfaction, then I'd be happy to add text. > Where an SF is not > encapsulation aware the encapsulation may be stripped by an SFC = proxy > > nit: "encapsulation-aware" Ack. > Thank you for the new text in the -05 prompted by the secdir review; = it > is a huge improvement! > In addition to encryption, I'd probably also note that MPLS at present > doesn't provide any cryptographic integrity protection on the headers. OK > o The SFC-capable devices participating in an SFC system are > responsible for verifying and protecting packets and their > contents as well as providing other security capabilities that > might be required in the particular system. > > Do I recall correctly that we currently don't specify any mechanisms = for > them to do so? If so, we probably need to note that this is currently > in implementation-specific territory. I believe this quote should say "payload packets and their contents." Of course, a host of mechanisms exist for that, but are out of scope. > I'd also suggest > OLD: > Thus, the security vulnerabilities are addressed (or should be > addressed) in all the underlying technologies used by this design. >NEW: > Thus, this design relies on the component underlying technologies to > address the potential security vulnerabilities, and documents the > necessary protections (or risk of their absence) above. It does not > include any native security mechanisms in-band with the MPLS > encoding of the NSH functionality. > (since "are addressed (or should be addressed)" is rather wishy-washy > language). OK. > No known new security vulnerabilities are introduced by this = design, > > It's probably worth stating what the reference point for the = comparison > is, just for clarity. (I assume it's the RFC8300 NSH.) OK Added 7665 and 8300. > Section 19.2 > > It seems that RFC 6790 needs to be a normative reference, since we are > RECOMMENDED to insert Entropy Labels. OK. Can do From nobody Thu Mar 7 07:05:28 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA00127967; Thu, 7 Mar 2019 07:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=RxFwIVmY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=1hITybRd 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 bm32HjnnClhG; Thu, 7 Mar 2019 07:05:11 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10322128664; Thu, 7 Mar 2019 07:05:11 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 115A636A2; Thu, 7 Mar 2019 10:05:09 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 07 Mar 2019 10:05:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm2; bh=JVPt0BS9+yxUb/hPydcwclS s+A0D9JnxI4ZP3wZQeAQ=; b=RxFwIVmYSUroqE1/jI0ZJyFrahMT1vQZUoXVlHI HJeTEhKhCJPfCg8/0Dt+5sb27GjmpxTHUBEidKhhYWRlEDW1XOSd6G6dcYlfTONF 4yz7eFbr1YXx2D7JsbJbeGGASX22eBe029J4m0fzN5kdnWsKy89wZv0OwQSVNIIb 7ZUu99h06as+0YMThn+Fh4Af7vEh0c/Wz2jPND5HRzz1yJvheEN5DDEoR28DOHuK gWAAgGN09LsU49+4v9S9jaSAQraBcBodBuFYizIiKr2AAsrV3Wsb0cfrS4yKVt9J /532E4MqYCQZ6E1snro/6s3LEbqm6wFSUufZPX9QTK6vrcA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm2; bh=JVPt0B S9+yxUb/hPydcwclSs+A0D9JnxI4ZP3wZQeAQ=; b=1hITybRdcg1djaV91HWT+r /KOo6QGXCVl0+rAn4DZwjEG2IAkTluX8XIazcTpFgp3XILGpJMI2TEdIjcb5E933 VtJzXUzkjEPdhxaE1k1zHTewpAJnnv5SHFT4x8KjrQUsaSzyws4gdOi6EYSs7yZ5 b4Wf9isTuYzgctSmp7+OpBywNxqRa9krAea+/jnzXRv1/YoreskfgGcUiTaMwGbi qN8Unx3YO9t1ijB7d4kiiNbW37m0YELrAqI6i1AuKeh11fjhjOQMg9+tVYssN9Op nHQMzvyPW4agldHOVJymj54Eok0Blj69FyyxkkZVFBDC0C7WdQmxciUGIWNBpACA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrfeekgdejgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtvdenucfhrhhomheptehlihhsshgr ucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucfkphepudejfe drfeekrdduudejrdejgeenucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgrsegt ohhophgvrhifrdhinhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.74]) by mail.messagingengine.com (Postfix) with ESMTPA id 7C1C710310; Thu, 7 Mar 2019 10:05:06 -0500 (EST) From: Alissa Cooper Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_381C6ADD-C769-42E4-98EF-118FEE8AF092" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 7 Mar 2019 10:05:03 -0500 In-Reply-To: <012901d4d4d8$60ea0180$22be0480$@olddog.co.uk> Cc: Datatracker on behalf of Alissa Cooper , IESG , IETF MPLS List , mpls-chairs@ietf.org, draft-ietf-mpls-sfc@ietf.org, loa@pi.nu To: Adrian Farrel References: <155193160518.13682.12438232337705583343.idtracker@ietfa.amsl.com> <012901d4d4d8$60ea0180$22be0480$@olddog.co.uk> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [mpls] Alissa Cooper's Discuss on draft-ietf-mpls-sfc-05: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 15:05:20 -0000 --Apple-Mail=_381C6ADD-C769-42E4-98EF-118FEE8AF092 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Adrian, > On Mar 7, 2019, at 6:24 AM, Adrian Farrel wrote: >=20 > Hey Alissa, >=20 > Thanks for reading. Any time. >=20 >> DISCUSS: >>=20 >> Comparing the requirements in RFC 8300 Section 8.1 under "Single = Domain >> Boundary" and the text in Section 15 of this document, it seems that = the >> mechanism specified in this document is not subject to the same = normative >> requirements as specified for the administrative boundaries of a = network where >> MPLS is used as the transport encapsulation for NSH. What is the = reasoning for >> that? I would have expected to see similar normative requirements = here as in >> RFC 8300 Section 8.1. >=20 > RFC 8300 is concerned with the forwarding plane, so (obviously) = includes normative language about packet handling. > But it is worth noting that the term used in 8.1 is "NSH domain". > However, the reference is back to the general SFC architecture in RFC = 7665. That's a more appropriate place to look for the constraints on = deploying SFC systems. >=20 > 7665 defines an SFC-Enabled Domain as "A network or region of a = network that implements SFC. An SFC-enabled domain is limited to a = single network administrative domain." We should note that an = "administrative domain" is (probably?) not the same as a single AS: an = administrative domain is often partitioned into multiple ASes. >=20 > We do say that "Discussion of the security properties of SFC networks = can be found in [RFC7665]. Further security discussion for the NSH and = its use is present in [RFC8300]." So we intend to inherit all the = security and deployment constraints. That should be made explicit then, in particular that the normative = security requirements from those documents apply to this specification. >=20 > We also have... > o The MPLS network is often considered to be a closed network such > that insertion, modification, or inspection of packets by an > outside party is not possible. This is particularly pertinent in > the SFC context because [RFC7665] notes that "The architecture > described herein is assumed to be applicable to a single network > administrative domain." >=20 > We could maybe tighten this by clarifying the concept of a closed = network. For example, > o The MPLS network is often considered to be a closed network such > that insertion, modification, or inspection of packets by an > outside party is not possible. MPLS networks are operated with > closed boundaries so that MPLS encapsulated packets are not=20 > admitted to the network, and MPLS headers are stripped before=20 > packets are forwarded from the network. This is particularly=20 > pertinent in the SFC context because [RFC7665] notes that "The > architecture described herein is assumed to be applicable to a > single network administrative domain." Furthermore, [RFC8300] > states that packets originating outside the SFC-enabled domain > MUST be dropped if they contain an NSH and packets exiting the=20 > SFC-enabled domain MUST be dropped if they contain an NSH. These > constraints apply equally to the use of MPLS to encode a logical > representation of the NSH. That works for me. >=20 >> COMMENT: >>=20 >> =3D Section 4.5 =3D >>=20 >> OLD >> The application of SR to SFC was considered in early versions of the >> SR architecture [RFC8402] and the MPLS-SR specification >> [I-D.ietf-spring-segment-routing-mpls], but has since been moved out >> of those documents. >>=20 >> NEW >> The application of SR to SFC was considered in early versions of the >> SR architecture [RFC8402] and the MPLS-SR specification >> [I-D.ietf-spring-segment-routing-mpls], but was not ultimately = adopted. >>=20 >> (I think this is about the ideas, not the organization of documents.) >=20 > Well, yes and no. There are, in fact, a number of drafts working their = way through the system that discuss the use of SR for SFC. Most of these = documents are not fully mature, but their proponents remain confident = that they will be adopted and become RFCs in the fullness of time. I = could list... > - draft-filsfils-spring-srv6-network-programming > - draft-guichard-spring-nsh-sr > - draft-xuclad-spring-sr-service-programming > There are probably others. This is not the impression the reader is left with from reading Section = 4.5. >=20 > So, SFC is clearly in scope for SR and the SPRING charter explicitly = says: > o Source-routed stateless service chaining using SR-MPLS > and SRv6 dataplanes. >=20 > We included the reference to draft-xuclad-spring-sr-service-chaining = (now replaced by draft-xuclad-spring-sr-service-programming - we need to = make an update!) and believe that and the text cover the point. I wonder about the archival value of the second paragraph altogether, = given the multiple streams of work on this. Perhaps it would make more = sense to just add a sentence to the end of the first paragraph noting = that implementation work was ongoing at the time of this writing, and = drop the second paragraph. Thanks, Alissa >=20 > Cheers, > Adrian --Apple-Mail=_381C6ADD-C769-42E4-98EF-118FEE8AF092 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Adrian,

On Mar 7, 2019, at 6:24 AM, Adrian Farrel = <adrian@olddog.co.uk> wrote:

Hey Alissa,

Thanks for reading.

Any = time.


DISCUSS:

Comparing the = requirements in RFC 8300 Section 8.1 under "Single Domain
Boundary" and the text in Section 15 of this document, it = seems that the
mechanism specified in this document is not = subject to the same normative
requirements as specified = for the administrative boundaries of a network where
MPLS = is used as the transport encapsulation for NSH. What is the reasoning = for
that? I would have expected to see similar normative = requirements here as in
RFC 8300 Section 8.1.

RFC 8300 is concerned with the forwarding plane, so = (obviously) includes normative language about packet handling.
But it is worth noting that the = term used in 8.1 is "NSH domain".
However, the reference is back to the general SFC = architecture in RFC 7665. That's a more appropriate place to look for = the constraints on deploying SFC systems.

7665 defines an SFC-Enabled Domain as "A network or region of = a network that implements SFC.  An SFC-enabled domain is limited to = a single network administrative domain." We should note that an = "administrative domain" is (probably?) not the same as a single AS: an = administrative domain is often partitioned into multiple ASes.

We do say that "Discussion of = the security properties of SFC networks can be found in [RFC7665]. =  Further security discussion for the NSH and its use is present in = [RFC8300]." So we intend to inherit all the security and deployment = constraints.

That = should be made explicit then, in particular that the normative security = requirements from those documents apply to this specification.


We also have...
  o  The MPLS = network is often considered to be a closed network such
     that= insertion, modification, or inspection of packets by an
     outside party is not possible. =  This is particularly pertinent in
     the SFC context because = [RFC7665] notes that "The architecture
     described herein is assumed to = be applicable to a single network
     administrative = domain."

We could = maybe tighten this by clarifying the concept of a closed network. For = example,
  o =  The MPLS network is often considered to be a closed network = such
     that insertion, modification, = or inspection of packets by an
     outside party is not possible. =  MPLS networks are operated with
     closed boundaries so that MPLS = encapsulated packets are not 
     admitted to the network, and = MPLS headers are stripped before 
     packets are forwarded from the = network.  This is particularly 
     pertinent in the SFC context = because [RFC7665] notes that "The
     architecture described herein = is assumed to be applicable to a
     single network administrative = domain."  Furthermore, [RFC8300]
     states that packets originating = outside the SFC-enabled domain
     MUST be dropped if they contain = an NSH and packets exiting the 
     SFC-enabled domain MUST be = dropped if they contain an NSH.  These
     constraints apply equally to = the use of MPLS to encode a logical
     representation of the = NSH.

That = works for me.


COMMENT:

=3D= Section 4.5 =3D

OLD
The = application of SR to SFC was considered in early versions of the
 SR architecture [RFC8402] and the MPLS-SR = specification
 [I-D.ietf-spring-segment-routing-mpls], = but has since been moved out
 of those documents.

NEW
The application of SR to SFC = was considered in early versions of the
 SR = architecture [RFC8402] and the MPLS-SR specification
 [I-D.ietf-spring-segment-routing-mpls], but was not = ultimately adopted.

(I think this is about = the ideas, not the organization of documents.)

Well, yes and no. There are, in fact, a number of drafts = working their way through the system that discuss the use of SR for SFC. = Most of these documents are not fully mature, but their proponents = remain confident that they will be adopted and become RFCs in the = fullness of time. I could list...
- draft-filsfils-spring-srv6-network-programming
- = draft-guichard-spring-nsh-sr
- draft-xuclad-spring-sr-service-programming
There are probably = others.

This = is not the impression the reader is left with from reading Section = 4.5.


So, SFC is = clearly in scope for SR and the SPRING charter explicitly = says:
 o = Source-routed stateless service chaining using SR-MPLS
    and SRv6 = dataplanes.

We included = the reference to draft-xuclad-spring-sr-service-chaining (now replaced = by draft-xuclad-spring-sr-service-programming - we need to make an = update!) and believe that and the text cover the point.

I wonder = about the archival value of the second paragraph altogether, given the = multiple streams of work on this. Perhaps it would make more sense to = just add a sentence to the end of the first paragraph noting that = implementation work was ongoing at the time of this writing, and drop = the second paragraph.

Thanks,
Alissa


Cheers,
Adrian

= --Apple-Mail=_381C6ADD-C769-42E4-98EF-118FEE8AF092-- From nobody Thu Mar 7 07:18:51 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11056129570; Thu, 7 Mar 2019 07:18: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, RCVD_IN_DNSWL_LOW=-0.7, 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 fv_YT9V1K6UA; Thu, 7 Mar 2019 07:18:41 -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 D8101128664; Thu, 7 Mar 2019 07:18:40 -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 x27FIbKn017035; Thu, 7 Mar 2019 15:18:38 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9C5F622042; Thu, 7 Mar 2019 15:18:37 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id 8665D22044; Thu, 7 Mar 2019 15:18:37 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id x27FIU3j008203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Mar 2019 15:18:32 GMT Reply-To: From: "Adrian Farrel" To: "'Datatracker on behalf of Martin Vigoureux'" , "'The IESG'" Cc: , , References: <155186757563.24618.8284642177706375034.idtracker@ietfa.amsl.com> In-Reply-To: <155186757563.24618.8284642177706375034.idtracker@ietfa.amsl.com> Date: Thu, 7 Mar 2019 15:18:28 -0000 Organization: Old Dog Consulting Message-ID: <017701d4d4f9$086b4520$1941cf60$@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 Content-Language: en-gb Thread-Index: AQCrbVAqMWWaUaEgKivLtWot7l5xIqhTFCrA X-Originating-IP: 87.112.237.8 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-24476.000 X-TM-AS-Result: No--17.223-10.0-31-10 X-imss-scan-details: No--17.223-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24476.000 X-TMASE-Result: 10--17.222700-10.000000 X-TMASE-MatchedRID: L8tZF6zWW2rxIbpQ8BhdbOYAh37ZsBDCLi2dwKiMR9xRXC4cX65cJCZK RIFpXA+BDv95a5ffqZv0+OmUKqID0AKVP1EUmtp5e5NWR5iixe1umrZiQVqsmQW3kEiN4kyfmtG /PWE2jkzsUepPGbNH8K0VV84ptAp6TPc9mhbHBd1+7IhLVmN+u3yzymMiw5QH1VNlojpO42g5d9 n04fLNZiWxb0EdRU2U+iHR6Lif927vXvInwhwK28K1Ib9JAALxdZPoD9V2prSbKItl61J/ybLn+ 0Vm71LcBXW7Bvonl8cLbigRnpKlKSPzRlrdFGDwlJoDb7wA2DbJ4YdyuydLW8LGYglzDlW3h6fG WY6pEO+H7Szq/aKVdw== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] Martin Vigoureux's Yes on draft-ietf-mpls-sfc-05: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 15:18:43 -0000 Hi Martin, Thanks for your thoughts. > COMMENT: > > I know I'm being too pernickety: As is your right =F0=9F=98=89 > You say: > o An SFF MUST decrement the TTL by one each time it performs a > forwarding lookup. > but in the examples you also say: > b. When the packet arrives at SFFa it strips any labels associated > with the tunnel that runs from the classifier to SFFa. SFFa > examines the top labels and matches the SPI/SI to identify that > the packet should be forwarded to SFa. The packet is forwarded > to SFa unmodified. > and > d. SFFa modifies the SI in the lower label stack entry (to 254) and > uses the SPI/SI to look up the forwarding instructions. > > It could look as two forwarding lookup, which, according to the > requirement, could lead to two TTL decrements. I do read in step b = that the packet is > forwarded unmodified, and read in Section 6 "The TTL in SF label stack = entry is > decremented once for each forwarding hop in the SFP" but still I = wonder if some > clarification wouldn't be beneficial. Oh, dear. Yes, you're right about the word "forward". It crops up too = often with too many meanings. I think the tidies solution is to change the first quote to say... An SFF MUST decrement the TTL by one each time it performs a lookup to forward a packet to the next SFF. > nits: > TTL: The TTL fields in the SFC Context label stack entry SF label > stack entry SHOULD be set to 1 as stated in Section 5, > Do you mean: SFC Context label stack entry *and* SF label stack entry = ? Yup > s/document)./document./ Ack _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Mar 7 07:34:38 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FB91277D0; Thu, 7 Mar 2019 07:34:30 -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] 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 SzMHn8EByhzA; Thu, 7 Mar 2019 07:34:28 -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 488D0124B19; Thu, 7 Mar 2019 07:34:28 -0800 (PST) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id x27FYLPd022056; Thu, 7 Mar 2019 15:34:21 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D89662204A; Thu, 7 Mar 2019 15:34:20 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id C292622048; Thu, 7 Mar 2019 15:34:20 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id x27FYFGR031673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Mar 2019 15:34:18 GMT Reply-To: From: "Adrian Farrel" To: "'Alissa Cooper'" Cc: "'Datatracker on behalf of Alissa Cooper'" , "'IESG'" , "'IETF MPLS List'" , , , References: <155193160518.13682.12438232337705583343.idtracker@ietfa.amsl.com> <012901d4d4d8$60ea0180$22be0480$@olddog.co.uk> In-Reply-To: Date: Thu, 7 Mar 2019 15:34:12 -0000 Organization: Old Dog Consulting Message-ID: <017a01d4d4fb$3a7d7f90$af787eb0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017B_01D4D4FB.3A7F0630" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQKlxTLn07BEOiTD/WT4iw2b8j2jOQIEjxYWAiQ4OU6kPSGQ0A== X-Originating-IP: 87.112.237.8 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-24476.000 X-TM-AS-Result: No--18.822-10.0-31-10 X-imss-scan-details: No--18.822-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24476.000 X-TMASE-Result: 10--18.822200-10.000000 X-TMASE-MatchedRID: 1ZHks2aQIkjxIbpQ8BhdbOYAh37ZsBDCH181YDtIVarW9R0dU1eYdALy tDvV39h+Nk2/rvTUAYa2XNLappcQzB6Hacd6Ohq7xZQoGMRGhhNK770EEUlgD1c/CedjlcvklpS lktUUlXlVvFaQ0zblDqN2rmJdCO/8IoY4ZTE7vhyzI1v7J4hEChlgDfyCPcHEV9eB8vnmKe/8k0 Y8XCLqDQnQeJLz0Ec+ys1f2ZkRNCOMB40CblSQ4khEDfw/93BugsuHb8lxzt5BDVeC8J7uwcbXN mojOJiwkJxgP3/yNu16v97VXslRaRAjnndaQMfLM0pZiLPQITre/DVpWKI5K914Aqe8EzF89t3o qadNMdEQY+auDXyVWOkFggkz1/z6qmLWaEinQeFWgOVCl/hN1bw2HnQG+TrAKAzGd8VeOIiK61Q 63RemBPk4X/uR4lHPSaVfaxxV948Ct8gNWNANfsG0UNgaZpYq6r+5bPPauHf5N0o2THGRZKgFX2 xz5NjH4j4lr4Wn4RisEFKef8ZUxqf50/sZyNUdupDIC9422DrTMQ/93vE8XUbaqUVvLFsi01gtG 8vJ6ZBbn6tefwlpGeGQF+JPeVuuMuYLNWSVlUgLPVZHwod7gO0ywEoYSNupnp9KgXcu34xWFBL5 r3scrXb4Bm7FqQnLXHn0K2CbIexTovWuZWqWkT5bo3ZLMFMHyiBjGmb09Nuyy072phvASaPFjJE Fr+ol4E9s12Gvf51cLc3sLtjOt9xWF9NJ0ly4KzfM9B6IRt7+efAnnZBiL6SszSEYZXnDpPuFdB ZT1XgjuA4bOvnCbiw/uYykF6clxkyiN4Xhycl+3BndfXUhXQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] Alissa Cooper's Discuss on draft-ietf-mpls-sfc-05: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 15:34:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_017B_01D4D4FB.3A7F0630 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Great. I think we have converged. Thanks for the Discussion. Adrian DISCUSS: Comparing the requirements in RFC 8300 Section 8.1 under "Single Domain Boundary" and the text in Section 15 of this document, it seems that the mechanism specified in this document is not subject to the same normative requirements as specified for the administrative boundaries of a network where MPLS is used as the transport encapsulation for NSH. What is the reasoning for that? I would have expected to see similar normative requirements here as in RFC 8300 Section 8.1. RFC 8300 is concerned with the forwarding plane, so (obviously) includes normative language about packet handling. But it is worth noting that the term used in 8.1 is "NSH domain". However, the reference is back to the general SFC architecture in RFC 7665. That's a more appropriate place to look for the constraints on deploying SFC systems. 7665 defines an SFC-Enabled Domain as "A network or region of a network that implements SFC. An SFC-enabled domain is limited to a single network administrative domain." We should note that an "administrative domain" is (probably?) not the same as a single AS: an administrative domain is often partitioned into multiple ASes. We do say that "Discussion of the security properties of SFC networks can be found in [RFC7665]. Further security discussion for the NSH and its use is present in [RFC8300]." So we intend to inherit all the security and deployment constraints. That should be made explicit then, in particular that the normative security requirements from those documents apply to this specification. [AF] That's easily done. COMMENT: = Section 4.5 = OLD The application of SR to SFC was considered in early versions of the SR architecture [RFC8402] and the MPLS-SR specification [I-D.ietf-spring-segment-routing-mpls], but has since been moved out of those documents. NEW The application of SR to SFC was considered in early versions of the SR architecture [RFC8402] and the MPLS-SR specification [I-D.ietf-spring-segment-routing-mpls], but was not ultimately adopted. (I think this is about the ideas, not the organization of documents.) Well, yes and no. There are, in fact, a number of drafts working their way through the system that discuss the use of SR for SFC. Most of these documents are not fully mature, but their proponents remain confident that they will be adopted and become RFCs in the fullness of time. I could list... - draft-filsfils-spring-srv6-network-programming - draft-guichard-spring-nsh-sr - draft-xuclad-spring-sr-service-programming There are probably others. This is not the impression the reader is left with from reading Section 4.5. So, SFC is clearly in scope for SR and the SPRING charter explicitly says: o Source-routed stateless service chaining using SR-MPLS and SRv6 dataplanes. We included the reference to draft-xuclad-spring-sr-service-chaining (now replaced by draft-xuclad-spring-sr-service-programming - we need to make an update!) and believe that and the text cover the point. I wonder about the archival value of the second paragraph altogether, given the multiple streams of work on this. Perhaps it would make more sense to just add a sentence to the end of the first paragraph noting that implementation work was ongoing at the time of this writing, and drop the second paragraph. [AF] Consider it done. ------=_NextPart_000_017B_01D4D4FB.3A7F0630 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Great. I think we have = converged.

Thanks for the = Discussion.

Adrian

DISCUSS:
=
Comparing the requirements in RFC 8300 Section 8.1 under = "Single Domain
Boundary" and the text in Section 15 of this = document, it seems that the
mechanism specified in this document is = not subject to the same normative
requirements as specified for the = administrative boundaries of a network where
MPLS is used as the = transport encapsulation for NSH. What is the reasoning for
that? I = would have expected to see similar normative requirements here as = in
RFC 8300 Section 8.1.


RFC = 8300 is concerned with the forwarding plane, so (obviously) includes = normative language about packet handling.
But it is worth noting that = the term used in 8.1 is "NSH domain".
However, the = reference is back to the general SFC architecture in RFC 7665. That's a = more appropriate place to look for the constraints on deploying SFC = systems.

7665 defines an SFC-Enabled Domain as "A network or = region of a network that implements SFC.  An SFC-enabled domain is = limited to a single network administrative domain." We should note = that an "administrative domain" is (probably?) not the same as = a single AS: an administrative domain is often partitioned into multiple = ASes.

We do say that "Discussion of the security properties = of SFC networks can be found in [RFC7665].  Further security = discussion for the NSH and its use is present in [RFC8300]." So we = intend to inherit all the security and deployment = constraints.

That should be made explicit then, in particular that = the normative security requirements from those documents apply to this = specification.

 

[AF] = That’s easily done.


COMMENT:=

=3D Section 4.5 =3D

OLD
The application of SR to SFC = was considered in early versions of the
 SR architecture = [RFC8402] and the MPLS-SR = specification
 [I-D.ietf-spring-segment-routing-mpls], but has = since been moved out
 of those documents.

NEW
The = application of SR to SFC was considered in early versions of = the
 SR architecture [RFC8402] and the MPLS-SR = specification
 [I-D.ietf-spring-segment-routing-mpls], but was = not ultimately adopted.

(I think this is about the ideas, not the = organization of documents.)


Well, = yes and no. There are, in fact, a number of drafts working their way = through the system that discuss the use of SR for SFC. Most of these = documents are not fully mature, but their proponents remain confident = that they will be adopted and become RFCs in the fullness of time. I = could list...
- draft-filsfils-spring-srv6-network-programming
- = draft-guichard-spring-nsh-sr
- = draft-xuclad-spring-sr-service-programming
There are probably = others.

This is not the impression the reader is left with = from reading Section 4.5.

So, SFC is = clearly in scope for SR and the SPRING charter explicitly = says:
 o Source-routed stateless service chaining using = SR-MPLS
    and SRv6 dataplanes.

We = included the reference to draft-xuclad-spring-sr-service-chaining (now = replaced by draft-xuclad-spring-sr-service-programming - we need to make = an update!) and believe that and the text cover the = point.

I wonder about the archival value of the second = paragraph altogether, given the multiple streams of work on this. = Perhaps it would make more sense to just add a sentence to the end of = the first paragraph noting that implementation work was ongoing at the = time of this writing, and drop the second paragraph.

 

[AF] = Consider it done.

------=_NextPart_000_017B_01D4D4FB.3A7F0630-- From nobody Thu Mar 7 07:42:27 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE81D1313F5; Thu, 7 Mar 2019 07:42:25 -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] 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 PuJYUfzEs-an; Thu, 7 Mar 2019 07:42:24 -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 D1AC11313DE; Thu, 7 Mar 2019 07:42:23 -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 x27FgJUB016107; Thu, 7 Mar 2019 15:42:21 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 89BD32203A; Thu, 7 Mar 2019 15:42:21 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 7E57322042; Thu, 7 Mar 2019 15:42:21 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id x27FgBfe014751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Mar 2019 15:42:15 GMT Reply-To: From: "Adrian Farrel" To: "'The IESG'" Cc: , , References: <155196768016.15999.10585144327198396679.idtracker@ietfa.amsl.com> In-Reply-To: <155196768016.15999.10585144327198396679.idtracker@ietfa.amsl.com> Date: Thu, 7 Mar 2019 15:42:07 -0000 Organization: Old Dog Consulting Message-ID: <018401d4d4fc$581475d0$083d6170$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQHuEEooEDNys56SgSz6gC1u6beC7qXN1SMQ X-Originating-IP: 87.112.237.8 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-24476.000 X-TM-AS-Result: No--14.754-10.0-31-10 X-imss-scan-details: No--14.754-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24476.000 X-TMASE-Result: 10--14.754400-10.000000 X-TMASE-MatchedRID: y/2oPz6gbvjxIbpQ8BhdbOYAh37ZsBDC0i/hFXziUdM0QmmUihPzrIuy XZ8/ROb4Gp8kmQmE0VAH75OaJJ1WU3ZFqfLxlafeCDuvg040bNwrHkgIan9a0fgnJH5vm2+gxGS h4nc4VFyhiTUrlW9Gg4BH6yFwyE6p6AmTKL8Tl2/4vYawCsCC2hNzcbBs7azLWabPstVV86mlGs yRp40hY8yVrKX5W8M1lFieF0i0o5p/JtSSO8GR9QdOQdS09jPF8lW420oy1gwwplGJ7NxS0/m0Y T+bdWquT5dYubiiJHl7/ppjELPtsk1+zyfzlN7y/sToY2qzpx7af1N18C+ZArDszp3K5gqDjocz muoPCq2iQTRSLBMLOHcGNO2USSo0UcsFmibe+Xx4LqXwj4w/q2dpB61dVpJP X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] Eric Rescorla's Discuss on draft-ietf-mpls-sfc-05: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 15:42:26 -0000 Thanks Ekr, that is an exceptionally good catch. It is both a simple problem and a real problem. A fix is going to take some thought and at least a few words. At a quick glance, I think the issue would at least get caught when an attempt to use the metadata was made (the index would not find an entry). That would cause an error to be flagged. But there are "update" cases that would not work. Adrian > DISCUSS: > > I have what may be a simple question or a real interop problem, > as noted below. Hopefully it's the former and we can resolve it quickly. > > DETAIL > S 13. > and defined in [RFC8300]. > > Metadata: The actual metadata formatted as described in whatever > document defines the metadata. This field is end-padded with zero > to three octets of zeroes to take it up to a four octet boundary. > > What happens if the packet gets lost? Is there an ACK? How often > should I send it? > > > COMMENT: > > S 12.1. > --------------- > > Figure 4: The MPLS SFC Metadata Label > > The Metadata Label value is an index into a table of metadata that is > programmed into the network using in-band or out-of-band mechanisms. > > You note below that the network needs to be secure. You should also > note that access to this table needs to be secure. Yes. Easy addition to Section 15 From nobody Thu Mar 7 07:50:46 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B065131446 for ; Thu, 7 Mar 2019 07:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 BEHknU1xAcYU for ; Thu, 7 Mar 2019 07:50:41 -0800 (PST) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 7C56313143F for ; Thu, 7 Mar 2019 07:50:39 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id 199so14666415ljj.5 for ; Thu, 07 Mar 2019 07:50:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qj+GwxbPweB5n9yvey44Oq4oO0aP6xRjmyftlsv73dg=; b=ZGU6JIIxgwwxkjzfrTNclTiJ56PDWsYSMbsa+T2NhZR/SOjkfiuVqo7tz9PG2Wccmi +mm7KwAhGNJwaYDqE7w9JMesiodsh+PLGz70m1oRZb8NqdUVOB7g6XkZhHaPTZnDQ5/c TlalLt7eAWXly6++qZUQt+DRjzM7Mox5U9JgzzHJvIRrQLW4GVjSHbJMXivwRnj2fcKd yVtk39oXPO5sZspD7j3iRBO/aptl0Iv5Pnnx5Ugoc+bHGkmFEETMTKwCZvIiOXbe/EV9 3zIzlk1qfwjYRVB5/pbWTWYGh5oq7OEg7IZGvRLWPXpjPzy14hrKUxOZHYnRGkFbjyOI 5NOQ== 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=qj+GwxbPweB5n9yvey44Oq4oO0aP6xRjmyftlsv73dg=; b=HoU8N+Z7NT4w1CXizpJvEE2eTsJwqePB7S1LBoRqtE8L7Uzdum1un2hQzc3fTxBZer TMUffGSaliDiwTBSWib7FMbbReffPbPnX1i/b5Zej8+0wsedrSnllc2WoEq+wLPQbQ9V VUBdLB/5yNBkcKV9txnqYHkpQdD4MV/OKVSenCrVRWWdnZkUepiL9dDpFe9gieefOU6r fs5B5uUf0alfsqMnIzT5jDYJnjg4EG01cwtdUHpsB76kN+rNU2+Goi7JfaRg64WSaYbc zgrI5II/eMTKu8oEo4nM/8uQtlfEWbZ4Q80DFQr40LO163IcIZcYJQQmOjf4hQv321k2 Xczg== X-Gm-Message-State: APjAAAWZhk42c2lRqrKprR8CNYPs7Oi4GiNYd7bjsQjZzrAkIsC+26Oc XO2sUjMiEbh1mb7SLUQm9iEip5HF3ajDg3vqN6aHAw== X-Google-Smtp-Source: APXvYqxPzJAitoHcAc1J/jD3imQRWn5r/4yRbCX6VqqQLX7eQaZ6wc7mbtto/EWAX3NPKhHFaAsWADV1LCIkwfociG0= X-Received: by 2002:a2e:47c4:: with SMTP id u187mr6256451lja.10.1551973836496; Thu, 07 Mar 2019 07:50:36 -0800 (PST) MIME-Version: 1.0 References: <155196768016.15999.10585144327198396679.idtracker@ietfa.amsl.com> <018401d4d4fc$581475d0$083d6170$@olddog.co.uk> In-Reply-To: <018401d4d4fc$581475d0$083d6170$@olddog.co.uk> From: Eric Rescorla Date: Thu, 7 Mar 2019 07:50:00 -0800 Message-ID: To: Adrian Farrel Cc: The IESG , mpls@ietf.org, mpls-chairs , draft-ietf-mpls-sfc@ietf.org Content-Type: multipart/alternative; boundary="00000000000039b6e50583831109" Archived-At: Subject: Re: [mpls] Eric Rescorla's Discuss on draft-ietf-mpls-sfc-05: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 15:50:44 -0000 --00000000000039b6e50583831109 Content-Type: text/plain; charset="UTF-8" On Thu, Mar 7, 2019 at 7:42 AM Adrian Farrel wrote: > Thanks Ekr, that is an exceptionally good catch. > Glad to be able to add value :) > It is both a simple problem and a real problem. > > A fix is going to take some thought and at least a few words. > > At a quick glance, I think the issue would at least get caught when an > attempt to use the metadata was made (the index would not find an entry). > That would cause an error to be flagged. > > But there are "update" cases that would not work. > Thanks. I'll probably be gone when this comes back, but I trust my successors to handle this (also, I don't think I have any special expertise here on how to fix this; I just happened to notice it). -Ekr > Adrian > > > DISCUSS: > > > > I have what may be a simple question or a real interop problem, > > as noted below. Hopefully it's the former and we can resolve it quickly. > > > > DETAIL > > S 13. > > and defined in [RFC8300]. > > > > Metadata: The actual metadata formatted as described in whatever > > document defines the metadata. This field is end-padded with > zero > > to three octets of zeroes to take it up to a four octet boundary. > > > > What happens if the packet gets lost? Is there an ACK? How often > > should I send it? > > > > > > COMMENT: > > > > S 12.1. > > --------------- > > > > Figure 4: The MPLS SFC Metadata Label > > > > The Metadata Label value is an index into a table of metadata that > is > > programmed into the network using in-band or out-of-band mechanisms. > > > > You note below that the network needs to be secure. You should also > > note that access to this table needs to be secure. > > Yes. Easy addition to Section 15 > > --00000000000039b6e50583831109 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Mar 7, 2019 at 7:42 AM Adrian= Farrel <adrian@olddog.co.uk&= gt; wrote:
Thank= s Ekr, that is an exceptionally good catch.

=
Glad to be able to add value :)


It is both a simple problem and a real problem.

A fix is going to take some thought and at least a few words.

At a quick glance, I think the issue would at least get caught when an
attempt to use the metadata was made (the index would not find an entry). That would cause an error to be flagged.

But there are "update" cases that would not work.

Thanks. I'll probably be gone when this comes back= , but I trust my successors
to handle this (also, I don't thi= nk I have any special expertise here on how
to fix this; I just h= appened to notice it).

-Ekr


Adrian

> DISCUSS:
>
> I have what may be a simple question or a real interop problem,
> as noted below. Hopefully it's the former and we can resolve it qu= ickly.
>
> DETAIL
> S 13.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and defined in [RFC8300].
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 Metadata:=C2=A0 The actual metadata formatted as d= escribed in whatever
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0document defines the metadata.=C2=A0 = This field is end-padded with zero
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to three octets of zeroes to take it = up to a four octet boundary.
>=C2=A0 =C2=A0
> What happens if the packet gets lost? Is there an ACK? How often
> should I send it?
>
>
> COMMENT:
>
> S 12.1.
>=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 Figure 4: The MPLS SFC Metadata Label
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 The Metadata Label value is an index into a table = of metadata that is
>=C2=A0 =C2=A0 =C2=A0 programmed into the network using in-band or out-o= f-band mechanisms.
>
> You note below that the network needs to be secure. You should also > note that access to this table needs to be secure.

Yes. Easy addition to Section 15

--00000000000039b6e50583831109-- From nobody Thu Mar 7 08:34:30 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D832127971; Thu, 7 Mar 2019 08:34:28 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=mit.edu 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 2cC8Zwbd0KGS; Thu, 7 Mar 2019 08:34:24 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810132.outbound.protection.outlook.com [40.107.81.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A6EF12788F; Thu, 7 Mar 2019 08:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6v9i/3PvmiWrfWIRwD14q5xFLGvwxUDG81z2sFM7G6k=; b=jsRw3P+VWjzSeaUhay9omPSSJ+3SoGpOUEAxML25PGXHXEpeAKfJKXqqfr55eLdIcUFsAWqCH2p17lmA06EQ2JGVh8YYwjDYgQ2wZFh1ok5SEd3abNMfnHfW+7UKeEZlcd1Arc0QfT7zE1pgsboZZMUjSK6FOjOYPpodvx8FQgI= Received: from MWHPR01CA0029.prod.exchangelabs.com (2603:10b6:300:101::15) by DM6PR01MB4857.prod.exchangelabs.com (2603:10b6:5:6d::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.16; Thu, 7 Mar 2019 16:34:19 +0000 Received: from BY2NAM03FT034.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::201) by MWHPR01CA0029.outlook.office365.com (2603:10b6:300:101::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1686.18 via Frontend Transport; Thu, 7 Mar 2019 16:34:18 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; pi.nu; dkim=none (message not signed) header.d=none;pi.nu; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT034.mail.protection.outlook.com (10.152.84.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Thu, 7 Mar 2019 16:34:16 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x27GYBvk015984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 7 Mar 2019 11:34:13 -0500 Date: Thu, 7 Mar 2019 10:34:10 -0600 From: Benjamin Kaduk To: Adrian Farrel CC: 'Datatracker on behalf of Benjamin Kaduk' , 'The IESG' , , , , Message-ID: <20190307163410.GA9824@kduck.mit.edu> References: <155193436776.13798.13710472280487229144.idtracker@ietfa.amsl.com> <016201d4d4f6$a91e5e10$fb5b1a30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <016201d4d4f6$a91e5e10$fb5b1a30$@olddog.co.uk> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(396003)(136003)(2980300002)(51444003)(199004)(189003)(51914003)(1076003)(53416004)(106466001)(55016002)(66574012)(356004)(54906003)(305945005)(5660300002)(246002)(229853002)(2486003)(6916009)(478600001)(26826003)(33656002)(8676002)(23676004)(7696005)(76176011)(106002)(104016004)(8936002)(6246003)(47776003)(26005)(36906005)(956004)(126002)(2870700001)(316002)(476003)(336012)(11346002)(786003)(75432002)(14444005)(426003)(186003)(446003)(58126008)(486006)(4326008)(86362001)(50466002)(30864003)(88552002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR01MB4857; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 03c23924-cdf5-4765-2c7d-08d6a31abe36 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:DM6PR01MB4857; X-MS-TrafficTypeDiagnostic: DM6PR01MB4857: X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB4857; 20:p4a/05suPCmcFCQciZz1QA7e3rVgzCQ17nyd8VXmD8JZRLBOlOOUzm9Y/HVf1IXk75l66yrpO6gdrLvRMlgq4VQheS2BQjJaitwi6ULcBAS4Rq8lzuWr03s3/kkXJruuqqTvzqZbXVj4BlI6RoYkHUhd8TT4mjWSRnZae7T8HOfQZc2REAuEHt1QR2LZLTUun7nbBgpDXg4XmbSHT3aIxJqcSEHyXbpRL/43W33YyRp59qbKA9liVaUqQVsqpiRXT93yVsHK1MEZeTltLGWJK6Pij7z6kLv4UY/SxuKrJUsq+91EnESvJrG0IXYR3oSqtUB1T701cQzJql7WWcRixWR5lQhvVNN9AabS2HwGwd26yziMzTdNxU5kEnqkL2Z5161XA7ZjPYaTvctBhS6+y3M9QP2E5niMUaD5XFONEPWxgNmx5aG7FHd8VMCQ6CCgRKFrNHfC76rXBe3gBFZSoKgbNM/gZINfxJI5vduYYhW29tZn4MUdgG0WxKrkxym17dcrX9KDfDIxvUa1qv5EQvP3h1BPwWbbNSoEmf8MAiyEQv9tfFzP5zFMZkqskfs9OED1lkKR1eHYfA0MzW2TyzG0xkUxWi4H6KWDJli+bq8= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 096943F07A X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTZQUjAxTUI0ODU3OzIzOnZ6SzlqZGErRUNNOXgxaElDRjQ2M2tDcnFm?= =?utf-8?B?TGk3ZkRpaWpxbVVkZk5VMTMvTGZrYTE4Z1NvdFZaZ0hibUJvTjE3bmRVTVdB?= =?utf-8?B?ellzSnR3cWU1ZzV0bEVlTi8vVUpyd3ZHV1o2cGNuQ0tNV21JN09acU10Vkhh?= =?utf-8?B?S1p5NHk4UGJzUUoyTy9ZVEx2TllpZ1FUWEVqd0RpYWhpcnhscy9KRktRUUVi?= =?utf-8?B?a3p2bnVpelVPOUx6Mks5bHZpc0Jzai9CNmVBWnljQUFtVndmUGoyMW8wcGNp?= =?utf-8?B?UUV2Y2JJMjRXMUczNnFLWVQydHdxa0MxQ2Vtb0Q3aWdLV3AxU01waUtRdnNP?= =?utf-8?B?RnYxSkZscXI2Ly8yZDNwUW5vS3JpajJuTGhmMENlOXpnNkZVd3ZRbitza0J1?= =?utf-8?B?dG9nek4vRjNVbHZnNVAyanZLOGxHOXMzclYxcHdIWiszdWt0Rkp1dTVBL1dC?= =?utf-8?B?dm85ZkhMY0cyd1kzZmpMd0VkQ2wza3U1MjRvcVF3NFZ2dG1XdUwzTG1yNFlM?= =?utf-8?B?TmhEbldZejVOZU1lVmJVaXcyNngrQlFCdGQ2U2NaOGRYZEs0VGl3c2RoZ2hQ?= =?utf-8?B?YUlKNUYxTXBVTG10bEpmRXo3eFVnUGNaL2I1Z25XczU5cGx6SC9scVV5bzcy?= =?utf-8?B?UXA1ZDM2aHVQYmJUYUhpaXdYbEhuNTNpejZoUERKTkVSb1RCTE9RdUlxYVIz?= =?utf-8?B?NzFGVFdKUjhyV0xRU0xXanBTOThaREdOMkJkZnRleXNFbFltZURKRThHdnBG?= =?utf-8?B?blVmMU9IampYdmkva1htekNOa2pHTmNiY1pNay8zQXN2N1BKUnNMSWc4cEEx?= =?utf-8?B?cmE2dHE4VEd0eVk2WnlEZUMyU2lHUzZ4OFBzb0MxbS9wU2tTcUxaOXlKM21z?= =?utf-8?B?UlRPWG5TYy9XT0dvOFBvb0ZQUER5czY4ZnRzREFNWkF3Z2t3Ykt1enVGSUZ6?= =?utf-8?B?NnRhM3l1bWRCWUVEdTRFTU5meUZXaU85RVV6SnZSYVNnUGROUDhYZUFNUjhC?= =?utf-8?B?QXBFcG5YdHFNVWdINVdnc1lLL3lEM05lMzVETmZoUE9ZaU5HUkhPa0Vxa3lY?= =?utf-8?B?cnFEZ1lQZlh3MG1uVzl4QnVOWW9LNFd3RDF4NnFDNWtHRTMwODdueXFPQ1Y3?= =?utf-8?B?eTRwRHFJeDhJU2pNUkxWVS9sYWN1aVVvYVlxNXVvYnI1Q2RxaXJRNHBzRUZr?= =?utf-8?B?QzVUR0xnNVRySE5hYXRCV1FPZXIwTUVTdjlGSjlqQlEwL0JYd3RaOE1mT1pG?= =?utf-8?B?dkEra1Y0YWdQVkdZcDdMRGZPYzhGYjR6dlJJNERXZG5wL1M4VEZzcGhKSlJV?= =?utf-8?B?TlhGaGhHYlEvUEFKSmlMb0dXbHpva2hVSExiQWV3NkRtREFGeHBWTEpOUTBl?= =?utf-8?B?RGRjWDBJZFdNR0pKbVFXUGN0eWt1a0N0L1d6ckxlcWZ3emdJYTd3NkNkajVq?= =?utf-8?B?UHl3NDA4WTZCVFp5eE5lei80MjdvdThwWlc0ZHg5SFZnVDdwSnhqNDhLVU1V?= =?utf-8?B?elNXWHI1SEtha3Bxd3pXbm9UbWxZTHVwaEhpVlNpYmZOaGY2T3Z2MVlZWjRS?= =?utf-8?B?Qk5VK2ZGcDZ4REpNeEtjbnQ1Zmg0ZGRVU3VWd05UaEJ4M1ZScHFHbjROSHJ0?= =?utf-8?B?M054MnlWREVkcFlKc2hDNnVjK2l1aUtIOWhJcVFMdTE4Rzc0c29VSHBZaXJE?= =?utf-8?Q?T7og0ZN9wu83xPKLaGZTtjw51rZhqunWg4WOGbE?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: PUvsMFAJdktRkC/JfqLY+by1G7n6+J5BC1WzJ9j1JTGbZAnTKm6vob4aG2C3WSHj5kyJGFCb9huP0LXBYsX7Z+qFlGw7of0M3wGf2PEt5U/2VJVuIpRjDXXbF/gigI5190/FoY2tHfAM38y3Rda89jGVuZZQ5aSojGLxI+n8BdXz7Ip7Qr1zC75ZC6BGbwBAWRXFQEhD74y9JLTQLqrsCu/Khv1HmYjZXV1cLGSg+PJfUivSLPWLLOjHkDLCOhX7dZo75nDSDtnkiSKrbtuiU20kshvX3qPt+Bw3wMtp8qF4dD08sc+3cJDEU6ZYVyk/mt2lBtYgQ7Q2uEPc3X5zZu9m1ry2v/nV6EHdHFbvaJtj7dPSXyzIokalTNnEQ1F4wtZ/21D3xv5gYr2FyheraxlN8y7VEZCvmsNTFLp3w4A= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2019 16:34:16.9527 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 03c23924-cdf5-4765-2c7d-08d6a31abe36 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR01MB4857 Archived-At: Subject: Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-sfc-05: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 16:34:29 -0000 On Thu, Mar 07, 2019 at 03:01:34PM -0000, Adrian Farrel wrote: > Hi Ben, > > Thanks for the detailed and thoughtful review. It's helpful. > > Answers below, and a new revision in my buffer. > > Adrian > > > DISCUSS: > > > > Thank you for this easy-to-read document! The design is pretty > > elegant, but I think there are a few places that remain insufficiently > > specified so as to admit interoperable implementation. > > > > In particular, I don't think the TTL-handling behavior for the SF > > Label in the "label stacking" case is completely specified, though > > an apparent typo in Section 7 (see COMMENT) makes it hard to > > tell what was intended. > > Fixing the typo would give us > TTL: The TTL fields in the SFC Context label stack entry and in the > SF label stack entry SHOULD be set to 1 as stated in Section 5, > but MAY be set to larger values if the label indicated a > forwarding operation towards the node that hosts the SF. > > In the SR case, it might not be necessary to tunnel the packets. In that case the SFC Context label provides sufficient information to route the packet through the SR network to the next SFF, but the TTL needs to reflect the distance between SFFs. > > Do you think we need to add text to explain that? I don't see a particular need; I was mostly just concerned that the typo-laden text wasn't saying anythign about the SF Label TTL, but that concern seems to be unfounded. > > In Section 8, we see that: > > When an SFF receives a packet containing an MPLS label stack, it > > checks whether it is processing an {SFP, SI} label pair for label > > swapping or a {context label, SFI index} label pair for label > > stacking. [...] > > > > What data source is consulted to make this check? The control > > plane? Is this distinction made on a per-node basis or a per-packet > > basis or otherwise? My first thought was that it's per-SFC-Context- > > Label, but we're not guaranteed that those values will be interpretable > > equivalently in the swapping or stacking usages, IIUC. > > All SFFs are programmed with context for SFC labels. So they know, from the top label (the SFP label or SFC context label) what form of processing is involved. Okay, so I guess this follows from being in a single MPLS domain that the topmost label in the "basic unit" is going to be uniquely interpretable, and thus will indicate whether it's an SFP label or SFC context label (and thus what form of processing); that makes sense. > But, additionally, this is not going to be a rabid free-for-all. As section 8 says a bit higher up... > it is also > possible that different parts of the network utilize swapping or > popping such that an end-to-end service chain has to utilize a > combination of both techniques. > > This "different parts of the network" is going to manifest as different interfaces to the SFF. > > Lets upgrade the text to... > When an SFF receives a packet containing an MPLS label stack, it > checks from the context of the incoming interface, and from the SFP > indicated by the top label whether it is processing an {SFP, SI} > label pair for label swapping or a {context label, SFI index} label > pair for label stacking. It then selects the appropriate SFI to > which to send the packet. When it receives the packet back from the > SFI, it has four cases to consider. That would be wonderful, thank you. > > I also support Alissa's DISCUSS (and the secdir reviewer makes > > similar comments). > > OK. Did you see my response to Alissa? Does that solve it for you? That part looks good, yes. > > COMMENT: > > > > Am I supposed to assume that the control plane sufficiently informs > > everyone whether they're an SFF, SFI, or neither? (Or does any given > > (virtual) device just inherently know?) > > They know. Like a router knows it is not a telephone box. > If (improbable) a device could be hawk or a handsaw depending on the direction of the wind, then it would need to be configured to know what it was doing. > > > Abstract (and Introduction) > > > > nit: no comma after "as well". > > Ack > > > This document describes how Service Function Chaining can be achieved > > in an MPLS network by means of a logical representation of the NSH in > > an MPLS label stack. That is, the NSH is not used, but the fields of > > the NSH are mapped to fields in the MPLS label stack. It does not > > deprecate or replace the NSH, but acknowledges that there may be a > > need for an interim deployment of SFC functionality in brownfield > > networks. > > > > Am I supposed to read this as that the NSH is the way of the > > future, and this mechanism is just a temporary interim measure? > > It is unclear. The full use of the NSH may require upgrades to some forwarding plane devices. The IETF, through consensus, has approved the NSH on the standards track via RFC 8300, and this document is not intended to displace that or argue against that consensus. On the other hand, there is a desire to achieve SFC function largely equivalent to that provided by the NSH for more immediate deployment using existing hardware. Hmm. I think that this comment is basically just asking whether the word "interim" is better in or out. But it's not my call to make, of course. (And English has these silly rules about the form of the indefinite article changing when preceding a word that does or does not start with a vowel, of course.) > > Section 4.3 > > > > It may be that a service function chain (as described in Section 4.1 > > allows some leeway in the choice of service function instances along > > the chain. However, it may be that a service classifier wishes to > > constrain the choice and this can be achieved using chain > > concatenation so that the first chain ends at the point of choice, > > > > This does not give any motivation for why a classifier might wish to > > constrain the choice. > > Yes. And I'm not sure that we should repeat the SFC architecture here, nor develop some of the use cases. > > I would offer three possible reasons off the top of my head: > - The tool constructing the SFP does not trust (or knows better than) the SFF what SFI load-balancing decisions to make. > - The SFIs are stateful, but the SFF is not capable of maintaining state as to which SFI is used for each SFP. > - There is a bidirectional SFP and the same SFI must be used in each direction. > > I'm not inclined to put into this document a description of reasons why an SFP might or might not specify precise choice of SFIs. We just describe how it can be done. That's fair (and this was intentionally in the non-blocking comment section). I'm just always amazed at how many choices we have to offer in some of these routing protocols, that the deployment scenarios don't admit more consolidation of technologies. > > Section 5 > > > > The decision to use the control plane to indicate "label stacking" vs. > > "label swapping" semantics as opposed to an in-band signal seems to > > create a new opportunity for misconfiguration and consequent service > > misbehavior. I suppose it's not appreciably worse than any other way to > > configure the interpretation of the label field, though. > > Not sure the comment applies to Section 5. But you're right, the use of a control plane is subject to misconfiguration. However, I think we only have the MPLS shim header to work with and unless we partition the label space (which the MPLS architects would scream about) I think we are stuck with what we have. > > > S: The bottom of stack bit has its usual meaning in MPLS. It MUST be > > clear in the SFC Context label stack entry and MAY be set in the > > SF label stack entry depending on whether the label is the bottom > > of stack. > > > > I don't understand why this is only a MAY. > > This is probably why the use of requirements language sucks sometimes 😊 > Perhaps we should expand this a bit and write... > > S: The bottom of stack bit has its usual meaning in MPLS. It MUST be > clear in the SFC Context label stack entry. In the SF label stack > entry it MUST be clear in all cases except when the label is the > bottom of stack, when it MUST be set. Thanks. > > Section 6 > > > > Under normal circumstances (with the exception of branching and > > reclassification - see [I-D.ietf-bess-nsh-bgp-control-plane]) the > > > > The word "reclassification" does not appear in the indicated reference. > > Dang! It's hyphenated in the other draft. > Fixing it here. Shoot, I should have checked for that. (I was actually looking it up to get more background.) > > The following processing rules apply to the TTL field of the SF label > > stack entry, and are derived from section 2.2 of [RFC8300]: > > > > nit: we seem to capitalize "SF Label" > > Yeah, hmmm/ Seem to have consistent use as: > "SF Label" > "SF label stack entry" > The label stack entry is a construct of its own (and thus a compound noun). Ok. > > Section 7 > > > > It's a bit unusual, style-wise, to have Section 6 introduce new terms > > for the SPI Label and SI Label that are specific to the swapping usage, > > and then have Section 7 just reuse the nominally generic terms from > > Section 5 as its own for the stacking usage. > > I think this the consequence of some politics ☹ > Two concepts and drafts were merged, and no one wanted to give up their language. > We might sort that out, but I don't know anyone with the energy! > I think the resultant text is clear enough, although as you say "unusual". Sure. > > SFC Context Label: The Label field of the SFC Context label stack > > entry contains a label that delivers SFC context. This label may > > be used to indicate the SPI encoded as a 20 bit integer using the > > semantics of the SPI is exactly as defined in [RFC8300] and noting > > that in this case a system using MPLS representation of the > > logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or > > less than 16. This label may also be used to convey other SFC > > context-specific semantics such as indicating how to interpret the > > SF Label or how to forward the packet to the node that offers the > > SF. > > > > This "may also be used" behavior seems rather under-specified. > > Yeah. Adding "if so configured and coordinated with the controller that programs the labels for the SFP." > > > TTL: The TTL fields in the SFC Context label stack entry SF label > > stack entry SHOULD be set to 1 as stated in Section 5, but MAY be > > set to larger values if the label indicated a forwarding operation > > towards the node that hosts the SF. > > > > What is "SFC Context label stack entry SF label stack entry"? It seems > > like there's a missing word or something. I note that section 5 defers > > to here for the TTL of the SF Label and we are either not saying > > anything or attempting to defer to Section 5, so this seems > > under-specified. > > See your Discuss for resolution of both of these. > > > Section 8 > > > > o If the current hop requires an {SFP, SI} and the next hop requires > > an {SFP, SI}, it selects an instance of the SF to be executed at > > the next hop, sets the SI label to the SI value of the next hop, > > and tunnels the packet to the SFF for that SFI. > > > > nit: I know the default behavior is to use the same SFP value, but (1) > > this should probably be stated explicitly, and (2) we've already talked > > about branching/etc. that could cause it to change. > > OK > > o If the current hop requires an {SPI, SI} and the next hop requires > an {SPI, SI}, it sets the SPI label according to the SFP to be > traversed, selects an instance of the SF to be executed at the > next hop, sets the SI label to the SI value of the next hop, and > tunnels the packet to the SFF for that SFI. > > > * If the top of the MPLS label stack contains a {context label, > > SFI label}, it tunnels the packet to the SFF indicated by the > > context label. > > > > nit: probably best to use "new top" for consistency with the preceding > > sub-bullet. > > Sure > > > Section 12.1 > > > > The SFC Metadata Label (as a set of three labels as indicated in > > Figure 4) may be present zero, one, or more times in an MPLS SFC > > packet. For MPLS label swapping, the SFC Metadata Labels are placed > > immediately after the basic unit of MPLS label stack for SFC as shown > > in Figure 5. For MPLS label stacking, the SFC Metadata Labels can be > > present zero, one, or more times and are placed at the bottom of the > > label stack as shown in Figure 6. > > > > The "may be present zero, one, or more times" appears twice. > > (I actually don't mind the internal redundancy of that phrase here, though, > > since all three cases are potentially relevant.) > > Yeah, but it's tacky. Tidied it up. > > > Section 12.2 > > > > Metadata Type: The type of the metadata present. Values for this > > field are taken from the "MD Types" registry maintained by IANA > > and defined in [RFC8300]. > > > > The "MD Types" registry I'm finding in RFC 8300 is defined to hold > > four-bit values; why do we need a 16-bit field to hold it here in the > > TLV? (I mean, "to keep the metadata itself aligned", sure, but having > > 12 reserved bits would do that, too.) > > It's true. > We could have jumped either way. > This way aligns with "normal" LTV processing. Well, it's potentially an interop issue, now that I think about it more. If I treat the values as integers, then I could in theory use some little-endian encoding, or even something more strange. So I think we probably do need more text about resolving the mismatch (even if we don't change the diagram). > > Section 15 > > > > I agree with the secdir reviewer that the "trusted" nature of the > > classifier as a "trusted resource" could be further clarified. > > I am having some trouble with the subtleties here. > I suppose this means that a trusted resource is one that will not behave in a way intended to cause harm to the network or to the payload data. That means that when a classifier puts a packet onto an SFP (by applying labels) its actions are not designed to cause the packet to avoid particular SFPs or be blackholed or be diverted to other parts of the network or SFs. > The point here, I think, is that there is no way for the rest of the network to have any visibility into the behaviour of the classifier, but must accept packets as they are forwarded. > Thus, the classifier is seen as within the MPLS trusted zone [RFC5920]. > > If you can suggest ways we could explain that to everyone's satisfaction, then I'd be happy to add text. Maybe: It is fundamental to the SFC design that the classifier is a fully trusted element; the classification decision process is not visible to the other elements and its output is treated as accurate. As such, the classifier has (sole?) responsibility for determining the processing that the packet will be subject to, including, for example, firewall functions. > > Where an SF is not > > encapsulation aware the encapsulation may be stripped by an SFC proxy > > > > nit: "encapsulation-aware" > > Ack. > > > Thank you for the new text in the -05 prompted by the secdir review; it > > is a huge improvement! > > In addition to encryption, I'd probably also note that MPLS at present > > doesn't provide any cryptographic integrity protection on the headers. > > OK > > > o The SFC-capable devices participating in an SFC system are > > responsible for verifying and protecting packets and their > > contents as well as providing other security capabilities that > > might be required in the particular system. > > > > Do I recall correctly that we currently don't specify any mechanisms for > > them to do so? If so, we probably need to note that this is currently > > in implementation-specific territory. > > I believe this quote should say "payload packets and their contents." > Of course, a host of mechanisms exist for that, but are out of scope. "payload packets" or "packet payloads"? But sure, I think we're in agreement. Thanks! -Benjamin > > I'd also suggest > > OLD: > > Thus, the security vulnerabilities are addressed (or should be > > addressed) in all the underlying technologies used by this design. > >NEW: > > Thus, this design relies on the component underlying technologies to > > address the potential security vulnerabilities, and documents the > > necessary protections (or risk of their absence) above. It does not > > include any native security mechanisms in-band with the MPLS > > encoding of the NSH functionality. > > (since "are addressed (or should be addressed)" is rather wishy-washy > > language). > > OK. > > > No known new security vulnerabilities are introduced by this design, > > > > It's probably worth stating what the reference point for the comparison > > is, just for clarity. (I assume it's the RFC8300 NSH.) > > OK > Added 7665 and 8300. > > > Section 19.2 > > > > It seems that RFC 6790 needs to be a normative reference, since we are > > RECOMMENDED to insert Entropy Labels. > > OK. Can do > > From nobody Thu Mar 7 08:44:09 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C8A1277D7; Thu, 7 Mar 2019 08:44:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mpls@ietf.org Message-ID: <155197704783.24888.13498480151463481563@ietfa.amsl.com> Date: Thu, 07 Mar 2019 08:44:07 -0800 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-sfc-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 16:44:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching WG of the IETF. Title : An MPLS-Based Forwarding Plane for Service Function Chaining Authors : Adrian Farrel Stewart Bryant John Drake Filename : draft-ietf-mpls-sfc-06.txt Pages : 30 Date : 2019-03-07 Abstract: This document describes how Service Function Chaining (SFC) can be achieved in an MPLS network by means of a logical representation of the Network Service Header (NSH) in an MPLS label stack. That is, the NSH is not used, but the fields of the NSH are mapped to fields in the MPLS label stack. It does not deprecate or replace the NSH, but acknowledges that there may be a need for an interim deployment of SFC functionality in brownfield networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-sfc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mpls-sfc-06 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-sfc-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-sfc-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 7 08:46:04 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C14128664; Thu, 7 Mar 2019 08:46:02 -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, 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 6I8aNKWNhAXj; Thu, 7 Mar 2019 08:45:58 -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 10F161277DB; Thu, 7 Mar 2019 08:45:57 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id x27Gjthu008858; Thu, 7 Mar 2019 16:45:55 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A87812203B; Thu, 7 Mar 2019 16:45:55 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS id 937D52203A; Thu, 7 Mar 2019 16:45:55 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id x27GjsP3001746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Mar 2019 16:45:55 GMT Reply-To: From: "Adrian Farrel" To: "'The IESG'" Cc: Date: Thu, 7 Mar 2019 16:45:52 -0000 Organization: Old Dog Consulting Message-ID: <01b401d4d505$3abc51c0$b034f540$@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 Content-Language: en-gb Thread-Index: AdTVBTdcC6VCEiReSnOKMkF5ca9NAQ== X-Originating-IP: 87.112.237.8 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-24476.000 X-TM-AS-Result: No--10.929-10.0-31-10 X-imss-scan-details: No--10.929-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24476.000 X-TMASE-Result: 10--10.928900-10.000000 X-TMASE-MatchedRID: lOHN29jQbHQ0DiQ9cxdwEuYAh37ZsBDCA9UhA/EMrwMn+p552csI1fkl m68wRsucV43LtMCw8IQ7EienwsmSJOS7PZsP9IZB9UVHiwLx0/KnHBIbyMjCFGecrqZc3vabqbD mzbecxFtmsXbHq7vzZUREAbkfT0bxXaS5Ieafe4MIVoCLGbl5T/x3eAlFiEvxehTPkBG4eNFXoY nJE8t84ktG3wpLMoxtuTUKFcBaOlG3EcV3YQtKOk1Wvi92YKnOtpK67+w8v6xaW2Ktn+I8/va/u /WjK5O/gEBR2HjnXiv27vlZQBKDdDcpdZ3fQiLdgxsfzkNRlfKp/mH7gW9/gAU5rQ/jDZbqjocz muoPCq0BYUGKdJtB8rR0EQ0nZ4UITXfH4aqIedDaIPlkiJ964UT+XRDItP42 X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [mpls] IESG updates to draft-ietf-mpls-sfc-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 16:46:02 -0000 All, Many thanks for the various reviews. This revision makes updates to address everything as discussed on email = *except* for Ekr's Discuss. Thought it would be helpful to get you an early revision in this busy = period. Best, Adrian -----Original Message----- From: internet-drafts@ietf.org =20 Sent: 07 March 2019 16:44 To: Adrian Farrel ; John Drake = ; Stewart Bryant Subject: New Version Notification for draft-ietf-mpls-sfc-06.txt A new version of I-D, draft-ietf-mpls-sfc-06.txt has been successfully submitted by Adrian Farrel and posted to the IETF repository. Name: draft-ietf-mpls-sfc Revision: 06 Title: An MPLS-Based Forwarding Plane for Service Function Chaining Document date: 2019-03-07 Group: mpls Pages: 30 URL: = https://www.ietf.org/internet-drafts/draft-ietf-mpls-sfc-06.txt Status: https://datatracker.ietf.org/doc/draft-ietf-mpls-sfc/ Htmlized: https://tools.ietf.org/html/draft-ietf-mpls-sfc-06 Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-mpls-sfc Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-sfc-06 Abstract: This document describes how Service Function Chaining (SFC) can be achieved in an MPLS network by means of a logical representation of the Network Service Header (NSH) in an MPLS label stack. That is, the NSH is not used, but the fields of the NSH are mapped to fields in the MPLS label stack. It does not deprecate or replace the NSH, but acknowledges that there may be a need for an interim deployment of SFC functionality in brownfield networks. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Mar 7 08:54:44 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9734A128BE6; Thu, 7 Mar 2019 08:54:41 -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-mpls-sfc@ietf.org, Loa Andersson , mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155197768161.24888.16544269693327458561.idtracker@ietfa.amsl.com> Date: Thu, 07 Mar 2019 08:54:41 -0800 Archived-At: Subject: [mpls] Alissa Cooper's No Objection on draft-ietf-mpls-sfc-06: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 16:54:42 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-mpls-sfc-06: 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-mpls-sfc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS. Original COMMENT below. = Section 4.5 = OLD The application of SR to SFC was considered in early versions of the SR architecture [RFC8402] and the MPLS-SR specification [I-D.ietf-spring-segment-routing-mpls], but has since been moved out of those documents. NEW The application of SR to SFC was considered in early versions of the SR architecture [RFC8402] and the MPLS-SR specification [I-D.ietf-spring-segment-routing-mpls], but was not ultimately adopted. (I think this is about the ideas, not the organization of documents.) From nobody Thu Mar 7 09:26:31 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A07012798F; Thu, 7 Mar 2019 09:26:26 -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] 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 HgDD6tDda-6j; Thu, 7 Mar 2019 09:26:24 -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 52ADE12798C; Thu, 7 Mar 2019 09:26:23 -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 x27HQKnN017857; Thu, 7 Mar 2019 17:26:20 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8E1B822040; Thu, 7 Mar 2019 17:26:20 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id 78AD322032; Thu, 7 Mar 2019 17:26:20 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id x27HQIjH000701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Mar 2019 17:26:19 GMT Reply-To: From: "Adrian Farrel" To: "'Benjamin Kaduk'" Cc: "'The IESG'" , , , , References: <155193436776.13798.13710472280487229144.idtracker@ietfa.amsl.com> <016201d4d4f6$a91e5e10$fb5b1a30$@olddog.co.uk> <20190307163410.GA9824@kduck.mit.edu> In-Reply-To: <20190307163410.GA9824@kduck.mit.edu> Date: Thu, 7 Mar 2019 17:26:17 -0000 Organization: Old Dog Consulting Message-ID: <01be01d4d50a$e00ec2c0$a02c4840$@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 Content-Language: en-gb Thread-Index: AQJzZtNl8vYRQS0gmn+2QKKbTlRPSgLsnwHDAkUo+M6kma+p8A== X-Originating-IP: 87.112.237.8 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-24476.000 X-TM-AS-Result: No--17.488-10.0-31-10 X-imss-scan-details: No--17.488-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24476.000 X-TMASE-Result: 10--17.487700-10.000000 X-TMASE-MatchedRID: X4bcv0S75KnxIbpQ8BhdbOYAh37ZsBDCfjJOgArMOCZb8pv4L0h+ItoU RXARSc3aGUeHw8iRpB/5v5mFbneVaaf0QmPqa4kevGTc5oROod4F15s6prCIu/gnJH5vm2+gv9+ RvGSUdYD5OW6MLFs1zj7Ml2KDF54I5s2E/HDpG1lZluvuHEedhJZ6zKu0q4rtgrAXgr/AjP2XTk aFZN0PCNmCd+j0KZG8F1FkRcqUhGN2VhA+n0wGkmOho7buv7d9KsyJ61LbQNGbO/6uzMwg9CTCV wyY5KnUlcdg+0tSlGn9dLcGF3vdjeVPKBunz2ET1yMJs9mBCcWbKpAlY2y6SWsftHRGGisM4d2N auEDjqzkPRHbBrz7vxmCYyF9c9FfjtW9kIs2cSeeAiCmPx4NwFkMvWAuahr8i2QFaYS1v20qtq5 d3cxkNQP90fJP9eHt X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-sfc-05: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 17:26:26 -0000 Thanks again, Ben, > > COMMENT: > > Section 12.2 > > > > Metadata Type: The type of the metadata present. Values for this > > field are taken from the "MD Types" registry maintained by IANA > > and defined in [RFC8300]. > > > > The "MD Types" registry I'm finding in RFC 8300 is defined to hold > > four-bit values; why do we need a 16-bit field to hold it here in = the > > TLV? (I mean, "to keep the metadata itself aligned", sure, but = having > > 12 reserved bits would do that, too.) >=20 > It's true.=20 > We could have jumped either way. > This way aligns with "normal" LTV processing. Well, it's potentially an interop issue, now that I think about it more. If I treat the values as integers, then I could in theory use some little-endian encoding, or even something more strange. So I think we probably do need more text about resolving the mismatch (even if we = don't change the diagram). [AF] OK. Notwithstanding that the way fields are encoded in MPLS are = well known we will add encoding rules > > Section 15 > > > > I agree with the secdir reviewer that the "trusted" nature of the > > classifier as a "trusted resource" could be further clarified. >=20 > I am having some trouble with the subtleties here. > I suppose this means that a trusted resource is one that will not = behave in a way intended to cause harm to the network or to the payload = data. That means that when a classifier puts a packet onto an SFP (by = applying labels) its actions are not designed to cause the packet to = avoid particular SFPs or be blackholed or be diverted to other parts of = the network or SFs. > The point here, I think, is that there is no way for the rest of the = network to have any visibility into the behaviour of the classifier, but = must accept packets as they are forwarded. > Thus, the classifier is seen as within the MPLS trusted zone = [RFC5920]. >=20 > If you can suggest ways we could explain that to everyone's = satisfaction, then I'd be happy to add text. Maybe: It is fundamental to the SFC design that the classifier is a fully = trusted element; the classification decision process is not visible to the other elements and its output is treated as accurate. As such, the classifier has (sole?) responsibility for determining the processing that the = packet will be subject to, including, for example, firewall functions. [AF] Yes. Working with that. > > o The SFC-capable devices participating in an SFC system are > > responsible for verifying and protecting packets and their > > contents as well as providing other security capabilities that > > might be required in the particular system. > > > > Do I recall correctly that we currently don't specify any mechanisms = for > > them to do so? If so, we probably need to note that this is = currently > > in implementation-specific territory. >=20 > I believe this quote should say "payload packets and their contents." > Of course, a host of mechanisms exist for that, but are out of scope. "payload packets" or "packet payloads"? But sure, I think we're in agreement. [AF] "Payload packets". The essence of SFC being that you have a packet = stream and you send it (via an encapsulation) to be processed by SFs. Thanks again, Adrian From nobody Thu Mar 7 14:33:03 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7901311E8; Thu, 7 Mar 2019 14:32:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mpls@ietf.org Message-ID: <155199797481.5436.5740849680147070827@ietfa.amsl.com> Date: Thu, 07 Mar 2019 14:32:54 -0800 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-sfc-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 22:32:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching WG of the IETF. Title : An MPLS-Based Forwarding Plane for Service Function Chaining Authors : Adrian Farrel Stewart Bryant John Drake Filename : draft-ietf-mpls-sfc-07.txt Pages : 30 Date : 2019-03-07 Abstract: This document describes how Service Function Chaining (SFC) can be achieved in an MPLS network by means of a logical representation of the Network Service Header (NSH) in an MPLS label stack. That is, the NSH is not used, but the fields of the NSH are mapped to fields in the MPLS label stack. It does not deprecate or replace the NSH, but acknowledges that there may be a need for an interim deployment of SFC functionality in brownfield networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-sfc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mpls-sfc-07 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-sfc-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-sfc-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 Thu Mar 7 15:10:18 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C794131476 for ; Thu, 7 Mar 2019 15:10:12 -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] 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 DSBjwG5MZn8t for ; Thu, 7 Mar 2019 15:10:10 -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 2CBE1131408 for ; Thu, 7 Mar 2019 15:10:06 -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 x27NA2c3005013; Thu, 7 Mar 2019 23:10:02 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 16B082203B; Thu, 7 Mar 2019 23:10:02 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS id 00CCC2203A; Thu, 7 Mar 2019 23:10:02 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id x27NA0wL014981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Mar 2019 23:10:01 GMT Reply-To: From: "Adrian Farrel" To: Date: Thu, 7 Mar 2019 23:10:00 -0000 Organization: Old Dog Consulting Message-ID: <026401d4d53a$e3e23820$aba6a860$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AdTVNc1ixxx1a+I5TC6NhcaF59rcgA== X-Originating-IP: 87.112.237.8 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-24476.003 X-TM-AS-Result: No--13.644-10.0-31-10 X-imss-scan-details: No--13.644-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24476.003 X-TMASE-Result: 10--13.644100-10.000000 X-TMASE-MatchedRID: 8gy9DfjknR7yD+EqUBix4biMC5wdwKqdk9atiES99p0QH8CxzihpgYjM Udtb8z35MSeq2sKeo9Y2bQz4x5+GPojH1M7lRGyeKNDiix19qYGWesyrtKuK7T9QzIS5KoGBgna slZ/rTdmwNKmrJljjNONaru5SD9HYD7rWxk93B9F/TWpwlAOFXqKRkGOW2z9y+Cckfm+bb6ByzE UsduoE4hJZHXXpafFmTa4Cf0D6Ap3Ncm2bW2t5nMOriXY+VMfQlavqJJda2A+7+NPPxj+R6pKQl syF4c0BRsl+7fC2d3bTMj+5r/4Bdlzo1wB5HFP3081phgl5F/kS12tj9Zvd85ps2hiiMFB2RCmR CsRFFA35PtOeXawPGTdIy3gNLQNBxMH2MOMU8Vsp/8fGeWUPKKuvxGMwcZCYGZ2zNQwkHw3N6oa SBNupLy9oi4Z4GUtI7Pf7V6wkGEBo/jLJ/UOlaHT7rnt3EYkYvnvglABdz6Gynk7TnYzMuo0xgX l4ajAL4vM1YF6AJbZcLc3sLtjOt9CpCFLDTHZU3QfwsVk0UbtuRXh7bFKB7pvabgEc58yH34yyP QGMc3LURn+/kV6A58RTgOwVLJz/WClYJu9r4yY= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [mpls] Change of some substance to draft-ietf-mpls-sfc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 23:10:16 -0000 Hi, The latest revision of draft-ietf-mpls-sfc (version -07) includes a new subsection to address an interesting Discuss from Eric Rescorla. The essence of his Discuss applies to the inband propagation of metadata described in Section 12.2. This is an optional process for distributing per-SFP or per-flow metadata by sending packets that follow the path of the SFP. Eric pointed out in his Discuss that there is a problem in relying on the distribution of metadata using this method because the packet carrying the metadata might get lost and there is no way to acknowledge or guarantee delivery. And he is right that even in an MPLS network, packet loss and packet corruption can happen. We have added a new subsection (12.2.1 - supplied below for reference) to describe this case. The essence is: - we do not propose a mechanism to plug this hole - we do not attempt to quantify the risk (i.e., how often a packet might get lost) - we suggest two mitigations - we suggest that if this risk is unacceptable to an application it should use some other method of propagating metadata The authors wanted to bring this change to the document to your attention. We have not actually changed the way the specification works, but we have flagged up an issue that you might want to solve in some other way. We are not seeking a Working Group consensus call on this, and are not empowered to call consensus anyway. However, while the IESG is clearing their Discusses and while our AD is preparing to forward the document, you might shout if you have any concerns. Thanks, Adrian (for the author team) 12.2.1. Loss of Inband Metadata Note that inband exchange of metadata is vulnerable to packet loss. This is both a risk arising from network faults and an attack vulnerability. If packets that arrive at an SFF use an MLI that does not have an entry in the metadata table, an alarm can be raised and the packet can be discarded or processed without the metadata according to local configuration. This provides some long-term mitigation, but is not an ideal solution. Further mitigation to loss of metadata packets can be achieved by retransmitting them at a configurable interval. This is a relatively cheap, but only partial solution because there may still be a window during which the metadata has not been received. The concern of lost metadata may be particularly important when the metadata applicable to a specific MPI is being changed. This could result in out-of-date metadata being applied to a packet. If this is a concern, it is RECOMMENDED that a new MPI is used to install a new entry in the metadata table, and the packets in the flow should be marked with the equivalent new MLI. Finally, if an application that requires metadata is sensitive to this potential loss or attack, it SHOULD NOT use inband metadata distribution, but SHOULD rely on control plane or management plane mechanisms because these approaches can use a more sophisticated protocol that includes confirmation of delivery, and can perform verification or inspection of entries in the metadata table. From nobody Fri Mar 8 04:38:31 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD6212797D; Fri, 8 Mar 2019 04:38:23 -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 HYnye1TVoad4; Fri, 8 Mar 2019 04:38:20 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150129.outbound.protection.outlook.com [40.107.15.129]) (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 7971F1276D0; Fri, 8 Mar 2019 04:38:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BzaRdQJ+G+3HqTUi7EaeMsQDHS5qnfB69bMu7VVkp7o=; b=cHGNVzH3Wq45tde/+fn0HS795brWu4gJfc7BnBxgsziw43Bkve7Awajr8Lx1Y83dVvQ6cHKzEYegrxofPtWUQWQQXrcSIcO4FswlCmY2lqKELXNnneYhn2uIvQSVQM8FffH+1+/jrc9HeLqf8KwPdWCHuDbBHIs56F4obgpC0cQ= Received: from VI1PR07MB6142.eurprd07.prod.outlook.com (20.178.124.157) by VI1PR07MB5919.eurprd07.prod.outlook.com (20.178.81.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.8; Fri, 8 Mar 2019 12:38:17 +0000 Received: from VI1PR07MB6142.eurprd07.prod.outlook.com ([fe80::5d24:f062:104a:b2f2]) by VI1PR07MB6142.eurprd07.prod.outlook.com ([fe80::5d24:f062:104a:b2f2%4]) with mapi id 15.20.1709.009; Fri, 8 Mar 2019 12:38:17 +0000 From: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" To: "adrian@olddog.co.uk" , 'Datatracker on behalf of Martin Vigoureux' , 'The IESG' CC: "mpls@ietf.org" , "mpls-chairs@ietf.org" , "draft-ietf-mpls-sfc@ietf.org" Thread-Topic: [mpls] Martin Vigoureux's Yes on draft-ietf-mpls-sfc-05: (with COMMENT) Thread-Index: AQHU1avOKQVAkk7q+EK9h1C8IIJl2Q== Date: Fri, 8 Mar 2019 12:38:17 +0000 Message-ID: <9ae094f5-3618-b14a-cb0f-e965ab7e2b9e@nokia.com> References: <155186757563.24618.8284642177706375034.idtracker@ietfa.amsl.com> <017701d4d4f9$086b4520$1941cf60$@olddog.co.uk> In-Reply-To: <017701d4d4f9$086b4520$1941cf60$@olddog.co.uk> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.228.2.20] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 x-clientproxiedby: MR2P264CA0016.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:1::28) To VI1PR07MB6142.eurprd07.prod.outlook.com (2603:10a6:803:da::29) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b71b952c-cd24-466f-fe66-08d6a3c2f05c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1PR07MB5919; x-ms-traffictypediagnostic: VI1PR07MB5919: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0970508454 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(346002)(39860400002)(366004)(136003)(54094003)(189003)(199004)(6486002)(6116002)(6246003)(3846002)(2501003)(64126003)(229853002)(97736004)(6436002)(86362001)(36756003)(52116002)(486006)(11346002)(305945005)(476003)(7736002)(31696002)(99286004)(2616005)(446003)(71190400001)(5660300002)(26005)(14454004)(186003)(71200400001)(256004)(6346003)(966005)(105586002)(8936002)(106356001)(8676002)(31686004)(386003)(110136005)(316002)(4326008)(58126008)(6506007)(65806001)(65956001)(76176011)(478600001)(6306002)(54906003)(6512007)(66066001)(65826007)(81156014)(81166006)(25786009)(102836004)(68736007)(53936002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5919; H:VI1PR07MB6142.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: K7acefo4O5fkXMl6zLTFpxEbwoQzONbpQ73iSFxsLVTgPke1cyWtJzO+yBgSRCWp1wEHb4jJz00ZpG0IWW1ttdfBU+0ptY/ovXBoKQpZeGDp6FiHUe3nBoMI20Y8UotpWDDLywtRHhxWcVxxBRfOSLj9GURMeOaYhBaKKY4mJzz/g0cSQnzkTLLT7AKOpIsD3d60P//Hr6nVIti5NgF3zWAMiFzC3OL59rORHxpul741Js3jtMoS/2bE70IBcerat+Co03a68Tg6gmBfapp8ovNUcwrVYAyyXuBVu7mbjCUEcjpCCfcnFDVv52tGXrbE5X03C96Z5NEF1gE9jUkmZ6WxiwcDd6tF2zu/AxrOmQQ9ECusNJgKjt4jHL4cLYff9/0vQqtYOI8qOjXRijalUMRhhb5eQKNaLgA6DEEXp68= 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: b71b952c-cd24-466f-fe66-08d6a3c2f05c X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2019 12:38:17.3774 (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-Transport-CrossTenantHeadersStamped: VI1PR07MB5919 Archived-At: Subject: Re: [mpls] Martin Vigoureux's Yes on draft-ietf-mpls-sfc-05: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 12:38:23 -0000 VGhhbmtzIEFkcmlhbiwgdGhhdCdzIHBlcmZlY3QuDQoNCkxlIDIwMTktMDMtMDcgw6AgMTY6MTgs IEFkcmlhbiBGYXJyZWwgYSDDqWNyaXTCoDoNCj4gSGkgTWFydGluLA0KPiANCj4gVGhhbmtzIGZv ciB5b3VyIHRob3VnaHRzLg0KPiANCj4+IENPTU1FTlQ6DQo+Pg0KPj4gSSBrbm93IEknbSBiZWlu ZyB0b28gcGVybmlja2V0eToNCj4gDQo+IEFzIGlzIHlvdXIgcmlnaHQg8J+YiQ0KPiANCj4+IFlv dSBzYXk6DQo+PiAgICBvICBBbiBTRkYgTVVTVCBkZWNyZW1lbnQgdGhlIFRUTCBieSBvbmUgZWFj aCB0aW1lIGl0IHBlcmZvcm1zIGENCj4+ICAgICAgIGZvcndhcmRpbmcgbG9va3VwLg0KPj4gYnV0 IGluIHRoZSBleGFtcGxlcyB5b3UgYWxzbyBzYXk6DQo+PiAgICBiLiAgV2hlbiB0aGUgcGFja2V0 IGFycml2ZXMgYXQgU0ZGYSBpdCBzdHJpcHMgYW55IGxhYmVscyBhc3NvY2lhdGVkDQo+PiAgICAg ICAgd2l0aCB0aGUgdHVubmVsIHRoYXQgcnVucyBmcm9tIHRoZSBjbGFzc2lmaWVyIHRvIFNGRmEu ICBTRkZhDQo+PiAgICAgICAgZXhhbWluZXMgdGhlIHRvcCBsYWJlbHMgYW5kIG1hdGNoZXMgdGhl IFNQSS9TSSB0byBpZGVudGlmeSB0aGF0DQo+PiAgICAgICAgdGhlIHBhY2tldCBzaG91bGQgYmUg Zm9yd2FyZGVkIHRvIFNGYS4gIFRoZSBwYWNrZXQgaXMgZm9yd2FyZGVkDQo+PiAgICAgICAgdG8g U0ZhIHVubW9kaWZpZWQuDQo+PiBhbmQNCj4+ICAgIGQuICBTRkZhIG1vZGlmaWVzIHRoZSBTSSBp biB0aGUgbG93ZXIgbGFiZWwgc3RhY2sgZW50cnkgKHRvIDI1NCkgYW5kDQo+PiAgICAgICAgdXNl cyB0aGUgU1BJL1NJIHRvIGxvb2sgdXAgdGhlIGZvcndhcmRpbmcgaW5zdHJ1Y3Rpb25zLg0KPj4N Cj4+IEl0IGNvdWxkIGxvb2sgYXMgdHdvIGZvcndhcmRpbmcgbG9va3VwLCB3aGljaCwgYWNjb3Jk aW5nIHRvIHRoZQ0KPj4gcmVxdWlyZW1lbnQsIGNvdWxkIGxlYWQgdG8gdHdvIFRUTCBkZWNyZW1l bnRzLiAgSSBkbyByZWFkIGluIHN0ZXAgYiB0aGF0IHRoZSBwYWNrZXQgaXMNCj4+IGZvcndhcmRl ZCB1bm1vZGlmaWVkLCBhbmQgcmVhZCBpbiBTZWN0aW9uIDYgIlRoZSBUVEwgaW4gU0YgbGFiZWwg c3RhY2sgZW50cnkgaXMNCj4+IGRlY3JlbWVudGVkIG9uY2UgZm9yIGVhY2ggZm9yd2FyZGluZyBo b3AgaW4gdGhlIFNGUCIgYnV0IHN0aWxsIEkgd29uZGVyIGlmIHNvbWUNCj4+IGNsYXJpZmljYXRp b24gd291bGRuJ3QgYmUgYmVuZWZpY2lhbC4NCj4gDQo+IE9oLCBkZWFyLiBZZXMsIHlvdSdyZSBy aWdodCBhYm91dCB0aGUgd29yZCAiZm9yd2FyZCIuIEl0IGNyb3BzIHVwIHRvbyBvZnRlbiB3aXRo IHRvbyBtYW55IG1lYW5pbmdzLg0KPiANCj4gSSB0aGluayB0aGUgdGlkaWVzIHNvbHV0aW9uIGlz IHRvIGNoYW5nZSB0aGUgZmlyc3QgcXVvdGUgdG8gc2F5Li4uDQo+IA0KPiAgICAgQW4gU0ZGIE1V U1QgZGVjcmVtZW50IHRoZSBUVEwgYnkgb25lIGVhY2ggdGltZSBpdCBwZXJmb3JtcyBhDQo+ICAg ICBsb29rdXAgdG8gZm9yd2FyZCBhIHBhY2tldCB0byB0aGUgbmV4dCBTRkYuDQo+IA0KPj4gbml0 czoNCj4+ICAgIFRUTDogIFRoZSBUVEwgZmllbGRzIGluIHRoZSBTRkMgQ29udGV4dCBsYWJlbCBz dGFjayBlbnRyeSBTRiBsYWJlbA0KPj4gICAgICAgc3RhY2sgZW50cnkgU0hPVUxEIGJlIHNldCB0 byAxIGFzIHN0YXRlZCBpbiBTZWN0aW9uIDUsDQo+PiBEbyB5b3UgbWVhbjogU0ZDIENvbnRleHQg bGFiZWwgc3RhY2sgZW50cnkgKmFuZCogU0YgbGFiZWwgc3RhY2sgZW50cnkgPw0KPiANCj4gWXVw DQo+IA0KPj4gcy9kb2N1bWVudCkuL2RvY3VtZW50Li8NCj4gDQo+IEFjaw0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbXBscyBtYWlsaW5n IGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21wbHMNCj4gDQo+IA0K From nobody Fri Mar 8 09:21:51 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B23131375; Fri, 8 Mar 2019 09:21:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar via Datatracker To: Cc: mpls@ietf.org, draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155206570582.3202.12517909943780959477@ietfa.amsl.com> Date: Fri, 08 Mar 2019 09:21:45 -0800 Archived-At: Subject: [mpls] Secdir telechat review of draft-ietf-mpls-lsp-ping-lag-multipath-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 17:21:46 -0000 Reviewer: Linda Dunbar Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document provides the detailed explanation of SR-MPLS processing in addition to RFC 8402. Since SR-MPLS are in the trusted domain, it is assumed that there is no malicious attacks to the nodes for the data plane and control plane. RFC8402 already has the good description on the Security Consideration for both SR-MPLS & SRv6. Best Regards, Linda Dunbar From nobody Fri Mar 8 10:14:28 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762AC131386 for ; Fri, 8 Mar 2019 10:14:26 -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_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 q_kZzKvcIzN0 for ; Fri, 8 Mar 2019 10:14:24 -0800 (PST) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 CFE03131375 for ; Fri, 8 Mar 2019 10:14:23 -0800 (PST) Received: by mail-it1-x130.google.com with SMTP id z124so22669314itc.2 for ; Fri, 08 Mar 2019 10:14:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=nirG/3LskGUN6EcQTZkfwRUTqrrr/voJWsNAzQNHWKk=; b=oYPJdV+F/e6gKEdlWu8aEHYzczKPKUsK+9FyGZBCJGGq2y1AsmY6/iyth4COe2g3jk N4tRnPM1KB+16TDCkf+/gDHIO3hhAi5dSfccpliv4j3hHMJf4Jq4gjwyQOEh7y3uBYN/ ppIcqJqRCKM9M/vcSieX3EntN6Gpf0/VwqdDjHWxiL6DnXyvrge26DtbEecbC6vpYNcT qo8yVWiNZFxP7EbvIxSgnCulp29G6fejLYYLpB2U/NEg7Jk+SN3K1DzcALRkhsS8EcOB vDnUFv7Y8Nmi3JaCSScH9wrjmr33izDOwy++D/AgC1WdUPicptwpUALPSi1sNAYPnM7u gDqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=nirG/3LskGUN6EcQTZkfwRUTqrrr/voJWsNAzQNHWKk=; b=iwJR+uPBeq7PHkEZIywKDjl5Dt0RtISCZnOawkfuJTahyRUeS1IanRFLn5HIWGpI5c lOyJxgUcU4Psff+fWIeibgr4wmYpfHUiC7YNBxCsQkJKmoFD2GAZPuC7wz7U/1AzCEz2 RY5Gt+TLSlRA05RMluloVmUTugFdp+6M+gDvvH/fusD+8C3LQ/sdcaRab47INDwjSH14 h73++SKZl/ihVp3l1Igw6MTPqkwUD10tBcuxyi6H9apMbK7uNOwaC9vBy8O9lJ99e94J c5V8e4rodOLoTnZxrVEryj+mQPO1Gx+bB1On2JxgECIDC83at1Ej4YCJvgbENt8M31Xu iieQ== X-Gm-Message-State: APjAAAU4kLBhGSCx4RbUztJBbpgmkWj/L7piMKyHHmQKEu18IWdtJawZ Dg9ZOeAglUuUQ99T+ssdx5U= X-Google-Smtp-Source: APXvYqz98GZrN6XnKv4AByLZ6S8vl2msFRtC9cp66THbe6KdL9V8CjBzY6FjagQyKGbwLf0u6eKGLA== X-Received: by 2002:a24:4161:: with SMTP id x94mr8675155ita.69.1552068863142; Fri, 08 Mar 2019 10:14:23 -0800 (PST) Received: from BN8PR06MB6289.namprd06.prod.outlook.com ([52.96.29.13]) by smtp.gmail.com with ESMTPSA id w19sm4195929ita.33.2019.03.08.10.14.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Mar 2019 10:14:22 -0800 (PST) From: Tarek Saad To: tom petch CC: "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-static-yang-08.txt Thread-Index: ATU5OTU3dRXcZeBagFJxXtYijmNCZjAwMTkxd0pWZXMwMDQzMbh77TeT X-MS-Exchange-MessageSentRepresentingType: 1 Date: Fri, 8 Mar 2019 18:14:21 +0000 Message-ID: References: <155155736768.27158.1653954565392604255@ietfa.amsl.com> <016901d4d379$a1e91e60$4001a8c0@gateway.2wire.net> <068601d4d4e3$c5dc4980$4001a8c0@gateway.2wire.net> In-Reply-To: <068601d4d4e3$c5dc4980$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] I-D Action: draft-ietf-mpls-static-yang-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 18:14:27 -0000 SGkgVG9tLA0KDQpUaGFua3MuIFdlJ2xsIHVuaWZ5IHRvICJNYnBzIiBhbmQga2VlcCB0aGlzIGNv bnNpc3RlbnQgaW4gdW5pdHMgYW5kIGRlc2NyaXB0aW9uLg0KDQpSZWdhcmRzLA0KVGFyZWsNCg0K 77u/T24gMy83LzE5LCA3OjQ4IEFNLCAidG9tIHBldGNoIiA8aWV0ZmNAYnRjb25uZWN0LmNvbT4g d3JvdGU6DQoNCiAgICBUYXJlaw0KICAgIA0KICAgIE9uZSBwb2ludCBJIGtlZXAgbm90aWNpbmcg YnV0IGRvIG5vdCB0aGluayBJIGhhdmUgcmFpc2VkIGJlZm9yZSBpcw0KICAgIA0KICAgICAgICAg IHVuaXRzIG1icHM7DQogICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICJCYW5kd2lk dGggaW4gTWJwcywNCiAgICANCiAgICBJIGhhdmUga25vd24gc3lzdGVtcyBmYWlsIGJlY2F1c2Ug b25lIHBhcnR5IHdhcyB1c2luZyBtYnBzLCBhbm90aGVyDQogICAgTWJwcywgc28gc2VlaW5nIGEg bWl4IG9mIHRoZSB0d28sIGFzIGhlcmUsIHJhaXNlcyBhIGZsYWcgZm9yIG1lLiAgSSBub3RlDQog ICAgdGhhdA0KICAgIGRyYWZ0LWlldGYtdGVhcy15YW5nLXRlLXR5cGVzDQogICAgaGFzDQogICAg ICAgICAgIHVuaXRzICJNYnBzIjsNCiAgICB3aGljaCBJIHByZWZlciAtIGlmIHRoZXkgcmVhbGx5 IG1lYW4gTWJwcyBhbmQgbm90IG1icHM7IEkgaGF2ZSBteQ0KICAgIGRvdWJ0cyEgLSBidXQgdGhl bg0KICAgICBkcmFmdC1pZXRmLWwyc20tbDJ2cG4tc2VydmljZS1tb2RlbC0xMA0KICAgIGhhcw0K ICAgICAgICAgICAgdW5pdHMgIm1icHMiOw0KICAgICAgICAgICAgZGVmYXVsdCAiMTAiOyAgZGVz Y3JpcHRpb24NCiAgICAgICAgICAgICAgIkxBQ1Agc3BlZWQuIEJ5IGRlZmF1bHQsIHRoZSBsYWNw IHNwZWVkIGlzIDEwTWJwcy4iOw0KICAgIA0KICAgIFBlcmhhcHMgaW4gdGhlIGNvbnRleHQgb2Yg TVBMUyB0aGVyZSBpcyBubyBhbWJpZ3VpdHkgYnV0IGl0IHdvdWxkIGJlDQogICAgbmljZSB0byBo YXZlIGNvbnNpc3RlbmN5IGF0IGxlYXN0IHdpdGhpbiBhbiBJLUQuDQogICAgDQogICAgVG9tIFBl dGNoDQogICAgDQogICAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KICAgIEZyb206ICJU YXJlayBTYWFkIiA8dHNhYWQubmV0QGdtYWlsLmNvbT4NCiAgICBTZW50OiBXZWRuZXNkYXksIE1h cmNoIDA2LCAyMDE5IDI6NTMgUE0NCiAgICANCiAgICANCiAgICA+IEhpIFRvbSwNCiAgICA+DQog ICAgPiBBcyB1c3VhbCwgdGhhbmtzIGZvciB5b3VyIHJldmlldyBvbiB0aGlzIG9uZSBhbmQgZm9y IHlvdXIgcGF0aWVuY2UuDQogICAgTW9yZQ0KICAgID4gSW5saW5lLi4NCiAgICA+DQogICAgPiBP biBUdWUsIE1hciA1LCAyMDE5IGF0IDEyOjM2IFBNIHRvbSBwZXRjaCA8aWV0ZmNAYnRjb25uZWN0 LmNvbT4gd3JvdGU6DQogICAgPg0KICAgID4gPiBBIGxvbmcgYW5kIHdpbmRpbmcgcm9hZCENCiAg ICA+ID4NCiAgICA+ID4gIG1vZHVsZSBpZXRmLW1wbHMtc3RhdGljIHsNCiAgICA+ID4gLi4uLi4N CiAgICA+ID4gICAgaW1wb3J0IGlldGYtcm91dGluZy10eXBlcyB7DQogICAgPiA+ICAgICAgcHJl Zml4ICJydC10eXBlcyI7DQogICAgPiA+ICAgICAgcmVmZXJlbmNlICJSRkM4Mjk0OiBDb21tb24g WUFORyBEYXRhIFR5cGVzIjsNCiAgICA+ID4NCiAgICA+ID4gSSBzZWUsIGluIHRoZSBSRkMgSW5k ZXgsDQogICAgPiA+DQogICAgPiA+IDgyOTQgQ29tbW9uIFlBTkcgRGF0YSBUeXBlcyBmb3IgdGhl IFJvdXRpbmcgQXJlYS4NCiAgICA+ID4gaS5lLiBhIGRpZmZlcmVudCB0aXRsZQ0KICAgID4gPg0K ICAgID4gPiBbVFNdOiB5ZXMsIHVuZm9ydHVuYXRlbHkgYSBkZWphIHZ1IChmaXhlZCBpbiBhbm90 aGVyIG1vZHVsZSkuIFdlJ2xsDQogICAgdGFrZQ0KICAgID4gY2FyZSBvZiB0aGlzIGluIHRoZSBu ZXcgdmVyc2lvbi4NCiAgICA+DQogICAgPiA+DQogICAgPiA+IG1vZHVsZSBpZXRmLW1wbHMtc3Rh dGljLWV4dGVuZGVkIHsNCiAgICA+ID4gLi4uLg0KICAgID4gPiAgIGltcG9ydCBpZXRmLXJvdXRp bmcgeyAgICBwcmVmaXggInJ0IjsNCiAgICA+ID4gICAgIHJlZmVyZW5jZSAiUkZDNjk5MTogQ29t bW9uIFlBTkcgRGF0YSBUeXBlcyI7DQogICAgPiA+IEkgc3VnZ2VzdA0KICAgID4gPiAgICAgIHJl ZmVyZW5jZSAiUkZDODM0OTogQSBZQU5HIERhdGEgTW9kZWwgZm9yIFJvdXRpbmcgTWFuYWdlbWVu dCI7DQogICAgPiA+DQogICAgPiA+IFtUU106IHllcywgd2lsbCB0YWtlIG9mIHRoaXMuDQogICAg Pg0KICAgID4gIHJlZmVyZW5jZSAiUkZDIFhYWFg6IEV4dGVuZGVkIFlBTkcgRGF0YSBNb2RlbCBm b3IgTVBMUyBTdGF0aWMgTFNQcyI7DQogICAgPiA+IHVtIC0gSSBzZWUgdGhpcyBJLUQgYXMgdGl0 bGVkDQogICAgPiA+IEEgWUFORyBEYXRhIE1vZGVsIGZvciBNUExTIFN0YXRpYyBMU1BzDQogICAg PiA+DQogICAgPiA+IFtUU106IE9LIGZvciB0aGlzIG9uZSB0b28uDQogICAgPg0KICAgID4gUmVn YXJkcywNCiAgICA+IFRhcmVrDQogICAgPg0KICAgID4NCiAgICA+ID4NCiAgICA+ID4gVG9tIFBl dGNoDQogICAgPiA+DQogICAgPiA+DQogICAgPiA+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0NCiAgICA+ID4gRnJvbTogPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCiAgICA+ID4gVG86 IDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQogICAgPiA+IENjOiA8bXBsc0BpZXRmLm9yZz4NCiAg ICA+ID4gU2VudDogU2F0dXJkYXksIE1hcmNoIDAyLCAyMDE5IDg6MDkgUE0NCiAgICA+ID4NCiAg ICA+ID4gPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGlu ZSBJbnRlcm5ldC1EcmFmdHMNCiAgICA+ID4gZGlyZWN0b3JpZXMuDQogICAgPiA+ID4gVGhpcyBk cmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcg V0cNCiAgICBvZg0KICAgID4gPiB0aGUgSUVURi4NCiAgICA+ID4gPg0KICAgID4gPiA+ICAgICAg ICAgVGl0bGUgICAgICAgICAgIDogQSBZQU5HIERhdGEgTW9kZWwgZm9yIE1QTFMgU3RhdGljIExT UHMNCiAgICA+ID4gPiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IFRhcmVrIFNhYWQNCiAgICA+ ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgIFJha2VzaCBHYW5kaGkNCiAgICA+ID4gPiAg ICAgICAgICAgICAgICAgICAgICAgICAgIFh1ZmVuZyBMaXUNCiAgICA+ID4gPiAgICAgICAgICAg ICAgICAgICAgICAgICAgIFZpc2hudSBQYXZhbiBCZWVyYW0NCiAgICA+ID4gPiAgICAgICAgICAg ICAgICAgICAgICAgICAgIElnb3IgQnJ5c2tpbg0KICAgID4gPiA+IEZpbGVuYW1lICAgICAgICA6 IGRyYWZ0LWlldGYtbXBscy1zdGF0aWMteWFuZy0wOC50eHQNCiAgICA+ID4gPiBQYWdlcyAgICAg ICAgICAgOiAxOA0KICAgID4gPiA+IERhdGUgICAgICAgICAgICA6IDIwMTktMDMtMDINCiAgICA+ ID4gPg0KICAgID4gPiA+IEFic3RyYWN0Og0KICAgID4gPiA+ICAgIFRoaXMgZG9jdW1lbnQgY29u dGFpbnMgdGhlIHNwZWNpZmljYXRpb24gZm9yIHRoZSBNUExTIFN0YXRpYw0KICAgIExhYmVsDQog ICAgPiA+ID4gICAgU3dpdGNoZWQgUGF0aHMgKExTUHMpIFlBTkcgbW9kZWwuICBUaGUgbW9kZWwg YWxsb3dzIGZvciB0aGUNCiAgICA+ID4gPiAgICBwcm92aXNpb25pbmcgb2Ygc3RhdGljIExTUChz KSBvbiBMYWJlbCBFZGdlIFJvdXRlcihzKSBMRVIocykNCiAgICBhbmQNCiAgICA+ID4gPiAgICBM YWJlbCBTd2l0Y2hlZCBSb3V0ZXIocykgTFNSKHMpIGRldmljZXMgYWxvbmcgYSBMU1AgcGF0aA0K ICAgIHdpdGhvdXQNCiAgICA+ID4gdGhlDQogICAgPiA+ID4gICAgZGVwZW5kZW5jeSBvbiBhbnkg c2lnbmFsaW5nIHByb3RvY29sLiAgVGhlIE1QTFMgU3RhdGljIExTUA0KICAgIG1vZGVsDQogICAg PiA+ID4gICAgYXVnbWVudHMgdGhlIE1QTFMgYmFzZSBZQU5HIG1vZGVsIHdpdGggc3BlY2lmaWMg ZGF0YSB0bw0KICAgIGNvbmZpZ3VyZQ0KICAgID4gPiBhbmQNCiAgICA+ID4gPiAgICBtYW5hZ2Ug TVBMUyBTdGF0aWMgTFNQKHMpLg0KICAgID4gPiA+DQogICAgPiA+ID4NCiAgICA+ID4gPiBUaGUg SUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCiAgICA+ID4g PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtc3RhdGlj LXlhbmcvDQogICAgPiA+ID4NCiAgICA+ID4gPiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJz aW9ucyBhdmFpbGFibGUgYXQ6DQogICAgPiA+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtbXBscy1zdGF0aWMteWFuZy0wOA0KICAgID4gPiA+DQogICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW1wbHMtc3RhdGljLXlhbmct MDgNCiAgICA+ID4gPg0KICAgID4gPiA+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9u IGlzIGF2YWlsYWJsZSBhdDoNCiAgICA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1tcGxzLXN0YXRpYy15YW5nLTA4DQogICAgPiA+ID4NCiAgICA+ID4g Pg0KICAgID4gPiA+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mDQogICAgPiA+IHN1Ym1pc3Npb24NCiAgICA+ID4gPiB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQogICAgdG9v bHMuaWV0Zi5vcmcuDQogICAgPiA+ID4NCiAgICA+ID4gPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFs c28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQogICAgPiA+ID4gZnRwOi8vZnRwLmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCiAgICA+ID4gPg0KICAgID4gPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiA+ID4gSS1ELUFubm91 bmNlIG1haWxpbmcgbGlzdA0KICAgID4gPiA+IEktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KICAgID4g PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQog ICAgPiA+ID4gSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcv c2hhZG93Lmh0bWwNCiAgICA+ID4gPiBvciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93 LXNpdGVzLnR4dA0KICAgID4gPg0KICAgID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KICAgID4gPiBtcGxzIG1haWxpbmcgbGlzdA0KICAgID4gPiBt cGxzQGlldGYub3JnDQogICAgPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbXBscw0KICAgID4gPg0KICAgID4NCiAgICANCiAgICANCg== From nobody Fri Mar 8 11:05:04 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28ABC12786D; Fri, 8 Mar 2019 11:04:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mpls@ietf.org Message-ID: <155207189711.3273.5860394930033819442@ietfa.amsl.com> Date: Fri, 08 Mar 2019 11:04:57 -0800 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-static-yang-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 19:04:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching WG of the IETF. Title : A YANG Data Model for MPLS Static LSPs Authors : Tarek Saad Rakesh Gandhi Xufeng Liu Vishnu Pavan Beeram Igor Bryskin Filename : draft-ietf-mpls-static-yang-09.txt Pages : 18 Date : 2019-03-08 Abstract: This document contains the specification for the MPLS Static Label Switched Paths (LSPs) YANG model. The model allows for the provisioning of static LSP(s) on Label Edge Router(s) LER(s) and Label Switched Router(s) LSR(s) devices along a LSP path without the dependency on any signaling protocol. The MPLS Static LSP model augments the MPLS base YANG model with specific data to configure and manage MPLS Static LSP(s). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-static-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mpls-static-yang-09 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-static-yang-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-static-yang-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 8 11:13:15 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D841E127A73 for ; Fri, 8 Mar 2019 11:13:13 -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_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 GqiBhv3nTpdy for ; Fri, 8 Mar 2019 11:13:11 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 829EA1313F9 for ; Fri, 8 Mar 2019 11:13:11 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id x9so17594507iog.12 for ; Fri, 08 Mar 2019 11:13:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=9jl6foEU3yfiCEWKiECev4NhD2dZcgL1733BYG47xRA=; b=bZKaTwKfLfVtzCQ2rJVaBACWrjjRLv06t1ne2fAxOF6MAgzwtRhnDuxSsCilo1+Uv7 HxTKLFQUCGtLw+gFX20HRlSJGHgmCae5e1Uz/TeyZKaGT7lpFg5bDpxCXL4C9LV8NiDl iOsIjZ0mNeJEGWdhSprSGVgQQjURYvc653u5b0aMR0wPxNrCicJs4FT0sOg//SMhvK4z RVSKooFPcppovjBkxijLiH6/AllYkIEuhcOKgc+MaPrhvfHLv+odQCtmse0ZrwDsOt3U 3eDrBE8v1693LsTky902dlYLh2O22ugqT40huKjGV1c0ouBZxhi+A8Ed2d8m+6xYbcr9 5CIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=9jl6foEU3yfiCEWKiECev4NhD2dZcgL1733BYG47xRA=; b=Q65PESCqNr8ujo+vP3rlt0893OeKxaugu94Madl4rE3l3QL3YdxRtcIrdx34tFCBcT 8s1NKPmyYAfn47n+9FzB4xgDmWMBwxxU4P71Kq0uEyF850Mn2oeo1UzcVZxSTWs0VOYg W4wa85tPAUpij5Gu/zLv6k67nyTHJfiNodD7ksPjdzhDv2NGUnIu9u7hNhdBslzYZ+qp b3vXqstjZNZnZXpIP4WPOUWp1Yu+hcVHblm9xWokehvdIY0+hsZH86oNRD+VnZqAOJh8 E44XMxG15Onpwr4oSr9xY3+0lYOTqTGMf3J4DG2f5vTQtkdD/UekAMj8+XbnJstNjqdX XNJA== X-Gm-Message-State: APjAAAX0JuCAJfpG/Op6cNYpbHrOd5fNNxGcDZCgnuey0Fbx/QJ6TEH3 GLD595gVh/BzlBI1f/J2Uio= X-Google-Smtp-Source: APXvYqz27zzWlhrfxjFnBncF+DUydR2w55XpkOrZm+mKbCc+lf/UuT4g2upPHhCE+UhC/HCmQuxGCA== X-Received: by 2002:a6b:7941:: with SMTP id j1mr10709474iop.262.1552072390820; Fri, 08 Mar 2019 11:13:10 -0800 (PST) Received: from BN8PR06MB6289.namprd06.prod.outlook.com ([52.96.29.13]) by smtp.gmail.com with ESMTPSA id k3sm3336954ioa.47.2019.03.08.11.13.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Mar 2019 11:13:10 -0800 (PST) From: Tarek Saad To: tom petch CC: "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-static-yang-08.txt Thread-Index: ATAwNDMx/sjNOmVXteTg2ZbdmzWIITAxNDQ2x8nT5hg= X-MS-Exchange-MessageSentRepresentingType: 1 Date: Fri, 8 Mar 2019 19:13:09 +0000 Message-ID: References: <155155736768.27158.1653954565392604255@ietfa.amsl.com> <016901d4d379$a1e91e60$4001a8c0@gateway.2wire.net> <068601d4d4e3$c5dc4980$4001a8c0@gateway.2wire.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] I-D Action: draft-ietf-mpls-static-yang-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 19:13:14 -0000 VGhhbmtzIFRvbS4gVGhlIGNvbW1lbnRzIGFyZSBhZGRyZXNzZWQgaW4gdmVyc2lvbiAtMDk6IA0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbXBscy1zdGF0aWMteWFuZy0w OQ0KDQpBbmQgZGlmZjoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1p ZXRmLW1wbHMtc3RhdGljLXlhbmctMDkNCg0KUmVnYXJkcywNClRhcmVrDQoNCu+7v09uIDMvOC8x OSwgMToxNCBQTSwgIlRhcmVrIFNhYWQiIDx0c2FhZC5uZXRAZ21haWwuY29tPiB3cm90ZToNCg0K ICAgIEhpIFRvbSwNCiAgICANCiAgICBUaGFua3MuIFdlJ2xsIHVuaWZ5IHRvICJNYnBzIiBhbmQg a2VlcCB0aGlzIGNvbnNpc3RlbnQgaW4gdW5pdHMgYW5kIGRlc2NyaXB0aW9uLg0KICAgIA0KICAg IFJlZ2FyZHMsDQogICAgVGFyZWsNCiAgICANCiAgICDvu79PbiAzLzcvMTksIDc6NDggQU0sICJ0 b20gcGV0Y2giIDxpZXRmY0BidGNvbm5lY3QuY29tPiB3cm90ZToNCiAgICANCiAgICAgICAgVGFy ZWsNCiAgICAgICAgDQogICAgICAgIE9uZSBwb2ludCBJIGtlZXAgbm90aWNpbmcgYnV0IGRvIG5v dCB0aGluayBJIGhhdmUgcmFpc2VkIGJlZm9yZSBpcw0KICAgICAgICANCiAgICAgICAgICAgICAg dW5pdHMgbWJwczsNCiAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICAgICAi QmFuZHdpZHRoIGluIE1icHMsDQogICAgICAgIA0KICAgICAgICBJIGhhdmUga25vd24gc3lzdGVt cyBmYWlsIGJlY2F1c2Ugb25lIHBhcnR5IHdhcyB1c2luZyBtYnBzLCBhbm90aGVyDQogICAgICAg IE1icHMsIHNvIHNlZWluZyBhIG1peCBvZiB0aGUgdHdvLCBhcyBoZXJlLCByYWlzZXMgYSBmbGFn IGZvciBtZS4gIEkgbm90ZQ0KICAgICAgICB0aGF0DQogICAgICAgIGRyYWZ0LWlldGYtdGVhcy15 YW5nLXRlLXR5cGVzDQogICAgICAgIGhhcw0KICAgICAgICAgICAgICAgdW5pdHMgIk1icHMiOw0K ICAgICAgICB3aGljaCBJIHByZWZlciAtIGlmIHRoZXkgcmVhbGx5IG1lYW4gTWJwcyBhbmQgbm90 IG1icHM7IEkgaGF2ZSBteQ0KICAgICAgICBkb3VidHMhIC0gYnV0IHRoZW4NCiAgICAgICAgIGRy YWZ0LWlldGYtbDJzbS1sMnZwbi1zZXJ2aWNlLW1vZGVsLTEwDQogICAgICAgIGhhcw0KICAgICAg ICAgICAgICAgIHVuaXRzICJtYnBzIjsNCiAgICAgICAgICAgICAgICBkZWZhdWx0ICIxMCI7ICBk ZXNjcmlwdGlvbg0KICAgICAgICAgICAgICAgICAgIkxBQ1Agc3BlZWQuIEJ5IGRlZmF1bHQsIHRo ZSBsYWNwIHNwZWVkIGlzIDEwTWJwcy4iOw0KICAgICAgICANCiAgICAgICAgUGVyaGFwcyBpbiB0 aGUgY29udGV4dCBvZiBNUExTIHRoZXJlIGlzIG5vIGFtYmlndWl0eSBidXQgaXQgd291bGQgYmUN CiAgICAgICAgbmljZSB0byBoYXZlIGNvbnNpc3RlbmN5IGF0IGxlYXN0IHdpdGhpbiBhbiBJLUQu DQogICAgICAgIA0KICAgICAgICBUb20gUGV0Y2gNCiAgICAgICAgDQogICAgICAgIC0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0NCiAgICAgICAgRnJvbTogIlRhcmVrIFNhYWQiIDx0c2FhZC5u ZXRAZ21haWwuY29tPg0KICAgICAgICBTZW50OiBXZWRuZXNkYXksIE1hcmNoIDA2LCAyMDE5IDI6 NTMgUE0NCiAgICAgICAgDQogICAgICAgIA0KICAgICAgICA+IEhpIFRvbSwNCiAgICAgICAgPg0K ICAgICAgICA+IEFzIHVzdWFsLCB0aGFua3MgZm9yIHlvdXIgcmV2aWV3IG9uIHRoaXMgb25lIGFu ZCBmb3IgeW91ciBwYXRpZW5jZS4NCiAgICAgICAgTW9yZQ0KICAgICAgICA+IElubGluZS4uDQog ICAgICAgID4NCiAgICAgICAgPiBPbiBUdWUsIE1hciA1LCAyMDE5IGF0IDEyOjM2IFBNIHRvbSBw ZXRjaCA8aWV0ZmNAYnRjb25uZWN0LmNvbT4gd3JvdGU6DQogICAgICAgID4NCiAgICAgICAgPiA+ IEEgbG9uZyBhbmQgd2luZGluZyByb2FkIQ0KICAgICAgICA+ID4NCiAgICAgICAgPiA+ICBtb2R1 bGUgaWV0Zi1tcGxzLXN0YXRpYyB7DQogICAgICAgID4gPiAuLi4uLg0KICAgICAgICA+ID4gICAg aW1wb3J0IGlldGYtcm91dGluZy10eXBlcyB7DQogICAgICAgID4gPiAgICAgIHByZWZpeCAicnQt dHlwZXMiOw0KICAgICAgICA+ID4gICAgICByZWZlcmVuY2UgIlJGQzgyOTQ6IENvbW1vbiBZQU5H IERhdGEgVHlwZXMiOw0KICAgICAgICA+ID4NCiAgICAgICAgPiA+IEkgc2VlLCBpbiB0aGUgUkZD IEluZGV4LA0KICAgICAgICA+ID4NCiAgICAgICAgPiA+IDgyOTQgQ29tbW9uIFlBTkcgRGF0YSBU eXBlcyBmb3IgdGhlIFJvdXRpbmcgQXJlYS4NCiAgICAgICAgPiA+IGkuZS4gYSBkaWZmZXJlbnQg dGl0bGUNCiAgICAgICAgPiA+DQogICAgICAgID4gPiBbVFNdOiB5ZXMsIHVuZm9ydHVuYXRlbHkg YSBkZWphIHZ1IChmaXhlZCBpbiBhbm90aGVyIG1vZHVsZSkuIFdlJ2xsDQogICAgICAgIHRha2UN CiAgICAgICAgPiBjYXJlIG9mIHRoaXMgaW4gdGhlIG5ldyB2ZXJzaW9uLg0KICAgICAgICA+DQog ICAgICAgID4gPg0KICAgICAgICA+ID4gbW9kdWxlIGlldGYtbXBscy1zdGF0aWMtZXh0ZW5kZWQg ew0KICAgICAgICA+ID4gLi4uLg0KICAgICAgICA+ID4gICBpbXBvcnQgaWV0Zi1yb3V0aW5nIHsg ICAgcHJlZml4ICJydCI7DQogICAgICAgID4gPiAgICAgcmVmZXJlbmNlICJSRkM2OTkxOiBDb21t b24gWUFORyBEYXRhIFR5cGVzIjsNCiAgICAgICAgPiA+IEkgc3VnZ2VzdA0KICAgICAgICA+ID4g ICAgICByZWZlcmVuY2UgIlJGQzgzNDk6IEEgWUFORyBEYXRhIE1vZGVsIGZvciBSb3V0aW5nIE1h bmFnZW1lbnQiOw0KICAgICAgICA+ID4NCiAgICAgICAgPiA+IFtUU106IHllcywgd2lsbCB0YWtl IG9mIHRoaXMuDQogICAgICAgID4NCiAgICAgICAgPiAgcmVmZXJlbmNlICJSRkMgWFhYWDogRXh0 ZW5kZWQgWUFORyBEYXRhIE1vZGVsIGZvciBNUExTIFN0YXRpYyBMU1BzIjsNCiAgICAgICAgPiA+ IHVtIC0gSSBzZWUgdGhpcyBJLUQgYXMgdGl0bGVkDQogICAgICAgID4gPiBBIFlBTkcgRGF0YSBN b2RlbCBmb3IgTVBMUyBTdGF0aWMgTFNQcw0KICAgICAgICA+ID4NCiAgICAgICAgPiA+IFtUU106 IE9LIGZvciB0aGlzIG9uZSB0b28uDQogICAgICAgID4NCiAgICAgICAgPiBSZWdhcmRzLA0KICAg ICAgICA+IFRhcmVrDQogICAgICAgID4NCiAgICAgICAgPg0KICAgICAgICA+ID4NCiAgICAgICAg PiA+IFRvbSBQZXRjaA0KICAgICAgICA+ID4NCiAgICAgICAgPiA+DQogICAgICAgID4gPiAtLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQogICAgICAgID4gPiBGcm9tOiA8aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPg0KICAgICAgICA+ID4gVG86IDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQog ICAgICAgID4gPiBDYzogPG1wbHNAaWV0Zi5vcmc+DQogICAgICAgID4gPiBTZW50OiBTYXR1cmRh eSwgTWFyY2ggMDIsIDIwMTkgODowOSBQTQ0KICAgICAgICA+ID4NCiAgICAgICAgPiA+ID4gQSBO ZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQt RHJhZnRzDQogICAgICAgID4gPiBkaXJlY3Rvcmllcy4NCiAgICAgICAgPiA+ID4gVGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgV0cN CiAgICAgICAgb2YNCiAgICAgICAgPiA+IHRoZSBJRVRGLg0KICAgICAgICA+ID4gPg0KICAgICAg ICA+ID4gPiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IEEgWUFORyBEYXRhIE1vZGVsIGZvciBN UExTIFN0YXRpYyBMU1BzDQogICAgICAgID4gPiA+ICAgICAgICAgQXV0aG9ycyAgICAgICAgIDog VGFyZWsgU2FhZA0KICAgICAgICA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgIFJha2Vz aCBHYW5kaGkNCiAgICAgICAgPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBYdWZlbmcg TGl1DQogICAgICAgID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgVmlzaG51IFBhdmFu IEJlZXJhbQ0KICAgICAgICA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgIElnb3IgQnJ5 c2tpbg0KICAgICAgICA+ID4gPiBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW1wbHMtc3Rh dGljLXlhbmctMDgudHh0DQogICAgICAgID4gPiA+IFBhZ2VzICAgICAgICAgICA6IDE4DQogICAg ICAgID4gPiA+IERhdGUgICAgICAgICAgICA6IDIwMTktMDMtMDINCiAgICAgICAgPiA+ID4NCiAg ICAgICAgPiA+ID4gQWJzdHJhY3Q6DQogICAgICAgID4gPiA+ICAgIFRoaXMgZG9jdW1lbnQgY29u dGFpbnMgdGhlIHNwZWNpZmljYXRpb24gZm9yIHRoZSBNUExTIFN0YXRpYw0KICAgICAgICBMYWJl bA0KICAgICAgICA+ID4gPiAgICBTd2l0Y2hlZCBQYXRocyAoTFNQcykgWUFORyBtb2RlbC4gIFRo ZSBtb2RlbCBhbGxvd3MgZm9yIHRoZQ0KICAgICAgICA+ID4gPiAgICBwcm92aXNpb25pbmcgb2Yg c3RhdGljIExTUChzKSBvbiBMYWJlbCBFZGdlIFJvdXRlcihzKSBMRVIocykNCiAgICAgICAgYW5k DQogICAgICAgID4gPiA+ICAgIExhYmVsIFN3aXRjaGVkIFJvdXRlcihzKSBMU1IocykgZGV2aWNl cyBhbG9uZyBhIExTUCBwYXRoDQogICAgICAgIHdpdGhvdXQNCiAgICAgICAgPiA+IHRoZQ0KICAg ICAgICA+ID4gPiAgICBkZXBlbmRlbmN5IG9uIGFueSBzaWduYWxpbmcgcHJvdG9jb2wuICBUaGUg TVBMUyBTdGF0aWMgTFNQDQogICAgICAgIG1vZGVsDQogICAgICAgID4gPiA+ICAgIGF1Z21lbnRz IHRoZSBNUExTIGJhc2UgWUFORyBtb2RlbCB3aXRoIHNwZWNpZmljIGRhdGEgdG8NCiAgICAgICAg Y29uZmlndXJlDQogICAgICAgID4gPiBhbmQNCiAgICAgICAgPiA+ID4gICAgbWFuYWdlIE1QTFMg U3RhdGljIExTUChzKS4NCiAgICAgICAgPiA+ID4NCiAgICAgICAgPiA+ID4NCiAgICAgICAgPiA+ ID4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQog ICAgICAgID4gPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt bXBscy1zdGF0aWMteWFuZy8NCiAgICAgICAgPiA+ID4NCiAgICAgICAgPiA+ID4gVGhlcmUgYXJl IGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KICAgICAgICA+ID4gPiBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tcGxzLXN0YXRpYy15YW5nLTA4DQog ICAgICAgID4gPiA+DQogICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQtaWV0Zi1tcGxzLXN0YXRpYy15YW5nLTA4DQogICAgICAgID4gPiA+DQogICAgICAg ID4gPiA+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoN CiAgICAgICAgPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtbXBscy1zdGF0aWMteWFuZy0wOA0KICAgICAgICA+ID4gPg0KICAgICAgICA+ID4gPg0KICAg ICAgICA+ID4gPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZg0KICAgICAgICA+ID4gc3VibWlzc2lvbg0KICAgICAgICA+ID4g PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQog ICAgICAgIHRvb2xzLmlldGYub3JnLg0KICAgICAgICA+ID4gPg0KICAgICAgICA+ID4gPiBJbnRl cm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQogICAg ICAgID4gPiA+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQogICAgICAgID4g PiA+DQogICAgICAgID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogICAgICAgID4gPiA+IEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCiAgICAg ICAgPiA+ID4gSS1ELUFubm91bmNlQGlldGYub3JnDQogICAgICAgID4gPiA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQogICAgICAgID4gPiA+IElu dGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1s DQogICAgICAgID4gPiA+IG9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMu dHh0DQogICAgICAgID4gPg0KICAgICAgICA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgPiA+IG1wbHMgbWFpbGluZyBsaXN0DQogICAg ICAgID4gPiBtcGxzQGlldGYub3JnDQogICAgICAgID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHMNCiAgICAgICAgPiA+DQogICAgICAgID4NCiAgICAgICAgDQog ICAgICAgIA0KICAgIA0K From nobody Fri Mar 8 13:55:11 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC9B130DCD; Fri, 8 Mar 2019 13:55:00 -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-mpls-lsp-ping-lag-multipath@ietf.org, mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155208210011.3264.12148702952456660789.idtracker@ietfa.amsl.com> Date: Fri, 08 Mar 2019 13:55:00 -0800 Archived-At: Subject: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 21:55:05 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-mpls-lsp-ping-lag-multipath-06: 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-mpls-lsp-ping-lag-multipath/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) The Update to rfc8029 is not clearly explained. The new functionality introduced in this document is clear, but it seems to me that it is optional from the point of view that it is only needed when LAGs exist, and even then, only the Initiator and the Responder need to implement the enhancements. IOW, the Update that this document presents is not one that is needed by all rfc8029 implementations. I'm looking for text that explains that. (2) §6: "Otherwise, if the responder does not know the LSR Capability TLV, an MPLS echo reply with the return code set to "One or more of the TLVs was not understood" MUST be sent back to the initiator LSR." Given that this is the case where the new TLV is not known, then we can't Normatively direct those nodes to do anything (since they probably don't implement anything in this document). s/MUST/must + add a reference to rfc8029 (where the behavior is specified) [The same text appears again in §3 and §3.2. Writing the specification is one place is enough.] BTW, according to rfc8029, the return code will be sent back only if the TLV is mandatory, but §6 defines it as optional. Please be clear and specific about the definition and the instructions to IANA. (3) This document doesn't talk about what should be done if a response is not received, at any point in the process. I searched in rfc8029, but didn't find anything related to timeouts...only §4.8 (Non-compliant Routers), which includes a process on what to do if a reply is not received. That process doesn't seem to apply to this document -- what should an initiator do if a reply is not received? I am specially interested in the discovery phases. (4) [nit] In §7, the DS Flags should look like this (see rfc8012): 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | MBZ |G|E|L|I|N| +-+-+-+-+-+-+-+-+ (5) RFC8126 should be a Normative reference. From nobody Fri Mar 8 14:45:56 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02BF127876; Fri, 8 Mar 2019 14:45:48 -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 Yos0_6JmSp-q; Fri, 8 Mar 2019 14:45:46 -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 A1D4D1277E7; Fri, 8 Mar 2019 14:45:46 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 16812D6118D746E1CF55; Fri, 8 Mar 2019 22:45:44 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 8 Mar 2019 22:45:43 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.29]) by SJCEML702-CHM.china.huawei.com ([169.254.4.10]) with mapi id 14.03.0415.000; Fri, 8 Mar 2019 14:45:41 -0800 From: Linda Dunbar To: Linda Dunbar via Datatracker , "secdir@ietf.org" CC: "mpls@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org" , "ietf@ietf.org" Thread-Topic: Secdir telechat review of draft-ietf-mpls-lsp-ping-lag-multipath-06 Thread-Index: AQHU1dNnxc5hRAyYl0CHKWsrtsDdC6YCUnoQ Date: Fri, 8 Mar 2019 22:45:40 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B2EE17E@sjceml521-mbs.china.huawei.com> References: <155206570582.3202.12517909943780959477@ietfa.amsl.com> In-Reply-To: <155206570582.3202.12517909943780959477@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.125.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] Secdir telechat review of draft-ietf-mpls-lsp-ping-lag-multipath-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 22:45:49 -0000 TmVlZCB0byBtb2RpZnkgbXkgcmV2aWV3IGNvbW1lbnRzOg0KDQpSZXZpZXdlcjogTGluZGEgRHVu YmFyDQpSZXZpZXcgcmVzdWx0OiBSZWFkeQ0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVu dCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRv IHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiAg VGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2Yg dGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLg0KIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNo YWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0 IGNhbGwgY29tbWVudHMuDQoNClRoZSBkZXNjcmliZWQgbWVjaGFuaXNtIGZvciBMU1AgTXVsdGlw YXRoIFBpbmcgaXMgdmVyeSBjbGVhci4NClRoZSBhdXRob3JzIGhhdmUgYWRkZWQgdGhlIHRleHQg dG8gYWRkcmVzcyBteSBjb21tZW50cyB0byB0aGUgMDUgdmVyc2lvbiBvbiB3aHkgdGhlcmUgaXMg bm8gc2VjdXJpdHkgcmlza3Mgb2YgaW50ZXJtZWRpYXRlIExTUnMgdGFtcGVyaW5nIGRhdGEgd2hl biB0aGUgTFNQIE11bHRpcGF0aCBQaW5nICYgcmVzcG9uc2UgYXJlIHRyYXZlcnNpbmcgdGhyb3Vn aC4gDQoNCkxpbmRhIER1bmJhcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog aWV0ZiBbbWFpbHRvOmlldGYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExpbmRhIER1 bmJhciB2aWEgRGF0YXRyYWNrZXINClNlbnQ6IEZyaWRheSwgTWFyY2ggMDgsIDIwMTkgMTE6MjIg QU0NClRvOiBzZWNkaXJAaWV0Zi5vcmcNCkNjOiBtcGxzQGlldGYub3JnOyBkcmFmdC1pZXRmLW1w bHMtbHNwLXBpbmctbGFnLW11bHRpcGF0aC5hbGxAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmcNClN1 YmplY3Q6IFNlY2RpciB0ZWxlY2hhdCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5n LWxhZy1tdWx0aXBhdGgtMDYNCg0KUmV2aWV3ZXI6IExpbmRhIER1bmJhcg0KUmV2aWV3IHJlc3Vs dDogUmVhZHkNCg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUg c2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYg ZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdl cmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVh IGRpcmVjdG9ycy4NCiBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0 IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0K DQpUaGUgZG9jdW1lbnQgcHJvdmlkZXMgdGhlIGRldGFpbGVkIGV4cGxhbmF0aW9uIG9mIFNSLU1Q TFMgcHJvY2Vzc2luZyBpbiBhZGRpdGlvbiB0byBSRkMgODQwMi4gU2luY2UgU1ItTVBMUyBhcmUg aW4gdGhlIHRydXN0ZWQgZG9tYWluLCBpdCBpcyBhc3N1bWVkIHRoYXQgdGhlcmUgaXMgbm8gbWFs aWNpb3VzIGF0dGFja3MgdG8gdGhlIG5vZGVzIGZvciB0aGUgZGF0YSBwbGFuZSBhbmQgY29udHJv bCBwbGFuZS4gIFJGQzg0MDIgYWxyZWFkeSBoYXMgdGhlIGdvb2QgZGVzY3JpcHRpb24gb24gdGhl IFNlY3VyaXR5IENvbnNpZGVyYXRpb24gZm9yIGJvdGggU1ItTVBMUyAmIFNSdjYuDQoNCkJlc3Qg UmVnYXJkcywNCkxpbmRhIER1bmJhcg0KDQo= From nobody Sat Mar 9 07:24:55 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9AB127917 for ; Sat, 9 Mar 2019 07:24:54 -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 EYVEeUXy1pvh for ; Sat, 9 Mar 2019 07:24:51 -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 B7311127598 for ; Sat, 9 Mar 2019 07:24:51 -0800 (PST) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 7EA04AED71710D8C6D20 for ; Sat, 9 Mar 2019 15:24:49 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 9 Mar 2019 15:24:48 +0000 Received: from DGGEMM511-MBS.china.huawei.com ([169.254.2.138]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0415.000; Sat, 9 Mar 2019 23:24:39 +0800 From: "Chenzhe (Z)" To: "mpls@ietf.org" CC: "qiangli (D)" Thread-Topic: New Version Notification for draft-chen-mpls-cqf-lsp-dp-00.txt Thread-Index: AdTWi+0w1D0++ysNToWuWr2CLLJlVA== Date: Sat, 9 Mar 2019 15:24:38 +0000 Message-ID: <9CEC02A9061421448CF80B7E967CE5BB0349B61D@dggemm511-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.111.173] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [mpls] Fwd: New Version Notification for draft-chen-mpls-cqf-lsp-dp-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 15:24:54 -0000 SGkgYWxsLA0KDQpBIC0wMCBkcmFmdCBoYXMgYmVlbiBzdWJtaXR0ZWQsIGFueSBjb21tZW50cyBh cmUgd2VsY29tZS4NCg0KUmVnYXJkcywNClpoZQ0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrl j5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10gDQrlj5HpgIHml7bpl7Q6IDIwMTnlubQz5pyIOeaXpSAyMzoyMQ0K5pS25Lu2 5Lq6OiBDaGVuemhlIChaKSA8Y2hlbnpoZTE3QGh1YXdlaS5jb20+OyBxaWFuZ2xpIChEKSA8cWlh bmdsaTNAaHVhd2VpLmNvbT4NCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1jaGVuLW1wbHMtY3FmLWxzcC1kcC0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtY2hlbi1tcGxzLWNxZi1sc3AtZHAtMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgWmhlIENoZW4gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5 Lg0KDQpOYW1lOgkJZHJhZnQtY2hlbi1tcGxzLWNxZi1sc3AtZHANClJldmlzaW9uOgkwMA0KVGl0 bGU6CQlNUExTLUxTUCBEYXRhIFBsYW5lIGZvciBDeWNsaWMgUXVldWluZyBhbmQgRm9yd2FyZGlu Zw0KRG9jdW1lbnQgZGF0ZToJMjAxOS0wMy0wOQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Np b24NClBhZ2VzOgkJNQ0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1jaGVuLW1wbHMtY3FmLWxzcC1kcC0wMC50eHQNClN0YXR1czogICAg ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jaGVuLW1wbHMtY3Fm LWxzcC1kcC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtY2hlbi1tcGxzLWNxZi1sc3AtZHAtMDANCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWNoZW4tbXBscy1jcWYtbHNwLWRwDQoNCg0K QWJzdHJhY3Q6DQogICBMYXJnZS1zY2FsZSBEZXRlcm1pbmlzdGljIE5ldHdvcmsgKExETikgW2xk bl0gYWltcyB0byBhY2hpZXZlIGJvdW5kZWQNCiAgIGxhdGVuY3kgZm9yd2FyZGluZyBvbiBsYXll ci0zIG5ldHdvcmtzIHRoYXQgY29udGFpbiBsb25nLWRpc3RhbmNlDQogICBsaW5rcywgbGFyZ2Ug bnVtYmVyIG9mIG5vZGVzIGFuZCBmbG93cy4gIExETiByZXF1aXJlcyBhIGRhdGEgcGxhbmUNCiAg IG1lY2hhbmlzbSB0byBpbmRpY2F0ZSBkaWZmZXJlbnQgZm9yd2FyZGluZyBjeWNsZXMgaW4gdGhl IHVwc3RyZWFtDQogICBub2RlLiAgVGhpcyBkb2N1bWVudCBwcm9wb3NlcyB0byB1c2UgbXVsdGlw bGUgTVBMUyBsYWJlbHMgdG8gaW5kaWNhdGUNCiAgIHRoaXMga2luZCBvZiBpbmZvcm1hdGlvbiwg Zm9yIE1QTFMtTFNQIGRhdGEgcGxhbmUuDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K DQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJp YXQNCg0K From nobody Sat Mar 9 16:33:09 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A791277C9; Sat, 9 Mar 2019 16:33:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla via Datatracker To: "The IESG" Cc: draft-ietf-mpls-sfc@ietf.org, Loa Andersson , mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155217798834.28635.9855263501719411858.idtracker@ietfa.amsl.com> Date: Sat, 09 Mar 2019 16:33:08 -0800 Archived-At: Subject: [mpls] Eric Rescorla's No Objection on draft-ietf-mpls-sfc-07: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 00:33:09 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-mpls-sfc-07: 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-mpls-sfc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have discussed appropriate text with the editors that will resolve my DISCUSS and trust them to submit a new draft. From nobody Sun Mar 10 09:56:00 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D1712796C; Sun, 10 Mar 2019 09:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 ss4PiYWj2pwJ; Sun, 10 Mar 2019 09:55:55 -0700 (PDT) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.116]) (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 5481C1277DE; Sun, 10 Mar 2019 09:55:54 -0700 (PDT) Received: from [85.158.142.200] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-5.bemta.az-b.eu-central-1.aws.symcld.net id F9/DF-12473-591458C5; Sun, 10 Mar 2019 16:55:49 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTWUwTURSGuTPTdtSOGQrIsUENJUZAWyhiLEY jPkk0Lg9uMRCdloHWlAHbEqvxARfEiIoPrg0V1BIBG5VNsBCXBlkULZgYExQaFBQIS4gJgibG mU5VfDn5zvn/e+45kzskriiUKUnWbmMtHGNWSecTydGpGeormwrTE994Fujqzj6U6prutEp0v RVVEl1n6QyuK3cPyXTt3T9RqjTtdOu4JM3lmsV2YvslJk6faz8oMVY8H8Lzakcw+7sPlUQB6h rEzqH5JEHfxuFygwcXEgVdgsE19yMkJn4EbV/u8sk8UkpvgNp7fVKBw+k4KDnfSwgmnC7CwH3 pCSYIYfR2mP7Zg0TTLpjq75KInASvvDW4wAS9HN4PVgQ8FJ0BY94HgbOIXgTfX7oDjNOR0DtY FmCgaXC1+HCRI2Dk8y+J6NeDf+gWEuvRcL2/VCbyEnhbVhysb4OJyQH+LMlzDNQPZwgzA/0ZQ U9LW9ATDyW+9iAr4WndTSSaShTgnn0dFMxQ9aIheEEUTI88Dg5UIIWGmXUCK2gDdJR+I8T6Uq i+MECIjbpx8I/dw8XNODjTdR8Xtw+FzhuDxCUU65iztGOOzTHH5uCXwPkv/8CTIFqi4XLxgEz kWCgsdcrm1suRrBql6C2mbKMthzGZ1drERLVWu1qdrNYmJ2mYY2q9hs1XG1jOZmF4VcMcsWqs R3MM5kwNx9pqEf/oMg8TF5vQVFG2Fy0mMVUEVUwUpisW6nMzjxoZq/GAJd/MWr0oiiRVQHWm8 lqohc1m7VkmM/9y/8hAylXh1F5Bpqx5TI7VlC1KL9FW8tntASdOXqz5wsd6vxAbA9ETiOPPvz pxBcHlcqwykmoSWtBCC2M+9/eCP3/HW7REGUahkJAQhTyPteSYbP/royiSRKowsYvcxNn+zjH Kj4jxIz5+ckoY0cb8k5QFSN42NtnmWL+5ZkuHL9TeWGnY6ZwoWmO4v7xvdG3UMrpm91j/yR9Z hpm+hoMTyRHjnn3n9CnHc3tb9FdjvdLT1+ShS2eIuIQbHvbjCl+zbyqp/qy/p+6Mr9HpIqluy pbwKezrjvVpn05kucZnUzaSxZikTPNxuOuQI6N55Z5VMdMqwmpktPG4xcr8BinIR20YBAAA X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-18.tower-245.messagelabs.com!1552236945!3119521!1 X-Originating-IP: [52.33.64.93] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 20870 invoked from network); 10 Mar 2019 16:55:48 -0000 Received: from us-west-2b.mta.dlp.protect.symantec.com (HELO EUR02-HE1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-18.tower-245.messagelabs.com with AES256-SHA256 encrypted SMTP; 10 Mar 2019 16:55:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ABraOsKPO25nzBcTvMdJ2vPpa7WYtsiyL699ep/7a38=; b=j209hmaKpH0TCX19BlTVXpoi7KzI4fGaIDCm4mgP+5tqufxp6Qx9A2Evry8svBoLbDbkeERRKEFvqlwTyvnx6WsdKK3mN0XA56UaZuawFttTd29BHfzcJBck7K330M29TR6W1YTSB7wHFCjY5MiLxBtWelRYLlTv09QjWGNn5SM= Received: from VI1PR03MB3839.eurprd03.prod.outlook.com (20.177.54.23) by VI1PR03MB1807.eurprd03.prod.outlook.com (10.166.42.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18; Sun, 10 Mar 2019 16:55:41 +0000 Received: from VI1PR03MB3839.eurprd03.prod.outlook.com ([fe80::4531:64c5:83dc:4252]) by VI1PR03MB3839.eurprd03.prod.outlook.com ([fe80::4531:64c5:83dc:4252%2]) with mapi id 15.20.1686.021; Sun, 10 Mar 2019 16:55:41 +0000 From: Alexander Vainshtein To: "rtg-ads@ietf.org" CC: "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , "draft-ietf-spring-segment-routing-mpls.authors@ietf.org" , Min Ye Thread-Topic: RTG-DIR Last Call review of draft-ietf-spring-segment-routing-mpls-18 Thread-Index: AdTUGm/eJf6lMfiCTXeKfnpkjeXMAgDR4c+g Date: Sun, 10 Mar 2019 16:55:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 87f37173-d36b-4265-3459-08d6a5793b09 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR03MB1807; x-ms-traffictypediagnostic: VI1PR03MB1807: x-ms-exchange-purlcount: 5 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtWSTFQUjAzTUIxODA3OzIzOkJJZi96OW1GZUU5QXdWL3YrVFhzMm5ibm04?= =?utf-8?B?N2xwdmx1QjJnOXJzMkZUWE9hSnBIc1c5SEE0ci9TU01zb3QzZXpUeCtCZWE5?= =?utf-8?B?UFRYMDlaV015OWFDN1EyYlhkS1phVE5JMTlKQ0M3OTkwZE92cDNZTmxTNUtO?= =?utf-8?B?NkZwTkJGZ0htWkhtWElYYmF3V3gvR2hDWFp2dWJyd3RHd285N1RFTDI2Ulpt?= =?utf-8?B?dml0QkwxRVRaenNyQzVNbWRYOVpMQkg1U0NVRk1wZFVyNkhGRm00emVCYUF2?= =?utf-8?B?NmluRlRYODU4Q1pVTTNZU3VmaGRlcmI1bnIxNGY2SUNZTjRHdnRLcnYvUUVk?= =?utf-8?B?d04vWGl1YmZ1VWNlL2ZRcmYxeXNqS2hUTFgyZmJzc3k4TGl0M2FhVnV3Mlp5?= =?utf-8?B?eTE1YkJuNzJZdFgxMVUreWtzVnBPSUNRWFpyTEJ6YTdoTmVUSitEOWc1UUNv?= =?utf-8?B?L2FZZUhmSVBTUmlnZ3RNcE9hT2lzSjNyRVNySTMzVXUzQXN3M1VNdFhIQ2xo?= =?utf-8?B?a0FJWVpMNUpDYllqSW5pVlgxQ1Z1cnYzOFVBbXZuQzdudklBZ0Z3MmFjU1M4?= =?utf-8?B?eTI5L0xOSk9lM3VYMThKOEttaWRVZTUxWkVCVWR4aEJKR1lSUjI1MG9lMUdw?= =?utf-8?B?ZTRUS1I2VUVvVVp3dkc1S2FjVkUrd0MvUVdIUkl2NWZVNlVVcUI3MWJJUU9G?= =?utf-8?B?Q3ZTWFhVRStRVE5mckRDU0xrckRxTTlialg5b0hCNmtlNEoxSmlZNnFCeVo2?= =?utf-8?B?TlltbjVoNkQwMXdwZXdpS0xpa253b3R0L01ocHlvbm8vNm5sbG45eUFIdytU?= =?utf-8?B?UHQ0ejFGU2d3NXFKTDI4L211SDBlSGRUMWlpWmlWMjlKcVU1OWw5d2J6YzBD?= =?utf-8?B?Q3JWN2loVkdHWjBocERocFZ2Y2VzbDJXWVIxU3ZEaTQ1WmR5NmZJU1lIVk1F?= =?utf-8?B?RGtBN1JEVWFjRXU2bHdLUDVxVDQrRm5xQ3JINm83Vk00VEJRQW9tQ1ZJeUJL?= =?utf-8?B?V2cyaUtuVU5jTFZHbjNTYWl1RWtNQkhycXBlMG5iTmZjNElIVUxYNUpsWGpB?= =?utf-8?B?UW9ta1AwRXJyRWVQdVp1bzErTGJkdCtSejJmRHhWeEZMaWRVVFlCYWdhYm53?= =?utf-8?B?ZVhoUlY5NU05WW02NnE2M3k3UTU5Ris0dzkvbDZnOUM5czJVOHlDZ0htU05W?= =?utf-8?B?OG1QM2tYdnZLVUZ0Si9JOVhyOTBpMmhsMUdKL0hENkhJWjhkbEd5MmZqaTN3?= =?utf-8?B?Kzg0Z0c1VzlIaTRYZXkxeGh6Z1BaZllORTV4YXpmOTJOOVJjWXA3aXErem55?= =?utf-8?B?ZkVpanhXZ0c4LzBXby9DbW5kUVRqZmFrUzVYUDgvQVpSb3BoTzNVKzNGb0hJ?= =?utf-8?B?QUdHMFRtVzBVM0NNYVhySnhHMnk5RTRxeTVVcnQ5OWpjTUpMU0JEOFlKYnl0?= =?utf-8?B?bkVNUk5oTlVnQ05hRmliSDQ5YmJ4OFZ5eUpoeTd0T09DakdobWNDNWxyZFpk?= =?utf-8?B?TlIyaThzVVcweU5obkllWGVyZmY3ck56WHU0NEJPTklkVHBOWkJuUHdBTXBM?= =?utf-8?B?UTFWOWtadFhqYnlhd0N2RUxTNWszZlNtTVZLV1RMT29sM2tndnY2R1BMMHNx?= =?utf-8?B?azFib1pUNHQ1ZFJYWUFKZ1pVVUNVWXg2b1E4Wlh1U0FVYzU3WFpiSThlQ3ZX?= =?utf-8?B?QVQzYlU1UVhHMjJCdkNsSlE4U0s2dGV0bDhpeHRjNHdjb1FoRjRoQ3FwK2xF?= =?utf-8?B?RmcvVU5SS3JaZmVQY21kY2VqMmlTclRqOUgrNVBuOUtjd0NGSC9JZC96V20r?= =?utf-8?B?bkZHZFFEMy9UOGJUSTljSGpaVWEvODJKNXZGOVp1bG8yMkE9PQ==?= x-microsoft-antispam-prvs: x-forefront-prvs: 0972DEC1D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(376002)(396003)(366004)(346002)(136003)(51444003)(189003)(199004)(6436002)(4326008)(53936002)(81166006)(81156014)(478600001)(5640700003)(9686003)(236005)(54896002)(55016002)(476003)(99286004)(66066001)(8676002)(6306002)(102836004)(7696005)(6506007)(7736002)(486006)(26005)(186003)(74316002)(105586002)(106356001)(2351001)(25786009)(6916009)(2906002)(606006)(9326002)(52536013)(2501003)(97736004)(33656002)(71190400001)(66574012)(316002)(5660300002)(14454004)(790700001)(6116002)(3846002)(71200400001)(86362001)(72206003)(54906003)(68736007)(256004)(14444005)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR03MB1807; H:VI1PR03MB3839.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ImIrbtKSX15bnCHCmNCf2APtVVy0YcgrMOewdR2jC0jItnHBlXv3HacR5b1/OSXRyvMFPWHhIiH7vtPwj9FH7YSKmMum6dLQr4dhJBix+SI+E9sud8AIAFZuqXyfstB8KdI2Gn6EjhE9cKIVgin+TSNuhRwS+klf9welYyjcYWQvaBRAB95cu/goPlPF23YMAkwItPrehtg3OY3ijxK3r47w+h/C1NLYWmNTkLzKvr3K709unTi8WdgomMafP7Zg+BqHw8yqFfycXoF2Qi+5cPYYLI1TA32i6fnwHJ6jwNG0kg8SqQLKWpkr+h81DNFvxPdKRJ4pq3efZcxi9lGR56ISvZPimgf2dpOjaj3wgAlIiiihg01uLyODVNqAs8tZhL3knaSr083W2RLkyLHs7xRRu9gOxz0ng4701SDRr5w= Content-Type: multipart/alternative; boundary="_000_VI1PR03MB383988C73163E1658BFCFCCE9D4F0VI1PR03MB3839eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 87f37173-d36b-4265-3459-08d6a5793b09 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2019 16:55:41.7987 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1807 X-CFilter-Loop: Reflected Archived-At: Subject: [mpls] RTG-DIR Last Call review of draft-ietf-spring-segment-routing-mpls-18 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 16:55:59 -0000 --_000_VI1PR03MB383988C73163E1658BFCFCCE9D4F0VI1PR03MB3839eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sCgpJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSBy ZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8g cmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNz IHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRpbWVzIG9u IHNwZWNpYWwgcmVxdWVzdC4gVGhlIHB1cnBvc2Ugb2YgdGhlIHJldmlldyBpcyB0byBwcm92aWRl IGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSDigItodHRwOi8vdHJhYy50b29s cy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyPGh0dHA6Ly90cmFjLnRvb2xzLmll dGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXI+CgpBbHRob3VnaCB0aGVzZSBjb21tZW50 cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQg YmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhl ciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRv IHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0 LgoKRG9jdW1lbnQ6IHJldmlldyBvZiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmct bXBscy0xOApSZXZpZXdlcjogQWxleGFuZGVyICjigJxTYXNoYeKAnSkgVmFpbnNodGVpbgpSZXZp ZXcgRGF0ZTogMTAtTWFyLTE5CklFVEYgTEMgRW5kIERhdGU6IDA3LU1hci0yMDE5CkludGVuZGVk IFN0YXR1czogUHJvcG9zZWQgU3RhbmRhcmQKClN1bW1hcnk6IEkgaGF2ZSBzb21lIG1pbm9yIGNv bmNlcm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgdGhhdCBJIHRoaW5rIHNob3VsZCBiZSByZXNvbHZl ZCBiZWZvcmUgcHVibGljYXRpb24uCgpDb21tZW50czoKCkkgaGF2ZSBkb25lIGFuIGVhcmx5IFJU Ry1ESVIgcmV2aWV3IG9mIHRoZSAtMTQgdmVyc2lvbiBvZiB0aGUgZHJhZnQgaGFsZiBhIHllYXIg YWdvLCBhbmQgdGhlIGlzc3VlcyBJ4oCZdmUgcmFpc2VkIHRoZW4gaGF2ZSBiZWVuIHJlc29sdmVk IGluIHRoZSBzdWJzZXF1ZW50IHZlcnNpb25zIG9uZSB3YXkgb3IgYW5vdGhlcikuIFRoZXJlZm9y ZSB0aGlzIHJldmlldyBoYXMgYmVlbiBpbnRlbnRpb25hbGx5IGZvY3VzZWQgb24gdGhlIGNoYW5n ZXMgZG9uZSB0byB0aGUgZHJhZnQgaW4gdGhlIGZldyByZWNlbnQgdmVyc2lvbnMuCgpJbiBteSBw cmV2aW91cyByZXZpZXcgSSBoYXZlIG5vdGljZWQgdGhhdCB0aGUgZHJhZnQgd2FzIG5vdCBlYXN5 IHJlYWRpbmcgZm9yIG1lLiBTaW5jZSB0aGVuIHJlYWRhYmlsaXR5IG9mIHRoZSBkcmFmdCBoYXMg YmVlbiBpbXByb3ZlZC4gSG93ZXZlciwgdGhlcmUgYXJlIHN0aWxsIHNldmVyYWwgcGxhY2VzIGlu IHRoZSBuZXcgdGV4dCB0aGF0IGFyZSBzdGlsbCBkaWZmaWN1bHQgdG8gcGFyc2UuCgpJIGRpZCBu b3QgcnVuIHRoZSBuaXRzIGNoZWNrZXIgb24gdGhlIGRyYWZ0LCBzbyBteSBsaXN0IG9mIG5pdHMg aXMgcHJvYmFibHkgaW5jb21wbGV0ZS4KCkp1c3QgYXMgd2l0aCBteSBlYXJsaWVyIHJldmlldywg SSBzZW5kIHRoaXMgb25lIGFsc28gdG8gdGhlIE1QTFMgV0cgbGlzdCDigJMgYW5kIGZvciB0aGUg c2FtZSByZWFzb25zLgoKSSB0cmllZCB0byBkaXNjdXNzIG15IHJldmlldyBwcml2YXRlbHkgd2l0 aCB0aGUgYXV0aG9ycywgYnV0IHRoZXkgZGlkIG5vdCByZXNwb25kLgoKTWFqb3IgSXNzdWVzOiBO byBtYWpvciBpc3N1ZXMgZm91bmQuCgpNaW5vciBJc3N1ZXM6CgoxLiAgICBUaGUgdGV4dCBpbiBT ZWN0aW9uIDEgc3RhdGVzIHRoYXQg4oCcYSBuZXR3b3JrIG9wZXJhdG9yIFNIT1VMRCBjb25maWd1 cmUgYXQgbGVhc3Qgb25lIG5vZGUgc2VnbWVudCBwZXIgcm91dGluZyBpbnN0YW5jZSwgdG9wb2xv Z3ksIGFsZ29yaXRobeKAnSBhbmQgY29udGludWVzIHRoYXQg4oCcQW4gaW1wbGVtZW50YXRpb24g TUFZIGNoZWNrIHRoYXQgYW4gSUdQIG5vZGUtU0lEIGlzIG5vdCBhc3NvY2lhdGVkIHdpdGggYSBw cmVmaXggdGhhdCBpcyBvd25lZCBieSBtb3JlIHRoYW4gb25lIHJvdXRlciB3aXRoaW4gdGhlIHNh bWUgcm91dGluZyBkb21haW4sIElmIHNvLCBpdCBTSE9VTEQgTk9UIHVzZSB0aGlzIE5vZGUtU0lE LCBNQVkgdXNlIGFub3RoZXIgb25lIGlmIGF2YWlsYWJsZSwgYW5kIFNIT1VMRCBsb2cgYW4gZXJy b3LigJ0uIFRoaXMgbG9va3Mgc29tZXdoYXQgY29udHJvdmVyc2lhbCB0byBtZSBiZWNhdXNlOgoK YS4gICAgVGhlIGNoZWNrIG9mIHRoZSBOb2RlIFNJRCBub3QgYmVpbmcgb3duZWQgYnkgbW9yZSB0 aGFuIG9uZSByb3V0ZXIgaW4gdGhlIHJvdXRpbmcgZG9tYWluIGlzIGRlZmluZWQgYXMgcHVyZWx5 IG9wdGlvbmFsLiBBY2NvcmRpbmcgdG8gUkZDIDIxMTksIGltcGxlbWVudGF0aW9ucyB0aGF0IGNo b29zZSB0byBpbXBsZW1lbnQgc3VjaCBhIGNoZWNrIG11c3QgYmUgYWJsZSB0byBpbnRlcm9wZXJh dGUgd2l0aCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkbyBub3QgaW1wbGVtZW50IGl0CgpiLiAgICBU aGUgcmVjb21tZW5kZWQgaGFuZGxpbmcgb2YgdGhlIHJlc3VsdHMgb2YgdGhpcyBjaGVjayAoZnVs bHkgYWxpZ25lZCB3aXRoIHRoZSB0ZXh0IGluIFNlY3Rpb24gMy4yIHBmIFJGQyA4NDAyIHRoYXQg cHJvaGliaXRzIHVzaW5nIHByZWZpeGVzIG93bmVkIGJ5IG1vcmUgdGhhbiBvbmUgcm91dGVyIGlu IHRoZSBkb21haW4gYXMgTm9kZS1TT0RzKSBzdHJvbmdseSBzdWdnZXN0cyB0aGF0IHRoZSBwcmVm aXggdGhhdCBpcyBvd25lZCBieSBtb3JlIHRoYW4gb25lIHJvdXRlciBpbiB0aGUgZG9tYWluIGlz IHVudXNhYmxlIGFzIHRoZSBOb2RlIFNJRAoKSSBzZWUgdHdvIHBvc3NpYmlsaXRpZXMgdG8gcmVz b2x2ZSB0aGlzIGNvbnRyb3ZlcnN5OiBlaXRoZXIgbWFrZSB0aGUgY2hlY2sgaW4gcXVlc3Rpb24g YSDigJxyZWFsIHJlcXVpcmVtZW504oCdIChpLmUuLCByZXBsYWNlIE1BWSB3aXRoIFNIT1VMRCBv ciBldmVuIE1VU1QpLCBvciBleHBsYWluIHdoeSBpdCBpcyBzYWZlIGVub3VnaCBub3QgdG8gaW1w bGVtZW50IHN1Y2ggYSBjaGVjayAoaS5lLiwgaG93IGltcGxlbWVudGF0aW9ucyB0aGF0IHN1cHBv cnQgdGhpcyBjaGVjayBhbmQgaW1wbGVtZW50YXRpb25zIHRoYXQgZG8gbm90IHN1cHBvcnQgaXQg Y2FuIGludGVyb3BlcmF0ZSB3aXRoaW4gYSBnaXZlbiByb3V0aW5nIGRvbWFpbikuIFRoZSBmaXJz dCBvZiB0aGVzZSBvcHRpb25zIHNlZW1zIHRvIG1lIGFsaWduZWQgd2l0aCBTZWN0aW9uIDMuMiBp biBSRkMgODQwMiB0aGF0IHNheXMgdGhhdCDigJxBbiBJR1AgTm9kZS1TSUQgTVVTVCBOT1QgYmUg YXNzb2NpYXRlZCB3aXRoIGEgcHJlZml4IHRoYXQgaXMgb3duZWQgYnkgbW9yZSB0aGFuIG9uZSBy b3V0ZXIgd2l0aGluIHRoZSBzYW1lIHJvdXRpbmcgZG9tYWlu4oCdLgoKMi4gICAgICAgSSBoYXZl ICBhIHByb2JsZW0gd2l0aCB0aGUgaGlnaGxpZ2h0ZWQgcGFydCBvZiB0aGUgZm9sbG93aW5nIHRl eHQgaW4gU2VjdGlvbiAyLjU6CiAgIEFuIGltcGxlbWVudGF0aW9uIE1VU1QgTk9UIGFsbG93IHRo ZSBNQ0NzIGJlbG9uZ2luZyB0byB0aGUgc2FtZQogICByb3V0ZXIgdG8gYXNzaWduIHRoZSBzYW1l IGluY29taW5nIGxhYmVsIHRvIG1vcmUgdGhhbiBvbmUgU1IgRkVDLiBBbgogICBpbXBsZW1lbnRh dGlvbiB0aGF0IGFsbG93cyBzdWNoIGJlaGF2aW9yIGlzIGNvbnNpZGVyZWQgYXMgZmF1bHR5Lgog ICBQcm9jZWR1cmVzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBlcXVhbGx5IGFwcGxpZXMgdG8g dGhpcyBjYXNlLAogICBib3RoIGZvciBpbmNvbWluZyBsYWJlbCBjb2xsaXNpb24gKFNlY3Rpb24g Mi41PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50 LXJvdXRpbmctbXBscy0xOCNzZWN0aW9uLTIuNT4pIGFuZCB0aGUgZWZmZWN0IG9uCiAgIG91dGdv aW5nIGxhYmVsIHByb2dyYW1taW5nIChTZWN0aW9uIDIuNjxodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMtMTgjc2VjdGlvbi0y LjY+KS4KCmEuICAgIFRoZSBTZWN0aW9uIGluIHF1ZXN0aW9uIGRlYWxzIHdpdGggaW5jb21pbmcg bGFiZWwgY29sbGlzaW9uIChpbiBmYWN0LCB0aGUgdGV4dCB0aGF0IGltbWVkaWF0ZWx5IGZvbGxv d3MgdGhlIHByb2JsZW1hdGljIGZyYWdtZW50IHN0YXRlcyB0aGF0IOKAnFRoZSBvYmplY3RpdmUg b2YgdGhlIGZvbGxvd2luZyBzdGVwcyBpcyB0byBkZXRlcm1pbmlzdGljYWxseSBpbnN0YWxsIGlu IHRoZSBNUExTIEluY29taW5nIExhYmVsIE1hcCwgYWxzbyBrbm93biBhcyBsYWJlbCBGSUIsIGEg c2luZ2xlIEZFQyB3aXRoIHRoZSBpbmNvbWluZyBsYWJlbCAiTDEi4oCdCgpiLiAgICBBcyBhIGNv bnNlcXVlbmNlLCBhbnkgbWVudGlvbiBvZiAgb3V0Z29pbmcgbGFiZWwgcHJvZ3JhbW1pbmcsIGxv b2tzIG91dCBvZiBjb250ZXh0IChldmVuIGFjY29tcGFuaWVkIGJ5IGEgZm9yd2FyZCByZWZlcmVu Y2UgdG8gU2VjdGlvbiAyLjYpCgpjLiAgICBTZWN0aW9uIDIuNiBjb3ZlcnMgdGhlIGltcGFjdCBv ZiBpbmNvbWluZyBsYWJlbCBjb2xsaXNpb24gb24gcHJvZ3JhbW1pbmcgb2Ygb3V0Z29pbmcgbGFi ZWxzIGluIHF1aXRlIGEgZ2VuZXJpYyB3YXkuIFRoZXJlZm9yZSBJIHRoaW5rIHRoYXQgdGhlICBo aWdobGlnaHRlZCBwYXJ0IG9mIHRoZSBxdW90ZWQgZnJhZ21lbnQgY2FuIGJlIHNhZmVseSByZW1v dmVkIChjb21wbGV0ZSB3aXRoIHRoZSBncmFtbWFyIG1pc3Rha2UpLgoKZC4gICAgSSBhbHNvIGRv IG5vdCBzZWUgYW55IHZhbHVlIGluIHN0YXRpbmcgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbnMgdGhh dCB2aW9sYXRlcyBhIG1hbmRhdG9yeSByZXF1aXJlbWVudCBvZiB0aGUgc3BlYyBpcyBmYXVsdHkg 4oCTIGlzbuKAmXQgdGhhdCBzZWxmLWV2aWRlbnQ/CgozLiAgICBUaGUgaGlnaGxpZ2h0ZWQgdGV4 dCBpbiBTZWN0aW9uIDIuOCBpcyBub3QgYWNjdXJhdGU6CgogICBGb3IgTG9jYWwgU0lEcywgdGhl IE1DQyBpcyByZXNwb25zaWJsZSBmb3IgZG93bmxvYWRpbmcgdGhlIGNvcnJlY3QKCiAgIGxhYmVs IHZhbHVlIHRvIEZJQi4gRm9yIGV4YW1wbGUsIGFuIElHUCB3aXRoIFNSIGV4dGVuc2lvbnMgW0kt RC5pZXRmLQoKICAgaXNpcy1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9ucywgSS1ELmlldGYtb3Nw Zi1zZWdtZW50LXJvdXRpbmctCgogICBleHRlbnNpb25zXSBhbGxvY2F0ZXMgYW5kIGRvd25sb2Fk cyB0aGUgTVBMUyBsYWJlbCBjb3JyZXNwb25kaW5nIHRvCgogICBhbiBBZGotU0lEIFtSRkM4NDAy PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NDAyPl0uCgphLiAgSUdQIHdpdGggU1Ig ZXh0ZW5zaW9ucyBtYXkgaW5kZWVkIGR5bmFtaWNhbGx5IGFsbG9jYXRlIGFuZCBkb3dubG9hZCBN UExTIGxhYmVscyBhY3RpbmcgYXMgbG9jYWwgQWRqLVNJRHMKCmIuICBIb3dldmVyLCB0aGVzZSBs YWJlbHMgY2FuIGJlIGFsbG9jYXRlZCBieSBjb25maWd1cmF0aW9uIChlLmcuIGFzIG1lbnRpb25l ZCBpbiB0aGUgdGllLWJyZWFraW5nIHJ1bGVzIGluIFNlY3Rpb24gMi41LjEgYW5kIGluIHRoZSBl eGFtcGxlIGluIFNlY3Rpb24gQS4yLjMgaW4gdGhlIGRyYWZ0KSwgaW4gd2hpY2ggY2FzZSBJR1Ag d2l0aCBTUiBleHRlbnNpb25zIHdvdWxkIG9ubHkgcmVzcG9uc2libGUgZm9yIGl0cyBhZHZlcnRp c2VtZW50IGFuZCBpbnN0YWxsYXRpb24uCgoKCk5JVFM6CgogOgoKMS4gICAgSW4gc2VjdGlvbiAy LjU6CgphLiAgICBJbiB0aGUgc2VudGVuY2Ug4oCcUHJvY2VkdXJlcyBkZWZpbmVkIGluIHRoaXMg ZG9jdW1lbnQgZXF1YWxseSBhcHBsaWVzIHRvIHRoaXMgY2FzZeKAnSB0aGUgbm91biBpcyBpbiBw bHVyYWwgYnV0IHRoZSB2ZXJiIGlzIGluIHNpbmd1bGFyLiAoSWYgdGhpcyBzZW50ZW5jZSBpcyBy ZW1vdmVkIGFzIHN1Z2dlc3RlZCBhYm92ZSwgdGhpcyBuaXQgZGlzYXBwZWFycykKCmIuICAgIFRo ZSBzYW1lIHByb2JsZW0gZXhpc3RzIGluIHRoZSBzZW50ZW5jZSDigJxBbiBpbmNvbWluZyBsYWJl bCBjb2xsaXNpb24gb2NjdXJzIGlmIHRoZSBTSURzIG9mIHRoZSBzZXQgb2YgRkVDcyB7RkVDMSwg RkVDMiwuLi4sIEZFQ2t9IG1hcHMgdG8gdGhlIHNhbWUgaW5jb21pbmcgU1IgTVBMUyBsYWJlbCAi TDEi4oCdCgoyLiAgICAgICBJbiBzZWN0aW9uIDIuMTAuMSB0aGUgcHJlcG9zaXRpb24g4oCcdG/i gJ0gYmV0d2VlbiB0aGUgd29yZHMg4oCcYWNjb3JkaW5n4oCdIGFuZCDigJxNUExT4oCdIGlzIG1p c3NpbmcgaW4gdGhlIGZyYWdtZW50IOKAnFB1c2ggdGhlIGNhbGN1bGF0ZWQgbGFiZWwgYWNjb3Jk aW5nIHRoZSBNUExTIGxhYmVsIHB1c2hpbmcgcnVsZXMgc3BlY2lmaWVkIGluIFtSRkMzMDMyXeKA nS4KCjMuICAgICAgIFByb2JsZW1zIHdpdGggcmVmZXJlbmNlczoKCmEuICAgICAgIEFzIHJlcG9y dGVkIGJ5IFNlcmdleTxodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3Nwcmlu Zy9DX1czS0JjTDJBV3htbEI3U3A1M19QdnFiUUE+LCB0aGVyZSBhcmUgdHdvIG9jY3VycmVuY2Vz IG9mIHJlZmVyZW5jZXMgdG8gUkZDIDgwNDIg4oCcT1NQRiBUd28tUGFydCBNZXRyaWPigJ0gaW5z dGVhZCBvZiBSRkMgODQwMi4gTG90cyBvZiB0aGFua3MgdG8gU2VyZ2V5IGZvciBjYXRjaGluZyB0 aGlzCgpiLiAgICAgICBSZWZlcmVuY2UgdG8gUkZDIDgxNzQgbWlzdGFrZW5seSBjb250YWlucyBh IGxpbmsgdG8gIFJGQyA3Mjc0LgoKSG9wZWZ1bGx5IHRoZXNlIG5vdGVzIHdpbGwgYmUgdXNlZnVs LgpSZWdhcmRzLApTYXNoYQoKT2ZmaWNlOiArOTcyLTM5MjY2MzAyCkNlbGw6ICAgICAgKzk3Mi01 NDkyNjYzMDIKRW1haWw6ICAgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20KCgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KClRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSBy ZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggaXMgCkNPTkZJREVO VElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIAp0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0g dXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwg CmFuZCBhbGwgY29waWVzIHRoZXJlb2YuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo= --_000_VI1PR03MB383988C73163E1658BFCFCCE9D4F0VI1PR03MB3839eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+CjxtZXRhIG5hbWU9IkdlbmVyYXRvciIg Y29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPgo8c3R5bGU+PCEt LQovKiBGb250IERlZmluaXRpb25zICovCkBmb250LWZhY2UKCXtmb250LWZhbWlseToiQ2FtYnJp YSBNYXRoIjsKCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQpAZm9udC1mYWNlCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsKCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30KQGZvbnQt ZmFjZQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIg NDt9Ci8qIFN0eWxlIERlZmluaXRpb25zICovCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwKCXttYXJnaW46MGNtOwoJbWFyZ2luLWJvdHRvbTouMDAwMXB0OwoJZm9udC1z aXplOjExLjBwdDsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluawoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsKCWNvbG9yOiMwNTYzQzE7 Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6Izk1NEY3MjsKCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQpwCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87CgltYXJnaW4tcmlnaHQ6MGNtOwoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87CgltYXJnaW4tbGVmdDowY207Cglmb250LXNpemU6MTIuMHB0OwoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQpwcmUKCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7CgltYXJnaW46MGNtOwoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0OwoJZm9udC1zaXplOjEwLjBwdDsKCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRp di5Nc29MaXN0UGFyYWdyYXBoCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0OwoJbWFyZ2luLXRvcDow Y207CgltYXJnaW4tcmlnaHQ6MGNtOwoJbWFyZ2luLWJvdHRvbTowY207CgltYXJnaW4tbGVmdDoz Ni4wcHQ7CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cglmb250LXNpemU6MTEuMHB0OwoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOwoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5OwoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsKCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt YWwwCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOwoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87CgltYXJnaW4tcmlnaHQ6MGNtOwoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87CgltYXJnaW4tbGVmdDowY207Cglmb250LXNpemU6MTIuMHB0OwoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQpzcGFuLkVtYWlsU3R5bGUyMgoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsKCWNvbG9yOndpbmRvd3RleHQ7fQpzcGFuLmljb24KCXttc28tc3R5bGUtbmFtZTpp Y29uO30KLk1zb0NocERlZmF1bHQKCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsKCWZvbnQt c2l6ZToxMC4wcHQ7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9CkBwYWdlIFdv cmRTZWN0aW9uMQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0OwoJbWFyZ2luOjcyLjBwdCA5MC4wcHQg NzIuMHB0IDkwLjBwdDt9CmRpdi5Xb3JkU2VjdGlvbjEKCXtwYWdlOldvcmRTZWN0aW9uMTt9Ci8q IExpc3QgRGVmaW5pdGlvbnMgKi8KQGxpc3QgbDAKCXttc28tbGlzdC1pZDo4Njc3MTUzNDQ7Cglt c28tbGlzdC10eXBlOmh5YnJpZDsKCW1zby1saXN0LXRlbXBsYXRlLWlkczoxOTA4ODEwNDk0IDIz OTM4NzA5MiA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5 ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9CkBsaXN0IGwwOmxldmVsMQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJbWFyZ2luLWxlZnQ6 MzkuNzVwdDsKCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMDpsZXZlbDIKCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsKCW1zby1sZXZlbC10YWItc3RvcDpub25lOwoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJbWFyZ2luLWxlZnQ6NzUuNzVwdDsKCXRl eHQtaW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMDpsZXZlbDMKCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsKCW1zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsKCW1hcmdpbi1sZWZ0OjExMS43NXB0OwoJdGV4dC1pbmRlbnQ6 LTkuMHB0O30KQGxpc3QgbDA6bGV2ZWw0Cgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7CgltYXJnaW4tbGVmdDoxNDcuNzVwdDsKCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMDpsZXZlbDUKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsKCW1zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0OwoJbWFyZ2luLWxlZnQ6MTgzLjc1cHQ7Cgl0ZXh0LWluZGVudDotMTgu MHB0O30KQGxpc3QgbDA6bGV2ZWw2Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 cmlnaHQ7CgltYXJnaW4tbGVmdDoyMTkuNzVwdDsKCXRleHQtaW5kZW50Oi05LjBwdDt9CkBsaXN0 IGwwOmxldmVsNwoJe21zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0OwoJbWFyZ2luLWxlZnQ6MjU1Ljc1cHQ7Cgl0ZXh0LWluZGVudDotMTguMHB0 O30KQGxpc3QgbDA6bGV2ZWw4Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsKCW1hcmdpbi1sZWZ0OjI5MS43NXB0OwoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9CkBsaXN0IGww OmxldmVsOQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOwoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0OwoJbWFyZ2lu LWxlZnQ6MzI3Ljc1cHQ7Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQpAbGlzdCBsMQoJe21zby1saXN0 LWlkOjE4NTc5NjQzMTU7Cgltc28tbGlzdC10eXBlOmh5YnJpZDsKCW1zby1saXN0LXRlbXBsYXRl LWlkczotMTk2NTI2MjIzNiAyMzkzODcwOTIgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2 OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQpAbGlzdCBsMTpsZXZl bDEKCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsKCW1hcmdpbi1sZWZ0OjM5Ljc1cHQ7Cgl0ZXh0LWluZGVudDotMTguMHB0O30KQGxpc3Qg bDE6bGV2ZWwyCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7Cgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMTpsZXZlbDMKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsKCW1zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsKCXRleHQtaW5kZW50Oi05LjBwdDt9CkBsaXN0IGwxOmxldmVsNAoJ e21zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 OwoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9CkBsaXN0IGwxOmxldmVsNQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotMTguMHB0O30KQGxpc3QgbDE6 bGV2ZWw2Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7Cgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7Cgl0ZXh0LWlu ZGVudDotOS4wcHQ7fQpAbGlzdCBsMTpsZXZlbDcKCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsK CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQpA bGlzdCBsMTpsZXZlbDgKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsKCW1z by1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDt9CkBsaXN0IGwxOmxldmVsOQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OnJvbWFuLWxvd2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0OwoJdGV4dC1pbmRlbnQ6LTkuMHB0O30Kb2wKCXttYXJnaW4t Ym90dG9tOjBjbTt9CnVsCgl7bWFyZ2luLWJvdHRvbTowY207fQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPgo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPgo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPgo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPgo8L2hlYWQ+Cjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+CjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+CjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SGVsbG8sCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JIGhhdmUgYmVlbiBz ZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcyBkcmFm dC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9y IHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0CiBj YWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRo ZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBS b3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0 b3JhdGUsIHBsZWFzZSBzZWUKPGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJl YS9ydGcvdHJhYy93aWtpL1J0Z0RpciI+PHNwYW4gY2xhc3M9Imljb24iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiNCQjAwMDA7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPuKAizwvc3Bhbj48L3NwYW4+aHR0cDovL3RyYWMudG9vbHMuaWV0 Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpcjwvYT4KPG86cD48L286cD48L3NwYW4+PC9w Pgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkFsdGhvdWdoIHRoZXNlIGNvbW1lbnRz IGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBpdCB3b3VsZCBi ZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVy IElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsCiBhbmQgc3RyaXZlIHRv IHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0 LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ RG9jdW1lbnQ6Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnJldmlldyBvZiBkcmFmdC1pZXRmLXNwcmlu Zy1zZWdtZW50LXJvdXRpbmctbXBscy0xODwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPjxicj4KUmV2aWV3ZXI6IEFsZXhhbmRlciAo4oCcU2FzaGHigJ0pIFZhaW5zaHRlaW48YnI+ ClJldmlldyBEYXRlOiAxMC1NYXItMTk8YnI+CklFVEYgTEMgRW5kIERhdGU6IDA3LU1hci0yMDE5 PGJyPgpJbnRlbmRlZCBTdGF0dXM6IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVw dDtjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUiPlByb3Bvc2VkIFN0YW5kYXJkPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPgo8cD48 c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+U3VtbWFyeTo8L3NwYW4+PC9zdHJv bmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4gSSBoYXZlIHNvbWUgbWlub3IgY29uY2Vy bnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxkIGJlCiByZXNvbHZlZCBi ZWZvcmUgcHVibGljYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPgo8cD48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPkNvbW1lbnRzPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPjoKPG86cD48L286cD48L3NwYW4+PC9wPgo8cD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPkkgaGF2ZSBkb25lIGFuIGVhcmx5IFJURy1ESVIgcmV2aWV3IG9mIHRoZSAtMTQg dmVyc2lvbiBvZiB0aGUgZHJhZnQgaGFsZiBhIHllYXIgYWdvLCBhbmQgdGhlIGlzc3VlcyBJ4oCZ dmUgcmFpc2VkIHRoZW4gaGF2ZSBiZWVuIHJlc29sdmVkIGluIHRoZSBzdWJzZXF1ZW50IHZlcnNp b25zIG9uZSB3YXkgb3IgYW5vdGhlcikuCiBUaGVyZWZvcmUgdGhpcyByZXZpZXcgaGFzIGJlZW4g aW50ZW50aW9uYWxseSBmb2N1c2VkIG9uIHRoZSBjaGFuZ2VzIGRvbmUgdG8gdGhlIGRyYWZ0IGlu IHRoZSBmZXcgcmVjZW50IHZlcnNpb25zLgo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SW4gbXkgcHJldmlvdXMgcmV2aWV3IEkgaGF2ZSBub3Rp Y2VkIHRoYXQgdGhlIGRyYWZ0IHdhcyBub3QgZWFzeSByZWFkaW5nIGZvciBtZS4gU2luY2UgdGhl biByZWFkYWJpbGl0eSBvZiB0aGUgZHJhZnQgaGFzIGJlZW4gaW1wcm92ZWQuIEhvd2V2ZXIsIHRo ZXJlIGFyZSBzdGlsbCBzZXZlcmFsIHBsYWNlcyBpbgogdGhlIG5ldyB0ZXh0IHRoYXQgYXJlIHN0 aWxsIGRpZmZpY3VsdCB0byBwYXJzZS4gPG86cD48L286cD48L3NwYW4+PC9wPgo8cD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPkkgZGlkIG5vdCBydW4gdGhlIG5pdHMgY2hlY2tlciBvbiB0 aGUgZHJhZnQsIHNvIG15IGxpc3Qgb2Ygbml0cyBpcyBwcm9iYWJseSBpbmNvbXBsZXRlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5KdXN0IGFz IHdpdGggbXkgZWFybGllciByZXZpZXcsIEkgc2VuZCB0aGlzIG9uZSBhbHNvIHRvIHRoZSBNUExT IFdHIGxpc3Qg4oCTIGFuZCBmb3IgdGhlIHNhbWUgcmVhc29ucy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+CjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSB0cmllZCB0byBkaXNjdXNzIG15 IHJldmlldyBwcml2YXRlbHkgd2l0aCB0aGUgYXV0aG9ycywgYnV0IHRoZXkgZGlkIG5vdCByZXNw b25kLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHA+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5NYWpvciBJc3N1ZXM8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ OiBObyBtYWpvciBpc3N1ZXMgZm91bmQuPG86cD48L286cD48L3NwYW4+PC9wPgo8cD48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk1pbm9yIElzc3Vlczwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj46CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MzkuNzVwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVs MSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoZSB0ZXh0IGluIFNlY3Rp b24gMSBzdGF0ZXMgdGhhdDwvc3Bhbj4g4oCcPGI+YSBuZXR3b3JrIG9wZXJhdG9yIFNIT1VMRCBj b25maWd1cmUgYXQgbGVhc3Qgb25lIG5vZGUgc2VnbWVudCBwZXIgcm91dGluZyBpbnN0YW5jZSwg dG9wb2xvZ3ksIGFsZ29yaXRobTwvYj7igJ0gPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+YW5kIGNvbnRpbnVlcyB0aGF0 PC9zcGFuPiDigJw8Yj5BbiBpbXBsZW1lbnRhdGlvbiBNQVkgY2hlY2sgdGhhdCBhbiBJR1Agbm9k ZS1TSUQgaXMgbm90IGFzc29jaWF0ZWQgd2l0aCBhIHByZWZpeCB0aGF0IGlzIG93bmVkIGJ5IG1v cmUgdGhhbiBvbmUgcm91dGVyIHdpdGhpbiB0aGUgc2FtZSByb3V0aW5nIGRvbWFpbiwgSWYgc28s IGl0IFNIT1VMRCBOT1QgdXNlIHRoaXMgTm9kZS1TSUQsIE1BWSB1c2UgYW5vdGhlciBvbmUgaWYg YXZhaWxhYmxlLCBhbmQgU0hPVUxEIGxvZyBhbiBlcnJvcjwvYj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj7igJ0uIFRo aXMgbG9va3Mgc29tZXdoYXQgY29udHJvdmVyc2lhbCB0byBtZSBiZWNhdXNlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPgo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3NS43NXB0O3RleHQtaW5kZW50 Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmEuPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsg PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+VGhlIGNoZWNrIG9mIHRoZSBOb2RlIFNJRCBub3QgYmVpbmcgb3duZWQgYnkgbW9y ZSB0aGFuIG9uZSByb3V0ZXIgaW4gdGhlIHJvdXRpbmcgZG9tYWluIGlzIGRlZmluZWQgYXMgcHVy ZWx5IG9wdGlvbmFsLiBBY2NvcmRpbmcgdG8gUkZDIDIxMTksIGltcGxlbWVudGF0aW9ucyB0aGF0 IGNob29zZSB0byBpbXBsZW1lbnQgc3VjaCBhIGNoZWNrIG11c3QgYmUgYWJsZSB0byBpbnRlcm9w ZXJhdGUgd2l0aCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkbyBub3QgaW1wbGVtZW50IGl0IDxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPgo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3NS43NXB0O3RleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmIuPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+VGhlIHJlY29tbWVuZGVkIGhhbmRsaW5nIG9mIHRoZSByZXN1bHRzIG9m IHRoaXMgY2hlY2sgKGZ1bGx5IGFsaWduZWQgd2l0aCB0aGUgdGV4dCBpbiBTZWN0aW9uIDMuMiBw ZiBSRkMgODQwMiB0aGF0IHByb2hpYml0cyB1c2luZyBwcmVmaXhlcyBvd25lZCBieSBtb3JlIHRo YW4gb25lIHJvdXRlciBpbiB0aGUgZG9tYWluIGFzIE5vZGUtU09Ecykgc3Ryb25nbHkgc3VnZ2Vz dHMgdGhhdCB0aGUgcHJlZml4IHRoYXQgaXMgb3duZWQgYnkgbW9yZSB0aGFuIG9uZSByb3V0ZXIg aW4gdGhlIGRvbWFpbiBpcyB1bnVzYWJsZSBhcyB0aGUgTm9kZSBTSUQgJm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wcmU+CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM5Ljc1cHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPkkgc2VlIHR3byBwb3NzaWJpbGl0aWVzIHRvIHJlc29sdmUgdGhpcyBjb250cm92ZXJzeTog ZWl0aGVyIG1ha2UgdGhlIGNoZWNrIGluIHF1ZXN0aW9uIGEg4oCccmVhbCByZXF1aXJlbWVudOKA nSAoaS5lLiwgcmVwbGFjZSA8L3NwYW4+PGI+TUFZPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiB3aXRoIDwvc3Bh bj48Yj5TSE9VTEQ8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+IG9yIGV2ZW4gPC9zcGFuPjxiPk1VU1Q8L2I+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+KSwgb3IgZXhwbGFpbiB3aHkgaXQgaXMgc2FmZSBlbm91Z2ggbm90IHRvIGltcGxl bWVudCBzdWNoIGEgY2hlY2sgKGkuZS4sIGhvdyBpbXBsZW1lbnRhdGlvbnMgdGhhdCBzdXBwb3J0 IHRoaXMgY2hlY2sgYW5kIGltcGxlbWVudGF0aW9ucyB0aGF0IGRvIG5vdCBzdXBwb3J0IGl0IGNh biBpbnRlcm9wZXJhdGUgd2l0aGluIGEgZ2l2ZW4gcm91dGluZyBkb21haW4pPC9zcGFuPi4gPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+VGhlIGZpcnN0IG9mIHRoZXNlIG9wdGlvbnMgc2VlbXMgdG8gbWUgYWxpZ25lZCB3 aXRoIFNlY3Rpb24gMy4yIGluIFJGQyA4NDAyIHRoYXQgc2F5cyB0aGF0IOKAnDwvc3Bhbj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QW4gSUdQIE5vZGUtU0lEIE1VU1QgTk9UIGJl IGFzc29jaWF0ZWQgd2l0aCBhIHByZWZpeCB0aGF0IGlzIG93bmVkIGJ5IG1vcmUgdGhhbiBvbmUg cm91dGVyIHdpdGhpbiB0aGUgc2FtZSByb3V0aW5nIGRvbWFpbjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+4oCdLiA8L3NwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wcmU+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzkuNzVwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4K PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBkaXI9IkxUUiI+PC9zcGFuPkkgaGF2ZSZuYnNwOyBhIHByb2JsZW0gd2l0aCB0aGUgPHNwYW4g c3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij4KaGlnaGxpZ2h0 ZWQ8L3NwYW4+IHBhcnQgb2YgdGhlIGZvbGxvd2luZyB0ZXh0IGluIFNlY3Rpb24gMi41OjxvOnA+ PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48Yj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkFuIGltcGxlbWVudGF0aW9u IE1VU1QgTk9UIGFsbG93IHRoZSBNQ0NzIGJlbG9uZ2luZyB0byB0aGUgc2FtZTxvOnA+PC9vOnA+ PC9zcGFuPjwvYj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDox OC4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IHJvdXRlciB0byBhc3NpZ24gdGhlIHNhbWUgaW5jb21pbmcgbGFiZWwg dG8gbW9yZSB0aGFuIG9uZSBTUiBGRUMuCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdztt c28taGlnaGxpZ2h0OnllbGxvdyI+QW48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9iPjwvcD4K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2JhY2tncm91bmQ6eWVs bG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij4mbmJzcDsmbmJzcDsgaW1wbGVtZW50YXRpb24gdGhh dCBhbGxvd3Mgc3VjaCBiZWhhdmlvciBpcyBjb25zaWRlcmVkIGFzIGZhdWx0eS48L3NwYW4+PC9i PjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86 cD48L286cD48L3NwYW4+PC9iPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjE4LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsKPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21z by1oaWdobGlnaHQ6eWVsbG93Ij5Qcm9jZWR1cmVzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBl cXVhbGx5IGFwcGxpZXMgdG8gdGhpcyBjYXNlLDxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L2I+ PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij48Yj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7YmFja2dyb3Vu ZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPiZuYnNwOyZuYnNwOyBib3RoIGZvciBpbmNv bWluZyBsYWJlbCBjb2xsaXNpb24gKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscy0xOCNzZWN0aW9uLTIuNSI+ PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPlNlY3Rp b24KIDIuNTwvc3Bhbj48L2E+KSBhbmQgdGhlIGVmZmVjdCBvbjxvOnA+PC9vOnA+PC9zcGFuPjwv Yj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPjxi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OztiYWNrZ3Jv dW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+Jm5ic3A7Jm5ic3A7IG91dGdvaW5nIGxh YmVsIHByb2dyYW1taW5nICg8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMtMTgjc2VjdGlvbi0yLjYiPjxzcGFu IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5TZWN0aW9uCiAy LjY8L3NwYW4+PC9hPikuPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+CjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0Ojc1Ljc1cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBs ZXZlbDIgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+YS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGUgU2VjdGlvbiBp biBxdWVzdGlvbiBkZWFscyB3aXRoIGluY29taW5nIGxhYmVsIGNvbGxpc2lvbiAoaW4gZmFjdCwg dGhlIHRleHQgdGhhdCBpbW1lZGlhdGVseSBmb2xsb3dzIHRoZSBwcm9ibGVtYXRpYyBmcmFnbWVu dCBzdGF0ZXMgdGhhdCDigJw8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PlRoZSBvYmplY3RpdmUgb2YgdGhlIGZvbGxvd2luZyBzdGVwcyBpcyB0byBkZXRlcm1pbmlzdGlj YWxseSBpbnN0YWxsIGluIHRoZSBNUExTIEluY29taW5nIExhYmVsIE1hcCwgYWxzbyBrbm93biBh cyBsYWJlbCBGSUIsIGEgc2luZ2xlIEZFQyB3aXRoIHRoZSBpbmNvbWluZyBsYWJlbCAmcXVvdDtM MSZxdW90Ozwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+4oCdIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pgo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3NS43NXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDAgbGV2ZWwyIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+QXMg YSBjb25zZXF1ZW5jZSwgYW55IG1lbnRpb24gb2YmbmJzcDsgPC9zcGFuPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5vdXRnb2luZyBsYWJlbCBwcm9ncmFtbWluZzwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+LCBsb29rcyBvdXQgb2YgY29udGV4dCAoZXZlbiBhY2NvbXBhbmllZCBieSBh IGZvcndhcmQgcmVmZXJlbmNlIHRvIFNlY3Rpb24gMi42KTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pgo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3NS43NXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDAgbGV2ZWwyIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+U2Vj dGlvbiAyLjYgY292ZXJzIHRoZSBpbXBhY3Qgb2YgaW5jb21pbmcgbGFiZWwgY29sbGlzaW9uIG9u IHByb2dyYW1taW5nIG9mIG91dGdvaW5nIGxhYmVscyBpbiBxdWl0ZSBhIGdlbmVyaWMgd2F5LiBU aGVyZWZvcmUgSSB0aGluayB0aGF0IHRoZSAmbmJzcDs8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5 ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPmhpZ2hsaWdodGVkPC9zcGFuPiBwYXJ0IG9mIHRo ZSBxdW90ZWQgZnJhZ21lbnQgY2FuIGJlIHNhZmVseSByZW1vdmVkIChjb21wbGV0ZSB3aXRoIHRo ZSBncmFtbWFyIG1pc3Rha2UpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPgo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDo3NS43NXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwy IGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPmQuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSBhbHNvIGRvIG5vdCBzZWUg YW55IHZhbHVlIGluIHN0YXRpbmcgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbnMgdGhhdCB2aW9sYXRl cyBhIG1hbmRhdG9yeSByZXF1aXJlbWVudCBvZiB0aGUgc3BlYyBpcyBmYXVsdHkg4oCTIGlzbuKA mXQgdGhhdCBzZWxmLWV2aWRlbnQ/PG86cD48L286cD48L3NwYW4+PC9wcmU+CjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM5Ljc1cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZl bDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGUgPHNwYW4gc3R5bGU9 ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij5oaWdobGlnaHRlZDwvc3Bh bj4gdGV4dCBpbiBTZWN0aW9uIDIuOCBpcyBub3QgYWNjdXJhdGU6PG86cD48L286cD48L3NwYW4+ PC9wcmU+CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjIxLjc1cHQiPjxiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEZvciBMb2NhbCBTSURzLCB0aGUgTUNDIGlzIHJlc3Bv bnNpYmxlIGZvciBkb3dubG9hZGluZyB0aGUgY29ycmVjdDxvOnA+PC9vOnA+PC9zcGFuPjwvYj48 L3ByZT4KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEuNzVwdCI+PGI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbGFiZWwgdmFsdWUgdG8gRklCLiBGb3IgZXhhbXBsZSwg YW4gSUdQIHdpdGggU1IgZXh0ZW5zaW9ucyBbSS1ELmlldGYtPG86cD48L286cD48L3NwYW4+PC9i PjwvcHJlPgo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoyMS43NXB0Ij48Yj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBpc2lzLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25z LCBJLUQuaWV0Zi1vc3BmLXNlZ21lbnQtcm91dGluZy08bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9w cmU+CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjIxLjc1cHQiPjxiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7IGV4dGVuc2lvbnNdIDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5k OnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+YWxsb2NhdGVzPC9zcGFuPiBhbmQgZG93bmxv YWRzIHRoZSBNUExTIGxhYmVsIGNvcnJlc3BvbmRpbmcgdG88bzpwPjwvbzpwPjwvc3Bhbj48L2I+ PC9wcmU+CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjIxLjc1cHQiPjxiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFuIEFkai1TSUQgWzxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM4NDAyIiB0aXRsZT0iJnF1b3Q7U2VnbWVudCBSb3V0aW5nIEFy Y2hpdGVjdHVyZSZxdW90OyI+UkZDODQwMjwvYT5dLjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3By ZT4KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzUuNzVwdDt0ZXh0LWluZGVudDotMTguMHB0O21z by1saXN0OmwwIGxldmVsMiBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48Yj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmEuPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsgPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PC9iPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPklHUCB3aXRoIFNSIGV4dGVuc2lvbnM8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4gPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5tYXkgaW5kZWVkIGR5bmFtaWNhbGx5IGFs bG9jYXRlIGFuZCBkb3dubG9hZCBNUExTIGxhYmVscyBhY3RpbmcgYXMgbG9jYWwgQWRqLVNJRHMg PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9i PjwvcHJlPgo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3NS43NXB0O3RleHQtaW5kZW50Oi0xOC4w cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Yi48c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyA8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48L2I+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+SG93ZXZlciwgdGhlc2UgbGFiZWxzIGNhbiBiZSBhbGxvY2F0ZWQgYnkgY29u ZmlndXJhdGlvbiAoZS5nLiBhcyBtZW50aW9uZWQgaW4gdGhlIHRpZS1icmVha2luZyBydWxlcyBp biBTZWN0aW9uIDIuNS4xIGFuZCBpbiB0aGUgZXhhbXBsZSBpbiBTZWN0aW9uIEEuMi4zIGluIHRo ZSBkcmFmdCksIGluIHdoaWNoIGNhc2UgSUdQIHdpdGggU1IgZXh0ZW5zaW9ucyB3b3VsZCBvbmx5 IHJlc3BvbnNpYmxlIGZvciBpdHMgYWR2ZXJ0aXNlbWVudCBhbmQgaW5zdGFsbGF0aW9uLiA8L3Nw YW4+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9w cmU+CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+CjxwcmU+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+TklUUzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+OjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPgo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiA6PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9iPjwvcHJlPgo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozOS43NXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzQi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIGRpcj0iTFRSIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SW4gc2VjdGlvbiAyLjU6PG86cD48L286 cD48L3NwYW4+PC9wcmU+CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVu dDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMiBsZm80Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5hLjxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPkluIHRoZSBzZW50ZW5jZSDigJw8L3NwYW4+PGI+UHJvY2VkdXJlcyBkZWZpbmVk IGluIHRoaXMgZG9jdW1lbnQgZXF1YWxseSBhcHBsaWVzIHRvIHRoaXMgY2FzZTwvYj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj7igJ0gdGhlIG5vdW4gaXMgaW4gcGx1cmFsIGJ1dCB0aGUgdmVyYiBpcyBpbiBzaW5ndWxh ci4gKElmIHRoaXMgc2VudGVuY2UgaXMgcmVtb3ZlZCBhcyBzdWdnZXN0ZWQgYWJvdmUsIHRoaXMg bml0IGRpc2FwcGVhcnMpPG86cD48L286cD48L3NwYW4+PC9wcmU+CjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMiBsZm80 Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj5iLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoZSBzYW1lIHByb2JsZW0gZXhpc3Rz IGluIHRoZSBzZW50ZW5jZSDigJw8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5B biBpbmNvbWluZyBsYWJlbCBjb2xsaXNpb24gb2NjdXJzIGlmIHRoZSBTSURzIG9mIHRoZSBzZXQg b2YgRkVDcyB7RkVDMSwgRkVDMiwuLi4sIEZFQ2t9IG1hcHMgdG8gdGhlIHNhbWUgaW5jb21pbmcg U1IgTVBMUyBsYWJlbCAmcXVvdDtMMSZxdW90Ozwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+4oCdPG86 cD48L286cD48L3NwYW4+PC9wcmU+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzkuNzVwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVs MSBsZm80Ij4KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPkluIHNlY3Rpb24gMi4xMC4xIHRoZSBwcmVwb3Np dGlvbiDigJw8Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPnRvPC9zcGFuPjwvYj7igJ0gYmV0d2VlbiB0aGUgd29yZHMg4oCcPGI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5hY2NvcmRpbmc8L3NwYW4+PC9i PuKAnSBhbmQg4oCcPGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5NUExTPC9zcGFuPjwvYj7igJ0KIGlzIG1pc3NpbmcgaW4gdGhlIGZyYWdtZW50IOKA nDxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+UHVz aCB0aGUgY2FsY3VsYXRlZCBsYWJlbCBhY2NvcmRpbmcgdGhlIE1QTFMgbGFiZWwgcHVzaGluZyBy dWxlcyBzcGVjaWZpZWQgaW4gW1JGQzMwMzJdPC9zcGFuPjwvYj7igJ0uPG86cD48L286cD48L3A+ CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzkuNzVwdDt0 ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm80Ij4KPCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+ PC9zcGFuPlByb2JsZW1zIHdpdGggcmVmZXJlbmNlczo8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDIgbGZvNCI+CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsKPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj48YSBo cmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9DX1czS0Jj TDJBV3htbEI3U3A1M19QdnFiUUEiPkFzIHJlcG9ydGVkIGJ5IFNlcmdleTwvYT4sIHRoZXJlIGFy ZSB0d28gb2NjdXJyZW5jZXMgb2YgcmVmZXJlbmNlcyB0byBSRkMgODA0MiDigJxPU1BGIFR3by1Q YXJ0IE1ldHJpY+KAnSBpbnN0ZWFkIG9mIFJGQyA4NDAyLiBMb3RzCiBvZiB0aGFua3MgdG8gU2Vy Z2V5IGZvciBjYXRjaGluZyB0aGlzPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDEgbGV2ZWwyIGxmbzQiPgo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj5iLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+UmVmZXJlbmNlIHRvIFJG QyA4MTc0IG1pc3Rha2VubHkgY29udGFpbnMgYSBsaW5rIHRvJm5ic3A7IFJGQyA3Mjc0LjxvOnA+ PC9vOnA+PC9wPgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkhvcGVmdWxseSB0aGVz ZSBub3RlcyB3aWxsIGJlIHVzZWZ1bC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJN c29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNh c2hhPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PZmZpY2U6ICYjNDM7OTcyLTM5MjY2MzAyPG86cD48 L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNlbGw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICYjNDM7OTcyLTU0OTI2NjMwMjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5FbWFpbDombmJzcDsmbmJzcDsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b208bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+CjwvZGl2Pgo8YnIgY2xlYXI9ImJvdGgiPgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+CjxCUj4K VGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFu ZCBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBpcyA8QlI+CkNPTkZJREVOVElBTCBhbmQgd2hp Y2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIDxCUj4KdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5IGUt bWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIDxCUj4KYW5k IGFsbCBjb3BpZXMgdGhlcmVvZi48QlI+Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4KPC9ib2R5Pgo8 L2h0bWw+Cgo= --_000_VI1PR03MB383988C73163E1658BFCFCCE9D4F0VI1PR03MB3839eurp_-- From nobody Sun Mar 10 09:56:18 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DEB127985; Sun, 10 Mar 2019 09:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 PVyGAhS2FeZB; Sun, 10 Mar 2019 09:55:56 -0700 (PDT) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.112]) (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 3D14C1240D3; Sun, 10 Mar 2019 09:55:55 -0700 (PDT) Received: from [85.158.142.200] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-b.eu-central-1.aws.symcld.net id EE/FE-29798-891458C5; Sun, 10 Mar 2019 16:55:52 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpil+JIrShJLcpLzFFi42IxUXSI1Z3u2Bp j0LZGwmJzxwY2ix2Lj7Ba3Fq6ktXi5JwfzBYL1jxltzh+4TejA5tHy5G3rB5LlvxkCmCKYs3M S8qvSGDNmDahlblg00umimvv37M3MJ55wtTFyMXBIrCIWWJayy0WEEdIoJ9JYurE+WwQzn1Gi eONN4AynBxsArYSm1bfZQOxRQQ0Jfp7IDqYBdqZJNZM2McEkhAW8JP49vsiI0RRiMTHe2dYIW w9ib+X7oPVsAioSrRNWAQU5+DgFYiV2LIvDiTMKCAm8f3UGrASZgFxiVtP5oPZEgICEkv2nGe GsEUlXj7+xwpRnyRx/+lCRoi4osSMe3PYIWxZiUvzuxlBxksI+ErsuxkCYSpLbHkRC3KxhMBj RomLe45BtWpJ9J8/DmVLSezfPI8RoqhfSOJFzywWiESORNv7yVBFMhLfXu6EuqeBTWLrDysQW 0ggWeLEnM9Q9XISq3ofskAMusAssXTbCWaIx/IkFj/YB3Yor4CgxMmZT1gmMGrMQvLzLCRls5 CUzQJ6ghkY7ut36UOUKEpM6X7IDmFrSLTOmcuOLL6AkX0Vo0VSUWZ6RkluYmaOrqGBga6hobG uia6RkV5ilW6SXmqpbnJqXklRIlBSL7G8WK+4Mjc5J0UvL7VkEyMwxaUUsojtYLywNP0QoyQH k5IobzdLa4wQX1J+SmVGYnFGfFFpTmrxIUYZDg4lCd6TDkA5waLU9NSKtMwcYLKFSUtw8CiJ8 IaDpHmLCxJzizPTIVKnGL05Dix6OJeZo2/jMyC55T6I3A4md4HJtwefz2UWYsnLz0uVEufdAT JCAGRERmke3AJY1rjEKCslzMvIwMAgxFOQWpSbWYIq/4pRnINRSRhiCk9mXgncHa+ATmQCOnH nvmaQE0sSEVJSDYwbLJ7+O3r9fVLE9Bztgh9pHBNCJkRk37jRJHx38u9Dlh1tkbylKjqH+V/c 6PiT5CCw9OVK1hVpBlcfye067Sd/YPqdL4KX65f9Ykg+rCa3Sfnl3pZTDFNWictZhFUpfD9UH vpZS5J7+6P3jv6tBv5vs9X4JONbNU08+X6I95un9UWmWJ/2nqPEUpyRaKjFXFScCADVfeApFQ QAAA== X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-18.tower-245.messagelabs.com!1552236945!3119521!2 X-Originating-IP: [52.33.64.93] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 21908 invoked from network); 10 Mar 2019 16:55:50 -0000 Received: from us-west-2b.mta.dlp.protect.symantec.com (HELO EUR02-HE1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-18.tower-245.messagelabs.com with AES256-SHA256 encrypted SMTP; 10 Mar 2019 16:55:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nX5UR3ugGsQMHbfimLc5DDBoRUgwUbI9uvnht6upMVs=; b=I0XWvDSS52cYSw5QI8fi6AbECX11WFVJ2yaXU5s4yRJGIDHuyJKr0QhTqDEKKLLwRf5uQPjF5bRhFK4YCzx7G/ZIHeKneyXF5Be0X7bdqLmdnVs+MPjTnwIGxGRw4EsrFJscgm17T2ZxaTvRgr/XeQGcU1VrpUZS+6dCWaORaj8= Received: from VI1PR03MB3839.eurprd03.prod.outlook.com (20.177.54.23) by VI1PR03MB1807.eurprd03.prod.outlook.com (10.166.42.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18; Sun, 10 Mar 2019 16:55:47 +0000 Received: from VI1PR03MB3839.eurprd03.prod.outlook.com ([fe80::4531:64c5:83dc:4252]) by VI1PR03MB3839.eurprd03.prod.outlook.com ([fe80::4531:64c5:83dc:4252%2]) with mapi id 15.20.1686.021; Sun, 10 Mar 2019 16:55:47 +0000 From: Alexander Vainshtein To: "rtg-ads@ietf.org" CC: "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , "draft-ietf-spring-segment-routing-mpls.authors@ietf.org" , Min Ye Thread-Topic: RTG-DIR Last Call review of draft-ietf-spring-segment-routing-mpls-18 Thread-Index: AdTUGm/eJf6lMfiCTXeKfnpkjeXMAg== Date: Sun, 10 Mar 2019 16:55:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 88bd6d81-8931-4805-d9e7-08d6a5793e47 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR03MB1807; x-ms-traffictypediagnostic: VI1PR03MB1807: x-ms-exchange-purlcount: 5 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtWSTFQUjAzTUIxODA3OzIzOk5nSklXUFRUZzFTK2h1RGZoZ2ZXWEE1VnBH?= =?utf-8?B?RWRrWHBQb0RCZ0ZEMTFMSVFwcUY0VHY4VHJnMUplWHFOd25GMVdDQ2xSMTU4?= =?utf-8?B?QzhWREFSTjFBMWNNa2dGdVNpM1F0Sm9LK2JQWFo4NGZlbTBRUWhvSkIybkE2?= =?utf-8?B?cXhqbE01MFpFWUhjdCtqNUtidVRrUGhPRXlkK1NZTVhsVmJEL05Rek9XdDhE?= =?utf-8?B?MDNzQlRFMXh5RmpELzllNXRna2FoQnVnd05YelQ4MnlWeTY4bUxobWg3aHF5?= =?utf-8?B?cWNjcmVXWlR4TGJxK3NURVM4RXdCVE9BWG5uRS91NFdTMFlvR0ZaK2VEUDk1?= =?utf-8?B?OXJONklYOE56RDdsUVBsdjRyOXhvL21VWk10YjkyTFowZzRpakVkRmxla29I?= =?utf-8?B?YU8zNzNVRmwyQTFDS25iK2wzb0E0eHZDUE9tTDBpRVVvK0NOMmtEWUg1R0l4?= =?utf-8?B?UWVqVExjWEs0ZEttcmM2MnBGRUo0aXAyTzRya0UxdGU1OFRLUTJYclZtZ2dX?= =?utf-8?B?TjRYZGdTUkcwMGpLbDZqdGxLQ0xYbmVTRUpqMFJWMkc5Z2JnTXFNZnpGdyt0?= =?utf-8?B?ekxvZm14ZW5QWENZSERxbGlZR25jSmZ5cVZMKzhvN2hEYXhlZGxmTjdKdUZN?= =?utf-8?B?VGhRNU04SnFQRFowNzBtS25wWnVWdjdMdm0wVFNCdTJkRjFQS3lTVWxLNWZN?= =?utf-8?B?eUY4VG92cUZRcURad3ROWFc1MDU3SklaTG9hNGdzSlFlb2ZreWt6L2ZaeGt1?= =?utf-8?B?TWp3QnlrUCthQnl2eGRBVG9tbEpDQ2RldWg3MkFCZGExNktEbExGVjQxdGR4?= =?utf-8?B?NnFnU0t0Z2VlZmxLYnpybVBVeEVSRzFxdzA2MU14TDNtekRuVkRXSkIzMTJQ?= =?utf-8?B?NTZlZUNudFhEWlArUEtSdFRnWFB1YVZjMERkTmpKZmloNE9sZGJ2R3ZtSkFY?= =?utf-8?B?K0VzajRtQllGN2NWUjFwYmh5N3ZLSjVEVDFKTFFXb0dJSUdyaE1NZ0JFdndl?= =?utf-8?B?M0gzMlhHTDVqQjVaQTlZMGFabCtnN1l0TFljcVUvc0lCWFBXNUQwUFFuRzRy?= =?utf-8?B?R2VZVHdPTzd1dWdUbXl2N0dxZDZaTGVCYkxRaEd5NFV5bEJkNHFHNXBKODBF?= =?utf-8?B?Mm5ncU5Zb2xETk5rdGRmcVNNVlMveSt4cnRwSEVvWmpybTNGelNiVkVvUG41?= =?utf-8?B?SFFSUk96OUt3QTdUUXQ2UEZ5Nm11Q2VJZHIvalFoUS8xSjlMQXZRVW5wS3dX?= =?utf-8?B?eVNxbWdrcE9LdGZjc2dpZkVrVkNORWFVV25ZMjhkT3VTWHRtekdTSHh1QW1s?= =?utf-8?B?OGRoVm9RaUI3OUJyQzlnanpMOUJxV21vRDFFdWw3bDBBUjljMlhtbUd3bmNT?= =?utf-8?B?M2E4RWMxL1hxQWltZmdTa1VDcEI2QVYrZkJPNGFjSCtCQUdzaGVjeWhVWGRm?= =?utf-8?B?VUpKNXZqRWVJK3I1anFRTld5VHNINHYvQnF2VndseDJibDZlTU85Sm5BUktQ?= =?utf-8?B?VVE4aGo1TXZZOEtpRm96T1VXM3BzMmJYaEl4eVpOUHQ4UnRGMW5zYTJmVVhG?= =?utf-8?B?UGw0ejVYK3BxeHFXNUVZaE9yVzJra0hNQ2VYZHpFQkFYUFdvbTNpYWdUUFdW?= =?utf-8?B?ZFNrMUx2KzBNSWMvVXZvUVp0TnFNRS8yRTgrZDYyaXo4Tk00dy9tNTBBYmxr?= =?utf-8?B?VXdGa2pGVlp4Z2JGSHhienJBdjFtTDk1cHZiWGFIZ2UvTFlhWnlFYkdXZjRP?= =?utf-8?B?SDN3ZTlsbzBuR3ZnYXFTQkFYWStqQjJQekxLRGJudzF3SUpoSTBqR3pvTUZk?= =?utf-8?B?NFdiODhQa2hDdlhZbFE0OVZpOCtHcldiNitKQ21TendoVnc9PQ==?= x-microsoft-antispam-prvs: x-forefront-prvs: 0972DEC1D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(376002)(396003)(366004)(346002)(136003)(51444003)(189003)(199004)(6436002)(4326008)(53936002)(81166006)(81156014)(478600001)(5640700003)(9686003)(236005)(54896002)(55016002)(476003)(99286004)(66066001)(8676002)(6306002)(102836004)(7696005)(6506007)(7736002)(486006)(26005)(186003)(74316002)(105586002)(106356001)(2351001)(25786009)(6916009)(2906002)(606006)(9326002)(52536013)(2501003)(97736004)(33656002)(71190400001)(66574012)(316002)(5660300002)(14454004)(790700001)(6116002)(3846002)(71200400001)(86362001)(72206003)(54906003)(68736007)(256004)(14444005)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR03MB1807; H:VI1PR03MB3839.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: C6MoA78mtQc0uwtEtkDcrVz+DNLkzc2DyTLAJRh+n//Q6dnp6Nkr9pvwj8ORuiVl/M8X4aczBN0Opi+XDWDnTS0DAHtTcQPHOUKM5MGqfNYWRXuaFRH4P2LJ8LINZMzVx01McGqPmUBZQKBYEyvqMfZJ5xlxC3ELjMoA0cHXAlJwdpwpP5OUR05f0CVITCU/k5wgftZHGn//9SXct/ap+x6OpDvM3jHm0JplgPWpHgdWxgZhYug3ZnPijH5hVY1rNEnUPvKU4wq+EDY2HGLl+5hfY6oCxmwFKyS1khm4tVd4FVB1UBorYfZHgT1Qa/kOz+z4OyTOIDp835YgXIgcjRE+Idbixs1oQQ9HBh1TCrJRImHKTMyD0/gL5zwWt02EnQPAP186iCLVxNl0++dx1usTLVEpP5gSBN/ZlITG7vU= Content-Type: multipart/alternative; boundary="_000_VI1PR03MB3839B5FA07EADE57084F8E389D4F0VI1PR03MB3839eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 88bd6d81-8931-4805-d9e7-08d6a5793e47 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2019 16:55:47.2234 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1807 X-CFilter-Loop: Reflected Archived-At: Subject: [mpls] RTG-DIR Last Call review of draft-ietf-spring-segment-routing-mpls-18 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 16:55:59 -0000 --_000_VI1PR03MB3839B5FA07EADE57084F8E389D4F0VI1PR03MB3839eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sCgpJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSBy ZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8g cmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNz IHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRpbWVzIG9u IHNwZWNpYWwgcmVxdWVzdC4gVGhlIHB1cnBvc2Ugb2YgdGhlIHJldmlldyBpcyB0byBwcm92aWRl IGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSDigItodHRwOi8vdHJhYy50b29s cy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyPGh0dHA6Ly90cmFjLnRvb2xzLmll dGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXI+CgpBbHRob3VnaCB0aGVzZSBjb21tZW50 cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQg YmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhl ciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRv IHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0 LgoKRG9jdW1lbnQ6IHJldmlldyBvZiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmct bXBscy0xOApSZXZpZXdlcjogQWxleGFuZGVyICjigJxTYXNoYeKAnSkgVmFpbnNodGVpbgpSZXZp ZXcgRGF0ZTogMTAtTWFyLTE5CklFVEYgTEMgRW5kIERhdGU6IDA3LU1hci0yMDE5CkludGVuZGVk IFN0YXR1czogUHJvcG9zZWQgU3RhbmRhcmQKClN1bW1hcnk6IEkgaGF2ZSBzb21lIG1pbm9yIGNv bmNlcm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgdGhhdCBJIHRoaW5rIHNob3VsZCBiZSByZXNvbHZl ZCBiZWZvcmUgcHVibGljYXRpb24uCgpDb21tZW50czoKCkkgaGF2ZSBkb25lIGFuIGVhcmx5IFJU Ry1ESVIgcmV2aWV3IG9mIHRoZSAtMTQgdmVyc2lvbiBvZiB0aGUgZHJhZnQgaGFsZiBhIHllYXIg YWdvLCBhbmQgdGhlIGlzc3VlcyBJ4oCZdmUgcmFpc2VkIHRoZW4gaGF2ZSBiZWVuIHJlc29sdmVk IGluIHRoZSBzdWJzZXF1ZW50IHZlcnNpb25zIG9uZSB3YXkgb3IgYW5vdGhlcikuIFRoZXJlZm9y ZSB0aGlzIHJldmlldyBoYXMgYmVlbiBpbnRlbnRpb25hbGx5IGZvY3VzZWQgb24gdGhlIGNoYW5n ZXMgZG9uZSB0byB0aGUgZHJhZnQgaW4gdGhlIGZldyByZWNlbnQgdmVyc2lvbnMuCgpJbiBteSBw cmV2aW91cyByZXZpZXcgSSBoYXZlIG5vdGljZWQgdGhhdCB0aGUgZHJhZnQgd2FzIG5vdCBlYXN5 IHJlYWRpbmcgZm9yIG1lLiBTaW5jZSB0aGVuIHJlYWRhYmlsaXR5IG9mIHRoZSBkcmFmdCBoYXMg YmVlbiBpbXByb3ZlZC4gSG93ZXZlciwgdGhlcmUgYXJlIHN0aWxsIHNldmVyYWwgcGxhY2VzIGlu IHRoZSBuZXcgdGV4dCB0aGF0IGFyZSBzdGlsbCBkaWZmaWN1bHQgdG8gcGFyc2UuCgpJIGRpZCBu b3QgcnVuIHRoZSBuaXRzIGNoZWNrZXIgb24gdGhlIGRyYWZ0LCBzbyBteSBsaXN0IG9mIG5pdHMg aXMgcHJvYmFibHkgaW5jb21wbGV0ZS4KCkp1c3QgYXMgd2l0aCBteSBlYXJsaWVyIHJldmlldywg SSBzZW5kIHRoaXMgb25lIGFsc28gdG8gdGhlIE1QTFMgV0cgbGlzdCDigJMgYW5kIGZvciB0aGUg c2FtZSByZWFzb25zLgoKSSB0cmllZCB0byBkaXNjdXNzIG15IHJldmlldyBwcml2YXRlbHkgd2l0 aCB0aGUgYXV0aG9ycywgYnV0IHRoZXkgZGlkIG5vdCByZXNwb25kLgoKTWFqb3IgSXNzdWVzOiBO byBtYWpvciBpc3N1ZXMgZm91bmQuCgpNaW5vciBJc3N1ZXM6CgoxLiAgICBUaGUgdGV4dCBpbiBT ZWN0aW9uIDEgc3RhdGVzIHRoYXQg4oCcYSBuZXR3b3JrIG9wZXJhdG9yIFNIT1VMRCBjb25maWd1 cmUgYXQgbGVhc3Qgb25lIG5vZGUgc2VnbWVudCBwZXIgcm91dGluZyBpbnN0YW5jZSwgdG9wb2xv Z3ksIGFsZ29yaXRobeKAnSBhbmQgY29udGludWVzIHRoYXQg4oCcQW4gaW1wbGVtZW50YXRpb24g TUFZIGNoZWNrIHRoYXQgYW4gSUdQIG5vZGUtU0lEIGlzIG5vdCBhc3NvY2lhdGVkIHdpdGggYSBw cmVmaXggdGhhdCBpcyBvd25lZCBieSBtb3JlIHRoYW4gb25lIHJvdXRlciB3aXRoaW4gdGhlIHNh bWUgcm91dGluZyBkb21haW4sIElmIHNvLCBpdCBTSE9VTEQgTk9UIHVzZSB0aGlzIE5vZGUtU0lE LCBNQVkgdXNlIGFub3RoZXIgb25lIGlmIGF2YWlsYWJsZSwgYW5kIFNIT1VMRCBsb2cgYW4gZXJy b3LigJ0uIFRoaXMgbG9va3Mgc29tZXdoYXQgY29udHJvdmVyc2lhbCB0byBtZSBiZWNhdXNlOgoK YS4gICAgVGhlIGNoZWNrIG9mIHRoZSBOb2RlIFNJRCBub3QgYmVpbmcgb3duZWQgYnkgbW9yZSB0 aGFuIG9uZSByb3V0ZXIgaW4gdGhlIHJvdXRpbmcgZG9tYWluIGlzIGRlZmluZWQgYXMgcHVyZWx5 IG9wdGlvbmFsLiBBY2NvcmRpbmcgdG8gUkZDIDIxMTksIGltcGxlbWVudGF0aW9ucyB0aGF0IGNo b29zZSB0byBpbXBsZW1lbnQgc3VjaCBhIGNoZWNrIG11c3QgYmUgYWJsZSB0byBpbnRlcm9wZXJh dGUgd2l0aCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkbyBub3QgaW1wbGVtZW50IGl0CgpiLiAgICBU aGUgcmVjb21tZW5kZWQgaGFuZGxpbmcgb2YgdGhlIHJlc3VsdHMgb2YgdGhpcyBjaGVjayAoZnVs bHkgYWxpZ25lZCB3aXRoIHRoZSB0ZXh0IGluIFNlY3Rpb24gMy4yIHBmIFJGQyA4NDAyIHRoYXQg cHJvaGliaXRzIHVzaW5nIHByZWZpeGVzIG93bmVkIGJ5IG1vcmUgdGhhbiBvbmUgcm91dGVyIGlu IHRoZSBkb21haW4gYXMgTm9kZS1TT0RzKSBzdHJvbmdseSBzdWdnZXN0cyB0aGF0IHRoZSBwcmVm aXggdGhhdCBpcyBvd25lZCBieSBtb3JlIHRoYW4gb25lIHJvdXRlciBpbiB0aGUgZG9tYWluIGlz IHVudXNhYmxlIGFzIHRoZSBOb2RlIFNJRAoKSSBzZWUgdHdvIHBvc3NpYmlsaXRpZXMgdG8gcmVz b2x2ZSB0aGlzIGNvbnRyb3ZlcnN5OiBlaXRoZXIgbWFrZSB0aGUgY2hlY2sgaW4gcXVlc3Rpb24g YSDigJxyZWFsIHJlcXVpcmVtZW504oCdIChpLmUuLCByZXBsYWNlIE1BWSB3aXRoIFNIT1VMRCBv ciBldmVuIE1VU1QpLCBvciBleHBsYWluIHdoeSBpdCBpcyBzYWZlIGVub3VnaCBub3QgdG8gaW1w bGVtZW50IHN1Y2ggYSBjaGVjayAoaS5lLiwgaG93IGltcGxlbWVudGF0aW9ucyB0aGF0IHN1cHBv cnQgdGhpcyBjaGVjayBhbmQgaW1wbGVtZW50YXRpb25zIHRoYXQgZG8gbm90IHN1cHBvcnQgaXQg Y2FuIGludGVyb3BlcmF0ZSB3aXRoaW4gYSBnaXZlbiByb3V0aW5nIGRvbWFpbikuIFRoZSBmaXJz dCBvZiB0aGVzZSBvcHRpb25zIHNlZW1zIHRvIG1lIGFsaWduZWQgd2l0aCBTZWN0aW9uIDMuMiBp biBSRkMgODQwMiB0aGF0IHNheXMgdGhhdCDigJxBbiBJR1AgTm9kZS1TSUQgTVVTVCBOT1QgYmUg YXNzb2NpYXRlZCB3aXRoIGEgcHJlZml4IHRoYXQgaXMgb3duZWQgYnkgbW9yZSB0aGFuIG9uZSBy b3V0ZXIgd2l0aGluIHRoZSBzYW1lIHJvdXRpbmcgZG9tYWlu4oCdLgoKMi4gICAgICAgSSBoYXZl ICBhIHByb2JsZW0gd2l0aCB0aGUgaGlnaGxpZ2h0ZWQgcGFydCBvZiB0aGUgZm9sbG93aW5nIHRl eHQgaW4gU2VjdGlvbiAyLjU6CiAgIEFuIGltcGxlbWVudGF0aW9uIE1VU1QgTk9UIGFsbG93IHRo ZSBNQ0NzIGJlbG9uZ2luZyB0byB0aGUgc2FtZQogICByb3V0ZXIgdG8gYXNzaWduIHRoZSBzYW1l IGluY29taW5nIGxhYmVsIHRvIG1vcmUgdGhhbiBvbmUgU1IgRkVDLiBBbgogICBpbXBsZW1lbnRh dGlvbiB0aGF0IGFsbG93cyBzdWNoIGJlaGF2aW9yIGlzIGNvbnNpZGVyZWQgYXMgZmF1bHR5Lgog ICBQcm9jZWR1cmVzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBlcXVhbGx5IGFwcGxpZXMgdG8g dGhpcyBjYXNlLAogICBib3RoIGZvciBpbmNvbWluZyBsYWJlbCBjb2xsaXNpb24gKFNlY3Rpb24g Mi41PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50 LXJvdXRpbmctbXBscy0xOCNzZWN0aW9uLTIuNT4pIGFuZCB0aGUgZWZmZWN0IG9uCiAgIG91dGdv aW5nIGxhYmVsIHByb2dyYW1taW5nIChTZWN0aW9uIDIuNjxodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMtMTgjc2VjdGlvbi0y LjY+KS4KCmEuICAgIFRoZSBTZWN0aW9uIGluIHF1ZXN0aW9uIGRlYWxzIHdpdGggaW5jb21pbmcg bGFiZWwgY29sbGlzaW9uIChpbiBmYWN0LCB0aGUgdGV4dCB0aGF0IGltbWVkaWF0ZWx5IGZvbGxv d3MgdGhlIHByb2JsZW1hdGljIGZyYWdtZW50IHN0YXRlcyB0aGF0IOKAnFRoZSBvYmplY3RpdmUg b2YgdGhlIGZvbGxvd2luZyBzdGVwcyBpcyB0byBkZXRlcm1pbmlzdGljYWxseSBpbnN0YWxsIGlu IHRoZSBNUExTIEluY29taW5nIExhYmVsIE1hcCwgYWxzbyBrbm93biBhcyBsYWJlbCBGSUIsIGEg c2luZ2xlIEZFQyB3aXRoIHRoZSBpbmNvbWluZyBsYWJlbCAiTDEi4oCdCgpiLiAgICBBcyBhIGNv bnNlcXVlbmNlLCBhbnkgbWVudGlvbiBvZiAgb3V0Z29pbmcgbGFiZWwgcHJvZ3JhbW1pbmcsIGxv b2tzIG91dCBvZiBjb250ZXh0IChldmVuIGFjY29tcGFuaWVkIGJ5IGEgZm9yd2FyZCByZWZlcmVu Y2UgdG8gU2VjdGlvbiAyLjYpCgpjLiAgICBTZWN0aW9uIDIuNiBjb3ZlcnMgdGhlIGltcGFjdCBv ZiBpbmNvbWluZyBsYWJlbCBjb2xsaXNpb24gb24gcHJvZ3JhbW1pbmcgb2Ygb3V0Z29pbmcgbGFi ZWxzIGluIHF1aXRlIGEgZ2VuZXJpYyB3YXkuIFRoZXJlZm9yZSBJIHRoaW5rIHRoYXQgdGhlICBo aWdobGlnaHRlZCBwYXJ0IG9mIHRoZSBxdW90ZWQgZnJhZ21lbnQgY2FuIGJlIHNhZmVseSByZW1v dmVkIChjb21wbGV0ZSB3aXRoIHRoZSBncmFtbWFyIG1pc3Rha2UpLgoKZC4gICAgSSBhbHNvIGRv IG5vdCBzZWUgYW55IHZhbHVlIGluIHN0YXRpbmcgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbnMgdGhh dCB2aW9sYXRlcyBhIG1hbmRhdG9yeSByZXF1aXJlbWVudCBvZiB0aGUgc3BlYyBpcyBmYXVsdHkg 4oCTIGlzbuKAmXQgdGhhdCBzZWxmLWV2aWRlbnQ/CgozLiAgICBUaGUgaGlnaGxpZ2h0ZWQgdGV4 dCBpbiBTZWN0aW9uIDIuOCBpcyBub3QgYWNjdXJhdGU6CgogICBGb3IgTG9jYWwgU0lEcywgdGhl IE1DQyBpcyByZXNwb25zaWJsZSBmb3IgZG93bmxvYWRpbmcgdGhlIGNvcnJlY3QKCiAgIGxhYmVs IHZhbHVlIHRvIEZJQi4gRm9yIGV4YW1wbGUsIGFuIElHUCB3aXRoIFNSIGV4dGVuc2lvbnMgW0kt RC5pZXRmLQoKICAgaXNpcy1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9ucywgSS1ELmlldGYtb3Nw Zi1zZWdtZW50LXJvdXRpbmctCgogICBleHRlbnNpb25zXSBhbGxvY2F0ZXMgYW5kIGRvd25sb2Fk cyB0aGUgTVBMUyBsYWJlbCBjb3JyZXNwb25kaW5nIHRvCgogICBhbiBBZGotU0lEIFtSRkM4NDAy PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NDAyPl0uCgphLiAgSUdQIHdpdGggU1Ig ZXh0ZW5zaW9ucyBtYXkgaW5kZWVkIGR5bmFtaWNhbGx5IGFsbG9jYXRlIGFuZCBkb3dubG9hZCBN UExTIGxhYmVscyBhY3RpbmcgYXMgbG9jYWwgQWRqLVNJRHMKCmIuICBIb3dldmVyLCB0aGVzZSBs YWJlbHMgY2FuIGJlIGFsbG9jYXRlZCBieSBjb25maWd1cmF0aW9uIChlLmcuIGFzIG1lbnRpb25l ZCBpbiB0aGUgdGllLWJyZWFraW5nIHJ1bGVzIGluIFNlY3Rpb24gMi41LjEgYW5kIGluIHRoZSBl eGFtcGxlIGluIFNlY3Rpb24gQS4yLjMgaW4gdGhlIGRyYWZ0KSwgaW4gd2hpY2ggY2FzZSBJR1Ag d2l0aCBTUiBleHRlbnNpb25zIHdvdWxkIG9ubHkgcmVzcG9uc2libGUgZm9yIGl0cyBhZHZlcnRp c2VtZW50IGFuZCBpbnN0YWxsYXRpb24uCgoKCk5JVFM6CgogOgoKMS4gICAgSW4gc2VjdGlvbiAy LjU6CgphLiAgICBJbiB0aGUgc2VudGVuY2Ug4oCcUHJvY2VkdXJlcyBkZWZpbmVkIGluIHRoaXMg ZG9jdW1lbnQgZXF1YWxseSBhcHBsaWVzIHRvIHRoaXMgY2FzZeKAnSB0aGUgbm91biBpcyBpbiBw bHVyYWwgYnV0IHRoZSB2ZXJiIGlzIGluIHNpbmd1bGFyLiAoSWYgdGhpcyBzZW50ZW5jZSBpcyBy ZW1vdmVkIGFzIHN1Z2dlc3RlZCBhYm92ZSwgdGhpcyBuaXQgZGlzYXBwZWFycykKCmIuICAgIFRo ZSBzYW1lIHByb2JsZW0gZXhpc3RzIGluIHRoZSBzZW50ZW5jZSDigJxBbiBpbmNvbWluZyBsYWJl bCBjb2xsaXNpb24gb2NjdXJzIGlmIHRoZSBTSURzIG9mIHRoZSBzZXQgb2YgRkVDcyB7RkVDMSwg RkVDMiwuLi4sIEZFQ2t9IG1hcHMgdG8gdGhlIHNhbWUgaW5jb21pbmcgU1IgTVBMUyBsYWJlbCAi TDEi4oCdCgoyLiAgICAgICBJbiBzZWN0aW9uIDIuMTAuMSB0aGUgcHJlcG9zaXRpb24g4oCcdG/i gJ0gYmV0d2VlbiB0aGUgd29yZHMg4oCcYWNjb3JkaW5n4oCdIGFuZCDigJxNUExT4oCdIGlzIG1p c3NpbmcgaW4gdGhlIGZyYWdtZW50IOKAnFB1c2ggdGhlIGNhbGN1bGF0ZWQgbGFiZWwgYWNjb3Jk aW5nIHRoZSBNUExTIGxhYmVsIHB1c2hpbmcgcnVsZXMgc3BlY2lmaWVkIGluIFtSRkMzMDMyXeKA nS4KCjMuICAgICAgIFByb2JsZW1zIHdpdGggcmVmZXJlbmNlczoKCmEuICAgICAgIEFzIHJlcG9y dGVkIGJ5IFNlcmdleTxodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3Nwcmlu Zy9DX1czS0JjTDJBV3htbEI3U3A1M19QdnFiUUE+LCB0aGVyZSBhcmUgdHdvIG9jY3VycmVuY2Vz IG9mIHJlZmVyZW5jZXMgdG8gUkZDIDgwNDIg4oCcT1NQRiBUd28tUGFydCBNZXRyaWPigJ0gaW5z dGVhZCBvZiBSRkMgODQwMi4gTG90cyBvZiB0aGFua3MgdG8gU2VyZ2V5IGZvciBjYXRjaGluZyB0 aGlzCgpiLiAgICAgICBSZWZlcmVuY2UgdG8gUkZDIDgxNzQgbWlzdGFrZW5seSBjb250YWlucyBh IGxpbmsgdG8gIFJGQyA3Mjc0LgoKSG9wZWZ1bGx5IHRoZXNlIG5vdGVzIHdpbGwgYmUgdXNlZnVs LgpSZWdhcmRzLApTYXNoYQoKT2ZmaWNlOiArOTcyLTM5MjY2MzAyCkNlbGw6ICAgICAgKzk3Mi01 NDkyNjYzMDIKRW1haWw6ICAgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20KCgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KClRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSBy ZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggaXMgCkNPTkZJREVO VElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIAp0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0g dXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwg CmFuZCBhbGwgY29waWVzIHRoZXJlb2YuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo= --_000_VI1PR03MB3839B5FA07EADE57084F8E389D4F0VI1PR03MB3839eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+CjxtZXRhIG5hbWU9IkdlbmVyYXRvciIg Y29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPgo8c3R5bGU+PCEt LQovKiBGb250IERlZmluaXRpb25zICovCkBmb250LWZhY2UKCXtmb250LWZhbWlseToiQ2FtYnJp YSBNYXRoIjsKCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQpAZm9udC1mYWNlCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsKCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30KQGZvbnQt ZmFjZQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIg NDt9Ci8qIFN0eWxlIERlZmluaXRpb25zICovCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwKCXttYXJnaW46MGNtOwoJbWFyZ2luLWJvdHRvbTouMDAwMXB0OwoJZm9udC1z aXplOjExLjBwdDsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluawoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsKCWNvbG9yOiMwNTYzQzE7 Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6Izk1NEY3MjsKCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQpwCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87CgltYXJnaW4tcmlnaHQ6MGNtOwoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87CgltYXJnaW4tbGVmdDowY207Cglmb250LXNpemU6MTIuMHB0OwoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQpwcmUKCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7CgltYXJnaW46MGNtOwoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0OwoJZm9udC1zaXplOjEwLjBwdDsKCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRp di5Nc29MaXN0UGFyYWdyYXBoCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0OwoJbWFyZ2luLXRvcDow Y207CgltYXJnaW4tcmlnaHQ6MGNtOwoJbWFyZ2luLWJvdHRvbTowY207CgltYXJnaW4tbGVmdDoz Ni4wcHQ7CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cglmb250LXNpemU6MTEuMHB0OwoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOwoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5OwoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsKCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt YWwwCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOwoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87CgltYXJnaW4tcmlnaHQ6MGNtOwoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87CgltYXJnaW4tbGVmdDowY207Cglmb250LXNpemU6MTIuMHB0OwoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQpzcGFuLkVtYWlsU3R5bGUyMgoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsKCWNvbG9yOndpbmRvd3RleHQ7fQpzcGFuLmljb24KCXttc28tc3R5bGUtbmFtZTpp Y29uO30KLk1zb0NocERlZmF1bHQKCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsKCWZvbnQt c2l6ZToxMC4wcHQ7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9CkBwYWdlIFdv cmRTZWN0aW9uMQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0OwoJbWFyZ2luOjcyLjBwdCA5MC4wcHQg NzIuMHB0IDkwLjBwdDt9CmRpdi5Xb3JkU2VjdGlvbjEKCXtwYWdlOldvcmRTZWN0aW9uMTt9Ci8q IExpc3QgRGVmaW5pdGlvbnMgKi8KQGxpc3QgbDAKCXttc28tbGlzdC1pZDo4Njc3MTUzNDQ7Cglt c28tbGlzdC10eXBlOmh5YnJpZDsKCW1zby1saXN0LXRlbXBsYXRlLWlkczoxOTA4ODEwNDk0IDIz OTM4NzA5MiA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5 ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9CkBsaXN0IGwwOmxldmVsMQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJbWFyZ2luLWxlZnQ6 MzkuNzVwdDsKCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMDpsZXZlbDIKCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsKCW1zby1sZXZlbC10YWItc3RvcDpub25lOwoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJbWFyZ2luLWxlZnQ6NzUuNzVwdDsKCXRl eHQtaW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMDpsZXZlbDMKCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsKCW1zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsKCW1hcmdpbi1sZWZ0OjExMS43NXB0OwoJdGV4dC1pbmRlbnQ6 LTkuMHB0O30KQGxpc3QgbDA6bGV2ZWw0Cgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7CgltYXJnaW4tbGVmdDoxNDcuNzVwdDsKCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMDpsZXZlbDUKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsKCW1zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0OwoJbWFyZ2luLWxlZnQ6MTgzLjc1cHQ7Cgl0ZXh0LWluZGVudDotMTgu MHB0O30KQGxpc3QgbDA6bGV2ZWw2Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 cmlnaHQ7CgltYXJnaW4tbGVmdDoyMTkuNzVwdDsKCXRleHQtaW5kZW50Oi05LjBwdDt9CkBsaXN0 IGwwOmxldmVsNwoJe21zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0OwoJbWFyZ2luLWxlZnQ6MjU1Ljc1cHQ7Cgl0ZXh0LWluZGVudDotMTguMHB0 O30KQGxpc3QgbDA6bGV2ZWw4Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsKCW1hcmdpbi1sZWZ0OjI5MS43NXB0OwoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9CkBsaXN0IGww OmxldmVsOQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOwoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0OwoJbWFyZ2lu LWxlZnQ6MzI3Ljc1cHQ7Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQpAbGlzdCBsMQoJe21zby1saXN0 LWlkOjE4NTc5NjQzMTU7Cgltc28tbGlzdC10eXBlOmh5YnJpZDsKCW1zby1saXN0LXRlbXBsYXRl LWlkczotMTk2NTI2MjIzNiAyMzkzODcwOTIgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2 OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQpAbGlzdCBsMTpsZXZl bDEKCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsKCW1hcmdpbi1sZWZ0OjM5Ljc1cHQ7Cgl0ZXh0LWluZGVudDotMTguMHB0O30KQGxpc3Qg bDE6bGV2ZWwyCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7Cgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMTpsZXZlbDMKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsKCW1zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsKCXRleHQtaW5kZW50Oi05LjBwdDt9CkBsaXN0IGwxOmxldmVsNAoJ e21zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 OwoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9CkBsaXN0IGwxOmxldmVsNQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotMTguMHB0O30KQGxpc3QgbDE6 bGV2ZWw2Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7Cgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7Cgl0ZXh0LWlu ZGVudDotOS4wcHQ7fQpAbGlzdCBsMTpsZXZlbDcKCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsK CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQpA bGlzdCBsMTpsZXZlbDgKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsKCW1z by1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDt9CkBsaXN0IGwxOmxldmVsOQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OnJvbWFuLWxvd2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0OwoJdGV4dC1pbmRlbnQ6LTkuMHB0O30Kb2wKCXttYXJnaW4t Ym90dG9tOjBjbTt9CnVsCgl7bWFyZ2luLWJvdHRvbTowY207fQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPgo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPgo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPgo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPgo8L2hlYWQ+Cjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+CjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+CjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SGVsbG8sCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JIGhhdmUgYmVlbiBz ZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcyBkcmFm dC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9y IHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0CiBj YWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRo ZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBS b3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0 b3JhdGUsIHBsZWFzZSBzZWUKPGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJl YS9ydGcvdHJhYy93aWtpL1J0Z0RpciI+PHNwYW4gY2xhc3M9Imljb24iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiNCQjAwMDA7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPuKAizwvc3Bhbj48L3NwYW4+aHR0cDovL3RyYWMudG9vbHMuaWV0 Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpcjwvYT4KPG86cD48L286cD48L3NwYW4+PC9w Pgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkFsdGhvdWdoIHRoZXNlIGNvbW1lbnRz IGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBpdCB3b3VsZCBi ZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVy IElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsCiBhbmQgc3RyaXZlIHRv IHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0 LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ RG9jdW1lbnQ6Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnJldmlldyBvZiBkcmFmdC1pZXRmLXNwcmlu Zy1zZWdtZW50LXJvdXRpbmctbXBscy0xODwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPjxicj4KUmV2aWV3ZXI6IEFsZXhhbmRlciAo4oCcU2FzaGHigJ0pIFZhaW5zaHRlaW48YnI+ ClJldmlldyBEYXRlOiAxMC1NYXItMTk8YnI+CklFVEYgTEMgRW5kIERhdGU6IDA3LU1hci0yMDE5 PGJyPgpJbnRlbmRlZCBTdGF0dXM6IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVw dDtjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUiPlByb3Bvc2VkIFN0YW5kYXJkPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPgo8cD48 c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+U3VtbWFyeTo8L3NwYW4+PC9zdHJv bmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4gSSBoYXZlIHNvbWUgbWlub3IgY29uY2Vy bnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxkIGJlCiByZXNvbHZlZCBi ZWZvcmUgcHVibGljYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPgo8cD48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPkNvbW1lbnRzPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPjoKPG86cD48L286cD48L3NwYW4+PC9wPgo8cD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPkkgaGF2ZSBkb25lIGFuIGVhcmx5IFJURy1ESVIgcmV2aWV3IG9mIHRoZSAtMTQg dmVyc2lvbiBvZiB0aGUgZHJhZnQgaGFsZiBhIHllYXIgYWdvLCBhbmQgdGhlIGlzc3VlcyBJ4oCZ dmUgcmFpc2VkIHRoZW4gaGF2ZSBiZWVuIHJlc29sdmVkIGluIHRoZSBzdWJzZXF1ZW50IHZlcnNp b25zIG9uZSB3YXkgb3IgYW5vdGhlcikuCiBUaGVyZWZvcmUgdGhpcyByZXZpZXcgaGFzIGJlZW4g aW50ZW50aW9uYWxseSBmb2N1c2VkIG9uIHRoZSBjaGFuZ2VzIGRvbmUgdG8gdGhlIGRyYWZ0IGlu IHRoZSBmZXcgcmVjZW50IHZlcnNpb25zLgo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SW4gbXkgcHJldmlvdXMgcmV2aWV3IEkgaGF2ZSBub3Rp Y2VkIHRoYXQgdGhlIGRyYWZ0IHdhcyBub3QgZWFzeSByZWFkaW5nIGZvciBtZS4gU2luY2UgdGhl biByZWFkYWJpbGl0eSBvZiB0aGUgZHJhZnQgaGFzIGJlZW4gaW1wcm92ZWQuIEhvd2V2ZXIsIHRo ZXJlIGFyZSBzdGlsbCBzZXZlcmFsIHBsYWNlcyBpbgogdGhlIG5ldyB0ZXh0IHRoYXQgYXJlIHN0 aWxsIGRpZmZpY3VsdCB0byBwYXJzZS4gPG86cD48L286cD48L3NwYW4+PC9wPgo8cD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPkkgZGlkIG5vdCBydW4gdGhlIG5pdHMgY2hlY2tlciBvbiB0 aGUgZHJhZnQsIHNvIG15IGxpc3Qgb2Ygbml0cyBpcyBwcm9iYWJseSBpbmNvbXBsZXRlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5KdXN0IGFz IHdpdGggbXkgZWFybGllciByZXZpZXcsIEkgc2VuZCB0aGlzIG9uZSBhbHNvIHRvIHRoZSBNUExT IFdHIGxpc3Qg4oCTIGFuZCBmb3IgdGhlIHNhbWUgcmVhc29ucy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+CjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSB0cmllZCB0byBkaXNjdXNzIG15 IHJldmlldyBwcml2YXRlbHkgd2l0aCB0aGUgYXV0aG9ycywgYnV0IHRoZXkgZGlkIG5vdCByZXNw b25kLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHA+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5NYWpvciBJc3N1ZXM8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ OiBObyBtYWpvciBpc3N1ZXMgZm91bmQuPG86cD48L286cD48L3NwYW4+PC9wPgo8cD48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk1pbm9yIElzc3Vlczwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj46CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MzkuNzVwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVs MSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoZSB0ZXh0IGluIFNlY3Rp b24gMSBzdGF0ZXMgdGhhdDwvc3Bhbj4g4oCcPGI+YSBuZXR3b3JrIG9wZXJhdG9yIFNIT1VMRCBj b25maWd1cmUgYXQgbGVhc3Qgb25lIG5vZGUgc2VnbWVudCBwZXIgcm91dGluZyBpbnN0YW5jZSwg dG9wb2xvZ3ksIGFsZ29yaXRobTwvYj7igJ0gPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+YW5kIGNvbnRpbnVlcyB0aGF0 PC9zcGFuPiDigJw8Yj5BbiBpbXBsZW1lbnRhdGlvbiBNQVkgY2hlY2sgdGhhdCBhbiBJR1Agbm9k ZS1TSUQgaXMgbm90IGFzc29jaWF0ZWQgd2l0aCBhIHByZWZpeCB0aGF0IGlzIG93bmVkIGJ5IG1v cmUgdGhhbiBvbmUgcm91dGVyIHdpdGhpbiB0aGUgc2FtZSByb3V0aW5nIGRvbWFpbiwgSWYgc28s IGl0IFNIT1VMRCBOT1QgdXNlIHRoaXMgTm9kZS1TSUQsIE1BWSB1c2UgYW5vdGhlciBvbmUgaWYg YXZhaWxhYmxlLCBhbmQgU0hPVUxEIGxvZyBhbiBlcnJvcjwvYj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj7igJ0uIFRo aXMgbG9va3Mgc29tZXdoYXQgY29udHJvdmVyc2lhbCB0byBtZSBiZWNhdXNlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPgo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3NS43NXB0O3RleHQtaW5kZW50 Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmEuPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsg PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+VGhlIGNoZWNrIG9mIHRoZSBOb2RlIFNJRCBub3QgYmVpbmcgb3duZWQgYnkgbW9y ZSB0aGFuIG9uZSByb3V0ZXIgaW4gdGhlIHJvdXRpbmcgZG9tYWluIGlzIGRlZmluZWQgYXMgcHVy ZWx5IG9wdGlvbmFsLiBBY2NvcmRpbmcgdG8gUkZDIDIxMTksIGltcGxlbWVudGF0aW9ucyB0aGF0 IGNob29zZSB0byBpbXBsZW1lbnQgc3VjaCBhIGNoZWNrIG11c3QgYmUgYWJsZSB0byBpbnRlcm9w ZXJhdGUgd2l0aCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkbyBub3QgaW1wbGVtZW50IGl0IDxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPgo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3NS43NXB0O3RleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmIuPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+VGhlIHJlY29tbWVuZGVkIGhhbmRsaW5nIG9mIHRoZSByZXN1bHRzIG9m IHRoaXMgY2hlY2sgKGZ1bGx5IGFsaWduZWQgd2l0aCB0aGUgdGV4dCBpbiBTZWN0aW9uIDMuMiBw ZiBSRkMgODQwMiB0aGF0IHByb2hpYml0cyB1c2luZyBwcmVmaXhlcyBvd25lZCBieSBtb3JlIHRo YW4gb25lIHJvdXRlciBpbiB0aGUgZG9tYWluIGFzIE5vZGUtU09Ecykgc3Ryb25nbHkgc3VnZ2Vz dHMgdGhhdCB0aGUgcHJlZml4IHRoYXQgaXMgb3duZWQgYnkgbW9yZSB0aGFuIG9uZSByb3V0ZXIg aW4gdGhlIGRvbWFpbiBpcyB1bnVzYWJsZSBhcyB0aGUgTm9kZSBTSUQgJm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wcmU+CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM5Ljc1cHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPkkgc2VlIHR3byBwb3NzaWJpbGl0aWVzIHRvIHJlc29sdmUgdGhpcyBjb250cm92ZXJzeTog ZWl0aGVyIG1ha2UgdGhlIGNoZWNrIGluIHF1ZXN0aW9uIGEg4oCccmVhbCByZXF1aXJlbWVudOKA nSAoaS5lLiwgcmVwbGFjZSA8L3NwYW4+PGI+TUFZPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiB3aXRoIDwvc3Bh bj48Yj5TSE9VTEQ8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+IG9yIGV2ZW4gPC9zcGFuPjxiPk1VU1Q8L2I+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+KSwgb3IgZXhwbGFpbiB3aHkgaXQgaXMgc2FmZSBlbm91Z2ggbm90IHRvIGltcGxl bWVudCBzdWNoIGEgY2hlY2sgKGkuZS4sIGhvdyBpbXBsZW1lbnRhdGlvbnMgdGhhdCBzdXBwb3J0 IHRoaXMgY2hlY2sgYW5kIGltcGxlbWVudGF0aW9ucyB0aGF0IGRvIG5vdCBzdXBwb3J0IGl0IGNh biBpbnRlcm9wZXJhdGUgd2l0aGluIGEgZ2l2ZW4gcm91dGluZyBkb21haW4pPC9zcGFuPi4gPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+VGhlIGZpcnN0IG9mIHRoZXNlIG9wdGlvbnMgc2VlbXMgdG8gbWUgYWxpZ25lZCB3 aXRoIFNlY3Rpb24gMy4yIGluIFJGQyA4NDAyIHRoYXQgc2F5cyB0aGF0IOKAnDwvc3Bhbj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QW4gSUdQIE5vZGUtU0lEIE1VU1QgTk9UIGJl IGFzc29jaWF0ZWQgd2l0aCBhIHByZWZpeCB0aGF0IGlzIG93bmVkIGJ5IG1vcmUgdGhhbiBvbmUg cm91dGVyIHdpdGhpbiB0aGUgc2FtZSByb3V0aW5nIGRvbWFpbjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+4oCdLiA8L3NwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wcmU+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzkuNzVwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4K PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBkaXI9IkxUUiI+PC9zcGFuPkkgaGF2ZSZuYnNwOyBhIHByb2JsZW0gd2l0aCB0aGUgPHNwYW4g c3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij4KaGlnaGxpZ2h0 ZWQ8L3NwYW4+IHBhcnQgb2YgdGhlIGZvbGxvd2luZyB0ZXh0IGluIFNlY3Rpb24gMi41OjxvOnA+ PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48Yj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkFuIGltcGxlbWVudGF0aW9u IE1VU1QgTk9UIGFsbG93IHRoZSBNQ0NzIGJlbG9uZ2luZyB0byB0aGUgc2FtZTxvOnA+PC9vOnA+ PC9zcGFuPjwvYj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDox OC4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IHJvdXRlciB0byBhc3NpZ24gdGhlIHNhbWUgaW5jb21pbmcgbGFiZWwg dG8gbW9yZSB0aGFuIG9uZSBTUiBGRUMuCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdztt c28taGlnaGxpZ2h0OnllbGxvdyI+QW48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9iPjwvcD4K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2JhY2tncm91bmQ6eWVs bG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij4mbmJzcDsmbmJzcDsgaW1wbGVtZW50YXRpb24gdGhh dCBhbGxvd3Mgc3VjaCBiZWhhdmlvciBpcyBjb25zaWRlcmVkIGFzIGZhdWx0eS48L3NwYW4+PC9i PjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86 cD48L286cD48L3NwYW4+PC9iPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjE4LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsKPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21z by1oaWdobGlnaHQ6eWVsbG93Ij5Qcm9jZWR1cmVzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBl cXVhbGx5IGFwcGxpZXMgdG8gdGhpcyBjYXNlLDxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L2I+ PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij48Yj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7YmFja2dyb3Vu ZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPiZuYnNwOyZuYnNwOyBib3RoIGZvciBpbmNv bWluZyBsYWJlbCBjb2xsaXNpb24gKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscy0xOCNzZWN0aW9uLTIuNSI+ PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPlNlY3Rp b24KIDIuNTwvc3Bhbj48L2E+KSBhbmQgdGhlIGVmZmVjdCBvbjxvOnA+PC9vOnA+PC9zcGFuPjwv Yj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPjxi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OztiYWNrZ3Jv dW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+Jm5ic3A7Jm5ic3A7IG91dGdvaW5nIGxh YmVsIHByb2dyYW1taW5nICg8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMtMTgjc2VjdGlvbi0yLjYiPjxzcGFu IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5TZWN0aW9uCiAy LjY8L3NwYW4+PC9hPikuPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+CjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0Ojc1Ljc1cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBs ZXZlbDIgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+YS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGUgU2VjdGlvbiBp biBxdWVzdGlvbiBkZWFscyB3aXRoIGluY29taW5nIGxhYmVsIGNvbGxpc2lvbiAoaW4gZmFjdCwg dGhlIHRleHQgdGhhdCBpbW1lZGlhdGVseSBmb2xsb3dzIHRoZSBwcm9ibGVtYXRpYyBmcmFnbWVu dCBzdGF0ZXMgdGhhdCDigJw8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PlRoZSBvYmplY3RpdmUgb2YgdGhlIGZvbGxvd2luZyBzdGVwcyBpcyB0byBkZXRlcm1pbmlzdGlj YWxseSBpbnN0YWxsIGluIHRoZSBNUExTIEluY29taW5nIExhYmVsIE1hcCwgYWxzbyBrbm93biBh cyBsYWJlbCBGSUIsIGEgc2luZ2xlIEZFQyB3aXRoIHRoZSBpbmNvbWluZyBsYWJlbCAmcXVvdDtM MSZxdW90Ozwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+4oCdIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pgo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3NS43NXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDAgbGV2ZWwyIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+QXMg YSBjb25zZXF1ZW5jZSwgYW55IG1lbnRpb24gb2YmbmJzcDsgPC9zcGFuPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5vdXRnb2luZyBsYWJlbCBwcm9ncmFtbWluZzwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+LCBsb29rcyBvdXQgb2YgY29udGV4dCAoZXZlbiBhY2NvbXBhbmllZCBieSBh IGZvcndhcmQgcmVmZXJlbmNlIHRvIFNlY3Rpb24gMi42KTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pgo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3NS43NXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDAgbGV2ZWwyIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+U2Vj dGlvbiAyLjYgY292ZXJzIHRoZSBpbXBhY3Qgb2YgaW5jb21pbmcgbGFiZWwgY29sbGlzaW9uIG9u IHByb2dyYW1taW5nIG9mIG91dGdvaW5nIGxhYmVscyBpbiBxdWl0ZSBhIGdlbmVyaWMgd2F5LiBU aGVyZWZvcmUgSSB0aGluayB0aGF0IHRoZSAmbmJzcDs8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5 ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPmhpZ2hsaWdodGVkPC9zcGFuPiBwYXJ0IG9mIHRo ZSBxdW90ZWQgZnJhZ21lbnQgY2FuIGJlIHNhZmVseSByZW1vdmVkIChjb21wbGV0ZSB3aXRoIHRo ZSBncmFtbWFyIG1pc3Rha2UpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPgo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDo3NS43NXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwy IGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPmQuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSBhbHNvIGRvIG5vdCBzZWUg YW55IHZhbHVlIGluIHN0YXRpbmcgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbnMgdGhhdCB2aW9sYXRl cyBhIG1hbmRhdG9yeSByZXF1aXJlbWVudCBvZiB0aGUgc3BlYyBpcyBmYXVsdHkg4oCTIGlzbuKA mXQgdGhhdCBzZWxmLWV2aWRlbnQ/PG86cD48L286cD48L3NwYW4+PC9wcmU+CjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM5Ljc1cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZl bDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGUgPHNwYW4gc3R5bGU9 ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij5oaWdobGlnaHRlZDwvc3Bh bj4gdGV4dCBpbiBTZWN0aW9uIDIuOCBpcyBub3QgYWNjdXJhdGU6PG86cD48L286cD48L3NwYW4+ PC9wcmU+CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjIxLjc1cHQiPjxiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEZvciBMb2NhbCBTSURzLCB0aGUgTUNDIGlzIHJlc3Bv bnNpYmxlIGZvciBkb3dubG9hZGluZyB0aGUgY29ycmVjdDxvOnA+PC9vOnA+PC9zcGFuPjwvYj48 L3ByZT4KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEuNzVwdCI+PGI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbGFiZWwgdmFsdWUgdG8gRklCLiBGb3IgZXhhbXBsZSwg YW4gSUdQIHdpdGggU1IgZXh0ZW5zaW9ucyBbSS1ELmlldGYtPG86cD48L286cD48L3NwYW4+PC9i PjwvcHJlPgo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoyMS43NXB0Ij48Yj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBpc2lzLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25z LCBJLUQuaWV0Zi1vc3BmLXNlZ21lbnQtcm91dGluZy08bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9w cmU+CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjIxLjc1cHQiPjxiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7IGV4dGVuc2lvbnNdIDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5k OnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+YWxsb2NhdGVzPC9zcGFuPiBhbmQgZG93bmxv YWRzIHRoZSBNUExTIGxhYmVsIGNvcnJlc3BvbmRpbmcgdG88bzpwPjwvbzpwPjwvc3Bhbj48L2I+ PC9wcmU+CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjIxLjc1cHQiPjxiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFuIEFkai1TSUQgWzxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM4NDAyIiB0aXRsZT0iJnF1b3Q7U2VnbWVudCBSb3V0aW5nIEFy Y2hpdGVjdHVyZSZxdW90OyI+UkZDODQwMjwvYT5dLjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3By ZT4KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzUuNzVwdDt0ZXh0LWluZGVudDotMTguMHB0O21z by1saXN0OmwwIGxldmVsMiBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48Yj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmEuPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsgPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PC9iPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPklHUCB3aXRoIFNSIGV4dGVuc2lvbnM8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4gPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5tYXkgaW5kZWVkIGR5bmFtaWNhbGx5IGFs bG9jYXRlIGFuZCBkb3dubG9hZCBNUExTIGxhYmVscyBhY3RpbmcgYXMgbG9jYWwgQWRqLVNJRHMg PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9i PjwvcHJlPgo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3NS43NXB0O3RleHQtaW5kZW50Oi0xOC4w cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Yi48c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyA8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48L2I+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+SG93ZXZlciwgdGhlc2UgbGFiZWxzIGNhbiBiZSBhbGxvY2F0ZWQgYnkgY29u ZmlndXJhdGlvbiAoZS5nLiBhcyBtZW50aW9uZWQgaW4gdGhlIHRpZS1icmVha2luZyBydWxlcyBp biBTZWN0aW9uIDIuNS4xIGFuZCBpbiB0aGUgZXhhbXBsZSBpbiBTZWN0aW9uIEEuMi4zIGluIHRo ZSBkcmFmdCksIGluIHdoaWNoIGNhc2UgSUdQIHdpdGggU1IgZXh0ZW5zaW9ucyB3b3VsZCBvbmx5 IHJlc3BvbnNpYmxlIGZvciBpdHMgYWR2ZXJ0aXNlbWVudCBhbmQgaW5zdGFsbGF0aW9uLiA8L3Nw YW4+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9w cmU+CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+CjxwcmU+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+TklUUzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+OjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPgo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiA6PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9iPjwvcHJlPgo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozOS43NXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzQi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIGRpcj0iTFRSIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SW4gc2VjdGlvbiAyLjU6PG86cD48L286 cD48L3NwYW4+PC9wcmU+CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVu dDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMiBsZm80Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5hLjxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPkluIHRoZSBzZW50ZW5jZSDigJw8L3NwYW4+PGI+UHJvY2VkdXJlcyBkZWZpbmVk IGluIHRoaXMgZG9jdW1lbnQgZXF1YWxseSBhcHBsaWVzIHRvIHRoaXMgY2FzZTwvYj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj7igJ0gdGhlIG5vdW4gaXMgaW4gcGx1cmFsIGJ1dCB0aGUgdmVyYiBpcyBpbiBzaW5ndWxh ci4gKElmIHRoaXMgc2VudGVuY2UgaXMgcmVtb3ZlZCBhcyBzdWdnZXN0ZWQgYWJvdmUsIHRoaXMg bml0IGRpc2FwcGVhcnMpPG86cD48L286cD48L3NwYW4+PC9wcmU+CjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMiBsZm80 Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj5iLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoZSBzYW1lIHByb2JsZW0gZXhpc3Rz IGluIHRoZSBzZW50ZW5jZSDigJw8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5B biBpbmNvbWluZyBsYWJlbCBjb2xsaXNpb24gb2NjdXJzIGlmIHRoZSBTSURzIG9mIHRoZSBzZXQg b2YgRkVDcyB7RkVDMSwgRkVDMiwuLi4sIEZFQ2t9IG1hcHMgdG8gdGhlIHNhbWUgaW5jb21pbmcg U1IgTVBMUyBsYWJlbCAmcXVvdDtMMSZxdW90Ozwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+4oCdPG86 cD48L286cD48L3NwYW4+PC9wcmU+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzkuNzVwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVs MSBsZm80Ij4KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPkluIHNlY3Rpb24gMi4xMC4xIHRoZSBwcmVwb3Np dGlvbiDigJw8Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPnRvPC9zcGFuPjwvYj7igJ0gYmV0d2VlbiB0aGUgd29yZHMg4oCcPGI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5hY2NvcmRpbmc8L3NwYW4+PC9i PuKAnSBhbmQg4oCcPGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5NUExTPC9zcGFuPjwvYj7igJ0KIGlzIG1pc3NpbmcgaW4gdGhlIGZyYWdtZW50IOKA nDxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+UHVz aCB0aGUgY2FsY3VsYXRlZCBsYWJlbCBhY2NvcmRpbmcgdGhlIE1QTFMgbGFiZWwgcHVzaGluZyBy dWxlcyBzcGVjaWZpZWQgaW4gW1JGQzMwMzJdPC9zcGFuPjwvYj7igJ0uPG86cD48L286cD48L3A+ CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzkuNzVwdDt0 ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm80Ij4KPCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+ PC9zcGFuPlByb2JsZW1zIHdpdGggcmVmZXJlbmNlczo8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDIgbGZvNCI+CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsKPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj48YSBo cmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9DX1czS0Jj TDJBV3htbEI3U3A1M19QdnFiUUEiPkFzIHJlcG9ydGVkIGJ5IFNlcmdleTwvYT4sIHRoZXJlIGFy ZSB0d28gb2NjdXJyZW5jZXMgb2YgcmVmZXJlbmNlcyB0byBSRkMgODA0MiDigJxPU1BGIFR3by1Q YXJ0IE1ldHJpY+KAnSBpbnN0ZWFkIG9mIFJGQyA4NDAyLiBMb3RzCiBvZiB0aGFua3MgdG8gU2Vy Z2V5IGZvciBjYXRjaGluZyB0aGlzPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDEgbGV2ZWwyIGxmbzQiPgo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj5iLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+UmVmZXJlbmNlIHRvIFJG QyA4MTc0IG1pc3Rha2VubHkgY29udGFpbnMgYSBsaW5rIHRvJm5ic3A7IFJGQyA3Mjc0LjxvOnA+ PC9vOnA+PC9wPgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkhvcGVmdWxseSB0aGVz ZSBub3RlcyB3aWxsIGJlIHVzZWZ1bC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJN c29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNh c2hhPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PZmZpY2U6ICYjNDM7OTcyLTM5MjY2MzAyPG86cD48 L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNlbGw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICYjNDM7OTcyLTU0OTI2NjMwMjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5FbWFpbDombmJzcDsmbmJzcDsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b208bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+CjwvZGl2Pgo8YnIgY2xlYXI9ImJvdGgiPgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+CjxCUj4K VGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFu ZCBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBpcyA8QlI+CkNPTkZJREVOVElBTCBhbmQgd2hp Y2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIDxCUj4KdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5IGUt bWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIDxCUj4KYW5k IGFsbCBjb3BpZXMgdGhlcmVvZi48QlI+Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4KPC9ib2R5Pgo8 L2h0bWw+Cgo= --_000_VI1PR03MB3839B5FA07EADE57084F8E389D4F0VI1PR03MB3839eurp_-- From nobody Sun Mar 10 15:39:39 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A441274A1; Sun, 10 Mar 2019 15:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 D0yG1TNrNCmw; Sun, 10 Mar 2019 15:39:35 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57E3A124408; Sun, 10 Mar 2019 15:39:35 -0700 (PDT) Received: from [192.168.1.20] (unknown [119.94.169.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 1F2EE1801556; Sun, 10 Mar 2019 23:39:31 +0100 (CET) From: Loa Andersson To: "mpls@ietf.org" Cc: "mpls-chairs@ietf.org" , draft-nainar-mpls-rfc8287-len-clarification@ietf.org References: <19124c2d-c53b-5826-e7fa-b16616e7ef01@pi.nu> Message-ID: <599dcabe-72ba-9ab1-47a8-49e4b6ab361a@pi.nu> Date: Mon, 11 Mar 2019 06:39:28 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <19124c2d-c53b-5826-e7fa-b16616e7ef01@pi.nu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [mpls] Closed: working group adoption poll draft-nainar-mpls-rfc8287-len-clarification X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 22:39:38 -0000 Working Group, This wgap is closed, and we have a new wg document. Can the authors please post the first wg version of the document without any other changes but administrative. /Loa On 2019-02-27 16:41, Loa Andersson wrote: > Working Group, > > This is to start a two week poll on adopting > draft-nainar-mpls-rfc8287-len-clarification > as a MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > We have done an IPR poll for this document. All the co-authors and > contributors have responded to the IPR poll that they are unaware of any > IPRs that relates to this draft. > > There are no IPR disclosures against this document. > > There has also been a discussion on adding text at the end of section 4 > that says: > > “The Figures in Sections 4.1, 4.2, and 4.3 replace the corresponding > Figures in RFC 8029  Sections 5.1, 5.2, and 5.3 respectively. The > updated figures contain explicitly defined length.” > > There has also been an agreement to add this after the adoption. > > The working group adoption poll ends March 10, 2019. > > /Loa > > mpls wg co-chair -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Mon Mar 11 08:22:24 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD261311D5 for ; Mon, 11 Mar 2019 08:22:15 -0700 (PDT) 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_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=broadcom.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 5Nscp4noDEBH for ; Mon, 11 Mar 2019 08:22:12 -0700 (PDT) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 8DE761311B8 for ; Mon, 11 Mar 2019 08:22:12 -0700 (PDT) Received: by mail-ua1-x933.google.com with SMTP id e15so1644977uam.3 for ; Mon, 11 Mar 2019 08:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=EI1KeSYjeaqQCROkgTjYlEh4GfYMau5A86crYYs+fOg=; b=XifqEGW0OdrCS2OSWK1qMXHq3VjgBuqeE0Jl8pF8/d60CyRG3AN0KkDSlwXyn8fhM0 tnmgiI3Q1wn7Hso1S9pH7X2hhtjN69FJjYU9xXoCOcD79nND03yxDV/gHccbNKzi9YSV NbFybFnw9gcXx3u3i75Lq3B9OqOjvBJOMVJSo= 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; bh=EI1KeSYjeaqQCROkgTjYlEh4GfYMau5A86crYYs+fOg=; b=uMWn2yusKK2GCW2ilfnef2lh0v5Vlo9nuAAxgsDQc7iBIRPbz2cgrsafAjj0HGMjQl /f7WrhSMVADY76r4h46YjNAMateYUdwIHuwEoB258SFlyDj2kZ3eb0QbBCJTCOCA6A84 hJv79O5dKnM1+7RjzUcAsCifoxVAh6fj1Sycym5FB5Fi9wnj+9P9d/rQSZ6hJuyMRkhN TwT+UayX4SgM4pw9qrAQNtMAAkGf14pec/HbSjpz39wYH9rz9h6fxKCTjldwZoXDIUAc bR5zK0D6CnYRQOEzZrlvi+NxHx2hkU3hkMeCo1M7to2eEyrfweIg/tKf5twbpc8yL3hz cp+Q== X-Gm-Message-State: APjAAAVgujdz80/aRgb7+/53m2TaQK+o8fbaR3DG4HklvOIbYCx9Odz1 Wv4aCBU8FfOPdf9WtHt+ywXTDfo5TPSWlnf0hORw5AFp X-Google-Smtp-Source: APXvYqxrUUV9+DNjv2GI59kgIbHSSIjdBLF1BQ/HXkUjzNRVSdtxbc2/5u/oCz0F5eQa4xum7fBL0f3tH79EXxmTOlM= X-Received: by 2002:ab0:2859:: with SMTP id c25mr1000342uaq.102.1552317731337; Mon, 11 Mar 2019 08:22:11 -0700 (PDT) MIME-Version: 1.0 References: <155231684496.23134.10690700852963235032.idtracker@ietfa.amsl.com> In-Reply-To: <155231684496.23134.10690700852963235032.idtracker@ietfa.amsl.com> From: Jai Kumar Date: Mon, 11 Mar 2019 08:22:00 -0700 Message-ID: To: mpls@ietf.org, draft-kumar-mpls-mint@ietf.org Content-Type: multipart/alternative; boundary="000000000000f4bcc90583d32293" Archived-At: Subject: [mpls] Fwd: New Version Notification for draft-kumar-mpls-mint-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 15:22:19 -0000 --000000000000f4bcc90583d32293 Content-Type: text/plain; charset="UTF-8" Hello WG members, A new draft describing methods for MPLS Inband Network Telemetry aka MINT protocol is posted. It attempts to define ability to insert MINT label in live packet for tracing flow path data. MINT domain consists of MINT node with functions of initiation, transit and, termination. Fragmentation function is defined for flows with larger number of hops in a flow path thus creating a deep MINT stack in the packet for eg in 5G network. Cases of carrier over carrier or tunnel over tunnel is defined as well. MINT protocol header provides nexthdr field to be able to identify the payload or create a chained header for various reasons. Please review and provide your feedback. I will try to schedule a lightening session at IETF104 as well. Regards, -Jai ---------- Forwarded message --------- From: Date: Mon, Mar 11, 2019 at 8:07 AM Subject: New Version Notification for draft-kumar-mpls-mint-00.txt To: Jai Kumar , Yoav Peleg , John Lemon , Kireeti Kompella A new version of I-D, draft-kumar-mpls-mint-00.txt has been successfully submitted by Jai Kumar and posted to the IETF repository. Name: draft-kumar-mpls-mint Revision: 00 Title: MPLS Inband Network Telemetry Document date: 2019-03-11 Group: Individual Submission Pages: 20 URL: https://www.ietf.org/internet-drafts/draft-kumar-mpls-mint-00.txt Status: https://datatracker.ietf.org/doc/draft-kumar-mpls-mint/ Htmlized: https://tools.ietf.org/html/draft-kumar-mpls-mint-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-kumar-mpls-mint Abstract: MPLS Inband Network Telemetry (MINT) records flow specific information from end stations and/or switches across a network. This document describes the method to collect data on a per hop basis across a network and perform localized or end to end analytics operations on the data. This document also describes the use of the Extension Label, value 15, for specifying extended special purpose labels for specifying presence of MINT data. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --000000000000f4bcc90583d32293 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello WG members,

=
A new draft describing methods for MPLS Inband Network Telemetry aka M= INT protocol is posted.
It attempts to define ability to insert M= INT label in live packet for tracing flow path data. MINT domain consists o= f MINT node with functions of initiation, transit and, termination. Fragmen= tation function is defined for flows with larger number of hops in a flow p= ath thus creating a deep MINT stack in the packet for eg in 5G network.
=

Cases of carrier over carrier or tunnel over tunn= el is defined as well.
MINT protocol header provides nexthdr= field to be able to identify the payload or create a chained header for va= rious reasons.

Please review and provide your feed= back. I will try to schedule a lightening session at IETF104 as well.
=

Regards,
-Jai

<= br>
---------- Forwarded message ---------
From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Date: Mon, Mar 11, 2019 at 8:07 AM
Subject: New Version Notif= ication for draft-kumar-mpls-mint-00.txt
To: Jai Kumar <jai.kumar@broadcom.com>, Yoav Peleg <= ;yoav.peleg@broadcom.com>= , John Lemon <john.lemon@broa= dcom.com>, Kireeti Kompella <kireeti@juniper.net>



A new version of I-D, draft-kumar-mpls-mint-00.txt
has been successfully submitted by Jai Kumar and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-kumar-mpls-mint
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MPLS Inband Network Telemetry
Document date:=C2=A0 2019-03-11
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 20
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-kumar-mpls-mint-00.t= xt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://datatracker.ietf.org/doc/draft-kumar-mpls-mint/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tool= s.ietf.org/html/draft-kumar-mpls-mint-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://datatracker.ietf.org/doc/html/draft-kumar-mpls-mint


Abstract:
=C2=A0 =C2=A0MPLS Inband Network Telemetry (MINT) records flow specific
=C2=A0 =C2=A0information from end stations and/or switches across a network= .=C2=A0 This
=C2=A0 =C2=A0document describes the method to collect data on a per hop bas= is
=C2=A0 =C2=A0across a network and perform localized or end to end analytics=
=C2=A0 =C2=A0operations on the data.=C2=A0 This document also describes the= use of the
=C2=A0 =C2=A0Extension Label, value 15, for specifying extended special pur= pose
=C2=A0 =C2=A0labels for specifying presence of MINT data.





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

The IETF Secretariat

--000000000000f4bcc90583d32293-- From nobody Mon Mar 11 10:25:56 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B50511310F2; Mon, 11 Mar 2019 10:25:41 -0700 (PDT) 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.93.0 Auto-Submitted: auto-generated Precedence: bulk Cc: mpls@ietf.org, db3546@att.com, The IESG , mpls-chairs@ietf.org, Loa Andersson , rfc-editor@rfc-editor.org, draft-ietf-mpls-sfc@ietf.org, loa@pi.nu MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <155232514173.23102.3473336775905516938.idtracker@ietfa.amsl.com> Date: Mon, 11 Mar 2019 10:25:41 -0700 Archived-At: Subject: [mpls] Protocol Action: 'An MPLS-Based Forwarding Plane for Service Function Chaining' to Proposed Standard (draft-ietf-mpls-sfc-07.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 17:25:42 -0000 The IESG has approved the following document: - 'An MPLS-Based Forwarding Plane for Service Function Chaining' (draft-ietf-mpls-sfc-07.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching 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-mpls-sfc/ Technical Summary This document describes how Service Function Chaining can be achieved in an MPLS network by means of a logical representation of the NSH in an MPLS label stack. That is, the NSH is not used, but the fields of the NSH are mapped to fields in the MPLS label stack. It does not deprecate or replace the NSH, but acknowledges that there may be a need for an interim deployment of SFC functionality in brownfield networks. Working Group Summary The processing of this document have been very smooth and the support from the working group is strong. Document Quality We do not currently have any definite information on existing implementations, an Implementations poll has been started and the write-up will be updated as soon as we get new information. There has been indications from vendors that they intend to implement this specification. We also have a strong interest from operators to have this implemented. No special types of reviews is necessary. Personnel Who is the Document Shepherd for this document? Loa Andersson Who is the Responsible Area Director? Deborah Brungard From nobody Tue Mar 12 03:14:26 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5C91274D0; Tue, 12 Mar 2019 03:14:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-mpls-sfc-encapsulation@ietf.org, Loa Andersson , mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155238565888.13944.15681509185213529887.idtracker@ietfa.amsl.com> Date: Tue, 12 Mar 2019 03:14:18 -0700 Archived-At: Subject: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-mpls-sfc-encapsulation-03=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 10:14:19 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-mpls-sfc-encapsulation-03: 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-mpls-sfc-encapsulation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Not sure about the document's intended status as informational. The doc does not specify a new protocol but it does give normative instructions on the used of protocols. However, I leave this decision to the responsible AD and WG. From nobody Tue Mar 12 03:53:16 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3631277D7; Tue, 12 Mar 2019 03:53:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-mpls-sr-over-ip@ietf.org, Loa Andersson , mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155238798836.13888.12133834062700877951.idtracker@ietfa.amsl.com> Date: Tue, 12 Mar 2019 03:53:08 -0700 Archived-At: Subject: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?mpls-sr-over-ip-03=3A_=28with_DISCUSS=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 10:53:08 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-mpls-sr-over-ip-03: 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-mpls-sr-over-ip/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- These points should be easy to resolve: 1) Given section 3.1, the following drafts all seems that they should be normative references: ietf-isis-encapsulation-cap, ietf-ospf-encapsulation-cap, ietf-ospf-segment-routing-extensions, ietf-isis-segment-routing-extensions 2) Sec 3.2.3 on IP Header fields should refer to RFC6040 for the ECN field and eventually RFC2983 for DSCP. From nobody Tue Mar 12 06:05:01 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2379130F39; Tue, 12 Mar 2019 06:04:53 -0700 (PDT) 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] 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 kUo6t4FoCdOJ; Tue, 12 Mar 2019 06:04:51 -0700 (PDT) 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 D94A5130F70; Tue, 12 Mar 2019 06:04:45 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id x2CD4h5o009474; Tue, 12 Mar 2019 13:04:43 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 90D8A22050; Tue, 12 Mar 2019 13:04:43 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id 83A952204E; Tue, 12 Mar 2019 13:04:43 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id x2CD4gSn004906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Mar 2019 13:04:42 GMT Reply-To: From: "Adrian Farrel" To: "=?utf-8?Q?'Mirja_K=C3=BChlewind_via_Datatracker?= =?utf-8?Q?'?=" , "'The IESG'" Cc: , "'Loa Andersson'" , , , References: <155238798836.13888.12133834062700877951.idtracker@ietfa.amsl.com> In-Reply-To: <155238798836.13888.12133834062700877951.idtracker@ietfa.amsl.com> Date: Tue, 12 Mar 2019 13:04:40 -0000 Organization: Old Dog Consulting Message-ID: <001601d4d8d4$2808d1c0$781a7540$@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: AQFAhuvuBzGCp3DgpBA+VBQ9KaQwWKcwl0EQ Content-Language: en-gb X-Originating-IP: 87.112.237.8 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-24484.007 X-TM-AS-Result: No--9.378-10.0-31-10 X-imss-scan-details: No--9.378-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24484.007 X-TMASE-Result: 10--9.378300-10.000000 X-TMASE-MatchedRID: QW5G6BKkLTrxIbpQ8BhdbOYAh37ZsBDCC/ExpXrHizwJF2U8dKhm+Xtx Bj0owbAa8JDf06DACvODD2YsveSRAUi2Drj9KXXXA9lly13c/gGMoAOyyQDaY665pTV4nlyUmPY Pzc9U9ykZxkaSIDa7cPWHSLoU43ZYey2hwIiqvBOzI1v7J4hECvqPNYK78GMcC/+dM49Ci+xpV1 CxFK6KOz4ycP3GnebWhUP7LVPwROAYkHOTosTds9xajlW+zwxCFIStk4KoNF0OAHqXajwVGAMRO zuQMTFrU0MXT8sFhvJftuJwrFEhTf306Q4zhC4D3QfwsVk0UbuGrPnef/I+epjAUsJ3ToshKlGS Rg0L+/10o/bsyGLnXPWwl0rq794xug58UuBS7ec= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?mpls-sr-over-ip-03=3A_=28with_DISCUSS=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 13:04:54 -0000 Thanks Mirja, > 1) Given section 3.1, the following drafts all seems that they should = be > normative references: ietf-isis-encapsulation-cap, = ietf-ospf-encapsulation-cap, > ietf-ospf-segment-routing-extensions, = ietf-isis-segment-routing-extensions Well, that wasn't the intention. It is meant to be an example of how the = forwarding entries are constructed. As it says at the top of Section 3... Note that the examples in Section 3.1 and Section 3.2 assume that OSPF or ISIS is enabled: in fact, other mechanisms of discovery and advertisement could be used including other routing protocols (such as BGP) or a central controller. We could be more explicit in section 3.1 so that, for example... OLD o The Segment Routing Global Block (SRGB) is defined in [RFC8402]. Router E is SR-MPLS capable, so it advertises an SRGB as described in [I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-isis-segment-routing-extensions]. NEW o The Segment Routing Global Block (SRGB) is defined in [RFC8402]. Router E is SR-MPLS capable, so it advertises an SRGB to the other SR-MPLS capable routers. If an IGP is in use then Router E = behaves as described in [I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-isis-segment-routing-extensions], but other mechanisms Could be applied. END We'd need to make similar changes throughout the section. Would such changes be enough for you? > 2) Sec 3.2.3 on IP Header fields should refer to RFC6040 for the ECN > field and eventually RFC2983 for DSCP. That's good. Thanks. It gives us... When encapsulating an = MPLS packet in UDP, the resulting packet is further = encapsulated in IP for transmission. IPv4 or IPv6 may be used according to = the capabilities of the network. The address fields are set as described in . The other IP = header fields (such as the ECN field , = the DSCP=20 code point , or IPv6 Flow Label) = on each UDP-encapsulated segment SHOULD be configurable according = to the operator's policy: they may be copied from the header = of the incoming packet; they may be promoted from the header of = the payload packet; they may be set according to instructions programmed to be associated with the SID; or they may be configured dependent on the outgoing interface and = payload. Best, Adrian From nobody Tue Mar 12 09:00:43 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 934E1131296; Tue, 12 Mar 2019 09:00:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org, mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155240641959.16274.10292530156982066442.idtracker@ietfa.amsl.com> Date: Tue, 12 Mar 2019 09:00:19 -0700 Archived-At: Subject: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-mpls-lsp-ping-lag-multipath-06=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 16:00:25 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-mpls-lsp-ping-lag-multipath-06: 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-mpls-lsp-ping-lag-multipath/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I wanted to comment on the same sentence/normative requirement as Alvaro did in his point (2). Given Alvaro's additional information that there is actually even a technical conflict with this requirement, I think this should be address before publication and might even be discuss-worthy. However, I'm really not an expert on MPLS and therefore leave the decision to state a discuss ballot position to potentially other, more knowledgable ADs. Thanks for addressing the TSV-ART review comments (and thanks Jörg for the review)! I support adding another sentence with a pointer to rate-limit requirements in other docs. Thanks for proposing this change. Looking forward this see this in the doc! From nobody Tue Mar 12 11:32:44 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D81B13129C; Tue, 12 Mar 2019 11:32:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins via Datatracker To: "The IESG" Cc: draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org, mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155241555050.20197.4534988324449089109.idtracker@ietfa.amsl.com> Date: Tue, 12 Mar 2019 11:32:30 -0700 Archived-At: Subject: [mpls] Spencer Dawkins' No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 18:32:35 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-mpls-lsp-ping-lag-multipath-06: 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-mpls-lsp-ping-lag-multipath/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the responses to Jorg's TSV-ART review. I did see one point in his review, that I'm not seeing a response or document change for. He said, 1. With the potentially substantial stacking of TLVs, I am wondering how large packets can get, especially if numerous links might constitute a LAG and all of those are extensively described. It may be useful to provide the reader with some intuition. There are many useful examples in the document, but they all refer to individual fields. A complete packet could be helpful. My question is actually a follow-on - in a world where we even tunnel tunnels, are there going to be MTU size issues that might be mentioned? From nobody Tue Mar 12 12:42:16 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3151312FA; Tue, 12 Mar 2019 12:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_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 5FZr6KjFexCS; Tue, 12 Mar 2019 12:42:13 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAF1B131159; Tue, 12 Mar 2019 12:42:12 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id v3so979947ljk.9; Tue, 12 Mar 2019 12:42:12 -0700 (PDT) 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=3fN8g/81tBJGPSpxERRfmvpSku9ZGusLi1sfgm8qFiE=; b=K7ZP6uPXUys9wUjkUPUqQTi6WyVD1092kkwdjd+Kd8iXIpn7OmXoGXMu7TK5201gx1 ZKl9vXcnMNcEhbc6OHffOg29TMgtsywQ4SCPSnjPweGjSuz8RICfbTm8daDL+jNMkaD+ 1F3d78kitHeDBpv+1NDxbQKUcfJymZOXEiRQSnXPuYj+kP690H9oIzm+xcb0rZglSmki mmPcsd109InImMH7/Ny9Ye1/NE3ptcUSxB9eHNj2LyZdT8WImUAx3MR/iTSf7bz1yi8c raWwW8u6ucDLazA2JP29mDeHtZwhn3kwTV60biEjp0mbxDvkCrODMunY5t8JLA6EDGs1 /qhQ== 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=3fN8g/81tBJGPSpxERRfmvpSku9ZGusLi1sfgm8qFiE=; b=r19Hsgv5KxrHeUCF+Zkse6rysqFAampLsIPTgq3OLNPiKii+a7R5O65tIDXDbZp3Mn oHRjJlkJctyrLSGQ86NTVxNltvAnnOCAgtPIX3ZEiokXVQJdENwz0xuPLG91BS+ecEQJ nm6qIJ1Ml/1ixYEm3W9faxN/+vX+lEtgY+zj8dEyQy4bPFyJ/7IGC53glXcOyS6JcSiJ AdoPgV1aQmRIA65mJOWSEavWHSXETkX77+rC8h2oZNEyyGWyTb3Rwl2XAQQGP7smprM/ uUC7VfnhprdUJ9u6lefaHxVr5IV0ov5PD4ur5hPnKuqqh1NClx/ZjIXRGIU6XAjIF60S B1Fw== X-Gm-Message-State: APjAAAVMmokEfe9AhYcOOBg/tMLoqTyLR0ZVOI5YXaPeDoeYrWPSZmPE snxdQn49UnENj/XFFzcoEGmzrcODTYZ+mfzmy7o= X-Google-Smtp-Source: APXvYqwd2b8jNEtraAjk+L//7JAcg+cKM5YbsYYdFnl4jdTOHpfKzqyutqP5xQnMIYOlSSkNYkFgocIZ9ma+hGxnaZk= X-Received: by 2002:a2e:9204:: with SMTP id k4mr16428959ljg.0.1552419730781; Tue, 12 Mar 2019 12:42:10 -0700 (PDT) MIME-Version: 1.0 References: <155182102765.27824.6348634481043936612@ietfa.amsl.com> <020a01d4d39b$4e92c460$ebb84d20$@olddog.co.uk> In-Reply-To: <020a01d4d39b$4e92c460$ebb84d20$@olddog.co.uk> From: Spencer Dawkins at IETF Date: Tue, 12 Mar 2019 14:41:57 -0500 Message-ID: To: Adrian Farrel Cc: Datatracker on behalf of Martin Stiemerling , tsv-art@ietf.org, mpls@ietf.org, IETF list , draft-ietf-mpls-sr-over-ip.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000987bce0583eae2bd" Archived-At: Subject: Re: [mpls] [Tsv-art] Tsvart last call review of draft-ietf-mpls-sr-over-ip-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 19:42:15 -0000 --000000000000987bce0583eae2bd Content-Type: text/plain; charset="UTF-8" Hi, Adrian, On Tue, Mar 5, 2019 at 3:35 PM Adrian Farrel wrote: > Hi Martin, > > Good to hear from you. > > > I have only one request: From a Transport Area perspective, > > it would be good to emphasize RFC 7510 and its details about > > MPLS over UDP. > > Happy to accommodate this request. > > But what do you have in mind? > > There are references to 7510, in the Introduction and in the first two use > cases in Section 2. > Then, the packet forwarding procedures in Section 3.2 begin with a > reference to 7510 as well. > And there a couple more references in the document. > > Thanks, > Adrian > I haven't seen a response back from Martin, and this doc is on the agenda in a couple of days, so I'll try to read Martin's mind, and you can both tell me what I'm getting wrong. So can everyone else, of course ... The character string "7510" does appear in a bunch of places in this draft, but what I'm not seeing is a statement of whether the congestion control considerations in Section 5 of RFC 7510 do, or do not, apply to MPLS-SR over UDP, as with MPLS over UDP. That might be obvious to MPLS-SR types, and it might be especially obvious to you, because you were author for this draft and responsible AD for RFC 7510 until after it entered the RFC Editor queue, but I wonder if it might be useful to Those Less Skilled In The Art. I'll ballot No Objection/still discussing TSV-ART review with author, and you can reply here, or there, as seems appropriate. Make good choices, of course ;-) Spencer --000000000000987bce0583eae2bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Adrian,=C2=A0
<= br>
On Tue,= Mar 5, 2019 at 3:35 PM Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi Martin,

Good to hear from you.

> I have only one request: From a Transport Area perspective,
> it would be good to emphasize RFC 7510 and its details about
> MPLS over UDP.

Happy to accommodate this request.

But what do you have in mind?

There are references to 7510, in the Introduction and in the first two use = cases in Section 2.
Then, the packet forwarding procedures in Section 3.2 begin with a referenc= e to 7510 as well.
And there a couple more references in the document.

Thanks,
Adrian

I haven't seen a response ba= ck from Martin, and this doc is on the agenda in a couple=C2=A0of days, so = I'll try to read Martin's mind, and you can both tell me what I'= ;m getting wrong. So can everyone else, of course ...

<= div>The character string "7510" does appear in a bunch of places = in this draft, but what I'm not seeing is a statement of whether the co= ngestion control considerations in Section 5 of RFC 7510 do, or do not, app= ly to MPLS-SR over UDP, as with MPLS over UDP. That might be obvious to MPL= S-SR types, and it might be especially obvious to you, because you were aut= hor for this draft and responsible AD for RFC 7510 until after it entered t= he RFC Editor queue, but I wonder if it might be useful to Those Less Skill= ed In The Art.=C2=A0

I'll ballot No Objection/still discussing T= SV-ART review with author, and you can reply here, or there, as seems appro= priate.=C2=A0

Make good choices, of course ;-)

<= div>Spencer
--000000000000987bce0583eae2bd-- From nobody Tue Mar 12 12:45:43 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB291312DD; Tue, 12 Mar 2019 12:45:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins via Datatracker To: "The IESG" Cc: draft-ietf-mpls-sr-over-ip@ietf.org, Loa Andersson , mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155241994083.20086.12751001972696220592.idtracker@ietfa.amsl.com> Date: Tue, 12 Mar 2019 12:45:40 -0700 Archived-At: Subject: [mpls] Spencer Dawkins' No Objection on draft-ietf-mpls-sr-over-ip-03: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 19:45:41 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-mpls-sr-over-ip-03: 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-mpls-sr-over-ip/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm still chatting with Adrian/whoever else about a possible mention of RFC 7510 Section 5 congestion control and its applicability to this draft, as the TSV-ART reviewer seemed to be pointing towards. But I'm sure we'll do the right thing (because if we did the right thing for MPLS over UDP, how could we not do the right thing for MPLS-SR over UDP?) Make good choices. From nobody Tue Mar 12 13:04:25 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103A7130EC5; Tue, 12 Mar 2019 13:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 KkydmLkHzuuz; Tue, 12 Mar 2019 13:04:13 -0700 (PDT) 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 084D3128B14; Tue, 12 Mar 2019 13:04:12 -0700 (PDT) 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 x2CK4Aio019856; Tue, 12 Mar 2019 20:04:10 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 047582204A; Tue, 12 Mar 2019 20:04:10 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id E2CE322044; Tue, 12 Mar 2019 20:04:09 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id x2CK46X1017539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Mar 2019 20:04:08 GMT Reply-To: From: "Adrian Farrel" To: "'Spencer Dawkins at IETF'" Cc: "'Datatracker on behalf of Martin Stiemerling'" , , , "'IETF list'" , References: <155182102765.27824.6348634481043936612@ietfa.amsl.com> <020a01d4d39b$4e92c460$ebb84d20$@olddog.co.uk> In-Reply-To: Date: Tue, 12 Mar 2019 20:04:05 -0000 Organization: Old Dog Consulting Message-ID: <00a901d4d90e$c0375bd0$40a61370$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AA_01D4D90E.C039CCD0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH2Qj+Sv2A2/J/rvZAZjZIPktu+aQIdMieTAy0HY8Wlm0RhUA== Content-Language: en-gb X-Originating-IP: 87.112.237.8 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-24486.002 X-TM-AS-Result: No--27.312-10.0-31-10 X-imss-scan-details: No--27.312-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24486.002 X-TMASE-Result: 10--27.311900-10.000000 X-TMASE-MatchedRID: H0/uSqZo4D7xIbpQ8BhdbOYAh37ZsBDCNU8z+tFJHR39k2xa9AhjgwQy VB/q66fr5NBvEMa3vVUCq6hMZ+k+fgeK3sUEdcSOzFOoeBdH/n0xRS4RlA/AFgmvtxE5nD8S9vz s8AUUikXv7KQvOHjFKBuyZsb18LW9SSQ7jOqms07Kl4yJoI+fG0Crr/LkAQ46knle09V58D1WFs MQfbcNE16FTN8b0aVfeJ4fXQORQoe1TiWqZWCojwArNgt5xpQYTJDl9FKHbrlqv/+QKNcPLlm82 OBgNpuLsVkaYcPQSsZIsgeX/PG9ZUc6H4e1kWXPVoDlQpf4TdWVZfG8cr6tXiHbfQoyuojp8z70 XDTUjsZHpIHZv4zxgUmlX2scVfePArfIDVjQDX7BtFDYGmaWKuq/uWzz2rh3+TdKNkxxkWSoBV9 sc+TYx+I+Ja+Fp+EYrBBSnn/GVMan+dP7GcjVHbqQyAveNtg60zEP/d7xPF1G2qlFbyxbImpHKt kQBynKY+p2L1EQN50NunoWbihTV/4wKFk6gUul2x/FmlC/aoz8Xh935PYSDpIC4CO/S0X+ImSkg xYdxsJ4XRigqDnz6lE8dwK9bOBtlwV2iaAfSWcURSScn+QSXlkMvWAuahr8mI+faDiwdhpheV+c rsE6IQwWxr7XDKH8EA93lsCV7S6v/HAzLdfiFzcnhjA8SIxZh3ITiqqSr12/JuXBqqNGYw== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] [Tsv-art] Tsvart last call review of draft-ietf-mpls-sr-over-ip-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 20:04:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00AA_01D4D90E.C039CCD0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks Spencer. =20 My initial reaction was to be a bit snippy about this, but I=E2=80=99ll = try to behave :-) =20 The intention is that MPLS-SR-over-IP utilises MPLS-over-UDP as = documented in RFC 7510. =20 I think (and hope) that section 5 of RFC 7510 is an integral part of RFC = 7510, and so is automatically part of any further specification that = uses the mechanisms defined in RFC 7510. =20 In my opinion, to would be wrong to single out one section of RFC 7510 = for special mention in this document since to do so might be taken to = apply that other sections are not equally important. =20 Cheers, Adrian =20 From: Spencer Dawkins at IETF =20 Sent: 12 March 2019 19:42 To: Adrian Farrel Cc: Datatracker on behalf of Martin Stiemerling = ; tsv-art@ietf.org; mpls@ietf.org; IETF = list ; draft-ietf-mpls-sr-over-ip.all@ietf.org Subject: Re: [Tsv-art] Tsvart last call review of = draft-ietf-mpls-sr-over-ip-03 =20 Hi, Adrian,=20 =20 On Tue, Mar 5, 2019 at 3:35 PM Adrian Farrel > wrote: Hi Martin, Good to hear from you. > I have only one request: From a Transport Area perspective, > it would be good to emphasize RFC 7510 and its details about > MPLS over UDP. Happy to accommodate this request. But what do you have in mind? There are references to 7510, in the Introduction and in the first two = use cases in Section 2. Then, the packet forwarding procedures in Section 3.2 begin with a = reference to 7510 as well. And there a couple more references in the document. Thanks, Adrian =20 I haven't seen a response back from Martin, and this doc is on the = agenda in a couple of days, so I'll try to read Martin's mind, and you = can both tell me what I'm getting wrong. So can everyone else, of course = ... =20 The character string "7510" does appear in a bunch of places in this = draft, but what I'm not seeing is a statement of whether the congestion = control considerations in Section 5 of RFC 7510 do, or do not, apply to = MPLS-SR over UDP, as with MPLS over UDP. That might be obvious to = MPLS-SR types, and it might be especially obvious to you, because you = were author for this draft and responsible AD for RFC 7510 until after = it entered the RFC Editor queue, but I wonder if it might be useful to = Those Less Skilled In The Art.=20 I'll ballot No Objection/still discussing TSV-ART review with author, = and you can reply here, or there, as seems appropriate.=20 Make good choices, of course ;-) =20 Spencer ------=_NextPart_000_00AA_01D4D90E.C039CCD0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Thanks = Spencer.

 

My initial = reaction was to be a bit snippy about this, but I=E2=80=99ll try to = behave :-)

 

The = intention is that MPLS-SR-over-IP utilises MPLS-over-UDP as documented = in RFC 7510.

 

I think = (and hope) that section 5 of RFC 7510 is an integral part of RFC 7510, = and so is automatically part of any further specification that uses the = mechanisms defined in RFC 7510.

 

In my = opinion, to would be wrong to single out one section of RFC 7510 for = special mention in this document since to do so might be taken to apply = that other sections are not equally important.

 

Cheers,

Adrian

 

From: Spencer Dawkins at IETF = <spencerdawkins.ietf@gmail.com>
Sent: 12 March 2019 = 19:42
To: Adrian Farrel = <adrian@olddog.co.uk>
Cc: Datatracker on behalf of = Martin Stiemerling <ietf-secretariat-reply@ietf.org>; = tsv-art@ietf.org; mpls@ietf.org; IETF list <ietf@ietf.org>; = draft-ietf-mpls-sr-over-ip.all@ietf.org
Subject: Re: [Tsv-art] = Tsvart last call review of = draft-ietf-mpls-sr-over-ip-03

 

Hi, Adrian, 

 

On = Tue, Mar 5, 2019 at 3:35 PM Adrian Farrel <adrian@olddog.co.uk> = wrote:

Hi = Martin,

Good to hear from you.

> I have only one = request: From a Transport Area perspective,
> it would be good to = emphasize RFC 7510 and its details about
> MPLS over = UDP.

Happy to accommodate this request.

But what do you = have in mind?

There are references to 7510, in the Introduction = and in the first two use cases in Section 2.
Then, the packet = forwarding procedures in Section 3.2 begin with a reference to 7510 as = well.
And there a couple more references in the = document.

Thanks,
Adrian

 

I = haven't seen a response back from Martin, and this doc is on the agenda = in a couple of days, so I'll try to read Martin's mind, and you can = both tell me what I'm getting wrong. So can everyone else, of course = ...

 

The character string "7510" does appear in a = bunch of places in this draft, but what I'm not seeing is a statement of = whether the congestion control considerations in Section 5 of RFC 7510 = do, or do not, apply to MPLS-SR over UDP, as with MPLS over UDP. That = might be obvious to MPLS-SR types, and it might be especially obvious to = you, because you were author for this draft and responsible AD for RFC = 7510 until after it entered the RFC Editor queue, but I wonder if it = might be useful to Those Less Skilled In The Art. 

I'll = ballot No Objection/still discussing TSV-ART review with author, and you = can reply here, or there, as seems appropriate. 

Make good = choices, of course ;-)

 

Spencer

------=_NextPart_000_00AA_01D4D90E.C039CCD0-- From nobody Tue Mar 12 13:30:38 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02911131304; Tue, 12 Mar 2019 13:30:31 -0700 (PDT) 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-mpls-lsp-ping-lag-multipath@ietf.org, mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155242263093.20169.3838924661112115545.idtracker@ietfa.amsl.com> Date: Tue, 12 Mar 2019 13:30:30 -0700 Archived-At: Subject: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 20:30:36 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-mpls-lsp-ping-lag-multipath-06: 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-mpls-lsp-ping-lag-multipath/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for this document; it's clearly going to provide value, and it gives a pretty well-readable description of how things are expected to work. That said, there's a number of details that need to be worked out before publication... This document has six listed authors; per RFC 7322, documents listing more than five authors are unusual, and six is greater than five. Let's talk about the author count. "optional TLV" seems to be used in MPLS contexts as a technical term for "comprehension-optional", not in the "optional to send" sense; it's the counterpart of "mandatory TLV", and this terminology is even documented in the MPLS TLVs registry. It's my understanding that the LSP Capabilities TLV and the Detailed Interface and Label Stack TLV are intended to be comprehension-required (i.e., "mandatory TLVs"), and thus that we must not use the phrase "optional TLV" in their description. This would be made clear if we listed which range of values we intended to allocate a TLV type from, in the IANA considerations, but that remains unspecified at this time. In a similar vein (the "comprehension-required" behavior), there are a few places (Section 3 (twice), and Section 6; also Section 3 for the LAG Description Indicator flag; see COMMENT) where we state new normative language ("MUST") that is unenforceable, since it would need to apply to MPLS implementations that do not implement this specification. Fortunately, the comprehension-required TLV ranges provide this functionality for us without the need to use normative language. Section 4.2 has some conflicting "MUST"s about the ordering/presence of sub-TLVs in the DDMAP TLV (see COMMENT, and also the "MANDATORY" langauge in Figure 2). If I'm reading Section 5.1.2 correctly, the described procedure is only intended to apply when the "G" flag is present (as well as the "I" flag, the requirement for which is explicitly stated), but this is not explicitly stated. In particular, the text as written says it applies to all responders that "understand the LAG Description Indicator flag" with no mention of runtime check for the presence of that flag. I also worry that Sections 8, 9, and 10 are insufficiently clear about the encoding of the interface index value -- is it an integer in NBO, an opaque bitstring, or something else? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Am I reading this correctly that the "LSR Capability TLV" created here is basically only applicable to properties of MPLS echo request/reply exchanges? If so, then perhaps the moniker "LSR Capability" is overly generic. Section 1.2 o Label switching over some member links of the LAG is successful, but will be failed over other member links of the LAG. nit: there's some verb tense inconsistency here; maybe "but fails over other member links" would help. Section 2 This document defines an optional TLV to discover the capabilities of a responder LSR and extensions for use with the MPLS LSP Ping and nit: is it only the *responder* LSR we care about, or are there potentially intermediaries in play? The solution consists of the MPLS echo request containing a DDMAP TLV and the optional LSR capability TLV to indicate that separate load nit: Is this "optional capability TLV" the same "optional TLV" that we are defining in this document? If so, calling it "the new optional LSR capability" would aid clarity. (Also, we seem to use both the "capability" and "Capability" capitzliations for describing this TLV.) Section 3 Capability TLV in the MPLS echo request message. When the responder LSR receives an MPLS echo request message with the LSR Capability TLV included, if it knows the LSR Capability TLV, then it MUST include the LSR Capability TLV in the MPLS echo reply message with the LSR Capability TLV describing features and extensions supported by the local LSR. Otherwise, an MPLS echo reply MUST be sent back to the initiator LSR with the return code set to "One or more of the TLVs was not understood". [...] This last MUST seems like something that this document cannot mandate (as it attempts to apply to non-implementations of this document); it could only work if it was an existing requirement from the core MPLS spec, in which case lower-case "must" is appropriate (possibly with section reference). o If the responder LSR does not understand the "LAG Description Indicator flag": * Clear both the "Downstream LAG Info Accommodation flag" and the "Upstream LAG Info Accommodation flag". Similarly, if an LSR does not understand a flag, it cannot give special treatment to packets containing that flag. (Why an LSR would not understand a flag defined in the same document that defines the Capabilities TLV is beyond me, but you seem to want to allow for that case.) If the responder does not know the LSR Capability TLV, an MPLS echo reply with the return code set to "One or more of the TLVs was not understood" MUST be sent back to the initiator LSR. This duplicates the content I quoted at the top of this section's comments. Section 4.1 Once the initiator LSR knows the capabilities that a responder supports, then it sends an MPLS echo request carrying a DDMAP with the "LAG Description Indicator flag" (G) set to the responder LSR. nit: I think the key point is not that the initiator knows the capabilities of the peer, but rather that the initiator knows that the peer supports this specific mechanism. Also, is this "a DDMAP TLV"? Section 4.2 Reading this makes it sound like the "LAG Description Indicator flag" is completely orthogonal to regular DDMAP functionality, so that if I set the LAG description indicator flag but do not otherwise request detailed descriptions, only the LAG interfaces are returned. However, the flag in question has to be inside a DDMAP TLV (and we should really say so, perhaps as "[flag] set *in the DDMAP TLV*"!), so it seems like in practice the LAG information can only be obtained in conjunction with full detailed description information. (The specific suggestion here is to note clearly that the flag is se in the DDMAP TLV.) * The responder LSR MUST include a DDMAP TLV when sending the MPLS echo reply. I got confused on my first pass through this section; adding "There is a single DDMAP TLV for the LAG interface, with member links described using sub-TLVs" here would have kept me from veering onto the wrong path. (I thought there was going to be one DDMAP TLV per member link, plus one for the LAG aggregate, with lots of duplication.) Based on the procedures described above, every LAG member link will have a Local Interface Index Sub-TLV and a Multipath Data Sub-TLV entries in the DDMAP TLV. The order of the Sub-TLVs in the DDMAP TLV for a LAG member link MUST be Local Interface Index Sub-TLV immediately followed by Multipath Data Sub-TLV. A LAG member link MAY also have a corresponding Remote Interface Index Sub-TLV. When a Local Interface Index Sub-TLV, a Remote Interface Index-Sub-TLV and a Multipath Data Sub-TLV are placed in the DDMAP TLV to describe a LAG member link, they MUST be placed in the order of Local Interface Index Sub-TLV, Remote Interface Index-Sub-TLV and Multipath Data Sub- TLV. This last MUST contradicts the previous MUST. I suggest some more text to clarify under which conditions each requirement applies. I'd also suggest not using the figure for conveying a (apparent?) mandatory requirement, and instead adding some text at the end: "The block of local interface index, (optional remote interface index) and multipath data sub-TLVs for each member link MUST appear adjacent to each other in order of increasing local interface index." It's confusing to label the multiplath data sub-TLV as "MANDATORY" when the body text says "MUST add an [sic] Multipath data Sub-TLV [...] if the received DDMAP TLV requested multipath information", i.e., it is not always present, based on the contents of the echo request. When none of the received multipath information maps to a particular LAG member link, then the responder LSR MUST still place the Local Interface Index Sub-TLV and the Multipath Data Sub-TLV for that LAG member link in the DDMAP TLV, the value of Multipath Length field of the Multipath Data Sub-TLV is set to zero. nit: the last comma is a comma splice. Section 5.1.2 It seems like this places a slightly stronger burden on the responder than stock 8029 does, in that there is a MUST-level requirement to act on the 'I' flag in combination with the 'G' flag, whereas for the 'I' flag alone 8029 only has a SHOULD-level requirement to respond accordingly. We may want to call this out as a change in behavior. Section 5.1.3 Expectation is that there's a relationship between the interface index of the outgoing LAG member link at TTL=n and the interface index of the incoming LAG member link at TTL=n+1 for all discovered entropies. In other words, set of entropies that load balances to nit: "The expectation" nit: "discovered entropies" is a strange wording given how the entropy label works; is this more like "all entropies examined"? The initiator LSR sends two MPLS echo request messages to traverse the two LAG member links at TTL=n+1: How does the initiator know (which entropy label values?) to get the echo requests to traverse different member links? o Error case: * One MPLS echo request message reaches TTL=n+1 on an LAG member link 1. * The other MPLS echo request message also reaches TTL=n+1 on an LAG member link 1. One or two MPLS echo request messages sent by the initiator LSR cannot reach the immediate downstream LSR, or the two MPLS echo request messages reach at the immediate downstream LSR from the same LAG member link. The description paragraph doesn't seem to match up the scenario described in the sub-bullets, which leaves me confused as to what scenario(s) are intended to be considered as the "error case". Section 6 This document defines a new optional TLV which is referred to as the "LSR Capability TLV. [...] Is this optional to use or comprehension-optional? (We elsewhere rely on comprehension-mandatory behavior, so in the RFC 8029 terminology this seems to be a "mandatory TLV" even if it is not mandatory to use.) included in the MPLS echo reply message. Otherwise, if the responder does not know the LSR Capability TLV, an MPLS echo reply with the return code set to "One or more of the TLVs was not understood" MUST be sent back to the initiator LSR. This duplicates a requirement stated elsewhere (that really ought to just be using existing required behavior from 8029 anyway). LSR Capability TLV Type is TBD1. Length is 4. The value field of In a hypothetical future where we need to allocate a 33rd capability flag, would we rather create a new "extended capabilities" TLV (burning another 32 bits for type+length) or leave flexibility now for 'length' to increase in multiples of 4 with receivers ignoring bits past what they know about? The "LSR Capability Flags" field is 4 octets in length, this document defines the following flags: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Must Be Zero (Reserved) |U|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I'm wary of describing these as "Must Be Zero", since they're just unallocated but not required to be zero other than by the current state of bit allocations. (I guess this is conventional for MPLS, though? So maybe it's not a problem.) Just "Reserved" would be fine. This document defines two flags. The remaining flags MUST be set to zero when sending and ignored on receipt. Both the U and the D flag MUST be cleared in the MPLS echo request message when sending, and ignored on receipt. Neither, either or both the U and the D flag MAY be set in the MPLS echo reply message. Similarly, I think we want to say "unallocated flags" rather than "the remaining flags". It also seems like the semantics being described here are "the TLV value is ignored in the echo request and only has meaning in the response" (i.e., this is a "tell me your capabilities" exchange, not a "here are mine; what are yours?" exchange). As written, that applies only to the U and D bits, and is not a general property. That may well be a fine choice if we think we might want the two-way exchange for some future allocated bit, but if we do think it's a general property of the mechanism, I'd suggest rewording the text. Section 7 (Per IANA, bits 4 and 5 are already assigned but are not reflected in the diagram.) Section 10 The Detailed Interface and Label Stack TLV format is derived from the Interface and Label Stack TLV format (from [RFC8029]). Two changes are introduced. The first is that the label stack is converted into a sub-TLV. The second is that a new sub-TLV is added to describe an interface index. These fields of Detailed Interface and Label Stack TLV have the same use and meaning as in [RFC8029]. A summary of these fields is as below: nit: Are "These fields" just "The other fields"? The Address Type indicates if the interface is numbered or unnumbered. It also determines the length of the IP Address and Interface fields. The resulting total length of the initial part of the TLV is listed as "K Octets". The Address Type is set to one of the following values: nit: is it better to list the currently allocated values or just refer to the IANA registry? I seee that this "index assigned to the interface" language for unnumbered address types originates from RFC 8029, but both this document and 8029 leave me confused as to the encoding used for this index (for either/both IPv4 or IPv6 address types). [My comment about "Must Be Zero" and allocatable bits also applies here] Section 12 This document also adds a capability "negotiation" mechanism for MPLS echo request/reply exchanges. As MPLS does not offer integrity protection for its messages, this negotiation is only as trustworthy as the network from which messages are accepted as valid, and initiators have no recourse but to accept faithfully the echo replies received. To prevent leakage of vital information to untrusted users, a responder LSR MUST only accept MPLS echo request messages from designated trusted sources via filtering source IP address field of received MPLS echo request messages. [...] I'd prefer to see a note added here about how "source IP address filtering provides only a weak form of access control and is not, in general, a reliable security mechanism. Nonetheless, it is required here in the absence of any more robust mechanism that might be used." Section 13 Should we ask IANA to update the "Interface and Label Stack Address Types" registry to also refer to this document, since we are sharing the registry between the Interface and Label Stack TLV and the Detailed version? Section 13.2 The range 4-31743 spans two different allocation procedures (Standards Action and Specification Required - Experimental RFC needed); I assume that we want the 4-16383 range for Standards Action - mandatory TLVs. Section 13.4 We don't say what range we want this to be allocated from -- I assume 4-16383 since this is a negotiated feature and sending it outside the negotiated scenario should be an error. Section 13.4.1 (I note that some existing sub-TLV registries have "Experimental RFC required" for the experimental ranges, but that is arguably more stringent than necessary; Specification Required seems more appropriate for this case.) Appendix A I was kind of hoping for some more guidance on what an initiator could do in these scenarios to try to get better visibility into the switch behavior (and, hopefully, a workaround to get reliable echo responses that cover all LAG member links). AFAICT there's not a better option than "try a bunch of entropy labels and see what responses you can get back" and that's the same remedy in all the described topologies, but it would be nice to have this stated explicitly for the reader. Section A.1 In the worst case, MPLS echo request messages with specific entropies to exercise every LAG members from R1 to S1 can all reach R2 via same LAG member. [...] I'm confused by the phrase "specific entropies to exercise every LAG members [sic] from R1 to S1" -- is there some deterministic algorithm by which a specific entropy label value will force a specific LAG member link? My understanding was that the entropy was used as input to an opaque hash function and that trial-and-error was the only way to explore the mapping from entropy value to LAG member link taken. From nobody Tue Mar 12 13:52:57 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFB01312E1; Tue, 12 Mar 2019 13:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_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 jFTnZ9fJDbNw; Tue, 12 Mar 2019 13:52:42 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 71FD4131304; Tue, 12 Mar 2019 13:52:36 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id h71so3163512lfe.0; Tue, 12 Mar 2019 13:52:36 -0700 (PDT) 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=oawi/ZtARp/bxTadazVMmcIG9VNn1TJX4ErFch4KlYo=; b=paFm1bqHCMOkPfhGJv0r4ES3MaHNEeAsDu7Lbje4f6wh8W4N9FDrjGDMtSi91x7zII iFkSYAdk1oAo47I7gM80CsQ4Qj1rXVlbEt4yqHeN4FxbMAhyA1O0m6U/DoKmzbUfe93V Uah1e+AK6J3TAPe/bx9zIObsUzWsfSkX6s2ujnKW3cd01tIp46frQZ/+mSNJXNhys/hT hAuov7wyKEofs19JUsXMFIUb7JAnjbXogEZDX11fu1VmjlkeEyqGLXJeHN10OQkqVeEp DrOLnwSsr5OJqp/743KdPot/lgRniB2cMGEab5Yk2yHSbpnhz9cAMEPQEN8T96ycfb/t ggRw== 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=oawi/ZtARp/bxTadazVMmcIG9VNn1TJX4ErFch4KlYo=; b=mfJmxuHXAgP454zno/sy6x6n1N33qU+b+M4KU0Jb6+fWZPpSAKGkAA+qppgUHqiUTp pLSWlZuZ6XxJBbLOZmrB/3RqJduulxCQ3Wxx0MY7u2yRSthvzI/Q95GXXq43gTlrpxGf VIY4gmMimhzyMFdqqlxV5TJhOs8nkACJ3hY5BLwUFPHp6KEpUBHvIorPl9v5lMpqDUqo a10Eqgm4fw14mJuwE/dnztaQM9/M8AZ3hK50u24rLfyCeeGVMTMAtAKwYecdI6AJCOFC h2Dj/zNBO/oKkZffVnbriO641pItput+McT6zefAfxPY7fP3WaG+wZmcdSaAl8ALsEnp /ykg== X-Gm-Message-State: APjAAAW2wh7+ekRHod8MBqiJxPHZwCYbk/3EI51xtzc03ELOOdDjCgGa pwoKpCGCakjfUdZ2GjerYjWtS8C3X1yObnbtaFg= X-Google-Smtp-Source: APXvYqxkD+v7WJ8em2KKTKLVJVEayxWOJ+6qWWLe5NJfUbEKkka4P6GOchyX5cG6JPo7+BBTa3ynDo6IdEYMsAsE9/I= X-Received: by 2002:a19:7503:: with SMTP id y3mr7705422lfe.83.1552423953050; Tue, 12 Mar 2019 13:52:33 -0700 (PDT) MIME-Version: 1.0 References: <155182102765.27824.6348634481043936612@ietfa.amsl.com> <020a01d4d39b$4e92c460$ebb84d20$@olddog.co.uk> <00a901d4d90e$c0375bd0$40a61370$@olddog.co.uk> In-Reply-To: <00a901d4d90e$c0375bd0$40a61370$@olddog.co.uk> From: Spencer Dawkins at IETF Date: Tue, 12 Mar 2019 15:52:19 -0500 Message-ID: To: Adrian Farrel Cc: Datatracker on behalf of Martin Stiemerling , tsv-art@ietf.org, mpls@ietf.org, IETF list , draft-ietf-mpls-sr-over-ip.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000434c850583ebde82" Archived-At: Subject: Re: [mpls] [Tsv-art] Tsvart last call review of draft-ietf-mpls-sr-over-ip-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 20:52:44 -0000 --000000000000434c850583ebde82 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Adrian, On Tue, Mar 12, 2019 at 3:04 PM Adrian Farrel wrote: > Thanks Spencer. > > > > My initial reaction was to be a bit snippy about this, but I=E2=80=99ll t= ry to > behave :-) > > > > The intention is that MPLS-SR-over-IP utilises MPLS-over-UDP as documente= d > in RFC 7510. > > > > I think (and hope) that section 5 of RFC 7510 is an integral part of RFC > 7510, and so is automatically part of any further specification that uses > the mechanisms defined in RFC 7510. > > > > In my opinion, to would be wrong to single out one section of RFC 7510 fo= r > special mention in this document since to do so might be taken to apply > that other sections are not equally important. > That's reasonable, and it's very likely that I missed what Martin was thinking. Thanks for the quick response. Spencer, who appreciates behaving since it's his last telechat ;-) > > > Cheers, > > Adrian > > > > *From:* Spencer Dawkins at IETF > *Sent:* 12 March 2019 19:42 > *To:* Adrian Farrel > *Cc:* Datatracker on behalf of Martin Stiemerling < > ietf-secretariat-reply@ietf.org>; tsv-art@ietf.org; mpls@ietf.org; IETF > list ; draft-ietf-mpls-sr-over-ip.all@ietf.org > *Subject:* Re: [Tsv-art] Tsvart last call review of > draft-ietf-mpls-sr-over-ip-03 > > > > Hi, Adrian, > > > > On Tue, Mar 5, 2019 at 3:35 PM Adrian Farrel wrote: > > Hi Martin, > > Good to hear from you. > > > I have only one request: From a Transport Area perspective, > > it would be good to emphasize RFC 7510 and its details about > > MPLS over UDP. > > Happy to accommodate this request. > > But what do you have in mind? > > There are references to 7510, in the Introduction and in the first two us= e > cases in Section 2. > Then, the packet forwarding procedures in Section 3.2 begin with a > reference to 7510 as well. > And there a couple more references in the document. > > Thanks, > Adrian > > > > I haven't seen a response back from Martin, and this doc is on the agenda > in a couple of days, so I'll try to read Martin's mind, and you can both > tell me what I'm getting wrong. So can everyone else, of course ... > > > > The character string "7510" does appear in a bunch of places in this > draft, but what I'm not seeing is a statement of whether the congestion > control considerations in Section 5 of RFC 7510 do, or do not, apply to > MPLS-SR over UDP, as with MPLS over UDP. That might be obvious to MPLS-SR > types, and it might be especially obvious to you, because you were author > for this draft and responsible AD for RFC 7510 until after it entered the > RFC Editor queue, but I wonder if it might be useful to Those Less Skille= d > In The Art. > > I'll ballot No Objection/still discussing TSV-ART review with author, and > you can reply here, or there, as seems appropriate. > > Make good choices, of course ;-) > > > > Spencer > --000000000000434c850583ebde82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Adrian,=C2=A0

On Tue, Mar 12, 2019 at = 3:04 PM Adrian Farrel <adrian@old= dog.co.uk> wrote:

Thanks Spencer.

=C2=A0

My initial reaction was to be a bit snippy about this,= but I=E2=80=99ll try to behave :-)

=C2=A0

T= he intention is that MPLS-SR-over-IP utilises MPLS-over-UDP as documented i= n RFC 7510.

=C2= =A0

I think (and hope) that s= ection 5 of RFC 7510 is an integral part of RFC 7510, and so is automatical= ly part of any further specification that uses the mechanisms defined in RF= C 7510.

=C2=A0<= u>

In my opinion, to would be wr= ong to single out one section of RFC 7510 for special mention in this docum= ent since to do so might be taken to apply that other sections are not equa= lly important.


That&= #39;s reasonable, and it's very likely that I missed what Martin was th= inking. Thanks for the quick response.

Spencer, wh= o appreciates behaving since it's his last telechat ;-)=C2=A0=C2=A0

=C2=A0<= u>

Cheers,<= /p>

Adrian

=C2=A0

<= span lang=3D"EN-US">From: Spencer Dawkins a= t IETF <spencerdawkins.ietf@gmail.com>
Sent: 12 March 2019 19:= 42
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: Datatracker on b= ehalf of Martin Stiemerling <ietf-secretariat-reply@ietf.org>; tsv-art@ietf.org; mpls@ietf.org; IETF list &= lt;ietf@ietf.org>= ; draft-ietf-mpls-sr-over-ip.all@ietf.org
Subject: Re: [Tsv= -art] Tsvart last call review of draft-ietf-mpls-sr-over-ip-03

=C2=A0

<= p class=3D"MsoNormal">Hi, Adrian,=C2=A0

=C2=A0

On Tue,= Mar 5, 2019 at 3:35 PM Adrian Farrel <adrian@olddog.co.uk> wrote:

Hi Martin,

Good= to hear from you.

> I have only one request: From a Transport Ar= ea perspective,
> it would be good to emphasize RFC 7510 and its deta= ils about
> MPLS over UDP.

Happy to accommodate this request.<= br>
But what do you have in mind?

There are references to 7510, i= n the Introduction and in the first two use cases in Section 2.
Then, th= e packet forwarding procedures in Section 3.2 begin with a reference to 751= 0 as well.
And there a couple more references in the document.

Th= anks,
Adrian

<= u>=C2=A0

I haven't seen= a response back from Martin, and this doc is on the agenda in a couple=C2= =A0of days, so I'll try to read Martin's mind, and you can both tel= l me what I'm getting wrong. So can everyone else, of course ...=

=C2=A0

=

The character string "7510" does appe= ar in a bunch of places in this draft, but what I'm not seeing is a sta= tement of whether the congestion control considerations in Section 5 of RFC= 7510 do, or do not, apply to MPLS-SR over UDP, as with MPLS over UDP. That= might be obvious to MPLS-SR types, and it might be especially obvious to y= ou, because you were author for this draft and responsible AD for RFC 7510 = until after it entered the RFC Editor queue, but I wonder if it might be us= eful to Those Less Skilled In The Art.=C2=A0

I'll ballot No Obje= ction/still discussing TSV-ART review with author, and you can reply here, = or there, as seems appropriate.=C2=A0

Make good choices, of course ;= -)

=C2=A0<= /p>

Spencer

<= /div>
--000000000000434c850583ebde82-- From nobody Tue Mar 12 18:59:53 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9E61311E4; Tue, 12 Mar 2019 18:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hM0WQ5SnWL6T; Tue, 12 Mar 2019 18:59:39 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F4131311D1; Tue, 12 Mar 2019 18:59:36 -0700 (PDT) Received: from [192.168.1.20] (unknown [119.94.169.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 071D9180157E; Wed, 13 Mar 2019 02:59:32 +0100 (CET) To: Benjamin Kaduk via Datatracker , The IESG Cc: draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org, mpls-chairs@ietf.org, mpls@ietf.org References: <155242263093.20169.3838924661112115545.idtracker@ietfa.amsl.com> From: Loa Andersson Message-ID: <8b26fc2e-54f4-b805-aa87-a60cee810567@pi.nu> Date: Wed, 13 Mar 2019 09:59:29 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <155242263093.20169.3838924661112115545.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 01:59:52 -0000 Benjamin, The number of authors were discussed and explained in the Shepherds Write-up. All the 6 authors listed on the front-page has made text contributions to the document. /Loa On 2019-03-13 04:30, Benjamin Kaduk via Datatracker wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-mpls-lsp-ping-lag-multipath-06: 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-mpls-lsp-ping-lag-multipath/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for this document; it's clearly going to provide value, and it > gives a pretty well-readable description of how things are expected to > work. That said, there's a number of details that need to be worked out > before publication... > > This document has six listed authors; per RFC 7322, documents listing > more than five authors are unusual, and six is greater than five. Let's > talk about the author count. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Am I reading this correctly that the "LSR Capability TLV" created here > is basically only applicable to properties of MPLS echo request/reply > exchanges? If so, then perhaps the moniker "LSR Capability" is overly > generic. > > Section 1.2 > > o Label switching over some member links of the LAG is successful, > but will be failed over other member links of the LAG. > > nit: there's some verb tense inconsistency here; maybe "but fails over > other member links" would help. > > Section 2 > > This document defines an optional TLV to discover the capabilities of > a responder LSR and extensions for use with the MPLS LSP Ping and > > nit: is it only the *responder* LSR we care about, or are there > potentially intermediaries in play? > > The solution consists of the MPLS echo request containing a DDMAP TLV > and the optional LSR capability TLV to indicate that separate load > > nit: Is this "optional capability TLV" the same "optional TLV" that we are > defining in this document? If so, calling it "the new optional LSR > capability" would aid clarity. (Also, we seem to use both the > "capability" and "Capability" capitzliations for describing this TLV.) > > Section 3 > > Capability TLV in the MPLS echo request message. When the responder > LSR receives an MPLS echo request message with the LSR Capability TLV > included, if it knows the LSR Capability TLV, then it MUST include > the LSR Capability TLV in the MPLS echo reply message with the LSR > Capability TLV describing features and extensions supported by the > local LSR. Otherwise, an MPLS echo reply MUST be sent back to the > initiator LSR with the return code set to "One or more of the TLVs > was not understood". [...] > > This last MUST seems like something that this document cannot mandate > (as it attempts to apply to non-implementations of this document); it > could only work if it was an existing requirement from the core MPLS > spec, in which case lower-case "must" is appropriate (possibly with > section reference). > > o If the responder LSR does not understand the "LAG Description > Indicator flag": > > * Clear both the "Downstream LAG Info Accommodation flag" and the > "Upstream LAG Info Accommodation flag". > > Similarly, if an LSR does not understand a flag, it cannot give special > treatment to packets containing that flag. (Why an LSR would not > understand a flag defined in the same document that defines the > Capabilities TLV is beyond me, but you seem to want to allow for that > case.) > > If the responder does not know the LSR Capability TLV, an MPLS echo > reply with the return code set to "One or more of the TLVs was not > understood" MUST be sent back to the initiator LSR. > > This duplicates the content I quoted at the top of this section's > comments. > > Section 4.1 > > Once the initiator LSR knows the capabilities that a responder > supports, then it sends an MPLS echo request carrying a DDMAP with > the "LAG Description Indicator flag" (G) set to the responder LSR. > > nit: I think the key point is not that the initiator knows the > capabilities of the peer, but rather that the initiator knows that the > peer supports this specific mechanism. > Also, is this "a DDMAP TLV"? > > Section 4.2 > > Reading this makes it sound like the "LAG Description Indicator flag" is > completely orthogonal to regular DDMAP functionality, so that if I set > the LAG description indicator flag but do not otherwise request detailed > descriptions, only the LAG interfaces are returned. However, the flag > in question has to be inside a DDMAP TLV (and we should really say so, > perhaps as "[flag] set *in the DDMAP TLV*"!), so it seems like in practice > the LAG information can only be obtained in conjunction with full > detailed description information. (The specific suggestion here is to > note clearly that the flag is se in the DDMAP TLV.) > > * The responder LSR MUST include a DDMAP TLV when sending the > MPLS echo reply. > > I got confused on my first pass through this section; adding "There is a > single DDMAP TLV for the LAG interface, with member links described > using sub-TLVs" here would have kept me from veering onto the wrong path. > (I thought there was going to be one DDMAP TLV per member link, plus one > for the LAG aggregate, with lots of duplication.) > > Based on the procedures described above, every LAG member link will > have a Local Interface Index Sub-TLV and a Multipath Data Sub-TLV > entries in the DDMAP TLV. The order of the Sub-TLVs in the DDMAP TLV > for a LAG member link MUST be Local Interface Index Sub-TLV > immediately followed by Multipath Data Sub-TLV. A LAG member link > MAY also have a corresponding Remote Interface Index Sub-TLV. When a > Local Interface Index Sub-TLV, a Remote Interface Index-Sub-TLV and a > Multipath Data Sub-TLV are placed in the DDMAP TLV to describe a LAG > member link, they MUST be placed in the order of Local Interface > Index Sub-TLV, Remote Interface Index-Sub-TLV and Multipath Data Sub- > TLV. > > This last MUST contradicts the previous MUST. I suggest some more text > to clarify under which conditions each requirement applies. > > I'd also suggest not using the figure for conveying a (apparent?) mandatory > requirement, and instead adding some text at the end: "The block of local > interface index, (optional remote interface index) and multipath data > sub-TLVs for each member link MUST appear adjacent to each other in > order of increasing local interface index." > > It's confusing to label the multiplath data sub-TLV as "MANDATORY" when > the body text says "MUST add an [sic] Multipath data Sub-TLV [...] if > the received DDMAP TLV requested multipath information", i.e., it is not > always present, based on the contents of the echo request. > > When none of the received multipath information maps to a particular > LAG member link, then the responder LSR MUST still place the Local > Interface Index Sub-TLV and the Multipath Data Sub-TLV for that LAG > member link in the DDMAP TLV, the value of Multipath Length field of > the Multipath Data Sub-TLV is set to zero. > > nit: the last comma is a comma splice. > > Section 5.1.2 > > It seems like this places a slightly stronger burden on the responder > than stock 8029 does, in that there is a MUST-level requirement to act > on the 'I' flag in combination with the 'G' flag, whereas for the 'I' > flag alone 8029 only has a SHOULD-level requirement to respond > accordingly. We may want to call this out as a change in behavior. > > Section 5.1.3 > > Expectation is that there's a relationship between the interface > index of the outgoing LAG member link at TTL=n and the interface > index of the incoming LAG member link at TTL=n+1 for all discovered > entropies. In other words, set of entropies that load balances to > > nit: "The expectation" > nit: "discovered entropies" is a strange wording given how the entropy > label works; is this more like "all entropies examined"? > > > The initiator LSR sends two MPLS echo request messages to traverse > the two LAG member links at TTL=n+1: > > How does the initiator know (which entropy label values?) to get the echo > requests to traverse different member links? > > o Error case: > > * One MPLS echo request message reaches TTL=n+1 on an LAG member > link 1. > > * The other MPLS echo request message also reaches TTL=n+1 on an > LAG member link 1. > > One or two MPLS echo request messages sent by the initiator LSR > cannot reach the immediate downstream LSR, or the two MPLS echo > request messages reach at the immediate downstream LSR from the > same LAG member link. > > The description paragraph doesn't seem to match up the scenario > described in the sub-bullets, which leaves me confused as to what > scenario(s) are intended to be considered as the "error case". > > Section 6 > > This document defines a new optional TLV which is referred to as the > "LSR Capability TLV. [...] > > Is this optional to use or comprehension-optional? (We elsewhere rely > on comprehension-mandatory behavior, so in the RFC 8029 terminology this > seems to be a "mandatory TLV" even if it is not mandatory to use.) > > included in the MPLS echo reply message. Otherwise, if the responder > does not know the LSR Capability TLV, an MPLS echo reply with the > return code set to "One or more of the TLVs was not understood" MUST > be sent back to the initiator LSR. > > This duplicates a requirement stated elsewhere (that really ought to > just be using existing required behavior from 8029 anyway). > > LSR Capability TLV Type is TBD1. Length is 4. The value field of > > In a hypothetical future where we need to allocate a 33rd capability > flag, would we rather create a new "extended capabilities" TLV (burning > another 32 bits for type+length) or leave flexibility now for 'length' > to increase in multiples of 4 with receivers ignoring bits past what > they know about? > > The "LSR Capability Flags" field is 4 octets in length, this > document defines the following flags: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Must Be Zero (Reserved) |U|D| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > I'm wary of describing these as "Must Be Zero", since they're just > unallocated but not required to be zero other than by the current state > of bit allocations. (I guess this is conventional for MPLS, though? So > maybe it's not a problem.) Just "Reserved" would be fine. > > This document defines two flags. The remaining flags MUST be set > to zero when sending and ignored on receipt. Both the U and the D > flag MUST be cleared in the MPLS echo request message when > sending, and ignored on receipt. Neither, either or both the U > and the D flag MAY be set in the MPLS echo reply message. > > Similarly, I think we want to say "unallocated flags" rather than "the > remaining flags". > > It also seems like the semantics being described here are "the TLV value > is ignored in the echo request and only has meaning in the response" > (i.e., this is a "tell me your capabilities" exchange, not a "here are > mine; what are yours?" exchange). As written, that applies only to the > U and D bits, and is not a general property. That may well be a fine > choice if we think we might want the two-way exchange for some future > allocated bit, but if we do think it's a general property of the > mechanism, I'd suggest rewording the text. > > Section 7 > > (Per IANA, bits 4 and 5 are already assigned but are not reflected in the > diagram.) > > Section 10 > > The Detailed Interface and Label Stack TLV format is derived from the > Interface and Label Stack TLV format (from [RFC8029]). Two changes > are introduced. The first is that the label stack is converted into > a sub-TLV. The second is that a new sub-TLV is added to describe an > interface index. These fields of Detailed Interface and Label Stack > TLV have the same use and meaning as in [RFC8029]. A summary of > these fields is as below: > > nit: Are "These fields" just "The other fields"? > > The Address Type indicates if the interface is numbered or > unnumbered. It also determines the length of the IP Address > and Interface fields. The resulting total length of the > initial part of the TLV is listed as "K Octets". The Address > Type is set to one of the following values: > > nit: is it better to list the currently allocated values or just refer > to the IANA registry? > > I seee that this "index assigned to the interface" language for > unnumbered address types originates from RFC 8029, but both this > document and 8029 leave me confused as to the encoding used for this > index (for either/both IPv4 or IPv6 address types). > > [My comment about "Must Be Zero" and allocatable bits also applies here] > > Section 12 > > This document also adds a capability "negotiation" mechanism for MPLS > echo request/reply exchanges. As MPLS does not offer integrity > protection for its messages, this negotiation is only as trustworthy as > the network from which messages are accepted as valid, and initiators > have no recourse but to accept faithfully the echo replies received. > > To prevent leakage of vital information to untrusted users, a > responder LSR MUST only accept MPLS echo request messages from > designated trusted sources via filtering source IP address field of > received MPLS echo request messages. [...] > > I'd prefer to see a note added here about how "source IP address > filtering provides only a weak form of access control and is not, in > general, a reliable security mechanism. Nonetheless, it is required > here in the absence of any more robust mechanism that might be used." > > Section 13 > > Should we ask IANA to update the "Interface and Label Stack Address > Types" registry to also refer to this document, since we are sharing the > registry between the Interface and Label Stack TLV and the Detailed > version? > > Section 13.2 > > The range 4-31743 spans two different allocation procedures (Standards > Action and Specification Required - Experimental RFC needed); I assume > that we want the 4-16383 range for Standards Action - mandatory TLVs. > > Section 13.4 > > We don't say what range we want this to be allocated from -- I assume > 4-16383 since this is a negotiated feature and sending it outside the > negotiated scenario should be an error. > > Section 13.4.1 > > (I note that some existing sub-TLV registries have "Experimental RFC > required" for the experimental ranges, but that is arguably more > stringent than necessary; Specification Required seems more appropriate > for this case.) > > Appendix A > > I was kind of hoping for some more guidance on what an initiator could > do in these scenarios to try to get better visibility into the switch > behavior (and, hopefully, a workaround to get reliable echo responses > that cover all LAG member links). AFAICT there's not a better option > than "try a bunch of entropy labels and see what responses you can get > back" and that's the same remedy in all the described topologies, but it > would be nice to have this stated explicitly for the reader. > > Section A.1 > > In the worst case, MPLS echo request messages with > specific entropies to exercise every LAG members from R1 to S1 can > all reach R2 via same LAG member. [...] > > I'm confused by the phrase "specific entropies to exercise every LAG > members [sic] from R1 to S1" -- is there some deterministic algorithm by > which a specific entropy label value will force a specific LAG member > link? My understanding was that the entropy was used as input to an > opaque hash function and that trial-and-error was the only way to > explore the mapping from entropy value to LAG member link taken. > > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Tue Mar 12 19:14:37 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72191271FF; Tue, 12 Mar 2019 19:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PEXEvOR7o9qE; Tue, 12 Mar 2019 19:14:34 -0700 (PDT) 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 9275B12716C; Tue, 12 Mar 2019 19:14:34 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D1C99EFA41FA5E0A37FF; Wed, 13 Mar 2019 02:14:32 +0000 (GMT) Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 13 Mar 2019 02:14:32 +0000 Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Wed, 13 Mar 2019 02:14:32 +0000 Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Wed, 13 Mar 2019 02:14:32 +0000 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.190]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0415.000; Wed, 13 Mar 2019 10:14:17 +0800 From: Mach Chen To: Alvaro Retana via Datatracker , The IESG CC: "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" , "mpls-chairs@ietf.org" , "loa@pi.nu" , "mpls@ietf.org" Thread-Topic: Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT) Thread-Index: AQHU1fmbThhWFHA7EEKjBTDftquDOKYI0X+w Date: Wed, 13 Mar 2019 02:14:17 +0000 Message-ID: References: <155208210011.3264.12148702952456660789.idtracker@ietfa.amsl.com> In-Reply-To: <155208210011.3264.12148702952456660789.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 02:14:37 -0000 SGkgQWx2YXJvLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMhDQoNClBsZWFzZSBzZWUgbXkg cmVwbGllcyBpbmxpbmUuLi4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBBbHZhcm8gUmV0YW5hIHZpYSBEYXRhdHJhY2tlciBbbWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmdd DQo+IFNlbnQ6IFNhdHVyZGF5LCBNYXJjaCAwOSwgMjAxOSA1OjU1IEFNDQo+IFRvOiBUaGUgSUVT RyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6IGRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1sYWctbXVs dGlwYXRoQGlldGYub3JnOyBtcGxzLWNoYWlyc0BpZXRmLm9yZzsNCj4gbG9hQHBpLm51OyBtcGxz QGlldGYub3JnDQo+IFN1YmplY3Q6IEFsdmFybyBSZXRhbmEncyBObyBPYmplY3Rpb24gb24gZHJh ZnQtaWV0Zi1tcGxzLWxzcC1waW5nLWxhZy0NCj4gbXVsdGlwYXRoLTA2OiAod2l0aCBDT01NRU5U KQ0KPiANCj4gQWx2YXJvIFJldGFuYSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBw b3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLWxhZy1tdWx0aXBhdGgtMDY6 IE5vIE9iamVjdGlvbg0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3Vi amVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsDQo+IGFkZHJlc3NlcyBpbmNs dWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJv ZHVjdG9yeQ0KPiBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0 byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0 bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5U IHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFs bG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1sYWctbXVsdGlwYXRoLw0KPiAN Cj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g DQo+ICgxKSBUaGUgVXBkYXRlIHRvIHJmYzgwMjkgaXMgbm90IGNsZWFybHkgZXhwbGFpbmVkLiAg VGhlIG5ldyBmdW5jdGlvbmFsaXR5DQo+IGludHJvZHVjZWQgaW4gdGhpcyBkb2N1bWVudCBpcyBj bGVhciwgYnV0IGl0IHNlZW1zIHRvIG1lIHRoYXQgaXQgaXMgb3B0aW9uYWwNCj4gZnJvbSB0aGUg cG9pbnQgb2YgdmlldyB0aGF0IGl0IGlzIG9ubHkgbmVlZGVkIHdoZW4gTEFHcyBleGlzdCwgYW5k IGV2ZW4gdGhlbiwNCj4gb25seSB0aGUgSW5pdGlhdG9yIGFuZCB0aGUgUmVzcG9uZGVyIG5lZWQg dG8gaW1wbGVtZW50IHRoZSBlbmhhbmNlbWVudHMuDQo+IElPVywgdGhlIFVwZGF0ZSB0aGF0IHRo aXMgZG9jdW1lbnQgcHJlc2VudHMgaXMgbm90IG9uZSB0aGF0IGlzIG5lZWRlZCBieSBhbGwNCj4g cmZjODAyOSBpbXBsZW1lbnRhdGlvbnMuICBJJ20gbG9va2luZyBmb3IgdGV4dCB0aGF0IGV4cGxh aW5zIHRoYXQuDQoNCkhvdyBhYm91dCBhZGQgdGhlIGZvbGxvd2luZyBzZW50ZW5jZToNCg0KIlRo ZSBkb2N1bWVudCB1cGRhdGVzIFJGQzgwMjkgYnkgaW50cm9kdWNlIHRoZSBMU1IgQ2FwYWJpbGl0 eSBUTFYgdGhhdCBpcyBub3Qgb25seSB1c2VkIGZvciBMQUdzIGJ1dCBhbHNvIGZvciBmdXR1cmUg Y2FwYWJpbGl0aWVzLiINCg0KPiANCj4gKDIpIMKnNjogIk90aGVyd2lzZSwgaWYgdGhlIHJlc3Bv bmRlciBkb2VzIG5vdCBrbm93IHRoZSBMU1IgQ2FwYWJpbGl0eSBUTFYsIGFuDQo+IE1QTFMgZWNo byByZXBseSB3aXRoIHRoZSByZXR1cm4gY29kZSBzZXQgdG8gIk9uZSBvciBtb3JlIG9mIHRoZSBU TFZzIHdhcw0KPiBub3QgdW5kZXJzdG9vZCIgTVVTVCBiZSBzZW50IGJhY2sgdG8gdGhlIGluaXRp YXRvciBMU1IuIiAgR2l2ZW4gdGhhdCB0aGlzIGlzDQo+IHRoZSBjYXNlIHdoZXJlIHRoZSBuZXcg VExWIGlzIG5vdCBrbm93biwgdGhlbiB3ZSBjYW4ndCBOb3JtYXRpdmVseSBkaXJlY3QNCj4gdGhv c2Ugbm9kZXMgdG8gZG8gYW55dGhpbmcgKHNpbmNlIHRoZXkgcHJvYmFibHkgZG9uJ3QgaW1wbGVt ZW50IGFueXRoaW5nIGluDQo+IHRoaXMgZG9jdW1lbnQpLiAgcy9NVVNUL211c3QgKyBhZGQgYSBy ZWZlcmVuY2UgdG8gcmZjODAyOSAod2hlcmUgdGhlDQo+IGJlaGF2aW9yIGlzDQo+IHNwZWNpZmll ZCkgW1RoZSBzYW1lIHRleHQgYXBwZWFycyBhZ2FpbiBpbiDCpzMgYW5kIMKnMy4yLiAgV3JpdGlu ZyB0aGUNCj4gc3BlY2lmaWNhdGlvbiBpcyBvbmUgcGxhY2UgaXMgZW5vdWdoLl0NCg0KSXQncyBt b3JlIGFjY3VyYXRlIHRvIGNhbGwgaXQgYSAiTWFuZGF0b3J5IiBUTFYgdGhhdCBkb2VzIG5vdCBy ZXF1aXJlIGFuIGltcGxlbWVudGF0aW9uIGhhcyB0byBpbXBsZW1lbnQgaXQsIGJ1dCB3aWxsIHJl c3VsdCBpbiByZXR1cm4gY29kZSB3aGVuIGEgbm9kZSBkb2VzIG5vdCBzdXBwb3J0IGl0LCBhcyBz cGVjaWZpZWQgaW4gUkZDODAyOS4gDQoNCk1heWJlIHdlIGNvdWxkIGp1c3QgcmVtb3ZlIHRoZSAi b3B0aW9uYWwiLCBhbmQgbWFrZSBpdCBjbGVhciB0byB0aGUgSUFOQSBzZWN0aW9uLCB0aGUgY29k ZSBwb2ludCBvZiB0aGlzIFRMViBzaG91bGQgYmUgYWxsb2NhdGVkIGZyb20gdGhlIE1hbmRhdG9y eSByYW5nZS4gIEhvdyBkbyB5b3UgdGhpbms/DQoNCj4gDQo+IEJUVywgYWNjb3JkaW5nIHRvIHJm YzgwMjksIHRoZSByZXR1cm4gY29kZSB3aWxsIGJlIHNlbnQgYmFjayBvbmx5IGlmIHRoZSBUTFYg aXMNCj4gbWFuZGF0b3J5LCBidXQgwqc2IGRlZmluZXMgaXQgYXMgb3B0aW9uYWwuICBQbGVhc2Ug YmUgY2xlYXIgYW5kIHNwZWNpZmljIGFib3V0DQo+IHRoZSBkZWZpbml0aW9uIGFuZCB0aGUgaW5z dHJ1Y3Rpb25zIHRvIElBTkEuDQoNClllcywgaXQncyBzaG91bGQgbW9yZSBjbGVhciBpbiBJQU5B IHNlY3Rpb24uDQoNClRoZSBjb2RlIHBvaW50IHNob3VsZCBiZSBhbGxvY2F0ZWQgZnJvbSBNYW5k YXRvcnkgcmFuZ2UuDQogDQo+IA0KPiAoMykgVGhpcyBkb2N1bWVudCBkb2Vzbid0IHRhbGsgYWJv dXQgd2hhdCBzaG91bGQgYmUgZG9uZSBpZiBhIHJlc3BvbnNlIGlzDQo+IG5vdCByZWNlaXZlZCwg YXQgYW55IHBvaW50IGluIHRoZSBwcm9jZXNzLiAgSSBzZWFyY2hlZCBpbiByZmM4MDI5LCBidXQg ZGlkbid0DQo+IGZpbmQgYW55dGhpbmcgcmVsYXRlZCB0byB0aW1lb3V0cy4uLm9ubHkgwqc0Ljgg KE5vbi1jb21wbGlhbnQgUm91dGVycyksIHdoaWNoDQo+IGluY2x1ZGVzIGEgcHJvY2VzcyBvbiB3 aGF0IHRvIGRvIGlmIGEgcmVwbHkgaXMgbm90IHJlY2VpdmVkLiAgVGhhdCBwcm9jZXNzDQo+IGRv ZXNuJ3Qgc2VlbSB0byBhcHBseSB0byB0aGlzIGRvY3VtZW50IC0tIHdoYXQgc2hvdWxkIGFuIGlu aXRpYXRvciBkbyBpZiBhDQo+IHJlcGx5IGlzIG5vdCByZWNlaXZlZD8gIEkgYW0gc3BlY2lhbGx5 IGludGVyZXN0ZWQgaW4gdGhlIGRpc2NvdmVyeSBwaGFzZXMuDQoNCk5vcm1hbGx5LCB0aGUgdGlt ZW91dCBwcm9jZXNzIGlzIGxlZnQgdGhlIGltcGxlbWVudGF0aW9uIChlLmcuLCB0aHJvdWdoIHRp bWVycykuIA0KDQpJZiBhIHJlcGx5IGNhbm5vdCBiZSByZWNlaXZlZCB3aXRoaW4gYSBjZXJ0YWlu IHBlcmlvZCwgdGhlIGluaXRpYXRvciB3aWxsIHJldHVybiB0aW1lb3V0LiBUaGF0IG1lYW5zIHRo ZXJlIHNvbWUgaXNzdWVzIGFsb25nIHRoZSBwYXRoLCBvcGVyYXRvciBzaG91bGQgaW50ZXJ2ZW5l IHRoZW4uIA0KDQo+IA0KPiAoNCkgW25pdF0gSW4gwqc3LCB0aGUgRFMgRmxhZ3Mgc2hvdWxkIGxv b2sgbGlrZSB0aGlzIChzZWUgcmZjODAxMik6DQo+IA0KPiAgICAgICAgMCAxIDIgMyA0IDUgNiA3 DQo+ICAgICAgICstKy0rLSstKy0rLSstKy0rDQo+ICAgICAgIHwgTUJaIHxHfEV8THxJfE58DQo+ ICAgICAgICstKy0rLSstKy0rLSstKy0rDQoNCk9LLiBXaWxsIG1vdmUgYWxsICJNQloiICB0b2dl dGhlci4NCg0KPiANCj4gKDUpIFJGQzgxMjYgc2hvdWxkIGJlIGEgTm9ybWF0aXZlIHJlZmVyZW5j ZS4NCg0KT0suDQoNCg0KQmVzdCByZWdhcmRzLA0KTWFjaCANCj4gDQoNCg== From nobody Tue Mar 12 19:14:56 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF97127987; Tue, 12 Mar 2019 19:14:51 -0700 (PDT) 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, 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 lZO3kK-zq329; Tue, 12 Mar 2019 19:14:49 -0700 (PDT) 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 5C2351311A1; Tue, 12 Mar 2019 19:14:49 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2D2EhWb008256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Mar 2019 22:14:45 -0400 Date: Tue, 12 Mar 2019 21:14:43 -0500 From: Benjamin Kaduk To: Loa Andersson Cc: The IESG , mpls@ietf.org, draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org, mpls-chairs@ietf.org Message-ID: <20190313021443.GC8182@kduck.mit.edu> References: <155242263093.20169.3838924661112115545.idtracker@ietfa.amsl.com> <8b26fc2e-54f4-b805-aa87-a60cee810567@pi.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8b26fc2e-54f4-b805-aa87-a60cee810567@pi.nu> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 02:14:55 -0000 Hi Loa, On Wed, Mar 13, 2019 at 09:59:29AM +0800, Loa Andersson wrote: > Benjamin, > > The number of authors were discussed and explained in the Shepherds > Write-up. All the 6 authors listed on the front-page has made > text contributions to the document. My apologies, I seem to have missed that line in my first read of the shepherd report; I can drop that point. Thanks, Benjamin From nobody Wed Mar 13 00:07:04 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C537130EC7; Wed, 13 Mar 2019 00:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 348HNrLMPV7x; Wed, 13 Mar 2019 00:06:54 -0700 (PDT) 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 C13D9130EA7; Wed, 13 Mar 2019 00:06:53 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id A33DDAAE26A43FD64B7C; Wed, 13 Mar 2019 07:06:51 +0000 (GMT) Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 13 Mar 2019 07:06:51 +0000 Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Wed, 13 Mar 2019 07:06:51 +0000 Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Wed, 13 Mar 2019 07:06:50 +0000 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.190]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0415.000; Wed, 13 Mar 2019 15:06:43 +0800 From: Mach Chen To: Benjamin Kaduk via Datatracker , The IESG CC: "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" , "mpls-chairs@ietf.org" , "loa@pi.nu" , "mpls@ietf.org" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with DISCUSS and COMMENT) Thread-Index: AQHU2RJ3vF0A2kVnzkeAK0NcOKNWfKYI0+dw Date: Wed, 13 Mar 2019 07:06:42 +0000 Message-ID: References: <155242263093.20169.3838924661112115545.idtracker@ietfa.amsl.com> In-Reply-To: <155242263093.20169.3838924661112115545.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 07:06:57 -0000 SGkgQmVuamFtaW4sDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cyENCg0KUGxlYXNlIHNlZSBz b21lIHJlcGxpZXMgaW5saW5lLi4uDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogQmVuamFtaW4gS2FkdWsgdmlhIERhdGF0cmFja2VyIFttYWlsdG86bm9yZXBseUBpZXRm Lm9yZ10NCj4gU2VudDogV2VkbmVzZGF5LCBNYXJjaCAxMywgMjAxOSA0OjMxIEFNDQo+IFRvOiBU aGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6IGRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1s YWctbXVsdGlwYXRoQGlldGYub3JnOyBtcGxzLWNoYWlyc0BpZXRmLm9yZzsNCj4gbG9hQHBpLm51 OyBtcGxzQGlldGYub3JnDQo+IFN1YmplY3Q6IEJlbmphbWluIEthZHVrJ3MgRGlzY3VzcyBvbiBk cmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctbGFnLW11bHRpcGF0aC0NCj4gMDY6ICh3aXRoIERJU0NV U1MgYW5kIENPTU1FTlQpDQo+IA0KPiBCZW5qYW1pbiBLYWR1ayBoYXMgZW50ZXJlZCB0aGUgZm9s bG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLWxh Zy1tdWx0aXBhdGgtMDY6IERpc2N1c3MNCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtl ZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbA0KPiBhZGRy ZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQg dGhpcyBpbnRyb2R1Y3RvcnkNCj4gcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVh c2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1j cml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBh bmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRo IG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctbGFnLW11bHRp cGF0aC8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBESVNDVVNTOg0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IA0KPiBUaGFua3MgZm9yIHRoaXMgZG9jdW1lbnQ7IGl0J3MgY2xlYXJseSBnb2lu ZyB0byBwcm92aWRlIHZhbHVlLCBhbmQgaXQgZ2l2ZXMgYQ0KPiBwcmV0dHkgd2VsbC1yZWFkYWJs ZSBkZXNjcmlwdGlvbiBvZiBob3cgdGhpbmdzIGFyZSBleHBlY3RlZCB0byB3b3JrLiAgVGhhdA0K DQpUaGFua3MuDQoNCj4gc2FpZCwgdGhlcmUncyBhIG51bWJlciBvZiBkZXRhaWxzIHRoYXQgbmVl ZCB0byBiZSB3b3JrZWQgb3V0IGJlZm9yZQ0KPiBwdWJsaWNhdGlvbi4uLg0KDQpPSy4NCg0KPiAN Cj4gVGhpcyBkb2N1bWVudCBoYXMgc2l4IGxpc3RlZCBhdXRob3JzOyBwZXIgUkZDIDczMjIsIGRv Y3VtZW50cyBsaXN0aW5nIG1vcmUNCj4gdGhhbiBmaXZlIGF1dGhvcnMgYXJlIHVudXN1YWwsIGFu ZCBzaXggaXMgZ3JlYXRlciB0aGFuIGZpdmUuICBMZXQncyB0YWxrIGFib3V0IHRoZQ0KPiBhdXRo b3IgY291bnQuDQoNCkxvYSBoYXMgYW5zd2VyZWQgdGhlIHF1ZXN0aW9uLiANCg0KUGxlYXNlIHJl ZmVyIHRvIHRoZSBTaGVwaGVyZCB3cml0ZXVwIHdoZXJlIGl0IGlzIG5vdGVkIHN1cHBvcnQgb2Yg dGhlIHNpeCBhdXRob3JzDQoNCj4gDQo+ICJvcHRpb25hbCBUTFYiIHNlZW1zIHRvIGJlIHVzZWQg aW4gTVBMUyBjb250ZXh0cyBhcyBhIHRlY2huaWNhbCB0ZXJtIGZvcg0KPiAiY29tcHJlaGVuc2lv bi1vcHRpb25hbCIsIG5vdCBpbiB0aGUgIm9wdGlvbmFsIHRvIHNlbmQiIHNlbnNlOyBpdCdzIHRo ZQ0KPiBjb3VudGVycGFydCBvZiAibWFuZGF0b3J5IFRMViIsIGFuZCB0aGlzIHRlcm1pbm9sb2d5 IGlzIGV2ZW4gZG9jdW1lbnRlZCBpbg0KPiB0aGUgTVBMUyBUTFZzIHJlZ2lzdHJ5LiAgSXQncyBt eSB1bmRlcnN0YW5kaW5nIHRoYXQgdGhlIExTUCBDYXBhYmlsaXRpZXMgVExWDQo+IGFuZCB0aGUg RGV0YWlsZWQgSW50ZXJmYWNlIGFuZCBMYWJlbCBTdGFjayBUTFYgYXJlIGludGVuZGVkIHRvIGJl DQo+IGNvbXByZWhlbnNpb24tcmVxdWlyZWQgKGkuZS4sICJtYW5kYXRvcnkgVExWcyIpLCBhbmQg dGh1cyB0aGF0IHdlIG11c3QNCj4gbm90IHVzZSB0aGUgcGhyYXNlICJvcHRpb25hbCBUTFYiIGlu IHRoZWlyIGRlc2NyaXB0aW9uLg0KPiBUaGlzIHdvdWxkIGJlIG1hZGUgY2xlYXIgaWYgd2UgbGlz dGVkIHdoaWNoIHJhbmdlIG9mIHZhbHVlcyB3ZSBpbnRlbmRlZCB0bw0KPiBhbGxvY2F0ZSBhIFRM ViB0eXBlIGZyb20sIGluIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zLCBidXQgdGhhdCByZW1haW5z DQo+IHVuc3BlY2lmaWVkIGF0IHRoaXMgdGltZS4NCg0KR29vZCBjYXRjaCBvbiB0aGUgTFNQIENh cGFiaWxpdGllcyBUTFYsIGl0IHNob3VsZCBiZSBzcGVjaWZpZWQgYXMgYXNzaWduZWQgZnJvbSB0 aGUgcmFuZ2UgMC0xNjM4MyBhcyBhIHJlc3BvbnNlIGlzIHJlcXVpcmVkLiBUaGUgVExWIGlzIG9w dGlvbmFsLCBhcyBub3RlZCB0aGlzIHJhbmdlIGFsc28gY292ZXJzIG9wdGlvbmFsIFRMVnMgZm9y IHdoaWNoIGEgcmVzcG9uc2UgaXMgcmVxdWlyZWQuIFBlciBSRkM4MDI5LCB0aGUgRG93bnN0cmVh bSBEZXRhaWxlZCBNYXBwaW5nIFRMViB3aGljaCBpcyB1c2VkIGluIHRoaXMgUkZDIGlzIGFsc28g b3B0aW9uYWwuDQoNCj4gDQo+IEluIGEgc2ltaWxhciB2ZWluICh0aGUgImNvbXByZWhlbnNpb24t cmVxdWlyZWQiIGJlaGF2aW9yKSwgdGhlcmUgYXJlIGEgZmV3DQo+IHBsYWNlcyAoU2VjdGlvbiAz ICh0d2ljZSksIGFuZCBTZWN0aW9uIDY7IGFsc28gU2VjdGlvbiAzIGZvciB0aGUgTEFHIERlc2Ny aXB0aW9uDQo+IEluZGljYXRvciBmbGFnOyBzZWUgQ09NTUVOVCkgd2hlcmUgd2Ugc3RhdGUgbmV3 IG5vcm1hdGl2ZSBsYW5ndWFnZQ0KPiAoIk1VU1QiKSB0aGF0IGlzIHVuZW5mb3JjZWFibGUsIHNp bmNlIGl0IHdvdWxkIG5lZWQgdG8gYXBwbHkgdG8gTVBMUw0KPiBpbXBsZW1lbnRhdGlvbnMgdGhh dCBkbyBub3QgaW1wbGVtZW50IHRoaXMgc3BlY2lmaWNhdGlvbi4NCj4gRm9ydHVuYXRlbHksIHRo ZSBjb21wcmVoZW5zaW9uLXJlcXVpcmVkIFRMViByYW5nZXMgcHJvdmlkZSB0aGlzDQo+IGZ1bmN0 aW9uYWxpdHkgZm9yIHVzIHdpdGhvdXQgdGhlIG5lZWQgdG8gdXNlIG5vcm1hdGl2ZSBsYW5ndWFn ZS4NCg0KT0ssIHRoaXMgaXMgYWRkcmVzc2VkIHdpdGggdGhlIGJlbG93IENNTUVOVC4NCg0KPiAN Cj4gU2VjdGlvbiA0LjIgaGFzIHNvbWUgY29uZmxpY3RpbmcgIk1VU1QicyBhYm91dCB0aGUgb3Jk ZXJpbmcvcHJlc2VuY2Ugb2YNCj4gc3ViLVRMVnMgaW4gdGhlIERETUFQIFRMViAoc2VlIENPTU1F TlQsIGFuZCBhbHNvIHRoZSAiTUFOREFUT1JZIg0KPiBsYW5nYXVnZSBpbiBGaWd1cmUgMikuDQoN Ck9LLCB0aGlzIGlzIGFkZHJlc3NlZCB3aXRoIHRoZSBDT01NRU5ULiANCg0KPiANCj4gSWYgSSdt IHJlYWRpbmcgU2VjdGlvbiA1LjEuMiBjb3JyZWN0bHksIHRoZSBkZXNjcmliZWQgcHJvY2VkdXJl IGlzIG9ubHkNCj4gaW50ZW5kZWQgdG8gYXBwbHkgd2hlbiB0aGUgIkciIGZsYWcgaXMgcHJlc2Vu dCAoYXMgd2VsbCBhcyB0aGUgIkkiIGZsYWcsIHRoZQ0KPiByZXF1aXJlbWVudCBmb3Igd2hpY2gg aXMgZXhwbGljaXRseSBzdGF0ZWQpLCBidXQgdGhpcyBpcyBub3QgZXhwbGljaXRseSBzdGF0ZWQu ICBJbg0KPiBwYXJ0aWN1bGFyLCB0aGUgdGV4dCBhcyB3cml0dGVuIHNheXMgaXQgYXBwbGllcyB0 byBhbGwgcmVzcG9uZGVycyB0aGF0DQo+ICJ1bmRlcnN0YW5kIHRoZSBMQUcgRGVzY3JpcHRpb24g SW5kaWNhdG9yIGZsYWciDQo+IHdpdGggbm8gbWVudGlvbiBvZiBydW50aW1lIGNoZWNrIGZvciB0 aGUgcHJlc2VuY2Ugb2YgdGhhdCBmbGFnLg0KDQpIb3cgYWJvdXQgYWRkIGEgY29uZGl0aW9uIGF0 IHRoZSBiZWdpbm5pbmc6DQoNCg0KPiANCj4gSSBhbHNvIHdvcnJ5IHRoYXQgU2VjdGlvbnMgOCwg OSwgYW5kIDEwIGFyZSBpbnN1ZmZpY2llbnRseSBjbGVhciBhYm91dCB0aGUNCj4gZW5jb2Rpbmcg b2YgdGhlIGludGVyZmFjZSBpbmRleCB2YWx1ZSAtLSBpcyBpdCBhbiBpbnRlZ2VyIGluIE5CTywg YW4gb3BhcXVlDQo+IGJpdHN0cmluZywgb3Igc29tZXRoaW5nIGVsc2U/DQo+IA0KPiANCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBBbSBJIHJlYWRp bmcgdGhpcyBjb3JyZWN0bHkgdGhhdCB0aGUgIkxTUiBDYXBhYmlsaXR5IFRMViIgY3JlYXRlZCBo ZXJlIGlzDQo+IGJhc2ljYWxseSBvbmx5IGFwcGxpY2FibGUgdG8gcHJvcGVydGllcyBvZiBNUExT IGVjaG8gcmVxdWVzdC9yZXBseSBleGNoYW5nZXM/DQo+IElmIHNvLCB0aGVuIHBlcmhhcHMgdGhl IG1vbmlrZXIgIkxTUiBDYXBhYmlsaXR5IiBpcyBvdmVybHkgZ2VuZXJpYy4NCg0KSXQncyBub3cg ZGVmaW5lZCBmb3IgTFNQIFBpbmcgZWNobyByZXF1ZXN0L3JlcGx5IGV4Y2hhbmdlcywgYnV0IG1h eSBiZSB1c2VkIHRvIHJldHVybiBnZW5lcmFsIExTUiBjYXBhYmlsaXRpZXMgaW4gdGhlIGZ1dHVy ZS4gSSBpbmNsaW5lIHRvIGtlZXAgaXQgYXMgaXMuICBBcmUgeW91IHN1Z2dlc3RpbmcgIHRvIGNo YW5nZSB0byBhbm90aGVyIG5hbWU/DQo+IA0KPiBTZWN0aW9uIDEuMg0KPiANCj4gICAgbyAgTGFi ZWwgc3dpdGNoaW5nIG92ZXIgc29tZSBtZW1iZXIgbGlua3Mgb2YgdGhlIExBRyBpcyBzdWNjZXNz ZnVsLA0KPiAgICAgICBidXQgd2lsbCBiZSBmYWlsZWQgb3ZlciBvdGhlciBtZW1iZXIgbGlua3Mg b2YgdGhlIExBRy4NCj4gDQo+IG5pdDogdGhlcmUncyBzb21lIHZlcmIgdGVuc2UgaW5jb25zaXN0 ZW5jeSBoZXJlOyBtYXliZSAiYnV0IGZhaWxzIG92ZXIgb3RoZXINCj4gbWVtYmVyIGxpbmtzIiB3 b3VsZCBoZWxwLg0KDQoNCk9LLg0KDQo+IA0KPiBTZWN0aW9uIDINCj4gDQo+ICAgIFRoaXMgZG9j dW1lbnQgZGVmaW5lcyBhbiBvcHRpb25hbCBUTFYgdG8gZGlzY292ZXIgdGhlIGNhcGFiaWxpdGll cyBvZg0KPiAgICBhIHJlc3BvbmRlciBMU1IgYW5kIGV4dGVuc2lvbnMgZm9yIHVzZSB3aXRoIHRo ZSBNUExTIExTUCBQaW5nIGFuZA0KPiANCj4gbml0OiBpcyBpdCBvbmx5IHRoZSAqcmVzcG9uZGVy KiBMU1Igd2UgY2FyZSBhYm91dCwgb3IgYXJlIHRoZXJlIHBvdGVudGlhbGx5DQo+IGludGVybWVk aWFyaWVzIGluIHBsYXk/DQoNCk9ubHkgdGhlIHJlc3BvbmRlciBMU1IgY2FyZXMuIA0KDQo+IA0K PiAgICBUaGUgc29sdXRpb24gY29uc2lzdHMgb2YgdGhlIE1QTFMgZWNobyByZXF1ZXN0IGNvbnRh aW5pbmcgYSBERE1BUCBUTFYNCj4gICAgYW5kIHRoZSBvcHRpb25hbCBMU1IgY2FwYWJpbGl0eSBU TFYgdG8gaW5kaWNhdGUgdGhhdCBzZXBhcmF0ZSBsb2FkDQo+IA0KPiBuaXQ6IElzIHRoaXMgIm9w dGlvbmFsIGNhcGFiaWxpdHkgVExWIiB0aGUgc2FtZSAib3B0aW9uYWwgVExWIiB0aGF0IHdlIGFy ZQ0KPiBkZWZpbmluZyBpbiB0aGlzIGRvY3VtZW50PyAgSWYgc28sIGNhbGxpbmcgaXQgInRoZSBu ZXcgb3B0aW9uYWwgTFNSIGNhcGFiaWxpdHkiDQo+IHdvdWxkIGFpZCBjbGFyaXR5LiAgKEFsc28s IHdlIHNlZW0gdG8gdXNlIGJvdGggdGhlICJjYXBhYmlsaXR5IiBhbmQNCj4gIkNhcGFiaWxpdHki IGNhcGl0emxpYXRpb25zIGZvciBkZXNjcmliaW5nIHRoaXMgVExWLikNCg0KT0suDQoNCkFuZCBh cyBzdWdnZXN0ZWQgYWJvdmUsIG1heWJlIHdlIGNvdWxkIHJlbW92ZSB0aGUgIm9wdGlvbmFsIiBw cmVmaXguIFdpbGwgY2hhbmdlIGl0IHRvICJ0aGUgbmV3IExTUCBjYXBhYmlsaXR5Ii4gSXMgaXQg T0sgZm9yIHlvdT8NCg0KPiANCj4gU2VjdGlvbiAzDQo+IA0KPiAgICBDYXBhYmlsaXR5IFRMViBp biB0aGUgTVBMUyBlY2hvIHJlcXVlc3QgbWVzc2FnZS4gIFdoZW4gdGhlIHJlc3BvbmRlcg0KPiAg ICBMU1IgcmVjZWl2ZXMgYW4gTVBMUyBlY2hvIHJlcXVlc3QgbWVzc2FnZSB3aXRoIHRoZSBMU1Ig Q2FwYWJpbGl0eSBUTFYNCj4gICAgaW5jbHVkZWQsIGlmIGl0IGtub3dzIHRoZSBMU1IgQ2FwYWJp bGl0eSBUTFYsIHRoZW4gaXQgTVVTVCBpbmNsdWRlDQo+ICAgIHRoZSBMU1IgQ2FwYWJpbGl0eSBU TFYgaW4gdGhlIE1QTFMgZWNobyByZXBseSBtZXNzYWdlIHdpdGggdGhlIExTUg0KPiAgICBDYXBh YmlsaXR5IFRMViBkZXNjcmliaW5nIGZlYXR1cmVzIGFuZCBleHRlbnNpb25zIHN1cHBvcnRlZCBi eSB0aGUNCj4gICAgbG9jYWwgTFNSLiAgT3RoZXJ3aXNlLCBhbiBNUExTIGVjaG8gcmVwbHkgTVVT VCBiZSBzZW50IGJhY2sgdG8gdGhlDQo+ICAgIGluaXRpYXRvciBMU1Igd2l0aCB0aGUgcmV0dXJu IGNvZGUgc2V0IHRvICJPbmUgb3IgbW9yZSBvZiB0aGUgVExWcw0KPiAgICB3YXMgbm90IHVuZGVy c3Rvb2QiLiAgWy4uLl0NCj4gDQo+IFRoaXMgbGFzdCBNVVNUIHNlZW1zIGxpa2Ugc29tZXRoaW5n IHRoYXQgdGhpcyBkb2N1bWVudCBjYW5ub3QgbWFuZGF0ZSAoYXMNCj4gaXQgYXR0ZW1wdHMgdG8g YXBwbHkgdG8gbm9uLWltcGxlbWVudGF0aW9ucyBvZiB0aGlzIGRvY3VtZW50KTsgaXQgY291bGQg b25seQ0KPiB3b3JrIGlmIGl0IHdhcyBhbiBleGlzdGluZyByZXF1aXJlbWVudCBmcm9tIHRoZSBj b3JlIE1QTFMgc3BlYywgaW4gd2hpY2gNCj4gY2FzZSBsb3dlci1jYXNlICJtdXN0IiBpcyBhcHBy b3ByaWF0ZSAocG9zc2libHkgd2l0aCBzZWN0aW9uIHJlZmVyZW5jZSkuDQoNCk9LLg0KDQo+IA0K PiAgICBvICBJZiB0aGUgcmVzcG9uZGVyIExTUiBkb2VzIG5vdCB1bmRlcnN0YW5kIHRoZSAiTEFH IERlc2NyaXB0aW9uDQo+ICAgICAgIEluZGljYXRvciBmbGFnIjoNCj4gDQo+ICAgICAgICogIENs ZWFyIGJvdGggdGhlICJEb3duc3RyZWFtIExBRyBJbmZvIEFjY29tbW9kYXRpb24gZmxhZyIgYW5k IHRoZQ0KPiAgICAgICAgICAiVXBzdHJlYW0gTEFHIEluZm8gQWNjb21tb2RhdGlvbiBmbGFnIi4N Cj4gDQo+IFNpbWlsYXJseSwgaWYgYW4gTFNSIGRvZXMgbm90IHVuZGVyc3RhbmQgYSBmbGFnLCBp dCBjYW5ub3QgZ2l2ZSBzcGVjaWFsDQo+IHRyZWF0bWVudCB0byBwYWNrZXRzIGNvbnRhaW5pbmcg dGhhdCBmbGFnLiAgKFdoeSBhbiBMU1Igd291bGQgbm90DQo+IHVuZGVyc3RhbmQgYSBmbGFnIGRl ZmluZWQgaW4gdGhlIHNhbWUgZG9jdW1lbnQgdGhhdCBkZWZpbmVzIHRoZSBDYXBhYmlsaXRpZXMN Cj4gVExWIGlzIGJleW9uZCBtZSwgYnV0IHlvdSBzZWVtIHRvIHdhbnQgdG8gYWxsb3cgZm9yIHRo YXQNCj4gY2FzZS4pDQoNCg0KPiANCj4gICAgSWYgdGhlIHJlc3BvbmRlciBkb2VzIG5vdCBrbm93 IHRoZSBMU1IgQ2FwYWJpbGl0eSBUTFYsIGFuIE1QTFMgZWNobw0KPiAgICByZXBseSB3aXRoIHRo ZSByZXR1cm4gY29kZSBzZXQgdG8gIk9uZSBvciBtb3JlIG9mIHRoZSBUTFZzIHdhcyBub3QNCj4g ICAgdW5kZXJzdG9vZCIgTVVTVCBiZSBzZW50IGJhY2sgdG8gdGhlIGluaXRpYXRvciBMU1IuDQo+ IA0KPiBUaGlzIGR1cGxpY2F0ZXMgdGhlIGNvbnRlbnQgSSBxdW90ZWQgYXQgdGhlIHRvcCBvZiB0 aGlzIHNlY3Rpb24ncyBjb21tZW50cy4NCg0KT0suIA0KDQo+IA0KPiBTZWN0aW9uIDQuMQ0KPiAN Cj4gICAgT25jZSB0aGUgaW5pdGlhdG9yIExTUiBrbm93cyB0aGUgY2FwYWJpbGl0aWVzIHRoYXQg YSByZXNwb25kZXINCj4gICAgc3VwcG9ydHMsIHRoZW4gaXQgc2VuZHMgYW4gTVBMUyBlY2hvIHJl cXVlc3QgY2FycnlpbmcgYSBERE1BUCB3aXRoDQo+ICAgIHRoZSAiTEFHIERlc2NyaXB0aW9uIElu ZGljYXRvciBmbGFnIiAoRykgc2V0IHRvIHRoZSByZXNwb25kZXIgTFNSLg0KPiANCj4gbml0OiBJ IHRoaW5rIHRoZSBrZXkgcG9pbnQgaXMgbm90IHRoYXQgdGhlIGluaXRpYXRvciBrbm93cyB0aGUg Y2FwYWJpbGl0aWVzIG9mIHRoZQ0KPiBwZWVyLCBidXQgcmF0aGVyIHRoYXQgdGhlIGluaXRpYXRv ciBrbm93cyB0aGF0IHRoZSBwZWVyIHN1cHBvcnRzIHRoaXMgc3BlY2lmaWMNCj4gbWVjaGFuaXNt Lg0KDQpPSywgaG93IGFib3V0IDoNCg0KIk9uY2UgdGhlIGluaXRpYXRvciBMU1Iga25vd3MgdGhh dCBhIHJlc3BvbmRlciBjYW4gc3VwcG9ydCB0aGlzIG1lY2hhbmlzbSwgdGhlbiBpdCBzZW5kcyBh biBNUExTIGVjaG8gcmVxdWVzdCBjYXJyeWluZyBhIERETUFQIFRMViB3aXRoIHRoZSAiTEFHIERl c2NyaXB0aW9uIEluZGljYXRvciBmbGFnIiAoRykgc2V0IHRvIHRoZSByZXNwb25kZXIgTFNSLg0K DQo+IEFsc28sIGlzIHRoaXMgImEgRERNQVAgVExWIj8NCg0KWWVzLg0KDQo+IA0KPiBTZWN0aW9u IDQuMg0KPiANCj4gUmVhZGluZyB0aGlzIG1ha2VzIGl0IHNvdW5kIGxpa2UgdGhlICJMQUcgRGVz Y3JpcHRpb24gSW5kaWNhdG9yIGZsYWciIGlzDQo+IGNvbXBsZXRlbHkgb3J0aG9nb25hbCB0byBy ZWd1bGFyIERETUFQIGZ1bmN0aW9uYWxpdHksIHNvIHRoYXQgaWYgSSBzZXQgdGhlDQo+IExBRyBk ZXNjcmlwdGlvbiBpbmRpY2F0b3IgZmxhZyBidXQgZG8gbm90IG90aGVyd2lzZSByZXF1ZXN0IGRl dGFpbGVkDQo+IGRlc2NyaXB0aW9ucywgb25seSB0aGUgTEFHIGludGVyZmFjZXMgYXJlIHJldHVy bmVkLiAgSG93ZXZlciwgdGhlIGZsYWcgaW4NCj4gcXVlc3Rpb24gaGFzIHRvIGJlIGluc2lkZSBh IERETUFQIFRMViAoYW5kIHdlIHNob3VsZCByZWFsbHkgc2F5IHNvLCBwZXJoYXBzDQo+IGFzICJb ZmxhZ10gc2V0ICppbiB0aGUgRERNQVAgVExWKiIhKSwgc28gaXQgc2VlbXMgbGlrZSBpbiBwcmFj dGljZSB0aGUgTEFHDQo+IGluZm9ybWF0aW9uIGNhbiBvbmx5IGJlIG9idGFpbmVkIGluIGNvbmp1 bmN0aW9uIHdpdGggZnVsbCBkZXRhaWxlZCBkZXNjcmlwdGlvbg0KPiBpbmZvcm1hdGlvbi4gIChU aGUgc3BlY2lmaWMgc3VnZ2VzdGlvbiBoZXJlIGlzIHRvIG5vdGUgY2xlYXJseSB0aGF0IHRoZSBm bGFnIGlzIHNlDQo+IGluIHRoZSBERE1BUCBUTFYuKQ0KDQpPSywgdGhlbiB0aGUgZmlyc3Qgc2Vu dGVuY2Ugd2lsbCBsaWtlIGJlbG93Og0KDQoiV2hlbiBhIHJlc3BvbmRlciBMU1IgcmVjZWl2ZWQg YW4gTVBMUyBlY2hvIHJlcXVlc3QgbWVzc2FnZSB3aXRoIHRoZSAiTEFHIERlc2NyaXB0aW9uIElu ZGljYXRvciBmbGFnIiBzZXQgaW4gdGhlIERETUFQIFRMVi4iDQoNCj4gDQo+ICAgICAgICogIFRo ZSByZXNwb25kZXIgTFNSIE1VU1QgaW5jbHVkZSBhIERETUFQIFRMViB3aGVuIHNlbmRpbmcgdGhl DQo+ICAgICAgICAgIE1QTFMgZWNobyByZXBseS4NCj4gDQo+IEkgZ290IGNvbmZ1c2VkIG9uIG15 IGZpcnN0IHBhc3MgdGhyb3VnaCB0aGlzIHNlY3Rpb247IGFkZGluZyAiVGhlcmUgaXMgYSBzaW5n bGUNCj4gRERNQVAgVExWIGZvciB0aGUgTEFHIGludGVyZmFjZSwgd2l0aCBtZW1iZXIgbGlua3Mg ZGVzY3JpYmVkIHVzaW5nIHN1Yi0NCj4gVExWcyIgaGVyZSB3b3VsZCBoYXZlIGtlcHQgbWUgZnJv bSB2ZWVyaW5nIG9udG8gdGhlIHdyb25nIHBhdGguDQo+IChJIHRob3VnaHQgdGhlcmUgd2FzIGdv aW5nIHRvIGJlIG9uZSBERE1BUCBUTFYgcGVyIG1lbWJlciBsaW5rLCBwbHVzIG9uZQ0KPiBmb3Ig dGhlIExBRyBhZ2dyZWdhdGUsIHdpdGggbG90cyBvZiBkdXBsaWNhdGlvbi4pDQoNCk9LLg0KDQo+ IA0KPiAgICBCYXNlZCBvbiB0aGUgcHJvY2VkdXJlcyBkZXNjcmliZWQgYWJvdmUsIGV2ZXJ5IExB RyBtZW1iZXIgbGluayB3aWxsDQo+ICAgIGhhdmUgYSBMb2NhbCBJbnRlcmZhY2UgSW5kZXggU3Vi LVRMViBhbmQgYSBNdWx0aXBhdGggRGF0YSBTdWItVExWDQo+ICAgIGVudHJpZXMgaW4gdGhlIERE TUFQIFRMVi4gIFRoZSBvcmRlciBvZiB0aGUgU3ViLVRMVnMgaW4gdGhlIERETUFQIFRMVg0KPiAg ICBmb3IgYSBMQUcgbWVtYmVyIGxpbmsgTVVTVCBiZSBMb2NhbCBJbnRlcmZhY2UgSW5kZXggU3Vi LVRMVg0KPiAgICBpbW1lZGlhdGVseSBmb2xsb3dlZCBieSBNdWx0aXBhdGggRGF0YSBTdWItVExW LiAgQSBMQUcgbWVtYmVyIGxpbmsNCj4gICAgTUFZIGFsc28gaGF2ZSBhIGNvcnJlc3BvbmRpbmcg UmVtb3RlIEludGVyZmFjZSBJbmRleCBTdWItVExWLiAgV2hlbiBhDQo+ICAgIExvY2FsIEludGVy ZmFjZSBJbmRleCBTdWItVExWLCBhIFJlbW90ZSBJbnRlcmZhY2UgSW5kZXgtU3ViLVRMViBhbmQg YQ0KPiAgICBNdWx0aXBhdGggRGF0YSBTdWItVExWIGFyZSBwbGFjZWQgaW4gdGhlIERETUFQIFRM ViB0byBkZXNjcmliZSBhIExBRw0KPiAgICBtZW1iZXIgbGluaywgdGhleSBNVVNUIGJlIHBsYWNl ZCBpbiB0aGUgb3JkZXIgb2YgTG9jYWwgSW50ZXJmYWNlDQo+ICAgIEluZGV4IFN1Yi1UTFYsIFJl bW90ZSBJbnRlcmZhY2UgSW5kZXgtU3ViLVRMViBhbmQgTXVsdGlwYXRoIERhdGEgU3ViLQ0KPiAg ICBUTFYuDQo+IA0KPiBUaGlzIGxhc3QgTVVTVCBjb250cmFkaWN0cyB0aGUgcHJldmlvdXMgTVVT VC4gIEkgc3VnZ2VzdCBzb21lIG1vcmUgdGV4dCB0bw0KPiBjbGFyaWZ5IHVuZGVyIHdoaWNoIGNv bmRpdGlvbnMgZWFjaCByZXF1aXJlbWVudCBhcHBsaWVzLg0KDQpIb3cgYWJvdXQgYWRkaW5nIHRo ZSBmb2xsb3dpbmcgc2VudGVuY2UgYmVmb3JlICJUaGUgb3JkZXIgb2YgLi4uLiIsIHRoZSBpdCB3 aWxsIGxvb2sgbGlrZToNCg0KIldoZW4gYSBMb2NhbCBJbnRlcmZhY2UgSW5kZXggU3ViLVRMViBh bmQgYSBNdWx0aXBhdGggRGF0YSBTdWItVExWIGFyZSBwbGFjZWQgaW4gdGhlIERETUFQIFRMViB0 byBkZXNjcmliZSBhIExBRyBtZW1iZXIgbGluaywgdGhlIG9yZGVyIG9mIHRoZSBTdWItVExWcyBp biB0aGUgRERNQVAgVExWLi4uIg0KDQo+IA0KPiBJJ2QgYWxzbyBzdWdnZXN0IG5vdCB1c2luZyB0 aGUgZmlndXJlIGZvciBjb252ZXlpbmcgYSAoYXBwYXJlbnQ/KSBtYW5kYXRvcnkNCj4gcmVxdWly ZW1lbnQsIGFuZCBpbnN0ZWFkIGFkZGluZyBzb21lIHRleHQgYXQgdGhlIGVuZDogIlRoZSBibG9j ayBvZiBsb2NhbA0KPiBpbnRlcmZhY2UgaW5kZXgsIChvcHRpb25hbCByZW1vdGUgaW50ZXJmYWNl IGluZGV4KSBhbmQgbXVsdGlwYXRoIGRhdGEgc3ViLQ0KPiBUTFZzIGZvciBlYWNoIG1lbWJlciBs aW5rIE1VU1QgYXBwZWFyIGFkamFjZW50IHRvIGVhY2ggb3RoZXIgaW4gb3JkZXIgb2YNCj4gaW5j cmVhc2luZyBsb2NhbCBpbnRlcmZhY2UgaW5kZXguIg0KDQpPSy4NCg0KPiANCj4gSXQncyBjb25m dXNpbmcgdG8gbGFiZWwgdGhlIG11bHRpcGxhdGggZGF0YSBzdWItVExWIGFzICJNQU5EQVRPUlki IHdoZW4NCj4gdGhlIGJvZHkgdGV4dCBzYXlzICJNVVNUIGFkZCBhbiBbc2ljXSBNdWx0aXBhdGgg ZGF0YSBTdWItVExWIFsuLi5dIGlmIHRoZQ0KPiByZWNlaXZlZCBERE1BUCBUTFYgcmVxdWVzdGVk IG11bHRpcGF0aCBpbmZvcm1hdGlvbiIsIGkuZS4sIGl0IGlzIG5vdCBhbHdheXMNCj4gcHJlc2Vu dCwgYmFzZWQgb24gdGhlIGNvbnRlbnRzIG9mIHRoZSBlY2hvIHJlcXVlc3QuDQoNClNpbmNlIGl0 J3MgYW4gZXhhbXBsZSwgd2lsbCAgcmVtb3ZlIHRoZSAiTUFOREFUT1JZIiBhbmQgIk9QVElPTkFM IiBwcmVmaXguIA0KDQo+IA0KPiAgICBXaGVuIG5vbmUgb2YgdGhlIHJlY2VpdmVkIG11bHRpcGF0 aCBpbmZvcm1hdGlvbiBtYXBzIHRvIGEgcGFydGljdWxhcg0KPiAgICBMQUcgbWVtYmVyIGxpbmss IHRoZW4gdGhlIHJlc3BvbmRlciBMU1IgTVVTVCBzdGlsbCBwbGFjZSB0aGUgTG9jYWwNCj4gICAg SW50ZXJmYWNlIEluZGV4IFN1Yi1UTFYgYW5kIHRoZSBNdWx0aXBhdGggRGF0YSBTdWItVExWIGZv ciB0aGF0IExBRw0KPiAgICBtZW1iZXIgbGluayBpbiB0aGUgRERNQVAgVExWLCB0aGUgdmFsdWUg b2YgTXVsdGlwYXRoIExlbmd0aCBmaWVsZCBvZg0KPiAgICB0aGUgTXVsdGlwYXRoIERhdGEgU3Vi LVRMViBpcyBzZXQgdG8gemVyby4NCj4gDQo+IG5pdDogdGhlIGxhc3QgY29tbWEgaXMgYSBjb21t YSBzcGxpY2UuDQo+IA0KPiBTZWN0aW9uIDUuMS4yDQo+IA0KPiBJdCBzZWVtcyBsaWtlIHRoaXMg cGxhY2VzIGEgc2xpZ2h0bHkgc3Ryb25nZXIgYnVyZGVuIG9uIHRoZSByZXNwb25kZXIgdGhhbg0K PiBzdG9jayA4MDI5IGRvZXMsIGluIHRoYXQgdGhlcmUgaXMgYSBNVVNULWxldmVsIHJlcXVpcmVt ZW50IHRvIGFjdCBvbiB0aGUgJ0knDQo+IGZsYWcgaW4gY29tYmluYXRpb24gd2l0aCB0aGUgJ0cn IGZsYWcsIHdoZXJlYXMgZm9yIHRoZSAnSScNCj4gZmxhZyBhbG9uZSA4MDI5IG9ubHkgaGFzIGEg U0hPVUxELWxldmVsIHJlcXVpcmVtZW50IHRvIHJlc3BvbmQgYWNjb3JkaW5nbHkuDQo+IFdlIG1h eSB3YW50IHRvIGNhbGwgdGhpcyBvdXQgYXMgYSBjaGFuZ2UgaW4gYmVoYXZpb3IuDQoNCkkgYW0g ZmluZSB0byBjaGFuZ2UgdG8gIlNIT1VMRCIsIHRoZW4gaXQgY2FuIGFsaWduIHdpdGggODAyOS4g DQoNCj4gDQo+IFNlY3Rpb24gNS4xLjMNCj4gDQo+ICAgIEV4cGVjdGF0aW9uIGlzIHRoYXQgdGhl cmUncyBhIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBpbnRlcmZhY2UNCj4gICAgaW5kZXggb2Yg dGhlIG91dGdvaW5nIExBRyBtZW1iZXIgbGluayBhdCBUVEw9biBhbmQgdGhlIGludGVyZmFjZQ0K PiAgICBpbmRleCBvZiB0aGUgaW5jb21pbmcgTEFHIG1lbWJlciBsaW5rIGF0IFRUTD1uKzEgZm9y IGFsbCBkaXNjb3ZlcmVkDQo+ICAgIGVudHJvcGllcy4gIEluIG90aGVyIHdvcmRzLCBzZXQgb2Yg ZW50cm9waWVzIHRoYXQgbG9hZCBiYWxhbmNlcyB0bw0KPiANCj4gbml0OiAiVGhlIGV4cGVjdGF0 aW9uIg0KT0suDQoNCj4gbml0OiAiZGlzY292ZXJlZCBlbnRyb3BpZXMiIGlzIGEgc3RyYW5nZSB3 b3JkaW5nIGdpdmVuIGhvdyB0aGUgZW50cm9weSBsYWJlbA0KPiB3b3JrczsgaXMgdGhpcyBtb3Jl IGxpa2UgImFsbCBlbnRyb3BpZXMgZXhhbWluZWQiPw0KDQpIb3cgYWJvdXQgICJhbGwgZW50cm9w aWVzIGRpc2NvdmVyZWQiPw0KDQo+IA0KPiANCj4gICAgVGhlIGluaXRpYXRvciBMU1Igc2VuZHMg dHdvIE1QTFMgZWNobyByZXF1ZXN0IG1lc3NhZ2VzIHRvIHRyYXZlcnNlDQo+ICAgIHRoZSB0d28g TEFHIG1lbWJlciBsaW5rcyBhdCBUVEw9bisxOg0KPiANCj4gSG93IGRvZXMgdGhlIGluaXRpYXRv ciBrbm93ICh3aGljaCBlbnRyb3B5IGxhYmVsIHZhbHVlcz8pIHRvIGdldCB0aGUgZWNobw0KPiBy ZXF1ZXN0cyB0byB0cmF2ZXJzZSBkaWZmZXJlbnQgbWVtYmVyIGxpbmtzPw0KPiANCj4gICAgbyAg RXJyb3IgY2FzZToNCj4gDQo+ICAgICAgICogIE9uZSBNUExTIGVjaG8gcmVxdWVzdCBtZXNzYWdl IHJlYWNoZXMgVFRMPW4rMSBvbiBhbiBMQUcgbWVtYmVyDQo+ICAgICAgICAgIGxpbmsgMS4NCj4g DQo+ICAgICAgICogIFRoZSBvdGhlciBNUExTIGVjaG8gcmVxdWVzdCBtZXNzYWdlIGFsc28gcmVh Y2hlcyBUVEw9bisxIG9uIGFuDQo+ICAgICAgICAgIExBRyBtZW1iZXIgbGluayAxLg0KPiANCj4g ICAgICAgT25lIG9yIHR3byBNUExTIGVjaG8gcmVxdWVzdCBtZXNzYWdlcyBzZW50IGJ5IHRoZSBp bml0aWF0b3IgTFNSDQo+ICAgICAgIGNhbm5vdCByZWFjaCB0aGUgaW1tZWRpYXRlIGRvd25zdHJl YW0gTFNSLCBvciB0aGUgdHdvIE1QTFMgZWNobw0KPiAgICAgICByZXF1ZXN0IG1lc3NhZ2VzIHJl YWNoIGF0IHRoZSBpbW1lZGlhdGUgZG93bnN0cmVhbSBMU1IgZnJvbSB0aGUNCj4gICAgICAgc2Ft ZSBMQUcgbWVtYmVyIGxpbmsuDQo+IA0KPiBUaGUgZGVzY3JpcHRpb24gcGFyYWdyYXBoIGRvZXNu J3Qgc2VlbSB0byBtYXRjaCB1cCB0aGUgc2NlbmFyaW8gZGVzY3JpYmVkDQo+IGluIHRoZSBzdWIt YnVsbGV0cywgd2hpY2ggbGVhdmVzIG1lIGNvbmZ1c2VkIGFzIHRvIHdoYXQNCj4gc2NlbmFyaW8o cykgYXJlIGludGVuZGVkIHRvIGJlIGNvbnNpZGVyZWQgYXMgdGhlICJlcnJvciBjYXNlIi4NCj4g DQo+IFNlY3Rpb24gNg0KPiANCj4gICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IG9wdGlv bmFsIFRMViB3aGljaCBpcyByZWZlcnJlZCB0byBhcyB0aGUNCj4gICAgIkxTUiBDYXBhYmlsaXR5 IFRMVi4gIFsuLi5dDQo+IA0KPiBJcyB0aGlzIG9wdGlvbmFsIHRvIHVzZSBvciBjb21wcmVoZW5z aW9uLW9wdGlvbmFsPyAgKFdlIGVsc2V3aGVyZSByZWx5IG9uDQo+IGNvbXByZWhlbnNpb24tbWFu ZGF0b3J5IGJlaGF2aW9yLCBzbyBpbiB0aGUgUkZDIDgwMjkgdGVybWlub2xvZ3kgdGhpcw0KPiBz ZWVtcyB0byBiZSBhICJtYW5kYXRvcnkgVExWIiBldmVuIGlmIGl0IGlzIG5vdCBtYW5kYXRvcnkg dG8gdXNlLikNCg0KWWVzLCBpdCdzIGEgIm1hbmRhdG9yeSBUTFYiIGFjY29yZGluZyB0byBSRkM4 MDI5Lg0KDQo+IA0KPiAgICBpbmNsdWRlZCBpbiB0aGUgTVBMUyBlY2hvIHJlcGx5IG1lc3NhZ2Uu ICBPdGhlcndpc2UsIGlmIHRoZSByZXNwb25kZXINCj4gICAgZG9lcyBub3Qga25vdyB0aGUgTFNS IENhcGFiaWxpdHkgVExWLCBhbiBNUExTIGVjaG8gcmVwbHkgd2l0aCB0aGUNCj4gICAgcmV0dXJu IGNvZGUgc2V0IHRvICJPbmUgb3IgbW9yZSBvZiB0aGUgVExWcyB3YXMgbm90IHVuZGVyc3Rvb2Qi IE1VU1QNCj4gICAgYmUgc2VudCBiYWNrIHRvIHRoZSBpbml0aWF0b3IgTFNSLg0KPiANCj4gVGhp cyBkdXBsaWNhdGVzIGEgcmVxdWlyZW1lbnQgc3RhdGVkIGVsc2V3aGVyZSAodGhhdCByZWFsbHkg b3VnaHQgdG8ganVzdCBiZQ0KPiB1c2luZyBleGlzdGluZyByZXF1aXJlZCBiZWhhdmlvciBmcm9t IDgwMjkgYW55d2F5KS4NCg0KT0ssIHdpbGwgdHJ5IHRvIHJlbW92ZSBzb21lIGR1cGxpY2F0ZSB0 ZXh0Lg0KDQo+IA0KPiAgICBMU1IgQ2FwYWJpbGl0eSBUTFYgVHlwZSBpcyBUQkQxLiAgTGVuZ3Ro IGlzIDQuICBUaGUgdmFsdWUgZmllbGQgb2YNCj4gDQo+IEluIGEgaHlwb3RoZXRpY2FsIGZ1dHVy ZSB3aGVyZSB3ZSBuZWVkIHRvIGFsbG9jYXRlIGEgMzNyZCBjYXBhYmlsaXR5IGZsYWcsDQo+IHdv dWxkIHdlIHJhdGhlciBjcmVhdGUgYSBuZXcgImV4dGVuZGVkIGNhcGFiaWxpdGllcyIgVExWIChi dXJuaW5nIGFub3RoZXINCj4gMzIgYml0cyBmb3IgdHlwZStsZW5ndGgpIG9yIGxlYXZlIGZsZXhp YmlsaXR5IG5vdyBmb3IgJ2xlbmd0aCcNCj4gdG8gaW5jcmVhc2UgaW4gbXVsdGlwbGVzIG9mIDQg d2l0aCByZWNlaXZlcnMgaWdub3JpbmcgYml0cyBwYXN0IHdoYXQgdGhleSBrbm93DQo+IGFib3V0 Pw0KDQozMiBzZWVtcyByZWFzb25hYmxlIGVub3VnaCBmb3IgZnV0dXJlIHVzZS4gSWYgdGhlcmUg d2lsbCBiZSBhIDMzcmQgY2FwYWJpbGl0eSBpbiBhIGh5cG90aGV0aWNhbCBmdXR1cmUsIGEgc3Vi LVRMViBtYXkgYmUgY3JlYXRlZCB0aGVuLiANCg0KPiANCj4gICAgICAgVGhlICJMU1IgQ2FwYWJp bGl0eSBGbGFncyIgZmllbGQgaXMgNCBvY3RldHMgaW4gbGVuZ3RoLCB0aGlzDQo+ICAgICAgIGRv Y3VtZW50IGRlZmluZXMgdGhlIGZvbGxvd2luZyBmbGFnczoNCj4gDQo+ICAgICAgIDAgICAgICAg ICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCj4g ICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxDQo+ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgICB8ICAgICAgICAgICAgICAgICAg TXVzdCBCZSBaZXJvIChSZXNlcnZlZCkgICAgICAgICAgICAgICAgICB8VXxEfA0KPiAgICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQo+IA0KPiBJJ20gd2FyeSBvZiBkZXNjcmliaW5nIHRoZXNlIGFzICJNdXN0IEJlIFpl cm8iLCBzaW5jZSB0aGV5J3JlIGp1c3QgdW5hbGxvY2F0ZWQNCj4gYnV0IG5vdCByZXF1aXJlZCB0 byBiZSB6ZXJvIG90aGVyIHRoYW4gYnkgdGhlIGN1cnJlbnQgc3RhdGUgb2YgYml0IGFsbG9jYXRp b25zLg0KPiAoSSBndWVzcyB0aGlzIGlzIGNvbnZlbnRpb25hbCBmb3IgTVBMUywgdGhvdWdoPyAg U28gbWF5YmUgaXQncyBub3QgYSBwcm9ibGVtLikNCj4gSnVzdCAiUmVzZXJ2ZWQiIHdvdWxkIGJl IGZpbmUuDQoNClllcywgaXQncyBjb252ZW50aW9uYWwgZm9yIE1QTFMuIEkgaW5jbGluZSB0byBr ZWVwIGl0IGFzIGlzLg0KDQo+IA0KPiAgICAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdHdvIGZs YWdzLiAgVGhlIHJlbWFpbmluZyBmbGFncyBNVVNUIGJlIHNldA0KPiAgICAgICB0byB6ZXJvIHdo ZW4gc2VuZGluZyBhbmQgaWdub3JlZCBvbiByZWNlaXB0LiAgQm90aCB0aGUgVSBhbmQgdGhlIEQN Cj4gICAgICAgZmxhZyBNVVNUIGJlIGNsZWFyZWQgaW4gdGhlIE1QTFMgZWNobyByZXF1ZXN0IG1l c3NhZ2Ugd2hlbg0KPiAgICAgICBzZW5kaW5nLCBhbmQgaWdub3JlZCBvbiByZWNlaXB0LiAgTmVp dGhlciwgZWl0aGVyIG9yIGJvdGggdGhlIFUNCj4gICAgICAgYW5kIHRoZSBEIGZsYWcgTUFZIGJl IHNldCBpbiB0aGUgTVBMUyBlY2hvIHJlcGx5IG1lc3NhZ2UuDQo+IA0KPiBTaW1pbGFybHksIEkg dGhpbmsgd2Ugd2FudCB0byBzYXkgInVuYWxsb2NhdGVkIGZsYWdzIiByYXRoZXIgdGhhbiAidGhl DQo+IHJlbWFpbmluZyBmbGFncyIuDQoNCk9LLg0KDQo+IA0KPiBJdCBhbHNvIHNlZW1zIGxpa2Ug dGhlIHNlbWFudGljcyBiZWluZyBkZXNjcmliZWQgaGVyZSBhcmUgInRoZSBUTFYgdmFsdWUgaXMN Cj4gaWdub3JlZCBpbiB0aGUgZWNobyByZXF1ZXN0IGFuZCBvbmx5IGhhcyBtZWFuaW5nIGluIHRo ZSByZXNwb25zZSINCj4gKGkuZS4sIHRoaXMgaXMgYSAidGVsbCBtZSB5b3VyIGNhcGFiaWxpdGll cyIgZXhjaGFuZ2UsIG5vdCBhICJoZXJlIGFyZSBtaW5lOyB3aGF0DQo+IGFyZSB5b3Vycz8iIGV4 Y2hhbmdlKS4gIEFzIHdyaXR0ZW4sIHRoYXQgYXBwbGllcyBvbmx5IHRvIHRoZSBVIGFuZCBEIGJp dHMsIGFuZA0KPiBpcyBub3QgYSBnZW5lcmFsIHByb3BlcnR5LiAgVGhhdCBtYXkgd2VsbCBiZSBh IGZpbmUgY2hvaWNlIGlmIHdlIHRoaW5rIHdlIG1pZ2h0DQo+IHdhbnQgdGhlIHR3by13YXkgZXhj aGFuZ2UgZm9yIHNvbWUgZnV0dXJlIGFsbG9jYXRlZCBiaXQsIGJ1dCBpZiB3ZSBkbyB0aGluaw0K PiBpdCdzIGEgZ2VuZXJhbCBwcm9wZXJ0eSBvZiB0aGUgbWVjaGFuaXNtLCBJJ2Qgc3VnZ2VzdCBy ZXdvcmRpbmcgdGhlIHRleHQuDQoNCkZvciBub3csIGl0J3MgZGVzaWduZWQgYXMgdW5pZGlyZWN0 aW9uYWwgY2FwYWJpbGl0aWVzIGFkdmVydGlzZW1lbnQuICBEZWZpbmUgaXQgYXMgYSBtb3JlIGdl bmVyYWwgcHJvcGVydHkgbWF5IHJlcXVpcmUgbW9yZSBjb25zaWRlcmF0aW9ucy4gSSBpbmNsaW5l IHRvIGtlZXAgaXQgYXMtaXMuIFdlIGNhbiBtYWtlIGFuIHVwZGF0ZSBpZiB3ZSBoYXZlIHNvbWUg c3BlY2lmaWMgdXNlIGNhc2UgaW4gdGhlIGZ1dHVyZS4NCg0KPiANCj4gU2VjdGlvbiA3DQo+IA0K PiAoUGVyIElBTkEsIGJpdHMgNCBhbmQgNSBhcmUgYWxyZWFkeSBhc3NpZ25lZCBidXQgYXJlIG5v dCByZWZsZWN0ZWQgaW4gdGhlDQo+IGRpYWdyYW0uKQ0KDQpPSywgd2lsbCBmaXggaXQuDQoNCj4g DQo+IFNlY3Rpb24gMTANCj4gDQo+ICAgIFRoZSBEZXRhaWxlZCBJbnRlcmZhY2UgYW5kIExhYmVs IFN0YWNrIFRMViBmb3JtYXQgaXMgZGVyaXZlZCBmcm9tIHRoZQ0KPiAgICBJbnRlcmZhY2UgYW5k IExhYmVsIFN0YWNrIFRMViBmb3JtYXQgKGZyb20gW1JGQzgwMjldKS4gIFR3byBjaGFuZ2VzDQo+ ICAgIGFyZSBpbnRyb2R1Y2VkLiAgVGhlIGZpcnN0IGlzIHRoYXQgdGhlIGxhYmVsIHN0YWNrIGlz IGNvbnZlcnRlZCBpbnRvDQo+ICAgIGEgc3ViLVRMVi4gIFRoZSBzZWNvbmQgaXMgdGhhdCBhIG5l dyBzdWItVExWIGlzIGFkZGVkIHRvIGRlc2NyaWJlIGFuDQo+ICAgIGludGVyZmFjZSBpbmRleC4g IFRoZXNlIGZpZWxkcyBvZiBEZXRhaWxlZCBJbnRlcmZhY2UgYW5kIExhYmVsIFN0YWNrDQo+ICAg IFRMViBoYXZlIHRoZSBzYW1lIHVzZSBhbmQgbWVhbmluZyBhcyBpbiBbUkZDODAyOV0uICBBIHN1 bW1hcnkgb2YNCj4gICAgdGhlc2UgZmllbGRzIGlzIGFzIGJlbG93Og0KPiANCj4gbml0OiBBcmUg IlRoZXNlIGZpZWxkcyIganVzdCAiVGhlIG90aGVyIGZpZWxkcyI/DQoNCk9LLg0KDQo+IA0KPiAg ICAgICAgICBUaGUgQWRkcmVzcyBUeXBlIGluZGljYXRlcyBpZiB0aGUgaW50ZXJmYWNlIGlzIG51 bWJlcmVkIG9yDQo+ICAgICAgICAgIHVubnVtYmVyZWQuICBJdCBhbHNvIGRldGVybWluZXMgdGhl IGxlbmd0aCBvZiB0aGUgSVAgQWRkcmVzcw0KPiAgICAgICAgICBhbmQgSW50ZXJmYWNlIGZpZWxk cy4gIFRoZSByZXN1bHRpbmcgdG90YWwgbGVuZ3RoIG9mIHRoZQ0KPiAgICAgICAgICBpbml0aWFs IHBhcnQgb2YgdGhlIFRMViBpcyBsaXN0ZWQgYXMgIksgT2N0ZXRzIi4gIFRoZSBBZGRyZXNzDQo+ ICAgICAgICAgIFR5cGUgaXMgc2V0IHRvIG9uZSBvZiB0aGUgZm9sbG93aW5nIHZhbHVlczoNCj4g DQo+IG5pdDogaXMgaXQgYmV0dGVyIHRvIGxpc3QgdGhlIGN1cnJlbnRseSBhbGxvY2F0ZWQgdmFs dWVzIG9yIGp1c3QgcmVmZXIgdG8gdGhlIElBTkENCj4gcmVnaXN0cnk/DQoNCkhlcmUsIGl0IGRv ZXMgbm90IGRlZmluZSBuZXcgcmVnaXN0cnksIGl0IGp1c3QgbGlzdHMgaG93IHRoZSB0aGUgcHVy cG9zZSBpcyB0aGUgDQoNCg0KPiANCj4gSSBzZWVlIHRoYXQgdGhpcyAiaW5kZXggYXNzaWduZWQg dG8gdGhlIGludGVyZmFjZSIgbGFuZ3VhZ2UgZm9yIHVubnVtYmVyZWQNCj4gYWRkcmVzcyB0eXBl cyBvcmlnaW5hdGVzIGZyb20gUkZDIDgwMjksIGJ1dCBib3RoIHRoaXMgZG9jdW1lbnQgYW5kIDgw MjkNCj4gbGVhdmUgbWUgY29uZnVzZWQgYXMgdG8gdGhlIGVuY29kaW5nIHVzZWQgZm9yIHRoaXMg aW5kZXggKGZvciBlaXRoZXIvYm90aA0KPiBJUHY0IG9yIElQdjYgYWRkcmVzcyB0eXBlcykuDQoN Cj4gDQo+IFtNeSBjb21tZW50IGFib3V0ICJNdXN0IEJlIFplcm8iIGFuZCBhbGxvY2F0YWJsZSBi aXRzIGFsc28gYXBwbGllcyBoZXJlXQ0KDQpPSy4gV2lsbCBjaGFuZ2UgdG8gIlJlc2VydmVkIi4N Cg0KPiANCj4gU2VjdGlvbiAxMg0KPiANCj4gVGhpcyBkb2N1bWVudCBhbHNvIGFkZHMgYSBjYXBh YmlsaXR5ICJuZWdvdGlhdGlvbiIgbWVjaGFuaXNtIGZvciBNUExTIGVjaG8NCj4gcmVxdWVzdC9y ZXBseSBleGNoYW5nZXMuICBBcyBNUExTIGRvZXMgbm90IG9mZmVyIGludGVncml0eSBwcm90ZWN0 aW9uIGZvciBpdHMNCj4gbWVzc2FnZXMsIHRoaXMgbmVnb3RpYXRpb24gaXMgb25seSBhcyB0cnVz dHdvcnRoeSBhcyB0aGUgbmV0d29yayBmcm9tIHdoaWNoDQo+IG1lc3NhZ2VzIGFyZSBhY2NlcHRl ZCBhcyB2YWxpZCwgYW5kIGluaXRpYXRvcnMgaGF2ZSBubyByZWNvdXJzZSBidXQgdG8gYWNjZXB0 DQo+IGZhaXRoZnVsbHkgdGhlIGVjaG8gcmVwbGllcyByZWNlaXZlZC4NCj4gDQo+ICAgIFRvIHBy ZXZlbnQgbGVha2FnZSBvZiB2aXRhbCBpbmZvcm1hdGlvbiB0byB1bnRydXN0ZWQgdXNlcnMsIGEN Cj4gICAgcmVzcG9uZGVyIExTUiBNVVNUIG9ubHkgYWNjZXB0IE1QTFMgZWNobyByZXF1ZXN0IG1l c3NhZ2VzIGZyb20NCj4gICAgZGVzaWduYXRlZCB0cnVzdGVkIHNvdXJjZXMgdmlhIGZpbHRlcmlu ZyBzb3VyY2UgSVAgYWRkcmVzcyBmaWVsZCBvZg0KPiAgICByZWNlaXZlZCBNUExTIGVjaG8gcmVx dWVzdCBtZXNzYWdlcy4gIFsuLi5dDQo+IA0KPiBJJ2QgcHJlZmVyIHRvIHNlZSBhIG5vdGUgYWRk ZWQgaGVyZSBhYm91dCBob3cgInNvdXJjZSBJUCBhZGRyZXNzIGZpbHRlcmluZw0KPiBwcm92aWRl cyBvbmx5IGEgd2VhayBmb3JtIG9mIGFjY2VzcyBjb250cm9sIGFuZCBpcyBub3QsIGluIGdlbmVy YWwsIGEgcmVsaWFibGUNCj4gc2VjdXJpdHkgbWVjaGFuaXNtLiAgTm9uZXRoZWxlc3MsIGl0IGlz IHJlcXVpcmVkIGhlcmUgaW4gdGhlIGFic2VuY2Ugb2YgYW55DQo+IG1vcmUgcm9idXN0IG1lY2hh bmlzbSB0aGF0IG1pZ2h0IGJlIHVzZWQuIg0KDQpPSywgd2lsbCBhZGQuDQoNCj4gDQo+IFNlY3Rp b24gMTMNCj4gDQo+IFNob3VsZCB3ZSBhc2sgSUFOQSB0byB1cGRhdGUgdGhlICJJbnRlcmZhY2Ug YW5kIExhYmVsIFN0YWNrIEFkZHJlc3MgVHlwZXMiDQo+IHJlZ2lzdHJ5IHRvIGFsc28gcmVmZXIg dG8gdGhpcyBkb2N1bWVudCwgc2luY2Ugd2UgYXJlIHNoYXJpbmcgdGhlIHJlZ2lzdHJ5DQo+IGJl dHdlZW4gdGhlIEludGVyZmFjZSBhbmQgTGFiZWwgU3RhY2sgVExWIGFuZCB0aGUgRGV0YWlsZWQg dmVyc2lvbj8NCg0KWWVzLg0KDQo+IA0KPiBTZWN0aW9uIDEzLjINCj4gDQo+IFRoZSByYW5nZSA0 LTMxNzQzIHNwYW5zIHR3byBkaWZmZXJlbnQgYWxsb2NhdGlvbiBwcm9jZWR1cmVzIChTdGFuZGFy ZHMNCj4gQWN0aW9uIGFuZCBTcGVjaWZpY2F0aW9uIFJlcXVpcmVkIC0gRXhwZXJpbWVudGFsIFJG QyBuZWVkZWQpOyBJIGFzc3VtZSB0aGF0DQo+IHdlIHdhbnQgdGhlIDQtMTYzODMgcmFuZ2UgZm9y IFN0YW5kYXJkcyBBY3Rpb24gLSBtYW5kYXRvcnkgVExWcy4NCg0KWWVzLg0KDQo+IA0KPiBTZWN0 aW9uIDEzLjQNCj4gDQo+IFdlIGRvbid0IHNheSB3aGF0IHJhbmdlIHdlIHdhbnQgdGhpcyB0byBi ZSBhbGxvY2F0ZWQgZnJvbSAtLSBJIGFzc3VtZQ0KPiA0LTE2MzgzIHNpbmNlIHRoaXMgaXMgYSBu ZWdvdGlhdGVkIGZlYXR1cmUgYW5kIHNlbmRpbmcgaXQgb3V0c2lkZSB0aGUNCj4gbmVnb3RpYXRl ZCBzY2VuYXJpbyBzaG91bGQgYmUgYW4gZXJyb3IuDQoNClllcy4NCg0KDQo+IA0KPiBTZWN0aW9u IDEzLjQuMQ0KPiANCj4gKEkgbm90ZSB0aGF0IHNvbWUgZXhpc3Rpbmcgc3ViLVRMViByZWdpc3Ry aWVzIGhhdmUgIkV4cGVyaW1lbnRhbCBSRkMNCj4gcmVxdWlyZWQiIGZvciB0aGUgZXhwZXJpbWVu dGFsIHJhbmdlcywgYnV0IHRoYXQgaXMgYXJndWFibHkgbW9yZSBzdHJpbmdlbnQNCj4gdGhhbiBu ZWNlc3Nhcnk7IFNwZWNpZmljYXRpb24gUmVxdWlyZWQgc2VlbXMgbW9yZSBhcHByb3ByaWF0ZSBm b3IgdGhpcyBjYXNlLikNCg0KT0suIENoYW5nZSB0byAiU3BlY2lmaWNhdGlvbiBSZXF1aXJlZC4N CiINCj4gDQo+IEFwcGVuZGl4IEENCj4gDQo+IEkgd2FzIGtpbmQgb2YgaG9waW5nIGZvciBzb21l IG1vcmUgZ3VpZGFuY2Ugb24gd2hhdCBhbiBpbml0aWF0b3IgY291bGQgZG8gaW4NCj4gdGhlc2Ug c2NlbmFyaW9zIHRvIHRyeSB0byBnZXQgYmV0dGVyIHZpc2liaWxpdHkgaW50byB0aGUgc3dpdGNo IGJlaGF2aW9yIChhbmQsDQo+IGhvcGVmdWxseSwgYSB3b3JrYXJvdW5kIHRvIGdldCByZWxpYWJs ZSBlY2hvIHJlc3BvbnNlcyB0aGF0IGNvdmVyIGFsbCBMQUcNCj4gbWVtYmVyIGxpbmtzKS4gIEFG QUlDVCB0aGVyZSdzIG5vdCBhIGJldHRlciBvcHRpb24gdGhhbiAidHJ5IGEgYnVuY2ggb2YNCj4g ZW50cm9weSBsYWJlbHMgYW5kIHNlZSB3aGF0IHJlc3BvbnNlcyB5b3UgY2FuIGdldCBiYWNrIiBh bmQgdGhhdCdzIHRoZQ0KPiBzYW1lIHJlbWVkeSBpbiBhbGwgdGhlIGRlc2NyaWJlZCB0b3BvbG9n aWVzLCBidXQgaXQgd291bGQgYmUgbmljZSB0byBoYXZlIHRoaXMNCj4gc3RhdGVkIGV4cGxpY2l0 bHkgZm9yIHRoZSByZWFkZXIuDQoNCkkgYW0gZmluZSB0byBhZGQgc3VjaCBhIG5vdGUgaW4gdGhp cyBzZWN0aW9uIGFzIHlvdSBzdWdnZXN0ZWQsIGhvdyBhYm91dDoNCg0KIk5vdGU6IEFGQUlDVCB0 aGVyZSdzIG5vdCBhIGJldHRlciBvcHRpb24gdGhhbiAidHJ5IGEgYnVuY2ggb2YgZW50cm9weSBs YWJlbHMgYW5kIHNlZSB3aGF0IHJlc3BvbnNlcyB5b3UgY2FuIGdldCBiYWNrIiBhbmQgdGhhdCdz IHRoZSBzYW1lIHJlbWVkeSBpbiBhbGwgdGhlIGRlc2NyaWJlZCB0b3BvbG9naWVzIGJlbG93LiIN Cg0KPiANCj4gU2VjdGlvbiBBLjENCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgSW4gdGhlIHdv cnN0IGNhc2UsIE1QTFMgZWNobyByZXF1ZXN0IG1lc3NhZ2VzIHdpdGgNCj4gICAgc3BlY2lmaWMg ZW50cm9waWVzIHRvIGV4ZXJjaXNlIGV2ZXJ5IExBRyBtZW1iZXJzIGZyb20gUjEgdG8gUzEgY2Fu DQo+ICAgIGFsbCByZWFjaCBSMiB2aWEgc2FtZSBMQUcgbWVtYmVyLiAgWy4uLl0NCj4gDQo+IEkn bSBjb25mdXNlZCBieSB0aGUgcGhyYXNlICJzcGVjaWZpYyBlbnRyb3BpZXMgdG8gZXhlcmNpc2Ug ZXZlcnkgTEFHDQo+IG1lbWJlcnMgW3NpY10gZnJvbSBSMSB0byBTMSIgLS0gaXMgdGhlcmUgc29t ZSBkZXRlcm1pbmlzdGljIGFsZ29yaXRobSBieQ0KPiB3aGljaCBhIHNwZWNpZmljIGVudHJvcHkg bGFiZWwgdmFsdWUgd2lsbCBmb3JjZSBhIHNwZWNpZmljIExBRyBtZW1iZXIgbGluaz8NCg0KTm8s IGF0IGxlYXN0IGZvciBteSB1bmRlcnN0YW5kaW5nLg0KDQo+IE15IHVuZGVyc3RhbmRpbmcgd2Fz IHRoYXQgdGhlIGVudHJvcHkgd2FzIHVzZWQgYXMgaW5wdXQgdG8gYW4gb3BhcXVlIGhhc2gNCj4g ZnVuY3Rpb24gYW5kIHRoYXQgdHJpYWwtYW5kLWVycm9yIHdhcyB0aGUgb25seSB3YXkgdG8gZXhw bG9yZSB0aGUgbWFwcGluZw0KPiBmcm9tIGVudHJvcHkgdmFsdWUgdG8gTEFHIG1lbWJlciBsaW5r IHRha2VuLg0KDQpZZXMsIHdlIGhhdmUgdGhlIHNhbWUgdW5kZXJzdGFuZGluZy4NCg0KDQpUaGFu a3MgYWdhaW4gZm9yIHlvdXIgZGV0YWlsZWQgYW5kIHZhbHVhYmxlIGNvbW1lbnRzIQ0KDQpCZXN0 IHJlZ2FyZHMsDQpNYWNoDQo+IA0KDQo= From nobody Wed Mar 13 01:34:28 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4D41311AB; Wed, 13 Mar 2019 01:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LLrROw422odz; Wed, 13 Mar 2019 01:34:09 -0700 (PDT) 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 2ED35130EDA; Wed, 13 Mar 2019 01:34:09 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 38909A17C55B9605AC10; Wed, 13 Mar 2019 08:34:07 +0000 (GMT) Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 13 Mar 2019 08:34:06 +0000 Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Wed, 13 Mar 2019 08:34:06 +0000 Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Wed, 13 Mar 2019 08:34:06 +0000 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.190]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0415.000; Wed, 13 Mar 2019 16:33:59 +0800 From: Mach Chen To: Benjamin Kaduk via Datatracker , The IESG CC: "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" , "mpls-chairs@ietf.org" , "loa@pi.nu" , "mpls@ietf.org" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with DISCUSS and COMMENT) Thread-Index: AQHU2RJ3vF0A2kVnzkeAK0NcOKNWfKYJJaDw Date: Wed, 13 Mar 2019 08:33:59 +0000 Message-ID: References: <155242263093.20169.3838924661112115545.idtracker@ietfa.amsl.com> In-Reply-To: <155242263093.20169.3838924661112115545.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 08:34:15 -0000 SGkgQmVuamFtaW4sDQoNClRoYW5rcyBmb3IgeW91ciB0aG9yb3VnaCByZXZpZXcgYW5kIGRldGFp bGVkIGNvbW1lbnRzIQ0KDQpQbGVhc2Ugc2VlIG15IHJlcGxpZXMgaW5saW5lLi4uDQoNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW5qYW1pbiBLYWR1ayB2aWEgRGF0 YXRyYWNrZXIgW21haWx0bzpub3JlcGx5QGlldGYub3JnXQ0KPiBTZW50OiBXZWRuZXNkYXksIE1h cmNoIDEzLCAyMDE5IDQ6MzEgQU0NCj4gVG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBD YzogZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLWxhZy1tdWx0aXBhdGhAaWV0Zi5vcmc7IG1wbHMt Y2hhaXJzQGlldGYub3JnOw0KPiBsb2FAcGkubnU7IG1wbHNAaWV0Zi5vcmcNCj4gU3ViamVjdDog QmVuamFtaW4gS2FkdWsncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1sYWct bXVsdGlwYXRoLQ0KPiAwNjogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IEJlbmph bWluIEthZHVrIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0K PiBkcmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctbGFnLW11bHRpcGF0aC0wNjogRGlzY3Vzcw0KPiAN Cj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBh bmQgcmVwbHkgdG8gYWxsIGVtYWlsDQo+IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5k IENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeQ0KPiBwYXJhZ3Jh cGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRm Lm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5m b3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+ IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2Fu IGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtbXBscy1sc3AtcGluZy1sYWctbXVsdGlwYXRoLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFRoYW5rcyBmb3IgdGhp cyBkb2N1bWVudDsgaXQncyBjbGVhcmx5IGdvaW5nIHRvIHByb3ZpZGUgdmFsdWUsIGFuZCBpdCBn aXZlcyBhDQo+IHByZXR0eSB3ZWxsLXJlYWRhYmxlIGRlc2NyaXB0aW9uIG9mIGhvdyB0aGluZ3Mg YXJlIGV4cGVjdGVkIHRvIHdvcmsuICBUaGF0DQoNClRoYW5rcy4NCg0KPiBzYWlkLCB0aGVyZSdz IGEgbnVtYmVyIG9mIGRldGFpbHMgdGhhdCBuZWVkIHRvIGJlIHdvcmtlZCBvdXQgYmVmb3JlDQo+ IHB1YmxpY2F0aW9uLi4uDQoNCk9LLg0KDQo+IA0KPiBUaGlzIGRvY3VtZW50IGhhcyBzaXggbGlz dGVkIGF1dGhvcnM7IHBlciBSRkMgNzMyMiwgZG9jdW1lbnRzIGxpc3RpbmcgbW9yZQ0KPiB0aGFu IGZpdmUgYXV0aG9ycyBhcmUgdW51c3VhbCwgYW5kIHNpeCBpcyBncmVhdGVyIHRoYW4gZml2ZS4g IExldCdzIHRhbGsgYWJvdXQgdGhlDQo+IGF1dGhvciBjb3VudC4NCg0KUGxlYXNlIHJlZmVyIHRv IExvYSdzIGFuc3dlci4NCg0KPiANCj4gIm9wdGlvbmFsIFRMViIgc2VlbXMgdG8gYmUgdXNlZCBp biBNUExTIGNvbnRleHRzIGFzIGEgdGVjaG5pY2FsIHRlcm0gZm9yDQo+ICJjb21wcmVoZW5zaW9u LW9wdGlvbmFsIiwgbm90IGluIHRoZSAib3B0aW9uYWwgdG8gc2VuZCIgc2Vuc2U7IGl0J3MgdGhl DQo+IGNvdW50ZXJwYXJ0IG9mICJtYW5kYXRvcnkgVExWIiwgYW5kIHRoaXMgdGVybWlub2xvZ3kg aXMgZXZlbiBkb2N1bWVudGVkIGluDQo+IHRoZSBNUExTIFRMVnMgcmVnaXN0cnkuICBJdCdzIG15 IHVuZGVyc3RhbmRpbmcgdGhhdCB0aGUgTFNQIENhcGFiaWxpdGllcyBUTFYNCj4gYW5kIHRoZSBE ZXRhaWxlZCBJbnRlcmZhY2UgYW5kIExhYmVsIFN0YWNrIFRMViBhcmUgaW50ZW5kZWQgdG8gYmUN Cj4gY29tcHJlaGVuc2lvbi1yZXF1aXJlZCAoaS5lLiwgIm1hbmRhdG9yeSBUTFZzIiksIGFuZCB0 aHVzIHRoYXQgd2UgbXVzdA0KPiBub3QgdXNlIHRoZSBwaHJhc2UgIm9wdGlvbmFsIFRMViIgaW4g dGhlaXIgZGVzY3JpcHRpb24uDQo+IFRoaXMgd291bGQgYmUgbWFkZSBjbGVhciBpZiB3ZSBsaXN0 ZWQgd2hpY2ggcmFuZ2Ugb2YgdmFsdWVzIHdlIGludGVuZGVkIHRvDQo+IGFsbG9jYXRlIGEgVExW IHR5cGUgZnJvbSwgaW4gdGhlIElBTkEgY29uc2lkZXJhdGlvbnMsIGJ1dCB0aGF0IHJlbWFpbnMN Cj4gdW5zcGVjaWZpZWQgYXQgdGhpcyB0aW1lLg0KDQpHb29kIGNhdGNoIG9uIHRoZSBMU1AgQ2Fw YWJpbGl0aWVzIFRMViwgaXQgc2hvdWxkIGJlIHNwZWNpZmllZCBhcyBhc3NpZ25lZCBmcm9tIHRo ZSByYW5nZSAwLTE2MzgzIGFzIGEgcmVzcG9uc2UgaXMgcmVxdWlyZWQuIFRoZSBUTFYgaXMgb3B0 aW9uYWwsIGFzIG5vdGVkIHRoaXMgcmFuZ2UgYWxzbyBjb3ZlcnMgb3B0aW9uYWwgVExWcyBmb3Ig d2hpY2ggYSByZXNwb25zZSBpcyByZXF1aXJlZC4gUGVyIFJGQzgwMjksIHRoZSBEb3duc3RyZWFt IERldGFpbGVkIE1hcHBpbmcgVExWIHdoaWNoIGlzIHVzZWQgaW4gdGhpcyBSRkMgaXMgYWxzbyBv cHRpb25hbC4NCg0KPiANCj4gSW4gYSBzaW1pbGFyIHZlaW4gKHRoZSAiY29tcHJlaGVuc2lvbi1y ZXF1aXJlZCIgYmVoYXZpb3IpLCB0aGVyZSBhcmUgYSBmZXcNCj4gcGxhY2VzIChTZWN0aW9uIDMg KHR3aWNlKSwgYW5kIFNlY3Rpb24gNjsgYWxzbyBTZWN0aW9uIDMgZm9yIHRoZSBMQUcgRGVzY3Jp cHRpb24NCj4gSW5kaWNhdG9yIGZsYWc7IHNlZSBDT01NRU5UKSB3aGVyZSB3ZSBzdGF0ZSBuZXcg bm9ybWF0aXZlIGxhbmd1YWdlDQo+ICgiTVVTVCIpIHRoYXQgaXMgdW5lbmZvcmNlYWJsZSwgc2lu Y2UgaXQgd291bGQgbmVlZCB0byBhcHBseSB0byBNUExTDQo+IGltcGxlbWVudGF0aW9ucyB0aGF0 IGRvIG5vdCBpbXBsZW1lbnQgdGhpcyBzcGVjaWZpY2F0aW9uLg0KPiBGb3J0dW5hdGVseSwgdGhl IGNvbXByZWhlbnNpb24tcmVxdWlyZWQgVExWIHJhbmdlcyBwcm92aWRlIHRoaXMNCj4gZnVuY3Rp b25hbGl0eSBmb3IgdXMgd2l0aG91dCB0aGUgbmVlZCB0byB1c2Ugbm9ybWF0aXZlIGxhbmd1YWdl Lg0KDQpBZGRyZXNzZWQgd2l0aCB0aGUgQ09NTUVOVCBiZWxvdy4NCg0KPiANCj4gU2VjdGlvbiA0 LjIgaGFzIHNvbWUgY29uZmxpY3RpbmcgIk1VU1QicyBhYm91dCB0aGUgb3JkZXJpbmcvcHJlc2Vu Y2Ugb2YNCj4gc3ViLVRMVnMgaW4gdGhlIERETUFQIFRMViAoc2VlIENPTU1FTlQsIGFuZCBhbHNv IHRoZSAiTUFOREFUT1JZIg0KPiBsYW5nYXVnZSBpbiBGaWd1cmUgMikuDQoNCkFkZHJlc3NlZCB3 aXRoIHRoZSBDT01NRU5UIGJlbG93Lg0KDQo+IA0KPiBJZiBJJ20gcmVhZGluZyBTZWN0aW9uIDUu MS4yIGNvcnJlY3RseSwgdGhlIGRlc2NyaWJlZCBwcm9jZWR1cmUgaXMgb25seQ0KPiBpbnRlbmRl ZCB0byBhcHBseSB3aGVuIHRoZSAiRyIgZmxhZyBpcyBwcmVzZW50IChhcyB3ZWxsIGFzIHRoZSAi SSIgZmxhZywgdGhlDQo+IHJlcXVpcmVtZW50IGZvciB3aGljaCBpcyBleHBsaWNpdGx5IHN0YXRl ZCksIGJ1dCB0aGlzIGlzIG5vdCBleHBsaWNpdGx5IHN0YXRlZC4gIEluDQo+IHBhcnRpY3VsYXIs IHRoZSB0ZXh0IGFzIHdyaXR0ZW4gc2F5cyBpdCBhcHBsaWVzIHRvIGFsbCByZXNwb25kZXJzIHRo YXQNCj4gInVuZGVyc3RhbmQgdGhlIExBRyBEZXNjcmlwdGlvbiBJbmRpY2F0b3IgZmxhZyINCj4g d2l0aCBubyBtZW50aW9uIG9mIHJ1bnRpbWUgY2hlY2sgZm9yIHRoZSBwcmVzZW5jZSBvZiB0aGF0 IGZsYWcuDQoNCkhvdyBhYm91dCBhZGQgYSBzZW50ZW5jZSBhdCB0aGUgYmVnaW5uaW5nIG9mIHRo ZSBzZWN0aW9uOg0KDQoiV2hlbiByZWNlaXZlZCBhbiBlY2hvIHJlcXVlc3Qgd2l0aCB0aGUgIkxB RyBEZXNjcmlwdGlvbiBJbmRpY2F0b3IgZmxhZyIgc2V0LCBhIHJlc3BvbmRlciBMU1IgdGhhdCAu Li4iDQoNCj4gDQo+IEkgYWxzbyB3b3JyeSB0aGF0IFNlY3Rpb25zIDgsIDksIGFuZCAxMCBhcmUg aW5zdWZmaWNpZW50bHkgY2xlYXIgYWJvdXQgdGhlDQo+IGVuY29kaW5nIG9mIHRoZSBpbnRlcmZh Y2UgaW5kZXggdmFsdWUgLS0gaXMgaXQgYW4gaW50ZWdlciBpbiBOQk8sIGFuIG9wYXF1ZQ0KPiBi aXRzdHJpbmcsIG9yIHNvbWV0aGluZyBlbHNlPw0KDQoNCg0KPiANCj4gDQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gQW0gSSByZWFkaW5nIHRoaXMg Y29ycmVjdGx5IHRoYXQgdGhlICJMU1IgQ2FwYWJpbGl0eSBUTFYiIGNyZWF0ZWQgaGVyZSBpcw0K PiBiYXNpY2FsbHkgb25seSBhcHBsaWNhYmxlIHRvIHByb3BlcnRpZXMgb2YgTVBMUyBlY2hvIHJl cXVlc3QvcmVwbHkgZXhjaGFuZ2VzPw0KPiBJZiBzbywgdGhlbiBwZXJoYXBzIHRoZSBtb25pa2Vy ICJMU1IgQ2FwYWJpbGl0eSIgaXMgb3Zlcmx5IGdlbmVyaWMuDQoNCkl0J3MgY3VycmVudGx5IGRl ZmluZWQgZm9yIExTUCBQaW5nLCBidXQgbWF5IGJlIHVzZWQgaW4gYSBtb3JlIGdlbmVyaWMgdXNl LiBJIGluY2xpbmUgdG8ga2VlcCBpdCBhcyBpcy4gDQoNCj4gDQo+IFNlY3Rpb24gMS4yDQo+IA0K PiAgICBvICBMYWJlbCBzd2l0Y2hpbmcgb3ZlciBzb21lIG1lbWJlciBsaW5rcyBvZiB0aGUgTEFH IGlzIHN1Y2Nlc3NmdWwsDQo+ICAgICAgIGJ1dCB3aWxsIGJlIGZhaWxlZCBvdmVyIG90aGVyIG1l bWJlciBsaW5rcyBvZiB0aGUgTEFHLg0KPiANCj4gbml0OiB0aGVyZSdzIHNvbWUgdmVyYiB0ZW5z ZSBpbmNvbnNpc3RlbmN5IGhlcmU7IG1heWJlICJidXQgZmFpbHMgb3ZlciBvdGhlcg0KPiBtZW1i ZXIgbGlua3MiIHdvdWxkIGhlbHAuDQoNCk9LLg0KDQo+IA0KPiBTZWN0aW9uIDINCj4gDQo+ICAg IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbiBvcHRpb25hbCBUTFYgdG8gZGlzY292ZXIgdGhlIGNh cGFiaWxpdGllcyBvZg0KPiAgICBhIHJlc3BvbmRlciBMU1IgYW5kIGV4dGVuc2lvbnMgZm9yIHVz ZSB3aXRoIHRoZSBNUExTIExTUCBQaW5nIGFuZA0KPiANCj4gbml0OiBpcyBpdCBvbmx5IHRoZSAq cmVzcG9uZGVyKiBMU1Igd2UgY2FyZSBhYm91dCwgb3IgYXJlIHRoZXJlIHBvdGVudGlhbGx5DQo+ IGludGVybWVkaWFyaWVzIGluIHBsYXk/DQoNCk9ubHkgdGhlIHJlc3BvbmRlciBMU1Igd2UgY2Fy ZSBhYm91dC4NCg0KPiANCj4gICAgVGhlIHNvbHV0aW9uIGNvbnNpc3RzIG9mIHRoZSBNUExTIGVj aG8gcmVxdWVzdCBjb250YWluaW5nIGEgRERNQVAgVExWDQo+ICAgIGFuZCB0aGUgb3B0aW9uYWwg TFNSIGNhcGFiaWxpdHkgVExWIHRvIGluZGljYXRlIHRoYXQgc2VwYXJhdGUgbG9hZA0KPiANCj4g bml0OiBJcyB0aGlzICJvcHRpb25hbCBjYXBhYmlsaXR5IFRMViIgdGhlIHNhbWUgIm9wdGlvbmFs IFRMViIgdGhhdCB3ZSBhcmUNCj4gZGVmaW5pbmcgaW4gdGhpcyBkb2N1bWVudD8gIElmIHNvLCBj YWxsaW5nIGl0ICJ0aGUgbmV3IG9wdGlvbmFsIExTUiBjYXBhYmlsaXR5Ig0KPiB3b3VsZCBhaWQg Y2xhcml0eS4gIChBbHNvLCB3ZSBzZWVtIHRvIHVzZSBib3RoIHRoZSAiY2FwYWJpbGl0eSIgYW5k DQo+ICJDYXBhYmlsaXR5IiBjYXBpdHpsaWF0aW9ucyBmb3IgZGVzY3JpYmluZyB0aGlzIFRMVi4p DQoNCk9LLCBmaXhlZC4NCiANCj4gDQo+IFNlY3Rpb24gMw0KPiANCj4gICAgQ2FwYWJpbGl0eSBU TFYgaW4gdGhlIE1QTFMgZWNobyByZXF1ZXN0IG1lc3NhZ2UuICBXaGVuIHRoZSByZXNwb25kZXIN Cj4gICAgTFNSIHJlY2VpdmVzIGFuIE1QTFMgZWNobyByZXF1ZXN0IG1lc3NhZ2Ugd2l0aCB0aGUg TFNSIENhcGFiaWxpdHkgVExWDQo+ICAgIGluY2x1ZGVkLCBpZiBpdCBrbm93cyB0aGUgTFNSIENh cGFiaWxpdHkgVExWLCB0aGVuIGl0IE1VU1QgaW5jbHVkZQ0KPiAgICB0aGUgTFNSIENhcGFiaWxp dHkgVExWIGluIHRoZSBNUExTIGVjaG8gcmVwbHkgbWVzc2FnZSB3aXRoIHRoZSBMU1INCj4gICAg Q2FwYWJpbGl0eSBUTFYgZGVzY3JpYmluZyBmZWF0dXJlcyBhbmQgZXh0ZW5zaW9ucyBzdXBwb3J0 ZWQgYnkgdGhlDQo+ICAgIGxvY2FsIExTUi4gIE90aGVyd2lzZSwgYW4gTVBMUyBlY2hvIHJlcGx5 IE1VU1QgYmUgc2VudCBiYWNrIHRvIHRoZQ0KPiAgICBpbml0aWF0b3IgTFNSIHdpdGggdGhlIHJl dHVybiBjb2RlIHNldCB0byAiT25lIG9yIG1vcmUgb2YgdGhlIFRMVnMNCj4gICAgd2FzIG5vdCB1 bmRlcnN0b29kIi4gIFsuLi5dDQo+IA0KPiBUaGlzIGxhc3QgTVVTVCBzZWVtcyBsaWtlIHNvbWV0 aGluZyB0aGF0IHRoaXMgZG9jdW1lbnQgY2Fubm90IG1hbmRhdGUgKGFzDQo+IGl0IGF0dGVtcHRz IHRvIGFwcGx5IHRvIG5vbi1pbXBsZW1lbnRhdGlvbnMgb2YgdGhpcyBkb2N1bWVudCk7IGl0IGNv dWxkIG9ubHkNCj4gd29yayBpZiBpdCB3YXMgYW4gZXhpc3RpbmcgcmVxdWlyZW1lbnQgZnJvbSB0 aGUgY29yZSBNUExTIHNwZWMsIGluIHdoaWNoDQo+IGNhc2UgbG93ZXItY2FzZSAibXVzdCIgaXMg YXBwcm9wcmlhdGUgKHBvc3NpYmx5IHdpdGggc2VjdGlvbiByZWZlcmVuY2UpLg0KDQpPSywgaG93 IGFib3V0IGJlbG93Og0KDQoiT3RoZXJ3aXNlLCBhbiBNUExTIGVjaG8gcmVwbHkgbXVzdCBiZSBz ZW50IGJhY2sgdG8gdGhlIGluaXRpYXRvciBMU1Igd2l0aCB0aGUgcmV0dXJuIGNvZGUgc2V0IHRv ICJPbmUgb3IgbW9yZSBvZiB0aGUgVExWcyB3YXMgbm90IHVuZGVyc3Rvb2QiLCBhY2NvcmRpbmcg dG8gdGhlIHJ1bGVzIGFzIGRlZmluZWQgU2VjdGlvbiAzIG9mIFJGQzgwMjkuIg0KDQo+IA0KPiAg ICBvICBJZiB0aGUgcmVzcG9uZGVyIExTUiBkb2VzIG5vdCB1bmRlcnN0YW5kIHRoZSAiTEFHIERl c2NyaXB0aW9uDQo+ICAgICAgIEluZGljYXRvciBmbGFnIjoNCj4gDQo+ICAgICAgICogIENsZWFy IGJvdGggdGhlICJEb3duc3RyZWFtIExBRyBJbmZvIEFjY29tbW9kYXRpb24gZmxhZyIgYW5kIHRo ZQ0KPiAgICAgICAgICAiVXBzdHJlYW0gTEFHIEluZm8gQWNjb21tb2RhdGlvbiBmbGFnIi4NCj4g DQo+IFNpbWlsYXJseSwgaWYgYW4gTFNSIGRvZXMgbm90IHVuZGVyc3RhbmQgYSBmbGFnLCBpdCBj YW5ub3QgZ2l2ZSBzcGVjaWFsDQo+IHRyZWF0bWVudCB0byBwYWNrZXRzIGNvbnRhaW5pbmcgdGhh dCBmbGFnLiAgKFdoeSBhbiBMU1Igd291bGQgbm90DQo+IHVuZGVyc3RhbmQgYSBmbGFnIGRlZmlu ZWQgaW4gdGhlIHNhbWUgZG9jdW1lbnQgdGhhdCBkZWZpbmVzIHRoZSBDYXBhYmlsaXRpZXMNCj4g VExWIGlzIGJleW9uZCBtZSwgYnV0IHlvdSBzZWVtIHRvIHdhbnQgdG8gYWxsb3cgZm9yIHRoYXQN Cj4gY2FzZS4pDQoNCk9LLCBJIHRoaW5rIGl0J3MgT0sgdG8gcmVtb3ZlIHRoZW0uICANCg0KPiAN Cj4gICAgSWYgdGhlIHJlc3BvbmRlciBkb2VzIG5vdCBrbm93IHRoZSBMU1IgQ2FwYWJpbGl0eSBU TFYsIGFuIE1QTFMgZWNobw0KPiAgICByZXBseSB3aXRoIHRoZSByZXR1cm4gY29kZSBzZXQgdG8g Ik9uZSBvciBtb3JlIG9mIHRoZSBUTFZzIHdhcyBub3QNCj4gICAgdW5kZXJzdG9vZCIgTVVTVCBi ZSBzZW50IGJhY2sgdG8gdGhlIGluaXRpYXRvciBMU1IuDQo+IA0KPiBUaGlzIGR1cGxpY2F0ZXMg dGhlIGNvbnRlbnQgSSBxdW90ZWQgYXQgdGhlIHRvcCBvZiB0aGlzIHNlY3Rpb24ncyBjb21tZW50 cy4NCg0KT0ssIHJlbW92ZSB0aGlzIGR1cGxpY2F0ZSB0ZXh0Lg0KDQo+IA0KPiBTZWN0aW9uIDQu MQ0KPiANCj4gICAgT25jZSB0aGUgaW5pdGlhdG9yIExTUiBrbm93cyB0aGUgY2FwYWJpbGl0aWVz IHRoYXQgYSByZXNwb25kZXINCj4gICAgc3VwcG9ydHMsIHRoZW4gaXQgc2VuZHMgYW4gTVBMUyBl Y2hvIHJlcXVlc3QgY2FycnlpbmcgYSBERE1BUCB3aXRoDQo+ICAgIHRoZSAiTEFHIERlc2NyaXB0 aW9uIEluZGljYXRvciBmbGFnIiAoRykgc2V0IHRvIHRoZSByZXNwb25kZXIgTFNSLg0KPiANCj4g bml0OiBJIHRoaW5rIHRoZSBrZXkgcG9pbnQgaXMgbm90IHRoYXQgdGhlIGluaXRpYXRvciBrbm93 cyB0aGUgY2FwYWJpbGl0aWVzIG9mIHRoZQ0KPiBwZWVyLCBidXQgcmF0aGVyIHRoYXQgdGhlIGlu aXRpYXRvciBrbm93cyB0aGF0IHRoZSBwZWVyIHN1cHBvcnRzIHRoaXMgc3BlY2lmaWMNCj4gbWVj aGFuaXNtLg0KDQpZZXMuDQoNCkhvdyBhYm91dDoNCiJPbmNlIHRoZSBpbml0aWF0b3IgTFNSIGtu b3dzIHRoYXQgYSByZXNwb25kZXIgY2FuIHN1cHBvcnQgdGhpcyBtZWFjaGFuaXNtLCB0aGVuIGl0 IHNlbmRzIGFuIE1QTFMgZWNobyByZXF1ZXN0IGNhcnJ5aW5nIGEgRERNQVAgVExWIHdpdGggIHRo ZSAiTEFHIERlc2NyaXB0aW9uIEluZGljYXRvciBmbGFnIiAoRykgc2V0IHRvIHRoZSByZXNwb25k ZXIgTFNSLiINCg0KDQo+IEFsc28sIGlzIHRoaXMgImEgRERNQVAgVExWIj8NCg0KWWVzLg0KDQo+ IA0KPiBTZWN0aW9uIDQuMg0KPiANCj4gUmVhZGluZyB0aGlzIG1ha2VzIGl0IHNvdW5kIGxpa2Ug dGhlICJMQUcgRGVzY3JpcHRpb24gSW5kaWNhdG9yIGZsYWciIGlzDQo+IGNvbXBsZXRlbHkgb3J0 aG9nb25hbCB0byByZWd1bGFyIERETUFQIGZ1bmN0aW9uYWxpdHksIHNvIHRoYXQgaWYgSSBzZXQg dGhlDQo+IExBRyBkZXNjcmlwdGlvbiBpbmRpY2F0b3IgZmxhZyBidXQgZG8gbm90IG90aGVyd2lz ZSByZXF1ZXN0IGRldGFpbGVkDQo+IGRlc2NyaXB0aW9ucywgb25seSB0aGUgTEFHIGludGVyZmFj ZXMgYXJlIHJldHVybmVkLiAgSG93ZXZlciwgdGhlIGZsYWcgaW4NCj4gcXVlc3Rpb24gaGFzIHRv IGJlIGluc2lkZSBhIERETUFQIFRMViAoYW5kIHdlIHNob3VsZCByZWFsbHkgc2F5IHNvLCBwZXJo YXBzDQo+IGFzICJbZmxhZ10gc2V0ICppbiB0aGUgRERNQVAgVExWKiIhKSwgc28gaXQgc2VlbXMg bGlrZSBpbiBwcmFjdGljZSB0aGUgTEFHDQo+IGluZm9ybWF0aW9uIGNhbiBvbmx5IGJlIG9idGFp bmVkIGluIGNvbmp1bmN0aW9uIHdpdGggZnVsbCBkZXRhaWxlZCBkZXNjcmlwdGlvbg0KPiBpbmZv cm1hdGlvbi4gIChUaGUgc3BlY2lmaWMgc3VnZ2VzdGlvbiBoZXJlIGlzIHRvIG5vdGUgY2xlYXJs eSB0aGF0IHRoZSBmbGFnIGlzIHNlDQo+IGluIHRoZSBERE1BUCBUTFYuKQ0KDQpGaXhlZC4NCg0K PiANCj4gICAgICAgKiAgVGhlIHJlc3BvbmRlciBMU1IgTVVTVCBpbmNsdWRlIGEgRERNQVAgVExW IHdoZW4gc2VuZGluZyB0aGUNCj4gICAgICAgICAgTVBMUyBlY2hvIHJlcGx5Lg0KPiANCj4gSSBn b3QgY29uZnVzZWQgb24gbXkgZmlyc3QgcGFzcyB0aHJvdWdoIHRoaXMgc2VjdGlvbjsgYWRkaW5n ICJUaGVyZSBpcyBhIHNpbmdsZQ0KPiBERE1BUCBUTFYgZm9yIHRoZSBMQUcgaW50ZXJmYWNlLCB3 aXRoIG1lbWJlciBsaW5rcyBkZXNjcmliZWQgdXNpbmcgc3ViLQ0KPiBUTFZzIiBoZXJlIHdvdWxk IGhhdmUga2VwdCBtZSBmcm9tIHZlZXJpbmcgb250byB0aGUgd3JvbmcgcGF0aC4NCj4gKEkgdGhv dWdodCB0aGVyZSB3YXMgZ29pbmcgdG8gYmUgb25lIERETUFQIFRMViBwZXIgbWVtYmVyIGxpbmss IHBsdXMgb25lDQo+IGZvciB0aGUgTEFHIGFnZ3JlZ2F0ZSwgd2l0aCBsb3RzIG9mIGR1cGxpY2F0 aW9uLikNCg0KU3VyZSwgYWRkZWQuDQoNCj4gDQo+ICAgIEJhc2VkIG9uIHRoZSBwcm9jZWR1cmVz IGRlc2NyaWJlZCBhYm92ZSwgZXZlcnkgTEFHIG1lbWJlciBsaW5rIHdpbGwNCj4gICAgaGF2ZSBh IExvY2FsIEludGVyZmFjZSBJbmRleCBTdWItVExWIGFuZCBhIE11bHRpcGF0aCBEYXRhIFN1Yi1U TFYNCj4gICAgZW50cmllcyBpbiB0aGUgRERNQVAgVExWLiAgVGhlIG9yZGVyIG9mIHRoZSBTdWIt VExWcyBpbiB0aGUgRERNQVAgVExWDQo+ICAgIGZvciBhIExBRyBtZW1iZXIgbGluayBNVVNUIGJl IExvY2FsIEludGVyZmFjZSBJbmRleCBTdWItVExWDQo+ICAgIGltbWVkaWF0ZWx5IGZvbGxvd2Vk IGJ5IE11bHRpcGF0aCBEYXRhIFN1Yi1UTFYuICBBIExBRyBtZW1iZXIgbGluaw0KPiAgICBNQVkg YWxzbyBoYXZlIGEgY29ycmVzcG9uZGluZyBSZW1vdGUgSW50ZXJmYWNlIEluZGV4IFN1Yi1UTFYu ICBXaGVuIGENCj4gICAgTG9jYWwgSW50ZXJmYWNlIEluZGV4IFN1Yi1UTFYsIGEgUmVtb3RlIElu dGVyZmFjZSBJbmRleC1TdWItVExWIGFuZCBhDQo+ICAgIE11bHRpcGF0aCBEYXRhIFN1Yi1UTFYg YXJlIHBsYWNlZCBpbiB0aGUgRERNQVAgVExWIHRvIGRlc2NyaWJlIGEgTEFHDQo+ICAgIG1lbWJl ciBsaW5rLCB0aGV5IE1VU1QgYmUgcGxhY2VkIGluIHRoZSBvcmRlciBvZiBMb2NhbCBJbnRlcmZh Y2UNCj4gICAgSW5kZXggU3ViLVRMViwgUmVtb3RlIEludGVyZmFjZSBJbmRleC1TdWItVExWIGFu ZCBNdWx0aXBhdGggRGF0YSBTdWItDQo+ICAgIFRMVi4NCj4gDQo+IFRoaXMgbGFzdCBNVVNUIGNv bnRyYWRpY3RzIHRoZSBwcmV2aW91cyBNVVNULiAgSSBzdWdnZXN0IHNvbWUgbW9yZSB0ZXh0IHRv DQo+IGNsYXJpZnkgdW5kZXIgd2hpY2ggY29uZGl0aW9ucyBlYWNoIHJlcXVpcmVtZW50IGFwcGxp ZXMuDQoNCk9LLCBhZGRlZC4NCg0KPiANCj4gSSdkIGFsc28gc3VnZ2VzdCBub3QgdXNpbmcgdGhl IGZpZ3VyZSBmb3IgY29udmV5aW5nIGEgKGFwcGFyZW50PykgbWFuZGF0b3J5DQo+IHJlcXVpcmVt ZW50LCBhbmQgaW5zdGVhZCBhZGRpbmcgc29tZSB0ZXh0IGF0IHRoZSBlbmQ6ICJUaGUgYmxvY2sg b2YgbG9jYWwNCj4gaW50ZXJmYWNlIGluZGV4LCAob3B0aW9uYWwgcmVtb3RlIGludGVyZmFjZSBp bmRleCkgYW5kIG11bHRpcGF0aCBkYXRhIHN1Yi0NCj4gVExWcyBmb3IgZWFjaCBtZW1iZXIgbGlu ayBNVVNUIGFwcGVhciBhZGphY2VudCB0byBlYWNoIG90aGVyIGluIG9yZGVyIG9mDQo+IGluY3Jl YXNpbmcgbG9jYWwgaW50ZXJmYWNlIGluZGV4LiINCg0KT0ssIGFkZGVkLg0KDQo+IA0KPiBJdCdz IGNvbmZ1c2luZyB0byBsYWJlbCB0aGUgbXVsdGlwbGF0aCBkYXRhIHN1Yi1UTFYgYXMgIk1BTkRB VE9SWSIgd2hlbg0KPiB0aGUgYm9keSB0ZXh0IHNheXMgIk1VU1QgYWRkIGFuIFtzaWNdIE11bHRp cGF0aCBkYXRhIFN1Yi1UTFYgWy4uLl0gaWYgdGhlDQo+IHJlY2VpdmVkIERETUFQIFRMViByZXF1 ZXN0ZWQgbXVsdGlwYXRoIGluZm9ybWF0aW9uIiwgaS5lLiwgaXQgaXMgbm90IGFsd2F5cw0KPiBw cmVzZW50LCBiYXNlZCBvbiB0aGUgY29udGVudHMgb2YgdGhlIGVjaG8gcmVxdWVzdC4NCg0KU2lu Y2UgaXQncyBqdXN0IGFuIGV4YW1wbGUgaGVyZSwgd2lsbCByZW1vdmUgdGhlIE1BTkRBVE9SWSBh bmQgT1BUSU9OQUwuIA0KPiANCj4gICAgV2hlbiBub25lIG9mIHRoZSByZWNlaXZlZCBtdWx0aXBh dGggaW5mb3JtYXRpb24gbWFwcyB0byBhIHBhcnRpY3VsYXINCj4gICAgTEFHIG1lbWJlciBsaW5r LCB0aGVuIHRoZSByZXNwb25kZXIgTFNSIE1VU1Qgc3RpbGwgcGxhY2UgdGhlIExvY2FsDQo+ICAg IEludGVyZmFjZSBJbmRleCBTdWItVExWIGFuZCB0aGUgTXVsdGlwYXRoIERhdGEgU3ViLVRMViBm b3IgdGhhdCBMQUcNCj4gICAgbWVtYmVyIGxpbmsgaW4gdGhlIERETUFQIFRMViwgdGhlIHZhbHVl IG9mIE11bHRpcGF0aCBMZW5ndGggZmllbGQgb2YNCj4gICAgdGhlIE11bHRpcGF0aCBEYXRhIFN1 Yi1UTFYgaXMgc2V0IHRvIHplcm8uDQo+IA0KPiBuaXQ6IHRoZSBsYXN0IGNvbW1hIGlzIGEgY29t bWEgc3BsaWNlLg0KDQpPSy4NCg0KPiANCj4gU2VjdGlvbiA1LjEuMg0KPiANCj4gSXQgc2VlbXMg bGlrZSB0aGlzIHBsYWNlcyBhIHNsaWdodGx5IHN0cm9uZ2VyIGJ1cmRlbiBvbiB0aGUgcmVzcG9u ZGVyIHRoYW4NCj4gc3RvY2sgODAyOSBkb2VzLCBpbiB0aGF0IHRoZXJlIGlzIGEgTVVTVC1sZXZl bCByZXF1aXJlbWVudCB0byBhY3Qgb24gdGhlICdJJw0KPiBmbGFnIGluIGNvbWJpbmF0aW9uIHdp dGggdGhlICdHJyBmbGFnLCB3aGVyZWFzIGZvciB0aGUgJ0knDQo+IGZsYWcgYWxvbmUgODAyOSBv bmx5IGhhcyBhIFNIT1VMRC1sZXZlbCByZXF1aXJlbWVudCB0byByZXNwb25kIGFjY29yZGluZ2x5 Lg0KPiBXZSBtYXkgd2FudCB0byBjYWxsIHRoaXMgb3V0IGFzIGEgY2hhbmdlIGluIGJlaGF2aW9y Lg0KDQpXaWxsIGNoYW5nZSB0byAiU0hPVUxEIiwgdGhlbiBpdCBjYW4gYWxpZ24gd2l0aCBSRkM4 MDI5Lg0KDQo+IA0KPiBTZWN0aW9uIDUuMS4zDQo+IA0KPiAgICBFeHBlY3RhdGlvbiBpcyB0aGF0 IHRoZXJlJ3MgYSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgaW50ZXJmYWNlDQo+ICAgIGluZGV4 IG9mIHRoZSBvdXRnb2luZyBMQUcgbWVtYmVyIGxpbmsgYXQgVFRMPW4gYW5kIHRoZSBpbnRlcmZh Y2UNCj4gICAgaW5kZXggb2YgdGhlIGluY29taW5nIExBRyBtZW1iZXIgbGluayBhdCBUVEw9bisx IGZvciBhbGwgZGlzY292ZXJlZA0KPiAgICBlbnRyb3BpZXMuICBJbiBvdGhlciB3b3Jkcywgc2V0 IG9mIGVudHJvcGllcyB0aGF0IGxvYWQgYmFsYW5jZXMgdG8NCj4gDQo+IG5pdDogIlRoZSBleHBl Y3RhdGlvbiINCg0KRml4ZWQuDQoNCj4gbml0OiAiZGlzY292ZXJlZCBlbnRyb3BpZXMiIGlzIGEg c3RyYW5nZSB3b3JkaW5nIGdpdmVuIGhvdyB0aGUgZW50cm9weSBsYWJlbA0KPiB3b3JrczsgaXMg dGhpcyBtb3JlIGxpa2UgImFsbCBlbnRyb3BpZXMgZXhhbWluZWQiPw0KDQpPSywgY2hhbmdlIHRv ICJhbGwgZW50cm9waWVzIGV4YW1pbmVkIi4NCg0KPiANCj4gDQo+ICAgIFRoZSBpbml0aWF0b3Ig TFNSIHNlbmRzIHR3byBNUExTIGVjaG8gcmVxdWVzdCBtZXNzYWdlcyB0byB0cmF2ZXJzZQ0KPiAg ICB0aGUgdHdvIExBRyBtZW1iZXIgbGlua3MgYXQgVFRMPW4rMToNCj4gDQo+IEhvdyBkb2VzIHRo ZSBpbml0aWF0b3Iga25vdyAod2hpY2ggZW50cm9weSBsYWJlbCB2YWx1ZXM/KSB0byBnZXQgdGhl IGVjaG8NCj4gcmVxdWVzdHMgdG8gdHJhdmVyc2UgZGlmZmVyZW50IG1lbWJlciBsaW5rcz8NCg0K VGhlIGluaXRpYXRvciBjYW5ub3QgZXhhY3RseSBrbm93IHdoaWNoIGVudHJvcHkgbGFiZWwgdmFs dWVzIGFyZSB3b3JrYWJsZS4gUHJlc3VtYWJseSwgdGhlIGluaXRpYXRvciBjYW4gc2V0IGRpZmZl cmVudCB2YWx1ZXMgYWNjb3JkaW5nIHRvIHRoZSBudW1iZXIgb2YgbWVtYmVyIGxpbmtzLCB0aGVu IHRoZSByZXNwb25kZXIgY2FuIHVzZSBlbnRyb3B5IHZhbHVlcyBmb3IgaGFzaCB0byB0cmF2ZXJz ZSBkaWZmZXJlbnQgbWVtYmVyIGxpbmsuIFRoaXMgaXMgbGVmdCB0byBpbXBsZW1lbnRhdGlvbi4g DQoNCj4gDQo+ICAgIG8gIEVycm9yIGNhc2U6DQo+IA0KPiAgICAgICAqICBPbmUgTVBMUyBlY2hv IHJlcXVlc3QgbWVzc2FnZSByZWFjaGVzIFRUTD1uKzEgb24gYW4gTEFHIG1lbWJlcg0KPiAgICAg ICAgICBsaW5rIDEuDQo+IA0KPiAgICAgICAqICBUaGUgb3RoZXIgTVBMUyBlY2hvIHJlcXVlc3Qg bWVzc2FnZSBhbHNvIHJlYWNoZXMgVFRMPW4rMSBvbiBhbg0KPiAgICAgICAgICBMQUcgbWVtYmVy IGxpbmsgMS4NCj4gDQo+ICAgICAgIE9uZSBvciB0d28gTVBMUyBlY2hvIHJlcXVlc3QgbWVzc2Fn ZXMgc2VudCBieSB0aGUgaW5pdGlhdG9yIExTUg0KPiAgICAgICBjYW5ub3QgcmVhY2ggdGhlIGlt bWVkaWF0ZSBkb3duc3RyZWFtIExTUiwgb3IgdGhlIHR3byBNUExTIGVjaG8NCj4gICAgICAgcmVx dWVzdCBtZXNzYWdlcyByZWFjaCBhdCB0aGUgaW1tZWRpYXRlIGRvd25zdHJlYW0gTFNSIGZyb20g dGhlDQo+ICAgICAgIHNhbWUgTEFHIG1lbWJlciBsaW5rLg0KPiANCj4gVGhlIGRlc2NyaXB0aW9u IHBhcmFncmFwaCBkb2Vzbid0IHNlZW0gdG8gbWF0Y2ggdXAgdGhlIHNjZW5hcmlvIGRlc2NyaWJl ZA0KPiBpbiB0aGUgc3ViLWJ1bGxldHMsIHdoaWNoIGxlYXZlcyBtZSBjb25mdXNlZCBhcyB0byB3 aGF0DQo+IHNjZW5hcmlvKHMpIGFyZSBpbnRlbmRlZCB0byBiZSBjb25zaWRlcmVkIGFzIHRoZSAi ZXJyb3IgY2FzZSIuDQoNClRoZSBzdWItYnVsbGV0cyBhcmUgbm90IGNvbXBsZXRlLCB3aWxsIGFk ZCBhIHRoaXJkIHN1Yi1idWxsZXQgYXMgYmVsb3c6DQoNCiJPbmUgb3IgYm90aCBNUExTIGVjaG8g cmVxdWVzdCBtZXNzYWdlcyBjYW5ub3QgcmVhY2ggdGhlIGltbWVkaWF0ZSBkb3duc3RyZWFtIExT UiBvbiB3aGljaGV2ZXIgbGluay4iDQoNCj4gDQo+IFNlY3Rpb24gNg0KPiANCj4gICAgVGhpcyBk b2N1bWVudCBkZWZpbmVzIGEgbmV3IG9wdGlvbmFsIFRMViB3aGljaCBpcyByZWZlcnJlZCB0byBh cyB0aGUNCj4gICAgIkxTUiBDYXBhYmlsaXR5IFRMVi4gIFsuLi5dDQo+IA0KPiBJcyB0aGlzIG9w dGlvbmFsIHRvIHVzZSBvciBjb21wcmVoZW5zaW9uLW9wdGlvbmFsPyAgKFdlIGVsc2V3aGVyZSBy ZWx5IG9uDQo+IGNvbXByZWhlbnNpb24tbWFuZGF0b3J5IGJlaGF2aW9yLCBzbyBpbiB0aGUgUkZD IDgwMjkgdGVybWlub2xvZ3kgdGhpcw0KPiBzZWVtcyB0byBiZSBhICJtYW5kYXRvcnkgVExWIiBl dmVuIGlmIGl0IGlzIG5vdCBtYW5kYXRvcnkgdG8gdXNlLikNCg0KSXQncyAibWFuZGF0b3J5IFRM ViIgYWNjb3JkaW5nIHRvIFJGQzgwMjkuDQoNCj4gDQo+ICAgIGluY2x1ZGVkIGluIHRoZSBNUExT IGVjaG8gcmVwbHkgbWVzc2FnZS4gIE90aGVyd2lzZSwgaWYgdGhlIHJlc3BvbmRlcg0KPiAgICBk b2VzIG5vdCBrbm93IHRoZSBMU1IgQ2FwYWJpbGl0eSBUTFYsIGFuIE1QTFMgZWNobyByZXBseSB3 aXRoIHRoZQ0KPiAgICByZXR1cm4gY29kZSBzZXQgdG8gIk9uZSBvciBtb3JlIG9mIHRoZSBUTFZz IHdhcyBub3QgdW5kZXJzdG9vZCIgTVVTVA0KPiAgICBiZSBzZW50IGJhY2sgdG8gdGhlIGluaXRp YXRvciBMU1IuDQo+IA0KPiBUaGlzIGR1cGxpY2F0ZXMgYSByZXF1aXJlbWVudCBzdGF0ZWQgZWxz ZXdoZXJlICh0aGF0IHJlYWxseSBvdWdodCB0byBqdXN0IGJlDQo+IHVzaW5nIGV4aXN0aW5nIHJl cXVpcmVkIGJlaGF2aW9yIGZyb20gODAyOSBhbnl3YXkpLg0KDQpSZW1vdmUgaXQuDQoNCj4gDQo+ ICAgIExTUiBDYXBhYmlsaXR5IFRMViBUeXBlIGlzIFRCRDEuICBMZW5ndGggaXMgNC4gIFRoZSB2 YWx1ZSBmaWVsZCBvZg0KPiANCj4gSW4gYSBoeXBvdGhldGljYWwgZnV0dXJlIHdoZXJlIHdlIG5l ZWQgdG8gYWxsb2NhdGUgYSAzM3JkIGNhcGFiaWxpdHkgZmxhZywNCj4gd291bGQgd2UgcmF0aGVy IGNyZWF0ZSBhIG5ldyAiZXh0ZW5kZWQgY2FwYWJpbGl0aWVzIiBUTFYgKGJ1cm5pbmcgYW5vdGhl cg0KPiAzMiBiaXRzIGZvciB0eXBlK2xlbmd0aCkgb3IgbGVhdmUgZmxleGliaWxpdHkgbm93IGZv ciAnbGVuZ3RoJw0KPiB0byBpbmNyZWFzZSBpbiBtdWx0aXBsZXMgb2YgNCB3aXRoIHJlY2VpdmVy cyBpZ25vcmluZyBiaXRzIHBhc3Qgd2hhdCB0aGV5IGtub3cNCj4gYWJvdXQ/DQoNCklNSE8sIDMy IGJpdCBzZWVtcyByZWFzb25hYmxlIGVub3VnaCBmb3IgbWUuIEkgaW5jbGluZSB0byBrZWVwIHRo ZSBmbGFnIGZpZWxkIGFzIGEgZml4ZWQgbGVuZ3RoLg0KDQpJZiB3ZSB3YW50IGl0IGJlIGV4dGVu c2libGUsIG1heWJlIHdlIGNvdWxkIGFkZCBvcHRpb25hbCBzdWItVExWcyB0byB0aGlzIFRMVi4N Cg0KPiANCj4gICAgICAgVGhlICJMU1IgQ2FwYWJpbGl0eSBGbGFncyIgZmllbGQgaXMgNCBvY3Rl dHMgaW4gbGVuZ3RoLCB0aGlzDQo+ICAgICAgIGRvY3VtZW50IGRlZmluZXMgdGhlIGZvbGxvd2lu ZyBmbGFnczoNCj4gDQo+ICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAg ICAgICAyICAgICAgICAgICAgICAgICAgIDMNCj4gICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQo+ICAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCj4gICAgICB8ICAgICAgICAgICAgICAgICAgTXVzdCBCZSBaZXJvIChSZXNlcnZlZCkgICAg ICAgICAgICAgICAgICB8VXxEfA0KPiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IA0KPiBJJ20gd2FyeSBvZiBk ZXNjcmliaW5nIHRoZXNlIGFzICJNdXN0IEJlIFplcm8iLCBzaW5jZSB0aGV5J3JlIGp1c3QgdW5h bGxvY2F0ZWQNCj4gYnV0IG5vdCByZXF1aXJlZCB0byBiZSB6ZXJvIG90aGVyIHRoYW4gYnkgdGhl IGN1cnJlbnQgc3RhdGUgb2YgYml0IGFsbG9jYXRpb25zLg0KPiAoSSBndWVzcyB0aGlzIGlzIGNv bnZlbnRpb25hbCBmb3IgTVBMUywgdGhvdWdoPyAgU28gbWF5YmUgaXQncyBub3QgYSBwcm9ibGVt LikNCj4gSnVzdCAiUmVzZXJ2ZWQiIHdvdWxkIGJlIGZpbmUuDQoNCk9LLiBDaGFuZ2UgdG8gIlJl c2VydmVkIi4NCg0KPiANCj4gICAgICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHR3byBmbGFncy4g IFRoZSByZW1haW5pbmcgZmxhZ3MgTVVTVCBiZSBzZXQNCj4gICAgICAgdG8gemVybyB3aGVuIHNl bmRpbmcgYW5kIGlnbm9yZWQgb24gcmVjZWlwdC4gIEJvdGggdGhlIFUgYW5kIHRoZSBEDQo+ICAg ICAgIGZsYWcgTVVTVCBiZSBjbGVhcmVkIGluIHRoZSBNUExTIGVjaG8gcmVxdWVzdCBtZXNzYWdl IHdoZW4NCj4gICAgICAgc2VuZGluZywgYW5kIGlnbm9yZWQgb24gcmVjZWlwdC4gIE5laXRoZXIs IGVpdGhlciBvciBib3RoIHRoZSBVDQo+ICAgICAgIGFuZCB0aGUgRCBmbGFnIE1BWSBiZSBzZXQg aW4gdGhlIE1QTFMgZWNobyByZXBseSBtZXNzYWdlLg0KPiANCj4gU2ltaWxhcmx5LCBJIHRoaW5r IHdlIHdhbnQgdG8gc2F5ICJ1bmFsbG9jYXRlZCBmbGFncyIgcmF0aGVyIHRoYW4gInRoZQ0KPiBy ZW1haW5pbmcgZmxhZ3MiLg0KDQpGaXhlZC4NCg0KPiANCj4gSXQgYWxzbyBzZWVtcyBsaWtlIHRo ZSBzZW1hbnRpY3MgYmVpbmcgZGVzY3JpYmVkIGhlcmUgYXJlICJ0aGUgVExWIHZhbHVlIGlzDQo+ IGlnbm9yZWQgaW4gdGhlIGVjaG8gcmVxdWVzdCBhbmQgb25seSBoYXMgbWVhbmluZyBpbiB0aGUg cmVzcG9uc2UiDQo+IChpLmUuLCB0aGlzIGlzIGEgInRlbGwgbWUgeW91ciBjYXBhYmlsaXRpZXMi IGV4Y2hhbmdlLCBub3QgYSAiaGVyZSBhcmUgbWluZTsgd2hhdA0KPiBhcmUgeW91cnM/IiBleGNo YW5nZSkuICBBcyB3cml0dGVuLCB0aGF0IGFwcGxpZXMgb25seSB0byB0aGUgVSBhbmQgRCBiaXRz LCBhbmQNCj4gaXMgbm90IGEgZ2VuZXJhbCBwcm9wZXJ0eS4gIFRoYXQgbWF5IHdlbGwgYmUgYSBm aW5lIGNob2ljZSBpZiB3ZSB0aGluayB3ZSBtaWdodA0KPiB3YW50IHRoZSB0d28td2F5IGV4Y2hh bmdlIGZvciBzb21lIGZ1dHVyZSBhbGxvY2F0ZWQgYml0LCBidXQgaWYgd2UgZG8gdGhpbmsNCj4g aXQncyBhIGdlbmVyYWwgcHJvcGVydHkgb2YgdGhlIG1lY2hhbmlzbSwgSSdkIHN1Z2dlc3QgcmV3 b3JkaW5nIHRoZSB0ZXh0Lg0KDQpJdCdzIGRlc2lnbmVkIGFzIGFuIHVuaWRpcmVjdGlvbmFsIHRv b2wsIG1ha2UgaXQgYSB0d28td2F5IGV4Y2hhbmdlIG1lY2hhbmlzbSB3aWxsIHJlcXVpcmUgbW9y ZSBjb25zaWRlcmF0aW9ucyBhbmQgc3Vic3RhbnRpYWwgY2hhbmdlcyB0byBkcmFmdC4gIFNvLCBJ IGlubGluZSB0byBrZWVwIGl0IGFzLWlzLiBJZiB3ZSBoYXZlIHN1Y2ggdXNlIGNhc2UgaW4gdGhl IGZ1dHVyZSwgd2UgdXBkYXRlIHRoaXMgbWVjaGFuaXNtIHRoZW4uDQoNCj4gDQo+IFNlY3Rpb24g Nw0KPiANCj4gKFBlciBJQU5BLCBiaXRzIDQgYW5kIDUgYXJlIGFscmVhZHkgYXNzaWduZWQgYnV0 IGFyZSBub3QgcmVmbGVjdGVkIGluIHRoZQ0KPiBkaWFncmFtLikNCg0KRml4ZWQuDQoNCj4gDQo+ IFNlY3Rpb24gMTANCj4gDQo+ICAgIFRoZSBEZXRhaWxlZCBJbnRlcmZhY2UgYW5kIExhYmVsIFN0 YWNrIFRMViBmb3JtYXQgaXMgZGVyaXZlZCBmcm9tIHRoZQ0KPiAgICBJbnRlcmZhY2UgYW5kIExh YmVsIFN0YWNrIFRMViBmb3JtYXQgKGZyb20gW1JGQzgwMjldKS4gIFR3byBjaGFuZ2VzDQo+ICAg IGFyZSBpbnRyb2R1Y2VkLiAgVGhlIGZpcnN0IGlzIHRoYXQgdGhlIGxhYmVsIHN0YWNrIGlzIGNv bnZlcnRlZCBpbnRvDQo+ICAgIGEgc3ViLVRMVi4gIFRoZSBzZWNvbmQgaXMgdGhhdCBhIG5ldyBz dWItVExWIGlzIGFkZGVkIHRvIGRlc2NyaWJlIGFuDQo+ICAgIGludGVyZmFjZSBpbmRleC4gIFRo ZXNlIGZpZWxkcyBvZiBEZXRhaWxlZCBJbnRlcmZhY2UgYW5kIExhYmVsIFN0YWNrDQo+ICAgIFRM ViBoYXZlIHRoZSBzYW1lIHVzZSBhbmQgbWVhbmluZyBhcyBpbiBbUkZDODAyOV0uICBBIHN1bW1h cnkgb2YNCj4gICAgdGhlc2UgZmllbGRzIGlzIGFzIGJlbG93Og0KPiANCj4gbml0OiBBcmUgIlRo ZXNlIGZpZWxkcyIganVzdCAiVGhlIG90aGVyIGZpZWxkcyI/DQoNCg0KRml4ZWQuDQoNCj4gDQo+ ICAgICAgICAgIFRoZSBBZGRyZXNzIFR5cGUgaW5kaWNhdGVzIGlmIHRoZSBpbnRlcmZhY2UgaXMg bnVtYmVyZWQgb3INCj4gICAgICAgICAgdW5udW1iZXJlZC4gIEl0IGFsc28gZGV0ZXJtaW5lcyB0 aGUgbGVuZ3RoIG9mIHRoZSBJUCBBZGRyZXNzDQo+ICAgICAgICAgIGFuZCBJbnRlcmZhY2UgZmll bGRzLiAgVGhlIHJlc3VsdGluZyB0b3RhbCBsZW5ndGggb2YgdGhlDQo+ICAgICAgICAgIGluaXRp YWwgcGFydCBvZiB0aGUgVExWIGlzIGxpc3RlZCBhcyAiSyBPY3RldHMiLiAgVGhlIEFkZHJlc3MN Cj4gICAgICAgICAgVHlwZSBpcyBzZXQgdG8gb25lIG9mIHRoZSBmb2xsb3dpbmcgdmFsdWVzOg0K PiANCj4gbml0OiBpcyBpdCBiZXR0ZXIgdG8gbGlzdCB0aGUgY3VycmVudGx5IGFsbG9jYXRlZCB2 YWx1ZXMgb3IganVzdCByZWZlciB0byB0aGUgSUFOQQ0KPiByZWdpc3RyeT8NCg0KU2luY2UgaGVy ZSBpdCBhbHNvIGluY2x1ZGUgdGhlIGxlbmd0aCBmaWVsZC4gSSdkIGxpa2UgdG8ga2VlcCBpdCBi b3RoIGhlcmUgYW5kIHRoZSBJQU5BIHJlZ2lzdHJ5Lg0KDQo+IA0KPiBJIHNlZWUgdGhhdCB0aGlz ICJpbmRleCBhc3NpZ25lZCB0byB0aGUgaW50ZXJmYWNlIiBsYW5ndWFnZSBmb3IgdW5udW1iZXJl ZA0KPiBhZGRyZXNzIHR5cGVzIG9yaWdpbmF0ZXMgZnJvbSBSRkMgODAyOSwgYnV0IGJvdGggdGhp cyBkb2N1bWVudCBhbmQgODAyOQ0KPiBsZWF2ZSBtZSBjb25mdXNlZCBhcyB0byB0aGUgZW5jb2Rp bmcgdXNlZCBmb3IgdGhpcyBpbmRleCAoZm9yIGVpdGhlci9ib3RoDQo+IElQdjQgb3IgSVB2NiBh ZGRyZXNzIHR5cGVzKS4NCg0KSXQncyBub3JtYWxseSBhbiB1bnNpZ25lZCBpbnRlZ2VyLiANCg0K PiANCj4gW015IGNvbW1lbnQgYWJvdXQgIk11c3QgQmUgWmVybyIgYW5kIGFsbG9jYXRhYmxlIGJp dHMgYWxzbyBhcHBsaWVzIGhlcmVdDQoNCkZpeGVkIGFzIGFib3ZlLg0KDQo+IA0KPiBTZWN0aW9u IDEyDQo+IA0KPiBUaGlzIGRvY3VtZW50IGFsc28gYWRkcyBhIGNhcGFiaWxpdHkgIm5lZ290aWF0 aW9uIiBtZWNoYW5pc20gZm9yIE1QTFMgZWNobw0KPiByZXF1ZXN0L3JlcGx5IGV4Y2hhbmdlcy4g IEFzIE1QTFMgZG9lcyBub3Qgb2ZmZXIgaW50ZWdyaXR5IHByb3RlY3Rpb24gZm9yIGl0cw0KPiBt ZXNzYWdlcywgdGhpcyBuZWdvdGlhdGlvbiBpcyBvbmx5IGFzIHRydXN0d29ydGh5IGFzIHRoZSBu ZXR3b3JrIGZyb20gd2hpY2gNCj4gbWVzc2FnZXMgYXJlIGFjY2VwdGVkIGFzIHZhbGlkLCBhbmQg aW5pdGlhdG9ycyBoYXZlIG5vIHJlY291cnNlIGJ1dCB0byBhY2NlcHQNCj4gZmFpdGhmdWxseSB0 aGUgZWNobyByZXBsaWVzIHJlY2VpdmVkLg0KPiANCj4gICAgVG8gcHJldmVudCBsZWFrYWdlIG9m IHZpdGFsIGluZm9ybWF0aW9uIHRvIHVudHJ1c3RlZCB1c2VycywgYQ0KPiAgICByZXNwb25kZXIg TFNSIE1VU1Qgb25seSBhY2NlcHQgTVBMUyBlY2hvIHJlcXVlc3QgbWVzc2FnZXMgZnJvbQ0KPiAg ICBkZXNpZ25hdGVkIHRydXN0ZWQgc291cmNlcyB2aWEgZmlsdGVyaW5nIHNvdXJjZSBJUCBhZGRy ZXNzIGZpZWxkIG9mDQo+ICAgIHJlY2VpdmVkIE1QTFMgZWNobyByZXF1ZXN0IG1lc3NhZ2VzLiAg Wy4uLl0NCj4gDQo+IEknZCBwcmVmZXIgdG8gc2VlIGEgbm90ZSBhZGRlZCBoZXJlIGFib3V0IGhv dyAic291cmNlIElQIGFkZHJlc3MgZmlsdGVyaW5nDQo+IHByb3ZpZGVzIG9ubHkgYSB3ZWFrIGZv cm0gb2YgYWNjZXNzIGNvbnRyb2wgYW5kIGlzIG5vdCwgaW4gZ2VuZXJhbCwgYSByZWxpYWJsZQ0K PiBzZWN1cml0eSBtZWNoYW5pc20uICBOb25ldGhlbGVzcywgaXQgaXMgcmVxdWlyZWQgaGVyZSBp biB0aGUgYWJzZW5jZSBvZiBhbnkNCj4gbW9yZSByb2J1c3QgbWVjaGFuaXNtIHRoYXQgbWlnaHQg YmUgdXNlZC4iDQoNCk9LLCBhZGRlZC4NCg0KDQo+IA0KPiBTZWN0aW9uIDEzDQo+IA0KPiBTaG91 bGQgd2UgYXNrIElBTkEgdG8gdXBkYXRlIHRoZSAiSW50ZXJmYWNlIGFuZCBMYWJlbCBTdGFjayBB ZGRyZXNzIFR5cGVzIg0KPiByZWdpc3RyeSB0byBhbHNvIHJlZmVyIHRvIHRoaXMgZG9jdW1lbnQs IHNpbmNlIHdlIGFyZSBzaGFyaW5nIHRoZSByZWdpc3RyeQ0KPiBiZXR3ZWVuIHRoZSBJbnRlcmZh Y2UgYW5kIExhYmVsIFN0YWNrIFRMViBhbmQgdGhlIERldGFpbGVkIHZlcnNpb24/DQoNCkFkZGVk Lg0KDQo+IA0KPiBTZWN0aW9uIDEzLjINCj4gDQo+IFRoZSByYW5nZSA0LTMxNzQzIHNwYW5zIHR3 byBkaWZmZXJlbnQgYWxsb2NhdGlvbiBwcm9jZWR1cmVzIChTdGFuZGFyZHMNCj4gQWN0aW9uIGFu ZCBTcGVjaWZpY2F0aW9uIFJlcXVpcmVkIC0gRXhwZXJpbWVudGFsIFJGQyBuZWVkZWQpOyBJIGFz c3VtZSB0aGF0DQo+IHdlIHdhbnQgdGhlIDQtMTYzODMgcmFuZ2UgZm9yIFN0YW5kYXJkcyBBY3Rp b24gLSBtYW5kYXRvcnkgVExWcy4NCg0KWWVzLg0KDQo+IA0KPiBTZWN0aW9uIDEzLjQNCj4gDQo+ IFdlIGRvbid0IHNheSB3aGF0IHJhbmdlIHdlIHdhbnQgdGhpcyB0byBiZSBhbGxvY2F0ZWQgZnJv bSAtLSBJIGFzc3VtZQ0KPiA0LTE2MzgzIHNpbmNlIHRoaXMgaXMgYSBuZWdvdGlhdGVkIGZlYXR1 cmUgYW5kIHNlbmRpbmcgaXQgb3V0c2lkZSB0aGUNCj4gbmVnb3RpYXRlZCBzY2VuYXJpbyBzaG91 bGQgYmUgYW4gZXJyb3IuDQoNClllcywgc3VnZ2VzdGVkIHJhbmdlIGFkZGVkLg0KDQo+IA0KPiBT ZWN0aW9uIDEzLjQuMQ0KPiANCj4gKEkgbm90ZSB0aGF0IHNvbWUgZXhpc3Rpbmcgc3ViLVRMViBy ZWdpc3RyaWVzIGhhdmUgIkV4cGVyaW1lbnRhbCBSRkMNCj4gcmVxdWlyZWQiIGZvciB0aGUgZXhw ZXJpbWVudGFsIHJhbmdlcywgYnV0IHRoYXQgaXMgYXJndWFibHkgbW9yZSBzdHJpbmdlbnQNCj4g dGhhbiBuZWNlc3Nhcnk7IFNwZWNpZmljYXRpb24gUmVxdWlyZWQgc2VlbXMgbW9yZSBhcHByb3By aWF0ZSBmb3IgdGhpcyBjYXNlLikNCg0KT0ssIGNoYW5nZSB0byAiIFNwZWNpZmljYXRpb24gUmVx dWlyZWQiLg0KDQo+IA0KPiBBcHBlbmRpeCBBDQo+IA0KPiBJIHdhcyBraW5kIG9mIGhvcGluZyBm b3Igc29tZSBtb3JlIGd1aWRhbmNlIG9uIHdoYXQgYW4gaW5pdGlhdG9yIGNvdWxkIGRvIGluDQo+ IHRoZXNlIHNjZW5hcmlvcyB0byB0cnkgdG8gZ2V0IGJldHRlciB2aXNpYmlsaXR5IGludG8gdGhl IHN3aXRjaCBiZWhhdmlvciAoYW5kLA0KPiBob3BlZnVsbHksIGEgd29ya2Fyb3VuZCB0byBnZXQg cmVsaWFibGUgZWNobyByZXNwb25zZXMgdGhhdCBjb3ZlciBhbGwgTEFHDQo+IG1lbWJlciBsaW5r cykuICBBRkFJQ1QgdGhlcmUncyBub3QgYSBiZXR0ZXIgb3B0aW9uIHRoYW4gInRyeSBhIGJ1bmNo IG9mDQo+IGVudHJvcHkgbGFiZWxzIGFuZCBzZWUgd2hhdCByZXNwb25zZXMgeW91IGNhbiBnZXQg YmFjayIgYW5kIHRoYXQncyB0aGUNCj4gc2FtZSByZW1lZHkgaW4gYWxsIHRoZSBkZXNjcmliZWQg dG9wb2xvZ2llcywgYnV0IGl0IHdvdWxkIGJlIG5pY2UgdG8gaGF2ZSB0aGlzDQo+IHN0YXRlZCBl eHBsaWNpdGx5IGZvciB0aGUgcmVhZGVyLg0KDQpBIG5vdGUgd2lsbCBiZSBhZGRlZC4NCg0KPiAN Cj4gU2VjdGlvbiBBLjENCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgSW4gdGhlIHdvcnN0IGNh c2UsIE1QTFMgZWNobyByZXF1ZXN0IG1lc3NhZ2VzIHdpdGgNCj4gICAgc3BlY2lmaWMgZW50cm9w aWVzIHRvIGV4ZXJjaXNlIGV2ZXJ5IExBRyBtZW1iZXJzIGZyb20gUjEgdG8gUzEgY2FuDQo+ICAg IGFsbCByZWFjaCBSMiB2aWEgc2FtZSBMQUcgbWVtYmVyLiAgWy4uLl0NCj4gDQo+IEknbSBjb25m dXNlZCBieSB0aGUgcGhyYXNlICJzcGVjaWZpYyBlbnRyb3BpZXMgdG8gZXhlcmNpc2UgZXZlcnkg TEFHDQo+IG1lbWJlcnMgW3NpY10gZnJvbSBSMSB0byBTMSIgLS0gaXMgdGhlcmUgc29tZSBkZXRl cm1pbmlzdGljIGFsZ29yaXRobSBieQ0KPiB3aGljaCBhIHNwZWNpZmljIGVudHJvcHkgbGFiZWwg dmFsdWUgd2lsbCBmb3JjZSBhIHNwZWNpZmljIExBRyBtZW1iZXIgbGluaz8NCg0KTm8uDQoNCj4g TXkgdW5kZXJzdGFuZGluZyB3YXMgdGhhdCB0aGUgZW50cm9weSB3YXMgdXNlZCBhcyBpbnB1dCB0 byBhbiBvcGFxdWUgaGFzaA0KPiBmdW5jdGlvbiBhbmQgdGhhdCB0cmlhbC1hbmQtZXJyb3Igd2Fz IHRoZSBvbmx5IHdheSB0byBleHBsb3JlIHRoZSBtYXBwaW5nDQo+IGZyb20gZW50cm9weSB2YWx1 ZSB0byBMQUcgbWVtYmVyIGxpbmsgdGFrZW4uDQoNClllcy4NCg0KVGhhbmtzIGFnYWluIGZvciB5 b3VyIGRldGFpbGVkIGFuZCB2YWx1YWJsZSBjb21tZW50cyENCg0KQmVzdCByZWdhcmRzLA0KTWFj aA0KPiANCg0K From nobody Wed Mar 13 02:15:26 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9582130EDB; Wed, 13 Mar 2019 02:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 f-k-AAHAY3Nk; Wed, 13 Mar 2019 02:15:16 -0700 (PDT) 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 B7DB8130ED0; Wed, 13 Mar 2019 02:15:16 -0700 (PDT) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id DC0B7CB42607FEFC9370; Wed, 13 Mar 2019 09:15:13 +0000 (GMT) Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 13 Mar 2019 09:15:13 +0000 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.190]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0415.000; Wed, 13 Mar 2019 17:15:09 +0800 From: Mach Chen To: =?utf-8?B?TWlyamEgS8O8aGxld2luZCB2aWEgRGF0YXRyYWNrZXI=?= , The IESG CC: "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" , "mpls-chairs@ietf.org" , "loa@pi.nu" , "mpls@ietf.org" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-mpls-lsp-ping-lag-multipath-06:_(with_COMMENT)?= Thread-Index: AQHU2Oy6s520bV8QO0y5RWWbir7qHKYJRALQ Date: Wed, 13 Mar 2019 09:15:08 +0000 Message-ID: References: <155240641959.16274.10292530156982066442.idtracker@ietfa.amsl.com> In-Reply-To: <155240641959.16274.10292530156982066442.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-mpls-lsp-ping-lag-multipath-06=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 09:15:19 -0000 SGkgTWlyamEsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cyENCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNaXJqYSBLw7xobGV3aW5kIHZpYSBEYXRhdHJhY2tlciBb bWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmddDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMTMsIDIw MTkgMTI6MDAgQU0NCj4gVG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBDYzogZHJhZnQt aWV0Zi1tcGxzLWxzcC1waW5nLWxhZy1tdWx0aXBhdGhAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQGll dGYub3JnOw0KPiBsb2FAcGkubnU7IG1wbHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogTWlyamEgS8O8 aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctbGFnLQ0K PiBtdWx0aXBhdGgtMDY6ICh3aXRoIENPTU1FTlQpDQo+IA0KPiBNaXJqYSBLw7xobGV3aW5kIGhh cyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRm LW1wbHMtbHNwLXBpbmctbGFnLW11bHRpcGF0aC0wNjogTm8gT2JqZWN0aW9uDQo+IA0KPiBXaGVu IHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBs eSB0byBhbGwgZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGlu ZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5DQo+IHBhcmFncmFwaCwgaG93 ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2ll c2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlv biBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRo ZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91 bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1t cGxzLWxzcC1waW5nLWxhZy1tdWx0aXBhdGgvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gSSB3YW50ZWQgdG8gY29tbWVudCBv biB0aGUgc2FtZSBzZW50ZW5jZS9ub3JtYXRpdmUgcmVxdWlyZW1lbnQgYXMNCj4gQWx2YXJvIGRp ZCBpbiBoaXMgcG9pbnQgKDIpLiBHaXZlbiBBbHZhcm8ncyBhZGRpdGlvbmFsIGluZm9ybWF0aW9u IHRoYXQgdGhlcmUgaXMNCj4gYWN0dWFsbHkgZXZlbiBhIHRlY2huaWNhbCBjb25mbGljdCB3aXRo IHRoaXMgcmVxdWlyZW1lbnQsIEkgdGhpbmsgdGhpcyBzaG91bGQgYmUNCj4gYWRkcmVzcyBiZWZv cmUgcHVibGljYXRpb24gYW5kIG1pZ2h0IGV2ZW4gYmUgZGlzY3Vzcy13b3J0aHkuIEhvd2V2ZXIs IEknbQ0KPiByZWFsbHkgbm90IGFuIGV4cGVydCBvbiBNUExTIGFuZCB0aGVyZWZvcmUgbGVhdmUg dGhlIGRlY2lzaW9uIHRvIHN0YXRlIGENCj4gZGlzY3VzcyBiYWxsb3QgcG9zaXRpb24gdG8gcG90 ZW50aWFsbHkgb3RoZXIsIG1vcmUga25vd2xlZGdhYmxlIEFEcy4NCj4gDQo+IFRoYW5rcyBmb3Ig YWRkcmVzc2luZyB0aGUgVFNWLUFSVCByZXZpZXcgY29tbWVudHMgKGFuZCB0aGFua3MgSsO2cmcg Zm9yDQo+IHRoZSByZXZpZXcpISBJIHN1cHBvcnQgYWRkaW5nIGFub3RoZXIgc2VudGVuY2Ugd2l0 aCBhIHBvaW50ZXIgdG8gcmF0ZS1saW1pdA0KPiByZXF1aXJlbWVudHMgaW4gb3RoZXIgZG9jcy4g VGhhbmtzIGZvciBwcm9wb3NpbmcgdGhpcyBjaGFuZ2UuIExvb2tpbmcNCj4gZm9yd2FyZCB0aGlz IHNlZSB0aGlzIGluIHRoZSBkb2MhDQoNCkFyZSB5b3Ugc3VnZ2VzdGluZyB0byBhZGQgYSByZWZl cmVuY2UsIGRvIHlvdSBoYXZlIGFueSBzcGVjaWZpYyBkb2NzIHN1Z2dlc3Rpb24/DQoNCkJlc3Qg cmVnYXJkcywNCk1hY2ggDQo+IA0KDQo= From nobody Wed Mar 13 02:51:39 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340DB130EDC; Wed, 13 Mar 2019 02:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3_lPH1Mryn2K; Wed, 13 Mar 2019 02:51:27 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 92B4B130EDB; Wed, 13 Mar 2019 02:51:27 -0700 (PDT) Received: from [129.192.10.2] (helo=[10.149.2.6]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1h40Xj-0002uM-7d; Wed, 13 Mar 2019 10:51:23 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Mirja Kuehlewind In-Reply-To: Date: Wed, 13 Mar 2019 10:51:22 +0100 Cc: =?utf-8?Q?Mirja_K=C3=BChlewind_via_Datatracker?= , The IESG , "mpls@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" , "mpls-chairs@ietf.org" , "loa@pi.nu" Content-Transfer-Encoding: quoted-printable Message-Id: References: <155240641959.16274.10292530156982066442.idtracker@ietfa.amsl.com> To: Mach Chen X-Mailer: Apple Mail (2.3445.101.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1552470687;27192278; X-HE-SMSGID: 1h40Xj-0002uM-7d Archived-At: Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-mpls-lsp-ping-lag-multipath-06=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 09:51:30 -0000 Hi Mach, Please see below > On 13. Mar 2019, at 10:15, Mach Chen wrote: >=20 > Hi Mirja, >=20 > Thanks for your comments! >=20 >> -----Original Message----- >> From: Mirja K=C3=BChlewind via Datatracker [mailto:noreply@ietf.org] >> Sent: Wednesday, March 13, 2019 12:00 AM >> To: The IESG >> Cc: draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org; = mpls-chairs@ietf.org; >> loa@pi.nu; mpls@ietf.org >> Subject: Mirja K=C3=BChlewind's No Objection on = draft-ietf-mpls-lsp-ping-lag- >> multipath-06: (with COMMENT) >>=20 >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-mpls-lsp-ping-lag-multipath-06: No Objection >>=20 >> 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.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> = https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-lag-multipath/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> I wanted to comment on the same sentence/normative requirement as >> Alvaro did in his point (2). Given Alvaro's additional information = that there is >> actually even a technical conflict with this requirement, I think = this should be >> address before publication and might even be discuss-worthy. However, = I'm >> really not an expert on MPLS and therefore leave the decision to = state a >> discuss ballot position to potentially other, more knowledgable ADs. >>=20 >> Thanks for addressing the TSV-ART review comments (and thanks J=C3=B6rg= for >> the review)! I support adding another sentence with a pointer to = rate-limit >> requirements in other docs. Thanks for proposing this change. Looking >> forward this see this in the doc! >=20 > Are you suggesting to add a reference, do you have any specific docs = suggestion? In your reply to Joerg=E2=80=99s tsv-art review (on Dec 14 already), you = proposed to add the following statement: "For an LSP path, it may be over several LAGs. For each LAG, there will = be many member links. To exercise all the links, many Echo Request/Reply = messages will be sent in a short period. It's possible that those = messages may traverse a common path as a burst. Under some circumstances = this might cause congestion at the common path. To avoid potential = congestion, it is RECOMMENDED that implementations to randomly delay the = Echo Request and Reply messages at the Initiating LSRs and Responder = LSRs.=E2=80=9D You also said: "RFC8029 (Security Consideration) does recommend the implementation to = regulate the ping traffic to the control plane, it applies to this = document as well.=20 At the same time, RFC 6425 (P2MP LSP Ping, section 2.2) introduces some = ways to limit the message rate. The way of random delay messages would = apply to this document as well.=E2=80=9D So adding pointer to these two documents/sections would be good as well = maybe. Thanks! Mirja >=20 > Best regards, > Mach=20 >>=20 >=20 From nobody Wed Mar 13 02:57:28 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4EF130EDC; Wed, 13 Mar 2019 02:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DM0yTcjgki_p; Wed, 13 Mar 2019 02:57:17 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 3E1E1130EBF; Wed, 13 Mar 2019 02:57:17 -0700 (PDT) Received: from [129.192.10.2] (helo=[10.149.2.6]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1h40dN-0008NR-AF; Wed, 13 Mar 2019 10:57:13 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Mirja Kuehlewind In-Reply-To: <001601d4d8d4$2808d1c0$781a7540$@olddog.co.uk> Date: Wed, 13 Mar 2019 10:57:12 +0100 Cc: =?utf-8?Q?Mirja_K=C3=BChlewind_via_Datatracker?= , The IESG , mpls@ietf.org, loa@pi.nu, mpls-chairs@ietf.org, draft-ietf-mpls-sr-over-ip@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <35AA21D8-14B0-4AF3-A46C-A0349B7697FD@kuehlewind.net> References: <155238798836.13888.12133834062700877951.idtracker@ietfa.amsl.com> <001601d4d8d4$2808d1c0$781a7540$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.3445.101.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1552471037;de860c0c; X-HE-SMSGID: 1h40dN-0008NR-AF Archived-At: Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?mpls-sr-over-ip-03=3A_=28with_DISCUSS=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 09:57:20 -0000 Hi Adrian, Please see below. > On 12. Mar 2019, at 14:04, Adrian Farrel wrote: >=20 > Thanks Mirja, >=20 >> 1) Given section 3.1, the following drafts all seems that they should = be >> normative references: ietf-isis-encapsulation-cap, = ietf-ospf-encapsulation-cap, >> ietf-ospf-segment-routing-extensions, = ietf-isis-segment-routing-extensions >=20 > Well, that wasn't the intention. It is meant to be an example of how = the forwarding entries are constructed. >=20 > As it says at the top of Section 3... > Note that the examples in > Section 3.1 and Section 3.2 assume that OSPF or ISIS is enabled: in > fact, other mechanisms of discovery and advertisement could be used > including other routing protocols (such as BGP) or a central > controller. >=20 > We could be more explicit in section 3.1 so that, for example... >=20 > OLD > o The Segment Routing Global Block (SRGB) is defined in [RFC8402]. > Router E is SR-MPLS capable, so it advertises an SRGB as = described > in [I-D.ietf-ospf-segment-routing-extensions] and > [I-D.ietf-isis-segment-routing-extensions]. > NEW > o The Segment Routing Global Block (SRGB) is defined in [RFC8402]. > Router E is SR-MPLS capable, so it advertises an SRGB to the = other > SR-MPLS capable routers. If an IGP is in use then Router E = behaves > as described in [I-D.ietf-ospf-segment-routing-extensions] and > [I-D.ietf-isis-segment-routing-extensions], but other mechanisms > Could be applied. > END >=20 > We'd need to make similar changes throughout the section. >=20 > Would such changes be enough for you? It still sounds to me that these document are basically a must read to = understand the full picture. Do you think it would be a problem or the = wrong thing to make these reference normative? However, your wording change makes it definitely more clear that this is = only one example. If the wg and responsible ADs think, it=E2=80=99s the = right thing to do to leave the reference informative, I will clear my = discuss. >=20 >> 2) Sec 3.2.3 on IP Header fields should refer to RFC6040 for the ECN >> field and eventually RFC2983 for DSCP. >=20 > That's good. Thanks. It gives us... >=20 > When encapsulating an = MPLS > packet in UDP, the resulting packet is further = encapsulated in > IP for transmission. IPv4 or IPv6 may be used according = to the > capabilities of the network. The address fields are set = as > described in . The other IP = header > fields (such as the ECN field , = the DSCP=20 > code point , or IPv6 Flow = Label) on each > UDP-encapsulated segment SHOULD be configurable according = to the > operator's policy: they may be copied from the = header of the > incoming packet; they may be promoted from the header of = the > payload packet; they may be set according to instructions > programmed to be associated with the SID; or they may be > configured dependent on the outgoing interface and = payload. Yes, thanks! Mirja >=20 > Best, > Adrian >=20 >=20 From nobody Wed Mar 13 03:40:31 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1624E130EED; Wed, 13 Mar 2019 03:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 R3XXgzewhuLO; Wed, 13 Mar 2019 03:40:19 -0700 (PDT) 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 51400130EF5; Wed, 13 Mar 2019 03:40:19 -0700 (PDT) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 8A08740698CDE5C9A72E; Wed, 13 Mar 2019 10:40:17 +0000 (GMT) Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 13 Mar 2019 10:40:16 +0000 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.190]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0415.000; Wed, 13 Mar 2019 18:40:10 +0800 From: Mach Chen To: Mirja Kuehlewind CC: =?utf-8?B?TWlyamEgS8O8aGxld2luZCB2aWEgRGF0YXRyYWNrZXI=?= , The IESG , "mpls@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" , "mpls-chairs@ietf.org" , "loa@pi.nu" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-mpls-lsp-ping-lag-multipath-06:_(with_COMMENT)?= Thread-Index: AQHU2Oy6s520bV8QO0y5RWWbir7qHKYJRALQ//+IqQCAAJNrAA== Date: Wed, 13 Mar 2019 10:40:09 +0000 Message-ID: References: <155240641959.16274.10292530156982066442.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-mpls-lsp-ping-lag-multipath-06=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 10:40:23 -0000 SGkgTWlyamEsDQoNClRoYW5rcywgdGhhdCdzIGhlbHAgYSBsb3QgOi0pDQoNCkJlc3QgcmVnYXJk cywNCk1hY2ggDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWlyamEg S3VlaGxld2luZCBbbWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXRdDQo+IFNlbnQ6IFdlZG5lc2Rh eSwgTWFyY2ggMTMsIDIwMTkgNTo1MSBQTQ0KPiBUbzogTWFjaCBDaGVuIDxtYWNoLmNoZW5AaHVh d2VpLmNvbT4NCj4gQ2M6IE1pcmphIEvDvGhsZXdpbmQgdmlhIERhdGF0cmFja2VyIDxub3JlcGx5 QGlldGYub3JnPjsgVGhlIElFU0cNCj4gPGllc2dAaWV0Zi5vcmc+OyBtcGxzQGlldGYub3JnOyBk cmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctbGFnLQ0KPiBtdWx0aXBhdGhAaWV0Zi5vcmc7IG1wbHMt Y2hhaXJzQGlldGYub3JnOyBsb2FAcGkubnUNCj4gU3ViamVjdDogUmU6IE1pcmphIEvDvGhsZXdp bmQncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLWxhZy0NCj4gbXVs dGlwYXRoLTA2OiAod2l0aCBDT01NRU5UKQ0KPiANCj4gSGkgTWFjaCwNCj4gDQo+IFBsZWFzZSBz ZWUgYmVsb3cNCj4gDQo+ID4gT24gMTMuIE1hciAyMDE5LCBhdCAxMDoxNSwgTWFjaCBDaGVuIDxt YWNoLmNoZW5AaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBIaSBNaXJqYSwNCj4gPg0KPiA+ IFRoYW5rcyBmb3IgeW91ciBjb21tZW50cyENCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+PiBGcm9tOiBNaXJqYSBLw7xobGV3aW5kIHZpYSBEYXRhdHJhY2tlciBbbWFp bHRvOm5vcmVwbHlAaWV0Zi5vcmddDQo+ID4+IFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMTMsIDIw MTkgMTI6MDAgQU0NCj4gPj4gVG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiA+PiBDYzog ZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLWxhZy1tdWx0aXBhdGhAaWV0Zi5vcmc7DQo+ID4+IG1w bHMtY2hhaXJzQGlldGYub3JnOyBsb2FAcGkubnU7IG1wbHNAaWV0Zi5vcmcNCj4gPj4gU3ViamVj dDogTWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbg0KPiA+PiBkcmFmdC1pZXRmLW1w bHMtbHNwLXBpbmctbGFnLQ0KPiA+PiBtdWx0aXBhdGgtMDY6ICh3aXRoIENPTU1FTlQpDQo+ID4+ DQo+ID4+IE1pcmphIEvDvGhsZXdpbmQgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3Qg cG9zaXRpb24gZm9yDQo+ID4+IGRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1sYWctbXVsdGlwYXRo LTA2OiBObyBPYmplY3Rpb24NCj4gPj4NCj4gPj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2Vl cCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+ID4+IGVtYWlsIGFk ZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1 dA0KPiA+PiB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiA+Pg0KPiA+ Pg0KPiA+PiBQbGVhc2UgcmVmZXIgdG8NCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9z dGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+ID4+IGZvciBtb3JlIGluZm9ybWF0aW9u IGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+ID4+DQo+ID4+DQo+ ID4+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4g YmUgZm91bmQgaGVyZToNCj4gPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1tcGxzLWxzcC1waW5nLWxhZy1tdWx0aXBhDQo+ID4+IHRoLw0KPiA+Pg0KPiA+Pg0K PiA+Pg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gLQ0KPiA+PiBDT01NRU5UOg0KPiA+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gPj4gLQ0KPiA+Pg0KPiA+PiBJIHdhbnRlZCB0byBjb21tZW50IG9uIHRoZSBz YW1lIHNlbnRlbmNlL25vcm1hdGl2ZSByZXF1aXJlbWVudCBhcw0KPiA+PiBBbHZhcm8gZGlkIGlu IGhpcyBwb2ludCAoMikuIEdpdmVuIEFsdmFybydzIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24NCj4g Pj4gdGhhdCB0aGVyZSBpcyBhY3R1YWxseSBldmVuIGEgdGVjaG5pY2FsIGNvbmZsaWN0IHdpdGgg dGhpcw0KPiA+PiByZXF1aXJlbWVudCwgSSB0aGluayB0aGlzIHNob3VsZCBiZSBhZGRyZXNzIGJl Zm9yZSBwdWJsaWNhdGlvbiBhbmQNCj4gPj4gbWlnaHQgZXZlbiBiZSBkaXNjdXNzLXdvcnRoeS4g SG93ZXZlciwgSSdtIHJlYWxseSBub3QgYW4gZXhwZXJ0IG9uDQo+ID4+IE1QTFMgYW5kIHRoZXJl Zm9yZSBsZWF2ZSB0aGUgZGVjaXNpb24gdG8gc3RhdGUgYSBkaXNjdXNzIGJhbGxvdCBwb3NpdGlv biB0bw0KPiBwb3RlbnRpYWxseSBvdGhlciwgbW9yZSBrbm93bGVkZ2FibGUgQURzLg0KPiA+Pg0K PiA+PiBUaGFua3MgZm9yIGFkZHJlc3NpbmcgdGhlIFRTVi1BUlQgcmV2aWV3IGNvbW1lbnRzIChh bmQgdGhhbmtzIErDtnJnDQo+ID4+IGZvciB0aGUgcmV2aWV3KSEgSSBzdXBwb3J0IGFkZGluZyBh bm90aGVyIHNlbnRlbmNlIHdpdGggYSBwb2ludGVyIHRvDQo+ID4+IHJhdGUtbGltaXQgcmVxdWly ZW1lbnRzIGluIG90aGVyIGRvY3MuIFRoYW5rcyBmb3IgcHJvcG9zaW5nIHRoaXMNCj4gPj4gY2hh bmdlLiBMb29raW5nIGZvcndhcmQgdGhpcyBzZWUgdGhpcyBpbiB0aGUgZG9jIQ0KPiA+DQo+ID4g QXJlIHlvdSBzdWdnZXN0aW5nIHRvIGFkZCBhIHJlZmVyZW5jZSwgZG8geW91IGhhdmUgYW55IHNw ZWNpZmljIGRvY3MNCj4gc3VnZ2VzdGlvbj8NCj4gDQo+IEluIHlvdXIgcmVwbHkgdG8gSm9lcmfi gJlzIHRzdi1hcnQgcmV2aWV3IChvbiBEZWMgMTQgYWxyZWFkeSksIHlvdSBwcm9wb3NlZCB0bw0K PiBhZGQgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQ6DQo+IA0KPiAiRm9yIGFuIExTUCBwYXRoLCBp dCBtYXkgYmUgb3ZlciBzZXZlcmFsIExBR3MuIEZvciBlYWNoIExBRywgdGhlcmUgd2lsbCBiZQ0K PiBtYW55IG1lbWJlciBsaW5rcy4gVG8gZXhlcmNpc2UgYWxsIHRoZSBsaW5rcywgbWFueSBFY2hv IFJlcXVlc3QvUmVwbHkNCj4gbWVzc2FnZXMgd2lsbCBiZSBzZW50IGluIGEgc2hvcnQgcGVyaW9k LiBJdCdzIHBvc3NpYmxlIHRoYXQgdGhvc2UgbWVzc2FnZXMgbWF5DQo+IHRyYXZlcnNlIGEgY29t bW9uIHBhdGggYXMgYSBidXJzdC4gVW5kZXIgc29tZSBjaXJjdW1zdGFuY2VzIHRoaXMgbWlnaHQN Cj4gY2F1c2UgY29uZ2VzdGlvbiBhdCB0aGUgY29tbW9uIHBhdGguIFRvIGF2b2lkIHBvdGVudGlh bCBjb25nZXN0aW9uLCBpdCBpcw0KPiBSRUNPTU1FTkRFRCB0aGF0IGltcGxlbWVudGF0aW9ucyB0 byByYW5kb21seSBkZWxheSB0aGUgRWNobyBSZXF1ZXN0DQo+IGFuZCBSZXBseSBtZXNzYWdlcyBh dCB0aGUgSW5pdGlhdGluZyBMU1JzIGFuZCBSZXNwb25kZXIgTFNScy7igJ0NCj4gDQo+IFlvdSBh bHNvIHNhaWQ6DQo+ICJSRkM4MDI5IChTZWN1cml0eSBDb25zaWRlcmF0aW9uKSBkb2VzIHJlY29t bWVuZCB0aGUgaW1wbGVtZW50YXRpb24gdG8NCj4gcmVndWxhdGUgdGhlIHBpbmcgdHJhZmZpYyB0 byB0aGUgY29udHJvbCBwbGFuZSwgaXQgIGFwcGxpZXMgdG8gdGhpcyBkb2N1bWVudCBhcw0KPiB3 ZWxsLg0KPiANCj4gQXQgdGhlIHNhbWUgdGltZSwgUkZDIDY0MjUgKFAyTVAgTFNQIFBpbmcsIHNl Y3Rpb24gMi4yKSBpbnRyb2R1Y2VzIHNvbWUNCj4gd2F5cyB0byBsaW1pdCB0aGUgbWVzc2FnZSBy YXRlLiBUaGUgd2F5IG9mIHJhbmRvbSBkZWxheSBtZXNzYWdlcyB3b3VsZA0KPiBhcHBseSB0byB0 aGlzIGRvY3VtZW50IGFzIHdlbGwu4oCdDQo+IA0KPiBTbyBhZGRpbmcgcG9pbnRlciB0byB0aGVz ZSB0d28gZG9jdW1lbnRzL3NlY3Rpb25zIHdvdWxkIGJlIGdvb2QgYXMgd2VsbA0KPiBtYXliZS4N Cj4gDQo+IFRoYW5rcyENCj4gTWlyamENCj4gDQo+IA0KPiA+DQo+ID4gQmVzdCByZWdhcmRzLA0K PiA+IE1hY2gNCj4gPj4NCj4gPg0KDQo= From nobody Wed Mar 13 03:52:50 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DFC130F24; Wed, 13 Mar 2019 03:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LtXiBWAMeMUP; Wed, 13 Mar 2019 03:52:29 -0700 (PDT) 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 637DE130EFF; Wed, 13 Mar 2019 03:52:29 -0700 (PDT) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 3B5888FB77603E8D1CDD; Wed, 13 Mar 2019 10:52:26 +0000 (GMT) Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 13 Mar 2019 10:52:25 +0000 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.190]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0415.000; Wed, 13 Mar 2019 18:52:22 +0800 From: Mach Chen To: Mirja Kuehlewind CC: =?utf-8?B?TWlyamEgS8O8aGxld2luZCB2aWEgRGF0YXRyYWNrZXI=?= , The IESG , "mpls@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" , "mpls-chairs@ietf.org" , "loa@pi.nu" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-mpls-lsp-ping-lag-multipath-06:_(with_COMMENT)?= Thread-Index: AQHU2Oy6s520bV8QO0y5RWWbir7qHKYJRALQ//+IqQCAAJatQA== Date: Wed, 13 Mar 2019 10:52:22 +0000 Message-ID: References: <155240641959.16274.10292530156982066442.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-mpls-lsp-ping-lag-multipath-06=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 10:52:42 -0000 SGkgTWlyamEsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWlyamEg S3VlaGxld2luZCBbbWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXRdDQo+IFNlbnQ6IFdlZG5lc2Rh eSwgTWFyY2ggMTMsIDIwMTkgNTo1MSBQTQ0KPiBUbzogTWFjaCBDaGVuIDxtYWNoLmNoZW5AaHVh d2VpLmNvbT4NCj4gQ2M6IE1pcmphIEvDvGhsZXdpbmQgdmlhIERhdGF0cmFja2VyIDxub3JlcGx5 QGlldGYub3JnPjsgVGhlIElFU0cNCj4gPGllc2dAaWV0Zi5vcmc+OyBtcGxzQGlldGYub3JnOyBk cmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctbGFnLQ0KPiBtdWx0aXBhdGhAaWV0Zi5vcmc7IG1wbHMt Y2hhaXJzQGlldGYub3JnOyBsb2FAcGkubnUNCj4gU3ViamVjdDogUmU6IE1pcmphIEvDvGhsZXdp bmQncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLWxhZy0NCj4gbXVs dGlwYXRoLTA2OiAod2l0aCBDT01NRU5UKQ0KPiANCj4gSGkgTWFjaCwNCj4gDQo+IFBsZWFzZSBz ZWUgYmVsb3cNCj4gDQo+ID4gT24gMTMuIE1hciAyMDE5LCBhdCAxMDoxNSwgTWFjaCBDaGVuIDxt YWNoLmNoZW5AaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBIaSBNaXJqYSwNCj4gPg0KPiA+ IFRoYW5rcyBmb3IgeW91ciBjb21tZW50cyENCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+PiBGcm9tOiBNaXJqYSBLw7xobGV3aW5kIHZpYSBEYXRhdHJhY2tlciBbbWFp bHRvOm5vcmVwbHlAaWV0Zi5vcmddDQo+ID4+IFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMTMsIDIw MTkgMTI6MDAgQU0NCj4gPj4gVG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiA+PiBDYzog ZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLWxhZy1tdWx0aXBhdGhAaWV0Zi5vcmc7DQo+ID4+IG1w bHMtY2hhaXJzQGlldGYub3JnOyBsb2FAcGkubnU7IG1wbHNAaWV0Zi5vcmcNCj4gPj4gU3ViamVj dDogTWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbg0KPiA+PiBkcmFmdC1pZXRmLW1w bHMtbHNwLXBpbmctbGFnLQ0KPiA+PiBtdWx0aXBhdGgtMDY6ICh3aXRoIENPTU1FTlQpDQo+ID4+ DQo+ID4+IE1pcmphIEvDvGhsZXdpbmQgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3Qg cG9zaXRpb24gZm9yDQo+ID4+IGRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1sYWctbXVsdGlwYXRo LTA2OiBObyBPYmplY3Rpb24NCj4gPj4NCj4gPj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2Vl cCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+ID4+IGVtYWlsIGFk ZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1 dA0KPiA+PiB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiA+Pg0KPiA+ Pg0KPiA+PiBQbGVhc2UgcmVmZXIgdG8NCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9z dGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+ID4+IGZvciBtb3JlIGluZm9ybWF0aW9u IGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+ID4+DQo+ID4+DQo+ ID4+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4g YmUgZm91bmQgaGVyZToNCj4gPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1tcGxzLWxzcC1waW5nLWxhZy1tdWx0aXBhDQo+ID4+IHRoLw0KPiA+Pg0KPiA+Pg0K PiA+Pg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gLQ0KPiA+PiBDT01NRU5UOg0KPiA+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gPj4gLQ0KPiA+Pg0KPiA+PiBJIHdhbnRlZCB0byBjb21tZW50IG9uIHRoZSBz YW1lIHNlbnRlbmNlL25vcm1hdGl2ZSByZXF1aXJlbWVudCBhcw0KPiA+PiBBbHZhcm8gZGlkIGlu IGhpcyBwb2ludCAoMikuIEdpdmVuIEFsdmFybydzIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24NCj4g Pj4gdGhhdCB0aGVyZSBpcyBhY3R1YWxseSBldmVuIGEgdGVjaG5pY2FsIGNvbmZsaWN0IHdpdGgg dGhpcw0KPiA+PiByZXF1aXJlbWVudCwgSSB0aGluayB0aGlzIHNob3VsZCBiZSBhZGRyZXNzIGJl Zm9yZSBwdWJsaWNhdGlvbiBhbmQNCj4gPj4gbWlnaHQgZXZlbiBiZSBkaXNjdXNzLXdvcnRoeS4g SG93ZXZlciwgSSdtIHJlYWxseSBub3QgYW4gZXhwZXJ0IG9uDQo+ID4+IE1QTFMgYW5kIHRoZXJl Zm9yZSBsZWF2ZSB0aGUgZGVjaXNpb24gdG8gc3RhdGUgYSBkaXNjdXNzIGJhbGxvdCBwb3NpdGlv biB0bw0KPiBwb3RlbnRpYWxseSBvdGhlciwgbW9yZSBrbm93bGVkZ2FibGUgQURzLg0KPiA+Pg0K PiA+PiBUaGFua3MgZm9yIGFkZHJlc3NpbmcgdGhlIFRTVi1BUlQgcmV2aWV3IGNvbW1lbnRzIChh bmQgdGhhbmtzIErDtnJnDQo+ID4+IGZvciB0aGUgcmV2aWV3KSEgSSBzdXBwb3J0IGFkZGluZyBh bm90aGVyIHNlbnRlbmNlIHdpdGggYSBwb2ludGVyIHRvDQo+ID4+IHJhdGUtbGltaXQgcmVxdWly ZW1lbnRzIGluIG90aGVyIGRvY3MuIFRoYW5rcyBmb3IgcHJvcG9zaW5nIHRoaXMNCj4gPj4gY2hh bmdlLiBMb29raW5nIGZvcndhcmQgdGhpcyBzZWUgdGhpcyBpbiB0aGUgZG9jIQ0KPiA+DQo+ID4g QXJlIHlvdSBzdWdnZXN0aW5nIHRvIGFkZCBhIHJlZmVyZW5jZSwgZG8geW91IGhhdmUgYW55IHNw ZWNpZmljIGRvY3MNCj4gc3VnZ2VzdGlvbj8NCj4gDQo+IEluIHlvdXIgcmVwbHkgdG8gSm9lcmfi gJlzIHRzdi1hcnQgcmV2aWV3IChvbiBEZWMgMTQgYWxyZWFkeSksIHlvdSBwcm9wb3NlZCB0bw0K PiBhZGQgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQ6DQo+IA0KPiAiRm9yIGFuIExTUCBwYXRoLCBp dCBtYXkgYmUgb3ZlciBzZXZlcmFsIExBR3MuIEZvciBlYWNoIExBRywgdGhlcmUgd2lsbCBiZQ0K PiBtYW55IG1lbWJlciBsaW5rcy4gVG8gZXhlcmNpc2UgYWxsIHRoZSBsaW5rcywgbWFueSBFY2hv IFJlcXVlc3QvUmVwbHkNCj4gbWVzc2FnZXMgd2lsbCBiZSBzZW50IGluIGEgc2hvcnQgcGVyaW9k LiBJdCdzIHBvc3NpYmxlIHRoYXQgdGhvc2UgbWVzc2FnZXMgbWF5DQo+IHRyYXZlcnNlIGEgY29t bW9uIHBhdGggYXMgYSBidXJzdC4gVW5kZXIgc29tZSBjaXJjdW1zdGFuY2VzIHRoaXMgbWlnaHQN Cj4gY2F1c2UgY29uZ2VzdGlvbiBhdCB0aGUgY29tbW9uIHBhdGguIFRvIGF2b2lkIHBvdGVudGlh bCBjb25nZXN0aW9uLCBpdCBpcw0KPiBSRUNPTU1FTkRFRCB0aGF0IGltcGxlbWVudGF0aW9ucyB0 byByYW5kb21seSBkZWxheSB0aGUgRWNobyBSZXF1ZXN0DQo+IGFuZCBSZXBseSBtZXNzYWdlcyBh dCB0aGUgSW5pdGlhdGluZyBMU1JzIGFuZCBSZXNwb25kZXIgTFNScy7igJ0NCj4gDQo+IFlvdSBh bHNvIHNhaWQ6DQo+ICJSRkM4MDI5IChTZWN1cml0eSBDb25zaWRlcmF0aW9uKSBkb2VzIHJlY29t bWVuZCB0aGUgaW1wbGVtZW50YXRpb24gdG8NCj4gcmVndWxhdGUgdGhlIHBpbmcgdHJhZmZpYyB0 byB0aGUgY29udHJvbCBwbGFuZSwgaXQgIGFwcGxpZXMgdG8gdGhpcyBkb2N1bWVudCBhcw0KPiB3 ZWxsLg0KPiANCj4gQXQgdGhlIHNhbWUgdGltZSwgUkZDIDY0MjUgKFAyTVAgTFNQIFBpbmcsIHNl Y3Rpb24gMi4yKSBpbnRyb2R1Y2VzIHNvbWUNCj4gd2F5cyB0byBsaW1pdCB0aGUgbWVzc2FnZSBy YXRlLiBUaGUgd2F5IG9mIHJhbmRvbSBkZWxheSBtZXNzYWdlcyB3b3VsZA0KPiBhcHBseSB0byB0 aGlzIGRvY3VtZW50IGFzIHdlbGwu4oCdDQo+IA0KPiBTbyBhZGRpbmcgcG9pbnRlciB0byB0aGVz ZSB0d28gZG9jdW1lbnRzL3NlY3Rpb25zIHdvdWxkIGJlIGdvb2QgYXMgd2VsbA0KPiBtYXliZS4N Cg0KSG93IGFib3V0IGFkZGluZyB0aGUgYmVsb3cgc2VudGVuY2U/DQoNCiJUaGUgc2ltaWxhciBy YXRlIGxpbWl0aW5nIHBhcmFkaWdtIGlzIGFscmVhZHkgYWRvcHRlZCBpbiBbUkZDODAyOV0gYW5k IFJGQ1s2NDI1XS4iDQoNCkJlc3QgcmVnYXJkcywNCk1hY2ggDQoNCj4gDQo+IFRoYW5rcyENCj4g TWlyamENCj4gDQo+IA0KPiA+DQo+ID4gQmVzdCByZWdhcmRzLA0KPiA+IE1hY2gNCj4gPj4NCj4g Pg0KDQo= From nobody Wed Mar 13 05:03:55 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B8F126E5C; Wed, 13 Mar 2019 05:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hR5zQDJFaf4G; Wed, 13 Mar 2019 05:03:44 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 2C4191277D2; Wed, 13 Mar 2019 05:03:44 -0700 (PDT) Received: from [129.192.10.2] (helo=[10.149.2.6]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1h42bf-0007GQ-It; Wed, 13 Mar 2019 13:03:35 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Mirja Kuehlewind In-Reply-To: Date: Wed, 13 Mar 2019 13:03:35 +0100 Cc: "mpls@ietf.org" , =?utf-8?Q?Mirja_K=C3=BChlewind_via_Datatracker?= , "mpls-chairs@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" , The IESG , "loa@pi.nu" Content-Transfer-Encoding: quoted-printable Message-Id: <33D26DA9-1F43-4C9E-93BD-DA1FC23BC7C0@kuehlewind.net> References: <155240641959.16274.10292530156982066442.idtracker@ietfa.amsl.com> To: Mach Chen X-Mailer: Apple Mail (2.3445.101.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1552478624;23e801fc; X-HE-SMSGID: 1h42bf-0007GQ-It Archived-At: Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-mpls-lsp-ping-lag-multipath-06=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 12:03:48 -0000 Hi Mach, See below. > On 13. Mar 2019, at 11:52, Mach Chen wrote: >=20 > Hi Mirja, >=20 >> -----Original Message----- >> From: Mirja Kuehlewind [mailto:ietf@kuehlewind.net] >> Sent: Wednesday, March 13, 2019 5:51 PM >> To: Mach Chen >> Cc: Mirja K=C3=BChlewind via Datatracker ; The IESG >> ; mpls@ietf.org; draft-ietf-mpls-lsp-ping-lag- >> multipath@ietf.org; mpls-chairs@ietf.org; loa@pi.nu >> Subject: Re: Mirja K=C3=BChlewind's No Objection on = draft-ietf-mpls-lsp-ping-lag- >> multipath-06: (with COMMENT) >>=20 >> Hi Mach, >>=20 >> Please see below >>=20 >>> On 13. Mar 2019, at 10:15, Mach Chen wrote: >>>=20 >>> Hi Mirja, >>>=20 >>> Thanks for your comments! >>>=20 >>>> -----Original Message----- >>>> From: Mirja K=C3=BChlewind via Datatracker = [mailto:noreply@ietf.org] >>>> Sent: Wednesday, March 13, 2019 12:00 AM >>>> To: The IESG >>>> Cc: draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org; >>>> mpls-chairs@ietf.org; loa@pi.nu; mpls@ietf.org >>>> Subject: Mirja K=C3=BChlewind's No Objection on >>>> draft-ietf-mpls-lsp-ping-lag- >>>> multipath-06: (with COMMENT) >>>>=20 >>>> Mirja K=C3=BChlewind has entered the following ballot position for >>>> draft-ietf-mpls-lsp-ping-lag-multipath-06: No Objection >>>>=20 >>>> 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.) >>>>=20 >>>>=20 >>>> Please refer to >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> = https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-lag-multipa >>>> th/ >>>>=20 >>>>=20 >>>>=20 >>>> = --------------------------------------------------------------------- >>>> - >>>> COMMENT: >>>> = --------------------------------------------------------------------- >>>> - >>>>=20 >>>> I wanted to comment on the same sentence/normative requirement as >>>> Alvaro did in his point (2). Given Alvaro's additional information >>>> that there is actually even a technical conflict with this >>>> requirement, I think this should be address before publication and >>>> might even be discuss-worthy. However, I'm really not an expert on >>>> MPLS and therefore leave the decision to state a discuss ballot = position to >> potentially other, more knowledgable ADs. >>>>=20 >>>> Thanks for addressing the TSV-ART review comments (and thanks J=C3=B6= rg >>>> for the review)! I support adding another sentence with a pointer = to >>>> rate-limit requirements in other docs. Thanks for proposing this >>>> change. Looking forward this see this in the doc! >>>=20 >>> Are you suggesting to add a reference, do you have any specific docs >> suggestion? >>=20 >> In your reply to Joerg=E2=80=99s tsv-art review (on Dec 14 already), = you proposed to >> add the following statement: >>=20 >> "For an LSP path, it may be over several LAGs. For each LAG, there = will be >> many member links. To exercise all the links, many Echo Request/Reply >> messages will be sent in a short period. It's possible that those = messages may >> traverse a common path as a burst. Under some circumstances this = might >> cause congestion at the common path. To avoid potential congestion, = it is >> RECOMMENDED that implementations to randomly delay the Echo Request >> and Reply messages at the Initiating LSRs and Responder LSRs.=E2=80=9D >>=20 >> You also said: >> "RFC8029 (Security Consideration) does recommend the implementation = to >> regulate the ping traffic to the control plane, it applies to this = document as >> well. >>=20 >> At the same time, RFC 6425 (P2MP LSP Ping, section 2.2) introduces = some >> ways to limit the message rate. The way of random delay messages = would >> apply to this document as well.=E2=80=9D >>=20 >> So adding pointer to these two documents/sections would be good as = well >> maybe. >=20 > How about adding the below sentence? >=20 > "The similar rate limiting paradigm is already adopted in [RFC8029] = and RFC[6425].=E2=80=9D That works, or, even better, you could say something more similar than = what you said earlier, e.g. =E2=80=9CRate limiting of ping traffic is further specified in RFC8092 = (secti?n 1) and RFC6425 (section 2.2) which apply to this document as = well.=E2=80=9D Thanks,=20 Mirja >=20 > Best regards, > Mach=20 >=20 >>=20 >> Thanks! >> Mirja >>=20 >>=20 >>>=20 >>> Best regards, >>> Mach >>>>=20 >>>=20 >=20 From nobody Wed Mar 13 06:16:21 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEDF130F5B; Wed, 13 Mar 2019 06:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 rQXrKutLx_RY; Wed, 13 Mar 2019 06:16:11 -0700 (PDT) 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 518FE130F02; Wed, 13 Mar 2019 06:16:11 -0700 (PDT) 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 x2DDG85w002823; Wed, 13 Mar 2019 13:16:09 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C8B9622044; Wed, 13 Mar 2019 13:16:08 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id B302122042; Wed, 13 Mar 2019 13:16:08 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id x2DDG7Qp030502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 13 Mar 2019 13:16:07 GMT Reply-To: From: "Adrian Farrel" To: "'Mirja Kuehlewind'" Cc: "=?utf-8?Q?'Mirja_K=C3=BChlewind_via_Datatracker?= =?utf-8?Q?'?=" , "'The IESG'" , , , , References: <155238798836.13888.12133834062700877951.idtracker@ietfa.amsl.com> <001601d4d8d4$2808d1c0$781a7540$@olddog.co.uk> <35AA21D8-14B0-4AF3-A46C-A0349B7697FD@kuehlewind.net> In-Reply-To: <35AA21D8-14B0-4AF3-A46C-A0349B7697FD@kuehlewind.net> Date: Wed, 13 Mar 2019 13:16:05 -0000 Organization: Old Dog Consulting Message-ID: <01ba01d4d99e$eade89e0$c09b9da0$@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: AQFAhuvuBzGCp3DgpBA+VBQ9KaQwWAH98EEQAV9smsunFw5rsA== Content-Language: en-gb X-Originating-IP: 87.112.237.8 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-24486.007 X-TM-AS-Result: No--14.015-10.0-31-10 X-imss-scan-details: No--14.015-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24486.007 X-TMASE-Result: 10--14.015100-10.000000 X-TMASE-MatchedRID: oHOSwQSJZWjxIbpQ8BhdbOYAh37ZsBDCC/ExpXrHizwJF2U8dKhm+Xtx Bj0owbAa8JDf06DACvODD2YsveSRAUi2Drj9KXXXA9lly13c/gGMoAOyyQDaY665pTV4nlyUmPY Pzc9U9ykZxkaSIDa7cPWHSLoU43ZYey2hwIiqvBOzI1v7J4hECvqPNYK78GMcut/GVGOoEnfReg 8IMPTbiiqGuIpmy1HAnQfu3ND6+pRJtzxaLxhtW5D6BbDN9+jO1kqyrcMalqUY0A95tjAn+1FPj tF42O5h5GQB1hOgRUQ9OBgxoSFyPNPxsjeTKRpTBfKxbfcZgylAq6/y5AEOOiJ8zskw0dbrJBDL QwAO11uEp6t9i7m0ai71R/jxbyBo3drJ6tQCW55I9rD1ir7Z9JZ6zKu0q4rtyWCL+8tLbvbtlt4 n4EC2BeL8GfmD/blkLUq1F8gGNyX/tH4UJZUAmZ4CIKY/Hg3AWQy9YC5qGvybk3ZgcwPRvwzKt8 /2P4LVIAcCikR3vq/apLNdXBrZ9ZGnpuAilcP+mJauI4tifr47dFn39uYUUFNNX6w4g5Ng X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?mpls-sr-over-ip-03=3A_=28with_DISCUSS=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 13:16:14 -0000 Thanks Mirja, >>> 1) Given section 3.1, the following drafts all seems that they >>> should be normative references: ietf-isis-encapsulation-cap, >>> ietf-ospf-encapsulation-cap, ietf-ospf-segment-routing-extensions, >>> ietf-isis-segment-routing-extensions >>=20 >> Well, that wasn't the intention. It is meant to be an example of >> how the forwarding entries are constructed. >>=20 >> As it says at the top of Section 3... >> Note that the examples in >> Section 3.1 and Section 3.2 assume that OSPF or ISIS is enabled: in >> fact, other mechanisms of discovery and advertisement could be used >> including other routing protocols (such as BGP) or a central >> controller. >>=20 >> We could be more explicit in section 3.1 so that, for example... >>=20 >> OLD >> o The Segment Routing Global Block (SRGB) is defined in [RFC8402]. >> Router E is SR-MPLS capable, so it advertises an SRGB as = described >> in [I-D.ietf-ospf-segment-routing-extensions] and >> [I-D.ietf-isis-segment-routing-extensions]. >> NEW >> o The Segment Routing Global Block (SRGB) is defined in [RFC8402]. >> Router E is SR-MPLS capable, so it advertises an SRGB to the = other >> SR-MPLS capable routers. If an IGP is in use then Router E = behaves >> as described in [I-D.ietf-ospf-segment-routing-extensions] and >> [I-D.ietf-isis-segment-routing-extensions], but other mechanisms >> Could be applied. >> END >>=20 >> We'd need to make similar changes throughout the section. >>=20 >> Would such changes be enough for you? > > It still sounds to me that these document are basically a must read=20 > to understand the full picture. Do you think it would be a problem > or the wrong thing to make these reference normative? > > However, your wording change makes it definitely more clear that > this is only one example. If the wg and responsible ADs think, = it=E2=80=99s > the right thing to do to leave the reference informative, I will clear > my discuss. I was worried about the rate of progress of SR documents. There has been = a tendency for them to travel a little slowly. It looks like these documents have all now progressed far enough, but = they are caught up in a deadly cluster of missing references (cluster = 340). We'll have a look through the cluster to see how dangerous it is = and make normative references where we can. >>> 2) Sec 3.2.3 on IP Header fields should refer to RFC6040 for the ECN >>> field and eventually RFC2983 for DSCP. >>=20 >> That's good. Thanks. It gives us... >>=20 >> When encapsulating an = MPLS >> packet in UDP, the resulting packet is further = encapsulated in >> IP for transmission. IPv4 or IPv6 may be used according to = the >> capabilities of the network. The address fields are set as >> described in . The other IP = header >> fields (such as the ECN field , = the DSCP=20 >> code point , or IPv6 Flow Label) = on each >> UDP-encapsulated segment SHOULD be configurable according = to the >> operator's policy: they may be copied from the header = of the >> incoming packet; they may be promoted from the header of = the >> payload packet; they may be set according to instructions >> programmed to be associated with the SID; or they may be >> configured dependent on the outgoing interface and = payload. > > Yes, thanks! Perfect. It's in my working copy. Best, Adrian From nobody Wed Mar 13 08:02:59 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E26124B0C; Wed, 13 Mar 2019 08:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[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=O7g2I6Ax; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=p3qEJ+Le 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 RU__A-F7yzgs; Wed, 13 Mar 2019 08:02:49 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15A091277D6; Wed, 13 Mar 2019 08:02:49 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5052624453; Wed, 13 Mar 2019 11:02:47 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 13 Mar 2019 11:02:47 -0400 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=T pw4aR0VgMgm6/CBlBmZE6n5sP5V9C3Du1hv8Xp22K4=; b=O7g2I6AxZ6p1Afccb 1YQ124ur7zYxRXt42Mj8Sfu9qFI3Nvk4mT3GH7cLkvsZs3COSCxMD4G2L3OIFkn9 VReUmdrmDNWse3ryG5eXlgw/AHqNfShPlJ4E8G4TbQKDa3ve/6alcQS0ZN2D9wrs fMXvTmzKZDnIWp+MAmvXQusR+BaaJkDbzc1HznccIXx+Q459Yre3Lx0Grpg56zCc b802OZ8PhIm3gDrU7CGWhYIT2IpNP92MTAxNJyRZbYmDqbX54fy5PLPU1uWpYzqf mpiwIT33jIqL/dmGPWiQ/uA5MLvZVmWL5oL/i1Go1XvBFcs23sZn6gmcznzNwXEj v70Rg== 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=fm2; bh=Tpw4aR0VgMgm6/CBlBmZE6n5sP5V9C3Du1hv8Xp22 K4=; b=p3qEJ+LePW98w0dmOf0KsvhT2+qyMyz++Cw3lKbUTPZ1eNTIxvA2R7Cye g2dWrVQI7UHoHL0wTPVIgJTyzOx8yCJ+Xx4oDMmtDgvyQaYC9QGH27SJ6mX/wJuI zd6WMrbBSAJL6dinY6JEV2ysxZX3bm2/Or5LDX53IbwkRIDkiDYfFQYJEfef7f7m HFOjUtKwx3g/O1KzDABnPPLkBzUcGB4rlhegJtbt+My7/5oaL3N7THxGgn9jaLrt Lff0QR8Gbm4C93iQmMcFdz57dNJhY9YqHab6GmNmWiHROwuFx3ZOlBZMKfYc6a2p 6Zao8Ew5dTLqN1TGpx3ZPMmud2flw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrhedtgdejudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdeiheenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.65]) by mail.messagingengine.com (Postfix) with ESMTPA id 4B84EE4665; Wed, 13 Mar 2019 11:02:45 -0400 (EDT) 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: <154514639446.5451.147366902800553455@ietfa.amsl.com> Date: Wed, 13 Mar 2019 11:02:43 -0400 Cc: General Area Review Team , IETF MPLS List , draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154514639446.5451.147366902800553455@ietfa.amsl.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [mpls] [Gen-art] Genart last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 15:02:51 -0000 Christer, thank you for your review. I entered a No Objection ballot. Alissa > On Dec 18, 2018, at 10:19 AM, Christer Holmberg = wrote: >=20 > Reviewer: Christer Holmberg > 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 > . >=20 > Document: draft-ietf-mpls-lsp-ping-lag-multipath-05 > Reviewer: Christer Holmberg > Review Date: 2018-12-18 > IETF LC End Date: 2018-12-11 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: The document is well written, and is ready for publication. >=20 > Major issues:None >=20 > Minor issues: None >=20 > Nits/editorial comments: None >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Mar 13 08:18:10 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F86B124B0C; Wed, 13 Mar 2019 08:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[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=nBmZWTOR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=1uxFvYaM 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 d1QuJTDuvrWg; Wed, 13 Mar 2019 08:18:05 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40E101277D6; Wed, 13 Mar 2019 08:18:05 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 560DE2859B; Wed, 13 Mar 2019 11:18:04 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 13 Mar 2019 11:18:04 -0400 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=g Uy37aT0Pz58WzxgqXl1HxL432W3+ktbz1UFQGKA0Ik=; b=nBmZWTORGVg7KdnAw MTdCiTZGJsQkYH5fnvZoOXbS4ZBn8cAQoD5LW/08HYC1hWBHPFtnq8qL8t/RK9pM buI+TomPKf0Pyopkwg4AzzjhvDe5hyI1eDyqQWQCFeeU9sXEHvKI/ZYrz4jmbX3I wBsk7IhJTr43X1zX6WTpGXxlD6Th7dCKPHO37L4VXPUDGvJZlEV4Uq5M2FJsLxYb fUng3Lo5c5qp2P+AAQH74aKuyEpOHtXEcGdUmWeQzT5W0xiq+U4UF4TSSzNDoK/g vvRsNAW1tKJHJrSbg9BDozsRKb1f39/rtrZCA3KiEq0ZkKlAum0hVhJPjffon4sk fXbRQ== 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=fm2; bh=gUy37aT0Pz58WzxgqXl1HxL432W3+ktbz1UFQGKA0 Ik=; b=1uxFvYaMivmUSxAwg3P97kMFyGc05osqR6f4A6yxCSxdwuMZb4+FJh5xR /oFyoZgWtstJazbz8PtjiUu2tBKYuqEfTFOLYe1XZ++8zA3MebLD5cowz9f+xQqb 7uX5Ro2rzEI9NBAYPCngwghXzj0QyMzg135+lU8ik+4eTfXEgR2enKFmaxGYHabt ey+0RzLNl6WBgsa3tu9vEq3b9Rwqo4Db8PHCgrwSsM4StcuAbVdUr4X8M/Ry8rF0 BZwBvCCcZK4DMVkeEkfoLaxSWtMUbNYJKvPXSZnccr++JTiwn++couI6ES8RhDZf 2DX9jrL7ORRpMemotOulN/Z2KSVXw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrhedtgdejhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdeiheenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.65]) by mail.messagingengine.com (Postfix) with ESMTPA id 0DEF7E456D; Wed, 13 Mar 2019 11:18:03 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <03b801d4cde5$805c6250$811526f0$@olddog.co.uk> Date: Wed, 13 Mar 2019 11:18:01 -0400 Cc: General Area Review Team , IETF MPLS List , IETF , draft-ietf-mpls-sr-over-ip.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <77F6EC08-297A-49CA-A864-103071713A19@cooperw.in> References: <155067766687.31388.18349714938448955572@ietfa.amsl.com> <04c001d4c938$7e3d86e0$7ab894a0$@olddog.co.uk> <03b801d4cde5$805c6250$811526f0$@olddog.co.uk> To: Adrian Farrel , Robert Sparks X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [mpls] [Gen-art] Genart last call review of draft-ietf-mpls-sr-over-ip-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 15:18:08 -0000 Robert, thank you for your review. Adrian, thank you for your responses. = I entered a No Objection ballot. Alissa > On Feb 26, 2019, at 10:11 AM, Adrian Farrel = wrote: >=20 > Hey Robert, >=20 > Some detailed responses. >=20 > The revision will be posted when the authors have signed off. >=20 > Regards, > Adrian >=20 >> The 2nd sentence of the introduction is complex. It should >> be easy to simplify. >=20 > Done >=20 >> It would help to place the reference to = draft-ietf-mpls-spring-entropy >> label at "If encoding of entropy is desired". (Or if some other = reference >> is better, use that) >=20 > Used RFC 6790. >=20 >> In that same paragraph, something is wrong at "make use of entropy >> label mechanism." Should that be "the entropy label mechanism"? >=20 > Yes. I have done some gardening. >=20 >> SRGB is used without expansion. >=20 > Fixed. >=20 >> Where is "the lower bound" of an SRGB defined? The string "lower = bound" >> doesn't occur in either of the routing-extensions drafts referenced = where >> SRGB is first used. >=20 > The concept of an SRGB is defined in RFC 8402. I've added a reference = to this at the first use of 'SRGB'. >=20 >> Section 3.1 is about ostensibly about constructing a FIB entry, but = its >> last step is sending a packet. >=20 > Yes. Overly enthusiastic engineers! =F0=9F=98=8A > I have jiggled the text so that the last couple of points are about = how the FIB is used. >=20 >> The first sentence in section 3.2 is more complex than it needs to = be. It >> should be easy to simplify. >=20 > OK >=20 >> It would be nice if you could make the differences between the = routers in >> figures 3 and 4 visually apparent rather than relying on text to = explain the >> difference. Something like (view in a fixed width font): >=20 > We looked at this, but decided against. If we adopt some kind of = notation, we will still need to explain it in the text, and the = explanation will only complicate things. >=20 >> At the first paragraph on page 9: s/and then process/and then = processes/ >=20 > Yes >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Mar 13 11:26:32 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 76551130F2A; Wed, 13 Mar 2019 11:26:24 -0700 (PDT) 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-mpls-sr-over-ip@ietf.org, Loa Andersson , mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155250158441.24829.14608035114926106633.idtracker@ietfa.amsl.com> Date: Wed, 13 Mar 2019 11:26:24 -0700 Archived-At: Subject: [mpls] Benjamin Kaduk's No Objection on draft-ietf-mpls-sr-over-ip-03: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 18:26:25 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-mpls-sr-over-ip-03: 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-mpls-sr-over-ip/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this clearly-written document! I do have several suggestions for improvements, and note many places where IS-IS and OSPF seem to be described as normative references would, in the vein of Mirja's DISCUSS. I think it is possible to adjust the document to keep those as informative references, but the changes might be pretty intrusive. I'm a little confused about what exactly the new protocol specified here is -- there seems to be a lot of "use these existing technologies together in the following way" going on, that may be screening the actual new bits from prominence. The only thing that comes to mind is the requirement to use the explicit null label when the last label has PHP and is going over the tunnel, which is admittely important behavior to have! (To be clear, the implication is that a document consisting solely of "glue these existing pieces together" could well be published as Informational, though does not strictly speaking need to be.) It might also be helpful to have a reference to RFC 4023 for the plain MPLS-in-IP encapsulation, even just to contrast it to the MPLS-in-UDP (RFC 7510) that we do use. (This reader did not discern why the RFC 4023 encapsulation was unpreferred.) Section-by-section comments follow. Abstract SR-MPLS could be leveraged to realize a source routing mechanism across MPLS, IPv4, and IPv6 data planes by using an MPLS label stack as a source routing instruction set while preserving backward compatibility with SR-MPLS. Is this really saying "SR-MPLS could be leveraged ... while preserving compatibility with SR-MPLS"? Section 1 (Introduction) Similarly to the above: SR-MPLS uses an MPLS label stack to encode a source routing instruction set. This can be used to realize a source routing mechanism that can operate across MPLS, IPv4, and IPv6 data planes. This approach preserves backward compatibility with SR-MPLS. No matter what SR-MPLS does, it is definitionally backward compatible with SR-MPLS. Section 2 o If encoding of entropy ([RFC6790] is desired, IP tunneling mechanisms that allow encoding of entropy, such as MPLS-in-UDP encapsulation [RFC7510] where the source port of the UDP header is I think it was already noted, but this language reads a little oddly, and it might be better as "If injection of additional entropy into the flow is needed". Section 3.1 Consider router A that receives a labeled packet with top label L(E) that corresponds to the prefix-SID SID(E) of prefix P(E) advertised by router E. Suppose the i-th next-hop router (termed NHi) along the shortest path from router A toward SID(E) is not SR-MPLS capable while both routers A and E are SR-MPLS capable. [...] Do we ever actually use the fact that it is specifically the i-th router that is SR-MPLS-incapable, or just need to know that at least one router on the path is deficient in that way? o The Segment Routing Global Block (SRGB) is defined in [RFC8402]. Router E is SR-MPLS capable, so it advertises an SRGB as described in [I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-isis-segment-routing-extensions]. I see the first sentence was added in discussion with another reviewer; I wonder if the text would flow better if the order of the sentences was swapped (particularly since this is the very first "processing step", and that declarative sentence does not describe any processing actions). o When Router E advertises the prefix-SID SID(E) of prefix P(E) it MUST also advertise the encapsulation endpoint and the tunnel type of any tunnel used to reach E. It does this using the mechanisms described in [I-D.ietf-isis-encapsulation-cap] or [I-D.ietf-ospf-encapsulation-cap]. This "it does this" still is implying that IS-IS and OSPF are the only ways this can be done, which (AIUI) is not the intention. (Similarly for the next bullet point's sub-bullets.) * If router E is running ISIS and advertises the ISIS capabilities TLV (TLV 242) [RFC7981], it MUST set the "router- nit: 7981 seems to call this the "ISIS Router CAPABILITY TLV"; I don't know if the usage here has since become conventional. o Router A programs the FIB entry for prefix P(E) corresponding to the SID(E) as follows: Keeping with the theme, this is a declarative statement of procedure, and the following sub-bullets only cover OSPF and ISIS. It would need to be a statement of requirements for behavior/functionality in order to keep them from being normative references. Once constructed, the FIB can be used to tell a router how to process packets. It encapsulates the packets according to the encapsulation advertised in [I-D.ietf-isis-encapsulation-cap] or [I-D.ietf-ospf-encapsulation-cap]. Then it sends the packets towards the next hop NHi. Oh, finally, "NHi" appears again. But are we actually forwarding towards the SR-MPLS-incapable router specifically, or just generically to the immediate next hop (which may or may not be NHi)? Also, I'll note that we introduced this list with "the following processing steps apply [for A wanting to send a packet towards E]", but most of the procedures therein involve things that E has to do to advertise the information that A will need in order to make the encapsulation, which feels like somewhat mismatched language. In short, this list of points doesn't tell me much about what specifically *A* does with this packet -- the last point handles what to do with the top label, but I guess we defer to the encapsulation scheme for the gory details (which is probably fine, but maybe the language could be tidied up to mention something about "using the appropriate mechanism for the selected tunnel type (e.g., IP)"). packets. It encapsulates the packets according to the encapsulation advertised in [I-D.ietf-isis-encapsulation-cap] or [I-D.ietf-ospf-encapsulation-cap]. Then it sends the packets towards nit: advertised *using the mechanisms in* Section 3.2 [RFC7510] specifies an IP-based encapsulation for MPLS, i.e., MPLS- in-UDP. This approach is applicable where IP-based encapsulation for MPLS is required and further fine-grained load balancing of MPLS packets over IP networks over Equal-Cost Multipath (ECMP) and/or Link Aggregation Groups (LAGs) is also required. This section provides details about the forwarding procedure when when UDP encapsulation is adopted for SR-MPLS over IP. (side note) Presumably this is just my lack of background showing, but this text seems to assume that the UDP encapsulation is the only way to do SR-MPLS over IP, with no discussion of RFC 4023. Nodes that are SR-MPLS capable can process SR-MPLS packets. Not all of the nodes in an SR-MPLS domain are SR-MPLS capable. Some nodes may be "legacy routers" that cannot handle SR-MPLS packets but can forward IP packets. An SR-MPLS-capable node MAY advertise its capabilities using the IGP as described in Section 3. There are six types of node in an SR-MPLS domain: (side note) Similarly, we only talk about SR-MPLS and IP routers here; is there some intermediate "MPLS but not SR-MPLS" category or similar? Also, the top-level Section 3 is just introductory text and doesn't really describe much of anything, and if we are considering this to refer to Section 3 and subsections, it then becomes self-referential. Section 3.2.1 Routers A, E, G, and H advertise their Segment Routing related information via IS-IS or OSPF. [still declarative] To handle this, when a router (here it is router G) pops the final SR-MPLS label, it inserts an explicit null label [RFC3032] before encapsulating the packet in an MPLS-over-UDP tunnel toward router H and sending it out. That is, router G pops the top label, discovers it has reached the bottom of stack, pushes an explicit null label, and then encapsulates the MPLS packet in a UDP tunnel to router H. This seems like a critical functional behavior that is not specific to the usage of IS-IS or OSPF. Section 3.2.3 For instance, in the example as described in Figure 4, assume F is now an SR-MPLS-capable transit node while all the other assumptions keep unchanged, since F is not identified by a SID in the stack and an MPLS-over-UDP tunnel is preferred to an MPLS LSP according to local policies, router E would replace the current top label with an MPLS-over-UDP tunnel toward router G and send it out. (nit: There's a comma splice before "since F".) This description is a little sparse, and seems to assume the reader knows that, all else being equal, with E, F, and G all being MPLS-capable, the segment from E to G would transit native MPLS, absent the indicated local policy. Since this is explicitly the thing we are contrasting against, it's probably good style to mention the behavior explicitly, too. IP Header Fields: When encapsulating an MPLS packet in UDP, the resulting packet is further encapsulated in IP for transmission. IPv4 or IPv6 may be used according to the capabilities of the network. The address fields are set as described in Section 2. (Does Section 2 say how to set the source address?) Entropy and ECMP: When encapsulating an MPLS packet with an IP tunnel header that is capable of encoding entropy (such as [RFC7510]), the corresponding entropy field (the source port in case UDP tunnel) MAY be filled with an entropy value that is nit: "in the case of a UDP tunnel" Section 5 [I'm going to comment on basically every line here; sorry to be so nitpicky.] The security consideration of [RFC8354] and [RFC7510] apply. DTLS RFC 8354's security considerations are, for practical purposes, empty. Perhaps a direct reference to 5095 would be more appropriate. (The RFC 7510 security considerations are of course quite relevant and helpful.) [RFC6347] SHOULD be used where security is needed on an MPLS-SR-over- UDP segment. I think you need to give some indication of when that might be the case, e.g., if the IP segment crosses the public Internet or some other untrusted environment. It is difficult for an attacker to pass a raw MPLS encoded packet into a network and operators have considerable experience at excluding such packets at the network boundaries. This is describing an expected/desired state (hopefully also the current state!) but not why that should be or what the consequences of failing to achieve that state are. I'm happy to contribute some text, but this seems like a generic MPLS consideration and I hope there is an already-published reference that could be used instead. It is easy for an ingress node to detect any attempt to smuggle an IP packet into the network since it would see that the UDP destination port was set to MPLS. SR packets not having a destination address Easy, sure, if you know to look for it. Where is that requirement mandated? terminating in the network would be transparently carried and would pose no security risk to the network under consideration. I'm not sure I see how the second sentence relates to the first; is this just trying to say that SR-MPLS is transparent to traffic flowing over such a network? There would still be generic capacity risks, of course, though maybe we don't need to be so specific -- "pose no different security risk than any other traffic" would be plenty. Where control plane techniques are used (as described in Section 3), it is important that these protocols are adequately secured for the environment in which they are run. What does "adequately secured" mean? Is there a best-practices document, or security considerations for the control protocols in question that cover this? Is the needed property that "any packets interpreted as MPLS must be originated from authorized network devices within the administrative domain (or group of such domains), with no ability for attackers to inject such traffic inside the domain and blocking at the boundary"? When different administrative domains are joined together, what are the counterparty risks? From nobody Wed Mar 13 18:44:20 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AC9131162; Wed, 13 Mar 2019 18:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 anMniq1dWL9U; Wed, 13 Mar 2019 18:44:06 -0700 (PDT) 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 1F8ED131164; Wed, 13 Mar 2019 18:44:06 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 3AA1EE3E6C3E4CBCB0A3; Thu, 14 Mar 2019 01:44:04 +0000 (GMT) Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 14 Mar 2019 01:44:03 +0000 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.190]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0415.000; Thu, 14 Mar 2019 09:44:00 +0800 From: Mach Chen To: Mirja Kuehlewind CC: "mpls@ietf.org" , =?utf-8?B?TWlyamEgS8O8aGxld2luZCB2aWEgRGF0YXRyYWNrZXI=?= , "mpls-chairs@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" , The IESG , "loa@pi.nu" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-mpls-lsp-ping-lag-multipath-06:_(with_COMMENT)?= Thread-Index: AQHU2Oy6s520bV8QO0y5RWWbir7qHKYJRALQ//+IqQCAAJatQP//jkSAgAFrBfA= Date: Thu, 14 Mar 2019 01:43:59 +0000 Message-ID: References: <155240641959.16274.10292530156982066442.idtracker@ietfa.amsl.com> <33D26DA9-1F43-4C9E-93BD-DA1FC23BC7C0@kuehlewind.net> In-Reply-To: <33D26DA9-1F43-4C9E-93BD-DA1FC23BC7C0@kuehlewind.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-mpls-lsp-ping-lag-multipath-06=3A_=28with_COMMENT=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 01:44:10 -0000 SGkgTWlyamEsDQoNClRoYW5rcyBmb3IgeW91ciBzdWdnZXN0aW9uLCB3aWxsIGFkZCB0byB0aGUg bmV4dCByZXZpc2lvbi4NCg0KQmVzdCByZWdhcmRzLA0KTWFjaCAgDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWlyamEgS3VlaGxld2luZCBbbWFpbHRvOmlldGZAa3Vl aGxld2luZC5uZXRdDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMTMsIDIwMTkgODowNCBQTQ0K PiBUbzogTWFjaCBDaGVuIDxtYWNoLmNoZW5AaHVhd2VpLmNvbT4NCj4gQ2M6IG1wbHNAaWV0Zi5v cmc7IE1pcmphIEvDvGhsZXdpbmQgdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGlldGYub3JnPjsN Cj4gbXBscy1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1sYWctbXVs dGlwYXRoQGlldGYub3JnOyBUaGUNCj4gSUVTRyA8aWVzZ0BpZXRmLm9yZz47IGxvYUBwaS5udQ0K PiBTdWJqZWN0OiBSZTogTWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1p ZXRmLW1wbHMtbHNwLXBpbmctbGFnLQ0KPiBtdWx0aXBhdGgtMDY6ICh3aXRoIENPTU1FTlQpDQo+ IA0KPiBIaSBNYWNoLA0KPiANCj4gU2VlIGJlbG93Lg0KPiANCj4gPiBPbiAxMy4gTWFyIDIwMTks IGF0IDExOjUyLCBNYWNoIENoZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPiB3cm90ZToNCj4gPg0K PiA+IEhpIE1pcmphLA0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ IEZyb206IE1pcmphIEt1ZWhsZXdpbmQgW21haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0XQ0KPiA+ PiBTZW50OiBXZWRuZXNkYXksIE1hcmNoIDEzLCAyMDE5IDU6NTEgUE0NCj4gPj4gVG86IE1hY2gg Q2hlbiA8bWFjaC5jaGVuQGh1YXdlaS5jb20+DQo+ID4+IENjOiBNaXJqYSBLw7xobGV3aW5kIHZp YSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz47IFRoZSBJRVNHDQo+ID4+IDxpZXNnQGll dGYub3JnPjsgbXBsc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLWxhZy0NCj4g Pj4gbXVsdGlwYXRoQGlldGYub3JnOyBtcGxzLWNoYWlyc0BpZXRmLm9yZzsgbG9hQHBpLm51DQo+ ID4+IFN1YmplY3Q6IFJlOiBNaXJqYSBLw7xobGV3aW5kJ3MgTm8gT2JqZWN0aW9uIG9uDQo+ID4+ IGRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1sYWctDQo+ID4+IG11bHRpcGF0aC0wNjogKHdpdGgg Q09NTUVOVCkNCj4gPj4NCj4gPj4gSGkgTWFjaCwNCj4gPj4NCj4gPj4gUGxlYXNlIHNlZSBiZWxv dw0KPiA+Pg0KPiA+Pj4gT24gMTMuIE1hciAyMDE5LCBhdCAxMDoxNSwgTWFjaCBDaGVuIDxtYWNo LmNoZW5AaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4gSGkgTWlyamEsDQo+ID4+Pg0K PiA+Pj4gVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIQ0KPiA+Pj4NCj4gPj4+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+IEZyb206IE1pcmphIEvDvGhsZXdpbmQgdmlhIERhdGF0 cmFja2VyIFttYWlsdG86bm9yZXBseUBpZXRmLm9yZ10NCj4gPj4+PiBTZW50OiBXZWRuZXNkYXks IE1hcmNoIDEzLCAyMDE5IDEyOjAwIEFNDQo+ID4+Pj4gVG86IFRoZSBJRVNHIDxpZXNnQGlldGYu b3JnPg0KPiA+Pj4+IENjOiBkcmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctbGFnLW11bHRpcGF0aEBp ZXRmLm9yZzsNCj4gPj4+PiBtcGxzLWNoYWlyc0BpZXRmLm9yZzsgbG9hQHBpLm51OyBtcGxzQGll dGYub3JnDQo+ID4+Pj4gU3ViamVjdDogTWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBv bg0KPiA+Pj4+IGRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1sYWctDQo+ID4+Pj4gbXVsdGlwYXRo LTA2OiAod2l0aCBDT01NRU5UKQ0KPiA+Pj4+DQo+ID4+Pj4gTWlyamEgS8O8aGxld2luZCBoYXMg ZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gPj4+PiBkcmFmdC1p ZXRmLW1wbHMtbHNwLXBpbmctbGFnLW11bHRpcGF0aC0wNjogTm8gT2JqZWN0aW9uDQo+ID4+Pj4N Cj4gPj4+PiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50 YWN0IGFuZCByZXBseSB0bw0KPiA+Pj4+IGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4g dGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0bw0KPiA+Pj4+IGN1dCB0aGlzIGludHJv ZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBQbGVh c2UgcmVmZXIgdG8NCj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9k aXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gPj4+PiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJ RVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+ PiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJl IGZvdW5kIGhlcmU6DQo+ID4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1tcGxzLWxzcC1waW5nLWxhZy1tdWx0aQ0KPiA+Pj4+IHBhDQo+ID4+Pj4gdGgvDQo+ ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+IC0tDQo+ID4+ Pj4gLQ0KPiA+Pj4+IENPTU1FTlQ6DQo+ID4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+IC0tDQo+ID4+ Pj4gLQ0KPiA+Pj4+DQo+ID4+Pj4gSSB3YW50ZWQgdG8gY29tbWVudCBvbiB0aGUgc2FtZSBzZW50 ZW5jZS9ub3JtYXRpdmUgcmVxdWlyZW1lbnQNCj4gYXMNCj4gPj4+PiBBbHZhcm8gZGlkIGluIGhp cyBwb2ludCAoMikuIEdpdmVuIEFsdmFybydzIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24NCj4gPj4+ PiB0aGF0IHRoZXJlIGlzIGFjdHVhbGx5IGV2ZW4gYSB0ZWNobmljYWwgY29uZmxpY3Qgd2l0aCB0 aGlzDQo+ID4+Pj4gcmVxdWlyZW1lbnQsIEkgdGhpbmsgdGhpcyBzaG91bGQgYmUgYWRkcmVzcyBi ZWZvcmUgcHVibGljYXRpb24gYW5kDQo+ID4+Pj4gbWlnaHQgZXZlbiBiZSBkaXNjdXNzLXdvcnRo eS4gSG93ZXZlciwgSSdtIHJlYWxseSBub3QgYW4gZXhwZXJ0IG9uDQo+ID4+Pj4gTVBMUyBhbmQg dGhlcmVmb3JlIGxlYXZlIHRoZSBkZWNpc2lvbiB0byBzdGF0ZSBhIGRpc2N1c3MgYmFsbG90DQo+ ID4+Pj4gcG9zaXRpb24gdG8NCj4gPj4gcG90ZW50aWFsbHkgb3RoZXIsIG1vcmUga25vd2xlZGdh YmxlIEFEcy4NCj4gPj4+Pg0KPiA+Pj4+IFRoYW5rcyBmb3IgYWRkcmVzc2luZyB0aGUgVFNWLUFS VCByZXZpZXcgY29tbWVudHMgKGFuZCB0aGFua3MgSsO2cmcNCj4gPj4+PiBmb3IgdGhlIHJldmll dykhIEkgc3VwcG9ydCBhZGRpbmcgYW5vdGhlciBzZW50ZW5jZSB3aXRoIGEgcG9pbnRlcg0KPiA+ Pj4+IHRvIHJhdGUtbGltaXQgcmVxdWlyZW1lbnRzIGluIG90aGVyIGRvY3MuIFRoYW5rcyBmb3Ig cHJvcG9zaW5nIHRoaXMNCj4gPj4+PiBjaGFuZ2UuIExvb2tpbmcgZm9yd2FyZCB0aGlzIHNlZSB0 aGlzIGluIHRoZSBkb2MhDQo+ID4+Pg0KPiA+Pj4gQXJlIHlvdSBzdWdnZXN0aW5nIHRvIGFkZCBh IHJlZmVyZW5jZSwgZG8geW91IGhhdmUgYW55IHNwZWNpZmljIGRvY3MNCj4gPj4gc3VnZ2VzdGlv bj8NCj4gPj4NCj4gPj4gSW4geW91ciByZXBseSB0byBKb2VyZ+KAmXMgdHN2LWFydCByZXZpZXcg KG9uIERlYyAxNCBhbHJlYWR5KSwgeW91DQo+ID4+IHByb3Bvc2VkIHRvIGFkZCB0aGUgZm9sbG93 aW5nIHN0YXRlbWVudDoNCj4gPj4NCj4gPj4gIkZvciBhbiBMU1AgcGF0aCwgaXQgbWF5IGJlIG92 ZXIgc2V2ZXJhbCBMQUdzLiBGb3IgZWFjaCBMQUcsIHRoZXJlDQo+ID4+IHdpbGwgYmUgbWFueSBt ZW1iZXIgbGlua3MuIFRvIGV4ZXJjaXNlIGFsbCB0aGUgbGlua3MsIG1hbnkgRWNobw0KPiA+PiBS ZXF1ZXN0L1JlcGx5IG1lc3NhZ2VzIHdpbGwgYmUgc2VudCBpbiBhIHNob3J0IHBlcmlvZC4gSXQn cyBwb3NzaWJsZQ0KPiA+PiB0aGF0IHRob3NlIG1lc3NhZ2VzIG1heSB0cmF2ZXJzZSBhIGNvbW1v biBwYXRoIGFzIGEgYnVyc3QuIFVuZGVyIHNvbWUNCj4gPj4gY2lyY3Vtc3RhbmNlcyB0aGlzIG1p Z2h0IGNhdXNlIGNvbmdlc3Rpb24gYXQgdGhlIGNvbW1vbiBwYXRoLiBUbw0KPiA+PiBhdm9pZCBw b3RlbnRpYWwgY29uZ2VzdGlvbiwgaXQgaXMgUkVDT01NRU5ERUQgdGhhdCBpbXBsZW1lbnRhdGlv bnMgdG8NCj4gPj4gcmFuZG9tbHkgZGVsYXkgdGhlIEVjaG8gUmVxdWVzdCBhbmQgUmVwbHkgbWVz c2FnZXMgYXQgdGhlIEluaXRpYXRpbmcNCj4gTFNScyBhbmQgUmVzcG9uZGVyIExTUnMu4oCdDQo+ ID4+DQo+ID4+IFlvdSBhbHNvIHNhaWQ6DQo+ID4+ICJSRkM4MDI5IChTZWN1cml0eSBDb25zaWRl cmF0aW9uKSBkb2VzIHJlY29tbWVuZCB0aGUgaW1wbGVtZW50YXRpb24NCj4gPj4gdG8gcmVndWxh dGUgdGhlIHBpbmcgdHJhZmZpYyB0byB0aGUgY29udHJvbCBwbGFuZSwgaXQgIGFwcGxpZXMgdG8N Cj4gPj4gdGhpcyBkb2N1bWVudCBhcyB3ZWxsLg0KPiA+Pg0KPiA+PiBBdCB0aGUgc2FtZSB0aW1l LCBSRkMgNjQyNSAoUDJNUCBMU1AgUGluZywgc2VjdGlvbiAyLjIpIGludHJvZHVjZXMNCj4gPj4g c29tZSB3YXlzIHRvIGxpbWl0IHRoZSBtZXNzYWdlIHJhdGUuIFRoZSB3YXkgb2YgcmFuZG9tIGRl bGF5IG1lc3NhZ2VzDQo+ID4+IHdvdWxkIGFwcGx5IHRvIHRoaXMgZG9jdW1lbnQgYXMgd2VsbC7i gJ0NCj4gPj4NCj4gPj4gU28gYWRkaW5nIHBvaW50ZXIgdG8gdGhlc2UgdHdvIGRvY3VtZW50cy9z ZWN0aW9ucyB3b3VsZCBiZSBnb29kIGFzDQo+ID4+IHdlbGwgbWF5YmUuDQo+ID4NCj4gPiBIb3cg YWJvdXQgYWRkaW5nIHRoZSBiZWxvdyBzZW50ZW5jZT8NCj4gPg0KPiA+ICJUaGUgc2ltaWxhciBy YXRlIGxpbWl0aW5nIHBhcmFkaWdtIGlzIGFscmVhZHkgYWRvcHRlZCBpbiBbUkZDODAyOV0gYW5k DQo+IFJGQ1s2NDI1XS7igJ0NCj4gDQo+IFRoYXQgd29ya3MsIG9yLCBldmVuIGJldHRlciwgeW91 IGNvdWxkIHNheSBzb21ldGhpbmcgbW9yZSBzaW1pbGFyIHRoYW4gd2hhdA0KPiB5b3Ugc2FpZCBl YXJsaWVyLCBlLmcuDQo+IA0KPiDigJxSYXRlIGxpbWl0aW5nIG9mIHBpbmcgdHJhZmZpYyBpcyBm dXJ0aGVyIHNwZWNpZmllZCBpbiBSRkM4MDkyIChzZWN0aT9uIDEpIGFuZA0KPiBSRkM2NDI1IChz ZWN0aW9uIDIuMikgd2hpY2ggYXBwbHkgdG8gdGhpcyBkb2N1bWVudCBhcyB3ZWxsLuKAnQ0KPiAN Cj4gVGhhbmtzLA0KPiBNaXJqYQ0KPiANCj4gDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4g TWFjaA0KPiA+DQo+ID4+DQo+ID4+IFRoYW5rcyENCj4gPj4gTWlyamENCj4gPj4NCj4gPj4NCj4g Pj4+DQo+ID4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+PiBNYWNoDQo+ID4+Pj4NCj4gPj4+DQo+ID4N Cg0K From nobody Wed Mar 13 18:58:24 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3CE131162; Wed, 13 Mar 2019 18:58:22 -0700 (PDT) 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-mpls-sr-over-ip@ietf.org, Loa Andersson , mpls-chairs@ietf.org, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alvaro Retana Message-ID: <155252870218.24914.13341927320393340552.idtracker@ietfa.amsl.com> Date: Wed, 13 Mar 2019 18:58:22 -0700 Archived-At: Subject: [mpls] Alvaro Retana's Discuss on draft-ietf-mpls-sr-over-ip-03: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 01:58:22 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-mpls-sr-over-ip-03: 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-mpls-sr-over-ip/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I am balloting DISCUSS because the specification is incomplete and not clear enough. I have concerns about both the construction of forwarding entries, including the setting of the tunnel endpoints. (1) Forwarding Entries The procedures in §3.1 seem to want to be specified by example, but I think that this approach doesn't serve the document well as it goes into specifics for the protocols used in the example only (even using Normative language), and doesn't provide a general specification. As §3 says, "the examples in Section 3.1 and Section 3.2 assume that OSPF or ISIS is enabled: in fact, other mechanisms of discovery and advertisement could be used including other routing protocols (such as BGP) or a central controller." I would prefer if the text would talk about the general process first. If the authors think that the examples serve an important function then it's ok to leave them. Others have raised the point about the link state extensions needing to be Normative references. The way the text is written, Normative language is used in some cases to specifically talk about the use of those extensions...so I would agree. Using the extensions just in examples (and not mixing them with specification text) would solve that issue. What would I like to see? For example, the third step talks about "If A and E are in different IGP areas/levels, then..." How does the rest of the text help with understanding how BGP, for example, would be used? In this case I believe that the step can be summarized into the need to advertise the SID and encapsulation with enough information so that the receiver "knows the characteristics of the router that originated the advertisement", even if not in the same routing/flooding domain (maybe: "information MUST be advertised across flooding domain boundaries..." -- I'm sure the authors can come up with better text). Making that (or some text to the effect) the normative statement would be better than using normative language in the example (e.g. "MUST set the "router-ID" field to a valid value") and hoping/expecting for the reader to be able to translate that into whatever makes sense for BGP, or OSPFv3 or the central controller... After the general specification, you can then use an example ("for example, if using OSPF, then the router-ID field is set to a valid value..."). (2) Tunnel Endpoints §2: "The tunnel selected MUST have its remote end point (destination) address equal to the address of the next SR-MPLS capable node along the path (i.e., the egress of the active node segment)." I find this statement misleading and confusing. In the general case the statement is wrong: Yes, the tunnel destination should be the next SR-MPLS node, but that isn't always "the egress of the active node segment". For example, in Figure 2 the SID could direct the traffic to the Egress Router (e.g. using it's Node SID) while having individual tunnels from the Ingress Router to the first SR, then to the next SR, etc., as explained in §3.2.1/3.2.2. I realize that the sentence after the statement above is "This is shown in Figure 1." Figure 1 is a degenerate case of the (almost) general case from Figure 2. Even in the single tunnel (Figure 1) case, "the egress of the active node segment" doesn't have to be R2, it could be another node inside the SR-MPLS network (as R2, being SR-MPLS aware, should be able to forward the frames). As I hopefully explained above, I have two issues with the statement: 1. It is wrong. I think that what makes it wrong is the clarification that "the next SR-MPLS capable node along the path" is "the egress of the active node segment". Taken the text is parenthesis out would solve this issue. 2. It is a general statement. The placement is somewhat unfortunate because it seems that it may apply only to the Figure 1 case...but it applies in general...and there is no similar statement then describing other cases. Instead of adding something similar for Figure 2, perhaps move the sentence to a place that covers all the use cases. A third issue with the statement comes up when considering §3.1/§3.2: there is no specification there that explains how to figure out which should be the tunnel destination address. The example in §3.1 only talks about receiving information from E, including the "the encapsulation endpoint and the tunnel type of any tunnel used to reach E"...but says nothing about other potential SR-MPLS capable nodes between A and E, or how A would use a tunnel to one of those transit nodes on the way to E...which is what is illustrated in §3.2.1/3.2.2. (3) A very, very late IPR declaration came in after the IETF LC started. I didn't find a thread where the WG was made aware of it. https://datatracker.ietf.org/ipr/3439/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for writing this document! In general, the use of terminology (defined in rfc8402 and elsewhere) needs to be cleaned up throughout the document. (1) [nit] From the Abstract: "SR-MPLS could be leveraged...while preserving backward compatibility with SR-MPLS." I'm sure you want to say something related to making no changes to SR-MPLS for this application...the use of backwards compatibility with itself just sounds strange. The Introduction has similar text, but it does go on to clarify a little. (2) [nit] §3.1: "the FIB can be used to tell a router how to process packets" The FIB is generally in the router, so no need to tell it anything. ;-) Maybe: "the FIB can be used by the router to process packets". (3) §3.2: "Not all of the nodes in an SR-MPLS domain are SR-MPLS capable." By definition, all nodes in an SR domain participate in the source-based routing model [rfc8402]. I think that you meant to say that not all nodes in the network (or maybe just the domain) are SR-MPLS capable. Note that the SR domain in the networks in Figure 1, for example, includes both the SR-MPLS networks at both sides and the tunneled portion. If you mean for that picture to represent 3 different SR domains, then please don't use "SR-MPLS domain" to describe what is happening in the IP network portion. (4) §3.2: "There are six types of node in an SR-MPLS domain..." Again, I think you mean to point at the types of nodes in the network and not in the SR domain. (5) Security Considerations: Please also point at the considerations in rfc8402. From nobody Wed Mar 13 19:13:12 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 105D21311D2; Wed, 13 Mar 2019 19:13:05 -0700 (PDT) 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-mpls-sfc-encapsulation@ietf.org, Loa Andersson , mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155252958505.24865.4180223375091950120.idtracker@ietfa.amsl.com> Date: Wed, 13 Mar 2019 19:13:05 -0700 Archived-At: Subject: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-sfc-encapsulation-03: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 02:13:05 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-mpls-sfc-encapsulation-03: 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-mpls-sfc-encapsulation/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for this clear and concise document! I just have one concern, which will hopefully be easy to resolve (since there is a good chance that all the text necessary to do so is already written). As far as I can tell, the comment made by the secdir reviewer of draft-ietf-mpls-sfc-04 about circular references between that document and RFCs 7665 and 8300 regarding security properties, is also somewhat applicable to this document. I do recognize the validity of first paragraph of the security considerations here (the NSH is an opaque payload for MPLS), but that in and of itself does not present a security analysis of the NSH in the MPLS environment. The last paragraph of the security considerations of this document attempts to provide some analysis, but it seems to be incomplete and perhaps overly optimistic, particularly with respect to the use of MPLS with Inter-Carrier Interconnect and the processing of MPLS traffic from external interfaces. Is there any reason not to fully harmonize (i.e., synchronize) the security considerations of draft-ietf-mpls-sfc and draft-ietf-mpls-sfc-encapsulation? (I guess the first paragraph of this document's security considerations doesn't apply to the other document, that allocates extended-special-purpose label values, but that's the only thing I saw.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 This encapsulation is equivalent from an SFC perspective to other transport encapsulations of packets using the NSH. This can be illustrated by adding an additional line to the example of a next-hop SPI/SI-to-network overlay network locator mapping in Table 1 of [RFC8300]: We probably should expand SPI and SI, since we haven't yet hit a terminiology section or a note that (implies that) readers should be familiar with the standard SFC terminology. Also, Table 1 of RFC 8300 is labeled "SFF NSH Mapping Example"; it's not really clear that specifically that table is the best way to illustrate how the MPLS encapsulation would work. (side note) We use the strings "VPN" and "virtual private" here, which in some contexts will cause an (uninformed) reader to assume that data privacy (confidentiality) is involved; our uses do not seem to be for cases that would involve such a confidentiality property. As a general matter, not necessarily involving changes to this document, it may be good to try to reserve these terms for cases where the confidentiality is in fact provided, to help disambiguate the cases for the reader. Section 2.1 nit: s/The TTL For/The TTL for/ (twice) Section 3 For SFC, ECMP may or may not be desirable. To prevent ECMP when it is not desired, the NSH Base Header was carefully constructed so that the NSH could not look like IPv4 or IPv6 based on its first nibble. See Section 2.2 of [RFC8300] for further details. nit: this paragraph might flow better into the next one if we add a note that "Accordingly, the default behavior for MPLS-encapsulated SFC will not use ECMP." Section 6 However, it can be argued that carrying the NSH over MPLS is more re: "it can be argued" -- is this document attempting to make that argument? secure than using other encapsulations, as it is extremely difficult, due to the MPLS architecture, for an attempted attacker to inject It's not entirely clear to me how much of this is the MPLS architecture vs. implementation/deployment; I suppose to some extent it is true of both. unexpected MPLS packets into a network, as MPLS networks do not by design accept MPLS packets from external interfaces, and an attacker What about Inter-Carrier Interconnect? would need knowledge of the specific labels allocated by control and/ or management plane protocols. Thus, an attacker attempting to spoof MPLS-encapsulated NSH packets would require insider knowledge of the An attacker in a position to inject traffic seems likely to also be able to observe legitimate traffic and correspondingly their valid label values (if not necessarily the mapping from label to behavior). network's control and management planes and a way to inject packets into internal interfaces. This is compared to, for example, NSH over UDP over IP, which could be injected into any external interface in a network that was not properly configured to filter out such packets at the ingress. The NSH security considerations already (essentially) require this filtering at ingress behavior; the practical question relevant here seems to just be a matter of scale -- how hard it is to misconfigure this filtering or how likely it is that the relevant filtering is present as a consequence of factors external to SFC. From nobody Wed Mar 13 20:30:54 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29472131262; Wed, 13 Mar 2019 20:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 vaqWBCLws3Ea; Wed, 13 Mar 2019 20:30:51 -0700 (PDT) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 251A113125A; Wed, 13 Mar 2019 20:30:50 -0700 (PDT) Received: by mail-ot1-x32c.google.com with SMTP id g1so3813656otj.11; Wed, 13 Mar 2019 20:30:50 -0700 (PDT) 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=Fi0DmkwWCW1sJgQHC8FBA/3aX2nVSp1sTSvqq0Hs40Y=; b=IV/vXuh6QNbP8l95AJcWvFYqFf+mb4Og3vD/4okEPr8vc6tuLarZwtWdzqPiFmWtXG jVGT5c3AQ/8x65QcZI4v6gKPXuce/93NCRyZsUhAGFRV05PUpaeKEOkIKOi8A5kMyxHw CEi9dyKlXsUKD9qIGhK4hlaW94zSc2OO97lrpbw7tLkA6PvPGEe+Jy26OiH6FrAERLTE pmKThl+9W+HP9WB/t2kr8sSVG1cf1h50EfLgQm2lbkyIYjlBquwqAXd2m2TZvVdPTpIQ V8XRBhpeX8loBxa2Xju1jKUJrLjlnm9uTr+K+xdJXHKUmP1sqYcLqkEN1oXU1uyHDOoK 4wUw== 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=Fi0DmkwWCW1sJgQHC8FBA/3aX2nVSp1sTSvqq0Hs40Y=; b=syp3/UGTdxJ9ynTjb4T4Kl8UksTeJxotpfGmv6NAmym4/4h/Sd04nGrNtQnaoRnRyP avjJkEYJJddnAFregSQSF5yJUXC4BcNaG3jRxsqAop6+QfbDAjZ1qEqqDCJgeyOamj3R g4Mda0iFX8JwSH3sv2mvtCzTVIGjRi/HxaF7zLkv3zmGv9N0pjH6IGwxeHS5+7ngHISx J+AJc+ZLKoBslIIMh7WhmyqTz79MKWQ6G7VWpxddy87Pvy0D61lDRq4y/0okqhUfBSBv Th4y/pYwjOFEMoEqQeXd1tAAT+qErYPPZ+SYO1cA86Gfjfc1so3I/7tWOxacsAjgLj8H wNfQ== X-Gm-Message-State: APjAAAWqh14B3Imr09Nx+559uAE5MJlv+i9SOZ70vLzNusI2Ft51khZ5 9MeG78EIRYFr2kNOOcSP9qfB/kLTLtAf5O65ZNWF5Q== X-Google-Smtp-Source: APXvYqwgCYCKwtJV2OnTvkxGCMjIEzKHDj7bZDdtgcMP3zTBVRyLNtRzSr8iBBrFtS1ptokGPbD9vuCKHs5YJW2xi1A= X-Received: by 2002:a05:6830:1388:: with SMTP id d8mr30886738otq.44.1552534248077; Wed, 13 Mar 2019 20:30:48 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 13 Mar 2019 23:30:42 -0400 From: Alvaro Retana In-Reply-To: References: <155208210011.3264.12148702952456660789.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Date: Wed, 13 Mar 2019 23:30:42 -0400 Message-ID: To: Alvaro Retana via Datatracker , The IESG , Mach Chen Cc: "mpls@ietf.org" , "mpls-chairs@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005bc11f0584058c39" Archived-At: Subject: Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 03:30:53 -0000 --0000000000005bc11f0584058c39 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On March 13, 2019 at 10:14:42 AM, Mach Chen (mach.chen@huawei.com) wrote: Mach: Hi! ... > (2) =C2=A76: "Otherwise, if the responder does not know the LSR Capabilit= y TLV, an > MPLS echo reply with the return code set to "One or more of the TLVs was > not understood" MUST be sent back to the initiator LSR." Given that this is > the case where the new TLV is not known, then we can't Normatively direct > those nodes to do anything (since they probably don't implement anything in > this document). s/MUST/must + add a reference to rfc8029 (where the > behavior is > specified) [The same text appears again in =C2=A73 and =C2=A73.2. Writing= the > specification is one place is enough.] It's more accurate to call it a "Mandatory" TLV that does not require an implementation has to implement it, but will result in return code when a node does not support it, as specified in RFC8029. Maybe we could just remove the "optional", and make it clear to the IANA section, the code point of this TLV should be allocated from the Mandatory range. How do you think? I think that optional should explicitly be replaced with mandatory=E2=80=A6= . And, the IANA section should be clarified to indicate the range. ... > (3) This document doesn't talk about what should be done if a response is > not received, at any point in the process. I searched in rfc8029, but didn't > find anything related to timeouts...only =C2=A74.8 (Non-compliant Routers= ), which > includes a process on what to do if a reply is not received. That process > doesn't seem to apply to this document -- what should an initiator do if = a > reply is not received? I am specially interested in the discovery phases. Normally, the timeout process is left the implementation (e.g., through timers). If a reply cannot be received within a certain period, the initiator will return timeout. That means there some issues along the path, operator should intervene then. Ok..so a log/notification of some kind should be raised. During the discovery process, it looks like some things could be specified without operator intervention. For example, the capabilities may be discovered (=C2=A73), but the request about the LAG may not be answered. I= t seems to me that the initiator could simply retry=E2=80=A6maybe after some = retries the log/notification can be raised. Just thinking out loud=E2=80=A6 Either= way is fine with me... Thanks! Alvaro. --0000000000005bc11f0584058c39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On March 13, 2019 at 10:14:42 AM, Mach Chen (mach.chen@huawei.com) wrote:
=

Mach:

Hi!

...
> (2) =C2=A76: "Otherwise, if t= he responder does not know the LSR Capability TLV, an=C2=A0
> MPLS echo reply with the return code set to "O= ne or more of the TLVs was=C2=A0
> not understood" MUST be sent back to the initiator LSR.&quo= t; Given that this is=C2=A0> the case where the new TLV is not known, then we can't Normativel= y direct=C2=A0
> those n= odes to do anything (since they probably don't implement anything in=C2=A0
> this document). s/= MUST/must + add a reference to rfc8029 (where the=C2=A0
> behavior is=C2=A0
> specified) [The same text appears again in = =C2=A73 and =C2=A73.2. Writing the=C2= =A0
> specification is one place is enough.]=C2=A0

It's more accurate to call it = a "Mandatory" TLV that does not require an implementation has to = implement it, but will result in return code when a node does not support i= t, as specified in RFC8029.=C2=A0

Maybe we could just remove the &q= uot;optional", and make it clear to the IANA section, the code point o= f this TLV should be allocated from the Mandatory range. How do you think?<= span class=3D"Apple-converted-space">=C2=A0

I think that optional should explicitly be replaced with ma= ndatory=E2=80=A6. And, the IANA section should be clarified to indicate the= range.


...

> (3) This document doesn't talk abou= t what should be done if a response is=C2=A0
> not received, at any point in the process. I searche= d in rfc8029, but didn't=C2=A0
> find anything related to timeouts...only =C2=A74.8 (Non-compli= ant Routers), which=C2=A0
&= gt; includes a process on what to do if a reply is not received. That proce= ss=C2=A0
> doesn't s= eem to apply to this document -- what should an initiator do if a=C2=A0
> reply is not received? I = am specially interested in the discovery phases.=C2=A0

Normally, the timeout process is left the i= mplementation (e.g., through timers).= =C2=A0

If a reply cannot be received within a certain period,= the initiator will return timeout. That means there some issues along the = path, operator should intervene then.= =C2=A0

Ok..so a log/notifica= tion of some kind should be raised. =C2=A0

During the discovery proce= ss, it looks like some things could be specified without operator intervent= ion.=C2=A0 For example, the capabilities may be discovered (=C2=A73), but t= he request about the LAG may not be answered.=C2=A0 It seems to me that the= initiator could simply retry=E2=80=A6maybe after some retries the log/noti= fication can be raised.=C2=A0 Just thinking out loud=E2=80=A6 Either way is= fine with me...

Thanks!=C2=A0

Alvaro.

--0000000000005bc11f0584058c39-- From nobody Wed Mar 13 20:47:16 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34E1131288; Wed, 13 Mar 2019 20:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 07jiizT6L7Fc; Wed, 13 Mar 2019 20:47:03 -0700 (PDT) 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 BE735131283; Wed, 13 Mar 2019 20:47:02 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2E3kq9b001331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Mar 2019 23:46:54 -0400 Date: Wed, 13 Mar 2019 22:46:52 -0500 From: Benjamin Kaduk To: Mach Chen Cc: Benjamin Kaduk via Datatracker , The IESG , "mpls@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" , "mpls-chairs@ietf.org" , "loa@pi.nu" Message-ID: <20190314034652.GY8182@kduck.mit.edu> References: <155242263093.20169.3838924661112115545.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 03:47:08 -0000 On Wed, Mar 13, 2019 at 08:33:59AM +0000, Mach Chen wrote: > Hi Benjamin, > > Thanks for your thorough review and detailed comments! > > Please see my replies inline... > > > > -----Original Message----- > > From: Benjamin Kaduk via Datatracker [mailto:noreply@ietf.org] > > Sent: Wednesday, March 13, 2019 4:31 AM > > To: The IESG > > Cc: draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org; mpls-chairs@ietf.org; > > loa@pi.nu; mpls@ietf.org > > Subject: Benjamin Kaduk's Discuss on draft-ietf-mpls-lsp-ping-lag-multipath- > > 06: (with DISCUSS and COMMENT) > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-mpls-lsp-ping-lag-multipath-06: 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-mpls-lsp-ping-lag-multipath/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Thanks for this document; it's clearly going to provide value, and it gives a > > pretty well-readable description of how things are expected to work. That > > Thanks. > > > said, there's a number of details that need to be worked out before > > publication... > > OK. > > > > > This document has six listed authors; per RFC 7322, documents listing more > > than five authors are unusual, and six is greater than five. Let's talk about the > > author count. > > Please refer to Loa's answer. > > > > > "optional TLV" seems to be used in MPLS contexts as a technical term for > > "comprehension-optional", not in the "optional to send" sense; it's the > > counterpart of "mandatory TLV", and this terminology is even documented in > > the MPLS TLVs registry. It's my understanding that the LSP Capabilities TLV > > and the Detailed Interface and Label Stack TLV are intended to be > > comprehension-required (i.e., "mandatory TLVs"), and thus that we must > > not use the phrase "optional TLV" in their description. > > This would be made clear if we listed which range of values we intended to > > allocate a TLV type from, in the IANA considerations, but that remains > > unspecified at this time. > > Good catch on the LSP Capabilities TLV, it should be specified as assigned from the range 0-16383 as a response is required. The TLV is optional, as noted this range also covers optional TLVs for which a response is required. Per RFC8029, the Downstream Detailed Mapping TLV which is used in this RFC is also optional. That works for me, though I'm also watching Alvaro's ballot thread. > > > > In a similar vein (the "comprehension-required" behavior), there are a few > > places (Section 3 (twice), and Section 6; also Section 3 for the LAG Description > > Indicator flag; see COMMENT) where we state new normative language > > ("MUST") that is unenforceable, since it would need to apply to MPLS > > implementations that do not implement this specification. > > Fortunately, the comprehension-required TLV ranges provide this > > functionality for us without the need to use normative language. > > Addressed with the COMMENT below. > > > > > Section 4.2 has some conflicting "MUST"s about the ordering/presence of > > sub-TLVs in the DDMAP TLV (see COMMENT, and also the "MANDATORY" > > langauge in Figure 2). > > Addressed with the COMMENT below. > > > > > If I'm reading Section 5.1.2 correctly, the described procedure is only > > intended to apply when the "G" flag is present (as well as the "I" flag, the > > requirement for which is explicitly stated), but this is not explicitly stated. In > > particular, the text as written says it applies to all responders that > > "understand the LAG Description Indicator flag" > > with no mention of runtime check for the presence of that flag. > > How about add a sentence at the beginning of the section: > > "When received an echo request with the "LAG Description Indicator flag" set, a responder LSR that ..." Just what I was looking for, thanks. > > > > I also worry that Sections 8, 9, and 10 are insufficiently clear about the > > encoding of the interface index value -- is it an integer in NBO, an opaque > > bitstring, or something else? Do I need to clarify this question more? > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Am I reading this correctly that the "LSR Capability TLV" created here is > > basically only applicable to properties of MPLS echo request/reply exchanges? > > If so, then perhaps the moniker "LSR Capability" is overly generic. > > It's currently defined for LSP Ping, but may be used in a more generic use. I incline to keep it as is. Ok. > > > > Section 1.2 > > > > o Label switching over some member links of the LAG is successful, > > but will be failed over other member links of the LAG. > > > > nit: there's some verb tense inconsistency here; maybe "but fails over other > > member links" would help. > > OK. > > > > > Section 2 > > > > This document defines an optional TLV to discover the capabilities of > > a responder LSR and extensions for use with the MPLS LSP Ping and > > > > nit: is it only the *responder* LSR we care about, or are there potentially > > intermediaries in play? > > Only the responder LSR we care about. > > > > > The solution consists of the MPLS echo request containing a DDMAP TLV > > and the optional LSR capability TLV to indicate that separate load > > > > nit: Is this "optional capability TLV" the same "optional TLV" that we are > > defining in this document? If so, calling it "the new optional LSR capability" > > would aid clarity. (Also, we seem to use both the "capability" and > > "Capability" capitzliations for describing this TLV.) > > OK, fixed. > > > > > Section 3 > > > > Capability TLV in the MPLS echo request message. When the responder > > LSR receives an MPLS echo request message with the LSR Capability TLV > > included, if it knows the LSR Capability TLV, then it MUST include > > the LSR Capability TLV in the MPLS echo reply message with the LSR > > Capability TLV describing features and extensions supported by the > > local LSR. Otherwise, an MPLS echo reply MUST be sent back to the > > initiator LSR with the return code set to "One or more of the TLVs > > was not understood". [...] > > > > This last MUST seems like something that this document cannot mandate (as > > it attempts to apply to non-implementations of this document); it could only > > work if it was an existing requirement from the core MPLS spec, in which > > case lower-case "must" is appropriate (possibly with section reference). > > OK, how about below: > > "Otherwise, an MPLS echo reply must be sent back to the initiator LSR with the return code set to "One or more of the TLVs was not understood", according to the rules as defined Section 3 of RFC8029." Works for me. > > > > o If the responder LSR does not understand the "LAG Description > > Indicator flag": > > > > * Clear both the "Downstream LAG Info Accommodation flag" and the > > "Upstream LAG Info Accommodation flag". > > > > Similarly, if an LSR does not understand a flag, it cannot give special > > treatment to packets containing that flag. (Why an LSR would not > > understand a flag defined in the same document that defines the Capabilities > > TLV is beyond me, but you seem to want to allow for that > > case.) > > OK, I think it's OK to remove them. > > > > > If the responder does not know the LSR Capability TLV, an MPLS echo > > reply with the return code set to "One or more of the TLVs was not > > understood" MUST be sent back to the initiator LSR. > > > > This duplicates the content I quoted at the top of this section's comments. > > OK, remove this duplicate text. > > > > > Section 4.1 > > > > Once the initiator LSR knows the capabilities that a responder > > supports, then it sends an MPLS echo request carrying a DDMAP with > > the "LAG Description Indicator flag" (G) set to the responder LSR. > > > > nit: I think the key point is not that the initiator knows the capabilities of the > > peer, but rather that the initiator knows that the peer supports this specific > > mechanism. > > Yes. > > How about: > "Once the initiator LSR knows that a responder can support this meachanism, then it sends an MPLS echo request carrying a DDMAP TLV with the "LAG Description Indicator flag" (G) set to the responder LSR." Sounds good. > > > Also, is this "a DDMAP TLV"? > > Yes. > > > > > Section 4.2 > > > > Reading this makes it sound like the "LAG Description Indicator flag" is > > completely orthogonal to regular DDMAP functionality, so that if I set the > > LAG description indicator flag but do not otherwise request detailed > > descriptions, only the LAG interfaces are returned. However, the flag in > > question has to be inside a DDMAP TLV (and we should really say so, perhaps > > as "[flag] set *in the DDMAP TLV*"!), so it seems like in practice the LAG > > information can only be obtained in conjunction with full detailed description > > information. (The specific suggestion here is to note clearly that the flag is se > > in the DDMAP TLV.) > > Fixed. > > > > > * The responder LSR MUST include a DDMAP TLV when sending the > > MPLS echo reply. > > > > I got confused on my first pass through this section; adding "There is a single > > DDMAP TLV for the LAG interface, with member links described using sub- > > TLVs" here would have kept me from veering onto the wrong path. > > (I thought there was going to be one DDMAP TLV per member link, plus one > > for the LAG aggregate, with lots of duplication.) > > Sure, added. > > > > > Based on the procedures described above, every LAG member link will > > have a Local Interface Index Sub-TLV and a Multipath Data Sub-TLV > > entries in the DDMAP TLV. The order of the Sub-TLVs in the DDMAP TLV > > for a LAG member link MUST be Local Interface Index Sub-TLV > > immediately followed by Multipath Data Sub-TLV. A LAG member link > > MAY also have a corresponding Remote Interface Index Sub-TLV. When a > > Local Interface Index Sub-TLV, a Remote Interface Index-Sub-TLV and a > > Multipath Data Sub-TLV are placed in the DDMAP TLV to describe a LAG > > member link, they MUST be placed in the order of Local Interface > > Index Sub-TLV, Remote Interface Index-Sub-TLV and Multipath Data Sub- > > TLV. > > > > This last MUST contradicts the previous MUST. I suggest some more text to > > clarify under which conditions each requirement applies. > > OK, added. > > > > > I'd also suggest not using the figure for conveying a (apparent?) mandatory > > requirement, and instead adding some text at the end: "The block of local > > interface index, (optional remote interface index) and multipath data sub- > > TLVs for each member link MUST appear adjacent to each other in order of > > increasing local interface index." > > OK, added. > > > > > It's confusing to label the multiplath data sub-TLV as "MANDATORY" when > > the body text says "MUST add an [sic] Multipath data Sub-TLV [...] if the > > received DDMAP TLV requested multipath information", i.e., it is not always > > present, based on the contents of the echo request. > > Since it's just an example here, will remove the MANDATORY and OPTIONAL. Ah, good point. > > When none of the received multipath information maps to a particular > > LAG member link, then the responder LSR MUST still place the Local > > Interface Index Sub-TLV and the Multipath Data Sub-TLV for that LAG > > member link in the DDMAP TLV, the value of Multipath Length field of > > the Multipath Data Sub-TLV is set to zero. > > > > nit: the last comma is a comma splice. > > OK. > > > > > Section 5.1.2 > > > > It seems like this places a slightly stronger burden on the responder than > > stock 8029 does, in that there is a MUST-level requirement to act on the 'I' > > flag in combination with the 'G' flag, whereas for the 'I' > > flag alone 8029 only has a SHOULD-level requirement to respond accordingly. > > We may want to call this out as a change in behavior. > > Will change to "SHOULD", then it can align with RFC8029. I think that will be okay (it wasn't the change I was expecting, but I will definitely defer to the authors and WG for this sort of thing!); I wasn't sure if the divergence was a conscious decision or not. > > > > Section 5.1.3 > > > > Expectation is that there's a relationship between the interface > > index of the outgoing LAG member link at TTL=n and the interface > > index of the incoming LAG member link at TTL=n+1 for all discovered > > entropies. In other words, set of entropies that load balances to > > > > nit: "The expectation" > > Fixed. > > > nit: "discovered entropies" is a strange wording given how the entropy label > > works; is this more like "all entropies examined"? > > OK, change to "all entropies examined". > > > > > > > The initiator LSR sends two MPLS echo request messages to traverse > > the two LAG member links at TTL=n+1: > > > > How does the initiator know (which entropy label values?) to get the echo > > requests to traverse different member links? > > The initiator cannot exactly know which entropy label values are workable. Presumably, the initiator can set different values according to the number of member links, then the responder can use entropy values for hash to traverse different member link. This is left to implementation. Maybe add "(Depending on the LAG traffic division algorithm, the messages may or may not traverse different member algorithms.)" or similar? > > > > o Error case: > > > > * One MPLS echo request message reaches TTL=n+1 on an LAG member > > link 1. > > > > * The other MPLS echo request message also reaches TTL=n+1 on an > > LAG member link 1. > > > > One or two MPLS echo request messages sent by the initiator LSR > > cannot reach the immediate downstream LSR, or the two MPLS echo > > request messages reach at the immediate downstream LSR from the > > same LAG member link. > > > > The description paragraph doesn't seem to match up the scenario described > > in the sub-bullets, which leaves me confused as to what > > scenario(s) are intended to be considered as the "error case". > > The sub-bullets are not complete, will add a third sub-bullet as below: > > "One or both MPLS echo request messages cannot reach the immediate downstream LSR on whichever link." That makes it sound like the sub-bullets are distinct options, and the top level bullet is an "error cases" plural. My reading with just the two sub-bullets present in the -06 was that both sub-bullets had to happen in order to be in the error case. > > > > Section 6 > > > > This document defines a new optional TLV which is referred to as the > > "LSR Capability TLV. [...] > > > > Is this optional to use or comprehension-optional? (We elsewhere rely on > > comprehension-mandatory behavior, so in the RFC 8029 terminology this > > seems to be a "mandatory TLV" even if it is not mandatory to use.) > > It's "mandatory TLV" according to RFC8029. I think Alvaro is more on top of the subtleties here, so maybe we should divert this topic to that ballot thread. > > > > included in the MPLS echo reply message. Otherwise, if the responder > > does not know the LSR Capability TLV, an MPLS echo reply with the > > return code set to "One or more of the TLVs was not understood" MUST > > be sent back to the initiator LSR. > > > > This duplicates a requirement stated elsewhere (that really ought to just be > > using existing required behavior from 8029 anyway). > > Remove it. > > > > > LSR Capability TLV Type is TBD1. Length is 4. The value field of > > > > In a hypothetical future where we need to allocate a 33rd capability flag, > > would we rather create a new "extended capabilities" TLV (burning another > > 32 bits for type+length) or leave flexibility now for 'length' > > to increase in multiples of 4 with receivers ignoring bits past what they know > > about? > > IMHO, 32 bit seems reasonable enough for me. I incline to keep the flag field as a fixed length. > > If we want it be extensible, maybe we could add optional sub-TLVs to this TLV. I agree that 32 bits seem likely to last for a very long time, so it's hardly an important point. I just wondered if anyone was going to enforce that the length is exactly 4, which would prevent any further changes to this TLV (other than allocating new bits). > > > > The "LSR Capability Flags" field is 4 octets in length, this > > document defines the following flags: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Must Be Zero (Reserved) |U|D| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > I'm wary of describing these as "Must Be Zero", since they're just unallocated > > but not required to be zero other than by the current state of bit allocations. > > (I guess this is conventional for MPLS, though? So maybe it's not a problem.) > > Just "Reserved" would be fine. > > OK. Change to "Reserved". > > > > > This document defines two flags. The remaining flags MUST be set > > to zero when sending and ignored on receipt. Both the U and the D > > flag MUST be cleared in the MPLS echo request message when > > sending, and ignored on receipt. Neither, either or both the U > > and the D flag MAY be set in the MPLS echo reply message. > > > > Similarly, I think we want to say "unallocated flags" rather than "the > > remaining flags". > > Fixed. > > > > > It also seems like the semantics being described here are "the TLV value is > > ignored in the echo request and only has meaning in the response" > > (i.e., this is a "tell me your capabilities" exchange, not a "here are mine; what > > are yours?" exchange). As written, that applies only to the U and D bits, and > > is not a general property. That may well be a fine choice if we think we might > > want the two-way exchange for some future allocated bit, but if we do think > > it's a general property of the mechanism, I'd suggest rewording the text. > > It's designed as an unidirectional tool, make it a two-way exchange mechanism will require more considerations and substantial changes to draft. So, I inline to keep it as-is. If we have such use case in the future, we update this mechanism then. Sure, thanks for thinking about it. > > > > Section 7 > > > > (Per IANA, bits 4 and 5 are already assigned but are not reflected in the > > diagram.) > > Fixed. > > > > > Section 10 > > > > The Detailed Interface and Label Stack TLV format is derived from the > > Interface and Label Stack TLV format (from [RFC8029]). Two changes > > are introduced. The first is that the label stack is converted into > > a sub-TLV. The second is that a new sub-TLV is added to describe an > > interface index. These fields of Detailed Interface and Label Stack > > TLV have the same use and meaning as in [RFC8029]. A summary of > > these fields is as below: > > > > nit: Are "These fields" just "The other fields"? > > > Fixed. > > > > > The Address Type indicates if the interface is numbered or > > unnumbered. It also determines the length of the IP Address > > and Interface fields. The resulting total length of the > > initial part of the TLV is listed as "K Octets". The Address > > Type is set to one of the following values: > > > > nit: is it better to list the currently allocated values or just refer to the IANA > > registry? > > Since here it also include the length field. I'd like to keep it both here and the IANA registry. > > > > > I seee that this "index assigned to the interface" language for unnumbered > > address types originates from RFC 8029, but both this document and 8029 > > leave me confused as to the encoding used for this index (for either/both > > IPv4 or IPv6 address types). > > It's normally an unsigned integer. We probably should specify network byte order for it, then. > > > > [My comment about "Must Be Zero" and allocatable bits also applies here] > > Fixed as above. > > > > > Section 12 > > > > This document also adds a capability "negotiation" mechanism for MPLS echo > > request/reply exchanges. As MPLS does not offer integrity protection for its > > messages, this negotiation is only as trustworthy as the network from which > > messages are accepted as valid, and initiators have no recourse but to accept > > faithfully the echo replies received. > > > > To prevent leakage of vital information to untrusted users, a > > responder LSR MUST only accept MPLS echo request messages from > > designated trusted sources via filtering source IP address field of > > received MPLS echo request messages. [...] > > > > I'd prefer to see a note added here about how "source IP address filtering > > provides only a weak form of access control and is not, in general, a reliable > > security mechanism. Nonetheless, it is required here in the absence of any > > more robust mechanism that might be used." > > OK, added. > > > > > > Section 13 > > > > Should we ask IANA to update the "Interface and Label Stack Address Types" > > registry to also refer to this document, since we are sharing the registry > > between the Interface and Label Stack TLV and the Detailed version? > > Added. > > > > > Section 13.2 > > > > The range 4-31743 spans two different allocation procedures (Standards > > Action and Specification Required - Experimental RFC needed); I assume that > > we want the 4-16383 range for Standards Action - mandatory TLVs. > > Yes. > > > > > Section 13.4 > > > > We don't say what range we want this to be allocated from -- I assume > > 4-16383 since this is a negotiated feature and sending it outside the > > negotiated scenario should be an error. > > Yes, suggested range added. > > > > > Section 13.4.1 > > > > (I note that some existing sub-TLV registries have "Experimental RFC > > required" for the experimental ranges, but that is arguably more stringent > > than necessary; Specification Required seems more appropriate for this case.) > > OK, change to " Specification Required". > > > > > Appendix A > > > > I was kind of hoping for some more guidance on what an initiator could do in > > these scenarios to try to get better visibility into the switch behavior (and, > > hopefully, a workaround to get reliable echo responses that cover all LAG > > member links). AFAICT there's not a better option than "try a bunch of > > entropy labels and see what responses you can get back" and that's the > > same remedy in all the described topologies, but it would be nice to have this > > stated explicitly for the reader. > > A note will be added. Thanks. > > > > Section A.1 > > > > In the worst case, MPLS echo request messages with > > specific entropies to exercise every LAG members from R1 to S1 can > > all reach R2 via same LAG member. [...] > > > > I'm confused by the phrase "specific entropies to exercise every LAG > > members [sic] from R1 to S1" -- is there some deterministic algorithm by > > which a specific entropy label value will force a specific LAG member link? > > No. > > > My understanding was that the entropy was used as input to an opaque hash > > function and that trial-and-error was the only way to explore the mapping > > from entropy value to LAG member link taken. > > Yes. > > Thanks again for your detailed and valuable comments! You're selcome! -Benjamin From nobody Wed Mar 13 21:04:41 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAEF13129E; Wed, 13 Mar 2019 21:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5wAz0cN_z3xT; Wed, 13 Mar 2019 21:04:26 -0700 (PDT) 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 150B812716C; Wed, 13 Mar 2019 21:04:26 -0700 (PDT) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 797FA58C31D6FAE46827; Thu, 14 Mar 2019 04:04:23 +0000 (GMT) Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 14 Mar 2019 04:04:22 +0000 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.190]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0415.000; Thu, 14 Mar 2019 12:04:18 +0800 From: Mach Chen To: Benjamin Kaduk CC: Benjamin Kaduk via Datatracker , The IESG , "mpls@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" , "mpls-chairs@ietf.org" , "loa@pi.nu" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with DISCUSS and COMMENT) Thread-Index: AQHU2RJ3vF0A2kVnzkeAK0NcOKNWfKYJJaDwgADTPQCAAIfKcA== Date: Thu, 14 Mar 2019 04:04:18 +0000 Message-ID: References: <155242263093.20169.3838924661112115545.idtracker@ietfa.amsl.com> <20190314034652.GY8182@kduck.mit.edu> In-Reply-To: <20190314034652.GY8182@kduck.mit.edu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 04:04:32 -0000 Hi Benjamin, Thanks for your prompt response! Please see some responses inline... > -----Original Message----- > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > Sent: Thursday, March 14, 2019 11:47 AM > To: Mach Chen > Cc: Benjamin Kaduk via Datatracker ; The IESG > ; mpls@ietf.org; draft-ietf-mpls-lsp-ping-lag- > multipath@ietf.org; mpls-chairs@ietf.org; loa@pi.nu > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-mpls-lsp-ping-lag- > multipath-06: (with DISCUSS and COMMENT) >=20 > On Wed, Mar 13, 2019 at 08:33:59AM +0000, Mach Chen wrote: > > Hi Benjamin, > > > > Thanks for your thorough review and detailed comments! > > > > Please see my replies inline... > > > > > > > -----Original Message----- > > > From: Benjamin Kaduk via Datatracker [mailto:noreply@ietf.org] > > > Sent: Wednesday, March 13, 2019 4:31 AM > > > To: The IESG > > > Cc: draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org; > > > mpls-chairs@ietf.org; loa@pi.nu; mpls@ietf.org > > > Subject: Benjamin Kaduk's Discuss on > > > draft-ietf-mpls-lsp-ping-lag-multipath- > > > 06: (with DISCUSS and COMMENT) > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-mpls-lsp-ping-lag-multipath-06: 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-mpls-lsp-ping-lag-multip > > > ath/ > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > DISCUSS: > > > -------------------------------------------------------------------- > > > -- > > > > > > Thanks for this document; it's clearly going to provide value, and > > > it gives a pretty well-readable description of how things are > > > expected to work. That > > > > Thanks. > > > > > said, there's a number of details that need to be worked out before > > > publication... > > > > OK. > > > > > > > > This document has six listed authors; per RFC 7322, documents > > > listing more than five authors are unusual, and six is greater than > > > five. Let's talk about the author count. > > > > Please refer to Loa's answer. > > > > > > > > "optional TLV" seems to be used in MPLS contexts as a technical term > > > for "comprehension-optional", not in the "optional to send" sense; > > > it's the counterpart of "mandatory TLV", and this terminology is > > > even documented in the MPLS TLVs registry. It's my understanding > > > that the LSP Capabilities TLV and the Detailed Interface and Label > > > Stack TLV are intended to be comprehension-required (i.e., > > > "mandatory TLVs"), and thus that we must not use the phrase "optional > TLV" in their description. > > > This would be made clear if we listed which range of values we > > > intended to allocate a TLV type from, in the IANA considerations, > > > but that remains unspecified at this time. > > > > Good catch on the LSP Capabilities TLV, it should be specified as assig= ned > from the range 0-16383 as a response is required. The TLV is optional, as > noted this range also covers optional TLVs for which a response is requir= ed. > Per RFC8029, the Downstream Detailed Mapping TLV which is used in this RF= C > is also optional. >=20 > That works for me, though I'm also watching Alvaro's ballot thread. OK, let's wait Alvaro's response. >=20 > > > > > > In a similar vein (the "comprehension-required" behavior), there are > > > a few places (Section 3 (twice), and Section 6; also Section 3 for > > > the LAG Description Indicator flag; see COMMENT) where we state new > > > normative language > > > ("MUST") that is unenforceable, since it would need to apply to MPLS > > > implementations that do not implement this specification. > > > Fortunately, the comprehension-required TLV ranges provide this > > > functionality for us without the need to use normative language. > > > > Addressed with the COMMENT below. > > > > > > > > Section 4.2 has some conflicting "MUST"s about the ordering/presence > > > of sub-TLVs in the DDMAP TLV (see COMMENT, and also the > "MANDATORY" > > > langauge in Figure 2). > > > > Addressed with the COMMENT below. > > > > > > > > If I'm reading Section 5.1.2 correctly, the described procedure is > > > only intended to apply when the "G" flag is present (as well as the > > > "I" flag, the requirement for which is explicitly stated), but this > > > is not explicitly stated. In particular, the text as written says > > > it applies to all responders that "understand the LAG Description Ind= icator > flag" > > > with no mention of runtime check for the presence of that flag. > > > > How about add a sentence at the beginning of the section: > > > > "When received an echo request with the "LAG Description Indicator flag= " > set, a responder LSR that ..." >=20 > Just what I was looking for, thanks. >=20 > > > > > > I also worry that Sections 8, 9, and 10 are insufficiently clear > > > about the encoding of the interface index value -- is it an integer > > > in NBO, an opaque bitstring, or something else? >=20 > Do I need to clarify this question more? No, this has been answered within the below COMMENT. The interface index value is normally an unsigned integer. You added we should specify network byte order. Will add some clarify text. >=20 > > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > COMMENT: > > > -------------------------------------------------------------------- > > > -- > > > > > > Am I reading this correctly that the "LSR Capability TLV" created > > > here is basically only applicable to properties of MPLS echo request/= reply > exchanges? > > > If so, then perhaps the moniker "LSR Capability" is overly generic. > > > > It's currently defined for LSP Ping, but may be used in a more generic = use. I > incline to keep it as is. >=20 > Ok. >=20 > > > > > > Section 1.2 > > > > > > o Label switching over some member links of the LAG is successful= , > > > but will be failed over other member links of the LAG. > > > > > > nit: there's some verb tense inconsistency here; maybe "but fails > > > over other member links" would help. > > > > OK. > > > > > > > > Section 2 > > > > > > This document defines an optional TLV to discover the capabilities= of > > > a responder LSR and extensions for use with the MPLS LSP Ping and > > > > > > nit: is it only the *responder* LSR we care about, or are there > > > potentially intermediaries in play? > > > > Only the responder LSR we care about. > > > > > > > > The solution consists of the MPLS echo request containing a DDMAP = TLV > > > and the optional LSR capability TLV to indicate that separate > > > load > > > > > > nit: Is this "optional capability TLV" the same "optional TLV" that > > > we are defining in this document? If so, calling it "the new optiona= l LSR > capability" > > > would aid clarity. (Also, we seem to use both the "capability" and > > > "Capability" capitzliations for describing this TLV.) > > > > OK, fixed. > > > > > > > > Section 3 > > > > > > Capability TLV in the MPLS echo request message. When the respond= er > > > LSR receives an MPLS echo request message with the LSR Capability = TLV > > > included, if it knows the LSR Capability TLV, then it MUST include > > > the LSR Capability TLV in the MPLS echo reply message with the LSR > > > Capability TLV describing features and extensions supported by the > > > local LSR. Otherwise, an MPLS echo reply MUST be sent back to the > > > initiator LSR with the return code set to "One or more of the TLVs > > > was not understood". [...] > > > > > > This last MUST seems like something that this document cannot > > > mandate (as it attempts to apply to non-implementations of this > > > document); it could only work if it was an existing requirement from > > > the core MPLS spec, in which case lower-case "must" is appropriate > (possibly with section reference). > > > > OK, how about below: > > > > "Otherwise, an MPLS echo reply must be sent back to the initiator LSR w= ith > the return code set to "One or more of the TLVs was not understood", > according to the rules as defined Section 3 of RFC8029." >=20 > Works for me. >=20 > > > > > > o If the responder LSR does not understand the "LAG Description > > > Indicator flag": > > > > > > * Clear both the "Downstream LAG Info Accommodation flag" and = the > > > "Upstream LAG Info Accommodation flag". > > > > > > Similarly, if an LSR does not understand a flag, it cannot give > > > special treatment to packets containing that flag. (Why an LSR > > > would not understand a flag defined in the same document that > > > defines the Capabilities TLV is beyond me, but you seem to want to > > > allow for that > > > case.) > > > > OK, I think it's OK to remove them. > > > > > > > > If the responder does not know the LSR Capability TLV, an MPLS ech= o > > > reply with the return code set to "One or more of the TLVs was not > > > understood" MUST be sent back to the initiator LSR. > > > > > > This duplicates the content I quoted at the top of this section's com= ments. > > > > OK, remove this duplicate text. > > > > > > > > Section 4.1 > > > > > > Once the initiator LSR knows the capabilities that a responder > > > supports, then it sends an MPLS echo request carrying a DDMAP with > > > the "LAG Description Indicator flag" (G) set to the responder LSR. > > > > > > nit: I think the key point is not that the initiator knows the > > > capabilities of the peer, but rather that the initiator knows that > > > the peer supports this specific mechanism. > > > > Yes. > > > > How about: > > "Once the initiator LSR knows that a responder can support this > meachanism, then it sends an MPLS echo request carrying a DDMAP TLV with > the "LAG Description Indicator flag" (G) set to the responder LSR." >=20 > Sounds good. >=20 > > > > > Also, is this "a DDMAP TLV"? > > > > Yes. > > > > > > > > Section 4.2 > > > > > > Reading this makes it sound like the "LAG Description Indicator > > > flag" is completely orthogonal to regular DDMAP functionality, so > > > that if I set the LAG description indicator flag but do not > > > otherwise request detailed descriptions, only the LAG interfaces are > > > returned. However, the flag in question has to be inside a DDMAP > > > TLV (and we should really say so, perhaps as "[flag] set *in the > > > DDMAP TLV*"!), so it seems like in practice the LAG information can > > > only be obtained in conjunction with full detailed description > > > information. (The specific suggestion here is to note clearly that > > > the flag is se in the DDMAP TLV.) > > > > Fixed. > > > > > > > > * The responder LSR MUST include a DDMAP TLV when sending the > > > MPLS echo reply. > > > > > > I got confused on my first pass through this section; adding "There > > > is a single DDMAP TLV for the LAG interface, with member links > > > described using sub- TLVs" here would have kept me from veering onto > the wrong path. > > > (I thought there was going to be one DDMAP TLV per member link, plus > > > one for the LAG aggregate, with lots of duplication.) > > > > Sure, added. > > > > > > > > Based on the procedures described above, every LAG member link wil= l > > > have a Local Interface Index Sub-TLV and a Multipath Data Sub-TLV > > > entries in the DDMAP TLV. The order of the Sub-TLVs in the DDMAP > TLV > > > for a LAG member link MUST be Local Interface Index Sub-TLV > > > immediately followed by Multipath Data Sub-TLV. A LAG member link > > > MAY also have a corresponding Remote Interface Index Sub-TLV. Whe= n > a > > > Local Interface Index Sub-TLV, a Remote Interface Index-Sub-TLV an= d a > > > Multipath Data Sub-TLV are placed in the DDMAP TLV to describe a L= AG > > > member link, they MUST be placed in the order of Local Interface > > > Index Sub-TLV, Remote Interface Index-Sub-TLV and Multipath Data > Sub- > > > TLV. > > > > > > This last MUST contradicts the previous MUST. I suggest some more > > > text to clarify under which conditions each requirement applies. > > > > OK, added. > > > > > > > > I'd also suggest not using the figure for conveying a (apparent?) > > > mandatory requirement, and instead adding some text at the end: "The > > > block of local interface index, (optional remote interface index) > > > and multipath data sub- TLVs for each member link MUST appear > > > adjacent to each other in order of increasing local interface index." > > > > OK, added. > > > > > > > > It's confusing to label the multiplath data sub-TLV as "MANDATORY" > > > when the body text says "MUST add an [sic] Multipath data Sub-TLV > > > [...] if the received DDMAP TLV requested multipath information", > > > i.e., it is not always present, based on the contents of the echo req= uest. > > > > Since it's just an example here, will remove the MANDATORY and > OPTIONAL. >=20 > Ah, good point. >=20 > > > When none of the received multipath information maps to a particul= ar > > > LAG member link, then the responder LSR MUST still place the Local > > > Interface Index Sub-TLV and the Multipath Data Sub-TLV for that LA= G > > > member link in the DDMAP TLV, the value of Multipath Length field = of > > > the Multipath Data Sub-TLV is set to zero. > > > > > > nit: the last comma is a comma splice. > > > > OK. > > > > > > > > Section 5.1.2 > > > > > > It seems like this places a slightly stronger burden on the > > > responder than stock 8029 does, in that there is a MUST-level > requirement to act on the 'I' > > > flag in combination with the 'G' flag, whereas for the 'I' > > > flag alone 8029 only has a SHOULD-level requirement to respond > accordingly. > > > We may want to call this out as a change in behavior. > > > > Will change to "SHOULD", then it can align with RFC8029. >=20 > I think that will be okay (it wasn't the change I was expecting, but I wi= ll > definitely defer to the authors and WG for this sort of thing!); I wasn't= sure if > the divergence was a conscious decision or not. >=20 > > > > > > Section 5.1.3 > > > > > > Expectation is that there's a relationship between the interface > > > index of the outgoing LAG member link at TTL=3Dn and the interface > > > index of the incoming LAG member link at TTL=3Dn+1 for all discove= red > > > entropies. In other words, set of entropies that load balances > > > to > > > > > > nit: "The expectation" > > > > Fixed. > > > > > nit: "discovered entropies" is a strange wording given how the > > > entropy label works; is this more like "all entropies examined"? > > > > OK, change to "all entropies examined". > > > > > > > > > > > The initiator LSR sends two MPLS echo request messages to traverse > > > the two LAG member links at TTL=3Dn+1: > > > > > > How does the initiator know (which entropy label values?) to get the > > > echo requests to traverse different member links? > > > > The initiator cannot exactly know which entropy label values are workab= le. > Presumably, the initiator can set different values according to the numbe= r of > member links, then the responder can use entropy values for hash to > traverse different member link. This is left to implementation. >=20 > Maybe add "(Depending on the LAG traffic division algorithm, the messages > may or may not traverse different member algorithms.)" or similar? OK, will do. >=20 > > > > > > o Error case: > > > > > > * One MPLS echo request message reaches TTL=3Dn+1 on an LAG > member > > > link 1. > > > > > > * The other MPLS echo request message also reaches TTL=3Dn+1 o= n an > > > LAG member link 1. > > > > > > One or two MPLS echo request messages sent by the initiator LSR > > > cannot reach the immediate downstream LSR, or the two MPLS echo > > > request messages reach at the immediate downstream LSR from the > > > same LAG member link. > > > > > > The description paragraph doesn't seem to match up the scenario > > > described in the sub-bullets, which leaves me confused as to what > > > scenario(s) are intended to be considered as the "error case". > > > > The sub-bullets are not complete, will add a third sub-bullet as below: > > > > "One or both MPLS echo request messages cannot reach the immediate > downstream LSR on whichever link." >=20 > That makes it sound like the sub-bullets are distinct options, and the to= p level > bullet is an "error cases" plural. My reading with just the two sub-bull= ets > present in the -06 was that both sub-bullets had to happen in order to be= in > the error case. >=20 > > > > > > Section 6 > > > > > > This document defines a new optional TLV which is referred to as t= he > > > "LSR Capability TLV. [...] > > > > > > Is this optional to use or comprehension-optional? (We elsewhere > > > rely on comprehension-mandatory behavior, so in the RFC 8029 > > > terminology this seems to be a "mandatory TLV" even if it is not > > > mandatory to use.) > > > > It's "mandatory TLV" according to RFC8029. >=20 > I think Alvaro is more on top of the subtleties here, so maybe we should > divert this topic to that ballot thread. OK, let's wait Alvaro's response. >=20 > > > > > > included in the MPLS echo reply message. Otherwise, if the respon= der > > > does not know the LSR Capability TLV, an MPLS echo reply with the > > > return code set to "One or more of the TLVs was not understood" > MUST > > > be sent back to the initiator LSR. > > > > > > This duplicates a requirement stated elsewhere (that really ought to > > > just be using existing required behavior from 8029 anyway). > > > > Remove it. > > > > > > > > LSR Capability TLV Type is TBD1. Length is 4. The value field > > > of > > > > > > In a hypothetical future where we need to allocate a 33rd capability > > > flag, would we rather create a new "extended capabilities" TLV > > > (burning another > > > 32 bits for type+length) or leave flexibility now for 'length' > > > to increase in multiples of 4 with receivers ignoring bits past what > > > they know about? > > > > IMHO, 32 bit seems reasonable enough for me. I incline to keep the flag > field as a fixed length. > > > > If we want it be extensible, maybe we could add optional sub-TLVs to th= is > TLV. >=20 > I agree that 32 bits seem likely to last for a very long time, so it's ha= rdly an > important point. I just wondered if anyone was going to enforce that the > length is exactly 4, which would prevent any further changes to this TLV > (other than allocating new bits). Maybe it can be relaxed to variable in length, and say the default is 4. >=20 > > > > > > The "LSR Capability Flags" field is 4 octets in length, this > > > document defines the following flags: > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > > | Must Be Zero (Reserved) |U|D= | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > I'm wary of describing these as "Must Be Zero", since they're just > > > unallocated but not required to be zero other than by the current sta= te of > bit allocations. > > > (I guess this is conventional for MPLS, though? So maybe it's not a > > > problem.) Just "Reserved" would be fine. > > > > OK. Change to "Reserved". > > > > > > > > This document defines two flags. The remaining flags MUST be s= et > > > to zero when sending and ignored on receipt. Both the U and th= e D > > > flag MUST be cleared in the MPLS echo request message when > > > sending, and ignored on receipt. Neither, either or both the U > > > and the D flag MAY be set in the MPLS echo reply message. > > > > > > Similarly, I think we want to say "unallocated flags" rather than > > > "the remaining flags". > > > > Fixed. > > > > > > > > It also seems like the semantics being described here are "the TLV > > > value is ignored in the echo request and only has meaning in the > response" > > > (i.e., this is a "tell me your capabilities" exchange, not a "here > > > are mine; what are yours?" exchange). As written, that applies only > > > to the U and D bits, and is not a general property. That may well > > > be a fine choice if we think we might want the two-way exchange for > > > some future allocated bit, but if we do think it's a general property= of the > mechanism, I'd suggest rewording the text. > > > > It's designed as an unidirectional tool, make it a two-way exchange > mechanism will require more considerations and substantial changes to dra= ft. > So, I inline to keep it as-is. If we have such use case in the future, we= update > this mechanism then. >=20 > Sure, thanks for thinking about it. >=20 > > > > > > Section 7 > > > > > > (Per IANA, bits 4 and 5 are already assigned but are not reflected > > > in the > > > diagram.) > > > > Fixed. > > > > > > > > Section 10 > > > > > > The Detailed Interface and Label Stack TLV format is derived from = the > > > Interface and Label Stack TLV format (from [RFC8029]). Two change= s > > > are introduced. The first is that the label stack is converted in= to > > > a sub-TLV. The second is that a new sub-TLV is added to describe = an > > > interface index. These fields of Detailed Interface and Label Sta= ck > > > TLV have the same use and meaning as in [RFC8029]. A summary of > > > these fields is as below: > > > > > > nit: Are "These fields" just "The other fields"? > > > > > > Fixed. > > > > > > > > The Address Type indicates if the interface is numbered or > > > unnumbered. It also determines the length of the IP Address > > > and Interface fields. The resulting total length of the > > > initial part of the TLV is listed as "K Octets". The Addres= s > > > Type is set to one of the following values: > > > > > > nit: is it better to list the currently allocated values or just > > > refer to the IANA registry? > > > > Since here it also include the length field. I'd like to keep it both h= ere and > the IANA registry. > > > > > > > > I seee that this "index assigned to the interface" language for > > > unnumbered address types originates from RFC 8029, but both this > > > document and 8029 leave me confused as to the encoding used for this > > > index (for either/both > > > IPv4 or IPv6 address types). > > > > It's normally an unsigned integer. >=20 > We probably should specify network byte order for it, then. OK. Best regards, Mach >=20 > > > > > > [My comment about "Must Be Zero" and allocatable bits also applies > > > here] > > > > Fixed as above. > > > > > > > > Section 12 > > > > > > This document also adds a capability "negotiation" mechanism for > > > MPLS echo request/reply exchanges. As MPLS does not offer integrity > > > protection for its messages, this negotiation is only as trustworthy > > > as the network from which messages are accepted as valid, and > > > initiators have no recourse but to accept faithfully the echo replies > received. > > > > > > To prevent leakage of vital information to untrusted users, a > > > responder LSR MUST only accept MPLS echo request messages from > > > designated trusted sources via filtering source IP address field o= f > > > received MPLS echo request messages. [...] > > > > > > I'd prefer to see a note added here about how "source IP address > > > filtering provides only a weak form of access control and is not, in > > > general, a reliable security mechanism. Nonetheless, it is required > > > here in the absence of any more robust mechanism that might be used." > > > > OK, added. > > > > > > > > > > Section 13 > > > > > > Should we ask IANA to update the "Interface and Label Stack Address > Types" > > > registry to also refer to this document, since we are sharing the > > > registry between the Interface and Label Stack TLV and the Detailed > version? > > > > Added. > > > > > > > > Section 13.2 > > > > > > The range 4-31743 spans two different allocation procedures > > > (Standards Action and Specification Required - Experimental RFC > > > needed); I assume that we want the 4-16383 range for Standards Action= - > mandatory TLVs. > > > > Yes. > > > > > > > > Section 13.4 > > > > > > We don't say what range we want this to be allocated from -- I > > > assume > > > 4-16383 since this is a negotiated feature and sending it outside > > > the negotiated scenario should be an error. > > > > Yes, suggested range added. > > > > > > > > Section 13.4.1 > > > > > > (I note that some existing sub-TLV registries have "Experimental RFC > > > required" for the experimental ranges, but that is arguably more > > > stringent than necessary; Specification Required seems more > > > appropriate for this case.) > > > > OK, change to " Specification Required". > > > > > > > > Appendix A > > > > > > I was kind of hoping for some more guidance on what an initiator > > > could do in these scenarios to try to get better visibility into the > > > switch behavior (and, hopefully, a workaround to get reliable echo > > > responses that cover all LAG member links). AFAICT there's not a > > > better option than "try a bunch of entropy labels and see what > > > responses you can get back" and that's the same remedy in all the > > > described topologies, but it would be nice to have this stated explic= itly for > the reader. > > > > A note will be added. >=20 > Thanks. >=20 > > > > > > Section A.1 > > > > > > In the worst case, MPLS echo request messages wit= h > > > specific entropies to exercise every LAG members from R1 to S1 can > > > all reach R2 via same LAG member. [...] > > > > > > I'm confused by the phrase "specific entropies to exercise every LAG > > > members [sic] from R1 to S1" -- is there some deterministic > > > algorithm by which a specific entropy label value will force a specif= ic LAG > member link? > > > > No. > > > > > My understanding was that the entropy was used as input to an opaque > > > hash function and that trial-and-error was the only way to explore > > > the mapping from entropy value to LAG member link taken. > > > > Yes. > > > > Thanks again for your detailed and valuable comments! >=20 > You're selcome! >=20 > -Benjamin From nobody Wed Mar 13 22:38:32 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8BF127994; Wed, 13 Mar 2019 22:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 U0k_uLcElZt6; Wed, 13 Mar 2019 22:38:20 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6044B12705F; Wed, 13 Mar 2019 22:38:20 -0700 (PDT) Received: from [192.168.1.20] (unknown [119.94.169.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 48F351801556; Thu, 14 Mar 2019 06:38:16 +0100 (CET) To: Alvaro Retana , Alvaro Retana via Datatracker , The IESG , Mach Chen Cc: "mpls@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" , "mpls-chairs@ietf.org" References: <155208210011.3264.12148702952456660789.idtracker@ietfa.amsl.com> From: Loa Andersson Message-ID: <9ede1e5e-319a-7b39-4700-202139fce4d6@pi.nu> Date: Thu, 14 Mar 2019 13:38:10 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 05:38:24 -0000 Alvaro, On 2019-03-14 11:30, Alvaro Retana wrote: > On March 13, 2019 at 10:14:42 AM, Mach Chen (mach.chen@huawei.com > ) wrote: > > Mach: > > Hi! > > ... >> > (2) §6: "Otherwise, if the responder does not know the LSR Capability TLV, an >> > MPLS echo reply with the return code set to "One or more of the TLVs was >> > not understood" MUST be sent back to the initiator LSR." Given that this is >> > the case where the new TLV is not known, then we can't Normatively direct >> > those nodes to do anything (since they probably don't implement anything in >> > this document). s/MUST/must + add a reference to rfc8029 (where the >> > behavior is >> > specified) [The same text appears again in §3 and §3.2. Writing the >> > specification is one place is enough.] >> >> It's more accurate to call it a "Mandatory" TLV that does not require >> an implementation has to implement it, but will result in return code >> when a node does not support it, as specified in RFC8029. >> Maybe we could just remove the "optional", and make it clear to the >> IANA section, the code point of this TLV should be allocated from the >> Mandatory range. How do you think? > > I think that optional should explicitly be replaced with mandatory…. > And, the IANA section should be clarified to indicate the range. > > No, I think this is wrong - the code point will be allocated from the range 0-16383 where code points are allocated by "Standards Action". This range is for mandatory TLVs or for optional TLVs that require an error message if not recognized. The difference between the two ranges is not that one is for "mandatory" TLVs and the for optional, but one is for TLVs that need a response if not recognized, the other can be silently dropped. The TLV we are discussing is optional. I have for a long time been aware of the there are some glitches in the description of the LSP Ping registries, and I'm preparing a draft to address this. /Loa > ... > >> > (3) This document doesn't talk about what should be done if a response is >> > not received, at any point in the process. I searched in rfc8029, but didn't >> > find anything related to timeouts...only §4.8 (Non-compliant Routers), which >> > includes a process on what to do if a reply is not received. That process >> > doesn't seem to apply to this document -- what should an initiator do if a >> > reply is not received? I am specially interested in the discovery phases. >> >> Normally, the timeout process is left the implementation (e.g., >> through timers). >> >> If a reply cannot be received within a certain period, the initiator >> will return timeout. That means there some issues along the path, >> operator should intervene then. > > Ok..so a log/notification of some kind should be raised. > > During the discovery process, it looks like some things could be > specified without operator intervention.  For example, the capabilities > may be discovered (§3), but the request about the LAG may not be > answered.  It seems to me that the initiator could simply retry…maybe > after some retries the log/notification can be raised.  Just thinking > out loud… Either way is fine with me... > > Thanks! > > Alvaro. > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Wed Mar 13 23:33:54 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC4912705F; Wed, 13 Mar 2019 23:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 N9-XYVjQGAmY; Wed, 13 Mar 2019 23:33:44 -0700 (PDT) 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 58B3F1200D7; Wed, 13 Mar 2019 23:33:44 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 07500653381D35EF3468; Thu, 14 Mar 2019 06:33:42 +0000 (GMT) Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 14 Mar 2019 06:33:41 +0000 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.190]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0415.000; Thu, 14 Mar 2019 14:33:35 +0800 From: Mach Chen To: Alvaro Retana , Alvaro Retana via Datatracker , The IESG CC: "mpls@ietf.org" , "mpls-chairs@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" Thread-Topic: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT) Thread-Index: AQHU1fmbThhWFHA7EEKjBTDftquDOKYI0X+wgAEpCwCAALQIUA== Date: Thu, 14 Mar 2019 06:33:34 +0000 Message-ID: References: <155208210011.3264.12148702952456660789.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE2928FD2A8dggeml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 06:33:48 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE2928FD2A8dggeml510mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWx2YXJvLA0KDQoNCkZyb206IEFsdmFybyBSZXRhbmEgW21haWx0bzphcmV0YW5hLmlldGZA Z21haWwuY29tXQ0KU2VudDogVGh1cnNkYXksIE1hcmNoIDE0LCAyMDE5IDExOjMxIEFNDQpUbzog QWx2YXJvIFJldGFuYSB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+OyBUaGUgSUVT RyA8aWVzZ0BpZXRmLm9yZz47IE1hY2ggQ2hlbiA8bWFjaC5jaGVuQGh1YXdlaS5jb20+DQpDYzog bXBsc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbXBscy1sc3At cGluZy1sYWctbXVsdGlwYXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIEFsdmFybyBS ZXRhbmEncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLWxhZy1tdWx0 aXBhdGgtMDY6ICh3aXRoIENPTU1FTlQpDQoNCk9uIE1hcmNoIDEzLCAyMDE5IGF0IDEwOjE0OjQy IEFNLCBNYWNoIENoZW4gKG1hY2guY2hlbkBodWF3ZWkuY29tPG1haWx0bzptYWNoLmNoZW5AaHVh d2VpLmNvbT4pIHdyb3RlOg0KDQpNYWNoOg0KDQpIaSENCg0KLi4uDQo+ICgyKSDCpzY6ICJPdGhl cndpc2UsIGlmIHRoZSByZXNwb25kZXIgZG9lcyBub3Qga25vdyB0aGUgTFNSIENhcGFiaWxpdHkg VExWLCBhbg0KPiBNUExTIGVjaG8gcmVwbHkgd2l0aCB0aGUgcmV0dXJuIGNvZGUgc2V0IHRvICJP bmUgb3IgbW9yZSBvZiB0aGUgVExWcyB3YXMNCj4gbm90IHVuZGVyc3Rvb2QiIE1VU1QgYmUgc2Vu dCBiYWNrIHRvIHRoZSBpbml0aWF0b3IgTFNSLiIgR2l2ZW4gdGhhdCB0aGlzIGlzDQo+IHRoZSBj YXNlIHdoZXJlIHRoZSBuZXcgVExWIGlzIG5vdCBrbm93biwgdGhlbiB3ZSBjYW4ndCBOb3JtYXRp dmVseSBkaXJlY3QNCj4gdGhvc2Ugbm9kZXMgdG8gZG8gYW55dGhpbmcgKHNpbmNlIHRoZXkgcHJv YmFibHkgZG9uJ3QgaW1wbGVtZW50IGFueXRoaW5nIGluDQo+IHRoaXMgZG9jdW1lbnQpLiBzL01V U1QvbXVzdCArIGFkZCBhIHJlZmVyZW5jZSB0byByZmM4MDI5ICh3aGVyZSB0aGUNCj4gYmVoYXZp b3IgaXMNCj4gc3BlY2lmaWVkKSBbVGhlIHNhbWUgdGV4dCBhcHBlYXJzIGFnYWluIGluIMKnMyBh bmQgwqczLjIuIFdyaXRpbmcgdGhlDQo+IHNwZWNpZmljYXRpb24gaXMgb25lIHBsYWNlIGlzIGVu b3VnaC5dDQoNCkl0J3MgbW9yZSBhY2N1cmF0ZSB0byBjYWxsIGl0IGEgIk1hbmRhdG9yeSIgVExW IHRoYXQgZG9lcyBub3QgcmVxdWlyZSBhbiBpbXBsZW1lbnRhdGlvbiBoYXMgdG8gaW1wbGVtZW50 IGl0LCBidXQgd2lsbCByZXN1bHQgaW4gcmV0dXJuIGNvZGUgd2hlbiBhIG5vZGUgZG9lcyBub3Qg c3VwcG9ydCBpdCwgYXMgc3BlY2lmaWVkIGluIFJGQzgwMjkuDQoNCk1heWJlIHdlIGNvdWxkIGp1 c3QgcmVtb3ZlIHRoZSAib3B0aW9uYWwiLCBhbmQgbWFrZSBpdCBjbGVhciB0byB0aGUgSUFOQSBz ZWN0aW9uLCB0aGUgY29kZSBwb2ludCBvZiB0aGlzIFRMViBzaG91bGQgYmUgYWxsb2NhdGVkIGZy b20gdGhlIE1hbmRhdG9yeSByYW5nZS4gSG93IGRvIHlvdSB0aGluaz8NCg0KSSB0aGluayB0aGF0 IG9wdGlvbmFsIHNob3VsZCBleHBsaWNpdGx5IGJlIHJlcGxhY2VkIHdpdGggbWFuZGF0b3J54oCm LiBBbmQsIHRoZSBJQU5BIHNlY3Rpb24gc2hvdWxkIGJlIGNsYXJpZmllZCB0byBpbmRpY2F0ZSB0 aGUgcmFuZ2UuDQoNCltNYWNoXSBBcyBMb2EgYW5kIERlYm9yYWggcG9pbnRlZCBvdXQsIHRoZSBU TFYgc2hvdWxkIGJlIGFuIG9wdGlvbmFsIFRMViwgYnV0IHRoZSBjb2RlIHBvaW50IHNob3VsZCBi ZSBhbGxvY2F0ZWQgZnJvbSB0aGUgTWFuZGF0b3J5IHJhbmdlLiBKdXN0IGFzIHRoZSBEb3duc3Ry ZWFtIERldGFpbGVkIE1hcHBpbmcgVExWIHdoaWNoIGlzIHVzZWQgaW4gdGhlIFJGQzgwMjkgaXMg YWxzbyBvcHRpb25hbCwgYnV0IGhhcyBhIGNvZGUgcG9pbnQgZnJvbSB0aGUgTWFuZGF0b3J5IHJh bmdlLg0KDQogIFNvLCB0aGUgc29sdXRpb24gd291bGQgYmU6IGtlZXAgaXQgYXMgYW4gb3B0aW9u YWwgVExWLCBhbmQgdXBkYXRlIElBTkEgc2VjdGlvbiB0byBpbmRpY2F0ZSB0aGUgcmFuZ2UuIElz IHRoaXMgT0sgZm9yIHlvdT8NCg0KDQoNCg0KDQouLi4NCj4gKDMpIFRoaXMgZG9jdW1lbnQgZG9l c24ndCB0YWxrIGFib3V0IHdoYXQgc2hvdWxkIGJlIGRvbmUgaWYgYSByZXNwb25zZSBpcw0KPiBu b3QgcmVjZWl2ZWQsIGF0IGFueSBwb2ludCBpbiB0aGUgcHJvY2Vzcy4gSSBzZWFyY2hlZCBpbiBy ZmM4MDI5LCBidXQgZGlkbid0DQo+IGZpbmQgYW55dGhpbmcgcmVsYXRlZCB0byB0aW1lb3V0cy4u Lm9ubHkgwqc0LjggKE5vbi1jb21wbGlhbnQgUm91dGVycyksIHdoaWNoDQo+IGluY2x1ZGVzIGEg cHJvY2VzcyBvbiB3aGF0IHRvIGRvIGlmIGEgcmVwbHkgaXMgbm90IHJlY2VpdmVkLiBUaGF0IHBy b2Nlc3MNCj4gZG9lc24ndCBzZWVtIHRvIGFwcGx5IHRvIHRoaXMgZG9jdW1lbnQgLS0gd2hhdCBz aG91bGQgYW4gaW5pdGlhdG9yIGRvIGlmIGENCj4gcmVwbHkgaXMgbm90IHJlY2VpdmVkPyBJIGFt IHNwZWNpYWxseSBpbnRlcmVzdGVkIGluIHRoZSBkaXNjb3ZlcnkgcGhhc2VzLg0KDQpOb3JtYWxs eSwgdGhlIHRpbWVvdXQgcHJvY2VzcyBpcyBsZWZ0IHRoZSBpbXBsZW1lbnRhdGlvbiAoZS5nLiwg dGhyb3VnaCB0aW1lcnMpLg0KDQpJZiBhIHJlcGx5IGNhbm5vdCBiZSByZWNlaXZlZCB3aXRoaW4g YSBjZXJ0YWluIHBlcmlvZCwgdGhlIGluaXRpYXRvciB3aWxsIHJldHVybiB0aW1lb3V0LiBUaGF0 IG1lYW5zIHRoZXJlIHNvbWUgaXNzdWVzIGFsb25nIHRoZSBwYXRoLCBvcGVyYXRvciBzaG91bGQg aW50ZXJ2ZW5lIHRoZW4uDQoNCk9rLi5zbyBhIGxvZy9ub3RpZmljYXRpb24gb2Ygc29tZSBraW5k IHNob3VsZCBiZSByYWlzZWQuDQoNCkR1cmluZyB0aGUgZGlzY292ZXJ5IHByb2Nlc3MsIGl0IGxv b2tzIGxpa2Ugc29tZSB0aGluZ3MgY291bGQgYmUgc3BlY2lmaWVkIHdpdGhvdXQgb3BlcmF0b3Ig aW50ZXJ2ZW50aW9uLiAgRm9yIGV4YW1wbGUsIHRoZSBjYXBhYmlsaXRpZXMgbWF5IGJlIGRpc2Nv dmVyZWQgKMKnMyksIGJ1dCB0aGUgcmVxdWVzdCBhYm91dCB0aGUgTEFHIG1heSBub3QgYmUgYW5z d2VyZWQuICBJdCBzZWVtcyB0byBtZSB0aGF0IHRoZSBpbml0aWF0b3IgY291bGQgc2ltcGx5IHJl dHJ54oCmbWF5YmUgYWZ0ZXIgc29tZSByZXRyaWVzIHRoZSBsb2cvbm90aWZpY2F0aW9uIGNhbiBi ZSByYWlzZWQuICBKdXN0IHRoaW5raW5nIG91dCBsb3Vk4oCmIEVpdGhlciB3YXkgaXMgZmluZSB3 aXRoIG1lLi4uDQoNCltNYWNoXSBPSywgdGhhbmtzIQ0KDQoNCg0KQmVzdCByZWdhcmRzLA0KDQpN YWNoDQoNCg0KDQpUaGFua3MhDQoNCkFsdmFyby4NCg== --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE2928FD2A8dggeml510mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQt c3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1h aWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5 MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEFsdmFybyw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2Qi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBzaXpl PSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbHZhcm8NCiBSZXRhbmEgW21h aWx0bzphcmV0YW5hLmlldGZAZ21haWwuY29tXSA8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+U2VudDo8L3NwYW4+PC9iPiBUaHVyc2RheSwgTWFyY2ggMTQsIDIwMTkgMTE6 MzEgQU08YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86PC9zcGFuPjwv Yj4gQWx2YXJvIFJldGFuYSB2aWEgRGF0YXRyYWNrZXIgJmx0O25vcmVwbHlAaWV0Zi5vcmcmZ3Q7 OyBUaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDs7IE1hY2ggQ2hlbiAmbHQ7bWFjaC5jaGVu QGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNj Ojwvc3Bhbj48L2I+IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQGlldGYub3JnOyBkcmFmdC1p ZXRmLW1wbHMtbHNwLXBpbmctbGFnLW11bHRpcGF0aEBpZXRmLm9yZzxicj4NCjxiPjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0Ojwvc3Bhbj48L2I+IFJlOiBbbXBsc10gQWx2 YXJvIFJldGFuYSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctbGFn LW11bHRpcGF0aC0wNjogKHdpdGggQ09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iSGVsdmV0aWNhIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24g TWFyY2ggMTMsIDIwMTkgYXQgMTA6MTQ6NDIgQU0sIE1hY2ggQ2hlbiAoPGEgaHJlZj0ibWFpbHRv Om1hY2guY2hlbkBodWF3ZWkuY29tIj5tYWNoLmNoZW5AaHVhd2VpLmNvbTwvYT4pIHdyb3RlOjxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJIZWx2ZXRpY2EiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iSGVsdmV0aWNhIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+TWFjaDo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iSGVsdmV0aWNh Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9 IkhlbHZldGljYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkhpITxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIy IiBmYWNlPSJIZWx2ZXRpY2EiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMiIgZmFjZT0iSGVsdmV0aWNhIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Li4uPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQ7Zm9udC12YXJpYW50LWNhcHM6 bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkhlbHZldGljYSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsgKDIpIMKnNjogJnF1b3Q7T3RoZXJ3aXNlLCBpZiB0aGUgcmVz cG9uZGVyIGRvZXMgbm90IGtub3cgdGhlIExTUiBDYXBhYmlsaXR5IFRMViwgYW4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWdu OnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJIZWx2ZXRpY2EiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4m Z3Q7IE1QTFMgZWNobyByZXBseSB3aXRoIHRoZSByZXR1cm4gY29kZSBzZXQgdG8gJnF1b3Q7T25l IG9yIG1vcmUgb2YgdGhlIFRMVnMgd2FzPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsgbm90IHVuZGVyc3Rvb2QmcXVvdDsgTVVTVCBiZSBz ZW50IGJhY2sgdG8gdGhlIGluaXRpYXRvciBMU1IuJnF1b3Q7IEdpdmVuIHRoYXQgdGhpcyBpczxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7 IHRoZSBjYXNlIHdoZXJlIHRoZSBuZXcgVExWIGlzIG5vdCBrbm93biwgdGhlbiB3ZSBjYW4ndCBO b3JtYXRpdmVseSBkaXJlY3Q8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGJyPg0KJmd0OyB0aG9zZSBub2RlcyB0byBkbyBhbnl0aGluZyAoc2luY2UgdGhl eSBwcm9iYWJseSBkb24ndCBpbXBsZW1lbnQgYW55dGhpbmcgaW48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyB0aGlzIGRvY3VtZW50KS4g cy9NVVNUL211c3QgJiM0MzsgYWRkIGEgcmVmZXJlbmNlIHRvIHJmYzgwMjkgKHdoZXJlIHRoZTxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7 IGJlaGF2aW9yIGlzPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxicj4NCiZndDsgc3BlY2lmaWVkKSBbVGhlIHNhbWUgdGV4dCBhcHBlYXJzIGFnYWluIGlu IMKnMyBhbmQgwqczLjIuIFdyaXRpbmcgdGhlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsgc3BlY2lmaWNhdGlvbiBpcyBvbmUgcGxhY2Ug aXMgZW5vdWdoLl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGJyPg0KPGJyPg0KSXQncyBtb3JlIGFjY3VyYXRlIHRvIGNhbGwgaXQgYSAmcXVvdDtNYW5k YXRvcnkmcXVvdDsgVExWIHRoYXQgZG9lcyBub3QgcmVxdWlyZSBhbiBpbXBsZW1lbnRhdGlvbiBo YXMgdG8gaW1wbGVtZW50IGl0LCBidXQgd2lsbCByZXN1bHQgaW4gcmV0dXJuIGNvZGUgd2hlbiBh IG5vZGUgZG9lcyBub3Qgc3VwcG9ydCBpdCwgYXMgc3BlY2lmaWVkIGluIFJGQzgwMjkuPHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7d29y ZC1zcGFjaW5nOjBweCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjIiIGZhY2U9IkhlbHZldGljYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCk1heWJl IHdlIGNvdWxkIGp1c3QgcmVtb3ZlIHRoZSAmcXVvdDtvcHRpb25hbCZxdW90OywgYW5kIG1ha2Ug aXQgY2xlYXIgdG8gdGhlIElBTkEgc2VjdGlvbiwgdGhlIGNvZGUgcG9pbnQgb2YgdGhpcyBUTFYg c2hvdWxkIGJlIGFsbG9jYXRlZCBmcm9tIHRoZSBNYW5kYXRvcnkgcmFuZ2UuIEhvdyBkbyB5b3Ug dGhpbms/PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cD48Zm9udCBzaXplPSIyIiBmYWNlPSJIZWx2ZXRpY2EiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5JIHRoaW5rIHRoYXQgb3B0aW9uYWwgc2hvdWxkIGV4cGxpY2l0bHkgYmUgcmVwbGFj ZWQgd2l0aCBtYW5kYXRvcnnigKYuIEFuZCwgdGhlIElBTkEgc2VjdGlvbiBzaG91bGQgYmUgY2xh cmlmaWVkIHRvIGluZGljYXRlIHRoZSByYW5nZS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPHA+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bTWFjaF0gQXMgTG9hIGFuZCBEZWJvcmFoIHBvaW50 ZWQgb3V0LCB0aGUgVExWIHNob3VsZCBiZSBhbiBvcHRpb25hbCBUTFYsIGJ1dCB0aGUgY29kZSBw b2ludCBzaG91bGQgYmUgYWxsb2NhdGVkIGZyb20gdGhlIE1hbmRhdG9yeQ0KIHJhbmdlLiBKdXN0 IGFzIHRoZSBEb3duc3RyZWFtIERldGFpbGVkIE1hcHBpbmcgVExWIHdoaWNoIGlzIHVzZWQgaW4g dGhlIFJGQzgwMjkgaXMgYWxzbyBvcHRpb25hbCwgYnV0IGhhcyBhIGNvZGUgcG9pbnQgZnJvbSB0 aGUgTWFuZGF0b3J5IHJhbmdlLg0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwPjxm b250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7U28sIHRoZSBzb2x1dGlvbiB3b3VsZCBiZTog a2VlcCBpdCBhcyBhbiBvcHRpb25hbCBUTFYsIGFuZCB1cGRhdGUgSUFOQSBzZWN0aW9uIHRvIGlu ZGljYXRlIHRoZSByYW5nZS4gSXMgdGhpcyBPSyBmb3IgeW91PzxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cD48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8cD48Zm9udCBzaXplPSIyIiBmYWNlPSJIZWx2ZXRpY2EiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHA+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iSGVsdmV0aWNhIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Li4uPG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3Jt YWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iSGVsdmV0aWNhIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+Jmd0OyAoMykgVGhpcyBkb2N1bWVudCBkb2Vzbid0IHRhbGsgYWJvdXQgd2hh dCBzaG91bGQgYmUgZG9uZSBpZiBhIHJlc3BvbnNlIGlzPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsgbm90IHJlY2VpdmVkLCBhdCBhbnkg cG9pbnQgaW4gdGhlIHByb2Nlc3MuIEkgc2VhcmNoZWQgaW4gcmZjODAyOSwgYnV0IGRpZG4ndDxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7 IGZpbmQgYW55dGhpbmcgcmVsYXRlZCB0byB0aW1lb3V0cy4uLm9ubHkgwqc0LjggKE5vbi1jb21w bGlhbnQgUm91dGVycyksIHdoaWNoPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsgaW5jbHVkZXMgYSBwcm9jZXNzIG9uIHdoYXQgdG8gZG8g aWYgYSByZXBseSBpcyBub3QgcmVjZWl2ZWQuIFRoYXQgcHJvY2VzczxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7IGRvZXNuJ3Qgc2VlbSB0 byBhcHBseSB0byB0aGlzIGRvY3VtZW50IC0tIHdoYXQgc2hvdWxkIGFuIGluaXRpYXRvciBkbyBp ZiBhPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4N CiZndDsgcmVwbHkgaXMgbm90IHJlY2VpdmVkPyBJIGFtIHNwZWNpYWxseSBpbnRlcmVzdGVkIGlu IHRoZSBkaXNjb3ZlcnkgcGhhc2VzLjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQpOb3JtYWxseSwgdGhlIHRpbWVvdXQgcHJvY2VzcyBp cyBsZWZ0IHRoZSBpbXBsZW1lbnRhdGlvbiAoZS5nLiwgdGhyb3VnaCB0aW1lcnMpLjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQpJZiBh IHJlcGx5IGNhbm5vdCBiZSByZWNlaXZlZCB3aXRoaW4gYSBjZXJ0YWluIHBlcmlvZCwgdGhlIGlu aXRpYXRvciB3aWxsIHJldHVybiB0aW1lb3V0LiBUaGF0IG1lYW5zIHRoZXJlIHNvbWUgaXNzdWVz IGFsb25nIHRoZSBwYXRoLCBvcGVyYXRvciBzaG91bGQgaW50ZXJ2ZW5lIHRoZW4uPHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cD48 Zm9udCBzaXplPSIyIiBmYWNlPSJIZWx2ZXRpY2EiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Pay4uc28g YSBsb2cvbm90aWZpY2F0aW9uIG9mIHNvbWUga2luZCBzaG91bGQgYmUgcmFpc2VkLiAmbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iSGVs dmV0aWNhIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RHVyaW5nIHRoZSBkaXNjb3ZlcnkgcHJvY2Vzcywg aXQgbG9va3MgbGlrZSBzb21lIHRoaW5ncyBjb3VsZCBiZSBzcGVjaWZpZWQgd2l0aG91dCBvcGVy YXRvciBpbnRlcnZlbnRpb24uJm5ic3A7IEZvciBleGFtcGxlLCB0aGUgY2FwYWJpbGl0aWVzIG1h eSBiZSBkaXNjb3ZlcmVkICjCpzMpLA0KIGJ1dCB0aGUgcmVxdWVzdCBhYm91dCB0aGUgTEFHIG1h eSBub3QgYmUgYW5zd2VyZWQuJm5ic3A7IEl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIGluaXRpYXRv ciBjb3VsZCBzaW1wbHkgcmV0cnnigKZtYXliZSBhZnRlciBzb21lIHJldHJpZXMgdGhlIGxvZy9u b3RpZmljYXRpb24gY2FuIGJlIHJhaXNlZC4mbmJzcDsgSnVzdCB0aGlua2luZyBvdXQgbG91ZOKA piBFaXRoZXIgd2F5IGlzIGZpbmUgd2l0aCBtZS4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8cD48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltNYWNoXSBPSywgdGhhbmtzITxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8cD48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cD48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIg ZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJk cyw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iMiIgY29sb3I9 IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5N YWNoPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9IjIiIGNvbG9y PSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9IjIiIGZh Y2U9IkhlbHZldGljYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyEmbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iSGVsdmV0aWNhIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+QWx2YXJvLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE2928FD2A8dggeml510mbxchi_-- From nobody Thu Mar 14 01:46:19 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 800531277C9; Thu, 14 Mar 2019 01:46:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari via Datatracker To: "The IESG" Cc: draft-ietf-mpls-sr-over-ip@ietf.org, Loa Andersson , mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org, acm@research.att.com X-Test-IDTracker: no X-IETF-IDTracker: 6.94.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <155255317751.2645.12883136190346380957.idtracker@ietfa.amsl.com> Date: Thu, 14 Mar 2019 01:46:17 -0700 Archived-At: Subject: [mpls] Warren Kumari's No Objection on draft-ietf-mpls-sr-over-ip-03: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 08:46:18 -0000 Warren Kumari has entered the following ballot position for draft-ietf-mpls-sr-over-ip-03: 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-mpls-sr-over-ip/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you very much for writing this - I think it is useful. Also, thanks to Al Morton for the OpsDir review, and for addressing his comment. From nobody Thu Mar 14 03:24:45 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2709128CB7; Thu, 14 Mar 2019 03:24:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Vigoureux via Datatracker To: "The IESG" Cc: draft-ietf-mpls-sfc-encapsulation@ietf.org, Loa Andersson , mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Vigoureux Message-ID: <155255907978.2609.2747211710494136361.idtracker@ietfa.amsl.com> Date: Thu, 14 Mar 2019 03:24:39 -0700 Archived-At: Subject: [mpls] Martin Vigoureux's No Objection on draft-ietf-mpls-sfc-encapsulation-03: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 10:24:40 -0000 Martin Vigoureux has entered the following ballot position for draft-ietf-mpls-sfc-encapsulation-03: 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-mpls-sfc-encapsulation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Without having looked before I was thinking this was Standard Track, I'm surprised it is not. You say: 1. Push zero or more labels that are interpreted by the destination MPLS node on to the packet, and then say: The receiving MPLS node then pops the SFF Label (and any labels beneath it) So it looks like that any label which might have been pushed before the SFF label is/are simply ignored at the other end. I'm not asking for the behaviour to be specified and I understand that strictly speaking the text is not forbidding something to happen based on these labels but still it might be useful to explicitly say that these labels may be processed. From nobody Thu Mar 14 07:03:05 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3CD130DD6; Thu, 14 Mar 2019 07:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_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 psuL9ijVBChq; Thu, 14 Mar 2019 07:03:00 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 61611129B88; Thu, 14 Mar 2019 07:03:00 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id m13so4316170lfb.6; Thu, 14 Mar 2019 07:03:00 -0700 (PDT) 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=LniJoLF77kVePKnv56PsnDt6ncxl8UWDqqsa3jhnXb0=; b=Gw9xsLlU/7Q5fTbS8zQNo6ax/mmp/+7a37yN6wb9T0oJ9bU0GmYicQvxQqJkcQVLUW nsBe2Njd/LIv/YTfHGXmQEPZaByTD6mVFQfL8/HifPXP9XeCjWfnYi4tC41jEp+tincc T3dhNhqkPzFU1AASvhIKHcOmx5Be7vP7YlUDwtdsWwiMH+JqJzY45nnwhF5T8HkNYYat MkMGx+/BwNnogPkVBRu0TWKeWp3cbIfKYBKk7cFspU9NMHCibiRBng4hmYBdj9K6Dxo9 BzWS8AS7Ixf+QhYH55TWr6BifeVFPmPGKDQvLiBg7GxKHhzAzf8lizLjwWFSg3oTHxuT RCJw== 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=LniJoLF77kVePKnv56PsnDt6ncxl8UWDqqsa3jhnXb0=; b=MXAMYPejZILVxWoiJ2FvM5u5bYFkiAm/EvDWF1IOjqvtmalQyV6zkyCwHEB9Q41fEy 0UFbr6IpeZyAw0c/RBfakF362AmE7RtH9uJm4p5mbNahD6a+RAJ4hUz+/+A63YgIRLxE j4SSz12k6o4uCQOLIOa1/A52XNqQu2oyclKc/6jP9NA6pf5UGZhMo+UY/kbM4gL62231 gd00JTxBnYNWwsskqFOOt6P7CTOvrQeDDcqutWQlskaRVVCQBO5Yy7SGeFx1/MMmpeuU 0dh2nPZFFt+BI9OUf4EEiaGicXT14tTc5PWOwRsTWfYMeThhNeV5lf9uGqbk9KcOsj/E RQnA== X-Gm-Message-State: APjAAAUAhZsTHnziVAKa/MMz9NyBrsHNFlu7eK6PmdykYf6bCpmTd27O 3TFJ9B4sTWRHPP+2GPi5NX8/9hpb1W9MRj8GzjHbqQO2 X-Google-Smtp-Source: APXvYqzWOfboOiGHAoPqSg+XD9G/2+NIHrN678ISJ79r7jCuPnqKVhrgxZaLt16Qa91IMJRwhG0WZeJzQFuXlel+P18= X-Received: by 2002:a19:9e0d:: with SMTP id h13mr11879606lfe.51.1552572178174; Thu, 14 Mar 2019 07:02:58 -0700 (PDT) MIME-Version: 1.0 References: <155238798836.13888.12133834062700877951.idtracker@ietfa.amsl.com> <001601d4d8d4$2808d1c0$781a7540$@olddog.co.uk> <35AA21D8-14B0-4AF3-A46C-A0349B7697FD@kuehlewind.net> <01ba01d4d99e$eade89e0$c09b9da0$@olddog.co.uk> In-Reply-To: <01ba01d4d99e$eade89e0$c09b9da0$@olddog.co.uk> From: Spencer Dawkins at IETF Date: Thu, 14 Mar 2019 09:02:46 -0500 Message-ID: To: Adrian Farrel Cc: Mirja Kuehlewind , mpls@ietf.org, draft-ietf-mpls-sr-over-ip@ietf.org, =?UTF-8?Q?Mirja_K=C3=BChlewind_via_Datatracker?= , mpls-chairs@ietf.org, The IESG , Loa Andersson Content-Type: multipart/alternative; boundary="0000000000002b2a4505840e61a4" Archived-At: Subject: Re: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?mpls-sr-over-ip-03=3A_=28with_DISCUSS=29?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 14:03:04 -0000 --0000000000002b2a4505840e61a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For the IESG ... On Wed, Mar 13, 2019 at 8:16 AM Adrian Farrel wrote: > Thanks Mirja, > > >>> 1) Given section 3.1, the following drafts all seems that they > >>> should be normative references: ietf-isis-encapsulation-cap, > >>> ietf-ospf-encapsulation-cap, ietf-ospf-segment-routing-extensions, > >>> ietf-isis-segment-routing-extensions > >> > >> Well, that wasn't the intention. It is meant to be an example of > >> how the forwarding entries are constructed. > >> > >> As it says at the top of Section 3... > >> Note that the examples in > >> Section 3.1 and Section 3.2 assume that OSPF or ISIS is enabled: in > >> fact, other mechanisms of discovery and advertisement could be used > >> including other routing protocols (such as BGP) or a central > >> controller. > >> > >> We could be more explicit in section 3.1 so that, for example... > >> > >> OLD > >> o The Segment Routing Global Block (SRGB) is defined in [RFC8402]. > >> Router E is SR-MPLS capable, so it advertises an SRGB as describe= d > >> in [I-D.ietf-ospf-segment-routing-extensions] and > >> [I-D.ietf-isis-segment-routing-extensions]. > >> NEW > >> o The Segment Routing Global Block (SRGB) is defined in [RFC8402]. > >> Router E is SR-MPLS capable, so it advertises an SRGB to the othe= r > >> SR-MPLS capable routers. If an IGP is in use then Router E behav= es > >> as described in [I-D.ietf-ospf-segment-routing-extensions] and > >> [I-D.ietf-isis-segment-routing-extensions], but other mechanisms > >> Could be applied. > >> END > >> > >> We'd need to make similar changes throughout the section. > >> > >> Would such changes be enough for you? > > > > It still sounds to me that these document are basically a must read > > to understand the full picture. Do you think it would be a problem > > or the wrong thing to make these reference normative? > > > > However, your wording change makes it definitely more clear that > > this is only one example. If the wg and responsible ADs think, it=E2=80= =99s > > the right thing to do to leave the reference informative, I will clear > > my discuss. > > I was worried about the rate of progress of SR documents. There has been = a > tendency for them to travel a little slowly. > > It looks like these documents have all now progressed far enough, but the= y > are caught up in a deadly cluster of missing references (cluster 340). > We'll have a look through the cluster to see how dangerous it is and make > normative references where we can. > "Deadly clusters" would be a FABulous retreat topic for the next IESG. I'm stepping down after three terms on the IESG,and I have documents in C238 ( https://www.rfc-editor.org/cluster_info.php?cid=3DC238) that have been in t= he RFC Editor queue since halfway through my first term. We've even updated stuff that's been in this cluster but hasn't been published yet, which confused the heck out of everyone. "Living PS", anyone? Spencer > > >>> 2) Sec 3.2.3 on IP Header fields should refer to RFC6040 for the ECN > >>> field and eventually RFC2983 for DSCP. > >> > >> That's good. Thanks. It gives us... > >> > >> When encapsulating an MPL= S > >> packet in UDP, the resulting packet is further encapsulated > in > >> IP for transmission. IPv4 or IPv6 may be used according to > the > >> capabilities of the network. The address fields are set as > >> described in . The other IP head= er > >> fields (such as the ECN field , t= he > DSCP > >> code point , or IPv6 Flow Label) = on > each > >> UDP-encapsulated segment SHOULD be configurable according t= o > the > >> operator's policy: they may be copied from the header > of the > >> incoming packet; they may be promoted from the header of th= e > >> payload packet; they may be set according to instructions > >> programmed to be associated with the SID; or they may be > >> configured dependent on the outgoing interface and > payload. > > > > Yes, thanks! > > Perfect. It's in my working copy. > > Best, > Adrian > > --0000000000002b2a4505840e61a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For the IESG ...=C2=A0

On Wed, Mar 13= , 2019 at 8:16 AM Adrian Farrel <= adrian@olddog.co.uk> wrote:
Thanks Mirja,

>>> 1) Given section 3.1, the following drafts all seems that they=
>>> should be normative references: ietf-isis-encapsulation-cap, >>> ietf-ospf-encapsulation-cap, ietf-ospf-segment-routing-extensi= ons,
>>> ietf-isis-segment-routing-extensions
>>
>> Well, that wasn't the intention. It is meant to be an example = of
>> how the forwarding entries are constructed.
>>
>> As it says at the top of Section 3...
>>=C2=A0 =C2=A0Note that the examples in
>>=C2=A0 =C2=A0Section 3.1 and Section 3.2 assume that OSPF or ISIS i= s enabled: in
>>=C2=A0 =C2=A0fact, other mechanisms of discovery and advertisement = could be used
>>=C2=A0 =C2=A0including other routing protocols (such as BGP) or a c= entral
>>=C2=A0 =C2=A0controller.
>>
>> We could be more explicit in section 3.1 so that, for example... >>
>> OLD
>>=C2=A0 =C2=A0o=C2=A0 The Segment Routing Global Block (SRGB) is def= ined in [RFC8402].
>>=C2=A0 =C2=A0 =C2=A0 Router E is SR-MPLS capable, so it advertises = an SRGB as described
>>=C2=A0 =C2=A0 =C2=A0 in [I-D.ietf-ospf-segment-routing-extensions] = and
>>=C2=A0 =C2=A0 =C2=A0 [I-D.ietf-isis-segment-routing-extensions]. >> NEW
>>=C2=A0 =C2=A0o=C2=A0 The Segment Routing Global Block (SRGB) is def= ined in [RFC8402].
>>=C2=A0 =C2=A0 =C2=A0 Router E is SR-MPLS capable, so it advertises = an SRGB to the other
>>=C2=A0 =C2=A0 =C2=A0 SR-MPLS capable routers.=C2=A0 If an IGP is in= use then Router E behaves
>>=C2=A0 =C2=A0 =C2=A0 as described in [I-D.ietf-ospf-segment-routing= -extensions] and
>>=C2=A0 =C2=A0 =C2=A0 [I-D.ietf-isis-segment-routing-extensions], bu= t other mechanisms
>>=C2=A0 =C2=A0 =C2=A0 Could be applied.
>> END
>>
>> We'd need to make similar changes throughout the section.
>>
>> Would such changes be enough for you?
>
> It still sounds to me that these document are basically a must read > to understand the full picture. Do you think it would be a problem
> or the wrong thing to make these reference normative?
>
> However, your wording change makes it definitely more clear that
> this is only one example. If the wg and responsible ADs think, it=E2= =80=99s
> the right thing to do to leave the reference informative, I will clear=
> my discuss.

I was worried about the rate of progress of SR documents. There has been a = tendency for them to travel a little slowly.

It looks like these documents have all now progressed far enough, but they = are caught up in a deadly cluster of missing references (cluster 340). We&#= 39;ll have a look through the cluster to see how dangerous it is and make n= ormative references where we can.

"= ;Deadly clusters" would be a FABulous retreat topic for the next IESG.= I'm stepping down after three terms on the IESG,and I have documents i= n C238 (= https://www.rfc-editor.org/cluster_info.php?cid=3DC238) that have been = in the RFC Editor queue since halfway through my first term. We've even= updated stuff that's been in this cluster but hasn't been publishe= d yet, which confused the heck out of everyone. "Living PS", anyo= ne?

Spencer

>>> 2) Sec 3.2.3 on IP Header fields should refer to RFC6040 for t= he ECN
>>> field and eventually RFC2983 for DSCP.
>>
>> That's good. Thanks. It gives us...
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <t hangText=3D"IP= Header Fields:">When encapsulating an MPLS
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 packet in UDP, the result= ing packet is further encapsulated in
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IP for transmission. IPv4= or IPv6 may be used according to the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 capabilities of the netwo= rk. The address fields are set as
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 described in <xref tar= get=3D"usecases"/>. The other IP header
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fields (such as the ECN f= ield <xref target=3D"RFC6040"/>, the DSCP
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 code point <xref targe= t=3D"RFC2983"/>, or IPv6 Flow Label) on each
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 UDP-encapsulated segment = SHOULD be configurable according to the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 operator&apos;s polic= y: they may be copied from the header of the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 incoming packet; they may= be promoted from the header of the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 payload packet; they may = be set according to instructions
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 programmed to be associat= ed with the SID; or they may be
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 configured dependent on t= he outgoing interface and payload.</t>
>
> Yes, thanks!

Perfect. It's in my working copy.

Best,
Adrian

--0000000000002b2a4505840e61a4-- From nobody Fri Mar 15 07:00:29 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE64130DC4; Fri, 15 Mar 2019 07:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_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 O46PRbzacRBr; Fri, 15 Mar 2019 07:00:25 -0700 (PDT) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 87F59130D7A; Fri, 15 Mar 2019 07:00:25 -0700 (PDT) Received: by mail-it1-x131.google.com with SMTP id z124so10959446itc.2; Fri, 15 Mar 2019 07:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=AWVgq4fmzpXzt+JIy4iff0ec8KE4ZCf6Ev9cyZRcEok=; b=TC3dKN00J0q3OU/0ocblQhIOBpZ0nlENc1bW0AfH/DeFAn4WAhrZ+8uwgXEnAXduVO AqjhCEnBwyc8OPcR3M1kYu99TRtNma14CLGyFKMTwptfFCRltU4MGB1RA3Ik/c+kVeTf JHpVGcv6t/au6oWpt3eHhKk0cHA0ys1WWi2n53jRS3m8hKzVpkAqFfIEIUvthVl+vArb Cwt0nLCCXvLNe9zVXmrJasRmARbVAGeAwLn7Aw5QSvIKuKOmFpoKI9cToakS5FPcZ3HR 42ttwz6N2nP6mC+GPI3mX7C1t68JYN/kayJ18ujl7+JIJ6OoqJ6cl6sRNeCFCVENSdIf okYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=AWVgq4fmzpXzt+JIy4iff0ec8KE4ZCf6Ev9cyZRcEok=; b=uDHeDoUIBc3aEY2tBch5SgLRv8byXvp2LBXx3mvIBOnAkykaUMU7ywIPS52LRTddr1 i4moCvMTdFvdk9X4WA2lh26+JozJFqWiWqLbNPgPbcafExi1PX1yPxAkHjdZy13AFlyW 6MMXCmW8wWEgXJZqvjfNv9HNYtFu2sQmZqI4gRYM2viv8z5W4H6rzX9Scuf/bGGwjsy+ BJaNCjTdNDeFGZ6OgTsUi46naerWGOFvycQvh6ev8YR1jjniaWhFr5FRCY3zSIn+egQE Od1C8qLXs4lA4KjsMAWPdwFvZKhUWQC4HMprkBMKiWq8KUx31yNNihKcRrmkRrNsejVO Ny0Q== X-Gm-Message-State: APjAAAVHkgAMnm88r+mwHX0bHzW21BG70CrOe7aOWfdRZRqkJD6POcQS T+CyKTjOwfpt5X11VxBj4NUmfSF3/9A= X-Google-Smtp-Source: APXvYqyZ+OBkJaXvfLyTOifglpVg9ovp89Yn+rSJIRgT4/x8hJ9NedN0v3JLl50aAjekfsDOTU14Vw== X-Received: by 2002:a24:75c7:: with SMTP id y190mr2119893itc.108.1552658424432; Fri, 15 Mar 2019 07:00:24 -0700 (PDT) Received: from BN8PR06MB6289.namprd06.prod.outlook.com ([52.96.29.13]) by smtp.gmail.com with ESMTPSA id f192sm1046669itc.42.2019.03.15.07.00.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Mar 2019 07:00:23 -0700 (PDT) From: Tarek Saad To: "mpls@ietf.org" CC: "mpls-chairs@ietf.org" Thread-Topic: MPLS agenda requests for IETF 104 in Prague Thread-Index: AWdYbU4tbcf2thkGAG03nRfJ3rcaPNsFlD9W X-MS-Exchange-MessageSentRepresentingType: 1 Date: Fri, 15 Mar 2019 14:00:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_BN8PR06MB62895E2C0768ADC77E4D849BFC440BN8PR06MB6289namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] MPLS agenda requests for IETF 104 in Prague X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 14:00:28 -0000 --_000_BN8PR06MB62895E2C0768ADC77E4D849BFC440BN8PR06MB6289namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, The agenda for Prague is now up at https://datatracker.ietf.org/meeting/104/materials/agenda-104-mpls If you're presenting, please send your slides copying me and the Chairs by = Friday, March 22nd (next week) so it can be uploaded. If you have a WG draf= t not being presented, please send an email update of current state/open is= sues/nesxt steps to the WG so it can be included in the WG progress update = slides. P.S. note my old email (tsaad@cisco.com) as MPLS se= cretary is no longer active and you can reach me on this email moving forwa= rd. Regards, Tarek From: Tarek Saad Date: Saturday, March 2, 2019 at 3:37 PM To: "mpls@ietf.org" Cc: "mpls-chairs@ietf.org" Subject: MPLS agenda requests for IETF 104 in Prague Hi all, We are building the MPLS WG session=92s agenda for IETF104 in Prague. The p= reliminary agenda is available at: https://datatracker.ietf.org/meeting/104/agenda.html The MPLS WG session is scheduled for the session below: Wednesday, March 27, 2019 (CET) 11:20-13:20 - Wednesday Morning session II Please send slot requests for presenting at the MPLS session copying myself= and the WG chairs - indicate draft name, speaker and desired duration. If presenting, your slides will be due by Friday March 22. Please send slid= es to myself and the WG chairs. A reminder to authors/editors of WG drafts that will not be discussed/prese= nted at IET104 to send a status report to the WG list by Friday March 22 so= it can be included in the MPLS WG progress report. Important dates: 2019-03-01 (Friday): Final agenda to be published. 2019-03-11 (Monday): Internet Draft submission cut-off (for all drafts, inc= luding -00) by UTC 23:59. Upload using the ID Submission Tool. 2019-03-11 (Monday): Standard rate registration and payment cut-off at UTC = 23:59.. 2019-03-13 (Wednesday): Draft Working Group agendas due by UTC 23:59. Uploa= d using the Meeting Materials Management Tool. 2019-03-18 (Monday): Registration cancellation cut-off at UTC 23:59. 2019-03-18 (Monday): Revised Working Group agendas due by UTC 23:59. Upload= using the Meeting Materials Management Tool. 2019-04-19 (Friday): Proceedings submission cutoff date by UTC 23:59. Uploa= d using the Meeting Materials Management Tool. 2019-05-13 (Monday): Proceedings submission corrections cutoff date by UTC = 23:59. Regards, Tarek and MPLS WG chairs --_000_BN8PR06MB62895E2C0768ADC77E4D849BFC440BN8PR06MB6289namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi all,

 

The agenda for Prague is now up at

https://datatracker.ietf.org/meeting/104/materia= ls/agenda-104-mpls

 

If you're presenting, please send your slides copyin= g me and the Chairs by Friday, March 22nd (next week) so it can be uploaded= . If you have a WG draft not being presented, please send an email update o= f current state/open issues/nesxt steps to the WG so it can be included in the WG progress update slides.

 

P.S. note my old email (tsaad@cisco.com) as MPLS secretary is no longer active and you c= an reach me on this email moving forward.

 

Regards,

Tarek

 

From= : Tarek Saad <ts= aad.net@gmail.com>
Date: Saturday, March 2, 2019 at 3:37 PM
To: "mpls@ietf.org" <mpls@ietf.org>
Cc: "mpls-chairs@ietf.org" <mpls-chairs@ietf.org> Subject: MPLS agenda requests for IETF 104 in Prague

 

Hi all,

We are building the MPLS WG session=92s agenda for IETF104 in Prague. The p= reliminary agenda is available at:
https://da= tatracker.ietf.org/meeting/104/agenda.html


The MPLS WG session is scheduled for the session below:

Wednesday, March 27, 2019 (CET) 11:20-13:20 - W= ednesday Morning session II


Please send slot requests for presenting at the MPLS session copying myself= and the WG chairs - indicate draft name, speaker and desired duration.
If presenting, your slides will be due by Friday March 22. Please send slid= es to myself and the WG chairs.

A reminder to authors/editors of WG drafts that will not be discussed/prese= nted at IET104 to send a status report to the WG list by Friday March 22 so= it can be included in the MPLS WG progress report.

Important dates:

2019-03-01 (Friday): Final agenda to be published.

2019-03-11 (Monday): Internet Draft submission cut-o= ff (for all drafts, including -00) by UTC 23:59. Upload using the ID Submis= sion Tool.

2019-03-11 (Monday): Standard rate registration and = payment cut-off at UTC 23:59..

2019-03-13 (Wednesday): Draft Working Group agendas = due by UTC 23:59. Upload using the Meeting Materials Management Tool.<= /o:p>

2019-03-18 (Monday): Registration cancellation cut-o= ff at UTC 23:59.

2019-03-18 (Monday): Revised Working Group agendas d= ue by UTC 23:59. Upload using the Meeting Materials Management Tool.

2019-04-19 (Friday): Proceedings submission cutoff d= ate by UTC 23:59. Upload using the Meeting Materials Management Tool.<= /o:p>

2019-05-13 (Monday): Proceedings submission correcti= ons cutoff date by UTC 23:59.

 

Regards,
Tarek and MPLS WG chairs

--_000_BN8PR06MB62895E2C0768ADC77E4D849BFC440BN8PR06MB6289namp_-- From nobody Fri Mar 15 08:06:25 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E61130DDA; Fri, 15 Mar 2019 08:06:16 -0700 (PDT) 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_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 s2QgrjWUb8vW; Fri, 15 Mar 2019 08:06:12 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 18F72128678; Fri, 15 Mar 2019 08:06:11 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id w5so2115028qtb.11; Fri, 15 Mar 2019 08:06:11 -0700 (PDT) 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=6z8SV3pD/Klc7DNsuewVyMgkTeb3beaWmi0mRfbbYVo=; b=LidFDdqf062l2ChF77c2l3WS7CT/yqRvrbLt7XARvhcbuaKZo+x1wjI3jgygPYm6D6 CgaJoCakl4Bgm+ghGaI06ccIK4MWbHgaoL+hHkXEvmG2+rS/UiBenj225GHdfKpjNQRq CtyQ4x6ZGrcR3efxSQIoH6oTA/VXIqMRsFeVzdFAnz/piQF+sOQhbPVPDGGx/KhMMU4U w7nrDiWoxTl0kr8BckRxBwnIhgYdOAtubNhknk9f2LdmbYaks6Yd42oU4PSAtOYyiuDz kphXiJrZeBRmZtxXb+B21btRuIxE0Ha3tX5ZVDP3FXgV8GliC1i4HBF/03TCiNz6rg4+ AKlA== 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=6z8SV3pD/Klc7DNsuewVyMgkTeb3beaWmi0mRfbbYVo=; b=uSTnI0wFhHZHaOEMdH3M8vN3EHGsV0GJtsIHwB6onuxkAAHUpz5LFAMofty5PUQsuv UZVOT/YLwQblAbD8C12MduBBlwJXwxeKgqjLX6PQpg7m2QTPSSVs5pcXUMi2Hm5KUbL7 3JYe+CgM/kQUluu7MtXOuFagUdnhSt7Ws9Vk64T8T7eCLAERye0GtWOBklD6HLV4AmUs dZ/4ujrSCuWzcmcqC1JgazrU5HyX9inQwq3YGH2w6pGt6xhIbJ3RC7HUPBcBYOE9e9+b NlJ7oieMfQ5Zm28LAJ6Tcr6wM4uF+CC5QuL/yVWBDQs/l6hVsSBGPqx8ZxttL6lZFMyT W/sg== X-Gm-Message-State: APjAAAWULrqNEh1iLJux5xJef4eUJz5mLp3Njjj2kJ3Q9IYi/Q6Yo2nO inQIuEU+rrRiIQH38q5FgmEBzLWfLNegAQcZArk= X-Google-Smtp-Source: APXvYqyPJ5DDV8PFmbT6SDyWo/CJLCVLeA5KVecDIGmx+Vg3OItH6t982BEvJ2GL+PYr9K7QTaXp/yH6mGEkE+hNBmM= X-Received: by 2002:aed:3101:: with SMTP id 1mr3088830qtg.81.1552662370709; Fri, 15 Mar 2019 08:06:10 -0700 (PDT) MIME-Version: 1.0 References: <155252958505.24865.4180223375091950120.idtracker@ietfa.amsl.com> In-Reply-To: <155252958505.24865.4180223375091950120.idtracker@ietfa.amsl.com> From: "Andrew G. Malis" Date: Fri, 15 Mar 2019 11:05:59 -0400 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-mpls-sfc-encapsulation@ietf.org, Loa Andersson , mpls-chairs , mpls Content-Type: multipart/alternative; boundary="0000000000000ff570058423616f" Archived-At: Subject: Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-sfc-encapsulation-03: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 15:06:17 -0000 --0000000000000ff570058423616f Content-Type: text/plain; charset="UTF-8" Benjamin, Thanks for your review and comments. See below inline. On Wed, Mar 13, 2019 at 10:13 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for this clear and concise document! I just have one concern, > which will hopefully be easy to resolve (since there is a good chance > that all the text necessary to do so is already written). > > As far as I can tell, the comment made by the secdir reviewer of > draft-ietf-mpls-sfc-04 about circular references between that document > and RFCs 7665 and 8300 regarding security properties, is also somewhat > applicable to this document. I do recognize the validity of first > paragraph of the security considerations here (the NSH is an opaque > payload for MPLS), but that in and of itself does not present a security > analysis of the NSH in the MPLS environment. The last paragraph of the > security considerations of this document attempts to provide some > analysis, but it seems to be incomplete and perhaps overly optimistic, > particularly with respect to the use of MPLS with Inter-Carrier > Interconnect and the processing of MPLS traffic from external > interfaces. Is there any reason not to fully harmonize (i.e., > synchronize) the security considerations of draft-ietf-mpls-sfc and > draft-ietf-mpls-sfc-encapsulation? (I guess the first paragraph of this > document's security considerations doesn't apply to the other document, > that allocates extended-special-purpose label values, but that's the > only thing I saw.) > Trying to keep this document in sync with draft-ietf-mpls-sfc was difficult because it was a moving target while this draft was being developed, and of course, it was updated during IETF last call and IESG review following the completion of this draft. And as you noted, there are some fundamental differences between the two drafts. Because the other draft makes some additions and changes to the MPLS label stack while this draft uses the MPLS label stack as designed and in wide practice, there's text in the other draft that doesn't apply to this one, such as regarding the use of MPLS to encode a logical representation of the NSH. If you have any specific suggestions for improvement for the text here, that would be greatly appreciated! Also, does the IESG have any policy regarding direct copying of applicable text from one draft to another in situations like this? Or perhaps we could just add a reference to particular paragraphs in section 15 of draft-ietf-mpls-sfc? That would remove the need to copy any text. I'll await your reply before taking any action. ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 1 > > This encapsulation is equivalent from an SFC perspective to other > transport encapsulations of packets using the NSH. This can be > illustrated by adding an additional line to the example of a next-hop > SPI/SI-to-network overlay network locator mapping in Table 1 of > [RFC8300]: > > We probably should expand SPI and SI, since we haven't yet hit a > terminiology section or a note that (implies that) readers should be > familiar with the standard SFC terminology. > Also, Table 1 of RFC 8300 is labeled "SFF NSH Mapping Example"; it's not > really clear that specifically that table is the best way to illustrate > how the MPLS encapsulation would work. > That table 1 extension was added to the draft as a result of the Routing Directorate review. Other than expanding the acronyms, I'll leave making any changes here up to Deborah. > (side note) We use the strings "VPN" and "virtual private" here, which > in some contexts will cause an (uninformed) reader to assume that data > privacy (confidentiality) is involved; our uses do not seem to be for > cases that would involve such a confidentiality property. As a general > matter, not necessarily involving changes to this document, it may be > good to try to reserve these terms for cases where the confidentiality > is in fact provided, to help disambiguate the cases for the reader. > I take your point, but these are just examples of other uses of MPLS service labels. > Section 2.1 > > nit: s/The TTL For/The TTL for/ (twice) > Will fix. > > Section 3 > > For SFC, ECMP may or may not be desirable. To prevent ECMP when it > is not desired, the NSH Base Header was carefully constructed so that > the NSH could not look like IPv4 or IPv6 based on its first nibble. > See Section 2.2 of [RFC8300] for further details. > > nit: this paragraph might flow better into the next one if we add a note > that "Accordingly, the default behavior for MPLS-encapsulated SFC will > not use ECMP." > Good suggestion, will add. > > Section 6 > > However, it can be argued that carrying the NSH over MPLS is more > > re: "it can be argued" -- is this document attempting to make that > argument? > It could be argued that is the case! :-) > secure than using other encapsulations, as it is extremely difficult, > due to the MPLS architecture, for an attempted attacker to inject > > It's not entirely clear to me how much of this is the MPLS architecture > vs. implementation/deployment; I suppose to some extent it is true of > both. > IMHO, it really is a result of the architecture, and as a result, any implementation that properly follows the architecture. MPLS packets must be created by a PE router, and downstream P routers will drop any incoming MPLS packets from upstream P or PE routers that don't have a top-most label that's in the router's LIB. So successfully injecting MPLS attack packets really does require insider access, and if you have that, there are so many other bad things you can do that are less expensive or difficult than trying to use an MPLS-based attack. > > unexpected MPLS packets into a network, as MPLS networks do not by > design accept MPLS packets from external interfaces, and an attacker > > What about Inter-Carrier Interconnect? > MPLS ICI is really off-topic for this draft because the NSH is only used in limited SFC domains that not only within a single domain (see RFC 8300), but within a well-defined sub-domain of that provider, such as within a data center. That said, just to answer your question, carriers for the most part don't do MPLS across carrier boundaries, there's too much trust that would be required. That said, there are some examples of inter-carrier MPLS, most commonly using RFC 4364 option A, which really isn't an MPLS interface. There is an MPLS Forum document, https://www.broadband-forum.org/technical/download/ipmpls/IPMPLSForum19.0.0.pdf , which discusses the various ways one can implement an MPLS ICI and the security implications of doing so, in section 13. > > would need knowledge of the specific labels allocated by control and/ > or management plane protocols. Thus, an attacker attempting to spoof > MPLS-encapsulated NSH packets would require insider knowledge of the > > An attacker in a position to inject traffic seems likely to also be able > to observe legitimate traffic and correspondingly their valid label > values (if not necessarily the mapping from label to behavior). > Absolutely, As I said above, if you've got that much insider access, there are much easier ways to screw up a network than play with MPLS packets. > > network's control and management planes and a way to inject packets > into internal interfaces. This is compared to, for example, NSH over > UDP over IP, which could be injected into any external interface in a > network that was not properly configured to filter out such packets > at the ingress. > > The NSH security considerations already (essentially) require this > filtering at ingress behavior; the practical question relevant here > seems to just be a matter of scale -- how hard it is to misconfigure > this filtering or how likely it is that the relevant filtering is > present as a consequence of factors external to SFC. > I think that's a question more for RFC 8300 than this draft. In terms of how hard it is to misconfigure filtering, that's really an implementation and deployment question. Thanks again for your review. Cheers, Andy --0000000000000ff570058423616f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Benjami= n,

Thanks for your review and comments. See below inline= .

On Wed, Mar 13, 2019 at 10:13 PM Benjamin Kaduk via Datatracker = <noreply@ietf.org<= /a>> wrote:
<= br>----------------------------------------------------------------------DISCUSS:
-------------------------------------------------------------= ---------

Thanks for this clear and concise document!=C2=A0 I just have one conce= rn,
which will hopefully be easy to resolve (since there is a good chanc= e
that all the text necessary to do so is already written).

As far as I can tell, the comment made by the secdir reviewer of
dra= ft-ietf-mpls-sfc-04 about circular references between that document
and = RFCs 7665 and 8300 regarding security properties, is also somewhat
appli= cable to this document.=C2=A0 I do recognize the validity of first
parag= raph of the security considerations here (the NSH is an opaque
payload f= or MPLS), but that in and of itself does not present a security
analysis= of the NSH in the MPLS environment.=C2=A0 The last paragraph of the
sec= urity considerations of this document attempts to provide some
analysis,= but it seems to be incomplete and perhaps overly optimistic,
particular= ly with respect to the use of MPLS with Inter-Carrier
Interconnect and t= he processing of MPLS traffic from external
interfaces.=C2=A0 Is there a= ny reason not to fully harmonize (i.e.,
synchronize) the security consid= erations of draft-ietf-mpls-sfc and
draft-ietf-mpls-sfc-encapsulation?= =C2=A0 (I guess the first paragraph of this
document's security cons= iderations doesn't apply to the other document,
that allocates exten= ded-special-purpose label values, but that's the
only thing I saw.)<= br>


If you have any specific suggestions for improvement for the text here, = that would be greatly appreciated! Also, does the IESG have any policy rega= rding direct copying of applicable text from one draft to another in situat= ions like this? Or perhaps we could just add a reference to particular para= graphs in section 15 of=C2=A0draft-= ietf-mpls-sfc? That would remove the need to copy any= text.

=
I'll await your repl= y before taking any action.
=C2=A0

---------------------= -------------------------------------------------
COMMENT:
----------= ------------------------------------------------------------

Section 1

=C2=A0 =C2=A0This encapsulation is equivalent from an SFC perspective t= o other
=C2=A0 =C2=A0transport encapsulations of packets using the NSH.= =C2=A0 This can be
=C2=A0 =C2=A0illustrated by adding an additional line= to the example of a next-hop
=C2=A0 =C2=A0SPI/SI-to-network overlay net= work locator mapping in Table 1 of
=C2=A0 =C2=A0[RFC8300]:

We probably should expand SPI and SI, since we haven't yet hit aterminiology section or a note that (implies that) readers should be
fa= miliar with the standard SFC terminology.
Also, Table 1 of RFC 8300 is l= abeled "SFF NSH Mapping Example"; it's not
really clear th= at specifically that table is the best way to illustrate
how the MPLS en= capsulation would work.

=C2=A0That tabl= e 1 extension was added to the draft as a result of the Routing Directorate= review. Other than expanding the acronyms, I'll leave making any chang= es here up to Deborah.


(side note) We use the strings "VPN" and "virtual privat= e" here, which
in some contexts will cause an (uninformed) reader t= o assume that data
privacy (confidentiality) is involved; our uses do no= t seem to be for
cases that would involve such a confidentiality propert= y.=C2=A0 As a general
matter, not necessarily involving changes to this = document, it may be
good to try to reserve these terms for cases where t= he confidentiality
is in fact provided, to help disambiguate the cases f= or the reader.=C2=A0

I take your point,= but these are just examples of other uses of MPLS service labels.
=C2=A0
Section 2.1=

nit: s/The TTL For/The TTL for/ (twice)

=
Will fix.
=C2=A0

Section 3

=C2=A0 =C2=A0For SFC, ECMP may or may not be desirable.=C2=A0 To preven= t ECMP when it
=C2=A0 =C2=A0is not desired, the NSH Base Header was care= fully constructed so that
=C2=A0 =C2=A0the NSH could not look like IPv4 = or IPv6 based on its first nibble.
=C2=A0 =C2=A0See Section 2.2 of [RFC8= 300] for further details.

nit: this paragraph might flow better into the next one if we add a not= e
that "Accordingly, the default behavior for MPLS-encapsulated SFC= will
not use ECMP."

Good sugge= stion, will add.
=C2=A0

Section 6

=C2=A0 =C2=A0However, it can be argued that carrying the NSH over MPLS = is more

re: "it can be argued" -- is this document attempting to make= that argument?

It could be argued that= is the case! :-)=C2=A0
=C2=A0
=C2=A0 =C2=A0secure than using other encapsulations, a= s it is extremely difficult,
=C2=A0 =C2=A0due to the MPLS architecture, = for an attempted attacker to inject

It's not entirely clear to me how much of this is the MPLS architec= ture
vs. implementation/deployment; I suppose to some extent it is true = of
both.

IMHO, it really is a result= of the architecture, and as a result, any implementation that properly fol= lows the architecture. MPLS packets must be created by a PE router, and dow= nstream P routers will drop any incoming MPLS packets from upstream P or PE= routers that don't have a top-most label that's in the router'= s LIB. So successfully injecting MPLS attack packets really does require in= sider access, and if you have that, there are so many other bad things you = can do that are less expensive or difficult than trying to use an MPLS-base= d attack.
=C2=A0

=C2=A0 =C2=A0unexpected MPLS packets into a network, as MPLS networks d= o not by
=C2=A0 =C2=A0design accept MPLS packets from external interface= s, and an attacker

What about Inter-Carrier Interconnect?

<= div>MPLS ICI is really off-topic for this draft because the NSH is only use= d in limited SFC domains that not only within a single domain (see RFC 8300= ), but within a well-defined sub-domain of that provider, such as within a = data center.=C2=A0

=C2=A0

=C2=A0 =C2=A0would need knowledge of the specific labels allocated by c= ontrol and/
=C2=A0 =C2=A0or management plane protocols.=C2=A0 Thus, an a= ttacker attempting to spoof
=C2=A0 =C2=A0MPLS-encapsulated NSH packets w= ould require insider knowledge of the

An attacker in a position to inject traffic seems likely to also be abl= e
to observe legitimate traffic and correspondingly their valid labelvalues (if not necessarily the mapping from label to behavior).

Absolutely, As I said above, if you've got th= at much insider access, there are much easier ways to screw up a network th= an play with MPLS packets.
=C2=A0

=C2=A0 =C2=A0network's control and management planes and a way to i= nject packets
=C2=A0 =C2=A0into internal interfaces.=C2=A0 This is compa= red to, for example, NSH over
=C2=A0 =C2=A0UDP over IP, which could be i= njected into any external interface in a
=C2=A0 =C2=A0network that was n= ot properly configured to filter out such packets
=C2=A0 =C2=A0at the in= gress.

The NSH security considerations already (essentially) require this
f= iltering at ingress behavior; the practical question relevant here
seems= to just be a matter of scale -- how hard it is to misconfigure
this fil= tering or how likely it is that the relevant filtering is
present as a c= onsequence of factors external to SFC.

= I think that's a question more for RFC 8300 than this draft. In terms o= f how hard it is to misconfigure filtering, that's really an implementa= tion and deployment question.

Thanks again for you= r review.

Cheers,
Andy
=C2=A0<= /div>
--0000000000000ff570058423616f-- From nobody Fri Mar 15 08:21:28 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA24128678; Fri, 15 Mar 2019 08:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_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 ecWBB4sG99ud; Fri, 15 Mar 2019 08:21:24 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 9DAAF130E2B; Fri, 15 Mar 2019 08:21:21 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id c189so5719392qke.6; Fri, 15 Mar 2019 08:21:21 -0700 (PDT) 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=JyOlwjW8oB/BCN12upQy6IYG2EYJOLFCb2+I0XvlGCA=; b=u/KENb2HC4IXo3oaZD4iQJNM27jvdCb8jwPWrNf8//dQGgqzr6vVNpc0KXWWhwmA0x 4rd/6WPpm/g7taQmcYDXMCDViRLZaauhf1wsP4XQaqIDs2fi7IIT1lut91VInSK1NRbz T7GX3KbfQESlnk3gsiyAmTqsX1mDPJKmBto0YYE7Ai6sjXaLKG/ROzDbXLNUEmTL6xmX q4P4h+55ERfTC8kgIGUkw0lkEnneRuV47U5i/k7mXzlUXauF9UZekIAIkzNyrRYcU/6j jPbo8M310xYgk9fqZ7nW9bTexdoU5rKiVYBtE3DXBZbC2oygmYrN/IwYrD1bTHB0G1L+ 92Cg== 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=JyOlwjW8oB/BCN12upQy6IYG2EYJOLFCb2+I0XvlGCA=; b=BgDMs/3b+ue/xpoZzbF1757BoX+WLr3nLiJ4O+cQbCwxeCvD+5WvheYr/wl3DPYEm6 ksrIyr4/HaqwQOM7xVN+OGiLzqwz4CUpRxkj4MEAIPYsaOBVnQub9TJKXR4AsV9j1fZN 5l+3SE++qBGa3bou38dAYfwE2Q8crhw9qxKm712k8MYk9SABWoS+Ri1Kud3Z63oeiiNU QhD124lebZWiI66oOZR4oA/3Wh+xtiEQlSSD1pm/imfL79FMsnUUHY+MYUxtJZoygLoo 2w53HmJ7mQBmPkMFKeX1sy8tZusaqdi6WKpjpcTROv5aIMZL5gtAgU5eeeLGhQkUzk03 v7gw== X-Gm-Message-State: APjAAAWbUyXBLEty/KrFQJ3i0iWc3W5WTAEqIdrQRHocde4Qvz0vJ2ZB 12uW0m+GKYOJdxmA8Npi4wxCmQ6acWG4uBNlag0= X-Google-Smtp-Source: APXvYqxf6flUBfcblGUTnYJoKup+fLD3mnnaAh+2zVfX4sSK0ByKW5oZwcHEnprxlYhclwpu4toJzNJDP9W7PS4ze4U= X-Received: by 2002:a37:4887:: with SMTP id v129mr3382056qka.100.1552663280693; Fri, 15 Mar 2019 08:21:20 -0700 (PDT) MIME-Version: 1.0 References: <155255907978.2609.2747211710494136361.idtracker@ietfa.amsl.com> In-Reply-To: <155255907978.2609.2747211710494136361.idtracker@ietfa.amsl.com> From: "Andrew G. Malis" Date: Fri, 15 Mar 2019 11:21:09 -0400 Message-ID: To: Martin Vigoureux Cc: The IESG , draft-ietf-mpls-sfc-encapsulation@ietf.org, Loa Andersson , mpls-chairs , mpls Content-Type: multipart/alternative; boundary="0000000000004d35c5058423971c" Archived-At: Subject: Re: [mpls] Martin Vigoureux's No Objection on draft-ietf-mpls-sfc-encapsulation-03: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 15:21:26 -0000 --0000000000004d35c5058423971c Content-Type: text/plain; charset="UTF-8" Martin, Thanks for your comments. On Thu, Mar 14, 2019 at 6:24 AM Martin Vigoureux via Datatracker < noreply@ietf.org> wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Without having looked before I was thinking this was Standard Track, I'm > surprised it is not. > Mirja had a similar comment. When we started work on the draft, it didn't have any normative language. However, that was added as a result of reviews, so we'll discuss this with Deborah and the WG chairs. > > You say: > 1. Push zero or more labels that are interpreted by the destination > MPLS node on to the packet, > and then say: > The receiving MPLS node then pops the SFF Label (and any labels > beneath it) > So it looks like that any label which might have been pushed before the SFF > label is/are simply ignored at the other end. I'm not asking for the > behaviour > to be specified and I understand that strictly speaking the text is not > forbidding something to happen based on these labels but still it might be > useful to explicitly say that these labels may be processed. > > That's already covered in the text: 3. Push zero or more additional labels such that (a) the resulting label stack will cause the packet to be transported to the destination MPLS node, and (b) when the packet arrives at the destination node, either: * the SFF Label will be at the top of the label stack (this is typically the case when penultimate hop popping is used at the penultimate node, or the source and destination nodes are direct neighbors), or * as a part of normal MPLS processing, the SFF Label becomes the top label in the stack before the packet is forwarded to another node and before the packet is dispatched to a higher layer. Unless I misunderstood your point. Please let me know if I did. Thanks again, Andy --0000000000004d35c5058423971c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Martin,

Thanks for you= r comments.

On Thu, Mar 14, 2019 at 6:24 AM Martin Vigoureux via Datat= racker <noreply@ie= tf.org> wrote:
---------------------------------------------------------------------= -
COMMENT:
----------------------------------------------------------= ------------

Without having looked before I was thinking this was Standard Track, I&= #39;m
surprised it is not.

Mirja had= a similar comment. When we started work on the draft, it didn't have a= ny normative language. However, that was added as a result of reviews, so w= e'll discuss this with Deborah and the WG chairs.
=C2=A0

You say:
=C2=A0 =C2=A01.=C2=A0 Push zero or more labels that are int= erpreted by the destination
=C2=A0 =C2=A0 =C2=A0 =C2=A0MPLS node on to t= he packet,
and then say:
=C2=A0 =C2=A0The receiving MPLS node then po= ps the SFF Label (and any labels
=C2=A0 =C2=A0beneath it)
So it looks= like that any label which might have been pushed before the SFF
label i= s/are simply ignored at the other end. I'm not asking for the behaviour=
to be specified and I understand that strictly speaking the text is not=
forbidding something to happen based on these labels but still it might= be
useful to explicitly say that these labels may be processed.

=

That's already covered in the text:

=
   3.  Push zero or more additional labels such that (a) the resulting
       label stack will cause the packet to be transported to the
       destination MPLS node, and (b) when the packet arrives at the
       destination node, either:

       *  the SFF Label will be at the top of the label stack (this is
          typically the case when penultimate hop popping is used at the
          penultimate node, or the source and destination nodes are
          direct neighbors), or


       *  as a part of normal =
MPLS processing, the SFF Label becomes the
          top label in the stack before the packet is forwarded to
          another node and before the packet is dispatched to a higher
          layer.

Unless I misunderstood your point. Please l= et me know if I did.

Thanks again,
Andy<= /div>
=C2=A0
--0000000000004d35c5058423971c-- From nobody Fri Mar 15 12:26:01 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCF0130DC9; Fri, 15 Mar 2019 12:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 2rz-3RonPM2R; Fri, 15 Mar 2019 12:25:54 -0700 (PDT) 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 0DA59130E86; Fri, 15 Mar 2019 12:25:50 -0700 (PDT) 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 x2FJPlHc024771; Fri, 15 Mar 2019 19:25:47 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6F96422044; Fri, 15 Mar 2019 19:25:47 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id 5527E22042; Fri, 15 Mar 2019 19:25:47 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id x2FJPk3o023695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 15 Mar 2019 19:25:46 GMT Reply-To: From: "Adrian Farrel" To: "'Andrew G. Malis'" , "'Benjamin Kaduk'" Cc: "'mpls-chairs'" , "'mpls'" , "'The IESG'" , References: <155252958505.24865.4180223375091950120.idtracker@ietfa.amsl.com> In-Reply-To: Date: Fri, 15 Mar 2019 19:25:44 -0000 Organization: Old Dog Consulting Message-ID: <059f01d4db64$e35136b0$a9f3a410$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05A0_01D4DB64.E3529640" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFwba7+EEBs3BcTXWcP2PbBAFPPQAFQgTLnpstpyzA= Content-Language: en-gb X-Originating-IP: 87.112.237.8 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-24492.002 X-TM-AS-Result: No--19.805-10.0-31-10 X-imss-scan-details: No--19.805-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24492.002 X-TMASE-Result: 10--19.805200-10.000000 X-TMASE-MatchedRID: yebcs53SkkDxIbpQ8BhdbCcP0e8lTEHzjLOy13Cgb4+ch4QlTwy6NRwA lHA73Fsg+Z8NQ0AmE0JgfRCaa0UeZWnPUXHDkPCRlVHM/F6YkvQS12tj9Zvd86W8iLE/8mvBilv Ab18i4hPnnltvi56PGBbjGhKsO2vnO9ndheAzkmRIRA38P/dwbmMF33UcwzdOP9e0x7rZ9oMzLM GWJa7zPwY5mIQL1oJyga0KtKweaSuWo3li0XnoAmZUc2jtcaSdmX+W7bzPOQEJF2U8dKhm+fOCO 0qhgEH3h4g24bvcHxJfODb4rhLBLZ0JkWHL+fxZlUgQqGVMqmwjo8c0NkYYIpsRtqA/Bg8z+oAN 6qKcRV+qd5roS6jjBE+Knlt+8Wv1tkm+9FsBiT8vzGdRPz7acS9eSYpU2Ct+ftq1M+x2V243awx +/2aEWtDIDCZBDTEek+K+ry6ntV6tGUuyWCB/KvO4FPWGZksPMVx/3ZYby7+zeXPuQa2kVHWHwI IGqa7xHQvc36ubF4ZT2j9KDY4iRS0M1J9+iCGWbD4iYfbCo2OPmFSaq6xM+OOxOq7LQlGL71ILi +vgwFHblS6MdnvfFHdGxXLmr3ajhKvT/B+wRC9m85QoNuKKvk151phHTNYR/uymSAhGxLLkKLnO ukKIG2fTH7UXFuPHSGr+5jqxcqOWHmpvkeKJB01Wvi92YKnO0wHvRbIG2MfxxaAXDrCns4Tfvl9 bn9nCWWTA0pz65RbJ7dIgVQ5VHxWcuhOAquMmWZbr7hxHnYTfC1U9Hn8O8rvsTEW9zEoTHWnBMn KUPfhgNsJ/Rsl8tqfq93UdCdXtTwz35qPn7ceeAiCmPx4NwGmRqNBHmBveGtkvK5L7RXGw7M6dy uYKgy1XUZZVE1iFqsFsAaXyon3WO8Vgz+Wfj3uuKBoYJhUbAagV85Co5wc= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-sfc-encapsulation-03: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 19:25:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05A0_01D4DB64.E3529640 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Andy, =20 Go ahead and copy text from draft-ietf-mpls-sfc, if you want to. I wrote = it and I donate each and every word to you for no fee. You can even use = them in the same order if it suits you. =20 Acknowledgements are also nice. =20 Adrian =20 From: mpls On Behalf Of Andrew G. Malis Sent: 15 March 2019 15:06 To: Benjamin Kaduk Cc: mpls-chairs ; mpls ; The IESG = ; draft-ietf-mpls-sfc-encapsulation@ietf.org Subject: Re: [mpls] Benjamin Kaduk's Discuss on = draft-ietf-mpls-sfc-encapsulation-03: (with DISCUSS and COMMENT) =20 Benjamin, =20 Thanks for your review and comments. See below inline.. =20 On Wed, Mar 13, 2019 at 10:13 PM Benjamin Kaduk via Datatracker = > wrote: ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for this clear and concise document! I just have one concern, which will hopefully be easy to resolve (since there is a good chance that all the text necessary to do so is already written). As far as I can tell, the comment made by the secdir reviewer of draft-ietf-mpls-sfc-04 about circular references between that document and RFCs 7665 and 8300 regarding security properties, is also somewhat applicable to this document. I do recognize the validity of first paragraph of the security considerations here (the NSH is an opaque payload for MPLS), but that in and of itself does not present a security analysis of the NSH in the MPLS environment. The last paragraph of the security considerations of this document attempts to provide some analysis, but it seems to be incomplete and perhaps overly optimistic, particularly with respect to the use of MPLS with Inter-Carrier Interconnect and the processing of MPLS traffic from external interfaces. Is there any reason not to fully harmonize (i.e., synchronize) the security considerations of draft-ietf-mpls-sfc and draft-ietf-mpls-sfc-encapsulation? (I guess the first paragraph of this document's security considerations doesn't apply to the other document, that allocates extended-special-purpose label values, but that's the only thing I saw.) =20 Trying to keep this document in sync with draft-ietf-mpls-sfc was = difficult because it was a moving target while this draft was being = developed, and of course, it was updated during IETF last call and IESG = review following the completion of this draft. And as you noted, there = are some fundamental differences between the two drafts. Because the = other draft makes some additions and changes to the MPLS label stack = while this draft uses the MPLS label stack as designed and in wide = practice, there's text in the other draft that doesn't apply to this = one, such as regarding the use of MPLS to encode a logical = representation of the NSH. =20 If you have any specific suggestions for improvement for the text here, = that would be greatly appreciated! Also, does the IESG have any policy = regarding direct copying of applicable text from one draft to another in = situations like this? Or perhaps we could just add a reference to = particular paragraphs in section 15 of draft-ietf-mpls-sfc? That would = remove the need to copy any text. =20 I'll await your reply before taking any action. =20 =20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 This encapsulation is equivalent from an SFC perspective to other transport encapsulations of packets using the NSH. This can be illustrated by adding an additional line to the example of a next-hop SPI/SI-to-network overlay network locator mapping in Table 1 of [RFC8300]: We probably should expand SPI and SI, since we haven't yet hit a terminiology section or a note that (implies that) readers should be familiar with the standard SFC terminology. Also, Table 1 of RFC 8300 is labeled "SFF NSH Mapping Example"; it's not really clear that specifically that table is the best way to illustrate how the MPLS encapsulation would work. =20 That table 1 extension was added to the draft as a result of the = Routing Directorate review. Other than expanding the acronyms, I'll = leave making any changes here up to Deborah. =20 (side note) We use the strings "VPN" and "virtual private" here, which in some contexts will cause an (uninformed) reader to assume that data privacy (confidentiality) is involved; our uses do not seem to be for cases that would involve such a confidentiality property. As a general matter, not necessarily involving changes to this document, it may be good to try to reserve these terms for cases where the confidentiality is in fact provided, to help disambiguate the cases for the reader.=20 =20 I take your point, but these are just examples of other uses of MPLS = service labels. =20 Section 2.1 nit: s/The TTL For/The TTL for/ (twice) =20 Will fix. =20 Section 3 For SFC, ECMP may or may not be desirable. To prevent ECMP when it is not desired, the NSH Base Header was carefully constructed so that the NSH could not look like IPv4 or IPv6 based on its first nibble. See Section 2.2 of [RFC8300] for further details. nit: this paragraph might flow better into the next one if we add a note that "Accordingly, the default behavior for MPLS-encapsulated SFC will not use ECMP." =20 Good suggestion, will add. =20 Section 6 However, it can be argued that carrying the NSH over MPLS is more re: "it can be argued" -- is this document attempting to make that = argument? =20 It could be argued that is the case! :-)=20 =20 secure than using other encapsulations, as it is extremely difficult, due to the MPLS architecture, for an attempted attacker to inject It's not entirely clear to me how much of this is the MPLS architecture vs. implementation/deployment; I suppose to some extent it is true of both. =20 IMHO, it really is a result of the architecture, and as a result, any = implementation that properly follows the architecture. MPLS packets must = be created by a PE router, and downstream P routers will drop any = incoming MPLS packets from upstream P or PE routers that don't have a = top-most label that's in the router's LIB. So successfully injecting = MPLS attack packets really does require insider access, and if you have = that, there are so many other bad things you can do that are less = expensive or difficult than trying to use an MPLS-based attack. =20 unexpected MPLS packets into a network, as MPLS networks do not by design accept MPLS packets from external interfaces, and an attacker What about Inter-Carrier Interconnect? =20 MPLS ICI is really off-topic for this draft because the NSH is only used = in limited SFC domains that not only within a single domain (see RFC = 8300), but within a well-defined sub-domain of that provider, such as = within a data center.=20 =20 That said, just to answer your question, carriers for the most part = don't do MPLS across carrier boundaries, there's too much trust that = would be required. That said, there are some examples of inter-carrier = MPLS, most commonly using RFC 4364 option A, which really isn't an MPLS = interface. There is an MPLS Forum document, = https://www.broadband-forum.org/technical/download/ipmpls/IPMPLSForum19.0= .0.pdf , which discusses the various ways one can implement an MPLS ICI = and the security implications of doing so, in section 13. =20 would need knowledge of the specific labels allocated by control and/ or management plane protocols. Thus, an attacker attempting to spoof MPLS-encapsulated NSH packets would require insider knowledge of the An attacker in a position to inject traffic seems likely to also be able to observe legitimate traffic and correspondingly their valid label values (if not necessarily the mapping from label to behavior). =20 Absolutely, As I said above, if you've got that much insider access, = there are much easier ways to screw up a network than play with MPLS = packets. =20 network's control and management planes and a way to inject packets into internal interfaces. This is compared to, for example, NSH over UDP over IP, which could be injected into any external interface in a network that was not properly configured to filter out such packets at the ingress. The NSH security considerations already (essentially) require this filtering at ingress behavior; the practical question relevant here seems to just be a matter of scale -- how hard it is to misconfigure this filtering or how likely it is that the relevant filtering is present as a consequence of factors external to SFC. =20 I think that's a question more for RFC 8300 than this draft. In terms of = how hard it is to misconfigure filtering, that's really an = implementation and deployment question. =20 Thanks again for your review. =20 Cheers, Andy =20 ------=_NextPart_000_05A0_01D4DB64.E3529640 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Andy,

 

Go ahead = and copy text from draft-ietf-mpls-sfc, if you want to. I wrote it and I = donate each and every word to you for no fee. You can even use them in = the same order if it suits you.

 

Acknowledgements are also = nice.

 

Adrian

 

From: mpls <mpls-bounces@ietf.org> On Behalf Of = Andrew G. Malis
Sent: 15 March 2019 15:06
To: = Benjamin Kaduk <kaduk@mit.edu>
Cc: mpls-chairs = <mpls-chairs@ietf.org>; mpls <mpls@ietf.org>; The IESG = <iesg@ietf.org>; = draft-ietf-mpls-sfc-encapsulation@ietf.org
Subject: Re: [mpls] = Benjamin Kaduk's Discuss on draft-ietf-mpls-sfc-encapsulation-03: (with = DISCUSS and COMMENT)

 

Benjamin,

 

Thanks for your review and comments. See below = inline..

 

On = Wed, Mar 13, 2019 at 10:13 PM Benjamin Kaduk via Datatracker <noreply@ietf.org> = wrote:


---------------------------------------------------= -------------------
DISCUSS:
--------------------------------------= --------------------------------

Thanks for this clear and = concise document!  I just have one concern,
which will hopefully = be easy to resolve (since there is a good chance
that all the text = necessary to do so is already written).

As far as I can tell, the = comment made by the secdir reviewer of
draft-ietf-mpls-sfc-04 about = circular references between that document
and RFCs 7665 and 8300 = regarding security properties, is also somewhat
applicable to this = document.  I do recognize the validity of first
paragraph of the = security considerations here (the NSH is an opaque
payload for MPLS), = but that in and of itself does not present a security
analysis of the = NSH in the MPLS environment.  The last paragraph of the
security = considerations of this document attempts to provide some
analysis, = but it seems to be incomplete and perhaps overly = optimistic,
particularly with respect to the use of MPLS with = Inter-Carrier
Interconnect and the processing of MPLS traffic from = external
interfaces.  Is there any reason not to fully harmonize = (i.e.,
synchronize) the security considerations of = draft-ietf-mpls-sfc and
draft-ietf-mpls-sfc-encapsulation?  (I = guess the first paragraph of this
document's security considerations = doesn't apply to the other document,
that allocates = extended-special-purpose label values, but that's the
only thing I = saw.)

 

Trying to keep this document in sync with draft-ietf-mpls-sfc was difficult because it was a = moving target while this draft was being developed, and of course, it = was updated during IETF last call and IESG review following the = completion of this draft. And as you noted, there are some fundamental = differences between the two drafts. Because the other draft makes some = additions and changes to the MPLS label stack while this draft uses the = MPLS label stack as designed and in wide practice, there's text in the = other draft that doesn't apply to this one, such as = regarding the use of MPLS to encode a logical representation = of the NSH.

 

If you have = any specific suggestions for improvement for the text here, that would = be greatly appreciated! Also, does the IESG have any policy regarding = direct copying of applicable text from one draft to another in = situations like this? Or perhaps we could just add a reference to = particular paragraphs in section 15 of draft-ietf-mpls-sfc? That would remove the need to = copy any text.

 

I'll await = your reply before taking any action.

 

 

-------------------------------------------------------= ---------------
COMMENT:
------------------------------------------= ----------------------------

Section 1

   This = encapsulation is equivalent from an SFC perspective to other
  =  transport encapsulations of packets using the NSH.  This can = be
   illustrated by adding an additional line to the = example of a next-hop
   SPI/SI-to-network overlay network = locator mapping in Table 1 of
   [RFC8300]:

We = probably should expand SPI and SI, since we haven't yet hit = a
terminiology section or a note that (implies that) readers should = be
familiar with the standard SFC terminology.
Also, Table 1 of = RFC 8300 is labeled "SFF NSH Mapping Example"; it's = not
really clear that specifically that table is the best way to = illustrate
how the MPLS encapsulation would = work.

 

 That table 1 extension was added to the draft as = a result of the Routing Directorate review. Other than expanding the = acronyms, I'll leave making any changes here up to = Deborah.

 


(side = note) We use the strings "VPN" and "virtual private" = here, which
in some contexts will cause an (uninformed) reader to = assume that data
privacy (confidentiality) is involved; our uses do = not seem to be for
cases that would involve such a confidentiality = property.  As a general
matter, not necessarily involving = changes to this document, it may be
good to try to reserve these = terms for cases where the confidentiality
is in fact provided, to = help disambiguate the cases for the = reader. 

 

I = take your point, but these are just examples of other uses of MPLS = service labels.

 

Section = 2.1

nit: s/The TTL For/The TTL for/ = (twice)

 

Will fix.

 


Section 3

   For SFC, ECMP may or = may not be desirable.  To prevent ECMP when it
   is = not desired, the NSH Base Header was carefully constructed so = that
   the NSH could not look like IPv4 or IPv6 based on = its first nibble.
   See Section 2.2 of [RFC8300] for = further details.

nit: this paragraph might flow better into the = next one if we add a note
that "Accordingly, the default = behavior for MPLS-encapsulated SFC will
not use = ECMP."

 

Good suggestion, will add.

 


Section 6

   However, it can be = argued that carrying the NSH over MPLS is more

re: "it can = be argued" -- is this document attempting to make that = argument?

 

It could be argued that is the case! = :-) 

 

  =  secure than using other encapsulations, as it is extremely = difficult,
   due to the MPLS architecture, for an = attempted attacker to inject

It's not entirely clear to me how = much of this is the MPLS architecture
vs. implementation/deployment; = I suppose to some extent it is true = of
both.

 

IMHO, it really is a result of the architecture, and = as a result, any implementation that properly follows the architecture. = MPLS packets must be created by a PE router, and downstream P routers = will drop any incoming MPLS packets from upstream P or PE routers that = don't have a top-most label that's in the router's LIB. So successfully = injecting MPLS attack packets really does require insider access, and if = you have that, there are so many other bad things you can do that are = less expensive or difficult than trying to use an MPLS-based = attack.

 


   unexpected MPLS packets into a = network, as MPLS networks do not by
   design accept MPLS = packets from external interfaces, and an attacker

What about = Inter-Carrier Interconnect?

 

MPLS ICI is really off-topic for this draft because = the NSH is only used in limited SFC domains that not only within a = single domain (see RFC 8300), but within a well-defined sub-domain of = that provider, such as within a data = center. 

 

That said, just to answer your question, carriers for = the most part don't do MPLS across carrier boundaries, there's too much = trust that would be required. That said, there are some examples of = inter-carrier MPLS, most commonly using RFC 4364 option A, which really = isn't an MPLS interface. There is an MPLS Forum document, https://www.broadband-forum.org/technical/download/ipmp= ls/IPMPLSForum19.0.0.pdf , which discusses the various ways one can = implement an MPLS ICI and the security implications of doing so, in = section 13.

 


   would need knowledge of the specific = labels allocated by control and/
   or management plane = protocols.  Thus, an attacker attempting to spoof
  =  MPLS-encapsulated NSH packets would require insider knowledge of = the

An attacker in a position to inject traffic seems likely to = also be able
to observe legitimate traffic and correspondingly their = valid label
values (if not necessarily the mapping from label to = behavior).

 

Absolutely, As I said above, if you've got that much = insider access, there are much easier ways to screw up a network than = play with MPLS packets.

 


   network's control and management = planes and a way to inject packets
   into internal = interfaces.  This is compared to, for example, NSH over
  =  UDP over IP, which could be injected into any external interface = in a
   network that was not properly configured to filter = out such packets
   at the ingress.

The NSH security = considerations already (essentially) require this
filtering at = ingress behavior; the practical question relevant here
seems to just = be a matter of scale -- how hard it is to misconfigure
this filtering = or how likely it is that the relevant filtering is
present as a = consequence of factors external to = SFC.

 

I = think that's a question more for RFC 8300 than this draft. In terms of = how hard it is to misconfigure filtering, that's really an = implementation and deployment question.

 

Thanks again for your = review.

 

Cheers,

Andy

 

------=_NextPart_000_05A0_01D4DB64.E3529640-- From nobody Fri Mar 15 12:47:24 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8EB13126E; Fri, 15 Mar 2019 12:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_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 FlaKVnp76EQT; Fri, 15 Mar 2019 12:47:11 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 63DC7130E16; Fri, 15 Mar 2019 12:47:11 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id y36so1672145qtb.3; Fri, 15 Mar 2019 12:47:11 -0700 (PDT) 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=0ESNN6jMQczayHrYsAJ3iSmPkHFVybzZIJYXOSFc4BQ=; b=sqmPMojjMwyt2FakxEB4AOd6/F59SgPJLjyEvays0GDV51TSiWhI+NH1puYMl8zceb 0qaibyo3DWtLxyMEcC/+HJPeiCA8H/kFyaFSUTarJdzayNNf8RrwC0uWtBsUh/4oZdds +UUtA/s62avNW511hLV1k0vKuh/6vzZh9gJTbjSh/m7Cri3h0eETOMCWScR0I3FVsDI2 HjDn8uT8pBAck+cq9OSTCguaDF11Bovk4qwV/pyRy3VYSdnmZtgHSXaYGSRRvttzFre6 WMm+XAmmVwDTxnjysbfTziSGTqctgJ8Uqj7w525wljDdh55M7QyRsv7t633bShyjyMzb ngtg== 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=0ESNN6jMQczayHrYsAJ3iSmPkHFVybzZIJYXOSFc4BQ=; b=fCeoB6WyBrkPtBpIggSQ99FksNXdsGM0jbETkSnuwYPc3ZzPjAdxo5lQiU8w/8UtKa mYNAmUjaW95TZx5V1N6HFM34n1AOYlPe/39nzryDxYTFr8/7ZUt7J/gQ9cqB0PAEz2Ks KSAmU89c0DXnHXnv4h3QKSQh5gI/o31lvphqNwIbO3PRTkIga6hl2NrbuvZ1dd+ebtOc tNBoVG0qZmgI8Y4FIcZz6/Do3FuDUa9WfjACjByqjdFgZgX2xCQo9wmDHGwUlWuvrdn7 GGIMkiPA1Pj54S5ewJd5OrzUZj9qPA6gI6Y4CPGuEwZJcnz7u5UwfH2kEL7qDzykasNW q0yA== X-Gm-Message-State: APjAAAUqWh8WKC+JEADtTqHuH5Cb0Uxs1S8czx+TXyOlr1NvnJEmb62z X/Gb5xdwzmDQbMd15RZedBm257WlBc/y3R8InLE= X-Google-Smtp-Source: APXvYqwFgH2rH038uUznUKiMOYU+wqEdKazhjiMWPVzaZpcB8IrhTPhzqkkzJLi7bLk0IAHqPRXRG8K/3hD2Hww0+n8= X-Received: by 2002:ac8:d49:: with SMTP id r9mr1375433qti.192.1552679230221; Fri, 15 Mar 2019 12:47:10 -0700 (PDT) MIME-Version: 1.0 References: <155252958505.24865.4180223375091950120.idtracker@ietfa.amsl.com> <059f01d4db64$e35136b0$a9f3a410$@olddog.co.uk> In-Reply-To: <059f01d4db64$e35136b0$a9f3a410$@olddog.co.uk> From: "Andrew G. Malis" Date: Fri, 15 Mar 2019 15:46:59 -0400 Message-ID: To: Adrian Farrel Cc: Benjamin Kaduk , mpls-chairs , mpls , The IESG , draft-ietf-mpls-sfc-encapsulation@ietf.org Content-Type: multipart/alternative; boundary="000000000000f7b8c30584274d6d" Archived-At: Subject: Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-sfc-encapsulation-03: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 19:47:15 -0000 --000000000000f7b8c30584274d6d Content-Type: text/plain; charset="UTF-8" Adrian, Thank you very much for your kind offer! Of course, anything copied would be properly acknowledged. But perhaps a reference may do the trick as well and has less of a carbon footprint - fewer bits all around. :-) Cheers, Andy On Fri, Mar 15, 2019 at 3:25 PM Adrian Farrel wrote: > Andy, > > > > Go ahead and copy text from draft-ietf-mpls-sfc, if you want to. I wrote > it and I donate each and every word to you for no fee. You can even use > them in the same order if it suits you. > > > > Acknowledgements are also nice. > > > > Adrian > > > > *From:* mpls *On Behalf Of *Andrew G. Malis > *Sent:* 15 March 2019 15:06 > *To:* Benjamin Kaduk > *Cc:* mpls-chairs ; mpls ; The IESG < > iesg@ietf.org>; draft-ietf-mpls-sfc-encapsulation@ietf.org > *Subject:* Re: [mpls] Benjamin Kaduk's Discuss on > draft-ietf-mpls-sfc-encapsulation-03: (with DISCUSS and COMMENT) > > > > Benjamin, > > > > Thanks for your review and comments. See below inline.. > > > > On Wed, Mar 13, 2019 at 10:13 PM Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for this clear and concise document! I just have one concern, > which will hopefully be easy to resolve (since there is a good chance > that all the text necessary to do so is already written). > > As far as I can tell, the comment made by the secdir reviewer of > draft-ietf-mpls-sfc-04 about circular references between that document > and RFCs 7665 and 8300 regarding security properties, is also somewhat > applicable to this document. I do recognize the validity of first > paragraph of the security considerations here (the NSH is an opaque > payload for MPLS), but that in and of itself does not present a security > analysis of the NSH in the MPLS environment. The last paragraph of the > security considerations of this document attempts to provide some > analysis, but it seems to be incomplete and perhaps overly optimistic, > particularly with respect to the use of MPLS with Inter-Carrier > Interconnect and the processing of MPLS traffic from external > interfaces. Is there any reason not to fully harmonize (i.e., > synchronize) the security considerations of draft-ietf-mpls-sfc and > draft-ietf-mpls-sfc-encapsulation? (I guess the first paragraph of this > document's security considerations doesn't apply to the other document, > that allocates extended-special-purpose label values, but that's the > only thing I saw.) > > > > Trying to keep this document in sync with draft-ietf-mpls-sfc was > difficult because it was a moving target while this draft was being > developed, and of course, it was updated during IETF last call and IESG > review following the completion of this draft. And as you noted, there are > some fundamental differences between the two drafts. Because the other > draft makes some additions and changes to the MPLS label stack while this > draft uses the MPLS label stack as designed and in wide practice, there's > text in the other draft that doesn't apply to this one, such as regarding the > use of MPLS to encode a logical representation of the NSH. > > > > If you have any specific suggestions for improvement for the text here, > that would be greatly appreciated! Also, does the IESG have any policy > regarding direct copying of applicable text from one draft to another in > situations like this? Or perhaps we could just add a reference to > particular paragraphs in section 15 of draft-ietf-mpls-sfc? That would > remove the need to copy any text. > > > > I'll await your reply before taking any action. > > > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 1 > > This encapsulation is equivalent from an SFC perspective to other > transport encapsulations of packets using the NSH. This can be > illustrated by adding an additional line to the example of a next-hop > SPI/SI-to-network overlay network locator mapping in Table 1 of > [RFC8300]: > > We probably should expand SPI and SI, since we haven't yet hit a > terminiology section or a note that (implies that) readers should be > familiar with the standard SFC terminology. > Also, Table 1 of RFC 8300 is labeled "SFF NSH Mapping Example"; it's not > really clear that specifically that table is the best way to illustrate > how the MPLS encapsulation would work. > > > > That table 1 extension was added to the draft as a result of the Routing > Directorate review. Other than expanding the acronyms, I'll leave making > any changes here up to Deborah. > > > > > (side note) We use the strings "VPN" and "virtual private" here, which > in some contexts will cause an (uninformed) reader to assume that data > privacy (confidentiality) is involved; our uses do not seem to be for > cases that would involve such a confidentiality property. As a general > matter, not necessarily involving changes to this document, it may be > good to try to reserve these terms for cases where the confidentiality > is in fact provided, to help disambiguate the cases for the reader. > > > > I take your point, but these are just examples of other uses of MPLS > service labels. > > > > Section 2.1 > > nit: s/The TTL For/The TTL for/ (twice) > > > > Will fix. > > > > > Section 3 > > For SFC, ECMP may or may not be desirable. To prevent ECMP when it > is not desired, the NSH Base Header was carefully constructed so that > the NSH could not look like IPv4 or IPv6 based on its first nibble. > See Section 2.2 of [RFC8300] for further details. > > nit: this paragraph might flow better into the next one if we add a note > that "Accordingly, the default behavior for MPLS-encapsulated SFC will > not use ECMP." > > > > Good suggestion, will add. > > > > > Section 6 > > However, it can be argued that carrying the NSH over MPLS is more > > re: "it can be argued" -- is this document attempting to make that > argument? > > > > It could be argued that is the case! :-) > > > > secure than using other encapsulations, as it is extremely difficult, > due to the MPLS architecture, for an attempted attacker to inject > > It's not entirely clear to me how much of this is the MPLS architecture > vs. implementation/deployment; I suppose to some extent it is true of > both. > > > > IMHO, it really is a result of the architecture, and as a result, any > implementation that properly follows the architecture. MPLS packets must be > created by a PE router, and downstream P routers will drop any incoming > MPLS packets from upstream P or PE routers that don't have a top-most label > that's in the router's LIB. So successfully injecting MPLS attack packets > really does require insider access, and if you have that, there are so many > other bad things you can do that are less expensive or difficult than > trying to use an MPLS-based attack. > > > > > unexpected MPLS packets into a network, as MPLS networks do not by > design accept MPLS packets from external interfaces, and an attacker > > What about Inter-Carrier Interconnect? > > > > MPLS ICI is really off-topic for this draft because the NSH is only used > in limited SFC domains that not only within a single domain (see RFC 8300), > but within a well-defined sub-domain of that provider, such as within a > data center. > > > > That said, just to answer your question, carriers for the most part don't > do MPLS across carrier boundaries, there's too much trust that would be > required. That said, there are some examples of inter-carrier MPLS, most > commonly using RFC 4364 option A, which really isn't an MPLS interface. > There is an MPLS Forum document, > https://www.broadband-forum.org/technical/download/ipmpls/IPMPLSForum19.0.0.pdf > , which discusses the various ways one can implement an MPLS ICI and the > security implications of doing so, in section 13. > > > > > would need knowledge of the specific labels allocated by control and/ > or management plane protocols. Thus, an attacker attempting to spoof > MPLS-encapsulated NSH packets would require insider knowledge of the > > An attacker in a position to inject traffic seems likely to also be able > to observe legitimate traffic and correspondingly their valid label > values (if not necessarily the mapping from label to behavior). > > > > Absolutely, As I said above, if you've got that much insider access, there > are much easier ways to screw up a network than play with MPLS packets. > > > > > network's control and management planes and a way to inject packets > into internal interfaces. This is compared to, for example, NSH over > UDP over IP, which could be injected into any external interface in a > network that was not properly configured to filter out such packets > at the ingress. > > The NSH security considerations already (essentially) require this > filtering at ingress behavior; the practical question relevant here > seems to just be a matter of scale -- how hard it is to misconfigure > this filtering or how likely it is that the relevant filtering is > present as a consequence of factors external to SFC. > > > > I think that's a question more for RFC 8300 than this draft. In terms of > how hard it is to misconfigure filtering, that's really an implementation > and deployment question. > > > > Thanks again for your review. > > > > Cheers, > > Andy > > > --000000000000f7b8c30584274d6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Adrian,

Thank you very much for your ki= nd offer! Of=C2=A0course, anything copied would be properly acknowledged. B= ut perhaps a reference may do the trick as well and has less of a carbon fo= otprint - fewer bits all around. :-)

Cheers,
=
Andy


On Fri, Mar 15, 2019 at 3:25 PM Adrian Farrel= <adrian@olddog.co.uk> wro= te:

Andy,

=C2=A0

Go ahead and = copy text from draft-ietf-mpls-sfc, if you want to. I wrote it and I donate= each and every word to you for no fee. You can even use them in the same o= rder if it suits you.

= =C2=A0

Acknowledgement= s are also nice.

=C2=A0

Adrian=

=C2=A0

From: mpls <m= pls-bounces@ietf.org> On Behalf Of Andrew G. Malis
Sent= : 15 March 2019 15:06
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: mpls= -chairs <mpls-= chairs@ietf.org>; mpls <mpls@ietf.org>; The IESG <iesg@ietf.org>; draft-ietf-mpls-sfc-enc= apsulation@ietf.org
Subject: Re: [mpls] Benjamin Kaduk's = Discuss on draft-ietf-mpls-sfc-encapsulation-03: (with DISCUSS and COMMENT)=

=C2=A0

Benjamin,

=C2=A0

Thanks for your review and comments. See below inline..

=C2=A0

On Wed, Mar 13, 2019 at 10:13 PM Benjamin Kaduk via Datat= racker <noreply@ie= tf.org> wrote:


-------------------------------------------------------= ---------------
DISCUSS:
--------------------------------------------= --------------------------

Thanks for this clear and concise documen= t!=C2=A0 I just have one concern,
which will hopefully be easy to resolv= e (since there is a good chance
that all the text necessary to do so is = already written).

As far as I can tell, the comment made by the secd= ir reviewer of
draft-ietf-mpls-sfc-04 about circular references between = that document
and RFCs 7665 and 8300 regarding security properties, is a= lso somewhat
applicable to this document.=C2=A0 I do recognize the valid= ity of first
paragraph of the security considerations here (the NSH is a= n opaque
payload for MPLS), but that in and of itself does not present a= security
analysis of the NSH in the MPLS environment.=C2=A0 The last pa= ragraph of the
security considerations of this document attempts to prov= ide some
analysis, but it seems to be incomplete and perhaps overly opti= mistic,
particularly with respect to the use of MPLS with Inter-Carrier<= br>Interconnect and the processing of MPLS traffic from external
interfa= ces.=C2=A0 Is there any reason not to fully harmonize (i.e.,
synchronize= ) the security considerations of draft-ietf-mpls-sfc and
draft-ietf-mpls= -sfc-encapsulation?=C2=A0 (I guess the first paragraph of this
document&= #39;s security considerations doesn't apply to the other document,
t= hat allocates extended-special-purpose label values, but that's the
= only thing I saw.)

=C2=A0

Trying to keep = this document in sync with draft-ietf-mpls-sfc was difficult becaus= e it was a moving target while this draft was being developed, and of cours= e, it was updated during IETF last call and IESG review following the compl= etion of this draft. And as you noted, there are some fundamental differenc= es between the two drafts. Because the other draft makes some additions and= changes to the MPLS label stack while this draft uses the MPLS label stack= as designed and in wide practice, there's text in the other draft that= doesn't apply to this one, such as regarding=C2=A0the use of MP= LS to encode a logical representation of the NSH.

=C2=A0

If you have any specific suggestions for improvement for the text he= re, that would be greatly appreciated! Also, does the IESG have any policy = regarding direct copying of applicable text from one draft to another in si= tuations like this? Or perhaps we could just add a reference to particular = paragraphs in section 15 of=C2=A0draft-ietf-mpls-sfc? That w= ould remove the need to copy any text.

<= p class=3D"MsoNormal">=C2=A0

I'll await your reply before taking any action.=

=C2=A0

=C2=A0

<= p class=3D"MsoNormal">-----------------------------------------------------= -----------------
COMMENT:
------------------------------------------= ----------------------------

Section 1

=C2=A0 =C2=A0This enca= psulation is equivalent from an SFC perspective to other
=C2=A0 =C2=A0tr= ansport encapsulations of packets using the NSH.=C2=A0 This can be
=C2= =A0 =C2=A0illustrated by adding an additional line to the example of a next= -hop
=C2=A0 =C2=A0SPI/SI-to-network overlay network locator mapping in T= able 1 of
=C2=A0 =C2=A0[RFC8300]:

We probably should expand SPI a= nd SI, since we haven't yet hit a
terminiology section or a note tha= t (implies that) readers should be
familiar with the standard SFC termin= ology.
Also, Table 1 of RFC 8300 is labeled "SFF NSH Mapping Exampl= e"; it's not
really clear that specifically that table is the b= est way to illustrate
how the MPLS encapsulation would work.

=C2=A0

=C2=A0That table 1 extension was added to the= draft as a result of the Routing Directorate review. Other than expanding = the acronyms, I'll leave making any changes here up to Deborah.<= u>

=C2=A0

<= blockquote style=3D"border-top:none;border-right:none;border-bottom:none;bo= rder-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.= 8pt;margin-right:0cm">


(side note) We use the str= ings "VPN" and "virtual private" here, which
in some= contexts will cause an (uninformed) reader to assume that data
privacy = (confidentiality) is involved; our uses do not seem to be for
cases that= would involve such a confidentiality property.=C2=A0 As a general
matte= r, not necessarily involving changes to this document, it may be
good to= try to reserve these terms for cases where the confidentiality
is in fa= ct provided, to help disambiguate the cases for the reader.=C2=A0=

=C2=A0

I take your point, but these are just examp= les of other uses of MPLS service labels.

=C2=A0

Section 2.1

nit: s/The TTL For/The TTL for/ (twic= e)

=C2=A0<= u>

Will fix.

=C2=A0


Section 3

=C2=A0 =C2=A0For SFC, E= CMP may or may not be desirable.=C2=A0 To prevent ECMP when it
=C2=A0 = =C2=A0is not desired, the NSH Base Header was carefully constructed so that=
=C2=A0 =C2=A0the NSH could not look like IPv4 or IPv6 based on its firs= t nibble.
=C2=A0 =C2=A0See Section 2.2 of [RFC8300] for further details.=

nit: this paragraph might flow better into the next one if we add a= note
that "Accordingly, the default behavior for MPLS-encapsulated= SFC will
not use ECMP."

=C2=A0

G= ood suggestion, will add.

=C2=A0


Section 6

=C2=A0 =C2=A0However, it can be argued that carryin= g the NSH over MPLS is more

re: "it can be argued" -- is t= his document attempting to make that argument?

=C2=A0

It could be argued that is the case! :-)=C2=A0=

=C2=A0

=C2=A0 =C2=A0secure than using other= encapsulations, as it is extremely difficult,
=C2=A0 =C2=A0due to the M= PLS architecture, for an attempted attacker to inject

It's not e= ntirely clear to me how much of this is the MPLS architecture
vs. implem= entation/deployment; I suppose to some extent it is true of
both.=

=C2=A0

IMHO, it really is a result of the archi= tecture, and as a result, any implementation that properly follows the arch= itecture. MPLS packets must be created by a PE router, and downstream P rou= ters will drop any incoming MPLS packets from upstream P or PE routers that= don't have a top-most label that's in the router's LIB. So suc= cessfully injecting MPLS attack packets really does require insider access,= and if you have that, there are so many other bad things you can do that a= re less expensive or difficult than trying to use an MPLS-based attack.<= /u>

=C2=A0


=C2=A0 =C2=A0unexpecte= d MPLS packets into a network, as MPLS networks do not by
=C2=A0 =C2=A0d= esign accept MPLS packets from external interfaces, and an attacker

= What about Inter-Carrier Interconnect?

<= p class=3D"MsoNormal">=C2=A0

MPLS ICI is really off-topic for this draft because the NSH is only us= ed in limited SFC domains that not only within a single domain (see RFC 830= 0), but within a well-defined sub-domain of that provider, such as within a= data center.=C2=A0

<= /u>=C2=A0

That said, just to an= swer your question, carriers for the most part don't do MPLS across car= rier boundaries, there's too much trust that would be required. That sa= id, there are some examples of inter-carrier MPLS, most commonly using RFC = 4364 option A, which really isn't an MPLS interface. There is an MPLS F= orum document,=C2=A0https://www.broadban= d-forum.org/technical/download/ipmpls/IPMPLSForum19.0.0.pdf , which dis= cusses the various ways one can implement an MPLS ICI and the security impl= ications of doing so, in section 13.

=C2=A0


=C2=A0 =C2=A0would need knowledge of the specific label= s allocated by control and/
=C2=A0 =C2=A0or management plane protocols.= =C2=A0 Thus, an attacker attempting to spoof
=C2=A0 =C2=A0MPLS-encapsula= ted NSH packets would require insider knowledge of the

An attacker i= n a position to inject traffic seems likely to also be able
to observe l= egitimate traffic and correspondingly their valid label
values (if not n= ecessarily the mapping from label to behavior).

=C2=A0

Absolutely, As I said above, if you've got that much ins= ider access, there are much easier ways to screw up a network than play wit= h MPLS packets.

=C2=A0


=C2= =A0 =C2=A0network's control and management planes and a way to inject p= ackets
=C2=A0 =C2=A0into internal interfaces.=C2=A0 This is compared to,= for example, NSH over
=C2=A0 =C2=A0UDP over IP, which could be injected= into any external interface in a
=C2=A0 =C2=A0network that was not prop= erly configured to filter out such packets
=C2=A0 =C2=A0at the ingress.<= br>
The NSH security considerations already (essentially) require thisfiltering at ingress behavior; the practical question relevant here
se= ems to just be a matter of scale -- how hard it is to misconfigure
this = filtering or how likely it is that the relevant filtering is
present as = a consequence of factors external to SFC.

=C2=A0

I think that's a question more for RFC 8300 than this draft. In= terms of how hard it is to misconfigure filtering, that's really an im= plementation and deployment question.

=C2=A0

Th= anks again for your review.

=C2=A0

Cheers,

Andy

<= div>

=C2=A0

=
--000000000000f7b8c30584274d6d-- From nobody Mon Mar 18 08:04:06 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3B1130E9A; Mon, 18 Mar 2019 08:04:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: mpls@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155292144536.26090.7017301366469931672@ietfa.amsl.com> Date: Mon, 18 Mar 2019 08:04:05 -0700 Archived-At: Subject: [mpls] IPR Disclosure China Mobile Communications Corporation' s Statement about IPR related to RFC 8227 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 15:04:05 -0000 Dear Weiqiang Cheng, Lei Wang, Han Li, Huub van Helvoort, Jie Dong: An IPR disclosure that pertains to your RFC entitled "MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology" (RFC8227) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3474/). The title of the IPR disclosure is "China Mobile Communications Corporation's Statement about IPR related to RFC 8227" Thank you IETF Secretariat From nobody Tue Mar 19 10:31:45 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBD6131578 for ; Tue, 19 Mar 2019 10:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.247 X-Spam-Level: X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 z5Mdl3g3OOWo for ; Tue, 19 Mar 2019 10:31:42 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130130.outbound.protection.outlook.com [40.107.13.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14CA131571 for ; Tue, 19 Mar 2019 10:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G3Ehr0K6YFH071wd5NAaKpK96I81j76rbuLBhs5kAZI=; b=RJ2W1mHUQ6NRuLF4UodP/1TEVgnjJCSA2NhXt9lLVP3RBX1Fdb0ccV04FSsJpsDgMnIQdD0UQ4ns+Z/jxC3rFNhEuoZ/Mfa+Nuu9ABwYRByNRZPy6afab7JpxubNLdN9UgnKfZgB9Yyi4mXAFSJ5Xaga4uBibo5T38MP0mW2EhU= Received: from AM6PR07MB5731.eurprd07.prod.outlook.com (20.177.189.85) by AM6PR07MB3959.eurprd07.prod.outlook.com (52.134.116.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.15; Tue, 19 Mar 2019 17:31:38 +0000 Received: from AM6PR07MB5731.eurprd07.prod.outlook.com ([fe80::c981:391e:4943:3dba]) by AM6PR07MB5731.eurprd07.prod.outlook.com ([fe80::c981:391e:4943:3dba%2]) with mapi id 15.20.1709.015; Tue, 19 Mar 2019 17:31:38 +0000 From: tom petch To: Tarek Saad CC: "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-static-yang-08.txt Thread-Index: AQHU03nqrT5RoCK7iEOJgW5Sst/P5g== Date: Tue, 19 Mar 2019 17:31:38 +0000 Message-ID: <034601d4de79$44f06000$4001a8c0@gateway.2wire.net> References: <155155736768.27158.1653954565392604255@ietfa.amsl.com> <016901d4d379$a1e91e60$4001a8c0@gateway.2wire.net> <068601d4d4e3$c5dc4980$4001a8c0@gateway.2wire.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0161.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9::29) To AM6PR07MB5731.eurprd07.prod.outlook.com (2603:10a6:20b:36::21) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.215.234] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8d5c2641-9922-4f62-89a9-08d6ac90bdbe x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7193020); SRVR:AM6PR07MB3959; x-ms-traffictypediagnostic: AM6PR07MB3959: x-ms-exchange-purlcount: 9 x-microsoft-antispam-prvs: x-forefront-prvs: 0981815F2F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(136003)(366004)(376002)(346002)(13464003)(199004)(189003)(53936002)(5660300002)(62236002)(86362001)(81166006)(256004)(50226002)(66066001)(68736007)(97736004)(8676002)(9686003)(81156014)(6306002)(305945005)(86152003)(4326008)(6246003)(6512007)(44716002)(4720700003)(8936002)(7736002)(476003)(71190400001)(486006)(44736005)(386003)(2906002)(478600001)(61296003)(71200400001)(6916009)(6486002)(106356001)(105586002)(966005)(99286004)(229853002)(6506007)(84392002)(25786009)(446003)(6116002)(316002)(52116002)(76176011)(3846002)(102836004)(53546011)(81686011)(1556002)(81816011)(93886005)(66574012)(14496001)(186003)(26005)(14454004)(6436002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB3959; H:AM6PR07MB5731.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: VgZ5UNfbiBQK+bLwpjmCHrNFi9doA7bTM+47qK5SFdhfHIxXrZcPSPwHtV57qEPGFKi7xPJO//2m1JuoGR+rqtnWRiWyOVt5VRl7a54rK2NBE7zElgQRjZzXLyw8aGWnLEcALdWg8xMrbhlZejpR/jJ8eF1O4utEqHuW6nONXwuPZsqbrqLd8rmyGl5D5TM7Dw8j4swGyKTLMjf5OyxYZJq6H4YDnYzF3y83/OtF9lVvy2bSo8tlwz3ygncn2eur2LgK5mUezHUS62zU7lEMcjhrcwGLuyqh/G5iKN9gaaxkuVsB4WtUDLcv1iiLIGTyP7oaZbo5w5/pbg29Q1PGZM0g3E2butTlUmlD5hxPGrwjk21ZfReTrW91F78DydTKO48E1TtSPIKAgd2Y6VGANLtFpD6Re0OmnJaK2gKDWgI= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8d5c2641-9922-4f62-89a9-08d6ac90bdbe X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2019 17:31:38.0974 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB3959 Archived-At: Subject: Re: [mpls] I-D Action: draft-ietf-mpls-static-yang-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 17:31:44 -0000 LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiAiVGFyZWsgU2FhZCIgPHRzYWFkLm5l dEBnbWFpbC5jb20+DQpTZW50OiBGcmlkYXksIE1hcmNoIDA4LCAyMDE5IDc6MTMgUE0NCg0KPiBU aGFua3MgVG9tLiBUaGUgY29tbWVudHMgYXJlIGFkZHJlc3NlZCBpbiB2ZXJzaW9uIC0wOToNCj4g aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbXBscy1zdGF0aWMteWFuZy0w OQ0KPg0KPiBBbmQgZGlmZjoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWlldGYtbXBscy1zdGF0aWMteWFuZy0wOQ0KDQpJbmRlZWQgdGhleSBhcmUuICBUd28gbW9y ZSB0ZWNobmljYWwgdGhvdWdodHMNCg0KSUFOQSBDb25zaWRlcmF0aW9ucyBoYXMNCg0KICAgICAg cHJlZml4OiAgICAgaWV0Zi1tcGxzLXN0YXRpYy1leHRlbmRlZA0KDQp3aGljaCBJIHdhcyBhYm91 dCB0byBzYXkgd2FzIHJhdGhlciBsb25nIGZvciBhIHByZWZpeCBhbmQgdGhlbiBJIHNhdw0KDQog ICBtb2R1bGUgaWV0Zi1tcGxzLXN0YXRpYy1leHRlbmRlZCB7IC4uLg0KICAgICBwcmVmaXggIm1w bHMtc3RhdGljLWV4dCI7DQoNCndoaWNoIGlzIG5vdCBzbyBsb25nLCBwcm9iYWJseSBzaG9ydCBl bm91Z2ggKGlmIHRoYXQgaXMgdGhlIHJpZ2h0IG9uZSEpLg0KDQpTZWNvbmQsIEkgYW0gd29udCB0 byBjaGVjayBzdWNoIHN0YXRlbWVudHMgYXMNCiAgICAgICBsZWFmIGxzcC1wcmlvcml0eS1ob2xk IHsgdHlwZSB1aW50OCB7DQogICAgICAgICAgIHJhbmdlICIwLi43IjsgIH0NCiAgICAgICAgIGRl c2NyaXB0aW9uICJMU1AgaG9sZCBwcmlvcml0eSI7DQphZ2FpbnN0IHRoZSBvcmlnaW5hbCBzcGVj aWZpY2F0aW9uLCBzaW5jZSBJIGtub3cgb2YgcnRnd2cgWUFORyBtb2R1bGVzDQp3aGVyZSB0aGUg WUFORyBjb250cmFkaWN0cyB0aGUgcHVibGlzaGVkIFJGQzsgYnV0IHRoZXJlIGlzIG5vIHJlZmVy ZW5jZQ0KY2xhdXNlIGZvciBvYmplY3RzIHN1Y2ggYXMgdGhpcyBvbmUsIHNvIEkgd291bGQgaGF2 ZSB0byBnbyBkaWdnaW5nIGZvcg0KdGhlIHJlbGV2YW50IFJGQywgd2hpY2ggd2FzIGVhc3kgaW4g MjAwMSBiZWNhdXNlIHRoZXJlIHdlcmUgc28gZmV3IFJGQw0KYnV0IG5vdyAuLi4NCg0KSWYgeW91 IGFkZCByZWZlcmVuY2VzLCBJIHdpbGwgZ28gbG9vayB1cCB0aGUgcmVsZXZhbnQgc2VjdGlvbnMg LSBpZiBub3QsDQouLi4NCg0KVXAgdG8geW91Oi0pDQoNClRvbSBQZXRjaA0KDQo+IFJlZ2FyZHMs DQo+IFRhcmVrDQo+DQo+IO+7v09uIDMvOC8xOSwgMToxNCBQTSwgIlRhcmVrIFNhYWQiIDx0c2Fh ZC5uZXRAZ21haWwuY29tPiB3cm90ZToNCj4NCj4gICAgIEhpIFRvbSwNCj4NCj4gICAgIFRoYW5r cy4gV2UnbGwgdW5pZnkgdG8gIk1icHMiIGFuZCBrZWVwIHRoaXMgY29uc2lzdGVudCBpbiB1bml0 cw0KYW5kIGRlc2NyaXB0aW9uLg0KPg0KPiAgICAgUmVnYXJkcywNCj4gICAgIFRhcmVrDQo+DQo+ ICAgICDvu79PbiAzLzcvMTksIDc6NDggQU0sICJ0b20gcGV0Y2giIDxpZXRmY0BidGNvbm5lY3Qu Y29tPiB3cm90ZToNCj4NCj4gICAgICAgICBUYXJlaw0KPg0KPiAgICAgICAgIE9uZSBwb2ludCBJ IGtlZXAgbm90aWNpbmcgYnV0IGRvIG5vdCB0aGluayBJIGhhdmUgcmFpc2VkDQpiZWZvcmUgaXMN Cj4NCj4gICAgICAgICAgICAgICB1bml0cyBtYnBzOw0KPiAgICAgICAgICAgICAgIGRlc2NyaXB0 aW9uDQo+ICAgICAgICAgICAgICAgICAiQmFuZHdpZHRoIGluIE1icHMsDQo+DQo+ICAgICAgICAg SSBoYXZlIGtub3duIHN5c3RlbXMgZmFpbCBiZWNhdXNlIG9uZSBwYXJ0eSB3YXMgdXNpbmcgbWJw cywNCmFub3RoZXINCj4gICAgICAgICBNYnBzLCBzbyBzZWVpbmcgYSBtaXggb2YgdGhlIHR3bywg YXMgaGVyZSwgcmFpc2VzIGEgZmxhZyBmb3INCm1lLiAgSSBub3RlDQo+ICAgICAgICAgdGhhdA0K PiAgICAgICAgIGRyYWZ0LWlldGYtdGVhcy15YW5nLXRlLXR5cGVzDQo+ICAgICAgICAgaGFzDQo+ ICAgICAgICAgICAgICAgIHVuaXRzICJNYnBzIjsNCj4gICAgICAgICB3aGljaCBJIHByZWZlciAt IGlmIHRoZXkgcmVhbGx5IG1lYW4gTWJwcyBhbmQgbm90IG1icHM7IEkgaGF2ZQ0KbXkNCj4gICAg ICAgICBkb3VidHMhIC0gYnV0IHRoZW4NCj4gICAgICAgICAgZHJhZnQtaWV0Zi1sMnNtLWwydnBu LXNlcnZpY2UtbW9kZWwtMTANCj4gICAgICAgICBoYXMNCj4gICAgICAgICAgICAgICAgIHVuaXRz ICJtYnBzIjsNCj4gICAgICAgICAgICAgICAgIGRlZmF1bHQgIjEwIjsgIGRlc2NyaXB0aW9uDQo+ ICAgICAgICAgICAgICAgICAgICJMQUNQIHNwZWVkLiBCeSBkZWZhdWx0LCB0aGUgbGFjcCBzcGVl ZCBpcyAxME1icHMuIjsNCj4NCj4gICAgICAgICBQZXJoYXBzIGluIHRoZSBjb250ZXh0IG9mIE1Q TFMgdGhlcmUgaXMgbm8gYW1iaWd1aXR5IGJ1dCBpdA0Kd291bGQgYmUNCj4gICAgICAgICBuaWNl IHRvIGhhdmUgY29uc2lzdGVuY3kgYXQgbGVhc3Qgd2l0aGluIGFuIEktRC4NCj4NCj4gICAgICAg ICBUb20gUGV0Y2gNCj4NCj4gICAgICAgICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ ICAgICAgICAgRnJvbTogIlRhcmVrIFNhYWQiIDx0c2FhZC5uZXRAZ21haWwuY29tPg0KPiAgICAg ICAgIFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMDYsIDIwMTkgMjo1MyBQTQ0KPg0KPg0KPiAgICAg ICAgID4gSGkgVG9tLA0KPiAgICAgICAgID4NCj4gICAgICAgICA+IEFzIHVzdWFsLCB0aGFua3Mg Zm9yIHlvdXIgcmV2aWV3IG9uIHRoaXMgb25lIGFuZCBmb3IgeW91cg0KcGF0aWVuY2UuDQo+ICAg ICAgICAgTW9yZQ0KPiAgICAgICAgID4gSW5saW5lLi4NCj4gICAgICAgICA+DQo+ICAgICAgICAg PiBPbiBUdWUsIE1hciA1LCAyMDE5IGF0IDEyOjM2IFBNIHRvbSBwZXRjaA0KPGlldGZjQGJ0Y29u bmVjdC5jb20+IHdyb3RlOg0KPiAgICAgICAgID4NCj4gICAgICAgICA+ID4gQSBsb25nIGFuZCB3 aW5kaW5nIHJvYWQhDQo+ICAgICAgICAgPiA+DQo+ICAgICAgICAgPiA+ICBtb2R1bGUgaWV0Zi1t cGxzLXN0YXRpYyB7DQo+ICAgICAgICAgPiA+IC4uLi4uDQo+ICAgICAgICAgPiA+ICAgIGltcG9y dCBpZXRmLXJvdXRpbmctdHlwZXMgew0KPiAgICAgICAgID4gPiAgICAgIHByZWZpeCAicnQtdHlw ZXMiOw0KPiAgICAgICAgID4gPiAgICAgIHJlZmVyZW5jZSAiUkZDODI5NDogQ29tbW9uIFlBTkcg RGF0YSBUeXBlcyI7DQo+ICAgICAgICAgPiA+DQo+ICAgICAgICAgPiA+IEkgc2VlLCBpbiB0aGUg UkZDIEluZGV4LA0KPiAgICAgICAgID4gPg0KPiAgICAgICAgID4gPiA4Mjk0IENvbW1vbiBZQU5H IERhdGEgVHlwZXMgZm9yIHRoZSBSb3V0aW5nIEFyZWEuDQo+ICAgICAgICAgPiA+IGkuZS4gYSBk aWZmZXJlbnQgdGl0bGUNCj4gICAgICAgICA+ID4NCj4gICAgICAgICA+ID4gW1RTXTogeWVzLCB1 bmZvcnR1bmF0ZWx5IGEgZGVqYSB2dSAoZml4ZWQgaW4gYW5vdGhlcg0KbW9kdWxlKS4gV2UnbGwN Cj4gICAgICAgICB0YWtlDQo+ICAgICAgICAgPiBjYXJlIG9mIHRoaXMgaW4gdGhlIG5ldyB2ZXJz aW9uLg0KPiAgICAgICAgID4NCj4gICAgICAgICA+ID4NCj4gICAgICAgICA+ID4gbW9kdWxlIGll dGYtbXBscy1zdGF0aWMtZXh0ZW5kZWQgew0KPiAgICAgICAgID4gPiAuLi4uDQo+ICAgICAgICAg PiA+ICAgaW1wb3J0IGlldGYtcm91dGluZyB7ICAgIHByZWZpeCAicnQiOw0KPiAgICAgICAgID4g PiAgICAgcmVmZXJlbmNlICJSRkM2OTkxOiBDb21tb24gWUFORyBEYXRhIFR5cGVzIjsNCj4gICAg ICAgICA+ID4gSSBzdWdnZXN0DQo+ICAgICAgICAgPiA+ICAgICAgcmVmZXJlbmNlICJSRkM4MzQ5 OiBBIFlBTkcgRGF0YSBNb2RlbCBmb3IgUm91dGluZw0KTWFuYWdlbWVudCI7DQo+ICAgICAgICAg PiA+DQo+ICAgICAgICAgPiA+IFtUU106IHllcywgd2lsbCB0YWtlIG9mIHRoaXMuDQo+ICAgICAg ICAgPg0KPiAgICAgICAgID4gIHJlZmVyZW5jZSAiUkZDIFhYWFg6IEV4dGVuZGVkIFlBTkcgRGF0 YSBNb2RlbCBmb3IgTVBMUw0KU3RhdGljIExTUHMiOw0KPiAgICAgICAgID4gPiB1bSAtIEkgc2Vl IHRoaXMgSS1EIGFzIHRpdGxlZA0KPiAgICAgICAgID4gPiBBIFlBTkcgRGF0YSBNb2RlbCBmb3Ig TVBMUyBTdGF0aWMgTFNQcw0KPiAgICAgICAgID4gPg0KPiAgICAgICAgID4gPiBbVFNdOiBPSyBm b3IgdGhpcyBvbmUgdG9vLg0KPiAgICAgICAgID4NCj4gICAgICAgICA+IFJlZ2FyZHMsDQo+ICAg ICAgICAgPiBUYXJlaw0KPiAgICAgICAgID4NCj4gICAgICAgICA+DQo+ICAgICAgICAgPiA+DQo+ ICAgICAgICAgPiA+IFRvbSBQZXRjaA0KPiAgICAgICAgID4gPg0KPiAgICAgICAgID4gPg0KPiAg ICAgICAgID4gPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ICAgICAgICAgPiA+IEZy b206IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQo+ICAgICAgICAgPiA+IFRvOiA8aS1kLWFu bm91bmNlQGlldGYub3JnPg0KPiAgICAgICAgID4gPiBDYzogPG1wbHNAaWV0Zi5vcmc+DQo+ICAg ICAgICAgPiA+IFNlbnQ6IFNhdHVyZGF5LCBNYXJjaCAwMiwgMjAxOSA4OjA5IFBNDQo+ICAgICAg ICAgPiA+DQo+ICAgICAgICAgPiA+ID4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxl IGZyb20gdGhlIG9uLWxpbmUNCkludGVybmV0LURyYWZ0cw0KPiAgICAgICAgID4gPiBkaXJlY3Rv cmllcy4NCj4gICAgICAgICA+ID4gPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBN dWx0aXByb3RvY29sIExhYmVsDQpTd2l0Y2hpbmcgV0cNCj4gICAgICAgICBvZg0KPiAgICAgICAg ID4gPiB0aGUgSUVURi4NCj4gICAgICAgICA+ID4gPg0KPiAgICAgICAgID4gPiA+ICAgICAgICAg VGl0bGUgICAgICAgICAgIDogQSBZQU5HIERhdGEgTW9kZWwgZm9yIE1QTFMNClN0YXRpYyBMU1Bz DQo+ICAgICAgICAgPiA+ID4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBUYXJlayBTYWFkDQo+ ICAgICAgICAgPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBSYWtlc2ggR2FuZGhpDQo+ ICAgICAgICAgPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBYdWZlbmcgTGl1DQo+ICAg ICAgICAgPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBWaXNobnUgUGF2YW4gQmVlcmFt DQo+ICAgICAgICAgPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBJZ29yIEJyeXNraW4N Cj4gICAgICAgICA+ID4gPiBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW1wbHMtc3RhdGlj LXlhbmctMDgudHh0DQo+ICAgICAgICAgPiA+ID4gUGFnZXMgICAgICAgICAgIDogMTgNCj4gICAg ICAgICA+ID4gPiBEYXRlICAgICAgICAgICAgOiAyMDE5LTAzLTAyDQo+ICAgICAgICAgPiA+ID4N Cj4gICAgICAgICA+ID4gPiBBYnN0cmFjdDoNCj4gICAgICAgICA+ID4gPiAgICBUaGlzIGRvY3Vt ZW50IGNvbnRhaW5zIHRoZSBzcGVjaWZpY2F0aW9uIGZvciB0aGUgTVBMUw0KU3RhdGljDQo+ICAg ICAgICAgTGFiZWwNCj4gICAgICAgICA+ID4gPiAgICBTd2l0Y2hlZCBQYXRocyAoTFNQcykgWUFO RyBtb2RlbC4gIFRoZSBtb2RlbCBhbGxvd3MNCmZvciB0aGUNCj4gICAgICAgICA+ID4gPiAgICBw cm92aXNpb25pbmcgb2Ygc3RhdGljIExTUChzKSBvbiBMYWJlbCBFZGdlIFJvdXRlcihzKQ0KTEVS KHMpDQo+ICAgICAgICAgYW5kDQo+ICAgICAgICAgPiA+ID4gICAgTGFiZWwgU3dpdGNoZWQgUm91 dGVyKHMpIExTUihzKSBkZXZpY2VzIGFsb25nIGEgTFNQDQpwYXRoDQo+ICAgICAgICAgd2l0aG91 dA0KPiAgICAgICAgID4gPiB0aGUNCj4gICAgICAgICA+ID4gPiAgICBkZXBlbmRlbmN5IG9uIGFu eSBzaWduYWxpbmcgcHJvdG9jb2wuICBUaGUgTVBMUw0KU3RhdGljIExTUA0KPiAgICAgICAgIG1v ZGVsDQo+ICAgICAgICAgPiA+ID4gICAgYXVnbWVudHMgdGhlIE1QTFMgYmFzZSBZQU5HIG1vZGVs IHdpdGggc3BlY2lmaWMgZGF0YQ0KdG8NCj4gICAgICAgICBjb25maWd1cmUNCj4gICAgICAgICA+ ID4gYW5kDQo+ICAgICAgICAgPiA+ID4gICAgbWFuYWdlIE1QTFMgU3RhdGljIExTUChzKS4NCj4g ICAgICAgICA+ID4gPg0KPiAgICAgICAgID4gPiA+DQo+ICAgICAgICAgPiA+ID4gVGhlIElFVEYg ZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ICAgICAgICAgPiA+ ID4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbXBscy1zdGF0 aWMteWFuZy8NCj4gICAgICAgICA+ID4gPg0KPiAgICAgICAgID4gPiA+IFRoZXJlIGFyZSBhbHNv IGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4gICAgICAgICA+ID4gPg0KaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbXBscy1zdGF0aWMteWFuZy0wOA0KPiAg ICAgICAgID4gPiA+DQo+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LWlldGYtbXBscy1zdGF0aWMteWFuZy0wOA0KPiAgICAgICAgID4gPiA+DQo+ICAgICAgICAg PiA+ID4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0K PiAgICAgICAgID4gPiA+DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aWV0Zi1tcGxzLXN0YXRpYy15YW5nLTA4DQo+ICAgICAgICAgPiA+ID4NCj4gICAgICAgICA+ID4g Pg0KPiAgICAgICAgID4gPiA+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tDQp0aGUgdGltZSBvZg0KPiAgICAgICAgID4gPiBzdWJtaXNzaW9uDQo+ ICAgICAgICAgPiA+ID4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdA0KPiAgICAgICAgIHRvb2xzLmlldGYub3JnLg0KPiAgICAgICAgID4gPiA+DQo+ ICAgICAgICAgPiA+ID4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9u eW1vdXMgRlRQIGF0Og0KPiAgICAgICAgID4gPiA+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvDQo+ICAgICAgICAgPiA+ID4NCj4gICAgICAgICA+ID4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgICAgID4gPiA+IEktRC1B bm5vdW5jZSBtYWlsaW5nIGxpc3QNCj4gICAgICAgICA+ID4gPiBJLUQtQW5ub3VuY2VAaWV0Zi5v cmcNCj4gICAgICAgICA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2ktZC1hbm5vdW5jZQ0KPiAgICAgICAgID4gPiA+IEludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVz Og0KaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0KPiAgICAgICAgID4gPiA+IG9yIGZ0 cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQo+ICAgICAgICAgPiA+DQo+ ICAgICAgICAgPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ICAgICAgICAgPiA+IG1wbHMgbWFpbGluZyBsaXN0DQo+ICAgICAgICAgPiA+IG1wbHNA aWV0Zi5vcmcNCj4gICAgICAgICA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzDQo+ICAgICAgICAgPiA+DQo+ICAgICAgICAgPg0KPg0KPg0KPg0KPg0KDQo= From nobody Tue Mar 19 17:18:01 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F5912AF7E; Tue, 19 Mar 2019 17:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 zLVKtHS1tDLj; Tue, 19 Mar 2019 17:17:56 -0700 (PDT) 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 6B228129515; Tue, 19 Mar 2019 17:17:56 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2K0Hpe2001429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 Mar 2019 20:17:53 -0400 Date: Tue, 19 Mar 2019 19:17:51 -0500 From: Benjamin Kaduk To: "Andrew G. Malis" Cc: The IESG , draft-ietf-mpls-sfc-encapsulation@ietf.org, Loa Andersson , mpls-chairs , mpls Message-ID: <20190320001751.GS80498@kduck.mit.edu> References: <155252958505.24865.4180223375091950120.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-sfc-encapsulation-03: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 00:17:59 -0000 On Fri, Mar 15, 2019 at 11:05:59AM -0400, Andrew G. Malis wrote: > Benjamin, > > Thanks for your review and comments. See below inline. > > On Wed, Mar 13, 2019 at 10:13 PM Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Thanks for this clear and concise document! I just have one concern, > > which will hopefully be easy to resolve (since there is a good chance > > that all the text necessary to do so is already written). > > > > As far as I can tell, the comment made by the secdir reviewer of > > draft-ietf-mpls-sfc-04 about circular references between that document > > and RFCs 7665 and 8300 regarding security properties, is also somewhat > > applicable to this document. I do recognize the validity of first > > paragraph of the security considerations here (the NSH is an opaque > > payload for MPLS), but that in and of itself does not present a security > > analysis of the NSH in the MPLS environment. The last paragraph of the > > security considerations of this document attempts to provide some > > analysis, but it seems to be incomplete and perhaps overly optimistic, > > particularly with respect to the use of MPLS with Inter-Carrier > > Interconnect and the processing of MPLS traffic from external > > interfaces. Is there any reason not to fully harmonize (i.e., > > synchronize) the security considerations of draft-ietf-mpls-sfc and > > draft-ietf-mpls-sfc-encapsulation? (I guess the first paragraph of this > > document's security considerations doesn't apply to the other document, > > that allocates extended-special-purpose label values, but that's the > > only thing I saw.) > > > > Trying to keep this document in sync with draft-ietf-mpls-sfc was difficult > because it was a moving target while this draft was being developed, and of > course, it was updated during IETF last call and IESG review following the > completion of this draft. And as you noted, there are some fundamental > differences between the two drafts. Because the other draft makes some > additions and changes to the MPLS label stack while this draft uses the > MPLS label stack as designed and in wide practice, there's text in the > other draft that doesn't apply to this one, such as regarding the use of > MPLS to encode a logical representation of the NSH. Other than things purely related to the specific encoding of the semantic content of the NSH, though, it seems that the security and privacy considerations to conveying the information content of the NSH over MPLS transit should be essentially identical, regardless of how that semantic content is encoded. Did you have in mind text in specifically the security considerations of the other draft that doesn't apply to this one? I made a quick skim and didn't see anything that stuck out, but it was pretty quick. > If you have any specific suggestions for improvement for the text here, > that would be greatly appreciated! Also, does the IESG have any policy I suppose this may change given the response to my question above, but given my comments in the COMMENT section on this document's security considerations, my initial specific suggestion would be to take the first paragraph from this document, strike the other three paragraphs, and incorporate (whether inline or by reference) the full security considerations from the other document. (And to be clear, "initial" and "suggestion" are important words here; I don't intend to say this is the final word.) > regarding direct copying of applicable text from one draft to another in > situations like this? Or perhaps we could just add a reference to I don't know of a policy one way or the other... > particular paragraphs in section 15 of draft-ietf-mpls-sfc? That would > remove the need to copy any text. ... but the reference seems like it should be sufficient, at least. > I'll await your reply before taking any action. > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Section 1 > > > > This encapsulation is equivalent from an SFC perspective to other > > transport encapsulations of packets using the NSH. This can be > > illustrated by adding an additional line to the example of a next-hop > > SPI/SI-to-network overlay network locator mapping in Table 1 of > > [RFC8300]: > > > > We probably should expand SPI and SI, since we haven't yet hit a > > terminiology section or a note that (implies that) readers should be > > familiar with the standard SFC terminology. > > Also, Table 1 of RFC 8300 is labeled "SFF NSH Mapping Example"; it's not > > really clear that specifically that table is the best way to illustrate > > how the MPLS encapsulation would work. > > > > That table 1 extension was added to the draft as a result of the Routing > Directorate review. Other than expanding the acronyms, I'll leave making > any changes here up to Deborah. Okay. I doubt I'm really the target audience anyway... > > > (side note) We use the strings "VPN" and "virtual private" here, which > > in some contexts will cause an (uninformed) reader to assume that data > > privacy (confidentiality) is involved; our uses do not seem to be for > > cases that would involve such a confidentiality property. As a general > > matter, not necessarily involving changes to this document, it may be > > good to try to reserve these terms for cases where the confidentiality > > is in fact provided, to help disambiguate the cases for the reader. > > > > I take your point, but these are just examples of other uses of MPLS > service labels. > > > > Section 2.1 > > > > nit: s/The TTL For/The TTL for/ (twice) > > > > Will fix. > > > > > > Section 3 > > > > For SFC, ECMP may or may not be desirable. To prevent ECMP when it > > is not desired, the NSH Base Header was carefully constructed so that > > the NSH could not look like IPv4 or IPv6 based on its first nibble. > > See Section 2.2 of [RFC8300] for further details. > > > > nit: this paragraph might flow better into the next one if we add a note > > that "Accordingly, the default behavior for MPLS-encapsulated SFC will > > not use ECMP." > > > > Good suggestion, will add. > > > > > > Section 6 > > > > However, it can be argued that carrying the NSH over MPLS is more > > > > re: "it can be argued" -- is this document attempting to make that > > argument? > > > > It could be argued that is the case! :-) I think that "arguably is more secure" would more directly represent such a claim, but it is of course your call. > > > secure than using other encapsulations, as it is extremely difficult, > > due to the MPLS architecture, for an attempted attacker to inject > > > > It's not entirely clear to me how much of this is the MPLS architecture > > vs. implementation/deployment; I suppose to some extent it is true of > > both. > > > > IMHO, it really is a result of the architecture, and as a result, any > implementation that properly follows the architecture. MPLS packets must be > created by a PE router, and downstream P routers will drop any incoming (I think the crux of what I'm "not clear" about is the source of this "must". But it seems unlikely to be relevant to the present discussion, so perhaps we should just drop this topic.) > MPLS packets from upstream P or PE routers that don't have a top-most label > that's in the router's LIB. So successfully injecting MPLS attack packets Just needing to know the label allocations that are valid for that router is unlikely to inspire much confidence from security-area folks; given that this is necessarily shared with several parties (i.e., at least everything directly connected to that router) it's hard for us, in our mental model, to be confident that it will remain secret and unguessable. (Also, depending on their goal, an attacker may not need to know what a specific label does, so if they just need to be able to guess *any* valid label, their job gets easier.) > really does require insider access, and if you have that, there are so many An N of 2**20 chance of success (per packet!) doesn't really mesh with "requires insider access", given my present understanding. > other bad things you can do that are less expensive or difficult than > trying to use an MPLS-based attack. Sure, but that doesn't always mean that we should completely ignore the risk; the situation may not always be that way. > > > > > unexpected MPLS packets into a network, as MPLS networks do not by > > design accept MPLS packets from external interfaces, and an attacker > > > > What about Inter-Carrier Interconnect? > > > > MPLS ICI is really off-topic for this draft because the NSH is only used in > limited SFC domains that not only within a single domain (see RFC 8300), > but within a well-defined sub-domain of that provider, such as within a > data center. The specific text I quoted was supposedly talking about generic MPLS networks, not restricted to sites using the NSH. The argument, as stated, does not seem to hold up, given the ability of MPLS networks to use ICI to accept external traffic (i.e., it is "within the design"). The specific environments in which the NSH is intended to be used may well have a different situation, but the current text does not reflect that different situation, just from a purely rhetorical point of view. > That said, just to answer your question, carriers for the most part don't > do MPLS across carrier boundaries, there's too much trust that would be > required. That said, there are some examples of inter-carrier MPLS, most > commonly using RFC 4364 option A, which really isn't an MPLS interface. > There is an MPLS Forum document, > https://www.broadband-forum.org/technical/download/ipmpls/IPMPLSForum19.0.0.pdf > , which discusses the various ways one can implement an MPLS ICI and the > security implications of doing so, in section 13. (I couldn't find "option A" in RFC 4364, and the broadband-forum link gives a 404 over here.) > > > > > would need knowledge of the specific labels allocated by control and/ > > or management plane protocols. Thus, an attacker attempting to spoof > > MPLS-encapsulated NSH packets would require insider knowledge of the > > > > An attacker in a position to inject traffic seems likely to also be able > > to observe legitimate traffic and correspondingly their valid label > > values (if not necessarily the mapping from label to behavior). > > > > Absolutely, As I said above, if you've got that much insider access, there > are much easier ways to screw up a network than play with MPLS packets. My point is that from a rhetorical point of view, this is a facile argument -- the "requirement" would essentially always be met by anyone that meets the preconditions from the first part of the sentence. > > > > > network's control and management planes and a way to inject packets > > into internal interfaces. This is compared to, for example, NSH over > > UDP over IP, which could be injected into any external interface in a > > network that was not properly configured to filter out such packets > > at the ingress. > > > > The NSH security considerations already (essentially) require this > > filtering at ingress behavior; the practical question relevant here > > seems to just be a matter of scale -- how hard it is to misconfigure > > this filtering or how likely it is that the relevant filtering is > > present as a consequence of factors external to SFC. > > > > I think that's a question more for RFC 8300 than this draft. In terms of > how hard it is to misconfigure filtering, that's really an implementation > and deployment question. I guess I'm trying to say that the comparison doesn't feel particularly compelling to me (given my (low) level of background knowledge) -- 8300 requires this sort of filtering in all cases, whether MPLS or UDP or otherwise. The expected MPLS deployment setup (or architecture, as you put it) makes this happen essentially by default, but anything using the NSH is supposed to do it. So, the comparison is not really about the encoding per se, but rather around the risk/likelihood of noncompliant deployment, but the current wording gives the impression that it's supposed to arise as a natural consequence of the encoding (as opposed to the deployment details). > Thanks again for your review. And thanks for your responses! Sorry for the slow reply. Benjamin From nobody Wed Mar 20 05:12:46 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E9D12865E; Wed, 20 Mar 2019 05:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 M3deG6rY2FHA; Wed, 20 Mar 2019 05:12:41 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 2965B127918; Wed, 20 Mar 2019 05:12:41 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id t28so2127533qte.6; Wed, 20 Mar 2019 05:12:41 -0700 (PDT) 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=jNn31cuLEQVzK6vn8sYCXrlF2j0TdvFdJ2y89h0TqUI=; b=JkL/74couHHmoihQWWq0tgbvWWhJH/NnCBtzQEkx/BhlfSR3epqJ8EP254Rzn1r/Cs kJBz4jXFfAWLwYzm0ptjYWwI9bpYs7+pJhfAGlQ9ssQKENnNk92az3vaQVVYaj6T8SRD LOT67OSHK6Xkh7I4OUKO1JcrCgweUpwon/toszNBWZNSPZGMwnKRtyiiGpi1xGPJsanD TE3LxCxInrd/+MOf5shcHKfaKr1OpNuB+XklhtPgXw98AiexB7PBzUTl5L9KM2yAAGt8 r7y+Gf62s2Jx3LX9cVz8UFBZLiPwmhl+WjcbNNVhOIM0sW8az315NLKkBrkoOfxfDO/V ghYg== 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=jNn31cuLEQVzK6vn8sYCXrlF2j0TdvFdJ2y89h0TqUI=; b=c917AdqjpAxExRQJoI1raNZrBAVx5wtWwsEj7qrGiq2HZnIB9L4BnMGbJmeipwvpZA pNT52gQU7XBX8QEGS8K9n2D6xd9kG5GkW/dGQm1LDVjXLmkLjWGCtaNXp8B6QG5IqkHN bKj/3+U2BqCu2m0pG5ntXzATGofmzqXvHYCIDWCSoN/Wc5gtn9iz54FyKZfPXGsqkoPB DBIjjQIhEuC54uySbeY85XRNx5RXgZzQWm9bhBB5aa8vPM9dNrYEmVx0IKZneJvzhQVa qTxLRn3ZCBTqAlT+m+7Y6rmsOVehynxVSppJey7WzEIdTx0hyoptrZy2XFExy5rB++Yd uCUQ== X-Gm-Message-State: APjAAAWCRn/pZfNCt/YyLCnrOsrDSNg1XSuNT1nCxdKY9MjtxK3yH1JZ O57+cdKWsOF68f7KW0hKki/+6UaS0vbWXEbn4qQ= X-Google-Smtp-Source: APXvYqxvCxzjPrIvJTepN0OIaLnKOmCeSs9eriXCxBnpR3Tt8VS4hlSE96HKp/gs02uVuo75AzvMusHmqpX4/LUakeA= X-Received: by 2002:ac8:2eec:: with SMTP id i41mr2975841qta.81.1553083960020; Wed, 20 Mar 2019 05:12:40 -0700 (PDT) MIME-Version: 1.0 References: <155252958505.24865.4180223375091950120.idtracker@ietfa.amsl.com> <20190320001751.GS80498@kduck.mit.edu> In-Reply-To: <20190320001751.GS80498@kduck.mit.edu> From: "Andrew G. Malis" Date: Wed, 20 Mar 2019 08:12:28 -0400 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-mpls-sfc-encapsulation@ietf.org, Loa Andersson , mpls-chairs , mpls Content-Type: multipart/alternative; boundary="000000000000be54d305848589d9" Archived-At: Subject: Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-sfc-encapsulation-03: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 12:12:45 -0000 --000000000000be54d305848589d9 Content-Type: text/plain; charset="UTF-8" Benjamin, Thanks again. I'm not sure why that BBF URL stopped working, but you can find the document here: https://web.archive.org/web/20160426184514/https://www.broadband-forum.org/technical/download/ipmpls/IPMPLSForum19.0.0.pdf I'll check with them regarding fixing the link going forward. Regarding option a of RFC 4364, see section 10 on p. 32. We've always referred to those as options a, b, and c. Once I get the go-ahead from Deborah, I'll do an update on the draft. Cheers, Andy On Tue, Mar 19, 2019 at 8:17 PM Benjamin Kaduk wrote: > On Fri, Mar 15, 2019 at 11:05:59AM -0400, Andrew G. Malis wrote: > > Benjamin, > > > > Thanks for your review and comments. See below inline. > > > > On Wed, Mar 13, 2019 at 10:13 PM Benjamin Kaduk via Datatracker < > > noreply@ietf.org> wrote: > > > > > > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > Thanks for this clear and concise document! I just have one concern, > > > which will hopefully be easy to resolve (since there is a good chance > > > that all the text necessary to do so is already written). > > > > > > As far as I can tell, the comment made by the secdir reviewer of > > > draft-ietf-mpls-sfc-04 about circular references between that document > > > and RFCs 7665 and 8300 regarding security properties, is also somewhat > > > applicable to this document. I do recognize the validity of first > > > paragraph of the security considerations here (the NSH is an opaque > > > payload for MPLS), but that in and of itself does not present a > security > > > analysis of the NSH in the MPLS environment. The last paragraph of the > > > security considerations of this document attempts to provide some > > > analysis, but it seems to be incomplete and perhaps overly optimistic, > > > particularly with respect to the use of MPLS with Inter-Carrier > > > Interconnect and the processing of MPLS traffic from external > > > interfaces. Is there any reason not to fully harmonize (i.e., > > > synchronize) the security considerations of draft-ietf-mpls-sfc and > > > draft-ietf-mpls-sfc-encapsulation? (I guess the first paragraph of > this > > > document's security considerations doesn't apply to the other document, > > > that allocates extended-special-purpose label values, but that's the > > > only thing I saw.) > > > > > > > Trying to keep this document in sync with draft-ietf-mpls-sfc was > difficult > > because it was a moving target while this draft was being developed, and > of > > course, it was updated during IETF last call and IESG review following > the > > completion of this draft. And as you noted, there are some fundamental > > differences between the two drafts. Because the other draft makes some > > additions and changes to the MPLS label stack while this draft uses the > > MPLS label stack as designed and in wide practice, there's text in the > > other draft that doesn't apply to this one, such as regarding the use of > > MPLS to encode a logical representation of the NSH. > > Other than things purely related to the specific encoding of the semantic > content of the NSH, though, it seems that the security and privacy > considerations to conveying the information content of the NSH over MPLS > transit should be essentially identical, regardless of how that semantic > content is encoded. Did you have in mind text in specifically the security > considerations of the other draft that doesn't apply to this one? I made > a quick skim and didn't see anything that stuck out, but it was pretty > quick. > > > If you have any specific suggestions for improvement for the text here, > > that would be greatly appreciated! Also, does the IESG have any policy > > I suppose this may change given the response to my question above, but > given my comments in the COMMENT section on this document's security > considerations, my initial specific suggestion would be to take the first > paragraph from this document, strike the other three paragraphs, and > incorporate (whether inline or by reference) the full security > considerations from the other document. > > (And to be clear, "initial" and "suggestion" are important words here; I > don't intend to say this is the final word.) > > > regarding direct copying of applicable text from one draft to another in > > situations like this? Or perhaps we could just add a reference to > > I don't know of a policy one way or the other... > > > particular paragraphs in section 15 of draft-ietf-mpls-sfc? That would > > remove the need to copy any text. > > ... but the reference seems like it should be sufficient, at least. > > > I'll await your reply before taking any action. > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > Section 1 > > > > > > This encapsulation is equivalent from an SFC perspective to other > > > transport encapsulations of packets using the NSH. This can be > > > illustrated by adding an additional line to the example of a > next-hop > > > SPI/SI-to-network overlay network locator mapping in Table 1 of > > > [RFC8300]: > > > > > > We probably should expand SPI and SI, since we haven't yet hit a > > > terminiology section or a note that (implies that) readers should be > > > familiar with the standard SFC terminology. > > > Also, Table 1 of RFC 8300 is labeled "SFF NSH Mapping Example"; it's > not > > > really clear that specifically that table is the best way to illustrate > > > how the MPLS encapsulation would work. > > > > > > > That table 1 extension was added to the draft as a result of the Routing > > Directorate review. Other than expanding the acronyms, I'll leave making > > any changes here up to Deborah. > > Okay. I doubt I'm really the target audience anyway... > > > > > > (side note) We use the strings "VPN" and "virtual private" here, which > > > in some contexts will cause an (uninformed) reader to assume that data > > > privacy (confidentiality) is involved; our uses do not seem to be for > > > cases that would involve such a confidentiality property. As a general > > > matter, not necessarily involving changes to this document, it may be > > > good to try to reserve these terms for cases where the confidentiality > > > is in fact provided, to help disambiguate the cases for the reader. > > > > > > > I take your point, but these are just examples of other uses of MPLS > > service labels. > > > > > > > Section 2.1 > > > > > > nit: s/The TTL For/The TTL for/ (twice) > > > > > > > Will fix. > > > > > > > > > > Section 3 > > > > > > For SFC, ECMP may or may not be desirable. To prevent ECMP when it > > > is not desired, the NSH Base Header was carefully constructed so > that > > > the NSH could not look like IPv4 or IPv6 based on its first nibble. > > > See Section 2.2 of [RFC8300] for further details. > > > > > > nit: this paragraph might flow better into the next one if we add a > note > > > that "Accordingly, the default behavior for MPLS-encapsulated SFC will > > > not use ECMP." > > > > > > > Good suggestion, will add. > > > > > > > > > > Section 6 > > > > > > However, it can be argued that carrying the NSH over MPLS is more > > > > > > re: "it can be argued" -- is this document attempting to make that > > > argument? > > > > > > > It could be argued that is the case! :-) > > I think that "arguably is more secure" would more directly represent such > a claim, but it is of course your call. > > > > > > secure than using other encapsulations, as it is extremely > difficult, > > > due to the MPLS architecture, for an attempted attacker to inject > > > > > > It's not entirely clear to me how much of this is the MPLS architecture > > > vs. implementation/deployment; I suppose to some extent it is true of > > > both. > > > > > > > IMHO, it really is a result of the architecture, and as a result, any > > implementation that properly follows the architecture. MPLS packets must > be > > created by a PE router, and downstream P routers will drop any incoming > > (I think the crux of what I'm "not clear" about is the source of this > "must". But it seems unlikely to be relevant to the present discussion, so > perhaps we should just drop this topic.) > > > MPLS packets from upstream P or PE routers that don't have a top-most > label > > that's in the router's LIB. So successfully injecting MPLS attack packets > > Just needing to know the label allocations that are valid for that router > is unlikely to inspire much confidence from security-area folks; given that > this is necessarily shared with several parties (i.e., at least everything > directly connected to that router) it's hard for us, in our mental model, > to be confident that it will remain secret and unguessable. (Also, > depending on their goal, an attacker may not need to know what a specific > label does, so if they just need to be able to guess *any* valid label, > their job gets easier.) > > > really does require insider access, and if you have that, there are so > many > > An N of 2**20 chance of success (per packet!) doesn't really mesh with > "requires insider access", given my present understanding. > > > other bad things you can do that are less expensive or difficult than > > trying to use an MPLS-based attack. > > Sure, but that doesn't always mean that we should completely ignore the > risk; the situation may not always be that way. > > > > > > > > > unexpected MPLS packets into a network, as MPLS networks do not by > > > design accept MPLS packets from external interfaces, and an attacker > > > > > > What about Inter-Carrier Interconnect? > > > > > > > MPLS ICI is really off-topic for this draft because the NSH is only used > in > > limited SFC domains that not only within a single domain (see RFC 8300), > > but within a well-defined sub-domain of that provider, such as within a > > data center. > > The specific text I quoted was supposedly talking about generic MPLS > networks, not restricted to sites using the NSH. The argument, as stated, > does not seem to hold up, given the ability of MPLS networks to use ICI to > accept external traffic (i.e., it is "within the design"). The specific > environments in which the NSH is intended to be used may well have a > different situation, but the current text does not reflect that different > situation, just from a purely rhetorical point of view. > > > That said, just to answer your question, carriers for the most part don't > > do MPLS across carrier boundaries, there's too much trust that would be > > required. That said, there are some examples of inter-carrier MPLS, most > > commonly using RFC 4364 option A, which really isn't an MPLS interface. > > There is an MPLS Forum document, > > > https://www.broadband-forum.org/technical/download/ipmpls/IPMPLSForum19.0.0.pdf > > , which discusses the various ways one can implement an MPLS ICI and the > > security implications of doing so, in section 13. > > (I couldn't find "option A" in RFC 4364, and the broadband-forum link gives > a 404 over here.) > > > > > > > > > would need knowledge of the specific labels allocated by control > and/ > > > or management plane protocols. Thus, an attacker attempting to > spoof > > > MPLS-encapsulated NSH packets would require insider knowledge of the > > > > > > An attacker in a position to inject traffic seems likely to also be > able > > > to observe legitimate traffic and correspondingly their valid label > > > values (if not necessarily the mapping from label to behavior). > > > > > > > Absolutely, As I said above, if you've got that much insider access, > there > > are much easier ways to screw up a network than play with MPLS packets. > > My point is that from a rhetorical point of view, this is a facile argument > -- the "requirement" would essentially always be met by anyone that meets > the preconditions from the first part of the sentence. > > > > > > > > > network's control and management planes and a way to inject packets > > > into internal interfaces. This is compared to, for example, NSH > over > > > UDP over IP, which could be injected into any external interface in > a > > > network that was not properly configured to filter out such packets > > > at the ingress. > > > > > > The NSH security considerations already (essentially) require this > > > filtering at ingress behavior; the practical question relevant here > > > seems to just be a matter of scale -- how hard it is to misconfigure > > > this filtering or how likely it is that the relevant filtering is > > > present as a consequence of factors external to SFC. > > > > > > > I think that's a question more for RFC 8300 than this draft. In terms of > > how hard it is to misconfigure filtering, that's really an implementation > > and deployment question. > > I guess I'm trying to say that the comparison doesn't feel particularly > compelling to me (given my (low) level of background knowledge) -- 8300 > requires this sort of filtering in all cases, whether MPLS or UDP or > otherwise. The expected MPLS deployment setup (or architecture, as you put > it) makes this happen essentially by default, but anything using the NSH is > supposed to do it. So, the comparison is not really about the encoding > per se, but rather around the risk/likelihood of noncompliant deployment, > but the current wording gives the impression that it's supposed to arise as > a natural consequence of the encoding (as opposed to the deployment > details). > > > Thanks again for your review. > > And thanks for your responses! Sorry for the slow reply. > > Benjamin > --000000000000be54d305848589d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Benjamin,

Thanks again= . I'm not sure why that BBF URL stopped working, but you can find the d= ocument here:


I'll check with them regarding fixing the= link going forward.

Regarding option a of=C2=A0RF= C 4364, see section 10 on p. 32. We've always referred to those as opti= ons a, b, and c.

Once I get the go-ahead from Debo= rah, I'll do an update on the draft.

Cheers,
Andy




On Tu= e, Mar 19, 2019 at 8:17 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
On Fri, Mar 15, 2019 at 11:05:59AM -0400, Andrew G. Malis = wrote:
> Benjamin,
>
> Thanks for your review and comments. See below inline.
>
> On Wed, Mar 13, 2019 at 10:13 PM Benjamin Kaduk via Datatracker < > noreply@ietf.org= > wrote:
>
> >
> > -----------------------------------------------------------------= -----
> > DISCUSS:
> > -----------------------------------------------------------------= -----
> >
> > Thanks for this clear and concise document!=C2=A0 I just have one= concern,
> > which will hopefully be easy to resolve (since there is a good ch= ance
> > that all the text necessary to do so is already written).
> >
> > As far as I can tell, the comment made by the secdir reviewer of<= br> > > draft-ietf-mpls-sfc-04 about circular references between that doc= ument
> > and RFCs 7665 and 8300 regarding security properties, is also som= ewhat
> > applicable to this document.=C2=A0 I do recognize the validity of= first
> > paragraph of the security considerations here (the NSH is an opaq= ue
> > payload for MPLS), but that in and of itself does not present a s= ecurity
> > analysis of the NSH in the MPLS environment.=C2=A0 The last parag= raph of the
> > security considerations of this document attempts to provide some=
> > analysis, but it seems to be incomplete and perhaps overly optimi= stic,
> > particularly with respect to the use of MPLS with Inter-Carrier > > Interconnect and the processing of MPLS traffic from external
> > interfaces.=C2=A0 Is there any reason not to fully harmonize (i.e= .,
> > synchronize) the security considerations of draft-ietf-mpls-sfc a= nd
> > draft-ietf-mpls-sfc-encapsulation?=C2=A0 (I guess the first parag= raph of this
> > document's security considerations doesn't apply to the o= ther document,
> > that allocates extended-special-purpose label values, but that= 9;s the
> > only thing I saw.)
> >
>
> Trying to keep this document in sync with draft-ietf-mpls-sfc was diff= icult
> because it was a moving target while this draft was being developed, a= nd of
> course, it was updated during IETF last call and IESG review following= the
> completion of this draft. And as you noted, there are some fundamental=
> differences between the two drafts. Because the other draft makes some=
> additions and changes to the MPLS label stack while this draft uses th= e
> MPLS label stack as designed and in wide practice, there's text in= the
> other draft that doesn't apply to this one, such as regarding the = use of
> MPLS to encode a logical representation of the NSH.

Other than things purely related to the specific encoding of the semantic content of the NSH, though, it seems that the security and privacy
considerations to conveying the information content of the NSH over MPLS transit should be essentially identical, regardless of how that semantic content is encoded.=C2=A0 Did you have in mind text in specifically the sec= urity
considerations of the other draft that doesn't apply to this one?=C2=A0= I made
a quick skim and didn't see anything that stuck out, but it was pretty<= br> quick.

> If you have any specific suggestions for improvement for the text here= ,
> that would be greatly appreciated! Also, does the IESG have any policy=

I suppose this may change given the response to my question above, but
given my comments in the COMMENT section on this document's security considerations, my initial specific suggestion would be to take the first paragraph from this document, strike the other three paragraphs, and
incorporate (whether inline or by reference) the full security
considerations from the other document.

(And to be clear, "initial" and "suggestion" are import= ant words here; I
don't intend to say this is the final word.)

> regarding direct copying of applicable text from one draft to another = in
> situations like this? Or perhaps we could just add a reference to

I don't know of a policy one way or the other...

> particular paragraphs in section 15 of draft-ietf-mpls-sfc? That would=
> remove the need to copy any text.

... but the reference seems like it should be sufficient, at least.

> I'll await your reply before taking any action.
>
>
> ----------------------------------------------------------------------=
> > COMMENT:
> > -----------------------------------------------------------------= -----
> >
> > Section 1
> >
> >=C2=A0 =C2=A0 This encapsulation is equivalent from an SFC perspec= tive to other
> >=C2=A0 =C2=A0 transport encapsulations of packets using the NSH.= =C2=A0 This can be
> >=C2=A0 =C2=A0 illustrated by adding an additional line to the exam= ple of a next-hop
> >=C2=A0 =C2=A0 SPI/SI-to-network overlay network locator mapping in= Table 1 of
> >=C2=A0 =C2=A0 [RFC8300]:
> >
> > We probably should expand SPI and SI, since we haven't yet hi= t a
> > terminiology section or a note that (implies that) readers should= be
> > familiar with the standard SFC terminology.
> > Also, Table 1 of RFC 8300 is labeled "SFF NSH Mapping Exampl= e"; it's not
> > really clear that specifically that table is the best way to illu= strate
> > how the MPLS encapsulation would work.
> >
>
>=C2=A0 That table 1 extension was added to the draft as a result of the= Routing
> Directorate review. Other than expanding the acronyms, I'll leave = making
> any changes here up to Deborah.

Okay.=C2=A0 I doubt I'm really the target audience anyway...

>
> > (side note) We use the strings "VPN" and "virtual = private" here, which
> > in some contexts will cause an (uninformed) reader to assume that= data
> > privacy (confidentiality) is involved; our uses do not seem to be= for
> > cases that would involve such a confidentiality property.=C2=A0 A= s a general
> > matter, not necessarily involving changes to this document, it ma= y be
> > good to try to reserve these terms for cases where the confidenti= ality
> > is in fact provided, to help disambiguate the cases for the reade= r.
> >
>
> I take your point, but these are just examples of other uses of MPLS > service labels.
>
>
> > Section 2.1
> >
> > nit: s/The TTL For/The TTL for/ (twice)
> >
>
> Will fix.
>
>
> >
> > Section 3
> >
> >=C2=A0 =C2=A0 For SFC, ECMP may or may not be desirable.=C2=A0 To = prevent ECMP when it
> >=C2=A0 =C2=A0 is not desired, the NSH Base Header was carefully co= nstructed so that
> >=C2=A0 =C2=A0 the NSH could not look like IPv4 or IPv6 based on it= s first nibble.
> >=C2=A0 =C2=A0 See Section 2.2 of [RFC8300] for further details. > >
> > nit: this paragraph might flow better into the next one if we add= a note
> > that "Accordingly, the default behavior for MPLS-encapsulate= d SFC will
> > not use ECMP."
> >
>
> Good suggestion, will add.
>
>
> >
> > Section 6
> >
> >=C2=A0 =C2=A0 However, it can be argued that carrying the NSH over= MPLS is more
> >
> > re: "it can be argued" -- is this document attempting t= o make that
> > argument?
> >
>
> It could be argued that is the case! :-)

I think that "arguably is more secure" would more directly repres= ent such
a claim, but it is of course your call.

>
> >=C2=A0 =C2=A0 secure than using other encapsulations, as it is ext= remely difficult,
> >=C2=A0 =C2=A0 due to the MPLS architecture, for an attempted attac= ker to inject
> >
> > It's not entirely clear to me how much of this is the MPLS ar= chitecture
> > vs. implementation/deployment; I suppose to some extent it is tru= e of
> > both.
> >
>
> IMHO, it really is a result of the architecture, and as a result, any<= br> > implementation that properly follows the architecture. MPLS packets mu= st be
> created by a PE router, and downstream P routers will drop any incomin= g

(I think the crux of what I'm "not clear" about is the source= of this
"must".=C2=A0 But it seems unlikely to be relevant to the present= discussion, so
perhaps we should just drop this topic.)

> MPLS packets from upstream P or PE routers that don't have a top-m= ost label
> that's in the router's LIB. So successfully injecting MPLS att= ack packets

Just needing to know the label allocations that are valid for that router is unlikely to inspire much confidence from security-area folks; given that=
this is necessarily shared with several parties (i.e., at least everything<= br> directly connected to that router) it's hard for us, in our mental mode= l,
to be confident that it will remain secret and unguessable.=C2=A0 (Also, depending on their goal, an attacker may not need to know what a specific label does, so if they just need to be able to guess *any* valid label,
their job gets easier.)

> really does require insider access, and if you have that, there are so= many

An N of 2**20 chance of success (per packet!) doesn't really mesh with<= br> "requires insider access", given my present understanding.

> other bad things you can do that are less expensive or difficult than<= br> > trying to use an MPLS-based attack.

Sure, but that doesn't always mean that we should completely ignore the=
risk; the situation may not always be that way.

>
> >
> >=C2=A0 =C2=A0 unexpected MPLS packets into a network, as MPLS netw= orks do not by
> >=C2=A0 =C2=A0 design accept MPLS packets from external interfaces,= and an attacker
> >
> > What about Inter-Carrier Interconnect?
> >
>
> MPLS ICI is really off-topic for this draft because the NSH is only us= ed in
> limited SFC domains that not only within a single domain (see RFC 8300= ),
> but within a well-defined sub-domain of that provider, such as within = a
> data center.

The specific text I quoted was supposedly talking about generic MPLS
networks, not restricted to sites using the NSH.=C2=A0 The argument, as sta= ted,
does not seem to hold up, given the ability of MPLS networks to use ICI to<= br> accept external traffic (i.e., it is "within the design").=C2=A0 = The specific
environments in which the NSH is intended to be used may well have a
different situation, but the current text does not reflect that different situation, just from a purely rhetorical point of view.

> That said, just to answer your question, carriers for the most part do= n't
> do MPLS across carrier boundaries, there's too much trust that wou= ld be
> required. That said, there are some examples of inter-carrier MPLS, mo= st
> commonly using RFC 4364 option A, which really isn't an MPLS inter= face.
> There is an MPLS Forum document,
> https://www.broa= dband-forum.org/technical/download/ipmpls/IPMPLSForum19.0.0.pdf
> , which discusses the various ways one can implement an MPLS ICI and t= he
> security implications of doing so, in section 13.

(I couldn't find "option A" in RFC 4364, and the broadband-fo= rum link gives
a 404 over here.)

>
> >
> >=C2=A0 =C2=A0 would need knowledge of the specific labels allocate= d by control and/
> >=C2=A0 =C2=A0 or management plane protocols.=C2=A0 Thus, an attack= er attempting to spoof
> >=C2=A0 =C2=A0 MPLS-encapsulated NSH packets would require insider = knowledge of the
> >
> > An attacker in a position to inject traffic seems likely to also = be able
> > to observe legitimate traffic and correspondingly their valid lab= el
> > values (if not necessarily the mapping from label to behavior). > >
>
> Absolutely, As I said above, if you've got that much insider acces= s, there
> are much easier ways to screw up a network than play with MPLS packets= .

My point is that from a rhetorical point of view, this is a facile argument=
-- the "requirement" would essentially always be met by anyone th= at meets
the preconditions from the first part of the sentence.

>
> >
> >=C2=A0 =C2=A0 network's control and management planes and a wa= y to inject packets
> >=C2=A0 =C2=A0 into internal interfaces.=C2=A0 This is compared to,= for example, NSH over
> >=C2=A0 =C2=A0 UDP over IP, which could be injected into any extern= al interface in a
> >=C2=A0 =C2=A0 network that was not properly configured to filter o= ut such packets
> >=C2=A0 =C2=A0 at the ingress.
> >
> > The NSH security considerations already (essentially) require thi= s
> > filtering at ingress behavior; the practical question relevant he= re
> > seems to just be a matter of scale -- how hard it is to misconfig= ure
> > this filtering or how likely it is that the relevant filtering is=
> > present as a consequence of factors external to SFC.
> >
>
> I think that's a question more for RFC 8300 than this draft. In te= rms of
> how hard it is to misconfigure filtering, that's really an impleme= ntation
> and deployment question.

I guess I'm trying to say that the comparison doesn't feel particul= arly
compelling to me (given my (low) level of background knowledge) -- 8300
requires this sort of filtering in all cases, whether MPLS or UDP or
otherwise.=C2=A0 The expected MPLS deployment setup (or architecture, as yo= u put
it) makes this happen essentially by default, but anything using the NSH is=
supposed to do it.=C2=A0 So, the comparison is not really about the encodin= g
per se, but rather around the risk/likelihood of noncompliant deployment, but the current wording gives the impression that it's supposed to aris= e as
a natural consequence of the encoding (as opposed to the deployment
details).

> Thanks again for your review.

And thanks for your responses!=C2=A0 Sorry for the slow reply.

Benjamin
--000000000000be54d305848589d9-- From nobody Wed Mar 20 07:57:29 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95F4129A4B; Wed, 20 Mar 2019 07:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, 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 qtzkuNK-sVuk; Wed, 20 Mar 2019 07:57:22 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 921771310AB; Wed, 20 Mar 2019 07:57:21 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id x12so2834006qts.7; Wed, 20 Mar 2019 07:57:21 -0700 (PDT) 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=P4d6J+UPPOrwoW2ZqDCOqXyWMbjF+fo8t6W/R6RACts=; b=jxz0YQHVCGX9QRX90YokZi9ZCrrRl4VrtbYVqhqRfghv3KH/7fE+9o810PnX996TcY +sml5eTKlWM+kSBMA6q1HqkBZVJVguqL5ZSFBO7eU5+vyrQGSAkA7DG4zGl0U4g6MjZY RblpAnHnQm5x77z/nsDIyBnI8NjbzmSmVa2q5YYdppLdaR+yrOpKO/hJY8FQSxfCdCA7 hmsaMWD1hTLq7A6O2OYaEFPnKQqe7mYTC+NDfthDyW6YN467Xs9pqgX4Y/R/74FOgq+/ k03aOl7MLCtH/bgC+7HD49Vnb+l4O6b2t3VUZVpML/XMmx92Fzoevf2ZgvEKnKXMwDC2 qiXg== 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=P4d6J+UPPOrwoW2ZqDCOqXyWMbjF+fo8t6W/R6RACts=; b=td+BHM3WIdATRrw1yW/qHRd2jDQaxqyO2L0mkxNbR1kEiLIp1liABzDn6FOcVOeLue OtwurMr6QDryrtk9RQUYvLydR5howuOpMvskkz41P2eML6QZRKfiJtTjS4oBJulEKCZv 6rPWRw2ZAC42U8jgZvH9ds0xmsPITfD4QTN5Qa+laCv1cI3P+JV5//5+xQH76+UjYfOr 4jwxatVUn8e1M+7zjc4np2rpKwuJX8qJpTDIQ5jVVoqkj5/mU+W4MTo1B36/2wxWnc1N 2jH/KaL1vuJD9KxJSLB080CIreXdYTwLh71I05DW4GvpEdkE2GkwATSIMpf5MTuREtmD bzyQ== X-Gm-Message-State: APjAAAVqF6LPE3hSp4xqr8oEXff08IOxInInq1GBELYtzznLJrchoUK3 EZjavu5AjkletosuHEESJZXMo1olcAoCl0KLRMPURUeahRg= X-Google-Smtp-Source: APXvYqwyn9dARQocRk6/VPg0vjPmvT/j9Cp//nsASllWBk2wkqnP7QnHd3/zp4Fls7BVz0em9S1rmW3XYORok3JAoVY= X-Received: by 2002:a0c:9319:: with SMTP id d25mr6775795qvd.99.1553093840504; Wed, 20 Mar 2019 07:57:20 -0700 (PDT) MIME-Version: 1.0 References: <155252958505.24865.4180223375091950120.idtracker@ietfa.amsl.com> <20190320001751.GS80498@kduck.mit.edu> In-Reply-To: From: "Andrew G. Malis" Date: Wed, 20 Mar 2019 10:57:09 -0400 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-mpls-sfc-encapsulation@ietf.org, Loa Andersson , mpls-chairs , mpls Content-Type: multipart/alternative; boundary="000000000000aa8d20058487d614" Archived-At: Subject: Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-sfc-encapsulation-03: (with DISCUSS and COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 14:57:28 -0000 --000000000000aa8d20058487d614 Content-Type: text/plain; charset="UTF-8" It turns out that the BBF recently reorganized their website. The new URL is https://www.broadband-forum.org/wp-content/uploads/2018/12/IPMPLSForum19.0.0.pdf . Cheers, Andy On Wed, Mar 20, 2019 at 8:12 AM Andrew G. Malis wrote: > Benjamin, > > Thanks again. I'm not sure why that BBF URL stopped working, but you can > find the document here: > > > https://web.archive.org/web/20160426184514/https://www.broadband-forum.org/technical/download/ipmpls/IPMPLSForum19.0.0.pdf > > I'll check with them regarding fixing the link going forward. > > Regarding option a of RFC 4364, see section 10 on p. 32. We've always > referred to those as options a, b, and c. > > Once I get the go-ahead from Deborah, I'll do an update on the draft. > > Cheers, > Andy > > > > > On Tue, Mar 19, 2019 at 8:17 PM Benjamin Kaduk wrote: > >> On Fri, Mar 15, 2019 at 11:05:59AM -0400, Andrew G. Malis wrote: >> > Benjamin, >> > >> > Thanks for your review and comments. See below inline. >> > >> > On Wed, Mar 13, 2019 at 10:13 PM Benjamin Kaduk via Datatracker < >> > noreply@ietf.org> wrote: >> > >> > > >> > > ---------------------------------------------------------------------- >> > > DISCUSS: >> > > ---------------------------------------------------------------------- >> > > >> > > Thanks for this clear and concise document! I just have one concern, >> > > which will hopefully be easy to resolve (since there is a good chance >> > > that all the text necessary to do so is already written). >> > > >> > > As far as I can tell, the comment made by the secdir reviewer of >> > > draft-ietf-mpls-sfc-04 about circular references between that document >> > > and RFCs 7665 and 8300 regarding security properties, is also somewhat >> > > applicable to this document. I do recognize the validity of first >> > > paragraph of the security considerations here (the NSH is an opaque >> > > payload for MPLS), but that in and of itself does not present a >> security >> > > analysis of the NSH in the MPLS environment. The last paragraph of >> the >> > > security considerations of this document attempts to provide some >> > > analysis, but it seems to be incomplete and perhaps overly optimistic, >> > > particularly with respect to the use of MPLS with Inter-Carrier >> > > Interconnect and the processing of MPLS traffic from external >> > > interfaces. Is there any reason not to fully harmonize (i.e., >> > > synchronize) the security considerations of draft-ietf-mpls-sfc and >> > > draft-ietf-mpls-sfc-encapsulation? (I guess the first paragraph of >> this >> > > document's security considerations doesn't apply to the other >> document, >> > > that allocates extended-special-purpose label values, but that's the >> > > only thing I saw.) >> > > >> > >> > Trying to keep this document in sync with draft-ietf-mpls-sfc was >> difficult >> > because it was a moving target while this draft was being developed, >> and of >> > course, it was updated during IETF last call and IESG review following >> the >> > completion of this draft. And as you noted, there are some fundamental >> > differences between the two drafts. Because the other draft makes some >> > additions and changes to the MPLS label stack while this draft uses the >> > MPLS label stack as designed and in wide practice, there's text in the >> > other draft that doesn't apply to this one, such as regarding the use of >> > MPLS to encode a logical representation of the NSH. >> >> Other than things purely related to the specific encoding of the semantic >> content of the NSH, though, it seems that the security and privacy >> considerations to conveying the information content of the NSH over MPLS >> transit should be essentially identical, regardless of how that semantic >> content is encoded. Did you have in mind text in specifically the >> security >> considerations of the other draft that doesn't apply to this one? I made >> a quick skim and didn't see anything that stuck out, but it was pretty >> quick. >> >> > If you have any specific suggestions for improvement for the text here, >> > that would be greatly appreciated! Also, does the IESG have any policy >> >> I suppose this may change given the response to my question above, but >> given my comments in the COMMENT section on this document's security >> considerations, my initial specific suggestion would be to take the first >> paragraph from this document, strike the other three paragraphs, and >> incorporate (whether inline or by reference) the full security >> considerations from the other document. >> >> (And to be clear, "initial" and "suggestion" are important words here; I >> don't intend to say this is the final word.) >> >> > regarding direct copying of applicable text from one draft to another in >> > situations like this? Or perhaps we could just add a reference to >> >> I don't know of a policy one way or the other... >> >> > particular paragraphs in section 15 of draft-ietf-mpls-sfc? That would >> > remove the need to copy any text. >> >> ... but the reference seems like it should be sufficient, at least. >> >> > I'll await your reply before taking any action. >> > >> > >> > ---------------------------------------------------------------------- >> > > COMMENT: >> > > ---------------------------------------------------------------------- >> > > >> > > Section 1 >> > > >> > > This encapsulation is equivalent from an SFC perspective to other >> > > transport encapsulations of packets using the NSH. This can be >> > > illustrated by adding an additional line to the example of a >> next-hop >> > > SPI/SI-to-network overlay network locator mapping in Table 1 of >> > > [RFC8300]: >> > > >> > > We probably should expand SPI and SI, since we haven't yet hit a >> > > terminiology section or a note that (implies that) readers should be >> > > familiar with the standard SFC terminology. >> > > Also, Table 1 of RFC 8300 is labeled "SFF NSH Mapping Example"; it's >> not >> > > really clear that specifically that table is the best way to >> illustrate >> > > how the MPLS encapsulation would work. >> > > >> > >> > That table 1 extension was added to the draft as a result of the >> Routing >> > Directorate review. Other than expanding the acronyms, I'll leave making >> > any changes here up to Deborah. >> >> Okay. I doubt I'm really the target audience anyway... >> >> > >> > > (side note) We use the strings "VPN" and "virtual private" here, which >> > > in some contexts will cause an (uninformed) reader to assume that data >> > > privacy (confidentiality) is involved; our uses do not seem to be for >> > > cases that would involve such a confidentiality property. As a >> general >> > > matter, not necessarily involving changes to this document, it may be >> > > good to try to reserve these terms for cases where the confidentiality >> > > is in fact provided, to help disambiguate the cases for the reader. >> > > >> > >> > I take your point, but these are just examples of other uses of MPLS >> > service labels. >> > >> > >> > > Section 2.1 >> > > >> > > nit: s/The TTL For/The TTL for/ (twice) >> > > >> > >> > Will fix. >> > >> > >> > > >> > > Section 3 >> > > >> > > For SFC, ECMP may or may not be desirable. To prevent ECMP when it >> > > is not desired, the NSH Base Header was carefully constructed so >> that >> > > the NSH could not look like IPv4 or IPv6 based on its first nibble. >> > > See Section 2.2 of [RFC8300] for further details. >> > > >> > > nit: this paragraph might flow better into the next one if we add a >> note >> > > that "Accordingly, the default behavior for MPLS-encapsulated SFC will >> > > not use ECMP." >> > > >> > >> > Good suggestion, will add. >> > >> > >> > > >> > > Section 6 >> > > >> > > However, it can be argued that carrying the NSH over MPLS is more >> > > >> > > re: "it can be argued" -- is this document attempting to make that >> > > argument? >> > > >> > >> > It could be argued that is the case! :-) >> >> I think that "arguably is more secure" would more directly represent such >> a claim, but it is of course your call. >> >> > >> > > secure than using other encapsulations, as it is extremely >> difficult, >> > > due to the MPLS architecture, for an attempted attacker to inject >> > > >> > > It's not entirely clear to me how much of this is the MPLS >> architecture >> > > vs. implementation/deployment; I suppose to some extent it is true of >> > > both. >> > > >> > >> > IMHO, it really is a result of the architecture, and as a result, any >> > implementation that properly follows the architecture. MPLS packets >> must be >> > created by a PE router, and downstream P routers will drop any incoming >> >> (I think the crux of what I'm "not clear" about is the source of this >> "must". But it seems unlikely to be relevant to the present discussion, >> so >> perhaps we should just drop this topic.) >> >> > MPLS packets from upstream P or PE routers that don't have a top-most >> label >> > that's in the router's LIB. So successfully injecting MPLS attack >> packets >> >> Just needing to know the label allocations that are valid for that router >> is unlikely to inspire much confidence from security-area folks; given >> that >> this is necessarily shared with several parties (i.e., at least everything >> directly connected to that router) it's hard for us, in our mental model, >> to be confident that it will remain secret and unguessable. (Also, >> depending on their goal, an attacker may not need to know what a specific >> label does, so if they just need to be able to guess *any* valid label, >> their job gets easier.) >> >> > really does require insider access, and if you have that, there are so >> many >> >> An N of 2**20 chance of success (per packet!) doesn't really mesh with >> "requires insider access", given my present understanding. >> >> > other bad things you can do that are less expensive or difficult than >> > trying to use an MPLS-based attack. >> >> Sure, but that doesn't always mean that we should completely ignore the >> risk; the situation may not always be that way. >> >> > >> > > >> > > unexpected MPLS packets into a network, as MPLS networks do not by >> > > design accept MPLS packets from external interfaces, and an >> attacker >> > > >> > > What about Inter-Carrier Interconnect? >> > > >> > >> > MPLS ICI is really off-topic for this draft because the NSH is only >> used in >> > limited SFC domains that not only within a single domain (see RFC 8300), >> > but within a well-defined sub-domain of that provider, such as within a >> > data center. >> >> The specific text I quoted was supposedly talking about generic MPLS >> networks, not restricted to sites using the NSH. The argument, as stated, >> does not seem to hold up, given the ability of MPLS networks to use ICI to >> accept external traffic (i.e., it is "within the design"). The specific >> environments in which the NSH is intended to be used may well have a >> different situation, but the current text does not reflect that different >> situation, just from a purely rhetorical point of view. >> >> > That said, just to answer your question, carriers for the most part >> don't >> > do MPLS across carrier boundaries, there's too much trust that would be >> > required. That said, there are some examples of inter-carrier MPLS, most >> > commonly using RFC 4364 option A, which really isn't an MPLS interface. >> > There is an MPLS Forum document, >> > >> https://www.broadband-forum.org/technical/download/ipmpls/IPMPLSForum19.0.0.pdf >> > , which discusses the various ways one can implement an MPLS ICI and the >> > security implications of doing so, in section 13. >> >> (I couldn't find "option A" in RFC 4364, and the broadband-forum link >> gives >> a 404 over here.) >> >> > >> > > >> > > would need knowledge of the specific labels allocated by control >> and/ >> > > or management plane protocols. Thus, an attacker attempting to >> spoof >> > > MPLS-encapsulated NSH packets would require insider knowledge of >> the >> > > >> > > An attacker in a position to inject traffic seems likely to also be >> able >> > > to observe legitimate traffic and correspondingly their valid label >> > > values (if not necessarily the mapping from label to behavior). >> > > >> > >> > Absolutely, As I said above, if you've got that much insider access, >> there >> > are much easier ways to screw up a network than play with MPLS packets. >> >> My point is that from a rhetorical point of view, this is a facile >> argument >> -- the "requirement" would essentially always be met by anyone that meets >> the preconditions from the first part of the sentence. >> >> > >> > > >> > > network's control and management planes and a way to inject packets >> > > into internal interfaces. This is compared to, for example, NSH >> over >> > > UDP over IP, which could be injected into any external interface >> in a >> > > network that was not properly configured to filter out such packets >> > > at the ingress. >> > > >> > > The NSH security considerations already (essentially) require this >> > > filtering at ingress behavior; the practical question relevant here >> > > seems to just be a matter of scale -- how hard it is to misconfigure >> > > this filtering or how likely it is that the relevant filtering is >> > > present as a consequence of factors external to SFC. >> > > >> > >> > I think that's a question more for RFC 8300 than this draft. In terms of >> > how hard it is to misconfigure filtering, that's really an >> implementation >> > and deployment question. >> >> I guess I'm trying to say that the comparison doesn't feel particularly >> compelling to me (given my (low) level of background knowledge) -- 8300 >> requires this sort of filtering in all cases, whether MPLS or UDP or >> otherwise. The expected MPLS deployment setup (or architecture, as you >> put >> it) makes this happen essentially by default, but anything using the NSH >> is >> supposed to do it. So, the comparison is not really about the encoding >> per se, but rather around the risk/likelihood of noncompliant deployment, >> but the current wording gives the impression that it's supposed to arise >> as >> a natural consequence of the encoding (as opposed to the deployment >> details). >> >> > Thanks again for your review. >> >> And thanks for your responses! Sorry for the slow reply. >> >> Benjamin >> > --000000000000aa8d20058487d614 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It turns out that the BBF recently reorga= nized their website. The new URL is=C2=A0https://www.broa= dband-forum.org/wp-content/uploads/2018/12/IPMPLSForum19.0.0.pdf .

Cheers,
Andy




On Wed, Mar 20, 2019= at 8:12 AM Andrew G. Malis <agmali= s@gmail.com> wrote:
Benjamin,

T= hanks again. I'm not sure why that BBF URL stopped working, but you can= find the document here:


I'll check w= ith them regarding fixing the link going forward.

= Regarding option a of=C2=A0RFC 4364, see section 10 on p. 32. We've alw= ays referred to those as options a, b, and c.

Once= I get the go-ahead from Deborah, I'll do an update on the draft.
=

Cheers,
Andy




On Tue, Mar 19, 2019 at 8:17 PM Benjamin Kaduk <= kaduk@mit.edu> wr= ote:
On Fri, Mar= 15, 2019 at 11:05:59AM -0400, Andrew G. Malis wrote:
> Benjamin,
>
> Thanks for your review and comments. See below inline.
>
> On Wed, Mar 13, 2019 at 10:13 PM Benjamin Kaduk via Datatracker < > noreply@ietf.org= > wrote:
>
> >
> > -----------------------------------------------------------------= -----
> > DISCUSS:
> > -----------------------------------------------------------------= -----
> >
> > Thanks for this clear and concise document!=C2=A0 I just have one= concern,
> > which will hopefully be easy to resolve (since there is a good ch= ance
> > that all the text necessary to do so is already written).
> >
> > As far as I can tell, the comment made by the secdir reviewer of<= br> > > draft-ietf-mpls-sfc-04 about circular references between that doc= ument
> > and RFCs 7665 and 8300 regarding security properties, is also som= ewhat
> > applicable to this document.=C2=A0 I do recognize the validity of= first
> > paragraph of the security considerations here (the NSH is an opaq= ue
> > payload for MPLS), but that in and of itself does not present a s= ecurity
> > analysis of the NSH in the MPLS environment.=C2=A0 The last parag= raph of the
> > security considerations of this document attempts to provide some=
> > analysis, but it seems to be incomplete and perhaps overly optimi= stic,
> > particularly with respect to the use of MPLS with Inter-Carrier > > Interconnect and the processing of MPLS traffic from external
> > interfaces.=C2=A0 Is there any reason not to fully harmonize (i.e= .,
> > synchronize) the security considerations of draft-ietf-mpls-sfc a= nd
> > draft-ietf-mpls-sfc-encapsulation?=C2=A0 (I guess the first parag= raph of this
> > document's security considerations doesn't apply to the o= ther document,
> > that allocates extended-special-purpose label values, but that= 9;s the
> > only thing I saw.)
> >
>
> Trying to keep this document in sync with draft-ietf-mpls-sfc was diff= icult
> because it was a moving target while this draft was being developed, a= nd of
> course, it was updated during IETF last call and IESG review following= the
> completion of this draft. And as you noted, there are some fundamental=
> differences between the two drafts. Because the other draft makes some=
> additions and changes to the MPLS label stack while this draft uses th= e
> MPLS label stack as designed and in wide practice, there's text in= the
> other draft that doesn't apply to this one, such as regarding the = use of
> MPLS to encode a logical representation of the NSH.

Other than things purely related to the specific encoding of the semantic content of the NSH, though, it seems that the security and privacy
considerations to conveying the information content of the NSH over MPLS transit should be essentially identical, regardless of how that semantic content is encoded.=C2=A0 Did you have in mind text in specifically the sec= urity
considerations of the other draft that doesn't apply to this one?=C2=A0= I made
a quick skim and didn't see anything that stuck out, but it was pretty<= br> quick.

> If you have any specific suggestions for improvement for the text here= ,
> that would be greatly appreciated! Also, does the IESG have any policy=

I suppose this may change given the response to my question above, but
given my comments in the COMMENT section on this document's security considerations, my initial specific suggestion would be to take the first paragraph from this document, strike the other three paragraphs, and
incorporate (whether inline or by reference) the full security
considerations from the other document.

(And to be clear, "initial" and "suggestion" are import= ant words here; I
don't intend to say this is the final word.)

> regarding direct copying of applicable text from one draft to another = in
> situations like this? Or perhaps we could just add a reference to

I don't know of a policy one way or the other...

> particular paragraphs in section 15 of draft-ietf-mpls-sfc? That would=
> remove the need to copy any text.

... but the reference seems like it should be sufficient, at least.

> I'll await your reply before taking any action.
>
>
> ----------------------------------------------------------------------=
> > COMMENT:
> > -----------------------------------------------------------------= -----
> >
> > Section 1
> >
> >=C2=A0 =C2=A0 This encapsulation is equivalent from an SFC perspec= tive to other
> >=C2=A0 =C2=A0 transport encapsulations of packets using the NSH.= =C2=A0 This can be
> >=C2=A0 =C2=A0 illustrated by adding an additional line to the exam= ple of a next-hop
> >=C2=A0 =C2=A0 SPI/SI-to-network overlay network locator mapping in= Table 1 of
> >=C2=A0 =C2=A0 [RFC8300]:
> >
> > We probably should expand SPI and SI, since we haven't yet hi= t a
> > terminiology section or a note that (implies that) readers should= be
> > familiar with the standard SFC terminology.
> > Also, Table 1 of RFC 8300 is labeled "SFF NSH Mapping Exampl= e"; it's not
> > really clear that specifically that table is the best way to illu= strate
> > how the MPLS encapsulation would work.
> >
>
>=C2=A0 That table 1 extension was added to the draft as a result of the= Routing
> Directorate review. Other than expanding the acronyms, I'll leave = making
> any changes here up to Deborah.

Okay.=C2=A0 I doubt I'm really the target audience anyway...

>
> > (side note) We use the strings "VPN" and "virtual = private" here, which
> > in some contexts will cause an (uninformed) reader to assume that= data
> > privacy (confidentiality) is involved; our uses do not seem to be= for
> > cases that would involve such a confidentiality property.=C2=A0 A= s a general
> > matter, not necessarily involving changes to this document, it ma= y be
> > good to try to reserve these terms for cases where the confidenti= ality
> > is in fact provided, to help disambiguate the cases for the reade= r.
> >
>
> I take your point, but these are just examples of other uses of MPLS > service labels.
>
>
> > Section 2.1
> >
> > nit: s/The TTL For/The TTL for/ (twice)
> >
>
> Will fix.
>
>
> >
> > Section 3
> >
> >=C2=A0 =C2=A0 For SFC, ECMP may or may not be desirable.=C2=A0 To = prevent ECMP when it
> >=C2=A0 =C2=A0 is not desired, the NSH Base Header was carefully co= nstructed so that
> >=C2=A0 =C2=A0 the NSH could not look like IPv4 or IPv6 based on it= s first nibble.
> >=C2=A0 =C2=A0 See Section 2.2 of [RFC8300] for further details. > >
> > nit: this paragraph might flow better into the next one if we add= a note
> > that "Accordingly, the default behavior for MPLS-encapsulate= d SFC will
> > not use ECMP."
> >
>
> Good suggestion, will add.
>
>
> >
> > Section 6
> >
> >=C2=A0 =C2=A0 However, it can be argued that carrying the NSH over= MPLS is more
> >
> > re: "it can be argued" -- is this document attempting t= o make that
> > argument?
> >
>
> It could be argued that is the case! :-)

I think that "arguably is more secure" would more directly repres= ent such
a claim, but it is of course your call.

>
> >=C2=A0 =C2=A0 secure than using other encapsulations, as it is ext= remely difficult,
> >=C2=A0 =C2=A0 due to the MPLS architecture, for an attempted attac= ker to inject
> >
> > It's not entirely clear to me how much of this is the MPLS ar= chitecture
> > vs. implementation/deployment; I suppose to some extent it is tru= e of
> > both.
> >
>
> IMHO, it really is a result of the architecture, and as a result, any<= br> > implementation that properly follows the architecture. MPLS packets mu= st be
> created by a PE router, and downstream P routers will drop any incomin= g

(I think the crux of what I'm "not clear" about is the source= of this
"must".=C2=A0 But it seems unlikely to be relevant to the present= discussion, so
perhaps we should just drop this topic.)

> MPLS packets from upstream P or PE routers that don't have a top-m= ost label
> that's in the router's LIB. So successfully injecting MPLS att= ack packets

Just needing to know the label allocations that are valid for that router is unlikely to inspire much confidence from security-area folks; given that=
this is necessarily shared with several parties (i.e., at least everything<= br> directly connected to that router) it's hard for us, in our mental mode= l,
to be confident that it will remain secret and unguessable.=C2=A0 (Also, depending on their goal, an attacker may not need to know what a specific label does, so if they just need to be able to guess *any* valid label,
their job gets easier.)

> really does require insider access, and if you have that, there are so= many

An N of 2**20 chance of success (per packet!) doesn't really mesh with<= br> "requires insider access", given my present understanding.

> other bad things you can do that are less expensive or difficult than<= br> > trying to use an MPLS-based attack.

Sure, but that doesn't always mean that we should completely ignore the=
risk; the situation may not always be that way.

>
> >
> >=C2=A0 =C2=A0 unexpected MPLS packets into a network, as MPLS netw= orks do not by
> >=C2=A0 =C2=A0 design accept MPLS packets from external interfaces,= and an attacker
> >
> > What about Inter-Carrier Interconnect?
> >
>
> MPLS ICI is really off-topic for this draft because the NSH is only us= ed in
> limited SFC domains that not only within a single domain (see RFC 8300= ),
> but within a well-defined sub-domain of that provider, such as within = a
> data center.

The specific text I quoted was supposedly talking about generic MPLS
networks, not restricted to sites using the NSH.=C2=A0 The argument, as sta= ted,
does not seem to hold up, given the ability of MPLS networks to use ICI to<= br> accept external traffic (i.e., it is "within the design").=C2=A0 = The specific
environments in which the NSH is intended to be used may well have a
different situation, but the current text does not reflect that different situation, just from a purely rhetorical point of view.

> That said, just to answer your question, carriers for the most part do= n't
> do MPLS across carrier boundaries, there's too much trust that wou= ld be
> required. That said, there are some examples of inter-carrier MPLS, mo= st
> commonly using RFC 4364 option A, which really isn't an MPLS inter= face.
> There is an MPLS Forum document,
> https://www.broa= dband-forum.org/technical/download/ipmpls/IPMPLSForum19.0.0.pdf
> , which discusses the various ways one can implement an MPLS ICI and t= he
> security implications of doing so, in section 13.

(I couldn't find "option A" in RFC 4364, and the broadband-fo= rum link gives
a 404 over here.)

>
> >
> >=C2=A0 =C2=A0 would need knowledge of the specific labels allocate= d by control and/
> >=C2=A0 =C2=A0 or management plane protocols.=C2=A0 Thus, an attack= er attempting to spoof
> >=C2=A0 =C2=A0 MPLS-encapsulated NSH packets would require insider = knowledge of the
> >
> > An attacker in a position to inject traffic seems likely to also = be able
> > to observe legitimate traffic and correspondingly their valid lab= el
> > values (if not necessarily the mapping from label to behavior). > >
>
> Absolutely, As I said above, if you've got that much insider acces= s, there
> are much easier ways to screw up a network than play with MPLS packets= .

My point is that from a rhetorical point of view, this is a facile argument=
-- the "requirement" would essentially always be met by anyone th= at meets
the preconditions from the first part of the sentence.

>
> >
> >=C2=A0 =C2=A0 network's control and management planes and a wa= y to inject packets
> >=C2=A0 =C2=A0 into internal interfaces.=C2=A0 This is compared to,= for example, NSH over
> >=C2=A0 =C2=A0 UDP over IP, which could be injected into any extern= al interface in a
> >=C2=A0 =C2=A0 network that was not properly configured to filter o= ut such packets
> >=C2=A0 =C2=A0 at the ingress.
> >
> > The NSH security considerations already (essentially) require thi= s
> > filtering at ingress behavior; the practical question relevant he= re
> > seems to just be a matter of scale -- how hard it is to misconfig= ure
> > this filtering or how likely it is that the relevant filtering is=
> > present as a consequence of factors external to SFC.
> >
>
> I think that's a question more for RFC 8300 than this draft. In te= rms of
> how hard it is to misconfigure filtering, that's really an impleme= ntation
> and deployment question.

I guess I'm trying to say that the comparison doesn't feel particul= arly
compelling to me (given my (low) level of background knowledge) -- 8300
requires this sort of filtering in all cases, whether MPLS or UDP or
otherwise.=C2=A0 The expected MPLS deployment setup (or architecture, as yo= u put
it) makes this happen essentially by default, but anything using the NSH is=
supposed to do it.=C2=A0 So, the comparison is not really about the encodin= g
per se, but rather around the risk/likelihood of noncompliant deployment, but the current wording gives the impression that it's supposed to aris= e as
a natural consequence of the encoding (as opposed to the deployment
details).

> Thanks again for your review.

And thanks for your responses!=C2=A0 Sorry for the slow reply.

Benjamin
--000000000000aa8d20058487d614-- From nobody Wed Mar 20 09:19:36 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846D612AF7F for ; Wed, 20 Mar 2019 09:19:35 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 (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 rWBKzuP1aImR for ; Wed, 20 Mar 2019 09:19:33 -0700 (PDT) Received: from mail-it1-x12c.google.com (mail-it1-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 D2945127598 for ; Wed, 20 Mar 2019 09:19:32 -0700 (PDT) Received: by mail-it1-x12c.google.com with SMTP id e24so32410803itl.1 for ; Wed, 20 Mar 2019 09:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=CfjVAM3cTi8G0TZOD19cGG0mDe6DZStF6jWWW1irDBU=; b=n3ut8/EGGTGgEtFejPvaOo3L1iTwJc0mmoqFkW+sSx4zs3ZRtezZDQwwgrCSViOmu9 FVHYH2YQbzVVmBp5pSirmzT0xjoij3IA8nvQFBvbDbsyNNMtz5weYkD+mD6uUICplUIV BHs9QPB03OFOHGXu9doIZdOpqi3gU90zV+Dvy3YVbWNSqlMRnXeMprEjuNs8iWf5TYJP 8rBrkmHtVUOueVGH1jNlXfM1R44p/IPnGdNsTf5LDjchJG4Ei1CuQwAzkbGvb1WBTQSX Ahtl3hqH/pp3Tj2jx9exCoembCkSoNLIoY6+krBAPaIFteFoDEdHgtL2XbMO1r/mwz64 R3IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=CfjVAM3cTi8G0TZOD19cGG0mDe6DZStF6jWWW1irDBU=; b=hMuaWHiNG1wiAt0Qu80TuMihBfOiJE6MeU6HXN01fx/poji0gXgjHo7I5wjFV3zTWv 4oXpXWS8F7rJhPNIlj9FKnbcsHYV8LYksQn66KIEb/LECutvwtezLC6c4Z/3C5mkHpC/ I2sbYTyaqKMpge8htMD3/DSESiBsbpB6R55gjTob5ESC4rs/+f9DZV3mnA82ONHeGblx TMaLAZ0PB1WB7NTXID76w4SN77KDEP56tBnY7ItSSqw2af+fNpkU2CghSEZ/6M4SqWmU HXeL67h0DFbxQokOVzwjvRw6qMpbXhxYInUviSwomUnjXciqllHyZLUrgXh71znNMg0T cetg== X-Gm-Message-State: APjAAAWc6ipJ0TSG+SUy+kq7wn1c9ciFNoEebGZD22eMEwEwzIAxtx/D Rx/RyzSXufV02x+/c8bU/pk= X-Google-Smtp-Source: APXvYqxlf6PPsTq1wZiRSiJD1oe/eZI5A58k06fX4JAOU4m2GZcovc/gmhvTXz0E/iJoygYMYDxP7w== X-Received: by 2002:a24:4741:: with SMTP id t62mr5386607itb.110.1553098772138; Wed, 20 Mar 2019 09:19:32 -0700 (PDT) Received: from BN8PR06MB6289.namprd06.prod.outlook.com ([52.96.29.13]) by smtp.gmail.com with ESMTPSA id v16sm1055024itc.7.2019.03.20.09.19.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Mar 2019 09:19:31 -0700 (PDT) From: Tarek Saad To: tom petch CC: "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-static-yang-08.txt Thread-Index: ATAxNDQ2i0LOojKGVyarzaBWsO/NHTAwMTkxd0pWZXMwMDQzMTAxNDQ2MDZEQzYwMDY5Mb4Z9af2 X-MS-Exchange-MessageSentRepresentingType: 1 Date: Wed, 20 Mar 2019 16:19:30 +0000 Message-ID: References: <155155736768.27158.1653954565392604255@ietfa.amsl.com> <016901d4d379$a1e91e60$4001a8c0@gateway.2wire.net> <068601d4d4e3$c5dc4980$4001a8c0@gateway.2wire.net> <034601d4de79$44f06000$4001a8c0@gateway.2wire.net> In-Reply-To: <034601d4de79$44f06000$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] I-D Action: draft-ietf-mpls-static-yang-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 16:19:36 -0000 SGkgVG9tLA0KDQpUaGFua3MgZm9yIHRoZSBmZWVkYmFjayAoYXMgdXN1YWwpLiBTZWUgaW5saW5l Li4NCg0K77u/T24gMy8xOS8xOSwgMTozMSBQTSwgInRvbSBwZXRjaCIgPGlldGZjQGJ0Y29ubmVj dC5jb20+IHdyb3RlOg0KDQogICAgLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQogICAgRnJv bTogIlRhcmVrIFNhYWQiIDx0c2FhZC5uZXRAZ21haWwuY29tPg0KICAgIFNlbnQ6IEZyaWRheSwg TWFyY2ggMDgsIDIwMTkgNzoxMyBQTQ0KICAgIA0KICAgID4gVGhhbmtzIFRvbS4gVGhlIGNvbW1l bnRzIGFyZSBhZGRyZXNzZWQgaW4gdmVyc2lvbiAtMDk6DQogICAgPiBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tcGxzLXN0YXRpYy15YW5nLTA5DQogICAgPg0KICAgID4g QW5kIGRpZmY6DQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aWV0Zi1tcGxzLXN0YXRpYy15YW5nLTA5DQogICAgDQogICAgSW5kZWVkIHRoZXkgYXJlLiAgVHdv IG1vcmUgdGVjaG5pY2FsIHRob3VnaHRzDQogICAgDQogICAgSUFOQSBDb25zaWRlcmF0aW9ucyBo YXMNCiAgICANCiAgICAgICAgICBwcmVmaXg6ICAgICBpZXRmLW1wbHMtc3RhdGljLWV4dGVuZGVk DQogICAgDQogICAgd2hpY2ggSSB3YXMgYWJvdXQgdG8gc2F5IHdhcyByYXRoZXIgbG9uZyBmb3Ig YSBwcmVmaXggYW5kIHRoZW4gSSBzYXcNCiAgICANCiAgICAgICBtb2R1bGUgaWV0Zi1tcGxzLXN0 YXRpYy1leHRlbmRlZCB7IC4uLg0KICAgICAgICAgcHJlZml4ICJtcGxzLXN0YXRpYy1leHQiOw0K ICAgIA0KICAgIHdoaWNoIGlzIG5vdCBzbyBsb25nLCBwcm9iYWJseSBzaG9ydCBlbm91Z2ggKGlm IHRoYXQgaXMgdGhlIHJpZ2h0IG9uZSEpLg0KICAgIA0KICAgIFNlY29uZCwgSSBhbSB3b250IHRv IGNoZWNrIHN1Y2ggc3RhdGVtZW50cyBhcw0KICAgICAgICAgICBsZWFmIGxzcC1wcmlvcml0eS1o b2xkIHsgdHlwZSB1aW50OCB7DQogICAgICAgICAgICAgICByYW5nZSAiMC4uNyI7ICB9DQogICAg ICAgICAgICAgZGVzY3JpcHRpb24gIkxTUCBob2xkIHByaW9yaXR5IjsNCiAgICBhZ2FpbnN0IHRo ZSBvcmlnaW5hbCBzcGVjaWZpY2F0aW9uLCBzaW5jZSBJIGtub3cgb2YgcnRnd2cgWUFORyBtb2R1 bGVzDQogICAgd2hlcmUgdGhlIFlBTkcgY29udHJhZGljdHMgdGhlIHB1Ymxpc2hlZCBSRkM7IGJ1 dCB0aGVyZSBpcyBubyByZWZlcmVuY2UNCiAgICBjbGF1c2UgZm9yIG9iamVjdHMgc3VjaCBhcyB0 aGlzIG9uZSwgc28gSSB3b3VsZCBoYXZlIHRvIGdvIGRpZ2dpbmcgZm9yDQoNCltUU106IHRoZSBy ZWZlcmVuY2UgaXMgUkZDMzIwOSwgc2VjdGlvbiA0LjcuMS4gV2UgY2FuIGFkZCBpdCBuZXh0IGNo YW5jZSB3ZSBnZXQgdG8gbWFrZSBlZGl0cy4NCg0KICAgICAgSG9sZGluZyBQcmlvcml0eQ0KDQog ICAgICAgICBUaGUgcHJpb3JpdHkgb2YgdGhlIHNlc3Npb24gd2l0aCByZXNwZWN0IHRvIGhvbGRp bmcgcmVzb3VyY2VzLA0KICAgICAgICAgaW4gdGhlIHJhbmdlIG9mIDAgdG8gNy4gIFRoZSB2YWx1 ZSAwIGlzIHRoZSBoaWdoZXN0IHByaW9yaXR5Lg0KICAgICAgICAgSG9sZGluZyBQcmlvcml0eSBp cyB1c2VkIGluIGRlY2lkaW5nIHdoZXRoZXIgdGhpcyBzZXNzaW9uIGNhbg0KICAgICAgICAgYmUg cHJlZW1wdGVkIGJ5IGFub3RoZXIgc2Vzc2lvbi4NCg0KUmVnYXJkcywNClRhcmVrDQoNCiAgICB0 aGUgcmVsZXZhbnQgUkZDLCB3aGljaCB3YXMgZWFzeSBpbiAyMDAxIGJlY2F1c2UgdGhlcmUgd2Vy ZSBzbyBmZXcgUkZDDQogICAgYnV0IG5vdyAuLi4NCiAgICANCiAgICBJZiB5b3UgYWRkIHJlZmVy ZW5jZXMsIEkgd2lsbCBnbyBsb29rIHVwIHRoZSByZWxldmFudCBzZWN0aW9ucyAtIGlmIG5vdCwN CiAgICAuLi4NCiAgICANCiAgICBVcCB0byB5b3U6LSkNCiAgICANCiAgICBUb20gUGV0Y2gNCiAg ICANCiAgICA+IFJlZ2FyZHMsDQogICAgPiBUYXJlaw0KICAgID4NCiAgICA+IO+7v09uIDMvOC8x OSwgMToxNCBQTSwgIlRhcmVrIFNhYWQiIDx0c2FhZC5uZXRAZ21haWwuY29tPiB3cm90ZToNCiAg ICA+DQogICAgPiAgICAgSGkgVG9tLA0KICAgID4NCiAgICA+ICAgICBUaGFua3MuIFdlJ2xsIHVu aWZ5IHRvICJNYnBzIiBhbmQga2VlcCB0aGlzIGNvbnNpc3RlbnQgaW4gdW5pdHMNCiAgICBhbmQg ZGVzY3JpcHRpb24uDQogICAgPg0KICAgID4gICAgIFJlZ2FyZHMsDQogICAgPiAgICAgVGFyZWsN CiAgICA+DQogICAgPiAgICAg77u/T24gMy83LzE5LCA3OjQ4IEFNLCAidG9tIHBldGNoIiA8aWV0 ZmNAYnRjb25uZWN0LmNvbT4gd3JvdGU6DQogICAgPg0KICAgID4gICAgICAgICBUYXJlaw0KICAg ID4NCiAgICA+ICAgICAgICAgT25lIHBvaW50IEkga2VlcCBub3RpY2luZyBidXQgZG8gbm90IHRo aW5rIEkgaGF2ZSByYWlzZWQNCiAgICBiZWZvcmUgaXMNCiAgICA+DQogICAgPiAgICAgICAgICAg ICAgIHVuaXRzIG1icHM7DQogICAgPiAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAgPiAg ICAgICAgICAgICAgICAgIkJhbmR3aWR0aCBpbiBNYnBzLA0KICAgID4NCiAgICA+ICAgICAgICAg SSBoYXZlIGtub3duIHN5c3RlbXMgZmFpbCBiZWNhdXNlIG9uZSBwYXJ0eSB3YXMgdXNpbmcgbWJw cywNCiAgICBhbm90aGVyDQogICAgPiAgICAgICAgIE1icHMsIHNvIHNlZWluZyBhIG1peCBvZiB0 aGUgdHdvLCBhcyBoZXJlLCByYWlzZXMgYSBmbGFnIGZvcg0KICAgIG1lLiAgSSBub3RlDQogICAg PiAgICAgICAgIHRoYXQNCiAgICA+ICAgICAgICAgZHJhZnQtaWV0Zi10ZWFzLXlhbmctdGUtdHlw ZXMNCiAgICA+ICAgICAgICAgaGFzDQogICAgPiAgICAgICAgICAgICAgICB1bml0cyAiTWJwcyI7 DQogICAgPiAgICAgICAgIHdoaWNoIEkgcHJlZmVyIC0gaWYgdGhleSByZWFsbHkgbWVhbiBNYnBz IGFuZCBub3QgbWJwczsgSSBoYXZlDQogICAgbXkNCiAgICA+ICAgICAgICAgZG91YnRzISAtIGJ1 dCB0aGVuDQogICAgPiAgICAgICAgICBkcmFmdC1pZXRmLWwyc20tbDJ2cG4tc2VydmljZS1tb2Rl bC0xMA0KICAgID4gICAgICAgICBoYXMNCiAgICA+ICAgICAgICAgICAgICAgICB1bml0cyAibWJw cyI7DQogICAgPiAgICAgICAgICAgICAgICAgZGVmYXVsdCAiMTAiOyAgZGVzY3JpcHRpb24NCiAg ICA+ICAgICAgICAgICAgICAgICAgICJMQUNQIHNwZWVkLiBCeSBkZWZhdWx0LCB0aGUgbGFjcCBz cGVlZCBpcyAxME1icHMuIjsNCiAgICA+DQogICAgPiAgICAgICAgIFBlcmhhcHMgaW4gdGhlIGNv bnRleHQgb2YgTVBMUyB0aGVyZSBpcyBubyBhbWJpZ3VpdHkgYnV0IGl0DQogICAgd291bGQgYmUN CiAgICA+ICAgICAgICAgbmljZSB0byBoYXZlIGNvbnNpc3RlbmN5IGF0IGxlYXN0IHdpdGhpbiBh biBJLUQuDQogICAgPg0KICAgID4gICAgICAgICBUb20gUGV0Y2gNCiAgICA+DQogICAgPiAgICAg ICAgIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCiAgICA+ICAgICAgICAgRnJvbTogIlRh cmVrIFNhYWQiIDx0c2FhZC5uZXRAZ21haWwuY29tPg0KICAgID4gICAgICAgICBTZW50OiBXZWRu ZXNkYXksIE1hcmNoIDA2LCAyMDE5IDI6NTMgUE0NCiAgICA+DQogICAgPg0KICAgID4gICAgICAg ICA+IEhpIFRvbSwNCiAgICA+ICAgICAgICAgPg0KICAgID4gICAgICAgICA+IEFzIHVzdWFsLCB0 aGFua3MgZm9yIHlvdXIgcmV2aWV3IG9uIHRoaXMgb25lIGFuZCBmb3IgeW91cg0KICAgIHBhdGll bmNlLg0KICAgID4gICAgICAgICBNb3JlDQogICAgPiAgICAgICAgID4gSW5saW5lLi4NCiAgICA+ ICAgICAgICAgPg0KICAgID4gICAgICAgICA+IE9uIFR1ZSwgTWFyIDUsIDIwMTkgYXQgMTI6MzYg UE0gdG9tIHBldGNoDQogICAgPGlldGZjQGJ0Y29ubmVjdC5jb20+IHdyb3RlOg0KICAgID4gICAg ICAgICA+DQogICAgPiAgICAgICAgID4gPiBBIGxvbmcgYW5kIHdpbmRpbmcgcm9hZCENCiAgICA+ ICAgICAgICAgPiA+DQogICAgPiAgICAgICAgID4gPiAgbW9kdWxlIGlldGYtbXBscy1zdGF0aWMg ew0KICAgID4gICAgICAgICA+ID4gLi4uLi4NCiAgICA+ICAgICAgICAgPiA+ICAgIGltcG9ydCBp ZXRmLXJvdXRpbmctdHlwZXMgew0KICAgID4gICAgICAgICA+ID4gICAgICBwcmVmaXggInJ0LXR5 cGVzIjsNCiAgICA+ICAgICAgICAgPiA+ICAgICAgcmVmZXJlbmNlICJSRkM4Mjk0OiBDb21tb24g WUFORyBEYXRhIFR5cGVzIjsNCiAgICA+ICAgICAgICAgPiA+DQogICAgPiAgICAgICAgID4gPiBJ IHNlZSwgaW4gdGhlIFJGQyBJbmRleCwNCiAgICA+ICAgICAgICAgPiA+DQogICAgPiAgICAgICAg ID4gPiA4Mjk0IENvbW1vbiBZQU5HIERhdGEgVHlwZXMgZm9yIHRoZSBSb3V0aW5nIEFyZWEuDQog ICAgPiAgICAgICAgID4gPiBpLmUuIGEgZGlmZmVyZW50IHRpdGxlDQogICAgPiAgICAgICAgID4g Pg0KICAgID4gICAgICAgICA+ID4gW1RTXTogeWVzLCB1bmZvcnR1bmF0ZWx5IGEgZGVqYSB2dSAo Zml4ZWQgaW4gYW5vdGhlcg0KICAgIG1vZHVsZSkuIFdlJ2xsDQogICAgPiAgICAgICAgIHRha2UN CiAgICA+ICAgICAgICAgPiBjYXJlIG9mIHRoaXMgaW4gdGhlIG5ldyB2ZXJzaW9uLg0KICAgID4g ICAgICAgICA+DQogICAgPiAgICAgICAgID4gPg0KICAgID4gICAgICAgICA+ID4gbW9kdWxlIGll dGYtbXBscy1zdGF0aWMtZXh0ZW5kZWQgew0KICAgID4gICAgICAgICA+ID4gLi4uLg0KICAgID4g ICAgICAgICA+ID4gICBpbXBvcnQgaWV0Zi1yb3V0aW5nIHsgICAgcHJlZml4ICJydCI7DQogICAg PiAgICAgICAgID4gPiAgICAgcmVmZXJlbmNlICJSRkM2OTkxOiBDb21tb24gWUFORyBEYXRhIFR5 cGVzIjsNCiAgICA+ICAgICAgICAgPiA+IEkgc3VnZ2VzdA0KICAgID4gICAgICAgICA+ID4gICAg ICByZWZlcmVuY2UgIlJGQzgzNDk6IEEgWUFORyBEYXRhIE1vZGVsIGZvciBSb3V0aW5nDQogICAg TWFuYWdlbWVudCI7DQogICAgPiAgICAgICAgID4gPg0KICAgID4gICAgICAgICA+ID4gW1RTXTog eWVzLCB3aWxsIHRha2Ugb2YgdGhpcy4NCiAgICA+ICAgICAgICAgPg0KICAgID4gICAgICAgICA+ ICByZWZlcmVuY2UgIlJGQyBYWFhYOiBFeHRlbmRlZCBZQU5HIERhdGEgTW9kZWwgZm9yIE1QTFMN CiAgICBTdGF0aWMgTFNQcyI7DQogICAgPiAgICAgICAgID4gPiB1bSAtIEkgc2VlIHRoaXMgSS1E IGFzIHRpdGxlZA0KICAgID4gICAgICAgICA+ID4gQSBZQU5HIERhdGEgTW9kZWwgZm9yIE1QTFMg U3RhdGljIExTUHMNCiAgICA+ICAgICAgICAgPiA+DQogICAgPiAgICAgICAgID4gPiBbVFNdOiBP SyBmb3IgdGhpcyBvbmUgdG9vLg0KICAgID4gICAgICAgICA+DQogICAgPiAgICAgICAgID4gUmVn YXJkcywNCiAgICA+ICAgICAgICAgPiBUYXJlaw0KICAgID4gICAgICAgICA+DQogICAgPiAgICAg ICAgID4NCiAgICA+ICAgICAgICAgPiA+DQogICAgPiAgICAgICAgID4gPiBUb20gUGV0Y2gNCiAg ICA+ICAgICAgICAgPiA+DQogICAgPiAgICAgICAgID4gPg0KICAgID4gICAgICAgICA+ID4gLS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KICAgID4gICAgICAgICA+ID4gRnJvbTogPGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZz4NCiAgICA+ICAgICAgICAgPiA+IFRvOiA8aS1kLWFubm91bmNl QGlldGYub3JnPg0KICAgID4gICAgICAgICA+ID4gQ2M6IDxtcGxzQGlldGYub3JnPg0KICAgID4g ICAgICAgICA+ID4gU2VudDogU2F0dXJkYXksIE1hcmNoIDAyLCAyMDE5IDg6MDkgUE0NCiAgICA+ ICAgICAgICAgPiA+DQogICAgPiAgICAgICAgID4gPiA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlz IGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lDQogICAgSW50ZXJuZXQtRHJhZnRzDQogICAgPiAg ICAgICAgID4gPiBkaXJlY3Rvcmllcy4NCiAgICA+ICAgICAgICAgPiA+ID4gVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgTXVsdGlwcm90b2NvbCBMYWJlbA0KICAgIFN3aXRjaGluZyBX Rw0KICAgID4gICAgICAgICBvZg0KICAgID4gICAgICAgICA+ID4gdGhlIElFVEYuDQogICAgPiAg ICAgICAgID4gPiA+DQogICAgPiAgICAgICAgID4gPiA+ICAgICAgICAgVGl0bGUgICAgICAgICAg IDogQSBZQU5HIERhdGEgTW9kZWwgZm9yIE1QTFMNCiAgICBTdGF0aWMgTFNQcw0KICAgID4gICAg ICAgICA+ID4gPiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IFRhcmVrIFNhYWQNCiAgICA+ICAg ICAgICAgPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBSYWtlc2ggR2FuZGhpDQogICAg PiAgICAgICAgID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgWHVmZW5nIExpdQ0KICAg ID4gICAgICAgICA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgIFZpc2hudSBQYXZhbiBC ZWVyYW0NCiAgICA+ICAgICAgICAgPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBJZ29y IEJyeXNraW4NCiAgICA+ICAgICAgICAgPiA+ID4gRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0 Zi1tcGxzLXN0YXRpYy15YW5nLTA4LnR4dA0KICAgID4gICAgICAgICA+ID4gPiBQYWdlcyAgICAg ICAgICAgOiAxOA0KICAgID4gICAgICAgICA+ID4gPiBEYXRlICAgICAgICAgICAgOiAyMDE5LTAz LTAyDQogICAgPiAgICAgICAgID4gPiA+DQogICAgPiAgICAgICAgID4gPiA+IEFic3RyYWN0Og0K ICAgID4gICAgICAgICA+ID4gPiAgICBUaGlzIGRvY3VtZW50IGNvbnRhaW5zIHRoZSBzcGVjaWZp Y2F0aW9uIGZvciB0aGUgTVBMUw0KICAgIFN0YXRpYw0KICAgID4gICAgICAgICBMYWJlbA0KICAg ID4gICAgICAgICA+ID4gPiAgICBTd2l0Y2hlZCBQYXRocyAoTFNQcykgWUFORyBtb2RlbC4gIFRo ZSBtb2RlbCBhbGxvd3MNCiAgICBmb3IgdGhlDQogICAgPiAgICAgICAgID4gPiA+ICAgIHByb3Zp c2lvbmluZyBvZiBzdGF0aWMgTFNQKHMpIG9uIExhYmVsIEVkZ2UgUm91dGVyKHMpDQogICAgTEVS KHMpDQogICAgPiAgICAgICAgIGFuZA0KICAgID4gICAgICAgICA+ID4gPiAgICBMYWJlbCBTd2l0 Y2hlZCBSb3V0ZXIocykgTFNSKHMpIGRldmljZXMgYWxvbmcgYSBMU1ANCiAgICBwYXRoDQogICAg PiAgICAgICAgIHdpdGhvdXQNCiAgICA+ICAgICAgICAgPiA+IHRoZQ0KICAgID4gICAgICAgICA+ ID4gPiAgICBkZXBlbmRlbmN5IG9uIGFueSBzaWduYWxpbmcgcHJvdG9jb2wuICBUaGUgTVBMUw0K ICAgIFN0YXRpYyBMU1ANCiAgICA+ICAgICAgICAgbW9kZWwNCiAgICA+ICAgICAgICAgPiA+ID4g ICAgYXVnbWVudHMgdGhlIE1QTFMgYmFzZSBZQU5HIG1vZGVsIHdpdGggc3BlY2lmaWMgZGF0YQ0K ICAgIHRvDQogICAgPiAgICAgICAgIGNvbmZpZ3VyZQ0KICAgID4gICAgICAgICA+ID4gYW5kDQog ICAgPiAgICAgICAgID4gPiA+ICAgIG1hbmFnZSBNUExTIFN0YXRpYyBMU1AocykuDQogICAgPiAg ICAgICAgID4gPiA+DQogICAgPiAgICAgICAgID4gPiA+DQogICAgPiAgICAgICAgID4gPiA+IFRo ZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KICAgID4g ICAgICAgICA+ID4gPg0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtbXBscy1zdGF0aWMteWFuZy8NCiAgICA+ICAgICAgICAgPiA+ID4NCiAgICA+ICAgICAg ICAgPiA+ID4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0K ICAgID4gICAgICAgICA+ID4gPg0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW1wbHMtc3RhdGljLXlhbmctMDgNCiAgICA+ICAgICAgICAgPiA+ID4NCiAgICA+DQog ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW1wbHMt c3RhdGljLXlhbmctMDgNCiAgICA+ICAgICAgICAgPiA+ID4NCiAgICA+ICAgICAgICAgPiA+ID4g QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KICAgID4g ICAgICAgICA+ID4gPg0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLW1wbHMtc3RhdGljLXlhbmctMDgNCiAgICA+ICAgICAgICAgPiA+ID4NCiAgICA+ICAg ICAgICAgPiA+ID4NCiAgICA+ICAgICAgICAgPiA+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20NCiAgICB0aGUgdGltZSBvZg0KICAgID4gICAg ICAgICA+ID4gc3VibWlzc2lvbg0KICAgID4gICAgICAgICA+ID4gPiB1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQogICAgPiAgICAgICAgIHRvb2xz LmlldGYub3JnLg0KICAgID4gICAgICAgICA+ID4gPg0KICAgID4gICAgICAgICA+ID4gPiBJbnRl cm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQogICAg PiAgICAgICAgID4gPiA+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQogICAg PiAgICAgICAgID4gPiA+DQogICAgPiAgICAgICAgID4gPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiAgICAgICAgID4gPiA+IEktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCiAgICA+ICAgICAgICAgPiA+ID4gSS1ELUFubm91bmNlQGlldGYu b3JnDQogICAgPiAgICAgICAgID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaS1kLWFubm91bmNlDQogICAgPiAgICAgICAgID4gPiA+IEludGVybmV0LURyYWZ0IGRp cmVjdG9yaWVzOg0KICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCiAgICA+ICAg ICAgICAgPiA+ID4gb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQN CiAgICA+ICAgICAgICAgPiA+DQogICAgPiAgICAgICAgID4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gICAgICAgICA+ID4gbXBscyBtYWls aW5nIGxpc3QNCiAgICA+ICAgICAgICAgPiA+IG1wbHNAaWV0Zi5vcmcNCiAgICA+ICAgICAgICAg PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KICAgID4gICAg ICAgICA+ID4NCiAgICA+ICAgICAgICAgPg0KICAgID4NCiAgICA+DQogICAgPg0KICAgID4NCiAg ICANCiAgICANCg== From nobody Fri Mar 22 01:38:40 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E721F130EC2; Fri, 22 Mar 2019 01:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=telekom.de 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 gvm1eisW5u0c; Fri, 22 Mar 2019 01:38:36 -0700 (PDT) Received: from mailout21.telekom.de (mailout21.telekom.de [194.25.225.215]) (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 B25AF130E8F; Fri, 22 Mar 2019 01:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1553243916; x=1584779916; h=from:to:cc:subject:date:message-id:mime-version; bh=9aYyciTCoFydM42Te61EuU6IJEE4HV53Cj903OaCkXU=; b=5mIQNFMaNE/XmMSbE2PTdFoKB+9vnJJSMsaiWGRtxlbLJXNRlLiWsAwd xD1hzkYbmcb35dmSomo3fwH/HJa0t1sLZce7Qse7m213QFkrOgqI2amKw iTyhTTSCRe3iTu1GEmHOuu9d6R7rtxoEMADmhsP724h1K7e0XmLwhrEKg 56wKDECX1nd0EYgK4a/BJeuBp6iqJOJs5bpV9f/Ty4mPkK0g792AVvi4f kkX5y1jwefgi9/AsUstGmAv9Kxyg4dg3NryNxL3wnzeR60kaq0oH3bYTV AAQ6bZCClhOCVXzGzkD2XkvReqj7KvBWjDijw/7/TuV0JKA0wv9pPlgL+ w==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2019 09:38:30 +0100 X-IronPort-AV: E=Sophos;i="5.60,256,1549926000"; d="scan'208,217";a="495504600" Received: from he105789.emea1.cds.t-internal.com ([10.169.118.28]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 22 Mar 2019 09:38:29 +0100 Received: from HE101951.EMEA1.cds.t-internal.com (10.169.118.77) by HE105789.emea1.cds.t-internal.com (10.169.118.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 22 Mar 2019 09:38:08 +0100 Received: from HE104160.emea1.cds.t-internal.com (10.171.40.36) by HE101951.EMEA1.cds.t-internal.com (10.169.118.77) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 22 Mar 2019 09:38:08 +0100 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.18) by O365mail03.telekom.de (172.30.0.232) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 22 Mar 2019 09:38:08 +0100 Received: from LEJPR01MB0377.DEUPRD01.PROD.OUTLOOK.DE (10.158.142.20) by LEJPR01MB0379.DEUPRD01.PROD.OUTLOOK.DE (10.158.142.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.16; Fri, 22 Mar 2019 08:38:08 +0000 Received: from LEJPR01MB0377.DEUPRD01.PROD.OUTLOOK.DE ([fe80::2440:a932:99b5:4c2d]) by LEJPR01MB0377.DEUPRD01.PROD.OUTLOOK.DE ([fe80::2440:a932:99b5:4c2d%6]) with mapi id 15.20.1709.017; Fri, 22 Mar 2019 08:38:08 +0000 From: To: CC: , , Thread-Topic: IPR poll on draft-ietf-mpls-summary-frr-rsvpte Thread-Index: AdTgipIrfmt/rAI/RAew/z067XwVGw== Date: Fri, 22 Mar 2019 08:38:07 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=N.Leymann@telekom.de; x-originating-ip: [164.19.4.221] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ca34bc79-b3c9-4854-51a2-08d6aea1b5a7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:LEJPR01MB0379; x-ms-traffictypediagnostic: LEJPR01MB0379: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 09840A4839 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(376002)(39860400002)(366004)(346002)(189003)(199004)(9686003)(54896002)(7736002)(71200400001)(14454004)(966005)(71190400001)(413944005)(5660300002)(478600001)(19627235002)(2501003)(72206003)(97736004)(5640700003)(476003)(75402003)(486006)(55016002)(106356001)(256004)(6306002)(68736007)(4743002)(54906003)(236005)(53936002)(1730700003)(81156014)(81166006)(33656002)(105586002)(2906002)(606006)(4326008)(102836004)(2351001)(74482002)(8936002)(26005)(8676002)(790700001)(6116002)(66066001)(3846002)(6916009)(316002)(86362001)(186003)(52396003)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:LEJPR01MB0379; H:LEJPR01MB0377.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ROp5D4BmrRj4lamDPzofH41DnCKeXPeyXZtcCGM8eKaHB+VAmZEdQl3koEHtMNSqV8dyKJziun4Pzn+8pd56/0UP/6QrnfD/r8Nprlsn2nwgNpFz2kCgSwcU3zwLE+VN9BFOT07FwxcQx+EgUFlbasw+D5yvty6UVKrbwBJYS/F3EwyiDqJMxzawioPccBob2cBYBQ/U3HZ3qeQl8Wvm+d4uiIWk7YwCAl1gdcvwncGn4Feym2egnp9CLd1RvXh1VUTtNl1ISLvarr32LFIfOA/U7HR4MKNAnIQOdMv6CtFTu/yvSDSySQDlRT/utl842d2aHPr6xDIGSZRrpvJ6PuJNVt/JsjxnLA5GAhFqZGSCIHFbRJXNOxtkjXK731LZ2Ov3M9Jc46hFtgnjZJxpMajsOW5vgxc50dQLNKDmzyM= Content-Type: multipart/alternative; boundary="_000_LEJPR01MB0377736655954BBFFA0D429798430LEJPR01MB0377DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ca34bc79-b3c9-4854-51a2-08d6aea1b5a7 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2019 08:38:07.9042 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEJPR01MB0379 X-OriginatorOrg: telekom.de Archived-At: Subject: [mpls] IPR poll on draft-ietf-mpls-summary-frr-rsvpte X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 08:38:39 -0000 --_000_LEJPR01MB0377736655954BBFFA0D429798430LEJPR01MB0377DEUP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Working Group, We are currently preparing draft draft-ietf-mpls-summary-frr-rsvpte for wor= king group last call. Part of this preparation is to do an IPR poll. This mail is to start the IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-summary-frr-rsvpte= ? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). There are no IPR disclosure directly against draft-ietf-mpls-summary-frr-rs= vpte. However, there is one IPR disclosure against the individual document draft-= mtaillon-mpls-summary-frr-rsvpte that preceded the working group document: https://datatracker.ietf.org/ipr/2559/ If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. *Th= e response needs to be sent to the MPLS WG mailing list.* The document will= not advance to the next stage until a response has been received from each= author and contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Best regards Nic --_000_LEJPR01MB0377736655954BBFFA0D429798430LEJPR01MB0377DEUP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Working Group,

 

We are currently preparing d= raft draft-ietf-mpls-summary-frr-rsvpte for working group last call.

 

Part of this preparation is = to do an IPR poll.

 

This mail is to start the IP= R poll.

 

Are you aware of any IPR tha= t applies to draft-ietf-mpls-summary-frr-rsvpte?

 

If so, has this IPR been dis= closed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 537= 8 for more details).

 

There are no IPR disclosure = directly against draft-ietf-mpls-summary-frr-rsvpte.

However, there is one IPR di= sclosure against the individual document draft-mtaillon-mpls-summary-frr-rs= vpte that preceded the working group document:

 

https://datatracker.ietf.org/ipr/2559/

 

If you are listed as a docum= ent author or contributor please respond to this email regardless of whethe= r or not you are aware of any relevant IPR. *The response needs to be sent = to the MPLS WG mailing list.* The document will not advance to the next stage until a response has been received from= each author and contributor.

 

If you are on the MPLS WG em= ail list but are not listed as an author or contributor, then please explic= itly respond only if you are aware of any IPR that has not yet been disclos= ed in conformance with IETF rules.

 

Best regards

 

   Nic

 

--_000_LEJPR01MB0377736655954BBFFA0D429798430LEJPR01MB0377DEUP_-- From nobody Fri Mar 22 03:23:52 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E391277CE for ; Fri, 22 Mar 2019 03:10:44 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 (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 3TnhwHU8Hcze for ; Fri, 22 Mar 2019 03:10:42 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3CF1126C01 for ; Fri, 22 Mar 2019 03:10:42 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id t206so1302226oib.3 for ; Fri, 22 Mar 2019 03:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=qF0fYIEOaChZjkpPr2rj2qEEdYxYHrexe1hsSNp2GG0=; b=YJYyWio/ItwQcYfE9T+iZEvzHQBF9pFQ+O70IfdB83Lmh2PxFr8OSOfoAR+iipIGWh e+QauH+gkzXtKMvb1v4sK5g0chG375OEP2VralTlaFaJFwONiTpG/J1oKioWSjJttMXp iHgaWzsCEPaE8nkj+btOnp928pwKe8wfbno81qn9nyRfx5lzPmiVIGNubCMmOTUy4Ql4 TF7Txv88KwddbOevo/hRen5T1pKLInjRTR1/cG43lJrxLqJxpXq4o6HmWdUU49OyK6P9 S2jvo7vNHJIxlHKxoyrsl+vrS7Cu5qfnC04zNIiF0KUC9+U+pZTX3ZBuRKHRDg2cfqGi lNuQ== 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; bh=qF0fYIEOaChZjkpPr2rj2qEEdYxYHrexe1hsSNp2GG0=; b=Htj6I/t5FYJEjgfW7peSPdsvXnPTbfEzV4BEcp3caEmKEITgdFv3ufeHmSb7ndsGsD dZQufGdeqpTFAbpaGqPbHz45jvNyTVnJ1INQfJh66zVO5gMNx+UbNjt2WU/Z+SIBDBct Yw6OjBbOyq2dsB7eBFIRlW1suXAGzmTICedS7+YQ6bmRPeMBN/IfX3QL3UFeWwsYqs5+ eXgVDl2glkc+zCx/bBEky2tZtwxNQAtXTSm4k+LLjl0tIANgoCcfaNO2hhrn2oALwbmg f+Xqo8GQiBQtUxA8awAftkWCP2Y2pTleLsROoGu4knRhHaRFWZdrgxF8gGePgFHgijlY NjEA== X-Gm-Message-State: APjAAAUlm8vJ6tjr1UhByymUiW8QdbA5FnQSt+WnQ8ZT3TcTYHn0Crrw MmK37yZJMOOOBnCM2KJ6+hThW9V3yId8ta5uvYYskfsL X-Google-Smtp-Source: APXvYqzGid6ZzE29cBFvZljV690JlXwqTIeRuA3gTOGBVqie2x3KH38AGOfUk5QHb2mh3tNzptkX+ZGYioGmcikwXJM= X-Received: by 2002:aca:ecd5:: with SMTP id k204mr1195400oih.53.1553249441795; Fri, 22 Mar 2019 03:10:41 -0700 (PDT) MIME-Version: 1.0 From: Ramakrishna Rao Desetti Date: Fri, 22 Mar 2019 15:40:29 +0530 Message-ID: To: mpls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-Mailman-Approved-At: Fri, 22 Mar 2019 03:23:50 -0700 Subject: [mpls] Request for clarification on RFC 7552 (Updates to LDP for IPv6) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 10:10:45 -0000 Hi, I request a clarification on a specific point with regard to RFC 7552. Section 8 says: "Lastly, for better scale and optimization, an LSR may advertise only the link-local IPv6 addresses in the Address message, assuming that the peer uses only the link-local IPv6 addresses as static and/or dynamic IP routing next hops." Link-local IPv6 addresses are specific to an interface/link. If we learn link-local IPv6 addresses via LDP session, how to assign to which interface this address belongs to? Note that an LDP session may be backed up by multiple adjacencies on parallel links between peers. RFC 7552 already provided a mechanism to learn link local addresses of a peer via hello messages. It correctly associates those addresses with an interface. Given that it is not clear what is the motivation for the above mentioned additional mechanism. Thanks and regards, Ramakrishna DTV. From nobody Fri Mar 22 04:54:34 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882AE130EC8; Fri, 22 Mar 2019 04:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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=ebkC4m6h; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Kpp07Wzk 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 dWRoMhd0IveC; Fri, 22 Mar 2019 04:54:29 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E5D51277CE; Fri, 22 Mar 2019 04:54:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12125; q=dns/txt; s=iport; t=1553255669; x=1554465269; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=r2OfVU9P86S654KfEw1hxhUy/wvvQblYqCZxCkq94PA=; b=ebkC4m6h1e9Aql+uj2XfusTfKcL2cSBPj9M7Z99Y7IfSqEws3H+iYrDZ qRGVlcIQ2eapWJSrkYpu1Oj/sT3CNqFpHOsNhZUuAaSh24hyQkkHoJoRD bKoHc2FpcKSQElf94IK94AcGBAUUtZI4Kqx7b8GVuDICMH4qIMXMHh1JV g=; IronPort-PHdr: =?us-ascii?q?9a23=3AGF0YXxNeZPYYKHYcZAsl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjhI/fsYyw7NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAACdy5Rc/51dJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYEPL1ADaHQECyeEDoNHA48ngleJNokLhEmBQoEQA1Q?= =?us-ascii?q?NAQEfDYRAAheEZCI4EgEBAwEBCQEDAm0cDIVKAQEBBCMdAQEsBgUBDwIBCBE?= =?us-ascii?q?DAQIrAgICHxEdCAEBBAENBYMiAYERTAMVAQIMnkACihRxgS8fglkBAQWBMQG?= =?us-ascii?q?DVw0LggwDBYEvizIXgUA/gTgfgkw+ghpHAgOBJgUBEQIBNQkNgl0xgiaKKYJ?= =?us-ascii?q?GhBuTTjYJAodhiBaDPxmCAYV8i36KRQlKhgGBOYtpAgQCBAUCDgEBBYFkIWV?= =?us-ascii?q?xcBU7KgGCQYIKg26EWTuFP3KBKI0VAQE?= X-IronPort-AV: E=Sophos;i="5.60,256,1549929600"; d="scan'208,217";a="527940098" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Mar 2019 11:54:28 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x2MBsRJE020607 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Mar 2019 11:54:27 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 22 Mar 2019 06:54:26 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 22 Mar 2019 06:54:26 -0500 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 22 Mar 2019 06:54:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r2OfVU9P86S654KfEw1hxhUy/wvvQblYqCZxCkq94PA=; b=Kpp07Wzkm9klZiLu4clv0uQSfX6H2Eoms7wlepxQc8fhlYuJAjSpPSs3mRM0sTCweYvz+bmydooRZ1Rb46rYZFhO296RoBJGOad8YX60O7pYVH6F6fosAEStNZKGlgztw+l+z8AvCSwWFaDD/vXzQue5ehN4BgBZJD2zOj3GZ0s= Received: from BYAPR11MB2567.namprd11.prod.outlook.com (52.135.226.160) by BYAPR11MB3816.namprd11.prod.outlook.com (20.178.239.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.15; Fri, 22 Mar 2019 11:54:24 +0000 Received: from BYAPR11MB2567.namprd11.prod.outlook.com ([fe80::9018:20f6:33c8:3a2b]) by BYAPR11MB2567.namprd11.prod.outlook.com ([fe80::9018:20f6:33c8:3a2b%4]) with mapi id 15.20.1730.017; Fri, 22 Mar 2019 11:54:24 +0000 From: "Rakesh Gandhi (rgandhi)" To: "N.Leymann@telekom.de" , "mpls@ietf.org" CC: "draft-ietf-mpls-summary-frr-rsvpte@ietf.org" , "tsaad.net@gmail.com" , "mpls-chairs@ietf.org" Thread-Topic: IPR poll on draft-ietf-mpls-summary-frr-rsvpte Thread-Index: AdTgipIrfmt/rAI/RAew/z067XwVG///88kA Date: Fri, 22 Mar 2019 11:54:24 +0000 Message-ID: <039CB6B6-C5B7-4F49-A57E-A072FDAB44EC@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/f.1d.0.161209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rgandhi@cisco.com; x-originating-ip: [2001:420:c0c8:1002::44] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ceb8fec4-9ef9-4b36-53dc-08d6aebd213a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR11MB3816; x-ms-traffictypediagnostic: BYAPR11MB3816: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 09840A4839 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(136003)(376002)(39860400002)(366004)(189003)(199004)(8676002)(81156014)(81166006)(4743002)(102836004)(97736004)(82746002)(33656002)(229853002)(6486002)(36756003)(6436002)(186003)(6246003)(7736002)(76176011)(46003)(2501003)(25786009)(99286004)(105586002)(316002)(476003)(106356001)(486006)(6506007)(6512007)(6306002)(236005)(2616005)(53546011)(54896002)(4326008)(53936002)(11346002)(446003)(606006)(6116002)(14454004)(5660300002)(966005)(2906002)(68736007)(58126008)(86362001)(54906003)(110136005)(9326002)(478600001)(256004)(8936002)(71190400001)(71200400001)(83716004); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3816; H:BYAPR11MB2567.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: WVKesaU+4Wo7uoiJ8tlGU/ejlX/om5G9x6+rGNo8UwwIVQI5MArywlM0SYBIQSi/qRLAoDELPIio94CZoKjbJuPxUlQ4eauRZZZ879cFb7d6G+S2O0rrj38OABlnL2s5qFQhcN2LBngsJcIcQEfpZm6ccyZUJheNW6BWmXUOJbOsi8VFQ4Wn7+o7f+nfuhq9OMwDnsqFgVsApcIWM4YG3P8iFRbBY+/hnIVZZZagdf71uAgdTc0/e5MgDl3+MLPqTd0WrMu2ZBbkbwCitI1ADyHpKIawIFEO0mpB+x3k0nlqpN+SytqBH+mdpVQTQANR3XTKMqtn1sAyP+8DCH08iBzNx66o6rlgKOObhkVjDlAC3ONf2lunaq5N5hgrgqp6W5El6ypLqjoLnKMLJwJN1c837MPzemYWKqKiqvwJWyA= Content-Type: multipart/alternative; boundary="_000_039CB6B6C5B74F49A57EA072FDAB44ECciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ceb8fec4-9ef9-4b36-53dc-08d6aebd213a X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2019 11:54:24.7655 (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-Transport-CrossTenantHeadersStamped: BYAPR11MB3816 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.23, xch-rcd-013.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [mpls] IPR poll on draft-ietf-mpls-summary-frr-rsvpte X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 11:54:33 -0000 --_000_039CB6B6C5B74F49A57EA072FDAB44ECciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmljLA0KDQpJIGFtIG5vdCBhd2FyZSBvZiBhbiBJUFIgb3RoZXIgdGhhbiB0aGUgb25lIGRp c2Nsb3NlZCBiZWxvdy4NCg0KVGhhbmtzLA0KUmFrZXNoDQoNCg0KRnJvbTogIk4uTGV5bWFubkB0 ZWxla29tLmRlIiA8Ti5MZXltYW5uQHRlbGVrb20uZGU+DQpEYXRlOiBGcmlkYXksIE1hcmNoIDIy LCAyMDE5IGF0IDQ6MzggQU0NClRvOiAibXBsc0BpZXRmLm9yZyIgPG1wbHNAaWV0Zi5vcmc+DQpD YzogImRyYWZ0LWlldGYtbXBscy1zdW1tYXJ5LWZyci1yc3ZwdGVAaWV0Zi5vcmciIDxkcmFmdC1p ZXRmLW1wbHMtc3VtbWFyeS1mcnItcnN2cHRlQGlldGYub3JnPiwgInRzYWFkLm5ldEBnbWFpbC5j b20iIDx0c2FhZC5uZXRAZ21haWwuY29tPiwgIm1wbHMtY2hhaXJzQGlldGYub3JnIiA8bXBscy1j aGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBJUFIgcG9sbCBvbiBkcmFmdC1pZXRmLW1wbHMtc3Vt bWFyeS1mcnItcnN2cHRlDQpSZXNlbnQtRnJvbTogPGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+DQpS ZXNlbnQtVG86ICI9U01UUDptdGFpbGxvbkBjaXNjby4gY29tIiA8bXRhaWxsb25AY2lzY28uY29t PiwgPHRzYWFkQGNpc2NvLmNvbT4sICI9U01UUDpyZ2FuZGhpQGNpc2NvLiBjb20iIDxyZ2FuZGhp QGNpc2NvLmNvbT4sIDxhZGVzaG11a2hAanVuaXBlci5uZXQ+LCA8bWpvcmtAanVuaXBlci5uZXQ+ LCA8dmJlZXJhbUBqdW5pcGVyLm5ldD4NClJlc2VudC1EYXRlOiBGcmlkYXksIE1hcmNoIDIyLCAy MDE5IGF0IDQ6MzggQU0NCg0KDQpEZWFyIFdvcmtpbmcgR3JvdXAsDQoNCg0KDQpXZSBhcmUgY3Vy cmVudGx5IHByZXBhcmluZyBkcmFmdCBkcmFmdC1pZXRmLW1wbHMtc3VtbWFyeS1mcnItcnN2cHRl IGZvciB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbC4NCg0KDQoNClBhcnQgb2YgdGhpcyBwcmVwYXJh dGlvbiBpcyB0byBkbyBhbiBJUFIgcG9sbC4NCg0KDQoNClRoaXMgbWFpbCBpcyB0byBzdGFydCB0 aGUgSVBSIHBvbGwuDQoNCg0KDQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVz IHRvIGRyYWZ0LWlldGYtbXBscy1zdW1tYXJ5LWZyci1yc3ZwdGU/DQoNCg0KDQpJZiBzbywgaGFz IHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxl cyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4N Cg0KDQoNClRoZXJlIGFyZSBubyBJUFIgZGlzY2xvc3VyZSBkaXJlY3RseSBhZ2FpbnN0IGRyYWZ0 LWlldGYtbXBscy1zdW1tYXJ5LWZyci1yc3ZwdGUuDQoNCkhvd2V2ZXIsIHRoZXJlIGlzIG9uZSBJ UFIgZGlzY2xvc3VyZSBhZ2FpbnN0IHRoZSBpbmRpdmlkdWFsIGRvY3VtZW50IGRyYWZ0LW10YWls bG9uLW1wbHMtc3VtbWFyeS1mcnItcnN2cHRlIHRoYXQgcHJlY2VkZWQgdGhlIHdvcmtpbmcgZ3Jv dXAgZG9jdW1lbnQ6DQoNCg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8yNTU5 Lw0KDQoNCg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJp YnV0b3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIg b3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gKlRoZSByZXNwb25zZSBu ZWVkcyB0byBiZSBzZW50IHRvIHRoZSBNUExTIFdHIG1haWxpbmcgbGlzdC4qIFRoZSBkb2N1bWVu dCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFz IGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IuDQoNCg0KDQpJ ZiB5b3UgYXJlIG9uIHRoZSBNUExTIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFz IGFuIGF1dGhvciBvciBjb250cmlidXRvciwgdGhlbiBwbGVhc2UgZXhwbGljaXRseSByZXNwb25k IG9ubHkgaWYgeW91IGFyZSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBk aXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLg0KDQoNCg0KQmVzdCByZWdh cmRzDQoNCg0KDQogICBOaWMNCg0K --_000_039CB6B6C5B74F49A57EA072FDAB44ECciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <2DB1B5F5548BF84BA75EEE5901066EB8@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6Q291cmllcjt9DQpwLm1zb25vcm1hbDAs IGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1h bDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KcC5OdXJUZXh0LCBsaS5OdXJUZXh0LCBkaXYu TnVyVGV4dA0KCXttc28tc3R5bGUtbmFtZToiTnVyIFRleHQiOw0KCW1zby1zdHlsZS1saW5rOiJO dXIgVGV4dCBaY2huIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5OdXJUZXh0WmNo bg0KCXttc28tc3R5bGUtbmFtZToiTnVyIFRleHQgWmNobiI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJOdXIgVGV4dCI7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9 DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJ Y29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGlu az0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGkgTmljLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIG5vdCBhd2FyZSBvZiBh biBJUFIgb3RoZXIgdGhhbiB0aGUgb25lIGRpc2Nsb3NlZCBiZWxvdy48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmFr ZXNoPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ JnF1b3Q7Ti5MZXltYW5uQHRlbGVrb20uZGUmcXVvdDsgJmx0O04uTGV5bWFubkB0ZWxla29tLmRl Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIE1hcmNoIDIyLCAyMDE5IGF0IDQ6MzggQU08 YnI+DQo8Yj5UbzogPC9iPiZxdW90O21wbHNAaWV0Zi5vcmcmcXVvdDsgJmx0O21wbHNAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtkcmFmdC1pZXRmLW1wbHMtc3VtbWFyeS1mcnIt cnN2cHRlQGlldGYub3JnJnF1b3Q7ICZsdDtkcmFmdC1pZXRmLW1wbHMtc3VtbWFyeS1mcnItcnN2 cHRlQGlldGYub3JnJmd0OywgJnF1b3Q7dHNhYWQubmV0QGdtYWlsLmNvbSZxdW90OyAmbHQ7dHNh YWQubmV0QGdtYWlsLmNvbSZndDssICZxdW90O21wbHMtY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZs dDttcGxzLWNoYWlyc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+SVBSIHBvbGwg b24gZHJhZnQtaWV0Zi1tcGxzLXN1bW1hcnktZnJyLXJzdnB0ZSA8YnI+DQo8Yj5SZXNlbnQtRnJv bTogPC9iPiZsdDthbGlhcy1ib3VuY2VzQGlldGYub3JnJmd0Ozxicj4NCjxiPlJlc2VudC1Ubzog PC9iPiZxdW90Oz1TTVRQOm10YWlsbG9uQGNpc2NvLiBjb20mcXVvdDsgJmx0O210YWlsbG9uQGNp c2NvLmNvbSZndDssICZsdDt0c2FhZEBjaXNjby5jb20mZ3Q7LCAmcXVvdDs9U01UUDpyZ2FuZGhp QGNpc2NvLiBjb20mcXVvdDsgJmx0O3JnYW5kaGlAY2lzY28uY29tJmd0OywgJmx0O2FkZXNobXVr aEBqdW5pcGVyLm5ldCZndDssICZsdDttam9ya0BqdW5pcGVyLm5ldCZndDssICZsdDt2YmVlcmFt QGp1bmlwZXIubmV0Jmd0Ozxicj4NCjxiPlJlc2VudC1EYXRlOiA8L2I+RnJpZGF5LCBNYXJjaCAy MiwgMjAxOSBhdCA0OjM4IEFNPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPkRlYXIgV29ya2luZyBHcm91cCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+V2UgYXJlIGN1cnJlbnRseSBwcmVwYXJpbmcgZHJhZnQgZHJhZnQtaWV0Zi1tcGxz LXN1bW1hcnktZnJyLXJzdnB0ZSBmb3Igd29ya2luZyBncm91cCBsYXN0IGNhbGwuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPlBhcnQgb2YgdGhpcyBwcmVwYXJhdGlvbiBpcyB0byBkbyBh biBJUFIgcG9sbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhpcyBtYWlsIGlzIHRv IHN0YXJ0IHRoZSBJUFIgcG9sbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QXJlIHlv dSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdC1pZXRmLW1wbHMtc3VtbWFy eS1mcnItcnN2cHRlPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JZiBzbywgaGFzIHRo aXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAo c2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlcmUgYXJlIG5vIElQUiBkaXNjbG9zdXJlIGRp cmVjdGx5IGFnYWluc3QgZHJhZnQtaWV0Zi1tcGxzLXN1bW1hcnktZnJyLXJzdnB0ZS4NCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SG93ZXZlciwgdGhlcmUgaXMgb25l IElQUiBkaXNjbG9zdXJlIGFnYWluc3QgdGhlIGluZGl2aWR1YWwgZG9jdW1lbnQgZHJhZnQtbXRh aWxsb24tbXBscy1zdW1tYXJ5LWZyci1yc3ZwdGUgdGhhdCBwcmVjZWRlZCB0aGUgd29ya2luZyBn cm91cCBkb2N1bWVudDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMjU1OS8iPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvaXByLzI1NTkvPC9hPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPklm IHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFz ZSByZXNwb25kIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3Ug YXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuICpUaGUgcmVzcG9uc2UgbmVlZHMgdG8gYmUg c2VudCB0byB0aGUgTVBMUyBXRyBtYWlsaW5nIGxpc3QuKiBUaGUgZG9jdW1lbnQgd2lsbCBub3Qg YWR2YW5jZQ0KIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVj ZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPklmIHlvdSBhcmUgb24gdGhlIE1QTFMgV0cgZW1haWwgbGlzdCBidXQgYXJl IG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBs aWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXMg bm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkJlc3QgcmVnYXJkczxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgTmljPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_039CB6B6C5B74F49A57EA072FDAB44ECciscocom_-- From nobody Fri Mar 22 11:18:15 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCCC131436; Fri, 22 Mar 2019 11:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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=Eq+2317S; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=AvwHBLdU 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 BlosPUl97oax; Fri, 22 Mar 2019 11:17:58 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73556131426; Fri, 22 Mar 2019 11:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9084; q=dns/txt; s=iport; t=1553278678; x=1554488278; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fyFG8UA3LHlbHyYxnpyfcAYB6nza1yZdqUkOXJSsXMg=; b=Eq+2317Sk+UXn9MlHNIliT2VOjrPBfYKC4Om3HvbAvnFK032L+9tV658 c1ByCCzgiBUnAMEMOlRwYwnPdGNMqeBtoy/MVdZhM4LOCMi+9ppzYk/Ya 6ld0ZAIB6pWs4n2rkdiSLWPh2db8TpbfU6CDQyRLWFTGT6wtDq3AiruSg 4=; IronPort-PHdr: =?us-ascii?q?9a23=3Aeq7tkhQEV/SYriiFzHGAtmyL/9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOikmFcVGUFhj13q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAABWJpVc/4QNJK1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUgQBAQEBCwGBDi9QA2h0BAsnh1UDjyiVGIRJgS4UgRADVA0?= =?us-ascii?q?BAR8NhEAChHwiNQgNAQEDAQEJAQMCbRwBC4VLBkABASwGBQEPAgEIPwcyFBE?= =?us-ascii?q?BAQQOBYMiAYERTAMVAQIMniYCihSCIIJ4AQEFgTEBg1EYggwDBYEvAYsxF4F?= =?us-ascii?q?AP4E4H4JMPoJhAgOBJgUBEQIBS4MOgiaKKoZhlAUJAodhi1UZggKFfIt+ikU?= =?us-ascii?q?JSoYCjSICBAIEBQIOAQEFgU8DM2VxcBU7KgGCQYIKg26FFIU/coEojVoBAQ?= X-IronPort-AV: E=Sophos;i="5.60,256,1549929600"; d="scan'208,217";a="249464141" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Mar 2019 18:17:57 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x2MIHvc2007780 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Mar 2019 18:17:57 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 22 Mar 2019 13:17:56 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 22 Mar 2019 14:17:54 -0400 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 22 Mar 2019 13:17:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tSOruXmyJW85fkWaMcbWJL2GYSR7UgrYjJlwB72qUEo=; b=AvwHBLdUquznwdxTjN4fw6/wVKEFo3MMgjZ+r8NXCoUvQUb7RoIodzH9Delb4HDzfDpydwGdtTBDRCdxW+B+N4xGj5bx3hnOSBU1/5rwLcH+KSgOW/BZE4xWYySgY1qaHeHOjDxyA1q86cBh1Qb5WxHjBbm734zIm+S7GD22RxQ= Received: from MN2PR11MB3663.namprd11.prod.outlook.com (20.178.253.96) by MN2PR11MB3632.namprd11.prod.outlook.com (20.178.251.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.16; Fri, 22 Mar 2019 18:17:53 +0000 Received: from MN2PR11MB3663.namprd11.prod.outlook.com ([fe80::c55e:7311:c943:388b]) by MN2PR11MB3663.namprd11.prod.outlook.com ([fe80::c55e:7311:c943:388b%4]) with mapi id 15.20.1730.013; Fri, 22 Mar 2019 18:17:53 +0000 From: "Mike Taillon (mtaillon)" To: "N.Leymann@telekom.de" CC: "mpls@ietf.org" , "draft-ietf-mpls-summary-frr-rsvpte@ietf.org" , "tsaad.net@gmail.com" , "mpls-chairs@ietf.org" Thread-Topic: IPR poll on draft-ietf-mpls-summary-frr-rsvpte Thread-Index: AdTgipIrfmt/rAI/RAew/z067XwVGwAUP3kA Date: Fri, 22 Mar 2019 18:17:53 +0000 Message-ID: <8A6A9ABF-E264-41EE-994C-1605F74D784E@cisco.com> 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=mtaillon@cisco.com; x-originating-ip: [2001:420:2840:1250:4113:9f01:873e:13fe] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a54bf5b3-ddc7-4f55-c961-08d6aef2b343 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:MN2PR11MB3632; x-ms-traffictypediagnostic: MN2PR11MB3632: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 09840A4839 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(376002)(346002)(136003)(396003)(189003)(199004)(14454004)(8676002)(11346002)(186003)(81156014)(2616005)(446003)(102836004)(486006)(478600001)(81166006)(6116002)(6486002)(476003)(46003)(2351001)(256004)(86362001)(6436002)(966005)(229853002)(99286004)(2501003)(76176011)(105586002)(106356001)(8936002)(5660300002)(2906002)(316002)(82746002)(36756003)(53546011)(6506007)(53936002)(5640700003)(25786009)(6306002)(54896002)(6512007)(236005)(6246003)(54906003)(97736004)(4326008)(83716004)(71200400001)(71190400001)(7736002)(68736007)(4743002)(6916009)(606006)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3632; H:MN2PR11MB3663.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: vUCWKjIOXGIaqxTh1I3x6hCSlQX62Nn35XnCY1KtFy+RATJbjl7ak+2eAyaKcyzwHOHaNVfXEo7+19+HQaHM1LQ2TaqS15yPSs36cMUX7iCel48HcMWE3CrlwdlayBcqgPV4Cc5GDLTS38EuGunz7ixsRjqRMGUgL/c5XkUKcN5X9hXAVcDny3vgwPbNKn0Obbmacz9MOoOTIFgqUAXCOnB6lRFWc6Yhxbu4ILiqA0w/Gu14uFRN2sVgLYF9mLoNq9JQFsxYw2USu99przErU2NB6ph8dYLa3pbN0DoZ3ykniJvFYjiH5SbB/dBxPYPSvNgO9bSIOXoweqP01fqOr63v9U7/w2XFRgMQuQTESpyL7At8c7jAegJWUAtLWd6FuZIOjmnjhNjrEPyzS+EYq9BlkP4lJXDNIfmy2GQuEvQ= Content-Type: multipart/alternative; boundary="_000_8A6A9ABFE26441EE994C1605F74D784Eciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a54bf5b3-ddc7-4f55-c961-08d6aef2b343 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2019 18:17:53.0655 (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-Transport-CrossTenantHeadersStamped: MN2PR11MB3632 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.25, xch-aln-015.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [mpls] IPR poll on draft-ietf-mpls-summary-frr-rsvpte X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 18:18:13 -0000 --_000_8A6A9ABFE26441EE994C1605F74D784Eciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nic, I am not aware of an IPR other than the one disclosed below. -mike On Mar 22, 2019, at 4:38 AM, N.Leymann@telekom.de wrote: Dear Working Group, We are currently preparing draft draft-ietf-mpls-summary-frr-rsvpte for wor= king group last call. Part of this preparation is to do an IPR poll. This mail is to start the IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-summary-frr-rsvpte= ? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). There are no IPR disclosure directly against draft-ietf-mpls-summary-frr-rs= vpte. However, there is one IPR disclosure against the individual document draft-= mtaillon-mpls-summary-frr-rsvpte that preceded the working group document: https://datatracker.ietf.org/ipr/2559/ If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. *Th= e response needs to be sent to the MPLS WG mailing list.* The document will= not advance to the next stage until a response has been received from each= author and contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Best regards Nic --_000_8A6A9ABFE26441EE994C1605F74D784Eciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4BF1B134B071D842BBF060F2BF4B3E3A@namprd11.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Nic,
 
I am not aware of an IPR other than the one disclosed below.

-mike

On Mar 22, 2019, at 4:38 AM, N.Leymann@telekom.de wrote:

Dear Working Group,
 
We are currently preparing draft draft-ietf= -mpls-summary-frr-rsvpte for working group last call.=
 
Part of this preparation is to do an IPR po= ll.
 
This mail is to start the IPR poll.
 
Are you aware of any IPR that applies to dr= aft-ietf-mpls-summary-frr-rsvpte?
 
If so, has this IPR been disclosed in compl= iance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more deta= ils).
 
There are no IPR disclosure directly agains= t draft-ietf-mpls-summary-frr-rsvpte.
However, there is one IPR disclosure agains= t the individual document draft-mtaillon-mpls-summary-frr-rsvpte that prece= ded the working group document:
 
https://datatracker.ietf.org/ipr/2559/
 
If you are listed as a document author or c= ontributor please respond to this email regardless of whether or not you ar= e aware of any relevant IPR. *The response needs to be sent to the MPLS WG = mailing list.* The document will not advance to the next stage until a response has been received from each aut= hor and contributor.
 
If you are on the MPLS WG email list but ar= e not listed as an author or contributor, then please explicitly respond on= ly if you are aware of any IPR that has not yet been disclosed in conforman= ce with IETF rules.
 
Best regards
 
   Nic

--_000_8A6A9ABFE26441EE994C1605F74D784Eciscocom_-- From nobody Fri Mar 22 11:20:54 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F23131414; Fri, 22 Mar 2019 11:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_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 uGmVWmKvzw9c; Fri, 22 Mar 2019 11:20:43 -0700 (PDT) Received: from mail-it1-x12c.google.com (mail-it1-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 756AC131411; Fri, 22 Mar 2019 11:20:43 -0700 (PDT) Received: by mail-it1-x12c.google.com with SMTP id 139so4765584ita.4; Fri, 22 Mar 2019 11:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=cb6fb6S863MLVCKLpYuVdBReRKtzeqluYAdJP2YEb0E=; b=qntpZaRcTxGIxUxxAFRruy49ISZU1GrtKT3bOYMDUmv2u3lHc4K/tEIodx8SiQRp1A X6oWX0X62TNGx3iUSmqDlR9LdnEpRELA3kf4uvtgjcNOTW8mgPhF0YIyY6NFRpgbmMBW wubykSQAYOiGX4VN/0L5CBGf2oVsr5cjpzK/uXVUijJ4aEsKuTfIGF62Pyd2hzA07zjf JF6iB7wjr0FE1mePoRDTsaWDbr6ijQs25yrUFC8OZyO2bfU3ku0ByNoNxTf5/vWp1EY4 NgH3oJDM94k/uLsfcYVdKQx5s95Y6b3RSbChI05LcP/4hXrOWKYR4OsLvDjWhxGkcyj+ LJsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=cb6fb6S863MLVCKLpYuVdBReRKtzeqluYAdJP2YEb0E=; b=oxIEqRVAsX3Vd0LPWvhyLeti+C43/qZPJPlzaw2yBEdMgf+BoN7CmUlA/N1y2Lh2Qn erIbMdzkhDnIOBT4eqk+1fl7DPcbJ4mLQxCIhjnLWS9x06Wr5PTUu07Pe678y3crBQHk V2+u7SBoHWUgTklx8toejFIS6/niAFRKWL8xCZ1KtQT8TKABfyKUj3rXwR1KZyGolIeo V612Hj2nlwy82NZEqXPHlm2jCAagbdsdb80fVOjvNODOI5lnuQHaC4yy9lGGxoGYohqw PTXQfyMvISbdmQcoGyKYRXf33k85n6GaaVts23ws1D8ghErxHRD4/g9w+AN9LbyKmqbH SJjA== X-Gm-Message-State: APjAAAW3ULcsLxgbnclby0sWE9IKlQTzYFiqFcf2QZGowcCQVoXVjj+h V5rhHIMBIHkZLX8ZjXgFjYY= X-Google-Smtp-Source: APXvYqwU8Mc7gdqhKUhqz/eT2VpgzNriwGyxyJYUT6f47JFjjEXDybPdDj+tk+HY6LE4+wPm9G1drw== X-Received: by 2002:a24:6c84:: with SMTP id w126mr2329871itb.35.1553278842827; Fri, 22 Mar 2019 11:20:42 -0700 (PDT) Received: from BN8PR06MB6289.namprd06.prod.outlook.com ([52.96.29.13]) by smtp.gmail.com with ESMTPSA id 15sm1640119ita.34.2019.03.22.11.20.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Mar 2019 11:20:42 -0700 (PDT) From: Tarek Saad To: "N.Leymann@telekom.de" , "mpls@ietf.org" CC: "draft-ietf-mpls-summary-frr-rsvpte@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: IPR poll on draft-ietf-mpls-summary-frr-rsvpte Thread-Index: ATAyQjYw1aYr1QNesybSJ02kYIgP8MldM32Z X-MS-Exchange-MessageSentRepresentingType: 1 Date: Fri, 22 Mar 2019 18:20:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_BN8PR06MB6289DE6E7423033F49EBAD9DFC430BN8PR06MB6289namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] IPR poll on draft-ietf-mpls-summary-frr-rsvpte X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 18:20:50 -0000 --_000_BN8PR06MB6289DE6E7423033F49EBAD9DFC430BN8PR06MB6289namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I am not aware of any IPRs other than what was disclosed below. Regards, Tarek From: "N.Leymann@telekom.de" Date: Friday, March 22, 2019 at 4:38 AM To: "mpls@ietf.org" Cc: "draft-ietf-mpls-summary-frr-rsvpte@ietf.org" , "tsaad.net@gmail.com" , "mpls-ch= airs@ietf.org" Subject: IPR poll on draft-ietf-mpls-summary-frr-rsvpte Dear Working Group, We are currently preparing draft draft-ietf-mpls-summary-frr-rsvpte for wor= king group last call. Part of this preparation is to do an IPR poll. This mail is to start the IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-summary-frr-rsvpte= ? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). There are no IPR disclosure directly against draft-ietf-mpls-summary-frr-rs= vpte. However, there is one IPR disclosure against the individual document draft-= mtaillon-mpls-summary-frr-rsvpte that preceded the working group document: https://datatracker.ietf.org/ipr/2559/ If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. *Th= e response needs to be sent to the MPLS WG mailing list.* The document will= not advance to the next stage until a response has been received from each= author and contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Best regards Nic --_000_BN8PR06MB6289DE6E7423033F49EBAD9DFC430BN8PR06MB6289namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I am not aware of any IPRs other than what was discl= osed below.

 

Regards,

Tarek

 

From= : "N.Leymann@t= elekom.de" <N.Leymann@telekom.de>
Date: Friday, March 22, 2019 at 4:38 AM
To: "mpls@ietf.org" <mpls@ietf.org>
Cc: "draft-ietf-mpls-summary-frr-rsvpte@ietf.org" <draf= t-ietf-mpls-summary-frr-rsvpte@ietf.org>, "tsaad.net@gmail.com"= ; <tsaad.net@gmail.com>, "mpls-chairs@ietf.org" <mpls-ch= airs@ietf.org>
Subject: IPR poll on draft-ietf-mpls-summary-frr-rsvpte <= /span>

 

Dear Working Group,

 

We are currently preparing draft draft-ietf-mpls-= summary-frr-rsvpte for working group last call.

 

Part of this preparation is to do an IPR poll.

 

This mail is to start the IPR poll.

 

Are you aware of any IPR that applies to draft-ie= tf-mpls-summary-frr-rsvpte?

 

If so, has this IPR been disclosed in compliance = with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).<= o:p>

 

There are no IPR disclosure directly against draf= t-ietf-mpls-summary-frr-rsvpte.

However, there is one IPR disclosure against the = individual document draft-mtaillon-mpls-summary-frr-rsvpte that preceded th= e working group document:

 

https://datatracker.ietf.org/ipr/2559/

 

If you are listed as a document author or contrib= utor please respond to this email regardless of whether or not you are awar= e of any relevant IPR. *The response needs to be sent to the MPLS WG mailin= g list.* The document will not advance to the next stage until a response has been received from each author and = contributor.

 

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

 

Best regards

 

   Nic

 

--_000_BN8PR06MB6289DE6E7423033F49EBAD9DFC430BN8PR06MB6289namp_-- From nobody Fri Mar 22 11:30:10 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F23131443; Fri, 22 Mar 2019 11:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_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 qrkeHhmttOjy; Fri, 22 Mar 2019 11:30:06 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 7EE59131446; Fri, 22 Mar 2019 11:30:06 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id g8so2090986pgf.2; Fri, 22 Mar 2019 11:30:06 -0700 (PDT) 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=8mu4cgEjvGq4KAKJTNai8uIIPMolrXDCCKp6skXU0ZY=; b=hutbng0f6LwCW8GNJpJWokfHwim0fPA/PNQYFi06TK4xbh89XzRKnKHBdEfkDRHsYX EsiiFgaHqAiW5715Lfy0fhhUZnL3zFnAbjQnimeOBp1yB4Uc9sXqIEweUC+SksYCIPJU 0cuINzhzgiQhJpppccsG/mRdUPp1Y8Ga/91uX3zWfSeataJ0C8hKpflWAIn+sek/e+7l sqy3OtY8kiJuWxHkg0BmrQij/r1hvKUDrUXNxBZT6RxDK3hzNHvhqM47BLYjNrlmhqAM BTRs0gmryPUkJdrOPuTuLa4xYd6I6WOgqYa9lqnOQEMMq6kxi6akYVh3pStGRXnSPpT5 h0TQ== 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=8mu4cgEjvGq4KAKJTNai8uIIPMolrXDCCKp6skXU0ZY=; b=HskUtwibjBPTNwb5lm/0knya+dzBJyFbXeahyB/cCOUQXepKSf+lVjy6yXfqwuA9rh SesxDvs8KNnNLn3CE0EitOjqOkNSaIIZUKJr0dvYpd4DG6E9kqEBq5VmWrW+DTfLjyoa 5y+P7QXYoaDMlXoVL3dQVzsQ2BY7mPl4T2CbNsAbjzx2pcVaXoZBYfP9MAffbhh5Yh0l mn+PNOiOSVH2o7YkskUxtA6yny8W89T2ravn8IEuxNl45DHuvvaqILTBnvTN8ZessjnV Ddafp60kdQU7kxv1f7ycb0fMXxh3/oWFvS55I3jVzZ6TSzbdT6yoo29iGMozc2SY+XGa jo8Q== X-Gm-Message-State: APjAAAXribyeu73qwazLvPE++aZ0DMRC8M4jihO8W5NgG52gy4R9yhu2 h+AEC5wa5UqtasjyiOEv9acGEIqHMVAGlCfga5BnJrWG X-Google-Smtp-Source: APXvYqxLuUn9rKPMx7i/bQw0aQLXuDVJSox1FlNahdPTUNDKGlic+ehUzxNXRVLUBSUP4VTYvQtZSPPffI6fjTPvt8s= X-Received: by 2002:aa7:8205:: with SMTP id k5mr10370451pfi.86.1553279406035; Fri, 22 Mar 2019 11:30:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vishnu Pavan Beeram Date: Fri, 22 Mar 2019 13:29:54 -0500 Message-ID: To: N.Leymann@telekom.de Cc: IETF MPLS List , draft-ietf-mpls-summary-frr-rsvpte@ietf.org, mpls-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000003bd8250584b30b07" Archived-At: Subject: Re: [mpls] IPR poll on draft-ietf-mpls-summary-frr-rsvpte X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 18:30:09 -0000 --0000000000003bd8250584b30b07 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, I=E2=80=99m aware of the IPR that applies to draft-ietf-mpls-summary-frr-rsvpte. And yes the IPR has been disclosed in compliance with IETF IPR rules. IPR -- https://datatracker.ietf.org/ipr/2559/ Regards, -Pavan On Fri, Mar 22, 2019 at 3:39 AM wrote: > Dear Working Group, > > > > We are currently preparing draft draft-ietf-mpls-summary-frr-rsvpte for > working group last call. > > > > Part of this preparation is to do an IPR poll. > > > > This mail is to start the IPR poll. > > > > Are you aware of any IPR that applies to > draft-ietf-mpls-summary-frr-rsvpte? > > > > If so, has this IPR been disclosed in compliance with IETF IPR rules (see > RFCs 3979, 4879, 3669 and 5378 for more details). > > > > There are no IPR disclosure directly against > draft-ietf-mpls-summary-frr-rsvpte. > > However, there is one IPR disclosure against the individual document > draft-mtaillon-mpls-summary-frr-rsvpte that preceded the working group > document: > > > > https://datatracker.ietf.org/ipr/2559/ > > > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant IPR= . > *The response needs to be sent to the MPLS WG mailing list.* The document > will not advance to the next stage until a response has been received fro= m > each author and contributor. > > > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > > > Best regards > > > > Nic > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --0000000000003bd8250584b30b07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, I=E2=80=99m aware of the IPR that applies to dra= ft-ietf-mpls-summary-frr-rsvpte.
And yes the IPR has been disclosed in= compliance with IETF IPR rules.
IPR -- https://datatracker.ietf.org/ipr/2559/=

Regards,
-Pavan

On Fri, Mar 22, 2019 at 3:39 AM <N.Leymann@telekom.de> wrote:

= Dear Working Group,

= =C2=A0

= We are currently preparing draft draft-ietf-mpls-summary-frr-rsvpte for wor= king group last call.

= =C2=A0

= Part of this preparation is to do an IPR poll.

= =C2=A0

= This mail is to start the IPR poll.

= =C2=A0

= Are you aware of any IPR that applies to draft-ietf-mpls-summary-frr-rsvpte= ?

= =C2=A0

= If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details).

= =C2=A0

= There are no IPR disclosure directly against draft-ietf-mpls-summary-frr-rs= vpte.

= However, there is one IPR disclosure against the individual document draft-= mtaillon-mpls-summary-frr-rsvpte that preceded the working group document:<= u>

= =C2=A0

= https:= //datatracker.ietf.org/ipr/2559/

= =C2=A0

= If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. *Th= e response needs to be sent to the MPLS WG mailing list.* The document will not advance to the next stage until a response has been received from= each author and contributor.

= =C2=A0

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

= =C2=A0

Best regards

=C2=A0<= /p>

=C2=A0=C2=A0 Nic

=C2=A0

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--0000000000003bd8250584b30b07-- From nobody Fri Mar 22 12:48:02 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0AB13132D; Fri, 22 Mar 2019 12:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.139 X-Spam-Level: X-Spam-Status: No, score=0.139 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, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=0.85, 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=juniper.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 1WlnixjV9SbS; Fri, 22 Mar 2019 12:47:59 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 407D01277D6; Fri, 22 Mar 2019 12:47:59 -0700 (PDT) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x2MJdNm5029209; Fri, 22 Mar 2019 12:47:58 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=TOcxqSsq+Y2iPxYtLnsqQAdFfac2W/lr5AXbcM0ImKQ=; b=AuqmvDzEd8XS8pvx5pWW/k9S1JwoYXBkegyKPk4RDc/CxdZFMdBhrZP6ASHWOgYFZe83 lFE5gTa31jmCPoV66MuKhGLu+j/Lpm72Mc+M6leEFPoGEMS+ZzcRCXHW+hRbN9bNkBul gTLpStdxIdJ+SIQU2fj3zVrlaH/lV/aUlJRjiiaiX1V+z/2cpMStIwEF4tB+UBHEuGZH ZSe6rBlCGrxu45plGKy48YoziUCAETKxyWz5sN05BIPgK2UCDzyGj3S08xgU4Ovpgd+H XTNfHfXlG/nCsPRT3jtKkLtTDQKiuiO0oVkY/nWRsD7AxX2WVG31dR7Feacgh3tgiW6g Ng== Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp2054.outbound.protection.outlook.com [104.47.32.54]) by mx0a-00273201.pphosted.com with ESMTP id 2rd5rkr13b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 22 Mar 2019 12:47:57 -0700 Received: from BYAPR05MB5109.namprd05.prod.outlook.com (20.177.231.15) by BYAPR05MB5222.namprd05.prod.outlook.com (20.177.231.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.14; Fri, 22 Mar 2019 19:47:55 +0000 Received: from BYAPR05MB5109.namprd05.prod.outlook.com ([fe80::7955:82de:5ea4:53d6]) by BYAPR05MB5109.namprd05.prod.outlook.com ([fe80::7955:82de:5ea4:53d6%5]) with mapi id 15.20.1750.010; Fri, 22 Mar 2019 19:47:55 +0000 From: Abhishek Deshmukh To: "N.Leymann@telekom.de" , "mpls@ietf.org" CC: "draft-ietf-mpls-summary-frr-rsvpte@ietf.org" , "tsaad.net@gmail.com" , "mpls-chairs@ietf.org" Thread-Topic: IPR poll on draft-ietf-mpls-summary-frr-rsvpte Thread-Index: AdTgipIrfmt/rAI/RAew/z067XwVGwAPAqoA Date: Fri, 22 Mar 2019 19:47:55 +0000 Message-ID: <66939B93-85BA-4354-ADB9-F84AF25998D7@juniper.net> 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.15.0.190117 x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5b8a9b79-5939-42b3-f014-08d6aeff473e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB5222; x-ms-traffictypediagnostic: BYAPR05MB5222: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 09840A4839 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(346002)(366004)(396003)(136003)(199004)(189003)(71190400001)(54896002)(71200400001)(236005)(6512007)(83716004)(97736004)(86362001)(6306002)(6486002)(2906002)(25786009)(53936002)(6506007)(11346002)(26005)(446003)(102836004)(53546011)(790700001)(6116002)(8676002)(3846002)(8936002)(81156014)(6436002)(106356001)(81166006)(186003)(2616005)(486006)(476003)(5660300002)(478600001)(36756003)(82746002)(606006)(2501003)(4743002)(68736007)(76176011)(105586002)(14454004)(33656002)(256004)(7736002)(229853002)(110136005)(4326008)(54906003)(316002)(66066001)(6246003)(99286004)(58126008)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5222; H:BYAPR05MB5109.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: r4XEDYlpIGWlpxboVp9M9dhenUXI1Y42O9KX8D50Ak2DoP0OIH2NhijmHlQD74GcITt1JmyAoeMe1QmVYYkM5GRcY4+ZhpQk6xZ/OC2c39XhrAqYHsb7fqsW18iY9I6Jwf3QkmWigiRY8oTjmmWsD5cFkUfbxALPHW8/ERlbT3oxAaqoy1HQEUMTqRy6mUj1UTvxE4f/I9V7pxqrc6Xo/zP3YOV1kWYa7tR10j6yyrGWWNl1ok7s1w2V0D3Ml3eeiK9HOWouEYSjZMAW5u4YaPVV4Lj1SrkkKd/5a6rb73dyO7lp4xx5TALUY7m5XSdd/GjWF6RPLeSY5lLEpdyOojhbFmYbBnaZr6ziiE7tdoJsKToAjFdD1iuHhbuTVbXeOR3zQ/2nTkaOtLmbGlbEDMANIoPhiMjYVC27TNPVdfs= Content-Type: multipart/alternative; boundary="_000_66939B9385BA4354ADB9F84AF25998D7junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 5b8a9b79-5939-42b3-f014-08d6aeff473e X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2019 19:47:55.3133 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5222 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-22_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903220140 Archived-At: Subject: Re: [mpls] IPR poll on draft-ietf-mpls-summary-frr-rsvpte X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 19:48:01 -0000 --_000_66939B9385BA4354ADB9F84AF25998D7junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLiBJIGFtIGF3YXJlIG9mIHRoZSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LWlldGYtbXBs cy1zdW1tYXJ5LWZyci1yc3ZwdGUuDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8y NTU5Lw0KDQpUaGUgYWJvdmUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdp dGggSUVURiBJUFIgcnVsZXMuDQoNClRoYW5rcywNCkFiaGlzaGVrDQoNCkZyb206ICJOLkxleW1h bm5AdGVsZWtvbS5kZSIgPE4uTGV5bWFubkB0ZWxla29tLmRlPg0KRGF0ZTogRnJpZGF5LCBNYXJj aCAyMiwgMjAxOSBhdCA0OjM4IEFNDQpUbzogIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3Jn Pg0KQ2M6ICJkcmFmdC1pZXRmLW1wbHMtc3VtbWFyeS1mcnItcnN2cHRlQGlldGYub3JnIiA8ZHJh ZnQtaWV0Zi1tcGxzLXN1bW1hcnktZnJyLXJzdnB0ZUBpZXRmLm9yZz4sICJ0c2FhZC5uZXRAZ21h aWwuY29tIiA8dHNhYWQubmV0QGdtYWlsLmNvbT4sICJtcGxzLWNoYWlyc0BpZXRmLm9yZyIgPG1w bHMtY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDogSVBSIHBvbGwgb24gZHJhZnQtaWV0Zi1tcGxz LXN1bW1hcnktZnJyLXJzdnB0ZQ0KUmVzZW50LUZyb206IDxhbGlhcy1ib3VuY2VzQGlldGYub3Jn Pg0KUmVzZW50LVRvOiA8bXRhaWxsb25AY2lzY28uY29tPiwgPHRzYWFkQGNpc2NvLmNvbT4sIDxy Z2FuZGhpQGNpc2NvLmNvbT4sIDxhZGVzaG11a2hAanVuaXBlci5uZXQ+LCBNYXJrdXMgSm9yayA8 bWpvcmtAanVuaXBlci5uZXQ+LCAidmJlZXJhbUBqdW5pcGVyLm5ldCIgPHZiZWVyYW1AanVuaXBl ci5uZXQ+DQpSZXNlbnQtRGF0ZTogRnJpZGF5LCBNYXJjaCAyMiwgMjAxOSBhdCA0OjM4IEFNDQoN Cg0KRGVhciBXb3JraW5nIEdyb3VwLA0KDQoNCg0KV2UgYXJlIGN1cnJlbnRseSBwcmVwYXJpbmcg ZHJhZnQgZHJhZnQtaWV0Zi1tcGxzLXN1bW1hcnktZnJyLXJzdnB0ZSBmb3Igd29ya2luZyBncm91 cCBsYXN0IGNhbGwuDQoNCg0KDQpQYXJ0IG9mIHRoaXMgcHJlcGFyYXRpb24gaXMgdG8gZG8gYW4g SVBSIHBvbGwuDQoNCg0KDQpUaGlzIG1haWwgaXMgdG8gc3RhcnQgdGhlIElQUiBwb2xsLg0KDQoN Cg0KQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdC1pZXRmLW1w bHMtc3VtbWFyeS1mcnItcnN2cHRlPw0KDQoNCg0KSWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRp c2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5Nzks IDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuDQoNCg0KDQpUaGVyZSBhcmUg bm8gSVBSIGRpc2Nsb3N1cmUgZGlyZWN0bHkgYWdhaW5zdCBkcmFmdC1pZXRmLW1wbHMtc3VtbWFy eS1mcnItcnN2cHRlLg0KDQpIb3dldmVyLCB0aGVyZSBpcyBvbmUgSVBSIGRpc2Nsb3N1cmUgYWdh aW5zdCB0aGUgaW5kaXZpZHVhbCBkb2N1bWVudCBkcmFmdC1tdGFpbGxvbi1tcGxzLXN1bW1hcnkt ZnJyLXJzdnB0ZSB0aGF0IHByZWNlZGVkIHRoZSB3b3JraW5nIGdyb3VwIGRvY3VtZW50Og0KDQoN Cg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMjU1OS88aHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9y Z19pcHJfMjU1OV8mZD1Ed01GQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3Zv RFRYY1d6b0NJJnI9Nzd3cW5ZS0NuaWhrLXhBWloyTTVJRkNvZnNUWWwzSVotUWIxV21WeGx1VSZt PTRfaFV6eUt6ZXo3alhkZHZjSUFoRlRER2pBYm10VXJRVF9Yc0Q1MDNnc1Emcz1VRm5saVZRai0t c2IwNFdCN0NUcmg3T3JCUy1DczBXdnNFVlN3NGt4d1lVJmU9Pg0KDQoNCg0KSWYgeW91IGFyZSBs aXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQg dG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUg b2YgYW55IHJlbGV2YW50IElQUi4gKlRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBzZW50IHRvIHRo ZSBNUExTIFdHIG1haWxpbmcgbGlzdC4qIFRoZSBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRv IHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBl YWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IuDQoNCg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBNUExT IFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250cmli dXRvciwgdGhlbiBwbGVhc2UgZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2Fy ZSBvZiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFu Y2Ugd2l0aCBJRVRGIHJ1bGVzLg0KDQoNCg0KQmVzdCByZWdhcmRzDQoNCg0KDQogICBOaWMNCg0K --_000_66939B9385BA4354ADB9F84AF25998D7junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9y bWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0K cC5OdXJUZXh0LCBsaS5OdXJUZXh0LCBkaXYuTnVyVGV4dA0KCXttc28tc3R5bGUtbmFtZToiTnVy IFRleHQiOw0KCW1zby1zdHlsZS1saW5rOiJOdXIgVGV4dCBaY2huIjsNCgltYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uTnVyVGV4dFpjaG4NCgl7bXNvLXN0eWxlLW5h bWU6Ik51ciBUZXh0IFpjaG4iOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiTnVyIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46NzAuODVwdCA3MC44 NXB0IDU2LjdwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5r PSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5ZZXMuIEkgYW0gYXdhcmUgb2YgdGhlIElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtaWV0 Zi1tcGxzLXN1bW1hcnktZnJyLXJzdnB0ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzI1NTkvIj5o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8yNTU5LzwvYT48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlIGFib3ZlIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3 aXRoIElFVEYgSVBSIHJ1bGVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BYmhpc2hlazxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+JnF1b3Q7Ti5MZXltYW5uQHRlbGVrb20uZGUmcXVv dDsgJmx0O04uTGV5bWFubkB0ZWxla29tLmRlJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXks IE1hcmNoIDIyLCAyMDE5IGF0IDQ6MzggQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90O21wbHNAaWV0 Zi5vcmcmcXVvdDsgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtk cmFmdC1pZXRmLW1wbHMtc3VtbWFyeS1mcnItcnN2cHRlQGlldGYub3JnJnF1b3Q7ICZsdDtkcmFm dC1pZXRmLW1wbHMtc3VtbWFyeS1mcnItcnN2cHRlQGlldGYub3JnJmd0OywgJnF1b3Q7dHNhYWQu bmV0QGdtYWlsLmNvbSZxdW90OyAmbHQ7dHNhYWQubmV0QGdtYWlsLmNvbSZndDssICZxdW90O21w bHMtY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDttcGxzLWNoYWlyc0BpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+SVBSIHBvbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXN1bW1hcnktZnJy LXJzdnB0ZSA8YnI+DQo8Yj5SZXNlbnQtRnJvbTogPC9iPiZsdDthbGlhcy1ib3VuY2VzQGlldGYu b3JnJmd0Ozxicj4NCjxiPlJlc2VudC1UbzogPC9iPiZsdDttdGFpbGxvbkBjaXNjby5jb20mZ3Q7 LCAmbHQ7dHNhYWRAY2lzY28uY29tJmd0OywgJmx0O3JnYW5kaGlAY2lzY28uY29tJmd0OywgJmx0 O2FkZXNobXVraEBqdW5pcGVyLm5ldCZndDssIE1hcmt1cyBKb3JrICZsdDttam9ya0BqdW5pcGVy Lm5ldCZndDssICZxdW90O3ZiZWVyYW1AanVuaXBlci5uZXQmcXVvdDsgJmx0O3ZiZWVyYW1AanVu aXBlci5uZXQmZ3Q7PGJyPg0KPGI+UmVzZW50LURhdGU6IDwvYj5GcmlkYXksIE1hcmNoIDIyLCAy MDE5IGF0IDQ6MzggQU08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+RGVhciBXb3JraW5nIEdyb3VwLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5XZSBhcmUgY3VycmVudGx5IHByZXBhcmluZyBkcmFmdCBkcmFmdC1pZXRmLW1wbHMt c3VtbWFyeS1mcnItcnN2cHRlIGZvciB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbC48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+UGFydCBvZiB0aGlzIHByZXBhcmF0aW9uIGlzIHRvIGRvIGFu IElQUiBwb2xsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGlzIG1haWwgaXMgdG8g c3RhcnQgdGhlIElQUiBwb2xsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BcmUgeW91 IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LWlldGYtbXBscy1zdW1tYXJ5 LWZyci1yc3ZwdGU/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPklmIHNvLCBoYXMgdGhp cyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChz ZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGVyZSBhcmUgbm8gSVBSIGRpc2Nsb3N1cmUgZGly ZWN0bHkgYWdhaW5zdCBkcmFmdC1pZXRmLW1wbHMtc3VtbWFyeS1mcnItcnN2cHRlLg0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Ib3dldmVyLCB0aGVyZSBpcyBvbmUg SVBSIGRpc2Nsb3N1cmUgYWdhaW5zdCB0aGUgaW5kaXZpZHVhbCBkb2N1bWVudCBkcmFmdC1tdGFp bGxvbi1tcGxzLXN1bW1hcnktZnJyLXJzdnB0ZSB0aGF0IHByZWNlZGVkIHRoZSB3b3JraW5nIGdy b3VwIGRvY3VtZW50OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFj a2VyLmlldGYub3JnX2lwcl8yNTU5XyZhbXA7ZD1Ed01GQWcmYW1wO2M9SEFrWXVoNjNyc3VocjZT Y2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj03N3dxbllLQ25paGsteEFaWjJNNUlG Q29mc1RZbDNJWi1RYjFXbVZ4bHVVJmFtcDttPTRfaFV6eUt6ZXo3alhkZHZjSUFoRlRER2pBYm10 VXJRVF9Yc0Q1MDNnc1EmYW1wO3M9VUZubGlWUWotLXNiMDRXQjdDVHJoN09yQlMtQ3MwV3ZzRVZT dzRreHdZVSZhbXA7ZT0iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzI1NTkvPC9h Pg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPklmIHlvdSBhcmUgbGlzdGVkIGFzIGEg ZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1h aWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxl dmFudCBJUFIuICpUaGUgcmVzcG9uc2UgbmVlZHMgdG8gYmUgc2VudCB0byB0aGUgTVBMUyBXRyBt YWlsaW5nIGxpc3QuKiBUaGUgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZQ0KIHRvIHRoZSBuZXh0 IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhv ciBhbmQgY29udHJpYnV0b3IuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPklmIHlvdSBh cmUgb24gdGhlIE1QTFMgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0 aG9yIG9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBp ZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3Nl ZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPkJlc3QgcmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsgTmljPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_66939B9385BA4354ADB9F84AF25998D7junipernet_-- From nobody Sun Mar 24 01:07:57 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0E61277D8; Sun, 24 Mar 2019 01:07:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mpls@ietf.org Message-ID: <155341486813.18050.6996601374801740784@ietfa.amsl.com> Date: Sun, 24 Mar 2019 01:07:48 -0700 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-sfc-encapsulation-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 08:07:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching WG of the IETF. Title : MPLS Transport Encapsulation For The SFC NSH Authors : Andrew G. Malis Stewart Bryant Joel M. Halpern Wim Henderickx Filename : draft-ietf-mpls-sfc-encapsulation-04.txt Pages : 8 Date : 2019-03-24 Abstract: This document describes how to use a Service Function Forwarder (SFF) Label (similar to a pseudowire label or VPN label) to indicate the presence of a Service Function Chaining (SFC) Network Service Header (NSH) between an MPLS label stack and the packet original packet/ frame. This allows SFC packets using the NSH to be forwarded between SFFs over an MPLS network, and to select one of multiple SFFs in the destination MPLS node. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-sfc-encapsulation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mpls-sfc-encapsulation-04 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-sfc-encapsulation-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-sfc-encapsulation-04 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 Mar 24 01:09:47 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C211277D8; Sun, 24 Mar 2019 01:09:46 -0700 (PDT) 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-mpls-sfc-encapsulation@ietf.org, Loa Andersson , mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155341498609.18034.796489937039984336.idtracker@ietfa.amsl.com> Date: Sun, 24 Mar 2019 01:09:46 -0700 Archived-At: Subject: [mpls] Benjamin Kaduk's No Objection on draft-ietf-mpls-sfc-encapsulation-04: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 08:09:46 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-mpls-sfc-encapsulation-04: 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-mpls-sfc-encapsulation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for resolving my DISCUSS point! From nobody Sun Mar 24 02:17:00 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A526130E9F; Sun, 24 Mar 2019 02:16:38 -0700 (PDT) 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.94.1 Auto-Submitted: auto-generated Precedence: bulk Cc: mpls@ietf.org, db3546@att.com, The IESG , draft-ietf-mpls-sfc-encapsulation@ietf.org, mpls-chairs@ietf.org, Loa Andersson , rfc-editor@rfc-editor.org, loa@pi.nu Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155341899842.18030.7112922807127018715.idtracker@ietfa.amsl.com> Date: Sun, 24 Mar 2019 02:16:38 -0700 Archived-At: Subject: [mpls] Document Action: 'MPLS Encapsulation For The SFC NSH' to Informational RFC (draft-ietf-mpls-sfc-encapsulation-04.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 09:16:46 -0000 The IESG has approved the following document: - 'MPLS Encapsulation For The SFC NSH' (draft-ietf-mpls-sfc-encapsulation-04.txt) as Informational RFC This document is the product of the Multiprotocol Label Switching 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-mpls-sfc-encapsulation/ Technical Summary This document describes how to use a Service Function Forwarder (SFF) Label (similar to a pseudowire label or VPN label) to indicate the presence of a Service Function Chaining (SFC) Network Service Header (NSH) between an MPLS label stack and the packet original packet/frame. This allows SFC packets using the NSH to be forwarded between SFFs over an MPLS network, and to select one of multiple SFFs in the destination MPLS node. Working Group Summary The working group process has been swift and there is strong support for the document. Document Quality This informational document follows well-established MPLS procedures and does not require any actions by IANA or any new protocol extensions. Personnel Who is the Document Shepherd for this document? Loa Andersson Who is the Responsible Area Director? Deborah Brungard From nobody Mon Mar 25 01:33:25 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63DE120687 for ; Mon, 25 Mar 2019 01:33:19 -0700 (PDT) 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 Hm4vwCfX3SeX for ; Mon, 25 Mar 2019 01:33:17 -0700 (PDT) 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 E938212037B for ; Mon, 25 Mar 2019 01:32:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7BE11B81A3D; Mon, 25 Mar 2019 01:32:17 -0700 (PDT) To: loa@pi.se, ina@juniper.net, rhthomas@cisco.com, db3546@att.com, aretana.ietf@gmail.com, martin.vigoureux@nokia.com, loa@pi.nu, n.leymann@telekom.de X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: ramakrishnadtv@gmail.com, mpls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190325083217.7BE11B81A3D@rfc-editor.org> Date: Mon, 25 Mar 2019 01:32:17 -0700 (PDT) Archived-At: Subject: [mpls] [Editorial Errata Reported] RFC5036 (5674) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 08:33:24 -0000 The following errata report has been submitted for RFC5036, "LDP Specification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5674 -------------------------------------- Type: Editorial Reported by: Ramakrishna Rao DTV Section: A.2.8 Original Text ------------- - FEC. The FEC for which a label request is to be sent. Corrected Text -------------- - FEC. The FEC for which a label mapping is to be sent. Notes ----- Prepare_Label_Mapping_Attributes is used for sending label mapping message and NOT label request message. 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. -------------------------------------- RFC5036 (draft-ietf-mpls-rfc3036bis-04) -------------------------------------- Title : LDP Specification Publication Date : October 2007 Author(s) : L. Andersson, Ed., I. Minei, Ed., B. Thomas, Ed. Category : DRAFT STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon Mar 25 01:45:36 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFDEC1203F6 for ; Mon, 25 Mar 2019 01:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 YaUgTi8JejQr for ; Mon, 25 Mar 2019 01:45:03 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 A56851203BE for ; Mon, 25 Mar 2019 01:45:03 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id k189so4818537qkc.0 for ; Mon, 25 Mar 2019 01:45:03 -0700 (PDT) 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=J8ZV/TEhWb54Jv5kJUY+6gzQFcV+XTbX9cgtU7ZQxuE=; b=an4992z3sun5xsRKwAJngP/rS90+LsSiWUyqgg8JtRsyA1c16JbhmyE2D9JAsXvCYx cr6pK59EHlwAvrndRKIW0z28LK0fLNPfrTsf7SqSjiYHQjNbK+CPMsY6XpptPcXhYPms OTWipKIWbSllrekm8BBuQj7tVssWflFHgYeIIPY946Sgh1lt5mAnoNYciiLkctdef2FC 0mZALaw9VKJ7GIoWiMcw7HwzQ5Ur2FHh27/o/fAV6i4C20812TpDwidiGbDirDuupoUv bdtwvI6mpXLDwCguSrpdCGGCteUlPA8Mo5HxuKHoMkdF6bLBGFcRiA3p7YdOmA7P7ydb 8wxw== 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=J8ZV/TEhWb54Jv5kJUY+6gzQFcV+XTbX9cgtU7ZQxuE=; b=bNsKRXWpONDiasTSRaf9lvNK2QzEbLesBOKSm/hP6ul6OuFx1qh0RtVCMq5aNQ8hez fCneaCnxMTZ9a1r/ACFNMTMamtHDmVtWSk2R7+z9d5NY8SXmyY6OlKW9qB/PXHXzzber UZePRZ+t+CPRcnS9fjUndLJtSKol07Clh2KVedoZC8hA02ZJs//u7dF72T1DZ41+lusR L9SU5twkYJgy1VGc2ThGpD3wRME+muc3S0mP0oZPZ09jjXYPOXORfhsgM27eEFn1CMJT zmygJbd/0vC4YA3xOh7O04wUQ3oB+V3k/GSuRygokz34qeGEoqMuflbXVGu54z81pY+w ErFA== X-Gm-Message-State: APjAAAVPH+9R+fw23IwUBzHn2K+dgVLExxfHr5UGe4ueBhqn2I/NGB26 zVinut5mKSsfLcu7GEjKx73pxdAOrwd+7DjMUU8= X-Google-Smtp-Source: APXvYqyxzRbtKKJ4WeYhaaCYZgRR76taadLu2PuL1tylRtfnkKlfEZNfvPWaEfH2TortjMkz81o7i3G6uDKtLySX7Sg= X-Received: by 2002:a37:acc:: with SMTP id 195mr17677916qkk.231.1553503502634; Mon, 25 Mar 2019 01:45:02 -0700 (PDT) MIME-Version: 1.0 References: <20190325083217.7BE11B81A3D@rfc-editor.org> In-Reply-To: <20190325083217.7BE11B81A3D@rfc-editor.org> From: "Andrew G. Malis" Date: Mon, 25 Mar 2019 09:44:51 +0100 Message-ID: To: RFC Errata System Cc: loa@pi.se, ina@juniper.net, rhthomas@cisco.com, "BRUNGARD, DEBORAH A (ATTLABS)" , Alvaro Retana , Martin Vigoureux , Loa Andersson , Nicolai Leymann , mpls , ramakrishnadtv@gmail.com Content-Type: multipart/alternative; boundary="0000000000006e988e0584e73887" Archived-At: Subject: Re: [mpls] [Editorial Errata Reported] RFC5036 (5674) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 08:45:16 -0000 --0000000000006e988e0584e73887 Content-Type: text/plain; charset="UTF-8" I agree, this was obviously a copy/paste error from the previous section. Cheers, Andy On Mon, Mar 25, 2019 at 9:34 AM RFC Errata System wrote: > The following errata report has been submitted for RFC5036, > "LDP Specification". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5674 > > -------------------------------------- > Type: Editorial > Reported by: Ramakrishna Rao DTV > > Section: A.2.8 > > Original Text > ------------- > - FEC. The FEC for which a label request is to be sent. > > > Corrected Text > -------------- > - FEC. The FEC for which a label mapping is to be sent. > > > Notes > ----- > Prepare_Label_Mapping_Attributes is used for sending label mapping message > and > NOT label request message. > > 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. > > -------------------------------------- > RFC5036 (draft-ietf-mpls-rfc3036bis-04) > -------------------------------------- > Title : LDP Specification > Publication Date : October 2007 > Author(s) : L. Andersson, Ed., I. Minei, Ed., B. Thomas, Ed. > Category : DRAFT STANDARD > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --0000000000006e988e0584e73887 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree, this was obviously a copy/paste error from the pr= evious section.

Cheers,
Andy


On Mon, Mar 25, 2019 at 9:34 AM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The following errata re= port has been submitted for RFC5036,
"LDP Specification".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5674

--------------------------------------
Type: Editorial
Reported by: Ramakrishna Rao DTV <ramakrishnadtv@gmail.com>

Section: A.2.8

Original Text
-------------
-=C2=A0 FEC.=C2=A0 The FEC for which a label request is to be sent.


Corrected Text
--------------
-=C2=A0 FEC.=C2=A0 The FEC for which a label mapping is to be sent.


Notes
-----
Prepare_Label_Mapping_Attributes is used for sending label mapping message = and
NOT label request message.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5036 (draft-ietf-mpls-rfc3036bis-04)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: LDP Specifica= tion
Publication Date=C2=A0 =C2=A0 : October 2007
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: L. Andersson, Ed., I. M= inei, Ed., B. Thomas, Ed.
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : DRAFT STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Multiprotocol Labe= l Switching
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Routing
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--0000000000006e988e0584e73887-- From nobody Mon Mar 25 01:48:00 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8311A120373 for ; Mon, 25 Mar 2019 01:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Rm5Zoj0ZC2iq for ; Mon, 25 Mar 2019 01:47:56 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 2AC72120379 for ; Mon, 25 Mar 2019 01:47:56 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id k2so9352770qtm.1 for ; Mon, 25 Mar 2019 01:47:56 -0700 (PDT) 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=IUOlKVh1WYNB8P2JM/9mo0Xt1ZyboXqxLGc2iVPLQ3I=; b=DjKnN3e1ACagSVpjFA5EDLnnvlu98ro+qb6vZZqth5yU9FoGn8S3vjLwaUK3Y6u9jp udpHaOTvX+5gBCwRzInPQe0KfKxVDwsIHZpSOGmL4ZmI0FKNVtNugEWU2RfRLOl9xyf3 izKmOEGrYifWX8O/vFntTRHzGQlmcJk/9ZwgOhAinqQZAdM8YQEm5B8dFm7MZ1ogOe/e yTIZvTWgLvR3oCxFt57UrMaR6GC5IQiC4Om5rjIHWh/dmQ10X+9U3GDZSmZCorRizAlO gswICfaH+CUBDzVGAtAAlmyUs0GJqZW1Pk/Cfa1AMi5/5VSbgxKWMVvxr/d2Hl731N7J 3yvA== 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=IUOlKVh1WYNB8P2JM/9mo0Xt1ZyboXqxLGc2iVPLQ3I=; b=NaAdYfkBlgNvcQKGxwEWwo+m9LWP42Fwb09S7tQPG4qPW76733NdrUSj6wUo1+sc/+ 0ZIfcppO0z8aQTj53SaRJ6IezoGv/OyDRMVp7vQ3wiyLvDAtm5rKvqdsozz/bcl37TFT zmguRLgeB3dQsFYiKDrWwiPX9OMXcgi+hjoLIfaR2uFRw2W1RNsSk4D8qnMJkIK1a29P DeHBfaX3wJrXp+U4qpJIEQM46DM/guJhnnmB7HxTCUW/GcFQfE77SJQE5OQD8puLnnSF gPoqYfe+KZJkofIqjERF/c16AeOzxWE3Hbi1FMhPoref9KNcG6Ue2+nEwibZCtHaaJh4 093w== X-Gm-Message-State: APjAAAVsB2DYabUDtKqIX5gDgnfRtK7CMNsC5XTVBlS88WWKYNIwNcoo YdeOn4bP9iCa04B2Ya/Y/TO2TPS9iLOiRnri46o= X-Google-Smtp-Source: APXvYqyksg9GHntUbzl1nE36RFtMy354xCcyA1dN5c2R9sU0hzXQM+zalmopynXCUdI7aNzCd6b/3VPFUrAla0Z1hek= X-Received: by 2002:a0c:d7c2:: with SMTP id g2mr18051490qvj.90.1553503675355; Mon, 25 Mar 2019 01:47:55 -0700 (PDT) MIME-Version: 1.0 References: <20190325083217.7BE11B81A3D@rfc-editor.org> In-Reply-To: From: "Andrew G. Malis" Date: Mon, 25 Mar 2019 09:47:44 +0100 Message-ID: To: RFC Errata System Cc: "BRUNGARD, DEBORAH A (ATTLABS)" , Alvaro Retana , Martin Vigoureux , Loa Andersson , Nicolai Leymann , mpls , ramakrishnadtv@gmail.com, Ina Minei Content-Type: multipart/alternative; boundary="000000000000ba18910584e7423b" Archived-At: Subject: Re: [mpls] [Editorial Errata Reported] RFC5036 (5674) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 08:47:59 -0000 --000000000000ba18910584e7423b Content-Type: text/plain; charset="UTF-8" Resent to update Ina's email address. Cheers, Andy On Mon, Mar 25, 2019 at 9:44 AM Andrew G. Malis wrote: > I agree, this was obviously a copy/paste error from the previous section. > > Cheers, > Andy > > > On Mon, Mar 25, 2019 at 9:34 AM RFC Errata System < > rfc-editor@rfc-editor.org> wrote: > >> The following errata report has been submitted for RFC5036, >> "LDP Specification". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5674 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Ramakrishna Rao DTV >> >> Section: A.2.8 >> >> Original Text >> ------------- >> - FEC. The FEC for which a label request is to be sent. >> >> >> Corrected Text >> -------------- >> - FEC. The FEC for which a label mapping is to be sent. >> >> >> Notes >> ----- >> Prepare_Label_Mapping_Attributes is used for sending label mapping >> message and >> NOT label request message. >> >> 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. >> >> -------------------------------------- >> RFC5036 (draft-ietf-mpls-rfc3036bis-04) >> -------------------------------------- >> Title : LDP Specification >> Publication Date : October 2007 >> Author(s) : L. Andersson, Ed., I. Minei, Ed., B. Thomas, Ed. >> Category : DRAFT STANDARD >> Source : Multiprotocol Label Switching >> Area : Routing >> Stream : IETF >> Verifying Party : IESG >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > --000000000000ba18910584e7423b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Resent to update Ina's email address.

Cheers,
Andy


On Mon, Mar 25, 2019 at 9:44 = AM Andrew G. Malis <agmalis@gmail.c= om> wrote:
I agree, this was obviously a copy/paste error from the = previous section.

Cheers,
Andy

<= /div>

On Mon, Mar 25, 2019 at 9:34 AM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The= following errata report has been submitted for RFC5036,
"LDP Specification".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5674

--------------------------------------
Type: Editorial
Reported by: Ramakrishna Rao DTV <ramakrishnadtv@gmail.com>

Section: A.2.8

Original Text
-------------
-=C2=A0 FEC.=C2=A0 The FEC for which a label request is to be sent.


Corrected Text
--------------
-=C2=A0 FEC.=C2=A0 The FEC for which a label mapping is to be sent.


Notes
-----
Prepare_Label_Mapping_Attributes is used for sending label mapping message = and
NOT label request message.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5036 (draft-ietf-mpls-rfc3036bis-04)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: LDP Specifica= tion
Publication Date=C2=A0 =C2=A0 : October 2007
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: L. Andersson, Ed., I. M= inei, Ed., B. Thomas, Ed.
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : DRAFT STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Multiprotocol Labe= l Switching
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Routing
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--000000000000ba18910584e7423b-- From nobody Mon Mar 25 04:49:21 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5092D120401; Mon, 25 Mar 2019 04:49:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mpls@ietf.org Message-ID: <155351455321.29037.9117485610609112203@ietfa.amsl.com> Date: Mon, 25 Mar 2019 04:49:13 -0700 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-rfc8287-len-clarification-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 11:49:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching WG of the IETF. Title : RFC8287 Sub-TLV Length Clarification Authors : Nagendra Kumar Nainar Carlos Pignataro Faisal Iqbal Alexander Vainshtein Filename : draft-ietf-mpls-rfc8287-len-clarification-00.txt Pages : 6 Date : 2019-03-25 Abstract: RFC8287 defines the extensions to MPLS LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifier (SIDs) with an MPLS data plane. RFC8287 proposes 3 Target FEC Stack Sub-TLVs. While the standard defines the format and procedure to handle those Sub-TLVs, it does not sufficiently clarify how the length of the Segment ID Sub-TLVs should be computed to include in the Length field of the Sub-TLVs which may result in interoperability issues. This document updates RFC8287 by clarifying the length of each Segment ID Sub-TLVs defined in RFC8287. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc8287-len-clarification/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mpls-rfc8287-len-clarification-00 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-rfc8287-len-clarification-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 25 08:08:26 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2B9120498; Mon, 25 Mar 2019 08:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 WQ3j8ACXsr_6; Mon, 25 Mar 2019 08:08:19 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE92812041D; Mon, 25 Mar 2019 08:08:18 -0700 (PDT) Received: from [31.133.130.12] (dhcp-820c.meeting.ietf.org [31.133.130.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 305C133F68D; Mon, 25 Mar 2019 16:08:17 +0100 (CET) From: Loa Andersson To: "mpls@ietf.org" Cc: "mpls-chairs@ietf.org" , "draft-zheng-mpls-lsp-ping-yang-cfg@ietf.org" References: <98db7e71-6152-1335-8ca0-b5ae67b8a4b6@pi.nu> Message-ID: <4328e121-8406-e28a-1937-327d0a762a84@pi.nu> Date: Mon, 25 Mar 2019 16:08:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: <98db7e71-6152-1335-8ca0-b5ae67b8a4b6@pi.nu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] Closed: Working Group Adoption Poll on draft-zheng-mpls-lsp-ping-yang-cfg X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 15:08:25 -0000 Working Group, We will discuss draft-zheng-mpls-lsp-ping-yang-cfg at our f2f meeting on Wednesday. The intention is to see if we can find a way forward. We normally do not discuss documents that are in some type of review. The wgap is therefore closed. /Loa On 2019-02-20 06:35, Loa Andersson wrote: > Working Group, > > This is to start a two week poll on adopting > draft-zheng-mpls-lsp-ping-yang-cfg-10 > as a MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > We have done an IPR poll for this document. All the co-authors have > responded to the IPR poll that they are unaware of any IPRs that relates > to this draft. > > All, the contributors (with one exception) have responded to the IPR > poll that they are unaware of any IPRs that relates to this draft. > > The contributor that has not responded has left his former employment > and is no longer on the MPLS wg mailing list. The wg chairs has decided > to go ahead with the wgap. If there is any concerns about this, please > speak up in the mailing list. > > There are no IPR disclosures against this document. > > The working group adoption poll ends March 6, 2019. > > /Loa > > mpls wg co-chair -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Tue Mar 26 02:56:54 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F13801202C1; Tue, 26 Mar 2019 02:56:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: Cc: Martin Vigoureux , Deborah Brungard , Vishnu Beeram , Multiprotocol Label Switching Discussion List , Adrian Farrel , Scott Mansfield , Dhruv Dhody , Path Computation Element Discussion List , Nicolai Leymann , John Drake , Alvaro Retana , Daniele Ceccarelli , Loa Andersson , Lou Berger , Common Control and Measurement Plane Discussion List , Fatai Zhang , scott.mansfield@ericsson.com, itu-t-liaison@iab.org, Traffic Engineering Architecture and Signaling Discussion List , Julien Meuric X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155359419797.20696.5453093815420919008.idtracker@ietfa.amsl.com> Date: Tue, 26 Mar 2019 02:56:37 -0700 Archived-At: Subject: [mpls] New Liaison Statement, "Reply to LS on OTNT Standardization Work Plan" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 09:56:45 -0000 Title: Reply to LS on OTNT Standardization Work Plan Submission Date: 2019-03-26 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1636/ From: Scott Mansfield To: hiroshi.ota@itu.int Cc: John Drake ,Deborah Brungard ,Julien Meuric ,Multiprotocol Label Switching Discussion List ,Adrian Farrel ,Scott Mansfield ,Fatai Zhang ,Vishnu Beeram ,Path Computation Element Discussion List ,Traffic Engineering Architecture and Signaling Discussion List ,Martin Vigoureux ,Alvaro Retana ,Daniele Ceccarelli ,Dhruv Dhody ,Loa Andersson ,Lou Berger ,Common Control and Measurement Plane Discussion List ,itu-t-liaison@iab.org,Nicolai Leymann ,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. Below is a list of the recent RFCs and working group drafts related to OTNT. * Recent Relevant RFC * RFC8282 * Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering * https://datatracker.ietf.org/doc/rfc8282/ * RFC8283 * An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control * https://datatracker.ietf.org/doc/rfc8283/ * RFC8363 * GMPLS OSPF-TE Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks * https://datatracker.ietf.org/doc/rfc8363/ * RFC8413 * Framework for Scheduled Use of Resources * https://datatracker.ietf.org/doc/rfc8413/ * RFC 8453 * Framework for Abstraction and Control of TE Networks (ACTN) * https://datatracker.ietf.org/doc/rfc8453/ * RFC 8469 * Recommendation to Use the Ethernet Control Word * https://datatracker.ietf.org/doc/rfc8469/ * Working Group Updates * Common Control and Measurement Plane (ccamp) * A framework for Management and Control of DWDM optical interface parameters * https://datatracker.ietf.org/doc/draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk/ * YANG data model for Flexi-Grid media-channels * https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexigrid-media-channel-ya ng/ * YANG data model for Flexi-Grid Optical Networks * https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexigrid-yang/ * Applicability of GMPLS for B100G Optical Transport Network * https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-otn-b100g-applicabil ity/ * A YANG Data Model for L1 Connectivity Service Model (L1CSM) * https://datatracker.ietf.org/doc/draft-ietf-ccamp-l1csm-yang/ * A YANG Data Model for Optical Transport Network Topology * https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-topo-yang/ * OTN Tunnel YANG Model * https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-tunnel-model/ * Information Encoding for WSON with Impairments Validation * https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-iv-encode/ * Information Model for Wavelength Switched Optical Networks (WSONs) with Impairments Validation * https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-iv-info/ * A Yang Data Model for WSON Tunnel * https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-tunnel-model/ * A YANG Data Model for WSON (Wavelength Switched Optical Networks) * https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-yang/ * Path Computation Element (pce) * PCEP Extension for WSON Routing and Wavelength Assignment * https://datatracker.ietf.org/doc/draft-ietf-pce-wson-rwa-ext/ * PCEP extensions for GMPLS * https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/ * PCEP Extension for Flexible Grid Networks * https://datatracker.ietf.org/doc/draft-ietf-pce-flexible-grid/ * Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS-controlled Networks * https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-stateful-pce-gmpls/ * Path Computation Element Communication Protocol (PCEP) Extensions for remote-initiated GMPLS LSP Setup * https://datatracker.ietf.org/doc/draft-ietf-pce-remote-initiated-gmpls-lsp/ 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) , Adrian Farrel (PCE Chair), Julien Meuric (PCE Chair), Vishnu Beeram (TEAS Chair), Lou Berger (TEAS Chair), Loa Andersson (MPLS Chair), Nicolai Leymann (MPLS Chair), and Scott Mansfield (IETF's ITU-T Liaison) Attachments: No document has been attached From nobody Tue Mar 26 09:34:21 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773B01205E0; Tue, 26 Mar 2019 09:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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=KsQ86MOh; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=iNcZr9M4 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 3CRBJAn7E1Es; Tue, 26 Mar 2019 09:34:15 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC4B41205D6; Tue, 26 Mar 2019 09:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15781; q=dns/txt; s=iport; t=1553618051; x=1554827651; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ds6qIrcNsmEEFcyexEgSSxLfhSkPOre+Ka+jL3xFNbQ=; b=KsQ86MOhrSynNP6PfKxcagS64eY4XR4Ns9Z1Ts2ttyDLW5qrVUmBwaPC 77dBpRJrOaBvU+f9JSFpG4a6aZcQwP6XdoRULtNcEoFWlK0ksiTPh8TdR bY+AWHabrDrHSRbIqNrIlItSmKKiCRCZUYAc0d1gr/tlSGYh9vsXFvXtr I=; IronPort-PHdr: =?us-ascii?q?9a23=3ASKGwDRx9UPSWBsbXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhSN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZufBkT9IP7rRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAADHU5pc/4YNJK1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYEPL1ADaHQECyeEDoNHA48tgleJOIkMhEmBQoEQA1Q?= =?us-ascii?q?NAQEfDYRAAheFCyI4EgEBAwEBCQEDAm0cDIVKAQEBBCMdAQEsBgUBDwIBCBE?= =?us-ascii?q?DAQIrAgICHxEbAQEFAwEBBAENBYMiAYERTAMVAQIMojMCihRxgS8fglkBAQW?= =?us-ascii?q?BMQGDUQ0LggwDBYEvizIXgUA/gTgfgkw+ghpHAgOBJgUBEQIBNQkNgl0xgia?= =?us-ascii?q?KLYJGhCGTUjYJAodhiBqDPhmCAoV9jAOKSglKhgaBOotyAgQCBAUCDgEBBYF?= =?us-ascii?q?kIWVxcBU7KgGCQYIKg26EWTuFP3KBKI8UAQE?= X-IronPort-AV: E=Sophos;i="5.60,273,1549929600"; d="scan'208,217";a="540041677" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 16:34:10 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x2QGYA4B004722 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Mar 2019 16:34:10 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 11:34:09 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 11:34:08 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 26 Mar 2019 11:34:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ds6qIrcNsmEEFcyexEgSSxLfhSkPOre+Ka+jL3xFNbQ=; b=iNcZr9M461tDce2sDQjsvINfJWDCF8I6wMjkg9rjEArFCki/NCk3m6eh0Bso2bhuyL6q7XsQ9wFNqWQSz8My8OfMpireMVDji9IDdZCsMWsnzNuaRAKkWAIv2MoVxn2uym2+/X0/JTp/Et8B5ysPJ3nIFa82aeLa6BO4vI3Awbs= Received: from BYAPR11MB2567.namprd11.prod.outlook.com (52.135.226.160) by BYAPR11MB3078.namprd11.prod.outlook.com (20.177.226.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.18; Tue, 26 Mar 2019 16:34:02 +0000 Received: from BYAPR11MB2567.namprd11.prod.outlook.com ([fe80::9018:20f6:33c8:3a2b]) by BYAPR11MB2567.namprd11.prod.outlook.com ([fe80::9018:20f6:33c8:3a2b%4]) with mapi id 15.20.1730.019; Tue, 26 Mar 2019 16:34:02 +0000 From: "Rakesh Gandhi (rgandhi)" To: "N.Leymann@telekom.de" , "mpls@ietf.org" , "ntan@arista.com" CC: "draft-ietf-mpls-summary-frr-rsvpte@ietf.org" , "tsaad.net@gmail.com" , "mpls-chairs@ietf.org" Thread-Topic: IPR poll on draft-ietf-mpls-summary-frr-rsvpte Thread-Index: AdTgipIrfmt/rAI/RAew/z067XwVG///88kAgAbrRAA= Date: Tue, 26 Mar 2019 16:34:02 +0000 Message-ID: <7F463149-D4B1-4C80-BFF6-C88F8EB8631C@cisco.com> References: <039CB6B6-C5B7-4F49-A57E-A072FDAB44EC@cisco.com> In-Reply-To: <039CB6B6-C5B7-4F49-A57E-A072FDAB44EC@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rgandhi@cisco.com; x-originating-ip: [2001:420:c0c8:1003::46] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e5ea4f9b-ce2b-41a2-93d5-08d6b208daf5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR11MB3078; x-ms-traffictypediagnostic: BYAPR11MB3078: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 09888BC01D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(39860400002)(376002)(396003)(366004)(189003)(199004)(99286004)(82746002)(53936002)(4743002)(606006)(7736002)(2906002)(6116002)(106356001)(68736007)(8936002)(236005)(4326008)(8676002)(105586002)(81166006)(81156014)(476003)(97736004)(2616005)(46003)(6486002)(11346002)(229853002)(71190400001)(486006)(256004)(53546011)(316002)(6436002)(33656002)(110136005)(58126008)(5660300002)(2501003)(14454004)(966005)(478600001)(25786009)(54906003)(2473003)(6512007)(54896002)(6306002)(36756003)(83716004)(446003)(71200400001)(76176011)(86362001)(186003)(102836004)(2201001)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3078; H:BYAPR11MB2567.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: w0PlJOBHaLYI5zDrYSK84UrQskPpZodYnR80D9T/sCIFvDFDWwHVDQ18WJVjQde8cIsD5v/1u5UpmG0PvoHYXRDmEDVYLXPIAHdgqexLadji3h5zssWzffbJuCTWMh2XvbG7uZVHZ17eXwhVqRdBLMyyGwyTeCpiZXcKpcTpgcwnfBA9xZbE/QW9KGKpzOnQ/Qy+XTyJGSyi0EVlU1SB9kmWzr8HtxXJTuONkm3sS0SzmCQ58pyUi9b62rnSRwsmY8TFD221kbhlB9q8UhU9omvbLcutniLRUoIbHlutJh3xryz51oCAnXHlWYcoxpXX+W+8VVNBgKW5AhuNbE7EJrChEr1NtEABJCiuQ1VH14hz54XgA6hEp0bGToExCjSoHelabLWh/EQLks1yt36BGeD5Pz2WQAhFpfotKeWg9hI= Content-Type: multipart/alternative; boundary="_000_7F463149D4B14C80BFF6C88F8EB8631Cciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e5ea4f9b-ce2b-41a2-93d5-08d6b208daf5 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2019 16:34:02.0982 (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-Transport-CrossTenantHeadersStamped: BYAPR11MB3078 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: [mpls] FW: IPR poll on draft-ietf-mpls-summary-frr-rsvpte X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 16:34:19 -0000 --_000_7F463149D4B14C80BFF6C88F8EB8631Cciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9yd2FyZGluZyBlbWFpbCBmcm9tIE5pY2hvbGFzIHRvIHRoZSBXRy4NCg0KDQpGcm9tOiBOaWNo b2xhcyBUYW4gPG50YW5AYXJpc3RhLmNvbT4NCkRhdGU6IFR1ZXNkYXksIE1hcmNoIDI2LCAyMDE5 IGF0IDU6MjkgUE0NClRvOiAiPVNNVFA6cmdhbmRoaUBjaXNjby4gY29tIiA8cmdhbmRoaUBjaXNj by5jb20+DQpDYzogInRzYWFkLm5ldEBnbWFpbC5jb20iIDx0c2FhZC5uZXRAZ21haWwuY29tPg0K U3ViamVjdDogUmU6IElQUiBwb2xsIG9uIGRyYWZ0LWlldGYtbXBscy1zdW1tYXJ5LWZyci1yc3Zw dGUNCg0KSSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiBhc2lkZSBmcm9tIHRoZSBvbmUgbWVudGlv bmVkIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzI1NTkvDQoNCg0KRnJvbTogIj1T TVRQOnJnYW5kaGlAY2lzY28uIGNvbSIgPHJnYW5kaGlAY2lzY28uY29tPg0KRGF0ZTogRnJpZGF5 LCBNYXJjaCAyMiwgMjAxOSBhdCAxMjo1NCBQTQ0KVG86ICJOLkxleW1hbm5AdGVsZWtvbS5kZSIg PE4uTGV5bWFubkB0ZWxla29tLmRlPiwgIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3JnPg0K Q2M6ICJkcmFmdC1pZXRmLW1wbHMtc3VtbWFyeS1mcnItcnN2cHRlQGlldGYub3JnIiA8ZHJhZnQt aWV0Zi1tcGxzLXN1bW1hcnktZnJyLXJzdnB0ZUBpZXRmLm9yZz4sICJ0c2FhZC5uZXRAZ21haWwu Y29tIiA8dHNhYWQubmV0QGdtYWlsLmNvbT4sICJtcGxzLWNoYWlyc0BpZXRmLm9yZyIgPG1wbHMt Y2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IElQUiBwb2xsIG9uIGRyYWZ0LWlldGYtbXBs cy1zdW1tYXJ5LWZyci1yc3ZwdGUNCg0KSGkgTmljLA0KDQpJIGFtIG5vdCBhd2FyZSBvZiBhbiBJ UFIgb3RoZXIgdGhhbiB0aGUgb25lIGRpc2Nsb3NlZCBiZWxvdy4NCg0KVGhhbmtzLA0KUmFrZXNo DQoNCg0KRnJvbTogIk4uTGV5bWFubkB0ZWxla29tLmRlIiA8Ti5MZXltYW5uQHRlbGVrb20uZGU+ DQpEYXRlOiBGcmlkYXksIE1hcmNoIDIyLCAyMDE5IGF0IDQ6MzggQU0NClRvOiAibXBsc0BpZXRm Lm9yZyIgPG1wbHNAaWV0Zi5vcmc+DQpDYzogImRyYWZ0LWlldGYtbXBscy1zdW1tYXJ5LWZyci1y c3ZwdGVAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLW1wbHMtc3VtbWFyeS1mcnItcnN2cHRlQGlldGYu b3JnPiwgInRzYWFkLm5ldEBnbWFpbC5jb20iIDx0c2FhZC5uZXRAZ21haWwuY29tPiwgIm1wbHMt Y2hhaXJzQGlldGYub3JnIiA8bXBscy1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBJUFIgcG9s bCBvbiBkcmFmdC1pZXRmLW1wbHMtc3VtbWFyeS1mcnItcnN2cHRlDQpSZXNlbnQtRnJvbTogPGFs aWFzLWJvdW5jZXNAaWV0Zi5vcmc+DQpSZXNlbnQtVG86ICI9U01UUDptdGFpbGxvbkBjaXNjby4g Y29tIiA8bXRhaWxsb25AY2lzY28uY29tPiwgPHRzYWFkQGNpc2NvLmNvbT4sICI9U01UUDpyZ2Fu ZGhpQGNpc2NvLiBjb20iIDxyZ2FuZGhpQGNpc2NvLmNvbT4sIDxhZGVzaG11a2hAanVuaXBlci5u ZXQ+LCA8bWpvcmtAanVuaXBlci5uZXQ+LCA8dmJlZXJhbUBqdW5pcGVyLm5ldD4NClJlc2VudC1E YXRlOiBGcmlkYXksIE1hcmNoIDIyLCAyMDE5IGF0IDQ6MzggQU0NCg0KDQpEZWFyIFdvcmtpbmcg R3JvdXAsDQoNCg0KDQpXZSBhcmUgY3VycmVudGx5IHByZXBhcmluZyBkcmFmdCBkcmFmdC1pZXRm LW1wbHMtc3VtbWFyeS1mcnItcnN2cHRlIGZvciB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbC4NCg0K DQoNClBhcnQgb2YgdGhpcyBwcmVwYXJhdGlvbiBpcyB0byBkbyBhbiBJUFIgcG9sbC4NCg0KDQoN ClRoaXMgbWFpbCBpcyB0byBzdGFydCB0aGUgSVBSIHBvbGwuDQoNCg0KDQpBcmUgeW91IGF3YXJl IG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LWlldGYtbXBscy1zdW1tYXJ5LWZyci1y c3ZwdGU/DQoNCg0KDQpJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBs aWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQg NTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4NCg0KDQoNClRoZXJlIGFyZSBubyBJUFIgZGlzY2xvc3Vy ZSBkaXJlY3RseSBhZ2FpbnN0IGRyYWZ0LWlldGYtbXBscy1zdW1tYXJ5LWZyci1yc3ZwdGUuDQoN Ckhvd2V2ZXIsIHRoZXJlIGlzIG9uZSBJUFIgZGlzY2xvc3VyZSBhZ2FpbnN0IHRoZSBpbmRpdmlk dWFsIGRvY3VtZW50IGRyYWZ0LW10YWlsbG9uLW1wbHMtc3VtbWFyeS1mcnItcnN2cHRlIHRoYXQg cHJlY2VkZWQgdGhlIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQ6DQoNCg0KDQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2lwci8yNTU5Lw0KDQoNCg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBk b2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFp bCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2 YW50IElQUi4gKlRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBzZW50IHRvIHRoZSBNUExTIFdHIG1h aWxpbmcgbGlzdC4qIFRoZSBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0 YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBh bmQgY29udHJpYnV0b3IuDQoNCg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBNUExTIFdHIGVtYWlsIGxp c3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250cmlidXRvciwgdGhlbiBw bGVhc2UgZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2FyZSBvZiBhbnkgSVBS IHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRG IHJ1bGVzLg0KDQoNCg0KQmVzdCByZWdhcmRzDQoNCg0KDQogICBOaWMNCg0K --_000_7F463149D4B14C80BFF6C88F8EB8631Cciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8CAA50E9D05F164F9115B61A9255D7FA@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6Q291cmllcjt9DQpwLm1zb25vcm1hbDAs IGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1h bDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5OdXJUZXh0WmNobg0KCXttc28tc3R5 bGUtbmFtZToiTnVyIFRleHQgWmNobiI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJOdXIgVGV4dCI7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpwLk51clRleHQs IGxpLk51clRleHQsIGRpdi5OdXJUZXh0DQoJe21zby1zdHlsZS1uYW1lOiJOdXIgVGV4dCI7DQoJ bXNvLXN0eWxlLWxpbms6Ik51ciBUZXh0IFpjaG4iOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9 DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFu Lm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToi IjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcw Ljg1cHQgNzAuODVwdCAyLjBjbSA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRl IiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvcndhcmRpbmcgZW1haWwg ZnJvbSBOaWNob2xhcyB0byB0aGUgV0cuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTogPC9iPk5pY2hvbGFz IFRhbiAmbHQ7bnRhbkBhcmlzdGEuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBN YXJjaCAyNiwgMjAxOSBhdCA1OjI5IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDs9U01UUDpyZ2Fu ZGhpQGNpc2NvLiBjb20mcXVvdDsgJmx0O3JnYW5kaGlAY2lzY28uY29tJmd0Ozxicj4NCjxiPkNj OiA8L2I+JnF1b3Q7dHNhYWQubmV0QGdtYWlsLmNvbSZxdW90OyAmbHQ7dHNhYWQubmV0QGdtYWls LmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IElQUiBwb2xsIG9uIGRyYWZ0LWlldGYt bXBscy1zdW1tYXJ5LWZyci1yc3ZwdGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBub3Qg YXdhcmUgb2YgYW55IElQUiBhc2lkZSBmcm9tIHRoZSBvbmUgbWVudGlvbmVkIDxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzI1NTkvIiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8yNTU5LzwvYT48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206 IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mcXVvdDs9U01UUDpyZ2FuZGhp QGNpc2NvLiBjb20mcXVvdDsgJmx0O3JnYW5kaGlAY2lzY28uY29tJmd0Ozxicj4NCjxiPkRhdGU6 IDwvYj5GcmlkYXksIE1hcmNoIDIyLCAyMDE5IGF0IDEyOjU0IFBNPGJyPg0KPGI+VG86IDwvYj4m cXVvdDtOLkxleW1hbm5AdGVsZWtvbS5kZSZxdW90OyAmbHQ7Ti5MZXltYW5uQHRlbGVrb20uZGUm Z3Q7LCAmcXVvdDttcGxzQGlldGYub3JnJnF1b3Q7ICZsdDttcGxzQGlldGYub3JnJmd0Ozxicj4N CjxiPkNjOiA8L2I+JnF1b3Q7ZHJhZnQtaWV0Zi1tcGxzLXN1bW1hcnktZnJyLXJzdnB0ZUBpZXRm Lm9yZyZxdW90OyAmbHQ7ZHJhZnQtaWV0Zi1tcGxzLXN1bW1hcnktZnJyLXJzdnB0ZUBpZXRmLm9y ZyZndDssICZxdW90O3RzYWFkLm5ldEBnbWFpbC5jb20mcXVvdDsgJmx0O3RzYWFkLm5ldEBnbWFp bC5jb20mZ3Q7LCAmcXVvdDttcGxzLWNoYWlyc0BpZXRmLm9yZyZxdW90OyAmbHQ7bXBscy1jaGFp cnNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBJUFIgcG9sbCBvbiBkcmFm dC1pZXRmLW1wbHMtc3VtbWFyeS1mcnItcnN2cHRlIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBOaWMsPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgYW0gbm90IGF3YXJlIG9mIGFuIElQUiBvdGhlciB0aGFuIHRoZSBvbmUgZGlzY2xvc2VkIGJl bG93LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5SYWtlc2g8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mcXVvdDtOLkxleW1hbm5AdGVsZWtvbS5kZSZxdW90OyAmbHQ7 Ti5MZXltYW5uQHRlbGVrb20uZGUmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgTWFyY2gg MjIsIDIwMTkgYXQgNDozOCBBTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7bXBsc0BpZXRmLm9yZyZx dW90OyAmbHQ7bXBsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O2RyYWZ0LWll dGYtbXBscy1zdW1tYXJ5LWZyci1yc3ZwdGVAaWV0Zi5vcmcmcXVvdDsgJmx0O2RyYWZ0LWlldGYt bXBscy1zdW1tYXJ5LWZyci1yc3ZwdGVAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDt0c2FhZC5uZXRAZ21h aWwuY29tJnF1b3Q7ICZsdDt0c2FhZC5uZXRAZ21haWwuY29tJmd0OywgJnF1b3Q7bXBscy1jaGFp cnNAaWV0Zi5vcmcmcXVvdDsgJmx0O21wbHMtY2hhaXJzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1 YmplY3Q6IDwvYj5JUFIgcG9sbCBvbiBkcmFmdC1pZXRmLW1wbHMtc3VtbWFyeS1mcnItcnN2cHRl IDxicj4NCjxiPlJlc2VudC1Gcm9tOiA8L2I+Jmx0O2FsaWFzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+UmVzZW50LVRvOiA8L2I+JnF1b3Q7PVNNVFA6bXRhaWxsb25AY2lzY28uIGNvbSZx dW90OyAmbHQ7bXRhaWxsb25AY2lzY28uY29tJmd0OywgJmx0O3RzYWFkQGNpc2NvLmNvbSZndDss ICZxdW90Oz1TTVRQOnJnYW5kaGlAY2lzY28uIGNvbSZxdW90OyAmbHQ7cmdhbmRoaUBjaXNjby5j b20mZ3Q7LCAmbHQ7YWRlc2htdWtoQGp1bmlwZXIubmV0Jmd0OywgJmx0O21qb3JrQGp1bmlwZXIu bmV0Jmd0OywgJmx0O3ZiZWVyYW1AanVuaXBlci5uZXQmZ3Q7PGJyPg0KPGI+UmVzZW50LURhdGU6 IDwvYj5GcmlkYXksIE1hcmNoIDIyLCAyMDE5IGF0IDQ6MzggQU08L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkRlYXIgV29ya2luZyBH cm91cCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+V2UgYXJlIGN1cnJlbnRseSBwcmVw YXJpbmcgZHJhZnQgZHJhZnQtaWV0Zi1tcGxzLXN1bW1hcnktZnJyLXJzdnB0ZSBmb3Igd29ya2lu ZyBncm91cCBsYXN0IGNhbGwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlBhcnQgb2Yg dGhpcyBwcmVwYXJhdGlvbiBpcyB0byBkbyBhbiBJUFIgcG9sbC48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+VGhpcyBtYWlsIGlzIHRvIHN0YXJ0IHRoZSBJUFIgcG9sbC48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+QXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGll cyB0byBkcmFmdC1pZXRmLW1wbHMtc3VtbWFyeS1mcnItcnN2cHRlPzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5JZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBs aWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQg NTM3OCBmb3IgbW9yZSBkZXRhaWxzKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhl cmUgYXJlIG5vIElQUiBkaXNjbG9zdXJlIGRpcmVjdGx5IGFnYWluc3QgZHJhZnQtaWV0Zi1tcGxz LXN1bW1hcnktZnJyLXJzdnB0ZS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+SG93ZXZlciwgdGhlcmUgaXMgb25lIElQUiBkaXNjbG9zdXJlIGFnYWluc3QgdGhlIGlu ZGl2aWR1YWwgZG9jdW1lbnQgZHJhZnQtbXRhaWxsb24tbXBscy1zdW1tYXJ5LWZyci1yc3ZwdGUg dGhhdCBwcmVjZWRlZCB0aGUgd29ya2luZyBncm91cCBkb2N1bWVudDo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIv MjU1OS8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzI1NTkvPC9hPg0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPklmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQg YXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgcmVnYXJk bGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIu ICpUaGUgcmVzcG9uc2UgbmVlZHMgdG8gYmUgc2VudCB0byB0aGUgTVBMUyBXRyBtYWlsaW5nIGxp c3QuKiBUaGUgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZQ0KIHRvIHRoZSBuZXh0IHN0YWdlIHVu dGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgY29u dHJpYnV0b3IuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPklmIHlvdSBhcmUgb24gdGhl IE1QTFMgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNv bnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJl IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25m b3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkJl c3QgcmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgTmlj PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7F463149D4B14C80BFF6C88F8EB8631Cciscocom_-- From nobody Tue Mar 26 16:10:57 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F53E120074; Tue, 26 Mar 2019 16:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-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_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 vLylghmgz9JR; Tue, 26 Mar 2019 16:10:53 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 EB947120005; Tue, 26 Mar 2019 16:10:52 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id s7so12383549iom.12; Tue, 26 Mar 2019 16:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=cycO9nIoaI4Ho8gebR2LSYTYYb0LReQmCqMvQfKrO9o=; b=mD22PF+f2IrS2LanD/oijKa9uw2JYGNy2ceiSnJkWXLdWxkJk2BfcUrBbfH74pgzI0 /XwzTuoFU+0HFUy+yXXP4p5PaAlnaUwUePLmecnBCf4gqXmVPP7/nm5AWpQ+R1v7Z1Ht VjBO0Y+6HITKkbR6vVd+yfTvE4/ZJ8/1S2BGezVfDLuIIacsEbXwrdwWFW87P+xa/h+3 MabBGccLvHDseFxl9JW2GXmCqpewJEZasJRW98HB4Ysv0/9eE+CWihT4LJXm8oVh8+Ig SwwSlEiFADgkQPx3KO9a2KJjXC5v4c/Nf/CHMiBcykLsVTMcAR/zOIdaVDhmXp8UbtPj i6JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=cycO9nIoaI4Ho8gebR2LSYTYYb0LReQmCqMvQfKrO9o=; b=M/UFVZwtgh3AjRDBVI4q9wvJeC18VV77IDzXj4ZIh8ltKRjk5N38yCxF/FM55Ne55V 6OMpp78ywscpjPTDuppzKq35dfaxfwHXBgR5UjNtCLpktEH/vlpV+YdyPW+uo/XkURq3 CHeVHmH2tjIWOVVTTBxyKvY8E0A5RRwDTfCIEvMfqNcXRB9Glooil54cFoAFMdQe+WKS pIuzLTolKZBfrYY81PIGDnMZD/G8SRaNZyS31plgltMV3z8ImUWqYAIkLi5TfxHE/6J0 Mw7HqNXCxsP78074LBOrxLp4zGAWthfrdNrMffMCMklX1ACzazLKH2Vk/vNSAcQkkEo1 iNhA== X-Gm-Message-State: APjAAAUYRcsGE25rjjIn0W4aX5MOYJKn8iFr+leUi39sXB42GHxcc3Gj Velloy1W3RmK/GDMtwVxxYc= X-Google-Smtp-Source: APXvYqwRZ241jNh3LLdm690xAapbTQt7KtG26eV2wzORnpZIFEoiKtjtY4LM/Oq2QBgYDq/uFb+MkA== X-Received: by 2002:a5d:9914:: with SMTP id x20mr21246733iol.257.1553641852281; Tue, 26 Mar 2019 16:10:52 -0700 (PDT) Received: from BN8PR06MB6289.namprd06.prod.outlook.com ([52.96.29.13]) by smtp.gmail.com with ESMTPSA id v16sm7130834itc.7.2019.03.26.16.10.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Mar 2019 16:10:51 -0700 (PDT) From: Tarek Saad To: "N.Leymann@telekom.de" , "mpls@ietf.org" , "mjork@128technology.com" CC: "draft-ietf-mpls-summary-frr-rsvpte@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: IPR poll on draft-ietf-mpls-summary-frr-rsvpte Thread-Index: ATAyQjYw1aYr1QNesybSJ02kYIgP8MljzeCF X-MS-Exchange-MessageSentRepresentingType: 1 Date: Tue, 26 Mar 2019 23:10:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_BN8PR06MB628933999BBD525D799FA66BFC5F0BN8PR06MB6289namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] IPR poll on draft-ietf-mpls-summary-frr-rsvpte X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 23:10:56 -0000 --_000_BN8PR06MB628933999BBD525D799FA66BFC5F0BN8PR06MB6289namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Added Markus=92s new email so he can respond. Regards, Tarek From: "N.Leymann@telekom.de" Date: Friday, March 22, 2019 at 9:38 AM To: "mpls@ietf.org" Cc: "draft-ietf-mpls-summary-frr-rsvpte@ietf.org" , "tsaad.net@gmail.com" , "mpls-ch= airs@ietf.org" Subject: IPR poll on draft-ietf-mpls-summary-frr-rsvpte Dear Working Group, We are currently preparing draft draft-ietf-mpls-summary-frr-rsvpte for wor= king group last call. Part of this preparation is to do an IPR poll. This mail is to start the IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-summary-frr-rsvpte= ? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). There are no IPR disclosure directly against draft-ietf-mpls-summary-frr-rs= vpte. However, there is one IPR disclosure against the individual document draft-= mtaillon-mpls-summary-frr-rsvpte that preceded the working group document: https://datatracker.ietf.org/ipr/2559/ If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. *Th= e response needs to be sent to the MPLS WG mailing list.* The document will= not advance to the next stage until a response has been received from each= author and contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. Best regards Nic --_000_BN8PR06MB628933999BBD525D799FA66BFC5F0BN8PR06MB6289namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Added Markus=92s new email so he can respond.

 

Regards,
Tarek

 

From= : "N.Leymann@t= elekom.de" <N.Leymann@telekom.de>
Date: Friday, March 22, 2019 at 9:38 AM
To: "mpls@ietf.org" <mpls@ietf.org>
Cc: "draft-ietf-mpls-summary-frr-rsvpte@ietf.org" <draf= t-ietf-mpls-summary-frr-rsvpte@ietf.org>, "tsaad.net@gmail.com"= ; <tsaad.net@gmail.com>, "mpls-chairs@ietf.org" <mpls-ch= airs@ietf.org>
Subject: IPR poll on draft-ietf-mpls-summary-frr-rsvpte <= /span>

 

Dear Working Group,

 

We are currently preparing draft draft-ietf-mpls-= summary-frr-rsvpte for working group last call.

 

Part of this preparation is to do an IPR poll.

 

This mail is to start the IPR poll.

 

Are you aware of any IPR that applies to draft-ie= tf-mpls-summary-frr-rsvpte?

 

If so, has this IPR been disclosed in compliance = with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).<= o:p>

 

There are no IPR disclosure directly against draf= t-ietf-mpls-summary-frr-rsvpte.

However, there is one IPR disclosure against the = individual document draft-mtaillon-mpls-summary-frr-rsvpte that preceded th= e working group document:

 

https://datatracker.ietf.org/ipr/2559/

 

If you are listed as a document author or contrib= utor please respond to this email regardless of whether or not you are awar= e of any relevant IPR. *The response needs to be sent to the MPLS WG mailin= g list.* The document will not advance to the next stage until a response has been received from each author and = contributor.

 

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

 

Best regards

 

   Nic

 

--_000_BN8PR06MB628933999BBD525D799FA66BFC5F0BN8PR06MB6289namp_-- From mjork@128technology.com Tue Mar 26 16:16:27 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C59A120124 for ; Tue, 26 Mar 2019 16:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=128technology.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 ptq3TNNB_svj for ; Tue, 26 Mar 2019 16:16:25 -0700 (PDT) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (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 953A512034E for ; Tue, 26 Mar 2019 16:16:22 -0700 (PDT) Received: by mail-qt1-x842.google.com with SMTP id z17so16703603qts.13 for ; Tue, 26 Mar 2019 16:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=128technology.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=MhCgnAF1tN6bRW1ROTVzy9rEek861J6qf2rT/oN33go=; b=dM8Ov+n0nxQCSSofqNba/TsIBjARnEeQsX8/CvdGa2afvJK/HGoY9ztkaJo7O9gYMQ 0UnLwhMoxdJ++XWuLIfyixGUWRlZLS8FEcUAK0Rcc2rBVNCXB9nGTEe5zxyZaac0irbY nim37IljS+6dv9S6LPO8GHrVtHJsZMJ2nL2Ho= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=MhCgnAF1tN6bRW1ROTVzy9rEek861J6qf2rT/oN33go=; b=aanvkFUfx9ike8SFiEHm/WdNMTrulQteui2lEf/7y5H3cYNTlMI+XhPzNN/JWUeJJn GuOd/jcLdhVopl8yMt1tUhblB8q8L72wZtlfwQGc9j8oUzcIZlwhelS4DfC7lhaRRqIb x7KldiEeQIBc7WveKbCv92KWkzC5JyfkWxXBgSwcbdnLyDUWsiJZWLepvaKz/KS2qLOu 1qgQ1ZqkQanaPp+Mp9nBwvGhhSu3WNa30+0gzbJDB9QqfM7Pv63ijOn+itmWTV7QsoKE UeM5Ma7SHIL0u+8aPNGHdX3lZnCBuShWJ+AJNG9lt5tzoIYOKS1SmrjfrxJ3okEB6bFi 2GMw== X-Gm-Message-State: APjAAAUbA9FKBcflWwWM9slYg4elVDC2fKoAvO4WtA9P89I2GvtDcXzn LCXFCUNkFrGzc966oZ59Ie9vUA== X-Google-Smtp-Source: APXvYqyuNEqfaAviGHb7bum7Ort0MBbENGk1s/nB1CjcYcO7K6N0HMWVI4ChT+RgY9NJmDU5/QOQpg== X-Received: by 2002:ac8:1497:: with SMTP id l23mr5276474qtj.296.1553642181700; Tue, 26 Mar 2019 16:16:21 -0700 (PDT) Received: from mjork.home (pool-72-74-56-119.bstnma.fios.verizon.net. [72.74.56.119]) by smtp.gmail.com with ESMTPSA id r53sm1960614qtr.80.2019.03.26.16.16.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Mar 2019 16:16:21 -0700 (PDT) From: Markus Jork Message-Id: <8C111E5E-AD36-4422-A35F-E9E15A1592DD@128technology.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E8EFB166-FEDD-4110-8D59-EC49FEF0E99F" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 26 Mar 2019 19:16:20 -0400 In-Reply-To: Cc: "N.Leymann@telekom.de" , "mpls@ietf.org" , "draft-ietf-mpls-summary-frr-rsvpte@ietf.org" , "mpls-chairs@ietf.org" To: Tarek Saad References: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-Mailman-Approved-At: Tue, 26 Mar 2019 18:05:25 -0700 Subject: Re: [mpls] IPR poll on draft-ietf-mpls-summary-frr-rsvpte X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 23:18:48 -0000 --Apple-Mail=_E8EFB166-FEDD-4110-8D59-EC49FEF0E99F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I am not aware of any IPR other than what has already been disclosed (as = stated below). -Markus > On Mar 26, 2019, at 7:10 PM, Tarek Saad wrote: >=20 > Added Markus=E2=80=99s new email so he can respond. > =20 > Regards, > Tarek > =20 > From: "N.Leymann@telekom.de " = > > Date: Friday, March 22, 2019 at 9:38 AM > To: "mpls@ietf.org " > > Cc: "draft-ietf-mpls-summary-frr-rsvpte@ietf.org = " = >, = "tsaad.net@gmail.com " >, "mpls-chairs@ietf.org = " > > Subject: IPR poll on draft-ietf-mpls-summary-frr-rsvpte=20 > =20 > Dear Working Group, > =20 > We are currently preparing draft draft-ietf-mpls-summary-frr-rsvpte = for working group last call. > =20 > Part of this preparation is to do an IPR poll. > =20 > This mail is to start the IPR poll. > =20 > Are you aware of any IPR that applies to = draft-ietf-mpls-summary-frr-rsvpte? > =20 > If so, has this IPR been disclosed in compliance with IETF IPR rules = (see RFCs 3979, 4879, 3669 and 5378 for more details). > =20 > There are no IPR disclosure directly against = draft-ietf-mpls-summary-frr-rsvpte. > However, there is one IPR disclosure against the individual document = draft-mtaillon-mpls-summary-frr-rsvpte that preceded the working group = document: > =20 > https://datatracker.ietf.org/ipr/2559/ = > =20 > If you are listed as a document author or contributor please respond = to this email regardless of whether or not you are aware of any relevant = IPR. *The response needs to be sent to the MPLS WG mailing list.* The = document will not advance to the next stage until a response has been = received from each author and contributor. > =20 > If you are on the MPLS WG email list but are not listed as an author = or contributor, then please explicitly respond only if you are aware of = any IPR that has not yet been disclosed in conformance with IETF rules. > =20 > Best regards > =20 > Nic --Apple-Mail=_E8EFB166-FEDD-4110-8D59-EC49FEF0E99F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = am not aware of any IPR other than what has already been disclosed (as = stated below).
-Markus

On Mar = 26, 2019, at 7:10 PM, Tarek Saad <tsaad.net@gmail.com>= wrote:

Added = Markus=E2=80=99s new email so he can respond.
 
Regards,Tarek
 
 
Dear Working Group,
 
We are = currently preparing draft draft-ietf-mpls-summary-frr-rsvpte for working = group last call.
 
Part of this preparation is to do an IPR poll.
 
This mail = is to start the IPR poll.
 
Are you aware of any IPR that applies to = draft-ietf-mpls-summary-frr-rsvpte?
 
If so, has this IPR been disclosed in = compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for = more details).
 
There are no IPR disclosure directly against = draft-ietf-mpls-summary-frr-rsvpte.
However, there is one IPR disclosure = against the individual document draft-mtaillon-mpls-summary-frr-rsvpte = that preceded the working group document:
 
https://datatracker.ietf.org/ipr/2559/
 
If you = are listed as a document author or contributor please respond to this = email regardless of whether or not you are aware of any relevant IPR. = *The response needs to be sent to the MPLS WG mailing list.* The = document will not advance to the next stage until a response has been = received from each author and contributor.
 
If you are on the MPLS WG email list = but are not listed as an author or contributor, then please explicitly = respond only if you are aware of any IPR that has not yet been disclosed = in conformance with IETF rules.
 
Best regards
 
   = Nic

= --Apple-Mail=_E8EFB166-FEDD-4110-8D59-EC49FEF0E99F-- From nobody Thu Mar 28 01:34:00 2019 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5065612025B; Thu, 28 Mar 2019 01:33:58 -0700 (PDT) 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.94.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155376203832.1440.9601518754320678609.idtracker@ietfa.amsl.com> Date: Thu, 28 Mar 2019 01:33:58 -0700 Archived-At: Subject: [mpls] The MPLS WG has placed draft-zzhang-mpls-rmr-multicast in state "Candidate for WG Adoption" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 08:33:58 -0000 The MPLS WG has placed draft-zzhang-mpls-rmr-multicast in state Candidate for WG Adoption (entered by Loa Andersson) The document is available at https://datatracker.ietf.org/doc/draft-zzhang-mpls-rmr-multicast/ From nobody Thu Mar 28 09:50:00 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0208A1202CC for ; Thu, 28 Mar 2019 09:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 jhbDT1MR0Au9 for ; Thu, 28 Mar 2019 09:49:55 -0700 (PDT) Received: from 10.mo173.mail-out.ovh.net (10.mo173.mail-out.ovh.net [46.105.74.148]) (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 457621202F4 for ; Thu, 28 Mar 2019 09:49:47 -0700 (PDT) Received: from player758.ha.ovh.net (unknown [10.109.159.68]) by mo173.mail-out.ovh.net (Postfix) with ESMTP id 4CB7CF470D for ; Thu, 28 Mar 2019 17:49:45 +0100 (CET) Received: from upperside.fr (aaubervilliers-682-1-111-83.w90-88.abo.wanadoo.fr [90.88.82.83]) (Authenticated sender: michelg@upperside.fr) by player758.ha.ovh.net (Postfix) with ESMTPSA id 9EB9F434816E for ; Thu, 28 Mar 2019 16:49:44 +0000 (UTC) From: "Michel Gosse" To: References: In-Reply-To: Date: Thu, 28 Mar 2019 17:49:41 +0100 Message-ID: <000001d4e586$3d859510$b890bf30$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D4E58E.9F4A4B30" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdTZipkiXFEXUTvcSpSQXJPJ0UTfNQL+wNHA Content-Language: fr X-Ovh-Tracer-Id: 18097715106298908762 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedutddrkeeggdelhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecu Archived-At: Subject: [mpls] MPLS+SDN+NFV World Paris 2019 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 16:49:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D4E58E.9F4A4B30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit AI for Networks, SRv6, Cloud and Edge Architectures, Automation and Orchestration, Network Slicing, Telemetry, SD-WAN vs MPLS, Interop Showcase: The 21st Edition of the MPLS +SDN + NFV World 2019 starts next April 9th. More information: https://www.uppersideconferences.com/mpls-sdn-nfv/mplswc2019_agenda_day_01.h tml ------=_NextPart_000_0001_01D4E58E.9F4A4B30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

AI for Networks, SRv6, Cloud and = Edge Architectures, Automation and Orchestration, Network Slicing, =  Telemetry, SD-WAN vs MPLS, Interop Showcase: =  

The = 21st Edition of the MPLS +SDN + NFV World 2019 starts next April = 9th.

 

More information:

https://www.uppersideconferences.com/mpls-sdn-nfv/mplswc2= 019_agenda_day_01.html

 

 

 

------=_NextPart_000_0001_01D4E58E.9F4A4B30-- From nobody Thu Mar 28 18:13:47 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E9912006A; Thu, 28 Mar 2019 18:13:44 -0700 (PDT) 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_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 PUySVVOMcF-3; Thu, 28 Mar 2019 18:13:41 -0700 (PDT) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 7A99A1200B6; Thu, 28 Mar 2019 18:13:41 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id g12so179968pll.11; Thu, 28 Mar 2019 18:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=6mXQZ4LZ/hO5N6avoB0nP6y8u+tFyjcrEUY2VtL+R6Y=; b=K8Ji65cDMz0RIoxKItpaObO8KdRejFhgc6cRGwV7BrpwQiOrYGQkknb7sQQaVvu6FS Ndj+EFkVmCatT0FvVq5qgqAUhoCidD5V3k6AFKjcY2YU3yRlkX1+YKaNuIUZDJCNTii3 w4MzWw/Xh7X1JVVNMTSkY3HTneBJXPg6sbHv39NLc/epapI3Jcqudv/1+oX9SDVDsfwq jDdD7NPGAG2NckLBWd7cZTOT3Bn/pRLIwWIsLEB1YjlrdnAsM87rTNUz1nbag+9Zi/7V 3pYY41bpqtvCA9gto2L4Vmc6m8/GkQObE3UGwSK3lewH7pEVcRma7npDaH9OJnOZIMCZ 54vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=6mXQZ4LZ/hO5N6avoB0nP6y8u+tFyjcrEUY2VtL+R6Y=; b=NwuiI6Sy/5DwWW82/GTuL0co2jvIrijqK/wDadwyPV51CSTvb6RHXVbx3VlM5NwY+n pKIAElRDc2ltvvsfNI+qT8BKUFWOTOmbnhnvtMqN1cM2BZQ6hUB8o1fUMM+p6Hu2fVgb d2BFsk+O55fL0fFMf3yyj5DIkgXrUOF7OuhMwJi4w3vdG8CAjdzBoHZynUiF1gNK6IM6 dP1sLid3VSbJNYyWVZbtOQ/D/akYkzUqAgy5s9VlhKwU4lzIZnmhNuFIK97NRFwn6aHO VIDCrrnvMiTT0zd0/GkWa2a6cMj0LYWYX6gpD3PY4+e1Ni0vSJyIu0mQekpvK3TJY949 0Nng== X-Gm-Message-State: APjAAAVqfjPAEcZ/NmZSlUyT8LYR/MGNYgn85D+abbNGH9IxYh8Y62ov 9bdv/QKBztDoJKSITrIId0I= X-Google-Smtp-Source: APXvYqx8YmVO06JmixYtWLHP8RNLKmI6FW8KTHa2t57QsyqV49tRyMOuVvAoiRdHn1fLH7vWZHMODQ== X-Received: by 2002:a17:902:a5c9:: with SMTP id t9mr44612552plq.196.1553822020960; Thu, 28 Mar 2019 18:13:40 -0700 (PDT) Received: from Arrcus-Ahmeds-MacBook-Pro.local (adsl-70-234-233-188.dsl.rcsntx.sbcglobal.net. [70.234.233.188]) by smtp.gmail.com with ESMTPSA id i79sm537164pfj.28.2019.03.28.18.13.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 18:13:40 -0700 (PDT) To: Alexander Vainshtein , "rtg-ads@ietf.org" Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , "draft-ietf-spring-segment-routing-mpls.authors@ietf.org" , Min Ye References: From: Ahmed Bashandy Message-ID: <65361777-db63-9a7a-9199-dd04425b4785@gmail.com> Date: Thu, 28 Mar 2019 18:13:39 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8CCF32B57D81BFE5451EA093" Content-Language: en-US Archived-At: Subject: Re: [mpls] RTG-DIR Last Call review of draft-ietf-spring-segment-routing-mpls-18 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 01:13:45 -0000 This is a multi-part message in MIME format. --------------8CCF32B57D81BFE5451EA093 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks a lot for the review I uploaded version 19 of the draft, which, IMO, addresses all your comments See the reply "#Ahmed" On 3/10/19 9:55 AM, Alexander Vainshtein wrote: > > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review, and sometimes on special request. The purpose of the review is > to provide assistance to the Routing ADs. For more information about > the Routing Directorate, please see > ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, > it would be helpful if you could consider them along with any other > IETF Last Call comments that you receive, and strive to resolve them > through discussion or by updating the draft. > > Document: review of draft-ietf-spring-segment-routing-mpls-18 > Reviewer: Alexander (“Sasha”) Vainshtein > Review Date: 10-Mar-19 > IETF LC End Date: 07-Mar-2019 > Intended Status: Proposed Standard > > *Summary:*I have some minor concerns about this document that I think > should be resolved before publication. > > *Comments*: > > I have done an early RTG-DIR review of the -14 version of the draft > half a year ago, and the issues I’ve raised then have been resolved in > the subsequent versions one way or another). Therefore this review has > been intentionally focused on the changes done to the draft in the few > recent versions. > > In my previous review I have noticed that the draft was not easy > reading for me. Since then readability of the draft has been improved. > However, there are still several places in the new text that are still > difficult to parse. > > I did not run the nits checker on the draft, so my list of nits is > probably incomplete. > > Just as with my earlier review, I send this one also to the MPLS WG > list – and for the same reasons. > > I tried to discuss my review privately with the authors, but they did > not respond. > > *Major Issues*: No major issues found. > > *Minor Issues*: > > 1.The text in Section 1 states that “*a network operator SHOULD configure at least one node segment per > routing instance, topology, algorithm*”and continues that “*An implementation MAY check that an IGP node-SID is not associated > with a prefix that is owned by more than one router within the same > routing domain, If so, it SHOULD NOT use this Node-SID, MAY use > another one if available, and SHOULD log an error*”. This looks somewhat controversial to me because: > a.The check of the Node SID not being owned by more than one router in > the routing domain is defined as purely optional. According to RFC > 2119, implementations that choose to implement such a check must be > able to interoperate with implementations that do not implement it > b.The recommended handling of the results of this check (fully aligned > with the text in Section 3.2 pf RFC 8402 that prohibits using prefixes > owned by more than one router in the domain as Node-SODs) strongly > suggests that the prefix that is owned by more than one router in the > domain is unusable as the Node SID > I see two possibilities to resolve this controversy: either make the > check in question a “real requirement” (i.e., replace *MAY*with *SHOULD*or even *MUST*), or explain why it is safe enough not to implement such a check > (i.e., how implementations that support this check and implementations > that do not support it can interoperate within a given routing domain).The first of these options seems to me aligned with Section 3.2 in RFC > 8402 that says that “*An IGP Node-SID MUST NOT be associated with a > prefix that is owned by more than one router within the same routing > domain*”. #Ahmed: I replaced the MAY with SHOULD > > 2.I have  a problem with the highlighted part of the following text in > Section 2.5: > > *An implementation MUST NOT allow the MCCs belonging to the same* > > *   router to assign the same incoming label to more than one SR FEC. An* > > *implementation that allows such behavior is considered as faulty.*** > > *Procedures defined in this document equally applies to this case,* > > *   both for incoming label collision (Section 2.5 > ) > and the effect on* > > *outgoing label programming (Section 2.6 > ).*** > > a.The Section in question deals with incoming label collision (in > fact, the text that immediately follows the problematic fragment > states that “*The objective of the following steps is to > deterministically install in the MPLS Incoming Label Map, also known > as label FIB, a single FEC with the incoming label "L1"*” > b.As a consequence, any mention of *outgoing label programming*, looks out of context (even accompanied by a forward reference to > Section 2.6) > c.Section 2.6 covers the impact of incoming label collision on > programming of outgoing labels in quite a generic way. Therefore I > think that the highlighted part of the quoted fragment can be safely > removed (complete with the grammar mistake). > d.I also do not see any value in stating that an implementations that > violates a mandatory requirement of the spec is faulty – isn’t that > self-evident? #Ahmed: I removed the highlighted text because I agree with what you said in item (d) that it has no value > 3.The highlighted text in Section 2.8 is not accurate: > *   For Local SIDs, the MCC is responsible for downloading the correct* > *   label value to FIB. For example, an IGP with SR extensions [I-D.ietf-* > *   isis-segment-routing-extensions, I-D.ietf-ospf-segment-routing-* > *   extensions] allocates and downloads the MPLS label corresponding to* > *   an Adj-SID [RFC8402 ].* > *a.*IGP with SR extensions**may indeed dynamically allocate and download MPLS labels acting as > local Adj-SIDs ** > *b.*However, these labels can be allocated by configuration (e.g. as > mentioned in the tie-breaking rules in Section 2.5.1 and in the > example in Section A.2.3 in the draft), in which case IGP with SR > extensions would only responsible for its advertisement and > installation. ** #Ahmed: I removed the highlighted word "allocated" > *NITS*: > :** > 1.In section 2.5: > a.In the sentence “*Procedures defined in this document equally > applies to this case*” the noun is in plural but the verb is in singular. (If this sentence > is removed as suggested above, this nit disappears) > b.The same problem exists in the sentence “*An incoming label > collision occurs if the SIDs of the set of FECs {FEC1, FEC2,..., FECk} > maps to the same incoming SR MPLS label "L1"*” #Ahmed: The sentence is removed as you suggested > > 2.In section 2.10.1 the preposition “*to*” between the words > “*according*” and “*MPLS*” is missing in the fragment “*Push the > calculated label according the MPLS label pushing rules specified in > [RFC3032]*”. > #Ahmed added the missing "to" > > 3.Problems with references: > > a.As reported by Sergey > , > there are two occurrences of references to RFC 8042 “OSPF Two-Part > Metric” instead of RFC 8402. Lots of thanks to Sergey for catching this > #Ahmed: Corrected, thanks again > > b.Reference to RFC 8174 mistakenly contains a link to  RFC 7274. > #Ahmed: Corrected > > Hopefully these notes will be useful. > #Ahmed: VERY useful > > Regards, > > Sasha > > Office: +972-39266302 > > Cell:      +972-549266302 > > Email:   Alexander.Vainshtein@ecitele.com > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and > then delete the original > and all copies thereof. > ___________________________________________________________________________ --------------8CCF32B57D81BFE5451EA093 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+CiAgPGhlYWQ+CiAgICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+CiAgPC9oZWFkPgogIDxib2R5IHRl eHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiPgogICAgPHA+VGhhbmtzIGEgbG90IGZv ciB0aGUgcmV2aWV3PC9wPgogICAgPHA+SSB1cGxvYWRlZCB2ZXJzaW9uIDE5IG9mIHRoZSBk cmFmdCwgd2hpY2gsIElNTywgYWRkcmVzc2VzIGFsbAogICAgICB5b3VyIGNvbW1lbnRzPC9w PgogICAgPHA+U2VlIHRoZSByZXBseSAiI0FobWVkIjxicj4KICAgIDwvcD4KICAgIDxkaXYg Y2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gMy8xMC8xOSA5OjU1IEFNLCBBbGV4YW5kZXIK ICAgICAgVmFpbnNodGVpbiB3cm90ZTo8YnI+CiAgICA8L2Rpdj4KICAgIDxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiCmNpdGU9Im1pZDpWSTFQUjAzTUIzODM5QjVGQTA3RUFERTU3MDg0RjhF Mzg5RDRGMEBWSTFQUjAzTUIzODM5LmV1cnByZDAzLnByb2Qub3V0bG9vay5jb20iPgogICAg ICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsg Y2hhcnNldD1VVEYtOCI+CiAgICAgIDxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0i TWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkCiAgICAgICAgbWVkaXVtKSI+CiAgICAgIDxz dHlsZT48IS0tCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8KQGZvbnQtZmFjZQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOwoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9CkBm b250LWZhY2UKCXtmb250LWZhbWlseTpDYWxpYnJpOwoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQpAZm9udC1mYWNlCgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsKCXBhbm9zZS0x OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbAoJe21hcmdpbjowY207CgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7Cglmb250LXNpemU6MTEuMHB0OwoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6IzA1NjNDMTsKCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQKCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjojOTU0RjcyOwoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9CnAKCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsKCW1hcmdpbi1yaWdodDowY207Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsK CW1hcmdpbi1sZWZ0OjBjbTsKCWZvbnQtc2l6ZToxMi4wcHQ7Cglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIixzZXJpZjt9CnByZQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsKCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsKCW1hcmdpbjowY207Cglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7Cglmb250LXNpemU6MTAuMHB0OwoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFw aCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgKCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7CgltYXJn aW4tdG9wOjBjbTsKCW1hcmdpbi1yaWdodDowY207CgltYXJnaW4tYm90dG9tOjBjbTsKCW1h cmdpbi1sZWZ0OjM2LjBwdDsKCW1hcmdpbi1ib3R0b206LjAwMDFwdDsKCWZvbnQtc2l6ZTox MS4wcHQ7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9CnNwYW4uSFRNTFBy ZWZvcm1hdHRlZENoYXIKCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQiOwoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9CnAubXNvbm9ybWFsMCwg bGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDAKCXttc28tc3R5bGUtbmFtZTptc29ub3Jt YWw7Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsK CW1hcmdpbi1yaWdodDowY207Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsKCW1hcmdp bi1sZWZ0OjBjbTsKCWZvbnQtc2l6ZToxMi4wcHQ7Cglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9CnNwYW4uRW1haWxTdHlsZTIyCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtY29tcG9zZTsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOwoJY29s b3I6d2luZG93dGV4dDt9CnNwYW4uaWNvbgoJe21zby1zdHlsZS1uYW1lOmljb247fQouTXNv Q2hwRGVmYXVsdAoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5OwoJZm9udC1zaXplOjEw LjBwdDsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30KQHBhZ2UgV29yZFNl Y3Rpb24xCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7CgltYXJnaW46NzIuMHB0IDkwLjBwdCA3 Mi4wcHQgOTAuMHB0O30KZGl2LldvcmRTZWN0aW9uMQoJe3BhZ2U6V29yZFNlY3Rpb24xO30K LyogTGlzdCBEZWZpbml0aW9ucyAqLwpAbGlzdCBsMAoJe21zby1saXN0LWlkOjg2NzcxNTM0 NDsKCW1zby1saXN0LXR5cGU6aHlicmlkOwoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE5MDg4 MTA0OTQgMjM5Mzg3MDkyIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3 Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30KQGxpc3QgbDA6bGV2ZWwxCgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7CgltYXJnaW4tbGVmdDozOS43NXB0OwoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9CkBsaXN0 IGwwOmxldmVsMgoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOwoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 CgltYXJnaW4tbGVmdDo3NS43NXB0OwoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9CkBsaXN0IGww OmxldmVsMwoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOwoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0OwoJ bWFyZ2luLWxlZnQ6MTExLjc1cHQ7Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQpAbGlzdCBsMDps ZXZlbDQKCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsKCW1hcmdpbi1sZWZ0OjE0Ny43NXB0OwoJdGV4dC1pbmRlbnQ6LTE4LjBw dDt9CkBsaXN0IGwwOmxldmVsNQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7CgltYXJnaW4tbGVmdDoxODMuNzVwdDsKCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQpAbGlzdCBsMDpsZXZlbDYKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsKCW1zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpyaWdodDsKCW1hcmdpbi1sZWZ0OjIxOS43NXB0OwoJdGV4dC1pbmRlbnQ6LTkuMHB0O30K QGxpc3QgbDA6bGV2ZWw3Cgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7CgltYXJnaW4tbGVmdDoyNTUuNzVwdDsKCXRleHQtaW5k ZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMDpsZXZlbDgKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsKCW1zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0OwoJbWFyZ2luLWxlZnQ6MjkxLjc1cHQ7Cgl0ZXh0LWluZGVu dDotMTguMHB0O30KQGxpc3QgbDA6bGV2ZWw5Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 cm9tYW4tbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246cmlnaHQ7CgltYXJnaW4tbGVmdDozMjcuNzVwdDsKCXRleHQtaW5kZW50 Oi05LjBwdDt9CkBsaXN0IGwxCgl7bXNvLWxpc3QtaWQ6MTg1Nzk2NDMxNTsKCW1zby1saXN0 LXR5cGU6aHlicmlkOwoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xOTY1MjYyMjM2IDIzOTM4 NzA5MiA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5 ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9CkBsaXN0IGwxOmxldmVsMQoJe21zby1sZXZlbC10 YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJbWFyZ2lu LWxlZnQ6MzkuNzVwdDsKCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMTpsZXZlbDIK CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsKCW1zby1sZXZlbC10YWIt c3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9CkBsaXN0IGwxOmxldmVsMwoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OnJvbWFuLWxvd2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOnJpZ2h0OwoJdGV4dC1pbmRlbnQ6LTkuMHB0O30KQGxpc3QgbDE6bGV2 ZWw0Cgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotMTguMHB0O30KQGxpc3QgbDE6bGV2ZWw1Cgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQpAbGlzdCBsMTpsZXZlbDYKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21h bi1sb3dlcjsKCW1zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpyaWdodDsKCXRleHQtaW5kZW50Oi05LjBwdDt9CkBsaXN0IGwxOmxldmVsNwoJ e21zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0OwoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9CkBsaXN0IGwxOmxldmVsOAoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotMTguMHB0 O30KQGxpc3QgbDE6bGV2ZWw5Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246cmlnaHQ7Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQpvbAoJe21hcmdpbi1ib3R0b206MGNt O30KdWwKCXttYXJnaW4tYm90dG9tOjBjbTt9Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pgo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+CiAgICAgIDxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+CiAgICAgICAgPHA+PHNwYW4Kc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5IZWxsbywKICAgICAgICAgICAgPG86cD48L286cD48L3NwYW4+PC9wPgogICAgICAg IDxwPjxzcGFuCnN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SQogICAgICAgICAgICBoYXZl IGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9y CiAgICAgICAgICAgIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtz IHRvIHJldmlldyBhbGwKICAgICAgICAgICAgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQg ZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYKICAgICAgICAgICAgbGFzdCBjYWxs IGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QuCiAg ICAgICAgICAgIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Np c3RhbmNlIHRvIHRoZQogICAgICAgICAgICBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3Jt YXRpb24gYWJvdXQgdGhlIFJvdXRpbmcKICAgICAgICAgICAgRGlyZWN0b3JhdGUsIHBsZWFz ZSBzZWUKICAgICAgICAgICAgPGEKICAgICAgICAgICAgICBocmVmPSJodHRwOi8vdHJhYy50 b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyIgogICAgICAgICAgICAg IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+PHNwYW4gY2xhc3M9Imljb24iPjxzcGFuCnN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiNCQjAw MDA7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPuKAizwvc3Bhbj48L3NwYW4+aHR0cDovL3RyYWMu dG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpcjwvYT4KICAgICAgICAg ICAgPG86cD48L286cD48L3NwYW4+PC9wPgogICAgICAgIDxwPjxzcGFuCnN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+QWx0aG91Z2gKICAgICAgICAgICAgdGhlc2UgY29tbWVudHMgYXJl IHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsCiAgICAgICAgICAg IGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcg d2l0aAogICAgICAgICAgICBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhh dCB5b3UgcmVjZWl2ZSwgYW5kCiAgICAgICAgICAgIHN0cml2ZSB0byByZXNvbHZlIHRoZW0g dGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZQogICAgICAgICAgICBkcmFm dC4gPG86cD48L286cD48L3NwYW4+PC9wPgogICAgICAgIDxwPjxzcGFuCnN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+RG9jdW1lbnQ6CiAgICAgICAgICA8L3NwYW4+PHNwYW4KICAgICAg ICAgICAgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5yZXZpZXcKICAgICAgICAgICAgb2YgZHJhZnQtaWV0Zi1zcHJp bmctc2VnbWVudC1yb3V0aW5nLW1wbHMtMTg8L3NwYW4+PHNwYW4Kc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj48YnI+CiAgICAgICAgICAgIFJldmlld2VyOiBBbGV4YW5kZXIgKOKAnFNh c2hh4oCdKSBWYWluc2h0ZWluPGJyPgogICAgICAgICAgICBSZXZpZXcgRGF0ZTogMTAtTWFy LTE5PGJyPgogICAgICAgICAgICBJRVRGIExDIEVuZCBEYXRlOiAwNy1NYXItMjAxOTxicj4K ICAgICAgICAgICAgSW50ZW5kZWQgU3RhdHVzOiA8L3NwYW4+PHNwYW4KICAgICAgICAgICAg c3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRl Ij5Qcm9wb3NlZAogICAgICAgICAgICBTdGFuZGFyZDwvc3Bhbj48c3BhbgpzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KICAgICAgICA8cD48c3Ry b25nPjxzcGFuCnN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+U3VtbWFyeTo8L3NwYW4+PC9z dHJvbmc+PHNwYW4Kc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4KICAgICAgICAgICAgSSBo YXZlIHNvbWUgbWlub3IgY29uY2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkgdGhp bmsKICAgICAgICAgICAgc2hvdWxkIGJlIHJlc29sdmVkIGJlZm9yZSBwdWJsaWNhdGlvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+CiAgICAgICAgPHA+PGI+PHNwYW4Kc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5Db21tZW50czwvc3Bhbj48L2I+PHNwYW4Kc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj46CiAgICAgICAgICAgIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KICAgICAg ICA8cD48c3BhbgpzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkkKICAgICAgICAgICAgaGF2 ZSBkb25lIGFuIGVhcmx5IFJURy1ESVIgcmV2aWV3IG9mIHRoZSAtMTQgdmVyc2lvbiBvZiB0 aGUKICAgICAgICAgICAgZHJhZnQgaGFsZiBhIHllYXIgYWdvLCBhbmQgdGhlIGlzc3VlcyBJ 4oCZdmUgcmFpc2VkIHRoZW4gaGF2ZQogICAgICAgICAgICBiZWVuIHJlc29sdmVkIGluIHRo ZSBzdWJzZXF1ZW50IHZlcnNpb25zIG9uZSB3YXkgb3IKICAgICAgICAgICAgYW5vdGhlciku IFRoZXJlZm9yZSB0aGlzIHJldmlldyBoYXMgYmVlbiBpbnRlbnRpb25hbGx5CiAgICAgICAg ICAgIGZvY3VzZWQgb24gdGhlIGNoYW5nZXMgZG9uZSB0byB0aGUgZHJhZnQgaW4gdGhlIGZl dyByZWNlbnQKICAgICAgICAgICAgdmVyc2lvbnMuCiAgICAgICAgICAgIDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4KICAgICAgICA8cD48c3BhbgpzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PkluCiAgICAgICAgICAgIG15IHByZXZpb3VzIHJldmlldyBJIGhhdmUgbm90aWNlZCB0aGF0 IHRoZSBkcmFmdCB3YXMgbm90CiAgICAgICAgICAgIGVhc3kgcmVhZGluZyBmb3IgbWUuIFNp bmNlIHRoZW4gcmVhZGFiaWxpdHkgb2YgdGhlIGRyYWZ0IGhhcwogICAgICAgICAgICBiZWVu IGltcHJvdmVkLiBIb3dldmVyLCB0aGVyZSBhcmUgc3RpbGwgc2V2ZXJhbCBwbGFjZXMgaW4K ICAgICAgICAgICAgdGhlIG5ldyB0ZXh0IHRoYXQgYXJlIHN0aWxsIGRpZmZpY3VsdCB0byBw YXJzZS4gPG86cD48L286cD48L3NwYW4+PC9wPgogICAgICAgIDxwPjxzcGFuCnN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+SQogICAgICAgICAgICBkaWQgbm90IHJ1biB0aGUgbml0cyBj aGVja2VyIG9uIHRoZSBkcmFmdCwgc28gbXkgbGlzdCBvZgogICAgICAgICAgICBuaXRzIGlz IHByb2JhYmx5IGluY29tcGxldGUuPG86cD48L286cD48L3NwYW4+PC9wPgogICAgICAgIDxw PjxzcGFuCnN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SnVzdAogICAgICAgICAgICBhcyB3 aXRoIG15IGVhcmxpZXIgcmV2aWV3LCBJIHNlbmQgdGhpcyBvbmUgYWxzbyB0byB0aGUgTVBM UwogICAgICAgICAgICBXRyBsaXN0IOKAkyBhbmQgZm9yIHRoZSBzYW1lIHJlYXNvbnMuPG86 cD48L286cD48L3NwYW4+PC9wPgogICAgICAgIDxwPjxzcGFuCnN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+SQogICAgICAgICAgICB0cmllZCB0byBkaXNjdXNzIG15IHJldmlldyBwcml2 YXRlbHkgd2l0aCB0aGUgYXV0aG9ycywgYnV0CiAgICAgICAgICAgIHRoZXkgZGlkIG5vdCBy ZXNwb25kLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KICAgICAgICA8cD48Yj48c3BhbgpzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPk1ham9yCiAgICAgICAgICAgICAgSXNzdWVzPC9zcGFu PjwvYj48c3BhbgpzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjoKICAgICAgICAgICAgTm8g bWFqb3IgaXNzdWVzIGZvdW5kLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KICAgICAgICA8cD48 Yj48c3BhbgpzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk1pbm9yCiAgICAgICAgICAgICAg SXNzdWVzPC9zcGFuPjwvYj48c3BhbgpzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjoKICAg ICAgICAgICAgPG86cD48L286cD48L3NwYW4+PC9wPgogICAgICAgIDxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjM5Ljc1cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZl bDEgbGZvMiI+PCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij7CoMKgwqAgPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCEtLVtlbmRpZl0tLT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRo ZSB0ZXh0IGluIFNlY3Rpb24gMSBzdGF0ZXMgdGhhdDwvc3Bhbj4g4oCcPGI+YSBuZXR3b3Jr IG9wZXJhdG9yIFNIT1VMRCBjb25maWd1cmUgYXQgbGVhc3Qgb25lIG5vZGUgc2VnbWVudCBw ZXIgcm91dGluZyBpbnN0YW5jZSwgdG9wb2xvZ3ksIGFsZ29yaXRobTwvYj7igJ0gPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+YW5kIGNvbnRpbnVlcyB0aGF0PC9zcGFuPiDigJw8Yj5BbiBpbXBsZW1lbnRh dGlvbiBNQVkgY2hlY2sgdGhhdCBhbiBJR1Agbm9kZS1TSUQgaXMgbm90IGFzc29jaWF0ZWQg d2l0aCBhIHByZWZpeCB0aGF0IGlzIG93bmVkIGJ5IG1vcmUgdGhhbiBvbmUgcm91dGVyIHdp dGhpbiB0aGUgc2FtZSByb3V0aW5nIGRvbWFpbiwgSWYgc28sIGl0IFNIT1VMRCBOT1QgdXNl IHRoaXMgTm9kZS1TSUQsIE1BWSB1c2UgYW5vdGhlciBvbmUgaWYgYXZhaWxhYmxlLCBhbmQg U0hPVUxEIGxvZyBhbiBlcnJvcjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj7igJ0uIFRoaXMgbG9va3Mg c29tZXdoYXQgY29udHJvdmVyc2lhbCB0byBtZSBiZWNhdXNlOjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPgogICAgICAgIDxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Ojc1Ljc1cHQ7dGV4dC1p bmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIgbGZvMiI+PCEtLVtpZiAhc3VwcG9y dExpc3RzXS0tPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PmEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij7CoMKgwqAgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT48c3BhbiBkaXI9 IkxUUiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoZSBjaGVjayBvZiB0aGUgTm9kZSBTSUQg bm90IGJlaW5nIG93bmVkIGJ5IG1vcmUgdGhhbiBvbmUgcm91dGVyIGluIHRoZSByb3V0aW5n IGRvbWFpbiBpcyBkZWZpbmVkIGFzIHB1cmVseSBvcHRpb25hbC4gQWNjb3JkaW5nIHRvIFJG QyAyMTE5LCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBjaG9vc2UgdG8gaW1wbGVtZW50IHN1Y2gg YSBjaGVjayBtdXN0IGJlIGFibGUgdG8gaW50ZXJvcGVyYXRlIHdpdGggaW1wbGVtZW50YXRp b25zIHRoYXQgZG8gbm90IGltcGxlbWVudCBpdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4K ICAgICAgICA8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3NS43NXB0O3RleHQtaW5kZW50Oi0x OC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzIiPjwhLS1baWYgIXN1cHBvcnRMaXN0c10t LT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5iLjxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+wqDCoMKg IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhLS1bZW5kaWZdLS0+PHNwYW4gZGlyPSJMVFIiPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5UaGUgcmVjb21tZW5kZWQgaGFuZGxpbmcgb2YgdGhlIHJl c3VsdHMgb2YgdGhpcyBjaGVjayAoZnVsbHkgYWxpZ25lZCB3aXRoIHRoZSB0ZXh0IGluIFNl Y3Rpb24gMy4yIHBmIFJGQyA4NDAyIHRoYXQgcHJvaGliaXRzIHVzaW5nIHByZWZpeGVzIG93 bmVkIGJ5IG1vcmUgdGhhbiBvbmUgcm91dGVyIGluIHRoZSBkb21haW4gYXMgTm9kZS1TT0Rz KSBzdHJvbmdseSBzdWdnZXN0cyB0aGF0IHRoZSBwcmVmaXggdGhhdCBpcyBvd25lZCBieSBt b3JlIHRoYW4gb25lIHJvdXRlciBpbiB0aGUgZG9tYWluIGlzIHVudXNhYmxlIGFzIHRoZSBO b2RlIFNJRCDCoDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPgogICAgICAgIDxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM5Ljc1cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkkgc2VlIHR3byBwb3NzaWJp bGl0aWVzIHRvIHJlc29sdmUgdGhpcyBjb250cm92ZXJzeTogZWl0aGVyIG1ha2UgdGhlIGNo ZWNrIGluIHF1ZXN0aW9uIGEg4oCccmVhbCByZXF1aXJlbWVudOKAnSAoaS5lLiwgcmVwbGFj ZSA8L3NwYW4+PGI+TUFZPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiB3aXRoIDwvc3Bhbj48Yj5TSE9V TEQ8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+IG9yIGV2ZW4gPC9zcGFuPjxiPk1VU1Q8L2I+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+KSwgb3IgZXhwbGFpbiB3aHkgaXQgaXMgc2FmZSBlbm91Z2ggbm90IHRvIGlt cGxlbWVudCBzdWNoIGEgY2hlY2sgKGkuZS4sIGhvdyBpbXBsZW1lbnRhdGlvbnMgdGhhdCBz dXBwb3J0IHRoaXMgY2hlY2sgYW5kIGltcGxlbWVudGF0aW9ucyB0aGF0IGRvIG5vdCBzdXBw b3J0IGl0IGNhbiBpbnRlcm9wZXJhdGUgd2l0aGluIGEgZ2l2ZW4gcm91dGluZyBkb21haW4p PC9zcGFuPi4gPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGhlIGZpcnN0IG9mIHRoZXNlIG9wdGlvbnMgc2Vl bXMgdG8gbWUgYWxpZ25lZCB3aXRoIFNlY3Rpb24gMy4yIGluIFJGQyA4NDAyIHRoYXQgc2F5 cyB0aGF0IOKAnDwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QW4g SUdQIE5vZGUtU0lEIE1VU1QgTk9UIGJlIGFzc29jaWF0ZWQgd2l0aCBhIHByZWZpeCB0aGF0 IGlzIG93bmVkIGJ5IG1vcmUgdGhhbiBvbmUgcm91dGVyIHdpdGhpbiB0aGUgc2FtZSByb3V0 aW5nIGRvbWFpbjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+4oCdLiA8L3NwYW4+wqDCoMKg PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+CiAgICAgIDwvZGl2Pgog ICAgPC9ibG9ja3F1b3RlPgogICAgI0FobWVkOiBJIHJlcGxhY2VkIHRoZSBNQVkgd2l0aCBT SE9VTEQ8YnI+CiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIgpjaXRlPSJtaWQ6VkkxUFIw M01CMzgzOUI1RkEwN0VBREU1NzA4NEY4RTM4OUQ0RjBAVkkxUFIwM01CMzgzOS5ldXJwcmQw My5wcm9kLm91dGxvb2suY29tIj4KICAgICAgPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4K ICAgICAgICA8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIKICAgICAgICAgIHN0eWxlPSJt YXJnaW4tbGVmdDozOS43NXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAKICAg ICAgICAgIGxldmVsMSBsZm8yIj4KICAgICAgICAgIDwhLS1baWYgIXN1cHBvcnRMaXN0c10t LT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuCiAgICAgICAgICAgICAg c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij7CoMKgwqDC oMKgwqAKICAgICAgICAgICAgPC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPjxzcGFuIGRp cj0iTFRSIj48L3NwYW4+SSBoYXZlwqAgYQogICAgICAgICAgcHJvYmxlbSB3aXRoIHRoZSA8 c3BhbgogICAgICAgICAgICBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdo dDp5ZWxsb3ciPgogICAgICAgICAgICBoaWdobGlnaHRlZDwvc3Bhbj4gcGFydCBvZiB0aGUg Zm9sbG93aW5nIHRleHQgaW4gU2VjdGlvbgogICAgICAgICAgMi41OjxvOnA+PC9vOnA+PC9w PgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4w cHQiPjxzcGFuCiAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIKICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj7C oMKgCiAgICAgICAgICA8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BbgogICAgICAgICAgICAgIGltcGxlbWVudGF0aW9uIE1V U1QgTk9UIGFsbG93IHRoZSBNQ0NzIGJlbG9uZ2luZyB0byB0aGUKICAgICAgICAgICAgICBz YW1lPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij48Yj48c3BhbgogICAgICAgICAgICAg IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+wqDCoCByb3V0 ZXIgdG8KICAgICAgICAgICAgICBhc3NpZ24gdGhlIHNhbWUgaW5jb21pbmcgbGFiZWwgdG8g bW9yZSB0aGFuIG9uZSBTUiBGRUMuCiAgICAgICAgICAgICAgPHNwYW4gc3R5bGU9ImJhY2tn cm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij5BbjxvOnA+PC9vOnA+PC9zcGFu Pjwvc3Bhbj48L2I+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDoxOC4wcHQiPjxiPjxzcGFuCiAgICAgICAgICAgICAgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIKICAgICAgICAgICAgICBOZXcmcXVvdDs7YmFja2dyb3Vu ZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPsKgwqAKICAgICAgICAgICAgICBpbXBs ZW1lbnRhdGlvbiB0aGF0IGFsbG93cyBzdWNoIGJlaGF2aW9yIGlzIGNvbnNpZGVyZWQgYXMK ICAgICAgICAgICAgICBmYXVsdHkuPC9zcGFuPjwvYj48Yj48c3BhbgogICAgICAgICAgICAg IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286 cD48L3NwYW4+PC9iPjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MTguMHB0Ij48Yj48c3BhbgogICAgICAgICAgICAgIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+wqDCoAogICAgICAgICAgICAgIDxz cGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+UHJv Y2VkdXJlcwogICAgICAgICAgICAgICAgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGVxdWFs bHkgYXBwbGllcyB0byB0aGlzIGNhc2UsPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvYj48 L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4 LjBwdCI+PGI+PHNwYW4KICAgICAgICAgICAgICBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllcgogICAgICAgICAgICAgIE5ldyZxdW90OztiYWNrZ3JvdW5kOnllbGxvdzttc28t aGlnaGxpZ2h0OnllbGxvdyI+wqDCoCBib3RoCiAgICAgICAgICAgICAgZm9yIGluY29taW5n IGxhYmVsIGNvbGxpc2lvbiAoPGEKaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLTE4I3NlY3Rpb24tMi41 IgogICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj48c3BhbgogICAgICAg ICAgICAgICAgICBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9u ZSI+U2VjdGlvbgogICAgICAgICAgICAgICAgICAyLjU8L3NwYW4+PC9hPikgYW5kIHRoZSBl ZmZlY3Qgb248bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPgogICAgICAgIDxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPjxiPjxzcGFuCiAgICAgICAg ICAgICAgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIKICAgICAgICAgICAgICBO ZXcmcXVvdDs7YmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPsKgwqAK ICAgICAgICAgICAgICBvdXRnb2luZyBsYWJlbCBwcm9ncmFtbWluZyAoPGEKaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91 dGluZy1tcGxzLTE4I3NlY3Rpb24tMi42IgogICAgICAgICAgICAgICAgbW96LWRvLW5vdC1z ZW5kPSJ0cnVlIj48c3BhbgogICAgICAgICAgICAgICAgICBzdHlsZT0iY29sb3I6d2luZG93 dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+U2VjdGlvbgogICAgICAgICAgICAgICAgICAy LjY8L3NwYW4+PC9hPikuPC9zcGFuPjwvYj48Yj48c3BhbgogICAgICAgICAgICAgIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9iPjwvcD4KICAgICAgICA8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3NS43NXB0O3Rl eHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzIiPjwhLS1baWYgIXN1 cHBvcnRMaXN0c10tLT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj5hLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+wqDCoMKgIDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhLS1bZW5kaWZdLS0+PHNwYW4g ZGlyPSJMVFIiPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGUgU2VjdGlvbiBpbiBxdWVzdGlv biBkZWFscyB3aXRoIGluY29taW5nIGxhYmVsIGNvbGxpc2lvbiAoaW4gZmFjdCwgdGhlIHRl eHQgdGhhdCBpbW1lZGlhdGVseSBmb2xsb3dzIHRoZSBwcm9ibGVtYXRpYyBmcmFnbWVudCBz dGF0ZXMgdGhhdCDigJw8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PlRoZSBvYmplY3RpdmUgb2YgdGhlIGZvbGxvd2luZyBzdGVwcyBpcyB0byBkZXRlcm1pbmlz dGljYWxseSBpbnN0YWxsIGluIHRoZSBNUExTIEluY29taW5nIExhYmVsIE1hcCwgYWxzbyBr bm93biBhcyBsYWJlbCBGSUIsIGEgc2luZ2xlIEZFQyB3aXRoIHRoZSBpbmNvbWluZyBsYWJl bCAiTDEiPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj7igJ0gPG86cD48L286cD48L3NwYW4+ PC9wcmU+CiAgICAgICAgPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzUuNzVwdDt0ZXh0LWlu ZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8yIj48IS0tW2lmICFzdXBwb3J0 TGlzdHNdLS0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ Yi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PsKgwqDCoCA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPjxzcGFuIGRpcj0i TFRSIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+QXMgYSBjb25zZXF1ZW5jZSwgYW55IG1lbnRp b24gb2bCoCA8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPm91dGdv aW5nIGxhYmVsIHByb2dyYW1taW5nPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4sIGxvb2tz IG91dCBvZiBjb250ZXh0IChldmVuIGFjY29tcGFuaWVkIGJ5IGEgZm9yd2FyZCByZWZlcmVu Y2UgdG8gU2VjdGlvbiAyLjYpPG86cD48L286cD48L3NwYW4+PC9wcmU+CiAgICAgICAgPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzUuNzVwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1s aXN0OmwwIGxldmVsMiBsZm8yIj48IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Yy48c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPsKgwqDCoCA8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+U2VjdGlvbiAyLjYgY292ZXJzIHRoZSBpbXBhY3Qgb2YgaW5jb21pbmcgbGFi ZWwgY29sbGlzaW9uIG9uIHByb2dyYW1taW5nIG9mIG91dGdvaW5nIGxhYmVscyBpbiBxdWl0 ZSBhIGdlbmVyaWMgd2F5LiBUaGVyZWZvcmUgSSB0aGluayB0aGF0IHRoZSDCoDxzcGFuIHN0 eWxlPSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+aGlnaGxpZ2h0 ZWQ8L3NwYW4+IHBhcnQgb2YgdGhlIHF1b3RlZCBmcmFnbWVudCBjYW4gYmUgc2FmZWx5IHJl bW92ZWQgKGNvbXBsZXRlIHdpdGggdGhlIGdyYW1tYXIgbWlzdGFrZSkuPG86cD48L286cD48 L3NwYW4+PC9wcmU+CiAgICAgICAgPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzUuNzVwdDt0 ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8yIj48IS0tW2lmICFz dXBwb3J0TGlzdHNdLS0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+ZC48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPsKgwqDCoCA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPjxzcGFu IGRpcj0iTFRSIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSBhbHNvIGRvIG5vdCBzZWUgYW55 IHZhbHVlIGluIHN0YXRpbmcgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbnMgdGhhdCB2aW9sYXRl cyBhIG1hbmRhdG9yeSByZXF1aXJlbWVudCBvZiB0aGUgc3BlYyBpcyBmYXVsdHkg4oCTIGlz buKAmXQgdGhhdCBzZWxmLWV2aWRlbnQ/PC9zcGFuPjwvcHJlPgogICAgICA8L2Rpdj4KICAg IDwvYmxvY2txdW90ZT4KICAgIDxwPiNBaG1lZDogSSByZW1vdmVkIHRoZSBoaWdobGlnaHRl ZCB0ZXh0IGJlY2F1c2UgSSBhZ3JlZSB3aXRoIHdoYXQKICAgICAgeW91IHNhaWQgaW4gaXRl bSAoZCkgdGhhdCBpdCBoYXMgbm8gdmFsdWU8L3A+CiAgICA8cD48YnI+CiAgICA8L3A+CiAg ICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIgpjaXRlPSJtaWQ6VkkxUFIwM01CMzgzOUI1RkEw N0VBREU1NzA4NEY4RTM4OUQ0RjBAVkkxUFIwM01CMzgzOS5ldXJwcmQwMy5wcm9kLm91dGxv b2suY29tIj4KICAgICAgPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4KICAgICAgICA8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDo3NS43NXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxp c3Q6bDAgbGV2ZWwyIGxmbzIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPgogICAgICAgIDxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM5Ljc1cHQ7dGV4dC1pbmRl bnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCEtLVtpZiAhc3VwcG9ydExp c3RzXS0tPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMu PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij7C oMKgwqAgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT48c3BhbiBkaXI9IkxU UiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoZSA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5 ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPmhpZ2hsaWdodGVkPC9zcGFuPiB0ZXh0IGlu IFNlY3Rpb24gMi44IGlzIG5vdCBhY2N1cmF0ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4K ICAgICAgICA8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoyMS43NXB0Ij48Yj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPsKgwqAgRm9yIExvY2FsIFNJRHMsIHRoZSBNQ0MgaXMgcmVzcG9u c2libGUgZm9yIGRvd25sb2FkaW5nIHRoZSBjb3JyZWN0PG86cD48L286cD48L3NwYW4+PC9i PjwvcHJlPgogICAgICAgIDxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjIxLjc1cHQiPjxiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+wqDCoCBsYWJlbCB2YWx1ZSB0byBGSUIuIEZvciBl eGFtcGxlLCBhbiBJR1Agd2l0aCBTUiBleHRlbnNpb25zIFtJLUQuaWV0Zi08bzpwPjwvbzpw Pjwvc3Bhbj48L2I+PC9wcmU+CiAgICAgICAgPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEu NzVwdCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj7CoMKgIGlzaXMtc2VnbWVudC1y b3V0aW5nLWV4dGVuc2lvbnMsIEktRC5pZXRmLW9zcGYtc2VnbWVudC1yb3V0aW5nLTxvOnA+ PC9vOnA+PC9zcGFuPjwvYj48L3ByZT4KICAgICAgICA8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDoyMS43NXB0Ij48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPsKgwqAgZXh0ZW5zaW9u c10gPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93 Ij5hbGxvY2F0ZXM8L3NwYW4+IGFuZCBkb3dubG9hZHMgdGhlIE1QTFMgbGFiZWwgY29ycmVz cG9uZGluZyB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3ByZT4KICAgICAgICA8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDoyMS43NXB0Ij48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PsKgwqAgYW4gQWRqLVNJRCBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzg0MDIiIHRpdGxlPSImcXVvdDtTZWdtZW50IFJvdXRpbmcgQXJjaGl0ZWN0dXJlJnF1 b3Q7IiBtb3otZG8tbm90LXNlbmQ9InRydWUiPlJGQzg0MDI8L2E+XS48bzpwPjwvbzpwPjwv c3Bhbj48L2I+PC9wcmU+CiAgICAgICAgPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzUuNzVw dDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8yIj48IS0tW2lm ICFzdXBwb3J0TGlzdHNdLS0+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5hLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+wqAgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9iPjwh LS1bZW5kaWZdLS0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JR1Ag d2l0aCBTUiBleHRlbnNpb25zPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+bWF5IGluZGVlZCBkeW5hbWljYWxseSBhbGxv Y2F0ZSBhbmQgZG93bmxvYWQgTVBMUyBsYWJlbHMgYWN0aW5nIGFzIGxvY2FsIEFkai1TSURz IDwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvYj48L3ByZT4KICAgICAgICA8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3NS43NXB0O3Rl eHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzIiPjwhLS1baWYgIXN1 cHBvcnRMaXN0c10tLT48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPmIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij7CoCA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L2I+PCEtLVtl bmRpZl0tLT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkhvd2V2ZXIs IHRoZXNlIGxhYmVscyBjYW4gYmUgYWxsb2NhdGVkIGJ5IGNvbmZpZ3VyYXRpb24gKGUuZy4g YXMgbWVudGlvbmVkIGluIHRoZSB0aWUtYnJlYWtpbmcgcnVsZXMgaW4gU2VjdGlvbiAyLjUu MSBhbmQgaW4gdGhlIGV4YW1wbGUgaW4gU2VjdGlvbiBBLjIuMyBpbiB0aGUgZHJhZnQpLCBp biB3aGljaCBjYXNlIElHUCB3aXRoIFNSIGV4dGVuc2lvbnMgd291bGQgb25seSByZXNwb25z aWJsZSBmb3IgaXRzIGFkdmVydGlzZW1lbnQgYW5kIGluc3RhbGxhdGlvbi4gPC9zcGFuPjxi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9iPjwvcHJl PgogICAgICA8L2Rpdj4KICAgIDwvYmxvY2txdW90ZT4KICAgICNBaG1lZDogSSByZW1vdmVk IHRoZSBoaWdobGlnaHRlZCB3b3JkICJhbGxvY2F0ZWQiIDxicj4KICAgIDxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiCmNpdGU9Im1pZDpWSTFQUjAzTUIzODM5QjVGQTA3RUFERTU3MDg0RjhF Mzg5RDRGMEBWSTFQUjAzTUIzODM5LmV1cnByZDAzLnByb2Qub3V0bG9vay5jb20iPgogICAg ICA8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPgogICAgICAgIDxwcmU+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+PG86cD7CoDwvbzpwPjwvc3Bhbj48L3ByZT4KICAgICAgICA8cHJlPjxiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPk5JVFM8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjo8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4KICAgICAgICA8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiA6PC9zcGFuPjxiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9iPjwvcHJlPgogICAg ICAgIDxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM5Ljc1cHQ7dGV4dC1pbmRlbnQ6LTE4LjBw dDttc28tbGlzdDpsMSBsZXZlbDEgbGZvNCI+PCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij7CoMKgwqAgPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT48c3BhbiBkaXI9IkxUUiI+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPkluIHNlY3Rpb24gMi41OjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl PgogICAgICAgIDxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDot MTguMHB0O21zby1saXN0OmwxIGxldmVsMiBsZm80Ij48IS0tW2lmICFzdXBwb3J0TGlzdHNd LS0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+YS48c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPsKgwqDC oCA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPjxzcGFuIGRpcj0iTFRSIj48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+SW4gdGhlIHNlbnRlbmNlIOKAnDwvc3Bhbj48Yj5Qcm9j ZWR1cmVzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBlcXVhbGx5IGFwcGxpZXMgdG8gdGhp cyBjYXNlPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPuKAnSB0aGUgbm91biBpcyBpbiBwbHVyYWwgYnV0 IHRoZSB2ZXJiIGlzIGluIHNpbmd1bGFyLiAoSWYgdGhpcyBzZW50ZW5jZSBpcyByZW1vdmVk IGFzIHN1Z2dlc3RlZCBhYm92ZSwgdGhpcyBuaXQgZGlzYXBwZWFycyk8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4KICAgICAgICA8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4 dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDIgbGZvNCI+PCEtLVtpZiAhc3Vw cG9ydExpc3RzXS0tPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPmIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij7CoMKgwqAgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT48c3BhbiBk aXI9IkxUUiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoZSBzYW1lIHByb2JsZW0gZXhpc3Rz IGluIHRoZSBzZW50ZW5jZSDigJw8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5BbiBpbmNvbWluZyBsYWJlbCBjb2xsaXNpb24gb2NjdXJzIGlmIHRoZSBTSURzIG9mIHRo ZSBzZXQgb2YgRkVDcyB7RkVDMSwgRkVDMiwuLi4sIEZFQ2t9IG1hcHMgdG8gdGhlIHNhbWUg aW5jb21pbmcgU1IgTVBMUyBsYWJlbCAiTDEiPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj7i gJ08L3NwYW4+PC9wcmU+CiAgICAgIDwvZGl2PgogICAgPC9ibG9ja3F1b3RlPgogICAgI0Fo bWVkOiBUaGUgc2VudGVuY2UgaXMgcmVtb3ZlZCBhcyB5b3Ugc3VnZ2VzdGVkPGJyPgogICAg PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIKY2l0ZT0ibWlkOlZJMVBSMDNNQjM4MzlCNUZBMDdF QURFNTcwODRGOEUzODlENEYwQFZJMVBSMDNNQjM4MzkuZXVycHJkMDMucHJvZC5vdXRsb29r LmNvbSI+CiAgICAgIDxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+CiAgICAgICAgPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 bDEgbGV2ZWwyIGxmbzQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl PgogICAgICAgIDxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIgogICAgICAgICAgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM5Ljc1cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMQog ICAgICAgICAgbGV2ZWwxIGxmbzQiPgogICAgICAgICAgPCEtLVtpZiAhc3VwcG9ydExpc3Rz XS0tPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4KICAgICAgICAgICAg ICBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPsKgwqDC oMKgwqDCoAogICAgICAgICAgICA8L3NwYW4+PC9zcGFuPjwhLS1bZW5kaWZdLS0+PHNwYW4g ZGlyPSJMVFIiPjwvc3Bhbj5JbgogICAgICAgICAgc2VjdGlvbiAyLjEwLjEgdGhlIHByZXBv c2l0aW9uIOKAnDxiPjxzcGFuCiAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij50bzwvc3Bhbj48L2I+4oCdCiAgICAgICAgICBiZXR3 ZWVuIHRoZSB3b3JkcyDigJw8Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllcgogICAgICAgICAgICAgIE5ldyZxdW90OyI+YWNjb3JkaW5nPC9zcGFuPjwvYj7igJ0g YW5kIOKAnDxiPjxzcGFuCiAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5NUExTPC9zcGFuPjwvYj7igJ0KICAgICAgICAgIGlzIG1p c3NpbmcgaW4gdGhlIGZyYWdtZW50IOKAnDxiPjxzcGFuCiAgICAgICAgICAgICAgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5QdXNoIHRoZQogICAgICAg ICAgICAgIGNhbGN1bGF0ZWQgbGFiZWwgYWNjb3JkaW5nIHRoZSBNUExTIGxhYmVsIHB1c2hp bmcgcnVsZXMKICAgICAgICAgICAgICBzcGVjaWZpZWQgaW4gW1JGQzMwMzJdPC9zcGFuPjwv Yj7igJ0uPC9wPgogICAgICA8L2Rpdj4KICAgIDwvYmxvY2txdW90ZT4KICAgICNBaG1lZCBh ZGRlZCB0aGUgbWlzc2luZyAidG8iPGJyPgogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIK Y2l0ZT0ibWlkOlZJMVBSMDNNQjM4MzlCNUZBMDdFQURFNTcwODRGOEUzODlENEYwQFZJMVBS MDNNQjM4MzkuZXVycHJkMDMucHJvZC5vdXRsb29rLmNvbSI+CiAgICAgIDxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+CiAgICAgICAgPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiCiAg ICAgICAgICBzdHlsZT0ibWFyZ2luLWxlZnQ6MzkuNzVwdDt0ZXh0LWluZGVudDotMTguMHB0 O21zby1saXN0OmwxCiAgICAgICAgICBsZXZlbDEgbGZvNCI+PG86cD48L286cD48L3A+CiAg ICAgICAgPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiCiAgICAgICAgICBzdHlsZT0ibWFy Z2luLWxlZnQ6MzkuNzVwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxCiAgICAg ICAgICBsZXZlbDEgbGZvNCI+CiAgICAgICAgICA8IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My48c3BhbgogICAgICAgICAgICAgIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+wqDCoMKgwqDC oMKgCiAgICAgICAgICAgIDwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT48c3BhbiBkaXI9 IkxUUiI+PC9zcGFuPlByb2JsZW1zCiAgICAgICAgICB3aXRoIHJlZmVyZW5jZXM6PG86cD48 L286cD48L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiCiAgICAgICAg ICBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxp c3Q6bDEKICAgICAgICAgIGxldmVsMiBsZm80Ij4KICAgICAgICAgIDwhLS1baWYgIXN1cHBv cnRMaXN0c10tLT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5hLjxzcGFuCiAgICAg ICAgICAgICAgc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij7CoMKgwqDCoMKgwqAKICAgICAgICAgICAgPC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0t PjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+PGEKaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5p ZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvQ19XM0tCY0wyQVd4bWxCN1NwNTNfUHZxYlFBIgog ICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPkFzIHJlcG9ydGVkIGJ5IFNlcmdl eTwvYT4sIHRoZXJlIGFyZQogICAgICAgICAgdHdvIG9jY3VycmVuY2VzIG9mIHJlZmVyZW5j ZXMgdG8gUkZDIDgwNDIg4oCcT1NQRiBUd28tUGFydAogICAgICAgICAgTWV0cmlj4oCdIGlu c3RlYWQgb2YgUkZDIDg0MDIuIExvdHMgb2YgdGhhbmtzIHRvIFNlcmdleSBmb3IKICAgICAg ICAgIGNhdGNoaW5nIHRoaXM8L3A+CiAgICAgIDwvZGl2PgogICAgPC9ibG9ja3F1b3RlPgog ICAgI0FobWVkOiBDb3JyZWN0ZWQsIHRoYW5rcyBhZ2Fpbjxicj4KICAgIDxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiCmNpdGU9Im1pZDpWSTFQUjAzTUIzODM5QjVGQTA3RUFERTU3MDg0RjhF Mzg5RDRGMEBWSTFQUjAzTUIzODM5LmV1cnByZDAzLnByb2Qub3V0bG9vay5jb20iPgogICAg ICA8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPgogICAgICAgIDxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIgogICAgICAgICAgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWlu ZGVudDotMTguMHB0O21zby1saXN0OmwxCiAgICAgICAgICBsZXZlbDIgbGZvNCI+PG86cD48 L286cD48L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiCiAgICAgICAg ICBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxp c3Q6bDEKICAgICAgICAgIGxldmVsMiBsZm80Ij4KICAgICAgICAgIDwhLS1baWYgIXN1cHBv cnRMaXN0c10tLT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5iLjxzcGFuCiAgICAg ICAgICAgICAgc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij7CoMKgwqDCoMKgwqAKICAgICAgICAgICAgPC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0t PjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+UmVmZXJlbmNlCiAgICAgICAgICB0byBSRkMgODE3 NCBtaXN0YWtlbmx5IGNvbnRhaW5zIGEgbGluayB0b8KgIFJGQyA3Mjc0LjwvcD4KICAgICAg PC9kaXY+CiAgICA8L2Jsb2NrcXVvdGU+CiAgICAjQWhtZWQ6IENvcnJlY3RlZDxicj4KICAg IDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiCmNpdGU9Im1pZDpWSTFQUjAzTUIzODM5QjVGQTA3 RUFERTU3MDg0RjhFMzg5RDRGMEBWSTFQUjAzTUIzODM5LmV1cnByZDAzLnByb2Qub3V0bG9v ay5jb20iPgogICAgICA8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPgogICAgICAgIDxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIgogICAgICAgICAgc3R5bGU9Im1hcmdpbi1sZWZ0Ojcy LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxCiAgICAgICAgICBsZXZlbDIg bGZvNCI+PG86cD48L286cD48L3A+CiAgICAgICAgPHA+PHNwYW4Kc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5Ib3BlZnVsbHkKICAgICAgICAgICAgdGhlc2Ugbm90ZXMgd2lsbCBiZSB1 c2VmdWwuPC9zcGFuPjwvcD4KICAgICAgPC9kaXY+CiAgICA8L2Jsb2NrcXVvdGU+CiAgICAj QWhtZWQ6IFZFUlkgdXNlZnVsPGJyPgogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIKY2l0 ZT0ibWlkOlZJMVBSMDNNQjM4MzlCNUZBMDdFQURFNTcwODRGOEUzODlENEYwQFZJMVBSMDNN QjM4MzkuZXVycHJkMDMucHJvZC5vdXRsb29rLmNvbSI+CiAgICAgIDxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+CiAgICAgICAgPHA+PHNwYW4Kc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+ UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5T YXNoYTxvOnA+PC9vOnA+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ wqA8L286cD48L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+T2ZmaWNlOiArOTcy LTM5MjY2MzAyPG86cD48L286cD48L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Q2VsbDrCoMKgwqDCoMKgICs5NzItNTQ5MjY2MzAyPG86cD48L286cD48L3A+CiAgICAgICAg PHAgY2xhc3M9Ik1zb05vcm1hbCI+RW1haWw6wqDCoCA8YSBjbGFzcz0ibW96LXR4dC1saW5r LWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVs ZS5jb20iPkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPC9hPjxvOnA+PC9vOnA+ PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+wqA8L286cD48L3A+CiAg ICAgIDwvZGl2PgogICAgICA8YnIgY2xlYXI9ImFsbCI+Cl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4KICAgICAgPGJyPgogICAgICBUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVk IGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kCiAgICAgIGNvbnRhaW5zIGluZm9ybWF0aW9u IHdoaWNoIGlzIDxicj4KICAgICAgQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJv cHJpZXRhcnkgdG8gRUNJIFRlbGVjb20uIElmIHlvdQogICAgICBoYXZlIHJlY2VpdmVkIHRo aXMgPGJyPgogICAgICB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gdXMg YnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsCiAgICAgIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3Jp Z2luYWwgPGJyPgogICAgICBhbmQgYWxsIGNvcGllcyB0aGVyZW9mLjxicj4KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPgogICAgPC9ibG9ja3F1b3RlPgogIDwvYm9keT4KPC9odG1sPgo= --------------8CCF32B57D81BFE5451EA093-- From nobody Fri Mar 29 21:13:51 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1ABE1203DA for ; Fri, 29 Mar 2019 21:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.49 X-Spam-Level: X-Spam-Status: No, score=-17.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, 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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 sXhalW2px7_N for ; Fri, 29 Mar 2019 21:13:45 -0700 (PDT) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 00B471203D0 for ; Fri, 29 Mar 2019 21:13:44 -0700 (PDT) Received: by mail-it1-x133.google.com with SMTP id m137so7059090ita.0 for ; Fri, 29 Mar 2019 21:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pwJ7RfF8feu4vFo74s9ZOiw95wCHvWkpgnpz8+zjfAE=; b=oFClJgpR6KSCBxr+VDO/V1JONXxseaaPrEOCMWFxS0qpKXy/vN93H043ZQ4S/YPF2M TgWuRvUZGY+VRy40c876/Ahv5mbSHrTqINR0d/ivvxXYUKmAR034s3IY5T/Fc4iy895F 28RyfScQGp+cdgiIA4bpS17sy0S1zoioIuLvejR/tvgyZRfR+QDSoAcuPbgJktl28H4s NAgXHutCQR1PbSlaAGgGlJckQAvzHBUoDNPDO3q3YX7NeDCHnxSqoBAuTdICnSo8YUPb 0rJBS/hqtnMmh9Hrg9jsXjbPPmNQt+WdAw5Ym6D7tfzEs1C7CHs8yTHGz2lb1vjinfdb VxdA== 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=pwJ7RfF8feu4vFo74s9ZOiw95wCHvWkpgnpz8+zjfAE=; b=N+yFxCmM/RSwJO8gYBCLp2zr+3z2KkuBL45uI4BSeipgMKofXC5wqtZV5+jp2yM7bG ROXa47aYYYxMWxqYeUkruTa5eLezdhybkG9Fiemawty/3q593lyHT7pdZ8RIgnIV4iet lcl/LKmDSS58fhk6DDM/6jF27e6UzoDk4peMyfxmrHC+83/EK0AQSdjfThW6ybAXCJ1D whMGVicIXj977nJuj7PdQ/u8kwJfN8CJVx8bO/dnyvpQsPUA6DhUBaM0Gz/kqaDwr7AZ DSLe+0NZiEc2oNyDE9u7yAWbwN68Wr/oWOukTZCUIO7yJ8+/cxvwAPoqmPM5J4Y+Ta+1 21Yw== X-Gm-Message-State: APjAAAUiqpruHMZUDkkh1K/L2XfZeFsoaL2r9eYj/BVEsBP5IPgnY772 DaoVTArQP2foLN599HMZOryClja1FzqcBO+Q3ATl/Q== X-Google-Smtp-Source: APXvYqxA05Uq3I5alUaQsIME5HJ8vf3zKHGCJsTK5l8JDcOpgvK38+ux8jxKANvwLrq2XYB+pyWvWP9HKxXQHFFuJ5Q= X-Received: by 2002:a24:7c52:: with SMTP id a79mr84450itd.51.1553919223787; Fri, 29 Mar 2019 21:13:43 -0700 (PDT) MIME-Version: 1.0 References: <65361777-db63-9a7a-9199-dd04425b4785@gmail.com> In-Reply-To: <65361777-db63-9a7a-9199-dd04425b4785@gmail.com> From: Przemyslaw Krol Date: Sat, 30 Mar 2019 05:13:05 +0100 Message-ID: To: Ahmed Bashandy Cc: Alexander Vainshtein , "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "spring@ietf.org" , "draft-ietf-spring-segment-routing-mpls.authors@ietf.org" , Min Ye , "mpls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000585d6d05854803bb" Archived-At: Subject: Re: [mpls] [spring] RTG-DIR Last Call review of draft-ietf-spring-segment-routing-mpls-18 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 04:13:49 -0000 --000000000000585d6d05854803bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ahmed, Cosmetic minor nit: 2.5. Incoming Label Collision [...] both links in the '(Mirrored SID)' section need a cleanup / update thanks, pk On Fri, Mar 29, 2019 at 2:14 AM Ahmed Bashandy wrote: > Thanks a lot for the review > > I uploaded version 19 of the draft, which, IMO, addresses all your commen= ts > > See the reply "#Ahmed" > On 3/10/19 9:55 AM, Alexander Vainshtein wrote: > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and sometimes > on special request. The purpose of the review is to provide assistance to > the Routing ADs. For more information about the Routing Directorate, plea= se > see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF Las= t > Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: review of draft-ietf-spring-segment-routing-mpls-18 > Reviewer: Alexander (=E2=80=9CSasha=E2=80=9D) Vainshtein > Review Date: 10-Mar-19 > IETF LC End Date: 07-Mar-2019 > Intended Status: Proposed Standard > > *Summary:* I have some minor concerns about this document that I think > should be resolved before publication. > > *Comments*: > > I have done an early RTG-DIR review of the -14 version of the draft half = a > year ago, and the issues I=E2=80=99ve raised then have been resolved in t= he > subsequent versions one way or another). Therefore this review has been > intentionally focused on the changes done to the draft in the few recent > versions. > > In my previous review I have noticed that the draft was not easy reading > for me. Since then readability of the draft has been improved. However, > there are still several places in the new text that are still difficult t= o > parse. > > I did not run the nits checker on the draft, so my list of nits is > probably incomplete. > > Just as with my earlier review, I send this one also to the MPLS WG list = =E2=80=93 > and for the same reasons. > > I tried to discuss my review privately with the authors, but they did not > respond. > > *Major Issues*: No major issues found. > > *Minor Issues*: > > 1. The text in Section 1 states that =E2=80=9C*a network operator SHOU= LD configure at least one node segment per routing instance, topology, algo= rithm*=E2=80=9D and continues that =E2=80=9C*An implementation MAY check th= at an IGP node-SID is not associated with a prefix that is owned by more th= an one router within the same routing domain, If so, it SHOULD NOT use this= Node-SID, MAY use another one if available, and SHOULD log an error*=E2=80= =9D. This looks somewhat controversial to me because: > > a. The check of the Node SID not being owned by more than one router i= n the routing domain is defined as purely optional. According to RFC 2119, = implementations that choose to implement such a check must be able to inter= operate with implementations that do not implement it > > b. The recommended handling of the results of this check (fully aligne= d with the text in Section 3.2 pf RFC 8402 that prohibits using prefixes ow= ned by more than one router in the domain as Node-SODs) strongly suggests t= hat the prefix that is owned by more than one router in the domain is unusa= ble as the Node SID > > I see two possibilities to resolve this controversy: either make the chec= k in question a =E2=80=9Creal requirement=E2=80=9D (i.e., replace *MAY* wit= h *SHOULD* or even *MUST*), or explain why it is safe enough not to impleme= nt such a check (i.e., how implementations that support this check and impl= ementations that do not support it can interoperate within a given routing = domain). The first of these options seems to me aligned with Section 3.2 in= RFC 8402 that says that =E2=80=9C*An IGP Node-SID MUST NOT be associated w= ith a prefix that is owned by more than one router within the same routing = domain*=E2=80=9D. > > #Ahmed: I replaced the MAY with SHOULD > > 2. I have a problem with the highlighted part of the following > text in Section 2.5: > > *An implementation MUST NOT allow the MCCs belonging to the same* > > * router to assign the same incoming label to more than one SR FEC. An* > > * implementation that allows such behavior is considered as faulty.* > > * Procedures defined in this document equally applies to this case,* > > * both for incoming label collision (Section 2.5 > ) > and the effect on* > > * outgoing label programming (Section 2.6 > ).* > > a. The Section in question deals with incoming label collision (in fac= t, the text that immediately follows the problematic fragment states that = =E2=80=9C*The objective of the following steps is to deterministically inst= all in the MPLS Incoming Label Map, also known as label FIB, a single FEC w= ith the incoming label "L1"*=E2=80=9D > > b. As a consequence, any mention of *outgoing label programming*, loo= ks out of context (even accompanied by a forward reference to Section 2.6) > > c. Section 2.6 covers the impact of incoming label collision on progra= mming of outgoing labels in quite a generic way. Therefore I think that the= highlighted part of the quoted fragment can be safely removed (complete w= ith the grammar mistake). > > d. I also do not see any value in stating that an implementations that= violates a mandatory requirement of the spec is faulty =E2=80=93 isn=E2=80= =99t that self-evident? > > #Ahmed: I removed the highlighted text because I agree with what you said > in item (d) that it has no value > > > 3. The highlighted text in Section 2.8 is not accurate: > > * For Local SIDs, the MCC is responsible for downloading the correct* > > * label value to FIB. For example, an IGP with SR extensions [I-D.ietf-= * > > * isis-segment-routing-extensions, I-D.ietf-ospf-segment-routing-* > > * extensions] allocates and downloads the MPLS label corresponding to* > > * an Adj-SID [RFC8402 ].* > > *a. *IGP with SR extensions may indeed dynamically allocate and download= MPLS labels acting as local Adj-SIDs > > *b. *However, these labels can be allocated by configuration (e.g. as me= ntioned in the tie-breaking rules in Section 2.5.1 and in the example in Se= ction A.2.3 in the draft), in which case IGP with SR extensions would only = responsible for its advertisement and installation. > > #Ahmed: I removed the highlighted word "allocated" > > > > *NITS*: > > : > > 1. In section 2.5: > > a. In the sentence =E2=80=9C*Procedures defined in this document equal= ly applies to this case*=E2=80=9D the noun is in plural but the verb is in = singular. (If this sentence is removed as suggested above, this nit disappe= ars) > > b. The same problem exists in the sentence =E2=80=9C*An incoming label= collision occurs if the SIDs of the set of FECs {FEC1, FEC2,..., FECk} map= s to the same incoming SR MPLS label "L1"*=E2=80=9D > > #Ahmed: The sentence is removed as you suggested > > 2. In section 2.10.1 the preposition =E2=80=9C*to*=E2=80=9D between= the words =E2=80=9C > *according*=E2=80=9D and =E2=80=9C*MPLS*=E2=80=9D is missing in the fragm= ent =E2=80=9C*Push the > calculated label according the MPLS label pushing rules specified in > [RFC3032]*=E2=80=9D. > > #Ahmed added the missing "to" > > 3. Problems with references: > > a. As reported by Sergey > , > there are two occurrences of references to RFC 8042 =E2=80=9COSPF Two-Par= t Metric=E2=80=9D > instead of RFC 8402. Lots of thanks to Sergey for catching this > > #Ahmed: Corrected, thanks again > > b. Reference to RFC 8174 mistakenly contains a link to RFC 7274. > > #Ahmed: Corrected > > Hopefully these notes will be useful. > > #Ahmed: VERY useful > > Regards, > > Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > > _________________________________________________________________________= __ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and then > delete the original > and all copies thereof. > _________________________________________________________________________= __ > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --=20 Przemyslaw "PK" Krol | Strategic Network Engineer ing | pkrol@google.com --000000000000585d6d05854803bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ahmed,

=
Cosmetic minor nit:
2.5.= Incoming Label Collision
[...]
both links in the '(Mirrored SID)' s= ection need a cleanup / update

thanks,
p= k


On Fri, Mar 29, 2019 at 2:14 AM Ahmed Bas= handy <aba= shandy.ietf@gmail.com> wrote:
=20 =20 =20

Thanks a lot for the review

I uploaded version 19 of the draft, which, IMO, addresses all your comments

See the reply "#Ahmed"

On 3/10/19 9:55 AM, Alexander Vainshtein wrote:
=20 =20 =20

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see =E2=80=8Bhttp://trac.tools.ie= tf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: review of draft-ietf-spring-segment-routing-mpls-18
Reviewer: Alexander (=E2=80=9CSasha=E2=80=9D) Vainshtein
Review Date: 10-Mar-19
IETF LC End Date: 07-Mar-2019
Intended Status: Proposed Standard

Summary: I have some minor concerns about this document that I think should be resolved before publication.

Comments:

I have done an early RTG-DIR review of the -14 version of the draft half a year ago, and the issues I=E2=80=99ve raised then = have been resolved in the subsequent versions one way or another). Therefore this review has been intentionally focused on the changes done to the draft in the few recent versions.

In my previous review I have noticed that the draft was not easy reading for me. Since then readability of the draft has been improved. However, there are still several places in the new text that are still difficult to parse. <= /span>

I did not run the nits checker on the draft, so my list of nits is probably incomplete.

Just as with my earlier review, I send this one also to the MPLS WG list =E2=80=93 and for the same reasons.

I tried to discuss my review privately with the authors, but they did not respond.

Major Issues: No major issues found.

Minor Issues: 

1.=C2=A0=C2=A0=C2=A0 The text in S=
ection 1 states that =E2=80=9Ca network operator SHOULD configure=
 at least one node segment per routing instance, topology, algorithm=E2=
=80=9D and conti=
nues that =E2=80=9CAn implementation MAY check that an IGP node-S=
ID is not associated with a prefix that is owned by more than one router wi=
thin the same routing domain, If so, it SHOULD NOT use this Node-SID, MAY u=
se another one if available, and SHOULD log an error=E2=80=9D. This looks somewhat cont=
roversial to me because:
a.=C2=A0=C2=A0=C2=A0 The check of =
the Node SID not being owned by more than one router in the routing domain =
is defined as purely optional. According to RFC 2119, implementations that =
choose to implement such a check must be able to interoperate with implemen=
tations that do not implement it 
b.=C2=A0=C2=A0=C2=A0 The recommend=
ed handling of the results of this check (fully aligned with the text in Se=
ction 3.2 pf RFC 8402 that prohibits using prefixes owned by more than one =
router in the domain as Node-SODs) strongly suggests that the prefix that i=
s owned by more than one router in the domain is unusable as the Node SID =
=C2=A0
I see two possibilities to resolve this controve=
rsy: either make the check in question a =E2=80=9Creal requirement=E2=80=9D=
 (i.e., replace MAY with SHOULD or even MUST), or explain why it is safe enough n=
ot to implement such a check (i.e., how implementations that support this c=
heck and implementations that do not support it can interoperate within a g=
iven routing domain). The first of these options seems to me aligned with Section 3.=
2 in RFC 8402 that says that =E2=80=9CAn IGP Node-SID MUST NOT be associated with a prefix that is owned by m=
ore than one router within the same routing domain=E2=80=9D. =C2=A0=C2=A0=
=C2=A0=
#Ahmed: I replaced the MAY with SHOULD

2.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I have=C2=A0 a problem with the highlighted part of the following text in Section 2.5:

=C2=A0=C2= =A0 An implementation MUST NOT allow the MCCs belonging to the same

=C2=A0=C2=A0 router to assign the same incoming label to more than one SR FEC. An

=C2=A0= =C2=A0 implementation that allows such behavior is considered as faulty.

=C2=A0=C2=A0 Procedures defined in this document equally applies to this case,

=C2=A0= =C2=A0 both for incoming label collision (Section 2.5) and the effect on

=C2=A0= =C2=A0 outgoing label programming (Section 2.6).

a.=C2=A0=C2=A0=C2=A0 The Section i=
n question deals with incoming label collision (in fact, the text that imme=
diately follows the problematic fragment states that =E2=80=9CThe objective of the following steps is to dete=
rministically install in the MPLS Incoming Label Map, also known as label F=
IB, a single FEC with the incoming label "L1"=E2=80=9D <=
/span>
b.=C2=A0=C2=A0=C2=A0 As a conseque=
nce, any mention of=C2=A0 outgoing=
 label programming, looks out of context (even accompanied by a forward referenc=
e to Section 2.6)
c.=C2=A0=C2=A0=C2=A0 Section 2.6 c=
overs the impact of incoming label collision on programming of outgoing lab=
els in quite a generic way. Therefore I think that the =C2=A0highlighted part of the quoted fragment can be s=
afely removed (complete with the grammar mistake).
        
d.=C2=A0=C2=A0=C2=A0 I also do not=
 see any value in stating that an implementations that violates a mandatory=
 requirement of the spec is faulty =E2=80=93 isn=E2=80=99t that self-eviden=
t?

#Ahmed: I removed the highlighted text because I agree with what you said in item (d) that it has no value


3.=C2=A0=C2=A0=C2=A0 The highlighted text in Section 2.8 is not accu=
rate:
=
=C2=A0=C2=A0 For Local SIDs, the MCC is responsible for downloading the cor=
rect
=
=C2=A0=C2=A0 label value to FIB. For example, an IGP with SR extensions [I-=
D.ietf-
=
=C2=A0=C2=A0 isis-segment-routing-extensions, I-D.ietf-ospf-segment-routing=
-
=
=C2=A0=C2=A0 extensions] allocates=
 and downloads the MPLS label corresponding to
        
=
=C2=A0=C2=A0 an Adj-SID [RFC8402<=
/a>].

        
<=
span>a.=C2=A0 <=
/span>IGP with SR extensions may indeed dynamically allocate and download MPLS labels acting as l=
ocal Adj-SIDs 

        
<=
span>b.=C2=A0 <=
/span>However, these labels can be allocated by configu=
ration (e.g. as mentioned in the tie-breaking rules in Section 2.5.1 and in=
 the example in Section A.2.3 in the draft), in which case IGP with SR exte=
nsions would only responsible for its advertisement and installation.
#Ahmed: I removed the highlighted word "allocated" 
=
=C2=A0
=
NITS:=

 :<=
/span>
1.=C2=A0=C2=A0=C2=A0 In section 2.=
5:
a.=C2=A0=C2=A0=C2=A0 =
In the sentence =
=E2=80=9CProcedures defined in this document equally applies to t=
his case=E2=
=80=9D the noun is in plural but the verb is in singular. (If this sentence=
 is removed as suggested above, this nit disappears)
        
b.=C2=A0=C2=A0=C2=A0 =
The same problem=
 exists in the sentence =E2=80=9CAn i=
ncoming label collision occurs if the SIDs of the set of FECs {FEC1, FEC2,.=
.., FECk} maps to the same incoming SR MPLS label "L1"=
=E2=80=9D=
#Ahmed: The sentence is removed as you suggested

2.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In section 2.10.1 the preposition =E2=80=9Cto=E2=80=9D between the words =E2=80=9Caccording=E2=80=9D= and =E2=80=9CMPLS=E2=80=9D is missing in the fragment =E2=80=9CPush the calculated label according the MPLS label pushing rules specified in [RFC3032]=E2=80=9D.

#Ahmed added the missing "to"

3.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Problems with references:

a.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 As reported by Sergey, there are two occurrences of references to RFC 8042 =E2=80=9COSPF Two-Part Metric=E2=80=9D instead of RFC 8402. Lots of thanks to Sergey for catching this

#Ahmed: Corrected, thanks again

b.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Reference to RFC 8174 mistakenly contains a link to=C2=A0 RFC 7274.

#Ahmed: Corrected

Hopefully these notes will be useful.

#Ahmed: VERY useful

Regards,

Sasha

=C2=A0

Office: +972-39266302

Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549= 266302

Email:=C2=A0=C2=A0 Alexander.Va= inshtein@ecitele.com

=C2=A0


___________________________________________________________________________=

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________=
_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring


--

Przemyslaw "PK" Kro= l |=C2=A0Str= ategic Network Engineering |=C2=A0pkrol@google.com=C2=A0
--000000000000585d6d05854803bb-- From nobody Sat Mar 30 15:30:31 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71E21201BE; Sat, 30 Mar 2019 15:30:29 -0700 (PDT) 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_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 N-Qx-iJwmdS6; Sat, 30 Mar 2019 15:30:24 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 9300E1201A3; Sat, 30 Mar 2019 15:30:24 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id t16so778242plo.0; Sat, 30 Mar 2019 15:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=lN5dDrAIUweSX8EpSCePmZH9oLlOwUg9I+jFB1ABbUg=; b=S1oFXJOP8oRu+iudRiFxqC3FaKwmCptl6tPPVEev54nn4hfB86ShmsOVb/2awXzmAK KM0Fmvt7ILz7GyiVGifE2jrqaHOrvT2CXBqVA7ruS0eT8uLU6x49D/15xVCoP1XNwDcb VFwBrCyuVaT2/9l5DKMkV51Rcg2pGP5CxSAkuSPZhygjig4V/yJErZKwlFF1zteluttZ FdEJFmh8meYoqfdlaPYJCw/rOklmJoSS/NL6xARFh5if8kAH5ONu32WQ2JoeZrS4Oqxn raeN3j3LriIC/Lv9U2WGXp+FGjI6fP7AeSUzqveLUX6Z3Exr3B3r984s2uucOKyuNxli G8+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=lN5dDrAIUweSX8EpSCePmZH9oLlOwUg9I+jFB1ABbUg=; b=fve2Jj28F8IG/fjIT6axI7+LRIWSWOu8ejyquQE3i44VgxrpBtqeSPLB5ahn0hXYMI eJd7dz836UCCTKaCkM+TRgBzwfwNmzz0ZwWewFvv0NZLUl0XMT1vupLST83ltuFd8QPa eCaOr1+le98aB782KUk0O+x/irFCHbxKtBTJknshdH2wZ20PN1X458C6AnqmmvMnb4fg aUhh3UZ62VVp3z1G6wH54all/leN2zaSyFJFTx5IrIVNQblk2yoxuUzEyb1U4sEkJaPH 83WpYrjOvStUCJyjH8KkmOcpqsPApTTBdhadVzXsz4kasw61jvm4H9zffshqaff8JgZe ViKA== X-Gm-Message-State: APjAAAX9xT8Tlw+/58G3+LJ0qKxg/N0rxOchAm+F910dogGyCtCCuYAY bsd7URukLzzBR0kTrokELSs= X-Google-Smtp-Source: APXvYqwENcFaW1HwUPv24EKVcoRtwPWA7MfnswBFC1bEnujFcBywxkwkjDFErRti9apNQzzqfym4Wg== X-Received: by 2002:a17:902:a5c9:: with SMTP id t9mr54855173plq.196.1553985024072; Sat, 30 Mar 2019 15:30:24 -0700 (PDT) Received: from Arrcus-Ahmeds-MacBook-Pro.local (adsl-70-234-233-188.dsl.rcsntx.sbcglobal.net. [70.234.233.188]) by smtp.gmail.com with ESMTPSA id a80sm19101979pfj.61.2019.03.30.15.30.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Mar 2019 15:30:23 -0700 (PDT) To: Przemyslaw Krol Cc: Alexander Vainshtein , "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "spring@ietf.org" , "draft-ietf-spring-segment-routing-mpls.authors@ietf.org" , Min Ye , "mpls@ietf.org" References: <65361777-db63-9a7a-9199-dd04425b4785@gmail.com> From: Ahmed Bashandy Message-ID: <2a3e1d27-5f26-36ca-7332-462b89c7c5a6@gmail.com> Date: Sat, 30 Mar 2019 15:30:21 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DFD87B35EB70336E4F03A005" Content-Language: en-US Archived-At: Subject: Re: [mpls] [spring] RTG-DIR Last Call review of draft-ietf-spring-segment-routing-mpls-18 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 22:30:30 -0000 This is a multi-part message in MIME format. --------------DFD87B35EB70336E4F03A005 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit thanks for the comment Mirrored SID  in Section 2.5 refers to RFC8402 section 5.1, which AFAIK is correct. What link needs to be updated? Ahmed On 3/29/19 9:13 PM, Przemyslaw Krol wrote: > Hi Ahmed, > > Cosmetic minor nit: > 2.5. Incoming Label Collision > [...] > both links in the '(Mirrored SID)' section need a cleanup / update > > thanks, > pk > > > On Fri, Mar 29, 2019 at 2:14 AM Ahmed Bashandy > > wrote: > > Thanks a lot for the review > > I uploaded version 19 of the draft, which, IMO, addresses all your > comments > > See the reply "#Ahmed" > > On 3/10/19 9:55 AM, Alexander Vainshtein wrote: >> >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this >> draft. The Routing Directorate seeks to review all routing or >> routing-related drafts as they pass through IETF last call and >> IESG review, and sometimes on special request. The purpose of the >> review is to provide assistance to the Routing ADs. For more >> information about the Routing Directorate, please see >> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >> >> Although these comments are primarily for the use of the Routing >> ADs, it would be helpful if you could consider them along with >> any other IETF Last Call comments that you receive, and strive to >> resolve them through discussion or by updating the draft. >> >> Document: review of draft-ietf-spring-segment-routing-mpls-18 >> Reviewer: Alexander (“Sasha”) Vainshtein >> Review Date: 10-Mar-19 >> IETF LC End Date: 07-Mar-2019 >> Intended Status: Proposed Standard >> >> *Summary:*I have some minor concerns about this document that I >> think should be resolved before publication. >> >> *Comments*: >> >> I have done an early RTG-DIR review of the -14 version of the >> draft half a year ago, and the issues I’ve raised then have been >> resolved in the subsequent versions one way or another). >> Therefore this review has been intentionally focused on the >> changes done to the draft in the few recent versions. >> >> In my previous review I have noticed that the draft was not easy >> reading for me. Since then readability of the draft has been >> improved. However, there are still several places in the new text >> that are still difficult to parse. >> >> I did not run the nits checker on the draft, so my list of nits >> is probably incomplete. >> >> Just as with my earlier review, I send this one also to the MPLS >> WG list – and for the same reasons. >> >> I tried to discuss my review privately with the authors, but they >> did not respond. >> >> *Major Issues*: No major issues found. >> >> *Minor Issues*: >> >> 1.The text in Section 1 states that “*a network operator SHOULD configure at least one node segment >> per routing instance, topology, algorithm*”and continues that “*An implementation MAY check that an IGP node-SID is not >> associated with a prefix that is owned by more than one router >> within the same routing domain, If so, it SHOULD NOT use this >> Node-SID, MAY use another one if available, and SHOULD log an error*”. This looks somewhat controversial to me because: >> a.The check of the Node SID not being owned by more than one >> router in the routing domain is defined as purely optional. >> According to RFC 2119, implementations that choose to implement >> such a check must be able to interoperate with implementations >> that do not implement it >> b.The recommended handling of the results of this check (fully >> aligned with the text in Section 3.2 pf RFC 8402 that prohibits >> using prefixes owned by more than one router in the domain as >> Node-SODs) strongly suggests that the prefix that is owned by >> more than one router in the domain is unusable as the Node SID >> I see two possibilities to resolve this controversy: either make >> the check in question a “real requirement” (i.e., replace *MAY*with *SHOULD*or even *MUST*), or explain why it is safe enough not to implement such a check >> (i.e., how implementations that support this check and >> implementations that do not support it can interoperate within a >> given routing domain).The first of these options seems to me aligned with Section 3.2 >> in RFC 8402 that says that “*An IGP Node-SID MUST NOT be >> associated with a prefix that is owned by more than one router >> within the same routing domain*”. > #Ahmed: I replaced the MAY with SHOULD >> >> 2.I have  a problem with the highlighted part of the following >> text in Section 2.5: >> >> *An implementation MUST NOT allow the MCCs belonging to the same* >> >> *router to assign the same incoming label to more than one SR >> FEC. An* >> >> *implementation that allows such behavior is considered as faulty.*** >> >> *Procedures defined in this document equally applies to this case,* >> >> *both for incoming label collision (Section 2.5 >> ) >> and the effect on* >> >> *outgoing label programming (Section 2.6 >> ).*** >> >> a.The Section in question deals with incoming label collision (in >> fact, the text that immediately follows the problematic fragment >> states that “*The objective of the following steps is to >> deterministically install in the MPLS Incoming Label Map, also >> known as label FIB, a single FEC with the incoming label "L1"*” >> b.As a consequence, any mention of *outgoing label programming*, looks out of context (even accompanied by a forward reference >> to Section 2.6) >> c.Section 2.6 covers the impact of incoming label collision on >> programming of outgoing labels in quite a generic way. Therefore >> I think that the highlighted part of the quoted fragment can be >> safely removed (complete with the grammar mistake). >> d.I also do not see any value in stating that an implementations >> that violates a mandatory requirement of the spec is faulty – >> isn’t that self-evident? > > #Ahmed: I removed the highlighted text because I agree with what > you said in item (d) that it has no value > > >> 3.The highlighted text in Section 2.8 is not accurate: >> *   For Local SIDs, the MCC is responsible for downloading the >> correct* >> *   label value to FIB. For example, an IGP with SR extensions >> [I-D.ietf-* >> *   isis-segment-routing-extensions, I-D.ietf-ospf-segment-routing-* >> *   extensions] allocates and downloads the MPLS label >> corresponding to* >> *   an Adj-SID [RFC8402 ].* >> *a.*IGP with SR extensions**may indeed dynamically allocate and download MPLS labels acting >> as local Adj-SIDs ** >> *b.*However, these labels can be allocated by configuration (e.g. as >> mentioned in the tie-breaking rules in Section 2.5.1 and in the >> example in Section A.2.3 in the draft), in which case IGP with SR >> extensions would only responsible for its advertisement and >> installation. ** > #Ahmed: I removed the highlighted word "allocated" >> *NITS*: >> :** >> 1.In section 2.5: >> a.In the sentence “*Procedures defined in this document equally >> applies to this case*” the noun is in plural but the verb is in singular. (If this >> sentence is removed as suggested above, this nit disappears) >> b.The same problem exists in the sentence “*An incoming label >> collision occurs if the SIDs of the set of FECs {FEC1, FEC2,..., >> FECk} maps to the same incoming SR MPLS label "L1"*” > #Ahmed: The sentence is removed as you suggested >> >> 2.In section 2.10.1 the preposition “*to*” between the words >> “*according*” and “*MPLS*” is missing in the fragment “*Push the >> calculated label according the MPLS label pushing rules specified >> in [RFC3032]*”. >> > #Ahmed added the missing "to" >> >> 3.Problems with references: >> >> a.As reported by Sergey >> , >> there are two occurrences of references to RFC 8042 “OSPF >> Two-Part Metric” instead of RFC 8402. Lots of thanks to Sergey >> for catching this >> > #Ahmed: Corrected, thanks again >> >> b.Reference to RFC 8174 mistakenly contains a link to  RFC 7274. >> > #Ahmed: Corrected >> >> Hopefully these notes will be useful. >> > #Ahmed: VERY useful >> >> Regards, >> >> Sasha >> >> Office: +972-39266302 >> >> Cell:      +972-549266302 >> >> Email: Alexander.Vainshtein@ecitele.com >> >> >> >> ___________________________________________________________________________ >> >> This e-mail message is intended for the recipient only and >> contains information which is >> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you >> have received this >> transmission in error, please inform us by e-mail, phone or fax, >> and then delete the original >> and all copies thereof. >> ___________________________________________________________________________ > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > > -- > Przemyslaw "PK" Krol |  Strategic Network Engineer ing > |pkrol@google.com > --------------DFD87B35EB70336E4F03A005 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+CiAgPGhlYWQ+CiAgICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+CiAgPC9oZWFkPgogIDxib2R5IHRl eHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiPgogICAgPHA+dGhhbmtzIGZvciB0aGUg Y29tbWVudDwvcD4KICAgIDxwPk1pcnJvcmVkIFNJRMKgIGluIFNlY3Rpb24gMi41IHJlZmVy cyB0byBSRkM4NDAyIHNlY3Rpb24gNS4xLCB3aGljaAogICAgICBBRkFJSyBpcyBjb3JyZWN0 LiBXaGF0IGxpbmsgbmVlZHMgdG8gYmUgdXBkYXRlZD8gPGJyPgogICAgPC9wPgogICAgPHA+ QWhtZWQ8L3A+CiAgICA8cD48YnI+CiAgICA8L3A+CiAgICA8ZGl2IGNsYXNzPSJtb3otY2l0 ZS1wcmVmaXgiPk9uIDMvMjkvMTkgOToxMyBQTSwgUHJ6ZW15c2xhdyBLcm9sCiAgICAgIHdy b3RlOjxicj4KICAgIDwvZGl2PgogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIKY2l0ZT0i bWlkOkNBQ0gyRWtVMDFYc0xQVDFvdzE1cSt5NkdMemdmZUtpRmtOUFdnN2pXWCtGRjBPUFpu d0BtYWlsLmdtYWlsLmNvbSI+CiAgICAgIDxtZXRhIGh0dHAtZXF1aXY9ImNvbnRlbnQtdHlw ZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVVURi04Ij4KICAgICAgPGRpdiBkaXI9 Imx0ciI+CiAgICAgICAgPGRpdiBkaXI9Imx0ciI+CiAgICAgICAgICA8ZGl2IGRpcj0ibHRy Ij5IaSBBaG1lZCwKICAgICAgICAgICAgPGRpdj48YnI+CiAgICAgICAgICAgIDwvZGl2Pgog ICAgICAgICAgICA8ZGl2PkNvc21ldGljIG1pbm9yIG5pdDo8L2Rpdj4KICAgICAgICAgICAg PGRpdj48Zm9udCBmYWNlPSJtb25vc3BhY2UsIG1vbm9zcGFjZSI+Mi41LiBJbmNvbWluZyBM YWJlbAogICAgICAgICAgICAgICAgQ29sbGlzaW9uPGJyPgogICAgICAgICAgICAgIDwvZm9u dD48L2Rpdj4KICAgICAgICAgICAgPGRpdj48Zm9udCBmYWNlPSJtb25vc3BhY2UsIG1vbm9z cGFjZSI+Wy4uLl08L2ZvbnQ+PC9kaXY+CiAgICAgICAgICAgIDxkaXY+Ym90aCBsaW5rcyBp biB0aGUgJyhNaXJyb3JlZCBTSUQpJyBzZWN0aW9uIG5lZWQgYQogICAgICAgICAgICAgIGNs ZWFudXAgLyB1cGRhdGU8L2Rpdj4KICAgICAgICAgICAgPGRpdj48YnI+CiAgICAgICAgICAg IDwvZGl2PgogICAgICAgICAgICA8ZGl2PnRoYW5rcyw8L2Rpdj4KICAgICAgICAgICAgPGRp dj5wazwvZGl2PgogICAgICAgICAgICA8ZGl2Pjxicj4KICAgICAgICAgICAgPC9kaXY+CiAg ICAgICAgICA8L2Rpdj4KICAgICAgICA8L2Rpdj4KICAgICAgPC9kaXY+CiAgICAgIDxicj4K ICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPgogICAgICAgIDxkaXYgZGlyPSJsdHIi IGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBGcmksIE1hciAyOSwgMjAxOSBhdCAyOjE0CiAgICAg ICAgICBBTSBBaG1lZCBCYXNoYW5keSAmbHQ7PGEKICAgICAgICAgICAgaHJlZj0ibWFpbHRv OmFiYXNoYW5keS5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiCiAgICAgICAgICAg IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+YWJhc2hhbmR5LmlldGZAZ21haWwuY29tPC9hPiZn dDsKICAgICAgICAgIHdyb3RlOjxicj4KICAgICAgICA8L2Rpdj4KICAgICAgICA8YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHgKICAg ICAgICAgIDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3Bh ZGRpbmctbGVmdDoxZXgiPgogICAgICAgICAgPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIj4KICAg ICAgICAgICAgPHA+VGhhbmtzIGEgbG90IGZvciB0aGUgcmV2aWV3PC9wPgogICAgICAgICAg ICA8cD5JIHVwbG9hZGVkIHZlcnNpb24gMTkgb2YgdGhlIGRyYWZ0LCB3aGljaCwgSU1PLCBh ZGRyZXNzZXMKICAgICAgICAgICAgICBhbGwgeW91ciBjb21tZW50czwvcD4KICAgICAgICAg ICAgPHA+U2VlIHRoZSByZXBseSAiI0FobWVkIjxicj4KICAgICAgICAgICAgPC9wPgogICAg ICAgICAgICA8ZGl2CmNsYXNzPSJnbWFpbC1tXy01NjQyNTE0MjcyMDg5ODUwMTI3Z21haWwt bV8tMjMwMzMwMjQyMDA2MTIzOTEyNW1vei1jaXRlLXByZWZpeCI+T24KICAgICAgICAgICAg ICAzLzEwLzE5IDk6NTUgQU0sIEFsZXhhbmRlciBWYWluc2h0ZWluIHdyb3RlOjxicj4KICAg ICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPgog ICAgICAgICAgICAgIDxkaXYKY2xhc3M9ImdtYWlsLW1fLTU2NDI1MTQyNzIwODk4NTAxMjdn bWFpbC1tXy0yMzAzMzAyNDIwMDYxMjM5MTI1V29yZFNlY3Rpb24xIj4KICAgICAgICAgICAg ICAgIDxwPjxzcGFuCiAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMHB0 O2ZvbnQtZmFtaWx5OlZlcmRhbmEsc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SGVsbG8sCiAg ICAgICAgICAgICAgICAgIDwvc3Bhbj48L3A+CiAgICAgICAgICAgICAgICA8cD48c3Bhbgog ICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTBwdDtmb250LWZhbWlseTpW ZXJkYW5hLHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkkKICAgICAgICAgICAgICAgICAgICBo YXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUKICAgICAgICAg ICAgICAgICAgICByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0 b3JhdGUKICAgICAgICAgICAgICAgICAgICBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcg b3Igcm91dGluZy1yZWxhdGVkCiAgICAgICAgICAgICAgICAgICAgZHJhZnRzIGFzIHRoZXkg cGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHCiAgICAgICAgICAgICAgICAg ICAgcmV2aWV3LCBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4gVGhlCiAgICAg ICAgICAgICAgICAgICAgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNz aXN0YW5jZSB0bwogICAgICAgICAgICAgICAgICAgIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1v cmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlCiAgICAgICAgICAgICAgICAgICAgUm91dGluZyBE aXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSA8YQogICAgICAgICAgICAgICAgICAgICAgaHJlZj0i aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpciIK ICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9 InRydWUiPjxzcGFuCiAgICAgICAgICAgICAgICAgICAgICAgIGNsYXNzPSJnbWFpbC1tXy01 NjQyNTE0MjcyMDg5ODUwMTI3Z21haWwtbV8tMjMwMzMwMjQyMDA2MTIzOTEyNWljb24iPjxz cGFuCnN0eWxlPSJmb250LWZhbWlseTpBcmlhbCxzYW5zLXNlcmlmO2NvbG9yOnJnYigxODcs MCwwKTt0ZXh0LWRlY29yYXRpb246bm9uZSI+4oCLPC9zcGFuPjwvc3Bhbj5odHRwOi8vdHJh Yy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyPC9hPgogICAgICAg ICAgICAgICAgICA8L3NwYW4+PC9wPgogICAgICAgICAgICAgICAgPHA+PHNwYW4KICAgICAg ICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Zm9udC1mYW1pbHk6VmVyZGFu YSxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5BbHRob3VnaAogICAgICAgICAgICAgICAgICAg IHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlCiAgICAg ICAgICAgICAgICAgICAgUm91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91 IGNvdWxkCiAgICAgICAgICAgICAgICAgICAgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFu eSBvdGhlciBJRVRGIExhc3QgQ2FsbAogICAgICAgICAgICAgICAgICAgIGNvbW1lbnRzIHRo YXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZQogICAgICAgICAgICAgICAg ICAgIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFmdC4g PC9zcGFuPjwvcD4KICAgICAgICAgICAgICAgIDxwPjxzcGFuCiAgICAgICAgICAgICAgICAg ICAgc3R5bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5OlZlcmRhbmEsc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+RG9jdW1lbnQ6CiAgICAgICAgICAgICAgICAgIDwvc3Bhbj48c3Bh bgogICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMt c2VyaWY7Y29sb3I6cmdiKDMxLDczLDEyNSkiPnJldmlldwogICAgICAgICAgICAgICAgICAg IG9mIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLTE4PC9zcGFuPjxz cGFuCnN0eWxlPSJmb250LXNpemU6MTBwdDtmb250LWZhbWlseTpWZXJkYW5hLHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxicj4KICAgICAgICAgICAgICAgICAgICBSZXZpZXdlcjogQWxl eGFuZGVyICjigJxTYXNoYeKAnSkgVmFpbnNodGVpbjxicj4KICAgICAgICAgICAgICAgICAg ICBSZXZpZXcgRGF0ZTogMTAtTWFyLTE5PGJyPgogICAgICAgICAgICAgICAgICAgIElFVEYg TEMgRW5kIERhdGU6IDA3LU1hci0yMDE5PGJyPgogICAgICAgICAgICAgICAgICAgIEludGVu ZGVkIFN0YXR1czogPC9zcGFuPjxzcGFuCiAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZv bnQtc2l6ZToxMS41cHQ7Y29sb3I6cmdiKDM0LDM0LDM0KTtiYWNrZ3JvdW5kOndoaXRlIj5Q cm9wb3NlZAogICAgICAgICAgICAgICAgICAgIFN0YW5kYXJkPC9zcGFuPjxzcGFuCiAgICAg ICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5OlZlcmRh bmEsc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4KICAgICAgICAgICAgICAg IDxwPjxzdHJvbmc+PHNwYW4KICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNp emU6MTBwdDtmb250LWZhbWlseTpWZXJkYW5hLHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlN1 bW1hcnk6PC9zcGFuPjwvc3Ryb25nPjxzcGFuCnN0eWxlPSJmb250LXNpemU6MTBwdDtmb250 LWZhbWlseTpWZXJkYW5hLHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiBJCiAgICAgICAgICAg ICAgICAgICAgaGF2ZSBzb21lIG1pbm9yIGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1lbnQg dGhhdCBJCiAgICAgICAgICAgICAgICAgICAgdGhpbmsgc2hvdWxkIGJlIHJlc29sdmVkIGJl Zm9yZSBwdWJsaWNhdGlvbi48L3NwYW4+PC9wPgogICAgICAgICAgICAgICAgPHA+PGI+PHNw YW4KICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTBwdDtmb250LWZh bWlseTpWZXJkYW5hLHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkNvbW1lbnRzPC9zcGFuPjwv Yj48c3BhbgpzdHlsZT0iZm9udC1zaXplOjEwcHQ7Zm9udC1mYW1pbHk6VmVyZGFuYSxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj46IDwvc3Bhbj48L3A+CiAgICAgICAgICAgICAgICA8cD48 c3BhbgogICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTBwdDtmb250LWZh bWlseTpWZXJkYW5hLHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkkKICAgICAgICAgICAgICAg ICAgICBoYXZlIGRvbmUgYW4gZWFybHkgUlRHLURJUiByZXZpZXcgb2YgdGhlIC0xNCB2ZXJz aW9uCiAgICAgICAgICAgICAgICAgICAgb2YgdGhlIGRyYWZ0IGhhbGYgYSB5ZWFyIGFnbywg YW5kIHRoZSBpc3N1ZXMgSeKAmXZlCiAgICAgICAgICAgICAgICAgICAgcmFpc2VkIHRoZW4g aGF2ZSBiZWVuIHJlc29sdmVkIGluIHRoZSBzdWJzZXF1ZW50CiAgICAgICAgICAgICAgICAg ICAgdmVyc2lvbnMgb25lIHdheSBvciBhbm90aGVyKS4gVGhlcmVmb3JlIHRoaXMgcmV2aWV3 CiAgICAgICAgICAgICAgICAgICAgaGFzIGJlZW4gaW50ZW50aW9uYWxseSBmb2N1c2VkIG9u IHRoZSBjaGFuZ2VzIGRvbmUKICAgICAgICAgICAgICAgICAgICB0byB0aGUgZHJhZnQgaW4g dGhlIGZldyByZWNlbnQgdmVyc2lvbnMuIDwvc3Bhbj48L3A+CiAgICAgICAgICAgICAgICA8 cD48c3BhbgogICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTBwdDtmb250 LWZhbWlseTpWZXJkYW5hLHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkluCiAgICAgICAgICAg ICAgICAgICAgbXkgcHJldmlvdXMgcmV2aWV3IEkgaGF2ZSBub3RpY2VkIHRoYXQgdGhlIGRy YWZ0IHdhcwogICAgICAgICAgICAgICAgICAgIG5vdCBlYXN5IHJlYWRpbmcgZm9yIG1lLiBT aW5jZSB0aGVuIHJlYWRhYmlsaXR5IG9mCiAgICAgICAgICAgICAgICAgICAgdGhlIGRyYWZ0 IGhhcyBiZWVuIGltcHJvdmVkLiBIb3dldmVyLCB0aGVyZSBhcmUKICAgICAgICAgICAgICAg ICAgICBzdGlsbCBzZXZlcmFsIHBsYWNlcyBpbiB0aGUgbmV3IHRleHQgdGhhdCBhcmUgc3Rp bGwKICAgICAgICAgICAgICAgICAgICBkaWZmaWN1bHQgdG8gcGFyc2UuIDwvc3Bhbj48L3A+ CiAgICAgICAgICAgICAgICA8cD48c3BhbgogICAgICAgICAgICAgICAgICAgIHN0eWxlPSJm b250LXNpemU6MTBwdDtmb250LWZhbWlseTpWZXJkYW5hLHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPkkKICAgICAgICAgICAgICAgICAgICBkaWQgbm90IHJ1biB0aGUgbml0cyBjaGVja2Vy IG9uIHRoZSBkcmFmdCwgc28gbXkKICAgICAgICAgICAgICAgICAgICBsaXN0IG9mIG5pdHMg aXMgcHJvYmFibHkgaW5jb21wbGV0ZS48L3NwYW4+PC9wPgogICAgICAgICAgICAgICAgPHA+ PHNwYW4KICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Zm9udC1m YW1pbHk6VmVyZGFuYSxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5KdXN0CiAgICAgICAgICAg ICAgICAgICAgYXMgd2l0aCBteSBlYXJsaWVyIHJldmlldywgSSBzZW5kIHRoaXMgb25lIGFs c28gdG8KICAgICAgICAgICAgICAgICAgICB0aGUgTVBMUyBXRyBsaXN0IOKAkyBhbmQgZm9y IHRoZSBzYW1lIHJlYXNvbnMuPC9zcGFuPjwvcD4KICAgICAgICAgICAgICAgIDxwPjxzcGFu CiAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5 OlZlcmRhbmEsc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SQogICAgICAgICAgICAgICAgICAg IHRyaWVkIHRvIGRpc2N1c3MgbXkgcmV2aWV3IHByaXZhdGVseSB3aXRoIHRoZQogICAgICAg ICAgICAgICAgICAgIGF1dGhvcnMsIGJ1dCB0aGV5IGRpZCBub3QgcmVzcG9uZC48L3NwYW4+ PC9wPgogICAgICAgICAgICAgICAgPHA+PGI+PHNwYW4KICAgICAgICAgICAgICAgICAgICAg IHN0eWxlPSJmb250LXNpemU6MTBwdDtmb250LWZhbWlseTpWZXJkYW5hLHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPk1ham9yCiAgICAgICAgICAgICAgICAgICAgICBJc3N1ZXM8L3NwYW4+ PC9iPjxzcGFuCiAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMHB0O2Zv bnQtZmFtaWx5OlZlcmRhbmEsc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+OgogICAgICAgICAg ICAgICAgICAgIE5vIG1ham9yIGlzc3VlcyBmb3VuZC48L3NwYW4+PC9wPgogICAgICAgICAg ICAgICAgPHA+PGI+PHNwYW4KICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNp emU6MTBwdDtmb250LWZhbWlseTpWZXJkYW5hLHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk1p bm9yCiAgICAgICAgICAgICAgICAgICAgICBJc3N1ZXM8L3NwYW4+PC9iPjxzcGFuCiAgICAg ICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5OlZlcmRh bmEsc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+OgogICAgICAgICAgICAgICAgICA8L3NwYW4+ PC9wPgogICAgICAgICAgICAgICAgPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzkuNzVwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmEsc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+PHNwYW4+MS48c3BhbiBzdHlsZT0iZm9udDo3cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij7CoMKgwqAgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gZGlyPSJMVFIiPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYSxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5UaGUgdGV4dCBpbiBTZWN0aW9uIDEgc3RhdGVzIHRoYXQ8L3NwYW4+IOKAnDxi PmEgbmV0d29yayBvcGVyYXRvciBTSE9VTEQgY29uZmlndXJlIGF0IGxlYXN0IG9uZSBub2Rl IHNlZ21lbnQgcGVyIHJvdXRpbmcgaW5zdGFuY2UsIHRvcG9sb2d5LCBhbGdvcml0aG08L2I+ 4oCdIDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpWZXJkYW5hLHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPmFuZCBjb250aW51ZXMgdGhhdDwvc3Bhbj4g4oCcPGI+QW4gaW1wbGVtZW50YXRp b24gTUFZIGNoZWNrIHRoYXQgYW4gSUdQIG5vZGUtU0lEIGlzIG5vdCBhc3NvY2lhdGVkIHdp dGggYSBwcmVmaXggdGhhdCBpcyBvd25lZCBieSBtb3JlIHRoYW4gb25lIHJvdXRlciB3aXRo aW4gdGhlIHNhbWUgcm91dGluZyBkb21haW4sIElmIHNvLCBpdCBTSE9VTEQgTk9UIHVzZSB0 aGlzIE5vZGUtU0lELCBNQVkgdXNlIGFub3RoZXIgb25lIGlmIGF2YWlsYWJsZSwgYW5kIFNI T1VMRCBsb2cgYW4gZXJyb3I8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmEs c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+4oCdLiBUaGlzIGxvb2tzIHNvbWV3aGF0IGNvbnRy b3ZlcnNpYWwgdG8gbWUgYmVjYXVzZTo8L3NwYW4+PC9wcmU+CiAgICAgICAgICAgICAgICA8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3NS43NXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6VmVyZGFuYSxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48c3Bhbj5hLjxzcGFuIHN0eWxl PSJmb250OjdwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPsKgwqDCoCA8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpWZXJkYW5hLHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoZSBjaGVjayBvZiB0 aGUgTm9kZSBTSUQgbm90IGJlaW5nIG93bmVkIGJ5IG1vcmUgdGhhbiBvbmUgcm91dGVyIGlu IHRoZSByb3V0aW5nIGRvbWFpbiBpcyBkZWZpbmVkIGFzIHB1cmVseSBvcHRpb25hbC4gQWNj b3JkaW5nIHRvIFJGQyAyMTE5LCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBjaG9vc2UgdG8gaW1w bGVtZW50IHN1Y2ggYSBjaGVjayBtdXN0IGJlIGFibGUgdG8gaW50ZXJvcGVyYXRlIHdpdGgg aW1wbGVtZW50YXRpb25zIHRoYXQgZG8gbm90IGltcGxlbWVudCBpdCA8L3NwYW4+PC9wcmU+ CiAgICAgICAgICAgICAgICA8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3NS43NXB0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYSxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48 c3Bhbj5iLjxzcGFuIHN0eWxlPSJmb250OjdwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPsKgwqDCoCA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3BhbiBkaXI9IkxUUiI+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpWZXJkYW5hLHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPlRoZSByZWNvbW1lbmRlZCBoYW5kbGluZyBvZiB0aGUgcmVzdWx0cyBvZiB0aGlzIGNo ZWNrIChmdWxseSBhbGlnbmVkIHdpdGggdGhlIHRleHQgaW4gU2VjdGlvbiAzLjIgcGYgUkZD IDg0MDIgdGhhdCBwcm9oaWJpdHMgdXNpbmcgcHJlZml4ZXMgb3duZWQgYnkgbW9yZSB0aGFu IG9uZSByb3V0ZXIgaW4gdGhlIGRvbWFpbiBhcyBOb2RlLVNPRHMpIHN0cm9uZ2x5IHN1Z2dl c3RzIHRoYXQgdGhlIHByZWZpeCB0aGF0IGlzIG93bmVkIGJ5IG1vcmUgdGhhbiBvbmUgcm91 dGVyIGluIHRoZSBkb21haW4gaXMgdW51c2FibGUgYXMgdGhlIE5vZGUgU0lEIMKgPC9zcGFu PjwvcHJlPgogICAgICAgICAgICAgICAgPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzkuNzVw dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmEsc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+SSBzZWUgdHdvIHBvc3NpYmlsaXRpZXMgdG8gcmVzb2x2ZSB0aGlzIGNvbnRyb3Zl cnN5OiBlaXRoZXIgbWFrZSB0aGUgY2hlY2sgaW4gcXVlc3Rpb24gYSDigJxyZWFsIHJlcXVp cmVtZW504oCdIChpLmUuLCByZXBsYWNlIDwvc3Bhbj48Yj5NQVk8L2I+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OlZlcmRhbmEsc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+IHdpdGggPC9z cGFuPjxiPlNIT1VMRDwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYSxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4gb3IgZXZlbiA8L3NwYW4+PGI+TVVTVDwvYj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYSxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4pLCBv ciBleHBsYWluIHdoeSBpdCBpcyBzYWZlIGVub3VnaCBub3QgdG8gaW1wbGVtZW50IHN1Y2gg YSBjaGVjayAoaS5lLiwgaG93IGltcGxlbWVudGF0aW9ucyB0aGF0IHN1cHBvcnQgdGhpcyBj aGVjayBhbmQgaW1wbGVtZW50YXRpb25zIHRoYXQgZG8gbm90IHN1cHBvcnQgaXQgY2FuIGlu dGVyb3BlcmF0ZSB3aXRoaW4gYSBnaXZlbiByb3V0aW5nIGRvbWFpbik8L3NwYW4+LiA8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYSxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5U aGUgZmlyc3Qgb2YgdGhlc2Ugb3B0aW9ucyBzZWVtcyB0byBtZSBhbGlnbmVkIHdpdGggU2Vj dGlvbiAzLjIgaW4gUkZDIDg0MDIgdGhhdCBzYXlzIHRoYXQg4oCcPC9zcGFuPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTFwdCI+QW4gSUdQIE5vZGUtU0lEIE1VU1QgTk9UIGJlIGFz c29jaWF0ZWQgd2l0aCBhIHByZWZpeCB0aGF0IGlzIG93bmVkIGJ5IG1vcmUgdGhhbiBvbmUg cm91dGVyIHdpdGhpbiB0aGUgc2FtZSByb3V0aW5nIGRvbWFpbjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmEsc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+4oCd LiA8L3NwYW4+wqDCoMKgPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmEsc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+PC9zcGFuPjwvcHJlPgogICAgICAgICAgICAgIDwvZGl2Pgog ICAgICAgICAgICA8L2Jsb2NrcXVvdGU+CiAgICAgICAgICAgICNBaG1lZDogSSByZXBsYWNl ZCB0aGUgTUFZIHdpdGggU0hPVUxEPGJyPgogICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj4KICAgICAgICAgICAgICA8ZGl2CmNsYXNzPSJnbWFpbC1tXy01NjQyNTE0Mjcy MDg5ODUwMTI3Z21haWwtbV8tMjMwMzMwMjQyMDA2MTIzOTEyNVdvcmRTZWN0aW9uMSI+CiAg ICAgICAgICAgICAgICA8cApjbGFzcz0iZ21haWwtbV8tNTY0MjUxNDI3MjA4OTg1MDEyN2dt YWlsLW1fLTIzMDMzMDI0MjAwNjEyMzkxMjVNc29MaXN0UGFyYWdyYXBoIgogICAgICAgICAg ICAgICAgICBzdHlsZT0ibWFyZ2luLWxlZnQ6MzkuNzVwdCI+IDxzcGFuPjIuPHNwYW4KICAg ICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250OjdwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPsKgwqDCoMKgwqDCoAogICAgICAgICAgICAgICAgICAgIDwvc3Bhbj48L3Nw YW4+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj5JIGhhdmXCoCBhCiAgICAgICAgICAgICAgICAg IHByb2JsZW0gd2l0aCB0aGUgPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93Ij4KICAg ICAgICAgICAgICAgICAgICBoaWdobGlnaHRlZDwvc3Bhbj4gcGFydCBvZiB0aGUgZm9sbG93 aW5nIHRleHQgaW4KICAgICAgICAgICAgICAgICAgU2VjdGlvbiAyLjU6PC9wPgogICAgICAg ICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4cHQi PjxzcGFuPsKgwqAgPC9zcGFuPjxiPjxzcGFuCiAgICAgICAgICAgICAgICAgICAgICBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkFuCiAgICAgICAgICAg ICAgICAgICAgICBpbXBsZW1lbnRhdGlvbiBNVVNUIE5PVCBhbGxvdyB0aGUgTUNDcyBiZWxv bmdpbmcKICAgICAgICAgICAgICAgICAgICAgIHRvIHRoZSBzYW1lPC9zcGFuPjwvYj48L3A+ CiAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MThwdCI+PGI+PHNwYW4KICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+wqDCoAogICAgICAgICAgICAgICAgICAg ICAgcm91dGVyIHRvIGFzc2lnbiB0aGUgc2FtZSBpbmNvbWluZyBsYWJlbCB0byBtb3JlCiAg ICAgICAgICAgICAgICAgICAgICB0aGFuIG9uZSBTUiBGRUMuIDxzcGFuIHN0eWxlPSJiYWNr Z3JvdW5kOnllbGxvdyI+QW48L3NwYW4+PC9zcGFuPjwvYj48L3A+CiAgICAgICAgICAgICAg ICA8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MThwdCI+PGI+PHNw YW4+wqDCoAogICAgICAgICAgICAgICAgICAgICAgaW1wbGVtZW50YXRpb24gdGhhdCBhbGxv d3Mgc3VjaCBiZWhhdmlvciBpcwogICAgICAgICAgICAgICAgICAgICAgY29uc2lkZXJlZCBh cyBmYXVsdHkuPC9zcGFuPjwvYj48Yj48c3BhbgogICAgICAgICAgICAgICAgICAgICAgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48L3NwYW4+PC9iPjwv cD4KICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDoxOHB0Ij48Yj48c3BhbgogICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7CoMKgIDxzcGFuCiAgICAgICAgICAg ICAgICAgICAgICAgIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdyI+UHJvY2VkdXJlcyBkZWZp bmVkIGluCiAgICAgICAgICAgICAgICAgICAgICAgIHRoaXMgZG9jdW1lbnQgZXF1YWxseSBh cHBsaWVzIHRvIHRoaXMgY2FzZSw8L3NwYW4+PC9zcGFuPjwvYj48L3A+CiAgICAgICAgICAg ICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MThwdCI+PGI+ PHNwYW4+wqDCoAogICAgICAgICAgICAgICAgICAgICAgYm90aCBmb3IgaW5jb21pbmcgbGFi ZWwgY29sbGlzaW9uICg8YQpocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMtMTgjc2VjdGlvbi0yLjUiCiAg ICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9 InRydWUiPjxzcGFuCiAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImNvbG9yOndp bmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPlNlY3Rpb24KICAgICAgICAgICAgICAg ICAgICAgICAgICAyLjU8L3NwYW4+PC9hPikgYW5kIHRoZSBlZmZlY3Qgb248L3NwYW4+PC9i PjwvcD4KICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDoxOHB0Ij48Yj48c3Bhbj7CoMKgCiAgICAgICAgICAgICAgICAgICAgICBvdXRn b2luZyBsYWJlbCBwcm9ncmFtbWluZyAoPGEKaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLTE4I3NlY3Rp b24tMi42IgogICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayIgbW96LWRv LW5vdC1zZW5kPSJ0cnVlIj48c3BhbgogICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5TZWN0aW9uCiAgICAg ICAgICAgICAgICAgICAgICAgICAgMi42PC9zcGFuPjwvYT4pLjwvc3Bhbj48L2I+PGI+PHNw YW4KICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+PC9zcGFuPjwvYj48L3A+CiAgICAgICAgICAgICAgICA8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDo3NS43NXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6VmVy ZGFuYSxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48c3Bhbj5hLjxzcGFuIHN0eWxlPSJmb250 OjdwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPsKgwqDCoCA8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpWZXJkYW5hLHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoZSBTZWN0aW9uIGluIHF1ZXN0 aW9uIGRlYWxzIHdpdGggaW5jb21pbmcgbGFiZWwgY29sbGlzaW9uIChpbiBmYWN0LCB0aGUg dGV4dCB0aGF0IGltbWVkaWF0ZWx5IGZvbGxvd3MgdGhlIHByb2JsZW1hdGljIGZyYWdtZW50 IHN0YXRlcyB0aGF0IOKAnDwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQi PlRoZSBvYmplY3RpdmUgb2YgdGhlIGZvbGxvd2luZyBzdGVwcyBpcyB0byBkZXRlcm1pbmlz dGljYWxseSBpbnN0YWxsIGluIHRoZSBNUExTIEluY29taW5nIExhYmVsIE1hcCwgYWxzbyBr bm93biBhcyBsYWJlbCBGSUIsIGEgc2luZ2xlIEZFQyB3aXRoIHRoZSBpbmNvbWluZyBsYWJl bCAiTDEiPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYSxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj7igJ0gPC9zcGFuPjwvcHJlPgogICAgICAgICAgICAgICAg PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzUuNzVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OlZlcmRhbmEsc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PHNwYW4+Yi48c3BhbiBzdHls ZT0iZm9udDo3cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij7CoMKgwqAgPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6VmVyZGFuYSxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5BcyBhIGNvbnNlcXVl bmNlLCBhbnkgbWVudGlvbiBvZsKgIDwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExcHQiPm91dGdvaW5nIGxhYmVsIHByb2dyYW1taW5nPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6VmVyZGFuYSxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4sIGxvb2tz IG91dCBvZiBjb250ZXh0IChldmVuIGFjY29tcGFuaWVkIGJ5IGEgZm9yd2FyZCByZWZlcmVu Y2UgdG8gU2VjdGlvbiAyLjYpPC9zcGFuPjwvcHJlPgogICAgICAgICAgICAgICAgPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6NzUuNzVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlZl cmRhbmEsc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PHNwYW4+Yy48c3BhbiBzdHlsZT0iZm9u dDo3cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij7CoMKgwqAgPC9zcGFuPjwvc3Bh bj48L3NwYW4+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6VmVyZGFuYSxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5TZWN0aW9uIDIuNiBjb3ZlcnMg dGhlIGltcGFjdCBvZiBpbmNvbWluZyBsYWJlbCBjb2xsaXNpb24gb24gcHJvZ3JhbW1pbmcg b2Ygb3V0Z29pbmcgbGFiZWxzIGluIHF1aXRlIGEgZ2VuZXJpYyB3YXkuIFRoZXJlZm9yZSBJ IHRoaW5rIHRoYXQgdGhlIMKgPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93Ij5oaWdo bGlnaHRlZDwvc3Bhbj4gcGFydCBvZiB0aGUgcXVvdGVkIGZyYWdtZW50IGNhbiBiZSBzYWZl bHkgcmVtb3ZlZCAoY29tcGxldGUgd2l0aCB0aGUgZ3JhbW1hciBtaXN0YWtlKS48L3NwYW4+ PC9wcmU+CiAgICAgICAgICAgICAgICA8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3NS43NXB0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYSxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj48c3Bhbj5kLjxzcGFuIHN0eWxlPSJmb250OjdwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPsKgwqDCoCA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3BhbiBkaXI9IkxUUiI+ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpWZXJkYW5hLHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPkkgYWxzbyBkbyBub3Qgc2VlIGFueSB2YWx1ZSBpbiBzdGF0aW5nIHRoYXQg YW4gaW1wbGVtZW50YXRpb25zIHRoYXQgdmlvbGF0ZXMgYSBtYW5kYXRvcnkgcmVxdWlyZW1l bnQgb2YgdGhlIHNwZWMgaXMgZmF1bHR5IOKAkyBpc27igJl0IHRoYXQgc2VsZi1ldmlkZW50 Pzwvc3Bhbj48L3ByZT4KICAgICAgICAgICAgICA8L2Rpdj4KICAgICAgICAgICAgPC9ibG9j a3F1b3RlPgogICAgICAgICAgICA8cD4jQWhtZWQ6IEkgcmVtb3ZlZCB0aGUgaGlnaGxpZ2h0 ZWQgdGV4dCBiZWNhdXNlIEkgYWdyZWUKICAgICAgICAgICAgICB3aXRoIHdoYXQgeW91IHNh aWQgaW4gaXRlbSAoZCkgdGhhdCBpdCBoYXMgbm8gdmFsdWU8L3A+CiAgICAgICAgICAgIDxw Pjxicj4KICAgICAgICAgICAgPC9wPgogICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj4KICAgICAgICAgICAgICA8ZGl2CmNsYXNzPSJnbWFpbC1tXy01NjQyNTE0MjcyMDg5 ODUwMTI3Z21haWwtbV8tMjMwMzMwMjQyMDA2MTIzOTEyNVdvcmRTZWN0aW9uMSI+CiAgICAg ICAgICAgICAgICA8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3NS43NXB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6VmVyZGFuYSxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48L3NwYW4+ PC9wcmU+CiAgICAgICAgICAgICAgICA8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozOS43NXB0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYSxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj48c3Bhbj4zLjxzcGFuIHN0eWxlPSJmb250OjdwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPsKgwqDCoCA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3BhbiBkaXI9IkxUUiI+ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpWZXJkYW5hLHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPlRoZSA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3ciPmhpZ2hsaWdo dGVkPC9zcGFuPiB0ZXh0IGluIFNlY3Rpb24gMi44IGlzIG5vdCBhY2N1cmF0ZTo8L3NwYW4+ PC9wcmU+CiAgICAgICAgICAgICAgICA8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoyMS43NXB0 Ij48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPsKgwqAgRm9yIExvY2FsIFNJRHMsIHRo ZSBNQ0MgaXMgcmVzcG9uc2libGUgZm9yIGRvd25sb2FkaW5nIHRoZSBjb3JyZWN0PC9zcGFu PjwvYj48L3ByZT4KICAgICAgICAgICAgICAgIDxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjIx Ljc1cHQiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+wqDCoCBsYWJlbCB2YWx1ZSB0 byBGSUIuIEZvciBleGFtcGxlLCBhbiBJR1Agd2l0aCBTUiBleHRlbnNpb25zIFtJLUQuaWV0 Zi08L3NwYW4+PC9iPjwvcHJlPgogICAgICAgICAgICAgICAgPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MjEuNzVwdCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj7CoMKgIGlzaXMt c2VnbWVudC1yb3V0aW5nLWV4dGVuc2lvbnMsIEktRC5pZXRmLW9zcGYtc2VnbWVudC1yb3V0 aW5nLTwvc3Bhbj48L2I+PC9wcmU+CiAgICAgICAgICAgICAgICA8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDoyMS43NXB0Ij48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPsKgwqAgZXh0 ZW5zaW9uc10gPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93Ij5hbGxvY2F0ZXM8L3Nw YW4+IGFuZCBkb3dubG9hZHMgdGhlIE1QTFMgbGFiZWwgY29ycmVzcG9uZGluZyB0bzwvc3Bh bj48L2I+PC9wcmU+CiAgICAgICAgICAgICAgICA8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoy MS43NXB0Ij48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPsKgwqAgYW4gQWRqLVNJRCBb PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg0MDIiIHRpdGxlPSIm cXVvdDtTZWdtZW50IFJvdXRpbmcgQXJjaGl0ZWN0dXJlJnF1b3Q7IiB0YXJnZXQ9Il9ibGFu ayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5SRkM4NDAyPC9hPl0uPC9zcGFuPjwvYj48L3By ZT4KICAgICAgICAgICAgICAgIDxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Ojc1Ljc1cHQiPjxi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4+YS48c3BhbiBzdHlsZT0iZm9udDo3 cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij7CoCA8L3NwYW4+PC9zcGFuPjwvc3Bh bj48L2I+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 VmVyZGFuYSxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JR1Agd2l0aCBTUiBleHRlbnNpb25z PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+IDwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmEsc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+bWF5 IGluZGVlZCBkeW5hbWljYWxseSBhbGxvY2F0ZSBhbmQgZG93bmxvYWQgTVBMUyBsYWJlbHMg YWN0aW5nIGFzIGxvY2FsIEFkai1TSURzIDwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjwvc3Bhbj48L2I+PC9wcmU+CiAgICAgICAgICAgICAgICA8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDo3NS43NXB0Ij48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxzcGFu PmIuPHNwYW4gc3R5bGU9ImZvbnQ6N3B0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ wqAgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmEsc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ SG93ZXZlciwgdGhlc2UgbGFiZWxzIGNhbiBiZSBhbGxvY2F0ZWQgYnkgY29uZmlndXJhdGlv biAoZS5nLiBhcyBtZW50aW9uZWQgaW4gdGhlIHRpZS1icmVha2luZyBydWxlcyBpbiBTZWN0 aW9uIDIuNS4xIGFuZCBpbiB0aGUgZXhhbXBsZSBpbiBTZWN0aW9uIEEuMi4zIGluIHRoZSBk cmFmdCksIGluIHdoaWNoIGNhc2UgSUdQIHdpdGggU1IgZXh0ZW5zaW9ucyB3b3VsZCBvbmx5 IHJlc3BvbnNpYmxlIGZvciBpdHMgYWR2ZXJ0aXNlbWVudCBhbmQgaW5zdGFsbGF0aW9uLiA8 L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9iPjwvcHJlPgog ICAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICA8L2Jsb2NrcXVvdGU+CiAgICAgICAg ICAgICNBaG1lZDogSSByZW1vdmVkIHRoZSBoaWdobGlnaHRlZCB3b3JkICJhbGxvY2F0ZWQi IDxicj4KICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+CiAgICAgICAgICAg ICAgPGRpdgpjbGFzcz0iZ21haWwtbV8tNTY0MjUxNDI3MjA4OTg1MDEyN2dtYWlsLW1fLTIz MDMzMDI0MjAwNjEyMzkxMjVXb3JkU2VjdGlvbjEiPgogICAgICAgICAgICAgICAgPHByZT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYSxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij7CoDwvc3Bhbj48L3ByZT4KICAgICAgICAgICAgICAgIDxwcmU+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OlZlcmRhbmEsc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+TklUUzwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmEsc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Ojwvc3Bhbj48L3ByZT4KICAgICAgICAgICAgICAgIDxwcmU+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmEsc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+IDo8L3Nw YW4+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9iPjwvcHJlPgogICAg ICAgICAgICAgICAgPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzkuNzVwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmEsc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PHNwYW4+ MS48c3BhbiBzdHlsZT0iZm9udDo3cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij7C oMKgwqAgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYSxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5J biBzZWN0aW9uIDIuNTo8L3NwYW4+PC9wcmU+CiAgICAgICAgICAgICAgICA8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDo3MnB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYSxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48c3Bhbj5hLjxzcGFuIHN0eWxlPSJmb250OjdwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPsKgwqDCoCA8L3NwYW4+PC9zcGFuPjwvc3Bh bj48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpWZXJk YW5hLHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkluIHRoZSBzZW50ZW5jZSDigJw8L3NwYW4+ PGI+UHJvY2VkdXJlcyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgZXF1YWxseSBhcHBsaWVz IHRvIHRoaXMgY2FzZTwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYSxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj7igJ0gdGhlIG5vdW4gaXMgaW4gcGx1cmFsIGJ1dCB0aGUg dmVyYiBpcyBpbiBzaW5ndWxhci4gKElmIHRoaXMgc2VudGVuY2UgaXMgcmVtb3ZlZCBhcyBz dWdnZXN0ZWQgYWJvdmUsIHRoaXMgbml0IGRpc2FwcGVhcnMpPC9zcGFuPjwvcHJlPgogICAg ICAgICAgICAgICAgPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzJwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OlZlcmRhbmEsc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PHNwYW4+Yi48 c3BhbiBzdHlsZT0iZm9udDo3cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij7CoMKg wqAgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYSxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGUg c2FtZSBwcm9ibGVtIGV4aXN0cyBpbiB0aGUgc2VudGVuY2Ug4oCcPC9zcGFuPjxiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+QW4gaW5jb21pbmcgbGFiZWwgY29sbGlzaW9uIG9jY3Vy cyBpZiB0aGUgU0lEcyBvZiB0aGUgc2V0IG9mIEZFQ3Mge0ZFQzEsIEZFQzIsLi4uLCBGRUNr fSBtYXBzIHRvIHRoZSBzYW1lIGluY29taW5nIFNSIE1QTFMgbGFiZWwgIkwxIjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmEsc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+4oCdPC9zcGFuPjwvcHJlPgogICAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAg ICA8L2Jsb2NrcXVvdGU+CiAgICAgICAgICAgICNBaG1lZDogVGhlIHNlbnRlbmNlIGlzIHJl bW92ZWQgYXMgeW91IHN1Z2dlc3RlZDxicj4KICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+CiAgICAgICAgICAgICAgPGRpdgpjbGFzcz0iZ21haWwtbV8tNTY0MjUxNDI3 MjA4OTg1MDEyN2dtYWlsLW1fLTIzMDMzMDI0MjAwNjEyMzkxMjVXb3JkU2VjdGlvbjEiPgog ICAgICAgICAgICAgICAgPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzJwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmEsc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PC9zcGFu PjwvcHJlPgogICAgICAgICAgICAgICAgPHAKY2xhc3M9ImdtYWlsLW1fLTU2NDI1MTQyNzIw ODk4NTAxMjdnbWFpbC1tXy0yMzAzMzAyNDIwMDYxMjM5MTI1TXNvTGlzdFBhcmFncmFwaCIK ICAgICAgICAgICAgICAgICAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM5Ljc1cHQiPiA8c3Bhbj4y LjxzcGFuCiAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udDo3cHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij7CoMKgwqDCoMKgwqAKICAgICAgICAgICAgICAgICAgICA8 L3NwYW4+PC9zcGFuPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+SW4gc2VjdGlvbgogICAgICAg ICAgICAgICAgICAyLjEwLjEgdGhlIHByZXBvc2l0aW9uIOKAnDxiPjxzcGFuCiAgICAgICAg ICAgICAgICAgICAgICBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPnRvPC9zcGFuPjwvYj7igJ0KICAgICAgICAgICAgICAgICAgYmV0d2VlbiB0aGUgd29y ZHMg4oCcPGI+PHNwYW4+YWNjb3JkaW5nPC9zcGFuPjwvYj7igJ0gYW5kCiAgICAgICAgICAg ICAgICAgIOKAnDxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+TVBMUzwvc3Bhbj48L2I+4oCdCiAgICAgICAgICAgICAgICAgIGlzIG1pc3Np bmcgaW4gdGhlIGZyYWdtZW50IOKAnDxiPjxzcGFuCiAgICAgICAgICAgICAgICAgICAgICBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlB1c2gKICAgICAg ICAgICAgICAgICAgICAgIHRoZSBjYWxjdWxhdGVkIGxhYmVsIGFjY29yZGluZyB0aGUgTVBM UyBsYWJlbAogICAgICAgICAgICAgICAgICAgICAgcHVzaGluZyBydWxlcyBzcGVjaWZpZWQg aW4gW1JGQzMwMzJdPC9zcGFuPjwvYj7igJ0uPC9wPgogICAgICAgICAgICAgIDwvZGl2Pgog ICAgICAgICAgICA8L2Jsb2NrcXVvdGU+CiAgICAgICAgICAgICNBaG1lZCBhZGRlZCB0aGUg bWlzc2luZyAidG8iPGJyPgogICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4K ICAgICAgICAgICAgICA8ZGl2CmNsYXNzPSJnbWFpbC1tXy01NjQyNTE0MjcyMDg5ODUwMTI3 Z21haWwtbV8tMjMwMzMwMjQyMDA2MTIzOTEyNVdvcmRTZWN0aW9uMSI+CiAgICAgICAgICAg ICAgICA8cApjbGFzcz0iZ21haWwtbV8tNTY0MjUxNDI3MjA4OTg1MDEyN2dtYWlsLW1fLTIz MDMzMDI0MjAwNjEyMzkxMjVNc29MaXN0UGFyYWdyYXBoIgogICAgICAgICAgICAgICAgICBz dHlsZT0ibWFyZ2luLWxlZnQ6MzkuNzVwdCI+IDxzcGFuPjMuPHNwYW4KICAgICAgICAgICAg ICAgICAgICAgIHN0eWxlPSJmb250OjdwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PsKgwqDCoMKgwqDCoAogICAgICAgICAgICAgICAgICAgIDwvc3Bhbj48L3NwYW4+PHNwYW4g ZGlyPSJMVFIiPjwvc3Bhbj5Qcm9ibGVtcyB3aXRoCiAgICAgICAgICAgICAgICAgIHJlZmVy ZW5jZXM6PC9wPgogICAgICAgICAgICAgICAgPHAKY2xhc3M9ImdtYWlsLW1fLTU2NDI1MTQy NzIwODk4NTAxMjdnbWFpbC1tXy0yMzAzMzAyNDIwMDYxMjM5MTI1TXNvTGlzdFBhcmFncmFw aCIKICAgICAgICAgICAgICAgICAgc3R5bGU9Im1hcmdpbi1sZWZ0OjcycHQiPiA8c3Bhbj5h LjxzcGFuCiAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udDo3cHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij7CoMKgwqDCoMKgwqAKICAgICAgICAgICAgICAgICAgICA8 L3NwYW4+PC9zcGFuPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+PGEKaHJlZj0iaHR0cHM6Ly9t YWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvQ19XM0tCY0wyQVd4bWxCN1Nw NTNfUHZxYlFBIgogICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIiBtb3otZG8t bm90LXNlbmQ9InRydWUiPkFzIHJlcG9ydGVkCiAgICAgICAgICAgICAgICAgICAgYnkgU2Vy Z2V5PC9hPiwgdGhlcmUgYXJlIHR3byBvY2N1cnJlbmNlcyBvZgogICAgICAgICAgICAgICAg ICByZWZlcmVuY2VzIHRvIFJGQyA4MDQyIOKAnE9TUEYgVHdvLVBhcnQgTWV0cmlj4oCdIGlu c3RlYWQKICAgICAgICAgICAgICAgICAgb2YgUkZDIDg0MDIuIExvdHMgb2YgdGhhbmtzIHRv IFNlcmdleSBmb3IgY2F0Y2hpbmcKICAgICAgICAgICAgICAgICAgdGhpczwvcD4KICAgICAg ICAgICAgICA8L2Rpdj4KICAgICAgICAgICAgPC9ibG9ja3F1b3RlPgogICAgICAgICAgICAj QWhtZWQ6IENvcnJlY3RlZCwgdGhhbmtzIGFnYWluPGJyPgogICAgICAgICAgICA8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj4KICAgICAgICAgICAgICA8ZGl2CmNsYXNzPSJnbWFpbC1tXy01 NjQyNTE0MjcyMDg5ODUwMTI3Z21haWwtbV8tMjMwMzMwMjQyMDA2MTIzOTEyNVdvcmRTZWN0 aW9uMSI+CiAgICAgICAgICAgICAgICA8cApjbGFzcz0iZ21haWwtbV8tNTY0MjUxNDI3MjA4 OTg1MDEyN2dtYWlsLW1fLTIzMDMzMDI0MjAwNjEyMzkxMjVNc29MaXN0UGFyYWdyYXBoIgog ICAgICAgICAgICAgICAgICBzdHlsZT0ibWFyZ2luLWxlZnQ6NzJwdCI+IDxzcGFuPmIuPHNw YW4KICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250OjdwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPsKgwqDCoMKgwqDCoAogICAgICAgICAgICAgICAgICAgIDwvc3Bh bj48L3NwYW4+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj5SZWZlcmVuY2UgdG8KICAgICAgICAg ICAgICAgICAgUkZDIDgxNzQgbWlzdGFrZW5seSBjb250YWlucyBhIGxpbmsgdG/CoCBSRkMg NzI3NC48L3A+CiAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgIDwvYmxvY2txdW90 ZT4KICAgICAgICAgICAgI0FobWVkOiBDb3JyZWN0ZWQ8YnI+CiAgICAgICAgICAgIDxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPgogICAgICAgICAgICAgIDxkaXYKY2xhc3M9ImdtYWlsLW1f LTU2NDI1MTQyNzIwODk4NTAxMjdnbWFpbC1tXy0yMzAzMzAyNDIwMDYxMjM5MTI1V29yZFNl Y3Rpb24xIj4KICAgICAgICAgICAgICAgIDxwPjxzcGFuCiAgICAgICAgICAgICAgICAgICAg c3R5bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5OlZlcmRhbmEsc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+SG9wZWZ1bGx5CiAgICAgICAgICAgICAgICAgICAgdGhlc2Ugbm90ZXMg d2lsbCBiZSB1c2VmdWwuPC9zcGFuPjwvcD4KICAgICAgICAgICAgICA8L2Rpdj4KICAgICAg ICAgICAgPC9ibG9ja3F1b3RlPgogICAgICAgICAgICAjQWhtZWQ6IFZFUlkgdXNlZnVsPGJy PgogICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4KICAgICAgICAgICAgICA8 ZGl2CmNsYXNzPSJnbWFpbC1tXy01NjQyNTE0MjcyMDg5ODUwMTI3Z21haWwtbV8tMjMwMzMw MjQyMDA2MTIzOTEyNVdvcmRTZWN0aW9uMSI+CiAgICAgICAgICAgICAgICA8cD48c3Bhbgog ICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTBwdDtmb250LWZhbWlseTpW ZXJkYW5hLHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjwvc3Bhbj48L3A+CiAgICAgICAgICAg ICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDwvcD4KICAgICAgICAgICAgICAg IDxwIGNsYXNzPSJNc29Ob3JtYWwiPlNhc2hhPC9wPgogICAgICAgICAgICAgICAgPHAgY2xh c3M9Ik1zb05vcm1hbCI+wqA8L3A+CiAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9y bWFsIj5PZmZpY2U6ICs5NzItMzkyNjYzMDI8L3A+CiAgICAgICAgICAgICAgICA8cCBjbGFz cz0iTXNvTm9ybWFsIj5DZWxsOsKgwqDCoMKgwqAgKzk3Mi01NDkyNjYzMDI8L3A+CiAgICAg ICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5FbWFpbDrCoMKgIDxhCmNsYXNzPSJn bWFpbC1tXy01NjQyNTE0MjcyMDg5ODUwMTI3Z21haWwtbV8tMjMwMzMwMjQyMDA2MTIzOTEy NW1vei10eHQtbGluay1hYmJyZXZpYXRlZCIKICAgICAgICAgICAgICAgICAgICBocmVmPSJt YWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20iCiAgICAgICAgICAgICAg ICAgICAgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+QWxleGFuZGVy LlZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+PC9wPgogICAgICAgICAgICAgICAgPHAgY2xh c3M9Ik1zb05vcm1hbCI+wqA8L3A+CiAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAg ICAgPGJyIGNsZWFyPSJhbGwiPgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+CiAgICAgICAg ICAgICAgPGJyPgogICAgICAgICAgICAgIFRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5k ZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQKICAgICAgICAgICAgICBjb250YWlucyBp bmZvcm1hdGlvbiB3aGljaCBpcyA8YnI+CiAgICAgICAgICAgICAgQ09ORklERU5USUFMIGFu ZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVjb20uCiAgICAgICAgICAg ICAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyA8YnI+CiAgICAgICAgICAgICAgdHJhbnNt aXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUKICAg ICAgICAgICAgICBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgPGJyPgog ICAgICAgICAgICAgIGFuZCBhbGwgY29waWVzIHRoZXJlb2YuPGJyPgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+CiAgICAgICAgICAgIDwvYmxvY2txdW90ZT4KICAgICAgICAgIDwvZGl2 PgogICAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+CiAgICAgICAgICBzcHJpbmcgbWFpbGluZyBsaXN0PGJyPgogICAgICAgICAg PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiCiAgICAg ICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4K ICAgICAgICAgIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc3ByaW5nIgogICAgICAgICAgICByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5r IiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc3ByaW5nPC9hPjxicj4KICAgICAgICA8L2Jsb2NrcXVvdGU+CiAgICAgIDwv ZGl2PgogICAgICA8YnIgY2xlYXI9ImFsbCI+CiAgICAgIDxkaXY+PGJyPgogICAgICA8L2Rp dj4KICAgICAgLS0gPGJyPgogICAgICA8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWwtbV8t NTY0MjUxNDI3MjA4OTg1MDEyN2dtYWlsX3NpZ25hdHVyZSI+CiAgICAgICAgPGRpdiBkaXI9 Imx0ciI+CiAgICAgICAgICA8ZGl2PgogICAgICAgICAgICA8ZGl2IGRpcj0ibHRyIj4KICAg ICAgICAgICAgICA8ZGl2PgogICAgICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+CiAgICAg ICAgICAgICAgICAgIDxkaXY+CiAgICAgICAgICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+ CiAgICAgICAgICAgICAgICAgICAgICA8ZGl2PgogICAgICAgICAgICAgICAgICAgICAgICA8 ZGl2IGRpcj0ibHRyIj4KICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PgogICAgICAg ICAgICAgICAgICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxkaXY+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRp dgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9InBhZGRpbmctdG9w OjEwcHg7bWFyZ2luLXRvcDoxMHB4Ij4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDx0YWJsZQpzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LWZhbWlseTpUaW1lczts aW5lLWhlaWdodDpub3JtYWw7Zm9udC1zaXplOm1lZGl1bSIKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRib2R5PgogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDx0cgogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgc3R5bGU9ImNvbG9yOnJnYig4NSw4NSw4NSk7Zm9udC1mYW1pbHk6 c2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPgogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPHRkIHN0eWxlPSJib3JkZXItdG9wOjJweCBzb2xpZAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZ2IoMjEzLDE1LDM3KSIKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbm93cmFwPSJub3dyYXAi PlByemVteXNsYXcKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IlBLIiBLcm9sIHw8L3RkPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPHRkIHN0eWxlPSJib3JkZXItdG9wOjJweCBzb2xpZAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICByZ2IoNTEsMTA1LDIzMikiCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vd3JhcD0ibm93cmFwIj7CoFN0cmF0ZWdp YwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOZXR3b3JrIEVu Z2luZWVyPC90ZD4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0 ZCBzdHlsZT0iYm9yZGVyLXRvcDoycHggc29saWQKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgcmdiKDAsMTUzLDU3KSIgbm93cmFwPSJub3dyYXAiPjxzcGFu CnN0eWxlPSJsaW5lLWhlaWdodDoxOXB4O3doaXRlLXNwYWNlOm5vcm1hbCI+PHNwYW4KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJib3Jk ZXItd2lkdGg6MnB4CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAwcHgKMHB4O2JvcmRlci1zdHlsZTpzb2xpZDtib3JkZXItY29sb3I6cmdiKDUxLDEw NSwyMzIpO3BhZGRpbmctdG9wOjJweDttYXJnaW4tdG9wOjJweCI+aW5nCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC9zcGFuPjxzcGFuCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iYm9yZGVy LXdpZHRoOjJweAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgMHB4CjBweDtib3JkZXItc3R5bGU6c29saWQ7Ym9yZGVyLWNvbG9yOnJnYigwLDE1Myw1 Nyk7cGFkZGluZy10b3A6MnB4O21hcmdpbi10b3A6MnB4Ij7CoDxhCmhyZWY9Im1haWx0bzpw a3JvbEBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVl Ij48Zm9udAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGNvbG9yPSIjMTE1NWNjIj5wa3JvbEBnb29nbGUuY29tPC9mb250PjwvYT7CoDwvc3Bh bj48L3NwYW4+PC90ZD4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDx0ZCBzdHlsZT0iYm9yZGVyLXRvcDoycHggc29saWQKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgcmdiKDIzOCwxNzgsMTcpIgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBub3dyYXA9Im5vd3JhcCI+PGJyPgogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD4KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8L3RyPgogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8L3Rib2R5PgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PC90YWJsZT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8L2Rpdj4KICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4KICAgICAgICAg ICAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4KICAg ICAgICAgICAgICAgICAgICA8L2Rpdj4KICAgICAgICAgICAgICAgICAgPC9kaXY+CiAgICAg ICAgICAgICAgICA8L2Rpdj4KICAgICAgICAgICAgICA8L2Rpdj4KICAgICAgICAgICAgPC9k aXY+CiAgICAgICAgICA8L2Rpdj4KICAgICAgICA8L2Rpdj4KICAgICAgPC9kaXY+CiAgICA8 L2Jsb2NrcXVvdGU+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== --------------DFD87B35EB70336E4F03A005-- From nobody Sat Mar 30 21:46:21 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA70E12013A; Sat, 30 Mar 2019 21:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 2zwXjwvC40_0; Sat, 30 Mar 2019 21:46:14 -0700 (PDT) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.117]) (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 027B612011F; Sat, 30 Mar 2019 21:46:12 -0700 (PDT) Received: from [85.158.142.200] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-6.bemta.az-b.eu-central-1.aws.symcld.net id E5/37-16347-F0640AC5; Sun, 31 Mar 2019 04:46:07 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjl+JIrShJLcpLzFFi42Ix0fyhosvvtiD G4H0nj8XiNRIWmzs2sFnsWHyE1eLW0pWsFifn/GC2WLDmKbvF8Qu/GR3YPXbOusvu0XLkLavH kiU/mQKYo1gz85LyKxJYM/qP3mIruHObuWL726OMDYw7rjJ3MXJxsAgsYpbYPbOTEcQREpjIJ HHt3BQmCOc+o8TCNW+BHE4ONgFbiU2r77KB2CICuhKXXp4C62AWWMckcW5/OztIQlggWOJl1y cmiKIQiY/3zrBC2FYSB2d1MoPYLAKqEjen7wKr4RWIlXj0cQuYLSTQzyhxc6E5iM0JtOzHw6V gyxgFxCS+n1oDVsMsIC5x68l8MFtCQEBiyZ7zzBC2qMTLx/9YIeqTJO4/XcgIEVeUmHFvDjuE LStxaX43VNxXoufqO6BeDiBbWWLLi1iQXyQEHjNKXNy4HWqmlkTjinY2CFtKYv/meVC9ORLPP h2HqpGR+NG1iwWieS6bxN//U9khnkmWODHnMwtEkZzEqt6HUEUXmCU23V3PDvFNnsS3B49ZJj BqzkLy3CwkqVngQBKUODnzCZDNARTXlFi/Sx+iRFFiSvdDdghbQ6J1zlx2ZPEFjOyrGC2TijL TM0pyEzNzdA0NDHQNDY11TXQNTYz0Eqt0k/RSS3WTU/NKihKBsnqJ5cV6xZW5yTkpenmpJZsY gakvpZClbwfjx/b0Q4ySHExKorx/182PEeJLyk+pzEgszogvKs1JLT7EKMPBoSTBK+O6IEZIs Cg1PbUiLTMHmIRh0hIcPEoivJ0uQGne4oLE3OLMdIjUKUZvjgOLHs5l5ujb+AxIbrkPIreDyV 1g8u3B53OZhVjy8vNSpcR5HUE2CICMyCjNg1sAyyaXGGWlhHkZGRgYhHgKUotyM0tQ5V8xinM wKgnz6oBM4cnMK4G74xXQiUxAJ1qUzgc5sSQRISXVwMj+ezrbVSvWxYcizPc8ehix/dPutyoS HBU5VyxskgMlPAzv7NnSmrXvfvtv44Yuxi6DWtNrW6Ut09b/1Dnf9qG6oUFj/+R79afmlImmr P0TEfPkotCLI9Gbn5hq2gR5fyhV+NhfN9v38IMiLed7nMJTTB98n6ow4buTzJ3f6yLnTw9jW/ Vh3n8lluKMREMt5qLiRAA+ryIuIQQAAA== X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-33.tower-245.messagelabs.com!1554007563!4205550!1 X-Originating-IP: [52.41.248.36] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 7779 invoked from network); 31 Mar 2019 04:46:06 -0000 Received: from us-west-2a.mta.dlp.protect.symantec.com (HELO EUR03-DB5-obe.outbound.protection.outlook.com) (52.41.248.36) by server-33.tower-245.messagelabs.com with AES256-SHA256 encrypted SMTP; 31 Mar 2019 04:46:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i6bhYJ9M9EeHQVlN/HeMnV5Byl5y3+X8VToEzBJmZto=; b=AXzO6uFrh53XyTaka/vXVtwS0QH8GCL/l2Z9QgBVB+bB2OGNJVP7WlgWQTl0tvsML5xS8ourIHdynt8RWejd+LyuyOhhXG8F1F09BOKC1oNVaTLOmPrp7yHqVRbq8NkaIxZ3GYoNJPv92MmoexF7sSamfXc0BFCQf/3RVVhjfLE= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB5731.eurprd03.prod.outlook.com (20.179.255.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.15; Sun, 31 Mar 2019 04:46:00 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::7946:b505:a799:7a25]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::7946:b505:a799:7a25%3]) with mapi id 15.20.1750.017; Sun, 31 Mar 2019 04:46:00 +0000 From: Alexander Vainshtein To: Ahmed Bashandy CC: "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , "draft-ietf-spring-segment-routing-mpls.authors@ietf.org" , Min Ye , "rtg-ads@ietf.org" Thread-Topic: RTG-DIR Last Call review of draft-ietf-spring-segment-routing-mpls-18 Thread-Index: AdTUGm/eJf6lMfiCTXeKfnpkjeXMAgRsjQ+AAGtdWKA= Date: Sun, 31 Mar 2019 04:46:00 +0000 Message-ID: References: <65361777-db63-9a7a-9199-dd04425b4785@gmail.com> In-Reply-To: <65361777-db63-9a7a-9199-dd04425b4785@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 51dcbff4-f7e3-49f9-bf74-08d6b593c620 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM0PR03MB5731; x-ms-traffictypediagnostic: AM0PR03MB5731: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-forefront-prvs: 0993689CD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(39850400004)(376002)(346002)(366004)(199004)(189003)(51444003)(6116002)(6306002)(8936002)(8676002)(99286004)(6436002)(14444005)(33656002)(54906003)(5660300002)(72206003)(316002)(53936002)(53946003)(97736004)(81156014)(478600001)(256004)(52536014)(6916009)(105586002)(2906002)(11346002)(6506007)(476003)(186003)(66574012)(74316002)(86362001)(14454004)(236005)(229853002)(81166006)(106356001)(53546011)(26005)(102836004)(71190400001)(4326008)(66066001)(790700001)(7736002)(68736007)(55016002)(3846002)(76176011)(71200400001)(54896002)(9686003)(606006)(446003)(486006)(6246003)(7696005)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB5731; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: YBDnzTcDq0vAQhAJKVncTbR1FOZvoIRphqZIgnlAvo1/XQhOgvwOQf51l4csCJjFPmTiV9nS5eRF6Cmj47Ub2fVlA1F3UKA0x0AP+5e7uqu4L3+ztytw2+5qF7OeC+tls0ArHq9AUK62gTRtBeCBUvDT2MrBRrFXLSiQUGqEoqF225HLTFgEjqvY0CXK9TkVZYlirUL4hM9YTjB5c8NJ4EB0bUBw0TErKIyQRoVywseypDDJ9uXQp/WOn+r6QooPLlmS8w/rvAR3uPTwBndfo0k2rIuubPEb6ZgLd1gISiCiTMMawz6E+CFWY0WOFE5WQaPyQv9xcA0i2qMnxc5FTE4492HErhWyRZq186BVyAu6LRiMoIXqtGFYrfqWcEy8dXRvHo0zsyQbn8bxUqZVvmvdSfO1kVqqXWqBJEYVOFo= Content-Type: multipart/alternative; boundary="_000_AM0PR03MB3828866508FC9A2FD28175319D540AM0PR03MB3828eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 51dcbff4-f7e3-49f9-bf74-08d6b593c620 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2019 04:46:00.6907 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB5731 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] RTG-DIR Last Call review of draft-ietf-spring-segment-routing-mpls-18 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 04:46:19 -0000 --_000_AM0PR03MB3828866508FC9A2FD28175319D540AM0PR03MB3828eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWhtZWQsCkxvdHMgb2YgdGhhbmtzIGZvciBhIHZlcnkgZW5jb3VyYWdpbmcgYW5kIGNvb3BlcmF0 aXZlIHJlc3BvbnNlLgoKSSBjaGVja2VkIHRoZSAtMTkgdmVyc2lvbiB3aXRoIHJlZ2FyZCB0byB0 aGUgaXNzdWVzIEnigJl2ZSByYWlzZWQgaW4gbXkgUlRHLURJUiBMYXN0IENhbGwgcmV2aWV3LCBh bmQgaGVyZSBpcyB0aGUgc3VtbWFyeSBzdGF0dXM6CgpJc3N1ZS9OaXQgcmFpc2VkIGluIHJldmll dyBvZiB0aGUgLTE4IHZlcnNpb24KClN0YXR1cyBpbiB0aGUgLTE5IHZlcnNpb24KCkNvbW1lbnRz CgpDaGVjayBvZiB0aGUgcHJlZml4IGFkdmVydGlzZWQgYXMgYSBOb2RlIFNJRCBiZWluZyBvd25l ZCBieSBtb3JlIHRoYW4gb25lIHJvdXRlciBpbiB0aGUgZG9tYWluIGlzIE9QVElPTkFMUgoKUmVz b2x2ZWQKClRoZSByZXF1aXJlbWVudCBsZXZlbCBmb3Igc3VjaCBhIGNoZWNrIGhhcyBiZWVuIGNo YW5nZWQgZnJvbSBNQVkgdG8gU0hPVUxECgpVbm5lY2Vzc2FyeSB0ZXh0IGRlY2xhcmluZyBub24t Y29tcGxpYW50IGltcGxlbWVudGF0aW9ucyBhcyBmYXVsdHkgYW5kIHVzaW5nIGZvcndhcmQgcmVm ZXJlbmNlcwoKUmVzb2x2ZWQKClVubmVjZXNzYXJ5IHRleHQgaGFzIGJlZW4gcmVtb3ZlZAoKSW5h Y2N1cmF0ZSBzdGF0ZW1lbnQgcmVnYXJkaW5nIGFsbG9jYXRpb24gYW5kIGFkdmVydGlzZW1lbnQg b2YgbGFiZWxzIHJlcHJlc2VudGluZyBBZGotU0lEcyBieSBJR1AgZXh0ZW5zaW9ucyBmb3IgU1IK ClJlc29sdmVkCgpUaGUgY29ycmVzcG9uZGluZyBzdGF0ZW1lbnQgZG9lcyBub3QgbWVudGlvbiBs YWJlbCBhbGxvY2F0aW9uIGFueSBtb3JlCgpOaXQ6IEdyYW1tYXIgaXNzdWVzIChzaW5ndWxhciB2 cy4gcGx1cmFsKQoKRml4ZWQKCkluIGFsbCBwbGFjZXMgSeKAmXZlIG1lbnRpb25lZCBhbmQgdGhl biBpbiBzb21lIG90aGVyIG9uZXMKCk5pdDogUmVmZXJlbmNlIGlzc3VlcwoKRml4ZWQKCgoKCgpS ZWdhcmRzLApTYXNoYQoKT2ZmaWNlOiArOTcyLTM5MjY2MzAyCkNlbGw6ICAgICAgKzk3Mi01NDky NjYzMDIKRW1haWw6ICAgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20KCkZyb206IEFo bWVkIEJhc2hhbmR5IDxhYmFzaGFuZHkuaWV0ZkBnbWFpbC5jb20+ClNlbnQ6IEZyaWRheSwgTWFy Y2ggMjksIDIwMTkgNDoxNCBBTQpUbzogQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRlci5W YWluc2h0ZWluQGVjaXRlbGUuY29tPjsgcnRnLWFkc0BpZXRmLm9yZwpDYzogcnRnLWRpckBpZXRm Lm9yZzsgc3ByaW5nQGlldGYub3JnOyBtcGxzQGlldGYub3JnOyBkcmFmdC1pZXRmLXNwcmluZy1z ZWdtZW50LXJvdXRpbmctbXBscy5hdXRob3JzQGlldGYub3JnOyBNaW4gWWUgPGFteS55ZW1pbkBo dWF3ZWkuY29tPgpTdWJqZWN0OiBSZTogUlRHLURJUiBMYXN0IENhbGwgcmV2aWV3IG9mIGRyYWZ0 LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLTE4CgoKVGhhbmtzIGEgbG90IGZvciB0 aGUgcmV2aWV3CgpJIHVwbG9hZGVkIHZlcnNpb24gMTkgb2YgdGhlIGRyYWZ0LCB3aGljaCwgSU1P LCBhZGRyZXNzZXMgYWxsIHlvdXIgY29tbWVudHMKClNlZSB0aGUgcmVwbHkgIiNBaG1lZCIKT24g My8xMC8xOSA5OjU1IEFNLCBBbGV4YW5kZXIgVmFpbnNodGVpbiB3cm90ZToKCkhlbGxvLAoKSSBo YXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9y IHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmlldyBhbGwg cm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIElF VEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJl cXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNl IHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRp bmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcv YXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpcjxodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVh L3J0Zy90cmFjL3dpa2kvUnRnRGlyPgoKQWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1h cmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwg aWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURiBMYXN0 IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRo ZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFmdC4KCkRvY3VtZW50 OiByZXZpZXcgb2YgZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMtMTgKUmV2 aWV3ZXI6IEFsZXhhbmRlciAo4oCcU2FzaGHigJ0pIFZhaW5zaHRlaW4KUmV2aWV3IERhdGU6IDEw LU1hci0xOQpJRVRGIExDIEVuZCBEYXRlOiAwNy1NYXItMjAxOQpJbnRlbmRlZCBTdGF0dXM6IFBy b3Bvc2VkIFN0YW5kYXJkCgpTdW1tYXJ5OiBJIGhhdmUgc29tZSBtaW5vciBjb25jZXJucyBhYm91 dCB0aGlzIGRvY3VtZW50IHRoYXQgSSB0aGluayBzaG91bGQgYmUgcmVzb2x2ZWQgYmVmb3JlIHB1 YmxpY2F0aW9uLgoKQ29tbWVudHM6CgpJIGhhdmUgZG9uZSBhbiBlYXJseSBSVEctRElSIHJldmll dyBvZiB0aGUgLTE0IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGhhbGYgYSB5ZWFyIGFnbywgYW5kIHRo ZSBpc3N1ZXMgSeKAmXZlIHJhaXNlZCB0aGVuIGhhdmUgYmVlbiByZXNvbHZlZCBpbiB0aGUgc3Vi c2VxdWVudCB2ZXJzaW9ucyBvbmUgd2F5IG9yIGFub3RoZXIpLiBUaGVyZWZvcmUgdGhpcyByZXZp ZXcgaGFzIGJlZW4gaW50ZW50aW9uYWxseSBmb2N1c2VkIG9uIHRoZSBjaGFuZ2VzIGRvbmUgdG8g dGhlIGRyYWZ0IGluIHRoZSBmZXcgcmVjZW50IHZlcnNpb25zLgoKSW4gbXkgcHJldmlvdXMgcmV2 aWV3IEkgaGF2ZSBub3RpY2VkIHRoYXQgdGhlIGRyYWZ0IHdhcyBub3QgZWFzeSByZWFkaW5nIGZv ciBtZS4gU2luY2UgdGhlbiByZWFkYWJpbGl0eSBvZiB0aGUgZHJhZnQgaGFzIGJlZW4gaW1wcm92 ZWQuIEhvd2V2ZXIsIHRoZXJlIGFyZSBzdGlsbCBzZXZlcmFsIHBsYWNlcyBpbiB0aGUgbmV3IHRl eHQgdGhhdCBhcmUgc3RpbGwgZGlmZmljdWx0IHRvIHBhcnNlLgoKSSBkaWQgbm90IHJ1biB0aGUg bml0cyBjaGVja2VyIG9uIHRoZSBkcmFmdCwgc28gbXkgbGlzdCBvZiBuaXRzIGlzIHByb2JhYmx5 IGluY29tcGxldGUuCgpKdXN0IGFzIHdpdGggbXkgZWFybGllciByZXZpZXcsIEkgc2VuZCB0aGlz IG9uZSBhbHNvIHRvIHRoZSBNUExTIFdHIGxpc3Qg4oCTIGFuZCBmb3IgdGhlIHNhbWUgcmVhc29u cy4KCkkgdHJpZWQgdG8gZGlzY3VzcyBteSByZXZpZXcgcHJpdmF0ZWx5IHdpdGggdGhlIGF1dGhv cnMsIGJ1dCB0aGV5IGRpZCBub3QgcmVzcG9uZC4KCk1ham9yIElzc3VlczogTm8gbWFqb3IgaXNz dWVzIGZvdW5kLgoKTWlub3IgSXNzdWVzOgoKMS4gIFRoZSB0ZXh0IGluIFNlY3Rpb24gMSBzdGF0 ZXMgdGhhdCDigJxhIG5ldHdvcmsgb3BlcmF0b3IgU0hPVUxEIGNvbmZpZ3VyZSBhdCBsZWFzdCBv bmUgbm9kZSBzZWdtZW50IHBlciByb3V0aW5nIGluc3RhbmNlLCB0b3BvbG9neSwgYWxnb3JpdGht 4oCdIGFuZCBjb250aW51ZXMgdGhhdCDigJxBbiBpbXBsZW1lbnRhdGlvbiBNQVkgY2hlY2sgdGhh dCBhbiBJR1Agbm9kZS1TSUQgaXMgbm90IGFzc29jaWF0ZWQgd2l0aCBhIHByZWZpeCB0aGF0IGlz IG93bmVkIGJ5IG1vcmUgdGhhbiBvbmUgcm91dGVyIHdpdGhpbiB0aGUgc2FtZSByb3V0aW5nIGRv bWFpbiwgSWYgc28sIGl0IFNIT1VMRCBOT1QgdXNlIHRoaXMgTm9kZS1TSUQsIE1BWSB1c2UgYW5v dGhlciBvbmUgaWYgYXZhaWxhYmxlLCBhbmQgU0hPVUxEIGxvZyBhbiBlcnJvcuKAnS4gVGhpcyBs b29rcyBzb21ld2hhdCBjb250cm92ZXJzaWFsIHRvIG1lIGJlY2F1c2U6CgphLiAgVGhlIGNoZWNr IG9mIHRoZSBOb2RlIFNJRCBub3QgYmVpbmcgb3duZWQgYnkgbW9yZSB0aGFuIG9uZSByb3V0ZXIg aW4gdGhlIHJvdXRpbmcgZG9tYWluIGlzIGRlZmluZWQgYXMgcHVyZWx5IG9wdGlvbmFsLiBBY2Nv cmRpbmcgdG8gUkZDIDIxMTksIGltcGxlbWVudGF0aW9ucyB0aGF0IGNob29zZSB0byBpbXBsZW1l bnQgc3VjaCBhIGNoZWNrIG11c3QgYmUgYWJsZSB0byBpbnRlcm9wZXJhdGUgd2l0aCBpbXBsZW1l bnRhdGlvbnMgdGhhdCBkbyBub3QgaW1wbGVtZW50IGl0CgpiLiAgVGhlIHJlY29tbWVuZGVkIGhh bmRsaW5nIG9mIHRoZSByZXN1bHRzIG9mIHRoaXMgY2hlY2sgKGZ1bGx5IGFsaWduZWQgd2l0aCB0 aGUgdGV4dCBpbiBTZWN0aW9uIDMuMiBwZiBSRkMgODQwMiB0aGF0IHByb2hpYml0cyB1c2luZyBw cmVmaXhlcyBvd25lZCBieSBtb3JlIHRoYW4gb25lIHJvdXRlciBpbiB0aGUgZG9tYWluIGFzIE5v ZGUtU09Ecykgc3Ryb25nbHkgc3VnZ2VzdHMgdGhhdCB0aGUgcHJlZml4IHRoYXQgaXMgb3duZWQg YnkgbW9yZSB0aGFuIG9uZSByb3V0ZXIgaW4gdGhlIGRvbWFpbiBpcyB1bnVzYWJsZSBhcyB0aGUg Tm9kZSBTSUQKCkkgc2VlIHR3byBwb3NzaWJpbGl0aWVzIHRvIHJlc29sdmUgdGhpcyBjb250cm92 ZXJzeTogZWl0aGVyIG1ha2UgdGhlIGNoZWNrIGluIHF1ZXN0aW9uIGEg4oCccmVhbCByZXF1aXJl bWVudOKAnSAoaS5lLiwgcmVwbGFjZSBNQVkgd2l0aCBTSE9VTEQgb3IgZXZlbiBNVVNUKSwgb3Ig ZXhwbGFpbiB3aHkgaXQgaXMgc2FmZSBlbm91Z2ggbm90IHRvIGltcGxlbWVudCBzdWNoIGEgY2hl Y2sgKGkuZS4sIGhvdyBpbXBsZW1lbnRhdGlvbnMgdGhhdCBzdXBwb3J0IHRoaXMgY2hlY2sgYW5k IGltcGxlbWVudGF0aW9ucyB0aGF0IGRvIG5vdCBzdXBwb3J0IGl0IGNhbiBpbnRlcm9wZXJhdGUg d2l0aGluIGEgZ2l2ZW4gcm91dGluZyBkb21haW4pLiBUaGUgZmlyc3Qgb2YgdGhlc2Ugb3B0aW9u cyBzZWVtcyB0byBtZSBhbGlnbmVkIHdpdGggU2VjdGlvbiAzLjIgaW4gUkZDIDg0MDIgdGhhdCBz YXlzIHRoYXQg4oCcQW4gSUdQIE5vZGUtU0lEIE1VU1QgTk9UIGJlIGFzc29jaWF0ZWQgd2l0aCBh IHByZWZpeCB0aGF0IGlzIG93bmVkIGJ5IG1vcmUgdGhhbiBvbmUgcm91dGVyIHdpdGhpbiB0aGUg c2FtZSByb3V0aW5nIGRvbWFpbuKAnS4KI0FobWVkOiBJIHJlcGxhY2VkIHRoZSBNQVkgd2l0aCBT SE9VTEQKCgoyLiAgICAgICBJIGhhdmUgIGEgcHJvYmxlbSB3aXRoIHRoZSBoaWdobGlnaHRlZCBw YXJ0IG9mIHRoZSBmb2xsb3dpbmcgdGV4dCBpbiBTZWN0aW9uIDIuNToKICAgQW4gaW1wbGVtZW50 YXRpb24gTVVTVCBOT1QgYWxsb3cgdGhlIE1DQ3MgYmVsb25naW5nIHRvIHRoZSBzYW1lCiAgIHJv dXRlciB0byBhc3NpZ24gdGhlIHNhbWUgaW5jb21pbmcgbGFiZWwgdG8gbW9yZSB0aGFuIG9uZSBT UiBGRUMuIEFuCiAgIGltcGxlbWVudGF0aW9uIHRoYXQgYWxsb3dzIHN1Y2ggYmVoYXZpb3IgaXMg Y29uc2lkZXJlZCBhcyBmYXVsdHkuCiAgIFByb2NlZHVyZXMgZGVmaW5lZCBpbiB0aGlzIGRvY3Vt ZW50IGVxdWFsbHkgYXBwbGllcyB0byB0aGlzIGNhc2UsCiAgIGJvdGggZm9yIGluY29taW5nIGxh YmVsIGNvbGxpc2lvbiAoU2VjdGlvbiAyLjU8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLTE4I3NlY3Rpb24tMi41PikgYW5k IHRoZSBlZmZlY3Qgb24KICAgb3V0Z29pbmcgbGFiZWwgcHJvZ3JhbW1pbmcgKFNlY3Rpb24gMi42 PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJv dXRpbmctbXBscy0xOCNzZWN0aW9uLTIuNj4pLgoKYS4gIFRoZSBTZWN0aW9uIGluIHF1ZXN0aW9u IGRlYWxzIHdpdGggaW5jb21pbmcgbGFiZWwgY29sbGlzaW9uIChpbiBmYWN0LCB0aGUgdGV4dCB0 aGF0IGltbWVkaWF0ZWx5IGZvbGxvd3MgdGhlIHByb2JsZW1hdGljIGZyYWdtZW50IHN0YXRlcyB0 aGF0IOKAnFRoZSBvYmplY3RpdmUgb2YgdGhlIGZvbGxvd2luZyBzdGVwcyBpcyB0byBkZXRlcm1p bmlzdGljYWxseSBpbnN0YWxsIGluIHRoZSBNUExTIEluY29taW5nIExhYmVsIE1hcCwgYWxzbyBr bm93biBhcyBsYWJlbCBGSUIsIGEgc2luZ2xlIEZFQyB3aXRoIHRoZSBpbmNvbWluZyBsYWJlbCAi TDEi4oCdCgpiLiAgQXMgYSBjb25zZXF1ZW5jZSwgYW55IG1lbnRpb24gb2YgIG91dGdvaW5nIGxh YmVsIHByb2dyYW1taW5nLCBsb29rcyBvdXQgb2YgY29udGV4dCAoZXZlbiBhY2NvbXBhbmllZCBi eSBhIGZvcndhcmQgcmVmZXJlbmNlIHRvIFNlY3Rpb24gMi42KQoKYy4gIFNlY3Rpb24gMi42IGNv dmVycyB0aGUgaW1wYWN0IG9mIGluY29taW5nIGxhYmVsIGNvbGxpc2lvbiBvbiBwcm9ncmFtbWlu ZyBvZiBvdXRnb2luZyBsYWJlbHMgaW4gcXVpdGUgYSBnZW5lcmljIHdheS4gVGhlcmVmb3JlIEkg dGhpbmsgdGhhdCB0aGUgIGhpZ2hsaWdodGVkIHBhcnQgb2YgdGhlIHF1b3RlZCBmcmFnbWVudCBj YW4gYmUgc2FmZWx5IHJlbW92ZWQgKGNvbXBsZXRlIHdpdGggdGhlIGdyYW1tYXIgbWlzdGFrZSku CgpkLiAgSSBhbHNvIGRvIG5vdCBzZWUgYW55IHZhbHVlIGluIHN0YXRpbmcgdGhhdCBhbiBpbXBs ZW1lbnRhdGlvbnMgdGhhdCB2aW9sYXRlcyBhIG1hbmRhdG9yeSByZXF1aXJlbWVudCBvZiB0aGUg c3BlYyBpcyBmYXVsdHkg4oCTIGlzbuKAmXQgdGhhdCBzZWxmLWV2aWRlbnQ/CgojQWhtZWQ6IEkg cmVtb3ZlZCB0aGUgaGlnaGxpZ2h0ZWQgdGV4dCBiZWNhdXNlIEkgYWdyZWUgd2l0aCB3aGF0IHlv dSBzYWlkIGluIGl0ZW0gKGQpIHRoYXQgaXQgaGFzIG5vIHZhbHVlCgoKCjMuICBUaGUgaGlnaGxp Z2h0ZWQgdGV4dCBpbiBTZWN0aW9uIDIuOCBpcyBub3QgYWNjdXJhdGU6CgogICBGb3IgTG9jYWwg U0lEcywgdGhlIE1DQyBpcyByZXNwb25zaWJsZSBmb3IgZG93bmxvYWRpbmcgdGhlIGNvcnJlY3QK CiAgIGxhYmVsIHZhbHVlIHRvIEZJQi4gRm9yIGV4YW1wbGUsIGFuIElHUCB3aXRoIFNSIGV4dGVu c2lvbnMgW0ktRC5pZXRmLQoKICAgaXNpcy1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9ucywgSS1E LmlldGYtb3NwZi1zZWdtZW50LXJvdXRpbmctCgogICBleHRlbnNpb25zXSBhbGxvY2F0ZXMgYW5k IGRvd25sb2FkcyB0aGUgTVBMUyBsYWJlbCBjb3JyZXNwb25kaW5nIHRvCgogICBhbiBBZGotU0lE IFtSRkM4NDAyPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NDAyPl0uCgphLiAgSUdQ IHdpdGggU1IgZXh0ZW5zaW9ucyBtYXkgaW5kZWVkIGR5bmFtaWNhbGx5IGFsbG9jYXRlIGFuZCBk b3dubG9hZCBNUExTIGxhYmVscyBhY3RpbmcgYXMgbG9jYWwgQWRqLVNJRHMKCmIuICBIb3dldmVy LCB0aGVzZSBsYWJlbHMgY2FuIGJlIGFsbG9jYXRlZCBieSBjb25maWd1cmF0aW9uIChlLmcuIGFz IG1lbnRpb25lZCBpbiB0aGUgdGllLWJyZWFraW5nIHJ1bGVzIGluIFNlY3Rpb24gMi41LjEgYW5k IGluIHRoZSBleGFtcGxlIGluIFNlY3Rpb24gQS4yLjMgaW4gdGhlIGRyYWZ0KSwgaW4gd2hpY2gg Y2FzZSBJR1Agd2l0aCBTUiBleHRlbnNpb25zIHdvdWxkIG9ubHkgcmVzcG9uc2libGUgZm9yIGl0 cyBhZHZlcnRpc2VtZW50IGFuZCBpbnN0YWxsYXRpb24uCiNBaG1lZDogSSByZW1vdmVkIHRoZSBo aWdobGlnaHRlZCB3b3JkICJhbGxvY2F0ZWQiCgoKCgpOSVRTOgoKIDoKCjEuICBJbiBzZWN0aW9u IDIuNToKCmEuICBJbiB0aGUgc2VudGVuY2Ug4oCcUHJvY2VkdXJlcyBkZWZpbmVkIGluIHRoaXMg ZG9jdW1lbnQgZXF1YWxseSBhcHBsaWVzIHRvIHRoaXMgY2FzZeKAnSB0aGUgbm91biBpcyBpbiBw bHVyYWwgYnV0IHRoZSB2ZXJiIGlzIGluIHNpbmd1bGFyLiAoSWYgdGhpcyBzZW50ZW5jZSBpcyBy ZW1vdmVkIGFzIHN1Z2dlc3RlZCBhYm92ZSwgdGhpcyBuaXQgZGlzYXBwZWFycykKCmIuICBUaGUg c2FtZSBwcm9ibGVtIGV4aXN0cyBpbiB0aGUgc2VudGVuY2Ug4oCcQW4gaW5jb21pbmcgbGFiZWwg Y29sbGlzaW9uIG9jY3VycyBpZiB0aGUgU0lEcyBvZiB0aGUgc2V0IG9mIEZFQ3Mge0ZFQzEsIEZF QzIsLi4uLCBGRUNrfSBtYXBzIHRvIHRoZSBzYW1lIGluY29taW5nIFNSIE1QTFMgbGFiZWwgIkwx IuKAnQojQWhtZWQ6IFRoZSBzZW50ZW5jZSBpcyByZW1vdmVkIGFzIHlvdSBzdWdnZXN0ZWQKCgoy LiAgICAgICBJbiBzZWN0aW9uIDIuMTAuMSB0aGUgcHJlcG9zaXRpb24g4oCcdG/igJ0gYmV0d2Vl biB0aGUgd29yZHMg4oCcYWNjb3JkaW5n4oCdIGFuZCDigJxNUExT4oCdIGlzIG1pc3NpbmcgaW4g dGhlIGZyYWdtZW50IOKAnFB1c2ggdGhlIGNhbGN1bGF0ZWQgbGFiZWwgYWNjb3JkaW5nIHRoZSBN UExTIGxhYmVsIHB1c2hpbmcgcnVsZXMgc3BlY2lmaWVkIGluIFtSRkMzMDMyXeKAnS4KI0FobWVk IGFkZGVkIHRoZSBtaXNzaW5nICJ0byIKCgozLiAgICAgICBQcm9ibGVtcyB3aXRoIHJlZmVyZW5j ZXM6CgphLiAgICAgICBBcyByZXBvcnRlZCBieSBTZXJnZXk8aHR0cHM6Ly9tYWlsYXJjaGl2ZS5p ZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvQ19XM0tCY0wyQVd4bWxCN1NwNTNfUHZxYlFBPiwgdGhl cmUgYXJlIHR3byBvY2N1cnJlbmNlcyBvZiByZWZlcmVuY2VzIHRvIFJGQyA4MDQyIOKAnE9TUEYg VHdvLVBhcnQgTWV0cmlj4oCdIGluc3RlYWQgb2YgUkZDIDg0MDIuIExvdHMgb2YgdGhhbmtzIHRv IFNlcmdleSBmb3IgY2F0Y2hpbmcgdGhpcwojQWhtZWQ6IENvcnJlY3RlZCwgdGhhbmtzIGFnYWlu CgoKYi4gICAgICAgUmVmZXJlbmNlIHRvIFJGQyA4MTc0IG1pc3Rha2VubHkgY29udGFpbnMgYSBs aW5rIHRvICBSRkMgNzI3NC4KI0FobWVkOiBDb3JyZWN0ZWQKCgpIb3BlZnVsbHkgdGhlc2Ugbm90 ZXMgd2lsbCBiZSB1c2VmdWwuCiNBaG1lZDogVkVSWSB1c2VmdWwKClJlZ2FyZHMsClNhc2hhCgpP ZmZpY2U6ICs5NzItMzkyNjYzMDIKQ2VsbDogICAgICArOTcyLTU0OTI2NjMwMgpFbWFpbDogICBB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRl aW5AZWNpdGVsZS5jb20+CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpUaGlzIGUtbWFpbCBtZXNzYWdl IGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0 aW9uIHdoaWNoIGlzCkNPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRv IEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzCnRyYW5zbWlzc2lvbiBpbiBl cnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4g ZGVsZXRlIHRoZSBvcmlnaW5hbAphbmQgYWxsIGNvcGllcyB0aGVyZW9mLgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwoKVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRl ZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBp cyAKQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVj b20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgCnRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxl YXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRo ZSBvcmlnaW5hbCAKYW5kIGFsbCBjb3BpZXMgdGhlcmVvZi4KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCg== --_000_AM0PR03MB3828866508FC9A2FD28175319D540AM0PR03MB3828eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+CjxtZXRhIG5hbWU9IkdlbmVyYXRvciIg Y29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPgo8c3R5bGU+PCEt LQovKiBGb250IERlZmluaXRpb25zICovCkBmb250LWZhY2UKCXtmb250LWZhbWlseToiQ2FtYnJp YSBNYXRoIjsKCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQpAZm9udC1mYWNlCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsKCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30KQGZvbnQt ZmFjZQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIg NDt9CkBmb250LWZhY2UKCXtmb250LWZhbWlseToiQ291cmllciBOZXcgXDtjb2xvclw6YmxhY2si OwoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9Ci8qIFN0eWxlIERlZmluaXRpb25zICov CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwKCXttYXJnaW46MGNtOwoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0OwoJZm9udC1zaXplOjExLjBwdDsKCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOwoJY29sb3I6YmxhY2s7fQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6IzA1NjNDMTsKCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQKCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjojOTU0RjcyOwoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9CnAKCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsKCW1hcmdpbi1yaWdodDowY207Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsKCW1h cmdpbi1sZWZ0OjBjbTsKCWZvbnQtc2l6ZToxMi4wcHQ7Cglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjsKCWNvbG9yOmJsYWNrO30KcHJlCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 OwoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOwoJbWFyZ2luOjBjbTsK CW1hcmdpbi1ib3R0b206LjAwMDFwdDsKCWZvbnQtc2l6ZToxMC4wcHQ7Cglmb250LWZhbWlseToi Q291cmllciBOZXciLHNlcmlmOwoJY29sb3I6YmxhY2s7fQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoCgl7bXNvLXN0eWxlLXByaW9y aXR5OjM0OwoJbWFyZ2luLXRvcDowY207CgltYXJnaW4tcmlnaHQ6MGNtOwoJbWFyZ2luLWJvdHRv bTowY207CgltYXJnaW4tbGVmdDozNi4wcHQ7CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cglmb250 LXNpemU6MTEuMHB0OwoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7Cgljb2xvcjpi bGFjazt9CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDAKCXttc28t c3R5bGUtbmFtZTptc29ub3JtYWw7Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsKCW1hcmdpbi1yaWdodDowY207Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsKCW1hcmdpbi1sZWZ0OjBjbTsKCWZvbnQtc2l6ZToxMi4wcHQ7Cglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjsKCWNvbG9yOmJsYWNrO30Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcgoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsKCW1zby1z dHlsZS1wcmlvcml0eTo5OTsKCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7Cglm b250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30Kc3Bhbi5FbWFpbFN0eWxlMjIKCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOwoJ Y29sb3I6d2luZG93dGV4dDt9CnNwYW4uaWNvbgoJe21zby1zdHlsZS1uYW1lOmljb247fQpzcGFu LkVtYWlsU3R5bGUyNQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5OwoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7Cgljb2xvcjojMUY0OTdEO30KLk1zb0NocERlZmF1bHQK CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsKCWZvbnQtc2l6ZToxMC4wcHQ7fQpAcGFnZSBX b3JkU2VjdGlvbjEKCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsKCW1hcmdpbjo3Mi4wcHQgOTAuMHB0 IDcyLjBwdCA5MC4wcHQ7fQpkaXYuV29yZFNlY3Rpb24xCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQov KiBMaXN0IERlZmluaXRpb25zICovCkBsaXN0IGwwCgl7bXNvLWxpc3QtaWQ6ODY3NzE1MzQ0OwoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTkwODgxMDQ5NCAy MzkzODcwOTIgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2 OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQpAbGlzdCBsMDpsZXZlbDEKCXttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsKCW1hcmdpbi1sZWZ0 OjM5Ljc1cHQ7Cgl0ZXh0LWluZGVudDotMTguMHB0O30KQGxpc3QgbDA6bGV2ZWwyCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsK CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsKCW1hcmdpbi1sZWZ0Ojc1Ljc1cHQ7Cgl0 ZXh0LWluZGVudDotMTguMHB0O30KQGxpc3QgbDA6bGV2ZWwzCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6cm9tYW4tbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246cmlnaHQ7CgltYXJnaW4tbGVmdDoxMTEuNzVwdDsKCXRleHQtaW5kZW50 Oi05LjBwdDt9CkBsaXN0IGwwOmxldmVsNAoJe21zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJbWFyZ2luLWxlZnQ6MTQ3Ljc1cHQ7Cgl0ZXh0 LWluZGVudDotMTguMHB0O30KQGxpc3QgbDA6bGV2ZWw1Cgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YWxwaGEtbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsKCW1hcmdpbi1sZWZ0OjE4My43NXB0OwoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9CkBsaXN0IGwwOmxldmVsNgoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxv d2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0OwoJbWFyZ2luLWxlZnQ6MjE5Ljc1cHQ7Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQpAbGlz dCBsMDpsZXZlbDcKCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsKCW1hcmdpbi1sZWZ0OjI1NS43NXB0OwoJdGV4dC1pbmRlbnQ6LTE4LjBw dDt9CkBsaXN0IGwwOmxldmVsOAoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2Vy OwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7CgltYXJnaW4tbGVmdDoyOTEuNzVwdDsKCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBs MDpsZXZlbDkKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsKCW1zby1sZXZl bC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsKCW1hcmdp bi1sZWZ0OjMyNy43NXB0OwoJdGV4dC1pbmRlbnQ6LTkuMHB0O30KQGxpc3QgbDEKCXttc28tbGlz dC1pZDoxODU3OTY0MzE1OwoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7Cgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6LTE5NjUyNjIyMzYgMjM5Mzg3MDkyIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3 Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30KQGxpc3QgbDE6bGV2 ZWwxCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7CgltYXJnaW4tbGVmdDozOS43NXB0OwoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9CkBsaXN0 IGwxOmxldmVsMgoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOwoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0 LWluZGVudDotMTguMHB0O30KQGxpc3QgbDE6bGV2ZWwzCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6cm9tYW4tbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246cmlnaHQ7Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQpAbGlzdCBsMTpsZXZlbDQK CXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsKCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMTpsZXZlbDUKCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsKCW1zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9CkBsaXN0IGwx OmxldmVsNgoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOwoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0OwoJdGV4dC1p bmRlbnQ6LTkuMHB0O30KQGxpc3QgbDE6bGV2ZWw3Cgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotMTguMHB0O30K QGxpc3QgbDE6bGV2ZWw4Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7Cglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsK CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMTpsZXZlbDkKCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpyb21hbi1sb3dlcjsKCW1zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpyaWdodDsKCXRleHQtaW5kZW50Oi05LjBwdDt9Cm9sCgl7bWFyZ2lu LWJvdHRvbTowY207fQp1bAoJe21hcmdpbi1ib3R0b206MGNtO30KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+CjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4KPC9oZWFkPgo8Ym9keSBiZ2NvbG9y PSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPkFobWVkLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkxvdHMgb2YgdGhhbmtzIGZvciBh IHZlcnkgZW5jb3VyYWdpbmcgYW5kIGNvb3BlcmF0aXZlIHJlc3BvbnNlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgY2hlY2tlZCB0aGUgLTE5IHZlcnNpb24gd2l0aCByZWdh cmQgdG8gdGhlIGlzc3VlcyBJ4oCZdmUgcmFpc2VkIGluIG15IFJURy1ESVIgTGFzdCBDYWxsIHJl dmlldywgYW5kIGhlcmUgaXMgdGhlIHN1bW1hcnkgc3RhdHVzOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPHRhYmxlIGNsYXNzPSJNc29UYWJsZUdyaWQiIGJvcmRl cj0iMSIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBzdHlsZT0iYm9yZGVyLWNvbGxh cHNlOmNvbGxhcHNlO2JvcmRlcjpub25lIj4KPHRib2R5Pgo8dHI+Cjx0ZCB3aWR0aD0iMzExIiB2 YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjI3Ni4wNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0 IDEuMHB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdCI+CjxwIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PGI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPklzc3VlL05pdCByYWlzZWQgaW4gcmV2aWV3IG9mIHRoZSAtMTggdmVy c2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+CjwvdGQ+Cjx0ZCB3aWR0aD0iMTQ3IiB2YWxp Z249InRvcCIgc3R5bGU9IndpZHRoOjEyNy41NXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEu MHB0O2JvcmRlci1sZWZ0Om5vbmU7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0Ij4KPHAgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48 Yj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+U3RhdHVzIGluIHRoZSAtMTkgdmVyc2lvbjxv OnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+CjwvdGQ+Cjx0ZCB3aWR0aD0iMjQ5IiB2YWxpZ249InRv cCIgc3R5bGU9IndpZHRoOjIxOS43cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9y ZGVyLWxlZnQ6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQiPgo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Db21tZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+ CjwvdGQ+CjwvdHI+Cjx0cj4KPHRkIHdpZHRoPSIzMTEiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lk dGg6Mjc2LjA1cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXRvcDpub25l O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdCI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5DaGVjayBvZiB0aGUgcHJlZml4IGFkdmVydGlzZWQgYXMg YSBOb2RlIFNJRCBiZWluZyBvd25lZCBieSBtb3JlIHRoYW4gb25lIHJvdXRlciBpbiB0aGUgZG9t YWluIGlzIE9QVElPTkFMUjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPC90ZD4KPHRkIHdpZHRoPSIx NDciIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTI3LjU1cHQ7Ym9yZGVyLXRvcDpub25lO2Jv cmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRl ci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRw dCI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5SZXNv bHZlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPC90ZD4KPHRkIHdpZHRoPSIyNDkiIHZhbGlnbj0i dG9wIiBzdHlsZT0id2lkdGg6MjE5LjdwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9u ZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlk IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0Ij4KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZSByZXF1aXJlbWVudCBs ZXZlbCBmb3Igc3VjaCBhIGNoZWNrIGhhcyBiZWVuIGNoYW5nZWQgZnJvbSBNQVkgdG8gU0hPVUxE PG86cD48L286cD48L3NwYW4+PC9wPgo8L3RkPgo8L3RyPgo8dHI+Cjx0ZCB3aWR0aD0iMzExIiB2 YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjI3Ni4wNXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0 IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQiPgo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VW5uZWNlc3Nhcnkg dGV4dCBkZWNsYXJpbmcgbm9uLWNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbnMgYXMgZmF1bHR5IGFu ZCB1c2luZyBmb3J3YXJkIHJlZmVyZW5jZXMKPG86cD48L286cD48L3NwYW4+PC9wPgo8L3RkPgo8 dGQgd2lkdGg9IjE0NyIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoxMjcuNTVwdDtib3JkZXIt dG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQg MS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS40 cHQgMGNtIDUuNHB0Ij4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPlJlc29sdmVkPG86cD48L286cD48L3NwYW4+PC9wPgo8L3RkPgo8dGQgd2lkdGg9IjI0 OSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoyMTkuN3B0O2JvcmRlci10b3A6bm9uZTtib3Jk ZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXIt cmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQi Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VW5uZWNl c3NhcnkgdGV4dCBoYXMgYmVlbiByZW1vdmVkPG86cD48L286cD48L3NwYW4+PC9wPgo8L3RkPgo8 L3RyPgo8dHI+Cjx0ZCB3aWR0aD0iMzExIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjI3Ni4w NXB0O2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5n OjBjbSA1LjRwdCAwY20gNS40cHQiPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+SW5hY2N1cmF0ZSBzdGF0ZW1lbnQgcmVnYXJkaW5nIGFsbG9jYXRpb24g YW5kIGFkdmVydGlzZW1lbnQgb2YgbGFiZWxzIHJlcHJlc2VudGluZyBBZGotU0lEcyBieSBJR1Ag ZXh0ZW5zaW9ucyBmb3IgU1I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvdGQ+Cjx0ZCB3aWR0aD0i MTQ3IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjEyNy41NXB0O2JvcmRlci10b3A6bm9uZTti b3JkZXItbGVmdDpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3Jk ZXItcmlnaHQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40 cHQiPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVz b2x2ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvdGQ+Cjx0ZCB3aWR0aD0iMjQ5IiB2YWxpZ249 InRvcCIgc3R5bGU9IndpZHRoOjIxOS43cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5v bmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xp ZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdCI+CjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGUgY29ycmVzcG9uZGlu ZyBzdGF0ZW1lbnQgZG9lcyBub3QgbWVudGlvbiBsYWJlbCBhbGxvY2F0aW9uIGFueSBtb3JlCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4KPC90ZD4KPC90cj4KPHRyPgo8dGQgd2lkdGg9IjMxMSIgdmFs aWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDoyNzYuMDVwdDtib3JkZXI6c29saWQgd2luZG93dGV4dCAx LjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0Ij4KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk5pdDogR3JhbW1hciBp c3N1ZXMgKHNpbmd1bGFyIHZzLiBwbHVyYWwpCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPC90ZD4K PHRkIHdpZHRoPSIxNDciIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTI3LjU1cHQ7Ym9yZGVy LXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0 IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDUu NHB0IDBjbSA1LjRwdCI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5GaXhlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPC90ZD4KPHRkIHdpZHRoPSIyNDki IHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MjE5LjdwdDtib3JkZXItdG9wOm5vbmU7Ym9yZGVy LWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7Ym9yZGVyLXJp Z2h0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gNS40cHQgMGNtIDUuNHB0Ij4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkluIGFsbCBw bGFjZXMgSeKAmXZlIG1lbnRpb25lZCBhbmQgdGhlbiBpbiBzb21lIG90aGVyIG9uZXM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+CjwvdGQ+CjwvdHI+Cjx0cj4KPHRkIHdpZHRoPSIzMTEiIHZhbGlnbj0i dG9wIiBzdHlsZT0id2lkdGg6Mjc2LjA1cHQ7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7 Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdCI+CjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5OaXQ6IFJlZmVyZW5jZSBpc3N1 ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvdGQ+Cjx0ZCB3aWR0aD0iMTQ3IiB2YWxpZ249InRv cCIgc3R5bGU9IndpZHRoOjEyNy41NXB0O2JvcmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpub25l O2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQg d2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSA1LjRwdCAwY20gNS40cHQiPgo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Rml4ZWQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+CjwvdGQ+Cjx0ZCB3aWR0aD0iMjQ5IiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRo OjIxOS43cHQ7Ym9yZGVyLXRvcDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpz b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0 O3BhZGRpbmc6MGNtIDUuNHB0IDBjbSA1LjRwdCI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjwvdGQ+ CjwvdHI+CjwvdGJvZHk+CjwvdGFibGU+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5SZWdhcmRzLCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TYXNoYTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPk9mZmljZTogJiM0Mzs5NzItMzkyNjYzMDI8bzpwPjwvbzpwPjwvc3Bh bj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5D ZWxsOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOzk3Mi01NDkyNjYzMDI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5FbWFpbDombmJzcDsmbmJzcDsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVs ZS5jb208bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8 ZGl2Pgo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQiPiBBaG1lZCBCYXNoYW5keSAmbHQ7YWJhc2hhbmR5LmlldGZAZ21h aWwuY29tJmd0Owo8YnI+CjxiPlNlbnQ6PC9iPiBGcmlkYXksIE1hcmNoIDI5LCAyMDE5IDQ6MTQg QU08YnI+CjxiPlRvOjwvYj4gQWxleGFuZGVyIFZhaW5zaHRlaW4gJmx0O0FsZXhhbmRlci5WYWlu c2h0ZWluQGVjaXRlbGUuY29tJmd0OzsgcnRnLWFkc0BpZXRmLm9yZzxicj4KPGI+Q2M6PC9iPiBy dGctZGlyQGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0LWll dGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLmF1dGhvcnNAaWV0Zi5vcmc7IE1pbiBZZSAm bHQ7YW15LnllbWluQGh1YXdlaS5jb20mZ3Q7PGJyPgo8Yj5TdWJqZWN0OjwvYj4gUmU6IFJURy1E SVIgTGFzdCBDYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmct bXBscy0xODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+CjwvZGl2Pgo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPHA+VGhhbmtzIGEgbG90IGZvciB0aGUgcmV2 aWV3PG86cD48L286cD48L3A+CjxwPkkgdXBsb2FkZWQgdmVyc2lvbiAxOSBvZiB0aGUgZHJhZnQs IHdoaWNoLCBJTU8sIGFkZHJlc3NlcyBhbGwgeW91ciBjb21tZW50czxvOnA+PC9vOnA+PC9wPgo8 cD5TZWUgdGhlIHJlcGx5ICZxdW90OyNBaG1lZCZxdW90OzxvOnA+PC9vOnA+PC9wPgo8ZGl2Pgo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAzLzEwLzE5IDk6NTUgQU0sIEFsZXhhbmRlciBWYWluc2h0 ZWluIHdyb3RlOjxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+CjxwPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+SGVs bG8sIDwvc3Bhbj4KPG86cD48L286cD48L3A+CjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+SSBoYXZlIGJl ZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMg ZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGlu ZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFz dCBjYWxsIGFuZAogSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0 LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0 aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERp cmVjdG9yYXRlLCBwbGVhc2Ugc2VlCjxhIGhyZWY9Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3Jn L2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXIiPjxzcGFuIGNsYXNzPSJpY29uIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojQkIwMDAw O3RleHQtZGVjb3JhdGlvbjpub25lIj7igIs8L3NwYW4+PC9zcGFuPmh0dHA6Ly90cmFjLnRvb2xz LmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXI8L2E+Cjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5BbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJp bWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1 bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJRVRGIExh c3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlCiB0byByZXNvbHZl IHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFmdC4gPC9zcGFu PjxvOnA+PC9vOnA+PC9wPgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPkRvY3VtZW50OiA8L3NwYW4+Cjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+cmV2aWV3IG9mIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1t cGxzLTE4PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+PGJyPgpSZXZpZXdlcjogQWxleGFuZGVyICji gJxTYXNoYeKAnSkgVmFpbnNodGVpbjxicj4KUmV2aWV3IERhdGU6IDEwLU1hci0xOTxicj4KSUVU RiBMQyBFbmQgRGF0ZTogMDctTWFyLTIwMTk8YnI+CkludGVuZGVkIFN0YXR1czogPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0 ZSI+UHJvcG9zZWQgU3RhbmRhcmQ8L3NwYW4+PG86cD48L286cD48L3A+CjxwPjxzdHJvbmc+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OyxzYW5zLXNlcmlmIj5TdW1tYXJ5Ojwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPiBJ IGhhdmUgc29tZSBtaW5vciBjb25jZXJucyBhYm91dCB0aGlzIGRvY3VtZW50IHRoYXQgSSB0aGlu ayBzaG91bGQgYmUgcmVzb2x2ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4KPHA+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5Db21tZW50czwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z LXNlcmlmIj46Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5JIGhh dmUgZG9uZSBhbiBlYXJseSBSVEctRElSIHJldmlldyBvZiB0aGUgLTE0IHZlcnNpb24gb2YgdGhl IGRyYWZ0IGhhbGYgYSB5ZWFyIGFnbywgYW5kIHRoZSBpc3N1ZXMgSeKAmXZlIHJhaXNlZCB0aGVu IGhhdmUgYmVlbiByZXNvbHZlZCBpbiB0aGUgc3Vic2VxdWVudCB2ZXJzaW9ucyBvbmUgd2F5IG9y IGFub3RoZXIpLiBUaGVyZWZvcmUKIHRoaXMgcmV2aWV3IGhhcyBiZWVuIGludGVudGlvbmFsbHkg Zm9jdXNlZCBvbiB0aGUgY2hhbmdlcyBkb25lIHRvIHRoZSBkcmFmdCBpbiB0aGUgZmV3IHJlY2Vu dCB2ZXJzaW9ucy4KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8cD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPklu IG15IHByZXZpb3VzIHJldmlldyBJIGhhdmUgbm90aWNlZCB0aGF0IHRoZSBkcmFmdCB3YXMgbm90 IGVhc3kgcmVhZGluZyBmb3IgbWUuIFNpbmNlIHRoZW4gcmVhZGFiaWxpdHkgb2YgdGhlIGRyYWZ0 IGhhcyBiZWVuIGltcHJvdmVkLiBIb3dldmVyLCB0aGVyZSBhcmUgc3RpbGwgc2V2ZXJhbCBwbGFj ZXMgaW4gdGhlIG5ldyB0ZXh0CiB0aGF0IGFyZSBzdGlsbCBkaWZmaWN1bHQgdG8gcGFyc2UuIDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5JIGRpZCBub3QgcnVuIHRo ZSBuaXRzIGNoZWNrZXIgb24gdGhlIGRyYWZ0LCBzbyBteSBsaXN0IG9mIG5pdHMgaXMgcHJvYmFi bHkgaW5jb21wbGV0ZS48L3NwYW4+PG86cD48L286cD48L3A+CjxwPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+ SnVzdCBhcyB3aXRoIG15IGVhcmxpZXIgcmV2aWV3LCBJIHNlbmQgdGhpcyBvbmUgYWxzbyB0byB0 aGUgTVBMUyBXRyBsaXN0IOKAkyBhbmQgZm9yIHRoZSBzYW1lIHJlYXNvbnMuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPgo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPkkgdHJpZWQgdG8gZGlzY3VzcyBteSByZXZp ZXcgcHJpdmF0ZWx5IHdpdGggdGhlIGF1dGhvcnMsIGJ1dCB0aGV5IGRpZCBub3QgcmVzcG9uZC48 L3NwYW4+PG86cD48L286cD48L3A+CjxwPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+TWFqb3IgSXNzdWVz PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjogTm8gbWFqb3IgaXNzdWVzIGZvdW5kLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4KPHA+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5NaW5vciBJc3N1ZXM8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+Ogo8L3NwYW4+PG86cD48L286cD48L3A+CjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM5Ljc1cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyA8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYi PlRoZSB0ZXh0IGluIFNlY3Rpb24gMSBzdGF0ZXMgdGhhdDwvc3Bhbj4g4oCcPGI+YSBuZXR3b3Jr IG9wZXJhdG9yIFNIT1VMRCBjb25maWd1cmUgYXQgbGVhc3Qgb25lIG5vZGUgc2VnbWVudCBwZXIg cm91dGluZyBpbnN0YW5jZSwgdG9wb2xvZ3ksIGFsZ29yaXRobTwvYj7igJ0gPHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+YW5kIGNvbnRpbnVl cyB0aGF0PC9zcGFuPiDigJw8Yj5BbiBpbXBsZW1lbnRhdGlvbiBNQVkgY2hlY2sgdGhhdCBhbiBJ R1Agbm9kZS1TSUQgaXMgbm90IGFzc29jaWF0ZWQgd2l0aCBhIHByZWZpeCB0aGF0IGlzIG93bmVk IGJ5IG1vcmUgdGhhbiBvbmUgcm91dGVyIHdpdGhpbiB0aGUgc2FtZSByb3V0aW5nIGRvbWFpbiwg SWYgc28sIGl0IFNIT1VMRCBOT1QgdXNlIHRoaXMgTm9kZS1TSUQsIE1BWSB1c2UgYW5vdGhlciBv bmUgaWYgYXZhaWxhYmxlLCBhbmQgU0hPVUxEIGxvZyBhbiBlcnJvcjwvYj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj7igJ0uIFRoaXMgbG9v a3Mgc29tZXdoYXQgY29udHJvdmVyc2lhbCB0byBtZSBiZWNhdXNlOjwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPgo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3NS43NXB0O3RleHQtaW5kZW50Oi0xOC4w cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPmEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g ZGlyPSJMVFIiPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OyxzYW5zLXNlcmlmIj5UaGUgY2hlY2sgb2YgdGhlIE5vZGUgU0lEIG5vdCBiZWluZyBvd25l ZCBieSBtb3JlIHRoYW4gb25lIHJvdXRlciBpbiB0aGUgcm91dGluZyBkb21haW4gaXMgZGVmaW5l ZCBhcyBwdXJlbHkgb3B0aW9uYWwuIEFjY29yZGluZyB0byBSRkMgMjExOSwgaW1wbGVtZW50YXRp b25zIHRoYXQgY2hvb3NlIHRvIGltcGxlbWVudCBzdWNoIGEgY2hlY2sgbXVzdCBiZSBhYmxlIHRv IGludGVyb3BlcmF0ZSB3aXRoIGltcGxlbWVudGF0aW9ucyB0aGF0IGRvIG5vdCBpbXBsZW1lbnQg aXQgPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Ojc1Ljc1 cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIgbGZvMiI+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Yi48c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyA8L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSByZWNvbW1lbmRlZCBoYW5k bGluZyBvZiB0aGUgcmVzdWx0cyBvZiB0aGlzIGNoZWNrIChmdWxseSBhbGlnbmVkIHdpdGggdGhl IHRleHQgaW4gU2VjdGlvbiAzLjIgcGYgUkZDIDg0MDIgdGhhdCBwcm9oaWJpdHMgdXNpbmcgcHJl Zml4ZXMgb3duZWQgYnkgbW9yZSB0aGFuIG9uZSByb3V0ZXIgaW4gdGhlIGRvbWFpbiBhcyBOb2Rl LVNPRHMpIHN0cm9uZ2x5IHN1Z2dlc3RzIHRoYXQgdGhlIHByZWZpeCB0aGF0IGlzIG93bmVkIGJ5 IG1vcmUgdGhhbiBvbmUgcm91dGVyIGluIHRoZSBkb21haW4gaXMgdW51c2FibGUgYXMgdGhlIE5v ZGUgU0lEICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPgo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozOS43NXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OyxzYW5zLXNlcmlmIj5JIHNlZSB0d28gcG9zc2liaWxpdGllcyB0byByZXNvbHZlIHRoaXMgY29u dHJvdmVyc3k6IGVpdGhlciBtYWtlIHRoZSBjaGVjayBpbiBxdWVzdGlvbiBhIOKAnHJlYWwgcmVx dWlyZW1lbnTigJ0gKGkuZS4sIHJlcGxhY2UgPC9zcGFuPjxiPk1BWTwvYj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4gd2l0aCA8L3NwYW4+ PGI+U0hPVUxEPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LHNhbnMtc2VyaWYiPiBvciBldmVuIDwvc3Bhbj48Yj5NVVNUPC9iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPiksIG9yIGV4cGxhaW4gd2h5 IGl0IGlzIHNhZmUgZW5vdWdoIG5vdCB0byBpbXBsZW1lbnQgc3VjaCBhIGNoZWNrIChpLmUuLCBo b3cgaW1wbGVtZW50YXRpb25zIHRoYXQgc3VwcG9ydCB0aGlzIGNoZWNrIGFuZCBpbXBsZW1lbnRh dGlvbnMgdGhhdCBkbyBub3Qgc3VwcG9ydCBpdCBjYW4gaW50ZXJvcGVyYXRlIHdpdGhpbiBhIGdp dmVuIHJvdXRpbmcgZG9tYWluKTwvc3Bhbj4uIDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBmaXJzdCBvZiB0aGVzZSBvcHRpb25zIHNl ZW1zIHRvIG1lIGFsaWduZWQgd2l0aCBTZWN0aW9uIDMuMiBpbiBSRkMgODQwMiB0aGF0IHNheXMg dGhhdCDigJw8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFuIElHUCBO b2RlLVNJRCBNVVNUIE5PVCBiZSBhc3NvY2lhdGVkIHdpdGggYSBwcmVmaXggdGhhdCBpcyBvd25l ZCBieSBtb3JlIHRoYW4gb25lIHJvdXRlciB3aXRoaW4gdGhlIHNhbWUgcm91dGluZyBkb21haW48 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNh bnMtc2VyaWYiPuKAnS4gPC9zcGFuPiZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+ CjwvYmxvY2txdW90ZT4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4j QWhtZWQ6IEkgcmVwbGFjZWQgdGhlIE1BWSB3aXRoIFNIT1VMRDxicj4KPGJyPgo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM5Ljc1cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+ CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gZGlyPSJMVFIiPjwvc3Bhbj5JIGhhdmUmbmJzcDsgYSBwcm9ibGVtIHdpdGggdGhlIDxzcGFu IHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+CmhpZ2hsaWdo dGVkPC9zcGFuPiBwYXJ0IG9mIHRoZSBmb2xsb3dpbmcgdGV4dCBpbiBTZWN0aW9uIDIuNTo8bzpw PjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsKPC9zcGFuPjxiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+QW4g aW1wbGVtZW50YXRpb24gTVVTVCBOT1QgYWxsb3cgdGhlIE1DQ3MgYmVsb25naW5nIHRvIHRoZSBz YW1lPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjE4LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsgcm91dGVyIHRvIGFzc2lnbiB0aGUg c2FtZSBpbmNvbWluZyBsYWJlbCB0byBtb3JlIHRoYW4gb25lIFNSIEZFQy4KPHNwYW4gc3R5bGU9 ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij5Bbjwvc3Bhbj48L3NwYW4+ PC9iPjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MTguMHB0Ij48Yj4mbmJzcDsmbmJzcDsgaW1wbGVtZW50YXRpb24gdGhhdCBhbGxvd3Mgc3Vj aCBiZWhhdmlvciBpcyBjb25zaWRlcmVkIGFzIGZhdWx0eS48L2I+PG86cD48L286cD48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPjxiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5i c3A7CjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+ UHJvY2VkdXJlcyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgZXF1YWxseSBhcHBsaWVzIHRvIHRo aXMgY2FzZSw8L3NwYW4+PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+PGI+Jm5ic3A7Jm5ic3A7IGJvdGggZm9y IGluY29taW5nIGxhYmVsIGNvbGxpc2lvbiAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLTE4I3NlY3Rpb24t Mi41Ij48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ U2VjdGlvbiAyLjU8L3NwYW4+PC9hPikKIGFuZCB0aGUgZWZmZWN0IG9uPC9iPjxvOnA+PC9vOnA+ PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij48Yj4m bmJzcDsmbmJzcDsgb3V0Z29pbmcgbGFiZWwgcHJvZ3JhbW1pbmcgKDxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBs cy0xOCNzZWN0aW9uLTIuNiI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPlNlY3Rpb24gMi42PC9zcGFuPjwvYT4pLjwvYj48bzpwPjwvbzpwPjwvcD4K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzUuNzVwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1s aXN0OmwwIGxldmVsMiBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj5hLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRS Ij48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fu cy1zZXJpZiI+VGhlIFNlY3Rpb24gaW4gcXVlc3Rpb24gZGVhbHMgd2l0aCBpbmNvbWluZyBsYWJl bCBjb2xsaXNpb24gKGluIGZhY3QsIHRoZSB0ZXh0IHRoYXQgaW1tZWRpYXRlbHkgZm9sbG93cyB0 aGUgcHJvYmxlbWF0aWMgZnJhZ21lbnQgc3RhdGVzIHRoYXQg4oCcPC9zcGFuPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGUgb2JqZWN0aXZlIG9mIHRoZSBmb2xsb3dpbmcgc3Rl cHMgaXMgdG8gZGV0ZXJtaW5pc3RpY2FsbHkgaW5zdGFsbCBpbiB0aGUgTVBMUyBJbmNvbWluZyBM YWJlbCBNYXAsIGFsc28ga25vd24gYXMgbGFiZWwgRklCLCBhIHNpbmdsZSBGRUMgd2l0aCB0aGUg aW5jb21pbmcgbGFiZWwgJnF1b3Q7TDEmcXVvdDs8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPuKAnSA8L3NwYW4+PG86cD48 L286cD48L3ByZT4KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzUuNzVwdDt0ZXh0LWluZGVudDot MTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5iLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIGRpcj0iTFRSIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssc2Fucy1zZXJpZiI+QXMgYSBjb25zZXF1ZW5jZSwgYW55IG1lbnRpb24gb2YmbmJz cDsgPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5vdXRnb2luZyBsYWJl bCBwcm9ncmFtbWluZzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+LCBsb29rcyBvdXQgb2YgY29udGV4dCAoZXZlbiBhY2Nv bXBhbmllZCBieSBhIGZvcndhcmQgcmVmZXJlbmNlIHRvIFNlY3Rpb24gMi42KTwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPgo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3NS43NXB0O3RleHQtaW5kZW50 Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5TZWN0aW9uIDIuNiBjb3ZlcnMgdGhlIGltcGFjdCBvZiBp bmNvbWluZyBsYWJlbCBjb2xsaXNpb24gb24gcHJvZ3JhbW1pbmcgb2Ygb3V0Z29pbmcgbGFiZWxz IGluIHF1aXRlIGEgZ2VuZXJpYyB3YXkuIFRoZXJlZm9yZSBJIHRoaW5rIHRoYXQgdGhlICZuYnNw OzxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+aGln aGxpZ2h0ZWQ8L3NwYW4+IHBhcnQgb2YgdGhlIHF1b3RlZCBmcmFnbWVudCBjYW4gYmUgc2FmZWx5 IHJlbW92ZWQgKGNvbXBsZXRlIHdpdGggdGhlIGdyYW1tYXIgbWlzdGFrZSkuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Ojc1Ljc1cHQ7dGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ZC48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyA8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LHNhbnMtc2VyaWYiPkkgYWxzbyBkbyBub3Qgc2VlIGFueSB2YWx1ZSBpbiBzdGF0 aW5nIHRoYXQgYW4gaW1wbGVtZW50YXRpb25zIHRoYXQgdmlvbGF0ZXMgYSBtYW5kYXRvcnkgcmVx dWlyZW1lbnQgb2YgdGhlIHNwZWMgaXMgZmF1bHR5IOKAkyBpc27igJl0IHRoYXQgc2VsZi1ldmlk ZW50Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPgo8L2Jsb2NrcXVvdGU+CjxwPiNBaG1lZDogSSBy ZW1vdmVkIHRoZSBoaWdobGlnaHRlZCB0ZXh0IGJlY2F1c2UgSSBhZ3JlZSB3aXRoIHdoYXQgeW91 IHNhaWQgaW4gaXRlbSAoZCkgdGhhdCBpdCBoYXMgbm8gdmFsdWU8bzpwPjwvbzpwPjwvcD4KPHA+ PG86cD4mbmJzcDs8L286cD48L3A+CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPgo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozOS43NXB0O3Rl eHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsgPC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgPHNwYW4gc3R5bGU9ImJhY2tncm91 bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij5oaWdobGlnaHRlZDwvc3Bhbj4gdGV4dCBp biBTZWN0aW9uIDIuOCBpcyBub3QgYWNjdXJhdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+Cjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjIxLjc1cHQiPjxiPiZuYnNwOyZuYnNwOyBGb3IgTG9jYWwg U0lEcywgdGhlIE1DQyBpcyByZXNwb25zaWJsZSBmb3IgZG93bmxvYWRpbmcgdGhlIGNvcnJlY3Q8 L2I+PG86cD48L286cD48L3ByZT4KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEuNzVwdCI+PGI+ Jm5ic3A7Jm5ic3A7IGxhYmVsIHZhbHVlIHRvIEZJQi4gRm9yIGV4YW1wbGUsIGFuIElHUCB3aXRo IFNSIGV4dGVuc2lvbnMgW0ktRC5pZXRmLTwvYj48bzpwPjwvbzpwPjwvcHJlPgo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDoyMS43NXB0Ij48Yj4mbmJzcDsmbmJzcDsgaXNpcy1zZWdtZW50LXJvdXRp bmctZXh0ZW5zaW9ucywgSS1ELmlldGYtb3NwZi1zZWdtZW50LXJvdXRpbmctPC9iPjxvOnA+PC9v OnA+PC9wcmU+CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjIxLjc1cHQiPjxiPiZuYnNwOyZuYnNw OyBleHRlbnNpb25zXSA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdo dDp5ZWxsb3ciPmFsbG9jYXRlczwvc3Bhbj4gYW5kIGRvd25sb2FkcyB0aGUgTVBMUyBsYWJlbCBj b3JyZXNwb25kaW5nIHRvPC9iPjxvOnA+PC9vOnA+PC9wcmU+CjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0OjIxLjc1cHQiPjxiPiZuYnNwOyZuYnNwOyBhbiBBZGotU0lEIFs8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODQwMiIgdGl0bGU9IiZxdW90O1NlZ21lbnQgUm91dGlu ZyBBcmNoaXRlY3R1cmUmcXVvdDsiPlJGQzg0MDI8L2E+XS48L2I+PG86cD48L286cD48L3ByZT4K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzUuNzVwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1s aXN0OmwwIGxldmVsMiBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj5hLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRS Ij48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fu cy1zZXJpZiI+SUdQIHdpdGggU1IgZXh0ZW5zaW9uczwvc3Bhbj48Yj4gPC9iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPm1heSBpbmRlZWQg ZHluYW1pY2FsbHkgYWxsb2NhdGUgYW5kIGRvd25sb2FkIE1QTFMgbGFiZWxzIGFjdGluZyBhcyBs b2NhbCBBZGotU0lEcyA8L3NwYW4+PG86cD48L286cD48L3ByZT4KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6NzUuNzVwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8y Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5iLjxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+SG93ZXZlciwg dGhlc2UgbGFiZWxzIGNhbiBiZSBhbGxvY2F0ZWQgYnkgY29uZmlndXJhdGlvbiAoZS5nLiBhcyBt ZW50aW9uZWQgaW4gdGhlIHRpZS1icmVha2luZyBydWxlcyBpbiBTZWN0aW9uIDIuNS4xIGFuZCBp biB0aGUgZXhhbXBsZSBpbiBTZWN0aW9uIEEuMi4zIGluIHRoZSBkcmFmdCksIGluIHdoaWNoIGNh c2UgSUdQIHdpdGggU1IgZXh0ZW5zaW9ucyB3b3VsZCBvbmx5IHJlc3BvbnNpYmxlIGZvciBpdHMg YWR2ZXJ0aXNlbWVudCBhbmQgaW5zdGFsbGF0aW9uLiA8L3NwYW4+PG86cD48L286cD48L3ByZT4K PC9ibG9ja3F1b3RlPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiNB aG1lZDogSSByZW1vdmVkIHRoZSBoaWdobGlnaHRlZCB3b3JkICZxdW90O2FsbG9jYXRlZCZxdW90 Owo8YnI+Cjxicj4KPG86cD48L286cD48L3NwYW4+PC9wPgo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3ByZT4KPHByZT48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5OSVRTPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj46PC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss c2Fucy1zZXJpZiI+IDo8L3NwYW4+PG86cD48L286cD48L3ByZT4KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzkuNzVwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm80 Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+SW4gc2VjdGlv biAyLjU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Ojcy LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMiBsZm80Ij48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5hLjxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7IDwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+SW4gdGhlIHNlbnRlbmNlIOKA nDwvc3Bhbj48Yj5Qcm9jZWR1cmVzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBlcXVhbGx5IGFw cGxpZXMgdG8gdGhpcyBjYXNlPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LHNhbnMtc2VyaWYiPuKAnSB0aGUgbm91biBpcyBpbiBwbHVyYWwgYnV0IHRoZSB2 ZXJiIGlzIGluIHNpbmd1bGFyLiAoSWYgdGhpcyBzZW50ZW5jZSBpcyByZW1vdmVkIGFzIHN1Z2dl c3RlZCBhYm92ZSwgdGhpcyBuaXQgZGlzYXBwZWFycyk8L3NwYW4+PG86cD48L286cD48L3ByZT4K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxp c3Q6bDEgbGV2ZWwyIGxmbzQiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPmIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIi Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z LXNlcmlmIj5UaGUgc2FtZSBwcm9ibGVtIGV4aXN0cyBpbiB0aGUgc2VudGVuY2Ug4oCcPC9zcGFu PjxiPkFuIGluY29taW5nIGxhYmVsIGNvbGxpc2lvbiBvY2N1cnMgaWYgdGhlIFNJRHMgb2YgdGhl IHNldCBvZiBGRUNzIHtGRUMxLCBGRUMyLC4uLiwgRkVDa30gbWFwcyB0byB0aGUgc2FtZSBpbmNv bWluZyBTUiBNUExTIGxhYmVsICZxdW90O0wxJnF1b3Q7PC9iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPuKAnTwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPgo8L2Jsb2NrcXVvdGU+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZiI+I0FobWVkOiBUaGUgc2VudGVuY2UgaXMgcmVtb3ZlZCBhcyB5b3Ugc3VnZ2VzdGVkPGJy Pgo8YnI+CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzkuNzVwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0 OmwxIGxldmVsMSBsZm80Ij4KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPkluIHNlY3Rpb24gMi4xMC4xIHRo ZSBwcmVwb3NpdGlvbiDigJw8Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDssc2VyaWYiPnRvPC9zcGFuPjwvYj7igJ0gYmV0d2VlbiB0aGUgd29yZHMg4oCc PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm Ij5hY2NvcmRpbmc8L3NwYW4+PC9iPuKAnSBhbmQg4oCcPGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj5NUExTPC9zcGFuPjwvYj7igJ0KIGlz IG1pc3NpbmcgaW4gdGhlIGZyYWdtZW50IOKAnDxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+UHVzaCB0aGUgY2FsY3VsYXRlZCBsYWJlbCBh Y2NvcmRpbmcgdGhlIE1QTFMgbGFiZWwgcHVzaGluZyBydWxlcyBzcGVjaWZpZWQgaW4gW1JGQzMw MzJdPC9zcGFuPjwvYj7igJ0uPG86cD48L286cD48L3A+CjwvYmxvY2txdW90ZT4KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4jQWhtZWQgYWRkZWQgdGhlIG1pc3Npbmcg JnF1b3Q7dG8mcXVvdDs8YnI+Cjxicj4KPG86cD48L286cD48L3NwYW4+PC9wPgo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDozOS43NXB0O3RleHQtaW5kZW50 Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzQiPgo8IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Cjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+UHJv YmxlbXMgd2l0aCByZWZlcmVuY2VzOjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21z by1saXN0OmwxIGxldmVsMiBsZm80Ij4KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+YS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxhIGhyZWY9Imh0dHBz Oi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL0NfVzNLQmNMMkFXeG1sQjdT cDUzX1B2cWJRQSI+QXMgcmVwb3J0ZWQgYnkgU2VyZ2V5PC9hPiwgdGhlcmUgYXJlIHR3byBvY2N1 cnJlbmNlcyBvZiByZWZlcmVuY2VzIHRvIFJGQyA4MDQyIOKAnE9TUEYgVHdvLVBhcnQgTWV0cmlj 4oCdIGluc3RlYWQgb2YgUkZDIDg0MDIuIExvdHMKIG9mIHRoYW5rcyB0byBTZXJnZXkgZm9yIGNh dGNoaW5nIHRoaXM8bzpwPjwvbzpwPjwvcD4KPC9ibG9ja3F1b3RlPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiNBaG1lZDogQ29ycmVjdGVkLCB0aGFua3MgYWdhaW48 YnI+Cjxicj4KPG86cD48L286cD48L3NwYW4+PC9wPgo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlz dDpsMSBsZXZlbDIgbGZvNCI+CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPmIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj5SZWZlcmVuY2UgdG8gUkZDIDgx NzQgbWlzdGFrZW5seSBjb250YWlucyBhIGxpbmsgdG8mbmJzcDsgUkZDIDcyNzQuPG86cD48L286 cD48L3A+CjwvYmxvY2txdW90ZT4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmIj4jQWhtZWQ6IENvcnJlY3RlZDxicj4KPGJyPgo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+Cjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPgo8 cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LHNhbnMtc2VyaWYiPkhvcGVmdWxseSB0aGVzZSBub3RlcyB3aWxsIGJlIHVzZWZ1bC48 L3NwYW4+PG86cD48L286cD48L3A+CjwvYmxvY2txdW90ZT4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LHNlcmlmIj4jQWhtZWQ6IFZFUlkgdXNlZnVsPGJyPgo8YnI+CjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48 L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNhc2hhPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PZmZp Y2U6ICYjNDM7OTcyLTM5MjY2MzAyPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwi PkNlbGw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7OTcyLTU0OTI2NjMwMjxv OnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FbWFpbDombmJzcDsmbmJzcDsgPGEg aHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIj5BbGV4YW5kZXIu VmFpbnNodGVpbkBlY2l0ZWxlLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyxzZXJpZiI+PGJyIGNsZWFyPSJhbGwiPgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Cjxicj4K VGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFu ZCBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBpcwo8YnI+CkNPTkZJREVOVElBTCBhbmQgd2hp Y2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzCjxicj4KdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5IGUt bWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsCjxicj4KYW5k IGFsbCBjb3BpZXMgdGhlcmVvZi48YnI+Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4KPC9ibG9ja3F1b3RlPgo8L2Rpdj4KPGJyIGNsZWFyPSJib3RoIj4KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPEJSPgo8QlI+ClRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRo ZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggaXMgPEJSPgpD T05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyA8QlI+CnRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxl YXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRo ZSBvcmlnaW5hbCA8QlI+CmFuZCBhbGwgY29waWVzIHRoZXJlb2YuPEJSPgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188QlI+CjwvYm9keT4KPC9odG1sPgoK --_000_AM0PR03MB3828866508FC9A2FD28175319D540AM0PR03MB3828eurp_-- From nobody Sun Mar 31 01:08:35 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543ED1201BA for ; Sun, 31 Mar 2019 01:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.491 X-Spam-Level: X-Spam-Status: No, score=-17.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 dAEVHpx5AG8X for ; Sun, 31 Mar 2019 01:08:29 -0700 (PDT) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 EE54312017C for ; Sun, 31 Mar 2019 01:08:28 -0700 (PDT) Received: by mail-it1-x130.google.com with SMTP id v8so14696347itf.0 for ; Sun, 31 Mar 2019 01:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c98WoPsiRfMxMKCYugSlj9JyYG7pccgrbdYyo8qkZd4=; b=fbPpijSE/hE2LBTYqe9aezYhgKQ9+gGY+oc+R5MpC/rWa9KPKGMhWYLFr1X669hgBI P0gF8YqYO6Vv1MmbdG6t5jFkdLGREyXPWxZ5mKU/Hy59GsbbDkRp2VEP/PxIX59PWxA+ MTa4iygCtRsrvDdrfxdFmJu8YLcHZkMFF8/Kj/YKZLLw/isto8d72yTx+XHwOgIjYGma +6ARi5kWLvo/7UJLzhYi8z7Hh93oCWGPNHdyUHPtBlKfEfxzNTQiiBbydaF0wTohNgzb i6/l7gBhgUgkdPtGSHJeAqdsh2Tc23YUrHfeP1JNh7YRIW1KkoXxQJN9RPcZ9pq8fnKQ KMkg== 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=c98WoPsiRfMxMKCYugSlj9JyYG7pccgrbdYyo8qkZd4=; b=aaKFK2nE/cKeKgy7t98q9bxTi7IUAlrZmn73ksxasNbPJ1zsSq8V/QBqLHWB5/aofZ eOdm1bxUeyYsS6i8STAb/WvdCateYdGFq3JWqoVO+0s/jEb0PmCw6GboH21jzwUrwN5b kJQkiAjJdgvBqdlbNKFTXAYXKVgaNvfr3He1Ibrxx+Ia7gbY0ChfLk9B6rpnyWXUaa72 BRpxEYzzd/AsY0c2U99bCbxRu7cZqeD1H/54cxfRTtR+t3ZcBGha3pCZT5RFIikqSStE QXd8F/NxXEu1vgFuUacKvJLiNQ5Wm9J+Y1K7eounrjb5e9PJihpTZ5Jn+u1rmXhPijnd 0jGQ== X-Gm-Message-State: APjAAAXUKfbBSNKnD5VTt2/Z1mMhFiWPi2+EsRCbZAHLLJ0W9CXOXbcg 5cWLH6mtGYsE2ehxOjULwUDuzdWiC+Y+nYMYCRyvbQ== X-Google-Smtp-Source: APXvYqxgIvigE/HslNuIGHFNvWnnMcHJBCv0B7SndMxBvLAJZDOFRho7KHzh+T1T17Gw7zGYnT4nnxVEf+edLxkP4Cc= X-Received: by 2002:a24:7c52:: with SMTP id a79mr3531970itd.51.1554019707793; Sun, 31 Mar 2019 01:08:27 -0700 (PDT) MIME-Version: 1.0 References: <65361777-db63-9a7a-9199-dd04425b4785@gmail.com> In-Reply-To: From: Przemyslaw Krol Date: Sun, 31 Mar 2019 10:07:50 +0200 Message-ID: To: Alexander Vainshtein Cc: Ahmed Bashandy , "rtg-dir@ietf.org" , "spring@ietf.org" , Min Ye , "mpls@ietf.org" , "rtg-ads@ietf.org" , "draft-ietf-spring-segment-routing-mpls.authors@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a893bf05855f68d2" Archived-At: Subject: Re: [mpls] [spring] RTG-DIR Last Call review of draft-ietf-spring-segment-routing-mpls-18 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 08:08:33 -0000 --000000000000a893bf05855f68d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mirrored SID in Section 2.5 refers to RFC8402 section 5.1, which AFAIK is correct. What link needs to be updated? [RFC8402, Section 5.1 ] - doesn't point to RFC8402 section 5.1 thanks, On Sun, Mar 31, 2019 at 6:46 AM Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Ahmed, > > Lots of thanks for a very encouraging and cooperative response. > > > > I checked the -19 version with regard to the issues I=E2=80=99ve raised i= n my > RTG-DIR Last Call review, and here is the summary status: > > > > *Issue/Nit raised in review of the -18 version* > > *Status in the -19 version* > > *Comments* > > Check of the prefix advertised as a Node SID being owned by more than one > router in the domain is OPTIONALR > > Resolved > > The requirement level for such a check has been changed from MAY to SHOUL= D > > Unnecessary text declaring non-compliant implementations as faulty and > using forward references > > Resolved > > Unnecessary text has been removed > > Inaccurate statement regarding allocation and advertisement of labels > representing Adj-SIDs by IGP extensions for SR > > Resolved > > The corresponding statement does not mention label allocation any more > > Nit: Grammar issues (singular vs. plural) > > Fixed > > In all places I=E2=80=99ve mentioned and then in some other ones > > Nit: Reference issues > > Fixed > > > > > > > > Regards, > > Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > > *From:* Ahmed Bashandy > *Sent:* Friday, March 29, 2019 4:14 AM > *To:* Alexander Vainshtein ; > rtg-ads@ietf.org > *Cc:* rtg-dir@ietf.org; spring@ietf.org; mpls@ietf.org; > draft-ietf-spring-segment-routing-mpls.authors@ietf.org; Min Ye < > amy.yemin@huawei.com> > *Subject:* Re: RTG-DIR Last Call review of > draft-ietf-spring-segment-routing-mpls-18 > > > > Thanks a lot for the review > > I uploaded version 19 of the draft, which, IMO, addresses all your commen= ts > > See the reply "#Ahmed" > > On 3/10/19 9:55 AM, Alexander Vainshtein wrote: > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and sometimes > on special request. The purpose of the review is to provide assistance to > the Routing ADs. For more information about the Routing Directorate, plea= se > see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF Las= t > Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: review of draft-ietf-spring-segment-routing-mpls-18 > Reviewer: Alexander (=E2=80=9CSasha=E2=80=9D) Vainshtein > Review Date: 10-Mar-19 > IETF LC End Date: 07-Mar-2019 > Intended Status: Proposed Standard > > *Summary:* I have some minor concerns about this document that I think > should be resolved before publication. > > *Comments*: > > I have done an early RTG-DIR review of the -14 version of the draft half = a > year ago, and the issues I=E2=80=99ve raised then have been resolved in t= he > subsequent versions one way or another). Therefore this review has been > intentionally focused on the changes done to the draft in the few recent > versions. > > In my previous review I have noticed that the draft was not easy reading > for me. Since then readability of the draft has been improved. However, > there are still several places in the new text that are still difficult t= o > parse. > > I did not run the nits checker on the draft, so my list of nits is > probably incomplete. > > Just as with my earlier review, I send this one also to the MPLS WG list = =E2=80=93 > and for the same reasons. > > I tried to discuss my review privately with the authors, but they did not > respond. > > *Major Issues*: No major issues found. > > *Minor Issues*: > > 1. The text in Section 1 states that =E2=80=9C*a network operator SHOULD= configure at least one node segment per routing instance, topology, algori= thm*=E2=80=9D and continues that =E2=80=9C*An implementation MAY check that= an IGP node-SID is not associated with a prefix that is owned by more than= one router within the same routing domain, If so, it SHOULD NOT use this N= ode-SID, MAY use another one if available, and SHOULD log an error*=E2=80= =9D. This looks somewhat controversial to me because: > > a. The check of the Node SID not being owned by more than one router in = the routing domain is defined as purely optional. According to RFC 2119, im= plementations that choose to implement such a check must be able to interop= erate with implementations that do not implement it > > b. The recommended handling of the results of this check (fully aligned = with the text in Section 3.2 pf RFC 8402 that prohibits using prefixes owne= d by more than one router in the domain as Node-SODs) strongly suggests tha= t the prefix that is owned by more than one router in the domain is unusabl= e as the Node SID > > I see two possibilities to resolve this controversy: either make the chec= k in question a =E2=80=9Creal requirement=E2=80=9D (i.e., replace *MAY* wit= h *SHOULD* or even *MUST*), or explain why it is safe enough not to impleme= nt such a check (i.e., how implementations that support this check and impl= ementations that do not support it can interoperate within a given routing = domain). The first of these options seems to me aligned with Section 3.2 in= RFC 8402 that says that =E2=80=9C*An IGP Node-SID MUST NOT be associated w= ith a prefix that is owned by more than one router within the same routing = domain*=E2=80=9D. > > #Ahmed: I replaced the MAY with SHOULD > > 2. I have a problem with the highlighted part of the following > text in Section 2.5: > > *An implementation MUST NOT allow the MCCs belonging to the same* > > * router to assign the same incoming label to more than one SR FEC. An* > > * implementation that allows such behavior is considered as faulty.* > > * Procedures defined in this document equally applies to this case,* > > * both for incoming label collision (Section 2.5 > ) > and the effect on* > > * outgoing label programming (Section 2.6 > ).* > > a. The Section in question deals with incoming label collision (in fact,= the text that immediately follows the problematic fragment states that =E2= =80=9C*The objective of the following steps is to deterministically install= in the MPLS Incoming Label Map, also known as label FIB, a single FEC with= the incoming label "L1"*=E2=80=9D > > b. As a consequence, any mention of *outgoing label programming*, looks= out of context (even accompanied by a forward reference to Section 2.6) > > c. Section 2.6 covers the impact of incoming label collision on programm= ing of outgoing labels in quite a generic way. Therefore I think that the = highlighted part of the quoted fragment can be safely removed (complete wit= h the grammar mistake). > > d. I also do not see any value in stating that an implementations that v= iolates a mandatory requirement of the spec is faulty =E2=80=93 isn=E2=80= =99t that self-evident? > > #Ahmed: I removed the highlighted text because I agree with what you said > in item (d) that it has no value > > > > 3. The highlighted text in Section 2.8 is not accurate: > > * For Local SIDs, the MCC is responsible for downloading the correct* > > * label value to FIB. For example, an IGP with SR extensions [I-D.ietf-= * > > * isis-segment-routing-extensions, I-D.ietf-ospf-segment-routing-* > > * extensions] allocates and downloads the MPLS label corresponding to* > > * an Adj-SID [RFC8402 ].* > > a. IGP with SR extensions may indeed dynamically allocate and download M= PLS labels acting as local Adj-SIDs > > b. However, these labels can be allocated by configuration (e.g. as ment= ioned in the tie-breaking rules in Section 2.5.1 and in the example in Sect= ion A.2.3 in the draft), in which case IGP with SR extensions would only re= sponsible for its advertisement and installation. > > #Ahmed: I removed the highlighted word "allocated" > > > > *NITS*: > > : > > 1. In section 2.5: > > a. In the sentence =E2=80=9C*Procedures defined in this document equally= applies to this case*=E2=80=9D the noun is in plural but the verb is in si= ngular. (If this sentence is removed as suggested above, this nit disappear= s) > > b. The same problem exists in the sentence =E2=80=9C*An incoming label c= ollision occurs if the SIDs of the set of FECs {FEC1, FEC2,..., FECk} maps = to the same incoming SR MPLS label "L1"*=E2=80=9D > > #Ahmed: The sentence is removed as you suggested > > 2. In section 2.10.1 the preposition =E2=80=9C*to*=E2=80=9D between= the words =E2=80=9C > *according*=E2=80=9D and =E2=80=9C*MPLS*=E2=80=9D is missing in the fragm= ent =E2=80=9C*Push the > calculated label according the MPLS label pushing rules specified in > [RFC3032]*=E2=80=9D. > > #Ahmed added the missing "to" > > 3. Problems with references: > > a. As reported by Sergey > , > there are two occurrences of references to RFC 8042 =E2=80=9COSPF Two-Par= t Metric=E2=80=9D > instead of RFC 8402. Lots of thanks to Sergey for catching this > > #Ahmed: Corrected, thanks again > > b. Reference to RFC 8174 mistakenly contains a link to RFC 7274. > > #Ahmed: Corrected > > Hopefully these notes will be useful. > > #Ahmed: VERY useful > > Regards, > > Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > > > _________________________________________________________________________= __ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and then > delete the original > and all copies thereof. > _________________________________________________________________________= __ > > > _________________________________________________________________________= __ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and then > delete the original > and all copies thereof. > _________________________________________________________________________= __ > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --=20 Przemyslaw "PK" Krol | Strategic Network Engineer ing | pkrol@google.com --000000000000a893bf05855f68d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mirrored SID=C2=A0 in Section 2.5 refers to RFC8402 sectio= n 5.1, which AFAIK is correct. What link needs to be updated?=C2=A0
[RFC8402, = Section 5.1] -=C2=A0 doesn't poin= t to RFC8402 section 5.1

thanks,

On Sun, Mar 31, 2019 at 6:46 AM Ale= xander Vainshtein <A= lexander.Vainshtein@ecitele.com> wrote:

Ahmed,

Lots of thanks = for a very encouraging and cooperative response.

=C2=A0

I checked the -= 19 version with regard to the issues I=E2=80=99ve raised in my RTG-DIR Last= Call review, and here is the summary status:

=C2=A0

Issue/Nit raised in review of the -18 vers= ion

Status in the -19 version

Comments

Check of the pr= efix advertised as a Node SID being owned by more than one router in the do= main is OPTIONALR

Resolved=

The requirement= level for such a check has been changed from MAY to SHOULD

Unnecessary tex= t declaring non-compliant implementations as faulty and using forward refer= ences

Resolved=

Unnecessary tex= t has been removed

Inaccurate stat= ement regarding allocation and advertisement of labels representing Adj-SID= s by IGP extensions for SR

Resolved=

The correspondi= ng statement does not mention label allocation any more

Nit: Grammar is= sues (singular vs. plural)

Fixed=

In all places I= =E2=80=99ve mentioned and then in some other ones

Nit: Reference = issues

Fixed=

=C2=A0

=C2=A0

=C2=A0

Regards,

Sasha=

=C2=A0

Office: +972-39= 266302

Cell:=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 +972-549266302

Email:=C2=A0=C2= =A0 A= lexander.Vainshtein@ecitele.com

=C2=A0

From:= Ahmed Bashandy <abashandy.ietf@gmail.com>
Sent: Friday, March 29, 2019 4:14 AM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>; rtg-ads@ietf.org Cc: rtg-dir@ie= tf.org; spring@iet= f.org; mpls@ietf.org= ; draft-ietf-spring-segment-routing-mpls.authors@ietf= .org; Min Ye <amy.yemin@huawei.com>
Subject: Re: RTG-DIR Last Call review of draft-ietf-spring-segment-r= outing-mpls-18

=C2=A0

Thanks a lot for the review

I uploaded version 19 of the draft, which, IMO, addresses all your comme= nts

See the reply "#Ahmed"

On 3/10/19 9:55 AM, Alexander Vainshtein wrote:

Hello,

I have bee= n selected as the Routing Directorate reviewer for this draft. The Routing = Directorate seeks to review all routing or routing-related drafts as they p= ass through IETF last call and IESG review, and sometimes on special request. The purpose of the review i= s to provide assistance to the Routing ADs. For more information about the = Routing Directorate, please see =E2=80= =8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although t= hese comments are primarily for the use of the Routing ADs, it would be hel= pful if you could consider them along with any other IETF Last Call comment= s that you receive, and strive to resolve them through discussion or by updating the draft.

Document: = review = of draft-ietf-spring-segment-routing-mpls-18
Reviewer: Alexander (=E2=80=9CSasha=E2=80=9D) Vainshtein
Review Date: 10-Mar-19
IETF LC End Date: 07-Mar-2019
Intended Status: Proposed Standard

Su= mmary: I have some minor concerns about this document that I think shoul= d be resolved before publication.

Comment= s:

I have don= e an early RTG-DIR review of the -14 version of the draft half a year ago, = and the issues I=E2=80=99ve raised then have been resolved in the subsequen= t versions one way or another). Therefore this review has been intentionally focused on the changes done to the draf= t in the few recent versions.

In my prev= ious review I have noticed that the draft was not easy reading for me. Sinc= e then readability of the draft has been improved. However, there are still= several places in the new text that are still difficult to parse.

I did not = run the nits checker on the draft, so my list of nits is probably incomplet= e.

Just as wi= th my earlier review, I send this one also to the MPLS WG list =E2=80=93 an= d for the same reasons.

I tried to= discuss my review privately with the authors, but they did not respond.

Major I= ssues: No major issues found.

Minor I= ssues: 

1.=C2=A0 <=
/span>The text in Section 1 =
states that =E2=80=9Ca network operator SHOULD configure at least=
 one node segment per routing instance, topology, algorithm=E2=80=9D and continues that =E2=
=80=9CAn implementation MAY check that an IGP node-SID is not associated=
 with a prefix that is owned by more than one router within the same routin=
g domain, If so, it SHOULD NOT use this Node-SID, MAY use another one if av=
ailable, and SHOULD log an error=E2=80=9D. This looks somewhat controversial to me because:<=
u>
a.=C2=A0 <=
/span>The check of the Node =
SID not being owned by more than one router in the routing domain is define=
d as purely optional. According to RFC 2119, implementations that choose to=
 implement such a check must be able to interoperate with implementations t=
hat do not implement it 
b.=C2=A0 <=
/span>The recommended handli=
ng of the results of this check (fully aligned with the text in Section 3.2=
 pf RFC 8402 that prohibits using prefixes owned by more than one router in=
 the domain as Node-SODs) strongly suggests that the prefix that is owned b=
y more than one router in the domain is unusable as the Node SID =C2=A0
I see two possibilities to resolve this controversy: either make the=
 check in question a =E2=80=9Creal requirement=E2=80=9D (i.e., replace MAY with SHOULD or even <=
b>MUST), or explain why =
it is safe enough not to implement such a check (i.e., how implementations =
that support this check and implementations that do not support it can inte=
roperate within a given routing domain). The first of these options seems to me aligned with Sec=
tion 3.2 in RFC 8402 that says that =E2=80=9CAn IGP Node-SID MUST NOT be associated with a prefix that is own=
ed by more than one router within the same routing domain=E2=80=9D. =C2=A0=C2=A0=C2=
=A0

#Ahmed: I replaced the MAY with SHOULD

2.=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I have=C2=A0 a problem with t= he highlighted part of the following text in Section 2.5:=

=C2=A0=C2=A0 An impl= ementation MUST NOT allow the MCCs belonging to the same<= u>

=C2=A0=C2=A0 router to assign the same = incoming label to more than one SR FEC. An

=C2=A0=C2=A0 implement= ation that allows such behavior is considered as faulty.<= /p>

=C2=A0=C2=A0 Procedures defined in this document equal= ly applies to this case,

=C2=A0=C2=A0 both for = incoming label collision (Section 2.5) and the effect on

=C2=A0=C2=A0 outgoing = label programming (Section 2.6).

a.=C2=A0 <=
/span>The Section in questio=
n deals with incoming label collision (in fact, the text that immediately f=
ollows the problematic fragment states that =E2=80=9CThe objective of the following steps is to deterministi=
cally install in the MPLS Incoming Label Map, also known as label FIB, a si=
ngle FEC with the incoming label "L1"=E2=80=9D 
b.=C2=A0 <=
/span>As a consequence, any =
mention of=C2=A0 outgoing label pr=
ogramming, looks =
out of context (even accompanied by a forward reference to Section 2.6)
c.=C2=A0 <=
/span>Section 2.6 covers the=
 impact of incoming label collision on programming of outgoing labels in qu=
ite a generic way. Therefore I think that the =C2=A0highlighted part of the quoted fragment can be safely rem=
oved (complete with the grammar mistake).
d.=C2=A0 <=
/span>I also do not see any =
value in stating that an implementations that violates a mandatory requirem=
ent of the spec is faulty =E2=80=93 isn=E2=80=99t that self-evident?=

#Ahmed: I removed the highlighted text because I agree with what you sai= d in item (d) that it has no value

=C2=A0

3.=C2=A0 <=
/span>The highlighted text in Section 2.8 is not accurate:
=C2=A0=C2=A0 For Local SIDs, the MCC =
is responsible for downloading the correct
=C2=A0=C2=A0 label value to FIB. For =
example, an IGP with SR extensions [I-D.ietf-
=C2=A0=C2=A0 isis-segment-routing-ext=
ensions, I-D.ietf-ospf-segment-routing-
=C2=A0=C2=A0 extensions] allocates and downloads the MPLS label corres=
ponding to
=C2=A0=C2=A0 an Adj-SID [RFC8402].
a.=C2=A0 <=
/span>IGP with SR extensions=
 may indeed dy=
namically allocate and download MPLS labels acting as local Adj-SIDs 
b.=C2=A0 <=
/span>However, these labels =
can be allocated by configuration (e.g. as mentioned in the tie-breaking ru=
les in Section 2.5.1 and in the example in Section A.2.3 in the draft), in =
which case IGP with SR extensions would only responsible for its advertisem=
ent and installation.

#Ahmed: I removed the highlighted word "alloc= ated" 

=C2=A0=

NITS:
 :=

1.=C2=A0 <=
/span>In section 2.5:=

a.=C2=A0 In the sentence =E2=80=9C=
Procedures defined in this document equally applies to this case<=
/b>=E2=80=9D the noun is in =
plural but the verb is in singular. (If this sentence is removed as suggest=
ed above, this nit disappears)
b.=C2=A0 The same problem exists i=
n the sentence =E2=80=9CAn incoming label collision occurs if the=
 SIDs of the set of FECs {FEC1, FEC2,..., FECk} maps to the same incoming S=
R MPLS label "L1"=E2=80=9D

#Ahmed: The sentence is removed as you suggested

2.=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In section 2.10.1 the preposi= tion =E2=80=9C= to=E2=80=9D between the words =E2=80=9Caccording=E2=80=9D and =E2= =80=9CMPLS=E2=80=9D is missing in the fragment =E2=80=9CPush the calculated label according the MPLS label p= ushing rules specified in [RFC3032]=E2=80=9D.

#Ahmed added the missing "to"

3.=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Problems with references:<= /u>

a.=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A= s reported by Sergey, there are two occurrences of references to RFC 80= 42 =E2=80=9COSPF Two-Part Metric=E2=80=9D instead of RFC 8402. Lots of thanks to Sergey for catching this

#Ahmed: Corrected, thanks again

b.=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Reference to RFC 8174 mistake= nly contains a link to=C2=A0 RFC 7274.

#Ahmed: Corrected

Hopefully = these notes will be useful.

#Ahmed: VERY useful

Regards,

Sasha

=C2=A0

Office: +972-39266302

Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302

Email:=C2=A0=C2=A0 Alexander.Vainshtein@ecitele.com

=C2=A0


___________________________________________________________________________=

This e-mail message is intended for the recipient only and contains informa= tion which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have recei= ved this
transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original
and all copies thereof.
___________________________________________________________________________=


___________________________________________________________________________=

This e-mail message is intended for the recipient only and contains informa= tion which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have recei= ved this
transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original
and all copies thereof.
___________________________________________________________________________=
_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring


--
=
Przemyslaw "PK" Krol |=C2=A0Strategic Network Engineering |=C2=A0pkrol@go= ogle.com=C2=A0
=
--000000000000a893bf05855f68d2-- From nobody Sun Mar 31 04:22:26 2019 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4A81200D8; Sun, 31 Mar 2019 04:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 HD2TtVcY9Wzx; Sun, 31 Mar 2019 04:22:23 -0700 (PDT) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 9E3B71200C7; Sun, 31 Mar 2019 04:22:23 -0700 (PDT) Received: by mail-pf1-x42d.google.com with SMTP id z5so2115896pfn.3; Sun, 31 Mar 2019 04:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:cc:to:date:mime-version:message-id; bh=i/7khVZzB3X+nRCa3WXnxuq0bwA60LZ0bDYOS5ZOVZM=; b=gJubjLHQualzCfSNOGi/1cQlnd2KPcaSNR9ZJ42qA1BvjW1H7ub4cn6tmr8W8N1ZMj 2mKm17690Jwgy+WIA8xeUNqfPVXKXqNkFHdlDhC+VDroNvjgDakCd+75+vPD3L77Gi7w VDuhEWTQa+7Mybfx2/t6C9EXAD9dsv/QRLyute4erUJaPzYQHA6z1BGzbQtqMKIf/y8B sHSHn5gANtMprwV3RVnsBSy8pducUc82Tu4IR0fJRaW1jAdWvYb9Fle9Ix+kNkCAaiR5 15msWCM8ASonyVkCP+cFdDlGZyHnj8NPcXLcOnJhzG30LMMYyKPzRlACIev1mTX6KsW1 KlrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:cc:to:date:mime-version:message-id; bh=i/7khVZzB3X+nRCa3WXnxuq0bwA60LZ0bDYOS5ZOVZM=; b=mVXOi9uXm9p5yz36BAvxv8CxtSUQ0eqaU8UqFi/yStLf9REDks4bq1sfqK+9gonzQM Bzxh+UGtFpFBIIHSi3ozRR8vSMWCb/ouBNwjgsCk/ImVny6784KNoIEolLpUZYUJt4kH MDUqcQuRPWyI5cSVMb+M+CBrQXCshUN40SbSmknsYoQIkuUE2hnXxyG1Mj8HO4LVZhaP 0ktx7yHA87C+4mOnHuvcKZPaDQwz5ECBg0n3/tF9c8IKznhq0R+zfSWOS4vZ76ZQUA2D /ePjElDdC9O4iB1O5i/G1kTNZc2Ht/cnVR3vttsoE4kljOuvmKnSbI30DMZRMz56Ezzr I3Xw== X-Gm-Message-State: APjAAAXY90Y8qCiQlaUm+VVVaYzVR3J0quqr98AexK8iBKGuzXg4Gogi poRpfPkvN4kn/aFoKDiCWkIiTXJQ X-Google-Smtp-Source: APXvYqyP7TuBSVxPeQ4HMfoFYYBePe6ZZ9HYW4XHzPr2STGpOCUDy5Oa1JjN2fg7tBkBRTvp7/dTvg== X-Received: by 2002:a63:2aca:: with SMTP id q193mr55891813pgq.269.1554031342821; Sun, 31 Mar 2019 04:22:22 -0700 (PDT) Received: from localhost ([103.129.252.48]) by smtp.gmail.com with ESMTPSA id d187sm9513783pgc.43.2019.03.31.04.22.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 Mar 2019 04:22:21 -0700 (PDT) From: cheng weiqiang Cc: "mpls-chairs@ietf.org" , "draft-cheng-mpls-inband-pm-encapsulation@ietf.org" To: "mpls@ietf.org" Date: Sun, 31 Mar 2019 19:22:21 +0800 MIME-Version: 1.0 X-Priority: 3 Message-ID: <1554031337333.szqsvmannprbisthrdrl01tx@android.mail.163.com> X-CUSTOM-MAIL-MASTER-SENT-ID: MailMasterAndroid-916-1554031337383-b8b7f563-cb08-417d-8584-ade8bb41beed Content-Type: multipart/alternative; boundary="__MESSAGE_BODY_PART__1_7490550241584673422" Archived-At: Subject: [mpls] Asking for comments for draft-cheng-mpls-inband-pm-encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 11:22:25 -0000 --__MESSAGE_BODY_PART__1_7490550241584673422 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGkgR3JvdXAsIFdlIGF1dGhvcnMgcHJlc2VudGVkIHRoZSBkcmFmdC1jaGVuZy1tcGxzLWluYmFu ZC1wbS1lbmNhcHN1bGF0aW9uIGF0IHRoZSBJRVRGIDEwNCBsYXN0IHdlZWsuIEFzIGZhciBhcyBu b3csIHdlIGRpZCBub3QgcmVjZWl2ZWQgYW55IGNvbW1lbnRzIG9uIGl0LiBJbnRlbnRpb24gb2Yg dGhpcyBkcmFmdCBpcyB0byBkZWZpbmUgdGhlIGVuY2Fwc3VsYXRpb24gZm9yIE1QTFMgaW5iYW5k IHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50LCB3aGljaCBwZXJmb3JtcyBmbG93LWJhc2VkIHBhY2tl dCBsb3NzLCBkZWxheSwgYW5kIGppdHRlciBtZWFzdXJlbWVudHMgb24gbGl2ZSB0cmFmZmljLCBi eSB1c2luZyB0aGUgYWx0ZXJuYXRlLW1hcmtpbmcgbWV0aG9kIGRlZmluZWQgaW4gUkZDIDgzMjEu IFdlIGFyZSBhc2tpbmcgZm9yIG1vcmUgcmV2aWV3cyBhbmQgY29tbWVudHMgYW5kIGhvcGUgdG8g cHJvZ3Jlc3MgdGhlIGRyYWZ0LiDCoCBCZXN0IFJlZ2FyZHMsIFdlaXFpYW5nIENoZW5nIFJlc2Vh cmNoIEluc3RpdHV0ZSBvZiBDaGluYSBNb2JpbGUgRGVwYXJ0bWVudCBvZiBOZXR3b3JrIFRlY2hu b2xvZ3k= --__MESSAGE_BODY_PART__1_7490550241584673422 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWw+CjxoZWFkPgogICAgPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPgo8L2hlYWQ+Cjxib2R5Pgo8ZGl2IHN0eWxlPSJs aW5lLWhlaWdodDoxLjY7Zm9udC1mYW1pbHk6J+iLueaWuScsJ+W+rui9r+mbhem7kScsJ3NhbnMt c2VyaWYnOyI+PGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxNHB4OyI+PGZvbnQgc3R5bGU9ImNvbG9y OnJnYigwLDAsMCk7Ij5IaSBHcm91cCw8YnIvPjwvZm9udD48L2ZvbnQ+PGZvbnQgc3R5bGU9ImZv bnQtc2l6ZToxNHB4OyI+PGZvbnQgc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Ij5XZSBhdXRob3Jz IHByZXNlbnRlZCB0aGUgZHJhZnQtY2hlbmctbXBscy1pbmJhbmQtcG0tZW5jYXBzdWxhdGlvbiBh dCB0aGUgSUVURiAxMDQgbGFzdCB3ZWVrLiBBcyBmYXIgYXMgbm93LCB3ZSBkaWQgbm90IHJlY2Vp dmVkIGFueSBjb21tZW50cyBvbiBpdC48YnIvPjwvZm9udD48L2ZvbnQ+PGZvbnQgc3R5bGU9ImZv bnQtc2l6ZToxNHB4OyI+PGZvbnQgc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Ij5JbnRlbnRpb24g b2YgdGhpcyBkcmFmdCBpcyB0byBkZWZpbmUgdGhlIGVuY2Fwc3VsYXRpb24gZm9yIE1QTFMgaW5i YW5kIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50LCB3aGljaCBwZXJmb3JtcyBmbG93LWJhc2VkIHBh Y2tldCBsb3NzLCBkZWxheSwgYW5kIGppdHRlciBtZWFzdXJlbWVudHMgb24gbGl2ZSB0cmFmZmlj LCBieSB1c2luZyB0aGUgYWx0ZXJuYXRlLW1hcmtpbmcgbWV0aG9kIGRlZmluZWQgaW4gUkZDIDgz MjEuPGJyLz48L2ZvbnQ+PC9mb250Pjxmb250IHN0eWxlPSJmb250LXNpemU6MTRweDsiPjxmb250 IHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApOyI+V2UgYXJlIGFza2luZyBmb3IgbW9yZSByZXZpZXdz IGFuZCBjb21tZW50cyBhbmQgaG9wZSB0byBwcm9ncmVzcyB0aGUgZHJhZnQuPGJyLz48L2ZvbnQ+ PC9mb250Pjxmb250IHN0eWxlPSJmb250LXNpemU6MTRweDsiPjxmb250IHN0eWxlPSJjb2xvcjpy Z2IoMCwwLDApOyI+wqA8YnIvPjwvZm9udD48L2ZvbnQ+PGZvbnQgc3R5bGU9ImZvbnQtc2l6ZTox NHB4OyI+PGZvbnQgc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Ij5CZXN0IFJlZ2FyZHMsPGJyLz48 L2ZvbnQ+PC9mb250Pjxmb250IHN0eWxlPSJmb250LXNpemU6MTRweDsiPjxmb250IHN0eWxlPSJj b2xvcjpyZ2IoMCwwLDApOyI+V2VpcWlhbmcgQ2hlbmc8YnIvPjwvZm9udD48L2ZvbnQ+PGZvbnQg c3R5bGU9ImZvbnQtc2l6ZToxNHB4OyI+PGZvbnQgc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Ij5S ZXNlYXJjaCBJbnN0aXR1dGUgb2YgQ2hpbmEgTW9iaWxlPGJyLz48L2ZvbnQ+PC9mb250Pjxmb250 IHN0eWxlPSJmb250LXNpemU6MTRweDsiPjxmb250IHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApOyI+ RGVwYXJ0bWVudCBvZiBOZXR3b3JrIFRlY2hub2xvZ3k8YnIvPjwvZm9udD48L2ZvbnQ+PGJyLz48 YnIvPjwvZGl2Pgo8L2JvZHk+CjwvaHRtbD4= --__MESSAGE_BODY_PART__1_7490550241584673422--