From nobody Fri Feb 1 14:58: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 88B59130EE0; Fri, 1 Feb 2019 14:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=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 UpMk9v-yLavj; Fri, 1 Feb 2019 14:58:04 -0800 (PST) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 8CF22130EBE; Fri, 1 Feb 2019 14:58:03 -0800 (PST) Received: by mail-oi1-x235.google.com with SMTP id y1so7145609oie.12; Fri, 01 Feb 2019 14:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=jNiSMhRyQfCtD8y8LnxexF8cCqQi3bIhNLPRLgc9/cQ=; b=c72AImIZr8udp6iHtVS0lfwn5dncyRrE6PLbV3XE6D2bVjN49y31aNUFLitwKODScy CBgDGsUJpZj1VDol9COEgDo5uByCuWKIYhaONyHTtZtJbG2hX3/EusMBmCf++EM8Gvra U4nPRhe+Bj6sofJbeS7k/ci0FWU1oeneTXRitNIYnuf4gqcE4Ky4MqKyNlhVrTwr+RIV zqp8RWzKBhkZBapTm7XGmPBSiWyNE9vEVb7slhatatxgFdGHFVxUDDEfPipQhTDftUBp 3OrTpZxMx9AAoaaPMzcJthrEM0RlCCNMhRdbu/7QuqC7G9g1PYAsaZ88Nz3dHnwc8Ul7 Bt2g== 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=jNiSMhRyQfCtD8y8LnxexF8cCqQi3bIhNLPRLgc9/cQ=; b=LlkeZ3tsAbbUKCJft1DZb0UfHANkl2cA+FWWflgNsNlA+4f07rsLLqvSg1CBhSjdtV HCuZRiW+TAotj7IRcpn23sPSfmgAJcGfV1JEJJg0UbrAEKCDBgKb/tEIG4QtUFMfOk9k htfeTWEqmaiVoVIBfDJxKUw8rEwhXA63wjZy1L5i1C5lmmdsqHwyR7jelQQmh9fjEABo /mYJs605S2WmMPmimtd9sRKKpgbWTfiouRhj3KoClTD3xY34Fp3AXedeQHwV/zwD4kHt IfuFfIqw64hg1hqMkQLy/FghtcFEWld6j9JehUyfTWSl3ewO341Z4CUgRqeUsKGSqUHF 0TbQ== X-Gm-Message-State: AJcUukc/TGo7hl/F/hfBL9rlwWrazh19QEnAGKGLAR5Gz1aWAF1HgYfs XGjLJ/x5Jz455Hm9nHLFpUsK48xCcbUxLYJ9mDs= X-Google-Smtp-Source: AHgI3IbS8OvZx/UN//HSFOsxcfnwE2Etg95J+N04Lkw6gWmXcxE6OVtRC7/M/joWVBEgiVFcsdql0VxqDoKbGPUB5zA= X-Received: by 2002:aca:1b13:: with SMTP id b19mr19413348oib.215.1549061882830; Fri, 01 Feb 2019 14:58:02 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 1 Feb 2019 23:58:02 +0100 From: Alvaro Retana In-Reply-To: References: <154508592591.4271.12094992121838897393.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Date: Fri, 1 Feb 2019 23:58:02 +0100 Message-ID: To: Vishnu Pavan Beeram Cc: mpls-chairs@ietf.org, IETF MPLS List , draft-ietf-mpls-rsvp-shared-labels@ietf.org, The IESG Content-Type: multipart/alternative; boundary="00000000000042e5000580dd13c5" Archived-At: Subject: Re: [mpls] Alvaro Retana's Discuss on draft-ietf-mpls-rsvp-shared-labels-07: (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, 01 Feb 2019 22:58:06 -0000 --00000000000042e5000580dd13c5 Content-Type: text/plain; charset="UTF-8" Just cleared the DISCUSS. Thanks! Alvaro. On January 31, 2019 at 8:45:26 PM, Vishnu Pavan Beeram ( vishnupavan@gmail.com) wrote: Thanks! We published an update as suggested ( https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rsvp-shared-labels-09). --00000000000042e5000580dd13c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Just cleared the DISCUSS.

Thanks!

Alvaro.

On January= 31, 2019 at 8:45:26 PM, Vishnu Pavan Beeram (vishnupavan@gmail.com) wrote:

--00000000000042e5000580dd13c5-- From nobody Fri Feb 8 21:29: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 6DED913115A; Fri, 8 Feb 2019 21:29: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.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mpls@ietf.org Message-ID: <154969014942.31116.6919072251920174620@ietfa.amsl.com> Date: Fri, 08 Feb 2019 21:29:09 -0800 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-ri-rsvp-frr-05.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, 09 Feb 2019 05:29: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 : Refresh Interval Independent FRR Facility Protection Authors : Chandra Ramachandran Ina Minei Dante Pacella Tarek Saad Filename : draft-ietf-mpls-ri-rsvp-frr-05.txt Pages : 24 Date : 2019-02-08 Abstract: RSVP-TE relies on periodic refresh of RSVP messages to synchronize and maintain the LSP related states along the reserved path. In the absence of refresh messages, the LSP related states are automatically deleted. Reliance on periodic refreshes and refresh timeouts are problematic from the scalability point of view. The number of RSVP- TE LSPs that a router needs to maintain has been growing in service provider networks and the implementations should be capable of handling increase in LSP scale. RFC 2961 specifies mechanisms to eliminate the reliance on periodic refresh and refresh timeout of RSVP messages, and enables a router to increase the message refresh interval to values much longer than the default 30 seconds defined in RFC 2205. However, the protocol extensions defined in RFC 4090 for supporting fast reroute (FRR) using bypass tunnels implicitly rely on short refresh timeouts to cleanup stale states. In order to eliminate the reliance on refresh timeouts, the routers should unambiguously determine when a particular LSP state should be deleted. Coupling LSP state with the corresponding RSVP-TE signaling adjacencies as recommended in RFC 8370 will apply in scenarios other than RFC 4090 FRR using bypass tunnels. In scenarios involving RFC 4090 FRR using bypass tunnels, additional explicit tear down messages are necessary. Refresh-interval Independent RSVP FRR (RI-RSVP-FRR) extensions specified in this document consists of procedures to enable LSP state cleanup that are essential in scenarios not covered by procedures defined in RSVP-TE Scaling Recommendations. Hence, this document updates the procedures defined in RFC 4090 to support Refresh-Interval Independent RSVP (RI-RSVP) capability specified in RFC 8370. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ri-rsvp-frr/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mpls-ri-rsvp-frr-05 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-ri-rsvp-frr-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ri-rsvp-frr-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Feb 9 03:53: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 5CFBD128D52 for ; Sat, 9 Feb 2019 03:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es 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 d-eT13DAVWQb for ; Sat, 9 Feb 2019 03:53:30 -0800 (PST) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 38849128CF2 for ; Sat, 9 Feb 2019 03:53:30 -0800 (PST) Received: by mail-wm1-x332.google.com with SMTP id y185so9262256wmd.1 for ; Sat, 09 Feb 2019 03:53:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=X3bP0Mp5+5cTT8UV5Lr9IqT9C4O287+RL1oOIB7XsY0=; b=OmZJhU//ArG3I/OIdXOqqf6ND98wNKoHRBLbkWiSHbmidl9CpjUIPhO5phdJ0S/V6g QRUiZ/3zL8My8HwUUIq+v0c2C5GarsA56zrUK1JFwjH4z9FfZOYSTG+pencYuJjLpPWE Dsu8iilSEwva9c6y19BNO7M2OV0k+XIkXt/Xq3JYvHPI1b4grvK3UP9AnpVTnmayLE9U Y9MnEe38OiX++G19xjGy1x7ZnFDJq8j53k2vCxXkUE3FYdnv7BG0Adey80e4p+CxVcJL fFktQnuDAJLQPKepEF0rQ+k2OvliyrAp4BEU9GibnPlyirYqO03wYyrl7p6fftIii7fm 1K+w== 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=X3bP0Mp5+5cTT8UV5Lr9IqT9C4O287+RL1oOIB7XsY0=; b=EkiAyLR2t+w1hMuzMVd1VSphsqh+R9Tg9FZA6RbNWISGQ7E1ScqTdZKWv+lAb4deDu qoQY6tkhFf6HAmTnfCrL1XxkUL6zSKvmjFyWbmvmovtI4V2zVI+wxoay7+nlqKB9tyvm nStW/0fDjqsuDX1eijnB+LTDbLkRxq0g2llGB8qQX7sPThl6CSKaORhuqCiCFxVmBfuS F6BawZWH/IgVfjgIEuDolVVZ7KDtXGGh2V02DIXYfsSGQWMXyOLX18n8fA5qHi7+wSVC 93nG8F2PuNMnRYS26em4iiddiXcw7DMa0n6ItavyjqdAqZnFzzyttdXN0LgsXabroRkM WoNA== X-Gm-Message-State: AHQUAuZzVuWpFSpp2gkt7NKwyI9W3JCF/HOCf6kj1UqXFEqMZGlGWdJA kJu4g4QixJT3lINdCE3WupWwUbX+fxii3QYEcuEghjX5 X-Google-Smtp-Source: AHgI3IZuHbsbJA+Ram/FQ7mhErpmEcfwV0U6mLL0OuoqFUfmDFLSvQtBkLEVFXCzjDj+p3sZ1hHrXrt7d/IWR/wO7SA= X-Received: by 2002:a5d:5492:: with SMTP id h18mr21480627wrv.322.1549713208005; Sat, 09 Feb 2019 03:53:28 -0800 (PST) MIME-Version: 1.0 References: <1bf361f0-1987-ce4e-0671-d46886898e44@pi.nu> <32e0c032-1c20-2bc1-30c3-23b3f7fb6901@pi.nu> In-Reply-To: From: CARLOS JESUS BERNARDOS CANO Date: Sat, 9 Feb 2019 12:53:11 +0100 Message-ID: To: mpls@ietf.org Content-Type: multipart/alternative; boundary="000000000000447c8b058174b92d" Archived-At: Subject: Re: [mpls] working group last call on draft-ietf-mpls-rmr 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 Feb 2019 11:53:33 -0000 --000000000000447c8b058174b92d Content-Type: text/plain; charset="UTF-8" Hi, Support. I think the document is ready to move forward. Carlos On 2019-01-15 16:10, Loa Andersson wrote: > > Working Group, > > > > This is to initiate a two week working group last call on > > draft-ietf-mpls-rmr. > > > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > > > There are no IPR disclosures directly against draft-ietf-mpls-rmr, but > > an IPR (#2661) were disclosed against the individual document that we > > adopted as a working group document. > > > > Both authors have stated on the working group mailing list that they > > are unaware of any non-disclosed IPRs that relates to this document. > > > > This working group last call ends Wednesday January 30, 2019. > > > > /Loa > > mpls wg co-chair > > -- > > Loa Andersson email: loa@pi.nu > Senior MPLS Expert > Bronze Dragon Consulting phone: +46 739 81 21 64 > --000000000000447c8b058174b92d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Support. I think the doc= ument is ready to move forward.

Carlos
<= br>
On 2019-01-15 16:10, Loa Andersson wrote:
> Working Group,
>
> This is to initiate a two week working group last call on
> draft-ietf-mpls-rmr.
>
> Please send your comments to the mpls wg mailing list (mpls@ietf.org).
>
> There are no IPR disclosures directly against draft-ietf-mpls-rmr, but=
> an IPR (#2661) were disclosed against the individual document that we<= br> > adopted as a working group document.
>
> Both authors have stated on the working group mailing list that they > are unaware of any non-disclosed IPRs that relates to this document. >
> This working group last call ends Wednesday January 30, 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
--000000000000447c8b058174b92d-- From nobody Sat Feb 9 04:30: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 7887C12E7C1 for ; Sat, 9 Feb 2019 04:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telefonica.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R52t-SI9NgtG for ; Sat, 9 Feb 2019 04:30:34 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10092.outbound.protection.outlook.com [40.107.1.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65D6128CF2 for ; Sat, 9 Feb 2019 04:30:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telefonica.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aZ9jxBgBfjBri0Xsh7pKBM2bKfmd2NiPjKNh0q4PeqQ=; b=eHDJYnC0Q2+u8aHguP7Am8JZh3RQcQkJFKASqVoyVme/1mZUkY8A/FeJOh+Ww7reEDUnCaAuo4HjOBzosVxpAvr7HjTJjrUWRJVWndiVD49haDTH5M8f6GgmKQ6jk4rp4YG9U2frXnwlBi52VCn0ZndxFPp63Pov8Y05hU3TbBU= Received: from DB3PR0602MB3788.eurprd06.prod.outlook.com (52.134.70.148) by DB3PR0602MB3676.eurprd06.prod.outlook.com (52.134.71.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.22; Sat, 9 Feb 2019 12:30:30 +0000 Received: from DB3PR0602MB3788.eurprd06.prod.outlook.com ([fe80::686f:4013:7aea:f279]) by DB3PR0602MB3788.eurprd06.prod.outlook.com ([fe80::686f:4013:7aea:f279%5]) with mapi id 15.20.1601.016; Sat, 9 Feb 2019 12:30:30 +0000 From: "Diego R. Lopez" To: "mpls@ietf.org" Thread-Topic: working group last call on draft-ietf-mpls-rmr Thread-Index: AQHUrKnTKcqiU6g6DUWKNE4hIXOmXKXXaF0AgAATCWCAACKFgA== Date: Sat, 9 Feb 2019 12:30:30 +0000 Message-ID: <5B5007CC-F022-4BE6-B2B0-1D897F682BFF@telefonica.com> References: <1bf361f0-1987-ce4e-0671-d46886898e44@pi.nu> <32e0c032-1c20-2bc1-30c3-23b3f7fb6901@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.6.190114 authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-originating-ip: [79.146.102.69] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR0602MB3676; 6:XYRJx17vVzqR98ZiaSwRvN5c4XumWjvbB6imDLeFERaxkWzhhIW35PbJZpKSP0LM3GOLHcqJFptf0BQtpJnLLp5aUu/r+/ws3GFsePADiJTfLJ41AOc1N2w7XHiMHQEfZNhxc0RfblNQJIHW0F6PYdB5h3DygVQkY1GbQGivkq2TM6l+A7OznCbd1Dr4FfBFU58/o/J5mKh7s9LXVRGaniQBHDoKH9Vq4uiV0u+Hz2ujKGy9hhOTh+yTinAQaHZVEAZKjOIsdVH6HdZaqR3wlfpewgHXux6uqoaYtvOxNW/s3WsI/4mg0BNBU+uAfcCDb2fCKgBVk3QDUudiZsiowB3nvrIWFiuzFfNPk5+fg4cW+txIkbEfECaDSOwAFx5Ead2axl2JFEVIVmxWwKmlvHrWgFMmM2MEUkDDBM8yx3ZHFZATEFdTHdxo/UZCfLT1d3EE1ongF9HGX5h55JztWw==; 5:+O7WjGHCm4RLLD65Hpr2nhfx2oV9XtUeKk66fqYplzdwVPmqXGdd6+wzDjVWicUfn4puILJixw33TbgsjLo+uYPhBgIYFKWRlF/Nz5Wae8V3aA52xu1b5KDoxod60PuuUo1Jp9xbns/0dDvpqX4mubkQlvErXe90k6rLxgapIQbWGK9Gp/SfjrOZOT90geHLlgYzRHCxGwXbBY4x++mf7Q==; 7:2zRiQdC8O7ASIWh4hyxNQJ59pAHeablqNxjqGacp+HB1ut+R/u68lfsuLcJnhJ2KYOINtYnX4cg2XXNweRKHk1+NeOrb5xPORwdIK0xqigxgRF1UGZdp3GYDm01EtSp7q72HhFIoPwDmuEH44sBVpA== x-ms-office365-filtering-correlation-id: 23845ecc-2a1e-4899-5f5a-08d68e8a60fa x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:DB3PR0602MB3676; x-ms-traffictypediagnostic: DB3PR0602MB3676: x-microsoft-antispam-prvs: x-forefront-prvs: 09435FCA72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(39860400002)(396003)(346002)(136003)(40134004)(189003)(199004)(2616005)(36756003)(11346002)(66066001)(8676002)(476003)(82746002)(83716004)(186003)(478600001)(105586002)(106356001)(99286004)(26005)(446003)(102836004)(6506007)(486006)(71190400001)(76176011)(14444005)(256004)(6916009)(66574012)(71200400001)(53546011)(58126008)(2906002)(8936002)(229853002)(316002)(3846002)(6116002)(81156014)(81166006)(68736007)(53936002)(14454004)(786003)(1730700003)(2351001)(25786009)(7736002)(305945005)(33656002)(6246003)(5640700003)(6512007)(6436002)(97736004)(2501003)(86362001)(6486002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR0602MB3676; H:DB3PR0602MB3788.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: iLjRYTijMEa6wQTp+wOMjWFHLMl8P1c2XgB9SWtVoMJUnMLIEsPvSWtIwlU6LMtX6N1Sl2jAeLE7SMCgxSIHSV0bWl4dzuUZr2kU09WjVVxPUlxJCuQR7BP5v0D8U62QEEhGxP9VyYX6WrAkfoGUFXdmDD/jla6FyHiNqEPbC9FT9VBlkG4HqOkognbsHEXGBRvjlvVgRASa1sFqsquqxwNKsxgUlowqHB2oKv9UOtbYqn1akRituyhp7iywF23mUzJqnjub2d0T6lZLeZSYiNB5w6/ovybN9+WgnhnEq/n4NBAEMT7uh7aZr36nI2oZ174EA6h5Y3S61eR6XqYn/H5KCSD/qs6y/jAZDJDplU/qu9d/e9W6B0sDs7dJeOfXfpLUH871ya7ci/XTd611WHDihRTBdW8MaGDEREsxLNo= Content-Type: text/plain; charset="utf-8" Content-ID: <4F78C963ECDABE489F000478722292F8@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-Network-Message-Id: 23845ecc-2a1e-4899-5f5a-08d68e8a60fa X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2019 12:30:30.1795 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0602MB3676 Archived-At: Subject: Re: [mpls] working group last call on draft-ietf-mpls-rmr 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 Feb 2019 12:30:37 -0000 SGksDQoNCkkga25vdyBpdCBpcyBhIGxpdHRsZSBiaXQgYmV5b25kIHRoZSBlbmQgZGF0ZSwgYnV0 IEkgd2FudCB0byBleHByZXNzIG15IHN1cHBvcnQgZm9yIGRyYWZ0LWlldGYtbXBscy1ybXIuIEkg dGhpbmsgaXQgaXMgcmVhZHkgdG8gcHJvZ3Jlc3MgdG8gaXRzIHB1YmxpY2F0aW9uLg0KDQpCZSBn b29kZSwNCg0KICBPbiAyMDE5LTAxLTE1IDE2OjEwLCBMb2EgQW5kZXJzc29uIHdyb3RlOg0KICAg IFdvcmtpbmcgR3JvdXAsDQoNCiAgICBUaGlzIGlzIHRvIGluaXRpYXRlIGEgdHdvIHdlZWsgd29y a2luZyBncm91cCBsYXN0IGNhbGwgb24NCiAgICBkcmFmdC1pZXRmLW1wbHMtcm1yLg0KDQogICBQ bGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdnIG1haWxpbmcgbGlzdCAobXBs c0BpZXRmLm9yZykuDQoNCiAgIFRoZXJlIGFyZSBubyBJUFIgZGlzY2xvc3VyZXMgZGlyZWN0bHkg YWdhaW5zdCBkcmFmdC1pZXRmLW1wbHMtcm1yLCBidXQNCiAgIGFuIElQUiAoIzI2NjEpIHdlcmUg ZGlzY2xvc2VkIGFnYWluc3QgdGhlIGluZGl2aWR1YWwgZG9jdW1lbnQgdGhhdCB3ZQ0KICAgYWRv cHRlZCBhcyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQoNCiAgIEJvdGggYXV0aG9ycyBoYXZl IHN0YXRlZCBvbiB0aGUgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgdGhhdCB0aGV5DQogICBh cmUgdW5hd2FyZSBvZiBhbnkgbm9uLWRpc2Nsb3NlZCBJUFJzIHRoYXQgcmVsYXRlcyB0byB0aGlz IGRvY3VtZW50Lg0KDQogICBUaGlzIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVuZHMgV2VkbmVz ZGF5IEphbnVhcnkgMzAsIDIwMTkuDQoNCiAgIC9Mb2ENCiAgIG1wbHMgd2cgY28tY2hhaXINCg0K ICAgIC0tDQoNCg0KICAgIExvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFp bDogbG9hQHBpLm51DQogICAgU2VuaW9yIE1QTFMgRXhwZXJ0DQogICAgQnJvbnplIERyYWdvbiBD b25zdWx0aW5nICAgICAgICAgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQoNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpFc3RlIG1lbnNhamUgeSBzdXMgYWRqdW50 b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpbywgcHVlZGUgY29u dGVuZXIgaW5mb3JtYWNpw7NuIHByaXZpbGVnaWFkYSBvIGNvbmZpZGVuY2lhbCB5IGVzIHBhcmEg dXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8gZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBl cyB1c3RlZC4gZWwgZGVzdGluYXRhcmlvIGluZGljYWRvLCBxdWVkYSBub3RpZmljYWRvIGRlIHF1 ZSBsYSBsZWN0dXJhLCB1dGlsaXphY2nDs24sIGRpdnVsZ2FjacOzbiB5L28gY29waWEgc2luIGF1 dG9yaXphY2nDs24gcHVlZGUgZXN0YXIgcHJvaGliaWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xh Y2nDs24gdmlnZW50ZS4gU2kgaGEgcmVjaWJpZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwgbGUg cm9nYW1vcyBxdWUgbm9zIGxvIGNvbXVuaXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNt YSB2w61hIHkgcHJvY2VkYSBhIHN1IGRlc3RydWNjacOzbi4NCg0KVGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRp YWwgaW5mb3JtYXRpb24gaW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVh bCBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlz IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0 IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11 bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIGRvIG5vdCByZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRl bHkgcmVwbHkgdG8gdGhlIHNlbmRlciB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVu aWNhdGlvbiBpbiBlcnJvciBhbmQgdGhlbiBkZWxldGUgaXQuDQoNCkVzdGEgbWVuc2FnZW0gZSBz ZXVzIGFuZXhvcyBzZSBkaXJpZ2VtIGV4Y2x1c2l2YW1lbnRlIGFvIHNldSBkZXN0aW5hdMOhcmlv LCBwb2RlIGNvbnRlciBpbmZvcm1hw6fDo28gcHJpdmlsZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBl IMOpIHBhcmEgdXNvIGV4Y2x1c2l2byBkYSBwZXNzb2Egb3UgZW50aWRhZGUgZGUgZGVzdGluby4g U2UgbsOjbyDDqSB2b3NzYSBzZW5ob3JpYSBvIGRlc3RpbmF0w6FyaW8gaW5kaWNhZG8sIGZpY2Eg bm90aWZpY2FkbyBkZSBxdWUgYSBsZWl0dXJhLCB1dGlsaXphw6fDo28sIGRpdnVsZ2HDp8OjbyBl L291IGPDs3BpYSBzZW0gYXV0b3JpemHDp8OjbyBwb2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1 ZGUgZGEgbGVnaXNsYcOnw6NvIHZpZ2VudGUuIFNlIHJlY2ViZXUgZXN0YSBtZW5zYWdlbSBwb3Ig ZXJybywgcm9nYW1vcy1saGUgcXVlIG5vcyBvIGNvbXVuaXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBl c3RhIG1lc21hIHZpYSBlIHByb2NlZGEgYSBzdWEgZGVzdHJ1acOnw6NvDQo= From nobody Sat Feb 9 04:45: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 D190E1311AF for ; Sat, 9 Feb 2019 04:45:26 -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, 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 LKt15gV8za06 for ; Sat, 9 Feb 2019 04:45:24 -0800 (PST) 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 1004912D829 for ; Sat, 9 Feb 2019 04:45:24 -0800 (PST) Received: from [192.168.1.20] (unknown [119.94.174.90]) (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 DB1B818015A3; Sat, 9 Feb 2019 13:45:20 +0100 (CET) To: "Diego R. Lopez" , "mpls@ietf.org" References: <1bf361f0-1987-ce4e-0671-d46886898e44@pi.nu> <32e0c032-1c20-2bc1-30c3-23b3f7fb6901@pi.nu> <5B5007CC-F022-4BE6-B2B0-1D897F682BFF@telefonica.com> From: Loa Andersson Message-ID: Date: Sat, 9 Feb 2019 20:45:14 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <5B5007CC-F022-4BE6-B2B0-1D897F682BFF@telefonica.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [mpls] working group last call on draft-ietf-mpls-rmr 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 Feb 2019 12:45:27 -0000 Diego, We have had a bit too few responses to the wglc, so I'm holding off on closing the wglc. So your comments is very welcome. I'm also waiting for a RTG dir Early review before closing the the wglc. I hope to close the wglc end of the week. /Loa On 2019-02-09 20:30, Diego R. Lopez wrote: > Hi, > > I know it is a little bit beyond the end date, but I want to express my support for draft-ietf-mpls-rmr. I think it is ready to progress to its publication. > > Be goode, > > On 2019-01-15 16:10, Loa Andersson wrote: > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-rmr. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > There are no IPR disclosures directly against draft-ietf-mpls-rmr, but > an IPR (#2661) were disclosed against the individual document that we > adopted as a working group document. > > Both authors have stated on the working group mailing list that they > are unaware of any non-disclosed IPRs that relates to this document. > > This working group last call ends Wednesday January 30, 2019. > > /Loa > mpls wg co-chair > > -- > > > Loa Andersson email: loa@pi.nu > Senior MPLS Expert > Bronze Dragon Consulting phone: +46 739 81 21 64 > > > > ________________________________ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. > > The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição > _______________________________________________ > 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 Sat Feb 9 17:46: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 9183B130DDA; Sat, 9 Feb 2019 17:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ZaPr6wPolhYI; Sat, 9 Feb 2019 17:46:12 -0800 (PST) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 5CFCC12F295; Sat, 9 Feb 2019 17:46:12 -0800 (PST) Received: by mail-ot1-x335.google.com with SMTP id z19so8117983otm.2; Sat, 09 Feb 2019 17:46:12 -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=dvZ/ltsMp6f9ZbBfIm/5xAkyhJp7w3q5JVCa69Ya95I=; b=rnDWPIz4r2yyuxU/ZQGa0gPJGDMGeCjevOSMtWO5ENM0rONZCBNMSX0NCXfxotKxMf cU7Rnp0f06Gu7OSx+ZLKyRhRmJITvIAmh3E5f/JpiIfSCFk/+wzRFI/HeqT+Y5rqTlwi SG5/wcvP6CmhDZhpz822AN04ueWsMs23cWZ0Idu1ORfD09nuZuRH6Y14smf8ctsoUuXS mDnMk1dXlcFFPtUoXSfYpi0zIoNdbATesxTts6oJdg5Z3dXEZQSHrhrgfWUyCuyJRAOq yymd6sZb38NyJuXGZ8XXkyK7iVISvqgLIacu5lgYwRBwwFJ2sU6PTZMqymyRNvY4XJy+ N7Og== 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=dvZ/ltsMp6f9ZbBfIm/5xAkyhJp7w3q5JVCa69Ya95I=; b=FGbIE8scssgLsm5LEQzu1qfW3S4kDfBK24fSoUmPLKHavwgIjjpjG/6HrulwSNuuE7 9ayjcfRedC9XlBhojvMq1hlsAS9Gl0rvCEbtEAZLH36MfuviBgMcF7tOKIb9RDzh/10Y NGuVyztqgYYE54bNJ0LEo/yM3fQlD4n9tYroZ/06r3z1U5UMLAEW1RkUdM1gL9DaM3rd NJ+JD7vJrHpc3hyjy+jJ5OFn9RXEjx9AtCLvni0UDJmJmErxpMPzXHNm1aS/38CCq66D 9TXy7QrLCMbcNxAtuztTEVlGVID+JY1K7rgvezVqYBpKsu5leE+43XmaGHsSHpEg7Tt5 A2MA== X-Gm-Message-State: AHQUAua5ZTNIOpf51E8LD756KWOv9W6x4xCF0MIgRJ6qB6kiK2VaDEJN yJQLmS2ll7AMiRIsNDdSuYgx96hY X-Google-Smtp-Source: AHgI3IbYrpNw7e1o8ITVU2rYHNqnhTUNvuLAZ8wSVbStOMDLEdjDoSO10Edo+DmYRlTtrH0Ll6DgJQ== X-Received: by 2002:a9d:73cf:: with SMTP id m15mr424694otk.126.1549763171375; Sat, 09 Feb 2019 17:46:11 -0800 (PST) Received: from ?IPv6:2600:1702:1d00:1dd0:2d12:eac9:8c69:83d0? ([2600:1702:1d00:1dd0:2d12:eac9:8c69:83d0]) by smtp.gmail.com with ESMTPSA id c17sm3019119oih.19.2019.02.09.17.46.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Feb 2019 17:46:10 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Kireeti Kompella X-Mailer: iPhone Mail (16C50) In-Reply-To: <1bf361f0-1987-ce4e-0671-d46886898e44@pi.nu> Date: Sat, 9 Feb 2019 17:46:09 -0800 Cc: "mpls@ietf.org" , "mpls-chairs@ietf.org" , "draft-ietf-mpls-rmr@ietf.org" , Deborah A Brungard Content-Transfer-Encoding: quoted-printable Message-Id: <805AC356-CCA3-4995-95C0-C60FE1A9C55F@gmail.com> References: <1bf361f0-1987-ce4e-0671-d46886898e44@pi.nu> To: Loa Andersson Archived-At: Subject: Re: [mpls] working group last call on draft-ietf-mpls-rmr 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 Feb 2019 01:46:15 -0000 I believe the draft is ready for publication. All comments and discussions h= ave been closed at this time. Kireeti > On Jan 15, 2019, at 00:10, Loa Andersson wrote: >=20 > Working Group, >=20 > This is to initiate a two week working group last call on > draft-ietf-mpls-rmr. >=20 > Please send your comments to the mpls wg mailing list (mpls@ietf.org). >=20 > There are no IPR disclosures directly against draft-ietf-mpls-rmr, but > an IPR (#2661) were disclosed against the individual document that we > adopted as a working group document. >=20 > Both authors have stated on the working group mailing list that they > are unaware of any non-disclosed IPRs that relates to this document. >=20 > This working group last call ends Wednesday January 30, 2019. >=20 > /Loa > 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 From nobody Sat Feb 9 23:54: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 96C72124C04 for ; Sat, 9 Feb 2019 23:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=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 Ei5mIva_p2i4 for ; Sat, 9 Feb 2019 23:54:02 -0800 (PST) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 12790130E6F for ; Sat, 9 Feb 2019 23:54:02 -0800 (PST) Received: by mail-pl1-x62c.google.com with SMTP id g9so3785680plo.3 for ; Sat, 09 Feb 2019 23:54:02 -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=OlsXzo0DIaUPVLSqFryw4ql/Lsc1IT50ID2sZQ55r+8=; b=sYEN6/PVJPGtNAc3itAIVMdJ3flQSY5J/Hdxa1atpIX2c3+wB3RcY8AaLK9ZuFfC3w am/ZTZladbB/5bk2V0TBBgfjmb5+Cp50bglVj6Cah1LQf1V9R5wsV8mN40YU7Ff6+h/X nUVy6N6/nfRfkkZvbjOPo0FHTI8w4puTrQ7L5Kb0wKU392A7Ki6emi9+ZVthCEHzzoml Dm0xAztAxECVtEl3wQT7FbIJqvlupeXcBWCYMn0fPYc46KglNMmS1phiD7J0/NoK3Z8x xMVni6ZsiV5dOcnb6/mWGGUjwXTcm86RBseseAd3TLVwNX5z3Y6uBVqpf66tMklW1IYr njJQ== 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=OlsXzo0DIaUPVLSqFryw4ql/Lsc1IT50ID2sZQ55r+8=; b=n9yPNo5O65cL6zxT7IR/gOKEq4MPXzckvpkmi0BoSDiK6eBnRwxAYhdGPne0cxt+wO PrJW8Buyr8LZrfymSqQYBxEN3UQVK/GyOia2BwJLFyyIhv2FxpwfBBe2Rpr2bIDzMncW RyeRkEzhYN2Iepyvctdkf36vgzod3L+CyXXCCEbw3meIwZiX1PExGfBypXbPCSvBDJtv j7xKQnooDTFmYXFa7Z23938Yu38RdWgYMMTK+rPWHiH+Beiy7W5tsX3y8XHcjfGHoVIS sppZMefPd3jmcm2crW/9dxEVhBAfMSm7+Sqm31hyMUOFlKKGuhUJbaoaFG2VjaBdHpJx W00A== X-Gm-Message-State: AHQUAuZHqtS58adCJv/O4eHnxpJf4CGm+nTJzntUTubKzzVyPZs4EfGi bVM2ASB6+28GKAsFv4OrOxw40qYO X-Google-Smtp-Source: AHgI3IbJR7Oyx2QDHZPFjy5wveX+qzhq0hNDIgM5MlhW/OfatsW9trTg0xZaXyZzPbpHPQLf83wCdA== X-Received: by 2002:a17:902:b68d:: with SMTP id c13mr31821308pls.102.1549785241223; Sat, 09 Feb 2019 23:54:01 -0800 (PST) Received: from [192.168.1.12] (c-73-189-13-44.hsd1.ca.comcast.net. [73.189.13.44]) by smtp.gmail.com with ESMTPSA id l10sm9499031pfc.90.2019.02.09.23.53.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Feb 2019 23:54:00 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Jeff Tantsura X-Mailer: iPhone Mail (16C101) In-Reply-To: <5B5007CC-F022-4BE6-B2B0-1D897F682BFF@telefonica.com> Date: Sat, 9 Feb 2019 23:53:57 -0800 Cc: "mpls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <22678FD0-89ED-4072-89E4-37E1FEFBD1D2@gmail.com> References: <1bf361f0-1987-ce4e-0671-d46886898e44@pi.nu> <32e0c032-1c20-2bc1-30c3-23b3f7fb6901@pi.nu> <5B5007CC-F022-4BE6-B2B0-1D897F682BFF@telefonica.com> To: "Diego R. Lopez" Archived-At: Subject: Re: [mpls] working group last call on draft-ietf-mpls-rmr 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 Feb 2019 07:54:05 -0000 +1 Regards, Jeff > On Feb 9, 2019, at 04:30, Diego R. Lopez wr= ote: >=20 > Hi, >=20 > I know it is a little bit beyond the end date, but I want to express my su= pport for draft-ietf-mpls-rmr. I think it is ready to progress to its public= ation. >=20 > Be goode, >=20 > On 2019-01-15 16:10, Loa Andersson wrote: > Working Group, >=20 > This is to initiate a two week working group last call on > draft-ietf-mpls-rmr. >=20 > Please send your comments to the mpls wg mailing list (mpls@ietf.org). >=20 > There are no IPR disclosures directly against draft-ietf-mpls-rmr, but > an IPR (#2661) were disclosed against the individual document that we > adopted as a working group document. >=20 > Both authors have stated on the working group mailing list that they > are unaware of any non-disclosed IPRs that relates to this document. >=20 > This working group last call ends Wednesday January 30, 2019. >=20 > /Loa > 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 >=20 >=20 > ________________________________ >=20 > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, p= uede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario i= ndicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3= n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de la legi= slaci=C3=B3n vigente. Si ha recibido este mensaje por error, le rogamos que n= os lo comunique inmediatamente por esta misma v=C3=ADa y proceda a su destru= cci=C3=B3n. >=20 > The information contained in this transmission is privileged and confident= ial information intended only for the use of the individual or entity named a= bove. If the reader of this message is not the intended recipient, you are h= ereby notified that any dissemination, distribution or copying of this commu= nication is strictly prohibited. If you have received this transmission in e= rror, do not read it. Please immediately reply to the sender that you have r= eceived this communication in error and then delete it. >=20 > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9 p= ara uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vossa= senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, ut= iliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza=C3=A7=C3= =A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigente. Se rece= beu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente po= r esta mesma via e proceda a sua destrui=C3=A7=C3=A3o > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Feb 10 09:15:49 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 517A8130E8E for ; Sun, 10 Feb 2019 09:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.631 X-Spam-Level: X-Spam-Status: No, score=-1.631 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nextworks-it.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 wN_YuK-46LPJ for ; Sun, 10 Feb 2019 09:15:44 -0800 (PST) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 5ADB2128CF2 for ; Sun, 10 Feb 2019 09:15:44 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id h22so12142136wmb.0 for ; Sun, 10 Feb 2019 09:15:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nextworks-it.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=fW9Vce0OgfoLnRLVmFlXFKBPub3kTSEEyQLRADiZ/tU=; b=cL608WALbuqlVXIPIBwdc3Wxo+zkhtFUnq19Oy3dvVnpy7vrywezMn7Z/+LQ14j0TV 3E1IJy8ycV/CB0mfD/1LpRGOzLz6z61J0ugftVRy+P1exv0P0u41xgWdOn5Wy5KNwUsE 1nhYzQwpAUZ55CUdMGQqdjnVmbieF62fBjRiPYslm4dlJRERTYlFw5/8hh+ach4zfJuu Lq8kT34nQYetxfG1SQzM93H37wsLUhvEdLjfJsPks8A+qmhEMKRxjLF55pjhiU5qBeVp AJQJjctW6DfpqpG2NTYE/Kf5BspcmtLQpv+wX8VUaJwf8joD5Gg2YR+M670o9BaYH1jG 1L/Q== 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=fW9Vce0OgfoLnRLVmFlXFKBPub3kTSEEyQLRADiZ/tU=; b=S52zXqdjcJA37lqy4JyLzh0o9ApMdTJsSRNuduzeOh4UuSVJZbzRDeE/MOGUh5ptMf zHBeoMHxL0l4QF7QidjvHdpyphGbxYkEejOVRTgFb1QoRIh2WJVMyZ8GRm0/YwU3B6ok u2VYVMJUjyhK0zdwFwvS4jeZOX/CKz34EPESBxPn4dxhaH5kfzesgY+VkNK12gA6wl2k OiDuUFqqGgEEfmxCMA60/TNgFnvpOzDHw97KybKXeQxeArdWaF5WI1MRFpjj2qpB2+tn 64IKcpwUtmeAp6YB3+OsGHVQBzs55XNMl50V4wwW3QIoEuDTcdx1qU18J7xvGbHO0zYa 7MaQ== X-Gm-Message-State: AHQUAubvq9W0c+ktqJ2dVVgOxQLfogZ/zBFMvAzqkKkcsSYOq2JPfAl2 6FggrvkKu+fHyTqz3qNIZ7a/Kj03Rx4rsT+Xuh4NxDX2CSU= X-Google-Smtp-Source: AHgI3Ibx57ntGrrHCo4QV7ZF7SMl5OKpAPbrnByZm/kiluXh4Qz9eVo+2w4O/TUcyzP3fKVnxmSIwXeV7R3nUCl2xrE= X-Received: by 2002:a5d:4ecd:: with SMTP id s13mr16311640wrv.110.1549818941864; Sun, 10 Feb 2019 09:15:41 -0800 (PST) MIME-Version: 1.0 From: Gino Carrozzo Date: Sun, 10 Feb 2019 18:15:31 +0100 Message-ID: To: mpls@ietf.org Content-Type: multipart/alternative; boundary="0000000000007f1c6905818d573e" Archived-At: Subject: Re: [mpls] working group last call on draft-ietf-mpls-rmr 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 Feb 2019 17:15:47 -0000 --0000000000007f1c6905818d573e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear WG chair & mailing list though not directly writing the related proto specification I-Ds, I support the adoption of this draft. br Gino -----Mensaje original----- De: Loa Andersson Enviado el: s=C3=A1bado, 9 de febrero de 2019 11:19 Para: mpls-chairs@ietf.org; draft-ietf-mpls-rmr@ietf.org Asunto: Re: working group last call on draft-ietf-mpls-rmr Authors, I'm holding of the closing of this wglc, there are two reasons: - we only have one response to the mailing list, can you please help me get a few more, at least the people writing documents that are based on this one should respond - I asked for a RTG Dir review, that is no in yet, bit I have a promise that it will appear soon /Loa On 2019-01-15 16:10, Loa Andersson wrote: > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-rmr. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > There are no IPR disclosures directly against draft-ietf-mpls-rmr, but > an IPR (#2661) were disclosed against the individual document that we > adopted as a working group document. > > Both authors have stated on the working group mailing list that they > are unaware of any non-disclosed IPRs that relates to this document. > > This working group last call ends Wednesday January 30, 2019. > > /Loa > mpls wg co-chair -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Gino Carrozzo Deputy Head of R&D mobile : +39 348 7610 081 landline : +39 050 3871 679 fax : +39 050 3871 601 e-mail : g.carrozzo@nextworks.it web : www.nextworks.it address : Nextworks s.r.l. via Livornese, 1027 56122 S.Piero a Grado, Pisa, ITALY =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --0000000000007f1c6905818d573e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear WG chair & mailing list

though= not directly writing the related proto specification I-Ds, I support the a= doption of this draft.

br
Gino
<= br>
-----Mensaje original-----
De: Loa Andersson <loa@pi.nu>
Enviado el: s= =C3=A1bado, 9 de febrero de 2019 11:19
Para:=C2=A0mpls-ch= airs@ietf.org;=C2=A0dra= ft-ietf-mpl= s-rmr@ietf<= /span>.org
Asunto: Re:=C2=A0working= =C2=A0group=C2=A0l= ast=C2=A0call=C2=A0on=C2=A0draft-ietf-mpls-rmr

Auth= ors,

I'm holding of the closing of this wglc, there are two
r= easons:

- we only have one response to the mailing list, can you
= =C2=A0 =C2=A0please help me get a few more, at least the people writing
= =C2=A0 =C2=A0documents that are based on this one should respond
- I ask= ed for a RTG Dir review, that is no in yet, bit I have
=C2=A0 =C2=A0a pr= omise that it will appear soon

/Loa

On 2019-01-15 16:10, Loa = Andersson wrote:
>=C2=A0Working=C2=A0= Group,
>
> This is to initiate = a two week=C2=A0working=C2=A0group=C2=A0last=C2=A0call=C2=A0on
>=C2=A0draft-ietf-mpls-rmr.
>
> Please= send your comments to the=C2=A0mpls=C2=A0w= g mailing list (mpls@ietf.org).=
>
> There are no IPR disclosures directly against=C2=A0draft-ietf-mpls-rmr, but
&= gt; an IPR (#2661) were disclosed against the individual document that we> adopted as a=C2=A0working=C2=A0group=C2=A0document.
>
> Both author= s have stated on the=C2=A0working=C2=A0group=C2=A0mailing list that they
> are u= naware of any non-disclosed IPRs that relates to this document.
>
= > This=C2=A0working=C2=A0group=C2=A0last=C2=A0call=C2=A0ends Wednesday January 30, 2019.
&g= t;
> /Loa
>=C2=A0mpls=C2=A0wg c= o-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:=C2=A0loa@pi.nu
Senior=C2=A0MPLS=C2=A0Expert
Bronze Dragon Consulting=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64=C2=A0=C2= =A0

--
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
=C2=A0 Dr. Gino Carrozzo
=C2=A0 Deputy Head of R&D

=C2=A0 mobile =C2=A0 =C2=A0: +39 348 7610 081
=C2=A0 landline = =C2=A0: +39 050 3871 679 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0
= =C2=A0 fax =C2=A0 =C2=A0 =C2=A0 =C2=A0 : +39 050 3871 601 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
--0000000000007f1c6905818d573e-- From nobody Sun Feb 10 12:35:48 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 C85EE12426E for ; Sun, 10 Feb 2019 12:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.63 X-Spam-Level: X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 waXnJ1Z9VY51 for ; Sun, 10 Feb 2019 12:35:43 -0800 (PST) Received: from mail.cnit.it (mail.cnit.it [217.9.64.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB76B1228B7 for ; Sun, 10 Feb 2019 12:35:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.cnit.it (Postfix) with ESMTP id 944BB40981 for ; Sun, 10 Feb 2019 21:35:40 +0100 (CET) X-Virus-Scanned: by cnit.it Received: from mail.cnit.it ([127.0.0.1]) by localhost (mail.cnit.it [127.0.0.1]) (amavisd-new, port 10026) with LMTP id P6kMwe8KOceq for ; Sun, 10 Feb 2019 21:35:40 +0100 (CET) Received: from [192.168.1.6] (host54-188-dynamic.21-87-r.retail.telecomitalia.it [87.21.188.54]) by mail.cnit.it (Postfix) with ESMTPSA id 457F24051A for ; Sun, 10 Feb 2019 21:35:40 +0100 (CET) To: mpls@ietf.org References: From: Filippo Cugini Message-ID: Date: Sun, 10 Feb 2019 21:35:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AE39E7CA8540E3DAEA1BAEA1" Content-Language: it-IT Archived-At: Subject: Re: [mpls] working group last call on draft-ietf-mpls-rmr 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 Feb 2019 20:35:47 -0000 This is a multi-part message in MIME format. --------------AE39E7CA8540E3DAEA1BAEA1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit +1 Support   Filippo Il 10/02/2019 18:15, Gino Carrozzo ha scritto: > Dear WG chair & mailing list > > though not directly writing the related proto specification I-Ds, I > support the adoption of this draft. > > br > Gino > > -----Mensaje original----- > De: Loa Andersson > > Enviado el: sábado, 9 de febrero de 2019 11:19 > Para: mpls-chairs@ietf.org ; > draft-ietf-mpls-rmr@ietf.org > Asunto: Re: working group last call on draft-ietf-mpls-rmr > > Authors, > > I'm holding of the closing of this wglc, there are two > reasons: > > - we only have one response to the mailing list, can you >    please help me get a few more, at least the people writing >    documents that are based on this one should respond > - I asked for a RTG Dir review, that is no in yet, bit I have >    a promise that it will appear soon > > /Loa > > On 2019-01-15 16:10, Loa Andersson wrote: > > Working Group, > > > > This is to initiate a two week working group last call on > > draft-ietf-mpls-rmr. > > > > Please send your comments to the mpls wg mailing list (mpls@ietf.org > ). > > > > There are no IPR disclosures directly against draft-ietf-mpls-rmr, but > > an IPR (#2661) were disclosed against the individual document that we > > adopted as a working group document. > > > > Both authors have stated on the working group mailing list that they > > are unaware of any non-disclosed IPRs that relates to this document. > > > > This working group last call ends Wednesday January 30, 2019. > > > > /Loa > > mpls wg co-chair > > -- > > > Loa Andersson                        email: loa@pi.nu > Senior MPLS Expert > Bronze Dragon Consulting             phone: +46 739 81 21 64 > > -- > ============================================================== >   Dr. Gino Carrozzo > Deputy Head of R&D > > mobile    : +39 348 7610 081 > landline  : +39 050 3871 679 >   fax         : +39 050 3871 601 > e-mail    : g.carrozzo@nextworks.it >   web       : www.nextworks.it > address   : Nextworks s.r.l. >             via Livornese, 1027 >             56122 S.Piero a Grado, Pisa, ITALY > ============================================================== > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --------------AE39E7CA8540E3DAEA1BAEA1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

+1

Support

  Filippo


Il 10/02/2019 18:15, Gino Carrozzo ha scritto:
Dear WG chair & mailing list

though not directly writing the related proto specification I-Ds, I support the adoption of this draft.

br
Gino

-----Mensaje original-----
De: Loa Andersson <loa@pi.nu>
Enviado el: sábado, 9 de febrero de 2019 11:19
Para: mpls-chairs@ietf.org; draft-ietf-mpls-rmr@ietf.org
Asunto: Re: working group last call on draft-ietf-mpls-rmr

Authors,

I'm holding of the closing of this wglc, there are two
reasons:

- we only have one response to the mailing list, can you
   please help me get a few more, at least the people writing
   documents that are based on this one should respond
- I asked for a RTG Dir review, that is no in yet, bit I have
   a promise that it will appear soon

/Loa

On 2019-01-15 16:10, Loa Andersson wrote:
> Working Group,
>
> This is to initiate a two week working group last call on
> draft-ietf-mpls-rmr.
>
> Please send your comments to the mpls wg mailing list (mpls@ietf.org).
>
> There are no IPR disclosures directly against draft-ietf-mpls-rmr, but
> an IPR (#2661) were disclosed against the individual document that we
> adopted as a working group document.
>
> Both authors have stated on the working group mailing list that they
> are unaware of any non-disclosed IPRs that relates to this document.
>
> This working group last call ends Wednesday January 30, 2019.
>
> /Loa
> mpls wg co-chair

--


Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64  

--
==============================================================
  Dr. Gino Carrozzo
  Deputy Head of R&D

  mobile    : +39 348 7610 081
  landline  : +39 050 3871 679                  
  fax         : +39 050 3871 601                  
  e-mail    : g.carrozzo@nextworks.it               
  web       : www.nextworks.it               
  address   : Nextworks s.r.l.
                  via Livornese, 1027                        
                  56122 S.Piero a Grado, Pisa, ITALY                      
==============================================================

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--------------AE39E7CA8540E3DAEA1BAEA1-- From nobody Sun Feb 10 17:31:11 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 D67DB130E84; Sun, 10 Feb 2019 17:31:08 -0800 (PST) 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 fHi8KaMhEHWE; Sun, 10 Feb 2019 17:31:07 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50B4312D4EC; Sun, 10 Feb 2019 17:31:03 -0800 (PST) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id DC0A6FA14DC0D03EFC58; Mon, 11 Feb 2019 01:31:00 +0000 (GMT) Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 11 Feb 2019 01:31:00 +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; Mon, 11 Feb 2019 01:31:00 +0000 Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) 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; Mon, 11 Feb 2019 01:31:00 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.156]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Mon, 11 Feb 2019 09:30:56 +0800 From: "Zhengguangying (Walker)" To: Sam Aldrin , "Reshad Rahman (rrahman)" CC: Loa Andersson , "mpls@ietf.org" , "draft-zheng-mpls-lsp-ping-yang-cfg@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: [mpls] IPR poll on draft-zheng-mpls-lsp-ping-yang-cfg Thread-Index: AQHUqLaSGZ+EHy0I3E2DFuR5rA8yGaW637IAgAO48gCAG2hOIA== Date: Mon, 11 Feb 2019 01:30:55 +0000 Message-ID: <381D7D55085B1E4D8B581BD652E1E140C9438DF4@nkgeml513-mbx.china.huawei.com> References: <70AB3349-FB5E-49E9-8D26-8DD62C2A670F@cisco.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.169.155] Content-Type: multipart/alternative; boundary="_000_381D7D55085B1E4D8B581BD652E1E140C9438DF4nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] IPR 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, 11 Feb 2019 01:31:09 -0000 --_000_381D7D55085B1E4D8B581BD652E1E140C9438DF4nkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9hLCBldCBhbC4sDQpJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgcmVsYXRlZCB0byBkcmFm dC16aGVuZy1tcGxzLWxzcC1waW5nLXlhbmctY2ZnLg0KDQpSZWdhcmRzLA0KR3Vhbmd5aW5nIFpo ZW5nDQoNCg0KRnJvbTogU2FtIEFsZHJpbiBbbWFpbHRvOmFsZHJpbi5pZXRmQGdtYWlsLmNvbV0N ClNlbnQ6IDIwMTnlubQx5pyIMjXml6UgNjo1Nw0KVG86IFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4p DQpDYzogTG9hIEFuZGVyc3NvbjsgbXBsc0BpZXRmLm9yZzsgZHJhZnQtemhlbmctbXBscy1sc3At cGluZy15YW5nLWNmZ0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbbXBsc10gSVBSIHBvbGwgb24gZHJhZnQtemhlbmctbXBscy1sc3AtcGluZy15YW5nLWNmZw0K DQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhpcyBkcmFmdA0KDQpPbiBU dWUsIEphbiAyMiwgMjAxOSwgNjowNiBBTSBSZXNoYWQgUmFobWFuIChycmFobWFuKSA8cnJhaG1h bkBjaXNjby5jb208bWFpbHRvOnJyYWhtYW5AY2lzY28uY29tPiB3cm90ZToNCkhpLA0KDQpJIGFt IG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdC16aGVuZy1tcGxzLWxz cC1waW5nLXlhbmctY2ZnLg0KDQpSZWdhcmRzLA0KUmVzaGFkLg0KDQoNCu+7v09uIDIwMTktMDEt MTAsIDI6MzEgQU0sICJMb2EgQW5kZXJzc29uIiA8bG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+ PiB3cm90ZToNCg0KICAgIFdvcmtpbmcgR3JvdXAsIGF1dGhvcnMsDQoNCiAgICBXZSBoYXZlIHN0 YXJ0ZWQgdG8gcHJlcGFyZSB0aGUgdGhlIGRyYWZ0LXpoZW5nLW1wbHMtbHNwLXBpbmcteWFuZy1j ZmcNCiAgICBmb3Igd29ya2luZyBncm91cCBhZG9wdGlvbiwgcHJpb3IgdG8gdGhlIHdnYXAgd2Ug bmVlZCB0byBkbyBhbiBJUFIgcG9sbC4NCg0KICAgIFRoaXMgbWFpbCBzdGFydHMgdGhpcyBJUFIg cG9sbC4NCg0KICAgIEFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJh ZnQtemhlbmctbXBscy1sc3AtcGluZy15YW5nLQ0KICAgIGNmZz8NCg0KICAgIElmIHNvLCBoYXMg dGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVz DQogICAgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWls cykuDQoNCiAgICBUaGVyZSBubyBJUFIgZGlzY2xvc3VyZXMgYWdhaW5zdCBkcmFmdC16aGVuZy1t cGxzLWxzcC1waW5nLXlhbmctY2ZnLg0KDQogICAgSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1 bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQgdG8NCiAgICB0aGlzIGVt YWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVs ZXZhbnQNCiAgICBJUFIuICpUaGUgcmVzcG9uc2UgbmVlZHMgdG8gYmUgc2VudCB0byB0aGUgTVBM UyBXRyBtYWlsaW5nIGxpc3QuKiBUaGUNCiAgICBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRv IHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4NCiAgICByZWNlaXZlZCBm cm9tIGVhY2ggYXV0aG9yIGFuZCBjb250cmlidXRvci4NCg0KICAgIElmIHlvdSBhcmUgb24gdGhl IE1QTFMgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yDQog ICAgY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlv dSBhcmUgYXdhcmUgb2YgYW55DQogICAgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9z ZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLg0KDQoNCiAgICAvTG9hDQogICAgICBt cGxzIHdnIGNvLWNoYWlyDQoNCiAgICAtLQ0KDQoNCiAgICBMb2EgQW5kZXJzc29uICAgICAgICAg ICAgICAgICAgICAgICAgZW1haWw6IGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pg0KICAgIFNl bmlvciBNUExTIEV4cGVydA0KICAgIEJyb256ZSBEcmFnb24gQ29uc3VsdGluZyAgICAgICAgICAg ICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZzxt YWlsdG86bXBsc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbXBscw0K --_000_381D7D55085B1E4D8B581BD652E1E140C9438DF4nkgeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGkmbmJzcDtMb2EsIGV0IGFs Liw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+SSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gZHJhZnQtemhlbmct bXBscy1sc3AtcGluZy15YW5nLWNmZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pkd1YW5neWluZyBaaGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFNhbSBBbGRyaW4gW21haWx0bzph bGRyaW4uaWV0ZkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjAxOTwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+5bm0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPuaciDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4y NTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+5pelPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KIDY6NTc8YnI+DQo8Yj5Ubzo8L2I+ IFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pPGJyPg0KPGI+Q2M6PC9iPiBMb2EgQW5kZXJzc29uOyBt cGxzQGlldGYub3JnOyBkcmFmdC16aGVuZy1tcGxzLWxzcC1waW5nLXlhbmctY2ZnQGlldGYub3Jn OyBtcGxzLWNoYWlyc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21wbHNdIElQ UiBwb2xsIG9uIGRyYWZ0LXpoZW5nLW1wbHMtbHNwLXBpbmcteWFuZy1jZmc8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5JIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhpcyBk cmFmdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFR1ZSwgSmFu IDIyLCAyMDE5LCA2OjA2IEFNIFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pICZsdDs8YSBocmVmPSJt YWlsdG86cnJhaG1hbkBjaXNjby5jb20iPnJyYWhtYW5AY2lzY28uY29tPC9hPiB3cm90ZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGksPGJyPg0KPGJyPg0KSSBhbSBub3QgYXdhcmUgb2Yg YW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtemhlbmctbXBscy1sc3AtcGluZy15YW5nLWNm Zy48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NClJlc2hhZC48YnI+DQo8YnI+DQo8YnI+DQrvu79P biAyMDE5LTAxLTEwLCAyOjMxIEFNLCAmcXVvdDtMb2EgQW5kZXJzc29uJnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86bG9hQHBpLm51IiB0YXJnZXQ9Il9ibGFuayI+bG9hQHBpLm51PC9hPiZndDsg d3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBXb3JraW5nIEdyb3VwLCBhdXRob3JzLDxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgV2UgaGF2ZSBzdGFydGVkIHRvIHByZXBhcmUgdGhlIHRo ZSBkcmFmdC16aGVuZy1tcGxzLWxzcC1waW5nLXlhbmctY2ZnPGJyPg0KJm5ic3A7ICZuYnNwOyBm b3Igd29ya2luZyBncm91cCBhZG9wdGlvbiwgcHJpb3IgdG8gdGhlIHdnYXAgd2UgbmVlZCB0byBk byBhbiBJUFIgcG9sbC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFRoaXMgbWFpbCBzdGFydHMg dGhpcyBJUFIgcG9sbC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEFyZSB5b3UgYXdhcmUgb2Yg YW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtemhlbmctbXBscy1sc3AtcGluZy15YW5nLTxi cj4NCiZuYnNwOyAmbmJzcDsgY2ZnPzxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgSWYgc28sIGhh cyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVs ZXM8YnI+DQombmJzcDsgJm5ic3A7IChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4 IGZvciBtb3JlIGRldGFpbHMpLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgVGhlcmUgbm8gSVBS IGRpc2Nsb3N1cmVzIGFnYWluc3QgZHJhZnQtemhlbmctbXBscy1sc3AtcGluZy15YW5nLWNmZy48 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IElmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQg YXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvPGJyPg0KJm5ic3A7ICZuYnNw OyB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBv ZiBhbnkgcmVsZXZhbnQ8YnI+DQombmJzcDsgJm5ic3A7IElQUi4gKlRoZSByZXNwb25zZSBuZWVk cyB0byBiZSBzZW50IHRvIHRoZSBNUExTIFdHIG1haWxpbmcgbGlzdC4qIFRoZTxicj4NCiZuYnNw OyAmbmJzcDsgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRp bCBhIHJlc3BvbnNlIGhhcyBiZWVuPGJyPg0KJm5ic3A7ICZuYnNwOyByZWNlaXZlZCBmcm9tIGVh Y2ggYXV0aG9yIGFuZCBjb250cmlidXRvci48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IElmIHlv dSBhcmUgb24gdGhlIE1QTFMgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4g YXV0aG9yIG9yPGJyPg0KJm5ic3A7ICZuYnNwOyBjb250cmlidXRvciwgdGhlbiBwbGVhc2UgZXhw bGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2FyZSBvZiBhbnk8YnI+DQombmJzcDsg Jm5ic3A7IElQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNl IHdpdGggSUVURiBydWxlcy48YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IC9Mb2E8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyBtcGxzIHdnIGNvLWNoYWlyPGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwOyAtLSA8YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IExvYSBBbmRlcnNzb24m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlbWFpbDogPGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5u dSIgdGFyZ2V0PSJfYmxhbmsiPg0KbG9hQHBpLm51PC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgU2Vu aW9yIE1QTFMgRXhwZXJ0PGJyPg0KJm5ic3A7ICZuYnNwOyBCcm9uemUgRHJhZ29uIENvbnN1bHRp bmcmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwaG9uZTog JiM0Mzs0NiA3MzkgODEgMjEgNjQ8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbXBscyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBsczwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_381D7D55085B1E4D8B581BD652E1E140C9438DF4nkgeml513mbxchi_-- From nobody Sun Feb 10 19:29:22 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 831A3130F3C; Sun, 10 Feb 2019 19:29:21 -0800 (PST) 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 hpj4y6fNXyfT; Sun, 10 Feb 2019 19:29:19 -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 2E99412426E; Sun, 10 Feb 2019 19:29:19 -0800 (PST) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 327E355A5DEC28FD0882; Mon, 11 Feb 2019 03:29:17 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 11 Feb 2019 03:29:16 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.156]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Mon, 11 Feb 2019 11:29:09 +0800 From: Qin Wu To: "Zhengguangying (Walker)" , Sam Aldrin , "Reshad Rahman (rrahman)" CC: "mpls@ietf.org" , "mpls-chairs@ietf.org" , "draft-zheng-mpls-lsp-ping-yang-cfg@ietf.org" Thread-Topic: [mpls] IPR poll on draft-zheng-mpls-lsp-ping-yang-cfg Thread-Index: AdTBudgmR6UIGqrOQR2A8bTrbaHsbw== Date: Mon, 11 Feb 2019 03:29:09 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.31.203] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B277ECFnkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] IPR 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, 11 Feb 2019 03:29:22 -0000 --_000_B8F9A780D330094D99AF023C5877DABA9B277ECFnkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gZHJhZnQtemhlbmctbXBscy1sc3At cGluZy15YW5nLWNmZy4NCg0KUWluIFd1DQrlj5Hku7bkuro6IG1wbHMgW21haWx0bzptcGxzLWJv dW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBaaGVuZ2d1YW5neWluZyAoV2Fsa2VyKQ0K5Y+R6YCB5pe2 6Ze0OiAyMDE55bm0MuaciDEx5pelIDk6MzENCuaUtuS7tuS6ujogU2FtIEFsZHJpbiA8YWxkcmlu LmlldGZAZ21haWwuY29tPjsgUmVzaGFkIFJhaG1hbiAocnJhaG1hbikgPHJyYWhtYW5AY2lzY28u Y29tPg0K5oqE6YCBOiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQt emhlbmctbXBscy1sc3AtcGluZy15YW5nLWNmZ0BpZXRmLm9yZw0K5Li76aKYOiBSZTogW21wbHNd IElQUiBwb2xsIG9uIGRyYWZ0LXpoZW5nLW1wbHMtbHNwLXBpbmcteWFuZy1jZmcNCg0KSGkgTG9h LCBldCBhbC4sDQpJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgcmVsYXRlZCB0byBkcmFmdC16aGVu Zy1tcGxzLWxzcC1waW5nLXlhbmctY2ZnLg0KDQpSZWdhcmRzLA0KR3Vhbmd5aW5nIFpoZW5nDQoN Cg0KRnJvbTogU2FtIEFsZHJpbiBbbWFpbHRvOmFsZHJpbi5pZXRmQGdtYWlsLmNvbV0NClNlbnQ6 IDIwMTnlubQx5pyIMjXml6UgNjo1Nw0KVG86IFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pDQpDYzog TG9hIEFuZGVyc3NvbjsgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz47IGRyYWZ0 LXpoZW5nLW1wbHMtbHNwLXBpbmcteWFuZy1jZmdAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXpoZW5n LW1wbHMtbHNwLXBpbmcteWFuZy1jZmdAaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0BpZXRmLm9yZzxt YWlsdG86bXBscy1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21wbHNdIElQUiBwb2xs IG9uIGRyYWZ0LXpoZW5nLW1wbHMtbHNwLXBpbmcteWFuZy1jZmcNCg0KSSBhbSBub3QgYXdhcmUg b2YgYW55IElQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQNCg0KT24gVHVlLCBKYW4gMjIsIDIwMTks IDY6MDYgQU0gUmVzaGFkIFJhaG1hbiAocnJhaG1hbikgPHJyYWhtYW5AY2lzY28uY29tPG1haWx0 bzpycmFobWFuQGNpc2NvLmNvbT4gd3JvdGU6DQpIaSwNCg0KSSBhbSBub3QgYXdhcmUgb2YgYW55 IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtemhlbmctbXBscy1sc3AtcGluZy15YW5nLWNmZy4N Cg0KUmVnYXJkcywNClJlc2hhZC4NCg0KDQrvu79PbiAyMDE5LTAxLTEwLCAyOjMxIEFNLCAiTG9h IEFuZGVyc3NvbiIgPGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pj4gd3JvdGU6DQoNCiAgICBX b3JraW5nIEdyb3VwLCBhdXRob3JzLA0KDQogICAgV2UgaGF2ZSBzdGFydGVkIHRvIHByZXBhcmUg dGhlIHRoZSBkcmFmdC16aGVuZy1tcGxzLWxzcC1waW5nLXlhbmctY2ZnDQogICAgZm9yIHdvcmtp bmcgZ3JvdXAgYWRvcHRpb24sIHByaW9yIHRvIHRoZSB3Z2FwIHdlIG5lZWQgdG8gZG8gYW4gSVBS IHBvbGwuDQoNCiAgICBUaGlzIG1haWwgc3RhcnRzIHRoaXMgSVBSIHBvbGwuDQoNCiAgICBBcmUg eW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LXpoZW5nLW1wbHMtbHNw LXBpbmcteWFuZy0NCiAgICBjZmc/DQoNCiAgICBJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlz Y2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcw0KICAgIChzZWUgUkZDcyAz OTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLg0KDQogICAgVGhlcmUg bm8gSVBSIGRpc2Nsb3N1cmVzIGFnYWluc3QgZHJhZnQtemhlbmctbXBscy1sc3AtcGluZy15YW5n LWNmZy4NCg0KICAgIElmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNv bnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvDQogICAgdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9m IHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50DQogICAgSVBSLiAq VGhlIHJlc3BvbnNlIG5lZWRzIHRvIGJlIHNlbnQgdG8gdGhlIE1QTFMgV0cgbWFpbGluZyBsaXN0 LiogVGhlDQogICAgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1 bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuDQogICAgcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBh bmQgY29udHJpYnV0b3IuDQoNCiAgICBJZiB5b3UgYXJlIG9uIHRoZSBNUExTIFdHIGVtYWlsIGxp c3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvcg0KICAgIGNvbnRyaWJ1dG9yLCB0 aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFu eQ0KICAgIElQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNl IHdpdGggSUVURiBydWxlcy4NCg0KDQogICAgL0xvYQ0KICAgICAgbXBscyB3ZyBjby1jaGFpcg0K DQogICAgLS0NCg0KDQogICAgTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVt YWlsOiBsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4NCiAgICBTZW5pb3IgTVBMUyBFeHBlcnQN CiAgICBCcm9uemUgRHJhZ29uIENvbnN1bHRpbmcgICAgICAgICAgICAgcGhvbmU6ICs0NiA3Mzkg ODEgMjEgNjQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== --_000_B8F9A780D330094D99AF023C5877DABA9B277ECFnkgeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTsN CglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMgMiAyIDQgMiAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAg MyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJa SC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkknbSBub3QgYXdh cmUgb2YgYW55IElQUiByZWxhdGVkIHRvIGRyYWZ0LXpoZW5nLW1wbHMtbHNwLXBpbmcteWFuZy1j ZmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UWluIFd1PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lj5Hku7bkuro8c3Bh biBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDss c2Fucy1zZXJpZiI+IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddDQo8L3NwYW4+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v 6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuS7o+ihqCA8L3NwYW4+DQo8L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mb hem7kSZxdW90OyxzYW5zLXNlcmlmIj5aaGVuZ2d1YW5neWluZyAoV2Fsa2VyKTxicj4NCjwvc3Bh bj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7o va/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMi Pjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPiAy MDE5PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+Mjwv c3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+MTE8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMi Pg0KIDk6MzE8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gU2FtIEFsZHJpbiAmbHQ7YWxkcmluLmlldGZAZ21h aWwuY29tJmd0OzsgUmVzaGFkIFJhaG1hbiAocnJhaG1hbikgJmx0O3JyYWhtYW5AY2lzY28uY29t Jmd0Ozxicj4NCjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiPiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0BpZXRmLm9yZzsg ZHJhZnQtemhlbmctbXBscy1sc3AtcGluZy15YW5nLWNmZ0BpZXRmLm9yZzxicj4NCjwvc3Bhbj48 Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi PiBSZTogW21wbHNdIElQUiBwb2xsIG9uIGRyYWZ0LXpoZW5nLW1wbHMtbHNwLXBpbmcteWFuZy1j Zmc8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGkmbmJzcDtMb2Es IGV0IGFsLiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+SSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gZHJhZnQt emhlbmctbXBscy1sc3AtcGluZy15YW5nLWNmZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPkd1YW5neWluZyBaaGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFNhbSBB bGRyaW4gWzxhIGhyZWY9Im1haWx0bzphbGRyaW4uaWV0ZkBnbWFpbC5jb20iPm1haWx0bzphbGRy aW4uaWV0ZkBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IDIwMTk8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuW5tDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4xPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7mnIg8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+MjU8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPuaXpTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4N CiA2OjU3PGJyPg0KPGI+VG86PC9iPiBSZXNoYWQgUmFobWFuIChycmFobWFuKTxicj4NCjxiPkNj OjwvYj4gTG9hIEFuZGVyc3NvbjsgPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNA aWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtemhlbmctbXBscy1sc3AtcGluZy15 YW5nLWNmZ0BpZXRmLm9yZyI+DQpkcmFmdC16aGVuZy1tcGxzLWxzcC1waW5nLXlhbmctY2ZnQGll dGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1wbHMtY2hhaXJzQGlldGYub3JnIj4NCm1wbHMt Y2hhaXJzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21wbHNdIElQUiBw b2xsIG9uIGRyYWZ0LXpoZW5nLW1wbHMtbHNwLXBpbmcteWFuZy1jZmc8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5JIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhpcyBkcmFm dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFR1ZSwgSmFuIDIy LCAyMDE5LCA2OjA2IEFNIFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pICZsdDs8YSBocmVmPSJtYWls dG86cnJhaG1hbkBjaXNjby5jb20iPnJyYWhtYW5AY2lzY28uY29tPC9hPiB3cm90ZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PkhpLDxicj4NCjxicj4NCkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRv IGRyYWZ0LXpoZW5nLW1wbHMtbHNwLXBpbmcteWFuZy1jZmcuPGJyPg0KPGJyPg0KUmVnYXJkcyw8 YnI+DQpSZXNoYWQuPGJyPg0KPGJyPg0KPGJyPg0K77u/T24gMjAxOS0wMS0xMCwgMjozMSBBTSwg JnF1b3Q7TG9hIEFuZGVyc3NvbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5udSIg dGFyZ2V0PSJfYmxhbmsiPmxvYUBwaS5udTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZuYnNw OyAmbmJzcDsgV29ya2luZyBHcm91cCwgYXV0aG9ycyw8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 IFdlIGhhdmUgc3RhcnRlZCB0byBwcmVwYXJlIHRoZSB0aGUgZHJhZnQtemhlbmctbXBscy1sc3At cGluZy15YW5nLWNmZzxicj4NCiZuYnNwOyAmbmJzcDsgZm9yIHdvcmtpbmcgZ3JvdXAgYWRvcHRp b24sIHByaW9yIHRvIHRoZSB3Z2FwIHdlIG5lZWQgdG8gZG8gYW4gSVBSIHBvbGwuPGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyBUaGlzIG1haWwgc3RhcnRzIHRoaXMgSVBSIHBvbGwuPGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyBBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRv IGRyYWZ0LXpoZW5nLW1wbHMtbHNwLXBpbmcteWFuZy08YnI+DQombmJzcDsgJm5ic3A7IGNmZz88 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IElmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9z ZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzPGJyPg0KJm5ic3A7ICZuYnNwOyAo c2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS48YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7IFRoZXJlIG5vIElQUiBkaXNjbG9zdXJlcyBhZ2FpbnN0IGRy YWZ0LXpoZW5nLW1wbHMtbHNwLXBpbmcteWFuZy1jZmcuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw OyBJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBw bGVhc2UgcmVzcG9uZCB0bzxicj4NCiZuYnNwOyAmbmJzcDsgdGhpcyBlbWFpbCByZWdhcmRsZXNz IG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50PGJyPg0KJm5i c3A7ICZuYnNwOyBJUFIuICpUaGUgcmVzcG9uc2UgbmVlZHMgdG8gYmUgc2VudCB0byB0aGUgTVBM UyBXRyBtYWlsaW5nIGxpc3QuKiBUaGU8YnI+DQombmJzcDsgJm5ic3A7IGRvY3VtZW50IHdpbGwg bm90IGFkdmFuY2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbjxi cj4NCiZuYnNwOyAmbmJzcDsgcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0 b3IuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBJZiB5b3UgYXJlIG9uIHRoZSBNUExTIFdHIGVt YWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvcjxicj4NCiZuYnNwOyAm bmJzcDsgY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlm IHlvdSBhcmUgYXdhcmUgb2YgYW55PGJyPg0KJm5ic3A7ICZuYnNwOyBJUFIgdGhhdCBoYXMgbm90 IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuPGJyPg0K PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAvTG9hPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg bXBscyB3ZyBjby1jaGFpcjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgLS0gPGJyPg0KPGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyBMb2EgQW5kZXJzc29uJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgZW1haWw6IDxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUiIHRhcmdldD0iX2JsYW5rIj4NCmxv YUBwaS5udTwvYT48YnI+DQombmJzcDsgJm5ic3A7IFNlbmlvciBNUExTIEV4cGVydDxicj4NCiZu YnNwOyAmbmJzcDsgQnJvbnplIERyYWdvbiBDb25zdWx0aW5nJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGhvbmU6ICYjNDM7NDYgNzM5IDgxIDIxIDY0PGJy Pg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQptcGxzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptcGxzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L2E+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_B8F9A780D330094D99AF023C5877DABA9B277ECFnkgeml513mbxchi_-- From nobody Sun Feb 10 19:56: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 036F112F295; Sun, 10 Feb 2019 19:56:51 -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 R1y5WsNjoYDm; Sun, 10 Feb 2019 19:56:48 -0800 (PST) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 16311127133; Sun, 10 Feb 2019 19:56:48 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id y1so4351080pgk.11; Sun, 10 Feb 2019 19:56:48 -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=lWKUzsCz2Ar51NOBqniJEavObkoW40yoZtz/CFPHZWo=; b=TJgdHc7L7jjELVUy/+DVqfu04zrbHBs9eHBnhXE8vMylwN3Or1DAZIjF6sKtXZNeki 9LJgejqBk62dGnOOWEvvYO79UDNWgqxxGO8QmxhT05BcdX2ReVGznNqjNu/LgqtkC/LK bwZ8BA38w/1Y1FFbhvF9UsjEll/yQO1V+LfPaWr1D8SEu2nreAnR0iHXu8BY0QDGr6wv vPrMNxTjf6UM4WZqW6BQqSyO0EaS3Li4COTrp205FbO3bdjVJoj2WPiuyh/IKi0a+Ezh vrZcRYpeqHh/XLX8oW0/wCmTSn5xCWAytec1YkD+5fYnbLp996oEzzaQTNzpTG027GVU miGQ== 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=lWKUzsCz2Ar51NOBqniJEavObkoW40yoZtz/CFPHZWo=; b=WwajGmOpY8Tp5a3SEBM73Ru+G/N7f5b/iduZkn57LIb0CsDIAup1iOstqvN8B4biVa KLNBBskFWzN4kW2rnoSv2tIJxmOqiulJB3G7ddgbTGv2V6FWf6KlYfpDzDF5ikx+LcYf vVwNqiPAjc8HqFb4m4FXy7yxGTHHYeqNOXyhRYcCaYdTb0wxby0Tlxf3GRIAhUp7A4T0 u1QXA7CcNq+H+HT+r3XjOQMMD6HseGvaHH0dYBZrQ6Ybi7x4L2Jvr6Z+EU4wlCiRHwVW RvClwzjZ6pFLjnkNu+R4/lSx2sTDlDrLWwiJHqYSm/z+2sIaYZuRRf7Uhjmdpj4cVjQP AKoQ== X-Gm-Message-State: AHQUAua2tZKvPFf9yqii0xg0TTNd6Yxrh1eGDQd10sTwlZjdgcToLKC9 OCaMm9iE2p8ZK4PdeE9sIDBeesdznCb4A+R5M1o= X-Google-Smtp-Source: AHgI3IbHzYO6TAsbkfrO4+c9wLh+QRoJS3iF2mqKnaDPvxQyu3UjQPG/5zTEURI3yWqQDP1GbADXTMF9PnIuEBgPjyE= X-Received: by 2002:a62:4549:: with SMTP id s70mr34439488pfa.233.1549857407298; Sun, 10 Feb 2019 19:56:47 -0800 (PST) MIME-Version: 1.0 References: <1bf361f0-1987-ce4e-0671-d46886898e44@pi.nu> In-Reply-To: <1bf361f0-1987-ce4e-0671-d46886898e44@pi.nu> From: Vishnu Pavan Beeram Date: Sun, 10 Feb 2019 22:56:35 -0500 Message-ID: To: Loa Andersson Cc: "mpls@ietf.org" , "mpls-chairs@ietf.org" , "draft-ietf-mpls-rmr@ietf.org" , Deborah A Brungard Content-Type: multipart/alternative; boundary="00000000000036f1960581964c2b" Archived-At: Subject: Re: [mpls] working group last call on draft-ietf-mpls-rmr 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 Feb 2019 03:56:51 -0000 --00000000000036f1960581964c2b Content-Type: text/plain; charset="UTF-8" Loa, Hi! Sorry for sending this in late. I have reviewed the current version (09) of this WG document. A few minor nits aside (listed below), the document is pretty well baked and ready to progress to the next stage. Regards, Pavan ** Nits: -- Section 1.1 Ring ID (RID): A non-zero number that identifies a ring; this is unique in some scope of a Service Provider's network. A node may belong to multiple rings. The above can be interpreted as the Ring ID being always a non-zero number. Consider adding something in the terminology section to signify that "RID=zero" (promiscuous node) is a special case. Same section: Ring links: Links that connnect ring neighbors. Express links: Links that connnect non-neighboring ring nodes. Fix typo in both definitions -- s/connnect/connect Also, in the same section: P_jk (Q_jk): A Path (Resv) message sent by R_j for RL_k. The above notation isn't used in this document or in either of the two RSVP RMR documents that have been published so far. Consider removing it from this document (it can be added in the base RSVP RMR document if needed). -- Section 3.3.1 The use of express links will be described in a future version of this document. Please remove the above statement if there are no plans to add more text on "express links" in this document. -- Section 4.1 MBZ (MUST be zero) isn't a well-known abbreviation. Please expand it. -- Section 4.3 ..other nodes in the ring to identify the ring master. There should be exaclty one; if not, each node restarts timer T2 and tries again. Fix typo -- s/exaclty/exactly -- Section 4.5 The removal of the last ring link between two nodes, or the removal of a ring node is an event that triggers protection switching. In a simple ring, the result is a broken ring. However, if a ring has express links, then it may be able to converge to a smaller ring with protection. Details of this process will be given in a future version. Please remove the last statement from the above paragraph if there are no plans to add more text on "express links" in this document. Also, in the same section: The addition of a new ring node can also be handled incrementally. Again, the details of this process will be given in a futre version. The last sentence needs to be removed/corrected. -- Section 5 A future version of this document will specify protocol-independent details about ring LSP signaling. The above statement needs to be removed if there are no plans of specifying the protocol-independent signaling details in this document. Consider replacing it with something along the following lines: The ring LSP signaling procedures will be described in the companion signaling documents. -- On Tue, Jan 15, 2019 at 3:11 AM Loa Andersson wrote: > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-rmr. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > There are no IPR disclosures directly against draft-ietf-mpls-rmr, but > an IPR (#2661) were disclosed against the individual document that we > adopted as a working group document. > > Both authors have stated on the working group mailing list that they > are unaware of any non-disclosed IPRs that relates to this document. > > This working group last call ends Wednesday January 30, 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 > --00000000000036f1960581964c2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Loa, Hi!

Sorry for sending th= is in late. I have reviewed the current version (09) of this WG document. A= few minor nits aside (listed below), the document is pretty well baked and= ready to progress to the next stage.

Regards,
Pavan

**Nits:

--
Section 1.1

=C2=A0=C2=A0 Ring ID (RID):=C2=A0 = A non-zero number that identifies a ring; this is
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 unique in some scope of a Service Provider's network.=C2=A0 A= node may
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 belong to multiple rings.
The above can be interpreted as the Ring ID being always a non-zero numbe= r. Consider adding something in the terminology section to signify that &qu= ot;RID=3Dzero" (promiscuous node) is a special case.

Same secti= on:

=C2=A0=C2=A0 Ring links:=C2=A0 Links that connnect ring neighbor= s.
=C2=A0=C2=A0 Express links:=C2=A0 Links that connnect non-neighboring= ring nodes.

Fix typo in both definitions -- s/connnect/connect
<= br>Also, in the same section:

=C2=A0=C2=A0 P_jk (Q_jk):=C2=A0 A Path= (Resv) message sent by R_j for RL_k.

The above notation isn't u= sed in this document or in either of the two RSVP RMR documents that have b= een published so far. Consider removing it from this document (it can be ad= ded in the base RSVP RMR document if needed).

--


Section = 3.3.1

=C2=A0=C2=A0 The use of express links will be described in a f= uture
=C2=A0=C2=A0 version of this document.

Please remove the a= bove statement if there are no plans to add more text on "express link= s" in this document.

--

Section 4.1

MBZ (MUST be = zero) isn't a well-known abbreviation. Please expand it.

--
=
Section 4.3

=C2=A0=C2=A0 ..other nodes in the ring to identify t= he ring master.=C2=A0 There should be
=C2=A0=C2=A0 exaclty one; if not, = each node restarts timer T2 and tries again.

Fix typo -- s/exaclty/e= xactly

--

Section 4.5

=C2=A0=C2=A0 The removal of the= last ring link between two nodes, or the removal
=C2=A0=C2=A0 of a ring= node is an event that triggers protection switching.=C2=A0 In a
=C2=A0= =C2=A0 simple ring, the result is a broken ring.=C2=A0 However, if a ring h= as
=C2=A0=C2=A0 express links, then it may be able to converge to a smal= ler ring with
=C2=A0=C2=A0 protection.=C2=A0 Details of this process wil= l be given in a future
=C2=A0=C2=A0 version.

Please remove the la= st statement from the above paragraph if there are no plans to add more tex= t on "express links" in this document.

Also, in the same s= ection:

=C2=A0=C2=A0 The addition of a new ring node can also be han= dled incrementally.
=C2=A0=C2=A0 Again, the details of this process will= be given in a futre version.

The last sentence needs to be removed/= corrected.

--

Section 5

=C2=A0=C2=A0 A future version = of this document will specify protocol-independent
=C2=A0=C2=A0 details = about ring LSP signaling.

The above statement needs to be removed if= there are no plans of specifying the protocol-independent signaling detail= s in this document. Consider replacing it with something along the followin= g lines:

=C2=A0=C2=A0 The ring LSP signaling procedures will be desc= ribed in the companion=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0 signaling documen= ts.

--


On Tue, Jan 15, 2019 at 3:11 AM Loa Anders= son <loa@pi.nu> wrote:
Working Group,

This is to initiate a two week working group last call on
draft-ietf-mpls-rmr.

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

There are no IPR disclosures directly against draft-ietf-mpls-rmr, but
an IPR (#2661) were disclosed against the individual document that we
adopted as a working group document.

Both authors have stated on the working group mailing list that they
are unaware of any non-disclosed IPRs that relates to this document.

This working group last call ends Wednesday January 30, 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
--00000000000036f1960581964c2b-- From nobody Sun Feb 10 22:48: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 D136012894E for ; Sun, 10 Feb 2019 22:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sjcfr1SpOO6q for ; Sun, 10 Feb 2019 22:48:27 -0800 (PST) Received: from mx05.telecomitalia.it (mx05.telecomitalia.it [156.54.232.21]) (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 DA05C12008A for ; Sun, 10 Feb 2019 22:48:26 -0800 (PST) X-AuditID: 0a5a2d15-c1bff70000007a41-fe-5c611ab63e5d Received: from TELMBXC12BA020.telecomitalia.local ( [10.90.43.46]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx05.telecomitalia.it () with SMTP id 2B.96.31297.6BA116C5; Mon, 11 Feb 2019 07:48:22 +0100 (CET) From: Di Giglio Andrea To: Filippo Cugini , "mpls@ietf.org" Thread-Topic: [EXT] Re: [mpls] working group last call on draft-ietf-mpls-rmr Thread-Index: AQHUwWRY4ygoeQhjsU6E7mEsoBlDB6XZbNGAgAC79Rc= Date: Mon, 11 Feb 2019 06:48:22 +0000 Message-ID: <-swvw36-24owcn-trgxf1-n3k8b5-c86ulj-qqxs0i-cjp2eh-ur8dbwf50yvj-39lr5e2oquj6-wf74dpuqdydo-lgm5uvqam14c-586xdu-73w7dt-fvk33x8hla-e2hk80j8w939xdvn1x-3cya0l-fx9iyt.1549867701735@email.android.com> References: , In-Reply-To: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-ti-disclaimer: Disclaimer1 Content-Type: multipart/alternative; boundary="_000_swvw3624owcntrgxf1n3k8b5c86uljqqxs0icjp2ehur8dbwf50yvj3_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDKsWRmVeSWpSXmKPExsXCFaWtp7tNKjHGYPUMXYtTTetZLG4tXcnq wORx7vQnRo8lS34yBTBFNTDaJObl5ZcklqQqpKQWJ9squWQWJ+ckZuamFimEpOakJufnKilk ptgqGSspFOQkJqfmpuaV2ColFhSk5qUo2XEpYAAboLLMPIXUvOT8lMy8dFslz2B/XQsLU0td QyW7wNLU4pJ8hdzU4uLE9PTMfIXUhPWCGZtP/GQvWBla8XLVTPYGxo+eXYycHBICJhKrPm5i 72Lk4hASmMwk8e7BZEaQBJuApUTDtfXsILaIgI/EqgezmUFsYQFfiUtnHjBCxH0lmhYuYoOw rSQezrrBAmKzCKhKzN68HWwor8BZRon9E5rBmoUE6iX6Lk0HK+IUsJZYfe0t2CBGAVmJCbsX gdnMAuISL6afYIe4TkBiyZ7zzBC2qMTLx/9YIWwDia1L97FA2DISC49MBopzAPXmS1x4KgoS 5hUQlDg58wkLxFpdiZvTzrBMYBSZhWTDLISOWUg6IEp0JBbs/sQGYWtLLFv4mhnGPnPgMROy +AJG9lWMorkVBqZ6JZCozCxJzMlM1Mss2cQITiK6ojsY39xwPsQowMGoxMOrJpwYI8SaWFZc mXuIUYKDWUmEd50oUIg3JbGyKrUoP76oNCe1+BCjDzAgJzJLiSbnAxNcXkm8oYmFpaGxhYWR oYWZKQ5hJXHez3axMUIC6cC0lp2aWpBaBDOOiYNTqoGR5dHURf6NLPF/yw2YjWNyfs35LiUa IyeYlLDkAcvbBevPnl/lEn311HLD2RMvX2/7ulpHvkS7fvXkTJmce+dvma7jT538mPvk9EPT 6+Ye7Yh22f3gz6NiBuvZRWGPP7Rv4brWvl+Ud1HdscBXOkxP+2euk3/C7G/32WXD2tMTU5ZU THvz9wxXshJLcUaioRZzUXEiAPvMTktPAwAA Archived-At: Subject: [mpls] Ris: [EXT] Re: working group last call on draft-ietf-mpls-rmr 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 Feb 2019 06:48:31 -0000 --_000_swvw3624owcntrgxf1n3k8b5c86uljqqxs0icjp2ehur8dbwf50yvj3_ Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable +1 Best regards Andrea Inviato dal mio dispositivo mobile Huawei -------- Messaggio originale -------- Oggetto: [EXT] Re: [mpls] working group last call on draft-ietf-mpls-rmr Da: Filippo Cugini A: mpls@ietf.org CC: +1 Support Filippo Il 10/02/2019 18:15, Gino Carrozzo ha scritto: Dear WG chair & mailing list though not directly writing the related proto specification I-Ds, I support= the adoption of this draft. br Gino -----Mensaje original----- De: Loa Andersson > Enviado el: s?bado, 9 de febrero de 2019 11:19 Para: mpls-chairs@ietf.org; draft-ietf-mpls-rmr= @ietf.org Asunto: Re: working group last call on draft-ietf-mpls-rmr Authors, I'm holding of the closing of this wglc, there are two reasons: - we only have one response to the mailing list, can you please help me get a few more, at least the people writing documents that are based on this one should respond - I asked for a RTG Dir review, that is no in yet, bit I have a promise that it will appear soon /Loa On 2019-01-15 16:10, Loa Andersson wrote: > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-rmr. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > There are no IPR disclosures directly against draft-ietf-mpls-rmr, but > an IPR (#2661) were disclosed against the individual document that we > adopted as a working group document. > > Both authors have stated on the working group mailing list that they > are unaware of any non-disclosed IPRs that relates to this document. > > This working group last call ends Wednesday January 30, 2019. > > /Loa > mpls wg co-chair -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Gino Carrozzo Deputy Head of R&D mobile : +39 348 7610 081 landline : +39 050 3871 679 fax : +39 050 3871 601 e-mail : g.carrozzo@nextworks.it web : www.nextworks.it address : Nextworks s.r.l. via Livornese, 1027 56122 S.Piero a Grado, Pisa, ITALY =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, please delete this message and any attachments and advise the sender= by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. --_000_swvw3624owcntrgxf1n3k8b5c86uljqqxs0icjp2ehur8dbwf50yvj3_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1
Best regards
Andrea

Inviato dal mio dispositivo mobile Huawei

-------- Messaggio originale --------
Oggetto: [EXT] Re: [mpls] working group last call on draft-ietf-mpls-rmr
Da: Filippo Cugini
A: mpls@ietf.org
CC:

+1

Support

  Filippo


Il 10/02/2019 18:15, Gino Carrozzo ha scritto= :
Dear WG chair & mailing list

though not directly writing the related proto specification I-Ds, I sup= port the adoption of this draft.

br
Gino

-----Mensaje original-----
De: Loa Andersson <loa@pi.= nu>
Enviado el: sábado, 9 de febrero de 2019 11:19
Para: mpls-chairs@ietf.or= g; draft-ietf= -mpls-rmr@ietf.org
Asunto: Re: working group last call on draft<= /span>-ietf-mpls-rmr

Authors,

I'm holding of the closing of this wglc, there are two
reasons:

- we only have one response to the mailing list, can you
   please help me get a few more, at least the people writing
   documents that are based on this one should respond
- I asked for a RTG Dir review, that is no in yet, bit I have
   a promise that it will appear soon

/Loa

On 2019-01-15 16:10, Loa Andersson wrote:
> Working Group,
>
> This is to initiate a two week working group last call on
> draft-iet= f-mpls-rmr.
>
> Please send your comments to the mpls wg mailing list (mpls@ietf.o= rg).
>
> There are no IPR disclosures directly against draft-ietf-mpls-rmr, but
> an IPR (#2661) were disclosed against the individual document that we > adopted as a working group document.
>
> Both authors have stated on the working group mailing list that they=
> are unaware of any non-disclosed IPRs that relates to this document. >
> This working group last call ends Wednesday January 30, 2019.
>
> /Loa
> mpls wg co-chair

--


Loa Andersson                 =       email: loa@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting             phon= e: +46 739 81 21 64  

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
  Dr. Gino Carrozzo
  Deputy Head of R&= ;D

  mobile    = : +39 348 7610 081
  landline  : = 3;39 050 3871 679                 &n= bsp;
  fax     &n= bsp;   : +39 050 3871 601            =      
  e-mail    = : g.carrozzo@nextworks.it              =  
  web     &n= bsp; : www.nextworks.it               <= /font>
  address   : Nex= tworks s.r.l.
       =           via Livornese, 1027      =                  
       =           56122 S.Piero a Grado, Pisa, ITALY  = ;                    
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

_______________________________________________
mpls mailing list
mpls@iet=
f.org
https://www.ietf.org/mailman/listinfo/mpls
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle= persone indicate. La diffusione, copia o qualsiasi altra azione derivante d= alla conoscenza di queste informazioni sono rigorosamente vietate. Qualora a= bbiate ricevuto questo documento per errore siete cortesemente pregati di da= rne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie.

This e-mail and any attachments is confidential and may contain privil= eged information intended for the addressee(s) only. Dissemination, copying,= printing or use by anybody else is unauthorised. If you are not the intende= d recipient, please delete this message and any attachments and advise the s= ender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessa= rio.
--_000_swvw3624owcntrgxf1n3k8b5c86uljqqxs0icjp2ehur8dbwf50yvj3_-- From nobody Mon Feb 11 07:01:35 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 6C800128D52; Mon, 11 Feb 2019 07:01:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Susan Hares To: Cc: draft-ietf-mpls-rmr.all@ietf.org, mpls@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154989728538.29584.3746504660070934932@ietfa.amsl.com> Date: Mon, 11 Feb 2019 07:01:25 -0800 Archived-At: Subject: [mpls] Rtgdir early review of draft-ietf-mpls-rmr-09 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 Feb 2019 15:01:25 -0000 Reviewer: Susan Hares Review result: Not Ready This is a routing directorate review. As such, it should be considered the same as other later WG LC review. overall-comment: Well-written and an exciting new direction. I appreciate Kireeti and Luis work on this topic. major concerns: 1) security (section 8), 2) long-term stability of architecture discussion, 3) FRR/Protection sections (3.6/3.7), and 4) amount of traffic that auto-discovery will place on the network. caveat: I have not been an WG participant for these discussions. As such, I am a "fresh" pair of eyes to read the current specification. Major concerns ======= 1) Section 8 - Security considerations. "This section states 'It is not anticipated that either the notion of MPLS rings or the extensions to various protocols to support them will cause security loopholes." This statement provides an opinion of the authors without any reasoning behind it. As such, it provide no utility to the reader. Inquiring minds would like to know "why" the authors feel this true and on what basis. Launching a new type of structure within the MPLS cloud that auto-configures it self with a great deal of message exchange does not appear to have these qualities. Surely, these authors have considered or tried these issues. 2) Long-term stability of document - in the face of repeated statements of a future version of this document. If this is just an interim document, then why is it being standardized. In a specification that is going to include an RFC track, the sttaements of scope seem inappropriate in sections 1, 3.3, 4.5, 5, 7.1, and 7.2). This scope should be gathered to a particular place and stated in another. I agree with the concept of deployment and then refinement of the protocol mechanisms. However, this document seems to anticipate quick refinement of the basic architeture. If this is really true, then why is this document going ot the IESG. If this is not true, then the scoping in above sections needs to be refined. 3) Fast re-routing installation puts details (3.6) before concepts of protection. Only after I read section 3.7, did section 3.6 start to make sense. If you re-ordered the sections, perhaps you could provide additonal depth to section 3.6. 4) paragraph 4.3, last sentence "The nodes that set their M bit should be extra careful in advertising their M Bit in subsequent tries". As an engineering, I find this description to avoid many of the problems about how long the bidding for master will take. Is there a potential for the bidding to repeat over and over. If so, how does the operator detect it. Can something drop the nodes into membership phase or re-identification phase repeated? While the ring announcement and ring identification cycle become a denial-of-service attack on the IGPs announcing the information? I suspect the authors have investigated these points, but the architeture document is the place to indicate why the architecture prevents these problems. As an editor, I find the anthropomorphism to be unwarranted in the text. While it took me to flights of fantasy where the nodes became intelligent silicon life forms, I suspect that is not what the authors wanted. Perhaps after clarifying the engineering point, the authors can rewrite the sense of the text. brief editorial nits: 1) page 4, node index linke /upto/ to /up to/ 2) page 5 (Q_jk): - not define earlier, please define it. 3) page 5, section 3 paragraph 2, sentence file sentence: current: /The default is to send traffic along the shortest path./ new: /The default policy is to send traffic along the shortest path./ 4) page 6, section 3.3 sentences 2 current:/ The last attribute means/ new: /The "auto-bundled" attribute means/ While the authors first formi is current, the change makes a specification clear. 5) page 3.5 - please spell out the first use of UHP 6) section 3.6/3.7 - could use a diagram. 7) page 11, section 4.3, paragraph 2, sentence 2 (spelling) - old/exaclty one;/ new/exactly one/ From nobody Mon Feb 11 07:38: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 3D2F9131031 for ; Mon, 11 Feb 2019 07:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 QAzk7Lv1Tpxt for ; Mon, 11 Feb 2019 07:38:00 -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 5254713102A for ; Mon, 11 Feb 2019 07:38:00 -0800 (PST) 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 x1BFajTu001522 for ; Mon, 11 Feb 2019 07:37:59 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=SmImIw+v5zGMYsPXKNZgIFhLA9OtUqTpigxtjGlWUXs=; b=mXRgGiZrm7HXe5bqOFzjMJaCFEDFxLP5Dc3i1+e4K/ylP/L1gPhcdD4NPLytziwk8Tde U8iWjeFlUrXS0ZndtJJyGy1ghYeFBesf4LEu3LHvTPBDZb8pdQVi9PJrBnaZ74taHLH1 GvAGq5GRHacabTkThm+lk+0iPTXeMACHQpWzZdGKXAon9HUVWzISuhKBITIoQiyqUpru wGMRy9vhMY53UthbSprctJS2TrR8G1fSte2SX0vlU0oMURp9NribwlWr3KF2T5L1JPrr +HpRTX2ydSKWtIXnQQHsNaGOgIv3qOSKGTWFpjJBgivr77DgDEQAwakhs5EiLSrrUP/s 3A== Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp2051.outbound.protection.outlook.com [104.47.37.51]) by mx0a-00273201.pphosted.com with ESMTP id 2qk64rrgea-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 11 Feb 2019 07:37:59 -0800 Received: from BN7PR05MB4243.namprd05.prod.outlook.com (52.133.222.152) by BN7PR05MB3955.namprd05.prod.outlook.com (52.132.216.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.14; Mon, 11 Feb 2019 15:37:57 +0000 Received: from BN7PR05MB4243.namprd05.prod.outlook.com ([fe80::c526:18a2:b633:fd25]) by BN7PR05MB4243.namprd05.prod.outlook.com ([fe80::c526:18a2:b633:fd25%6]) with mapi id 15.20.1622.016; Mon, 11 Feb 2019 15:37:57 +0000 From: Ron Bonica To: "mpls@ietf.org" Thread-Topic: working group last call on draft-ietf-mpls-rmr Thread-Index: AdTCH8IwGds6UcC3TP62ZuOO/cnxlg== Date: Mon, 11 Feb 2019 15:37:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN7PR05MB3955; 6:NW3XPNMP4R3DPPEZs9kIqAiUhMwCOFtu7LG48NAl5NJjOuJ+nM+ZY+bUcXU4/uPP+wRqfskVIT9tJiG7b7xP3A1yKZ7rQTuTJSLnHJnVB29OOY+KArJfi5CwpEquogfKcu3NPWbLRKgLguXMFtWO2QWmB8yBptiTT2gQC8VL9Fkr+fEAOmO+EX/fMgf0byitoGmdTxxlVVmRvP+jq+XkyysGGOOZ/9P8Okz7hMmVEIFe6caA750BDu3S2FFUjsuDlzWEEX8j+/8qjZHKdZukQ5qSY7mdZHZdWkssGhAgGbX9GE/I463R94R9m+oczhU5jaEsz/YPJGCeYhp3rWR1HDS5i7i2Guz96Fz8IsPgMBQBo857mqNcozGaHauCsD/P9LwxnPZXgmVw+5Ppxgf90N3oDnOZpzbI1494ILf5mNnGJWVDum1N9nKfTVzJ25CgCEm6IYShR77IzQkNvszYfA==; 5:9SoHdsuQs4F1l3wMzgPPhqc0hsr4iCs0YR00nxsvqlU1GPFCUcpx3BVV7JBWtIJWqfkzlZmCRf20Htgu7LyAY8O5OZPnJRLyGTjuK/FarL8liO0kHfdX7VoXhVv8MYERRnSlcAXgQEZdgGu6Pgl7kX7SFFSfILvnrY43pkYFk5LmTqTpUZ6oSXBj2Ws2kvQzPux07l7PZP02lP0gTjcQmA==; 7:PmCMW5sEhnf1EQwQDZZmkb1INNFnuYvFGXC8OVyu+T7N4xIehvNOmIvCYplYoSgS4+0JF8GsYDG9CvryOCGA5AEQkh4eZk/UEU6nCyKoVzjAh2anRtpKqaD0KzKnv1iQyg8Mz/lwA6ru8vuhvJ9YHA== x-ms-office365-filtering-correlation-id: edb81edf-d476-4806-9199-08d69036e5a3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:BN7PR05MB3955; x-ms-traffictypediagnostic: BN7PR05MB3955: x-microsoft-antispam-prvs: x-forefront-prvs: 0945B0CC72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(39860400002)(346002)(366004)(136003)(51444003)(189003)(199004)(316002)(478600001)(25786009)(66066001)(14454004)(68736007)(558084003)(256004)(71200400001)(186003)(476003)(486006)(26005)(6246003)(6916009)(4270600006)(7696005)(71190400001)(99286004)(6506007)(102836004)(6346003)(2501003)(86362001)(19618925003)(2906002)(3846002)(6116002)(5640700003)(9686003)(8936002)(97736004)(53936002)(229853002)(55016002)(6436002)(7736002)(305945005)(74316002)(81166006)(33656002)(81156014)(8676002)(2351001)(106356001)(105586002)(1730700003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR05MB3955; H:BN7PR05MB4243.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: JKdqSRvx2pushNSgvr14PoTE/7p5eBm5/cR/V/NwCQnJEjftS4WY6GTnhUX8SZ9hj/iToWNHz8h2GX6AH6OIpcREDVQhaqXzbWv2Kd+lY31AoAn0gEv6BpLhmoZ1Xyet2Ym7FpK1qY5kWEg9JGG5CRAW46XqI5bIAjK3fgzNxcfpR87AJypduy8lqdEZhqE5dW6q4Qh3sUMBha0uPZLhE3NmSw9vQb0uXCXW5MChNq2At4x80TI7rb/ujYxrktZE5qYW1JmA3rPmo9Z43xUU0CYERSZVtxkdHrcWe437QPa1w62ltQ19uYlWT1G9q0xnMJuExlPA4dWfHc73YSI+ZPl/ZyvpeozT7+4opXGAwqAqKjPtSzgiJFm/C1lsqzkRPnReZvxawURUtUHtK2FWSlUSeSVbyi71CEnb9Sn3dh4= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: edb81edf-d476-4806-9199-08d69036e5a3 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2019 15:37:57.3378 (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: BN7PR05MB3955 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-11_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=625 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902110118 Archived-At: Subject: Re: [mpls] working group last call on draft-ietf-mpls-rmr 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 Feb 2019 15:38:02 -0000 Loa, I think that the draft is ready for publication. Ron From nobody Mon Feb 11 07:48: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 6E69013104F for ; Mon, 11 Feb 2019 07:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_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 5dn-DaB4lzfy for ; Mon, 11 Feb 2019 07:48:36 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 2315D131047 for ; Mon, 11 Feb 2019 07:48:36 -0800 (PST) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1BFkoKk007102; Mon, 11 Feb 2019 07:48:35 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=aN1hmtzLkAj0ugiYLm5nTtC1b2LSufb+OUZANdBFrEo=; b=JzFF5JXGZmjx0gIjICmmKNW5C7khtKd54VyC1hSQMjnPQDmgHWGr66AmHZvblQLYEyBe hUDXvKddoSo+1HIQR8XhUXB2YojWZkkFJ2C+zezzdoKzie4qrHQ33nmBIi0n6Y6/hveG b/YvQfMYtKOiJZA+q3/MC2Ug0JAJl2Bh82T5BCTeagQYUKKv/Rv+QSf6mGxOI9VrrKUe QuZkqZo7wUBQhBGpGIXOMAhNHA7GNyPEWJm/waxVIhtInFW0Gr0agx/1i62tC+YCueFE GqjexJxyr18iu6+U5/89PodhLtlW3wn51dA+b9gWxMj+4ohwdhFonqfw92j2xRBcsQe3 4w== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2050.outbound.protection.outlook.com [104.47.36.50]) by mx0b-00273201.pphosted.com with ESMTP id 2qkbexg20y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 11 Feb 2019 07:48:34 -0800 Received: from CO2PR05MB2455.namprd05.prod.outlook.com (10.166.95.137) by CO2PR05MB2455.namprd05.prod.outlook.com (10.166.95.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.13; Mon, 11 Feb 2019 15:48:33 +0000 Received: from CO2PR05MB2455.namprd05.prod.outlook.com ([fe80::58b5:43a2:6964:5583]) by CO2PR05MB2455.namprd05.prod.outlook.com ([fe80::58b5:43a2:6964:5583%10]) with mapi id 15.20.1622.016; Mon, 11 Feb 2019 15:48:33 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] working group last call on draft-ietf-mpls-rmr Thread-Index: AQHUwLIfHNs7TgRofEWq/CS2mjtMdqXawK7w Date: Mon, 11 Feb 2019 15:48:32 +0000 Message-ID: References: <1bf361f0-1987-ce4e-0671-d46886898e44@pi.nu> <32e0c032-1c20-2bc1-30c3-23b3f7fb6901@pi.nu> <5B5007CC-F022-4BE6-B2B0-1D897F682BFF@telefonica.com> In-Reply-To: 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.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO2PR05MB2455; 6:UFM8x16XERpCZgnA2x5JbTG+on0+6cVOdnuAiCX4EvnoMKSvBUi9R4uA+cSOR2X4eWqxfZ2cfw640345Tb8gRgav04GokmZnfnM1ZL5EEkoDL1KfiZEThS0tcUOF+1WsVVo2NyrObjleA85DDC2qVDKaZAdfyjok2vExRXPW71nGLffjZ2Vspa9wEJbBBJWI5kjFbaylB9Ve4zOwT5goV5oy1sMUV6e99v/xj0XIp7VZqfWkBIOrh9HIDpwIlR4WGn9IUmaA1szAlmpWBRHRPfQdLjZBl5FZdDbPQDU3n/y0jA0JPymFJxTG0AfMCo5hRMmI126bmqXRXkZSK3lFbGtf4zFR3+U54JpjDUMbHQP4jIsT3jG+CuTuqvCEofqymJs00Y6DtyEoQ6WauQ0kbAMjX0xw9fX9yJ2b77ParNAg6MvI9y6gR1kyTvxNJkcrgCNhvVOqxCl8xYHcqWt4lQ==; 5:nnxxUcsYHkezDRbt7Y9p0/mqzQf7ve4a9QcFs+pJ2UBYEhDFaRFobyCgFURAmZpxJ9vEl/9TQa9FvbMQTQTR/+CN9N7YA9lJZW18nT+L0sqWklcEktq7/fqSSd8dFxvk1BQOALP72PKCtoZtgK8+MdkTu6Siq9nPLSbAA+xEoxllBQyjKQGbApBMg6jeZ+9njAr5ZIF6ujcP9r8aykMzKg==; 7:hZZS6/NauTRj5TV0xVaOyqLxlN1O1OSnhQci00lkSQTdZgnmcZRs1gmIAtF8ikNHukN0F/255EGvksvwzxGcl8d5jAsHMtUUyXlNn8+Hkiwq61IpwVPxPw/8+veO5d1w/YJKdh2tQRAYtomU4z7Vrg== x-ms-office365-filtering-correlation-id: a36ecc80-a68d-443a-c863-08d69038608c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:CO2PR05MB2455; x-ms-traffictypediagnostic: CO2PR05MB2455: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0945B0CC72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(396003)(366004)(136003)(40134004)(189003)(13464003)(199004)(966005)(53936002)(93886005)(71200400001)(8936002)(86362001)(102836004)(229853002)(478600001)(66066001)(71190400001)(9686003)(6306002)(316002)(53546011)(6506007)(110136005)(55016002)(25786009)(68736007)(8676002)(66574012)(6246003)(81166006)(7736002)(81156014)(6436002)(74316002)(305945005)(14454004)(2906002)(19627235002)(99286004)(186003)(97736004)(7696005)(14444005)(3846002)(6116002)(2501003)(256004)(76176011)(11346002)(446003)(106356001)(486006)(105586002)(33656002)(26005)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2455; H:CO2PR05MB2455.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: X05uDwt0IHPEvHbJVDKAUluqPdCe88Va0L7nBBcSJSO6zOg47h0q27rT51uuebgSJvbDJlOUkTDvXrvUYbuGk94drSYlKu/hnzSDNEfSM7AfLAavVQ38jYr7IJUgXZ7wZU0OtMlqcJT/o4O2n9ABbMctyT4feGr+LRSxIx8a+1Wzh06FoP20HB+UC+OqKeyHFpw+L02fiRzmRaqlHCPQo2eAJNDT0GzOfDyWQ2T54ovgWYspK5rhRfcVi57wpQI5NMpVV9WR+Yvq6pmaeO0dLd0cFPppakY0Zy6HhJj2aF4e74uAvfTeeamLTKNGKi9Hu7V6Njm83mmlx7IDGQJrKgpMScRsU8/NGrogHJkD/TUSfXDyS7znZANfOupeNPT0ebZmzCYBd8K7AP76+fBJP8xjNeTawoWA5SFR75smDPw= 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: a36ecc80-a68d-443a-c863-08d69038608c X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2019 15:48:32.9799 (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: CO2PR05MB2455 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-11_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-1902110119 Archived-At: Subject: Re: [mpls] working group last call on draft-ietf-mpls-rmr 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 Feb 2019 15:48:38 -0000 U3VwcG9ydCBtb3ZpbmcgaXQgcGFzdCBMQyB0byB0aGUgbmV4dCBzdGFnZS4NCg0KVGhhbmtzIQ0K SmVmZnJleQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IExvYSBBbmRl cnNzb24gPGxvYUBwaS5udT4NCj4gU2VudDogU2F0dXJkYXksIEZlYnJ1YXJ5IDksIDIwMTkgNzo0 NSBBTQ0KPiBUbzogRGllZ28gUi4gTG9wZXogPGRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5jb20+ OyBtcGxzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbXBsc10gd29ya2luZyBncm91cCBsYXN0 IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXJtcg0KPiANCj4gRGllZ28sDQo+IA0KPiBXZSBoYXZl IGhhZCBhIGJpdCB0b28gZmV3IHJlc3BvbnNlcyB0byB0aGUgd2dsYywgc28gSSdtIGhvbGRpbmcN Cj4gb2ZmIG9uIGNsb3NpbmcgdGhlIHdnbGMuIFNvIHlvdXIgY29tbWVudHMgaXMgdmVyeSB3ZWxj b21lLg0KPiANCj4gSSdtIGFsc28gd2FpdGluZyBmb3IgYSBSVEcgZGlyIEVhcmx5IHJldmlldyBi ZWZvcmUgY2xvc2luZyB0aGUNCj4gdGhlIHdnbGMuDQo+IA0KPiBJIGhvcGUgdG8gY2xvc2UgdGhl IHdnbGMgZW5kIG9mIHRoZSB3ZWVrLg0KPiANCj4gL0xvYQ0KPiANCj4gDQo+IE9uIDIwMTktMDIt MDkgMjA6MzAsIERpZWdvIFIuIExvcGV6IHdyb3RlOg0KPiA+IEhpLA0KPiA+DQo+ID4gSSBrbm93 IGl0IGlzIGEgbGl0dGxlIGJpdCBiZXlvbmQgdGhlIGVuZCBkYXRlLCBidXQgSSB3YW50IHRvIGV4 cHJlc3MgbXkNCj4gc3VwcG9ydCBmb3IgZHJhZnQtaWV0Zi1tcGxzLXJtci4gSSB0aGluayBpdCBp cyByZWFkeSB0byBwcm9ncmVzcyB0byBpdHMNCj4gcHVibGljYXRpb24uDQo+ID4NCj4gPiBCZSBn b29kZSwNCj4gPg0KPiA+ICAgIE9uIDIwMTktMDEtMTUgMTY6MTAsIExvYSBBbmRlcnNzb24gd3Jv dGU6DQo+ID4gICAgICBXb3JraW5nIEdyb3VwLA0KPiA+DQo+ID4gICAgICBUaGlzIGlzIHRvIGlu aXRpYXRlIGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24NCj4gPiAgICAgIGRy YWZ0LWlldGYtbXBscy1ybXIuDQo+ID4NCj4gPiAgICAgUGxlYXNlIHNlbmQgeW91ciBjb21tZW50 cyB0byB0aGUgbXBscyB3ZyBtYWlsaW5nIGxpc3QgKG1wbHNAaWV0Zi5vcmcpLg0KPiA+DQo+ID4g ICAgIFRoZXJlIGFyZSBubyBJUFIgZGlzY2xvc3VyZXMgZGlyZWN0bHkgYWdhaW5zdCBkcmFmdC1p ZXRmLW1wbHMtcm1yLCBidXQNCj4gPiAgICAgYW4gSVBSICgjMjY2MSkgd2VyZSBkaXNjbG9zZWQg YWdhaW5zdCB0aGUgaW5kaXZpZHVhbCBkb2N1bWVudCB0aGF0IHdlDQo+ID4gICAgIGFkb3B0ZWQg YXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KPiA+DQo+ID4gICAgIEJvdGggYXV0aG9ycyBo YXZlIHN0YXRlZCBvbiB0aGUgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgdGhhdCB0aGV5DQo+ ID4gICAgIGFyZSB1bmF3YXJlIG9mIGFueSBub24tZGlzY2xvc2VkIElQUnMgdGhhdCByZWxhdGVz IHRvIHRoaXMgZG9jdW1lbnQuDQo+ID4NCj4gPiAgICAgVGhpcyB3b3JraW5nIGdyb3VwIGxhc3Qg Y2FsbCBlbmRzIFdlZG5lc2RheSBKYW51YXJ5IDMwLCAyMDE5Lg0KPiA+DQo+ID4gICAgIC9Mb2EN Cj4gPiAgICAgbXBscyB3ZyBjby1jaGFpcg0KPiA+DQo+ID4gICAgICAtLQ0KPiA+DQo+ID4NCj4g PiAgICAgIExvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQHBp Lm51DQo+ID4gICAgICBTZW5pb3IgTVBMUyBFeHBlcnQNCj4gPiAgICAgIEJyb256ZSBEcmFnb24g Q29uc3VsdGluZyAgICAgICAgICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KPiA+DQo+ID4N Cj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4NCj4gPiBFc3Rl IG1lbnNhamUgeSBzdXMgYWRqdW50b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBhIHN1IGRl c3RpbmF0YXJpbywNCj4gcHVlZGUgY29udGVuZXIgaW5mb3JtYWNpw7NuIHByaXZpbGVnaWFkYSBv IGNvbmZpZGVuY2lhbCB5IGVzIHBhcmEgdXNvDQo+IGV4Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8g ZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBlcyB1c3RlZC4gZWwgZGVzdGluYXRhcmlvDQo+IGlu ZGljYWRvLCBxdWVkYSBub3RpZmljYWRvIGRlIHF1ZSBsYSBsZWN0dXJhLCB1dGlsaXphY2nDs24s IGRpdnVsZ2FjacOzbiB5L28NCj4gY29waWEgc2luIGF1dG9yaXphY2nDs24gcHVlZGUgZXN0YXIg cHJvaGliaWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xhY2nDs24NCj4gdmlnZW50ZS4gU2kgaGEg cmVjaWJpZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwgbGUgcm9nYW1vcyBxdWUgbm9zIGxvDQo+ IGNvbXVuaXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61hIHkgcHJvY2VkYSBh IHN1IGRlc3RydWNjacOzbi4NCj4gPg0KPiA+IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4g dGhpcyB0cmFuc21pc3Npb24gaXMgcHJpdmlsZWdlZCBhbmQNCj4gY29uZmlkZW50aWFsIGluZm9y bWF0aW9uIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50 aXR5DQo+IG5hbWVkIGFib3ZlLiBJZiB0aGUgcmVhZGVyIG9mIHRoaXMgbWVzc2FnZSBpcyBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwNCj4geW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBh bnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YNCj4gdGhpcyBjb21t dW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMNCj4gdHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBub3QgcmVhZCBpdC4gUGxlYXNlIGltbWVk aWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXINCj4gdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGNvbW11bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVsZXRlIGl0Lg0KPiA+DQo+ID4gRXN0 YSBtZW5zYWdlbSBlIHNldXMgYW5leG9zIHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1 DQo+IGRlc3RpbmF0w6FyaW8sIHBvZGUgY29udGVyIGluZm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEg b3UgY29uZmlkZW5jaWFsIGUgw6kgcGFyYQ0KPiB1c28gZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBl bnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBuw6NvIMOpIHZvc3NhIHNlbmhvcmlhIG8NCj4gZGVzdGlu YXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3RpZmljYWRvIGRlIHF1ZSBhIGxlaXR1cmEsIHV0aWxp emHDp8OjbywgZGl2dWxnYcOnw6NvDQo+IGUvb3UgY8OzcGlhIHNlbSBhdXRvcml6YcOnw6NvIHBv ZGUgZXN0YXIgcHJvaWJpZGEgZW0gdmlydHVkZSBkYSBsZWdpc2xhw6fDo28NCj4gdmlnZW50ZS4g U2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBvciBlcnJvLCByb2dhbW9zLWxoZSBxdWUgbm9zIG8N Cj4gY29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9yIGVzdGEgbWVzbWEgdmlhIGUgcHJvY2VkYSBh IHN1YSBkZXN0cnVpw6fDo28NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4gbXBsc0BpZXRmLm9yZw0K PiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4g M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX21wbHMmZD1Ed0lEYVEmYz1IQWtZdWg2 M3JzdWhyNlMNCj4gY2JmaDBVakJYZU1LLQ0KPiBuZGIzdm9EVFhjV3pvQ0kmcj1mN3dzTEdjZnpB V0ROUzZYTlRCWndqX09MQU9zWlpxZHJSMklEQXplWnFFDQo+ICZtPUpWdFFrN3F1SG80NFY2bFZI X1M3NHJDOGZCalNMdW5mS3RzeWVhN2szV2cmcz1SVTJzdzBFM1RXTmINCj4gTTJFY3BYUWVYVWxf dzM2WUtFZEZiM0VMeXduUXlYdyZlPQ0KPiA+DQo+IA0KPiAtLQ0KPiANCj4gDQo+IExvYSBBbmRl cnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQHBpLm51DQo+IFNlbmlvciBN UExTIEV4cGVydA0KPiBCcm9uemUgRHJhZ29uIENvbnN1bHRpbmcgICAgICAgICAgICAgcGhvbmU6 ICs0NiA3MzkgODEgMjEgNjQNCj4gDQoNCg== From nobody Mon Feb 11 15:03:41 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 1C9FD1311A2; Mon, 11 Feb 2019 15:03:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Cc: mpls@ietf.org, db3546@att.com, The IESG , draft-ietf-mpls-rsvp-shared-labels@ietf.org, mpls-chairs@ietf.org, Loa Andersson , rfc-editor@rfc-editor.org, loa@pi.nu MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <154992620611.29544.8131871277357953604.idtracker@ietfa.amsl.com> Date: Mon, 11 Feb 2019 15:03:26 -0800 Archived-At: Subject: [mpls] Protocol Action: 'Signaling RSVP-TE tunnels on a shared MPLS forwarding plane' to Proposed Standard (draft-ietf-mpls-rsvp-shared-labels-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: Mon, 11 Feb 2019 23:03:26 -0000 The IESG has approved the following document: - 'Signaling RSVP-TE tunnels on a shared MPLS forwarding plane' (draft-ietf-mpls-rsvp-shared-labels-09.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-rsvp-shared-labels/ Technical Summary This document defines a mechanism to prevent the maximum size of the label space limit on an LSR from being a constraint to control plane scaling on that node. It introduces the notion of pre-installed 'per Traffic Engineering (TE) link labels' that can be shared by MPLS RSVP-TE LSPs that traverse these TE links. This approach significantly reduces the forwarding plane state required to support a large number of LSPs. This couples the feature benefits of the RSVP-TE control plane with the simplicity of the Segment Routing MPLS forwarding plane. Working Group Summary No such controversies. The WG process has been very straightforward. Document Quality We know of implementation plans and implementations, this was the reason to allocate some of the code points by early allocation. However we have no detailed information. We have started an implementation poll and will update the Write-Up when we receive more information. No expert reviews necessary. Personnel Who is the Document Shepherd for this document? Loa Andersson Who is the Responsible Area Director? Deborah Brungard From nobody Mon Feb 11 22:06:43 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 D2B9D12D861; Mon, 11 Feb 2019 22:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 6t2W_Sfo9KH5; Mon, 11 Feb 2019 22:06:39 -0800 (PST) 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 AFEE512DD85; Mon, 11 Feb 2019 22:06:39 -0800 (PST) Received: from [192.168.1.20] (unknown [119.94.174.90]) (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 4750318015A3; Tue, 12 Feb 2019 07:06:36 +0100 (CET) From: Loa Andersson To: "mpls@ietf.org" Cc: "mpls-chairs@ietf.org" , "draft-zheng-mpls-lsp-ping-yang-cfg@ietf.org" Message-ID: <50a0a7c0-9849-efd9-acab-2d346c8d50f4@pi.nu> Date: Tue, 12 Feb 2019 14:06:30 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] The IPR 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: Tue, 12 Feb 2019 06:06:42 -0000 Working Group, We have an IPR poll running on draft-zheng-mpls-lsp-ping-yang-cfg. However it has stalled, since a listed contributor has not responded, Yanfeng Zhang. He his no longer employed by the same company as he were that he was lsited as a contributor. We have tried to locate him but so far we have failed. We normally wait for responses from all authors and contributors, but failing that there is a escape procedure. Here is what happens now: - if anyone has contact with Yanfeng Zhang and can contact him, please do so and ask him to respond to the IPR poll - If nothing has happened February 19, I will start the wgap, and in the mail starting the wgap explain the IPR situation. If anyone have objections to these procedure, please notify the mailing list and copy the chairs. /Loa -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Tue Feb 12 04:09: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 EA3E5124C04; Tue, 12 Feb 2019 04:09:46 -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.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mpls@ietf.org Message-ID: <154997338693.8442.70128632755287526@ietfa.amsl.com> Date: Tue, 12 Feb 2019 04:09:46 -0800 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-sfc-05.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: Tue, 12 Feb 2019 12:09:47 -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-05.txt Pages : 29 Date : 2019-02-12 Abstract: Service Function Chaining (SFC) is the process of directing packets through a network so that they can be acted on by an ordered set of abstract service functions before being delivered to the intended destination. An architecture for SFC is defined in RFC7665. The Network Service Header (NSH) can be inserted into packets to steer them along a specific path to realize a Service Function Chain. 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. Labels may also be used to establish the context under which the packet is forwarded. 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. 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-sfc-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-sfc-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 12 04:15: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 75D6B12D861; Tue, 12 Feb 2019 04:14:59 -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 fSzql_ZTHUip; Tue, 12 Feb 2019 04:14:52 -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 D809B124C04; Tue, 12 Feb 2019 04:14:51 -0800 (PST) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id x1CCDwlx029214; Tue, 12 Feb 2019 12:13:59 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AF8A62203C; Tue, 12 Feb 2019 12:13:58 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id 9A18B2203D; Tue, 12 Feb 2019 12:13:58 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.189.92]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id x1CCDun3026744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Feb 2019 12:13:57 GMT Reply-To: From: "Adrian Farrel" To: "'BRUNGARD, DEBORAH A'" Cc: , , , "'Russ Mundy'" , "'S Moonesamy'" References: <154997338693.8442.70128632755287526@ietfa.amsl.com> In-Reply-To: <154997338693.8442.70128632755287526@ietfa.amsl.com> Date: Tue, 12 Feb 2019 12:13:55 -0000 Organization: Old Dog Consulting Message-ID: <01b901d4c2cc$6de04c00$49a0e400$@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: AQHeyDsQlDAiNRdOSOriixBQq3WdsaXIB+Jw Content-Language: en-gb X-Originating-IP: 87.112.189.92 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-24424.007 X-TM-AS-Result: No--3.216-10.0-31-10 X-imss-scan-details: No--3.216-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24424.007 X-TMASE-Result: 10--3.215700-10.000000 X-TMASE-MatchedRID: qIjbTF8VzOS0upcqUpSkATPDkSOzeDWWGNMTWh+TA9trMbakJN8Oeayq cSRToWuMP4wcg9yz5nEQw9gsnchuvYLSdZH87Opg+z2c4lioPkgZskwWqoib3BorpeFcAGj3Wmr Yr8SaWTWu0yIFe9uhSw+tU2/Wp19VEfcvFiT8lxDOUnHdMlbPm2Rt0giz+0LSmyiLZetSf8nJ4y 0wP1A6ADMMszeAZpzJdB0ntd9Tzp7GVuWouVipchI/jDal3oyGwI02s83B0fx+mZzGXYipE5ttl uDezTPjzeJEZbuNC08FMKyq+I0KXSxzw6MTudPyK9AQJrddopm/ZsUSd/ERWLCf48ZV53d3afcR 7jPQH1IinlGzjbYHk3tWcHWSNHdfOOjaqoykIZw= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [mpls] FW: I-D Action: draft-ietf-mpls-sfc-05.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, 12 Feb 2019 12:14:59 -0000 Deborah, All, I made some updates, principally to the Security Considerations, as a result of comments received during IETF last call. I believe I captured everything. Thanks, Adrian -----Original Message----- From: I-D-Announce On Behalf Of internet-drafts@ietf.org Sent: 12 February 2019 12:10 To: i-d-announce@ietf.org Cc: mpls@ietf.org Subject: I-D Action: draft-ietf-mpls-sfc-05.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 : An MPLS-Based Forwarding Plane for Service Function Chaining Authors : Adrian Farrel Stewart Bryant John Drake Filename : draft-ietf-mpls-sfc-05.txt Pages : 29 Date : 2019-02-12 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-sfc/ From nobody Tue Feb 12 15:15:28 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 D3579126C15; Tue, 12 Feb 2019 15:15:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk CC: mpls@ietf.org, db3546@att.com, draft-ietf-mpls-sfc-encapsulation@ietf.org, mpls-chairs@ietf.org, Loa Andersson , loa@pi.nu Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <155001332682.8635.175028859900488100.idtracker@ietfa.amsl.com> Date: Tue, 12 Feb 2019 15:15:26 -0800 Archived-At: Subject: [mpls] Last Call: (MPLS Encapsulation For The SFC NSH) to Informational RFC 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 Feb 2019 23:15:27 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS Encapsulation For The SFC NSH' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-02-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes 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 payload. 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mpls-sfc-encapsulation/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mpls-sfc-encapsulation/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Feb 12 15:30: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 F1811126C01; Tue, 12 Feb 2019 15:30:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk CC: mpls@ietf.org, db3546@att.com, draft-ietf-mpls-sr-over-ip@ietf.org, mpls-chairs@ietf.org, Loa Andersson , loa@pi.nu Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <155001420691.8563.12845586045911946941.idtracker@ietfa.amsl.com> Date: Tue, 12 Feb 2019 15:30:06 -0800 Archived-At: Subject: [mpls] Last Call: (SR-MPLS over IP) to Proposed Standard 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 Feb 2019 23:30:07 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'SR-MPLS over IP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-02-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mpls-sr-over-ip/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mpls-sr-over-ip/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3210/ https://datatracker.ietf.org/ipr/3211/ From nobody Wed Feb 13 19:02: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 B9914130EDD; Wed, 13 Feb 2019 19:02:22 -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 qcnKyaDyHFfo; Wed, 13 Feb 2019 19:02:20 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B04130ECF; Wed, 13 Feb 2019 19:02:20 -0800 (PST) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 1F7D2A9FCB1644FFFE23; Thu, 14 Feb 2019 03:02:18 +0000 (GMT) Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 14 Feb 2019 03:02:17 +0000 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.6]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0415.000; Thu, 14 Feb 2019 11:02:08 +0800 From: Mach Chen To: Benjamin Kaduk CC: Linda Dunbar , "secdir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org" , "ietf@ietf.org" Thread-Topic: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05 Thread-Index: AQHUkY+Xr7eIQ7lWe0az4uRG6fBCdqV9d+SwgERX9oCAHShNQA== Date: Thu, 14 Feb 2019 03:02:07 +0000 Message-ID: References: <154455986336.13151.8483284555885294015@ietfa.amsl.com> <20190126211729.GJ49072@kduck.mit.edu> In-Reply-To: <20190126211729.GJ49072@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] [secdir] Secdir 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: Thu, 14 Feb 2019 03:02:23 -0000 Hi Benjamin, Sorry for the delayed response! Please see my response inline... > -----Original Message----- > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > Sent: Sunday, January 27, 2019 5:17 AM > To: Mach Chen > Cc: Linda Dunbar ; secdir@ietf.org; > mpls@ietf.org; draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org; > ietf@ietf.org > Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping= -lag- > multipath-05 >=20 > On Fri, Dec 14, 2018 at 02:11:21AM +0000, Mach Chen wrote: > > Hi Linda, > > > > Thanks for the review! > > > > Some responses inline... > > > > > -----Original Message----- > > > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Linda Dunbar > > > Sent: Wednesday, December 12, 2018 4:24 AM > > > To: secdir@ietf.org > > > Cc: mpls@ietf.org; > > > draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org; > > > ietf@ietf.org > > > Subject: Secdir last call review of > > > draft-ietf-mpls-lsp-ping-lag-multipath-05 > > > > > > 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 summary of the review is Ready with comment > > > > > > The described mechanism for LSP Multipath Ping is very clear. The > > > Security Consideration re-uses the description of RFC8029, which is > > > very comprehensive. > > > It would be better if the draft describes how to prevent > > > intermediate LSRs in between the Initiating LSR and Responding LSR > > > from mis-using the detailed link information (e.g. forwarding to > somewhere else). > > > > The Echo Request and Reply messages are directly exchanged between the > Initiating LSR and the Responding LSR, those intermediate LSRs just forwa= rd > the messages as normal packets, they will not see the detailed link > information unless if they inspect and do DPI on every packet forwarded b= y > them. > > > > The detailed link information is supplied to the Initiating LSR for usi= ng, the > intermediate LSRs will not try to use it even if they received the inform= ation, > because there is no corresponding Echo Request to the received Echo Reply= . >=20 > The intermediate LSRs still will have access to the plaintext information= , even > if in normal operation they do not need to act upon that information. > Generally in this sort of situation we will either explicitly state that = the > intermediate nodes must be trusted to not abuse the information in > question, or provide some mechanism for end-to-end confidentiality > protection. "Intermediate nodes must be trusted to not abuse the information" is normal= ly assumed. For the intermediate nodes, there is no different between the E= cho Reply messages and any other data traffic, control messages. They just = forward the Echo Reply messages as normal packets. I am not sure it needs = to explicitly state this. Do you suggest to add such a statement in the se= curity consideration section? >=20 > Also (noting that I only skimmed the document so this may not make sense)= , > the security considerations seem to suggest using an IP ACL for determini= ng > which messages are trusted; IP ACLs are generally not recommended in favo= r > of cryptographic mechanisms at this point. IP ACLs was introduced in RFC 8029 and is reused in this document, it's jus= t one of the security mechanisms. This document is an extension to RFC 802= 9, as stated in this document, all security considerations defined in RFC 8= 029 apply to this document. Do you have any specific suggestion to the curr= ent security consideration? Best regards, Mach >=20 > -Benjamin From nobody Thu Feb 14 01:12: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 052BC13115A; Thu, 14 Feb 2019 01:12:12 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] 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 ux4MeXXrSlbt; Thu, 14 Feb 2019 01:12:08 -0800 (PST) Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.65]) (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 0DFDB131056; Thu, 14 Feb 2019 01:12:07 -0800 (PST) Received: from [46.226.52.199] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-b.eu-west-1.aws.symcld.net id B2/13-19420-5E0356C5; Thu, 14 Feb 2019 09:12:05 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTe2xLcRTH9+t97E5WfrrOjjKxLosYrdYkaiH eTDyCCMmyhdv1akvbLb0dNf5YsIUyGfGYZrVHiq1m3sKQbUZGh7GEeKQemTGvCYIMwb29ncc/ J5/fOd/fOd/fzbkMofhEqxjO7eKcDtampvuR45KmZGu6dFyWbve3WINv52HS8NNXThgeHqylD K23vyND8Ck7hco47w1FZ/j9vbIM775ieiGRSVkdxlz3CspyqD1E5/3KdB/z9KBCVLHIg/oxJK 4moOZsgBIPClwqg7ebu5F0CCEIeI4THhTD0HgSnDwSoj2IYZR4BLy4ukzUEPgmgqLG9zJRE4d nwav6ElJkJZ4Nv1qKCUmfDqWl48Q0iVOg8NQjWmQ5zob7wQ9hiQKvgrriwWI6RpjU1PaAEhnh QfA1WBfuTuAEePi8IsyAMfgvthMSx8Orzp+UxElQ9rg8WuJE6KjYhiSeDz8uNFLiKMDJcLo7W 3QPuBOBr7Enok+FjUU9pMQq6LlfT0qibQPgsW9XZJgNGntvRS4MhXu7q2hJVE/Dl2p/2J0C58 C18k+k9AIjPOmqirgYBoGSZ5Gutwk437JHVopSvf+8zis4JLADrl5K94a/0UC4vv85KUlGQ+W Fj7TEo+BQ1Ruij280dcr+zVei6AAyGJ1Ws8VlZ602jV6n0+j1YzX6CRM0+rE6LVugMWq5fM1a jndp9Fp2La/l19lzbCatg3OdRMK6mfJa3edQu8d8GQ1mZOp4edodU5aivzHXtM7C8pblznwbx 19GQxlGDfJMYS0VA52cmXOvtNqEne0rAxOrVspni2U5n8faeatZKgXRZKap+pmPYHaceCHE00 /E2CBGBenIdXCqBHndGOEaFq9Z8h1/mvb9Cx0oURUnR1FRUYrYPM5pt7r+r79GCQxSx8nzxeG xVofrz+zXgi2ZYKtLaRJtudi/JVUh2nqlcsb4L80F5X7z4o8JZek56e6lQzak7LW/zPo+b3X8 3tFHV16a+86XPD14cMiZnSnL+lNBpmZmSeuWonfFEzvbQsqRd5u3J6fVdl/5nNi8JI219BZ8b mpt8zcU0DHkro7krMJpC2zrPVNtMzetKXpZWdYSsyYwZ/jhDFXDyAPHb/3g1SRvYfWphJNnfw Ph3J+2BgQAAA== X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-8.tower-287.messagelabs.com!1550135521!2301440!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 13844 invoked from network); 14 Feb 2019 09:12:04 -0000 Received: from us-west-2b.mta.dlp.protect.symantec.com (HELO EUR02-VE1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-8.tower-287.messagelabs.com with AES256-SHA256 encrypted SMTP; 14 Feb 2019 09:12:04 -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=LVGXUOW1vYNulV5h/RTx7i8y9fZynTLSXQzklzNZTzU=; b=LxTvodcXdBr5b0UFNaBvz/04d5xGaFDQoUuqvVjoAdE+G44mRIGVKMQwA1XUgIx+Y/yjzqgK9X4ui+opLQk9kR47Zoy+7hUNrBk1k7SoCvbaOpVfvcjotHUP4cwXCNX4MX+wKhDCyN0GGo/EEHUXa9jxkLAf6hMwQbO6O8hnc+c= Received: from AM6PR03MB3830.eurprd03.prod.outlook.com (20.176.243.17) by AM6PR03MB4743.eurprd03.prod.outlook.com (20.177.35.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.21; Thu, 14 Feb 2019 09:12:00 +0000 Received: from AM6PR03MB3830.eurprd03.prod.outlook.com ([fe80::54cd:c2fd:c0c8:d95]) by AM6PR03MB3830.eurprd03.prod.outlook.com ([fe80::54cd:c2fd:c0c8:d95%5]) with mapi id 15.20.1601.023; Thu, 14 Feb 2019 09:12:00 +0000 From: Alexander Vainshtein To: "spring@ietf.org" CC: Stewart Bryant , Loa Andersson , "draft-cheng-spring-mpls-path-segment@ietf.org" , "mpls@ietf.org" Thread-Topic: [spring] to progress draft-cheng-spring-mpls-path-segment Thread-Index: AQHUwRhECynjpYpi60SfZPZB3V3IGKXdkPkAgAFwWaA= Date: Thu, 14 Feb 2019 09:11:59 +0000 Message-ID: References: <0980ce7c-047c-519f-e7d5-98d32b498482@pi.nu> <9419b7d7-87ef-151f-5ed8-b0f78c6e83af@gmail.com> In-Reply-To: <9419b7d7-87ef-151f-5ed8-b0f78c6e83af@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: ed9a38d0-de3f-41c5-023d-08d6925c79f4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020); SRVR:AM6PR03MB4743; x-ms-traffictypediagnostic: AM6PR03MB4743: x-ms-exchange-purlcount: 4 x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; AM6PR03MB4743; 23:J86+JlmsVmcb/oEgsI7RsYkN2ed8qsR5OPNBFcPFL?= =?us-ascii?Q?AAf+2RUE+8MbVB98wcOY/PWIoq7vbFBfJkU/Ocm31M7BbrNciNWYjJDS/2ye?= =?us-ascii?Q?bZuTz+e6BEe00DKTWrjgJY6OuX6y4jt00gpNkWHJDM0k8rkmSweUnA/BUqG6?= =?us-ascii?Q?CfKyij57xJ8+Vhpfh3GPwYOHtd16Tf5Cn2Ofn63pz88gNDqnEALOA010Lpc7?= =?us-ascii?Q?HMIwhtxbZtjlDXEoNmujV2nqXyy/I85NtI3NIF3bNlWOSVXsm5btJduTRoUZ?= =?us-ascii?Q?P5IHqcocms/eLRRkRX5qhcwS9SHOD7Wsyq+BWLbPYdcAJZxuAW3Efphmu/Rh?= =?us-ascii?Q?hTrNPf/tef3Nb5fRTFXznx9JjJ0foVxB8bldetGfupadjoI+76BZzub8Mf02?= =?us-ascii?Q?mASiY9zmgTMQSleyPfxd+XO0DutTLK/uUhpy3Nng8a9rIg4YWA0n8aDFqh93?= =?us-ascii?Q?01ajj4f5diAu0W4mZgG1kMk2LNTyzWJCUxv2gU0/lXnZCgh46rh071Y6dLhX?= =?us-ascii?Q?D5nQhYJDWDgHEdpgr4qFpxNTciAOjD9f+XCRY5u1np6/eoegf8alZTJfLXqQ?= =?us-ascii?Q?ijHQACa46aEtwUAyH0bGayhmBTLMqGHyf46Bc4JCC4HEcFZpn3tRW0jHHNd8?= =?us-ascii?Q?gXeMmQmteCV3IRP6aRIYsu1TrXUFESPalde2ihN8xr/zo9ambmJaPzrJZpXI?= =?us-ascii?Q?E293XOYjLiYyfgDog4+zi7tNihxkGeHQKuvM+MInamqY3gtCEzOeM+Y+CDLI?= =?us-ascii?Q?fKWt27w9Z9e4ut2vmC2fae8Fnj6FyaNWRG+RFlMph1ZbKFdGLlpSOcTH3Zd4?= =?us-ascii?Q?Dp/oK2Fv/KEjqkUUkQaicLLkABMt4qEmwfkglKccqHUwV0Prd52dAYIHRBQT?= =?us-ascii?Q?DjxDI1v0D3+UdW5L6r2i+T7tnQEglWYqvAIsWErKXJ1EdjlApaKarCa0oyaV?= =?us-ascii?Q?V091H549WSy5/MhB4xevYln7tEds1s0Nddx/PJqaRPy7dVlJpHkbZOmF9WoV?= =?us-ascii?Q?jsphw01jmilYK/yu4YT4iHVVfhAHrfRWgoRDHFvYbrl4xchpsAq19l/MznjT?= =?us-ascii?Q?A2dFORcddyfDRmYcbLIbfqeMXYqUgRWfxxhEykMAMsmiifD8iN5JHrCWdXIc?= =?us-ascii?Q?YqvcyTsWJNVV43gllqSwksX5kk5swi9x+C9SAFyavKGsOpnMShkrJ0PRVK7G?= =?us-ascii?Q?xODwdN95eQ1r2RF4NWzmDdApzdhVL3eod25rN9P3anbCls9iDc61yliKP1Cb?= =?us-ascii?Q?COTqUFQP2F0BwyOO39x6cy2P8NVp7W2SvLpoEqzQpFcZnwGHbZdFh8NnyiP9?= =?us-ascii?Q?4PsXFevhu0u8zyqP9AhGjElWAgBe87AetaJf70AjscjzjY5o2z+afwFe2A8u?= =?us-ascii?Q?XCAj0CLG54aHx+nF/0E4pwRsQztbRS1f5CovJraWGF9Q5nnz05CtX2yMdf+8?= =?us-ascii?Q?cxGq5yMb1iitP7w+OOoIuZj1MTVGJ0=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 09480768F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(366004)(346002)(376002)(136003)(13464003)(189003)(199004)(106356001)(7696005)(476003)(486006)(26005)(99286004)(316002)(25786009)(71190400001)(71200400001)(6116002)(2501003)(53936002)(66066001)(105586002)(76176011)(3846002)(6346003)(6506007)(54906003)(2906002)(2351001)(229853002)(53546011)(790700001)(55016002)(97736004)(54896002)(6306002)(9686003)(186003)(6436002)(236005)(446003)(5640700003)(11346002)(102836004)(1730700003)(14444005)(6916009)(33656002)(256004)(966005)(6246003)(14454004)(68736007)(478600001)(606006)(74316002)(4326008)(7736002)(86362001)(81156014)(8936002)(8676002)(81166006)(72206003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR03MB4743; H:AM6PR03MB3830.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: bWoQHzSrQcDc64ZosZatm3H4t48JywX5HHhQp1IHXa+kVWzaRMudM47FR+6MR9osN31xLnTbOZihZphNxZVvA+g+d96/ghssucXiL3rq4kNO52tNdQr+0xy7+38OXY4hgfN/+VkZpdVi72bzfU//CqPnlB/r1Pw49mbCXWMnUh083RF1Tz0s4ikbUuZEVGyL9frg5+I0MPAdr+L/r6com+L/Us7gw84ZV+cOBdkRZhQAyQ5cuVJKpDD4NEpWCca+C+P8wBa0M2Kd139Rpk5ntQK1K3qR2NiM6MmKPgH5u1sKHtF1KiMex8Pc/JY5+MHJXDDoL5RTKbAHCoOdSfz27bRpwhC3eeIVJB8EiZqJEQW+9mZ0woaPlDA84vrv+veiqhVC/m0JiNqzTaVE8wehqaGTbgCcKttId2fXPo/2BF8= Content-Type: multipart/alternative; boundary="_000_AM6PR03MB3830EBBF1D04E91C35E7B8C99D670AM6PR03MB3830eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: ed9a38d0-de3f-41c5-023d-08d6925c79f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2019 09:11:59.8723 (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: AM6PR03MB4743 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] [spring] to progress draft-cheng-spring-mpls-path-segment 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 Feb 2019 09:12:12 -0000 --_000_AM6PR03MB3830EBBF1D04E91C35E7B8C99D670AM6PR03MB3830eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1. I have been following this draft from its -00 revision. The current revisi= on has resolved most of the issues I (and others) have been raised (e.g., = elimination of excessive options). >From my POV, in its current state the draft meets two basic requirements f= or the WG adoption: 1. It addresses a real and relevant problem, namely the MPLS Flow Id= entification problem discussed in general in RFC 8372 and scoped to SR-MPLS LSPs in this draft. Specifics of SR= -MPLS include the need to provide end-to-end liveness check that is one of= the requirements explicitly specified in Section 2 of RFC 8355. 2. It provides a reasonable (from my POV) approach to solution of t= his problem. I also concur with Stewart's comment about strong similarity between the a= pproach taken in this draft for SR-MPLS and generic work in progress on sy= nonymous flow labels that has been already adopted as a MPLS WG item. To me this is y= et another indication that the draft should be adopted. My 2c, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: spring On Behalf Of Stewart Bryant Sent: Wednesday, February 13, 2019 12:48 PM To: Loa Andersson ; spring@ietf.org; draft-cheng-spring-mpls-pa= th-segment@ietf.org Subject: Re: [spring] to progress draft-cheng-spring-mpls-path-segment I have just read the draft and agree that it should be adopted by the WG. = It solves an important problem in instrumenting and protecting an SR path.= It should be noted that we needed to do something very similar in mainstre= am MPLS via the synonymous label work which is already adopted. However SL did not address the SR case. We therefore need this path label = work to be progressed. - Stewart On 10/02/2019 08:11, Loa Andersson wrote: > Working Group, > > I have reviewed draft-cheng-spring-mpls-path-segment and as far as I > can see, it is ready for wg adoption. > > There were some comments in Bangkok, but due to the many collisions > between working groups at that meeting I couldn't attend the SPRING > f2f. > > The minutes are not clear, but as far as I understand, there is > nothing that can't be resolved in the wg process. > > /Loa _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_AM6PR03MB3830EBBF1D04E91C35E7B8C99D670AM6PR03MB3830eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1.

 

I have been following this draft from its -00 re= vision. The current revision has resolved most of the issues I (and others= ) have been raised (e.g., elimination of excessive options).

 

From my POV, in its current state the draft meet= s two basic requirements for the WG adoption:

1.       It addresses a real and r= elevant problem, namely the MPLS Flow Identification problem discussed in = general in RFC 8372 and scoped= to SR-MPLS LSPs in this draft. Specifics of SR-MPLS include the need to p= rovide end-to-end liveness check that is one of the requirements explicitl= y specified in Section 2 of RFC 8355. <= /p>

2.       It provides a reasonable = (from my POV) approach to  solution of this problem.

 

I also concur with Stewart’s comment about= strong similarity between the approach taken in this draft for SR-MPLS an= d generic w= ork in progress on synonymous flow labels that has been already adopte= d as a MPLS WG item.  To me this is yet another indication that the d= raft should be adopted.

 

My 2c,

Sasha

 

Office: +972-39266302

Cell:      +972-549= 266302

Email:   Alexander.Vainshtein@ecitele.= com

 

-----Original Message-----
From: spring <spring-bounces@ietf.org> On Behalf Of Stewart Bryant Sent: Wednesday, February 13, 2019 12:48 PM
To: Loa Andersson <loa@pi.nu>; spring@ietf.org; draft-cheng-spring-m= pls-path-segment@ietf.org
Subject: Re: [spring] to progress draft-cheng-spring-mpls-path-segment

=

 

I have just read the draft and agree that it sho= uld be adopted by the WG. It solves an important problem in instrumenting = and protecting an SR path.

 

It should be noted that we needed to do somethin= g very similar in mainstream MPLS via the synonymous label work which is a= lready adopted.

However SL did not address the SR case. We there= fore need this path label work to be progressed.

 

- Stewart

 

On 10/02/2019 08:11, Loa Andersson wrote:

> Working Group,

> 

> I have reviewed draft-cheng-spring-mpls-pat= h-segment and as far as I

> can see, it is ready for wg adoption.<= /o:p>

> 

> There were some comments in Bangkok, but du= e to the many collisions

> between working groups at that meeting I co= uldn't attend the SPRING

> f2f.

> 

> The minutes are not clear, but as far as I = understand, there is

> nothing that can't be resolved in the wg pr= ocess.

> 

> /Loa

 

_______________________________________________<= o:p>

spring mailing list

spring@ietf.org

https://www= .ietf.org/mailman/listinfo/spring


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_AM6PR03MB3830EBBF1D04E91C35E7B8C99D670AM6PR03MB3830eurp_-- From nobody Thu Feb 14 11:38: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 6469613119D; Thu, 14 Feb 2019 11:37:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 SnvI1dj6Hl0l; Thu, 14 Feb 2019 11:37:38 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 914F413119C; Thu, 14 Feb 2019 11:37:37 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id e27so5420691lfj.8; Thu, 14 Feb 2019 11:37:37 -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=mfl+sCwxkGvJxJERq3lMvJ/wolMyQgf0FZvPUf2dJIY=; b=fsh8cuIxLDW1J+LbBypZzQPi/MG8c8uJKMkmyedGx1FUzKFSMg2D/OERs3lXUqXb5q kfpz564de9cC9WszxvSlfrU9e7Uyr+bxz/KkKbellb7p8aVu7ZHnmkhHywXOzQ9mdL2D 60Q4zbYPf+pOmNUnAcEFoKypC6LU2dsGcKv3dQWftarMz2OW9ZLU4cNrlHsakRnf42ga oeLoSIky3yk3ohU4fd0XkTywAoFVYwvgkcZjGAv9O8mGwlHFGwwlXJ7j89kLkxK2wBYx bJ93apwJPbv9fcQ1Ns7xg4Vau4muLAb6DeG2ASs5A0Zuh8SknZCTFLoPo2/HwoABFlTU 3Now== 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=mfl+sCwxkGvJxJERq3lMvJ/wolMyQgf0FZvPUf2dJIY=; b=IfPpreWaZ2mHklprWBGnKZAnpR88Ejsn1ZJ8LvRMTewcyFCV6lWEtQ+E5caMJPDJQp TGMrl8EWthlNugE7uf3wDU0tQVI8anS+AKMsxjbrI0sZ8A40XfXE8EUYla3TTMXuQ9+c 3ERaz+TI49NWsJQcnW7rZHvreoIxMKXomF/+yf9QNdg32CJY4nsXOnL5Oe7ax+lPrlna yewFSElHIDxcIRyJiU1cfzb6GFDECQN5Z2LrqUHTdfvzlYglGoMMEbvEnKMl78TDPGhp Alck2YrmaILpRwThFa1Om+/mL14SEKhF344Xx2cu//J+0JDY/o8qrXVsSo0Z7UQFxt6X AXvQ== X-Gm-Message-State: AHQUAuadN2uVGRtsiM9AXkp7+k8khk7UwKQBj7iIiwe67nDERyh46V25 QoYL14awJJE8UyVPm1dXpwWSjVZYui+EVvKO2kc= X-Google-Smtp-Source: AHgI3IY8tRtlYL7VXzGJd22+yjcXLkWzL7gPo16W/t3QhbsfvPOXiYLC7Dl+4bj+1uVnJnUJjwt52XVYExIQRArHsRg= X-Received: by 2002:a19:9dd1:: with SMTP id g200mr3278526lfe.127.1550173055558; Thu, 14 Feb 2019 11:37:35 -0800 (PST) MIME-Version: 1.0 References: <0980ce7c-047c-519f-e7d5-98d32b498482@pi.nu> <9419b7d7-87ef-151f-5ed8-b0f78c6e83af@gmail.com> In-Reply-To: From: Greg Mirsky Date: Thu, 14 Feb 2019 11:37:24 -0800 Message-ID: To: Alexander Vainshtein Cc: "spring@ietf.org" , Stewart Bryant , "draft-cheng-spring-mpls-path-segment@ietf.org" , "mpls@ietf.org" , Loa Andersson Content-Type: multipart/alternative; boundary="000000000000512b060581dfca9d" Archived-At: Subject: Re: [mpls] [spring] to progress draft-cheng-spring-mpls-path-segment 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 Feb 2019 19:37:43 -0000 --000000000000512b060581dfca9d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear All, I concur with all what has been said in support of the adoption of this draft by SPRING WG. The document is well-written, addresses the real problem in SR-MPLS, and the proposed solution is technically viable. My comments and questions are entirely for further discussion: - would the draft be expanded to demonstrate how "the Path Segment may be used to identify an SR-MPLS Policy, its Candidate-Path (CP) or a SID List (SL)"? - as many use cases for the Path Segment are related to OAM operations, it would be helpful to expand on the use of GAL and the Path Segment. Regards, Greg On Thu, Feb 14, 2019 at 1:12 AM Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > +1. > > > > I have been following this draft from its -00 revision. The current > revision has resolved most of the issues I (and others) have been raised > (e.g., elimination of excessive options). > > > > From my POV, in its current state the draft meets two basic requirements > for the WG adoption: > > 1. It addresses a real and relevant problem, namely the MPLS Flow > Identification problem discussed in general in RFC 8372 > and scoped to SR-MPLS LSPs in this > draft. Specifics of SR-MPLS include the need to provide end-to-end livene= ss > check that is one of the requirements explicitly specified in Section 2 o= f RFC > 8355 . > > 2. It provides a reasonable (from my POV) approach to solution of > this problem. > > > > I also concur with Stewart=E2=80=99s comment about strong similarity betw= een the > approach taken in this draft for SR-MPLS and generic work in progress on > synonymous flow labels > that has > been already adopted as a MPLS WG item. To me this is yet another > indication that the draft should be adopted. > > > > My 2c, > > Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > > -----Original Message----- > From: spring On Behalf Of Stewart Bryant > Sent: Wednesday, February 13, 2019 12:48 PM > To: Loa Andersson ; spring@ietf.org; > draft-cheng-spring-mpls-path-segment@ietf.org > Subject: Re: [spring] to progress draft-cheng-spring-mpls-path-segment > > > > I have just read the draft and agree that it should be adopted by the WG. > It solves an important problem in instrumenting and protecting an SR path= . > > > > It should be noted that we needed to do something very similar in > mainstream MPLS via the synonymous label work which is already adopted. > > However SL did not address the SR case. We therefore need this path label > work to be progressed. > > > > - Stewart > > > > On 10/02/2019 08:11, Loa Andersson wrote: > > > Working Group, > > > > > > I have reviewed draft-cheng-spring-mpls-path-segment and as far as I > > > can see, it is ready for wg adoption. > > > > > > There were some comments in Bangkok, but due to the many collisions > > > between working groups at that meeting I couldn't attend the SPRING > > > f2f. > > > > > > The minutes are not clear, but as far as I understand, there is > > > nothing that can't be resolved in the wg process. > > > > > > /Loa > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www..ietf.org/mailman/listinfo/spring > > > _________________________________________________________________________= __ > > 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 > --000000000000512b060581dfca9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Al= l,
I concur with all what has been said in support of the adoption of t= his draft by SPRING WG. The document is well-written, addresses the real pr= oblem in SR-MPLS, and the proposed solution is technically viable.
My comments and questions are entirely for further discussion:
=
  • would the=C2=A0draft be expanded to demonstrate how "the Path = Segment may be used to identify an SR-MPLS Policy, its Candidate-Path (CP) = or a SID List (SL)"?
  • as many use cases for the Path Segment ar= e related to OAM operations, it would be helpful to expand on the use of GA= L and the Path Segment.
Regards,
Greg

On Thu, Feb 14, 2019 at 1:12 AM Alexander Vainshtein <Alexander.Vainshtein@ecit= ele.com> wrote:

+1.

=C2=A0

I have been following = this draft from its -00 revision. The current revision has resolved most of= the issues I (and others) have been raised (e.g., elimination of excessive= options).

=C2=A0

From my POV, in its cu= rrent state the draft meets two basic requirements for the WG adoption:<= /u>

1.=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 It addresses a real and relev= ant problem, namely the MPLS Flow Identification problem discussed in gener= al in RFC 83= 72 and scoped to SR-MPLS LSPs in this draft. Specifics of SR-MPLS inclu= de the need to provide end-to-end liveness check that is one of the require= ments explicitly specified in Section 2 of RFC 8355<= /a>.

2.=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 It provides a reasonable (fro= m my POV) approach to =C2=A0solution of this problem.

=C2=A0

I also concur with Ste= wart=E2=80=99s comment about strong similarity between the approach taken i= n this draft for SR-MPLS and generic work in progress on synonymous flow labels that has bee= n already adopted as a MPLS WG item.=C2=A0 To me this is yet another indica= tion that the draft should be adopted.

=C2=A0

My 2c,

Sasha

=C2=A0

Office: +972-39266302<= u>

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

Email:=C2=A0=C2=A0 Alexande= r.Vainshtein@ecitele.com

=C2=A0

-----Original Message-= ----
From: spring <spring-bounces@ietf.org> On Behalf Of Stewart Bryant
Sent: Wednesday, February 13, 2019 12:48 PM
To: Loa Andersson <loa@pi= .nu>; spring@ie= tf.org; draft-cheng-spring-mpls-path-segment@ietf.org
Subject: Re: [spring] to progress draft-cheng-spring-mpls-path-segment

=C2=A0

I have just read the d= raft and agree that it should be adopted by the WG. It solves an important = problem in instrumenting and protecting an SR path.

=C2=A0

It should be noted tha= t we needed to do something very similar in mainstream MPLS via the synonym= ous label work which is already adopted.

However SL did not add= ress the SR case. We therefore need this path label work to be progressed.<= u>

=C2=A0

- Stewart

=C2=A0

On 10/02/2019 08:11, L= oa Andersson wrote:

> Working Group,=

>=C2=A0

> I have reviewed d= raft-cheng-spring-mpls-path-segment and as far as I

> can see, it is re= ady for wg adoption.

>=C2=A0

> There were some c= omments in Bangkok, but due to the many collisions

> between working g= roups at that meeting I couldn't attend the SPRING

> f2f.

>=C2=A0

> The minutes are n= ot clear, but as far as I understand, there is

> nothing that can&= #39;t be resolved in the wg process.

>=C2=A0

> /Loa

=C2=A0

______________________= _________________________

spring mailing list=

spring@ietf.org

https://www..ietf.org/mailman/listinfo/spri= ng


___________________________________________________________________________=

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
--000000000000512b060581dfca9d-- From nobody Fri Feb 15 00:35: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 17CD6130F28; Fri, 15 Feb 2019 00:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mb43B8rIxUor; Fri, 15 Feb 2019 00:35:04 -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 884B7130E7E; Fri, 15 Feb 2019 00:35:04 -0800 (PST) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 91253463B076B3A3321B; Fri, 15 Feb 2019 08:35:02 +0000 (GMT) Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 15 Feb 2019 08:35:01 +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; Fri, 15 Feb 2019 08:35:02 +0000 Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) 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; Fri, 15 Feb 2019 08:35:01 +0000 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.6]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0415.000; Fri, 15 Feb 2019 16:34:54 +0800 From: Mach Chen To: "mpls@ietf.org" CC: "mpls-chairs@ietf.org" Thread-Topic: MPLS-RT review on draft-nainar-mpls-rfc8287-len-clarification-00 Thread-Index: AdTFCCSJ+LGMIYq7QLWdBvABpp77Vg== Date: Fri, 15 Feb 2019 08:34:54 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.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: [mpls] MPLS-RT review on draft-nainar-mpls-rfc8287-len-clarification-00 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 Feb 2019 08:35:06 -0000 Hi all, I have done the MPLS-RT review on draft-nainar-mpls-rfc8287-len-clarificati= on-00. This is a very short and well-written draft that addresses the 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 is a useful document and ready for WG adoption, even for WG last call = :-).=20 Best regards, Mach From nobody Fri Feb 15 16:41:07 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 1B4E71289FA; Fri, 15 Feb 2019 16:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.28 X-Spam-Level: X-Spam-Status: No, score=-1.28 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_RP_RNBL=1.31, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oj-0DYJIwxuT; Fri, 15 Feb 2019 16:40:55 -0800 (PST) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE5E127287; Fri, 15 Feb 2019 16:40:53 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.5]) by rmmx-syy-dmz-app05-12005 (RichMail) with SMTP id 2ee55c675c136a9-855ce; Sat, 16 Feb 2019 08:40:51 +0800 (CST) X-RM-TRANSID: 2ee55c675c136a9-855ce X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmcc (unknown[111.32.143.115]) by rmsmtp-syy-appsvr03-12003 (RichMail) with SMTP id 2ee35c675c115e8-a64b5; Sat, 16 Feb 2019 08:40:51 +0800 (CST) X-RM-TRANSID: 2ee35c675c115e8-a64b5 From: "Weiqiang Cheng" To: "'Greg Mirsky'" , "'Alexander Vainshtein'" Cc: , "'Stewart Bryant'" , , , "'Loa Andersson'" References: <0980ce7c-047c-519f-e7d5-98d32b498482@pi.nu> <9419b7d7-87ef-151f-5ed8-b0f78c6e83af@gmail.com> In-Reply-To: Date: Sat, 16 Feb 2019 08:40:49 +0800 Message-ID: <050301d4c590$445f5d50$cd1e17f0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0504_01D4C5D3.52829D50" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdTEnLWGUqstE6FFTsuVHdcBGm8kCgA8RPPw Content-Language: zh-cn Archived-At: Subject: [mpls] =?utf-8?b?562U5aSNOiBbc3ByaW5nXSB0byBwcm9ncmVzcyBkcmFm?= =?utf-8?q?t-cheng-spring-mpls-path-segment?= 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, 16 Feb 2019 00:40:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0504_01D4C5D3.52829D50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks a lot for your comments. My comments are in-line. =20 B.R. Weiqiang Cheng =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B42=E6=9C=8815=E6=97=A5 = 3:37 =E6=94=B6=E4=BB=B6=E4=BA=BA: Alexander Vainshtein =E6=8A=84=E9=80=81: spring@ietf.org; Stewart Bryant; = draft-cheng-spring-mpls-path-segment@ietf.org; mpls@ietf.org; Loa = Andersson =E4=B8=BB=E9=A2=98: Re: [spring] to progress = draft-cheng-spring-mpls-path-segment =20 Dear All, I concur with all what has been said in support of the adoption of this = draft by SPRING WG. The document is well-written, addresses the real = problem in SR-MPLS, and the proposed solution is technically viable. My comments and questions are entirely for further discussion: * would the draft be expanded to demonstrate how "the Path Segment may = be used to identify an SR-MPLS Policy, its Candidate-Path (CP) or a SID = List (SL)"? [Weiqiang] Yes, It is necessary and we will add some text to demonstrate = this in the future version.=20 * as many use cases for the Path Segment are related to OAM operations, = it would be helpful to expand on the use of GAL and the Path Segment. [Weiqiang] It is always helpful to have more use cases. However, = The GAL is used today in MPLS-TP LSPs to flag the G-Ach and is used for = OAM packets only while the Path segment is used for data packets for the = each traffic flow. It is a little bit different.=20 Regards, Greg =20 On Thu, Feb 14, 2019 at 1:12 AM Alexander Vainshtein = wrote: +1. =20 I have been following this draft from its -00 revision. The current = revision has resolved most of the issues I (and others) have been raised = (e.g., elimination of excessive options). =20 >From my POV, in its current state the draft meets two basic requirements = for the WG adoption: 1. It addresses a real and relevant problem, namely the MPLS Flow = Identification problem discussed in general in RFC 8372 = and scoped to SR-MPLS LSPs in = this draft. Specifics of SR-MPLS include the need to provide end-to-end = liveness check that is one of the requirements explicitly specified in = Section 2 of RFC 8355 .=20 2. It provides a reasonable (from my POV) approach to solution of = this problem. =20 I also concur with Stewart=E2=80=99s comment about strong similarity = between the approach taken in this draft for SR-MPLS and generic work in = progress on synonymous flow labels = that has = been already adopted as a MPLS WG item. To me this is yet another = indication that the draft should be adopted. =20 My 2c, Sasha =20 Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com =20 -----Original Message----- From: spring On Behalf Of Stewart Bryant Sent: Wednesday, February 13, 2019 12:48 PM To: Loa Andersson >; spring@ietf.org; = draft-cheng-spring-mpls-path-segment@ietf.org Subject: Re: [spring] to progress draft-cheng-spring-mpls-path-segment =20 I have just read the draft and agree that it should be adopted by the = WG. It solves an important problem in instrumenting and protecting an SR = path. =20 It should be noted that we needed to do something very similar in = mainstream MPLS via the synonymous label work which is already adopted.=20 However SL did not address the SR case. We therefore need this path = label work to be progressed. =20 - Stewart =20 On 10/02/2019 08:11, Loa Andersson wrote: > Working Group, >=20 > I have reviewed draft-cheng-spring-mpls-path-segment and as far as I=20 > can see, it is ready for wg adoption. >=20 > There were some comments in Bangkok, but due to the many collisions=20 > between working groups at that meeting I couldn't attend the SPRING=20 > f2f. >=20 > The minutes are not clear, but as far as I understand, there is=20 > nothing that can't be resolved in the wg process. >=20 > /Loa =20 _______________________________________________ spring mailing list spring@ietf.org = https://www..ietf.org/mailman/listinfo/spring _________________________________________________________________________= __ This e-mail message is intended for the recipient only and contains = information which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have = received this=20 transmission in error, please inform us by e-mail, phone or fax, and = then delete the original=20 and all copies thereof. _________________________________________________________________________= __ _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring ------=_NextPart_000_0504_01D4C5D3.52829D50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Greg,

Thanks a lot for your comments.

My comments are in-line.

 

B.R.

Weiqiang Cheng

 

=E5=8F=91=E4=BB=B6=E4=BA=BA: Greg Mirsky [mailto:gregimirsky@gmail.com] =
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B42=E6=9C=8815=E6=97=A5 3:37
=E6=94=B6=E4=BB=B6=E4=BA=BA: Alexander = Vainshtein
=E6=8A=84=E9=80=81: spring@ietf.org; Stewart = Bryant; draft-cheng-spring-mpls-path-segment@ietf.org; mpls@ietf.org; = Loa Andersson
=E4=B8=BB=E9=A2=98: Re: [spring] to progress = draft-cheng-spring-mpls-path-segment

 

Dear = All,

I = concur with all what has been said in support of the adoption of this = draft by SPRING WG. The document is well-written, addresses the real = problem in SR-MPLS, and the proposed solution is technically = viable.

My comments and questions are entirely for further = discussion:

  • would the draft be expanded to = demonstrate how "the Path Segment may be used to identify an = SR-MPLS Policy, its Candidate-Path (CP) or a SID List = (SL)"?

[Weiqiang] Yes, It is necessary and we will add some text to = demonstrate this in the future version.

  • as many use cases for the Path Segment = are related to OAM operations, it would be helpful to expand on the use = of GAL and the Path Segment.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0[Weiqiang] It is always helpful to have more use cases. However, The = GAL is used today in MPLS-TP LSPs to flag the G-Ach and is used for OAM = packets only while the Path segment is used for data packets for the = each traffic flow. It is a little bit different. =

Regards,

Greg

 

On Thu, Feb 14, 2019 at 1:12 AM = Alexander Vainshtein <Alexander.Vainshtein@eci= tele.com> wrote:

+1.

 

I have = been following this draft from its -00 revision. The current revision = has resolved most of the issues I (and others) have been raised (e.g., = elimination of excessive options).

 

From = my POV, in its current state the draft meets two basic requirements for = the WG adoption:

1.       It addresses a real and relevant problem, namely the MPLS = Flow Identification problem discussed in general in RFC = 8372 and scoped to SR-MPLS LSPs in this draft. Specifics of SR-MPLS = include the need to provide end-to-end liveness check that is one of the = requirements explicitly specified in Section 2 of RFC = 8355.

2.       It provides a reasonable (from my POV) approach to =  solution of this problem.

 

I also = concur with Stewart=E2=80=99s comment about strong similarity between = the approach taken in this draft for SR-MPLS and generic work in progress on synonymous flow labels that = has been already adopted as a MPLS WG item.  To me this is yet = another indication that the draft should be = adopted.

 

My = 2c,

Sasha

 

Office: +972-39266302

Cell:      = +972-549266302

Email:   Alexander.Vainshtein@ecitele.com<= /p>

 

-----Original Message-----
From: spring <spring-bounces@ietf.org> On Behalf Of Stewart = Bryant
Sent: Wednesday, February 13, 2019 12:48 PM
To: Loa = Andersson <loa@pi..nu>; spring@ietf.org; draft-cheng-spring-mpls-path-segment@ietf.org
Su= bject: Re: [spring] to progress = draft-cheng-spring-mpls-path-segment

 

I have = just read the draft and agree that it should be adopted by the WG. It = solves an important problem in instrumenting and protecting an SR = path.

 

It = should be noted that we needed to do something very similar in = mainstream MPLS via the synonymous label work which is already adopted. =

However SL did not address the SR case. We therefore need = this path label work to be progressed.

 

- = Stewart

 

On = 10/02/2019 08:11, Loa Andersson wrote:

> = Working Group,

> 

> I = have reviewed draft-cheng-spring-mpls-path-segment and as far as I =

> = can see, it is ready for wg adoption.

> 

> = There were some comments in Bangkok, but due to the many collisions =

> = between working groups at that meeting I couldn't attend the SPRING =

> = f2f.

> 

> = The minutes are not clear, but as far as I understand, there is =

> = nothing that can't be resolved in the wg = process.

> 

> = /Loa

 

_______________________________________________

spring mailing list

spring@ietf.org

https://www..ietf.org/mai= lman/listinfo/spring


________________________________________________________= ___________________

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

------=_NextPart_000_0504_01D4C5D3.52829D50-- From nobody Sat Feb 16 12:28:33 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 59BE2130EBA; Sat, 16 Feb 2019 12:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 fLByxz6dWhPJ; Sat, 16 Feb 2019 12:28:23 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810097.outbound.protection.outlook.com [40.107.81.97]) (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 79AE212F1A2; Sat, 16 Feb 2019 12:28:23 -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=I+EPbpnhttHUaGa0RAwEfEOuyyrPZyO9OVcIEK2oulc=; b=E9mRYZqM4mwgaaKG/bwe90jIursUIBKF3vYTYGwWW4TFPd6Yfw9E9D1hu6ShBNUO9v8Gpakxmui4ModwZ9U/pIBFh361ovFqhkix6DHc3eiQAZI+xrYphQ2sQNyYOJGtfAIq1LVmVzbTlep7WuC0E2e8mqIYgahbTiywtZTuaPc= Received: from DM5PR0101CA0001.prod.exchangelabs.com (2603:10b6:4:28::14) by CY4PR01MB3287.prod.exchangelabs.com (2603:10b6:903:e9::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Sat, 16 Feb 2019 20:28:21 +0000 Received: from BY2NAM03FT039.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::209) by DM5PR0101CA0001.outlook.office365.com (2603:10b6:4:28::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1622.16 via Frontend Transport; Sat, 16 Feb 2019 20:28:21 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; 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 BY2NAM03FT039.mail.protection.outlook.com (10.152.85.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1580.10 via Frontend Transport; Sat, 16 Feb 2019 20:28:20 +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 x1GKSGPW032739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 16 Feb 2019 15:28:18 -0500 Date: Sat, 16 Feb 2019 14:28:16 -0600 From: Benjamin Kaduk To: Mach Chen CC: Linda Dunbar , "secdir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org" , "ietf@ietf.org" Message-ID: <20190216202815.GD82217@kduck.mit.edu> References: <154455986336.13151.8483284555885294015@ietfa.amsl.com> <20190126211729.GJ49072@kduck.mit.edu> 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) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(39860400002)(136003)(346002)(396003)(2980300002)(13464003)(199004)(51914003)(189003)(356004)(88552002)(8676002)(106466001)(246002)(26826003)(478600001)(8936002)(2906002)(54906003)(53416004)(104016004)(106002)(36906005)(58126008)(16586007)(75432002)(86362001)(786003)(46406003)(50466002)(316002)(97756001)(33656002)(6916009)(26005)(53546011)(14444005)(1076003)(47776003)(5660300002)(76176011)(7696005)(55016002)(305945005)(23726003)(4326008)(446003)(426003)(93886005)(336012)(126002)(486006)(476003)(6246003)(956004)(229853002)(11346002)(186003)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR01MB3287; 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: b1c14253-d078-4302-a92f-08d6944d4aeb X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:CY4PR01MB3287; X-MS-TrafficTypeDiagnostic: CY4PR01MB3287: X-Microsoft-Exchange-Diagnostics: 1; CY4PR01MB3287; 20:+2VnjcvkH67Tx0Sm+biV/6KradzTFjE7zggikFI/N1ODnIMiJx3ueH4EUf6FtcqgkIp/JBLpXzoU4foGJELxG1Qkoclwx//0AgRXbeElDLBaQv5ehNQJY5/6CddJvsSIgAUpgrQAylJUf5mqrXrY0twK6I5lfqh1TBr5Y+V6nvsv6370aELC+Y++ekOS2Zpw8jjqGpbmms9O3LVau5ix+dG1Rh/BSdd5CbbBoe5rmApLWUmQxLnOugRhrVepDgGC95RoHRpZA5tUDnQKVGSNmPEJBgC7irBodR9i2Wn1QFcmroHDMdRmU5Iss/RT8QVBZ6GkkMCDsE/H/E/Z/udOBdAAx6VD/ElgNjW819IH21x+3VAd/C2olUqtDnBQBci/Vi5li0Loe7X77uMmAQEIpm5j5uqpqVcaG5r8OX7gVdPkbhh9hMBHv4IlwxiMpjE8RATomMOmbYpiLtJAl8D8ZSIhtUvxioPpY9rCoOMzWfE9977TOpNQgS+gv+hw87VgmtUaiedh/tJabBS7IwazBFX8zwWLP+OVH4lqY//XzT4Sd+XTc+ZcU2EbAoAB4QMvQhkkBSdGslXRgnUnCvt/xl9W4HkVAIlZZSeCWl7buoU= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0950706AC1 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR01MB3287; 23:QnQzhMrBSbRtj96yz7pvan1g9x2PFxZtv17kFUsYD?= =?us-ascii?Q?02fUeLa4P1cWL88Eqdd0lM9+P7JfoP2Cowvw7sWtsw9xTWGNc/Yxm+3uOQQJ?= =?us-ascii?Q?gWGdYx++f+TnMDnB2vbmzLl7720Scmv6wfTWAm9fynRmYvBxN5GHJJJUozyV?= =?us-ascii?Q?jgeffd7qtjzgD4Lo/Jb8Cg/9KhqI2wm9Gw/ts65kIUTZj+yhQGsTL4eJz5Dw?= =?us-ascii?Q?71mPivqaTXDbUGNk1GmzOfnjcF9SrvV6hPDfu9LpTm/WLE8WERjD+LMFprEF?= =?us-ascii?Q?G7shiDHn6XWMIe/ktFpqZ9BSl9c7GYfAXRRviN6q5uuAyh4sxy9kqf9FYZ7w?= =?us-ascii?Q?3JPb0k/GdTr0sMfLjSexUzgSwNwCWxgA5s/ZPV0pybL8sIekMvDGOwmCFKPn?= =?us-ascii?Q?gUkrYTaFMcWBP+q6/4qA30kjiN8xVBWo9xb/mklA3+oP0hr/iCnU21qYERXB?= =?us-ascii?Q?xarawwAwJZuKqHU1p/9NAKr+RNLu1kRMbO4VTyTJKNegEsRqeEosrNuMhlMy?= =?us-ascii?Q?WPhMJ5eZ1gTvdgfNRh36sirPCOahUedKJp+1xUvFE7zrpz+kbvpQp+jF8SMq?= =?us-ascii?Q?KDrbLr4JyxXRLhu1jvKPxfJO5g0pQP84d48kRpvonzKZA010JlBLQj+qCpMd?= =?us-ascii?Q?qAwTXudV0rxXCjmVfTdjmRVVMRGBG05VW2yv0iEDjweTjYJASBU71PYTD6la?= =?us-ascii?Q?mUaDKkGNW8xtjR2kF8SOCUKtN6FIEbUm+/M+lpezg7sUcG/CShkIswdEokk7?= =?us-ascii?Q?q5f6y5K0Lqbu1CG/jFuMn3J/tEcrza+HuePqdMj3mtn8VNU3gWavB/FLdUlh?= =?us-ascii?Q?YrdrNFTOmJGE/Gz5elH7JoDjxlkdH5dAlVv4shAdu484ZMBqBPqMGdMH1xVC?= =?us-ascii?Q?WenQwEQ8wHWN6tOCx3JapEgEz72fNQistCmjKI62Ipm+LjZWpfXocoGU89gm?= =?us-ascii?Q?DoByMALwZ5nwA91PesrKpvbmlKZQ4gWl3JtrgmcIv0xtZt0TZv5jUnz5BfrB?= =?us-ascii?Q?OqVOglrBf5p+LsPPEU38pqcfTu4R2et48A6coY1S/Yjlha7EE4lIGL6tWOQT?= =?us-ascii?Q?u9vKEU4gVxDjh4H4O1XuYvjNyCo86DcnHRMuoG4JixdPm9w5O9LWbDPa2OR1?= =?us-ascii?Q?1voaMfG2wfUkjXOlEx+BGw9Y4daI+5Q9jx1amIIOTaLnzChDEsu3OjFmTcXU?= =?us-ascii?Q?jdhtKdwlnFXTcFkN3txoFaAu5HmdjLuVzh/XHtrVDk1aOfiU5i1FRV68SjZw?= =?us-ascii?Q?OodiNHX7Sp0oK4XKHLdWOYNZvW8cxePYdYAoOMEEpoI/DfXkTOFKPA8jhdp8?= =?us-ascii?Q?BPrjTqoUtyFcRlbbMi/d6I=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: TFfZj69soQ3eX0ccf8qMO2ZGHhbdzvYC5gQsJFOd45icJK6883Rj5SveiEMSwVz8aSvuNXsZNnWXi9Pgc2P16jLNG0wBHJlOTJWTBpucKpxJfrU38b3JaNxrERHpwJfivifjvRt5/7szg6UoxFlp37y1NwCr80Kk+ydSbJdUWcU1k5khA1nR4hMzrOOSs6i0a87Y/WSNkLNEURF0ljif1QM8/WmDq0sWDT7y9/l5P4r2gnL68dseGZVSBzrCF4VLuMqwdoEoLIaw1djtuk49rRWGcTFL3pimVSWsNsQ+1iu4tiP4RwAzkgk0Vxs+s6f0tglSXWiFV8toBW/PJJw3Jn2Jbdk3LMnZivilPUNLCBo2RW3tBsrNty6w4JtaQjVOdVSXwtZEoMBfucpyZhRqnMjFhNH1dYlOtWLf3UJyAgc= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2019 20:28:20.5701 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b1c14253-d078-4302-a92f-08d6944d4aeb 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: CY4PR01MB3287 Archived-At: Subject: Re: [mpls] [secdir] Secdir 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: Sat, 16 Feb 2019 20:28:26 -0000 Hi Mach, My apologies as well for the delay. On Thu, Feb 14, 2019 at 03:02:07AM +0000, Mach Chen wrote: > Hi Benjamin, > > Sorry for the delayed response! > > Please see my response inline... > > > -----Original Message----- > > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > > Sent: Sunday, January 27, 2019 5:17 AM > > To: Mach Chen > > Cc: Linda Dunbar ; secdir@ietf.org; > > mpls@ietf.org; draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org; > > ietf@ietf.org > > Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag- > > multipath-05 > > > > On Fri, Dec 14, 2018 at 02:11:21AM +0000, Mach Chen wrote: > > > Hi Linda, > > > > > > Thanks for the review! > > > > > > Some responses inline... > > > > > > > -----Original Message----- > > > > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Linda Dunbar > > > > Sent: Wednesday, December 12, 2018 4:24 AM > > > > To: secdir@ietf.org > > > > Cc: mpls@ietf.org; > > > > draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org; > > > > ietf@ietf.org > > > > Subject: Secdir last call review of > > > > draft-ietf-mpls-lsp-ping-lag-multipath-05 > > > > > > > > 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 summary of the review is Ready with comment > > > > > > > > The described mechanism for LSP Multipath Ping is very clear. The > > > > Security Consideration re-uses the description of RFC8029, which is > > > > very comprehensive. > > > > It would be better if the draft describes how to prevent > > > > intermediate LSRs in between the Initiating LSR and Responding LSR > > > > from mis-using the detailed link information (e.g. forwarding to > > somewhere else). > > > > > > The Echo Request and Reply messages are directly exchanged between the > > Initiating LSR and the Responding LSR, those intermediate LSRs just forward > > the messages as normal packets, they will not see the detailed link > > information unless if they inspect and do DPI on every packet forwarded by > > them. > > > > > > The detailed link information is supplied to the Initiating LSR for using, the > > intermediate LSRs will not try to use it even if they received the information, > > because there is no corresponding Echo Request to the received Echo Reply. > > > > The intermediate LSRs still will have access to the plaintext information, even > > if in normal operation they do not need to act upon that information. > > Generally in this sort of situation we will either explicitly state that the > > intermediate nodes must be trusted to not abuse the information in > > question, or provide some mechanism for end-to-end confidentiality > > protection. > > "Intermediate nodes must be trusted to not abuse the information" is normally assumed. For the intermediate nodes, there is no different between the Echo Reply messages and any other data traffic, control messages. They just forward the Echo Reply messages as normal packets. I am not sure it needs to explicitly state this. Do you suggest to add such a statement in the security consideration section? The concern is not about the normal operation, but rather about abnormal operation, e.g., if an intermediate node gets compromised by an attacker. We need to document the new abilities an attacker gets, when comparing the original case of "an attacker compromises an intermediate node that is using MPLS without this mechanism" to the new case of "an attacker compromises an intermediate node that is using MPLS with this mechanism". So, while I do suggest adding a statement to the security considerations section, the statement I want does not relate to the normal operation case (when intermediate nodes ignore the contents of the message). > > > > Also (noting that I only skimmed the document so this may not make sense), > > the security considerations seem to suggest using an IP ACL for determining > > which messages are trusted; IP ACLs are generally not recommended in favor > > of cryptographic mechanisms at this point. > > IP ACLs was introduced in RFC 8029 and is reused in this document, it's I did not find a clear and explicit declaration in RFC 8029 of the concept of an IP ACL; I assume you are referring to: To protect against unauthorized sources using MPLS echo request messages to obtain network information, it is RECOMMENDED that implementations provide a means of checking the source addresses of MPLS echo request messages against an access list before accepting the message. I do not think anyone is going to say "do not filter based on IP source address", but there would be general skepticism about relying upon it as a sole security mechanism. > just one of the security mechanisms. This document is an extension to (Could you remind me of the other mechanisms? I don't think I have a good handle on them.) > RFC 8029, as stated in this document, all security considerations defined > in RFC 8029 apply to this document. Do you have any specific suggestion > to the current security consideration? I am mostly just lamenting the state of affairs; this is a sufficiently incremental change that it is inappropriate to require dramatic changes in the security mechanisms. -Ben From nobody Sat Feb 16 13:07:42 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 B6E72130FC5; Sat, 16 Feb 2019 13:07:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Al Morton 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.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155035125470.28448.13188042604940095760@ietfa.amsl.com> Date: Sat, 16 Feb 2019 13:07:34 -0800 Archived-At: Subject: [mpls] Opsdir last call review of draft-ietf-mpls-sr-over-ip-02 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, 16 Feb 2019 21:07:35 -0000 Reviewer: Al Morton Review result: Has Nits Thanks for preparing this draft. Providing transition methods is very welcome to Operations. These comments are best viewed with a monospace font, and should be treated as any Last Call comments (and optional). There seem to be a few more opportunities to employ Requirements Language in this draft (currently only 3 MUSTs and 2 MAYs), to improve the consistency of implementations and subsequent adoption in operations. For example: Section 2: o Incremental deployment of the SR-MPLS technology may be facilitated by tunneling SR-MPLS packets across parts of a network that are not SR-MPLS enabled using an IP tunneling mechanism such as MPLS-in-UDP [RFC7510]. The tunnel destination address is the ^^^^ address of the next SR-MPLS capable node along the path (i.e., the egress of the active node segment). This is shown in Figure 1. Setting the Dst address correctly seems to be a requirement, because this material in Section 2 is referenced later, in 3.2.3. This seems a reasonable spot for s/is/SHOULD be/ at least. Section 3.1 FIB construction relies on about 5 drafts: much work in progress, just noting dependencies (no action) SRGB - ?? spell-out at first use Section 3.2.3. Additional Forwarding Procedures ... 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. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The other IP header fields (such as DSCP code point, or IPv6 Flow Label) on each UDP-encapsulated segment can be set according to ^^^^^^^^^^ the operator's policy: Suggest: s/can be set/SHOULD be configurable/ From nobody Sat Feb 16 13:24:33 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 73C1F1200ED; Sat, 16 Feb 2019 13:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 ocFlxJRCdH4i; Sat, 16 Feb 2019 13:24:22 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 9C2F7126F72; Sat, 16 Feb 2019 13:24:21 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id w6so6462320ljd.7; Sat, 16 Feb 2019 13:24:21 -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=VaBceLmBUPvYrZQD/6sAcUTK+VFMky4elCm1aGgl8Ws=; b=RVlmXn+nNRrHwvjeJy5ua0/izXoegC2gKv6hLS+xCywdoMZoLEcaO7AsNWCM5xOYEb edtKujjkEycD8LXQBqHx+e1YMjUa6rnEkWURntbVmLFYB+ZSVBKYJezYRmg5/PyFsnz4 +sXKQp5+8ztxcQPeOpPtzOPBkJ0sBz4TSEUE6CQwIQ1neKvmJV5eQ3NOFn4WP9vqL73I VRjItwg3YWWCBGiEBfP3oiLaztszMSlPOCBwsm0Zn0M7GqubfF81YHr4r+QpYZ979miP Jh8h0SvNOr2FMMRuEwt/qouMt4ebsX2Gr3JKjRUW8zW8/CspcQhOZKF/YDBEBV9wsG+X Juew== 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=VaBceLmBUPvYrZQD/6sAcUTK+VFMky4elCm1aGgl8Ws=; b=PVw/FKeBCB5nQlGEDjvUCJyxKJwISpkQzw6hotEQdabre8IuLya2/ZKZdQjctLCUX6 JvUXSjpNBG4uiPHzwuNBdpMKDa2mMKqadIkOO3b0N9wkqqIUfJPVdWpCsUUQaeK/ysIk 6fRrZaMy484w5G5SNZeD581MqRSJzNyHcNdmmXlJnKJkb1N49C4BqLxYj/tS+xpBNi1F sqbGiHhkgQmpdmuSlCt9KG4pHogakyihiOMKf8Ch7jmi6kT/fBfmqieoyee9utL3jH/j BfKMRFSQ618ijG7B5cwWwAewJyvlCD4XhRwjls2ORoIt5v/wEOV1QecAUHTxF2836POB Z/Xg== X-Gm-Message-State: AHQUAuaeaXPjH9clS3nejmmmA5nfs+Myowplo01BW0CwMH/A1kIXx4r/ VNkdudZTVrwLVefPMKf+WOr12s+IgQc/xeW0Tq4= X-Google-Smtp-Source: AHgI3IYrL+6U/iN9SFVsia9KADU6RpOv0XOdGb2ENNclbvyB2/abmNzQyEDGcF0A1B7+cPHCNojwcdXZ95lf1b3ne2c= X-Received: by 2002:a2e:81a:: with SMTP id 26-v6mr9514893lji.14.1550352259455; Sat, 16 Feb 2019 13:24:19 -0800 (PST) MIME-Version: 1.0 References: <0980ce7c-047c-519f-e7d5-98d32b498482@pi.nu> <9419b7d7-87ef-151f-5ed8-b0f78c6e83af@gmail.com> <050301d4c590$445f5d50$cd1e17f0$@com> In-Reply-To: <050301d4c590$445f5d50$cd1e17f0$@com> From: Greg Mirsky Date: Sat, 16 Feb 2019 13:24:09 -0800 Message-ID: To: Weiqiang Cheng Cc: Alexander Vainshtein , spring , Stewart Bryant , draft-cheng-spring-mpls-path-segment@ietf.org, mpls@ietf.org, Loa Andersson Content-Type: multipart/alternative; boundary="000000000000b39f570582098306" Archived-At: Subject: Re: [mpls] [spring] to progress draft-cheng-spring-mpls-path-segment 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, 16 Feb 2019 21:24:24 -0000 --000000000000b39f570582098306 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Weiqiang Cheng, thank you for your expedient response to my questions. The document states that one of the use cases for the Path segment is to be used as a performance, packet loss and/or delay, measurement session identifier. I think that RFC 6374 is the most suitable for PM OAM in SR-MPLS environment. Of course, the type of the encapsulated message can be identified using the destination UDP port number with IP/UDP encapsulation. But another option is to use G-ACh encapsulation. That would require the use of GAL. And that is how I've arrived at my original question (I should have explained it better, my apologies): How the Path segment and GAL are placed relative to each other in the SR-MPLS label stack? Regards, Greg On Fri, Feb 15, 2019 at 4:40 PM Weiqiang Cheng < chengweiqiang@chinamobile.com> wrote: > Hi Greg, > > Thanks a lot for your comments. > > My comments are in-line. > > > > B.R. > > Weiqiang Cheng > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Greg Mirsky [mailto:gregimirsky@gmail.com] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2019=E5=B9=B42=E6=9C=8815=E6=97= =A5 3:37 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Alexander Vainshtein > *=E6=8A=84=E9=80=81:* spring@ietf.org; Stewart Bryant; > draft-cheng-spring-mpls-path-segment@ietf.org; mpls@ietf.org; Loa > Andersson > *=E4=B8=BB=E9=A2=98:* Re: [spring] to progress draft-cheng-spring-mpls-pa= th-segment > > > > Dear All, > > I concur with all what has been said in support of the adoption of this > draft by SPRING WG. The document is well-written, addresses the real > problem in SR-MPLS, and the proposed solution is technically viable. > > My comments and questions are entirely for further discussion: > > - would the draft be expanded to demonstrate how "the Path Segment may > be used to identify an SR-MPLS Policy, its Candidate-Path (CP) or a SI= D > List (SL)"? > > [Weiqiang] Yes, It is necessary and we will add some text to demonstrate > this in the future version. > > - as many use cases for the Path Segment are related to OAM > operations, it would be helpful to expand on the use of GAL and the Pa= th > Segment. > > [Weiqiang] It is always helpful to have more use cases. However, > The GAL is used today in MPLS-TP LSPs to flag the G-Ach and is used for O= AM > packets only while the Path segment is used for data packets for the each > traffic flow. It is a little bit different. > > Regards, > > Greg > > > > On Thu, Feb 14, 2019 at 1:12 AM Alexander Vainshtein < > Alexander.Vainshtein@ecitele.com> wrote: > > +1. > > > > I have been following this draft from its -00 revision. The current > revision has resolved most of the issues I (and others) have been raised > (e.g., elimination of excessive options). > > > > From my POV, in its current state the draft meets two basic requirements > for the WG adoption: > > 1. It addresses a real and relevant problem, namely the MPLS Flow > Identification problem discussed in general in RFC 8372 > and scoped to SR-MPLS LSPs in this > draft. Specifics of SR-MPLS include the need to provide end-to-end livene= ss > check that is one of the requirements explicitly specified in Section 2 o= f RFC > 8355 . > > 2. It provides a reasonable (from my POV) approach to solution of > this problem. > > > > I also concur with Stewart=E2=80=99s comment about strong similarity betw= een the > approach taken in this draft for SR-MPLS and generic work in progress on > synonymous flow labels > that has > been already adopted as a MPLS WG item. To me this is yet another > indication that the draft should be adopted. > > > > My 2c, > > Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > > -----Original Message----- > From: spring On Behalf Of Stewart Bryant > Sent: Wednesday, February 13, 2019 12:48 PM > To: Loa Andersson >; spring@ietf.org; > draft-cheng-spring-mpls-path-segment@ietf.org > Subject: Re: [spring] to progress draft-cheng-spring-mpls-path-segment > > > > I have just read the draft and agree that it should be adopted by the WG. > It solves an important problem in instrumenting and protecting an SR path= . > > > > It should be noted that we needed to do something very similar in > mainstream MPLS via the synonymous label work which is already adopted. > > However SL did not address the SR case. We therefore need this path label > work to be progressed. > > > > - Stewart > > > > On 10/02/2019 08:11, Loa Andersson wrote: > > > Working Group, > > > > > > I have reviewed draft-cheng-spring-mpls-path-segment and as far as I > > > can see, it is ready for wg adoption. > > > > > > There were some comments in Bangkok, but due to the many collisions > > > between working groups at that meeting I couldn't attend the SPRING > > > f2f. > > > > > > The minutes are not clear, but as far as I understand, there is > > > nothing that can't be resolved in the wg process. > > > > > > /Loa > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www..ietf.org/mailman/listinfo/spring > > > _________________________________________________________________________= __ > > 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 > > --000000000000b39f570582098306 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Weiqiang Cheng,
thank you for your expedient r= esponse to my questions. The document states that one of the use cases for = the Path segment is to be used as a performance, packet loss and/or delay, = measurement session identifier. I think that RFC 6374 is the most suitable = for PM OAM in SR-MPLS environment. Of course, the type of the encapsulated= =C2=A0message can be identified using the destination UDP port number with = IP/UDP encapsulation. But another option is to use G-ACh encapsulation. Tha= t would require the use of GAL. And that is how I've arrived at my orig= inal question (I should have explained it better, my apologies):
=
How th= e Path segment and GAL are placed relative to each other in the SR-MPLS lab= el stack?

Regards,
Greg

On = Fri, Feb 15, 2019 at 4:40 PM Weiqiang Cheng <chengweiqiang@chinamobile.com> wrote:

<= span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:Calibri,sans-seri= f;color:rgb(31,73,125)">Hi Greg,

Thanks a lot for your comments.=

My comments are = in-line.

=C2=A0

B.R.

Weiqiang Cheng

<= span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:Calibri,sans-seri= f;color:rgb(31,73,125)">=C2=A0

=E5=8F=91=E4=BB=B6=E4=BA=BA: Greg Mirsky [mailto:gregimirsky@gmail.= com]
=E5=8F=91=E9=80=81=E6= =97=B6=E9=97=B4: 2019=E5=B9= =B42=E6=9C=8815=E6= =97=A5 3:37
=E6=94=B6=E4=BB=B6=E4=BA=BA: Alexander Vainshtein=E6=8A=84=E9=80=81: spring@iet= f.org; Stewart Bryant; draft-cheng-spring-mpls-path-segment@iet= f.org; mpls@ietf.org= ; Loa Andersson
=E4=B8=BB=E9=A2=98: Re: [spring] to progress draft-cheng-spring-= mpls-path-segment

=C2=A0

=

Dear All,<= /p>

I concur with all what = has been said in support of the adoption of this draft by SPRING WG. The do= cument is well-written, addresses the real problem in SR-MPLS, and the prop= osed solution is technically viable.

My comments and questions are enti= rely for further discussion:

  • would the=C2=A0draft be= expanded to demonstrate how "the Path Segment may be used to identify= an SR-MPLS Policy, its Candidate-Path (CP) or a SID List (SL)"?

[W= eiqiang] Yes, It is necessary and=C2=A0we will add some text to demonstrate= this in the future version.

    as many use cases for the Path Se= gment are related to OAM operations, it would be helpful to expand on the u= se of GAL and the Path Segment.

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0[Weiqiang] It is alw= ays helpful to have more use cases. However, The GAL is used today in MPLS-= TP LSPs to flag the G-Ach and is used for OAM packets only while the Path s= egment is used for data packets for the each traffic flow. It is a little b= it different.

Regards,

Greg

=C2=A0

On Th= u, Feb 14, 2019 at 1:12 AM Alexander Vainshtein <Alexander.Vainshtein@ecitele= .com> wrote:

+1.

=C2=A0

I have b= een following this draft from its -00 revision. The current revision has re= solved most of the issues I (and others) have been raised (e.g., eliminatio= n of excessive options).

= =C2=A0

From my POV, in its= current state the draft meets two basic requirements for the WG adoption:<= u>

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 It addresses a real and relevant problem, namely the MPLS F= low Identification problem discussed in general in RFC 8372 and scoped to SR-MPL= S LSPs in this draft. Specifics of SR-MPLS include the need to provide end-= to-end liveness check that is one of the requirements explicitly specified = in Section 2 of RFC 8355.

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 It provides a reasonable (from my POV= ) approach to =C2=A0solution of this problem.

<= span lang=3D"EN-US">=C2=A0

I also concur with Stewart=E2=80=99s comment about strong similarity betwe= en the approach taken in this draft for SR-MPLS and generic work in progress on synonymous flow labels that has been already adopt= ed as a MPLS WG item.=C2=A0 To me this is yet another indication that the d= raft should be adopted.

= =C2=A0

My 2c,

Sasha

=C2=A0

Of= fice: +972-39266302

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

<= span lang=3D"EN-US">Email:=C2=A0=C2=A0 Alexander.Vainshtein@ecitele.com

=C2=A0

-----Original Message-----
From: spring <spring-bounces@i= etf.org> On Behalf Of Stewart Bryant
Sent: Wednesday, February 13= , 2019 12:48 PM
To: Loa Andersson <loa@pi..nu>; spring@ietf.org; draft-cheng-spring-mpls-path-segme= nt@ietf.org
Subject: Re: [spring] to progress draft-cheng-spring-mpl= s-path-segment

=C2=A0

I have just read the draft and= agree that it should be adopted by the WG. It solves an important problem = in instrumenting and protecting an SR path.

=C2=A0

I= t should be noted that we needed to do something very similar in mainstream= MPLS via the synonymous label work which is already adopted.

However SL did not address the SR case= . We therefore need this path label work to be progressed.

=C2=A0

- Stewart

= =C2=A0

On 10/02/2019 08:11= , Loa Andersson wrote:

>= ; Working Group,

>=C2= =A0

> I have reviewed d= raft-cheng-spring-mpls-path-segment and as far as I

> can see, it is ready for wg adoption.

>=C2=A0=

> There were some comments in Bangkok, but = due to the many collisions

> between working groups at that meeting I couldn't attend the SPR= ING

> f2f.

>=C2=A0

> The minutes are not clear, but as far as I unde= rstand, there is

> not= hing that can't be resolved in the wg process.

=

>=C2=A0

> /Loa

=C2= =A0

______________________= _________________________

= spring mailing list

spring@ietf.org

https://www..ietf.org/mailman/listinfo/spring


________= ___________________________________________________________________

= 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 received this
transmission in error, please inform us by e= -mail, phone or fax, and then delete the original
and all copies thereo= f.
_____________________________________________________________________= ______

_______________________________________________
spring mailing lis= t
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring=

--000000000000b39f570582098306-- From nobody Sun Feb 17 03:19: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 C92AA127AC2; Sun, 17 Feb 2019 03:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 JMQeJbzdsQe0; Sun, 17 Feb 2019 03:19:17 -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 F19CE128B01; Sun, 17 Feb 2019 03:19:13 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id x1HBJ7uP021004; Sun, 17 Feb 2019 11:19:07 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5D4882203B; Sun, 17 Feb 2019 11:19:07 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id 46B822203A; Sun, 17 Feb 2019 11:19:07 +0000 (GMT) Received: from LAPTOPK7AS653V ([59.37.21.226]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id x1HBJ1Pd025578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 17 Feb 2019 11:19:05 GMT Reply-To: From: "Adrian Farrel" To: "'Al Morton'" , Cc: , , References: <155035125470.28448.13188042604940095760@ietfa.amsl.com> In-Reply-To: <155035125470.28448.13188042604940095760@ietfa.amsl.com> Date: Sun, 17 Feb 2019 11:18:59 -0000 Organization: Old Dog Consulting Message-ID: <00ef01d4c6b2$98102420$c8306c60$@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: AQGBGQl8mGC2K5R3NLNQWApPimb6ZKaLMFcA Content-Language: en-gb X-Originating-IP: 59.37.21.226 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-24434.007 X-TM-AS-Result: No--11.092-10.0-31-10 X-imss-scan-details: No--11.092-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24434.007 X-TMASE-Result: 10--11.092100-10.000000 X-TMASE-MatchedRID: fE0JoqABJp3xIbpQ8BhdbOYAh37ZsBDCC/ExpXrHizzlJZht6cF9xFM1 EzrOOwvWQkIpLU6y2ndal/o0mVdrU054kNlzd6J3cFEiuPxHjsUICu6i14k6HPgnJH5vm2+gFhM gncTYqyS0JGeVHQ04WopMlj66NgD77Hz728uiamCcnm0v4tsY4ziAbW+oEE345VavBrAV4wUNqg 8odlnkKKaBafyu8kavPvqiJzbDmiyrSqv5DWrMSh47EGkpGeA9OkDbNlgmO/UN+H+9vY7EAGVYY C40jpLGTupBKcY88KK4VxGFQBNJeNUMAwTDOBnsbuFuYBIpyuk38FNTll9lEuedK36PXYKWmi3F G4ndT6WEjbv1/pAnVVb+d1W2AA/qhPc4FTJN6V5I9rD1ir7Z9L8+q17GFLKRmyiLZetSf8my5/t FZu9S3AV1uwb6J5fHC24oEZ6SpSkj80Za3RRg8B5g4ELUg4CGm+Yg55upS4XCkIkNXnqRGLbSWE lXgokXEze1V/T0TyU= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] Opsdir 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: Sun, 17 Feb 2019 11:19:20 -0000 Hi Al, Thanks very much for reviewing. Responses in line. > Thanks for preparing this draft. > Providing transition methods is very welcome to > Operations. We aim to please =F0=9F=98=8A > There seem to be a few more opportunities to employ > Requirements Language in this draft (currently only > 3 MUSTs and 2 MAYs), to improve the consistency of=20 > implementations and subsequent adoption in operations. You are right. The original vision for this document was Informational (telling you how = to use existing tools), so the Requirements language only crept in as we = moved to Standards Track, and we should probably have more of it. > For example: > Section 2: > o Incremental deployment of the SR-MPLS technology may be > facilitated by tunneling SR-MPLS packets across parts of a = network > that are not SR-MPLS enabled using an IP tunneling mechanism such > as MPLS-in-UDP [RFC7510]. The tunnel destination address is the > ^^^^ > address of the next SR-MPLS capable node along the path (i.e., = the > egress of the active node segment). This is shown in Figure 1. > > Setting the Dst address correctly seems to be a requirement, > because this material in Section 2 is referenced later, in 3.2.3. > This seems a reasonable spot for s/is/SHOULD be/ at least. Well, in this specific case I'm going to agree with you, but for a = different reason. You don't set a destination address, you pick a tunnel = that has an end point. So we should probably write... OLD The tunnel destination address is the address of the next SR-MPLS capable node along the path (i.e., the egress of the active node segment). NEW The tunnel selected MUST have its remote end point (destination) Address equal to the address of the next SR-MPLS capable node=20 along the path (i.e., the egress of the active node segment). END > Section 3.1 FIB construction relies on about 5 drafts:=20 > much work in progress, just noting dependencies (no action) Yes, it is sad for me that the SR work still lingers in the pipe. > SRGB - ?? spell-out at first use Good catch. Segment Routing Global Block > Section 3.2.3. Additional Forwarding Procedures >....=20 > 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. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > The other IP header fields (such as DSCP code point, or IPv6 Flow > Label) on each UDP-encapsulated segment can be set according to > ^^^^^^^^^^ > the operator's policy: >Suggest: > s/can be set/SHOULD be configurable/ Yes From nobody Sun Feb 17 05:47: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 CDA311295EC; Sun, 17 Feb 2019 05:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 sVOSS88VZ11j; Sun, 17 Feb 2019 05:46:57 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 AB1ED1293B1; Sun, 17 Feb 2019 05:46:57 -0800 (PST) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x1HDjV6P018814; Sun, 17 Feb 2019 08:46:57 -0500 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0048589.ppops.net-00191d01. with ESMTP id 2qpsqxenbd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 17 Feb 2019 08:46:56 -0500 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id x1HDktep053990; Sun, 17 Feb 2019 07:46:55 -0600 Received: from zlp30497.vci.att.com (zlp30497.vci.att.com [135.46.181.156]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id x1HDkqg9053961; Sun, 17 Feb 2019 07:46:52 -0600 Received: from zlp30497.vci.att.com (zlp30497.vci.att.com [127.0.0.1]) by zlp30497.vci.att.com (Service) with ESMTP id 1F0E340141FF; Sun, 17 Feb 2019 13:46:52 +0000 (GMT) Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30497.vci.att.com (Service) with ESMTP id F2B1840141F8; Sun, 17 Feb 2019 13:46:51 +0000 (GMT) Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id x1HDkpeH010472; Sun, 17 Feb 2019 07:46:51 -0600 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.255.15]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id x1HDkhnD010020; Sun, 17 Feb 2019 07:46:43 -0600 Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-green.research.att.com (Postfix) with ESMTP id D53FFE40DB; Sun, 17 Feb 2019 08:46:10 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0439.000; Sun, 17 Feb 2019 08:46:42 -0500 From: "MORTON, ALFRED C (AL)" To: "adrian@olddog.co.uk" , "ops-dir@ietf.org" CC: "mpls@ietf.org" , "ietf@ietf.org" , "draft-ietf-mpls-sr-over-ip.all@ietf.org" Thread-Topic: Opsdir last call review of draft-ietf-mpls-sr-over-ip-02 Thread-Index: AQHUxrKxZBFm/1ktuk++wNABClUm86XkALAA Date: Sun, 17 Feb 2019 13:46:19 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF6BFF80C5@njmtexg5.research.att.com> References: <155035125470.28448.13188042604940095760@ietfa.amsl.com> <00ef01d4c6b2$98102420$c8306c60$@olddog.co.uk> In-Reply-To: <00ef01d4c6b2$98102420$c8306c60$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.141.203.172] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-17_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy 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-1902170108 Archived-At: Subject: Re: [mpls] Opsdir 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: Sun, 17 Feb 2019 13:47:00 -0000 VGhhbmtzIEFkcmlhbi4NCg0KQE9QUy1ESVIgLSBjb25zaWRlciB0aGVzZSBjb21tZW50cyByZXNv bHZlZC4NCg0KQWwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBZHJp YW4gRmFycmVsIFttYWlsdG86YWRyaWFuQG9sZGRvZy5jby51a10NCj4gU2VudDogU3VuZGF5LCBG ZWJydWFyeSAxNywgMjAxOSA2OjE5IEFNDQo+IFRvOiBNT1JUT04sIEFMRlJFRCBDIChBTCkgPGFj bUByZXNlYXJjaC5hdHQuY29tPjsgb3BzLWRpckBpZXRmLm9yZw0KPiBDYzogbXBsc0BpZXRmLm9y ZzsgaWV0ZkBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxzLXNyLW92ZXItaXAuYWxsQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJFOiBPcHNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLW1w bHMtc3Itb3Zlci1pcC0wMg0KPiANCj4gSGkgQWwsDQo+IA0KPiBUaGFua3MgdmVyeSBtdWNoIGZv ciByZXZpZXdpbmcuDQo+IA0KPiBSZXNwb25zZXMgaW4gbGluZS4NCj4gDQo+ID4gVGhhbmtzIGZv ciBwcmVwYXJpbmcgdGhpcyBkcmFmdC4NCj4gPiBQcm92aWRpbmcgdHJhbnNpdGlvbiBtZXRob2Rz IGlzIHZlcnkgd2VsY29tZSB0bw0KPiA+IE9wZXJhdGlvbnMuDQo+IA0KPiBXZSBhaW0gdG8gcGxl YXNlIPCfmIoNCj4gDQo+ID4gVGhlcmUgc2VlbSB0byBiZSBhIGZldyBtb3JlIG9wcG9ydHVuaXRp ZXMgdG8gZW1wbG95DQo+ID4gUmVxdWlyZW1lbnRzIExhbmd1YWdlIGluIHRoaXMgZHJhZnQgKGN1 cnJlbnRseSBvbmx5DQo+ID4gMyBNVVNUcyBhbmQgMiBNQVlzKSwgdG8gaW1wcm92ZSB0aGUgY29u c2lzdGVuY3kgb2YNCj4gPiBpbXBsZW1lbnRhdGlvbnMgYW5kIHN1YnNlcXVlbnQgYWRvcHRpb24g aW4gb3BlcmF0aW9ucy4NCj4gDQo+IFlvdSBhcmUgcmlnaHQuDQo+IFRoZSBvcmlnaW5hbCB2aXNp b24gZm9yIHRoaXMgZG9jdW1lbnQgd2FzIEluZm9ybWF0aW9uYWwgKHRlbGxpbmcgeW91IGhvdw0K PiB0byB1c2UgZXhpc3RpbmcgdG9vbHMpLCBzbyB0aGUgUmVxdWlyZW1lbnRzIGxhbmd1YWdlIG9u bHkgY3JlcHQgaW4gYXMgd2UNCj4gbW92ZWQgdG8gU3RhbmRhcmRzIFRyYWNrLCBhbmQgd2Ugc2hv dWxkIHByb2JhYmx5IGhhdmUgbW9yZSBvZiBpdC4NCj4gDQo+ID4gRm9yIGV4YW1wbGU6DQo+ID4g U2VjdGlvbiAyOg0KPiA+ICAgbyAgSW5jcmVtZW50YWwgZGVwbG95bWVudCBvZiB0aGUgU1ItTVBM UyB0ZWNobm9sb2d5IG1heSBiZQ0KPiA+ICAgICAgZmFjaWxpdGF0ZWQgYnkgdHVubmVsaW5nIFNS LU1QTFMgcGFja2V0cyBhY3Jvc3MgcGFydHMgb2YgYSBuZXR3b3JrDQo+ID4gICAgICB0aGF0IGFy ZSBub3QgU1ItTVBMUyBlbmFibGVkIHVzaW5nIGFuIElQIHR1bm5lbGluZyBtZWNoYW5pc20gc3Vj aA0KPiA+ICAgICAgYXMgTVBMUy1pbi1VRFAgW1JGQzc1MTBdLiAgVGhlIHR1bm5lbCBkZXN0aW5h dGlvbiBhZGRyZXNzIGlzIHRoZQ0KPiA+CSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgXl5eXg0KPiA+ICAgICAgYWRkcmVzcyBvZiB0aGUg bmV4dCBTUi1NUExTIGNhcGFibGUgbm9kZSBhbG9uZyB0aGUgcGF0aCAoaS5lLiwgdGhlDQo+ID4g ICAgICBlZ3Jlc3Mgb2YgdGhlIGFjdGl2ZSBub2RlIHNlZ21lbnQpLiAgVGhpcyBpcyBzaG93biBp biBGaWd1cmUgMS4NCj4gPg0KPiA+IFNldHRpbmcgdGhlIERzdCBhZGRyZXNzIGNvcnJlY3RseSBz ZWVtcyB0byBiZSBhIHJlcXVpcmVtZW50LA0KPiA+IGJlY2F1c2UgdGhpcyBtYXRlcmlhbCBpbiBT ZWN0aW9uIDIgaXMgcmVmZXJlbmNlZCBsYXRlciwgaW4gMy4yLjMuDQo+ID4gVGhpcyBzZWVtcyBh IHJlYXNvbmFibGUgc3BvdCBmb3Igcy9pcy9TSE9VTEQgYmUvIGF0IGxlYXN0Lg0KPiANCj4gV2Vs bCwgaW4gdGhpcyBzcGVjaWZpYyBjYXNlIEknbSBnb2luZyB0byBhZ3JlZSB3aXRoIHlvdSwgYnV0 IGZvciBhDQo+IGRpZmZlcmVudCByZWFzb24uIFlvdSBkb24ndCBzZXQgYSBkZXN0aW5hdGlvbiBh ZGRyZXNzLCB5b3UgcGljayBhIHR1bm5lbA0KPiB0aGF0IGhhcyBhbiBlbmQgcG9pbnQuDQo+IA0K PiBTbyB3ZSBzaG91bGQgcHJvYmFibHkgd3JpdGUuLi4NCj4gT0xEDQo+ICAgICAgIFRoZSB0dW5u ZWwgZGVzdGluYXRpb24gYWRkcmVzcyBpcyB0aGUNCj4gICAgICAgYWRkcmVzcyBvZiB0aGUgbmV4 dCBTUi1NUExTIGNhcGFibGUgbm9kZSBhbG9uZyB0aGUgcGF0aCAoaS5lLiwgdGhlDQo+ICAgICAg IGVncmVzcyBvZiB0aGUgYWN0aXZlIG5vZGUgc2VnbWVudCkuDQo+IE5FVw0KPiAgICAgICBUaGUg dHVubmVsIHNlbGVjdGVkIE1VU1QgaGF2ZSBpdHMgcmVtb3RlIGVuZCBwb2ludCAoZGVzdGluYXRp b24pDQo+ICAgICAgIEFkZHJlc3MgZXF1YWwgdG8gdGhlIGFkZHJlc3Mgb2YgdGhlIG5leHQgU1It TVBMUyBjYXBhYmxlIG5vZGUNCj4gICAgICAgYWxvbmcgdGhlIHBhdGggKGkuZS4sIHRoZSBlZ3Jl c3Mgb2YgdGhlIGFjdGl2ZSBub2RlIHNlZ21lbnQpLg0KPiBFTkQNCj4gDQo+ID4gU2VjdGlvbiAz LjEgRklCIGNvbnN0cnVjdGlvbiByZWxpZXMgb24gYWJvdXQgNSBkcmFmdHM6DQo+ID4gbXVjaCB3 b3JrIGluIHByb2dyZXNzLCBqdXN0IG5vdGluZyBkZXBlbmRlbmNpZXMgKG5vIGFjdGlvbikNCj4g DQo+IFllcywgaXQgaXMgc2FkIGZvciBtZSB0aGF0IHRoZSBTUiB3b3JrIHN0aWxsIGxpbmdlcnMg aW4gdGhlIHBpcGUuDQo+IA0KPiA+IFNSR0IgLSA/PyBzcGVsbC1vdXQgYXQgZmlyc3QgdXNlDQo+ IA0KPiBHb29kIGNhdGNoLg0KPiBTZWdtZW50IFJvdXRpbmcgR2xvYmFsIEJsb2NrDQo+IA0KPiA+ IFNlY3Rpb24gMy4yLjMuIEFkZGl0aW9uYWwgRm9yd2FyZGluZyBQcm9jZWR1cmVzDQo+ID4uLi4u DQo+ID4gICAgICBJUCBIZWFkZXIgRmllbGRzOiAgV2hlbiBlbmNhcHN1bGF0aW5nIGFuIE1QTFMg cGFja2V0IGluIFVEUCwgdGhlDQo+ID4gICAgICByZXN1bHRpbmcgcGFja2V0IGlzIGZ1cnRoZXIg ZW5jYXBzdWxhdGVkIGluIElQIGZvciB0cmFuc21pc3Npb24uDQo+ID4gICAgICBJUHY0IG9yIElQ djYgbWF5IGJlIHVzZWQgYWNjb3JkaW5nIHRvIHRoZSBjYXBhYmlsaXRpZXMgb2YgdGhlDQo+ID4g ICAgICBuZXR3b3JrLiAgVGhlIGFkZHJlc3MgZmllbGRzIGFyZSBzZXQgYXMgZGVzY3JpYmVkIGlu IFNlY3Rpb24gMi4NCj4gPgkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXg0KPiA+ICAgICAgVGhlIG90aGVyIElQIGhlYWRlciBm aWVsZHMgKHN1Y2ggYXMgRFNDUCBjb2RlIHBvaW50LCBvciBJUHY2IEZsb3cNCj4gPiAgICAgIExh YmVsKSBvbiBlYWNoIFVEUC1lbmNhcHN1bGF0ZWQgc2VnbWVudCBjYW4gYmUgc2V0IGFjY29yZGlu ZyB0bw0KPiA+CSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF5eXl5e Xl5eXl4NCj4gPiAgICAgIHRoZSBvcGVyYXRvcidzIHBvbGljeToNCj4gPlN1Z2dlc3Q6DQo+ID4g cy9jYW4gYmUgc2V0L1NIT1VMRCBiZSBjb25maWd1cmFibGUvDQo+IA0KPiBZZXMNCg0K From nobody Sun Feb 17 15:58: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 B01F2128D52; Sun, 17 Feb 2019 15:57:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Paul Wouters To: Cc: mpls@ietf.org, draft-ietf-mpls-sfc-encapsulation.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155044786665.4047.16182077722084116649@ietfa.amsl.com> Date: Sun, 17 Feb 2019 15:57:46 -0800 Archived-At: Subject: [mpls] Secdir last call review of draft-ietf-mpls-sfc-encapsulation-02 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, 17 Feb 2019 23:57:47 -0000 Reviewer: Paul Wouters 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 summary of the review is Ready While I'm not familiar with the Service Function Chaining (SFC) architecture and the Network Service Header (NSH), the Security Considerations in this document seem to be correct in pointing out that: This document simply defines one additional transport encapsulation. The NSH was specially constructed to be agnostic to its transport encapsulation. As as result, in general this additional encapsulation is no more or less secure than carrying the NSH in any other encapsulation. From nobody Sun Feb 17 16:08: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 69996124D68; Sun, 17 Feb 2019 16:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 prBpk-qasiFN; Sun, 17 Feb 2019 16:08:42 -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 F1BFA1286D8; Sun, 17 Feb 2019 16:08:38 -0800 (PST) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id x1I08a48022598; Mon, 18 Feb 2019 00:08:36 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 93E9B2203D; Mon, 18 Feb 2019 00:08:36 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id 7D38C2203C; Mon, 18 Feb 2019 00:08:36 +0000 (GMT) Received: from LAPTOPK7AS653V ([59.37.21.226]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id x1I08WRo007527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Feb 2019 00:08:34 GMT Reply-To: From: "Adrian Farrel" To: "'Paul Wouters'" , Cc: , , References: <155044786665.4047.16182077722084116649@ietfa.amsl.com> In-Reply-To: <155044786665.4047.16182077722084116649@ietfa.amsl.com> Date: Mon, 18 Feb 2019 00:08:30 -0000 Organization: Old Dog Consulting Message-ID: <011a01d4c71e$16d9dd30$448d9790$@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: AQF5B8APV/6zAJCJLq3MOjIgukEp0qacKyZg Content-Language: en-gb X-Originating-IP: 59.37.21.226 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-24434.007 X-TM-AS-Result: No--8.253-10.0-31-10 X-imss-scan-details: No--8.253-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24434.007 X-TMASE-Result: 10--8.252600-10.000000 X-TMASE-MatchedRID: oTBA/+sdKabxIbpQ8BhdbKlXXrpOy3q0JPNIV6GF8mvOxDyJFXIPjuV0 5r5vXH4sv8qe8eDZGElC65348+oZgVdI3z1FMme36Zzj+kMRBrZR3sGN+j7mNMz1fqX318VP0u5 faGP8ztRV/mZWautsNz95I71UPSkOzsxad8fKloYF8rFt9xmDKTIaJpKzSfrsUCgEErrUGFwHn+ RaCrVBs4SaYXP5EhtmCOtlGomeL41qxgfCZhqtfAI0yP/uoH+DfS0Ip2eEHnwa2S8rkvtFcbDsz p3K5gqDjoczmuoPCq22oIhiAsKJgJS5x7cNmK0Fjy77szn26nqiQGmmwblmDsUufy2PLnHz X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] Secdir last call review of draft-ietf-mpls-sfc-encapsulation-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: Mon, 18 Feb 2019 00:08:44 -0000 Hi Paul, Should we make the observation that, since the MPLS forwarding plane = does not offer any security features, if security is required it must be = provided by the SFC layer using some mechanisms inherent in the NSH. We = could/should probably also observe that, as yet, no NSH security = mechanisms have been defined. Cheers, Adrian -----Original Message----- From: ietf On Behalf Of Paul Wouters Sent: 17 February 2019 23:58 To: secdir@ietf.org Cc: mpls@ietf.org; draft-ietf-mpls-sfc-encapsulation.all@ietf.org; = ietf@ietf.org Subject: Secdir last call review of draft-ietf-mpls-sfc-encapsulation-02 Reviewer: Paul Wouters 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 summary of the review is Ready While I'm not familiar with the Service Function Chaining (SFC) = architecture and the Network Service Header (NSH), the Security Considerations in = this document seem to be correct in pointing out that: This document simply defines one additional transport encapsulation. The NSH was specially constructed to be agnostic to its transport encapsulation. As as result, in general this additional encapsulation is no more or less secure than carrying the NSH in any other encapsulation. From nobody Sun Feb 17 16:59: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 42B5712E04D; Sun, 17 Feb 2019 16:59:25 -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, 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 YMBS5eosftrW; Sun, 17 Feb 2019 16:59:22 -0800 (PST) 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 6A35C130DE5; Sun, 17 Feb 2019 16:59:22 -0800 (PST) Received: from [10.255.254.3] (unknown [31.220.15.140]) (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 9A28518015A3; Mon, 18 Feb 2019 01:59:18 +0100 (CET) From: Loa Andersson To: "mpls@ietf.org" , "mpls-chairs@ietf.org" , "draft-ietf-mpls-rmr@ietf.org" , Deborah A Brungard References: <1bf361f0-1987-ce4e-0671-d46886898e44@pi.nu> Message-ID: <4a5eb0ec-38d5-a74b-56d4-1d2779f52b73@pi.nu> Date: Mon, 18 Feb 2019 08:59:13 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <1bf361f0-1987-ce4e-0671-d46886898e44@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 last call on draft-ietf-mpls-rmr 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, 18 Feb 2019 00:59:25 -0000 Working Group, This working group last call is closed. There has been some comments (Pavan and Sue), could the author please decide how they want to respond to the comments and update the draft as necessary. /Loa mpls wg co-chair On 2019-01-15 16:10, Loa Andersson wrote: > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-rmr. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > There are no IPR disclosures directly against draft-ietf-mpls-rmr, but > an IPR (#2661) were disclosed against the individual document that we > adopted as a working group document. > > Both authors have stated on the working group mailing list that they > are unaware of any non-disclosed IPRs that relates to this document. > > This working group last call ends Wednesday January 30, 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 Feb 18 02:11:48 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 A8B23130EEF; Mon, 18 Feb 2019 02:11:40 -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 Wrqx0-ZKzI1m; Mon, 18 Feb 2019 02:11:38 -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 2734A130EEC; Mon, 18 Feb 2019 02:11:38 -0800 (PST) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 5B44719CC5C6C19F10FE; Mon, 18 Feb 2019 10:11:36 +0000 (GMT) Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 18 Feb 2019 10:11:35 +0000 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.6]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0415.000; Mon, 18 Feb 2019 18:11:24 +0800 From: Mach Chen To: Benjamin Kaduk CC: Linda Dunbar , "secdir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org" , "ietf@ietf.org" Thread-Topic: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05 Thread-Index: AQHUkY+Xr7eIQ7lWe0az4uRG6fBCdqV9d+SwgERX9oCAHShNQIADyugAgALw4PA= Date: Mon, 18 Feb 2019 10:11:24 +0000 Message-ID: References: <154455986336.13151.8483284555885294015@ietfa.amsl.com> <20190126211729.GJ49072@kduck.mit.edu> <20190216202815.GD82217@kduck.mit.edu> In-Reply-To: <20190216202815.GD82217@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] [secdir] Secdir 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: Mon, 18 Feb 2019 10:11:41 -0000 Hi Benjamin, > -----Original Message----- > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > Sent: Sunday, February 17, 2019 4:28 AM > To: Mach Chen > Cc: Linda Dunbar ; secdir@ietf.org; > mpls@ietf.org; draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org; > ietf@ietf.org > Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping= -lag- > multipath-05 >=20 > Hi Mach, >=20 > My apologies as well for the delay. >=20 > On Thu, Feb 14, 2019 at 03:02:07AM +0000, Mach Chen wrote: > > Hi Benjamin, > > > > Sorry for the delayed response! > > > > Please see my response inline... > > > > > -----Original Message----- > > > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > > > Sent: Sunday, January 27, 2019 5:17 AM > > > To: Mach Chen > > > Cc: Linda Dunbar ; secdir@ietf.org; > > > mpls@ietf.org; draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org; > > > ietf@ietf.org > > > Subject: Re: [secdir] Secdir last call review of > > > draft-ietf-mpls-lsp-ping-lag- > > > multipath-05 > > > > > > On Fri, Dec 14, 2018 at 02:11:21AM +0000, Mach Chen wrote: > > > > Hi Linda, > > > > > > > > Thanks for the review! > > > > > > > > Some responses inline... > > > > > > > > > -----Original Message----- > > > > > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Linda > > > > > Dunbar > > > > > Sent: Wednesday, December 12, 2018 4:24 AM > > > > > To: secdir@ietf.org > > > > > Cc: mpls@ietf.org; > > > > > draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org; > > > > > ietf@ietf.org > > > > > Subject: Secdir last call review of > > > > > draft-ietf-mpls-lsp-ping-lag-multipath-05 > > > > > > > > > > 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 summary of the review is Ready with comment > > > > > > > > > > The described mechanism for LSP Multipath Ping is very clear. > > > > > The Security Consideration re-uses the description of RFC8029, > > > > > which is very comprehensive. > > > > > It would be better if the draft describes how to prevent > > > > > intermediate LSRs in between the Initiating LSR and Responding > > > > > LSR from mis-using the detailed link information (e.g. > > > > > forwarding to > > > somewhere else). > > > > > > > > The Echo Request and Reply messages are directly exchanged between > > > > the > > > Initiating LSR and the Responding LSR, those intermediate LSRs just > > > forward the messages as normal packets, they will not see the > > > detailed link information unless if they inspect and do DPI on every > > > packet forwarded by them. > > > > > > > > The detailed link information is supplied to the Initiating LSR > > > > for using, the > > > intermediate LSRs will not try to use it even if they received the > > > information, because there is no corresponding Echo Request to the > received Echo Reply. > > > > > > The intermediate LSRs still will have access to the plaintext > > > information, even if in normal operation they do not need to act upon > that information. > > > Generally in this sort of situation we will either explicitly state > > > that the intermediate nodes must be trusted to not abuse the > > > information in question, or provide some mechanism for end-to-end > > > confidentiality protection. > > > > "Intermediate nodes must be trusted to not abuse the information" is > normally assumed. For the intermediate nodes, there is no different > between the Echo Reply messages and any other data traffic, control > messages. They just forward the Echo Reply messages as normal packets. I > am not sure it needs to explicitly state this. Do you suggest to add suc= h a > statement in the security consideration section? >=20 > The concern is not about the normal operation, but rather about abnormal > operation, e.g., if an intermediate node gets compromised by an attacker. > We need to document the new abilities an attacker gets, when comparing > the original case of "an attacker compromises an intermediate node that i= s > using MPLS without this mechanism" to the new case of "an attacker > compromises an intermediate node that is using MPLS with this mechanism". > So, while I do suggest adding a statement to the security considerations > section, the statement I want does not relate to the normal operation cas= e > (when intermediate nodes ignore the contents of the message). OK, will add such a statement in the security considerations section.=20 >=20 > > > > > > Also (noting that I only skimmed the document so this may not make > > > sense), the security considerations seem to suggest using an IP ACL > > > for determining which messages are trusted; IP ACLs are generally > > > not recommended in favor of cryptographic mechanisms at this point. > > > > IP ACLs was introduced in RFC 8029 and is reused in this document, > > it's >=20 > I did not find a clear and explicit declaration in RFC 8029 of the concep= t of an > IP ACL; I assume you are referring to: >=20 > To protect against unauthorized sources using MPLS echo request > messages to obtain network information, it is RECOMMENDED that > implementations provide a means of checking the source addresses of > MPLS echo request messages against an access list before accepting > the message. Yes, this is that I am referring to. >=20 > I do not think anyone is going to say "do not filter based on IP source > address", but there would be general skepticism about relying upon it as = a > sole security mechanism. >=20 > > just one of the security mechanisms. This document is an extension to >=20 > (Could you remind me of the other mechanisms? I don't think I have a goo= d > handle on them.) You are right, for protecting against unauthorized sources, IP ACL is the o= nly way proposed in RFC 8029 and this document.=20 >=20 > > RFC 8029, as stated in this document, all security considerations > > defined in RFC 8029 apply to this document. Do you have any specific > > suggestion to the current security consideration? >=20 > I am mostly just lamenting the state of affairs; this is a sufficiently > incremental change that it is inappropriate to require dramatic changes i= n the > security mechanisms. I agree with you. Does it mean that you are OK with the current security co= nsiderations, given that a statement regarding the intermediate node's proc= ess will be added. Best regards, Mach >=20 > -Ben From nobody Mon Feb 18 06:52: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 2DD7C1293B1; Mon, 18 Feb 2019 06:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Cz5U-ZOLzokx; Mon, 18 Feb 2019 06:51:51 -0800 (PST) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720097.outbound.protection.outlook.com [40.107.72.97]) (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 7FA1A128B01; Mon, 18 Feb 2019 06:51:51 -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=lVYPbnYPkpm/bwDCOEPn0B1t8qnyLYO4Y6dxuGmnqS0=; b=aEP/0P+4/bAV94OakfTNRvahNI4bG4Y7LzHKEbO4aUgE96bAm5FbC+IsDIgBKLzwLNtxzKAbnmCcp4RTgAkmRg51nxh+rFKadFzST4gxjq06Zd2jUZlyQmPraX9pV+c94lhw8VSlmrbt2eX20eaP/JpM9TtXFqWo1Gjcx6wqCbI= Received: from CY4PR01CA0024.prod.exchangelabs.com (2603:10b6:903:1f::34) by SN6PR01MB4863.prod.exchangelabs.com (2603:10b6:805:d8::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.18; Mon, 18 Feb 2019 14:51:49 +0000 Received: from CO1NAM03FT023.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::201) by CY4PR01CA0024.outlook.office365.com (2603:10b6:903:1f::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16 via Frontend Transport; Mon, 18 Feb 2019 14:51:49 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; 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 CO1NAM03FT023.mail.protection.outlook.com (10.152.80.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.13 via Frontend Transport; Mon, 18 Feb 2019 14:51:48 +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 x1IEpiIl031107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Feb 2019 09:51:46 -0500 Date: Mon, 18 Feb 2019 08:51:44 -0600 From: Benjamin Kaduk To: Mach Chen CC: Linda Dunbar , "secdir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org" , "ietf@ietf.org" Message-ID: <20190218145144.GG24387@kduck.mit.edu> References: <154455986336.13151.8483284555885294015@ietfa.amsl.com> <20190126211729.GJ49072@kduck.mit.edu> <20190216202815.GD82217@kduck.mit.edu> 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) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(346002)(39860400002)(136003)(396003)(376002)(2980300002)(13464003)(189003)(199004)(55016002)(8936002)(305945005)(8676002)(229853002)(7696005)(14444005)(76176011)(93886005)(53416004)(47776003)(50466002)(88552002)(5660300002)(356004)(1076003)(97756001)(246002)(2906002)(478600001)(26826003)(106466001)(956004)(446003)(6916009)(86362001)(6246003)(36906005)(46406003)(336012)(486006)(126002)(426003)(4326008)(476003)(11346002)(186003)(23726003)(26005)(53546011)(104016004)(58126008)(54906003)(16586007)(75432002)(106002)(786003)(316002)(33656002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR01MB4863; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: be2d71d8-ad48-4ebb-e147-08d695b09c53 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:SN6PR01MB4863; X-MS-TrafficTypeDiagnostic: SN6PR01MB4863: X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB4863; 20:ym0GVIZcxbl/bnNQVTKyq9Qkuf91nUNkTgV2HhhgSFHbtxZC5ceiMpHCkoWV8lxYPwtEdDGUPphqdKu+gYJk/rl5Sc4xqEJwb/zLA45c7A2o0mZ/iae+4J+D7TiMsYfTw/3HYQUAT2O9ceDH6yPywTZMcd2Od5/esPjTjUMBkeOKofaKC+vjgjwik13IwpvY4Tghp6fvU/C3UN8VZSThEhLvLzw7D45TBFep0xt2J3655KAr3IFU+IkYgXZ2zmEljvzDuSEdnmf0QU4Rv3QT0pbe6DaT4t/0vVFS/7OR4ZnpDpGeDgzUtKsKIYx86KAhwvtmJw0rYMnGDUkW3nzqZv2ZA1I75YrW/lVrMCK42eMHyT0jwrilLaztS0SMh9inymgz2Z1eLJPTw4Sp/28ETqg/jb1PiUhq+A2UN02KWXSqwqTzJ7IIu+fxZ9k0tr7epQr+UGaQ7hdPPpZDmo26FqgxtJ0iSUUsTzqtzY2/RXDUwQDHLqbbcjbf52q0cl3CRi7LXPaBBJ7mMRwM5K8V+/DsJgotE8leZnohIUArm+TULHg5mixpIn8s0TM8uAz3VANWtiKSs7dXBkEGKa0sWmS8jEHsnXMgPLkzD3tqMnk= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09525C61DB X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN6PR01MB4863; 23:RlpfaBZzEPRXK8P9ARlMbNAqMLnUBDd5GSD4ol+T+?= =?us-ascii?Q?Zp58+rzdsfnWJ2ELub1Gm47E2kEbTRPriWs44thxxDplN/FKUgIEcUSjYHLU?= =?us-ascii?Q?bsPnyVOOEulZo3BGMTnuSq2c8cPNttOn64zdR8PsXjvwvyf8+NBQUKZx16Vh?= =?us-ascii?Q?b3a6ItuK3LABwvlyT3wwhN17ucXHWf7UOsfYPoEertFKUagmwNfn+MgUuFUB?= =?us-ascii?Q?0k00A5Ts2+BRYhJrUzm/SGmd2z/hvU/y0ZUbS015s444QDBaHaPWHJJITVK8?= =?us-ascii?Q?USSYixoo8AwBpuNrEBbc7kKqeW5BsusQbT+mlTOwB+2v0qEiZCB3SDdOl6+M?= =?us-ascii?Q?d8uKxZLt9ViFWWW0QkjxSnjgeNFHy37TgHP+cQuxsfu+71mVelNt607805ol?= =?us-ascii?Q?gcMyxzmqeHelwFexRT7JIqcEmYq8sXlN64dnnk7KtRQMWM6Mu5JAmk0ZtFrg?= =?us-ascii?Q?y3nFuSwfS34nUt2Hp5PgMLRNyNSujCWFoFqxVHPNvDjbYX+9zqKWlh9NMQY6?= =?us-ascii?Q?yTKT4zlCTv6uUPGIBwn9bKjJiDPvd1hGRRTTOs+mk4LMWTGCE/X6ihg93DL8?= =?us-ascii?Q?Yu0m5hwEF4+aoH1q3kKJhbTyWHlUEghzvjiyvN1kKaX2Oc36kL2Zwb0ykWgM?= =?us-ascii?Q?D5p3WGC0upuL1I0+cNAQ4/jbVe2NO0oY3jKPATJX9tj28ol8T5dkFLtJkML2?= =?us-ascii?Q?czH4W8KweIhSfWX3UWtslk2uf1QAwuSLVOawfYqVod/FL9ANtpyQFxJcE+NO?= =?us-ascii?Q?5L7lZU83CBZXE+udtqfnIWDM2xO25WM08N1gc6hiT4gMmldRvLZBoLJ2ZZFv?= =?us-ascii?Q?mwacEQwmc1P5Rdk5DnluMNHl6JCRdUW9siL3F9JhF/UpvI57HnZSwdf1/zCZ?= =?us-ascii?Q?DUUMOaqq5xqboUk3V5mQaC7PF8UDH8uq8slHRWvTQo7iDdj0gCHo2DQbiAU8?= =?us-ascii?Q?ng3tj/fLdBYBZSaYIbW7CQC1zGXeXCpwgOL91KCl8nsQCI0wR/nnxzE9SRof?= =?us-ascii?Q?YjwLMsNRqqTVbCeOY+VRCG5GgsPXLSm1UapIVvEq3N89LBbIuf5Ry0bqjKS6?= =?us-ascii?Q?WZKl7X3D4TOI3x51R7jGm6kCKhPsyLzsrbO/0pl/FSgs7sW3sdIcCtERe8VZ?= =?us-ascii?Q?eM3cc/Ytk2hojNd9QvW/JJzO3+ex36C7KQgVIH7y+vWH9sThHMLjAJ+tdjJp?= =?us-ascii?Q?6W7yxzsYMDI7sZ5FlUps+kvpcoVSI4kChQVE4Upy5tpeNFiFMpioJLCkfeUm?= =?us-ascii?Q?rDjblOa5P8MM3OEzx/wOZ19NOPm4He7i8gtCskHzoQlJEUIotHooLbzC1gJh?= =?us-ascii?B?Zz09?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: WGuFwtGUsdiMOeUxAOx5S9pwVIQYyR5QusLdVhqekwUtynGHckmKTG0YIE3BWyW34dWTzUpJr1rGuMnzGQP7nTtZFyTIH7K8jwUOlZepDtXRJ7S+nmiBqD+ytUfWxVbvIZgw5hpkfQtGJq8NwZD98JdS7ASzmGyFxAnzuHJwtBis18kkrLhfsT90jdOtGlOqHyI5Zegdgu5ckQs7dz6f16ll++2k5mcEoHjpe/ggvTipdYgAMgVgRYPy1ybUSFGa2YyAlHruGbZ3wbvsbEEwEQPIO0kG58NRGv1Hd9oASntmhjyu/5m8hInwhp/cRPq8fEqKHOuYickAcsOUtfSBqq0YYA5Z+G19sEbphFHkGl87feqJ1cGnfMgez6btjj/8HPtB5fVSvjUmfdF4+C94y4EMGAk9gb8oLROEB22LhZc= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Feb 2019 14:51:48.4495 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: be2d71d8-ad48-4ebb-e147-08d695b09c53 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: SN6PR01MB4863 Archived-At: Subject: Re: [mpls] [secdir] Secdir 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: Mon, 18 Feb 2019 14:51:54 -0000 On Mon, Feb 18, 2019 at 10:11:24AM +0000, Mach Chen wrote: > Hi Benjamin, > > > -----Original Message----- > > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > > Sent: Sunday, February 17, 2019 4:28 AM > > To: Mach Chen > > Cc: Linda Dunbar ; secdir@ietf.org; > > mpls@ietf.org; draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org; > > ietf@ietf.org > > Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag- > > multipath-05 > > > > Hi Mach, > > > > My apologies as well for the delay. > > > > On Thu, Feb 14, 2019 at 03:02:07AM +0000, Mach Chen wrote: > > > Hi Benjamin, > > > > > > Sorry for the delayed response! > > > > > > > > > "Intermediate nodes must be trusted to not abuse the information" is > > normally assumed. For the intermediate nodes, there is no different > > between the Echo Reply messages and any other data traffic, control > > messages. They just forward the Echo Reply messages as normal packets. I > > am not sure it needs to explicitly state this. Do you suggest to add such a > > statement in the security consideration section? > > > > The concern is not about the normal operation, but rather about abnormal > > operation, e.g., if an intermediate node gets compromised by an attacker. > > We need to document the new abilities an attacker gets, when comparing > > the original case of "an attacker compromises an intermediate node that is > > using MPLS without this mechanism" to the new case of "an attacker > > compromises an intermediate node that is using MPLS with this mechanism". > > So, while I do suggest adding a statement to the security considerations > > section, the statement I want does not relate to the normal operation case > > (when intermediate nodes ignore the contents of the message). > > OK, will add such a statement in the security considerations section. Thanks! > > > > > > > > > > Also (noting that I only skimmed the document so this may not make > > > > sense), the security considerations seem to suggest using an IP ACL > > > > for determining which messages are trusted; IP ACLs are generally > > > > not recommended in favor of cryptographic mechanisms at this point. > > > > > > IP ACLs was introduced in RFC 8029 and is reused in this document, > > > it's > > > > I did not find a clear and explicit declaration in RFC 8029 of the concept of an > > IP ACL; I assume you are referring to: > > > > To protect against unauthorized sources using MPLS echo request > > messages to obtain network information, it is RECOMMENDED that > > implementations provide a means of checking the source addresses of > > MPLS echo request messages against an access list before accepting > > the message. > > Yes, this is that I am referring to. > > > > > I do not think anyone is going to say "do not filter based on IP source > > address", but there would be general skepticism about relying upon it as a > > sole security mechanism. > > > > > just one of the security mechanisms. This document is an extension to > > > > (Could you remind me of the other mechanisms? I don't think I have a good > > handle on them.) > > You are right, for protecting against unauthorized sources, IP ACL is the only way proposed in RFC 8029 and this document. > > > > > > RFC 8029, as stated in this document, all security considerations > > > defined in RFC 8029 apply to this document. Do you have any specific > > > suggestion to the current security consideration? > > > > I am mostly just lamenting the state of affairs; this is a sufficiently > > incremental change that it is inappropriate to require dramatic changes in the > > security mechanisms. > > I agree with you. Does it mean that you are OK with the current security considerations, given that a statement regarding the intermediate node's process will be added. Given what I've seen so far, yes. (I only skimmed the document as part of this thread, and will do a full review as it comes up on an IESG telechat.) -Benjamin From nobody Tue Feb 19 21:35: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 D6CE0129619; Tue, 19 Feb 2019 21:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 DmsU2UHeVg6E; Tue, 19 Feb 2019 21:35:48 -0800 (PST) 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 4EC59130DC9; Tue, 19 Feb 2019 21:35:46 -0800 (PST) Received: from [192.168.1.20] (unknown [119.94.174.90]) (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 8DC8D180157E; Wed, 20 Feb 2019 06:35:43 +0100 (CET) From: Loa Andersson To: "mpls@ietf.org" Cc: "mpls-chairs@ietf.org" , "draft-zheng-mpls-lsp-ping-yang-cfg@ietf.org" Message-ID: <98db7e71-6152-1335-8ca0-b5ae67b8a4b6@pi.nu> Date: Wed, 20 Feb 2019 13:35:40 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] 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: Wed, 20 Feb 2019 05:35:51 -0000 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 Wed Feb 20 03:30: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 8F0A812D826; Wed, 20 Feb 2019 03:30:38 -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, SPF_PASS=-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 8Y6KFZLfpcWH; Wed, 20 Feb 2019 03:30:37 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30123.outbound.protection.outlook.com [40.107.3.123]) (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 E7F00128CF2; Wed, 20 Feb 2019 03:30:36 -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=2uQnfuIYn16v2RjwYCfp/Y14NnmrpfAxLziTpLGgpGA=; b=Eshk7zqDNeTh88uvZPjpyT0bTBEs0lc6yn93biqLoJHJjj/ynoovZmgxpoBQE68pDQysJf9p+Kkdwu9MFGR/ub/lZjyFrxTDiZVDXWoaDkKchrfLHCpOs7RMK5VY4ExzxaT0Lh1vBunTiZAaXmhcwwgI/1vY+RZokc4nH9fC+L8= Received: from VI1PR07MB4768.eurprd07.prod.outlook.com (20.177.57.155) by VI1PR07MB6141.eurprd07.prod.outlook.com (20.178.124.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.11; Wed, 20 Feb 2019 11:30:34 +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.1643.014; Wed, 20 Feb 2019 11:30:34 +0000 From: tom petch To: Loa Andersson , "mpls@ietf.org" CC: "mpls-chairs@ietf.org" , "draft-zheng-mpls-lsp-ping-yang-cfg@ietf.org" Thread-Topic: [mpls] Working Group Adoption Poll on draft-zheng-mpls-lsp-ping-yang-cfg Thread-Index: AQHUyQ+ywD+0BDpFC0yeZz/8w8buHA== Date: Wed, 20 Feb 2019 11:30:34 +0000 Message-ID: <020301d4c90f$748bd300$4001a8c0@gateway.2wire.net> References: <98db7e71-6152-1335-8ca0-b5ae67b8a4b6@pi.nu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0252.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8a::24) 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: 1d82f132-9203-4500-15bc-08d69726d45a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB6141; x-ms-traffictypediagnostic: VI1PR07MB6141: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0954EE4910 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(346002)(376002)(136003)(39860400002)(199004)(13464003)(189003)(9686003)(50226002)(102836004)(52116002)(99286004)(6306002)(6512007)(68736007)(478600001)(446003)(486006)(476003)(54906003)(53936002)(4720700003)(1556002)(86152003)(8936002)(6436002)(110136005)(316002)(229853002)(44736005)(6486002)(76176011)(6506007)(33896004)(81816011)(386003)(81686011)(71190400001)(86362001)(84392002)(256004)(966005)(5660300002)(2906002)(71200400001)(61296003)(62236002)(106356001)(105586002)(4326008)(25786009)(6246003)(66066001)(44716002)(186003)(81156014)(81166006)(305945005)(14454004)(7736002)(6116002)(2501003)(3846002)(8676002)(97736004)(26005)(14496001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB6141; 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) x-microsoft-exchange-diagnostics: =?iso-8859-1?Q?1; VI1PR07MB6141; 23:U4j5Vi43BAK3D/3G8kqnIpJKq1JVbDUBn+UHhyH?= =?iso-8859-1?Q?zsCjiSN0TY0mZUlCiGuii9iw0ZZWtJG2GIOY7Dz+7Hf5CdeqO2AkEEes6U?= =?iso-8859-1?Q?gdBnpWLHze0HlLTwrQ5ik27dk4VyEpbVReUO+Jed7w+Cvbp4Ubk2FxhwoJ?= =?iso-8859-1?Q?xtLSZbHS33n4Yz+PFCe3xg8uB8FAGs95h27zdLpwwU3S3Wal0k5Oyc+nkl?= =?iso-8859-1?Q?V5HH/V70O4bnOWYa7aGG1oT3wQx9SPPajzYLmhhVeWWSaXznZvAA+OHhWk?= =?iso-8859-1?Q?5fq8sNWkAiOm0PfPR5lizAN8dRqg8u7lW6FvCyGOp0Fxd7x9hrIS9de30K?= =?iso-8859-1?Q?bX9pVZuOIflhVYbaD/dEyjDdTCnz4LoaDNH961AhYA8fUGTr2tPj+t5aCj?= =?iso-8859-1?Q?UprxpMKH6ZCKijPbjT82W0G2zjxN50a7IBqdRajrwx3w/eh4j9IM96SqX7?= =?iso-8859-1?Q?DF0GTspbEm1qCeatBw4lu7E6sb0KMx3L1X7v5RN3cf/taXyjR2O6RVaKd2?= =?iso-8859-1?Q?gmFx1qPaz9dcrvW3awVmZWHtaPfkGScZr5MlMifg7/ut5ymLv8qZ1lB7sz?= =?iso-8859-1?Q?Sf0JupmzKMhMh3wJnBtYG0ZvlZE818YQUGJ9pzBoCvz5ov+qeHPlMADJxs?= =?iso-8859-1?Q?YxzpHYH+r+TAhTnAfmkADqm8fwBjXtc5IaBzwCjcUIWKf26yxXlGhIuhHo?= =?iso-8859-1?Q?cZmal0EkqL6ZPNEbN1J2PRwjkLs2gpK6v6tCudFFXYCINMsBkPKq9UkU6u?= =?iso-8859-1?Q?ZCP0FJmZoiXb/olgEXEysUI1QOunkeJNiP85BFb+7NAY8dtvh92WR4ECis?= =?iso-8859-1?Q?OxZ0nFNYFiOULYMj9xPAPMJp5SHQkl8FDahKp1hZahZDnPOOd56ZWqJiJm?= =?iso-8859-1?Q?47CAUzpwvmFrctLCDNP13KXiKijczz5eGdVLDUPmMRrfIX4V3fggFh/ocy?= =?iso-8859-1?Q?vhaBW22+Mep0RIl1tM6gPe1aHZ023i7REl2yygRIwHCwuw7QeO/fnahGpb?= =?iso-8859-1?Q?wv0ZDZRno1gdRYskadeT/nVB0hCO0qDTvWHeyzBN8r56iVw6HgdIRRM20B?= =?iso-8859-1?Q?J10PPC/vmJQf5L9jCm1lgfqS+R55HC8UQADyaigBuyA5E03dZ4pNK0aIDu?= =?iso-8859-1?Q?8g7UUQ4b/PfRO/dTGNnMtu++FY4rPvkb1mlQtpmLm+/H8Palcl0IjJStgh?= =?iso-8859-1?Q?lZbluOMQ0Nt26XV1hnUSFXgf3383/74RZQTdcVY0c9mMqjPieVUCrh3ePV?= =?iso-8859-1?Q?zLN2U7dF93FWLM0u8L68gsWzcGG5n0Ax5XfKM3VBftykBbQWjIDB/31iSS?= =?iso-8859-1?Q?S8GSoS5gM9XFE+r2QREbWlXzeV4C3LfRLCXgxdE4HtABlEAyiPqH1AKg28?= =?iso-8859-1?Q?v3VzfAw/Xtn3xrUeB4E9qihqAQN1Zh8kkI8i9JoMCQm4oQvIBdjd+XhxHM?= =?iso-8859-1?Q?ihsDzGpepjm1mIafnjX/J/b/YfR/l4rz0nBsXaV2Ye1+/BuYfR/A6J+xmc?= =?iso-8859-1?Q?OL7JmyInZ96iWRXvHoWfp+LxsYnICILExGBIbTcFnkaImbru87W8cc0bDl?= =?iso-8859-1?Q?q/kzr/rwZl36h3FTWkinQYGuI7cj6dqsO7nak54f0YtngesOibvZeTOkXG?= =?iso-8859-1?Q?886eYsspxog=3D=3D?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: BlXio5Gk7YlxKo1OKtPhJuBamI7xCaKH+Dn6kXh6M3LVbnFGH3smvml8lzT0bv+ZlAZEJw+/G5P2m5Vhph4h9tPDL8H4RMwyLKg8H5BScM7FNKczi7Emog3GOyhpSVtPA+keiIRITMBc7LSWfr97VXqqq7IbbVxTgwEqqZMnqqF549mzJGZAe/qiGSWccisM+VuMt1uryT8hvwQfNfDJkmtS3XAmpQIe6YR1UrQctMYKTWAZYCDFPhPOd1lf0zIAbXFAhcO9SBNcLtmo+T42n6fEBa9ZatC2XYp+2HeJF7ujUn7x7FtfRVqOqu4/wg2jNKKn7A2OdMv0fV34cFjPX7U1lyiIVWUwwEsMdMmubKV7yB0xlwnBBs+3iYkcHIYZyBMm+8Q/batEhktA7j2OH5PkLUTChnmDGJtTtOeGqRM= Content-Type: text/plain; charset="iso-8859-1" Content-ID: <619EC5B61417F54EB4AF8BE1BBA43B95@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1d82f132-9203-4500-15bc-08d69726d45a X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2019 11:30:34.2766 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6141 Archived-At: Subject: Re: [mpls] 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: Wed, 20 Feb 2019 11:30:38 -0000 Not support The YANG module is very weak on references which makes it hard for me to be sure but there seems to be a mismatch between e.g. FEC classes in RFC8029 and the YANG module. Thus RFC809 has 1 5 LDP IPv4 prefix with a one byte prefix length and four byte prefix. The YANG module has enum ip-prefix { value "0"; description "IPv4/IPv6 prefix"; and choice target-fec { case ip-prefix { leaf ip-address { type inet:ip-address; description "IPv4/IPv6 Prefix"; where ip-address has no concept of prefix length how can that be configured?. There are many such instances IMHO; having references in the YANG module to sections of RFC8029 would make this more apparent. Tom Petch ----- Original Message ----- From: "Loa Andersson" To: Cc: ; Sent: Wednesday, February 20, 2019 5:35 AM > 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 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Feb 20 07:48: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 E817D130E5F; Wed, 20 Feb 2019 07:47:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks 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.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155067766687.31388.18349714938448955572@ietfa.amsl.com> Date: Wed, 20 Feb 2019 07:47:46 -0800 Archived-At: Subject: [mpls] Genart last call review of draft-ietf-mpls-sr-over-ip-02 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, 20 Feb 2019 15:47:47 -0000 Reviewer: Robert Sparks Review result: Ready with Nits 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. For more information, please see the FAQ at . Document: draft-ietf-mpls-sr-over-ip-02 Reviewer: Robert Sparks Review Date: 2019-02-20 IETF LC End Date: 2019-02-26 IESG Telechat date: Not scheduled for a telechat Summary: Ready, but with nits that should be addressed before publication as a Standards Track RFC Nits The 2nd sentence of the introduction is complex. It should be easy to simplify. 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) In that same paragraph, something is wrong at "make use of entropy label mechanism." Should that be "the entropy label mechanism"? SRGB is used without expansion. 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. Section 3.1 is about ostensibly about constructing a FIB entry, but its last step is sending a packet. The first sentence in section 3.2 is more complex than it needs to be. It should be easy to simplify. 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): s-----s i-----i | A +------+ B +-- s-----s i--+--i | At the first paragraph on page 9: s/and then process/and then processes/ From nobody Wed Feb 20 08:22: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 8CD3C12F19D; Wed, 20 Feb 2019 08:22:44 -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 kQUPWo4UI-lx; Wed, 20 Feb 2019 08:22:42 -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 8A54C12870E; Wed, 20 Feb 2019 08:22:41 -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 x1KGMdwn006497; Wed, 20 Feb 2019 16:22:39 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 924782203A; Wed, 20 Feb 2019 16:22:38 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id 869DF22044; Wed, 20 Feb 2019 16:22:38 +0000 (GMT) Received: from LAPTOPK7AS653V ([114.247.104.200]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id x1KGMWYV019450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 20 Feb 2019 16:22:35 GMT Reply-To: From: "Adrian Farrel" To: "'Robert Sparks'" , Cc: , , References: <155067766687.31388.18349714938448955572@ietfa.amsl.com> In-Reply-To: <155067766687.31388.18349714938448955572@ietfa.amsl.com> Date: Wed, 20 Feb 2019 16:22:31 -0000 Organization: Old Dog Consulting Message-ID: <04c001d4c938$7e3d86e0$7ab894a0$@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: AQF4uyAuQiUz1zT6JW7t9AabcMIgdqag+eEA Content-Language: en-gb X-Originating-IP: 114.247.104.200 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-24444.000 X-TM-AS-Result: No--6.875-10.0-31-10 X-imss-scan-details: No--6.875-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24444.000 X-TMASE-Result: 10--6.875100-10.000000 X-TMASE-MatchedRID: oHOSwQSJZWjxIbpQ8BhdbBMMmcrjEONd+IfriO3cV8SabNoYojBQdiGZ 6VVOVYeW7dnYL8JC+0XUmqAjrrnfrJIB4waj1+h9CmEn+y8Sa8b2kudi1D33EjyC5ddG2JcgMHF tu0lPAG76E2YHggZaQtcpv7GvOwuKFDf/GgM78iUXrP0cYcrA23OKOUMFh4P85DJ1FS+XdBP7XJ 5E3BcU3MyPK22RoB20JIVdEtqJTGx4+z8LHUMl3Z1U1lojafr/bv16+gil4jeX1RWcrwojHEj8A tVpDcmgwbJMFgUlJjevc0qsf6qV8Ucld4HSm4ijsyNb+yeIRAoTskidPjB12gDqzaYhcjeQAX0N cth4O8nnICRLH3OSnjU3TINr6s6sbLfoydCzQDMOrlBkQa9qFiNGSJ9zRuUNCVuEXtlNqcv1Xsi 2J/hIsxPyIdXWTILbw6cKPh/0DZG5F/6XhVIKVo3NgkEqAN0RfS0Ip2eEHnwa2S8rkvtFcbDszp 3K5gqDjoczmuoPCq3ZtQwo6oIY+se6fE3ZVPPhAYB8H/4m94QlsEBx8s1Oadlhg0pKM5dp X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] 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, 20 Feb 2019 16:22:45 -0000 That's a good review, Robert, thank you. The changes look achievable to me, and I'm sure the author team can work = to include them. Cheers, Adrian -- Want to buy a signed copy of a book of fairy stories for adults of all = ages? Send me an email and I'll bring one to Prague for you. "Tales from the Wood" "More Tales from the Wood" "Tales from Beyond the Wood" https://www.feedaread.com/profiles/8604/ -----Original Message----- From: ietf On Behalf Of Robert Sparks Sent: 20 February 2019 15:48 To: gen-art@ietf.org Cc: mpls@ietf.org; ietf@ietf.org; = draft-ietf-mpls-sr-over-ip.all@ietf.org Subject: Genart last call review of draft-ietf-mpls-sr-over-ip-02 Reviewer: Robert Sparks Review result: Ready with Nits 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. For more information, please see the FAQ at . Document: draft-ietf-mpls-sr-over-ip-02 Reviewer: Robert Sparks Review Date: 2019-02-20 IETF LC End Date: 2019-02-26 IESG Telechat date: Not scheduled for a telechat Summary: Ready, but with nits that should be addressed before = publication as a Standards Track RFC Nits The 2nd sentence of the introduction is complex. It should be easy to = simplify. 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) In that same paragraph, something is wrong at "make use of entropy label mechanism." Should that be "the entropy label mechanism"? SRGB is used without expansion. 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. Section 3.1 is about ostensibly about constructing a FIB entry, but its = last step is sending a packet. The first sentence in section 3.2 is more complex than it needs to be. = It should be easy to simplify. 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): s-----s i-----i | A +------+ B +-- s-----s i--+--i | At the first paragraph on page 9: s/and then process/and then processes/ From nobody Wed Feb 20 16:41: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 B9F3F130F28; Wed, 20 Feb 2019 16:41:00 -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, 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 Brco5pg6l771; Wed, 20 Feb 2019 16:40:57 -0800 (PST) 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 E3602130F47; Wed, 20 Feb 2019 16:40:55 -0800 (PST) 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 D39D81801556; Thu, 21 Feb 2019 01:40:51 +0100 (CET) To: tom petch , "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> <020301d4c90f$748bd300$4001a8c0@gateway.2wire.net> From: Loa Andersson Message-ID: Date: Thu, 21 Feb 2019 08:40:46 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <020301d4c90f$748bd300$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] 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: Thu, 21 Feb 2019 00:41:01 -0000 Tom, Much as I appreciate your comments, and I agree with the technical aspects of them. The references and the inconsistencies should be fixed. However, I have a little bit different view of what should be done. It is clear that we need a YANG module for LSP Ping. It is unlikely that there will be another document. This document has been very slow developing, the first version is from 2015. I think that we should say that this is "a good enough starting point", and that there are thing that need to be fixed before publication, e.g the RPCs mentioned by Acee, and the lack of references and the potential inconsistencies pointed out by you. To put the working group in control of the draft and make sure that it progress well I want to adaopt it as a working group document. The only thing I believe is necessary is that the authors acknowledge that the issues pointed out needs to be addressed. /Loa On 2019-02-20 19:30, tom petch wrote: > Not support > > The YANG module is very weak on references which makes it hard for me to > be sure but there seems to be a mismatch between e.g. FEC classes in > RFC8029 and the YANG module. > > Thus RFC809 has > 1 5 LDP IPv4 prefix > with a one byte prefix length and four byte prefix. > > The YANG module has > enum ip-prefix { > value "0"; > description "IPv4/IPv6 prefix"; > and > choice target-fec { > case ip-prefix { > leaf ip-address { > type inet:ip-address; > description "IPv4/IPv6 Prefix"; > where ip-address has no concept of prefix length how can that be > configured?. > > There are many such instances IMHO; having references in the YANG module > to sections of RFC8029 would make this more apparent. > > Tom Petch > > ----- Original Message ----- > From: "Loa Andersson" > To: > Cc: ; > > Sent: Wednesday, February 20, 2019 5:35 AM > >> 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 >> >> _______________________________________________ >> 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 Feb 20 19:57:58 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 0258512D4F2; Wed, 20 Feb 2019 19:57:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Carlos Pignataro To: Cc: mpls@ietf.org, draft-ietf-mpls-sfc-encapsulation.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155072147698.20210.381511429964485828@ietfa.amsl.com> Date: Wed, 20 Feb 2019 19:57:57 -0800 Archived-At: Subject: [mpls] Opsdir last call review of draft-ietf-mpls-sfc-encapsulation-02 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, 21 Feb 2019 03:57:57 -0000 Reviewer: Carlos Pignataro Review result: Has Issues Reviewer: Carlos Pignataro Review Result: Has Issues I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document is highly readable, includes very clear textual descriptions, and is very well organized. Easy to read in its simplicity. However, it would benefit from a more explicit connection to the transport encap mechanics from RFC 8300 (e.g., S4, S6.1). Specifically, I'd recommend adding a Figure or an SFF NSH Mapping Table example, to depict and/or exemplify the SFF function. >From an Operational standpoint, the document seems largely appropriate in terms of dataplane considerations. Some key considerations are explicitly out of scope: The method used by the downstream receiving node to advertise SFF Labels to the upstream sending node is out of scope of this document. This really seems to mean that, with the simple definition in this Informational document, interoperable implementations cannot yet exist. If there is no mechanism to advertise the SFF Label or to manage the semantics of this particular label, how will it know? Static configuration, which is not covered anyway, is not in my humble opinion a manageable scalable approach. Title: MPLS Encapsulation For The SFC NSH RFC 8300 makes an explicit distinction between the terms 'encapsulation' and 'transport encapsulation' (see e.g., Figure 1, Section 1.5 5., and Section 4 of RFC 8300). It seems to me that this is the "MPLS Transport Encapsulation for the SFC NSH" 2. MPLS Encapsulation Using an SFF Label Similarly, "2. MPLS Transport Encapsulation Using an SFF Label" The encapsulation is a standard MPLS label stack [RFC3032] with an SFF Label at the bottom of the stack, followed by a NSH as defined by [RFC8300] and the NSH payload. Insteadf of "NSH payload" I think "orignal packet" is meant. Also, this encapsulation is Underdefined: What is the value of TTL? TC? Much like a pseudowire label, an SFF Label is allocated by the downstream receiver of the NSH from its per-platform label space. A PW Label is more restrictive. RFC 8077 says it MUST be allocated as per-platform: egress LSR only. Note that the PW label must always be at the bottom of the packet's label stack, and labels MUST be allocated from the per-platform label space. Is this the case for the SFF Label as well? If so, what is the implication of the MUST? If not, why is it different than other equivalent similar labels? 2. Push the SFF Label to identify the desired SFF in the receiving MPLS node. TTL value? 1? 2? 255 for GTSM? GTSM RFC 5082 could be used here. 4. Operations, Administration, and Maintenance (OAM) Considerations OAM at the SFC Layer is handled by SFC-defined mechanisms [RFC8300]. However, OAM may be required at the MPLS transport layer. If so, then standard MPLS-layer OAM mechanisms such as the Generic Associated Channel [RFC5586] label may be used. RFC 5586 is _not_ an OAM mechanism. It is an associated channel creation mechanism, over which OAM could be carried. Thus, what traditional MPLS OAM can be carried here? Things like RFC 4379 / RFC 8029 would need the definition of an SFF Label FEC (which does not exist). Which other one? IP/ICMP seems of very limited value. 6. Security Considerations Have you considered the use of GTSM? 8. References [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . SHould RFC 7665 be Normative? It defines the "SFF" which is quite central to understanding this document. Other Nits and Editorials: SFF Labels are similar to other service labels at the bottom of an MPLS label stack that denote the contents of the MPLS payload being other than IP, such as a layer 2 pseudowire, an IP packet that is routed in a VPN context with a private address, or an Ethernet virtual private wire service. This says "being other than IP, such as IP", which seems to be self-contradictory :-) Best, Carlos Pignataro. From nobody Thu Feb 21 04:17: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 A365B130F9D; Thu, 21 Feb 2019 04:17:25 -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 qfuUVBluUo6z; Thu, 21 Feb 2019 04:17:23 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30092.outbound.protection.outlook.com [40.107.3.92]) (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 A9E20130F97; Thu, 21 Feb 2019 04:17:22 -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=VdY9YWRCepiYimTWJgsbVikWRT9Tqq3V+5sc8ghpNCs=; b=dESRYleF19yej0FwDiWrkicxeoL9gyu4Ethyh2SYDGoTj7O5XF4VgfTWFflFexh1qT4GVN7c00td4Hu13ZtM5IhVmaTBp5HKaxhiOPtJQ/VNqWNBXeoJXkEPmuyHtIy2CXkgXxyLM548YP6w/Azycy7AMCTykPcKrYP/hEKuFiA= Received: from VI1PR07MB4768.eurprd07.prod.outlook.com (20.177.57.155) by VI1PR07MB4910.eurprd07.prod.outlook.com (20.177.201.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.8; Thu, 21 Feb 2019 12:17:20 +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.1643.014; Thu, 21 Feb 2019 12:17:20 +0000 From: tom petch To: "mpls@ietf.org" , Loa Andersson CC: "mpls-chairs@ietf.org" , "draft-zheng-mpls-lsp-ping-yang-cfg@ietf.org" Thread-Topic: [mpls] Working Group Adoption Poll on draft-zheng-mpls-lsp-ping-yang-cfg Thread-Index: AQHUyQ+ywD+0BDpFC0yeZz/8w8buHA== Date: Thu, 21 Feb 2019 12:17:20 +0000 Message-ID: <030301d4c9df$2602e180$4001a8c0@gateway.2wire.net> References: <98db7e71-6152-1335-8ca0-b5ae67b8a4b6@pi.nu> <020301d4c90f$748bd300$4001a8c0@gateway.2wire.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0243.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8a::15) 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: 03ddeceb-df91-46cf-1995-08d697f686a9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB4910; x-ms-traffictypediagnostic: VI1PR07MB4910: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 09555FB1AD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(396003)(346002)(366004)(136003)(199004)(189003)(51444003)(13464003)(25786009)(44716002)(62236002)(4720700003)(81686011)(76176011)(4326008)(81816011)(256004)(33896004)(966005)(53546011)(44736005)(14496001)(229853002)(106356001)(386003)(6506007)(6436002)(97736004)(316002)(6116002)(81156014)(476003)(54906003)(110136005)(2906002)(8936002)(8676002)(66066001)(6486002)(102836004)(84392002)(5660300002)(52116002)(81166006)(486006)(50226002)(3846002)(6246003)(61296003)(99286004)(26005)(2501003)(446003)(14454004)(478600001)(9686003)(6512007)(86362001)(53936002)(68736007)(7736002)(86152003)(105586002)(71200400001)(71190400001)(6306002)(186003)(305945005)(1556002)(440344003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4910; 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) x-microsoft-exchange-diagnostics: =?utf-8?B?MTtWSTFQUjA3TUI0OTEwOzIzOjVMUW10aXM0aWdtZWZlOHF3U0JUaVp1aHJa?= =?utf-8?B?YW4rUFZUcCtyTE5iTEx3UUFMWXYzSU1QVGpUdW1rRmMvVTNFYlBmSVZMck9h?= =?utf-8?B?eWNwSjZUelB3YXpBb3lkTE1zM3hiYTBJdEVJZHZuYW9SS08zR3dDY1lSdXVH?= =?utf-8?B?VHlMN2g3a2tZRDF6SkZ4dVlPcFdjak1zb3ZqSzYyMUNVUlByekdFbGN1SlVJ?= =?utf-8?B?K2pJL3lOMENlelNwOFNqSk9QSHlXdUk4RGpHNTdmanhlTU1QV1NqSnFzVnVB?= =?utf-8?B?R0taZDA5emVUTjE5dTJ4TmJwOHBOd0JoTzNFV2F0MElVb2M5VHJnMmdnNkhD?= =?utf-8?B?N01EcDNTTWNDeThwcXR2ZDJwTzRsRFNjemRkdEN0dE1IUU56NWhTQWNvcnpE?= =?utf-8?B?dG44dEsyd2NlYTJObDV2VnljUTFNWUVQOXVjaTNweE1RRU56WEdVNDlURUl5?= =?utf-8?B?a0tpZmg1V2s4L05XRGNIRldTWW9pbXVWbGx0Z3QxRVhZSUpUczVUNHBoZ3pY?= =?utf-8?B?anhycXpVTElKSHYxWDM1UGpERFdjbXRJZ0xVTEI4WmJITnY0REx2bGVEMTIx?= =?utf-8?B?bjRBVE0yQ2RBTXBtYURFYkRRWHljV2ROYjM3WVZDRTc4M0RCamJuaGRjR0Fu?= =?utf-8?B?TCtZa0hSUG1JTGxISWZrRGU0bnllMkpxbmk0MU52TERoSDlkTjc2UGpnWGVu?= =?utf-8?B?UnQyeDcyREp5Wlhha3A5czJROUIvbEdZTnROVURzM3ROWjBBVGQ0QnI4a24r?= =?utf-8?B?bndMQjBBZWxUdytRS1Bram1MMnFsb2pRblQrYWFESkVaN2tManU0QmQwNXN0?= =?utf-8?B?VVQwL1NDb0NuS253dnVXMUhmRkhrUDIzaHphREU4d2RwYWh0N2N2WXJoUWxa?= =?utf-8?B?UUw5UVl3SFVWdEE3Nm0xYTBKa0QvWkk1RXpNZFNvVGUwWVpTSHh1RWpocDlx?= =?utf-8?B?eG0waFVBaDU4N2toWXFPejljbWJDRGp5ZVNOSGI2RkpKSnJPTkorYXhHelpJ?= =?utf-8?B?b1dKUy9RK0tMbHo0MkJ5K0NZV1RrR21PbWsvRnhoM0Y3QlB4VThCSHBabzUy?= =?utf-8?B?eXZ0Z1lHVVViZS9sd2taREx0MnRDeU1ORmpRNHB2LzRqOVcvYktjSW1HWlpT?= =?utf-8?B?WG9zN2JFajhaa0lLcnhsTDkvd1Y0Vmd4QVhaZUpxeFpkTms1bTNMOW1Yek9U?= =?utf-8?B?MmplRCtHdnlQdTFpYzRhYVV2SzNFZUJ6RUZNWEJaQ1IxSzdnSHpsWnVLekVS?= =?utf-8?B?a0ZTaXU3Zk5OWVV1K0ErK0UvMFpWM2xjTTVEUmVYUjN2aTVkR0VEelg0VWpa?= =?utf-8?B?RElCN2hhK1Nsdzh3VDB6aHMyZmIzVHV4Sk8rWjBqbHRJZk9FMlh2dnZHeFlr?= =?utf-8?B?aDhiQXgxNWsxblhiK0VnYmNyU3JRWTF6OTJDZDZWODJ1NnQ4MkJXQjRUVkJD?= =?utf-8?B?aksveWNXcG9Bd1RxYlBUTmRBekI4T2pLZFJFVUl5eldQN2g5ZVhZQyt0Sjk5?= =?utf-8?B?YzB6SmRUcHlNQ3JuZk13WGFsWWdzYk1yWkZhdnJabUdYQy9KOUw0dmZYaUhP?= =?utf-8?B?MDZBdktjM3Q4c1U0WkF0ZHFaeWxqM2xzTWU1cEY0Tnh6VW1lSHpyMEFEU2xC?= =?utf-8?B?K3JhazA1eTRmdXhKcDRTbHdDNjUxR2IrcnZUeGpSRUc3N09vNDlQd21ycExY?= =?utf-8?B?cGNpa3NiK1RtYXBQWjhBTE50Q2hneFFvWnhwR3I5dkY1RW5LUTJHeFp0SUUv?= =?utf-8?B?QnJvSnhJOEFiaFo3RCt0NVFYa0JBL0hORkpML3dkZ3plSkNrbHk0b3hBdlZn?= =?utf-8?B?UVR4Qjl3b3E0c0NoNjRoalpiVVBBVkNITVBFM09STkhzSnJwenRzaXZHZVEv?= =?utf-8?B?cnFkb3ZDQkNxeXM1bGhMcndJWS9DRDU4SVBEUHFYb3diajVYcnVQVUpzSVdL?= =?utf-8?B?UjFKZzB1SytWblc0QkxhL0ZHWDZoS0duZEozelZnSGN3MTFpVStNSnNMMTF1?= =?utf-8?B?eHVFMjBESTJoQ2tzQUtuS004UGVDZVNuNk9jOVpjZUdNN3JyOVUvMFNCZkZ5?= =?utf-8?B?SzVDZTFpSGVwOGZYcW1Jdk1FUURqT01OWVVJL3dGRHN0R0x2MDBhejZuVkpY?= =?utf-8?B?dkZGOENwTHYwZXZXTGM5MHRtbTFCM240UU16N2ZBUEthdFR2WG5HaG05ekxW?= =?utf-8?Q?f6vqCm0Dq5Q6Uoa1zAIs+8mjmQ5RoIzSV8HiSDCzq4=3D?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: vMDr+bjq4zeDoaWfauWRJfXh9BGwk23pMKeidzgwz3sjdeecQFTK7kXEMnLJk5cu3lnekvMEvsJhhWAKv6Krh8RJG2ocDt/iMuf3BbQ87kGn6Bl1QTUntOccaIQzSdSSAa3ljhTOyaYMagiyQc2CIMXXZj4yZcyH5qJYv8XJ41LnS87Uyuo2dDAoqh2wy26SYrpe/OirTZRC1HS3+8afDxuJsVZrhWPMAAXq7ZwIRXgxiWsPas3xNtv+srO9UL/p15wA7xxcptdFhegPZeaO4lFkpVIXIETNbs0WVD8TdXDI0+kAkICUFqkwWtUYxbhSPxJmQXOge5R6myTpDNwb0Khs92/wdo+Rucu4kOdS0gmbseKEhRle6jBw9onNZBpevH/QSfIZNJzJ/NBBIEIqfKmaXxklnSqylMmj4Gzbr5U= Content-Type: text/plain; charset="utf-8" Content-ID: <3641681989280B40AF5F0C500CEA7BC3@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 03ddeceb-df91-46cf-1995-08d697f686a9 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2019 12:17:19.2178 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4910 Archived-At: Subject: Re: [mpls] 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: Thu, 21 Feb 2019 12:17:26 -0000 LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIkxvYSBBbmRlcnNzb24iIDxsb2FA cGkubnU+DQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMjEsIDIwMTkgMTI6NDAgQU0NCg0KPiBU b20sDQo+DQo+IE11Y2ggYXMgSSBhcHByZWNpYXRlIHlvdXIgY29tbWVudHMsIGFuZCBJIGFncmVl IHdpdGggdGhlIHRlY2huaWNhbA0KPiBhc3BlY3RzIG9mIHRoZW0uIFRoZSByZWZlcmVuY2VzIGFu ZCB0aGUgaW5jb25zaXN0ZW5jaWVzIHNob3VsZCBiZQ0KPiBmaXhlZC4gSG93ZXZlciwgSSBoYXZl IGEgbGl0dGxlIGJpdCBkaWZmZXJlbnQgdmlldyBvZiB3aGF0IHNob3VsZA0KPiBiZSBkb25lLg0K Pg0KPiBJdCBpcyBjbGVhciB0aGF0IHdlIG5lZWQgYSBZQU5HIG1vZHVsZSBmb3IgTFNQIFBpbmcu DQo+DQo+IEl0IGlzIHVubGlrZWx5IHRoYXQgdGhlcmUgd2lsbCBiZSBhbm90aGVyIGRvY3VtZW50 Lg0KPg0KPiBUaGlzIGRvY3VtZW50IGhhcyBiZWVuIHZlcnkgc2xvdyBkZXZlbG9waW5nLCB0aGUg Zmlyc3QgdmVyc2lvbiBpcw0KPiBmcm9tIDIwMTUuDQo+DQo+IEkgdGhpbmsgdGhhdCB3ZSBzaG91 bGQgc2F5IHRoYXQgdGhpcyBpcyAiYSBnb29kIGVub3VnaCBzdGFydGluZw0KPiBwb2ludCIsIGFu ZCB0aGF0IHRoZXJlIGFyZSB0aGluZyB0aGF0IG5lZWQgdG8gYmUgZml4ZWQgYmVmb3JlDQo+IHB1 YmxpY2F0aW9uLCBlLmcgdGhlIFJQQ3MgbWVudGlvbmVkIGJ5IEFjZWUsIGFuZCB0aGUgbGFjayBv Zg0KcmVmZXJlbmNlcw0KPiBhbmQgdGhlIHBvdGVudGlhbCBpbmNvbnNpc3RlbmNpZXMgcG9pbnRl ZCBvdXQgYnkgeW91Lg0KDQpXaGljaCBpcyB3aGVyZSB3ZSBwYXJ0IGNvbXBhbnkuICBBZnRlciB0 aHJlZSB5ZWFycywgYW5kIDEwIHJldmlzaW9ucywgSQ0KbG9vayBmb3IgbW9yZS4gIEluIHBhcnRp Y3VsYXIsIEkgc2VlIHRvbyBtdWNoIGRpc2NyZXBhbmN5IGJldHdlZW4gdGhlDQpZQU5HIG1vZHVs ZSBhbmQgUkZDODAyOSwgYWx0aG91Z2gsIGFzIEkgc2FpZCwgdGhlIGxhY2sgb2YgcmVmZXJlbmNl cyBhbmQNCnRoZSBjaGFuZ2Ugb2YgaWRlbnRpZmllcnMgZm9yIEZFQyBjbGFzc2VzIGFuZCB0aGUg Y29uZmxhdGlvbiBvZiBGRUMNCmNsYXNzZXMsICBtYWtlcyBjb21wYXJpc29uIGRpZmZpY3VsdCBm b3IgbWUuDQoNClJGQzgwMjkgbGlzdCAxNiBGRUMsIHRoaXMgSS1EIHNpeDsgV2h5IHRoZSBlbGlz aW9uPyBXaGF0IGlzIHRoZSBtYXBwaW5nPw0KDQpUaGlzIEktRCB1c2VzIGVudW1lcmF0aW9uIGFu ZCBwcm92aWRlcyBhIG51bWVyaWMgdmFsdWUuICBUaGUgbnVtZXJpYw0KdmFsdWUgaXMgbm90IHBy ZXNlbnQgb24gdGhlIHdpcmUgYW5kIHNvIHVzdWFsbHkgaXMgbm90IHNwZWNpZmllZCBpbiBhDQpZ QU5HIG1vZHVsZSwgZXhjZXB0IGFzIGRvY3VtZW50YXRpb24gLSBoZXJlIHRoZSB2YWx1ZXMgc3Bl Y2lmaWVkIGJlYXIgbm8NCnJlbGF0aW9uc2hpcCB0byB0aGUgUkZDIGFuZCBzbyBjb25mdXNlIG1l ICAoQ29tbW9uIHByYWN0aWNlIG5vdyBpcyB0bw0KdXNlIFlBTkcgaWRlbnRpdHkgcmF0aGVyIHRo YW4gZW51bWVyYXRpb24gYWx0aG91Z2ggbmVpdGhlciBhcmUgaWRlYWwpLg0KDQpUYWtpbmcgYSBn dWVzcyBhdCB0aGUgbWFwcGluZywgY29tcGFyZWQgdG8gUkZDODAyOSwNCg0KICAgICAgICAgIGNh c2UgaXAtcHJlZml4IHsNCmxhY2tzIHByZWZpeCBsZW5ndGgNCg0KICAgICAgICAgIGNhc2UgYmdw IHsNCiBsYWNrcyBwcmVmaXggbGVuZ3RoDQoNCiAgICAgICAgICBjYXNlIHJzdnAgew0KSSBzdHJ1 Z2dsZSB3aXRoIC0gdGhlIEktRCBvbmx5IGRlZmluZXMgYSBzdHJpbmcsIHRoZSBSRkMNCiAgICBJ UHY0IHR1bm5lbCBlbmQgcG9pbnQgYWRkcmVzcw0KICAgIFR1bm5lbCBJRA0KICAgIEV4dGVuZGVk IFR1bm5lbCBJRA0KICAgIElQdjQgdHVubmVsIHNlbmRlciBhZGRyZXNzDQogICAgTFNQIElEDQoN CiAgICAgICAgICBjYXNlIHZwbiB7DQpkZWZpbmVzICBsZWFmIHZyZi1uYW1lIHsgdHlwZSB1aW50 MzI7ICAiTGF5ZXIzIFZQTiBOYW1lIjsNCiAgICAgICAgICAgIGxlYWYgdnBuLWlwLWFkZHJlc3Mg dHlwZSBpbmV0OmlwLWFkZHJlc3M7ICJMYXllcjMgVlBOIElQdjQNClByZWZpeCI7DQp3aGljaCBs YWNrcyBwcmVmaXggbGVuZ3RoIGFuZCBSb3V0ZSBEaXN0aW5ndWlzaGVyICg4IG9jdGV0cykgIGNv bXBhcmVkDQp0byB0aGUgUkZDDQoNCiAgICAgICAgICBjYXNlIHB3DQpoYXMNCiAgIGxlYWYgdmNp ZCB7ICB0eXBlIHVpbnQzMjsNCndoaWxlIHRoZSBSRkMgaGFzDQogICAgU2VuZGVyJ3MgUEUgSVB2 NCBBZGRyZXNzDQogICAgUmVtb3RlIFBFIElQdjQgQWRkcmVzcw0KICAgIFBXIElEDQogICAgUFcg VHlwZQ0KDQogICAgICAgICAgY2FzZSB2cGxzIHsNCmFwcGVhcnMgdG8gYmUgYW4gKHVuZm9ydHVu YXRlKSByZW5hbWluZyBvZiBGRUMxMjkgYW5kIHNwZWNpZmllcw0KICAgICAgICAgbGVhZiB2c2kt bmFtZSB7IHR5cGUgc3RyaW5nOyBkZXNjcmlwdGlvbiAiVlBMUyBWU0kiOw0Kd2hlcmUgdGhlIFJG QyBoYXMgQUdJIEFJSSBldGMNCg0KU28gd2UgYWdyZWUgdGhhdCB3ZSBuZWVkIHRoZSBhYmlsaXR5 IHRvIGNvbmZpZ3VyZSB0aGUgZnVuY3Rpb25zIG9mDQpSRkM4MDI5LCBidXQgdGhpcyBJLUQgc2Vl bXMgc29tZXdoYXQgcmVtb3ZlZCBmcm9tIHRoYXQsIHRvbyBmYXIgdG8NCmJlY29tZSBhIFdHIEkt RCBJTUhPLg0KDQpUb20gUGV0Y2gNCg0KPg0KPiBUbyBwdXQgdGhlIHdvcmtpbmcgZ3JvdXAgaW4g Y29udHJvbCBvZiB0aGUgZHJhZnQgYW5kIG1ha2Ugc3VyZSB0aGF0IGl0DQo+IHByb2dyZXNzIHdl bGwgSSB3YW50IHRvIGFkYW9wdCBpdCBhcyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuIFRoZQ0K PiBvbmx5IHRoaW5nIEkgYmVsaWV2ZSBpcyBuZWNlc3NhcnkgaXMgdGhhdCB0aGUgYXV0aG9ycyBh Y2tub3dsZWRnZSB0aGF0DQo+IHRoZSBpc3N1ZXMgcG9pbnRlZCBvdXQgbmVlZHMgdG8gYmUgYWRk cmVzc2VkLg0KPg0KPiAvTG9hDQo+DQo+IE9uIDIwMTktMDItMjAgMTk6MzAsIHRvbSBwZXRjaCB3 cm90ZToNCj4gPiBOb3Qgc3VwcG9ydA0KPiA+DQo+ID4gVGhlIFlBTkcgbW9kdWxlIGlzIHZlcnkg d2VhayBvbiByZWZlcmVuY2VzIHdoaWNoIG1ha2VzIGl0IGhhcmQgZm9yDQptZSB0bw0KPiA+IGJl IHN1cmUgYnV0IHRoZXJlIHNlZW1zIHRvIGJlIGEgbWlzbWF0Y2ggYmV0d2VlbiBlLmcuIEZFQyBj bGFzc2VzIGluDQo+ID4gUkZDODAyOSBhbmQgdGhlIFlBTkcgbW9kdWxlLg0KPiA+DQo+ID4gVGh1 cyBSRkM4MDkgaGFzDQo+ID4gICAgICAgICAgICAgMSAgICAgICAgICA1ICAgICAgICAgTERQIElQ djQgcHJlZml4DQo+ID4gd2l0aCBhIG9uZSBieXRlIHByZWZpeCBsZW5ndGggYW5kIGZvdXIgYnl0 ZSBwcmVmaXguDQo+ID4NCj4gPiBUaGUgWUFORyBtb2R1bGUgaGFzDQo+ID4gICAgICAgIGVudW0g aXAtcHJlZml4IHsNCj4gPiAgICAgICAgICB2YWx1ZSAiMCI7DQo+ID4gICAgICAgICAgZGVzY3Jp cHRpb24gIklQdjQvSVB2NiBwcmVmaXgiOw0KPiA+IGFuZA0KPiA+ICAgICAgICAgIGNob2ljZSB0 YXJnZXQtZmVjIHsNCj4gPiAgICAgICAgICAgIGNhc2UgaXAtcHJlZml4IHsNCj4gPiAgICAgICAg ICAgICAgbGVhZiBpcC1hZGRyZXNzIHsNCj4gPiAgICAgICAgICAgICAgICB0eXBlIGluZXQ6aXAt YWRkcmVzczsNCj4gPiAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiSVB2NC9JUHY2IFByZWZp eCI7DQo+ID4gd2hlcmUgaXAtYWRkcmVzcyBoYXMgbm8gY29uY2VwdCBvZiBwcmVmaXggbGVuZ3Ro IGhvdyBjYW4gdGhhdCBiZQ0KPiA+IGNvbmZpZ3VyZWQ/Lg0KPiA+DQo+ID4gVGhlcmUgYXJlIG1h bnkgc3VjaCBpbnN0YW5jZXMgSU1ITzsgaGF2aW5nIHJlZmVyZW5jZXMgaW4gdGhlIFlBTkcNCm1v ZHVsZQ0KPiA+IHRvIHNlY3Rpb25zIG9mIFJGQzgwMjkgd291bGQgbWFrZSB0aGlzIG1vcmUgYXBw YXJlbnQuDQo+ID4NCj4gPiBUb20gUGV0Y2gNCj4gPg0KPiA+IC0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0NCj4gPiBGcm9tOiAiTG9hIEFuZGVyc3NvbiIgPGxvYUBwaS5udT4NCj4gPiBUbzog PG1wbHNAaWV0Zi5vcmc+DQo+ID4gQ2M6IDxtcGxzLWNoYWlyc0BpZXRmLm9yZz47DQo+ID4gPGRy YWZ0LXpoZW5nLW1wbHMtbHNwLXBpbmcteWFuZy1jZmdAaWV0Zi5vcmc+DQo+ID4gU2VudDogV2Vk bmVzZGF5LCBGZWJydWFyeSAyMCwgMjAxOSA1OjM1IEFNDQo+ID4NCj4gPj4gV29ya2luZyBHcm91 cCwNCj4gPj4NCj4gPj4gVGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHBvbGwgb24gYWRvcHRp bmcNCj4gPj4gZHJhZnQtemhlbmctbXBscy1sc3AtcGluZy15YW5nLWNmZy0xMA0KPiA+PiBhcyBh IE1QTFMgd29ya2luZyBncm91cCBkb2N1bWVudC4NCj4gPj4NCj4gPj4gUGxlYXNlIHNlbmQgeW91 ciBjb21tZW50cyAoc3VwcG9ydC9ub3Qgc3VwcG9ydCkgdG8gdGhlIG1wbHMgd29ya2luZw0KPiA+ PiBncm91cCBtYWlsaW5nIGxpc3QgKG1wbHNAaWV0Zi5vcmcpLiBQbGVhc2UgZ2l2ZSBhIHRlY2hu aWNhbA0KPiA+PiBtb3RpdmF0aW9uIGZvciB5b3VyIHN1cHBvcnQvbm90IHN1cHBvcnQsIGVzcGVj aWFsbHkgaWYgeW91IHRoaW5rDQp0aGF0DQo+ID4+IHRoZSBkb2N1bWVudCBzaG91bGQgbm90IGJl IGFkb3B0ZWQgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KPiA+Pg0KPiA+PiBXZSBoYXZl IGRvbmUgYW4gSVBSIHBvbGwgZm9yIHRoaXMgZG9jdW1lbnQuIEFsbCB0aGUgY28tYXV0aG9ycyBo YXZlDQo+ID4+IHJlc3BvbmRlZCB0byB0aGUgSVBSIHBvbGwgdGhhdCB0aGV5IGFyZSB1bmF3YXJl IG9mIGFueSBJUFJzIHRoYXQNCj4gPiByZWxhdGVzDQo+ID4+IHRvIHRoaXMgZHJhZnQuDQo+ID4+ DQo+ID4+IEFsbCwgdGhlIGNvbnRyaWJ1dG9ycyAod2l0aCBvbmUgZXhjZXB0aW9uKSBoYXZlIHJl c3BvbmRlZCB0byB0aGUNCklQUg0KPiA+PiBwb2xsIHRoYXQgdGhleSBhcmUgdW5hd2FyZSBvZiBh bnkgSVBScyB0aGF0IHJlbGF0ZXMgdG8gdGhpcyBkcmFmdC4NCj4gPj4NCj4gPj4gVGhlIGNvbnRy aWJ1dG9yIHRoYXQgaGFzIG5vdCByZXNwb25kZWQgaGFzIGxlZnQgaGlzIGZvcm1lcg0KZW1wbG95 bWVudA0KPiA+PiBhbmQgaXMgbm8gbG9uZ2VyIG9uIHRoZSBNUExTIHdnIG1haWxpbmcgbGlzdC4g VGhlIHdnIGNoYWlycyBoYXMNCj4gPiBkZWNpZGVkDQo+ID4+IHRvIGdvIGFoZWFkIHdpdGggdGhl IHdnYXAuIElmIHRoZXJlIGlzIGFueSBjb25jZXJucyBhYm91dCB0aGlzLA0KcGxlYXNlDQo+ID4+ IHNwZWFrIHVwIGluIHRoZSBtYWlsaW5nIGxpc3QuDQo+ID4+DQo+ID4+IFRoZXJlIGFyZSBubyBJ UFIgZGlzY2xvc3VyZXMgYWdhaW5zdCB0aGlzIGRvY3VtZW50Lg0KPiA+Pg0KPiA+PiBUaGUgd29y a2luZyBncm91cCBhZG9wdGlvbiBwb2xsIGVuZHMgTWFyY2ggNiwgMjAxOS4NCj4gPj4NCj4gPj4g L0xvYQ0KPiA+Pg0KPiA+PiBtcGxzIHdnIGNvLWNoYWlyDQo+ID4+IC0tDQo+ID4+DQo+ID4+DQo+ ID4+IExvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQHBpLm51 DQo+ID4+IFNlbmlvciBNUExTIEV4cGVydA0KPiA+PiBCcm9uemUgRHJhZ29uIENvbnN1bHRpbmcg ICAgICAgICAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCj4gPj4NCj4gPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gbXBscyBtYWlsaW5n IGxpc3QNCj4gPj4gbXBsc0BpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMNCj4gPg0KPg0KPiAtLQ0KPg0KPg0KPiBMb2EgQW5kZXJzc29uICAg ICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBwaS5udQ0KPiBTZW5pb3IgTVBMUyBFeHBl cnQNCj4gQnJvbnplIERyYWdvbiBDb25zdWx0aW5nICAgICAgICAgICAgIHBob25lOiArNDYgNzM5 IDgxIDIxIDY0DQoNCg== From nobody Thu Feb 21 09:02: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 AC961130DEF; Thu, 21 Feb 2019 09:01:59 -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 BJPcNo435UV7; Thu, 21 Feb 2019 09:01:56 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B5D1200D7; Thu, 21 Feb 2019 09:01:55 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id q128so24571300ljb.11; Thu, 21 Feb 2019 09:01:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gHm8w6iZOEq4wzcbQGgpo+NHM+OljxlpHqsY3+Jy/iY=; b=WoIi1Seaq4NeAr6u77FWrEym6mdcJPUEWW9+X7xsBmb2fDdQgllbrX0z4GlsIskoJ5 noLHGv/ZFdblJ5vKPhO5X2UHxQ0F80hXe8D+G8ZFraVH9yV+jxngpg2OfvPVLSDQYSZc 7N2KALXn368lDZxlECeNdUOq/G1zxEZlHsNdBTr4Ogxmb62V09+W2INz+jWDELoC3hPC kHUuIzWS4PyZOlQNQmEQ9Ar8dDY+LrOMp5mkhtSHJDDH58YRi2VX/+s5sfpRvPHMP6YJ qKnSGDxzgQD/YvmC16NfUP+GakQL2gLiDwPlHF8fUJZ8qYzTVV0Ug3rrUVAOHg/OfwSV GCAw== 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=gHm8w6iZOEq4wzcbQGgpo+NHM+OljxlpHqsY3+Jy/iY=; b=Olc/vApaygs4NvDhfUIam62YF6Fqx13NgrdYh+9KMLjwNZgmizwVYWBAXhia0dzXO0 XyBi0eoOB7NOj60MVRw2u1w4UXgIpgcfYRb1bzMso0qgOHz0MVnesuzvsMxAsg5T2yR3 yeA1c5RU4Xuls3klxTq6RUMi7a+dj5rVxdIUXGtSeVP3utS6ZyWKhyhL5oJZtznEWVhy GM/IKHNdv8e0b8khz1ajZIzeh8UcYUtYp0hfSp4E/SLOLvyoAxyOzrhXd9ZbQ33dE4nA k3ppra/a2Uwm+/iodztrN66odCE65a5B4AcPF2wjFu+q/PrCcAJ34NupP5IixqEL/T2I qAcA== X-Gm-Message-State: AHQUAubvVmGmBNTuKsjDykYluFNwitCSHYyq11hOFq9CfXPcZlkwW7+Q /6GTI/CLdeLOSrjVTmD08MGrqbGkU8QR4zYU7QI= X-Google-Smtp-Source: AHgI3IZEAiksJagQEjuVEl6RRHr6vnn/NLfYbZ42JBL/YDvb8NQoLtsbzJW+5HqrfT0o7QkVYB0eb871Rp52HWXMWNw= X-Received: by 2002:a2e:8446:: with SMTP id u6-v6mr24665903ljh.74.1550768513409; Thu, 21 Feb 2019 09:01:53 -0800 (PST) MIME-Version: 1.0 References: <98db7e71-6152-1335-8ca0-b5ae67b8a4b6@pi.nu> <020301d4c90f$748bd300$4001a8c0@gateway.2wire.net> <030301d4c9df$2602e180$4001a8c0@gateway.2wire.net> In-Reply-To: <030301d4c9df$2602e180$4001a8c0@gateway.2wire.net> From: Greg Mirsky Date: Thu, 21 Feb 2019 09:01:44 -0800 Message-ID: To: tom petch Cc: "mpls@ietf.org" , Loa Andersson , "mpls-chairs@ietf.org" , "draft-zheng-mpls-lsp-ping-yang-cfg@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005ee9e105826a6e0f" Archived-At: Subject: Re: [mpls] 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: Thu, 21 Feb 2019 17:02:00 -0000 --0000000000005ee9e105826a6e0f Content-Type: text/plain; charset="UTF-8" Hi Tom, much appreciate your comments, suggestions. The original source for the model was RFC 4379, not RFC 8029. I understand that a lot of work is ahead for us with the model, document. I hope that the WG will actively participate and contribute to complete the model in a reasonable time. Regards, Greg On Thu, Feb 21, 2019 at 4:17 AM tom petch wrote: > ----- Original Message ----- > From: "Loa Andersson" > Sent: Thursday, February 21, 2019 12:40 AM > > > Tom, > > > > Much as I appreciate your comments, and I agree with the technical > > aspects of them. The references and the inconsistencies should be > > fixed. However, I have a little bit different view of what should > > be done. > > > > It is clear that we need a YANG module for LSP Ping. > > > > It is unlikely that there will be another document. > > > > This document has been very slow developing, the first version is > > from 2015. > > > > I think that we should say that this is "a good enough starting > > point", and that there are thing that need to be fixed before > > publication, e.g the RPCs mentioned by Acee, and the lack of > references > > and the potential inconsistencies pointed out by you. > > Which is where we part company. After three years, and 10 revisions, I > look for more. In particular, I see too much discrepancy between the > YANG module and RFC8029, although, as I said, the lack of references and > the change of identifiers for FEC classes and the conflation of FEC > classes, makes comparison difficult for me. > > RFC8029 list 16 FEC, this I-D six; Why the elision? What is the mapping? > > This I-D uses enumeration and provides a numeric value. The numeric > value is not present on the wire and so usually is not specified in a > YANG module, except as documentation - here the values specified bear no > relationship to the RFC and so confuse me (Common practice now is to > use YANG identity rather than enumeration although neither are ideal). > > Taking a guess at the mapping, compared to RFC8029, > > case ip-prefix { > lacks prefix length > > case bgp { > lacks prefix length > > case rsvp { > I struggle with - the I-D only defines a string, the RFC > IPv4 tunnel end point address > Tunnel ID > Extended Tunnel ID > IPv4 tunnel sender address > LSP ID > > case vpn { > defines leaf vrf-name { type uint32; "Layer3 VPN Name"; > leaf vpn-ip-address type inet:ip-address; "Layer3 VPN IPv4 > Prefix"; > which lacks prefix length and Route Distinguisher (8 octets) compared > to the RFC > > case pw > has > leaf vcid { type uint32; > while the RFC has > Sender's PE IPv4 Address > Remote PE IPv4 Address > PW ID > PW Type > > case vpls { > appears to be an (unfortunate) renaming of FEC129 and specifies > leaf vsi-name { type string; description "VPLS VSI"; > where the RFC has AGI AII etc > > So we agree that we need the ability to configure the functions of > RFC8029, but this I-D seems somewhat removed from that, too far to > become a WG I-D IMHO. > > Tom Petch > > > > > To put the working group in control of the draft and make sure that it > > progress well I want to adaopt it as a working group document. The > > only thing I believe is necessary is that the authors acknowledge that > > the issues pointed out needs to be addressed. > > > > /Loa > > > > On 2019-02-20 19:30, tom petch wrote: > > > Not support > > > > > > The YANG module is very weak on references which makes it hard for > me to > > > be sure but there seems to be a mismatch between e.g. FEC classes in > > > RFC8029 and the YANG module. > > > > > > Thus RFC809 has > > > 1 5 LDP IPv4 prefix > > > with a one byte prefix length and four byte prefix. > > > > > > The YANG module has > > > enum ip-prefix { > > > value "0"; > > > description "IPv4/IPv6 prefix"; > > > and > > > choice target-fec { > > > case ip-prefix { > > > leaf ip-address { > > > type inet:ip-address; > > > description "IPv4/IPv6 Prefix"; > > > where ip-address has no concept of prefix length how can that be > > > configured?. > > > > > > There are many such instances IMHO; having references in the YANG > module > > > to sections of RFC8029 would make this more apparent. > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: "Loa Andersson" > > > To: > > > Cc: ; > > > > > > Sent: Wednesday, February 20, 2019 5:35 AM > > > > > >> 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 > > >> > > >> _______________________________________________ > > >> 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 > > --0000000000005ee9e105826a6e0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,
much appreciate your comments, suggestions.
The original source for the model was RFC 4379, not RFC 8029. I und= erstand that a lot of work is ahead for us with the model, document. I hope= that the WG will actively participate and contribute to complete the model= in a reasonable time.

Regards,
Greg

On Thu, Feb 21, 2019 at 4:17 AM tom petch <ietfc@btconnect.com> wrote:
----- Original Message -----
From: "Loa Andersson" <loa@pi.nu>
Sent: Thursday, February 21, 2019 12:40 AM

> Tom,
>
> Much as I appreciate your comments, and I agree with the technical
> aspects of them. The references and the inconsistencies should be
> fixed. However, I have a little bit different view of what should
> be done.
>
> It is clear that we need a YANG module for LSP Ping.
>
> It is unlikely that there will be another document.
>
> This document has been very slow developing, the first version is
> from 2015.
>
> I think that we should say that this is "a good enough starting > point", and that there are thing that need to be fixed before
> publication, e.g the RPCs mentioned by Acee, and the lack of
references
> and the potential inconsistencies pointed out by you.

Which is where we part company.=C2=A0 After three years, and 10 revisions, = I
look for more.=C2=A0 In particular, I see too much discrepancy between the<= br> YANG module and RFC8029, although, as I said, the lack of references and the change of identifiers for FEC classes and the conflation of FEC
classes,=C2=A0 makes comparison difficult for me.

RFC8029 list 16 FEC, this I-D six; Why the elision? What is the mapping?
This I-D uses enumeration and provides a numeric value.=C2=A0 The numeric value is not present on the wire and so usually is not specified in a
YANG module, except as documentation - here the values specified bear no relationship to the RFC and so confuse me=C2=A0 (Common practice now is to<= br> use YANG identity rather than enumeration although neither are ideal).

Taking a guess at the mapping, compared to RFC8029,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case ip-prefix {
lacks prefix length

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case bgp {
=C2=A0lacks prefix length

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case rsvp {
I struggle with - the I-D only defines a string, the RFC
=C2=A0 =C2=A0 IPv4 tunnel end point address
=C2=A0 =C2=A0 Tunnel ID
=C2=A0 =C2=A0 Extended Tunnel ID
=C2=A0 =C2=A0 IPv4 tunnel sender address
=C2=A0 =C2=A0 LSP ID

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case vpn {
defines=C2=A0 leaf vrf-name { type uint32;=C2=A0 "Layer3 VPN Name"= ;;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf vpn-ip-address type inet:ip-= address; "Layer3 VPN IPv4
Prefix";
which lacks prefix length and Route Distinguisher (8 octets)=C2=A0 compared=
to the RFC

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case pw
has
=C2=A0 =C2=A0leaf vcid {=C2=A0 type uint32;
while the RFC has
=C2=A0 =C2=A0 Sender's PE IPv4 Address
=C2=A0 =C2=A0 Remote PE IPv4 Address
=C2=A0 =C2=A0 PW ID
=C2=A0 =C2=A0 PW Type

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case vpls {
appears to be an (unfortunate) renaming of FEC129 and specifies
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf vsi-name { type string; description = "VPLS VSI";
where the RFC has AGI AII etc

So we agree that we need the ability to configure the functions of
RFC8029, but this I-D seems somewhat removed from that, too far to
become a WG I-D IMHO.

Tom Petch

>
> To put the working group in control of the draft and make sure that it=
> progress well I want to adaopt it as a working group document. The
> only thing I believe is necessary is that the authors acknowledge that=
> the issues pointed out needs to be addressed.
>
> /Loa
>
> On 2019-02-20 19:30, tom petch wrote:
> > Not support
> >
> > The YANG module is very weak on references which makes it hard fo= r
me to
> > be sure but there seems to be a mismatch between e.g. FEC classes= in
> > RFC8029 and the YANG module.
> >
> > Thus RFC809 has
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 5=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LDP IPv4 prefix
> > with a one byte prefix length and four byte prefix.
> >
> > The YANG module has
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 enum ip-prefix {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 value "0";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description "IPv4/IPv6 pre= fix";
> > and
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 choice target-fec {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case ip-prefix {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf ip-address {=
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type inet:= ip-address;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 descriptio= n "IPv4/IPv6 Prefix";
> > where ip-address has no concept of prefix length how can that be<= br> > > configured?.
> >
> > There are many such instances IMHO; having references in the YANG=
module
> > to sections of RFC8029 would make this more apparent.
> >
> > Tom Petch
> >
> > ----- Original Message -----
> > From: "Loa Andersson" <loa@pi.nu>
> > To: <mpls@i= etf.org>
> > Cc: <mpls-chairs@ietf.org>;
> > <draft-zheng-mpls-lsp-ping-yang-cfg@ietf.org>
> > Sent: Wednesday, February 20, 2019 5:35 AM
> >
> >> 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 w= orking
> >> group mailing list (mpls@ietf.org). Please give a technical
> >> motivation for your support/not support, especially if you th= ink
that
> >> the document should not be adopted as a working group documen= t.
> >>
> >> We have done an IPR poll for this document. All the co-author= s have
> >> responded to the IPR poll that they are unaware of any IPRs t= hat
> > 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 d= raft.
> >>
> >> The contributor that has not responded has left his former employment
> >> and is no longer on the MPLS wg mailing list. The wg chairs h= as
> > decided
> >> to go ahead with the wgap. If there is any concerns about thi= s,
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=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=A0phone: +46 739 81 21 64
> >>
> >> _______________________________________________
> >> mpls mailing list
> >> mpls@ietf.= org
> >> https://www.ietf.org/mailman/listinfo/mpls
> >
>
> --
>
>
> 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= =A0phone: +46 739 81 21 64

--0000000000005ee9e105826a6e0f-- From nobody Thu Feb 21 10:06:48 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 37AA713108C; Thu, 21 Feb 2019 10:06:39 -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 Q0jiG1PUf4hm; Thu, 21 Feb 2019 10:06:36 -0800 (PST) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 37FD413108B; Thu, 21 Feb 2019 10:06:36 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id s1so6406931qte.5; Thu, 21 Feb 2019 10:06:36 -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=5DU4A0cvGiFJKJgChxt6BFxScRZRP68oR2x9avJDc8s=; b=g3oI8bSYnqbVepOEeQYYV3TKwSlZhxF8IEai1gx9y/As8GdKibiWAXGuq3s6ioV5JY tjETYqRVXurBP/A7kj8xIHUD+/4UI8bm/V47/TwrLD6ErrSKPbAghf9oYdkkVRw8NoEQ Ow6KUXffdsSe5VRFUrBlYw2fTvbrHfwkpuGB82SxQ9vZ8qdjgPVMscx3E0hZbP8c6JOu Nu12sZBIKs2uuyE+Xi3lr2XmlBL11Yurpo1hzldVogDJ8uwFzJ10+tRt3Nc+p34NsxpI 7ohoNnQgF3+zsAuo4gwouVpNITUyEdzhISlMzOC7a4Gre8uYAsrk4dt0eOjxbWve6MsU iCFQ== 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=5DU4A0cvGiFJKJgChxt6BFxScRZRP68oR2x9avJDc8s=; b=ayuxcEKWSVlAgxH1fOmyIOYDDgyrNdU3jYiGzpQ6xLPZAUAyXZ28+N4wDoNtMSPXct 8vOqEMX+sMoqdVUVq00JzyzoKVWvwcWOOb0Sh7mVP2zE23Y4u6ES9BSnmMuHmCfRh0x0 ei3bAV9ZcYCnuCS8zXajW7Q5GJy/k+B8k1l1cEQtiTaNm2K9aEHs/mhJTdEz+OWni4HD kqIBLeXXhp7oUu4y/0uO6+OdYt2EwhjwJZybtw89hNLELnCL5qxXaZJDUnQAfuZZKCOA tlDr4vu5/9u/h/gv1BrcWvQAQU2utNjVDAp+Sni216O68Y84gkUaEBKkIuexR9P/psbT gfoQ== X-Gm-Message-State: AHQUAuY5SjqVSYYP8Dp9a19RQI9XK/ET4tS+Ctdc5T5vSY6rFmqxyJy6 UBDx+Le004tFnfepZGy9FuYLu1bUMdHcNDTHSrolzep8 X-Google-Smtp-Source: AHgI3IZM/RpfgQ6z50h4yolpC/D1atzYCW/RjxNgKlhSXmiWzOvXNNkHzzpWPcQVuMneN7EtN9pOocozP4ozNGDR0BI= X-Received: by 2002:ac8:38ba:: with SMTP id f55mr32200094qtc.192.1550772395135; Thu, 21 Feb 2019 10:06:35 -0800 (PST) MIME-Version: 1.0 References: <155072147698.20210.381511429964485828@ietfa.amsl.com> In-Reply-To: <155072147698.20210.381511429964485828@ietfa.amsl.com> From: "Andrew G. Malis" Date: Thu, 21 Feb 2019 13:06:23 -0500 Message-ID: To: Carlos Pignataro Cc: ops-dir@ietf.org, mpls@ietf.org, draft-ietf-mpls-sfc-encapsulation.all@ietf.org, IETF Discussion , sfc@ietf.org Content-Type: multipart/alternative; boundary="000000000000bd572905826b55f9" Archived-At: Subject: Re: [mpls] Opsdir last call review of draft-ietf-mpls-sfc-encapsulation-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: Thu, 21 Feb 2019 18:06:39 -0000 --000000000000bd572905826b55f9 Content-Type: text/plain; charset="UTF-8" Carlos, Many thanks for your review! I'm also including the SFC WG on my reply. Comments inline. On Wed, Feb 20, 2019 at 10:58 PM Carlos Pignataro wrote: > Reviewer: Carlos Pignataro > Review result: Has Issues > > Reviewer: Carlos Pignataro > Review Result: Has Issues > > I have reviewed this document as part of the Operational directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These > comments were written with the intent of improving the operational aspects > of > the IETF drafts. Comments that are not addressed in last call may be > included > in AD reviews during the IESG review. Document editors and WG chairs > should > treat these comments just like any other last call comments. > > This document is highly readable, includes very clear textual > descriptions, and > is very well organized. Easy to read in its simplicity. However, it would > benefit from a more explicit connection to the transport encap mechanics > from > RFC 8300 (e.g., S4, S6.1). Specifically, I'd recommend adding a Figure or > an > SFF NSH Mapping Table example, to depict and/or exemplify the SFF function. > I'm trying to envision what would make a good figure here. We could add an additional line to Table 1 of RFC 8300 and reference that table: +------+------+---------------------+-------------------------+ | SPI | SI | Next Hop(s) | Transport Encapsulation | +------+------+---------------------+-------------------------+ | 25 | 220 | Label 5467 | MPLS | +------+------+---------------------+-------------------------+ Is that what you had in mind? If not, I'm open to other suggestions. > > >From an Operational standpoint, the document seems largely appropriate in > terms > of dataplane considerations. Some key considerations are explicitly out of > scope: > The method used by the downstream receiving node to advertise SFF > Labels to the upstream sending node is out of scope of this document. > > This really seems to mean that, with the simple definition in this > Informational document, interoperable implementations cannot yet exist. If > there is no mechanism to advertise the SFF Label or to manage the > semantics of > this particular label, how will it know? Static configuration, which is not > covered anyway, is not in my humble opinion a manageable scalable approach. > Actually, while it is outside the scope of this document, it is within the scope of draft-ietf-bess-nsh-bgp-control-plane, and text is being added to the next revision of that draft to show how it can be used to signal the encapsulation defined here. This was worked out after this draft was forwarded to the IESG, but we can now add a reference to that draft seeing as we'll be doing a post-last-call update. > > Title: MPLS Encapsulation For The SFC NSH > > RFC 8300 makes an explicit distinction between the terms 'encapsulation' > and > 'transport encapsulation' (see e.g., Figure 1, Section 1.5 5., and Section > 4 of > RFC 8300). > > It seems to me that this is the "MPLS Transport Encapsulation for the SFC > NSH" > Thanks, we'll fix that. > > 2. MPLS Encapsulation Using an SFF Label > > Similarly, "2. MPLS Transport Encapsulation Using an SFF Label" > > The encapsulation is a standard MPLS label stack [RFC3032] with an > SFF Label at the bottom of the stack, followed by a NSH as defined by > [RFC8300] and the NSH payload. > > Insteadf of "NSH payload" I think "orignal packet" is meant. > RFC 8300 uses both "payload" and "original packet/frame", but the latter more than the former. So we can change "payload" to "original packet/frame". > > Also, this encapsulation is Underdefined: What is the value of TTL? TC? > I've been looking back at other related RFCs (such as PW and IP VPN label definitions) and they're also mostly silent on these values. I did find the following in RFC 6073: The setting of the TTL of the PW MPLS label is a matter of local policy on the originating PE, but SHOULD be set to 255. Regarding the TC, we can follow the example of RFC 6391: This document does not define a use for the Traffic Class (TC) field [RFC5462 ] (formerly known as the Experimental Use (EXP) bits [RFC3032 ]) in the flow label. Future documents may define a use for these bits; therefore, implementations conforming to this specification MUST set the TC field to zero at the ingress and MUST ignore them at the egress. Do you have any alternative suggestions? > > Much like a pseudowire label, an SFF Label is allocated by the > downstream receiver of the NSH from its per-platform label space. > > A PW Label is more restrictive. RFC 8077 says it MUST be allocated as > per-platform: > > egress LSR only. Note that the PW label must always be at the bottom > of the packet's label stack, and labels MUST be allocated from the > per-platform label space. > > Is this the case for the SFF Label as well? If so, what is the implication > of > the MUST? If not, why is it different than other equivalent similar labels? > We can change the text to: Much like a pseudowire label, an SFF Label MUST be allocated by the downstream receiver of the NSH from its per-platform label space, since the meaning of the label is identical independent of which incoming interface it is received [RFC3031]. > 2. Push the SFF Label to identify the desired SFF in the receiving > MPLS node. > > TTL value? 1? 2? 255 for GTSM? GTSM RFC 5082 could be used here. > As I noted above, 255, although I used RFC 6073 as my source rather than 5082. We'll add that here as well. > 4. Operations, Administration, and Maintenance (OAM) Considerations > > OAM at the SFC Layer is handled by SFC-defined mechanisms [RFC8300]. > However, OAM may be required at the MPLS transport layer. If so, > then standard MPLS-layer OAM mechanisms such as the Generic > Associated Channel [RFC5586] label may be used. > > RFC 5586 is _not_ an OAM mechanism. It is an associated channel creation > mechanism, over which OAM could be carried. > > Thus, what traditional MPLS OAM can be carried here? Things like RFC 4379 > / RFC > 8029 would need the definition of an SFF Label FEC (which does not exist). > Which other one? IP/ICMP seems of very limited value. > That's a good point about RFC 5586. The intention is that the MPLS OAM would be at the transport label layer above the SFF label, so most any MPLS-layer OAM would be applicable. So how about rewording to make that more clear: OAM at the SFC Layer is handled by SFC-defined mechanisms [RFC8300]. However, OAM may be required at the MPLS transport layer. If so, then standard MPLS-layer OAM mechanisms may be used at the transport label layer (the labels above the SFF label). > > 6. Security Considerations > > Have you considered the use of GTSM? > No, we hadn't. Can you point me to any examples of GTSM being used in an MPLS or PW context? > > 8. References > > [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function > Chaining (SFC) Architecture", RFC 7665, > DOI 10.17487/RFC7665, October 2015, > . > > SHould RFC 7665 be Normative? It defines the "SFF" which is quite central > to > understanding this document. > Good point. It was there because 7665 is an Informational RFC, but RFC 8067 does allow normative references to informational RFCs, so I'll move it. > > Other Nits and Editorials: > > SFF Labels are similar to other service labels at the bottom of an > MPLS label stack that denote the contents of the MPLS payload being > other than IP, such as a layer 2 pseudowire, an IP packet that is > routed in a VPN context with a private address, or an Ethernet > virtual private wire service. > > This says "being other than IP, such as IP", which seems to be > self-contradictory :-) > > :-) How about we change "other than IP," to "other than a normally routed IP packet", Thanks again, Andy --000000000000bd572905826b55f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Carlos,

Man= y thanks for your review! I'm also including the SFC WG on my reply.

Comments inline.

On Wed, Feb 20, 2019 at 10:58 PM Car= los Pignataro <cpignata@cisco.com<= /a>> wrote:
R= eviewer: Carlos Pignataro
Review result: Has Issues

Reviewer: Carlos Pignataro
Review Result: Has Issues

I have reviewed this document as part of the Operational directorate= 9;s
ongoing effort to review all IETF documents being processed by the I= ESG.=C2=A0 These
comments were written with the intent of improving the = operational aspects of
the IETF drafts. Comments that are not addressed = in last call may be included
in AD reviews during the IESG review.=C2=A0= Document editors and WG chairs should
treat these comments just like an= y other last call comments.

This document is highly readable, includes very clear textual descripti= ons, and
is very well organized. Easy to read in its simplicity. However= , it would
benefit from a more explicit connection to the transport enca= p mechanics from
RFC 8300 (e.g., S4, S6.1). Specifically, I'd recomm= end adding a Figure or an
SFF NSH Mapping Table example, to depict and/o= r exemplify the SFF function.


<= /div>
      +------=
+------+---------------------+-------------------------+
      | SPI  | SI   | Next Hop(s)   =
      | Transport Encapsulation |
      +------+------+---------------------+-------------------------+
= 
      | 25   | 220  | L=
abel 5467          | MPLS                    |
      +------+------+---------------------+---=
----------------------+

=
Is that what you had in mind? If not, I'm open to other sugg= estions.
=C2=A0

>From an Operational standpoint, the document seems largely appropri= ate in terms
of dataplane considerations. Some key considerations are ex= plicitly out of
scope:
=C2=A0 =C2=A0The method used by the downstream= receiving node to advertise SFF
=C2=A0 =C2=A0Labels to the upstream sen= ding node is out of scope of this document.

This really seems to mean that, with the simple definition in this
I= nformational document, interoperable implementations cannot yet exist. Ifthere is no mechanism to advertise the SFF Label or to manage the semanti= cs of
this particular label, how will it know? Static configuration, whi= ch is not
covered anyway, is not in my humble opinion a manageable scala= ble approach.

Actually, while it is out= side the scope of this document, it is within the scope of=C2=A0draft-ietf-= bess-nsh-bgp-control-plane, and text is being added to the next revision of= that draft to show how it can be used to signal the encapsulation defined = here. This was worked out after this draft was forwarded to the IESG, but w= e can now add a reference to that draft seeing as we'll be doing a post= -last-call update.
=C2=A0

Title: MPLS Encapsulation For The SFC NSH

RFC 8300 makes an explicit distinction between the terms 'encapsula= tion' and
'transport encapsulation' (see e.g., Figure 1, Sec= tion 1.5 5., and Section 4 of
RFC 8300).

It seems to me that this is the "MPLS Transport Encapsulation for = the SFC NSH"

Thanks, we'll fix= that.
=C2=A0

2.=C2=A0 MPLS Encapsulation Using an SFF Label

Similarly, "2. MPLS Transport Encapsulation Using an SFF Label&quo= t;

=C2=A0 =C2=A0The encapsulation is a standard MPLS label stack [RFC3032]= with an
=C2=A0 =C2=A0SFF Label at the bottom of the stack, followed by = a NSH as defined by
=C2=A0 =C2=A0[RFC8300] and the NSH payload.

Insteadf of "NSH payload" I think "orignal packet" = is meant.

RFC 8300 uses both "payl= oad" and "original packet/frame", but the latter more than t= he former. So we can change "payload" to "original packet/fr= ame".
=C2=A0

Also, this encapsulation is Underdefined: What is the value of TTL? TC?=

I've been looking back at other re= lated RFCs (such as PW and IP VPN label definitions) and they're also m= ostly silent on these values. I did find the following in RFC 6073:



   This document does not define a use for=
 the Traffic Class (TC) field
   [RFC5462] (forme=
rly known as the Experimental Use (EXP) bits
   [RFC3032]) in the flow label.  Future documents=
 may define a use for
   these bits; therefore, implementations conforming to this
   specification MUST set the TC field to zero at the ingress and MUST
   ignore them at the egress.

Do you have = any alternative suggestions?
=C2=A0

=C2=A0 =C2=A0Much like a pseudowire label, an SFF Label is allocated by= the
=C2=A0 =C2=A0downstream receiver of the NSH from its per-platform l= abel space.

A PW Label is more restrictive. RFC 8077 says it MUST be allocated asper-platform:

=C2=A0 =C2=A0egress LSR only.=C2=A0 Note that the PW label must always = be at the bottom
=C2=A0 =C2=A0of the packet's label stack, and label= s MUST be allocated from the
=C2=A0 =C2=A0per-platform label space.

Is this the case for the SFF Label as well? If so, what is the implicat= ion of
the MUST? If not, why is it different than other equivalent simil= ar labels?

We can change the text to:

=C2=A0Much like a pseudowire label, an SFF Label MU= ST be allocated by the downstream receiver of the NSH from its per-platform= label space, since the meaning of the label is identical independent of wh= ich incoming interface it is received [RFC3031].


=C2=A0 =C2=A02.=C2=A0 Push the SFF Label to identify the desired SFF in= the receiving
=C2=A0 =C2=A0 =C2=A0 =C2=A0MPLS node.

TTL value? 1? 2? 255 for GTSM? GTSM RFC 5082 could be used here.

As I noted above, 255, although I used RFC 60= 73 as my source rather than 5082. We'll add that here as well.


4.=C2=A0 Operations, Administration, and Maintenance (OAM) Consideratio= ns

=C2=A0 =C2=A0OAM at the SFC Layer is handled by SFC-defined mechanisms = [RFC8300].
=C2=A0 =C2=A0However, OAM may be required at the MPLS transpo= rt layer.=C2=A0 If so,
=C2=A0 =C2=A0then standard MPLS-layer OAM mechani= sms such as the Generic
=C2=A0 =C2=A0Associated Channel [RFC5586] label = may be used.

RFC 5586 is _not_ an OAM mechanism. It is an associated channel creatio= n
mechanism, over which OAM could be carried.

Thus, what traditional MPLS OAM can be carried here? Things like RFC 43= 79 / RFC
8029 would need the definition of an SFF Label FEC (which does = not exist).
Which other one? IP/ICMP seems of very limited value.

That's a good point about RFC 5586. The i= ntention is that the MPLS OAM would be at the transport label layer above t= he SFF label, so most any MPLS-layer OAM would be applicable. So how about = rewording to make that more clear:

OAM at the SFC = Layer is handled by SFC-defined mechanisms [RFC8300]. However, OAM may be r= equired at the MPLS transport layer.=C2=A0 If so, then standard MPLS-layer = OAM mechanisms may be used at the transport label layer (the labels above t= he SFF label).
=C2=A0

6.=C2=A0 Security Considerations

Have you considered the use of GTSM?

No, we hadn't. Can you point me to any examples of GTSM being used in= an MPLS or PW context?
=C2=A0

8.=C2=A0 References

=C2=A0 =C2=A0[RFC7665]=C2=A0 Halpern, J., Ed. and C. Pignataro, Ed., &q= uot;Service Function
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ch= aining (SFC) Architecture", RFC 7665,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 DOI 10.17487/RFC7665, October 2015,
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.rfc-editor= .org/info/rfc7665>.

SHould RFC 7665 be Normative? It defines the "SFF" which is q= uite central to
understanding this document.

Good point. It was there because 7665 is an Informational RFC, but= RFC 8067 does allow normative references to informational RFCs, so I'l= l move it.
=C2=A0

Other Nits and Editorials:

=C2=A0 =C2=A0SFF Labels are similar to other service labels at the bott= om of an
=C2=A0 =C2=A0MPLS label stack that denote the contents of the M= PLS payload being
=C2=A0 =C2=A0other than IP, such as a layer 2 pseudowi= re, an IP packet that is
=C2=A0 =C2=A0routed in a VPN context with a pri= vate address, or an Ethernet
=C2=A0 =C2=A0virtual private wire service.<= br>
This says "being other than IP, such as IP", which seems to b= e
self-contradictory :-)

:-)

How about we change "other than IP," to "other than a= normally routed IP packet",

Thanks again,
Andy

--000000000000bd572905826b55f9-- From nobody Thu Feb 21 17:42: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 0431D12D7EA; Thu, 21 Feb 2019 17:41:58 -0800 (PST) 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_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, 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 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 6Q6mAMMcrMvG; Thu, 21 Feb 2019 17:41:55 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28EB128B01; Thu, 21 Feb 2019 17:41:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43432; q=dns/txt; s=iport; t=1550799714; x=1552009314; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aWggBEghsItTOFXRZltTXQ8YlsL7WhhFg9VdsH/lKbQ=; b=dihJBnzY8BpnQ+ncqClSPsgmktdkT4qnkxy8h58uULh5qz/bterlca8i iLkNcmeTv36QAw4PHdIjbYhYx4ZNvJq+0gtfMHkwiNVDiNNbGOikcKRdc dA+wwJ3XdRtcjItm7cqxCkTm0GRC7exGsNrQ986QSvpfXs0nS/nlBafl0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAADlUW9c/5xdJa1bChoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVMDAQEBAQsBgQ1MKmeBAycKg32VWIlSjnGBewsBASOESQI?= =?us-ascii?q?Xg2MiNgcNAQMBAQIBAQJtHAyFSwYjRBIQAgEIEiYBBgMCAgIfERQDDgIEDgW?= =?us-ascii?q?DIAGBDkwDFQ+sEYEvhENBgwINghkFjEgXgUA/gREnDBOCTIJXRwEBAwGBMgQ?= =?us-ascii?q?mgwoxgiYCigcDB4F9hCOHF4s0JDMJAoc8h2SDPBmBcYVag0GEY4Mci1mEPoE?= =?us-ascii?q?tiCCCbAIRFIEoJg0kgVZwFRpLAYINATM+gWoFEoEAAQiHVoU/QTGNPoEugR8?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.58,397,1544486400"; d="scan'208,217";a="525624780" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2019 01:41:53 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x1M1fqMq018261 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Feb 2019 01:41:53 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 21 Feb 2019 20:41:52 -0500 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1395.000; Thu, 21 Feb 2019 20:41:52 -0500 From: "Carlos Pignataro (cpignata)" To: "Andrew G. Malis" CC: "ops-dir@ietf.org" , mpls , "draft-ietf-mpls-sfc-encapsulation.all@ietf.org" , IETF Discussion , "sfc@ietf.org" Thread-Topic: [mpls] Opsdir last call review of draft-ietf-mpls-sfc-encapsulation-02 Thread-Index: AQHUyhBL6QxMzhBFbEuO+4PZE0wBEaXrX0GA Date: Fri, 22 Feb 2019 01:41:52 +0000 Message-ID: <6A97863A-DD90-4D62-9607-569386F5F850@cisco.com> References: <155072147698.20210.381511429964485828@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.102.3) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.116.133] Content-Type: multipart/alternative; boundary="_000_6A97863ADD904D629607569386F5F850ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.160, xch-rtp-020.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [mpls] Opsdir last call review of draft-ietf-mpls-sfc-encapsulation-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: Fri, 22 Feb 2019 01:41:58 -0000 --_000_6A97863ADD904D629607569386F5F850ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEFuZHksDQoNCk9uIEZlYiAyMSwgMjAxOSwgYXQgMTowNiBQTSwgQW5kcmV3IEcuIE1hbGlz IDxhZ21hbGlzQGdtYWlsLmNvbTxtYWlsdG86YWdtYWxpc0BnbWFpbC5jb20+PiB3cm90ZToNCg0K Q2FybG9zLA0KDQpNYW55IHRoYW5rcyBmb3IgeW91ciByZXZpZXchIEknbSBhbHNvIGluY2x1ZGlu ZyB0aGUgU0ZDIFdHIG9uIG15IHJlcGx5Lg0KDQpUaGFua3MgZm9yIHRoZSBxdWljayByZXNwb25z ZSwgYW5kIGZvciBjb25zaWRlcmluZyB0aGUgY29tbWVudHMhDQoNCkkgZW5qb3llZCByZWFkaW5n IHRoaXMgZG9jdW1lbnQg4oCUIHBsZWFzZSBzZWUgYmVsb3cuDQoNCg0KQ29tbWVudHMgaW5saW5l Lg0KDQpPbiBXZWQsIEZlYiAyMCwgMjAxOSBhdCAxMDo1OCBQTSBDYXJsb3MgUGlnbmF0YXJvIDxj cGlnbmF0YUBjaXNjby5jb208bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbT4+IHdyb3RlOg0KUmV2 aWV3ZXI6IENhcmxvcyBQaWduYXRhcm8NClJldmlldyByZXN1bHQ6IEhhcyBJc3N1ZXMNCg0KUmV2 aWV3ZXI6IENhcmxvcyBQaWduYXRhcm8NClJldmlldyBSZXN1bHQ6IEhhcyBJc3N1ZXMNCg0KSSBo YXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgT3BlcmF0aW9uYWwgZGly ZWN0b3JhdGUncw0Kb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBi ZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZQ0KY29tbWVudHMgd2VyZSB3cml0dGVu IHdpdGggdGhlIGludGVudCBvZiBpbXByb3ZpbmcgdGhlIG9wZXJhdGlvbmFsIGFzcGVjdHMgb2YN CnRoZSBJRVRGIGRyYWZ0cy4gQ29tbWVudHMgdGhhdCBhcmUgbm90IGFkZHJlc3NlZCBpbiBsYXN0 IGNhbGwgbWF5IGJlIGluY2x1ZGVkDQppbiBBRCByZXZpZXdzIGR1cmluZyB0aGUgSUVTRyByZXZp ZXcuICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkDQp0cmVhdCB0aGVzZSBj b21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCg0KVGhpcyBk b2N1bWVudCBpcyBoaWdobHkgcmVhZGFibGUsIGluY2x1ZGVzIHZlcnkgY2xlYXIgdGV4dHVhbCBk ZXNjcmlwdGlvbnMsIGFuZA0KaXMgdmVyeSB3ZWxsIG9yZ2FuaXplZC4gRWFzeSB0byByZWFkIGlu IGl0cyBzaW1wbGljaXR5LiBIb3dldmVyLCBpdCB3b3VsZA0KYmVuZWZpdCBmcm9tIGEgbW9yZSBl eHBsaWNpdCBjb25uZWN0aW9uIHRvIHRoZSB0cmFuc3BvcnQgZW5jYXAgbWVjaGFuaWNzIGZyb20N ClJGQyA4MzAwIChlLmcuLCBTNCwgUzYuMSkuIFNwZWNpZmljYWxseSwgSSdkIHJlY29tbWVuZCBh ZGRpbmcgYSBGaWd1cmUgb3IgYW4NClNGRiBOU0ggTWFwcGluZyBUYWJsZSBleGFtcGxlLCB0byBk ZXBpY3QgYW5kL29yIGV4ZW1wbGlmeSB0aGUgU0ZGIGZ1bmN0aW9uLg0KDQpJJ20gdHJ5aW5nIHRv IGVudmlzaW9uIHdoYXQgd291bGQgbWFrZSBhIGdvb2QgZmlndXJlIGhlcmUuIFdlIGNvdWxkIGFk ZCBhbiBhZGRpdGlvbmFsIGxpbmUgdG8gVGFibGUgMSBvZiBSRkMgODMwMCBhbmQgcmVmZXJlbmNl IHRoYXQgdGFibGU6DQoNCg0KICAgICAgKy0tLS0tLSstLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCiAgICAgIHwgU1BJICB8IFNJICAgfCBO ZXh0IEhvcChzKSAgICAgICAgIHwgVHJhbnNwb3J0IEVuY2Fwc3VsYXRpb24gfA0KICAgICAgKy0t LS0tLSstLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rDQoNCiAgICAgIHwgMjUgICB8IDIyMCAgfCBMYWJlbCA1NDY3ICAgICAgICAgIHwgTVBMUyAg ICAgICAgICAgICAgICAgICAgfA0KDQogICAgICArLS0tLS0tKy0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KSXMgdGhhdCB3aGF0IHlvdSBo YWQgaW4gbWluZD8gSWYgbm90LCBJJ20gb3BlbiB0byBvdGhlciBzdWdnZXN0aW9ucy4NCg0KSWYg eW91IHRoaW5rIGl0IGhlbHBzLCB0aGlzIHdvdWxkIGJlIGEgZ29vZCBhZGRpdGlvbi4NCg0KDQoN Cj5Gcm9tIGFuIE9wZXJhdGlvbmFsIHN0YW5kcG9pbnQsIHRoZSBkb2N1bWVudCBzZWVtcyBsYXJn ZWx5IGFwcHJvcHJpYXRlIGluIHRlcm1zDQpvZiBkYXRhcGxhbmUgY29uc2lkZXJhdGlvbnMuIFNv bWUga2V5IGNvbnNpZGVyYXRpb25zIGFyZSBleHBsaWNpdGx5IG91dCBvZg0Kc2NvcGU6DQogICBU aGUgbWV0aG9kIHVzZWQgYnkgdGhlIGRvd25zdHJlYW0gcmVjZWl2aW5nIG5vZGUgdG8gYWR2ZXJ0 aXNlIFNGRg0KICAgTGFiZWxzIHRvIHRoZSB1cHN0cmVhbSBzZW5kaW5nIG5vZGUgaXMgb3V0IG9m IHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNClRoaXMgcmVhbGx5IHNlZW1zIHRvIG1lYW4gdGhh dCwgd2l0aCB0aGUgc2ltcGxlIGRlZmluaXRpb24gaW4gdGhpcw0KSW5mb3JtYXRpb25hbCBkb2N1 bWVudCwgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMgY2Fubm90IHlldCBleGlzdC4gSWYN CnRoZXJlIGlzIG5vIG1lY2hhbmlzbSB0byBhZHZlcnRpc2UgdGhlIFNGRiBMYWJlbCBvciB0byBt YW5hZ2UgdGhlIHNlbWFudGljcyBvZg0KdGhpcyBwYXJ0aWN1bGFyIGxhYmVsLCBob3cgd2lsbCBp dCBrbm93PyBTdGF0aWMgY29uZmlndXJhdGlvbiwgd2hpY2ggaXMgbm90DQpjb3ZlcmVkIGFueXdh eSwgaXMgbm90IGluIG15IGh1bWJsZSBvcGluaW9uIGEgbWFuYWdlYWJsZSBzY2FsYWJsZSBhcHBy b2FjaC4NCg0KQWN0dWFsbHksIHdoaWxlIGl0IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMg ZG9jdW1lbnQsIGl0IGlzIHdpdGhpbiB0aGUgc2NvcGUgb2YgZHJhZnQtaWV0Zi1iZXNzLW5zaC1i Z3AtY29udHJvbC1wbGFuZSwgYW5kIHRleHQgaXMgYmVpbmcgYWRkZWQgdG8gdGhlIG5leHQgcmV2 aXNpb24gb2YgdGhhdCBkcmFmdCB0byBzaG93IGhvdyBpdCBjYW4gYmUgdXNlZCB0byBzaWduYWwg dGhlIGVuY2Fwc3VsYXRpb24gZGVmaW5lZCBoZXJlLiBUaGlzIHdhcyB3b3JrZWQgb3V0IGFmdGVy IHRoaXMgZHJhZnQgd2FzIGZvcndhcmRlZCB0byB0aGUgSUVTRywgYnV0IHdlIGNhbiBub3cgYWRk IGEgcmVmZXJlbmNlIHRvIHRoYXQgZHJhZnQgc2VlaW5nIGFzIHdlJ2xsIGJlIGRvaW5nIGEgcG9z dC1sYXN0LWNhbGwgdXBkYXRlLg0KDQpJIHRoaW5rIHRoYXQgd2lsbCBoZWxwLCBhcyBhbiBJbmZv cm1hdGl2ZSDigJxvbmUgZW1ib2RpbWVudOKAnSB0eXBlIG9mIGxpbmsuDQoNCg0KDQpUaXRsZTog TVBMUyBFbmNhcHN1bGF0aW9uIEZvciBUaGUgU0ZDIE5TSA0KDQpSRkMgODMwMCBtYWtlcyBhbiBl eHBsaWNpdCBkaXN0aW5jdGlvbiBiZXR3ZWVuIHRoZSB0ZXJtcyAnZW5jYXBzdWxhdGlvbicgYW5k DQondHJhbnNwb3J0IGVuY2Fwc3VsYXRpb24nIChzZWUgZS5nLiwgRmlndXJlIDEsIFNlY3Rpb24g MS41IDUuLCBhbmQgU2VjdGlvbiA0IG9mDQpSRkMgODMwMCkuDQoNCkl0IHNlZW1zIHRvIG1lIHRo YXQgdGhpcyBpcyB0aGUgIk1QTFMgVHJhbnNwb3J0IEVuY2Fwc3VsYXRpb24gZm9yIHRoZSBTRkMg TlNIIg0KDQpUaGFua3MsIHdlJ2xsIGZpeCB0aGF0Lg0KDQoNCjIuICBNUExTIEVuY2Fwc3VsYXRp b24gVXNpbmcgYW4gU0ZGIExhYmVsDQoNClNpbWlsYXJseSwgIjIuIE1QTFMgVHJhbnNwb3J0IEVu Y2Fwc3VsYXRpb24gVXNpbmcgYW4gU0ZGIExhYmVsIg0KDQogICBUaGUgZW5jYXBzdWxhdGlvbiBp cyBhIHN0YW5kYXJkIE1QTFMgbGFiZWwgc3RhY2sgW1JGQzMwMzJdIHdpdGggYW4NCiAgIFNGRiBM YWJlbCBhdCB0aGUgYm90dG9tIG9mIHRoZSBzdGFjaywgZm9sbG93ZWQgYnkgYSBOU0ggYXMgZGVm aW5lZCBieQ0KICAgW1JGQzgzMDBdIGFuZCB0aGUgTlNIIHBheWxvYWQuDQoNCkluc3RlYWRmIG9m ICJOU0ggcGF5bG9hZCIgSSB0aGluayAib3JpZ25hbCBwYWNrZXQiIGlzIG1lYW50Lg0KDQpSRkMg ODMwMCB1c2VzIGJvdGggInBheWxvYWQiIGFuZCAib3JpZ2luYWwgcGFja2V0L2ZyYW1lIiwgYnV0 IHRoZSBsYXR0ZXIgbW9yZSB0aGFuIHRoZSBmb3JtZXIuIFNvIHdlIGNhbiBjaGFuZ2UgInBheWxv YWQiIHRvICJvcmlnaW5hbCBwYWNrZXQvZnJhbWUiLg0KDQoNCkFsc28sIHRoaXMgZW5jYXBzdWxh dGlvbiBpcyBVbmRlcmRlZmluZWQ6IFdoYXQgaXMgdGhlIHZhbHVlIG9mIFRUTD8gVEM/DQoNCkkn dmUgYmVlbiBsb29raW5nIGJhY2sgYXQgb3RoZXIgcmVsYXRlZCBSRkNzIChzdWNoIGFzIFBXIGFu ZCBJUCBWUE4gbGFiZWwgZGVmaW5pdGlvbnMpIGFuZCB0aGV5J3JlIGFsc28gbW9zdGx5IHNpbGVu dCBvbiB0aGVzZSB2YWx1ZXMuIEkgZGlkIGZpbmQgdGhlIGZvbGxvd2luZyBpbiBSRkMgNjA3MzoN Cg0KDQogICBUaGUgc2V0dGluZyBvZiB0aGUgVFRMIG9mIHRoZSBQVyBNUExTDQogICBsYWJlbCBp cyBhIG1hdHRlciBvZiBsb2NhbCBwb2xpY3kgb24gdGhlIG9yaWdpbmF0aW5nIFBFLCBidXQgU0hP VUxEDQogICBiZSBzZXQgdG8gMjU1Lg0KDQpSZWdhcmRpbmcgdGhlIFRDLCB3ZSBjYW4gZm9sbG93 IHRoZSBleGFtcGxlIG9mIFJGQyA2MzkxOg0KDQoNCiAgIFRoaXMgZG9jdW1lbnQgZG9lcyBub3Qg ZGVmaW5lIGEgdXNlIGZvciB0aGUgVHJhZmZpYyBDbGFzcyAoVEMpIGZpZWxkDQogICBbUkZDNTQ2 MjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTQ2Mj5dIChmb3JtZXJseSBrbm93biBh cyB0aGUgRXhwZXJpbWVudGFsIFVzZSAoRVhQKSBiaXRzDQogICBbUkZDMzAzMjxodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjMzAzMj5dKSBpbiB0aGUgZmxvdyBsYWJlbC4gIEZ1dHVyZSBk b2N1bWVudHMgbWF5IGRlZmluZSBhIHVzZSBmb3INCiAgIHRoZXNlIGJpdHM7IHRoZXJlZm9yZSwg aW1wbGVtZW50YXRpb25zIGNvbmZvcm1pbmcgdG8gdGhpcw0KICAgc3BlY2lmaWNhdGlvbiBNVVNU IHNldCB0aGUgVEMgZmllbGQgdG8gemVybyBhdCB0aGUgaW5ncmVzcyBhbmQgTVVTVA0KICAgaWdu b3JlIHRoZW0gYXQgdGhlIGVncmVzcy4NCg0KDQpEbyB5b3UgaGF2ZSBhbnkgYWx0ZXJuYXRpdmUg c3VnZ2VzdGlvbnM/DQoNClRoZXNlIHR3byBhcHByb2FjaGVzIHNvdW5kcyBnb29kIHRvIG1lLiBB bmQgQWNrIHRvIHRoZSBvdGhlciBwcmV2aW91cyByZXNwb25zZXMuDQoNCg0KDQogICBNdWNoIGxp a2UgYSBwc2V1ZG93aXJlIGxhYmVsLCBhbiBTRkYgTGFiZWwgaXMgYWxsb2NhdGVkIGJ5IHRoZQ0K ICAgZG93bnN0cmVhbSByZWNlaXZlciBvZiB0aGUgTlNIIGZyb20gaXRzIHBlci1wbGF0Zm9ybSBs YWJlbCBzcGFjZS4NCg0KQSBQVyBMYWJlbCBpcyBtb3JlIHJlc3RyaWN0aXZlLiBSRkMgODA3NyBz YXlzIGl0IE1VU1QgYmUgYWxsb2NhdGVkIGFzDQpwZXItcGxhdGZvcm06DQoNCiAgIGVncmVzcyBM U1Igb25seS4gIE5vdGUgdGhhdCB0aGUgUFcgbGFiZWwgbXVzdCBhbHdheXMgYmUgYXQgdGhlIGJv dHRvbQ0KICAgb2YgdGhlIHBhY2tldCdzIGxhYmVsIHN0YWNrLCBhbmQgbGFiZWxzIE1VU1QgYmUg YWxsb2NhdGVkIGZyb20gdGhlDQogICBwZXItcGxhdGZvcm0gbGFiZWwgc3BhY2UuDQoNCklzIHRo aXMgdGhlIGNhc2UgZm9yIHRoZSBTRkYgTGFiZWwgYXMgd2VsbD8gSWYgc28sIHdoYXQgaXMgdGhl IGltcGxpY2F0aW9uIG9mDQp0aGUgTVVTVD8gSWYgbm90LCB3aHkgaXMgaXQgZGlmZmVyZW50IHRo YW4gb3RoZXIgZXF1aXZhbGVudCBzaW1pbGFyIGxhYmVscz8NCg0KV2UgY2FuIGNoYW5nZSB0aGUg dGV4dCB0bzoNCg0KIE11Y2ggbGlrZSBhIHBzZXVkb3dpcmUgbGFiZWwsIGFuIFNGRiBMYWJlbCBN VVNUIGJlIGFsbG9jYXRlZCBieSB0aGUgZG93bnN0cmVhbSByZWNlaXZlciBvZiB0aGUgTlNIIGZy b20gaXRzIHBlci1wbGF0Zm9ybSBsYWJlbCBzcGFjZSwgc2luY2UgdGhlIG1lYW5pbmcgb2YgdGhl IGxhYmVsIGlzIGlkZW50aWNhbCBpbmRlcGVuZGVudCBvZiB3aGljaCBpbmNvbWluZyBpbnRlcmZh Y2UgaXQgaXMgcmVjZWl2ZWQgW1JGQzMwMzFdLg0KDQoNClRoYXTigJlzIGEgZ3JlYXQgaW1wcm92 ZW1lbnQuDQoNCg0KICAgMi4gIFB1c2ggdGhlIFNGRiBMYWJlbCB0byBpZGVudGlmeSB0aGUgZGVz aXJlZCBTRkYgaW4gdGhlIHJlY2VpdmluZw0KICAgICAgIE1QTFMgbm9kZS4NCg0KVFRMIHZhbHVl PyAxPyAyPyAyNTUgZm9yIEdUU00/IEdUU00gUkZDIDUwODIgY291bGQgYmUgdXNlZCBoZXJlLg0K DQpBcyBJIG5vdGVkIGFib3ZlLCAyNTUsIGFsdGhvdWdoIEkgdXNlZCBSRkMgNjA3MyBhcyBteSBz b3VyY2UgcmF0aGVyIHRoYW4gNTA4Mi4gV2UnbGwgYWRkIHRoYXQgaGVyZSBhcyB3ZWxsLg0KDQoN ClNvdW5kcyBnb29kLg0KVGhlc2UgcHJvdG9jb2xzIHVzZSA1MDgyIGluIG9uZSBmb3JtIG9yIGFu b3RoZXI6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzUwODIvcmVmZXJlbmNl ZGJ5Lw0KDQoNCjQuICBPcGVyYXRpb25zLCBBZG1pbmlzdHJhdGlvbiwgYW5kIE1haW50ZW5hbmNl IChPQU0pIENvbnNpZGVyYXRpb25zDQoNCiAgIE9BTSBhdCB0aGUgU0ZDIExheWVyIGlzIGhhbmRs ZWQgYnkgU0ZDLWRlZmluZWQgbWVjaGFuaXNtcyBbUkZDODMwMF0uDQogICBIb3dldmVyLCBPQU0g bWF5IGJlIHJlcXVpcmVkIGF0IHRoZSBNUExTIHRyYW5zcG9ydCBsYXllci4gIElmIHNvLA0KICAg dGhlbiBzdGFuZGFyZCBNUExTLWxheWVyIE9BTSBtZWNoYW5pc21zIHN1Y2ggYXMgdGhlIEdlbmVy aWMNCiAgIEFzc29jaWF0ZWQgQ2hhbm5lbCBbUkZDNTU4Nl0gbGFiZWwgbWF5IGJlIHVzZWQuDQoN ClJGQyA1NTg2IGlzIF9ub3RfIGFuIE9BTSBtZWNoYW5pc20uIEl0IGlzIGFuIGFzc29jaWF0ZWQg Y2hhbm5lbCBjcmVhdGlvbg0KbWVjaGFuaXNtLCBvdmVyIHdoaWNoIE9BTSBjb3VsZCBiZSBjYXJy aWVkLg0KDQpUaHVzLCB3aGF0IHRyYWRpdGlvbmFsIE1QTFMgT0FNIGNhbiBiZSBjYXJyaWVkIGhl cmU/IFRoaW5ncyBsaWtlIFJGQyA0Mzc5IC8gUkZDDQo4MDI5IHdvdWxkIG5lZWQgdGhlIGRlZmlu aXRpb24gb2YgYW4gU0ZGIExhYmVsIEZFQyAod2hpY2ggZG9lcyBub3QgZXhpc3QpLg0KV2hpY2gg b3RoZXIgb25lPyBJUC9JQ01QIHNlZW1zIG9mIHZlcnkgbGltaXRlZCB2YWx1ZS4NCg0KVGhhdCdz IGEgZ29vZCBwb2ludCBhYm91dCBSRkMgNTU4Ni4gVGhlIGludGVudGlvbiBpcyB0aGF0IHRoZSBN UExTIE9BTSB3b3VsZCBiZSBhdCB0aGUgdHJhbnNwb3J0IGxhYmVsIGxheWVyIGFib3ZlIHRoZSBT RkYgbGFiZWwsIHNvIG1vc3QgYW55IE1QTFMtbGF5ZXIgT0FNIHdvdWxkIGJlIGFwcGxpY2FibGUu IFNvIGhvdyBhYm91dCByZXdvcmRpbmcgdG8gbWFrZSB0aGF0IG1vcmUgY2xlYXI6DQoNCk9BTSBh dCB0aGUgU0ZDIExheWVyIGlzIGhhbmRsZWQgYnkgU0ZDLWRlZmluZWQgbWVjaGFuaXNtcyBbUkZD ODMwMF0uIEhvd2V2ZXIsIE9BTSBtYXkgYmUgcmVxdWlyZWQgYXQgdGhlIE1QTFMgdHJhbnNwb3J0 IGxheWVyLiAgSWYgc28sIHRoZW4gc3RhbmRhcmQgTVBMUy1sYXllciBPQU0gbWVjaGFuaXNtcyBt YXkgYmUgdXNlZCBhdCB0aGUgdHJhbnNwb3J0IGxhYmVsIGxheWVyICh0aGUgbGFiZWxzIGFib3Zl IHRoZSBTRkYgbGFiZWwpLg0KDQpMb29rcyBnb29kIHRvIG1lLCB0aGFuayB5b3UuDQoNCg0KDQo2 LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KSGF2ZSB5b3UgY29uc2lkZXJlZCB0aGUgdXNl IG9mIEdUU00/DQoNCk5vLCB3ZSBoYWRuJ3QuIENhbiB5b3UgcG9pbnQgbWUgdG8gYW55IGV4YW1w bGVzIG9mIEdUU00gYmVpbmcgdXNlZCBpbiBhbiBNUExTIG9yIFBXIGNvbnRleHQ/DQoNClllcywg c2VlIGFib3ZlLg0KDQoNCg0KOC4gIFJlZmVyZW5jZXMNCg0KICAgW1JGQzc2NjVdICBIYWxwZXJu LCBKLiwgRWQuIGFuZCBDLiBQaWduYXRhcm8sIEVkLiwgIlNlcnZpY2UgRnVuY3Rpb24NCiAgICAg ICAgICAgICAgQ2hhaW5pbmcgKFNGQykgQXJjaGl0ZWN0dXJlIiwgUkZDIDc2NjUsDQogICAgICAg ICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM3NjY1LCBPY3RvYmVyIDIwMTUsDQogICAgICAgICAgICAg IDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzc2NjU+Lg0KDQpTSG91bGQgUkZD IDc2NjUgYmUgTm9ybWF0aXZlPyBJdCBkZWZpbmVzIHRoZSAiU0ZGIiB3aGljaCBpcyBxdWl0ZSBj ZW50cmFsIHRvDQp1bmRlcnN0YW5kaW5nIHRoaXMgZG9jdW1lbnQuDQoNCkdvb2QgcG9pbnQuIEl0 IHdhcyB0aGVyZSBiZWNhdXNlIDc2NjUgaXMgYW4gSW5mb3JtYXRpb25hbCBSRkMsIGJ1dCBSRkMg ODA2NyBkb2VzIGFsbG93IG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIGluZm9ybWF0aW9uYWwgUkZD cywgc28gSSdsbCBtb3ZlIGl0Lg0KDQoNClRoYW5rIHlvdS4NCg0KDQpPdGhlciBOaXRzIGFuZCBF ZGl0b3JpYWxzOg0KDQogICBTRkYgTGFiZWxzIGFyZSBzaW1pbGFyIHRvIG90aGVyIHNlcnZpY2Ug bGFiZWxzIGF0IHRoZSBib3R0b20gb2YgYW4NCiAgIE1QTFMgbGFiZWwgc3RhY2sgdGhhdCBkZW5v dGUgdGhlIGNvbnRlbnRzIG9mIHRoZSBNUExTIHBheWxvYWQgYmVpbmcNCiAgIG90aGVyIHRoYW4g SVAsIHN1Y2ggYXMgYSBsYXllciAyIHBzZXVkb3dpcmUsIGFuIElQIHBhY2tldCB0aGF0IGlzDQog ICByb3V0ZWQgaW4gYSBWUE4gY29udGV4dCB3aXRoIGEgcHJpdmF0ZSBhZGRyZXNzLCBvciBhbiBF dGhlcm5ldA0KICAgdmlydHVhbCBwcml2YXRlIHdpcmUgc2VydmljZS4NCg0KVGhpcyBzYXlzICJi ZWluZyBvdGhlciB0aGFuIElQLCBzdWNoIGFzIElQIiwgd2hpY2ggc2VlbXMgdG8gYmUNCnNlbGYt Y29udHJhZGljdG9yeSA6LSkNCg0KOi0pDQoNCkhvdyBhYm91dCB3ZSBjaGFuZ2UgIm90aGVyIHRo YW4gSVAsIiB0byAib3RoZXIgdGhhbiBhIG5vcm1hbGx5IHJvdXRlZCBJUCBwYWNrZXTigJ0sDQoN ClRoYXQgd291bGQgZGlzYW1iaWd1YXRlIGl0Lg0KDQpUaGFua3MgYWdhaW4uDQoNClRvIG1lLCB0 aGUgY29udHJvbCBwbGFuZSAvIGFkdmVydGlzZW1lbnQgd2FzIHRoZSBtb3N0IGltcG9ydGFudCBv cGVyYXRpb25hbGx5LXJlbGV2YW50IGNvbW1lbnQuDQoNClRoYW5rcywNCg0KQ2FybG9zLg0KDQoN ClRoYW5rcyBhZ2FpbiwNCkFuZHkNCg0K --_000_6A97863ADD904D629607569386F5F850ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1666F5168A59714B8F3562BC0C3A4BB3@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpLCBBbmR5LA0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPk9uIEZlYiAyMSwgMjAxOSwgYXQgMTowNiBQTSwgQW5kcmV3IEcuIE1hbGlzICZs dDs8YSBocmVmPSJtYWlsdG86YWdtYWxpc0BnbWFpbC5jb20iIGNsYXNzPSIiPmFnbWFsaXNAZ21h aWwuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdl LW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0 ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj5DYXJsb3MsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5NYW55IHRoYW5rcyBmb3IgeW91ciByZXZpZXchIEkn bSBhbHNvIGluY2x1ZGluZyB0aGUgU0ZDIFdHIG9uIG15IHJlcGx5LjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXY+VGhhbmtzIGZvciB0aGUgcXVpY2sgcmVzcG9uc2UsIGFuZCBmb3IgY29uc2lkZXJpbmcg dGhlIGNvbW1lbnRzITwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+SSBl bmpveWVkIHJlYWRpbmcgdGhpcyBkb2N1bWVudCDigJQgcGxlYXNlIHNlZSBiZWxvdy48L2Rpdj4N CjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5v bmU7IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q29tbWVudHMgaW5saW5lLjwvZGl2 Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0 ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIFdlZCwgRmViIDIwLCAyMDE5IGF0IDEwOjU4IFBNIENh cmxvcyBQaWduYXRhcm8gJmx0OzxhIGhyZWY9Im1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20iIGNs YXNzPSIiPmNwaWduYXRhQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOiAwcHgg MHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6IDFweDsgYm9yZGVyLWxlZnQtc3R5bGU6 IHNvbGlkOyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0LCAyMDQpOyBwYWRkaW5nLWxl ZnQ6IDFleDsiPg0KUmV2aWV3ZXI6IENhcmxvcyBQaWduYXRhcm88YnIgY2xhc3M9IiI+DQpSZXZp ZXcgcmVzdWx0OiBIYXMgSXNzdWVzPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUmV2aWV3 ZXI6IENhcmxvcyBQaWduYXRhcm88YnIgY2xhc3M9IiI+DQpSZXZpZXcgUmVzdWx0OiBIYXMgSXNz dWVzPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9j dW1lbnQgYXMgcGFydCBvZiB0aGUgT3BlcmF0aW9uYWwgZGlyZWN0b3JhdGUnczxiciBjbGFzcz0i Ij4NCm9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJv Y2Vzc2VkIGJ5IHRoZSBJRVNHLiZuYnNwOyBUaGVzZTxiciBjbGFzcz0iIj4NCmNvbW1lbnRzIHdl cmUgd3JpdHRlbiB3aXRoIHRoZSBpbnRlbnQgb2YgaW1wcm92aW5nIHRoZSBvcGVyYXRpb25hbCBh c3BlY3RzIG9mPGJyIGNsYXNzPSIiPg0KdGhlIElFVEYgZHJhZnRzLiBDb21tZW50cyB0aGF0IGFy ZSBub3QgYWRkcmVzc2VkIGluIGxhc3QgY2FsbCBtYXkgYmUgaW5jbHVkZWQ8YnIgY2xhc3M9IiI+ DQppbiBBRCByZXZpZXdzIGR1cmluZyB0aGUgSUVTRyByZXZpZXcuJm5ic3A7IERvY3VtZW50IGVk aXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQ8YnIgY2xhc3M9IiI+DQp0cmVhdCB0aGVzZSBjb21t ZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpUaGlzIGRvY3VtZW50IGlzIGhpZ2hseSByZWFkYWJsZSwgaW5jbHVk ZXMgdmVyeSBjbGVhciB0ZXh0dWFsIGRlc2NyaXB0aW9ucywgYW5kPGJyIGNsYXNzPSIiPg0KaXMg dmVyeSB3ZWxsIG9yZ2FuaXplZC4gRWFzeSB0byByZWFkIGluIGl0cyBzaW1wbGljaXR5LiBIb3dl dmVyLCBpdCB3b3VsZDxiciBjbGFzcz0iIj4NCmJlbmVmaXQgZnJvbSBhIG1vcmUgZXhwbGljaXQg Y29ubmVjdGlvbiB0byB0aGUgdHJhbnNwb3J0IGVuY2FwIG1lY2hhbmljcyBmcm9tPGJyIGNsYXNz PSIiPg0KUkZDIDgzMDAgKGUuZy4sIFM0LCBTNi4xKS4gU3BlY2lmaWNhbGx5LCBJJ2QgcmVjb21t ZW5kIGFkZGluZyBhIEZpZ3VyZSBvciBhbjxiciBjbGFzcz0iIj4NClNGRiBOU0ggTWFwcGluZyBU YWJsZSBleGFtcGxlLCB0byBkZXBpY3QgYW5kL29yIGV4ZW1wbGlmeSB0aGUgU0ZGIGZ1bmN0aW9u LjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkknbSB0cnlpbmcgdG8gZW52aXNpb24gd2hhdCB3b3Vs ZCBtYWtlIGEgZ29vZCBmaWd1cmUgaGVyZS4gV2UgY291bGQgYWRkIGFuIGFkZGl0aW9uYWwgbGlu ZSB0byBUYWJsZSAxIG9mIFJGQyA4MzAwIGFuZCByZWZlcmVuY2UgdGhhdCB0YWJsZTo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHBy ZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMzM3B4OyBtYXJn aW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgYnJlYWstYmVmb3JlOiBwYWdlOyI+ICAg ICAgJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzs8L3ByZT4NCjxwcmUgY2xhc3M9ImdtYWlsLW5l d3BhZ2UiIHN0eWxlPSJmb250LXNpemU6IDEzLjMzMzNweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJn aW4tYm90dG9tOiAwcHg7IGJyZWFrLWJlZm9yZTogcGFnZTsiPiAgICAgIHwgU1BJICB8IFNJICAg fCBOZXh0IEhvcChzKSAgICAgICAgIHwgVHJhbnNwb3J0IEVuY2Fwc3VsYXRpb24gfA0KICAgICAg JiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzs8L3ByZT4NCjxwcmUgY2xhc3M9ImdtYWlsLW5ld3Bh Z2UiIHN0eWxlPSJmb250LXNpemU6IDEzLjMzMzNweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4t Ym90dG9tOiAwcHg7IGJyZWFrLWJlZm9yZTogcGFnZTsiPiAgICAgIHwgMjUgICB8IDIyMCAgfCBM YWJlbCA1NDY3ICAgICAgICAgIHwgTVBMUyAgICAgICAgICAgICAgICAgICAgfDwvcHJlPg0KPHBy ZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMzM3B4OyBtYXJn aW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgYnJlYWstYmVmb3JlOiBwYWdlOyI+ICAg ICAgJiM0MzstLS0tLS0mIzQzOy0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzs8L3ByZT4NCjxiciBjbGFzcz0iZ21haWwtQXBw bGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SXMgdGhhdCB3 aGF0IHlvdSBoYWQgaW4gbWluZD8gSWYgbm90LCBJJ20gb3BlbiB0byBvdGhlciBzdWdnZXN0aW9u cy48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+SWYgeW91IHRoaW5rIGl0IGhlbHBzLCB0 aGlzIHdvdWxkIGJlIGEgZ29vZCBhZGRpdGlvbi48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJs dHIiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxkaXYg ZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBjbGFz cz0iIj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjogMHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHg7IGJvcmRl ci1sZWZ0LXN0eWxlOiBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0 KTsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4NCjxiciBjbGFzcz0iIj4NCiZndDtGcm9tIGFuIE9wZXJh dGlvbmFsIHN0YW5kcG9pbnQsIHRoZSBkb2N1bWVudCBzZWVtcyBsYXJnZWx5IGFwcHJvcHJpYXRl IGluIHRlcm1zPGJyIGNsYXNzPSIiPg0Kb2YgZGF0YXBsYW5lIGNvbnNpZGVyYXRpb25zLiBTb21l IGtleSBjb25zaWRlcmF0aW9ucyBhcmUgZXhwbGljaXRseSBvdXQgb2Y8YnIgY2xhc3M9IiI+DQpz Y29wZTo8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7VGhlIG1ldGhvZCB1c2VkIGJ5IHRoZSBk b3duc3RyZWFtIHJlY2VpdmluZyBub2RlIHRvIGFkdmVydGlzZSBTRkY8YnIgY2xhc3M9IiI+DQom bmJzcDsgJm5ic3A7TGFiZWxzIHRvIHRoZSB1cHN0cmVhbSBzZW5kaW5nIG5vZGUgaXMgb3V0IG9m IHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhp cyByZWFsbHkgc2VlbXMgdG8gbWVhbiB0aGF0LCB3aXRoIHRoZSBzaW1wbGUgZGVmaW5pdGlvbiBp biB0aGlzPGJyIGNsYXNzPSIiPg0KSW5mb3JtYXRpb25hbCBkb2N1bWVudCwgaW50ZXJvcGVyYWJs ZSBpbXBsZW1lbnRhdGlvbnMgY2Fubm90IHlldCBleGlzdC4gSWY8YnIgY2xhc3M9IiI+DQp0aGVy ZSBpcyBubyBtZWNoYW5pc20gdG8gYWR2ZXJ0aXNlIHRoZSBTRkYgTGFiZWwgb3IgdG8gbWFuYWdl IHRoZSBzZW1hbnRpY3Mgb2Y8YnIgY2xhc3M9IiI+DQp0aGlzIHBhcnRpY3VsYXIgbGFiZWwsIGhv dyB3aWxsIGl0IGtub3c/IFN0YXRpYyBjb25maWd1cmF0aW9uLCB3aGljaCBpcyBub3Q8YnIgY2xh c3M9IiI+DQpjb3ZlcmVkIGFueXdheSwgaXMgbm90IGluIG15IGh1bWJsZSBvcGluaW9uIGEgbWFu YWdlYWJsZSBzY2FsYWJsZSBhcHByb2FjaC48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BY3R1YWxs eSwgd2hpbGUgaXQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudCwgaXQgaXMg d2l0aGluIHRoZSBzY29wZSBvZiZuYnNwO2RyYWZ0LWlldGYtYmVzcy1uc2gtYmdwLWNvbnRyb2wt cGxhbmUsIGFuZCB0ZXh0IGlzIGJlaW5nIGFkZGVkIHRvIHRoZSBuZXh0IHJldmlzaW9uIG9mIHRo YXQgZHJhZnQgdG8gc2hvdyBob3cgaXQgY2FuIGJlIHVzZWQgdG8gc2lnbmFsIHRoZSBlbmNhcHN1 bGF0aW9uIGRlZmluZWQNCiBoZXJlLiBUaGlzIHdhcyB3b3JrZWQgb3V0IGFmdGVyIHRoaXMgZHJh ZnQgd2FzIGZvcndhcmRlZCB0byB0aGUgSUVTRywgYnV0IHdlIGNhbiBub3cgYWRkIGEgcmVmZXJl bmNlIHRvIHRoYXQgZHJhZnQgc2VlaW5nIGFzIHdlJ2xsIGJlIGRvaW5nIGEgcG9zdC1sYXN0LWNh bGwgdXBkYXRlLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5JIHRoaW5rIHRoYXQgd2ls bCBoZWxwLCBhcyBhbiBJbmZvcm1hdGl2ZSDigJxvbmUgZW1ib2RpbWVudOKAnSB0eXBlIG9mIGxp bmsuPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7PC9kaXY+DQo8YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4 OyBib3JkZXItbGVmdC13aWR0aDogMXB4OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IGJvcmRl ci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IHBhZGRpbmctbGVmdDogMWV4OyI+DQo8 YnIgY2xhc3M9IiI+DQpUaXRsZTogTVBMUyBFbmNhcHN1bGF0aW9uIEZvciBUaGUgU0ZDIE5TSDxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClJGQyA4MzAwIG1ha2VzIGFuIGV4cGxpY2l0IGRp c3RpbmN0aW9uIGJldHdlZW4gdGhlIHRlcm1zICdlbmNhcHN1bGF0aW9uJyBhbmQ8YnIgY2xhc3M9 IiI+DQondHJhbnNwb3J0IGVuY2Fwc3VsYXRpb24nIChzZWUgZS5nLiwgRmlndXJlIDEsIFNlY3Rp b24gMS41IDUuLCBhbmQgU2VjdGlvbiA0IG9mPGJyIGNsYXNzPSIiPg0KUkZDIDgzMDApLjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkl0IHNlZW1zIHRvIG1lIHRoYXQgdGhpcyBpcyB0aGUg JnF1b3Q7TVBMUyBUcmFuc3BvcnQgRW5jYXBzdWxhdGlvbiBmb3IgdGhlIFNGQyBOU0gmcXVvdDs8 YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MsIHdlJ2xsIGZpeCB0aGF0LjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4mbmJzcDs8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNz PSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1s ZWZ0LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgYm9yZGVyLWxlZnQtY29s b3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4NCjxiciBjbGFzcz0i Ij4NCjIuJm5ic3A7IE1QTFMgRW5jYXBzdWxhdGlvbiBVc2luZyBhbiBTRkYgTGFiZWw8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTaW1pbGFybHksICZxdW90OzIuIE1QTFMgVHJhbnNwb3J0 IEVuY2Fwc3VsYXRpb24gVXNpbmcgYW4gU0ZGIExhYmVsJnF1b3Q7PGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO1RoZSBlbmNhcHN1bGF0aW9uIGlzIGEgc3RhbmRhcmQg TVBMUyBsYWJlbCBzdGFjayBbUkZDMzAzMl0gd2l0aCBhbjxiciBjbGFzcz0iIj4NCiZuYnNwOyAm bmJzcDtTRkYgTGFiZWwgYXQgdGhlIGJvdHRvbSBvZiB0aGUgc3RhY2ssIGZvbGxvd2VkIGJ5IGEg TlNIIGFzIGRlZmluZWQgYnk8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7W1JGQzgzMDBdIGFu ZCB0aGUgTlNIIHBheWxvYWQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSW5zdGVhZGYg b2YgJnF1b3Q7TlNIIHBheWxvYWQmcXVvdDsgSSB0aGluayAmcXVvdDtvcmlnbmFsIHBhY2tldCZx dW90OyBpcyBtZWFudC48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5SRkMgODMwMCB1c2VzIGJvdGgg JnF1b3Q7cGF5bG9hZCZxdW90OyBhbmQgJnF1b3Q7b3JpZ2luYWwgcGFja2V0L2ZyYW1lJnF1b3Q7 LCBidXQgdGhlIGxhdHRlciBtb3JlIHRoYW4gdGhlIGZvcm1lci4gU28gd2UgY2FuIGNoYW5nZSAm cXVvdDtwYXlsb2FkJnF1b3Q7IHRvICZxdW90O29yaWdpbmFsIHBhY2tldC9mcmFtZSZxdW90Oy48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13 aWR0aDogMXB4OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOiBy Z2IoMjA0LCAyMDQsIDIwNCk7IHBhZGRpbmctbGVmdDogMWV4OyI+DQo8YnIgY2xhc3M9IiI+DQpB bHNvLCB0aGlzIGVuY2Fwc3VsYXRpb24gaXMgVW5kZXJkZWZpbmVkOiBXaGF0IGlzIHRoZSB2YWx1 ZSBvZiBUVEw/IFRDPzxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkndmUgYmVlbiBsb29raW5nIGJh Y2sgYXQgb3RoZXIgcmVsYXRlZCBSRkNzIChzdWNoIGFzIFBXIGFuZCBJUCBWUE4gbGFiZWwgZGVm aW5pdGlvbnMpIGFuZCB0aGV5J3JlIGFsc28gbW9zdGx5IHNpbGVudCBvbiB0aGVzZSB2YWx1ZXMu IEkgZGlkIGZpbmQgdGhlIGZvbGxvd2luZyBpbiBSRkMgNjA3Mzo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHByZSBjbGFzcz0iZ21h aWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMzM3B4OyBtYXJnaW4tdG9wOiAwcHg7 IG1hcmdpbi1ib3R0b206IDBweDsgYnJlYWstYmVmb3JlOiBwYWdlOyI+ICAgVGhlIHNldHRpbmcg b2YgdGhlIFRUTCBvZiB0aGUgUFcgTVBMUw0KICAgbGFiZWwgaXMgYSBtYXR0ZXIgb2YgbG9jYWwg cG9saWN5IG9uIHRoZSBvcmlnaW5hdGluZyBQRSwgYnV0IFNIT1VMRA0KICAgYmUgc2V0IHRvIDI1 NS48L3ByZT4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+UmVnYXJkaW5nIHRoZSBUQywgd2UgY2FuIGZvbGxvdyB0aGUgZXhhbXBsZSBv ZiBSRkMgNjM5MTo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6 ZTogMTMuMzMzM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgYnJlYWst YmVmb3JlOiBwYWdlOyI+ICAgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBkZWZpbmUgYSB1c2UgZm9y IHRoZSBUcmFmZmljIENsYXNzIChUQykgZmllbGQNCiAgIFs8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNTQ2MiIgdGl0bGU9IiZxdW90O011bHRpcHJvdG9jb2wgTGFiZWwg U3dpdGNoaW5nIChNUExTKSBMYWJlbCBTdGFjayBFbnRyeTogJnF1b3Q7IiBjbGFzcz0iIj5SRkM1 NDYyPC9hPl0gKGZvcm1lcmx5IGtub3duIGFzIHRoZSBFeHBlcmltZW50YWwgVXNlIChFWFApIGJp dHMNCiAgIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzAzMiIgdGl0 bGU9IiZxdW90O01QTFMgTGFiZWwgU3RhY2sgRW5jb2RpbmcmcXVvdDsiIGNsYXNzPSIiPlJGQzMw MzI8L2E+XSkgaW4gdGhlIGZsb3cgbGFiZWwuICBGdXR1cmUgZG9jdW1lbnRzIG1heSBkZWZpbmUg YSB1c2UgZm9yDQogICB0aGVzZSBiaXRzOyB0aGVyZWZvcmUsIGltcGxlbWVudGF0aW9ucyBjb25m b3JtaW5nIHRvIHRoaXMNCiAgIHNwZWNpZmljYXRpb24gTVVTVCBzZXQgdGhlIFRDIGZpZWxkIHRv IHplcm8gYXQgdGhlIGluZ3Jlc3MgYW5kIE1VU1QNCiAgIGlnbm9yZSB0aGVtIGF0IHRoZSBlZ3Jl c3MuDQo8L3ByZT4NCjxiciBjbGFzcz0iZ21haWwtQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RG8geW91IGhhdmUgYW55IGFsdGVybmF0aXZlIHN1Z2dl c3Rpb25zPzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5UaGVzZSB0d28gYXBwcm9hY2hl cyBzb3VuZHMgZ29vZCB0byBtZS4gQW5kIEFjayB0byB0aGUgb3RoZXIgcHJldmlvdXMgcmVzcG9u c2VzLjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9ImNhcmV0LWNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVj b3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPGJsb2Nr cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCAwLjhl eDsgYm9yZGVyLWxlZnQtd2lkdGg6IDFweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyBib3Jk ZXItbGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0LCAyMDQpOyBwYWRkaW5nLWxlZnQ6IDFleDsiPg0K PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO011Y2ggbGlrZSBhIHBzZXVkb3dpcmUgbGFiZWws IGFuIFNGRiBMYWJlbCBpcyBhbGxvY2F0ZWQgYnkgdGhlPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZu YnNwO2Rvd25zdHJlYW0gcmVjZWl2ZXIgb2YgdGhlIE5TSCBmcm9tIGl0cyBwZXItcGxhdGZvcm0g bGFiZWwgc3BhY2UuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQSBQVyBMYWJlbCBpcyBt b3JlIHJlc3RyaWN0aXZlLiBSRkMgODA3NyBzYXlzIGl0IE1VU1QgYmUgYWxsb2NhdGVkIGFzPGJy IGNsYXNzPSIiPg0KcGVyLXBsYXRmb3JtOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZu YnNwOyAmbmJzcDtlZ3Jlc3MgTFNSIG9ubHkuJm5ic3A7IE5vdGUgdGhhdCB0aGUgUFcgbGFiZWwg bXVzdCBhbHdheXMgYmUgYXQgdGhlIGJvdHRvbTxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtv ZiB0aGUgcGFja2V0J3MgbGFiZWwgc3RhY2ssIGFuZCBsYWJlbHMgTVVTVCBiZSBhbGxvY2F0ZWQg ZnJvbSB0aGU8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7cGVyLXBsYXRmb3JtIGxhYmVsIHNw YWNlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCklzIHRoaXMgdGhlIGNhc2UgZm9yIHRo ZSBTRkYgTGFiZWwgYXMgd2VsbD8gSWYgc28sIHdoYXQgaXMgdGhlIGltcGxpY2F0aW9uIG9mPGJy IGNsYXNzPSIiPg0KdGhlIE1VU1Q/IElmIG5vdCwgd2h5IGlzIGl0IGRpZmZlcmVudCB0aGFuIG90 aGVyIGVxdWl2YWxlbnQgc2ltaWxhciBsYWJlbHM/PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2Ug Y2FuIGNoYW5nZSB0aGUgdGV4dCB0bzo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwO011Y2ggbGlrZSBhIHBzZXVkb3dpcmUgbGFi ZWwsIGFuIFNGRiBMYWJlbCBNVVNUIGJlIGFsbG9jYXRlZCBieSB0aGUgZG93bnN0cmVhbSByZWNl aXZlciBvZiB0aGUgTlNIIGZyb20gaXRzIHBlci1wbGF0Zm9ybSBsYWJlbCBzcGFjZSwgc2luY2Ug dGhlIG1lYW5pbmcgb2YgdGhlIGxhYmVsIGlzIGlkZW50aWNhbCBpbmRlcGVuZGVudCBvZiB3aGlj aCBpbmNvbWluZyBpbnRlcmZhY2UgaXQgaXMgcmVjZWl2ZWQgW1JGQzMwMzFdLjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+ VGhhdOKAmXMgYSBncmVhdCBpbXByb3ZlbWVudC48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJs dHIiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxkaXYg ZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCAwLjhleDsg Ym9yZGVyLWxlZnQtd2lkdGg6IDFweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyBib3JkZXIt bGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0LCAyMDQpOyBwYWRkaW5nLWxlZnQ6IDFleDsiPg0KPGJy IGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOzIuJm5ic3A7IFB1c2ggdGhlIFNGRiBMYWJlbCB0byBp ZGVudGlmeSB0aGUgZGVzaXJlZCBTRkYgaW4gdGhlIHJlY2VpdmluZzxiciBjbGFzcz0iIj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO01QTFMgbm9kZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpUVEwgdmFsdWU/IDE/IDI/IDI1NSBmb3IgR1RTTT8gR1RTTSBSRkMgNTA4MiBjb3Vs ZCBiZSB1c2VkIGhlcmUuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QXMgSSBub3RlZCBhYm92ZSwg MjU1LCBhbHRob3VnaCBJIHVzZWQgUkZDIDYwNzMgYXMgbXkgc291cmNlIHJhdGhlciB0aGFuIDUw ODIuIFdlJ2xsIGFkZCB0aGF0IGhlcmUgYXMgd2VsbC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlNvdW5kcyBnb29kLjwv ZGl2Pg0KPGRpdj5UaGVzZSBwcm90b2NvbHMgdXNlIDUwODIgaW4gb25lIGZvcm0gb3IgYW5vdGhl cjombmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9yZmM1MDgy L3JlZmVyZW5jZWRieS8iIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L3JmYzUwODIvcmVmZXJlbmNlZGJ5LzwvYT48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIi IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxkaXYgZGly PSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUg Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCAwLjhleDsgYm9y ZGVyLWxlZnQtd2lkdGg6IDFweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyBib3JkZXItbGVm dC1jb2xvcjogcmdiKDIwNCwgMjA0LCAyMDQpOyBwYWRkaW5nLWxlZnQ6IDFleDsiPg0KPGJyIGNs YXNzPSIiPg0KNC4mbmJzcDsgT3BlcmF0aW9ucywgQWRtaW5pc3RyYXRpb24sIGFuZCBNYWludGVu YW5jZSAoT0FNKSBDb25zaWRlcmF0aW9uczxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZu YnNwOyAmbmJzcDtPQU0gYXQgdGhlIFNGQyBMYXllciBpcyBoYW5kbGVkIGJ5IFNGQy1kZWZpbmVk IG1lY2hhbmlzbXMgW1JGQzgzMDBdLjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtIb3dldmVy LCBPQU0gbWF5IGJlIHJlcXVpcmVkIGF0IHRoZSBNUExTIHRyYW5zcG9ydCBsYXllci4mbmJzcDsg SWYgc28sPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO3RoZW4gc3RhbmRhcmQgTVBMUy1sYXll ciBPQU0gbWVjaGFuaXNtcyBzdWNoIGFzIHRoZSBHZW5lcmljPGJyIGNsYXNzPSIiPg0KJm5ic3A7 ICZuYnNwO0Fzc29jaWF0ZWQgQ2hhbm5lbCBbUkZDNTU4Nl0gbGFiZWwgbWF5IGJlIHVzZWQuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUkZDIDU1ODYgaXMgX25vdF8gYW4gT0FNIG1lY2hh bmlzbS4gSXQgaXMgYW4gYXNzb2NpYXRlZCBjaGFubmVsIGNyZWF0aW9uPGJyIGNsYXNzPSIiPg0K bWVjaGFuaXNtLCBvdmVyIHdoaWNoIE9BTSBjb3VsZCBiZSBjYXJyaWVkLjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NClRodXMsIHdoYXQgdHJhZGl0aW9uYWwgTVBMUyBPQU0gY2FuIGJlIGNh cnJpZWQgaGVyZT8gVGhpbmdzIGxpa2UgUkZDIDQzNzkgLyBSRkM8YnIgY2xhc3M9IiI+DQo4MDI5 IHdvdWxkIG5lZWQgdGhlIGRlZmluaXRpb24gb2YgYW4gU0ZGIExhYmVsIEZFQyAod2hpY2ggZG9l cyBub3QgZXhpc3QpLjxiciBjbGFzcz0iIj4NCldoaWNoIG90aGVyIG9uZT8gSVAvSUNNUCBzZWVt cyBvZiB2ZXJ5IGxpbWl0ZWQgdmFsdWUuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhdCdzIGEg Z29vZCBwb2ludCBhYm91dCBSRkMgNTU4Ni4gVGhlIGludGVudGlvbiBpcyB0aGF0IHRoZSBNUExT IE9BTSB3b3VsZCBiZSBhdCB0aGUgdHJhbnNwb3J0IGxhYmVsIGxheWVyIGFib3ZlIHRoZSBTRkYg bGFiZWwsIHNvIG1vc3QgYW55IE1QTFMtbGF5ZXIgT0FNIHdvdWxkIGJlIGFwcGxpY2FibGUuIFNv IGhvdyBhYm91dCByZXdvcmRpbmcgdG8gbWFrZSB0aGF0IG1vcmUgY2xlYXI6PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5PQU0gYXQgdGhl IFNGQyBMYXllciBpcyBoYW5kbGVkIGJ5IFNGQy1kZWZpbmVkIG1lY2hhbmlzbXMgW1JGQzgzMDBd LiBIb3dldmVyLCBPQU0gbWF5IGJlIHJlcXVpcmVkIGF0IHRoZSBNUExTIHRyYW5zcG9ydCBsYXll ci4mbmJzcDsgSWYgc28sIHRoZW4gc3RhbmRhcmQgTVBMUy1sYXllciBPQU0gbWVjaGFuaXNtcyBt YXkgYmUgdXNlZCBhdCB0aGUgdHJhbnNwb3J0IGxhYmVsIGxheWVyICh0aGUgbGFiZWxzIGFib3Zl IHRoZSBTRkYgbGFiZWwpLjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K TG9va3MgZ29vZCB0byBtZSwgdGhhbmsgeW91LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRp cj0ibHRyIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8 ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYg Y2xhc3M9IiI+Jm5ic3A7PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0i Z21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVm dC13aWR0aDogMXB4OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IGJvcmRlci1sZWZ0LWNvbG9y OiByZ2IoMjA0LCAyMDQsIDIwNCk7IHBhZGRpbmctbGVmdDogMWV4OyI+DQo8YnIgY2xhc3M9IiI+ DQo2LiZuYnNwOyBTZWN1cml0eSBDb25zaWRlcmF0aW9uczxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCkhhdmUgeW91IGNvbnNpZGVyZWQgdGhlIHVzZSBvZiBHVFNNPzxiciBjbGFzcz0iIj4N CjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPk5vLCB3ZSBoYWRuJ3QuIENhbiB5b3UgcG9pbnQgbWUgdG8gYW55IGV4YW1wbGVz IG9mIEdUU00gYmVpbmcgdXNlZCBpbiBhbiBNUExTIG9yIFBXIGNvbnRleHQ/PC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQpZZXMsIHNlZSBhYm92ZS48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBk aXI9Imx0ciIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0K PGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2 IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBz dHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6IDFweDsg Ym9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0 LCAyMDQpOyBwYWRkaW5nLWxlZnQ6IDFleDsiPg0KPGJyIGNsYXNzPSIiPg0KOC4mbmJzcDsgUmVm ZXJlbmNlczxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtbUkZDNzY2 NV0mbmJzcDsgSGFscGVybiwgSi4sIEVkLiBhbmQgQy4gUGlnbmF0YXJvLCBFZC4sICZxdW90O1Nl cnZpY2UgRnVuY3Rpb248YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgQ2hhaW5pbmcgKFNGQykgQXJjaGl0ZWN0dXJlJnF1b3Q7LCBS RkMgNzY2NSw8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgRE9JIDEwLjE3NDg3L1JGQzc2NjUsIE9jdG9iZXIgMjAxNSw8YnIgY2xh c3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzY2NSIgcmVs PSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93d3cucmZjLWVk aXRvci5vcmcvaW5mby9yZmM3NjY1PC9hPiZndDsuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KU0hvdWxkIFJGQyA3NjY1IGJlIE5vcm1hdGl2ZT8gSXQgZGVmaW5lcyB0aGUgJnF1b3Q7U0ZG JnF1b3Q7IHdoaWNoIGlzIHF1aXRlIGNlbnRyYWwgdG88YnIgY2xhc3M9IiI+DQp1bmRlcnN0YW5k aW5nIHRoaXMgZG9jdW1lbnQuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+R29vZCBwb2ludC4gSXQg d2FzIHRoZXJlIGJlY2F1c2UgNzY2NSBpcyBhbiBJbmZvcm1hdGlvbmFsIFJGQywgYnV0IFJGQyA4 MDY3IGRvZXMgYWxsb3cgbm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gaW5mb3JtYXRpb25hbCBSRkNz LCBzbyBJJ2xsIG1vdmUgaXQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KVGhhbmsgeW91LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0i bHRyIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8ZGl2 IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxibG9ja3F1 b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggMC44ZXg7 IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgYm9yZGVy LWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4NCjxi ciBjbGFzcz0iIj4NCk90aGVyIE5pdHMgYW5kIEVkaXRvcmlhbHM6PGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO1NGRiBMYWJlbHMgYXJlIHNpbWlsYXIgdG8gb3RoZXIg c2VydmljZSBsYWJlbHMgYXQgdGhlIGJvdHRvbSBvZiBhbjxiciBjbGFzcz0iIj4NCiZuYnNwOyAm bmJzcDtNUExTIGxhYmVsIHN0YWNrIHRoYXQgZGVub3RlIHRoZSBjb250ZW50cyBvZiB0aGUgTVBM UyBwYXlsb2FkIGJlaW5nPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO290aGVyIHRoYW4gSVAs IHN1Y2ggYXMgYSBsYXllciAyIHBzZXVkb3dpcmUsIGFuIElQIHBhY2tldCB0aGF0IGlzPGJyIGNs YXNzPSIiPg0KJm5ic3A7ICZuYnNwO3JvdXRlZCBpbiBhIFZQTiBjb250ZXh0IHdpdGggYSBwcml2 YXRlIGFkZHJlc3MsIG9yIGFuIEV0aGVybmV0PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO3Zp cnR1YWwgcHJpdmF0ZSB3aXJlIHNlcnZpY2UuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K VGhpcyBzYXlzICZxdW90O2JlaW5nIG90aGVyIHRoYW4gSVAsIHN1Y2ggYXMgSVAmcXVvdDssIHdo aWNoIHNlZW1zIHRvIGJlPGJyIGNsYXNzPSIiPg0Kc2VsZi1jb250cmFkaWN0b3J5IDotKTxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+Oi0p PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5Ib3cgYWJvdXQgd2UgY2hhbmdlICZxdW90O290aGVyIHRoYW4gSVAsJnF1b3Q7IHRvICZxdW90 O290aGVyIHRoYW4gYSBub3JtYWxseSByb3V0ZWQgSVAgcGFja2V04oCdLDwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KVGhhdCB3b3VsZCBkaXNhbWJpZ3VhdGUgaXQuPC9kaXY+DQo8ZGl2PjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MgYWdhaW4uPC9kaXY+DQo8ZGl2PjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdj5UbyBtZSwgdGhlIGNvbnRyb2wgcGxhbmUgLyBhZHZlcnRpc2Vt ZW50IHdhcyB0aGUgbW9zdCBpbXBvcnRhbnQgb3BlcmF0aW9uYWxseS1yZWxldmFudCBjb21tZW50 LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0K PGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+Q2FybG9zLjwvZGl2Pg0KPGRpdj48YnIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGRpcj0ibHRyIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIg Y2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PlRoYW5rcyBhZ2Fpbiw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QW5keTwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6A97863ADD904D629607569386F5F850ciscocom_-- From nobody Fri Feb 22 00:16: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 B3FD5130E5B; Fri, 22 Feb 2019 00:16:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Nicolai Leymann To: X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Cc: mpls@ietf.org, iesg-secretary@ietf.org, mpls-chairs@ietf.org, n.leymann@telekom.de, Nicolai Leymann Message-ID: <155082338672.5530.13242949849431837123.idtracker@ietfa.amsl.com> Date: Fri, 22 Feb 2019 00:16:26 -0800 Archived-At: Subject: [mpls] Publication has been requested for draft-ietf-mpls-ri-rsvp-frr-05 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, 22 Feb 2019 08:16:27 -0000 Nicolai Leymann has requested publication of draft-ietf-mpls-ri-rsvp-frr-05 as Proposed Standard on behalf of the MPLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-mpls-ri-rsvp-frr/ From nobody Fri Feb 22 06:28:19 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 7C515128B14; Fri, 22 Feb 2019 06:27:58 -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, 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 wudulC6S0vZ5; Fri, 22 Feb 2019 06:27:54 -0800 (PST) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 C8AD91200D7; Fri, 22 Feb 2019 06:27:53 -0800 (PST) Received: by mail-qk1-x72a.google.com with SMTP id m9so1223924qkl.4; Fri, 22 Feb 2019 06:27:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MsL45pVdD5eFTzCxcEpxkHcA5BN9oOg/mLDJUyyc8T8=; b=rEFwOfeu3/4X2a4adw4l38DdvuLeGiB9UNmPadmIQO383H9eePoXAnkSV3nCfkFJi4 /z7t7OEEg6h8KlpBUnaYugWNKgvS2YUfgwutceMrlh/Yi6urAfMOFVFYR6d5GbfgBIz0 r6xu6CzEui8sD2B/oScstH7R7/Yqva/TawNH6Eb5tmfbKyOzfYh4bP7hEMa+ZEDWBnsM T9idE0HTpQDzZjTJGc91T/H5CXMI85jMT5uFIZYzDf/luppde+ETOzgsNwcRGXUttwgh w2m6sfTyr2GTlvO1EbTXCMUeUGc++a0X2wfNHkgaLIWBTjUTo7o6yNo1FHm7n6GnbdRq SPCA== 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=MsL45pVdD5eFTzCxcEpxkHcA5BN9oOg/mLDJUyyc8T8=; b=lPMx5BzVQ9S7HHpgbelJJZ6f7HOokZTMRdnpuxUYhTQEt+7mPSPttx3fQ/Dp8XDzS2 LW5GWVueAYuT9T55ANJ5NswB+kYD1401bumrVoyqtrWKOnQ/zHciEx7zfZbfaWvK75uI Zrd3BENQBT4Zf6S/G8A6lakgmlVvIdI2iQQ/Z1ZYjAVw/8GJcAWJRLgQU3e5sXfNDXL+ bVQqJQ96EpT+Lrl8FdKXaOmwQ8lxvAJpzqVmVIie381mF5obSB4wZUNVlGWB9OMKIj1t yVB/181XzSCnN3IdybelsiEMYPPYsusM9CHWPAH/zhnhYKpNDD7kODfuKO55rikImGx/ xhMA== X-Gm-Message-State: AHQUAuazgOG3UQK933yoG+rO5fOw6eRXem8QLXI0EG/U0k22BylNQOJx kUV59MV4v4amDA86+8UEja05z1e9P6LFGtfzQus= X-Google-Smtp-Source: AHgI3IZgumz8LhNkfwkkhXtC3UKECaQvLFVFYKwjpZkBHmCelFsvlyk+VQg0UBRY61Ko912nUBPxMzUiaUYkF5xemhE= X-Received: by 2002:ae9:ec0f:: with SMTP id h15mr3300880qkg.100.1550845672682; Fri, 22 Feb 2019 06:27:52 -0800 (PST) MIME-Version: 1.0 References: <155072147698.20210.381511429964485828@ietfa.amsl.com> <6A97863A-DD90-4D62-9607-569386F5F850@cisco.com> In-Reply-To: <6A97863A-DD90-4D62-9607-569386F5F850@cisco.com> From: "Andrew G. Malis" Date: Fri, 22 Feb 2019 09:27:41 -0500 Message-ID: To: "Carlos Pignataro (cpignata)" Cc: "ops-dir@ietf.org" , mpls , "draft-ietf-mpls-sfc-encapsulation.all@ietf.org" , IETF Discussion , "sfc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006bfb4005827c65f7" Archived-At: Subject: Re: [mpls] Opsdir last call review of draft-ietf-mpls-sfc-encapsulation-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: Fri, 22 Feb 2019 14:27:59 -0000 --0000000000006bfb4005827c65f7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Carlos, Looks good on all but one point - I think I see why you're referencing GTSM, since packets at the SFC layer would generally be one hop away from each other at that layer. Is that correct? However, I really don't have sufficient experience with GTSM to craft specific text. If you think it's important enough to include, could you propose some text for me to include? Thanks again, Andy On Thu, Feb 21, 2019 at 8:41 PM Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hi, Andy, > > On Feb 21, 2019, at 1:06 PM, Andrew G. Malis wrote: > > Carlos, > > Many thanks for your review! I'm also including the SFC WG on my reply. > > > Thanks for the quick response, and for considering the comments! > > I enjoyed reading this document =E2=80=94 please see below. > > > Comments inline. > > On Wed, Feb 20, 2019 at 10:58 PM Carlos Pignataro > wrote: > >> Reviewer: Carlos Pignataro >> Review result: Has Issues >> >> Reviewer: Carlos Pignataro >> Review Result: Has Issues >> >> I have reviewed this document as part of the Operational directorate's >> ongoing effort to review all IETF documents being processed by the IESG. >> These >> comments were written with the intent of improving the operational >> aspects of >> the IETF drafts. Comments that are not addressed in last call may be >> included >> in AD reviews during the IESG review. Document editors and WG chairs >> should >> treat these comments just like any other last call comments. >> >> This document is highly readable, includes very clear textual >> descriptions, and >> is very well organized. Easy to read in its simplicity. However, it woul= d >> benefit from a more explicit connection to the transport encap mechanics >> from >> RFC 8300 (e.g., S4, S6.1). Specifically, I'd recommend adding a Figure o= r >> an >> SFF NSH Mapping Table example, to depict and/or exemplify the SFF >> function. >> > > I'm trying to envision what would make a good figure here. We could add a= n > additional line to Table 1 of RFC 8300 and reference that table: > > +------+------+---------------------+-------------------------+ > > | SPI | SI | Next Hop(s) | Transport Encapsulation | > +------+------+---------------------+-------------------------+ > > | 25 | 220 | Label 5467 | MPLS | > > +------+------+---------------------+-------------------------+ > > > Is that what you had in mind? If not, I'm open to other suggestions. > > > If you think it helps, this would be a good addition. > > > >> >> >From an Operational standpoint, the document seems largely appropriate >> in terms >> of dataplane considerations. Some key considerations are explicitly out = of >> scope: >> The method used by the downstream receiving node to advertise SFF >> Labels to the upstream sending node is out of scope of this document. >> >> This really seems to mean that, with the simple definition in this >> Informational document, interoperable implementations cannot yet exist. = If >> there is no mechanism to advertise the SFF Label or to manage the >> semantics of >> this particular label, how will it know? Static configuration, which is >> not >> covered anyway, is not in my humble opinion a manageable scalable >> approach. >> > > Actually, while it is outside the scope of this document, it is within th= e > scope of draft-ietf-bess-nsh-bgp-control-plane, and text is being added t= o > the next revision of that draft to show how it can be used to signal the > encapsulation defined here. This was worked out after this draft was > forwarded to the IESG, but we can now add a reference to that draft seein= g > as we'll be doing a post-last-call update. > > > I think that will help, as an Informative =E2=80=9Cone embodiment=E2=80= =9D type of link. > > > >> >> Title: MPLS Encapsulation For The SFC NSH >> >> RFC 8300 makes an explicit distinction between the terms 'encapsulation' >> and >> 'transport encapsulation' (see e.g., Figure 1, Section 1.5 5., and >> Section 4 of >> RFC 8300). >> >> It seems to me that this is the "MPLS Transport Encapsulation for the SF= C >> NSH" >> > > Thanks, we'll fix that. > > >> >> 2. MPLS Encapsulation Using an SFF Label >> >> Similarly, "2. MPLS Transport Encapsulation Using an SFF Label" >> >> The encapsulation is a standard MPLS label stack [RFC3032] with an >> SFF Label at the bottom of the stack, followed by a NSH as defined by >> [RFC8300] and the NSH payload. >> >> Insteadf of "NSH payload" I think "orignal packet" is meant. >> > > RFC 8300 uses both "payload" and "original packet/frame", but the latter > more than the former. So we can change "payload" to "original packet/fram= e". > > >> >> Also, this encapsulation is Underdefined: What is the value of TTL? TC? >> > > I've been looking back at other related RFCs (such as PW and IP VPN label > definitions) and they're also mostly silent on these values. I did find t= he > following in RFC 6073: > > The setting of the TTL of the PW MPLS > label is a matter of local policy on the originating PE, but SHOULD > be set to 255. > > > Regarding the TC, we can follow the example of RFC 6391: > > This document does not define a use for the Traffic Class (TC) field > [RFC5462 ] (formerly known as the= Experimental Use (EXP) bits > [RFC3032 ]) in the flow label. F= uture documents may define a use for > these bits; therefore, implementations conforming to this > specification MUST set the TC field to zero at the ingress and MUST > ignore them at the egress. > > > Do you have any alternative suggestions? > > > These two approaches sounds good to me. And Ack to the other previous > responses. > > > >> >> Much like a pseudowire label, an SFF Label is allocated by the >> downstream receiver of the NSH from its per-platform label space. >> >> A PW Label is more restrictive. RFC 8077 says it MUST be allocated as >> per-platform: >> >> egress LSR only. Note that the PW label must always be at the bottom >> of the packet's label stack, and labels MUST be allocated from the >> per-platform label space. >> >> Is this the case for the SFF Label as well? If so, what is the >> implication of >> the MUST? If not, why is it different than other equivalent similar >> labels? >> > > We can change the text to: > > Much like a pseudowire label, an SFF Label MUST be allocated by the > downstream receiver of the NSH from its per-platform label space, since t= he > meaning of the label is identical independent of which incoming interface > it is received [RFC3031]. > > > That=E2=80=99s a great improvement. > > >> 2. Push the SFF Label to identify the desired SFF in the receiving >> MPLS node. >> >> TTL value? 1? 2? 255 for GTSM? GTSM RFC 5082 could be used here. >> > > As I noted above, 255, although I used RFC 6073 as my source rather than > 5082. We'll add that here as well. > > > Sounds good. > These protocols use 5082 in one form or another: > https://datatracker.ietf.org/doc/rfc5082/referencedby/ > > >> 4. Operations, Administration, and Maintenance (OAM) Considerations >> >> OAM at the SFC Layer is handled by SFC-defined mechanisms [RFC8300]. >> However, OAM may be required at the MPLS transport layer. If so, >> then standard MPLS-layer OAM mechanisms such as the Generic >> Associated Channel [RFC5586] label may be used. >> >> RFC 5586 is _not_ an OAM mechanism. It is an associated channel creation >> mechanism, over which OAM could be carried. >> >> Thus, what traditional MPLS OAM can be carried here? Things like RFC 437= 9 >> / RFC >> 8029 would need the definition of an SFF Label FEC (which does not exist= ). >> Which other one? IP/ICMP seems of very limited value. >> > > That's a good point about RFC 5586. The intention is that the MPLS OAM > would be at the transport label layer above the SFF label, so most any > MPLS-layer OAM would be applicable. So how about rewording to make that > more clear: > > OAM at the SFC Layer is handled by SFC-defined mechanisms [RFC8300]. > However, OAM may be required at the MPLS transport layer. If so, then > standard MPLS-layer OAM mechanisms may be used at the transport label lay= er > (the labels above the SFF label). > > > Looks good to me, thank you. > > > >> >> 6. Security Considerations >> >> Have you considered the use of GTSM? >> > > No, we hadn't. Can you point me to any examples of GTSM being used in an > MPLS or PW context? > > > Yes, see above. > > > >> >> 8. References >> >> [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function >> Chaining (SFC) Architecture", RFC 7665, >> DOI 10.17487/RFC7665, October 2015, >> . >> >> SHould RFC 7665 be Normative? It defines the "SFF" which is quite centra= l >> to >> understanding this document. >> > > Good point. It was there because 7665 is an Informational RFC, but RFC > 8067 does allow normative references to informational RFCs, so I'll move = it. > > > > Thank you. > > >> Other Nits and Editorials: >> >> SFF Labels are similar to other service labels at the bottom of an >> MPLS label stack that denote the contents of the MPLS payload being >> other than IP, such as a layer 2 pseudowire, an IP packet that is >> routed in a VPN context with a private address, or an Ethernet >> virtual private wire service. >> >> This says "being other than IP, such as IP", which seems to be >> self-contradictory :-) >> >> :-) > > How about we change "other than IP," to "other than a normally routed IP > packet=E2=80=9D, > > > That would disambiguate it. > > Thanks again. > > To me, the control plane / advertisement was the most important > operationally-relevant comment. > > Thanks, > > Carlos. > > > Thanks again, > Andy > > > --0000000000006bfb4005827c65f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Carlos,

Looks good on all but one point= - I think I see why you're referencing GTSM,=C2=A0since packets at the= SFC layer would generally be one hop away from each other at that layer. I= s that correct? However, I really don't have sufficient experience with= GTSM to craft specific=C2=A0text. If you think it's important enough t= o include, could you propose some text for me to include?

Thanks again,
Andy


On Thu, Feb 21, 20= 19 at 8:41 PM Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hi, Andy,

On Feb 21, 2019, at 1:06 PM, Andrew G. Malis <agmalis@gmail.com> wrote:

Carlos,

Many thanks for your review! I'm also including the SFC WG on my r= eply.

Thanks for the quick response, and for considering the comments!

I enjoyed reading this document =E2=80=94 please see below.


Comments inline.

On Wed, Feb 20, 2019 at 10:58 PM Carl= os Pignataro <cp= ignata@cisco.com> wrote:
Reviewer: Carlos Pignataro
Review result: Has Issues

Reviewer: Carlos Pignataro
Review Result: Has Issues

I have reviewed this document as part of the Operational directorate's<= br> ongoing effort to review all IETF documents being processed by the IESG.=C2= =A0 These
comments were written with the intent of improving the operational aspects = of
the IETF drafts. Comments that are not addressed in last call may be includ= ed
in AD reviews during the IESG review.=C2=A0 Document editors and WG chairs = should
treat these comments just like any other last call comments.

This document is highly readable, includes very clear textual descriptions,= and
is very well organized. Easy to read in its simplicity. However, it would benefit from a more explicit connection to the transport encap mechanics fr= om
RFC 8300 (e.g., S4, S6.1). Specifically, I'd recommend adding a Figure = or an
SFF NSH Mapping Table example, to depict and/or exemplify the SFF function.=

I'm trying to envision what would make a good figure here. We coul= d add an additional line to Table 1 of RFC 8300 and reference that table: 

      +------=
+------+---------------------+-------------------------+
      | SPI  =
| SI   | Next Hop(s)         | Transport Encapsulation |
      +------+------+---------------------+-------------------------+
      | 25   =
| 220  | Label 5467          | MPLS                    |
      +------=
+------+---------------------+-------------------------+

Is that what you had in mind? If not, I'm open to other suggestion= s.

If you think it helps, this would be a good addition.

=C2=A0

>From an Operational standpoint, the document seems largely appropriate = in terms
of dataplane considerations. Some key considerations are explicitly out of<= br> scope:
=C2=A0 =C2=A0The method used by the downstream receiving node to advertise = SFF
=C2=A0 =C2=A0Labels to the upstream sending node is out of scope of this do= cument.

This really seems to mean that, with the simple definition in this
Informational document, interoperable implementations cannot yet exist. If<= br> there is no mechanism to advertise the SFF Label or to manage the semantics= of
this particular label, how will it know? Static configuration, which is not=
covered anyway, is not in my humble opinion a manageable scalable approach.=

Actually, while it is outside the scope of this document, it is within= the scope of=C2=A0draft-ietf-bess-nsh-bgp-control-plane, and text is being= added to the next revision of that draft to show how it can be used to sig= nal the encapsulation defined here. This was worked out after this draft was forwarded to the IESG, but = we can now add a reference to that draft seeing as we'll be doing a pos= t-last-call update.

I think that will help, as an Informative =E2=80=9Cone embodiment=E2= =80=9D type of link.

=C2=A0

Title: MPLS Encapsulation For The SFC NSH

RFC 8300 makes an explicit distinction between the terms 'encapsulation= ' and
'transport encapsulation' (see e.g., Figure 1, Section 1.5 5., and = Section 4 of
RFC 8300).

It seems to me that this is the "MPLS Transport Encapsulation for the = SFC NSH"

Thanks, we'll fix that.
=C2=A0

2.=C2=A0 MPLS Encapsulation Using an SFF Label

Similarly, "2. MPLS Transport Encapsulation Using an SFF Label"
=C2=A0 =C2=A0The encapsulation is a standard MPLS label stack [RFC3032] wit= h an
=C2=A0 =C2=A0SFF Label at the bottom of the stack, followed by a NSH as def= ined by
=C2=A0 =C2=A0[RFC8300] and the NSH payload.

Insteadf of "NSH payload" I think "orignal packet" is m= eant.

RFC 8300 uses both "payload" and "original packet/frame= ", but the latter more than the former. So we can change "payload= " to "original packet/frame".
=C2=A0

Also, this encapsulation is Underdefined: What is the value of TTL? TC?

I've been looking back at other related RFCs (such as PW and IP VP= N label definitions) and they're also mostly silent on these values. I = did find the following in RFC 6073:

   The settin=
g of the TTL of the PW MPLS
   label is a matter of local policy on the originating PE, but SHOULD
   be set to 255.

Regarding the TC, we can follow the example of RFC 6391:

   This docum=
ent does not define a use for the Traffic Class (TC) field
   [R=
FC5462] (formerly known as the Experimental Use (EXP) bits
   [RFC3032]) in the flow label.=
  Future documents may define a use for
   these bits; therefore, implementations conforming to this
   specification MUST set the TC field to zero at the ingress and MUST
   ignore them at the egress.

Do you have any alternative suggestions?

These two approaches sounds good to me. And Ack to the other previous = responses.

=C2=A0

=C2=A0 =C2=A0Much like a pseudowire label, an SFF Label is allocated by the=
=C2=A0 =C2=A0downstream receiver of the NSH from its per-platform label spa= ce.

A PW Label is more restrictive. RFC 8077 says it MUST be allocated as
per-platform:

=C2=A0 =C2=A0egress LSR only.=C2=A0 Note that the PW label must always be a= t the bottom
=C2=A0 =C2=A0of the packet's label stack, and labels MUST be allocated = from the
=C2=A0 =C2=A0per-platform label space.

Is this the case for the SFF Label as well? If so, what is the implication = of
the MUST? If not, why is it different than other equivalent similar labels?=

We can change the text to:

=C2=A0Much like a pseudowire label, an SFF Label MUST be allocated by = the downstream receiver of the NSH from its per-platform label space, since= the meaning of the label is identical independent of which incoming interf= ace it is received [RFC3031].


That=E2=80=99s a great improvement.


=C2=A0 =C2=A02.=C2=A0 Push the SFF Label to identify the desired SFF in the= receiving
=C2=A0 =C2=A0 =C2=A0 =C2=A0MPLS node.

TTL value? 1? 2? 255 for GTSM? GTSM RFC 5082 could be used here.

As I noted above, 255, although I used RFC 6073 as my source rather th= an 5082. We'll add that here as well.


Sounds good.
These protocols use 5082 in one form or another:=C2=A0https:= //datatracker.ietf.org/doc/rfc5082/referencedby/


4.=C2=A0 Operations, Administration, and Maintenance (OAM) Considerations
=C2=A0 =C2=A0OAM at the SFC Layer is handled by SFC-defined mechanisms [RFC= 8300].
=C2=A0 =C2=A0However, OAM may be required at the MPLS transport layer.=C2= =A0 If so,
=C2=A0 =C2=A0then standard MPLS-layer OAM mechanisms such as the Generic =C2=A0 =C2=A0Associated Channel [RFC5586] label may be used.

RFC 5586 is _not_ an OAM mechanism. It is an associated channel creation mechanism, over which OAM could be carried.

Thus, what traditional MPLS OAM can be carried here? Things like RFC 4379 /= RFC
8029 would need the definition of an SFF Label FEC (which does not exist).<= br> Which other one? IP/ICMP seems of very limited value.

That's a good point about RFC 5586. The intention is that the MPLS= OAM would be at the transport label layer above the SFF label, so most any= MPLS-layer OAM would be applicable. So how about rewording to make that mo= re clear:

OAM at the SFC Layer is handled by SFC-defined mechanisms [RFC8300]. H= owever, OAM may be required at the MPLS transport layer.=C2=A0 If so, then = standard MPLS-layer OAM mechanisms may be used at the transport label layer= (the labels above the SFF label).

Looks good to me, thank you.

=C2=A0

6.=C2=A0 Security Considerations

Have you considered the use of GTSM?

No, we hadn't. Can you point me to any examples of GTSM being used= in an MPLS or PW context?

Yes, see above.

=C2=A0

8.=C2=A0 References

=C2=A0 =C2=A0[RFC7665]=C2=A0 Halpern, J., Ed. and C. Pignataro, Ed., "= Service Function
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Chaining (SFC) Architectur= e", RFC 7665,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DOI 10.17487/RFC7665, Octo= ber 2015,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://= www.rfc-editor.org/info/rfc7665>.

SHould RFC 7665 be Normative? It defines the "SFF" which is quite= central to
understanding this document.

Good point. It was there because 7665 is an Informational RFC, but RFC= 8067 does allow normative references to informational RFCs, so I'll mo= ve it.
=C2=A0

Thank you.


Other Nits and Editorials:

=C2=A0 =C2=A0SFF Labels are similar to other service labels at the bottom o= f an
=C2=A0 =C2=A0MPLS label stack that denote the contents of the MPLS payload = being
=C2=A0 =C2=A0other than IP, such as a layer 2 pseudowire, an IP packet that= is
=C2=A0 =C2=A0routed in a VPN context with a private address, or an Ethernet=
=C2=A0 =C2=A0virtual private wire service.

This says "being other than IP, such as IP", which seems to be self-contradictory :-)

:-)

How about we change "other than IP," to "other than a n= ormally routed IP packet=E2=80=9D,

That would disambiguate it.

Thanks again.

To me, the control plane / advertisement was the most important operat= ionally-relevant comment.

Thanks,

Carlos.


Thanks again,
Andy

--0000000000006bfb4005827c65f7-- From nobody Fri Feb 22 07:39:58 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 15FD7130E9D for ; Fri, 22 Feb 2019 07:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=K6i+R0QS; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=ericsson.com header.b=DE20JK3T 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 ccwxQXm9i7PP for ; Fri, 22 Feb 2019 07:39:52 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8679F130E6E for ; Fri, 22 Feb 2019 07:39:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1550849989; x=1553441989; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DjR0XNOT9wk/eK8f817dCnkkb/VW2GNEBt9cU7y41aE=; b=K6i+R0QS4XTBApm7iIdvjOGxWc3gucJdaXL9JevN79r6juhIcS1R9E9GOFSUEUTP /eAdMXjiQxDF0WmUEKzIc+RSLtANMT1rdi2sWRk+pIHShivbX2oiMo2PAo50PRTr gmWFj2K6Tdrf3QfVA95TDX3cyP6TWgsYNMY9RSE5SEU=; X-AuditID: c1b4fb25-209009e000005ff7-23-5c7017c511ad Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 04.42.24567.5C7107C5; Fri, 22 Feb 2019 16:39:49 +0100 (CET) Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 22 Feb 2019 16:39:48 +0100 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 22 Feb 2019 16:39:48 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hPmzlGn+jw1nbA3vZ2gVBbXESzLbFkimt8uXFjP6M3g=; b=DE20JK3TZRTanJkcoO4xxqzfxl6E2ApD+WEys4G/rMnZID7bAb0+aIlArpNQQqTSz8yQyC+QjtxYEAoAOoo6qMIjYwTl62fNxQwFD8lvaA2pRL9htnwCH9eKr82AkujAq5LOE1CshuQKIfQyzTyw4Ra2lFSOVk9HqZZOhQx2JaY= Received: from BN6PR15MB1236.namprd15.prod.outlook.com (10.172.205.136) by BN6PR15MB1203.namprd15.prod.outlook.com (10.172.208.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.18; Fri, 22 Feb 2019 15:39:45 +0000 Received: from BN6PR15MB1236.namprd15.prod.outlook.com ([fe80::2ce1:745d:5907:30c1]) by BN6PR15MB1236.namprd15.prod.outlook.com ([fe80::2ce1:745d:5907:30c1%5]) with mapi id 15.20.1643.018; Fri, 22 Feb 2019 15:39:45 +0000 From: Joel Halpern To: "Andrew G. Malis" , "Carlos Pignataro (cpignata)" CC: "ops-dir@ietf.org" , mpls , "draft-ietf-mpls-sfc-encapsulation.all@ietf.org" , IETF Discussion , "sfc@ietf.org" Thread-Topic: [mpls] Opsdir last call review of draft-ietf-mpls-sfc-encapsulation-02 Thread-Index: AQHUyZmooeeOlrGJcEi/lzVg6owG5qXqjRuAgAB/QwCAANX3gIAAE8pQ Date: Fri, 22 Feb 2019 15:39:44 +0000 Message-ID: References: <155072147698.20210.381511429964485828@ietfa.amsl.com> <6A97863A-DD90-4D62-9607-569386F5F850@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=joel.halpern@ericsson.com; x-originating-ip: [209.255.163.147] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2d989364-92ae-43ff-1f80-08d698dbf864 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR15MB1203; x-ms-traffictypediagnostic: BN6PR15MB1203: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCTjZQUjE1TUIxMjAzOzIzOnpxSVFYeXNjWG9qSjExNkcycjZNeFRUcGx2?= =?utf-8?B?dHBTd0V5U0wzMTIrL1U3ekYxdlNXV1lQODdsUWxvOWRrYktlZVQyL3pnUW1n?= =?utf-8?B?RkhDVVAzdm1QbXR4dTRuZ1R0MTlQcGRodHk3ZzNNMWZnU0YxWUFoMlhrZ0Ro?= =?utf-8?B?TlNCc25LL0RvbnROZUNDN1FIQjNrR0MrTExhclFUZEUrKysybzJmd2ZLN2kr?= =?utf-8?B?ejBJR1RYVDk3TEF4R2t2TEpodytGYlhNWmxIR3ozS2RkMnVLMWVHMzZSWmxR?= =?utf-8?B?bkNWWllMd2JUVElQOTFWNjdqV2RJRmZ1c1BhZzZvVW1COEVSTlFVZVZKYWpF?= =?utf-8?B?Qm9wdlhFTEhzVmYvaFgxTG4xL3J1UVY0SDl4VnArdmxVWE9pZUx2Yk1Kcmsw?= =?utf-8?B?cEUwcGNjMlBTMGgzTm5rb08vRUJPUXZ6K09kYlRhb0tHWm1NbWN5M2xlZVJp?= =?utf-8?B?QXpuN1lqUWhQZXJON2FabXdqRndFQXJZQjU4VzZObzJpNjdEaVNPLzlGUnkz?= =?utf-8?B?SWp2WG5lNmlFYVkxZHhaclduOWMrL2dDVnpQbTA0cmFTUFBDMVVxK2ZPOFNR?= =?utf-8?B?Mk96ajEzY1dSRHRTRDZCMWVSVm4vWGpCL2U2aVMxNjJneEdSS1lBMlRMQ0lJ?= =?utf-8?B?VmNITHRoaXpMNmZjL1hSeTgySUlsNVBqclJFbksreGsxYm5YV3N5Y1NFRmJS?= =?utf-8?B?bTc3RHVIZFlRVG1BdUo4T0pKTTlDQk1qVjJ4L1dadkt0VG1jc0Z6TVF3WXAw?= =?utf-8?B?T3VBb3FzWTRMTUFDR0QycTV4ODRiOW4zUDJwWnVNRVIrb29kSmwrS3ZvYlp6?= =?utf-8?B?WWJveU1Rdm9FL2cwY250aExGYnBpenAxU0pXYmpJK1Z3bjQvcjJvZ1p5Witn?= =?utf-8?B?TWh5L0ZZeXM1ajdIQ1FJZjIveFhHczU4bHFYVllxK3kvaER0VzBqR0VtcVUr?= =?utf-8?B?VHNpQnRzWWU1MHhvTzY5ZnhUN3VESDZURm5JTXpJUFRHREVnK1ArbG5KdWhB?= =?utf-8?B?ZllhWnJJNXJuL2xCcmRGMXl5L01hS0U4MndNS3NHaWI5MklTSDd3YSthOThw?= =?utf-8?B?Z1I5Q3BuMWczaVQzeEw0WU1uNWFBb3dBUHE3KzVXNUNNMWpDakh0aXZubUsx?= =?utf-8?B?bGphV2MrMW1DeTNjcFkvYkpEL3RCUzc1THhhMzB4LzRIRHdIK1pPWXZRT1Fr?= =?utf-8?B?SDgwdHE0ZG9ZTFc5TUN4bjBROFdkOWdXMXcxeHF0NFZYVEE2KzRoY3RMRTEx?= =?utf-8?B?cW9kdGp5NnRxZzgzNjJTRTUvbjdlNDlSK0hvMXhUUDhmN1R3aDM1bSthRlp5?= =?utf-8?B?S050UDg2Mi9RSnZBZDhPN3BrT1p5eld5bldmc0Fsa3AvNGwzMW9lVjhwQU1L?= =?utf-8?B?YjdLRFlmckNPWGphVERMWVR0UnlYdVRvRVptYlpJSE1CSDB2SHNEVHVqUjU2?= =?utf-8?B?RzNLc0FyUGpqbjJiWFBVdE5sK1NlUmwrQzhhdDVDeE8xYTFjcWliL041RVZ0?= =?utf-8?B?TXJUc2ZyUlhJTGZ1cnRYTDljMHZIRk84b0ltby9oMDgyU1c1UlAvUTQzRDMz?= =?utf-8?B?NmJydkxmczFVYUJMTlIySkhCZUhnVFFIWkhUSTMrY0JxTU13K25GbEZvS3Vl?= =?utf-8?B?Y29BQkN4S3NVcklINXdsSjByMVJxRTR1MndUT1p0Wm4xbUdJd3RGYzZqUHFa?= =?utf-8?B?WmFFS1NmWXlNK0F1ZlZrUklITit1QWdZMjlEQ3hBNm0zazJ1bE5YTXpTZ2Ex?= =?utf-8?B?dTJsMDQ2RzVja2FjVnRIdDF0a28yaFdWdzVNRU9Cb2R0d2VlYjVCZXV5OEFV?= =?utf-8?B?ajJzNnVWMzVOVmF6eXlRTU43RVZZbmQ5Y1ErN1MyblQ5eEVqZTNEbGIzUUlr?= =?utf-8?B?T2wvT2dRUnFQQzhDdG5UWTFyWThZUGQ5enhaVzUrb3JoMW5raElmL1d6cHdj?= =?utf-8?B?aFRvWlhlOVAzTk1vYU5KU2Z4TzhEUHd6YzZWQURTbjdESGhhK1dFUGlSeUpv?= =?utf-8?Q?+dSm8g?= x-microsoft-antispam-prvs: x-forefront-prvs: 09565527D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(396003)(366004)(39860400002)(376002)(189003)(199004)(51914003)(52314003)(51444003)(790700001)(6116002)(186003)(5660300002)(8936002)(7696005)(68736007)(3846002)(53936002)(4326008)(256004)(8676002)(81156014)(14444005)(316002)(76176011)(81166006)(53546011)(6506007)(6246003)(44832011)(110136005)(229853002)(97736004)(66066001)(6436002)(74316002)(54906003)(7736002)(93886005)(71200400001)(71190400001)(106356001)(25786009)(99936001)(33656002)(105586002)(99286004)(14454004)(478600001)(26005)(486006)(102836004)(86362001)(966005)(2906002)(55016002)(606006)(446003)(6306002)(11346002)(236005)(9686003)(54896002)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR15MB1203; H:BN6PR15MB1236.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 7ryHChmRvGFs+1szWEmXNd4k9u3N86O0rWpr9Why1Z3roVVrusq7XGz0GsBLY288uKyK9RgV3Nc1vIki1dLIFizc0q5WK1VORfuS7eG1e0/vlRSlJVWCg8OuSnT4q8eSJxLoncyflFhaUjJRqcOzwsEz+Zn0k0VKGFig7a4NJJNUxqUkypS2WnbdBLNt9B0rQjxcYXbKCz9+k9ltmGVq9dyk/nH7aOUVTOHkx+XNyLBvgtmSEf6+7PcKhKNBa0yXTuiaAGb4DYc52wcICTn8hZiyZLijUaOu1sCp9vZff1VbvM8DxABk2dS+iMpluYjzGNXbMU7fSg/8kzHC19qlQfIk7BU60LBCNHGlBCDA8gP4DW7EUKR6ICeaJuQyB42CQT6lmLMRDlxfuY6pI9uzG4dwIN+SChGjK4fFC+LI+38= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0128_01D4CA9A.EBF1E560" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2d989364-92ae-43ff-1f80-08d698dbf864 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 15:39:44.9722 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR15MB1203 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA2WSfUhTURjGO/fe3V2txXFNfbP6o6kUVrNPGPRBRYQElpVZ5NBWXky0Kfda ZBCJtUrLUjPBhfODTcsyXCR+YIkri7YyS8o0S+dmTRJD6UuN1bY7Iei/3/s+z3ne8x4OQ0pz 6RAmRZPJchp1mpz2p0oPNPIrOoIzVCtd+lCl9bOFVk6MNVHKZrMRKT+Zyilln/GWSJmfYyCV jsEG8WZxVPG0SRTVrPsgjjIYJokY8qD/hiQ2LeUEy0VuOuR/9HxpF5ExpSVPGs9V09nobC+R h/wYwGuhpqRFlIf8GSl+jKCyY5AWih8I9NZRJBQGAvQ3r4g9BYULSDBd6CYFpZiAkWGHL2AI wUfbRZEnmcYKqPtqd09hGBlOhLeGRI+HxE4ETws7KY9nHt4HZVY96WEZjoNrdzsIgbfD4/O9 Xg+Fw8HuGvN6JFgFI7+bKGHYWQJ6c0toj+CHd8P11kfewwgHwU/LHS+TOBj6HOW+VWVge2Wl BQ6EEbtLJPhVkNPeJxL6oWCrLSAFXgSvyy8hgaPBUqInPIMB2xEUvTT4giLgwfNSsSAMzIOi snxfUiqUfZ3y8UIoybHSgqmehrYbw95YKWahpk6LCtBy3T+31XnfqRBB7tOXlM67dwA8K3W4 mXEL8WDqzxL8yyDfpkUzXF35hRQ4Al686RH/398ITsuAr78Yii/ZfLwOvnSMowo0uxYF8ix/ +Fjy6jUKlks5wvPpGoWGzbyH3J+y/f50eBPqHt1iRphB8jmSBlmGSipSn+CzjplRmDtnqP52 FwqhNOkaVi6TPHGlq6SSJHXWKZZLT+SOp7G8GS1gKHmw5Lc0QCXFyepMNpVlM1huRiUYv5Bs lLkucXhzUUJ8/2RP7LZl86t+hR/nJk3JDxMuR8ZUDM/dWrV+T/PPvbMetLYFHLo6PkQHBoUa VzgVylRVoVEmaVE4LQHvtkZ/02gb2/+0OIKeu3S271FnRmM7K9/vSEo4XZ5lnBtXtf8UVx3c ltdvn1rSYC4Im8hvW+oUdckmtLt2yin+qHpVBMnx6r+UhOBonAMAAA== Archived-At: Subject: Re: [mpls] Opsdir last call review of draft-ietf-mpls-sfc-encapsulation-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: Fri, 22 Feb 2019 15:39:56 -0000 ------=_NextPart_000_0128_01D4CA9A.EBF1E560 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0129_01D4CA9A.EBF1E560" ------=_NextPart_001_0129_01D4CA9A.EBF1E560 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable More generally, I do not think there is a requirement that SFF be only = one MPLS-hop apart. So I tend to doubt whether a reference to GTSM will = be helpful. Maybe I am missing the applicability? Yours, Joel =20 From: Andrew G. Malis =20 Sent: Friday, February 22, 2019 9:28 AM To: Carlos Pignataro (cpignata) Cc: ops-dir@ietf.org; mpls ; = draft-ietf-mpls-sfc-encapsulation.all@ietf.org; IETF Discussion = ; sfc@ietf.org Subject: Re: [mpls] Opsdir last call review of = draft-ietf-mpls-sfc-encapsulation-02 =20 Carlos, =20 Looks good on all but one point - I think I see why you're referencing = GTSM, since packets at the SFC layer would generally be one hop away = from each other at that layer. Is that correct? However, I really don't = have sufficient experience with GTSM to craft specific text. If you = think it's important enough to include, could you propose some text for = me to include? =20 Thanks again, Andy =20 =20 On Thu, Feb 21, 2019 at 8:41 PM Carlos Pignataro (cpignata) = > wrote: Hi, Andy,=20 =20 On Feb 21, 2019, at 1:06 PM, Andrew G. Malis > wrote: =20 Carlos, =20 Many thanks for your review! I'm also including the SFC WG on my reply. =20 Thanks for the quick response, and for considering the comments! =20 I enjoyed reading this document =E2=80=94 please see below. =20 Comments inline. =20 On Wed, Feb 20, 2019 at 10:58 PM Carlos Pignataro > wrote: Reviewer: Carlos Pignataro Review result: Has Issues Reviewer: Carlos Pignataro Review Result: Has Issues I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. = These comments were written with the intent of improving the operational = aspects of the IETF drafts. Comments that are not addressed in last call may be = included in AD reviews during the IESG review. Document editors and WG chairs = should treat these comments just like any other last call comments. This document is highly readable, includes very clear textual = descriptions, and is very well organized. Easy to read in its simplicity. However, it = would benefit from a more explicit connection to the transport encap mechanics = from RFC 8300 (e.g., S4, S6.1). Specifically, I'd recommend adding a Figure = or an SFF NSH Mapping Table example, to depict and/or exemplify the SFF = function. =20 I'm trying to envision what would make a good figure here. We could add = an additional line to Table 1 of RFC 8300 and reference that table: =20 +------+------+---------------------+-------------------------+ | SPI | SI | Next Hop(s) | Transport Encapsulation | +------+------+---------------------+-------------------------+ | 25 | 220 | Label 5467 | MPLS | +------+------+---------------------+-------------------------+ =20 Is that what you had in mind? If not, I'm open to other suggestions. =20 If you think it helps, this would be a good addition. =20 >From an Operational standpoint, the document seems largely appropriate = in terms of dataplane considerations. Some key considerations are explicitly out = of scope: The method used by the downstream receiving node to advertise SFF Labels to the upstream sending node is out of scope of this document. This really seems to mean that, with the simple definition in this Informational document, interoperable implementations cannot yet exist. = If there is no mechanism to advertise the SFF Label or to manage the = semantics of this particular label, how will it know? Static configuration, which is = not covered anyway, is not in my humble opinion a manageable scalable = approach. =20 Actually, while it is outside the scope of this document, it is within = the scope of draft-ietf-bess-nsh-bgp-control-plane, and text is being = added to the next revision of that draft to show how it can be used to = signal the encapsulation defined here. This was worked out after this = draft was forwarded to the IESG, but we can now add a reference to that = draft seeing as we'll be doing a post-last-call update. =20 I think that will help, as an Informative =E2=80=9Cone = embodiment=E2=80=9D type of link. =20 Title: MPLS Encapsulation For The SFC NSH RFC 8300 makes an explicit distinction between the terms 'encapsulation' = and 'transport encapsulation' (see e.g., Figure 1, Section 1.5 5., and = Section 4 of RFC 8300). It seems to me that this is the "MPLS Transport Encapsulation for the = SFC NSH" =20 Thanks, we'll fix that. =20 2. MPLS Encapsulation Using an SFF Label Similarly, "2. MPLS Transport Encapsulation Using an SFF Label" The encapsulation is a standard MPLS label stack [RFC3032] with an SFF Label at the bottom of the stack, followed by a NSH as defined by [RFC8300] and the NSH payload. Insteadf of "NSH payload" I think "orignal packet" is meant. =20 RFC 8300 uses both "payload" and "original packet/frame", but the latter = more than the former. So we can change "payload" to "original = packet/frame". =20 Also, this encapsulation is Underdefined: What is the value of TTL? TC? =20 I've been looking back at other related RFCs (such as PW and IP VPN = label definitions) and they're also mostly silent on these values. I did = find the following in RFC 6073: =20 The setting of the TTL of the PW MPLS label is a matter of local policy on the originating PE, but SHOULD be set to 255. =20 Regarding the TC, we can follow the example of RFC 6391: =20 This document does not define a use for the Traffic Class (TC) field [RFC5462 ] (formerly known as = the Experimental Use (EXP) bits [RFC3032 ]) in the flow label. = Future documents may define a use for these bits; therefore, implementations conforming to this specification MUST set the TC field to zero at the ingress and MUST ignore them at the egress. =20 Do you have any alternative suggestions? =20 These two approaches sounds good to me. And Ack to the other previous = responses. =20 Much like a pseudowire label, an SFF Label is allocated by the downstream receiver of the NSH from its per-platform label space. A PW Label is more restrictive. RFC 8077 says it MUST be allocated as per-platform: egress LSR only. Note that the PW label must always be at the bottom of the packet's label stack, and labels MUST be allocated from the per-platform label space. Is this the case for the SFF Label as well? If so, what is the = implication of the MUST? If not, why is it different than other equivalent similar = labels? =20 We can change the text to: =20 Much like a pseudowire label, an SFF Label MUST be allocated by the = downstream receiver of the NSH from its per-platform label space, since = the meaning of the label is identical independent of which incoming = interface it is received [RFC3031]. =20 =20 That=E2=80=99s a great improvement. 2. Push the SFF Label to identify the desired SFF in the receiving MPLS node. TTL value? 1? 2? 255 for GTSM? GTSM RFC 5082 could be used here. =20 As I noted above, 255, although I used RFC 6073 as my source rather than = 5082. We'll add that here as well. =20 =20 Sounds good. These protocols use 5082 in one form or another: = https://datatracker.ietf.org/doc/rfc5082/referencedby/ 4. Operations, Administration, and Maintenance (OAM) Considerations OAM at the SFC Layer is handled by SFC-defined mechanisms [RFC8300]. However, OAM may be required at the MPLS transport layer. If so, then standard MPLS-layer OAM mechanisms such as the Generic Associated Channel [RFC5586] label may be used. RFC 5586 is _not_ an OAM mechanism. It is an associated channel creation mechanism, over which OAM could be carried. Thus, what traditional MPLS OAM can be carried here? Things like RFC = 4379 / RFC 8029 would need the definition of an SFF Label FEC (which does not = exist). Which other one? IP/ICMP seems of very limited value. =20 That's a good point about RFC 5586. The intention is that the MPLS OAM = would be at the transport label layer above the SFF label, so most any = MPLS-layer OAM would be applicable. So how about rewording to make that = more clear: =20 OAM at the SFC Layer is handled by SFC-defined mechanisms [RFC8300]. = However, OAM may be required at the MPLS transport layer. If so, then = standard MPLS-layer OAM mechanisms may be used at the transport label = layer (the labels above the SFF label). =20 Looks good to me, thank you. =20 6. Security Considerations Have you considered the use of GTSM? =20 No, we hadn't. Can you point me to any examples of GTSM being used in an = MPLS or PW context? =20 Yes, see above. =20 8. References [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . SHould RFC 7665 be Normative? It defines the "SFF" which is quite = central to understanding this document. =20 Good point. It was there because 7665 is an Informational RFC, but RFC = 8067 does allow normative references to informational RFCs, so I'll move = it. =20 =20 Thank you. Other Nits and Editorials: SFF Labels are similar to other service labels at the bottom of an MPLS label stack that denote the contents of the MPLS payload being other than IP, such as a layer 2 pseudowire, an IP packet that is routed in a VPN context with a private address, or an Ethernet virtual private wire service. This says "being other than IP, such as IP", which seems to be self-contradictory :-) :-) =20 How about we change "other than IP," to "other than a normally routed IP = packet=E2=80=9D, =20 That would disambiguate it. =20 Thanks again. =20 To me, the control plane / advertisement was the most important = operationally-relevant comment. =20 Thanks, =20 Carlos. =20 Thanks again, Andy =20 ------=_NextPart_001_0129_01D4CA9A.EBF1E560 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

More = generally, I do not think there is a requirement that SFF be only one = MPLS-hop apart.=C2=A0 So I tend to doubt whether a reference to GTSM = will be helpful. =C2=A0=C2=A0Maybe I am missing the = applicability?

Yours,

Joel

 

From: = Andrew G. Malis <agmalis@gmail.com>
Sent: Friday, = February 22, 2019 9:28 AM
To: Carlos Pignataro (cpignata) = <cpignata@cisco.com>
Cc: ops-dir@ietf.org; mpls = <mpls@ietf.org>; draft-ietf-mpls-sfc-encapsulation.all@ietf.org; = IETF Discussion <ietf@ietf.org>; sfc@ietf.org
Subject: = Re: [mpls] Opsdir last call review of = draft-ietf-mpls-sfc-encapsulation-02

 

Carlos,

 

Looks good on all but one point - I think I see why = you're referencing GTSM, since packets at the SFC layer would = generally be one hop away from each other at that layer. Is that = correct? However, I really don't have sufficient experience with GTSM to = craft specific text. If you think it's important enough to include, = could you propose some text for me to = include?

 

Thanks again,

Andy

 

 

On = Thu, Feb 21, 2019 at 8:41 PM Carlos Pignataro (cpignata) <cpignata@cisco.com> = wrote:

Hi, = Andy,

 

On Feb 21, 2019, at 1:06 PM, Andrew G. Malis <agmalis@gmail.com> = wrote:

 

Carlos,=

 <= /o:p>

Many thanks = for your review! I'm also including the SFC WG on my = reply.

 

Thanks for the quick response, and for considering the = comments!

 

I = enjoyed reading this document =E2=80=94 please see = below.



 <= /o:p>

Comments = inline.

 <= /o:p>

On Wed, Feb = 20, 2019 at 10:58 PM Carlos Pignataro <cpignata@cisco.com> = wrote:

Reviewer: = Carlos Pignataro
Review result: Has Issues

Reviewer: Carlos = Pignataro
Review Result: Has Issues

I have reviewed this = document as part of the Operational directorate's
ongoing effort to = review all IETF documents being processed by the IESG.  = These
comments were written with the intent of improving the = operational aspects of
the IETF drafts. Comments that are not = addressed in last call may be included
in AD reviews during the IESG = review.  Document editors and WG chairs should
treat these = comments just like any other last call comments.

This document is = highly readable, includes very clear textual descriptions, and
is = very well organized. Easy to read in its simplicity. However, it = would
benefit from a more explicit connection to the transport encap = mechanics from
RFC 8300 (e.g., S4, S6.1). Specifically, I'd recommend = adding a Figure or an
SFF NSH Mapping Table example, to depict and/or = exemplify the SFF function.

 <= /o:p>

I'm trying = to envision what would make a good figure here. We could add an = additional line to Table 1 of RFC 8300 and reference that = table:

 <= /o:p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
+------+------+---------------------+-------------------------+
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | =
SPI=C2=A0 | SI=C2=A0=C2=A0 | Next =
Hop(s)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Transport =
Encapsulation |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
+------+------+---------------------+-------------------------+
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | =
25=C2=A0=C2=A0 | 220=C2=A0 | Label =
5467=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | =
MPLS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
+------+------+---------------------+-------------------------+

 <= /o:p>

Is that = what you had in mind? If not, I'm open to other = suggestions.

 

If you think it helps, this would be a good = addition.



<= p class=3DMsoNormal> <= /o:p>


>From= an Operational standpoint, the document seems largely appropriate in = terms
of dataplane considerations. Some key considerations are = explicitly out of
scope:
   The method used by the = downstream receiving node to advertise SFF
   Labels to the = upstream sending node is out of scope of this document.

This = really seems to mean that, with the simple definition in = this
Informational document, interoperable implementations cannot yet = exist. If
there is no mechanism to advertise the SFF Label or to = manage the semantics of
this particular label, how will it know? = Static configuration, which is not
covered anyway, is not in my = humble opinion a manageable scalable = approach.

 <= /o:p>

Actually, = while it is outside the scope of this document, it is within the scope = of draft-ietf-bess-nsh-bgp-control-plane, and text is being added = to the next revision of that draft to show how it can be used to signal = the encapsulation defined here. This was worked out after this draft was = forwarded to the IESG, but we can now add a reference to that draft = seeing as we'll be doing a post-last-call = update.

<= div>

 

I think that will help, as an Informative =E2=80=9Cone = embodiment=E2=80=9D type of link.



<= p class=3DMsoNormal> <= /o:p>


Title: = MPLS Encapsulation For The SFC NSH

RFC 8300 makes an explicit = distinction between the terms 'encapsulation' and
'transport = encapsulation' (see e.g., Figure 1, Section 1.5 5., and Section 4 = of
RFC 8300).

It seems to me that this is the "MPLS = Transport Encapsulation for the SFC = NSH"

 <= /o:p>

Thanks, = we'll fix that.

 <= /o:p>


2. = MPLS Encapsulation Using an SFF Label

Similarly, "2. MPLS = Transport Encapsulation Using an SFF Label"

   The = encapsulation is a standard MPLS label stack [RFC3032] with an
  =  SFF Label at the bottom of the stack, followed by a NSH as defined = by
   [RFC8300] and the NSH payload.

Insteadf of = "NSH payload" I think "orignal packet" is = meant.

 <= /o:p>

RFC 8300 = uses both "payload" and "original packet/frame", but = the latter more than the former. So we can change "payload" to = "original packet/frame".

 <= /o:p>


Also, = this encapsulation is Underdefined: What is the value of TTL? = TC?

 <= /o:p>

I've been = looking back at other related RFCs (such as PW and IP VPN label = definitions) and they're also mostly silent on these values. I did find = the following in RFC 6073:

 <= /o:p>

=C2=A0=C2=A0 =
The setting of the TTL of the PW MPLS
=C2=A0=C2=A0 =
label is a matter of local policy on the originating PE, but =
SHOULD
=C2=A0=C2=A0 be set to =
255.

 <= /o:p>

Regarding = the TC, we can follow the example of RFC = 6391:

 <= /o:p>

=C2=A0=C2=A0 =
This document does not define a use for the Traffic Class (TC) =
field
=C2=A0=C2=A0 [RFC5462] (formerly known as the Experimental Use (EXP) =
bits
=C2=A0=C2=A0 [RFC3032]) in the =
flow label.=C2=A0 Future documents may define a use =
for
=C2=A0=C2=A0 these bits; therefore, =
implementations conforming to this
=C2=A0=C2=A0 =
specification MUST set the TC field to zero at the ingress and =
MUST
=C2=A0=C2=A0 ignore them at the =
egress.

 <= /o:p>

Do you have = any alternative = suggestions?

 

These two approaches sounds good to me. And Ack to the = other previous responses.



<= p class=3DMsoNormal> <= /o:p>


  =  Much like a pseudowire label, an SFF Label is allocated by = the
   downstream receiver of the NSH from its per-platform = label space.

A PW Label is more restrictive. RFC 8077 says it = MUST be allocated as
per-platform:

   egress LSR = only.  Note that the PW label must always be at the = bottom
   of the packet's label stack, and labels MUST be = allocated from the
   per-platform label space.

Is = this the case for the SFF Label as well? If so, what is the implication = of
the MUST? If not, why is it different than other equivalent = similar labels?

 <= /o:p>

We can = change the text to:

 <= /o:p>

 Much = like a pseudowire label, an SFF Label MUST be allocated by the = downstream receiver of the NSH from its per-platform label space, since = the meaning of the label is identical independent of which incoming = interface it is received [RFC3031].

 <= /o:p>

 

That=E2=80=99s a great = improvement.




  =  2.  Push the SFF Label to identify the desired SFF in the = receiving
       MPLS node.

TTL value? 1? = 2? 255 for GTSM? GTSM RFC 5082 could be used = here.

 <= /o:p>

As I noted = above, 255, although I used RFC 6073 as my source rather than 5082. = We'll add that here as well.

 <= /o:p>

 

Sounds good.

These protocols use 5082 in one form or = another: https://datatracker.ietf.org/doc/rfc5082/referencedby/<= /a>



<= div>

 

Looks good to me, thank = you.




8. = References

   [RFC7665]  Halpern, J., Ed. and C. = Pignataro, Ed., "Service Function
        =       Chaining (SFC) Architecture", RFC = 7665,
              DOI = 10.17487/RFC7665, October 2015,
          =     <https://www.rfc-editor.org/info/rfc7665>.
SHould RFC 7665 be Normative? It defines the "SFF" which is = quite central to
understanding this = document.

 <= /o:p>

Good point. = It was there because 7665 is an Informational RFC, but RFC 8067 does = allow normative references to informational RFCs, so I'll move = it.

 <= /o:p>

 

Thank = you.




Other = Nits and Editorials:

   SFF Labels are similar to other = service labels at the bottom of an
   MPLS label stack that = denote the contents of the MPLS payload being
   other than = IP, such as a layer 2 pseudowire, an IP packet that is
  =  routed in a VPN context with a private address, or an = Ethernet
   virtual private wire service.

This says = "being other than IP, such as IP", which seems to = be
self-contradictory :-)

:-)

 <= /o:p>

How about = we change "other than IP," to "other than a normally = routed IP = packet=E2=80=9D,

 

That would disambiguate = it.

 

Thanks again.

 

To me, the control plane / advertisement was the most = important operationally-relevant comment.

 

Thanks,

 

Carlos.



<= p class=3DMsoNormal> <= /o:p>

Thanks = again,

Andy

 

------=_NextPart_001_0129_01D4CA9A.EBF1E560-- ------=_NextPart_000_0128_01D4CA9A.EBF1E560 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVZzCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF+DCCA+CgAwIBAgIQ Rm7dpb6xLpDDWuklrtLDgTANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTgwMTA5 MTc1MDMxWhcNMjEwMTA5MTc1MDMwWjBmMREwDwYDVQQKDAhFcmljc3NvbjEVMBMGA1UEAwwMSm9l bCBIYWxwZXJuMSgwJgYJKoZIhvcNAQkBFhlqb2VsLmhhbHBlcm5AZXJpY3Nzb24uY29tMRAwDgYD VQQFEwdlaGFyam9lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyy2JgvRsHX1BlLY9 MsoWvInQ+gxmOCJOkcQ0KMcMKp5BosxeAajKJma3EGAxJh3M+Vj1FyjV5lT6rFRbn4Wk83Av2A2j kjIVSjhhmoZKIvi9U14I6K1Swo6citkrXxMNRxYlsGnPX9Zz68QZE2LJpxzHfxRpecrZDucOIFxR 7jGRvLKK+pfKOrtFwz/hnTG+shmPP7lZ7CEpukIKpz/wRfzVaX9zKLU7ORWoUeJ9aw19pOsEXxEn bW2Ra2qYPmqaA1HfDkEOJMmabq1Qt+0b6TgOcmy5qKzQd8uV8LhOH3ID1DE51q3QFT4Y1tDJuW5P 3D+Nj+90i/0WZaWtumO5lQIDAQABo4IBvzCCAbswSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny bC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCBggYIKwYBBQUH AQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUF BzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs Y2F2My5jZXIwJAYDVR0RBB0wG4EZam9lbC5oYWxwZXJuQGVyaWNzc29uLmNvbTBVBgNVHSAETjBM MEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3Qu dGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0O BBYEFH16/zJ9JH26dPyf8spTDrZy+WTuMB8GA1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZT MA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEAAfc8UKdtqvT0HtMgIOCwY5YN1l1I oU47l6nwym1jy8A+k/ZM5M5RsrSaNoALuDlSrDhyPFsIwAxeWXcuxzPJTTE+CptMkfTZg6CEfXY0 YiR7CiZfDCul36xBVQtXD3+8RyE8/4J+gbvArBkXkJTpqK9RhGBDyXLShNGQZVqQMQApLdnvTklF quy9b8VByKNjDBSGPnIAc3D6YGJYjOkPdR8P3B6Iv7/ysYnhUzy1d/6K1TDHghkSfNY5InD+h8Zm +F15n2WRc8mvQ8ZeYJ9uGT0C+cvh3oMFBm4BjOLxmGoF7bczT/ToIWFLYBYPRRhWAprUmVWBsmkl ZzYOJ80+W0oGIHT14YniJysOZaVrdkQEWzwJ4g9Xz4uzWaB6ThVcmkFCuoMMwQpCmobWz+EktXX5 bqMxPmtUvmAqueQsDzXhxFYCgawN9px2HbFPiz+vd/XiWJp+5F4xkNlAyyDu/l9PyhvyZ7vz1V5s 03FO5hOabZ7c4wgbo0VYU0zuhLIhabwVw/p2t3wsN/T6Ma8H/RjbfVWPaVYR4Rz1y/imF/26SuMe WzTnMGfytdA+rzAagxZUmtzg3yN7MHGsdbB9RtNH/0g4Q57s3CUNmnGrJzx8ciui9oFGKegdDFeu GqcAqC5Dlp83BQpngkFtFmrRa+Gutq6HsXL6LgyIo0ZYPB8wggbCMIIEqqADAgECAhBTuH6D4ZyZ KJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0Nlow RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKn u9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQ of1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/f DL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36p nb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U +86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiM j9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt 7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9u WhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2l FJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgw ggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlh c29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25l cmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0g BE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRy dXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRy dXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA92Nzj kWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOC AgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkj TFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGg e5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx 0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDD TDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A +w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGj zZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJC mpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN 4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmP lpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UE AwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQRm7dpb6xLpDDWuklrtLDgTAJBgUrDgMC GgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTAyMjIx NTM5NDNaMCMGCSqGSIb3DQEJBDEWBBQcyTrXverzEfcxuCZegzPwvZf+3zBDBgkqhkiG9w0BCQ8x NjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCGjBq BgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UE AwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQRm7dpb6xLpDDWuklrtLDgTBsBgsqhkiG 9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxF cmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhBGbt2lvrEukMNa6SWu0sOBMA0GCSqGSIb3DQEB AQUABIIBABVdxR2tZ1oBCsUI7NPCeFpwZ2Q3V1ka7IbXg1WxIGM5OsZdGKqQTuZV76CcyKgKmfWP nnQZ1qJkUnlH5mAb5N+mWjCLfUpAEDEioHnh/nm4T1wVI2ZVLcH6/kINSv9zBK6GwjoZ7ICk4b+V Aj+u5e7WGF2NK+IuZAndEdntgBuD1dZZevTHx+Wj5y45AuqnFqzK19B9HBAg7S0fliSjoaCq22Pa /7YLlp0bCS1rYdESDajY+M5eWmIYAoqzHnciDiU+AU7pABz1XPC3QO35hJZuBBWU9oEbGovFLCI4 +wqWlxLUIJYi5RFH1csrXFUxxZNZUAvJXNlfmwJfPPQ26KcAAAAAAAA= ------=_NextPart_000_0128_01D4CA9A.EBF1E560-- From nobody Fri Feb 22 08:43: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 C1305129284; Fri, 22 Feb 2019 08:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 Z4Wz0SBfK-2s; Fri, 22 Feb 2019 08:43:40 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 7B550130ECD; Fri, 22 Feb 2019 08:43:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 445cbv0LRgzZs6Z; Fri, 22 Feb 2019 08:43:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1550853819; bh=kjuMZqpGXP0kS5zroOd1LrNlFR4hd2ZlF5zx0BhRkvk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=a+4dfDy6CNo2jjbU7q3U85gqQcMRhq9j0dxqc7jGJEt54crocdZU/pXLdk8OCOLJN C7vatIqxJ+j7oMdQNavV7yUAEtQ39L6J9ClqhNbQBCXqg3kAoTokl4OStVwGljx208 Y9hXYLWGvZqWqpXsBjTqqk4gv+ZCOL4y2BwALlwA= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 445cbs5FDMzKnJL; Fri, 22 Feb 2019 08:43:37 -0800 (PST) To: "Andrew G. Malis" , "Carlos Pignataro (cpignata)" Cc: mpls , "ops-dir@ietf.org" , "draft-ietf-mpls-sfc-encapsulation.all@ietf.org" , IETF Discussion , "sfc@ietf.org" References: <155072147698.20210.381511429964485828@ietfa.amsl.com> <6A97863A-DD90-4D62-9607-569386F5F850@cisco.com> From: "Joel M. Halpern" Message-ID: <03769b15-8375-a23a-a882-0a183056a8b5@joelhalpern.com> Date: Fri, 22 Feb 2019 11:43:36 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 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] Opsdir last call review of draft-ietf-mpls-sfc-encapsulation-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: Fri, 22 Feb 2019 16:43:44 -0000 My comment on this may not have made it to everyone. If you receive a duplicate, I apologize (I received DMARC errors from something about translations from the draft.all address to gmail addresses.) Speaking as a co-author... It is not at all clear to me that GTSM applies or how it would apply. There is no requirement that successive SFF be one MPLS hop apart. Yours, Joel On 2/22/19 9:27 AM, Andrew G. Malis wrote: > Carlos, > > Looks good on all but one point - I think I see why you're referencing > GTSM, since packets at the SFC layer would generally be one hop away > from each other at that layer. Is that correct? However, I really don't > have sufficient experience with GTSM to craft specific text. If you > think it's important enough to include, could you propose some text for > me to include? > > Thanks again, > Andy > > > On Thu, Feb 21, 2019 at 8:41 PM Carlos Pignataro (cpignata) > > wrote: > > Hi, Andy, > >> On Feb 21, 2019, at 1:06 PM, Andrew G. Malis > > wrote: >> >> Carlos, >> >> Many thanks for your review! I'm also including the SFC WG on my >> reply. > > Thanks for the quick response, and for considering the comments! > > I enjoyed reading this document — please see below. > >> >> Comments inline. >> >> On Wed, Feb 20, 2019 at 10:58 PM Carlos Pignataro >> > wrote: >> >> Reviewer: Carlos Pignataro >> Review result: Has Issues >> >> Reviewer: Carlos Pignataro >> Review Result: Has Issues >> >> I have reviewed this document as part of the Operational >> directorate's >> ongoing effort to review all IETF documents being processed by >> the IESG.  These >> comments were written with the intent of improving the >> operational aspects of >> the IETF drafts. Comments that are not addressed in last call >> may be included >> in AD reviews during the IESG review.  Document editors and WG >> chairs should >> treat these comments just like any other last call comments. >> >> This document is highly readable, includes very clear textual >> descriptions, and >> is very well organized. Easy to read in its simplicity. >> However, it would >> benefit from a more explicit connection to the transport encap >> mechanics from >> RFC 8300 (e.g., S4, S6.1). Specifically, I'd recommend adding >> a Figure or an >> SFF NSH Mapping Table example, to depict and/or exemplify the >> SFF function. >> >> >> I'm trying to envision what would make a good figure here. We >> could add an additional line to Table 1 of RFC 8300 and reference >> that table: >> >> +------+------+---------------------+-------------------------+ >> | SPI | SI | Next Hop(s) | Transport Encapsulation | >> +------+------+---------------------+-------------------------+ >> | 25 | 220 | Label 5467 | MPLS | >> +------+------+---------------------+-------------------------+ >> >> Is that what you had in mind? If not, I'm open to other suggestions. > > If you think it helps, this would be a good addition. > >> >> >From an Operational standpoint, the document seems largely >> appropriate in terms >> of dataplane considerations. Some key considerations are >> explicitly out of >> scope: >>    The method used by the downstream receiving node to >> advertise SFF >>    Labels to the upstream sending node is out of scope of this >> document. >> >> This really seems to mean that, with the simple definition in this >> Informational document, interoperable implementations cannot >> yet exist. If >> there is no mechanism to advertise the SFF Label or to manage >> the semantics of >> this particular label, how will it know? Static configuration, >> which is not >> covered anyway, is not in my humble opinion a manageable >> scalable approach. >> >> >> Actually, while it is outside the scope of this document, it is >> within the scope of draft-ietf-bess-nsh-bgp-control-plane, and >> text is being added to the next revision of that draft to show how >> it can be used to signal the encapsulation defined here. This was >> worked out after this draft was forwarded to the IESG, but we can >> now add a reference to that draft seeing as we'll be doing a >> post-last-call update. > > I think that will help, as an Informative “one embodiment” type of link. > >> >> Title: MPLS Encapsulation For The SFC NSH >> >> RFC 8300 makes an explicit distinction between the terms >> 'encapsulation' and >> 'transport encapsulation' (see e.g., Figure 1, Section 1.5 5., >> and Section 4 of >> RFC 8300). >> >> It seems to me that this is the "MPLS Transport Encapsulation >> for the SFC NSH" >> >> >> Thanks, we'll fix that. >> >> >> 2.  MPLS Encapsulation Using an SFF Label >> >> Similarly, "2. MPLS Transport Encapsulation Using an SFF Label" >> >>    The encapsulation is a standard MPLS label stack [RFC3032] >> with an >>    SFF Label at the bottom of the stack, followed by a NSH as >> defined by >>    [RFC8300] and the NSH payload. >> >> Insteadf of "NSH payload" I think "orignal packet" is meant. >> >> >> RFC 8300 uses both "payload" and "original packet/frame", but the >> latter more than the former. So we can change "payload" to >> "original packet/frame". >> >> >> Also, this encapsulation is Underdefined: What is the value of >> TTL? TC? >> >> >> I've been looking back at other related RFCs (such as PW and IP >> VPN label definitions) and they're also mostly silent on these >> values. I did find the following in RFC 6073: >> >> The setting of the TTL of the PW MPLS >> label is a matter of local policy on the originating PE, but SHOULD >> be set to 255. >> >> Regarding the TC, we can follow the example of RFC 6391: >> >> This document does not define a use for the Traffic Class (TC) field >> [RFC5462 ] (formerly known as the Experimental Use (EXP) bits >> [RFC3032 ]) in the flow label. Future documents may define a use for >> these bits; therefore, implementations conforming to this >> specification MUST set the TC field to zero at the ingress and MUST >> ignore them at the egress. >> >> Do you have any alternative suggestions? > > These two approaches sounds good to me. And Ack to the other > previous responses. > >> >>    Much like a pseudowire label, an SFF Label is allocated by the >>    downstream receiver of the NSH from its per-platform label >> space. >> >> A PW Label is more restrictive. RFC 8077 says it MUST be >> allocated as >> per-platform: >> >>    egress LSR only.  Note that the PW label must always be at >> the bottom >>    of the packet's label stack, and labels MUST be allocated >> from the >>    per-platform label space. >> >> Is this the case for the SFF Label as well? If so, what is the >> implication of >> the MUST? If not, why is it different than other equivalent >> similar labels? >> >> >> We can change the text to: >> >>  Much like a pseudowire label, an SFF Label MUST be allocated by >> the downstream receiver of the NSH from its per-platform label >> space, since the meaning of the label is identical independent of >> which incoming interface it is received [RFC3031]. >> > > That’s a great improvement. > >> >>    2.  Push the SFF Label to identify the desired SFF in the >> receiving >>        MPLS node. >> >> TTL value? 1? 2? 255 for GTSM? GTSM RFC 5082 could be used here. >> >> >> As I noted above, 255, although I used RFC 6073 as my source >> rather than 5082. We'll add that here as well. >> > > Sounds good. > These protocols use 5082 in one form or another: > https://datatracker.ietf.org/doc/rfc5082/referencedby/ > >> >> 4.  Operations, Administration, and Maintenance (OAM) >> Considerations >> >>    OAM at the SFC Layer is handled by SFC-defined mechanisms >> [RFC8300]. >>    However, OAM may be required at the MPLS transport layer. >> If so, >>    then standard MPLS-layer OAM mechanisms such as the Generic >>    Associated Channel [RFC5586] label may be used. >> >> RFC 5586 is _not_ an OAM mechanism. It is an associated >> channel creation >> mechanism, over which OAM could be carried. >> >> Thus, what traditional MPLS OAM can be carried here? Things >> like RFC 4379 / RFC >> 8029 would need the definition of an SFF Label FEC (which does >> not exist). >> Which other one? IP/ICMP seems of very limited value. >> >> >> That's a good point about RFC 5586. The intention is that the MPLS >> OAM would be at the transport label layer above the SFF label, so >> most any MPLS-layer OAM would be applicable. So how about >> rewording to make that more clear: >> >> OAM at the SFC Layer is handled by SFC-defined mechanisms >> [RFC8300]. However, OAM may be required at the MPLS transport >> layer.  If so, then standard MPLS-layer OAM mechanisms may be used >> at the transport label layer (the labels above the SFF label). > > Looks good to me, thank you. > >> >> >> 6.  Security Considerations >> >> Have you considered the use of GTSM? >> >> >> No, we hadn't. Can you point me to any examples of GTSM being used >> in an MPLS or PW context? > > Yes, see above. > >> >> 8.  References >> >>    [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service >> Function >>               Chaining (SFC) Architecture", RFC 7665, >>               DOI 10.17487/RFC7665, October 2015, >>               > >. >> >> SHould RFC 7665 be Normative? It defines the "SFF" which is >> quite central to >> understanding this document. >> >> >> Good point. It was there because 7665 is an Informational RFC, but >> RFC 8067 does allow normative references to informational RFCs, so >> I'll move it. > > Thank you. > >> >> Other Nits and Editorials: >> >>    SFF Labels are similar to other service labels at the >> bottom of an >>    MPLS label stack that denote the contents of the MPLS >> payload being >>    other than IP, such as a layer 2 pseudowire, an IP packet >> that is >>    routed in a VPN context with a private address, or an Ethernet >>    virtual private wire service. >> >> This says "being other than IP, such as IP", which seems to be >> self-contradictory :-) >> >> :-) >> >> How about we change "other than IP," to "other than a normally >> routed IP packet”, > > That would disambiguate it. > > Thanks again. > > To me, the control plane / advertisement was the most important > operationally-relevant comment. > > Thanks, > > Carlos. > >> >> Thanks again, >> Andy > From nobody Fri Feb 22 09:19: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 73248130F1C; Fri, 22 Feb 2019 09:19:19 -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, SPF_PASS=-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 eHo92Kdh2Yuy; Fri, 22 Feb 2019 09:19:16 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70092.outbound.protection.outlook.com [40.107.7.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF0A412426A; Fri, 22 Feb 2019 09:19:15 -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=z/8nIl8UlDJD+4LMGpCKGmmiuwMvpIErUa9QCgtvWjY=; b=CTpXgNMLXXXk50ck6D0dy2cF98Du4ELi57jIX+09L7yNTI+hxeIlCJAw8hJscLnpDKT7xlKhKtTB1AGUc1/Jesk3+qm2EXHfBaL4QP1ZAK+c9EJ5b7gT6kxKeJSQ2oZ0yIyj4rt11K0fBZYy+eLsINRzW7zlq5aeRvzk4mhn3+U= Received: from VI1PR07MB4768.eurprd07.prod.outlook.com (20.177.57.155) by VI1PR07MB5936.eurprd07.prod.outlook.com (20.178.81.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.6; Fri, 22 Feb 2019 17:19:12 +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.1665.008; Fri, 22 Feb 2019 17:19:12 +0000 From: tom petch To: Greg Mirsky CC: "mpls@ietf.org" , Loa Andersson , "mpls-chairs@ietf.org" , "draft-zheng-mpls-lsp-ping-yang-cfg@ietf.org" Thread-Topic: [mpls] Working Group Adoption Poll on draft-zheng-mpls-lsp-ping-yang-cfg Thread-Index: AQHUyQ+ywD+0BDpFC0yeZz/8w8buHA== Date: Fri, 22 Feb 2019 17:19:12 +0000 Message-ID: <00c501d4cad2$7b2bd4c0$4001a8c0@gateway.2wire.net> References: <98db7e71-6152-1335-8ca0-b5ae67b8a4b6@pi.nu> <020301d4c90f$748bd300$4001a8c0@gateway.2wire.net> <030301d4c9df$2602e180$4001a8c0@gateway.2wire.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0030.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:61::18) 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: 7900616f-95a5-427f-1229-08d698e9dcfc x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1PR07MB5936; x-ms-traffictypediagnostic: VI1PR07MB5936: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 09565527D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(39860400002)(366004)(136003)(51444003)(189003)(199004)(13464003)(93886005)(71200400001)(86362001)(486006)(68736007)(62236002)(54906003)(476003)(1556002)(229853002)(106356001)(105586002)(4720700003)(14444005)(6916009)(84392002)(256004)(8936002)(66066001)(71190400001)(5660300002)(316002)(2906002)(14496001)(50226002)(186003)(26005)(446003)(44716002)(86152003)(53936002)(6306002)(6436002)(8676002)(478600001)(7736002)(6246003)(61296003)(25786009)(44736005)(4326008)(6486002)(3846002)(6116002)(9686003)(81156014)(1411001)(81166006)(6512007)(305945005)(33896004)(53546011)(386003)(6506007)(97736004)(99286004)(966005)(14454004)(76176011)(102836004)(81816011)(81686011)(52116002)(440344003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5936; 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: =?utf-8?B?MTtWSTFQUjA3TUI1OTM2OzIzOlA2M0ZRUU9INy9YdVJmN0FSRndjcG14REhL?= =?utf-8?B?anpqS1h3K2U3VWhHOVVKN0lkQU5BblYreXdXdnBHa3Uya1RvbGFGUUJ3Q2tr?= =?utf-8?B?REF1NFdUcS9wa3BUWWF0cHg5dCtadlhLeFBQM2tmU0JOc255UTV2cmI4c2xZ?= =?utf-8?B?VkZPc291eVhUQzFHdW5SaGtZOXQ5bFgydUlPaUkwSjNjK2NhUVgwNllEN0Jk?= =?utf-8?B?eDlZWXV1ZzFROUR5ZGtoajZrQXlxNjJMS1NISTErck4wL3hJOG5lVHRnT2tp?= =?utf-8?B?aGZ2aXlQdnpLZkhMNzBjYWdrZ3JFYnBzN0NmT3dzTjdhbTZLZ25YQ2t1dGZz?= =?utf-8?B?cC9XUGFzV1A2ajFKYUpqb1VjdjRhTHl6aGlYZEpQSE1oWXV0VGdjZUFrQzQw?= =?utf-8?B?VS9lK2xLTWlUN3AyZGtGNCszRXJhQkducC9CVWNrMXZSUDNCUjFTRFlBNFB5?= =?utf-8?B?ckdWUU9ieStHeFZrY2Znemk4OTY2dElMNDd4b0xhd0lZaHY1OWs3bTI1N3dy?= =?utf-8?B?STNYMEl1QXB1Znhnc2ovUVMyOFpyNXlWc3dteVdhdVJ5U1oyb0c0R3AxUGJv?= =?utf-8?B?UHhjS0U3enhIaENrUnM1OWJCMUhteFd1Q1E5UXR4YUM0cGpCb09ObmJRNSsv?= =?utf-8?B?MEJYWDR6Y0hjQTBkMEEvNEpXRzdrQjh1UVJXSVNNLzdIZ1JUR25MUnRBZDBm?= =?utf-8?B?c1AxeDNIT21nWSt3RXBwcUd3ck5XK1JjSkxxMEw0T1FDL21wcVg0a3VHeVly?= =?utf-8?B?VFFRVFIwSXRoLy9qVzNETCs1dHptcEZ2cDROaFd2T0xpTU1DelNrdFlPUURH?= =?utf-8?B?VXRPYk1ReHNldkgwdGZsNGFvdnhLS1M3SGNmUU1aUmxVQUVRbWRHRnY3Z0h4?= =?utf-8?B?MVhQRG0rR0Ywa2N4aEc1ZlhKRjg2RFFObndFL2pDaCtnNWNhV2g0WFRBUG0y?= =?utf-8?B?bU1LVzdZZ1dWSEdNajl6SHNNYmpaald1MHpNdm01cjVtdEtrczRRTjVjNkF1?= =?utf-8?B?TUtYa3UzQytMYWs5dmxZREVMREMxMVFWamc1SG5IaENDT3RYS1pTZ0FsbUFy?= =?utf-8?B?bHI0QVlzV1M1aktjWWU1ZlA3UThiZExuY3dMenJQSVd1VGRWYXk2WXlnYjRk?= =?utf-8?B?QTUyMlpMOERDY3dsckI3a05wUTlFeXVUY1pXQ1FQWjNEMnA0a255KzFXemt4?= =?utf-8?B?aVBjUEVQMVhnOU53Q0xXdTcrUmJIaVMzOGVsbnRsbWZxdEhUalR1NGVYOXB0?= =?utf-8?B?K1UralJCQk9iazV2SnZVWHVMZzcwRnV4bHpPc1JtSjJNODBlaWRoM1JnbmVP?= =?utf-8?B?aHVHOGVwMGFiYjcrbVIydzcrU3ZCeGpJSEVCdTVvMlAxeXR6UTV4TVN0SDZF?= =?utf-8?B?b1BFaWFCaFlBYld0L3Z3L20rM0lCMHBZNStXSGcrNi9QWDU4RjlwSkdSZDR1?= =?utf-8?B?c0F5djhYdVpzUWFEZkVQck5ya3RSRG5QWWRzRnEyY29tS1ErNkptcnRKQk9F?= =?utf-8?B?bWh3OU1FRUQxQVdXMktFZ2Ixa1Ftb0lFSGlrWjRudmZHY3FqeEdrYkgxM0Vy?= =?utf-8?B?WTRxZTVlUTRtOWowdWtON0c3cUJLVkdCdGpoS2RUTHJpLzQ1VFRiVHUwRXdJ?= =?utf-8?B?MzRqeU5rbEIxWVYwZ085U2kzd1RHWmhIYTBpQVJUVHg1N0JNcG0vVHVZZnY5?= =?utf-8?B?d0JXUlpQQy9qMXh1Zy9xcUxUdEVnNmNJRjRySk9yVWFGVnJQV2Jmb2w3ZDNU?= =?utf-8?B?UWlPWkNzMHZDTnpDeVFVN0cvOVg4ZFlHQk1jclFXM2YwcitWb2ZKZVhVaGRo?= =?utf-8?B?RUhVcy9EZVVIVE91VmtsWVdvMnI1WkwwT1NDYk0zMSs0T0xGalo0MS9Rc2hO?= =?utf-8?B?ZDZCdzBXTFpNcnNQbHpYN0g3SVhTdmFNWTY2MTI4OGt3cTlSemF1MzNqcXJi?= =?utf-8?B?M1ZFQVI1OVJOdmg2Y3BMeFVuTnhNdkdHRW1QWTVyUXVWYVU3MmUrR0NlRGFm?= =?utf-8?B?aE0zN0JGQjI2M2tWY01XVFRBMjJkdmx2R0lIcTEzL01JQVdSTnU4TGRiWGR2?= =?utf-8?B?MzVwVU45ZkNaK1VvRnRwOVZYeE12RER2SkU1dXFrVCtETTBkeFFwR2FISlVM?= =?utf-8?B?TklQcHExaHAxOFZ4anI4QjBWdnNuMnYvSzNFTldYL2pGWXN6UktZQUdNV3Vj?= =?utf-8?B?aThHa3dMNFhVOER3OFRVd0srYVdHSGVTeDdObHYyang3MFFFZWozbkRjdFNh?= =?utf-8?Q?LDcZ8XtPtEJhQUChaQ?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: mJTe9e3wfyd0MNPECWUyQZB6PGV1fwlW8Ag2NVe8xOU/vLQD8Wo2xCiT/wWt5L1CagSsLcQTtz4o8X5wfKtI4xnLkRn8T5P7guOX8O44W0cVE9j4y2hT5mCk7qoVJBjXOyIToeE6lHkZKbh4crjUYlJ10DqvD6bTuUZTHlEEDvPiRd2qprXKCam/YrSLc0xI7f0dpa/lEE4sA/lgcoWzok4p2IubVRy3q6sxaSOLxVNSMs1rGMwuRKR6fJnPVPuNOXklanEIchXchM+rGaaobqwE0rZfblwF81diHdaaDmAqWXJgAMvPmjOBTBElIzKiq+RR/iUYaL/ACOjX4ol7VtsibPxRuQoVvkoG2wQFGrOgTob/XdbrKdz3KBwRjDXvhv5VKZrFoPuLhGwsgkVBt/UI88F0nlgPMF3xdet1SFM= Content-Type: text/plain; charset="utf-8" Content-ID: <3A1946AD97BE3F4BA491F7EE88EF09B5@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7900616f-95a5-427f-1229-08d698e9dcfc X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 17:19:12.4584 (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: VI1PR07MB5936 Archived-At: Subject: Re: [mpls] 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: Fri, 22 Feb 2019 17:19:19 -0000 LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIkdyZWcgTWlyc2t5IiA8Z3JlZ2lt aXJza3lAZ21haWwuY29tPg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDIxLCAyMDE5IDU6MDEg UE0NCg0KDQo+IEhpIFRvbSwNCj4gbXVjaCBhcHByZWNpYXRlIHlvdXIgY29tbWVudHMsIHN1Z2dl c3Rpb25zLg0KPiBUaGUgb3JpZ2luYWwgc291cmNlIGZvciB0aGUgbW9kZWwgd2FzIFJGQyA0Mzc5 LCBub3QgUkZDIDgwMjkuIEkNCnVuZGVyc3RhbmQNCj4gdGhhdCBhIGxvdCBvZiB3b3JrIGlzIGFo ZWFkIGZvciB1cyB3aXRoIHRoZSBtb2RlbCwgZG9jdW1lbnQuIEkgaG9wZQ0KdGhhdA0KPiB0aGUg V0cgd2lsbCBhY3RpdmVseSBwYXJ0aWNpcGF0ZSBhbmQgY29udHJpYnV0ZSB0byBjb21wbGV0ZSB0 aGUgbW9kZWwNCmluIGENCj4gcmVhc29uYWJsZSB0aW1lLg0KDQpHcmVnDQoNCkkgbG9vayBmb3J3 YXJkIHRvIGl0Lg0KDQpBcyBpcyBwcm9iYWJseSBjbGVhcmVyIGluIG15IHNlY29uZCBlLW1haWws IHdoYXQgSSBob3BlIGZvciBpcyB0byBiZQ0KYWJsZSB0byBnbyByZWFkaWx5IGZyb20gdGhlIGZ1 bmN0aW9ucyBpbiBSRkM4MDI5IHRvIHNlZSBob3cgdG8gY29uZmlndXJlDQphbGwgdGhlIGZpZWxk cyB0aGVyZWluIGZyb20gdGhpcyBJLUQsIGFuZCBsaWtld2lzZSB0byBnbyBmcm9tIHRoaXMgSS1E DQpiYWNrIHRvIFJGQzgwMjkgZm9yIG1vcmUgaW5mb3JtYXRpb24gb24gYSBwYXJ0aWN1bGFyIG9i amVjdDsgYW5kIHdoZXJlDQp0aGUgWUFORyBtb2R1bGUgZG9lcyBub3QgZmFjaWxpdGF0ZSBjb25m aWd1cmF0aW9uLCBwZXJoYXBzIHRoZSB2YWx1ZSBpcw0KaW1wbGljaXQgb3IgdGhhdCBwYXJ0IG9m IHRoZSBmdW5jdGlvbmFsaXR5IGlzIG5vdCBzdXBwb3J0ZWQgYXQgdGhpcw0KdGltZSwgdGhlbiB0 byBiZSB0b2xkIHRoYXQgaW4gdGhlIEktRC4NCg0KVG9tIFBldGNoDQoNCj4gUmVnYXJkcywNCj4g R3JlZw0KPg0KPiBPbiBUaHUsIEZlYiAyMSwgMjAxOSBhdCA0OjE3IEFNIHRvbSBwZXRjaCB3cm90 ZToNCj4NCj4gPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ID4gRnJvbTogIkxvYSBB bmRlcnNzb24iIDxsb2FAcGkubnU+DQo+ID4gU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDIxLCAy MDE5IDEyOjQwIEFNDQo+ID4NCj4gPiA+IFRvbSwNCj4gPiA+DQo+ID4gPiBNdWNoIGFzIEkgYXBw cmVjaWF0ZSB5b3VyIGNvbW1lbnRzLCBhbmQgSSBhZ3JlZSB3aXRoIHRoZSB0ZWNobmljYWwNCj4g PiA+IGFzcGVjdHMgb2YgdGhlbS4gVGhlIHJlZmVyZW5jZXMgYW5kIHRoZSBpbmNvbnNpc3RlbmNp ZXMgc2hvdWxkIGJlDQo+ID4gPiBmaXhlZC4gSG93ZXZlciwgSSBoYXZlIGEgbGl0dGxlIGJpdCBk aWZmZXJlbnQgdmlldyBvZiB3aGF0IHNob3VsZA0KPiA+ID4gYmUgZG9uZS4NCj4gPiA+DQo+ID4g PiBJdCBpcyBjbGVhciB0aGF0IHdlIG5lZWQgYSBZQU5HIG1vZHVsZSBmb3IgTFNQIFBpbmcuDQo+ ID4gPg0KPiA+ID4gSXQgaXMgdW5saWtlbHkgdGhhdCB0aGVyZSB3aWxsIGJlIGFub3RoZXIgZG9j dW1lbnQuDQo+ID4gPg0KPiA+ID4gVGhpcyBkb2N1bWVudCBoYXMgYmVlbiB2ZXJ5IHNsb3cgZGV2 ZWxvcGluZywgdGhlIGZpcnN0IHZlcnNpb24gaXMNCj4gPiA+IGZyb20gMjAxNS4NCj4gPiA+DQo+ ID4gPiBJIHRoaW5rIHRoYXQgd2Ugc2hvdWxkIHNheSB0aGF0IHRoaXMgaXMgImEgZ29vZCBlbm91 Z2ggc3RhcnRpbmcNCj4gPiA+IHBvaW50IiwgYW5kIHRoYXQgdGhlcmUgYXJlIHRoaW5nIHRoYXQg bmVlZCB0byBiZSBmaXhlZCBiZWZvcmUNCj4gPiA+IHB1YmxpY2F0aW9uLCBlLmcgdGhlIFJQQ3Mg bWVudGlvbmVkIGJ5IEFjZWUsIGFuZCB0aGUgbGFjayBvZg0KPiA+IHJlZmVyZW5jZXMNCj4gPiA+ IGFuZCB0aGUgcG90ZW50aWFsIGluY29uc2lzdGVuY2llcyBwb2ludGVkIG91dCBieSB5b3UuDQo+ ID4NCj4gPiBXaGljaCBpcyB3aGVyZSB3ZSBwYXJ0IGNvbXBhbnkuICBBZnRlciB0aHJlZSB5ZWFy cywgYW5kIDEwDQpyZXZpc2lvbnMsIEkNCj4gPiBsb29rIGZvciBtb3JlLiAgSW4gcGFydGljdWxh ciwgSSBzZWUgdG9vIG11Y2ggZGlzY3JlcGFuY3kgYmV0d2Vlbg0KdGhlDQo+ID4gWUFORyBtb2R1 bGUgYW5kIFJGQzgwMjksIGFsdGhvdWdoLCBhcyBJIHNhaWQsIHRoZSBsYWNrIG9mIHJlZmVyZW5j ZXMNCmFuZA0KPiA+IHRoZSBjaGFuZ2Ugb2YgaWRlbnRpZmllcnMgZm9yIEZFQyBjbGFzc2VzIGFu ZCB0aGUgY29uZmxhdGlvbiBvZiBGRUMNCj4gPiBjbGFzc2VzLCAgbWFrZXMgY29tcGFyaXNvbiBk aWZmaWN1bHQgZm9yIG1lLg0KPiA+DQo+ID4gUkZDODAyOSBsaXN0IDE2IEZFQywgdGhpcyBJLUQg c2l4OyBXaHkgdGhlIGVsaXNpb24/IFdoYXQgaXMgdGhlDQptYXBwaW5nPw0KPiA+DQo+ID4gVGhp cyBJLUQgdXNlcyBlbnVtZXJhdGlvbiBhbmQgcHJvdmlkZXMgYSBudW1lcmljIHZhbHVlLiAgVGhl IG51bWVyaWMNCj4gPiB2YWx1ZSBpcyBub3QgcHJlc2VudCBvbiB0aGUgd2lyZSBhbmQgc28gdXN1 YWxseSBpcyBub3Qgc3BlY2lmaWVkIGluDQphDQo+ID4gWUFORyBtb2R1bGUsIGV4Y2VwdCBhcyBk b2N1bWVudGF0aW9uIC0gaGVyZSB0aGUgdmFsdWVzIHNwZWNpZmllZA0KYmVhciBubw0KPiA+IHJl bGF0aW9uc2hpcCB0byB0aGUgUkZDIGFuZCBzbyBjb25mdXNlIG1lICAoQ29tbW9uIHByYWN0aWNl IG5vdyBpcw0KdG8NCj4gPiB1c2UgWUFORyBpZGVudGl0eSByYXRoZXIgdGhhbiBlbnVtZXJhdGlv biBhbHRob3VnaCBuZWl0aGVyIGFyZQ0KaWRlYWwpLg0KPiA+DQo+ID4gVGFraW5nIGEgZ3Vlc3Mg YXQgdGhlIG1hcHBpbmcsIGNvbXBhcmVkIHRvIFJGQzgwMjksDQo+ID4NCj4gPiAgICAgICAgICAg Y2FzZSBpcC1wcmVmaXggew0KPiA+IGxhY2tzIHByZWZpeCBsZW5ndGgNCj4gPg0KPiA+ICAgICAg ICAgICBjYXNlIGJncCB7DQo+ID4gIGxhY2tzIHByZWZpeCBsZW5ndGgNCj4gPg0KPiA+ICAgICAg ICAgICBjYXNlIHJzdnAgew0KPiA+IEkgc3RydWdnbGUgd2l0aCAtIHRoZSBJLUQgb25seSBkZWZp bmVzIGEgc3RyaW5nLCB0aGUgUkZDDQo+ID4gICAgIElQdjQgdHVubmVsIGVuZCBwb2ludCBhZGRy ZXNzDQo+ID4gICAgIFR1bm5lbCBJRA0KPiA+ICAgICBFeHRlbmRlZCBUdW5uZWwgSUQNCj4gPiAg ICAgSVB2NCB0dW5uZWwgc2VuZGVyIGFkZHJlc3MNCj4gPiAgICAgTFNQIElEDQo+ID4NCj4gPiAg ICAgICAgICAgY2FzZSB2cG4gew0KPiA+IGRlZmluZXMgIGxlYWYgdnJmLW5hbWUgeyB0eXBlIHVp bnQzMjsgICJMYXllcjMgVlBOIE5hbWUiOw0KPiA+ICAgICAgICAgICAgIGxlYWYgdnBuLWlwLWFk ZHJlc3MgdHlwZSBpbmV0OmlwLWFkZHJlc3M7ICJMYXllcjMgVlBODQpJUHY0DQo+ID4gUHJlZml4 IjsNCj4gPiB3aGljaCBsYWNrcyBwcmVmaXggbGVuZ3RoIGFuZCBSb3V0ZSBEaXN0aW5ndWlzaGVy ICg4IG9jdGV0cykNCmNvbXBhcmVkDQo+ID4gdG8gdGhlIFJGQw0KPiA+DQo+ID4gICAgICAgICAg IGNhc2UgcHcNCj4gPiBoYXMNCj4gPiAgICBsZWFmIHZjaWQgeyAgdHlwZSB1aW50MzI7DQo+ID4g d2hpbGUgdGhlIFJGQyBoYXMNCj4gPiAgICAgU2VuZGVyJ3MgUEUgSVB2NCBBZGRyZXNzDQo+ID4g ICAgIFJlbW90ZSBQRSBJUHY0IEFkZHJlc3MNCj4gPiAgICAgUFcgSUQNCj4gPiAgICAgUFcgVHlw ZQ0KPiA+DQo+ID4gICAgICAgICAgIGNhc2UgdnBscyB7DQo+ID4gYXBwZWFycyB0byBiZSBhbiAo dW5mb3J0dW5hdGUpIHJlbmFtaW5nIG9mIEZFQzEyOSBhbmQgc3BlY2lmaWVzDQo+ID4gICAgICAg ICAgbGVhZiB2c2ktbmFtZSB7IHR5cGUgc3RyaW5nOyBkZXNjcmlwdGlvbiAiVlBMUyBWU0kiOw0K PiA+IHdoZXJlIHRoZSBSRkMgaGFzIEFHSSBBSUkgZXRjDQo+ID4NCj4gPiBTbyB3ZSBhZ3JlZSB0 aGF0IHdlIG5lZWQgdGhlIGFiaWxpdHkgdG8gY29uZmlndXJlIHRoZSBmdW5jdGlvbnMgb2YNCj4g PiBSRkM4MDI5LCBidXQgdGhpcyBJLUQgc2VlbXMgc29tZXdoYXQgcmVtb3ZlZCBmcm9tIHRoYXQs IHRvbyBmYXIgdG8NCj4gPiBiZWNvbWUgYSBXRyBJLUQgSU1ITy4NCj4gPg0KPiA+IFRvbSBQZXRj aA0KPiA+DQo+ID4gPg0KPiA+ID4gVG8gcHV0IHRoZSB3b3JraW5nIGdyb3VwIGluIGNvbnRyb2wg b2YgdGhlIGRyYWZ0IGFuZCBtYWtlIHN1cmUNCnRoYXQgaXQNCj4gPiA+IHByb2dyZXNzIHdlbGwg SSB3YW50IHRvIGFkYW9wdCBpdCBhcyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuIFRoZQ0KPiA+ ID4gb25seSB0aGluZyBJIGJlbGlldmUgaXMgbmVjZXNzYXJ5IGlzIHRoYXQgdGhlIGF1dGhvcnMg YWNrbm93bGVkZ2UNCnRoYXQNCj4gPiA+IHRoZSBpc3N1ZXMgcG9pbnRlZCBvdXQgbmVlZHMgdG8g YmUgYWRkcmVzc2VkLg0KPiA+ID4NCj4gPiA+IC9Mb2ENCj4gPiA+DQo+ID4gPiBPbiAyMDE5LTAy LTIwIDE5OjMwLCB0b20gcGV0Y2ggd3JvdGU6DQo+ID4gPiA+IE5vdCBzdXBwb3J0DQo+ID4gPiA+ DQo+ID4gPiA+IFRoZSBZQU5HIG1vZHVsZSBpcyB2ZXJ5IHdlYWsgb24gcmVmZXJlbmNlcyB3aGlj aCBtYWtlcyBpdCBoYXJkDQpmb3INCj4gPiBtZSB0bw0KPiA+ID4gPiBiZSBzdXJlIGJ1dCB0aGVy ZSBzZWVtcyB0byBiZSBhIG1pc21hdGNoIGJldHdlZW4gZS5nLiBGRUMNCmNsYXNzZXMgaW4NCj4g PiA+ID4gUkZDODAyOSBhbmQgdGhlIFlBTkcgbW9kdWxlLg0KPiA+ID4gPg0KPiA+ID4gPiBUaHVz IFJGQzgwOSBoYXMNCj4gPiA+ID4gICAgICAgICAgICAgMSAgICAgICAgICA1ICAgICAgICAgTERQ IElQdjQgcHJlZml4DQo+ID4gPiA+IHdpdGggYSBvbmUgYnl0ZSBwcmVmaXggbGVuZ3RoIGFuZCBm b3VyIGJ5dGUgcHJlZml4Lg0KPiA+ID4gPg0KPiA+ID4gPiBUaGUgWUFORyBtb2R1bGUgaGFzDQo+ ID4gPiA+ICAgICAgICBlbnVtIGlwLXByZWZpeCB7DQo+ID4gPiA+ICAgICAgICAgIHZhbHVlICIw IjsNCj4gPiA+ID4gICAgICAgICAgZGVzY3JpcHRpb24gIklQdjQvSVB2NiBwcmVmaXgiOw0KPiA+ ID4gPiBhbmQNCj4gPiA+ID4gICAgICAgICAgY2hvaWNlIHRhcmdldC1mZWMgew0KPiA+ID4gPiAg ICAgICAgICAgIGNhc2UgaXAtcHJlZml4IHsNCj4gPiA+ID4gICAgICAgICAgICAgIGxlYWYgaXAt YWRkcmVzcyB7DQo+ID4gPiA+ICAgICAgICAgICAgICAgIHR5cGUgaW5ldDppcC1hZGRyZXNzOw0K PiA+ID4gPiAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiSVB2NC9JUHY2IFByZWZpeCI7DQo+ ID4gPiA+IHdoZXJlIGlwLWFkZHJlc3MgaGFzIG5vIGNvbmNlcHQgb2YgcHJlZml4IGxlbmd0aCBo b3cgY2FuIHRoYXQgYmUNCj4gPiA+ID4gY29uZmlndXJlZD8uDQo+ID4gPiA+DQo+ID4gPiA+IFRo ZXJlIGFyZSBtYW55IHN1Y2ggaW5zdGFuY2VzIElNSE87IGhhdmluZyByZWZlcmVuY2VzIGluIHRo ZQ0KWUFORw0KPiA+IG1vZHVsZQ0KPiA+ID4gPiB0byBzZWN0aW9ucyBvZiBSRkM4MDI5IHdvdWxk IG1ha2UgdGhpcyBtb3JlIGFwcGFyZW50Lg0KPiA+ID4gPg0KPiA+ID4gPiBUb20gUGV0Y2gNCj4g PiA+ID4NCj4gPiA+ID4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiA+ID4gPiBGcm9t OiAiTG9hIEFuZGVyc3NvbiIgPGxvYUBwaS5udT4NCj4gPiA+ID4gVG86IDxtcGxzQGlldGYub3Jn Pg0KPiA+ID4gPiBDYzogPG1wbHMtY2hhaXJzQGlldGYub3JnPjsNCj4gPiA+ID4gPGRyYWZ0LXpo ZW5nLW1wbHMtbHNwLXBpbmcteWFuZy1jZmdAaWV0Zi5vcmc+DQo+ID4gPiA+IFNlbnQ6IFdlZG5l c2RheSwgRmVicnVhcnkgMjAsIDIwMTkgNTozNSBBTQ0KPiA+ID4gPg0KPiA+ID4gPj4gV29ya2lu ZyBHcm91cCwNCj4gPiA+ID4+DQo+ID4gPiA+PiBUaGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsg cG9sbCBvbiBhZG9wdGluZw0KPiA+ID4gPj4gZHJhZnQtemhlbmctbXBscy1sc3AtcGluZy15YW5n LWNmZy0xMA0KPiA+ID4gPj4gYXMgYSBNUExTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQo+ID4g PiA+Pg0KPiA+ID4gPj4gUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyAoc3VwcG9ydC9ub3Qgc3Vw cG9ydCkgdG8gdGhlIG1wbHMNCndvcmtpbmcNCj4gPiA+ID4+IGdyb3VwIG1haWxpbmcgbGlzdCAo bXBsc0BpZXRmLm9yZykuIFBsZWFzZSBnaXZlIGEgdGVjaG5pY2FsDQo+ID4gPiA+PiBtb3RpdmF0 aW9uIGZvciB5b3VyIHN1cHBvcnQvbm90IHN1cHBvcnQsIGVzcGVjaWFsbHkgaWYgeW91DQp0aGlu aw0KPiA+IHRoYXQNCj4gPiA+ID4+IHRoZSBkb2N1bWVudCBzaG91bGQgbm90IGJlIGFkb3B0ZWQg YXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KPiA+ID4gPj4NCj4gPiA+ID4+IFdlIGhhdmUg ZG9uZSBhbiBJUFIgcG9sbCBmb3IgdGhpcyBkb2N1bWVudC4gQWxsIHRoZSBjby1hdXRob3JzDQpo YXZlDQo+ID4gPiA+PiByZXNwb25kZWQgdG8gdGhlIElQUiBwb2xsIHRoYXQgdGhleSBhcmUgdW5h d2FyZSBvZiBhbnkgSVBScw0KdGhhdA0KPiA+ID4gPiByZWxhdGVzDQo+ID4gPiA+PiB0byB0aGlz IGRyYWZ0Lg0KPiA+ID4gPj4NCj4gPiA+ID4+IEFsbCwgdGhlIGNvbnRyaWJ1dG9ycyAod2l0aCBv bmUgZXhjZXB0aW9uKSBoYXZlIHJlc3BvbmRlZCB0bw0KdGhlDQo+ID4gSVBSDQo+ID4gPiA+PiBw b2xsIHRoYXQgdGhleSBhcmUgdW5hd2FyZSBvZiBhbnkgSVBScyB0aGF0IHJlbGF0ZXMgdG8gdGhp cw0KZHJhZnQuDQo+ID4gPiA+Pg0KPiA+ID4gPj4gVGhlIGNvbnRyaWJ1dG9yIHRoYXQgaGFzIG5v dCByZXNwb25kZWQgaGFzIGxlZnQgaGlzIGZvcm1lcg0KPiA+IGVtcGxveW1lbnQNCj4gPiA+ID4+ IGFuZCBpcyBubyBsb25nZXIgb24gdGhlIE1QTFMgd2cgbWFpbGluZyBsaXN0LiBUaGUgd2cgY2hh aXJzIGhhcw0KPiA+ID4gPiBkZWNpZGVkDQo+ID4gPiA+PiB0byBnbyBhaGVhZCB3aXRoIHRoZSB3 Z2FwLiBJZiB0aGVyZSBpcyBhbnkgY29uY2VybnMgYWJvdXQgdGhpcywNCj4gPiBwbGVhc2UNCj4g PiA+ID4+IHNwZWFrIHVwIGluIHRoZSBtYWlsaW5nIGxpc3QuDQo+ID4gPiA+Pg0KPiA+ID4gPj4g VGhlcmUgYXJlIG5vIElQUiBkaXNjbG9zdXJlcyBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQuDQo+ID4g PiA+Pg0KPiA+ID4gPj4gVGhlIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gcG9sbCBlbmRzIE1hcmNo IDYsIDIwMTkuDQo+ID4gPiA+Pg0KPiA+ID4gPj4gL0xvYQ0KPiA+ID4gPj4NCj4gPiA+ID4+IG1w bHMgd2cgY28tY2hhaXINCj4gPiA+ID4+IC0tDQo+ID4gPiA+Pg0KPiA+ID4gPj4NCj4gPiA+ID4+ IExvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQHBpLm51DQo+ ID4gPiA+PiBTZW5pb3IgTVBMUyBFeHBlcnQNCj4gPiA+ID4+IEJyb256ZSBEcmFnb24gQ29uc3Vs dGluZyAgICAgICAgICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KPiA+ID4gPj4NCj4gPiA+ ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g PiA+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+ID4gPj4gbXBsc0BpZXRmLm9yZw0KPiA+ID4gPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4gPiA+DQo+ID4g Pg0KPiA+ID4gLS0NCj4gPiA+DQo+ID4gPg0KPiA+ID4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAg ICAgICAgICAgICAgIGVtYWlsOiBsb2FAcGkubnUNCj4gPiA+IFNlbmlvciBNUExTIEV4cGVydA0K PiA+ID4gQnJvbnplIERyYWdvbiBDb25zdWx0aW5nICAgICAgICAgICAgIHBob25lOiArNDYgNzM5 IDgxIDIxIDY0DQo+ID4NCj4gPg0KPg0KDQo= From nobody Fri Feb 22 17:25: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 15774130EB0; Fri, 22 Feb 2019 17:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 CLKDXiB2bdfu; Fri, 22 Feb 2019 17:25:14 -0800 (PST) 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 E809B12D4E7; Fri, 22 Feb 2019 17:25:13 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id i5so2254832qkd.13; Fri, 22 Feb 2019 17:25:13 -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=9Ef8uLW3ZLsLWHBuz0f68IRLAEaO+akIaI7uIifOi7M=; b=c/mveP4aH1vfdHFT9TLHXNDEbtyBSsSeUI/83nOJYOqZazlblRTbyZri72SH2Fuse1 A3VidQ7hsDPhJdt29ew8/V6NN9tDfmavahWoTSjis7f1JUzVsESzyGAaEz1IeCRdphzd sD5kaH13fQjW+836PHGDADszwJh3+R0GvWaEsjfFKJ7HHWW/P1rmdHU2sAFKzBa/0wra 9+0WRE2osdqKYZhvtkA4FF2oRPYeNp/DKv2dB8aIjgiKP+RB8gCxX0YM2bxTlEg/yQ5L ZbdMHUF4yeoZ27iaiOislu9t3J5dfQ57waWTbGVBOnWtkWuSWBH5JoL3+XdSyIkMVfk8 E0cQ== 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=9Ef8uLW3ZLsLWHBuz0f68IRLAEaO+akIaI7uIifOi7M=; b=q0llbonRwf9+fchp+MqkofazIKnGQuHYT8Ve5kFXb9WaluopPb7ioa/IoiRmNTioMU CiHT3UuhH39jTM1JNetN1Tl8pJcisbSYOjNFbF2L0q3pOUAprbIhuknOwnSSYQX34/Yl GnLgF/d3BJ9jQbvCMjFbc/wQJkXpfQRzfCwy5uRdqy1WbfJAqjuc/5WLtJYp6BdpvJif uCoQSIZNgRCiGchifLXTtzVDPjXvjo+Q7AW3hUh/eAR75PduEgcLUKw1a86JHyJq/Uoc jcJlVYvy2NB3WkurzERNKMrRk8cEltqhEDOV4ncBm7Y6SDtBB5EIPOr4H81si/f0/BBQ cPQw== X-Gm-Message-State: AHQUAuZdhhIfp3D219N2r6mnRxTPaNuqTeRB8jfXjo//y0s9cXYM6SAF gvPkpgMnp/OYU57c4nwOP0BDqC+ZOYvPm4dbvQ== X-Google-Smtp-Source: AHgI3IZZ5bPM37JNUQl/eoaR12g+KEfGOIs52cSfz8d+Z03qcJl3H551/qYLqFtnrjJuLG0Mw1ksBpqF/RKAw7DEyiA= X-Received: by 2002:a37:c442:: with SMTP id h2mr4932918qkm.53.1550885112590; Fri, 22 Feb 2019 17:25:12 -0800 (PST) MIME-Version: 1.0 References: <0980ce7c-047c-519f-e7d5-98d32b498482@pi.nu> <9419b7d7-87ef-151f-5ed8-b0f78c6e83af@gmail.com> <050301d4c590$445f5d50$cd1e17f0$@com> In-Reply-To: From: Rakesh Gandhi Date: Fri, 22 Feb 2019 20:25:00 -0500 Message-ID: To: Greg Mirsky Cc: Weiqiang Cheng , mpls@ietf.org, spring , Alexander Vainshtein , draft-cheng-spring-mpls-path-segment@ietf.org, Stewart Bryant , Loa Andersson Content-Type: multipart/alternative; boundary="00000000000039367b058285947d" Archived-At: Subject: Re: [mpls] [spring] to progress draft-cheng-spring-mpls-path-segment 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, 23 Feb 2019 01:25:18 -0000 --00000000000039367b058285947d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Greg, I am not sure if the question has been answered. I would think GAL is at the bottom of the label stack. Thanks, Rakesh On Sat, Feb 16, 2019 at 4:24 PM Greg Mirsky wrote: > Hi Weiqiang Cheng, > thank you for your expedient response to my questions. The document state= s > that one of the use cases for the Path segment is to be used as a > performance, packet loss and/or delay, measurement session identifier. I > think that RFC 6374 is the most suitable for PM OAM in SR-MPLS environmen= t. > Of course, the type of the encapsulated message can be identified using t= he > destination UDP port number with IP/UDP encapsulation. But another option > is to use G-ACh encapsulation. That would require the use of GAL. And tha= t > is how I've arrived at my original question (I should have explained it > better, my apologies): > > How the Path segment and GAL are placed relative to each other in the > SR-MPLS label stack? > > Regards, > Greg > > On Fri, Feb 15, 2019 at 4:40 PM Weiqiang Cheng < > chengweiqiang@chinamobile.com> wrote: > >> Hi Greg, >> >> Thanks a lot for your comments. >> >> My comments are in-line. >> >> >> >> B.R. >> >> Weiqiang Cheng >> >> >> >> *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Greg Mirsky [mailto:gregimirsky@gmail.com= ] >> *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2019=E5=B9=B42=E6=9C=8815=E6=97= =A5 3:37 >> *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Alexander Vainshtein >> *=E6=8A=84=E9=80=81:* spring@ietf.org; Stewart Bryant; >> draft-cheng-spring-mpls-path-segment@ietf.org; mpls@ietf.org; Loa >> Andersson >> *=E4=B8=BB=E9=A2=98:* Re: [spring] to progress draft-cheng-spring-mpls-p= ath-segment >> >> >> >> Dear All, >> >> I concur with all what has been said in support of the adoption of this >> draft by SPRING WG. The document is well-written, addresses the real >> problem in SR-MPLS, and the proposed solution is technically viable. >> >> My comments and questions are entirely for further discussion: >> >> - would the draft be expanded to demonstrate how "the Path Segment >> may be used to identify an SR-MPLS Policy, its Candidate-Path (CP) or= a SID >> List (SL)"? >> >> [Weiqiang] Yes, It is necessary and we will add some text to demonstrate >> this in the future version. >> >> - as many use cases for the Path Segment are related to OAM >> operations, it would be helpful to expand on the use of GAL and the P= ath >> Segment. >> >> [Weiqiang] It is always helpful to have more use cases. However, >> The GAL is used today in MPLS-TP LSPs to flag the G-Ach and is used for = OAM >> packets only while the Path segment is used for data packets for the eac= h >> traffic flow. It is a little bit different. >> >> Regards, >> >> Greg >> >> >> >> On Thu, Feb 14, 2019 at 1:12 AM Alexander Vainshtein < >> Alexander.Vainshtein@ecitele..com > >> wrote: >> >> +1. >> >> >> >> I have been following this draft from its -00 revision. The current >> revision has resolved most of the issues I (and others) have been raised >> (e.g., elimination of excessive options). >> >> >> >> From my POV, in its current state the draft meets two basic requirements >> for the WG adoption: >> >> 1. It addresses a real and relevant problem, namely the MPLS Flow >> Identification problem discussed in general in RFC 8372 >> and scoped to SR-MPLS LSPs in this >> draft. Specifics of SR-MPLS include the need to provide end-to-end liven= ess >> check that is one of the requirements explicitly specified in Section 2 = of RFC >> 8355 . >> >> 2. It provides a reasonable (from my POV) approach to solution of >> this problem. >> >> >> >> I also concur with Stewart=E2=80=99s comment about strong similarity bet= ween the >> approach taken in this draft for SR-MPLS and generic work in progress on >> synonymous flow labels >> that has >> been already adopted as a MPLS WG item. To me this is yet another >> indication that the draft should be adopted. >> >> >> >> My 2c, >> >> Sasha >> >> >> >> Office: +972-39266302 >> >> Cell: +972-549266302 >> >> Email: Alexander.Vainshtein@ecitele.com >> >> >> >> -----Original Message----- >> From: spring On Behalf Of Stewart Bryant >> Sent: Wednesday, February 13, 2019 12:48 PM >> To: Loa Andersson >; spring@ietf.org; >> draft-cheng-spring-mpls-path-segment@ietf.org >> Subject: Re: [spring] to progress draft-cheng-spring-mpls-path-segment >> >> >> >> I have just read the draft and agree that it should be adopted by the WG= . >> It solves an important problem in instrumenting and protecting an SR pat= h. >> >> >> >> It should be noted that we needed to do something very similar in >> mainstream MPLS via the synonymous label work which is already adopted. >> >> However SL did not address the SR case.. We therefore need this path >> label work to be progressed. >> >> >> >> - Stewart >> >> >> >> On 10/02/2019 08:11, Loa Andersson wrote: >> >> > Working Group, >> >> > >> >> > I have reviewed draft-cheng-spring-mpls-path-segment and as far as I >> >> > can see, it is ready for wg adoption. >> >> > >> >> > There were some comments in Bangkok, but due to the many collisions >> >> > between working groups at that meeting I couldn't attend the SPRING >> >> > f2f. >> >> > >> >> > The minutes are not clear, but as far as I understand, there is >> >> > nothing that can't be resolved in the wg process. >> >> > >> >> > /Loa >> >> >> >> _______________________________________________ >> >> spring mailing list >> >> spring@ietf.org >> >> https://www..ietf.org/mailman/listinfo/spring >> >> >> >> ________________________________________________________________________= ___ >> >> 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 the= n >> delete the original >> and all copies thereof. >> >> ________________________________________________________________________= ___ >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> >> _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --00000000000039367b058285947d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Greg,

I am not sure if th= e question has been answered. I would think GAL is at the bottom of the lab= el stack.

Thanks,
Rakesh

<= /div>

On Sat, Feb 16, 2019 at 4:24 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi=C2=A0Weiqiang C= heng,
thank you for your expedient response to my questions. The docume= nt states that one of the use cases for the Path segment is to be used as a= performance, packet loss and/or delay, measurement session identifier. I t= hink that RFC 6374 is the most suitable for PM OAM in SR-MPLS environment. = Of course, the type of the encapsulated=C2=A0message can be identified usin= g the destination UDP port number with IP/UDP encapsulation. But another op= tion is to use G-ACh encapsulation. That would require the use of GAL. And = that is how I've arrived at my original question (I should have explain= ed it better, my apologies):
How the Path segment and GAL = are placed relative to each other in the SR-MPLS label stack?
Regards,
Greg

On Fri, Feb 15, 2019 at 4:= 40 PM Weiqiang Cheng <chengweiqiang@chinamobile.com> wrote:
Hi Greg,=

Thanks a lot for your c= omments.

My comments are in-line.

=C2=A0

B.R.

Weiqiang Cheng

=C2=A0

=E5=8F=91=E4=BB= =B6=E4=BA=BA: Greg Mirsky [mailto:gregimirsky@gmail.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 20= 19=E5=B9=B42=E6=9C=8815=E6=97=A5 3:= 37
=E6=94=B6=E4=BB=B6=E4=BA=BA: Alexander Vainshtein
=E6=8A=84=E9=80=81= : spring@ietf.org; Stewart Bryant; draft-cheng-spring-mpls-path-segment@ietf.org; mpls@ietf.org; Loa Andersson
=E4=B8=BB=E9=A2=98: R= e: [spring] to progress draft-cheng-spring-mpls-path-segment<= /span>

= =C2=A0

Dear All,

= I concur with all what has been said in support of the= adoption of this draft by SPRING WG. The document is well-written, address= es the real problem in SR-MPLS, and the proposed solution is technically vi= able.

My comments and questions are entirely for further discussion:

  • would the=C2=A0draft be expanded to demonstrate how &= quot;the Path Segment may be used to identify an SR-MPLS Policy, its Candid= ate-Path (CP) or a SID List (SL)"?

[Weiq= iang] Yes, It is necessary and=C2=A0we will add some text to demonstrate th= is in the future version.

  • as many use cases for the Path Segme= nt are related to OAM operations, it would be helpful to expand on the use = of GAL and the Path Segment.

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 =C2=A0[Weiqiang] It is always= helpful to have more use cases. However, The GAL is used today in MPLS-TP = LSPs to flag the G-Ach and is used for OAM packets only while the Path segm= ent is used for data packets for the each traffic flow. It is a little bit = different.

Regards,

Greg

=C2=A0<= /u>

On Thu,= Feb 14, 2019 at 1:12 AM Alexander Vainshtein <Alexander.Vainshtein@ecitele..= com> wrote:

+1.

=C2=A0

I have been following this dr= aft from its -00 revision. The current revision has resolved most of the is= sues I (and others) have been raised (e.g., elimination of excessive option= s).

=C2=A0

From my POV, in its current state the draft meets two basic re= quirements for the WG adoption:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 It addresses a real and relevant problem, namely the MPLS Flow Identificat= ion problem discussed in general in RFC 8372 and scoped to SR-MPLS LSPs in this = draft. Specifics of SR-MPLS include the need to provide end-to-end liveness= check that is one of the requirements explicitly specified in Section 2 of= RFC 8355= .

2.=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 It provides a reasonable = (from my POV) approach to =C2=A0solution of this problem.

=C2=A0=

I also c= oncur with Stewart=E2=80=99s comment about strong similarity between the ap= proach taken in this draft for SR-MPLS and generic work in = progress on synonymous flow labels that has been already adopted as a M= PLS WG item.=C2=A0 To me this is yet another indication that the draft shou= ld be adopted.

=C2=A0

My 2c,

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.Va= inshtein@ecitele.com

=C2=A0

-----Original Message-----
From: sprin= g <spring-b= ounces@ietf.org> On Behalf Of Stewart Bryant
Sent: Wednesday, Feb= ruary 13, 2019 12:48 PM
To: Loa Andersson <loa@pi..nu>; spring@ietf.org; draft-cheng-spring-mpls-pat= h-segment@ietf.org
Subject: Re: [spring] to progress draft-cheng-spr= ing-mpls-path-segment

=C2=A0

I have just read the draft and agree that it= should be adopted by the WG. It solves an important problem in instrumenti= ng and protecting an SR path.

=C2=A0

It should be noted that we needed to= do something very similar in mainstream MPLS via the synonymous label work= which is already adopted.

However SL did not address the SR case.. We th= erefore need this path label work to be progressed.

=C2=A0

- Stewart

=C2= =A0

On 10/02/2019 08:11, Loa Andersson wrote:

> Working Group,<= u>

>= =C2=A0

> I have reviewed draft-cheng-spring-mpls-path-segment and as fa= r as I

> can see, it is ready for wg adoption.<= /p>

>=C2=A0=

> The= re were some comments in Bangkok, but due to the many collisions =

> bet= ween working groups at that meeting I couldn't attend the SPRING

>= f2f.

>=C2=A0

> The minutes are not clear, but as far as I understa= nd, there is

> nothing that can't be resolved in the wg process.

= >=C2=A0

> /Loa

=C2=A0

____________________________________________= ___

spring mailing list

spring@ietf.org

https://w= ww..ietf.org/mailman/listinfo/spring


________________________= ___________________________________________________

This e-mail mess= age is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rec= eived 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://ww= w.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--00000000000039367b058285947d-- From nobody Fri Feb 22 18:16:11 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 765E0129AA0; Fri, 22 Feb 2019 18:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001, URIBL_DBL_SPAM=2.5] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vJpVlWWNpxJ; Fri, 22 Feb 2019 18:16:00 -0800 (PST) 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 6DBD41293B1; Fri, 22 Feb 2019 18:16:00 -0800 (PST) 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 3C372180157E; Sat, 23 Feb 2019 03:15:56 +0100 (CET) To: Rakesh Gandhi , Greg Mirsky Cc: Weiqiang Cheng , mpls@ietf.org, spring , Alexander Vainshtein , draft-cheng-spring-mpls-path-segment@ietf.org, Stewart Bryant References: <0980ce7c-047c-519f-e7d5-98d32b498482@pi.nu> <9419b7d7-87ef-151f-5ed8-b0f78c6e83af@gmail.com> <050301d4c590$445f5d50$cd1e17f0$@com> From: Loa Andersson Message-ID: <9d7a2690-6ef4-438a-6ca8-0548ad2aca0e@pi.nu> Date: Sat, 23 Feb 2019 10:15:50 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 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] [spring] to progress draft-cheng-spring-mpls-path-segment 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, 23 Feb 2019 02:16:04 -0000 Rakesh, authors, I have not been thinking about this too much. But if you look at fig 2 of draft-cheng-spring-mpls-path-segment, and you need a GACh between A and D, I'd say that the GAL will be at the bottom of stack. What if you need the CACh for the sub-path B to C, where will the GAL go? /Loa On 2019-02-23 09:25, Rakesh Gandhi wrote: > Hi Greg, > > I am not sure if the question has been answered. I would think GAL is at > the bottom of the label stack. > > Thanks, > Rakesh > > > On Sat, Feb 16, 2019 at 4:24 PM Greg Mirsky > wrote: > > Hi Weiqiang Cheng, > thank you for your expedient response to my questions. The document > states that one of the use cases for the Path segment is to be used > as a performance, packet loss and/or delay, measurement session > identifier. I think that RFC 6374 is the most suitable for PM OAM in > SR-MPLS environment. Of course, the type of the encapsulated message > can be identified using the destination UDP port number with IP/UDP > encapsulation. But another option is to use G-ACh encapsulation. > That would require the use of GAL. And that is how I've arrived at > my original question (I should have explained it better, my apologies): > > How the Path segment and GAL are placed relative to each other > in the SR-MPLS label stack? > > Regards, > Greg > > On Fri, Feb 15, 2019 at 4:40 PM Weiqiang Cheng > > wrote: > > Hi Greg,____ > > Thanks a lot for your comments.____ > > My comments are in-line.____ > > __ __ > > B.R.____ > > Weiqiang Cheng____ > > __ __ > > *发件人:*Greg Mirsky [mailto:gregimirsky@gmail.com > ] > *发送时间:*2019年2月15日3:37 > *收件人:*Alexander Vainshtein > *抄送:*spring@ietf.org ; Stewart Bryant; > draft-cheng-spring-mpls-path-segment@ietf.org > ; > mpls@ietf.org ; Loa Andersson > *主题:*Re: [spring] to progress > draft-cheng-spring-mpls-path-segment____ > > __ __ > > Dear All,____ > > I concur with all what has been said in support of the adoption > of this draft by SPRING WG. The document is well-written, > addresses the real problem in SR-MPLS, and the proposed solution > is technically viable.____ > > My comments and questions are entirely for further discussion:____ > > * would the draft be expanded to demonstrate how "the Path > Segment may be used to identify an SR-MPLS Policy, its > Candidate-Path (CP) or a SID List (SL)"?____ > > [Weiqiang] Yes, It is necessary and we will add some text to > demonstrate this in the future version. ____ > > * as many use cases for the Path Segment are related to OAM > operations, it would be helpful to expand on the use of GAL > and the Path Segment.____ > > [Weiqiang] It is always helpful to have more use cases. However, > The GAL is used today in MPLS-TP LSPs to flag the G-Ach and is > used for OAM packets only while the Path segment is used for > data packets for the each traffic flow. It is a little bit > different. ____ > > Regards,____ > > Greg____ > > __ __ > > On Thu, Feb 14, 2019 at 1:12 AM Alexander Vainshtein > > wrote:____ > > +1.____ > > ____ > > I have been following this draft from its -00 revision. The > current revision has resolved most of the issues I (and > others) have been raised (e.g., elimination of excessive > options).____ > > ____ > > From my POV, in its current state the draft meets two basic > requirements for the WG adoption:____ > > 1.It addresses a real and relevant problem, namely the MPLS > Flow Identification problem discussed in general in RFC 8372 > and scoped to SR-MPLS > LSPs in this draft. Specifics of SR-MPLS include the need to > provide end-to-end liveness check that is one of the > requirements explicitly specified in Section 2 of RFC 8355 > . ____ > > 2.It provides a reasonable (from my POV) approach to >  solution of this problem.____ > > ____ > > I also concur with Stewart’s comment about strong similarity > between the approach taken in this draft for SR-MPLS and > generic work in progress on synonymous flow labels > > that has been already adopted as a MPLS WG item.  To me this > is yet another indication that the draft should be adopted.____ > > ____ > > My 2c,____ > > Sasha____ > > ____ > > Office: +972-39266302____ > > Cell:      +972-549266302____ > > Email: Alexander.Vainshtein@ecitele.com > ____ > > ____ > > -----Original Message----- > From: spring > On Behalf Of Stewart Bryant > Sent: Wednesday, February 13, 2019 12:48 PM > To: Loa Andersson >; > spring@ietf.org ; > draft-cheng-spring-mpls-path-segment@ietf.org > > Subject: Re: [spring] to progress > draft-cheng-spring-mpls-path-segment____ > > ____ > > I have just read the draft and agree that it should be > adopted by the WG. It solves an important problem in > instrumenting and protecting an SR path.____ > > ____ > > It should be noted that we needed to do something very > similar in mainstream MPLS via the synonymous label work > which is already adopted. ____ > > However SL did not address the SR case.. We therefore need > this path label work to be progressed.____ > > ____ > > - Stewart____ > > ____ > > On 10/02/2019 08:11, Loa Andersson wrote:____ > > > Working Group,____ > > > ____ > > > I have reviewed draft-cheng-spring-mpls-path-segment and as far as I ____ > > > can see, it is ready for wg adoption.____ > > > ____ > > > There were some comments in Bangkok, but due to the many collisions ____ > > > between working groups at that meeting I couldn't attend the SPRING ____ > > > f2f.____ > > > ____ > > > The minutes are not clear, but as far as I understand, there is ____ > > > nothing that can't be resolved in the wg process.____ > > > ____ > > > /Loa____ > > ____ > > ___________________________________________________ > > spring mailing list____ > > spring@ietf.org ____ > > https://www..ietf.org/mailman/listinfo/spring____ > > > ___________________________________________________________________________ > > 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____ > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Fri Feb 22 19:56: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 BAC40130EBD; Fri, 22 Feb 2019 19:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 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, URIBL_DBL_SPAM=2.5] autolearn=no 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 7NtFJVdRWczE; Fri, 22 Feb 2019 19:56:01 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E7B71288BD; Fri, 22 Feb 2019 19:56:00 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id m11so3215018lfc.6; Fri, 22 Feb 2019 19:56:00 -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=++F7H6NcceQJXOwjR5Ml6zlNL91pRWIGtNW0SEe8Krc=; b=f3eXBtZAaBQTvoaL2ScUkP3arbrGwavuMEmIrbtTvdIvy5gvcbWb6tTVgCOSda2t0O bl4JWI3wML5z9VAeZ1kyo2YwPGs2gQU4hRxVZ5Wxdp4rjTEAhkzYCkk5o57E8fFrfud9 WTCFDdP0Nimknbf1TxMUPRlKmCxhKM4LlcppttVV6sqVdo/eG2M+scd63YJhd6qrLdKk 7uO6Purc2M6thFwRa2imZB3fxhr8OCC4CBlTMPER0HEQeWCPtz4N9Zp2GRA991Kaegqr GOzunb10ikB+mOTuh/fAD9pgvee8Asqc/oSAKs1BUbP4Guze5nt8bmrA7sR5KwhtgSJ3 4X/Q== 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=++F7H6NcceQJXOwjR5Ml6zlNL91pRWIGtNW0SEe8Krc=; b=GyJKIKIen9d2dv6FvjnZqq4MXe+itwjKzx6YDMCGC7nxO+cqfZXAqmnduWojXLIaaM NJUv5HvfjV8dFyNKu+cEwZWFoVk8K033IyW08sYT8qnmQxDIxZtXpR0L7JIVrM5VRABt zs/uVPhhSDVi160ZiIIRWkUxhtXo1mCjZS1P9D+ANy6uh9odUDHatMy82c0aYsx2g1/p R6m8b/XQM/b2zgvsum53zPtsgv2M0ITtyxP8b8UzGbDcg4+MErCbCs6puBlKW4RgPe0V 41n4p4/OmDb7G3ZXNT8HIb5Z+8nL1pXFwT6nt4r2J2I/3FomK7kGmLOjXsQtoEL7yt3C BmbQ== X-Gm-Message-State: AHQUAuagvG2EBhDCXEP6zB1IATATitU87o0YfJIf1WwHfUc85R5ld7tH zPT/9q3bmJyof4tU4yhc7tmox4lVIjATnyzOrwM= X-Google-Smtp-Source: AHgI3IYGHwiwF5kS5oZ0T+HtYZqQ9eh9vQNWkNAVPJ8cvn2JJJ+riZWT2UH7HAk9nZsWkxpWcTl8Gci9PsbRaICPrp0= X-Received: by 2002:a19:260e:: with SMTP id m14mr4548024lfm.158.1550894158065; Fri, 22 Feb 2019 19:55:58 -0800 (PST) MIME-Version: 1.0 References: <0980ce7c-047c-519f-e7d5-98d32b498482@pi.nu> <9419b7d7-87ef-151f-5ed8-b0f78c6e83af@gmail.com> <050301d4c590$445f5d50$cd1e17f0$@com> <9d7a2690-6ef4-438a-6ca8-0548ad2aca0e@pi.nu> In-Reply-To: <9d7a2690-6ef4-438a-6ca8-0548ad2aca0e@pi.nu> From: Greg Mirsky Date: Fri, 22 Feb 2019 19:55:49 -0800 Message-ID: To: Loa Andersson Cc: Rakesh Gandhi , Weiqiang Cheng , mpls@ietf.org, spring , Alexander Vainshtein , draft-cheng-spring-mpls-path-segment@ietf.org, Stewart Bryant Content-Type: multipart/alternative; boundary="000000000000603427058287af50" Archived-At: Subject: Re: [mpls] [spring] to progress draft-cheng-spring-mpls-path-segment 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, 23 Feb 2019 03:56:04 -0000 --000000000000603427058287af50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Loa, I think it will be similar to SPME and we'll need to have another SR-tunnel B-C with its own Path segment allocated by node C. But GAL will still be BoS. Regards, Greg. On Fri, Feb 22, 2019 at 6:15 PM Loa Andersson wrote: > Rakesh, authors, > > I have not been thinking about this too much. But if you look at fig 2 > of draft-cheng-spring-mpls-path-segment, and you need a GACh between > A and D, I'd say that the GAL will be at the bottom of stack. > > What if you need the CACh for the sub-path B to C, where will the GAL > go? > > /Loa > > > > On 2019-02-23 09:25, Rakesh Gandhi wrote: > > Hi Greg, > > > > I am not sure if the question has been answered. I would think GAL is a= t > > the bottom of the label stack. > > > > Thanks, > > Rakesh > > > > > > On Sat, Feb 16, 2019 at 4:24 PM Greg Mirsky > > wrote: > > > > Hi Weiqiang Cheng, > > thank you for your expedient response to my questions. The document > > states that one of the use cases for the Path segment is to be used > > as a performance, packet loss and/or delay, measurement session > > identifier. I think that RFC 6374 is the most suitable for PM OAM i= n > > SR-MPLS environment. Of course, the type of the encapsulated messag= e > > can be identified using the destination UDP port number with IP/UDP > > encapsulation. But another option is to use G-ACh encapsulation. > > That would require the use of GAL. And that is how I've arrived at > > my original question (I should have explained it better, my > apologies): > > > > How the Path segment and GAL are placed relative to each other > > in the SR-MPLS label stack? > > > > Regards, > > Greg > > > > On Fri, Feb 15, 2019 at 4:40 PM Weiqiang Cheng > > > > wrote: > > > > Hi Greg,____ > > > > Thanks a lot for your comments.____ > > > > My comments are in-line.____ > > > > __ __ > > > > B.R.____ > > > > Weiqiang Cheng____ > > > > __ __ > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:*Greg Mirsky [mailto:gregimirsky@g= mail.com > > ] > > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:*2019=E5=B9=B42=E6=9C=881= 5=E6=97=A53:37 > > *=E6=94=B6=E4=BB=B6=E4=BA=BA:*Alexander Vainshtein > > *=E6=8A=84=E9=80=81:*spring@ietf.org ; = Stewart Bryant; > > draft-cheng-spring-mpls-path-segment@ietf.org > > ; > > mpls@ietf.org ; Loa Andersson > > *=E4=B8=BB=E9=A2=98:*Re: [spring] to progress > > draft-cheng-spring-mpls-path-segment____ > > > > __ __ > > > > Dear All,____ > > > > I concur with all what has been said in support of the adoption > > of this draft by SPRING WG. The document is well-written, > > addresses the real problem in SR-MPLS, and the proposed solutio= n > > is technically viable.____ > > > > My comments and questions are entirely for further > discussion:____ > > > > * would the draft be expanded to demonstrate how "the Path > > Segment may be used to identify an SR-MPLS Policy, its > > Candidate-Path (CP) or a SID List (SL)"?____ > > > > [Weiqiang] Yes, It is necessary and we will add some text to > > demonstrate this in the future version. ____ > > > > * as many use cases for the Path Segment are related to OAM > > operations, it would be helpful to expand on the use of GAL > > and the Path Segment.____ > > > > [Weiqiang] It is always helpful to have more use cases. However= , > > The GAL is used today in MPLS-TP LSPs to flag the G-Ach and is > > used for OAM packets only while the Path segment is used for > > data packets for the each traffic flow. It is a little bit > > different. ____ > > > > Regards,____ > > > > Greg____ > > > > __ __ > > > > On Thu, Feb 14, 2019 at 1:12 AM Alexander Vainshtein > > > > wrote:____ > > > > +1.____ > > > > ____ > > > > I have been following this draft from its -00 revision. The > > current revision has resolved most of the issues I (and > > others) have been raised (e.g., elimination of excessive > > options).____ > > > > ____ > > > > From my POV, in its current state the draft meets two basi= c > > requirements for the WG adoption:____ > > > > 1.It addresses a real and relevant problem, namely the MPLS > > Flow Identification problem discussed in general in RFC 837= 2 > > and scoped to SR-MPLS > > LSPs in this draft. Specifics of SR-MPLS include the need t= o > > provide end-to-end liveness check that is one of the > > requirements explicitly specified in Section 2 of RFC 8355 > > . ____ > > > > 2.It provides a reasonable (from my POV) approach to > > solution of this problem.____ > > > > ____ > > > > I also concur with Stewart=E2=80=99s comment about strong s= imilarity > > between the approach taken in this draft for SR-MPLS and > > generic work in progress on synonymous flow labels > > < > https://tools.ietf.org/html/draft-ietf-mpls-sfl-framework-04> > > that has been already adopted as a MPLS WG item. To me thi= s > > is yet another indication that the draft should be > adopted.____ > > > > ____ > > > > My 2c,____ > > > > Sasha____ > > > > ____ > > > > Office: +972-39266302____ > > > > Cell: +972-549266302____ > > > > Email: Alexander.Vainshtein@ecitele.com > > ____ > > > > ____ > > > > -----Original Message----- > > From: spring > > On Behalf Of Stewart > Bryant > > Sent: Wednesday, February 13, 2019 12:48 PM > > To: Loa Andersson >; > > spring@ietf.org ; > > draft-cheng-spring-mpls-path-segment@ietf.org > > > > Subject: Re: [spring] to progress > > draft-cheng-spring-mpls-path-segment____ > > > > ____ > > > > I have just read the draft and agree that it should be > > adopted by the WG. It solves an important problem in > > instrumenting and protecting an SR path.____ > > > > ____ > > > > It should be noted that we needed to do something very > > similar in mainstream MPLS via the synonymous label work > > which is already adopted. ____ > > > > However SL did not address the SR case.. We therefore need > > this path label work to be progressed.____ > > > > ____ > > > > - Stewart____ > > > > ____ > > > > On 10/02/2019 08:11, Loa Andersson wrote:____ > > > > > Working Group,____ > > > > > ____ > > > > > I have reviewed draft-cheng-spring-mpls-path-segment and > as far as I ____ > > > > > can see, it is ready for wg adoption.____ > > > > > ____ > > > > > There were some comments in Bangkok, but due to the many > collisions ____ > > > > > between working groups at that meeting I couldn't attend > the SPRING ____ > > > > > f2f.____ > > > > > ____ > > > > > The minutes are not clear, but as far as I understand, > there is ____ > > > > > nothing that can't be resolved in the wg process.____ > > > > > ____ > > > > > /Loa____ > > > > ____ > > > > ___________________________________________________ > > > > spring mailing list____ > > > > spring@ietf.org ____ > > > > https://www..ietf.org/mailman/listinfo/spring____ > > > > > > > ________________________________________________________________________= ___ > > > > This e-mail message is intended for the recipient only and > > contains information which is > > CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f > > you have received this > > transmission in error, please inform us by e-mail, phone or > > fax, and then delete the original > > and all copies thereof. > > > ________________________________________________________________________= _______ > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring____ > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > > > -- > > > Loa Andersson email: loa@pi.nu > Senior MPLS Expert > Bronze Dragon Consulting phone: +46 739 81 21 64 > --000000000000603427058287af50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Loa,
I think it will be similar to SPME and we'= ll need to have another SR-tunnel B-C with its own Path segment allocated b= y node C. But GAL will still be BoS.

Regards,
Greg.=C2=A0

On Fri, Feb 22, 2019 at 6:15 PM Loa Andersson <loa@pi.nu> wrote:
Rakesh, authors,

I have not been thinking about this too much. But if you look at fig 2
of draft-cheng-spring-mpls-path-segment, and you need a GACh between
A and D, I'd say that the GAL will be at the bottom of stack.

What if you need the CACh for the sub-path B to C, where will the GAL
go?

/Loa



On 2019-02-23 09:25, Rakesh Gandhi wrote:
> Hi Greg,
>
> I am not sure if the question has been answered. I would think GAL is = at
> the bottom of the label stack.
>
> Thanks,
> Rakesh
>
>
> On Sat, Feb 16, 2019 at 4:24 PM Greg Mirsky <gregimirsky@gmail.com
> <mailto:= gregimirsky@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi=C2=A0Weiqiang Cheng,
>=C2=A0 =C2=A0 =C2=A0thank you for your expedient response to my questio= ns. The document
>=C2=A0 =C2=A0 =C2=A0states that one of the use cases for the Path segme= nt is to be used
>=C2=A0 =C2=A0 =C2=A0as a performance, packet loss and/or delay, measure= ment session
>=C2=A0 =C2=A0 =C2=A0identifier. I think that RFC 6374 is the most suita= ble for PM OAM in
>=C2=A0 =C2=A0 =C2=A0SR-MPLS environment. Of course, the type of the enc= apsulated=C2=A0message
>=C2=A0 =C2=A0 =C2=A0can be identified using the destination UDP port nu= mber with IP/UDP
>=C2=A0 =C2=A0 =C2=A0encapsulation. But another option is to use G-ACh e= ncapsulation.
>=C2=A0 =C2=A0 =C2=A0That would require the use of GAL. And that is how = I've arrived at
>=C2=A0 =C2=A0 =C2=A0my original question (I should have explained it be= tter, my apologies):
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0How the Path segment and GAL are plac= ed relative to each other
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the SR-MPLS label stack?
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0Greg
>
>=C2=A0 =C2=A0 =C2=A0On Fri, Feb 15, 2019 at 4:40 PM Weiqiang Cheng
>=C2=A0 =C2=A0 =C2=A0<chengweiqiang@chinamobile.com
>=C2=A0 =C2=A0 =C2=A0<mailto:chengweiqiang@chinamobile.com>> wrote:=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Greg,____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks a lot for your comments.____ >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0My comments are in-line.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0B.R.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Weiqiang Cheng____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=E5=8F=91=E4=BB=B6=E4=BA=BA:*Greg Mi= rsky [mailto:gre= gimirsky@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com>]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4= :*2019=E5=B9=B42=E6=9C=8815=E6=97=A53:37
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=E6=94=B6=E4=BB=B6=E4=BA=BA:*Alexand= er Vainshtein
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=E6=8A=84=E9=80=81:*spring@ietf.org <mailto:spring@ietf.org>; Stew= art Bryant;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-cheng-spring-mpls-path-= segment@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:draft-cheng-spring= -mpls-path-segment@ietf.org>;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mpls@ietf.org <mailto:mpls@ietf.org>; Loa Andersson
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=E4=B8=BB=E9=A2=98:*Re: [spring] to = progress
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-cheng-spring-mpls-path-segment_= ___
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dear All,____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I concur with all what has been said = in support of the adoption
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of this draft by SPRING WG. The docum= ent is well-written,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0addresses the real problem in SR-MPLS= , and the proposed solution
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is technically viable.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0My comments and questions are entirel= y for further discussion:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* would the=C2=A0draft be expa= nded to demonstrate how "the Path
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Segment may be used to = identify an SR-MPLS Policy, its
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Candidate-Path (CP) or = a SID List (SL)"?____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Weiqiang] Yes, It is necessary and= =C2=A0we will add some text to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0demonstrate this in the future versio= n. ____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* as many use cases for the Pa= th Segment are related to OAM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0operations, it would be= helpful to expand on the use of GAL
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and the Path Segment.__= __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Weiqiang] It is always helpful to ha= ve more use cases. However,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The GAL is used today in MPLS-TP LSPs= to flag the G-Ach and is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0used for OAM packets only while the P= ath segment is used for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0data packets for the each traffic flo= w. It is a little bit
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0different. ____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards,____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Greg____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Thu, Feb 14, 2019 at 1:12 AM Alexa= nder Vainshtein
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<Alexander.Vainshtein@ecitele..com=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein@ecitele.co= m>> wrote:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+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=A0I have been following t= his draft from its -00 revision. The
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0current revision has re= solved most of the issues I (and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0others) have been raise= d (e.g., elimination of excessive
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0options).____
>
>=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 From my POV, in its cu= rrent state the draft meets two basic
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0requirements for the WG= adoption:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01.It addresses a real a= nd relevant problem, namely the MPLS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Flow Identification pro= blem discussed in general in RFC 8372
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://t= ools.ietf.org/html/rfc8372> and scoped to SR-MPLS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LSPs in this draft. Spe= cifics of SR-MPLS include the need to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0provide end-to-end live= ness check that is one of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0requirements explicitly= specified in Section 2 of RFC 8355
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://t= ools.ietf.org/html/rfc8355>. ____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02.It provides a reasona= ble (from my POV) approach to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0solution of this= problem.____
>
>=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=A0I also concur with Stew= art=E2=80=99s comment about strong similarity
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0between the approach ta= ken in this draft for SR-MPLS and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0generic work in progres= s on synonymous flow labels
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://tools.ietf.org/html/draft-ietf-mpls-sfl-framework-0= 4>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that has been already a= dopted as a MPLS WG item.=C2=A0 To me this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is yet another indicati= on that the draft should be adopted.____
>
>=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=A0My 2c,____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sasha____
>
>=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=A0Office: +972-39266302__= __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cell:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 +972-549266302____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Email: Alexander.Vainshtein@= ecitele.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainsht= ein@ecitele.com>____
>
>=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-----Original Message--= ---
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0From: spring <spring-bounces@ietf.= org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:spring-bounces@ietf.org>> On Behalf Of Stewart Bryant
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sent: Wednesday, Februa= ry 13, 2019 12:48 PM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To: Loa Andersson <l= oa@pi..nu <mailto:loa@pi.= nu>>;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spring@ietf.org <mailto:spring@ietf.org>;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-cheng-spr= ing-mpls-path-segment@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:draf= t-cheng-spring-mpls-path-segment@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subject: Re: [spring] t= o progress
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-cheng-spring-mpls= -path-segment____
>
>=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=A0I have just read the dr= aft and agree that it should be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0adopted by the WG. It s= olves an important problem in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0instrumenting and prote= cting an SR path.____
>
>=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=A0It should be noted that= we needed to do something very
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0similar in mainstream M= PLS via the synonymous label work
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0which is already adopte= d. ____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0However SL did not addr= ess the SR case.. We therefore need
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this path label work to= be progressed.____
>
>=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- Stewart____
>
>=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=A0On 10/02/2019 08:11, Lo= a Andersson wrote:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Working Group,____=
>
>=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> I have reviewed dr= aft-cheng-spring-mpls-path-segment and as far as I ____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> can see, it is rea= dy for wg adoption.____
>
>=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> There were some co= mments in Bangkok, but due to the many collisions ____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> between working gr= oups at that meeting I couldn't attend the SPRING ____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> f2f.____
>
>=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> The minutes are no= t clear, but as far as I understand, there is ____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> nothing that can&#= 39;t be resolved in the wg process.____
>
>=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> /Loa____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________________= ____________________________
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spring mailing list____=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spring@ietf.org <mailto:spring@ietf.org>____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www..i= etf.org/mailman/listinfo/spring____
>
>
>=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=A0This e-mail message is = intended for the recipient only and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0contains information wh= ich is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CONFIDENTIAL and which = may be proprietary to ECI Telecom. If
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0you have received this<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transmission in error, = please inform us by e-mail, phone or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fax, and then delete th= e original
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and all copies thereof.=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________________= ________________________________________________________
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________________= ________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spring mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://www.ietf.org/mailman/listinfo/spring____
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0spring mailing list
>=C2=A0 =C2=A0 =C2=A0spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/lis= tinfo/spring
>

--


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
--000000000000603427058287af50-- From nobody Fri Feb 22 20:15: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 C54E6128B33; Fri, 22 Feb 2019 20:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001, URIBL_DBL_SPAM=2.5] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCRtQB-Rahks; Fri, 22 Feb 2019 20:15:35 -0800 (PST) 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 794781288BD; Fri, 22 Feb 2019 20:15:35 -0800 (PST) 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 6F6D4180157E; Sat, 23 Feb 2019 05:15:31 +0100 (CET) To: Greg Mirsky Cc: mpls@ietf.org, spring , Alexander Vainshtein , Weiqiang Cheng , Rakesh Gandhi , draft-cheng-spring-mpls-path-segment@ietf.org, Stewart Bryant References: <0980ce7c-047c-519f-e7d5-98d32b498482@pi.nu> <9419b7d7-87ef-151f-5ed8-b0f78c6e83af@gmail.com> <050301d4c590$445f5d50$cd1e17f0$@com> <9d7a2690-6ef4-438a-6ca8-0548ad2aca0e@pi.nu> From: Loa Andersson Message-ID: <13cb42a8-e298-c3cc-d116-219f144f5357@pi.nu> Date: Sat, 23 Feb 2019 12:15:26 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 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] [spring] to progress draft-cheng-spring-mpls-path-segment 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, 23 Feb 2019 04:15:38 -0000 Greg, We are close, though I hope the rules are that GAL is bottom of stack, and that a packet with a GACh does not carry user payload. I should have said that "if you want a GACg for the I don't understand why we need a "new" SR tunnel, the GAL/GACh can ride with the GAL as bottom of stack with the label stack for Sub-path(B->C), right? If you put it on "another" tunnel, how do you guarantee fate sharing? /Loa /Loa On 2019-02-23 11:55, Greg Mirsky wrote: > Hi Loa, > I think it will be similar to SPME and we'll need to have another > SR-tunnel B-C with its own Path segment allocated by node C. But GAL > will still be BoS. > > Regards, > Greg. > > On Fri, Feb 22, 2019 at 6:15 PM Loa Andersson > wrote: > > Rakesh, authors, > > I have not been thinking about this too much. But if you look at fig 2 > of draft-cheng-spring-mpls-path-segment, and you need a GACh between > A and D, I'd say that the GAL will be at the bottom of stack. > > What if you need the CACh for the sub-path B to C, where will the GAL > go? > > /Loa > > > > On 2019-02-23 09:25, Rakesh Gandhi wrote: > > Hi Greg, > > > > I am not sure if the question has been answered. I would think > GAL is at > > the bottom of the label stack. > > > > Thanks, > > Rakesh > > > > > > On Sat, Feb 16, 2019 at 4:24 PM Greg Mirsky > > > >> wrote: > > > >     Hi Weiqiang Cheng, > >     thank you for your expedient response to my questions. The > document > >     states that one of the use cases for the Path segment is to > be used > >     as a performance, packet loss and/or delay, measurement session > >     identifier. I think that RFC 6374 is the most suitable for PM > OAM in > >     SR-MPLS environment. Of course, the type of the > encapsulated message > >     can be identified using the destination UDP port number with > IP/UDP > >     encapsulation. But another option is to use G-ACh encapsulation. > >     That would require the use of GAL. And that is how I've > arrived at > >     my original question (I should have explained it better, my > apologies): > > > >         How the Path segment and GAL are placed relative to each > other > >         in the SR-MPLS label stack? > > > >     Regards, > >     Greg > > > >     On Fri, Feb 15, 2019 at 4:40 PM Weiqiang Cheng > >      > >      >> wrote: > > > >         Hi Greg,____ > > > >         Thanks a lot for your comments.____ > > > >         My comments are in-line.____ > > > >         __ __ > > > >         B.R.____ > > > >         Weiqiang Cheng____ > > > >         __ __ > > > >         *发件人:*Greg Mirsky [mailto:gregimirsky@gmail.com > > >          >] > >         *发送时间:*2019年2月15日3:37 > >         *收件人:*Alexander Vainshtein > >         *抄送:*spring@ietf.org > >; Stewart Bryant; > > draft-cheng-spring-mpls-path-segment@ietf.org > > >          >; > > mpls@ietf.org >; Loa Andersson > >         *主题:*Re: [spring] to progress > >         draft-cheng-spring-mpls-path-segment____ > > > >         __ __ > > > >         Dear All,____ > > > >         I concur with all what has been said in support of the > adoption > >         of this draft by SPRING WG. The document is well-written, > >         addresses the real problem in SR-MPLS, and the proposed > solution > >         is technically viable.____ > > > >         My comments and questions are entirely for further > discussion:____ > > > >           * would the draft be expanded to demonstrate how "the Path > >             Segment may be used to identify an SR-MPLS Policy, its > >             Candidate-Path (CP) or a SID List (SL)"?____ > > > >         [Weiqiang] Yes, It is necessary and we will add some text to > >         demonstrate this in the future version. ____ > > > >           * as many use cases for the Path Segment are related to OAM > >             operations, it would be helpful to expand on the use > of GAL > >             and the Path Segment.____ > > > >         [Weiqiang] It is always helpful to have more use cases. > However, > >         The GAL is used today in MPLS-TP LSPs to flag the G-Ach > and is > >         used for OAM packets only while the Path segment is used for > >         data packets for the each traffic flow. It is a little bit > >         different. ____ > > > >         Regards,____ > > > >         Greg____ > > > >         __ __ > > > >         On Thu, Feb 14, 2019 at 1:12 AM Alexander Vainshtein > >          >          >> wrote:____ > > > >             +1.____ > > > >             ____ > > > >             I have been following this draft from its -00 > revision. The > >             current revision has resolved most of the issues I (and > >             others) have been raised (e.g., elimination of excessive > >             options).____ > > > >             ____ > > > >              From my POV, in its current state the draft meets > two basic > >             requirements for the WG adoption:____ > > > >             1.It addresses a real and relevant problem, namely > the MPLS > >             Flow Identification problem discussed in general in > RFC 8372 > >              and scoped to > SR-MPLS > >             LSPs in this draft. Specifics of SR-MPLS include the > need to > >             provide end-to-end liveness check that is one of the > >             requirements explicitly specified in Section 2 of RFC > 8355 > >             . ____ > > > >             2.It provides a reasonable (from my POV) approach to > >               solution of this problem.____ > > > >             ____ > > > >             I also concur with Stewart’s comment about strong > similarity > >             between the approach taken in this draft for SR-MPLS and > >             generic work in progress on synonymous flow labels > > >   > >             that has been already adopted as a MPLS WG item.  To > me this > >             is yet another indication that the draft should be > adopted.____ > > > >             ____ > > > >             My 2c,____ > > > >             Sasha____ > > > >             ____ > > > >             Office: +972-39266302____ > > > >             Cell:      +972-549266302____ > > > >             Email: Alexander.Vainshtein@ecitele.com > > >              >____ > > > >             ____ > > > >             -----Original Message----- > >             From: spring > >              >> On Behalf Of Stewart Bryant > >             Sent: Wednesday, February 13, 2019 12:48 PM > >             To: Loa Andersson >>; > > spring@ietf.org >; > > draft-cheng-spring-mpls-path-segment@ietf.org > > >              > > >             Subject: Re: [spring] to progress > >             draft-cheng-spring-mpls-path-segment____ > > > >             ____ > > > >             I have just read the draft and agree that it should be > >             adopted by the WG. It solves an important problem in > >             instrumenting and protecting an SR path.____ > > > >             ____ > > > >             It should be noted that we needed to do something very > >             similar in mainstream MPLS via the synonymous label work > >             which is already adopted. ____ > > > >             However SL did not address the SR case.. We therefore > need > >             this path label work to be progressed.____ > > > >             ____ > > > >             - Stewart____ > > > >             ____ > > > >             On 10/02/2019 08:11, Loa Andersson wrote:____ > > > >             > Working Group,____ > > > >             > ____ > > > >             > I have reviewed > draft-cheng-spring-mpls-path-segment and as far as I ____ > > > >             > can see, it is ready for wg adoption.____ > > > >             > ____ > > > >             > There were some comments in Bangkok, but due to the > many collisions ____ > > > >             > between working groups at that meeting I couldn't > attend the SPRING ____ > > > >             > f2f.____ > > > >             > ____ > > > >             > The minutes are not clear, but as far as I > understand, there is ____ > > > >             > nothing that can't be resolved in the wg process.____ > > > >             > ____ > > > >             > /Loa____ > > > >             ____ > > > >             ___________________________________________________ > > > >             spring mailing list____ > > > > spring@ietf.org >____ > > > > https://www..ietf.org/mailman/listinfo/spring____ > > > > > > > >  ___________________________________________________________________________ > > > >             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____ > > > >     _______________________________________________ > >     spring mailing list > > spring@ietf.org > > > https://www.ietf.org/mailman/listinfo/spring > > > > -- > > > Loa Andersson                        email: loa@pi.nu > Senior MPLS Expert > Bronze Dragon Consulting             phone: +46 739 81 21 64 > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Fri Feb 22 20:31:48 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 6AA80128B33; Fri, 22 Feb 2019 20:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 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, URIBL_DBL_SPAM=2.5] autolearn=no 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 P3Xhd_BGzk52; Fri, 22 Feb 2019 20:31:36 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 A72691228B7; Fri, 22 Feb 2019 20:31:35 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id g2so3225899lfh.11; Fri, 22 Feb 2019 20:31: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=kuSPtQN4RDzVHDf+ZHsA/pUMyR1qmlU7LCgc35R3wSA=; b=ohVxUbzDF9cGnIKXgVBXgfw155OcV8BN85JXsZk3edzuOhBQuoxKkLsSf9YMTQE0aq A4S7V27Lw7WEUSt2AM/IBL1YDhnILWS4o4cnu+wkJUtKl/CK5WLIYF2NL33VtBwel616 1rf1arYhRgFnk/sQ6i/Dh/zaow3Qd+uucJxRRWMZ9yjlcKDAJ6ZC4ksEHPVyUmas55ZC 3w8XXvkjzJN+G8BUzM9mk50EvzaRWzj6Xi2z1hQNafX7ZSrUXu1N09LFpFgPuUEreVFm pgs34wxyi4DKkdLXFXlzS1DiqfvFtrRy2uHUGXWVb5FIhfdyF3/xm6YKxVfg2fUCKCxk 4Lyw== 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=kuSPtQN4RDzVHDf+ZHsA/pUMyR1qmlU7LCgc35R3wSA=; b=DllajXTz9UUcJ6/zbesC5DwlWG1g/M9AsoBJ94wRQ5k6wqNqNujBWoQMmsxV8Mi1MX lfohwBQog5RnMNmy6X+9sVhwmklgtxwyZYkuMNg7DwmHNRn9V72xNW6hcQ8BgzXHwp1a iiZkZ4VPHIa+ihOGOr7yRTgA39BbTDFGcpf+lr68OOoh8lLAekhPmWRxVNI23nBIGFuV C3ld1ILoBp1cuIkWD+NSpZkaPuJKCrJSAi4ORiJqYv9kVa+mExnROodRNalbhoJUrAC+ N8NK3g4xTnXCXJj+uT9VCWfaj9T2nPjtDSaqlE6u+HMJ4erQX9O051wkTB6lxG00Ma24 fFlg== X-Gm-Message-State: AHQUAuZzHEUBWiVAonZzNmvjW1VMTUuKpDhVtHTVzGFxnj4CUIs74PtH FiceKLNbVt4VRR7ZF67NNt8ZG3Si7qGiIdnLbAU= X-Google-Smtp-Source: AHgI3IY6NOZOfV7PdU3Vwn9CSN6ww+cXOSgTUDFvkiePIEeYkhZ4Yz5dHhVmxcaJvLLRQeEK1UBoRYxqPcUXH9vC6C8= X-Received: by 2002:a19:4948:: with SMTP id l8mr4719646lfj.156.1550896293207; Fri, 22 Feb 2019 20:31:33 -0800 (PST) MIME-Version: 1.0 References: <0980ce7c-047c-519f-e7d5-98d32b498482@pi.nu> <9419b7d7-87ef-151f-5ed8-b0f78c6e83af@gmail.com> <050301d4c590$445f5d50$cd1e17f0$@com> <9d7a2690-6ef4-438a-6ca8-0548ad2aca0e@pi.nu> <13cb42a8-e298-c3cc-d116-219f144f5357@pi.nu> In-Reply-To: <13cb42a8-e298-c3cc-d116-219f144f5357@pi.nu> From: Greg Mirsky Date: Fri, 22 Feb 2019 20:31:22 -0800 Message-ID: To: Loa Andersson Cc: mpls@ietf.org, spring , Alexander Vainshtein , Weiqiang Cheng , Rakesh Gandhi , draft-cheng-spring-mpls-path-segment@ietf.org, Stewart Bryant Content-Type: multipart/alternative; boundary="000000000000a3e39c0582882e44" Archived-At: Subject: Re: [mpls] [spring] to progress draft-cheng-spring-mpls-path-segment 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, 23 Feb 2019 04:31:39 -0000 --000000000000a3e39c0582882e44 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Loa, another tunnel with the Path segment from node C is, in my view, very close to SPME tunnel. The Path segment from C is needed because Path segment from D is not known to the node C, cannot be associated with the right SR-tunnel segment, i.e., tunnel B-C. The fate sharing may be achieved by using exactly the same SIDs as in the A-D tunnel for the B-C segment. And GAL is still BoS on B-C tunnel. Are we getting closer? Regards, Greg On Fri, Feb 22, 2019 at 8:15 PM Loa Andersson wrote: > Greg, > > We are close, though I hope the rules are that GAL is bottom of stack, > and that a packet with a GACh does not carry user payload. > > I should have said that "if you want a GACg for the > > I don't understand why we need a "new" SR tunnel, the GAL/GACh can > ride with the GAL as bottom of stack with the label stack for > Sub-path(B->C), right? If you put it on "another" tunnel, how do > you guarantee fate sharing? > > /Loa > > /Loa > > On 2019-02-23 11:55, Greg Mirsky wrote: > > Hi Loa, > > I think it will be similar to SPME and we'll need to have another > > SR-tunnel B-C with its own Path segment allocated by node C. But GAL > > will still be BoS. > > > > Regards, > > Greg. > > > > On Fri, Feb 22, 2019 at 6:15 PM Loa Andersson > > wrote: > > > > Rakesh, authors, > > > > I have not been thinking about this too much. But if you look at fi= g > 2 > > of draft-cheng-spring-mpls-path-segment, and you need a GACh betwee= n > > A and D, I'd say that the GAL will be at the bottom of stack. > > > > What if you need the CACh for the sub-path B to C, where will the G= AL > > go? > > > > /Loa > > > > > > > > On 2019-02-23 09:25, Rakesh Gandhi wrote: > > > Hi Greg, > > > > > > I am not sure if the question has been answered. I would think > > GAL is at > > > the bottom of the label stack. > > > > > > Thanks, > > > Rakesh > > > > > > > > > On Sat, Feb 16, 2019 at 4:24 PM Greg Mirsky > > > > > >> > wrote: > > > > > > Hi Weiqiang Cheng, > > > thank you for your expedient response to my questions. The > > document > > > states that one of the use cases for the Path segment is to > > be used > > > as a performance, packet loss and/or delay, measurement > session > > > identifier. I think that RFC 6374 is the most suitable for P= M > > OAM in > > > SR-MPLS environment. Of course, the type of the > > encapsulated message > > > can be identified using the destination UDP port number with > > IP/UDP > > > encapsulation. But another option is to use G-ACh > encapsulation. > > > That would require the use of GAL. And that is how I've > > arrived at > > > my original question (I should have explained it better, my > > apologies): > > > > > > How the Path segment and GAL are placed relative to each > > other > > > in the SR-MPLS label stack? > > > > > > Regards, > > > Greg > > > > > > On Fri, Feb 15, 2019 at 4:40 PM Weiqiang Cheng > > > > > > > > >> wrote: > > > > > > Hi Greg,____ > > > > > > Thanks a lot for your comments.____ > > > > > > My comments are in-line.____ > > > > > > __ __ > > > > > > B.R.____ > > > > > > Weiqiang Cheng____ > > > > > > __ __ > > > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:*Greg Mirsky [mailto:gregim= irsky@gmail.com > > > > > > >] > > > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:*2019=E5=B9=B42=E6= =9C=8815=E6=97=A53:37 > > > *=E6=94=B6=E4=BB=B6=E4=BA=BA:*Alexander Vainshtein > > > *=E6=8A=84=E9=80=81:*spring@ietf.org > > >; Stewart Bryant; > > > draft-cheng-spring-mpls-path-segment@ietf.org > > > > > > >; > > > mpls@ietf.org > >; Loa Andersson > > > *=E4=B8=BB=E9=A2=98:*Re: [spring] to progress > > > draft-cheng-spring-mpls-path-segment____ > > > > > > __ __ > > > > > > Dear All,____ > > > > > > I concur with all what has been said in support of the > > adoption > > > of this draft by SPRING WG. The document is well-written= , > > > addresses the real problem in SR-MPLS, and the proposed > > solution > > > is technically viable.____ > > > > > > My comments and questions are entirely for further > > discussion:____ > > > > > > * would the draft be expanded to demonstrate how "the > Path > > > Segment may be used to identify an SR-MPLS Policy, i= ts > > > Candidate-Path (CP) or a SID List (SL)"?____ > > > > > > [Weiqiang] Yes, It is necessary and we will add some tex= t > to > > > demonstrate this in the future version. ____ > > > > > > * as many use cases for the Path Segment are related t= o > OAM > > > operations, it would be helpful to expand on the use > > of GAL > > > and the Path Segment.____ > > > > > > [Weiqiang] It is always helpful to have more use cases. > > However, > > > The GAL is used today in MPLS-TP LSPs to flag the G-Ach > > and is > > > used for OAM packets only while the Path segment is used > for > > > data packets for the each traffic flow. It is a little b= it > > > different. ____ > > > > > > Regards,____ > > > > > > Greg____ > > > > > > __ __ > > > > > > On Thu, Feb 14, 2019 at 1:12 AM Alexander Vainshtein > > > > > > >> wrote:____ > > > > > > +1.____ > > > > > > ____ > > > > > > I have been following this draft from its -00 > > revision. The > > > current revision has resolved most of the issues I > (and > > > others) have been raised (e.g., elimination of > excessive > > > options).____ > > > > > > ____ > > > > > > From my POV, in its current state the draft meets > > two basic > > > requirements for the WG adoption:____ > > > > > > 1.It addresses a real and relevant problem, namely > > the MPLS > > > Flow Identification problem discussed in general in > > RFC 8372 > > > and scoped to > > SR-MPLS > > > LSPs in this draft. Specifics of SR-MPLS include the > > need to > > > provide end-to-end liveness check that is one of the > > > requirements explicitly specified in Section 2 of RF= C > > 8355 > > > . ____ > > > > > > 2.It provides a reasonable (from my POV) approach to > > > solution of this problem.____ > > > > > > ____ > > > > > > I also concur with Stewart=E2=80=99s comment about s= trong > > similarity > > > between the approach taken in this draft for SR-MPLS > and > > > generic work in progress on synonymous flow labels > > > > > > > > that has been already adopted as a MPLS WG item. To > > me this > > > is yet another indication that the draft should be > > adopted.____ > > > > > > ____ > > > > > > My 2c,____ > > > > > > Sasha____ > > > > > > ____ > > > > > > Office: +972-39266302____ > > > > > > Cell: +972-549266302____ > > > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > > >____ > > > > > > ____ > > > > > > -----Original Message----- > > > From: spring > > > > > >> On Behalf Of Stewart Bryant > > > Sent: Wednesday, February 13, 2019 12:48 PM > > > To: Loa Andersson > >>; > > > spring@ietf.org > >; > > > draft-cheng-spring-mpls-path-segment@ietf.org > > > > > > > > > > Subject: Re: [spring] to progress > > > draft-cheng-spring-mpls-path-segment____ > > > > > > ____ > > > > > > I have just read the draft and agree that it should = be > > > adopted by the WG. It solves an important problem in > > > instrumenting and protecting an SR path.____ > > > > > > ____ > > > > > > It should be noted that we needed to do something ve= ry > > > similar in mainstream MPLS via the synonymous label > work > > > which is already adopted. ____ > > > > > > However SL did not address the SR case.. We therefor= e > > need > > > this path label work to be progressed.____ > > > > > > ____ > > > > > > - Stewart____ > > > > > > ____ > > > > > > On 10/02/2019 08:11, Loa Andersson wrote:____ > > > > > > > Working Group,____ > > > > > > > ____ > > > > > > > I have reviewed > > draft-cheng-spring-mpls-path-segment and as far as I ____ > > > > > > > can see, it is ready for wg adoption.____ > > > > > > > ____ > > > > > > > There were some comments in Bangkok, but due to th= e > > many collisions ____ > > > > > > > between working groups at that meeting I couldn't > > attend the SPRING ____ > > > > > > > f2f.____ > > > > > > > ____ > > > > > > > The minutes are not clear, but as far as I > > understand, there is ____ > > > > > > > nothing that can't be resolved in the wg > process.____ > > > > > > > ____ > > > > > > > /Loa____ > > > > > > ____ > > > > > > ___________________________________________________ > > > > > > spring mailing list____ > > > > > > spring@ietf.org > >____ > > > > > > https://www..ietf.org/mailman/listinfo/spring____ > > > > > > > > > > > > > > ________________________________________________________________________= ___ > > > > > > 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____ > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > -- > > > > > > Loa Andersson email: loa@pi.nu loa@pi.nu> > > Senior MPLS Expert > > Bronze Dragon Consulting phone: +46 739 81 21 64 > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > > > -- > > > Loa Andersson email: loa@pi.nu > Senior MPLS Expert > Bronze Dragon Consulting phone: +46 739 81 21 64 > --000000000000a3e39c0582882e44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Loa,
another tunnel with the Path = segment from node C is, in my view, very close to SPME tunnel. The Path seg= ment from C is needed because Path segment from D is not known to the node = C, cannot be associated with the right SR-tunnel segment, i.e., tunnel B-C.= The fate sharing may be achieved by using exactly the same SIDs as in the = A-D tunnel for the B-C segment. And GAL is still BoS on B-C tunnel. Are we = getting closer?

Regards,
Greg

On Fr= i, Feb 22, 2019 at 8:15 PM Loa Andersson <l= oa@pi.nu> wrote:
Greg,

We are close, though I hope the rules are that GAL is bottom of stack,
and that a packet with a GACh does not carry user payload.

I should have said that "if you want a GACg for the

I don't understand why we need a "new" SR tunnel, the GAL/GAC= h can
ride with the GAL as bottom of stack with the label stack for
Sub-path(B->C), right? If you put it on "another" tunnel, how = do
you guarantee fate sharing?

/Loa

/Loa

On 2019-02-23 11:55, Greg Mirsky wrote:
> Hi Loa,
> I think it will be similar to SPME and we'll need to have another =
> SR-tunnel B-C with its own Path segment allocated by node C. But GAL <= br> > will still be BoS.
>
> Regards,
> Greg.
>
> On Fri, Feb 22, 2019 at 6:15 PM Loa Andersson <loa@pi.nu
> <mailto:loa@pi.nu>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Rakesh, authors,
>
>=C2=A0 =C2=A0 =C2=A0I have not been thinking about this too much. But i= f you look at fig 2
>=C2=A0 =C2=A0 =C2=A0of draft-cheng-spring-mpls-path-segment, and you ne= ed a GACh between
>=C2=A0 =C2=A0 =C2=A0A and D, I'd say that the GAL will be at the bo= ttom of stack.
>
>=C2=A0 =C2=A0 =C2=A0What if you need the CACh for the sub-path B to C, = where will the GAL
>=C2=A0 =C2=A0 =C2=A0go?
>
>=C2=A0 =C2=A0 =C2=A0/Loa
>
>
>
>=C2=A0 =C2=A0 =C2=A0On 2019-02-23 09:25, Rakesh Gandhi wrote:
>=C2=A0 =C2=A0 =C2=A0 > Hi Greg,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I am not sure if the question has been answer= ed. I would think
>=C2=A0 =C2=A0 =C2=A0GAL is at
>=C2=A0 =C2=A0 =C2=A0 > the bottom of the label stack.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Thanks,
>=C2=A0 =C2=A0 =C2=A0 > Rakesh
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On Sat, Feb 16, 2019 at 4:24 PM Greg Mirsky >=C2=A0 =C2=A0 =C2=A0<gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
>=C2=A0 =C2=A0 =C2=A0 > <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>= >> wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Hi=C2=A0Weiqiang Cheng, >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0thank you for your expedie= nt response to my questions. The
>=C2=A0 =C2=A0 =C2=A0document
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0states that one of the use= cases for the Path segment is to
>=C2=A0 =C2=A0 =C2=A0be used
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0as a performance, packet l= oss and/or delay, measurement session
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0identifier. I think that R= FC 6374 is the most suitable for PM
>=C2=A0 =C2=A0 =C2=A0OAM in
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0SR-MPLS environment. Of co= urse, the type of the
>=C2=A0 =C2=A0 =C2=A0encapsulated=C2=A0message
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0can be identified using th= e destination UDP port number with
>=C2=A0 =C2=A0 =C2=A0IP/UDP
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0encapsulation. But another= option is to use G-ACh encapsulation.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0That would require the use= of GAL. And that is how I've
>=C2=A0 =C2=A0 =C2=A0arrived at
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0my original question (I sh= ould have explained it better, my
>=C2=A0 =C2=A0 =C2=A0apologies):
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0How the Path= segment and GAL are placed relative to each
>=C2=A0 =C2=A0 =C2=A0other
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the SR-MP= LS label stack?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Greg
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On Fri, Feb 15, 2019 at 4:= 40 PM Weiqiang Cheng
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<chengweiqiang@chinamobile.com<= /a>
>=C2=A0 =C2=A0 =C2=A0<mailto:chengweiqiang@chinamobile.com>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:chengweiqiang@chinamobi= le.com
>=C2=A0 =C2=A0 =C2=A0<mailto:chengweiqiang@chinamobile.com>>> wr= ote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Greg,____=
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks a lot= for your comments.____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0My comments = are in-line.____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0B.R.____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Weiqiang Che= ng____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=E5=8F=91= =E4=BB=B6=E4=BA=BA:*Greg Mirsky [mailto:gregimirsky@gmail.com
>=C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:<= a href=3D"mailto:gregimirsky@gmail.com" target=3D"_blank">gregimirsky@gmail= .com
>=C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com>>]
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=E5=8F=91= =E9=80=81=E6=97=B6=E9=97=B4:*2019=E5=B9=B42=E6=9C=8815=E6=97=A53:37
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=E6=94=B6= =E4=BB=B6=E4=BA=BA:*Alexander Vainshtein
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=E6=8A=84= =E9=80=81:*spring@ietf= .org <mailto:sp= ring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>>; Stewart Bryant;
>=C2=A0 =C2=A0 =C2=A0 > draft-cheng-spring-mpls-path-segment@= ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:draft-cheng-spring-mpls-path-seg= ment@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:<= a href=3D"mailto:draft-cheng-spring-mpls-path-segment@ietf.org" target=3D"_= blank">draft-cheng-spring-mpls-path-segment@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:draft-cheng-spring-mpls-path-seg= ment@ietf.org>>;
>=C2=A0 =C2=A0 =C2=A0 > mpls@ietf.org <mailto:mpls@ietf.org> <mailto:mpls@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:mpls@ietf.org>>; Loa Andersson
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=E4=B8=BB= =E9=A2=98:*Re: [spring] to progress
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-cheng-= spring-mpls-path-segment____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dear All,___= _
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I concur wit= h all what has been said in support of the
>=C2=A0 =C2=A0 =C2=A0adoption
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of this draf= t by SPRING WG. The document is well-written,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0addresses th= e real problem in SR-MPLS, and the proposed
>=C2=A0 =C2=A0 =C2=A0solution
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is technical= ly viable.____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0My comments = and questions are entirely for further
>=C2=A0 =C2=A0 =C2=A0discussion:____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* wou= ld the=C2=A0draft be expanded to demonstrate how "the Path
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Segment may be used to identify an SR-MPLS Policy, its
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Candidate-Path (CP) or a SID List (SL)"?____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Weiqiang] Y= es, It is necessary and=C2=A0we will add some text to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0demonstrate = this in the future version. ____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* as = many use cases for the Path Segment are related to OAM
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0operations, it would be helpful to expand on the use
>=C2=A0 =C2=A0 =C2=A0of GAL
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0and the Path Segment.____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Weiqiang] I= t is always helpful to have more use cases.
>=C2=A0 =C2=A0 =C2=A0However,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The GAL is u= sed today in MPLS-TP LSPs to flag the G-Ach
>=C2=A0 =C2=A0 =C2=A0and is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0used for OAM= packets only while the Path segment is used for
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0data packets= for the each traffic flow. It is a little bit
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0different. _= ___
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards,____=
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Greg____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__ __
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Thu, Feb = 14, 2019 at 1:12 AM Alexander Vainshtein
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<Alexande= r.Vainshtein@ecitele..com
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:<= a href=3D"mailto:Alexander.Vainshtein@ecitele.com" target=3D"_blank">Alexan= der.Vainshtein@ecitele.com
>=C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein@ecitele.com>>&= gt; wrote:____
>=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+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 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0I have been following this draft from its -00
>=C2=A0 =C2=A0 =C2=A0revision. The
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0current revision has resolved most of the issues I (and
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0others) have been raised (e.g., elimination of excessive
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0options).____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 From my POV, in its current state the draft meets
>=C2=A0 =C2=A0 =C2=A0two basic
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0requirements for the WG adoption:____
>=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= =A01.It addresses a real and relevant problem, namely
>=C2=A0 =C2=A0 =C2=A0the MPLS
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Flow Identification problem discussed in general in
>=C2=A0 =C2=A0 =C2=A0RFC 8372
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<https://tools.ietf.org/html/rfc8372> and scoped to<= br> >=C2=A0 =C2=A0 =C2=A0SR-MPLS
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0LSPs in this draft. Specifics of SR-MPLS include the
>=C2=A0 =C2=A0 =C2=A0need to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0provide end-to-end liveness check that is one of the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0requirements explicitly specified in Section 2 of RFC
>=C2=A0 =C2=A0 =C2=A08355
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<https://tools.ietf.org/html/rfc8355>. ____
>=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= =A02.It provides a reasonable (from my POV) approach to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0solution of this problem.____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0I also concur with Stewart=E2=80=99s comment about strong
>=C2=A0 =C2=A0 =C2=A0similarity
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0between the approach taken in this draft for SR-MPLS and
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0generic work in progress on synonymous flow labels
>=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<https= ://tools.ietf.org/html/draft-ietf-mpls-sfl-framework-04>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0that has been already adopted as a MPLS WG item.=C2=A0 To
>=C2=A0 =C2=A0 =C2=A0me this
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0is yet another indication that the draft should be
>=C2=A0 =C2=A0 =C2=A0adopted.____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0My 2c,____
>=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= =A0Sasha____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Office: +972-39266302____
>=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= =A0Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302____
>=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= =A0Email: Alexander.Vainshtein@ecitele.com
>=C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein@ecitele.com>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<mailto:Alexander.Vainshtein@ecitele.com
>=C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein@ecitele.com>>_= ___
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0-----Original Message-----
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0From: spring <spring-bounces@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:spring-bounces@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<mailto:= spring-bounces@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:spring-bounces@ietf.org>>> On Behalf Of S= tewart Bryant
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Sent: Wednesday, February 13, 2019 12:48 PM
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0To: Loa Andersson <loa@pi..nu <mailto:loa@pi.nu
>=C2=A0 =C2=A0 =C2=A0<mailto:loa@pi.nu>>>;
>=C2=A0 =C2=A0 =C2=A0 > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org>>;
>=C2=A0 =C2=A0 =C2=A0 > draft-cheng-spring-mpls-path-segment@= ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:draft-cheng-spring-mpls-path-seg= ment@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<mailto:draft-cheng-spring-mpls-path-segment@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:draft-cheng-spring-mpls-path-seg= ment@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Subject: Re: [spring] to progress
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0draft-cheng-spring-mpls-path-segment____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0I have just read the draft and agree that it should be
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0adopted by the WG. It solves an important problem in
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0instrumenting and protecting an SR path.____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0It should be noted that we needed to do something very
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0similar in mainstream MPLS via the synonymous label work
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0which is already adopted. ____
>=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= =A0However SL did not address the SR case.. We therefore
>=C2=A0 =C2=A0 =C2=A0need
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0this path label work to be progressed.____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0- Stewart____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0On 10/02/2019 08:11, Loa Andersson wrote:____
>=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> Working Group,____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> ____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> I have reviewed
>=C2=A0 =C2=A0 =C2=A0draft-cheng-spring-mpls-path-segment and as far as = I ____
>=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> can see, it is ready for wg adoption.____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> ____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> There were some comments in Bangkok, but due to the
>=C2=A0 =C2=A0 =C2=A0many collisions ____
>=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> between working groups at that meeting I couldn't
>=C2=A0 =C2=A0 =C2=A0attend the SPRING ____
>=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> f2f.____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> ____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> The minutes are not clear, but as far as I
>=C2=A0 =C2=A0 =C2=A0understand, there is ____
>=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> nothing that can't be resolved in the wg process.____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> ____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> /Loa____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =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= =A0spring mailing list____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org>>____
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > https://www..ietf.org/mailman/listin= fo/spring____
>=C2=A0 =C2=A0 =C2=A0<http://ietf.org/mailman/listi= nfo/spring____>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0____________________________________________= _______________________________
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0This e-mail message is intended for the recipient
>=C2=A0 =C2=A0 =C2=A0only and
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0contains information which is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0CONFIDENTIAL and which may be proprietary to ECI
>=C2=A0 =C2=A0 =C2=A0Telecom. If
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0you have received this
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0transmission in error, please inform us by e-mail,
>=C2=A0 =C2=A0 =C2=A0phone or
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0fax, and then delete the original
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0and all copies thereof.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0____________________________________________= ___________________________________
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =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= =A0spring mailing list
>=C2=A0 =C2=A0 =C2=A0 > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/m= ailman/listinfo/spring____
>=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=A0spring mailing list
>=C2=A0 =C2=A0 =C2=A0 > spring@ietf.org <mailto:spring@ietf.org> <mailto:spring@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mailm= an/listinfo/spring
>=C2=A0 =C2=A0 =C2=A0 >
>
>=C2=A0 =C2=A0 =C2=A0--
>
>
>=C2=A0 =C2=A0 =C2=A0Loa 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 <mailto:loa@pi.nu>
>=C2=A0 =C2=A0 =C2=A0Senior MPLS Expert
>=C2=A0 =C2=A0 =C2=A0Bronze Dragon Consulting=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring >

--


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
--000000000000a3e39c0582882e44-- From nobody Sat Feb 23 00:16: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 3F89C130E64; Sat, 23 Feb 2019 00:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001, URIBL_DBL_SPAM=2.5] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id budA4k69tYxo; Sat, 23 Feb 2019 00:16:48 -0800 (PST) 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 120411200B3; Sat, 23 Feb 2019 00:16:48 -0800 (PST) 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 B56DF180157E; Sat, 23 Feb 2019 09:16:43 +0100 (CET) To: Greg Mirsky Cc: mpls@ietf.org, spring , Alexander Vainshtein , Weiqiang Cheng , Rakesh Gandhi , draft-cheng-spring-mpls-path-segment@ietf.org, Stewart Bryant References: <0980ce7c-047c-519f-e7d5-98d32b498482@pi.nu> <9419b7d7-87ef-151f-5ed8-b0f78c6e83af@gmail.com> <050301d4c590$445f5d50$cd1e17f0$@com> <9d7a2690-6ef4-438a-6ca8-0548ad2aca0e@pi.nu> <13cb42a8-e298-c3cc-d116-219f144f5357@pi.nu> From: Loa Andersson Message-ID: <886d0aeb-281e-984a-9c9d-645101d4d02b@pi.nu> Date: Sat, 23 Feb 2019 16:16:00 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 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] [spring] to progress draft-cheng-spring-mpls-path-segment 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, 23 Feb 2019 08:16:52 -0000 Greg, On 2019-02-23 12:31, Greg Mirsky wrote: > Hi Loa, > another tunnel with the Path segment from node C is, in my view, very > close to SPME tunnel. The Path segment from C is needed because Path > segment from D is not known to the node C, cannot be associated with the > right SR-tunnel segment, i.e., tunnel B-C. The fate sharing may be > achieved by using exactly the same SIDs as in the A-D tunnel for the B-C > segment. And GAL is still BoS on B-C tunnel. Are we getting closer? Not sure, you lose me somewhere between the "B", "C", "D", "from" and "another". So let me check I was talking about So the stack transporting payload from B-C looks like this: +------------+ ~B->C SubPath~ +------------+ |s-PSID(B->C)| +------------+ | BSID(C->D) | +------------+ |e-PSID(A->D)| +------------+ figure 1 The "~" at the top means that there might be more than one label that can be popped or swapped, right? So the stack transporting GACh from B-C looks like this: +--------------+ ~ B->C SubPath ~ +--------------+ | GAL | +--------------+ | GACh info-1 | +--------------+ | GACh info-2 | +--------------+ figure 2 Now my question is the "B->C SubPath" in the first figure identical to the "B->C SubPath" in the second figure? Now -- > > Regards, > Greg > > On Fri, Feb 22, 2019 at 8:15 PM Loa Andersson > wrote: > > Greg, > > We are close, though I hope the rules are that GAL is bottom of stack, > and that a packet with a GACh does not carry user payload. > > I should have said that "if you want a GACg for the > > I don't understand why we need a "new" SR tunnel, the GAL/GACh can > ride with the GAL as bottom of stack with the label stack for > Sub-path(B->C), right? If you put it on "another" tunnel, how do > you guarantee fate sharing? > > /Loa > > /Loa > > On 2019-02-23 11:55, Greg Mirsky wrote: > > Hi Loa, > > I think it will be similar to SPME and we'll need to have another > > SR-tunnel B-C with its own Path segment allocated by node C. But GAL > > will still be BoS. > > > > Regards, > > Greg. > > > > On Fri, Feb 22, 2019 at 6:15 PM Loa Andersson > > >> wrote: > > > >     Rakesh, authors, > > > >     I have not been thinking about this too much. But if you look > at fig 2 > >     of draft-cheng-spring-mpls-path-segment, and you need a GACh > between > >     A and D, I'd say that the GAL will be at the bottom of stack. > > > >     What if you need the CACh for the sub-path B to C, where will > the GAL > >     go? > > > >     /Loa > > > > > > > >     On 2019-02-23 09:25, Rakesh Gandhi wrote: > >      > Hi Greg, > >      > > >      > I am not sure if the question has been answered. I would think > >     GAL is at > >      > the bottom of the label stack. > >      > > >      > Thanks, > >      > Rakesh > >      > > >      > > >      > On Sat, Feb 16, 2019 at 4:24 PM Greg Mirsky > >      > > > >      > >>> wrote: > >      > > >      >     Hi Weiqiang Cheng, > >      >     thank you for your expedient response to my questions. The > >     document > >      >     states that one of the use cases for the Path segment > is to > >     be used > >      >     as a performance, packet loss and/or delay, > measurement session > >      >     identifier. I think that RFC 6374 is the most suitable > for PM > >     OAM in > >      >     SR-MPLS environment. Of course, the type of the > >     encapsulated message > >      >     can be identified using the destination UDP port > number with > >     IP/UDP > >      >     encapsulation. But another option is to use G-ACh > encapsulation. > >      >     That would require the use of GAL. And that is how I've > >     arrived at > >      >     my original question (I should have explained it > better, my > >     apologies): > >      > > >      >         How the Path segment and GAL are placed relative > to each > >     other > >      >         in the SR-MPLS label stack? > >      > > >      >     Regards, > >      >     Greg > >      > > >      >     On Fri, Feb 15, 2019 at 4:40 PM Weiqiang Cheng > >      >      > >      > > >      >      > >      >>> wrote: > >      > > >      >         Hi Greg,____ > >      > > >      >         Thanks a lot for your comments.____ > >      > > >      >         My comments are in-line.____ > >      > > >      >         __ __ > >      > > >      >         B.R.____ > >      > > >      >         Weiqiang Cheng____ > >      > > >      >         __ __ > >      > > >      >         *发件人:*Greg Mirsky [mailto:gregimirsky@gmail.com > > >     > > >      >          > >     >>] > >      >         *发送时间:*2019年2月15日3:37 > >      >         *收件人:*Alexander Vainshtein > >      >         *抄送:*spring@ietf..org > > > >      > >>; Stewart Bryant; > >      > draft-cheng-spring-mpls-path-segment@ietf.org > > >      > > >      > >   > >      >>; > >      > mpls@ietf.org > > >     >>; Loa Andersson > >      >         *主题:*Re: [spring] to progress > >      >         draft-cheng-spring-mpls-path-segment____ > >      > > >      >         __ __ > >      > > >      >         Dear All,____ > >      > > >      >         I concur with all what has been said in support of the > >     adoption > >      >         of this draft by SPRING WG. The document is > well-written, > >      >         addresses the real problem in SR-MPLS, and the > proposed > >     solution > >      >         is technically viable.____ > >      > > >      >         My comments and questions are entirely for further > >     discussion:____ > >      > > >      >           * would the draft be expanded to demonstrate how > "the Path > >      >             Segment may be used to identify an SR-MPLS > Policy, its > >      >             Candidate-Path (CP) or a SID List (SL)"?____ > >      > > >      >         [Weiqiang] Yes, It is necessary and we will add > some text to > >      >         demonstrate this in the future version. ____ > >      > > >      >           * as many use cases for the Path Segment are > related to OAM > >      >             operations, it would be helpful to expand on > the use > >     of GAL > >      >             and the Path Segment.____ > >      > > >      >         [Weiqiang] It is always helpful to have more use > cases. > >     However, > >      >         The GAL is used today in MPLS-TP LSPs to flag the > G-Ach > >     and is > >      >         used for OAM packets only while the Path segment > is used for > >      >         data packets for the each traffic flow. It is a > little bit > >      >         different. ____ > >      > > >      >         Regards,____ > >      > > >      >         Greg____ > >      > > >      >         __ __ > >      > > >      >         On Thu, Feb 14, 2019 at 1:12 AM Alexander Vainshtein > >      >          >      >          > >      >>> wrote:____ > >      > > >      >             +1.____ > >      > > >      >             ____ > >      > > >      >             I have been following this draft from its -00 > >     revision. The > >      >             current revision has resolved most of the > issues I (and > >      >             others) have been raised (e.g., elimination of > excessive > >      >             options).____ > >      > > >      >             ____ > >      > > >      >              From my POV, in its current state the draft meets > >     two basic > >      >             requirements for the WG adoption:____ > >      > > >      >             1.It addresses a real and relevant problem, namely > >     the MPLS > >      >             Flow Identification problem discussed in > general in > >     RFC 8372 > >      >              and > scoped to > >     SR-MPLS > >      >             LSPs in this draft. Specifics of SR-MPLS > include the > >     need to > >      >             provide end-to-end liveness check that is one > of the > >      >             requirements explicitly specified in Section 2 > of RFC > >     8355 > >      >             . ____ > >      > > >      >             2.It provides a reasonable (from my POV) > approach to > >      >               solution of this problem.____ > >      > > >      >             ____ > >      > > >      >             I also concur with Stewart’s comment about strong > >     similarity > >      >             between the approach taken in this draft for > SR-MPLS and > >      >             generic work in progress on synonymous flow labels > >      > > >        > >      >             that has been already adopted as a MPLS WG > item.  To > >     me this > >      >             is yet another indication that the draft should be > >     adopted.____ > >      > > >      >             ____ > >      > > >      >             My 2c,____ > >      > > >      >             Sasha____ > >      > > >      >             ____ > >      > > >      >             Office: +972-39266302____ > >      > > >      >             Cell:      +972-549266302____ > >      > > >      >             Email: Alexander.Vainshtein@ecitele.com > > >      > > >      >              > >      >>____ > >      > > >      >             ____ > >      > > >      >             -----Original Message----- > >      >             From: spring > >     > > >      >              > >      >>> On Behalf Of Stewart Bryant > >      >             Sent: Wednesday, February 13, 2019 12:48 PM > >      >             To: Loa Andersson > >     >>>; > >      > spring@ietf.org > > > > >     >>; > >      > draft-cheng-spring-mpls-path-segment@ietf.org > > >      > > >      > >   > >      >> > >      >             Subject: Re: [spring] to progress > >      >             draft-cheng-spring-mpls-path-segment____ > >      > > >      >             ____ > >      > > >      >             I have just read the draft and agree that it > should be > >      >             adopted by the WG. It solves an important > problem in > >      >             instrumenting and protecting an SR path.____ > >      > > >      >             ____ > >      > > >      >             It should be noted that we needed to do > something very > >      >             similar in mainstream MPLS via the synonymous > label work > >      >             which is already adopted. ____ > >      > > >      >             However SL did not address the SR case.. We > therefore > >     need > >      >             this path label work to be progressed.____ > >      > > >      >             ____ > >      > > >      >             - Stewart____ > >      > > >      >             ____ > >      > > >      >             On 10/02/2019 08:11, Loa Andersson wrote:____ > >      > > >      >             > Working Group,____ > >      > > >      >             > ____ > >      > > >      >             > I have reviewed > >     draft-cheng-spring-mpls-path-segment and as far as I ____ > >      > > >      >             > can see, it is ready for wg adoption.____ > >      > > >      >             > ____ > >      > > >      >             > There were some comments in Bangkok, but due > to the > >     many collisions ____ > >      > > >      >             > between working groups at that meeting I > couldn't > >     attend the SPRING ____ > >      > > >      >             > f2f.____ > >      > > >      >             > ____ > >      > > >      >             > The minutes are not clear, but as far as I > >     understand, there is ____ > >      > > >      >             > nothing that can't be resolved in the wg > process.____ > >      > > >      >             > ____ > >      > > >      >             > /Loa____ > >      > > >      >             ____ > >      > > >      > >  ___________________________________________________ > >      > > >      >             spring mailing list____ > >      > > >      > spring@ietf.org > > > > >     >>____ > >      > > >      > https://www..ietf.org/mailman/listinfo/spring____ > > >      > >      > > >      > > >      > > > >  ___________________________________________________________________________ > >      > > >      >             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____ > >      > > >      >     _______________________________________________ > >      >     spring mailing list > >      > spring@ietf.org > > > > >     >> > >      > https://www.ietf.org/mailman/listinfo/spring > >      > > > > >     -- > > > > > >     Loa Andersson                        email: loa@pi.nu > > > >     Senior MPLS Expert > >     Bronze Dragon Consulting             phone: +46 739 81 21 64 > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > > > -- > > > Loa Andersson                        email: loa@pi.nu > Senior MPLS Expert > Bronze Dragon Consulting             phone: +46 739 81 21 64 > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Sat Feb 23 08:17: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 687A912958B; Sat, 23 Feb 2019 08:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 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, URIBL_DBL_SPAM=2.5] autolearn=no 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 KwHFNTCxrUEv; Sat, 23 Feb 2019 08:17:26 -0800 (PST) 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 9C0D112426A; Sat, 23 Feb 2019 08:17:25 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id z196so3233656lff.4; Sat, 23 Feb 2019 08:17:25 -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=TE+IhqWup3gNJw00z9WVzdw3CN4hmojA8xZXac/D8IE=; b=NK/fWY7K164Cx0UazVDJ5B/fXsnTWIZZZWus+ZPV9TOi0AUnrkODfu9HGwHukP7MSi +iAYi1l4LyJXuMmOUuGioE3sWYWVQymydn41Xlls5uO7ss1UuuZYCNyq0Rk+ASvhT2O7 v5tfYAnylPjO5kiU1mZGnJaoK7iIUCvf7UV+TgjUXRErA2I2PyzhfGyP0Y57VWhlYYUa 8ZHPplrZ9u2qzFk3ECaNntvS5gyfudBcKKZeALrhg1po6q3bZHldoIwAJBQ9dbCVHwoz BJieVEiKtb5WjwKeEspG0bVQVMEc79lNWZWGsEiBVfJ0sM3eY9hUT0m7+iYDjSxHkgUc qoRA== 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=TE+IhqWup3gNJw00z9WVzdw3CN4hmojA8xZXac/D8IE=; b=SGtuR9LCI9s+klKskJiWmSdtYqX0dXBxJpE1K/gyUjpzrK06oWIaR9hf9S+KVxOK5w p/RbqDTi9WfwRSbCrkNtwZz/gCMLc8Ex+0+gesiRJyLohX4fswX9AnjwDLzzIA+myW1N WIHtb81v/z7j24oJRvZijRTM4yEI5gGsVUrS5oL5nOCYf7GbsuZiDVu0p/eD/1++bZUK 6KohpVSL1mDM6PD8s+rV8K704nMc7cb6N/cFI3vAuWiY/vs+BG99tDCvTqDCC5sXKOWf 16JPq4MGOt8DQfF6WnrbZ2h4XO4VxQZ7fRVwM5C14Btrb/AFgsi0+dTHSYpSVaJKZgWq Hdmw== X-Gm-Message-State: AHQUAuZpUYIcPIPhKLmM7RgR4n1BX9rpEqr8lAFT2oibkhW2ZAP2WsDg Q4r9QbtotWOurbpNxy/xOKK7Nf5JQxdRhaiROcI= X-Google-Smtp-Source: AHgI3Ibdk9V+IgkNTnhMw+vfmkfoNvurkio4zr/7sOQyR+YO1WbfUqVHM2bmkn+9uOBioJRSDI/PQ3yKd6g8fQX/BLY= X-Received: by 2002:a19:f104:: with SMTP id p4mr5538984lfh.37.1550938643067; Sat, 23 Feb 2019 08:17:23 -0800 (PST) MIME-Version: 1.0 References: <0980ce7c-047c-519f-e7d5-98d32b498482@pi.nu> <9419b7d7-87ef-151f-5ed8-b0f78c6e83af@gmail.com> <050301d4c590$445f5d50$cd1e17f0$@com> <9d7a2690-6ef4-438a-6ca8-0548ad2aca0e@pi.nu> <13cb42a8-e298-c3cc-d116-219f144f5357@pi.nu> <886d0aeb-281e-984a-9c9d-645101d4d02b@pi.nu> In-Reply-To: <886d0aeb-281e-984a-9c9d-645101d4d02b@pi.nu> From: Greg Mirsky Date: Sat, 23 Feb 2019 08:17:15 -0800 Message-ID: To: Loa Andersson Cc: mpls@ietf.org, spring , Alexander Vainshtein , Weiqiang Cheng , Rakesh Gandhi , draft-cheng-spring-mpls-path-segment@ietf.org, Stewart Bryant Content-Type: multipart/alternative; boundary="000000000000e378140582920a57" Archived-At: Subject: Re: [mpls] [spring] to progress draft-cheng-spring-mpls-path-segment 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, 23 Feb 2019 16:17:31 -0000 --000000000000e378140582920a57 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Loa, picture is worth a thousand words, thank you! I think that OAM packet on A-D A-D tunnel will be like this: Couple notes: - not sure we need s-PSID(B->C) (assuming it is Path SID for the B-C segment); - encapsulation for an OAM packet on the segment B-C must include s-PSID(B->C); - I agree that B->C SubPath must be the same in both cases. Regards, Greg On Sat, Feb 23, 2019 at 12:16 AM Loa Andersson wrote: > Greg, > > > > On 2019-02-23 12:31, Greg Mirsky wrote: > > Hi Loa, > > another tunnel with the Path segment from node C is, in my view, very > > close to SPME tunnel. The Path segment from C is needed because Path > > segment from D is not known to the node C, cannot be associated with th= e > > right SR-tunnel segment, i.e., tunnel B-C. The fate sharing may be > > achieved by using exactly the same SIDs as in the A-D tunnel for the B-= C > > segment. And GAL is still BoS on B-C tunnel. Are we getting closer? > > Not sure, you lose me somewhere between the "B", "C", "D", "from" and > "another". > > So let me check I was talking about > > So the stack transporting payload from B-C looks like this: > > +------------+ > ~B->C SubPath~ > +------------+ > |s-PSID(B->C)| > +------------+ > | BSID(C->D) | > +------------+ > |e-PSID(A->D)| > +------------+ > figure 1 > > The "~" at the top means that there might be more than one label that > can be popped or swapped, right? > > So the stack transporting GACh from B-C looks like this: > > +--------------+ > ~ B->C SubPath ~ > +--------------+ > | GAL | > +--------------+ > | GACh info-1 | > +--------------+ > | GACh info-2 | > +--------------+ > figure 2 > > Now my question is the "B->C SubPath" in the first figure identical > to the "B->C SubPath" in the second figure? > Now > -- > > > > > > > Regards, > > Greg > > > > On Fri, Feb 22, 2019 at 8:15 PM Loa Andersson > > wrote: > > > > Greg, > > > > We are close, though I hope the rules are that GAL is bottom of > stack, > > and that a packet with a GACh does not carry user payload. > > > > I should have said that "if you want a GACg for the > > > > I don't understand why we need a "new" SR tunnel, the GAL/GACh can > > ride with the GAL as bottom of stack with the label stack for > > Sub-path(B->C), right? If you put it on "another" tunnel, how do > > you guarantee fate sharing? > > > > /Loa > > > > /Loa > > > > On 2019-02-23 11:55, Greg Mirsky wrote: > > > Hi Loa, > > > I think it will be similar to SPME and we'll need to have anothe= r > > > SR-tunnel B-C with its own Path segment allocated by node C. But > GAL > > > will still be BoS. > > > > > > Regards, > > > Greg. > > > > > > On Fri, Feb 22, 2019 at 6:15 PM Loa Andersson > > > > >> wrote: > > > > > > Rakesh, authors, > > > > > > I have not been thinking about this too much. But if you loo= k > > at fig 2 > > > of draft-cheng-spring-mpls-path-segment, and you need a GACh > > between > > > A and D, I'd say that the GAL will be at the bottom of stack= . > > > > > > What if you need the CACh for the sub-path B to C, where wil= l > > the GAL > > > go? > > > > > > /Loa > > > > > > > > > > > > On 2019-02-23 09:25, Rakesh Gandhi wrote: > > > > Hi Greg, > > > > > > > > I am not sure if the question has been answered. I would > think > > > GAL is at > > > > the bottom of the label stack. > > > > > > > > Thanks, > > > > Rakesh > > > > > > > > > > > > On Sat, Feb 16, 2019 at 4:24 PM Greg Mirsky > > > > > > > > > > > > >>> wrote: > > > > > > > > Hi Weiqiang Cheng, > > > > thank you for your expedient response to my questions= . > The > > > document > > > > states that one of the use cases for the Path segment > > is to > > > be used > > > > as a performance, packet loss and/or delay, > > measurement session > > > > identifier. I think that RFC 6374 is the most suitabl= e > > for PM > > > OAM in > > > > SR-MPLS environment. Of course, the type of the > > > encapsulated message > > > > can be identified using the destination UDP port > > number with > > > IP/UDP > > > > encapsulation. But another option is to use G-ACh > > encapsulation. > > > > That would require the use of GAL. And that is how I'= ve > > > arrived at > > > > my original question (I should have explained it > > better, my > > > apologies): > > > > > > > > How the Path segment and GAL are placed relative > > to each > > > other > > > > in the SR-MPLS label stack? > > > > > > > > Regards, > > > > Greg > > > > > > > > On Fri, Feb 15, 2019 at 4:40 PM Weiqiang Cheng > > > > > > > > > > > > > > > > > > > >>> wrote: > > > > > > > > Hi Greg,____ > > > > > > > > Thanks a lot for your comments.____ > > > > > > > > My comments are in-line.____ > > > > > > > > __ __ > > > > > > > > B.R.____ > > > > > > > > Weiqiang Cheng____ > > > > > > > > __ __ > > > > > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:*Greg Mirsky [mailto= :gregimirsky@gmail.com > > > > > = > > > > > > > > > >>>] > > > > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:*2019=E5=B9= =B42=E6=9C=8815=E6=97=A53:37 > > > > *=E6=94=B6=E4=BB=B6=E4=BA=BA:*Alexander Vainshtei= n > > > > *=E6=8A=84=E9=80=81:*spring@ietf..org > > > > > > > > >>; Stewart Bryant; > > > > draft-cheng-spring-mpls-path-segment@ietf.org > > > > > > > > > > > > > > > > > > >>; > > > > mpls@ietf.org > > > > > >>; Loa Andersso= n > > > > *=E4=B8=BB=E9=A2=98:*Re: [spring] to progress > > > > draft-cheng-spring-mpls-path-segment____ > > > > > > > > __ __ > > > > > > > > Dear All,____ > > > > > > > > I concur with all what has been said in support o= f > the > > > adoption > > > > of this draft by SPRING WG. The document is > > well-written, > > > > addresses the real problem in SR-MPLS, and the > > proposed > > > solution > > > > is technically viable.____ > > > > > > > > My comments and questions are entirely for furthe= r > > > discussion:____ > > > > > > > > * would the draft be expanded to demonstrate ho= w > > "the Path > > > > Segment may be used to identify an SR-MPLS > > Policy, its > > > > Candidate-Path (CP) or a SID List (SL)"?____ > > > > > > > > [Weiqiang] Yes, It is necessary and we will add > > some text to > > > > demonstrate this in the future version. ____ > > > > > > > > * as many use cases for the Path Segment are > > related to OAM > > > > operations, it would be helpful to expand on > > the use > > > of GAL > > > > and the Path Segment.____ > > > > > > > > [Weiqiang] It is always helpful to have more use > > cases. > > > However, > > > > The GAL is used today in MPLS-TP LSPs to flag the > > G-Ach > > > and is > > > > used for OAM packets only while the Path segment > > is used for > > > > data packets for the each traffic flow. It is a > > little bit > > > > different. ____ > > > > > > > > Regards,____ > > > > > > > > Greg____ > > > > > > > > __ __ > > > > > > > > On Thu, Feb 14, 2019 at 1:12 AM Alexander > Vainshtein > > > > > > > > > > > > >>> wrote:____ > > > > > > > > +1.____ > > > > > > > > ____ > > > > > > > > I have been following this draft from its -00 > > > revision. The > > > > current revision has resolved most of the > > issues I (and > > > > others) have been raised (e.g., elimination o= f > > excessive > > > > options).____ > > > > > > > > ____ > > > > > > > > From my POV, in its current state the draft > meets > > > two basic > > > > requirements for the WG adoption:____ > > > > > > > > 1.It addresses a real and relevant problem, > namely > > > the MPLS > > > > Flow Identification problem discussed in > > general in > > > RFC 8372 > > > > and > > scoped to > > > SR-MPLS > > > > LSPs in this draft. Specifics of SR-MPLS > > include the > > > need to > > > > provide end-to-end liveness check that is one > > of the > > > > requirements explicitly specified in Section = 2 > > of RFC > > > 8355 > > > > . ____ > > > > > > > > 2.It provides a reasonable (from my POV) > > approach to > > > > solution of this problem.____ > > > > > > > > ____ > > > > > > > > I also concur with Stewart=E2=80=99s comment = about > strong > > > similarity > > > > between the approach taken in this draft for > > SR-MPLS and > > > > generic work in progress on synonymous flow > labels > > > > > > > < > https://tools.ietf.org/html/draft-ietf-mpls-sfl-framework-04> > > > > that has been already adopted as a MPLS WG > > item. To > > > me this > > > > is yet another indication that the draft > should be > > > adopted.____ > > > > > > > > ____ > > > > > > > > My 2c,____ > > > > > > > > Sasha____ > > > > > > > > ____ > > > > > > > > Office: +972-39266302____ > > > > > > > > Cell: +972-549266302____ > > > > > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > > > > > > > > > > > > >>____ > > > > > > > > ____ > > > > > > > > -----Original Message----- > > > > From: spring > > > > spring-bounces@ietf.org>> > > > > > > > > > >>> On Behalf Of Stewart Bryant > > > > Sent: Wednesday, February 13, 2019 12:48 PM > > > > To: Loa Andersson > > > > >>>; > > > > spring@ietf.org > > > > > > > > >>; > > > > draft-cheng-spring-mpls-path-segment@ietf.org > > > > > > > > > > > > > > > > > > >> > > > > Subject: Re: [spring] to progress > > > > draft-cheng-spring-mpls-path-segment____ > > > > > > > > ____ > > > > > > > > I have just read the draft and agree that it > > should be > > > > adopted by the WG. It solves an important > > problem in > > > > instrumenting and protecting an SR path.____ > > > > > > > > ____ > > > > > > > > It should be noted that we needed to do > > something very > > > > similar in mainstream MPLS via the synonymous > > label work > > > > which is already adopted. ____ > > > > > > > > However SL did not address the SR case.. We > > therefore > > > need > > > > this path label work to be progressed.____ > > > > > > > > ____ > > > > > > > > - Stewart____ > > > > > > > > ____ > > > > > > > > On 10/02/2019 08:11, Loa Andersson wrote:____ > > > > > > > > > Working Group,____ > > > > > > > > > ____ > > > > > > > > > I have reviewed > > > draft-cheng-spring-mpls-path-segment and as far as I ____ > > > > > > > > > can see, it is ready for wg adoption.____ > > > > > > > > > ____ > > > > > > > > > There were some comments in Bangkok, but du= e > > to the > > > many collisions ____ > > > > > > > > > between working groups at that meeting I > > couldn't > > > attend the SPRING ____ > > > > > > > > > f2f.____ > > > > > > > > > ____ > > > > > > > > > The minutes are not clear, but as far as I > > > understand, there is ____ > > > > > > > > > nothing that can't be resolved in the wg > > process.____ > > > > > > > > > ____ > > > > > > > > > /Loa____ > > > > > > > > ____ > > > > > > > > > > ___________________________________________________ > > > > > > > > spring mailing list____ > > > > > > > > spring@ietf.org > > > > > > > > >>____ > > > > > > > > https://www..ietf.org/mailman/listinfo/spring____ > > > > > > > > > > > > > > > > > > > > > > > ________________________________________________________________________= ___ > > > > > > > > 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____ > > > > > > > > _______________________________________________ > > > > spring mailing list > > > > spring@ietf.org > > > > > > > > >> > > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > > > > -- > > > > > > > > > Loa Andersson email: loa@pi.nu > > > > > > Senior MPLS Expert > > > Bronze Dragon Consulting phone: +46 739 81 21 64 > > > > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > -- > > > > > > Loa Andersson email: loa@pi.nu loa@pi.nu> > > Senior MPLS Expert > > Bronze Dragon Consulting phone: +46 739 81 21 64 > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > > > -- > > > Loa Andersson email: loa@pi.nu > Senior MPLS Expert > Bronze Dragon Consulting phone: +46 739 81 21 64 > --000000000000e378140582920a57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Loa,
picture is worth a thousand w= ords, thank you! I think that OAM packet on A-D A-D tunnel will be like thi= s:
Couple notes:
  • not sure we need=C2=A0 s-PSID(B->C) (assuming it is Path SID for the B-C segment);
  • enca= psulation for an OAM packet on the segment B-C must include=C2=A0 s-PSID(B->C);
  • I agree that=C2=A0 B->C SubPath must be the same in both cases.
<= div>Regards,
Greg

On Sat, Feb 23, 2019 at 12:16 AM Loa Anders= son <loa@pi.nu> wrote:
Greg,



On 2019-02-23 12:31, Greg Mirsky wrote:
> Hi Loa,
> another tunnel with the Path segment from node C is, in my view, very =
> close to SPME tunnel. The Path segment from C is needed because Path <= br> > segment from D is not known to the node C, cannot be associated with t= he
> right SR-tunnel segment, i.e., tunnel B-C. The fate sharing may be > achieved by using exactly the same SIDs as in the A-D tunnel for the B= -C
> segment. And GAL is still BoS on B-C tunnel. Are we getting closer?
Not sure, you lose me somewhere between the "B", "C", &= quot;D", "from" and
"another".

So let me check I was talking about

So the stack transporting payload from B-C looks like this:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0~B->C SubPath~
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|s-PSID(B->C)|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| BSID(C->D) |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|e-PSID(A->D)|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 figure 1

The "~" at the top means that there might be more than one label = that
can be popped or swapped, right?

So the stack transporting GACh from B-C looks like this:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0~ B->C SubPath ~
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0GAL=C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 GACh info-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 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 GACh info-2 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 figure 2

Now my question is the "B->C SubPath" in the first figure iden= tical
to the "B->C SubPath" in the second figure?
Now
--



>
> Regards,
> Greg
>
> On Fri, Feb 22, 2019 at 8:15 PM Loa Andersson <loa@pi.nu
> <mailto:loa@pi.nu>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Greg,
>
>=C2=A0 =C2=A0 =C2=A0We are close, though I hope the rules are that GAL = is bottom of stack,
>=C2=A0 =C2=A0 =C2=A0and that a packet with a GACh does not carry user p= ayload.
>
>=C2=A0 =C2=A0 =C2=A0I should have said that "if you want a GACg fo= r the
>
>=C2=A0 =C2=A0 =C2=A0I don't understand why we need a "new"= ; SR tunnel, the GAL/GACh can
>=C2=A0 =C2=A0 =C2=A0ride with the GAL as bottom of stack with the label= stack for
>=C2=A0 =C2=A0 =C2=A0Sub-path(B->C), right? If you put it on "an= other" tunnel, how do
>=C2=A0 =C2=A0 =C2=A0you guarantee fate sharing?
>
>=C2=A0 =C2=A0 =C2=A0/Loa
>
>=C2=A0 =C2=A0 =C2=A0/Loa
>
>=C2=A0 =C2=A0 =C2=A0On 2019-02-23 11:55, Greg Mirsky wrote:
>=C2=A0 =C2=A0 =C2=A0 > Hi Loa,
>=C2=A0 =C2=A0 =C2=A0 > I think it will be similar to SPME and we'= ;ll need to have another
>=C2=A0 =C2=A0 =C2=A0 > SR-tunnel B-C with its own Path segment alloc= ated by node C. But GAL
>=C2=A0 =C2=A0 =C2=A0 > will still be BoS.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Regards,
>=C2=A0 =C2=A0 =C2=A0 > Greg.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On Fri, Feb 22, 2019 at 6:15 PM Loa Andersson= <loa@pi.nu
>=C2=A0 =C2=A0 =C2=A0<mailto:loa@pi.nu>
>=C2=A0 =C2=A0 =C2=A0 > <mailto:loa@pi.nu <mailto:loa@pi.nu>>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Rakesh, authors,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I have not been thinking a= bout this too much. But if you look
>=C2=A0 =C2=A0 =C2=A0at fig 2
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0of draft-cheng-spring-mpls= -path-segment, and you need a GACh
>=C2=A0 =C2=A0 =C2=A0between
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0A and D, I'd say that = the GAL will be at the bottom of stack.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0What if you need the CACh = for the sub-path B to C, where will
>=C2=A0 =C2=A0 =C2=A0the GAL
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0go?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0/Loa
>=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=A0On 2019-02-23 09:25, Rakes= h Gandhi wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Hi Greg,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > I am not sure if the= question has been answered. I would think
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0GAL is at
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > the bottom of the la= bel stack.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Thanks,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Rakesh
>=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 > On Sat, Feb 16, 2019= at 4:24 PM Greg Mirsky
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<gregimirsky@gmail.com <mailto:<= a href=3D"mailto:gregimirsky@gmail.com" target=3D"_blank">gregimirsky@gmail= .com>
>=C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > <mailto:gregimirsky@gmail.com
>=C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com
>=C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com>>>> wrote:
>=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=A0H= i=C2=A0Weiqiang Cheng,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0t= hank you for your expedient response to my questions. The
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0document
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0s= tates that one of the use cases for the Path segment
>=C2=A0 =C2=A0 =C2=A0is to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0be used
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0a= s a performance, packet loss and/or delay,
>=C2=A0 =C2=A0 =C2=A0measurement session
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0i= dentifier. I think that RFC 6374 is the most suitable
>=C2=A0 =C2=A0 =C2=A0for PM
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0OAM in
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0S= R-MPLS environment. Of course, the type of the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0encapsulated=C2=A0message<= br> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0c= an be identified using the destination UDP port
>=C2=A0 =C2=A0 =C2=A0number with
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0IP/UDP
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0e= ncapsulation. But another option is to use G-ACh
>=C2=A0 =C2=A0 =C2=A0encapsulation.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0T= hat would require the use of GAL. And that is how I've
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0arrived at
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0m= y original question (I should have explained it
>=C2=A0 =C2=A0 =C2=A0better, my
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0apologies):
>=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=A0How the Path segment and GAL are placed relative
>=C2=A0 =C2=A0 =C2=A0to each
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0other
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0in the SR-MPLS label stack?
>=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=A0R= egards,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0G= reg
>=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=A0O= n Fri, Feb 15, 2019 at 4:40 PM Weiqiang Cheng
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0&= lt;cheng= weiqiang@chinamobile.com
>=C2=A0 =C2=A0 =C2=A0<mailto:chengweiqiang@chinamobile.com>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:chengweiqiang@chinamobi= le.com
>=C2=A0 =C2=A0 =C2=A0<mailto:chengweiqiang@chinamobile.com>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0&= lt;mailto:chengweiqiang@chinamobile.com
>=C2=A0 =C2=A0 =C2=A0<mailto:chengweiqiang@chinamobile.com>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:chengweiqiang@chinamobi= le.com
>=C2=A0 =C2=A0 =C2=A0<mailto:chengweiqiang@chinamobile.com>>>>= ; wrote:
>=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=A0Hi Greg,____
>=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=A0Thanks a lot for your comments.____
>=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=A0My comments are in-line.____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0__ __
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0B.R.____
>=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=A0Weiqiang Cheng____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0__ __
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0*=E5=8F=91=E4=BB=B6=E4=BA=BA:*Greg Mirsky [mailto:gregimirsky@gmail.com >=C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail..com>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com <m= ailto:gregimirsk= y@gmail.com>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0<mailto:gregimirsky@gmail..com
>=C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com <m= ailto:gregimirsk= y@gmail.com>>>]
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0*=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:*2019=E5=B9=B42=E6=9C=88= 15=E6=97=A53:37
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0*=E6=94=B6=E4=BB=B6=E4=BA=BA:*Alexander Vainshtein
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0*=E6=8A=84=E9=80=81:*spring@ietf..org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>>>; Stewart Bryant;
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > draft-cheng-= spring-mpls-path-segment@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:draft-cheng-spring-mpls-path-seg= ment@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:draft-c= heng-spring-mpls-path-segment@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:draft-cheng-spring-mpls-path-seg= ment@ietf.org>>
>=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<mailto:draft-cheng-spring-mpls-p= ath-segment@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:draft-cheng-spring-mpls-path-seg= ment@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:draft-c= heng-spring-mpls-path-segment@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:draft-cheng-spring-mpls-path-seg= ment@ietf.org>>>;
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > mpls@ietf.org <mailto:mpls@ietf.org> <mailto:mpls@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:mpls@ietf.org>> <mailto:mpls@ietf.org <mailto:mpls@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:mpls@ietf.org <mailto:mpls@ietf.org>>>; Loa= Andersson
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0*=E4=B8=BB=E9=A2=98:*Re: [spring] to progress
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0draft-cheng-spring-mpls-path-segment____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0__ __
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Dear All,____
>=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=A0I concur with all what has been said in support of the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0adoption
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0of this draft by SPRING WG. The document is
>=C2=A0 =C2=A0 =C2=A0well-written,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0addresses the real problem in SR-MPLS, and the
>=C2=A0 =C2=A0 =C2=A0proposed
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0solution
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0is technically viable.____
>=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=A0My comments and questions are entirely for further
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0discussion:____
>=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* would the=C2=A0draft be expanded to demonstrate how >=C2=A0 =C2=A0 =C2=A0"the Path
>=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=A0Segment may be used to identify an SR-MPLS
>=C2=A0 =C2=A0 =C2=A0Policy, its
>=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=A0Candidate-Path (CP) or a SID List (SL)"?___= _
>=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[Weiqiang] Yes, It is necessary and=C2=A0we will add
>=C2=A0 =C2=A0 =C2=A0some text to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0demonstrate this in the future version. ____
>=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* as many use cases for the Path Segment are
>=C2=A0 =C2=A0 =C2=A0related to OAM
>=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=A0operations, it would be helpful to expand on
>=C2=A0 =C2=A0 =C2=A0the use
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0of GAL
>=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=A0and the Path Segment.____
>=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[Weiqiang] It is always helpful to have more use
>=C2=A0 =C2=A0 =C2=A0cases.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0However,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0The GAL is used today in MPLS-TP LSPs to flag the
>=C2=A0 =C2=A0 =C2=A0G-Ach
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0and is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0used for OAM packets only while the Path segment
>=C2=A0 =C2=A0 =C2=A0is used for
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0data packets for the each traffic flow. It is a
>=C2=A0 =C2=A0 =C2=A0little bit
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0different. ____
>=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=A0Regards,____
>=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=A0Greg____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0__ __
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0On Thu, Feb 14, 2019 at 1:12 AM Alexander Vainshtein
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0<Alexander.Vainshtein@ecitele..com
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0<mailto:Alexander.Vainshtein@ecitele.com
>=C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein@ecitele.com>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein= @ecitele.com
>=C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein@ecitele.com>>&= gt;> wrote:____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0+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 =C2=A0____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0I have been following this draft from its -00 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0revision. The
>=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=A0current revision has resolved most of the
>=C2=A0 =C2=A0 =C2=A0issues I (and
>=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=A0others) have been raised (e.g., elimination of >=C2=A0 =C2=A0 =C2=A0excessive
>=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=A0options).____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>=C2=A0 =C2=A0 =C2=A0 >=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 From my POV, in its current state the draft mee= ts
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0two basic
>=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=A0requirements for the WG adoption:____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A01.It addresses a real and relevant problem, name= ly
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the MPLS
>=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=A0Flow Identification problem discussed in
>=C2=A0 =C2=A0 =C2=A0general in
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0RFC 8372
>=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<https://tools.ietf.org/html/rfc837= 2> and
>=C2=A0 =C2=A0 =C2=A0scoped to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0SR-MPLS
>=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=A0LSPs in this draft. Specifics of SR-MPLS
>=C2=A0 =C2=A0 =C2=A0include the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0need to
>=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=A0provide end-to-end liveness check that is one >=C2=A0 =C2=A0 =C2=A0of the
>=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=A0requirements explicitly specified in Section 2 >=C2=A0 =C2=A0 =C2=A0of RFC
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A08355
>=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<https://tools.ietf.org/html/rfc835= 5>. ____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A02.It provides a reasonable (from my POV)
>=C2=A0 =C2=A0 =C2=A0approach to
>=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=A0solution of this problem.____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>=C2=A0 =C2=A0 =C2=A0 >=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=A0I also concur with Stewart=E2=80=99s comment abo= ut strong
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0similarity
>=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=A0between the approach taken in this draft for
>=C2=A0 =C2=A0 =C2=A0SR-MPLS and
>=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=A0generic work in progress on synonymous flow labe= ls
>=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<https://tools.ietf.org/html/draft-ietf-mpls-sfl-framewo= rk-04>
>=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=A0that has been already adopted as a MPLS WG
>=C2=A0 =C2=A0 =C2=A0item.=C2=A0 To
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0me this
>=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=A0is yet another indication that the draft should = be
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0adopted.____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>=C2=A0 =C2=A0 =C2=A0 >=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=A0My 2c,____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Sasha____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>=C2=A0 =C2=A0 =C2=A0 >=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=A0Office: +972-39266302____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-5492663= 02____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Email: Alexander.Vainshtein@ecitele.com
>=C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein@ecitele.com>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein= @ecitele.com
>=C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein@ecitele.com>><= br> >=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<mailto:Alexander.Vainshtein@ecitele.com
>=C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein@ecitele.com>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein= @ecitele.com
>=C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein@ecitele.com>>&= gt;____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>=C2=A0 =C2=A0 =C2=A0 >=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-----Original Message-----
>=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=A0From: spring <spring-bounces@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:spring-bounces@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:spring-bounces@ietf.org &= lt;mailto:spri= ng-bounces@ietf.org>>
>=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<mailto:spring-bounces@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:spring-bounces@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:spring-bounces@ietf.org >=C2=A0 =C2=A0 =C2=A0<mailto:spring-bounces@ietf.org>>>> On Behalf = Of 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=A0Sent: Wednesday, February 13, 2019 12:48 PM
>=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=A0To: Loa Andersson <loa@pi..nu
>=C2=A0 =C2=A0 =C2=A0<mailto:loa@pi.nu <mailto:loa@pi.nu>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:loa@pi.nu <mailto:loa@pi.nu>>>>;
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>>&= gt;;
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > draft-cheng-= spring-mpls-path-segment@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:draft-cheng-spring-mpls-path-seg= ment@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:draft-c= heng-spring-mpls-path-segment@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:draft-cheng-spring-mpls-path-seg= ment@ietf.org>>
>=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<mailto:draft-cheng-spring-mpls-p= ath-segment@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:draft-cheng-spring-mpls-path-seg= ment@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:draft-c= heng-spring-mpls-path-segment@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:draft-cheng-spring-mpls-path-seg= ment@ietf.org>>>
>=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=A0Subject: Re: [spring] to progress
>=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=A0draft-cheng-spring-mpls-path-segment____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>=C2=A0 =C2=A0 =C2=A0 >=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=A0I have just read the draft and agree that it
>=C2=A0 =C2=A0 =C2=A0should be
>=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=A0adopted by the WG. It solves an important
>=C2=A0 =C2=A0 =C2=A0problem in
>=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=A0instrumenting and protecting an SR path.____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>=C2=A0 =C2=A0 =C2=A0 >=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=A0It should be noted that we needed to do
>=C2=A0 =C2=A0 =C2=A0something very
>=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=A0similar in mainstream MPLS via the synonymous >=C2=A0 =C2=A0 =C2=A0label work
>=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=A0which is already adopted. ____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0However SL did not address the SR case.. We
>=C2=A0 =C2=A0 =C2=A0therefore
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0need
>=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=A0this path label work to be progressed.____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>=C2=A0 =C2=A0 =C2=A0 >=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- Stewart____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>=C2=A0 =C2=A0 =C2=A0 >=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=A0On 10/02/2019 08:11, Loa Andersson wrote:____ >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> Working Group,____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> ____
>=C2=A0 =C2=A0 =C2=A0 >=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> I have reviewed
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0draft-cheng-spring-mpls-pa= th-segment and as far as I ____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> can see, it is ready for wg adoption.____ >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> ____
>=C2=A0 =C2=A0 =C2=A0 >=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> There were some comments in Bangkok, but du= e
>=C2=A0 =C2=A0 =C2=A0to the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0many collisions ____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> between working groups at that meeting I >=C2=A0 =C2=A0 =C2=A0couldn't
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0attend the SPRING ____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> f2f.____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> ____
>=C2=A0 =C2=A0 =C2=A0 >=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> The minutes are not clear, but as far as I<= br> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0understand, there is ____<= br> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> nothing that can't be resolved in the w= g
>=C2=A0 =C2=A0 =C2=A0process.____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> ____
>=C2=A0 =C2=A0 =C2=A0 >=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> /Loa____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0____________________________________________= _______
>=C2=A0 =C2=A0 =C2=A0 >=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=A0spring mailing list____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>>&= gt;____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > https://www..ietf.org/mailman/listinfo/spring____
>=C2=A0 =C2=A0 =C2=A0<http://ietf.org/mailman/listi= nfo/spring____>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<http= ://ietf.org/mailman/listinfo/spring____>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0____________________________________________= _______________________________
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0This e-mail message is intended for the recipien= t
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0only and
>=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=A0contains information which is
>=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=A0CONFIDENTIAL and which may be proprietary to ECI=
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Telecom. If
>=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=A0you have received this
>=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=A0transmission in error, please inform us by e-mai= l,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0phone or
>=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=A0fax, and then delete the original
>=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=A0and all copies thereof.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0____________________________________________= ___________________________________
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=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_______________________________________________<= br> >=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=A0spring mailing list
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>>&= gt;
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/spring____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0_= ______________________________________________
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0s= pring mailing list
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>>&= gt;
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > h= ttps://www.ietf.org/mailman/listinfo/spring
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Loa 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 emai= l: loa@pi.nu
>=C2=A0 =C2=A0 =C2=A0<mailto:loa@pi.nu> <mailto:loa@pi.nu <mailto:loa@pi.nu>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Senior MPLS Expert
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Bronze Dragon Consulting= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > _____________________________________________= __
>=C2=A0 =C2=A0 =C2=A0 > spring mailing list
>=C2=A0 =C2=A0 =C2=A0 > spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mailm= an/listinfo/spring
>=C2=A0 =C2=A0 =C2=A0 >
>
>=C2=A0 =C2=A0 =C2=A0--
>
>
>=C2=A0 =C2=A0 =C2=A0Loa 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 <mailto:loa@pi.nu>
>=C2=A0 =C2=A0 =C2=A0Senior MPLS Expert
>=C2=A0 =C2=A0 =C2=A0Bronze Dragon Consulting=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring >

--


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
--000000000000e378140582920a57-- From nobody Sun Feb 24 11:44: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 E302912D4EF; Sun, 24 Feb 2019 11:43:52 -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.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mpls@ietf.org Message-ID: <155103743287.10983.6512427262984211001@ietfa.amsl.com> Date: Sun, 24 Feb 2019 11:43:52 -0800 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-base-yang-10.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 Feb 2019 19:43:53 -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 Base Authors : Tarek Saad Kamran Raza Rakesh Gandhi Xufeng Liu Vishnu Pavan Beeram Filename : draft-ietf-mpls-base-yang-10.txt Pages : 19 Date : 2019-02-24 Abstract: This document contains a specification of the the MPLS base YANG model. The MPLS base YANG model serves as a base framework for configuring and managing an MPLS switching subsystem on an MPLS- enabled router. It is expected that other MPLS YANG models (e.g. MPLS LSP Static, LDP or RSVP-TE YANG models) will augment the MPLS base YANG model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-base-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mpls-base-yang-10 https://datatracker.ietf.org/doc/html/draft-ietf-mpls-base-yang-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-base-yang-10 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 Feb 24 17:23:33 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 E0AFE130E86 for ; Sun, 24 Feb 2019 17:23:31 -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 R_0b_1alw0ZT for ; Sun, 24 Feb 2019 17:23:30 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04D7B12DD85 for ; Sun, 24 Feb 2019 17:23:29 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C02BDB80458; Sun, 24 Feb 2019 17:23:11 -0800 (PST) To: erosen@cisco.com, arun@force10networks.com, rcallon@juniper.net, 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: markzzzsmith@gmail.com, mpls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190225012311.C02BDB80458@rfc-editor.org> Date: Sun, 24 Feb 2019 17:23:11 -0800 (PST) Archived-At: Subject: [mpls] [Technical Errata Reported] RFC3031 (5643) 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 Feb 2019 01:23:32 -0000 The following errata report has been submitted for RFC3031, "Multiprotocol Label Switching Architecture". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5643 -------------------------------------- Type: Technical Reported by: Mark Smith Section: Terminology Original Text ------------- Corrected Text -------------- label edge router - a router capable of accepting an unlabelled packet, and through MPLS processing, may MPLS encapsulate the packet by adding a label stack. Notes ----- I am doing some MPLS review. The book I'm using said an LER was an (RFC3031) MPLS edge node. I believed it was any router that could take unlabelled packets and label them, regardless of where the router was within the MPLS domain. (In other words, an MPLS router was not an LER if it would not MPLS label unlabelled packets and forward them.) I decided to check RFC3031 for a definition, and discovered there isn't a definition at all for "label edge router", or a match on any text that matches "label edge" or "LER". RFC6178 clarifies LER processing of IPv4 packets, and the general description of processing matches my understanding of what an LER is. However, it doesn't formally define an "label edge router" either, and I think an update to RFC3031 should be where "label edge router" is formally defined. 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. -------------------------------------- RFC3031 (draft-ietf-mpls-arch-06) -------------------------------------- Title : Multiprotocol Label Switching Architecture Publication Date : January 2001 Author(s) : E. Rosen, A. Viswanathan, R. Callon Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Sun Feb 24 18:32: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 7FDCA130E98; Sun, 24 Feb 2019 18:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_SPAM=2.5] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcYn-NgsJcB6; Sun, 24 Feb 2019 18:32:49 -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 0E452128BCC; Sun, 24 Feb 2019 18:32:49 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 7B3435978DEFE0CF7E90; Mon, 25 Feb 2019 02:32:46 +0000 (GMT) Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 25 Feb 2019 02:32:45 +0000 Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.187]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0415.000; Mon, 25 Feb 2019 10:32:42 +0800 From: "Chengli (Cheng Li)" To: Loa Andersson , Greg Mirsky CC: "mpls@ietf.org" , spring , Weiqiang Cheng , "draft-cheng-spring-mpls-path-segment@ietf.org" Thread-Topic: [mpls] [spring] to progress draft-cheng-spring-mpls-path-segment Thread-Index: AQHUyzC/3+4K0aHNrUy+2rVERdsXgKXsg4cAgANJb0A= Date: Mon, 25 Feb 2019 02:32:41 +0000 Message-ID: References: <0980ce7c-047c-519f-e7d5-98d32b498482@pi.nu> <9419b7d7-87ef-151f-5ed8-b0f78c6e83af@gmail.com> <050301d4c590$445f5d50$cd1e17f0$@com> <9d7a2690-6ef4-438a-6ca8-0548ad2aca0e@pi.nu> <13cb42a8-e298-c3cc-d116-219f144f5357@pi.nu> <886d0aeb-281e-984a-9c9d-645101d4d02b@pi.nu> In-Reply-To: <886d0aeb-281e-984a-9c9d-645101d4d02b@pi.nu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.185.75] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] [spring] to progress draft-cheng-spring-mpls-path-segment 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 Feb 2019 02:32:52 -0000 SGkgTG9hIGFuZCBHcmVnLA0KDQpZZXMsIHlvdSBhcmUgcmlnaHQuDQoNClRoZSAiQi0+QyBTdWJQ YXRoIiBpbiB0aGUgZmlyc3QgZmlndXJlIG5lZWRzIHRvIGJlIGlkZW50aWNhbCB0byB0aGUgIkIt PkMgU3ViUGF0aCIgaW4gdGhlIHNlY29uZC4NCg0KTWFueSB0aGFua3MgZm9yIHlvdXIgZGlzY3Vz c2lvbiBvbiB0aGlzLCBhIHZlcnkgaW50ZXJlc3RpbmcgcXVlc3Rpb24hDQoNClRoYW5rcywNCkNo ZW5nDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBtcGxzIFttYWlsdG86bXBs cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTG9hIEFuZGVyc3Nvbg0KU2VudDogU2F0 dXJkYXksIEZlYnJ1YXJ5IDIzLCAyMDE5IDQ6MTYgUE0NClRvOiBHcmVnIE1pcnNreSA8Z3JlZ2lt aXJza3lAZ21haWwuY29tPg0KQ2M6IG1wbHNAaWV0Zi5vcmc7IHNwcmluZyA8c3ByaW5nQGlldGYu b3JnPjsgV2VpcWlhbmcgQ2hlbmcgPGNoZW5nd2VpcWlhbmdAY2hpbmFtb2JpbGUuY29tPjsgZHJh ZnQtY2hlbmctc3ByaW5nLW1wbHMtcGF0aC1zZWdtZW50QGlldGYub3JnDQpTdWJqZWN0OiBSZTog W21wbHNdIFtzcHJpbmddIHRvIHByb2dyZXNzIGRyYWZ0LWNoZW5nLXNwcmluZy1tcGxzLXBhdGgt c2VnbWVudA0KDQpHcmVnLA0KDQoNCg0KT24gMjAxOS0wMi0yMyAxMjozMSwgR3JlZyBNaXJza3kg d3JvdGU6DQo+IEhpIExvYSwNCj4gYW5vdGhlciB0dW5uZWwgd2l0aCB0aGUgUGF0aCBzZWdtZW50 IGZyb20gbm9kZSBDIGlzLCBpbiBteSB2aWV3LCB2ZXJ5IA0KPiBjbG9zZSB0byBTUE1FIHR1bm5l bC4gVGhlIFBhdGggc2VnbWVudCBmcm9tIEMgaXMgbmVlZGVkIGJlY2F1c2UgUGF0aCANCj4gc2Vn bWVudCBmcm9tIEQgaXMgbm90IGtub3duIHRvIHRoZSBub2RlIEMsIGNhbm5vdCBiZSBhc3NvY2lh dGVkIHdpdGggDQo+IHRoZSByaWdodCBTUi10dW5uZWwgc2VnbWVudCwgaS5lLiwgdHVubmVsIEIt Qy4gVGhlIGZhdGUgc2hhcmluZyBtYXkgYmUgDQo+IGFjaGlldmVkIGJ5IHVzaW5nIGV4YWN0bHkg dGhlIHNhbWUgU0lEcyBhcyBpbiB0aGUgQS1EIHR1bm5lbCBmb3IgdGhlIA0KPiBCLUMgc2VnbWVu dC4gQW5kIEdBTCBpcyBzdGlsbCBCb1Mgb24gQi1DIHR1bm5lbC4gQXJlIHdlIGdldHRpbmcgY2xv c2VyPw0KDQpOb3Qgc3VyZSwgeW91IGxvc2UgbWUgc29tZXdoZXJlIGJldHdlZW4gdGhlICJCIiwg IkMiLCAiRCIsICJmcm9tIiBhbmQgImFub3RoZXIiLg0KDQpTbyBsZXQgbWUgY2hlY2sgSSB3YXMg dGFsa2luZyBhYm91dA0KDQpTbyB0aGUgc3RhY2sgdHJhbnNwb3J0aW5nIHBheWxvYWQgZnJvbSBC LUMgbG9va3MgbGlrZSB0aGlzOg0KDQogICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0t Kw0KICAgICAgICAgICAgICAgICAgICAgfkItPkMgU3ViUGF0aH4NCiAgICAgICAgICAgICAgICAg ICAgICstLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgICB8cy1QU0lEKEItPkMpfA0K ICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAg IHwgQlNJRChDLT5EKSB8DQogICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tKw0KICAg ICAgICAgICAgICAgICAgICAgfGUtUFNJRChBLT5EKXwNCiAgICAgICAgICAgICAgICAgICAgICst LS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAgICBmaWd1cmUgMQ0KDQpUaGUgIn4i IGF0IHRoZSB0b3AgbWVhbnMgdGhhdCB0aGVyZSBtaWdodCBiZSBtb3JlIHRoYW4gb25lIGxhYmVs IHRoYXQgY2FuIGJlIHBvcHBlZCBvciBzd2FwcGVkLCByaWdodD8NCg0KU28gdGhlIHN0YWNrIHRy YW5zcG9ydGluZyBHQUNoIGZyb20gQi1DIGxvb2tzIGxpa2UgdGhpczoNCg0KICAgICAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgfiBCLT5DIFN1 YlBhdGggfg0KICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAg ICAgICAgICAgICAgfCAgICAgR0FMICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgKy0tLS0t LS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgfCAgR0FDaCBpbmZvLTEgfA0KICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgfCAg R0FDaCBpbmZvLTIgfA0KICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKw0KICAg ICAgICAgICAgICAgICAgICAgICAgZmlndXJlIDINCg0KTm93IG15IHF1ZXN0aW9uIGlzIHRoZSAi Qi0+QyBTdWJQYXRoIiBpbiB0aGUgZmlyc3QgZmlndXJlIGlkZW50aWNhbCB0byB0aGUgIkItPkMg U3ViUGF0aCIgaW4gdGhlIHNlY29uZCBmaWd1cmU/DQpOb3cNCi0tDQoNCg0KDQo+IA0KPiBSZWdh cmRzLA0KPiBHcmVnDQo+IA0KPiBPbiBGcmksIEZlYiAyMiwgMjAxOSBhdCA4OjE1IFBNIExvYSBB bmRlcnNzb24gPGxvYUBwaS5udSANCj4gPG1haWx0bzpsb2FAcGkubnU+PiB3cm90ZToNCj4gDQo+ ICAgICBHcmVnLA0KPiANCj4gICAgIFdlIGFyZSBjbG9zZSwgdGhvdWdoIEkgaG9wZSB0aGUgcnVs ZXMgYXJlIHRoYXQgR0FMIGlzIGJvdHRvbSBvZiBzdGFjaywNCj4gICAgIGFuZCB0aGF0IGEgcGFj a2V0IHdpdGggYSBHQUNoIGRvZXMgbm90IGNhcnJ5IHVzZXIgcGF5bG9hZC4NCj4gDQo+ICAgICBJ IHNob3VsZCBoYXZlIHNhaWQgdGhhdCAiaWYgeW91IHdhbnQgYSBHQUNnIGZvciB0aGUNCj4gDQo+ ICAgICBJIGRvbid0IHVuZGVyc3RhbmQgd2h5IHdlIG5lZWQgYSAibmV3IiBTUiB0dW5uZWwsIHRo ZSBHQUwvR0FDaCBjYW4NCj4gICAgIHJpZGUgd2l0aCB0aGUgR0FMIGFzIGJvdHRvbSBvZiBzdGFj ayB3aXRoIHRoZSBsYWJlbCBzdGFjayBmb3INCj4gICAgIFN1Yi1wYXRoKEItPkMpLCByaWdodD8g SWYgeW91IHB1dCBpdCBvbiAiYW5vdGhlciIgdHVubmVsLCBob3cgZG8NCj4gICAgIHlvdSBndWFy YW50ZWUgZmF0ZSBzaGFyaW5nPw0KPiANCj4gICAgIC9Mb2ENCj4gDQo+ICAgICAvTG9hDQo+IA0K PiAgICAgT24gMjAxOS0wMi0yMyAxMTo1NSwgR3JlZyBNaXJza3kgd3JvdGU6DQo+ICAgICAgPiBI aSBMb2EsDQo+ICAgICAgPiBJIHRoaW5rIGl0IHdpbGwgYmUgc2ltaWxhciB0byBTUE1FIGFuZCB3 ZSdsbCBuZWVkIHRvIGhhdmUgYW5vdGhlcg0KPiAgICAgID4gU1ItdHVubmVsIEItQyB3aXRoIGl0 cyBvd24gUGF0aCBzZWdtZW50IGFsbG9jYXRlZCBieSBub2RlIEMuIEJ1dCBHQUwNCj4gICAgICA+ IHdpbGwgc3RpbGwgYmUgQm9TLg0KPiAgICAgID4NCj4gICAgICA+IFJlZ2FyZHMsDQo+ICAgICAg PiBHcmVnLg0KPiAgICAgID4NCj4gICAgICA+IE9uIEZyaSwgRmViIDIyLCAyMDE5IGF0IDY6MTUg UE0gTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51DQo+ICAgICA8bWFpbHRvOmxvYUBwaS5udT4NCj4g ICAgICA+IDxtYWlsdG86bG9hQHBpLm51IDxtYWlsdG86bG9hQHBpLm51Pj4+IHdyb3RlOg0KPiAg ICAgID4NCj4gICAgICA+wqAgwqAgwqBSYWtlc2gsIGF1dGhvcnMsDQo+ICAgICAgPg0KPiAgICAg ID7CoCDCoCDCoEkgaGF2ZSBub3QgYmVlbiB0aGlua2luZyBhYm91dCB0aGlzIHRvbyBtdWNoLiBC dXQgaWYgeW91IGxvb2sNCj4gICAgIGF0IGZpZyAyDQo+ICAgICAgPsKgIMKgIMKgb2YgZHJhZnQt Y2hlbmctc3ByaW5nLW1wbHMtcGF0aC1zZWdtZW50LCBhbmQgeW91IG5lZWQgYSBHQUNoDQo+ICAg ICBiZXR3ZWVuDQo+ICAgICAgPsKgIMKgIMKgQSBhbmQgRCwgSSdkIHNheSB0aGF0IHRoZSBHQUwg d2lsbCBiZSBhdCB0aGUgYm90dG9tIG9mIHN0YWNrLg0KPiAgICAgID4NCj4gICAgICA+wqAgwqAg wqBXaGF0IGlmIHlvdSBuZWVkIHRoZSBDQUNoIGZvciB0aGUgc3ViLXBhdGggQiB0byBDLCB3aGVy ZSB3aWxsDQo+ICAgICB0aGUgR0FMDQo+ICAgICAgPsKgIMKgIMKgZ28/DQo+ICAgICAgPg0KPiAg ICAgID7CoCDCoCDCoC9Mb2ENCj4gICAgICA+DQo+ICAgICAgPg0KPiAgICAgID4NCj4gICAgICA+ wqAgwqAgwqBPbiAyMDE5LTAyLTIzIDA5OjI1LCBSYWtlc2ggR2FuZGhpIHdyb3RlOg0KPiAgICAg ID7CoCDCoCDCoCA+IEhpIEdyZWcsDQo+ICAgICAgPsKgIMKgIMKgID4NCj4gICAgICA+wqAgwqAg wqAgPiBJIGFtIG5vdCBzdXJlIGlmIHRoZSBxdWVzdGlvbiBoYXMgYmVlbiBhbnN3ZXJlZC4gSSB3 b3VsZCB0aGluaw0KPiAgICAgID7CoCDCoCDCoEdBTCBpcyBhdA0KPiAgICAgID7CoCDCoCDCoCA+ IHRoZSBib3R0b20gb2YgdGhlIGxhYmVsIHN0YWNrLg0KPiAgICAgID7CoCDCoCDCoCA+DQo+ICAg ICAgPsKgIMKgIMKgID4gVGhhbmtzLA0KPiAgICAgID7CoCDCoCDCoCA+IFJha2VzaA0KPiAgICAg ID7CoCDCoCDCoCA+DQo+ICAgICAgPsKgIMKgIMKgID4NCj4gICAgICA+wqAgwqAgwqAgPiBPbiBT YXQsIEZlYiAxNiwgMjAxOSBhdCA0OjI0IFBNIEdyZWcgTWlyc2t5DQo+ICAgICAgPsKgIMKgIMKg PGdyZWdpbWlyc2t5QGdtYWlsLmNvbSA8bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4NCj4g ICAgIDxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tIDxtYWlsdG86Z3JlZ2ltaXJza3lAZ21h aWwuY29tPj4NCj4gICAgICA+wqAgwqAgwqAgPiA8bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNv bQ0KPiAgICAgPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+IDxtYWlsdG86Z3JlZ2ltaXJz a3lAZ21haWwuY29tDQo+ICAgICA8bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+Pj4gd3Jv dGU6DQo+ICAgICAgPsKgIMKgIMKgID4NCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgSGnCoFdl aXFpYW5nIENoZW5nLA0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqB0aGFuayB5b3UgZm9yIHlv dXIgZXhwZWRpZW50IHJlc3BvbnNlIHRvIG15IHF1ZXN0aW9ucy4gVGhlDQo+ICAgICAgPsKgIMKg IMKgZG9jdW1lbnQNCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgc3RhdGVzIHRoYXQgb25lIG9m IHRoZSB1c2UgY2FzZXMgZm9yIHRoZSBQYXRoIHNlZ21lbnQNCj4gICAgIGlzIHRvDQo+ICAgICAg PsKgIMKgIMKgYmUgdXNlZA0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqBhcyBhIHBlcmZvcm1h bmNlLCBwYWNrZXQgbG9zcyBhbmQvb3IgZGVsYXksDQo+ICAgICBtZWFzdXJlbWVudCBzZXNzaW9u DQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoGlkZW50aWZpZXIuIEkgdGhpbmsgdGhhdCBSRkMg NjM3NCBpcyB0aGUgbW9zdCBzdWl0YWJsZQ0KPiAgICAgZm9yIFBNDQo+ICAgICAgPsKgIMKgIMKg T0FNIGluDQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoFNSLU1QTFMgZW52aXJvbm1lbnQuIE9m IGNvdXJzZSwgdGhlIHR5cGUgb2YgdGhlDQo+ICAgICAgPsKgIMKgIMKgZW5jYXBzdWxhdGVkwqBt ZXNzYWdlDQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoGNhbiBiZSBpZGVudGlmaWVkIHVzaW5n IHRoZSBkZXN0aW5hdGlvbiBVRFAgcG9ydA0KPiAgICAgbnVtYmVyIHdpdGgNCj4gICAgICA+wqAg wqAgwqBJUC9VRFANCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgZW5jYXBzdWxhdGlvbi4gQnV0 IGFub3RoZXIgb3B0aW9uIGlzIHRvIHVzZSBHLUFDaA0KPiAgICAgZW5jYXBzdWxhdGlvbi4NCj4g ICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgVGhhdCB3b3VsZCByZXF1aXJlIHRoZSB1c2Ugb2YgR0FM LiBBbmQgdGhhdCBpcyBob3cgSSd2ZQ0KPiAgICAgID7CoCDCoCDCoGFycml2ZWQgYXQNCj4gICAg ICA+wqAgwqAgwqAgPsKgIMKgIMKgbXkgb3JpZ2luYWwgcXVlc3Rpb24gKEkgc2hvdWxkIGhhdmUg ZXhwbGFpbmVkIGl0DQo+ICAgICBiZXR0ZXIsIG15DQo+ICAgICAgPsKgIMKgIMKgYXBvbG9naWVz KToNCj4gICAgICA+wqAgwqAgwqAgPg0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqBI b3cgdGhlIFBhdGggc2VnbWVudCBhbmQgR0FMIGFyZSBwbGFjZWQgcmVsYXRpdmUNCj4gICAgIHRv IGVhY2gNCj4gICAgICA+wqAgwqAgwqBvdGhlcg0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAg wqAgwqBpbiB0aGUgU1ItTVBMUyBsYWJlbCBzdGFjaz8NCj4gICAgICA+wqAgwqAgwqAgPg0KPiAg ICAgID7CoCDCoCDCoCA+wqAgwqAgwqBSZWdhcmRzLA0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAg wqBHcmVnDQo+ICAgICAgPsKgIMKgIMKgID4NCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgT24g RnJpLCBGZWIgMTUsIDIwMTkgYXQgNDo0MCBQTSBXZWlxaWFuZyBDaGVuZw0KPiAgICAgID7CoCDC oCDCoCA+wqAgwqAgwqA8Y2hlbmd3ZWlxaWFuZ0BjaGluYW1vYmlsZS5jb20NCj4gICAgIDxtYWls dG86Y2hlbmd3ZWlxaWFuZ0BjaGluYW1vYmlsZS5jb20+DQo+ICAgICAgPsKgIMKgIMKgPG1haWx0 bzpjaGVuZ3dlaXFpYW5nQGNoaW5hbW9iaWxlLmNvbQ0KPiAgICAgPG1haWx0bzpjaGVuZ3dlaXFp YW5nQGNoaW5hbW9iaWxlLmNvbT4+DQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoDxtYWlsdG86 Y2hlbmd3ZWlxaWFuZ0BjaGluYW1vYmlsZS5jb20NCj4gICAgIDxtYWlsdG86Y2hlbmd3ZWlxaWFu Z0BjaGluYW1vYmlsZS5jb20+DQo+ICAgICAgPsKgIMKgIMKgPG1haWx0bzpjaGVuZ3dlaXFpYW5n QGNoaW5hbW9iaWxlLmNvbQ0KPiAgICAgPG1haWx0bzpjaGVuZ3dlaXFpYW5nQGNoaW5hbW9iaWxl LmNvbT4+Pj4gd3JvdGU6DQo+ICAgICAgPsKgIMKgIMKgID4NCj4gICAgICA+wqAgwqAgwqAgPsKg IMKgIMKgIMKgIMKgSGkgR3JlZyxfX19fDQo+ICAgICAgPsKgIMKgIMKgID4NCj4gICAgICA+wqAg wqAgwqAgPsKgIMKgIMKgIMKgIMKgVGhhbmtzIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzLl9fX18N Cj4gICAgICA+wqAgwqAgwqAgPg0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqBNeSBj b21tZW50cyBhcmUgaW4tbGluZS5fX19fDQo+ICAgICAgPsKgIMKgIMKgID4NCj4gICAgICA+wqAg wqAgwqAgPsKgIMKgIMKgIMKgIMKgX18gX18NCj4gICAgICA+wqAgwqAgwqAgPg0KPiAgICAgID7C oCDCoCDCoCA+wqAgwqAgwqAgwqAgwqBCLlIuX19fXw0KPiAgICAgID7CoCDCoCDCoCA+DQo+ICAg ICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoFdlaXFpYW5nIENoZW5nX19fXw0KPiAgICAgID7C oCDCoCDCoCA+DQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoF9fIF9fDQo+ICAgICAg PsKgIMKgIMKgID4NCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKgKuWPkeS7tuS6ujoq R3JlZyBNaXJza3kgW21haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20NCj4gICAgIDxtYWlsdG86 Z3JlZ2ltaXJza3lAZ21haWwuLmNvbT4NCj4gICAgICA+wqAgwqAgwqA8bWFpbHRvOmdyZWdpbWly c2t5QGdtYWlsLmNvbSA8bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+DQo+ICAgICAgPsKg IMKgIMKgID7CoCDCoCDCoCDCoCDCoDxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuLmNvbQ0KPiAg ICAgPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+DQo+ICAgICAgPsKgIMKgIMKgPG1haWx0 bzpncmVnaW1pcnNreUBnbWFpbC5jb20gPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+Pj5d DQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoCrlj5HpgIHml7bpl7Q6KjIwMTnlubQy 5pyIMTXml6UzOjM3DQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoCrmlLbku7bkuro6 KkFsZXhhbmRlciBWYWluc2h0ZWluDQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoCrm ioTpgIE6KnNwcmluZ0BpZXRmLi5vcmcgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAgICA8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4+DQo+ICAgICAg PsKgIMKgIMKgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+ DQo+ICAgICA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4+ PjsgU3Rld2FydCBCcnlhbnQ7DQo+ICAgICAgPsKgIMKgIMKgID4gZHJhZnQtY2hlbmctc3ByaW5n LW1wbHMtcGF0aC1zZWdtZW50QGlldGYub3JnDQo+ICAgICA8bWFpbHRvOmRyYWZ0LWNoZW5nLXNw cmluZy1tcGxzLXBhdGgtc2VnbWVudEBpZXRmLm9yZz4NCj4gICAgICA+wqAgwqAgwqA8bWFpbHRv OmRyYWZ0LWNoZW5nLXNwcmluZy1tcGxzLXBhdGgtc2VnbWVudEBpZXRmLm9yZw0KPiAgICAgPG1h aWx0bzpkcmFmdC1jaGVuZy1zcHJpbmctbXBscy1wYXRoLXNlZ21lbnRAaWV0Zi5vcmc+Pg0KPiAg ICAgID7CoCDCoCDCoCA+ICAgICAgIA0KPiAgICAgIMKgPG1haWx0bzpkcmFmdC1jaGVuZy1zcHJp bmctbXBscy1wYXRoLXNlZ21lbnRAaWV0Zi5vcmcNCj4gICAgIDxtYWlsdG86ZHJhZnQtY2hlbmct c3ByaW5nLW1wbHMtcGF0aC1zZWdtZW50QGlldGYub3JnPg0KPiAgICAgID7CoCDCoCDCoDxtYWls dG86ZHJhZnQtY2hlbmctc3ByaW5nLW1wbHMtcGF0aC1zZWdtZW50QGlldGYub3JnDQo+ICAgICA8 bWFpbHRvOmRyYWZ0LWNoZW5nLXNwcmluZy1tcGxzLXBhdGgtc2VnbWVudEBpZXRmLm9yZz4+PjsN Cj4gICAgICA+wqAgwqAgwqAgPiBtcGxzQGlldGYub3JnIDxtYWlsdG86bXBsc0BpZXRmLm9yZz4g PG1haWx0bzptcGxzQGlldGYub3JnDQo+ICAgICA8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+PiA8bWFp bHRvOm1wbHNAaWV0Zi5vcmcgPG1haWx0bzptcGxzQGlldGYub3JnPg0KPiAgICAgID7CoCDCoCDC oDxtYWlsdG86bXBsc0BpZXRmLm9yZyA8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+Pj47IExvYSBBbmRl cnNzb24NCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKgKuS4u+mimDoqUmU6IFtzcHJp bmddIHRvIHByb2dyZXNzDQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoGRyYWZ0LWNo ZW5nLXNwcmluZy1tcGxzLXBhdGgtc2VnbWVudF9fX18NCj4gICAgICA+wqAgwqAgwqAgPg0KPiAg ICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqBfXyBfXw0KPiAgICAgID7CoCDCoCDCoCA+DQo+ ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoERlYXIgQWxsLF9fX18NCj4gICAgICA+wqAg wqAgwqAgPg0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqBJIGNvbmN1ciB3aXRoIGFs bCB3aGF0IGhhcyBiZWVuIHNhaWQgaW4gc3VwcG9ydCBvZiB0aGUNCj4gICAgICA+wqAgwqAgwqBh ZG9wdGlvbg0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqBvZiB0aGlzIGRyYWZ0IGJ5 IFNQUklORyBXRy4gVGhlIGRvY3VtZW50IGlzDQo+ICAgICB3ZWxsLXdyaXR0ZW4sDQo+ICAgICAg PsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoGFkZHJlc3NlcyB0aGUgcmVhbCBwcm9ibGVtIGluIFNS LU1QTFMsIGFuZCB0aGUNCj4gICAgIHByb3Bvc2VkDQo+ICAgICAgPsKgIMKgIMKgc29sdXRpb24N Cj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKgaXMgdGVjaG5pY2FsbHkgdmlhYmxlLl9f X18NCj4gICAgICA+wqAgwqAgwqAgPg0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqBN eSBjb21tZW50cyBhbmQgcXVlc3Rpb25zIGFyZSBlbnRpcmVseSBmb3IgZnVydGhlcg0KPiAgICAg ID7CoCDCoCDCoGRpc2N1c3Npb246X19fXw0KPiAgICAgID7CoCDCoCDCoCA+DQo+ICAgICAgPsKg IMKgIMKgID7CoCDCoCDCoCDCoCDCoCDCoCogd291bGQgdGhlwqBkcmFmdCBiZSBleHBhbmRlZCB0 byBkZW1vbnN0cmF0ZSBob3cNCj4gICAgICJ0aGUgUGF0aA0KPiAgICAgID7CoCDCoCDCoCA+wqAg wqAgwqAgwqAgwqAgwqAgwqBTZWdtZW50IG1heSBiZSB1c2VkIHRvIGlkZW50aWZ5IGFuIFNSLU1Q TFMNCj4gICAgIFBvbGljeSwgaXRzDQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoCDC oCDCoENhbmRpZGF0ZS1QYXRoIChDUCkgb3IgYSBTSUQgTGlzdCAoU0wpIj9fX19fDQo+ICAgICAg PsKgIMKgIMKgID4NCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKgW1dlaXFpYW5nXSBZ ZXMsIEl0IGlzIG5lY2Vzc2FyeSBhbmTCoHdlIHdpbGwgYWRkDQo+ICAgICBzb21lIHRleHQgdG8N Cj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKgZGVtb25zdHJhdGUgdGhpcyBpbiB0aGUg ZnV0dXJlIHZlcnNpb24uIF9fX18NCj4gICAgICA+wqAgwqAgwqAgPg0KPiAgICAgID7CoCDCoCDC oCA+wqAgwqAgwqAgwqAgwqAgwqAqIGFzIG1hbnkgdXNlIGNhc2VzIGZvciB0aGUgUGF0aCBTZWdt ZW50IGFyZQ0KPiAgICAgcmVsYXRlZCB0byBPQU0NCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKg IMKgIMKgIMKgIMKgb3BlcmF0aW9ucywgaXQgd291bGQgYmUgaGVscGZ1bCB0byBleHBhbmQgb24N Cj4gICAgIHRoZSB1c2UNCj4gICAgICA+wqAgwqAgwqBvZiBHQUwNCj4gICAgICA+wqAgwqAgwqAg PsKgIMKgIMKgIMKgIMKgIMKgIMKgYW5kIHRoZSBQYXRoIFNlZ21lbnQuX19fXw0KPiAgICAgID7C oCDCoCDCoCA+DQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoFtXZWlxaWFuZ10gSXQg aXMgYWx3YXlzIGhlbHBmdWwgdG8gaGF2ZSBtb3JlIHVzZQ0KPiAgICAgY2FzZXMuDQo+ICAgICAg PsKgIMKgIMKgSG93ZXZlciwNCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKgVGhlIEdB TCBpcyB1c2VkIHRvZGF5IGluIE1QTFMtVFAgTFNQcyB0byBmbGFnIHRoZQ0KPiAgICAgRy1BY2gN Cj4gICAgICA+wqAgwqAgwqBhbmQgaXMNCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKg dXNlZCBmb3IgT0FNIHBhY2tldHMgb25seSB3aGlsZSB0aGUgUGF0aCBzZWdtZW50DQo+ICAgICBp cyB1c2VkIGZvcg0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqBkYXRhIHBhY2tldHMg Zm9yIHRoZSBlYWNoIHRyYWZmaWMgZmxvdy4gSXQgaXMgYQ0KPiAgICAgbGl0dGxlIGJpdA0KPiAg ICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqBkaWZmZXJlbnQuIF9fX18NCj4gICAgICA+wqAg wqAgwqAgPg0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqBSZWdhcmRzLF9fX18NCj4g ICAgICA+wqAgwqAgwqAgPg0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqBHcmVnX19f Xw0KPiAgICAgID7CoCDCoCDCoCA+DQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoF9f IF9fDQo+ICAgICAgPsKgIMKgIMKgID4NCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKg T24gVGh1LCBGZWIgMTQsIDIwMTkgYXQgMToxMiBBTSBBbGV4YW5kZXIgVmFpbnNodGVpbg0KPiAg ICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVs ZS4uY29tDQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoDxtYWlsdG86QWxleGFuZGVy LlZhaW5zaHRlaW5AZWNpdGVsZS5jb20NCj4gICAgIDxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRl aW5AZWNpdGVsZS5jb20+DQo+ICAgICAgPsKgIMKgIMKgPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNo dGVpbkBlY2l0ZWxlLmNvbQ0KPiAgICAgPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0 ZWxlLmNvbT4+Pj4gd3JvdGU6X19fXw0KPiAgICAgID7CoCDCoCDCoCA+DQo+ICAgICAgPsKgIMKg IMKgID7CoCDCoCDCoCDCoCDCoCDCoCDCoCsxLl9fX18NCj4gICAgICA+wqAgwqAgwqAgPg0KPiAg ICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgwqBfX19fDQo+ICAgICAgPsKgIMKgIMKg ID4NCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKgIMKgIMKgSSBoYXZlIGJlZW4gZm9s bG93aW5nIHRoaXMgZHJhZnQgZnJvbSBpdHMgLTAwDQo+ICAgICAgPsKgIMKgIMKgcmV2aXNpb24u IFRoZQ0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgwqBjdXJyZW50IHJldmlz aW9uIGhhcyByZXNvbHZlZCBtb3N0IG9mIHRoZQ0KPiAgICAgaXNzdWVzIEkgKGFuZA0KPiAgICAg ID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgwqBvdGhlcnMpIGhhdmUgYmVlbiByYWlzZWQg KGUuZy4sIGVsaW1pbmF0aW9uIG9mDQo+ICAgICBleGNlc3NpdmUNCj4gICAgICA+wqAgwqAgwqAg PsKgIMKgIMKgIMKgIMKgIMKgIMKgb3B0aW9ucykuX19fXw0KPiAgICAgID7CoCDCoCDCoCA+DQo+ ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoCDCoCDCoF9fX18NCj4gICAgICA+wqAgwqAg wqAgPg0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgwqAgRnJvbSBteSBQT1Ys IGluIGl0cyBjdXJyZW50IHN0YXRlIHRoZSBkcmFmdCBtZWV0cw0KPiAgICAgID7CoCDCoCDCoHR3 byBiYXNpYw0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgwqByZXF1aXJlbWVu dHMgZm9yIHRoZSBXRyBhZG9wdGlvbjpfX19fDQo+ICAgICAgPsKgIMKgIMKgID4NCj4gICAgICA+ wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKgIMKgIMKgMS5JdCBhZGRyZXNzZXMgYSByZWFsIGFuZCBy ZWxldmFudCBwcm9ibGVtLCBuYW1lbHkNCj4gICAgICA+wqAgwqAgwqB0aGUgTVBMUw0KPiAgICAg ID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgwqBGbG93IElkZW50aWZpY2F0aW9uIHByb2Js ZW0gZGlzY3Vzc2VkIGluDQo+ICAgICBnZW5lcmFsIGluDQo+ICAgICAgPsKgIMKgIMKgUkZDIDgz NzINCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKgIMKgIMKgPGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM4MzcyPiBhbmQNCj4gICAgIHNjb3BlZCB0bw0KPiAgICAgID7CoCDC oCDCoFNSLU1QTFMNCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKgIMKgIMKgTFNQcyBp biB0aGlzIGRyYWZ0LiBTcGVjaWZpY3Mgb2YgU1ItTVBMUw0KPiAgICAgaW5jbHVkZSB0aGUNCj4g ICAgICA+wqAgwqAgwqBuZWVkIHRvDQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoCDC oCDCoHByb3ZpZGUgZW5kLXRvLWVuZCBsaXZlbmVzcyBjaGVjayB0aGF0IGlzIG9uZQ0KPiAgICAg b2YgdGhlDQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoCDCoCDCoHJlcXVpcmVtZW50 cyBleHBsaWNpdGx5IHNwZWNpZmllZCBpbiBTZWN0aW9uIDINCj4gICAgIG9mIFJGQw0KPiAgICAg ID7CoCDCoCDCoDgzNTUNCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKgIMKgIMKgPGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MzU1Pi4gX19fXw0KPiAgICAgID7CoCDCoCDC oCA+DQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoCDCoCDCoDIuSXQgcHJvdmlkZXMg YSByZWFzb25hYmxlIChmcm9tIG15IFBPVikNCj4gICAgIGFwcHJvYWNoIHRvDQo+ICAgICAgPsKg IMKgIMKgID7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHNvbHV0aW9uIG9mIHRoaXMgcHJvYmxlbS5f X19fDQo+ICAgICAgPsKgIMKgIMKgID4NCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKg IMKgIMKgX19fXw0KPiAgICAgID7CoCDCoCDCoCA+DQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDC oCDCoCDCoCDCoCDCoEkgYWxzbyBjb25jdXIgd2l0aCBTdGV3YXJ04oCZcyBjb21tZW50IGFib3V0 IHN0cm9uZw0KPiAgICAgID7CoCDCoCDCoHNpbWlsYXJpdHkNCj4gICAgICA+wqAgwqAgwqAgPsKg IMKgIMKgIMKgIMKgIMKgIMKgYmV0d2VlbiB0aGUgYXBwcm9hY2ggdGFrZW4gaW4gdGhpcyBkcmFm dCBmb3INCj4gICAgIFNSLU1QTFMgYW5kDQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDC oCDCoCDCoGdlbmVyaWMgd29yayBpbiBwcm9ncmVzcyBvbiBzeW5vbnltb3VzIGZsb3cgbGFiZWxz DQo+ICAgICAgPsKgIMKgIMKgID4NCj4gICAgICA+wqAgwqAgwqAgwqA8aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbXBscy1zZmwtZnJhbWV3b3JrLTA0Pg0KPiAgICAgID7C oCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgwqB0aGF0IGhhcyBiZWVuIGFscmVhZHkgYWRvcHRl ZCBhcyBhIE1QTFMgV0cNCj4gICAgIGl0ZW0uwqAgVG8NCj4gICAgICA+wqAgwqAgwqBtZSB0aGlz DQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoCDCoCDCoGlzIHlldCBhbm90aGVyIGlu ZGljYXRpb24gdGhhdCB0aGUgZHJhZnQgc2hvdWxkIGJlDQo+ICAgICAgPsKgIMKgIMKgYWRvcHRl ZC5fX19fDQo+ICAgICAgPsKgIMKgIMKgID4NCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgIMKg IMKgIMKgIMKgX19fXw0KPiAgICAgID7CoCDCoCDCoCA+DQo+ICAgICAgPsKgIMKgIMKgID7CoCDC oCDCoCDCoCDCoCDCoCDCoE15IDJjLF9fX18NCj4gICAgICA+wqAgwqAgwqAgPg0KPiAgICAgID7C oCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgwqBTYXNoYV9fX18NCj4gICAgICA+wqAgwqAgwqAg Pg0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgwqBfX19fDQo+ICAgICAgPsKg IMKgIMKgID4NCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKgIMKgIMKgT2ZmaWNlOiAr OTcyLTM5MjY2MzAyX19fXw0KPiAgICAgID7CoCDCoCDCoCA+DQo+ICAgICAgPsKgIMKgIMKgID7C oCDCoCDCoCDCoCDCoCDCoCDCoENlbGw6wqDCoMKgwqDCoCArOTcyLTU0OTI2NjMwMl9fX18NCj4g ICAgICA+wqAgwqAgwqAgPg0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgwqBF bWFpbDogQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20NCj4gICAgIDxtYWlsdG86QWxl eGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQo+ICAgICAgPsKgIMKgIMKgPG1haWx0bzpB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KPiAgICAgPG1haWx0bzpBbGV4YW5kZXIu VmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4+DQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDC oCDCoCDCoDxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20NCj4gICAgIDxt YWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQo+ICAgICAgPsKgIMKgIMKg PG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KPiAgICAgPG1haWx0bzpB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4+Pl9fX18NCj4gICAgICA+wqAgwqAgwqAg Pg0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgwqBfX19fDQo+ICAgICAgPsKg IMKgIMKgID4NCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKgIMKgIMKgLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKgIMKgIMKg RnJvbTogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZw0KPiAgICAgPG1haWx0bzpzcHJp bmctYm91bmNlc0BpZXRmLm9yZz4NCj4gICAgICA+wqAgwqAgwqA8bWFpbHRvOnNwcmluZy1ib3Vu Y2VzQGlldGYub3JnIDxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+Pg0KPiAgICAgID7C oCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgwqA8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYu b3JnDQo+ICAgICA8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPg0KPiAgICAgID7CoCDC oCDCoDxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcNCj4gICAgIDxtYWlsdG86c3ByaW5n LWJvdW5jZXNAaWV0Zi5vcmc+Pj4+IE9uIEJlaGFsZiBPZiBTdGV3YXJ0IEJyeWFudA0KPiAgICAg ID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgwqBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5 IDEzLCAyMDE5IDEyOjQ4IFBNDQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoCDCoCDC oFRvOiBMb2EgQW5kZXJzc29uIDxsb2FAcGkuLm51DQo+ICAgICA8bWFpbHRvOmxvYUBwaS5udSA8 bWFpbHRvOmxvYUBwaS5udT4NCj4gICAgICA+wqAgwqAgwqA8bWFpbHRvOmxvYUBwaS5udSA8bWFp bHRvOmxvYUBwaS5udT4+Pj47DQo+ICAgICAgPsKgIMKgIMKgID4gc3ByaW5nQGlldGYub3JnIDxt YWlsdG86c3ByaW5nQGlldGYub3JnPg0KPiAgICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmcgPG1h aWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pg0KPiAgICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmcgPG1h aWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ICAgICAgPsKgIMKgIMKgPG1haWx0bzpzcHJpbmdAaWV0 Zi5vcmcgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pj47DQo+ICAgICAgPsKgIMKgIMKgID4gZHJh ZnQtY2hlbmctc3ByaW5nLW1wbHMtcGF0aC1zZWdtZW50QGlldGYub3JnDQo+ICAgICA8bWFpbHRv OmRyYWZ0LWNoZW5nLXNwcmluZy1tcGxzLXBhdGgtc2VnbWVudEBpZXRmLm9yZz4NCj4gICAgICA+ wqAgwqAgwqA8bWFpbHRvOmRyYWZ0LWNoZW5nLXNwcmluZy1tcGxzLXBhdGgtc2VnbWVudEBpZXRm Lm9yZw0KPiAgICAgPG1haWx0bzpkcmFmdC1jaGVuZy1zcHJpbmctbXBscy1wYXRoLXNlZ21lbnRA aWV0Zi5vcmc+Pg0KPiAgICAgID7CoCDCoCDCoCA+ICAgICAgICAgICANCj4gICAgICDCoDxtYWls dG86ZHJhZnQtY2hlbmctc3ByaW5nLW1wbHMtcGF0aC1zZWdtZW50QGlldGYub3JnDQo+ICAgICA8 bWFpbHRvOmRyYWZ0LWNoZW5nLXNwcmluZy1tcGxzLXBhdGgtc2VnbWVudEBpZXRmLm9yZz4NCj4g ICAgICA+wqAgwqAgwqA8bWFpbHRvOmRyYWZ0LWNoZW5nLXNwcmluZy1tcGxzLXBhdGgtc2VnbWVu dEBpZXRmLm9yZw0KPiAgICAgPG1haWx0bzpkcmFmdC1jaGVuZy1zcHJpbmctbXBscy1wYXRoLXNl Z21lbnRAaWV0Zi5vcmc+Pj4NCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKgIMKgIMKg U3ViamVjdDogUmU6IFtzcHJpbmddIHRvIHByb2dyZXNzDQo+ICAgICAgPsKgIMKgIMKgID7CoCDC oCDCoCDCoCDCoCDCoCDCoGRyYWZ0LWNoZW5nLXNwcmluZy1tcGxzLXBhdGgtc2VnbWVudF9fX18N Cj4gICAgICA+wqAgwqAgwqAgPg0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAg wqBfX19fDQo+ICAgICAgPsKgIMKgIMKgID4NCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgIMKg IMKgIMKgIMKgSSBoYXZlIGp1c3QgcmVhZCB0aGUgZHJhZnQgYW5kIGFncmVlIHRoYXQgaXQNCj4g ICAgIHNob3VsZCBiZQ0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgwqBhZG9w dGVkIGJ5IHRoZSBXRy4gSXQgc29sdmVzIGFuIGltcG9ydGFudA0KPiAgICAgcHJvYmxlbSBpbg0K PiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgwqBpbnN0cnVtZW50aW5nIGFuZCBw cm90ZWN0aW5nIGFuIFNSIHBhdGguX19fXw0KPiAgICAgID7CoCDCoCDCoCA+DQo+ICAgICAgPsKg IMKgIMKgID7CoCDCoCDCoCDCoCDCoCDCoCDCoF9fX18NCj4gICAgICA+wqAgwqAgwqAgPg0KPiAg ICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgwqBJdCBzaG91bGQgYmUgbm90ZWQgdGhh dCB3ZSBuZWVkZWQgdG8gZG8NCj4gICAgIHNvbWV0aGluZyB2ZXJ5DQo+ICAgICAgPsKgIMKgIMKg ID7CoCDCoCDCoCDCoCDCoCDCoCDCoHNpbWlsYXIgaW4gbWFpbnN0cmVhbSBNUExTIHZpYSB0aGUg c3lub255bW91cw0KPiAgICAgbGFiZWwgd29yaw0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAg wqAgwqAgwqAgwqB3aGljaCBpcyBhbHJlYWR5IGFkb3B0ZWQuIF9fX18NCj4gICAgICA+wqAgwqAg wqAgPg0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgwqBIb3dldmVyIFNMIGRp ZCBub3QgYWRkcmVzcyB0aGUgU1IgY2FzZS4uIFdlDQo+ICAgICB0aGVyZWZvcmUNCj4gICAgICA+ wqAgwqAgwqBuZWVkDQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoCDCoCDCoHRoaXMg cGF0aCBsYWJlbCB3b3JrIHRvIGJlIHByb2dyZXNzZWQuX19fXw0KPiAgICAgID7CoCDCoCDCoCA+ DQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoCDCoCDCoF9fX18NCj4gICAgICA+wqAg wqAgwqAgPg0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgwqAtIFN0ZXdhcnRf X19fDQo+ICAgICAgPsKgIMKgIMKgID4NCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKg IMKgIMKgX19fXw0KPiAgICAgID7CoCDCoCDCoCA+DQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDC oCDCoCDCoCDCoCDCoE9uIDEwLzAyLzIwMTkgMDg6MTEsIExvYSBBbmRlcnNzb24gd3JvdGU6X19f Xw0KPiAgICAgID7CoCDCoCDCoCA+DQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoCDC oCDCoD4gV29ya2luZyBHcm91cCxfX19fDQo+ICAgICAgPsKgIMKgIMKgID4NCj4gICAgICA+wqAg wqAgwqAgPsKgIMKgIMKgIMKgIMKgIMKgIMKgPiBfX19fDQo+ICAgICAgPsKgIMKgIMKgID4NCj4g ICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKgIMKgIMKgPiBJIGhhdmUgcmV2aWV3ZWQNCj4g ICAgICA+wqAgwqAgwqBkcmFmdC1jaGVuZy1zcHJpbmctbXBscy1wYXRoLXNlZ21lbnQgYW5kIGFz IGZhciBhcyBJIF9fX18NCj4gICAgICA+wqAgwqAgwqAgPg0KPiAgICAgID7CoCDCoCDCoCA+wqAg wqAgwqAgwqAgwqAgwqAgwqA+IGNhbiBzZWUsIGl0IGlzIHJlYWR5IGZvciB3ZyBhZG9wdGlvbi5f X19fDQo+ICAgICAgPsKgIMKgIMKgID4NCj4gICAgICA+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKg IMKgIMKgPiBfX19fDQo+ICAgICAgPsKgIMKgIMKgID4NCj4gICAgICA+wqAgwqAgwqAgPsKgIMKg IMKgIMKgIMKgIMKgIMKgPiBUaGVyZSB3ZXJlIHNvbWUgY29tbWVudHMgaW4gQmFuZ2tvaywgYnV0 IGR1ZQ0KPiAgICAgdG8gdGhlDQo+ICAgICAgPsKgIMKgIMKgbWFueSBjb2xsaXNpb25zIF9fX18N Cj4gICAgICA+wqAgwqAgwqAgPg0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAg wqA+IGJldHdlZW4gd29ya2luZyBncm91cHMgYXQgdGhhdCBtZWV0aW5nIEkNCj4gICAgIGNvdWxk bid0DQo+ICAgICAgPsKgIMKgIMKgYXR0ZW5kIHRoZSBTUFJJTkcgX19fXw0KPiAgICAgID7CoCDC oCDCoCA+DQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoCDCoCDCoD4gZjJmLl9fX18N Cj4gICAgICA+wqAgwqAgwqAgPg0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAg wqA+IF9fX18NCj4gICAgICA+wqAgwqAgwqAgPg0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAg wqAgwqAgwqAgwqA+IFRoZSBtaW51dGVzIGFyZSBub3QgY2xlYXIsIGJ1dCBhcyBmYXIgYXMgSQ0K PiAgICAgID7CoCDCoCDCoHVuZGVyc3RhbmQsIHRoZXJlIGlzIF9fX18NCj4gICAgICA+wqAgwqAg wqAgPg0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgwqA+IG5vdGhpbmcgdGhh dCBjYW4ndCBiZSByZXNvbHZlZCBpbiB0aGUgd2cNCj4gICAgIHByb2Nlc3MuX19fXw0KPiAgICAg ID7CoCDCoCDCoCA+DQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoCDCoCDCoD4gX19f Xw0KPiAgICAgID7CoCDCoCDCoCA+DQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoCDC oCDCoD4gL0xvYV9fX18NCj4gICAgICA+wqAgwqAgwqAgPg0KPiAgICAgID7CoCDCoCDCoCA+wqAg wqAgwqAgwqAgwqAgwqAgwqBfX19fDQo+ICAgICAgPsKgIMKgIMKgID4NCj4gICAgICA+wqAgwqAg wqAgPiAgICAgICAgICAgDQo+ICAgICAgwqBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gICAgICA+wqAgwqAgwqAgPg0KPiAgICAgID7CoCDCoCDC oCA+wqAgwqAgwqAgwqAgwqAgwqAgwqBzcHJpbmcgbWFpbGluZyBsaXN0X19fXw0KPiAgICAgID7C oCDCoCDCoCA+DQo+ICAgICAgPsKgIMKgIMKgID4gc3ByaW5nQGlldGYub3JnIDxtYWlsdG86c3By aW5nQGlldGYub3JnPg0KPiAgICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJp bmdAaWV0Zi5vcmc+Pg0KPiAgICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJp bmdAaWV0Zi5vcmc+DQo+ICAgICAgPsKgIMKgIMKgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmcgPG1h aWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pj5fX19fDQo+ICAgICAgPsKgIMKgIMKgID4NCj4gICAgICA+ wqAgwqAgwqAgPiBodHRwczovL3d3dy4uaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmdf X19fDQo+ICAgICA8aHR0cDovL2lldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nX19fXz4N Cj4gICAgICA+wqAgwqAgwqA8aHR0cDovL2lldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5n X19fXz4NCj4gICAgICA+wqAgwqAgwqAgPg0KPiAgICAgID7CoCDCoCDCoCA+DQo+ICAgICAgPsKg IMKgIMKgID4NCj4gICAgICA+ICAgICANCj4gICAgICDCoF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAg ICAgID7CoCDCoCDCoCA+DQo+ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoCDCoCDCoFRo aXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQNCj4gICAgICA+ wqAgwqAgwqBvbmx5IGFuZA0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgwqBj b250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBpcw0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAg wqAgwqAgwqAgwqBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBF Q0kNCj4gICAgICA+wqAgwqAgwqBUZWxlY29tLiBJZg0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAg wqAgwqAgwqAgwqAgwqB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzDQo+ICAgICAgPsKgIMKgIMKgID7C oCDCoCDCoCDCoCDCoCDCoCDCoHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1 cyBieSBlLW1haWwsDQo+ICAgICAgPsKgIMKgIMKgcGhvbmUgb3INCj4gICAgICA+wqAgwqAgwqAg PsKgIMKgIMKgIMKgIMKgIMKgIMKgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsDQo+ ICAgICAgPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoCDCoCDCoGFuZCBhbGwgY29waWVzIHRoZXJl b2YuDQo+ICAgICAgPsKgIMKgIMKgID4NCj4gICAgICA+ICAgICANCj4gICAgICDCoF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gICAgICA+wqAgwqAgwqAgPg0KPiAgICAgID7CoCDCoCDCoCA+wqAg wqAgwqAgwqAgwqAgwqAgwqBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgwqBzcHJpbmcgbWFp bGluZyBsaXN0DQo+ICAgICAgPsKgIMKgIMKgID4gc3ByaW5nQGlldGYub3JnIDxtYWlsdG86c3By aW5nQGlldGYub3JnPg0KPiAgICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJp bmdAaWV0Zi5vcmc+Pg0KPiAgICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJp bmdAaWV0Zi5vcmc+DQo+ICAgICAgPsKgIMKgIMKgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmcgPG1h aWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pj4NCj4gICAgICA+wqAgwqAgwqAgPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZ19fX18NCj4gICAgICA+wqAgwqAgwqAgPg0K PiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiAgICAgID7CoCDCoCDCoCA+wqAgwqAgwqBzcHJpbmcgbWFpbGlu ZyBsaXN0DQo+ICAgICAgPsKgIMKgIMKgID4gc3ByaW5nQGlldGYub3JnIDxtYWlsdG86c3ByaW5n QGlldGYub3JnPg0KPiAgICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJpbmdA aWV0Zi5vcmc+Pg0KPiAgICAgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJpbmdA aWV0Zi5vcmc+DQo+ICAgICAgPsKgIMKgIMKgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmcgPG1haWx0 bzpzcHJpbmdAaWV0Zi5vcmc+Pj4NCj4gICAgICA+wqAgwqAgwqAgPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KPiAgICAgID7CoCDCoCDCoCA+DQo+ICAgICAg Pg0KPiAgICAgID7CoCDCoCDCoC0tDQo+ICAgICAgPg0KPiAgICAgID4NCj4gICAgICA+wqAgwqAg wqBMb2EgQW5kZXJzc29uwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZW1haWw6 IGxvYUBwaS5udQ0KPiAgICAgPG1haWx0bzpsb2FAcGkubnU+IDxtYWlsdG86bG9hQHBpLm51IDxt YWlsdG86bG9hQHBpLm51Pj4NCj4gICAgICA+wqAgwqAgwqBTZW5pb3IgTVBMUyBFeHBlcnQNCj4g ICAgICA+wqAgwqAgwqBCcm9uemUgRHJhZ29uIENvbnN1bHRpbmfCoCDCoCDCoCDCoCDCoCDCoCDC oHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo+ICAgICAgPg0KPiAgICAgID4NCj4gICAgICA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICAgPiBz cHJpbmcgbWFpbGluZyBsaXN0DQo+ICAgICAgPiBzcHJpbmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJp bmdAaWV0Zi5vcmc+DQo+ICAgICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NwcmluZw0KPiAgICAgID4NCj4gDQo+ICAgICAtLQ0KPiANCj4gDQo+ICAgICBMb2EgQW5k ZXJzc29uwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZW1haWw6IGxvYUBwaS5u dSA8bWFpbHRvOmxvYUBwaS5udT4NCj4gICAgIFNlbmlvciBNUExTIEV4cGVydA0KPiAgICAgQnJv bnplIERyYWdvbiBDb25zdWx0aW5nwqAgwqAgwqAgwqAgwqAgwqAgwqBwaG9uZTogKzQ2IDczOSA4 MSAyMSA2NA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IHNwcmluZyBtYWlsaW5nIGxpc3QNCj4gc3ByaW5nQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQo+IA0KDQotLSANCg0K DQpMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBwaS5udQ0K U2VuaW9yIE1QTFMgRXhwZXJ0DQpCcm9uemUgRHJhZ29uIENvbnN1bHRpbmcgICAgICAgICAgICAg cGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From nobody Sun Feb 24 20:49: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 8B8C7130DD3; Sun, 24 Feb 2019 20:49:47 -0800 (PST) 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 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 CCYYLwV9ZlNb; Sun, 24 Feb 2019 20:49:44 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD1512D4E7; Sun, 24 Feb 2019 20:49:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48880; q=dns/txt; s=iport; t=1551070184; x=1552279784; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LFyI5QHXApXrNzpkdLFsI7IxDyM6qMaIVBJ09f4OjTA=; b=Vv74iAumM/2ygCDSb/FXkKNP8UJEkWrQqXayJkZC0G6pP51KEfmM5ZcB VTGmHXo8dpQ6tIGxQDnkUujBz6RVFt7rtiqBejRTlXLOEkt9RFeAfpKbb bDHa57CMJGm7s835mOp5M8hFVHybYSzG56ciIDvDu+GapaHH/7oNoRI41 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACycnNc/5pdJa1bChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYENTCpngQMnCoN+iBqXEY5xgXsLAQE?= =?us-ascii?q?jhEkCF4NnIjQJDQEDAQECAQECbRwMhUsGI0QSEAIBCBImAQYDAgICHxEUAw4?= =?us-ascii?q?CBA4FgyABgQ5MAxUPqlOBL4RDQYJ0DYIZBYxIF4FAP4ERJx+CTIJXRwEBAwG?= =?us-ascii?q?BMgQmgwsxgiYCigkDB4F+KYN9hxuLMgUkMwkChz+DM4Q1gz0ZgXGFW4NDhGa?= =?us-ascii?q?DHotlhECBLogngmwCERSBKB84gVZwFRpLAYINATM+gWoFEoEAAQiHVoU/QTG?= =?us-ascii?q?NPoEugR8BAQ?= X-IronPort-AV: E=Sophos;i="5.58,410,1544486400"; d="scan'208,217";a="241860934" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Feb 2019 04:49:43 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x1P4ngP3022994 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Feb 2019 04:49:42 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 24 Feb 2019 23:49:41 -0500 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1395.000; Sun, 24 Feb 2019 23:49:41 -0500 From: "Carlos Pignataro (cpignata)" To: "Andrew G. Malis" CC: "ops-dir@ietf.org" , mpls , "draft-ietf-mpls-sfc-encapsulation.all@ietf.org" , IETF Discussion , "sfc@ietf.org" Thread-Topic: [mpls] Opsdir last call review of draft-ietf-mpls-sfc-encapsulation-02 Thread-Index: AQHUyhBL6QxMzhBFbEuO+4PZE0wBEaXrX0GAgADV+YCABBV+gA== Date: Mon, 25 Feb 2019 04:49:41 +0000 Message-ID: <7CB3E446-C745-42B4-A6A0-31028E1569C3@cisco.com> References: <155072147698.20210.381511429964485828@ietfa.amsl.com> <6A97863A-DD90-4D62-9607-569386F5F850@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.102.3) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.70.231.8] Content-Type: multipart/alternative; boundary="_000_7CB3E446C74542B4A6A031028E1569C3ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.157, xch-rtp-017.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [mpls] Opsdir last call review of draft-ietf-mpls-sfc-encapsulation-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: Mon, 25 Feb 2019 04:49:48 -0000 --_000_7CB3E446C74542B4A6A031028E1569C3ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEFuZHkhDQoNCllvdSBjYW4gZmluZCBzb21lIHByb3RvY29scyB1c2luZyBHVFNNIGF0 IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzUwODIvcmVmZXJlbmNlZGJ5Lywg aW5jbHVkaW5nIHJmYzY3MjAsIHJmYzczMjUsIHJmYzc4ODUsIGFuZCBvdGhlcnMuDQoNClRvIG1l LCBzcGVjaWZ5aW5nIHRoZSBUVEwgYmVoYXZpb3IgZWFybHkgb24gaXMgY3JpdGljYWwgdG8gbWFr ZSB1c2Ugb2YgaXQgYmVmb3JlIHZhcmlvdXMgaW1wbGVtZW50YXRpb25zIHVzZSBpbmNvbXBhdGli bGUgdmFsdWVzLiBGb3IgZXhhbXBsZSwgZWl0aGVyIHVzaW5nIDI1NSBmb3IgR1RTTSwgb3IgdXNp bmcgMSBvciBzaW1pbGFyIHRvIGVuc3VyZSB0aGVyZeKAmXMgbm8gbWlzLWZvcndhcmRpbmcsIGFy ZSBhcHByb3ByaWF0ZSBwb3NpdGlvbnMuIEJ1dCBJIHdvdWxkIGxpa2UgdG8gaGF2ZSB0aGlzIGV4 cGxpY2l0bHkgc3RhdGVkIHdoaWNoZXZlciB3YXkuDQoNClRoYW5rcywNCg0K4oCUIENhcmxvcyBQ aWduYXRhcm8NCg0KT24gRmViIDIyLCAyMDE5LCBhdCAxMToyNyBQTSwgQW5kcmV3IEcuIE1hbGlz IDxhZ21hbGlzQGdtYWlsLmNvbTxtYWlsdG86YWdtYWxpc0BnbWFpbC5jb20+PiB3cm90ZToNCg0K Q2FybG9zLA0KDQpMb29rcyBnb29kIG9uIGFsbCBidXQgb25lIHBvaW50IC0gSSB0aGluayBJIHNl ZSB3aHkgeW91J3JlIHJlZmVyZW5jaW5nIEdUU00sIHNpbmNlIHBhY2tldHMgYXQgdGhlIFNGQyBs YXllciB3b3VsZCBnZW5lcmFsbHkgYmUgb25lIGhvcCBhd2F5IGZyb20gZWFjaCBvdGhlciBhdCB0 aGF0IGxheWVyLiBJcyB0aGF0IGNvcnJlY3Q/IEhvd2V2ZXIsIEkgcmVhbGx5IGRvbid0IGhhdmUg c3VmZmljaWVudCBleHBlcmllbmNlIHdpdGggR1RTTSB0byBjcmFmdCBzcGVjaWZpYyB0ZXh0LiBJ ZiB5b3UgdGhpbmsgaXQncyBpbXBvcnRhbnQgZW5vdWdoIHRvIGluY2x1ZGUsIGNvdWxkIHlvdSBw cm9wb3NlIHNvbWUgdGV4dCBmb3IgbWUgdG8gaW5jbHVkZT8NCg0KVGhhbmtzIGFnYWluLA0KQW5k eQ0KDQoNCk9uIFRodSwgRmViIDIxLCAyMDE5IGF0IDg6NDEgUE0gQ2FybG9zIFBpZ25hdGFybyAo Y3BpZ25hdGEpIDxjcGlnbmF0YUBjaXNjby5jb208bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbT4+ IHdyb3RlOg0KSGksIEFuZHksDQoNCk9uIEZlYiAyMSwgMjAxOSwgYXQgMTowNiBQTSwgQW5kcmV3 IEcuIE1hbGlzIDxhZ21hbGlzQGdtYWlsLmNvbTxtYWlsdG86YWdtYWxpc0BnbWFpbC5jb20+PiB3 cm90ZToNCg0KQ2FybG9zLA0KDQpNYW55IHRoYW5rcyBmb3IgeW91ciByZXZpZXchIEknbSBhbHNv IGluY2x1ZGluZyB0aGUgU0ZDIFdHIG9uIG15IHJlcGx5Lg0KDQpUaGFua3MgZm9yIHRoZSBxdWlj ayByZXNwb25zZSwgYW5kIGZvciBjb25zaWRlcmluZyB0aGUgY29tbWVudHMhDQoNCkkgZW5qb3ll ZCByZWFkaW5nIHRoaXMgZG9jdW1lbnQg4oCUIHBsZWFzZSBzZWUgYmVsb3cuDQoNCg0KQ29tbWVu dHMgaW5saW5lLg0KDQpPbiBXZWQsIEZlYiAyMCwgMjAxOSBhdCAxMDo1OCBQTSBDYXJsb3MgUGln bmF0YXJvIDxjcGlnbmF0YUBjaXNjby5jb208bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbT4+IHdy b3RlOg0KUmV2aWV3ZXI6IENhcmxvcyBQaWduYXRhcm8NClJldmlldyByZXN1bHQ6IEhhcyBJc3N1 ZXMNCg0KUmV2aWV3ZXI6IENhcmxvcyBQaWduYXRhcm8NClJldmlldyBSZXN1bHQ6IEhhcyBJc3N1 ZXMNCg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgT3BlcmF0 aW9uYWwgZGlyZWN0b3JhdGUncw0Kb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRv Y3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZQ0KY29tbWVudHMgd2Vy ZSB3cml0dGVuIHdpdGggdGhlIGludGVudCBvZiBpbXByb3ZpbmcgdGhlIG9wZXJhdGlvbmFsIGFz cGVjdHMgb2YNCnRoZSBJRVRGIGRyYWZ0cy4gQ29tbWVudHMgdGhhdCBhcmUgbm90IGFkZHJlc3Nl ZCBpbiBsYXN0IGNhbGwgbWF5IGJlIGluY2x1ZGVkDQppbiBBRCByZXZpZXdzIGR1cmluZyB0aGUg SUVTRyByZXZpZXcuICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkDQp0cmVh dCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4N Cg0KVGhpcyBkb2N1bWVudCBpcyBoaWdobHkgcmVhZGFibGUsIGluY2x1ZGVzIHZlcnkgY2xlYXIg dGV4dHVhbCBkZXNjcmlwdGlvbnMsIGFuZA0KaXMgdmVyeSB3ZWxsIG9yZ2FuaXplZC4gRWFzeSB0 byByZWFkIGluIGl0cyBzaW1wbGljaXR5LiBIb3dldmVyLCBpdCB3b3VsZA0KYmVuZWZpdCBmcm9t IGEgbW9yZSBleHBsaWNpdCBjb25uZWN0aW9uIHRvIHRoZSB0cmFuc3BvcnQgZW5jYXAgbWVjaGFu aWNzIGZyb20NClJGQyA4MzAwIChlLmcuLCBTNCwgUzYuMSkuIFNwZWNpZmljYWxseSwgSSdkIHJl Y29tbWVuZCBhZGRpbmcgYSBGaWd1cmUgb3IgYW4NClNGRiBOU0ggTWFwcGluZyBUYWJsZSBleGFt cGxlLCB0byBkZXBpY3QgYW5kL29yIGV4ZW1wbGlmeSB0aGUgU0ZGIGZ1bmN0aW9uLg0KDQpJJ20g dHJ5aW5nIHRvIGVudmlzaW9uIHdoYXQgd291bGQgbWFrZSBhIGdvb2QgZmlndXJlIGhlcmUuIFdl IGNvdWxkIGFkZCBhbiBhZGRpdGlvbmFsIGxpbmUgdG8gVGFibGUgMSBvZiBSRkMgODMwMCBhbmQg cmVmZXJlbmNlIHRoYXQgdGFibGU6DQoNCg0KICAgICAgKy0tLS0tLSstLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCiAgICAgIHwgU1BJICB8 IFNJICAgfCBOZXh0IEhvcChzKSAgICAgICAgIHwgVHJhbnNwb3J0IEVuY2Fwc3VsYXRpb24gfA0K ICAgICAgKy0tLS0tLSstLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rDQoNCiAgICAgIHwgMjUgICB8IDIyMCAgfCBMYWJlbCA1NDY3ICAgICAgICAg IHwgTVBMUyAgICAgICAgICAgICAgICAgICAgfA0KDQogICAgICArLS0tLS0tKy0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KSXMgdGhhdCB3 aGF0IHlvdSBoYWQgaW4gbWluZD8gSWYgbm90LCBJJ20gb3BlbiB0byBvdGhlciBzdWdnZXN0aW9u cy4NCg0KSWYgeW91IHRoaW5rIGl0IGhlbHBzLCB0aGlzIHdvdWxkIGJlIGEgZ29vZCBhZGRpdGlv bi4NCg0KDQoNCj5Gcm9tIGFuIE9wZXJhdGlvbmFsIHN0YW5kcG9pbnQsIHRoZSBkb2N1bWVudCBz ZWVtcyBsYXJnZWx5IGFwcHJvcHJpYXRlIGluIHRlcm1zDQpvZiBkYXRhcGxhbmUgY29uc2lkZXJh dGlvbnMuIFNvbWUga2V5IGNvbnNpZGVyYXRpb25zIGFyZSBleHBsaWNpdGx5IG91dCBvZg0Kc2Nv cGU6DQogICBUaGUgbWV0aG9kIHVzZWQgYnkgdGhlIGRvd25zdHJlYW0gcmVjZWl2aW5nIG5vZGUg dG8gYWR2ZXJ0aXNlIFNGRg0KICAgTGFiZWxzIHRvIHRoZSB1cHN0cmVhbSBzZW5kaW5nIG5vZGUg aXMgb3V0IG9mIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNClRoaXMgcmVhbGx5IHNlZW1zIHRv IG1lYW4gdGhhdCwgd2l0aCB0aGUgc2ltcGxlIGRlZmluaXRpb24gaW4gdGhpcw0KSW5mb3JtYXRp b25hbCBkb2N1bWVudCwgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMgY2Fubm90IHlldCBl eGlzdC4gSWYNCnRoZXJlIGlzIG5vIG1lY2hhbmlzbSB0byBhZHZlcnRpc2UgdGhlIFNGRiBMYWJl bCBvciB0byBtYW5hZ2UgdGhlIHNlbWFudGljcyBvZg0KdGhpcyBwYXJ0aWN1bGFyIGxhYmVsLCBo b3cgd2lsbCBpdCBrbm93PyBTdGF0aWMgY29uZmlndXJhdGlvbiwgd2hpY2ggaXMgbm90DQpjb3Zl cmVkIGFueXdheSwgaXMgbm90IGluIG15IGh1bWJsZSBvcGluaW9uIGEgbWFuYWdlYWJsZSBzY2Fs YWJsZSBhcHByb2FjaC4NCg0KQWN0dWFsbHksIHdoaWxlIGl0IGlzIG91dHNpZGUgdGhlIHNjb3Bl IG9mIHRoaXMgZG9jdW1lbnQsIGl0IGlzIHdpdGhpbiB0aGUgc2NvcGUgb2YgZHJhZnQtaWV0Zi1i ZXNzLW5zaC1iZ3AtY29udHJvbC1wbGFuZSwgYW5kIHRleHQgaXMgYmVpbmcgYWRkZWQgdG8gdGhl IG5leHQgcmV2aXNpb24gb2YgdGhhdCBkcmFmdCB0byBzaG93IGhvdyBpdCBjYW4gYmUgdXNlZCB0 byBzaWduYWwgdGhlIGVuY2Fwc3VsYXRpb24gZGVmaW5lZCBoZXJlLiBUaGlzIHdhcyB3b3JrZWQg b3V0IGFmdGVyIHRoaXMgZHJhZnQgd2FzIGZvcndhcmRlZCB0byB0aGUgSUVTRywgYnV0IHdlIGNh biBub3cgYWRkIGEgcmVmZXJlbmNlIHRvIHRoYXQgZHJhZnQgc2VlaW5nIGFzIHdlJ2xsIGJlIGRv aW5nIGEgcG9zdC1sYXN0LWNhbGwgdXBkYXRlLg0KDQpJIHRoaW5rIHRoYXQgd2lsbCBoZWxwLCBh cyBhbiBJbmZvcm1hdGl2ZSDigJxvbmUgZW1ib2RpbWVudOKAnSB0eXBlIG9mIGxpbmsuDQoNCg0K DQpUaXRsZTogTVBMUyBFbmNhcHN1bGF0aW9uIEZvciBUaGUgU0ZDIE5TSA0KDQpSRkMgODMwMCBt YWtlcyBhbiBleHBsaWNpdCBkaXN0aW5jdGlvbiBiZXR3ZWVuIHRoZSB0ZXJtcyAnZW5jYXBzdWxh dGlvbicgYW5kDQondHJhbnNwb3J0IGVuY2Fwc3VsYXRpb24nIChzZWUgZS5nLiwgRmlndXJlIDEs IFNlY3Rpb24gMS41IDUuLCBhbmQgU2VjdGlvbiA0IG9mDQpSRkMgODMwMCkuDQoNCkl0IHNlZW1z IHRvIG1lIHRoYXQgdGhpcyBpcyB0aGUgIk1QTFMgVHJhbnNwb3J0IEVuY2Fwc3VsYXRpb24gZm9y IHRoZSBTRkMgTlNIIg0KDQpUaGFua3MsIHdlJ2xsIGZpeCB0aGF0Lg0KDQoNCjIuICBNUExTIEVu Y2Fwc3VsYXRpb24gVXNpbmcgYW4gU0ZGIExhYmVsDQoNClNpbWlsYXJseSwgIjIuIE1QTFMgVHJh bnNwb3J0IEVuY2Fwc3VsYXRpb24gVXNpbmcgYW4gU0ZGIExhYmVsIg0KDQogICBUaGUgZW5jYXBz dWxhdGlvbiBpcyBhIHN0YW5kYXJkIE1QTFMgbGFiZWwgc3RhY2sgW1JGQzMwMzJdIHdpdGggYW4N CiAgIFNGRiBMYWJlbCBhdCB0aGUgYm90dG9tIG9mIHRoZSBzdGFjaywgZm9sbG93ZWQgYnkgYSBO U0ggYXMgZGVmaW5lZCBieQ0KICAgW1JGQzgzMDBdIGFuZCB0aGUgTlNIIHBheWxvYWQuDQoNCklu c3RlYWRmIG9mICJOU0ggcGF5bG9hZCIgSSB0aGluayAib3JpZ25hbCBwYWNrZXQiIGlzIG1lYW50 Lg0KDQpSRkMgODMwMCB1c2VzIGJvdGggInBheWxvYWQiIGFuZCAib3JpZ2luYWwgcGFja2V0L2Zy YW1lIiwgYnV0IHRoZSBsYXR0ZXIgbW9yZSB0aGFuIHRoZSBmb3JtZXIuIFNvIHdlIGNhbiBjaGFu Z2UgInBheWxvYWQiIHRvICJvcmlnaW5hbCBwYWNrZXQvZnJhbWUiLg0KDQoNCkFsc28sIHRoaXMg ZW5jYXBzdWxhdGlvbiBpcyBVbmRlcmRlZmluZWQ6IFdoYXQgaXMgdGhlIHZhbHVlIG9mIFRUTD8g VEM/DQoNCkkndmUgYmVlbiBsb29raW5nIGJhY2sgYXQgb3RoZXIgcmVsYXRlZCBSRkNzIChzdWNo IGFzIFBXIGFuZCBJUCBWUE4gbGFiZWwgZGVmaW5pdGlvbnMpIGFuZCB0aGV5J3JlIGFsc28gbW9z dGx5IHNpbGVudCBvbiB0aGVzZSB2YWx1ZXMuIEkgZGlkIGZpbmQgdGhlIGZvbGxvd2luZyBpbiBS RkMgNjA3MzoNCg0KDQogICBUaGUgc2V0dGluZyBvZiB0aGUgVFRMIG9mIHRoZSBQVyBNUExTDQog ICBsYWJlbCBpcyBhIG1hdHRlciBvZiBsb2NhbCBwb2xpY3kgb24gdGhlIG9yaWdpbmF0aW5nIFBF LCBidXQgU0hPVUxEDQogICBiZSBzZXQgdG8gMjU1Lg0KDQpSZWdhcmRpbmcgdGhlIFRDLCB3ZSBj YW4gZm9sbG93IHRoZSBleGFtcGxlIG9mIFJGQyA2MzkxOg0KDQoNCiAgIFRoaXMgZG9jdW1lbnQg ZG9lcyBub3QgZGVmaW5lIGEgdXNlIGZvciB0aGUgVHJhZmZpYyBDbGFzcyAoVEMpIGZpZWxkDQog ICBbUkZDNTQ2MjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTQ2Mj5dIChmb3JtZXJs eSBrbm93biBhcyB0aGUgRXhwZXJpbWVudGFsIFVzZSAoRVhQKSBiaXRzDQogICBbUkZDMzAzMjxo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzAzMj5dKSBpbiB0aGUgZmxvdyBsYWJlbC4g IEZ1dHVyZSBkb2N1bWVudHMgbWF5IGRlZmluZSBhIHVzZSBmb3INCiAgIHRoZXNlIGJpdHM7IHRo ZXJlZm9yZSwgaW1wbGVtZW50YXRpb25zIGNvbmZvcm1pbmcgdG8gdGhpcw0KICAgc3BlY2lmaWNh dGlvbiBNVVNUIHNldCB0aGUgVEMgZmllbGQgdG8gemVybyBhdCB0aGUgaW5ncmVzcyBhbmQgTVVT VA0KICAgaWdub3JlIHRoZW0gYXQgdGhlIGVncmVzcy4NCg0KDQpEbyB5b3UgaGF2ZSBhbnkgYWx0 ZXJuYXRpdmUgc3VnZ2VzdGlvbnM/DQoNClRoZXNlIHR3byBhcHByb2FjaGVzIHNvdW5kcyBnb29k IHRvIG1lLiBBbmQgQWNrIHRvIHRoZSBvdGhlciBwcmV2aW91cyByZXNwb25zZXMuDQoNCg0KDQog ICBNdWNoIGxpa2UgYSBwc2V1ZG93aXJlIGxhYmVsLCBhbiBTRkYgTGFiZWwgaXMgYWxsb2NhdGVk IGJ5IHRoZQ0KICAgZG93bnN0cmVhbSByZWNlaXZlciBvZiB0aGUgTlNIIGZyb20gaXRzIHBlci1w bGF0Zm9ybSBsYWJlbCBzcGFjZS4NCg0KQSBQVyBMYWJlbCBpcyBtb3JlIHJlc3RyaWN0aXZlLiBS RkMgODA3NyBzYXlzIGl0IE1VU1QgYmUgYWxsb2NhdGVkIGFzDQpwZXItcGxhdGZvcm06DQoNCiAg IGVncmVzcyBMU1Igb25seS4gIE5vdGUgdGhhdCB0aGUgUFcgbGFiZWwgbXVzdCBhbHdheXMgYmUg YXQgdGhlIGJvdHRvbQ0KICAgb2YgdGhlIHBhY2tldCdzIGxhYmVsIHN0YWNrLCBhbmQgbGFiZWxz IE1VU1QgYmUgYWxsb2NhdGVkIGZyb20gdGhlDQogICBwZXItcGxhdGZvcm0gbGFiZWwgc3BhY2Uu DQoNCklzIHRoaXMgdGhlIGNhc2UgZm9yIHRoZSBTRkYgTGFiZWwgYXMgd2VsbD8gSWYgc28sIHdo YXQgaXMgdGhlIGltcGxpY2F0aW9uIG9mDQp0aGUgTVVTVD8gSWYgbm90LCB3aHkgaXMgaXQgZGlm ZmVyZW50IHRoYW4gb3RoZXIgZXF1aXZhbGVudCBzaW1pbGFyIGxhYmVscz8NCg0KV2UgY2FuIGNo YW5nZSB0aGUgdGV4dCB0bzoNCg0KIE11Y2ggbGlrZSBhIHBzZXVkb3dpcmUgbGFiZWwsIGFuIFNG RiBMYWJlbCBNVVNUIGJlIGFsbG9jYXRlZCBieSB0aGUgZG93bnN0cmVhbSByZWNlaXZlciBvZiB0 aGUgTlNIIGZyb20gaXRzIHBlci1wbGF0Zm9ybSBsYWJlbCBzcGFjZSwgc2luY2UgdGhlIG1lYW5p bmcgb2YgdGhlIGxhYmVsIGlzIGlkZW50aWNhbCBpbmRlcGVuZGVudCBvZiB3aGljaCBpbmNvbWlu ZyBpbnRlcmZhY2UgaXQgaXMgcmVjZWl2ZWQgW1JGQzMwMzFdLg0KDQoNClRoYXTigJlzIGEgZ3Jl YXQgaW1wcm92ZW1lbnQuDQoNCg0KICAgMi4gIFB1c2ggdGhlIFNGRiBMYWJlbCB0byBpZGVudGlm eSB0aGUgZGVzaXJlZCBTRkYgaW4gdGhlIHJlY2VpdmluZw0KICAgICAgIE1QTFMgbm9kZS4NCg0K VFRMIHZhbHVlPyAxPyAyPyAyNTUgZm9yIEdUU00/IEdUU00gUkZDIDUwODIgY291bGQgYmUgdXNl ZCBoZXJlLg0KDQpBcyBJIG5vdGVkIGFib3ZlLCAyNTUsIGFsdGhvdWdoIEkgdXNlZCBSRkMgNjA3 MyBhcyBteSBzb3VyY2UgcmF0aGVyIHRoYW4gNTA4Mi4gV2UnbGwgYWRkIHRoYXQgaGVyZSBhcyB3 ZWxsLg0KDQoNClNvdW5kcyBnb29kLg0KVGhlc2UgcHJvdG9jb2xzIHVzZSA1MDgyIGluIG9uZSBm b3JtIG9yIGFub3RoZXI6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzUwODIv cmVmZXJlbmNlZGJ5Lw0KDQoNCjQuICBPcGVyYXRpb25zLCBBZG1pbmlzdHJhdGlvbiwgYW5kIE1h aW50ZW5hbmNlIChPQU0pIENvbnNpZGVyYXRpb25zDQoNCiAgIE9BTSBhdCB0aGUgU0ZDIExheWVy IGlzIGhhbmRsZWQgYnkgU0ZDLWRlZmluZWQgbWVjaGFuaXNtcyBbUkZDODMwMF0uDQogICBIb3dl dmVyLCBPQU0gbWF5IGJlIHJlcXVpcmVkIGF0IHRoZSBNUExTIHRyYW5zcG9ydCBsYXllci4gIElm IHNvLA0KICAgdGhlbiBzdGFuZGFyZCBNUExTLWxheWVyIE9BTSBtZWNoYW5pc21zIHN1Y2ggYXMg dGhlIEdlbmVyaWMNCiAgIEFzc29jaWF0ZWQgQ2hhbm5lbCBbUkZDNTU4Nl0gbGFiZWwgbWF5IGJl IHVzZWQuDQoNClJGQyA1NTg2IGlzIF9ub3RfIGFuIE9BTSBtZWNoYW5pc20uIEl0IGlzIGFuIGFz c29jaWF0ZWQgY2hhbm5lbCBjcmVhdGlvbg0KbWVjaGFuaXNtLCBvdmVyIHdoaWNoIE9BTSBjb3Vs ZCBiZSBjYXJyaWVkLg0KDQpUaHVzLCB3aGF0IHRyYWRpdGlvbmFsIE1QTFMgT0FNIGNhbiBiZSBj YXJyaWVkIGhlcmU/IFRoaW5ncyBsaWtlIFJGQyA0Mzc5IC8gUkZDDQo4MDI5IHdvdWxkIG5lZWQg dGhlIGRlZmluaXRpb24gb2YgYW4gU0ZGIExhYmVsIEZFQyAod2hpY2ggZG9lcyBub3QgZXhpc3Qp Lg0KV2hpY2ggb3RoZXIgb25lPyBJUC9JQ01QIHNlZW1zIG9mIHZlcnkgbGltaXRlZCB2YWx1ZS4N Cg0KVGhhdCdzIGEgZ29vZCBwb2ludCBhYm91dCBSRkMgNTU4Ni4gVGhlIGludGVudGlvbiBpcyB0 aGF0IHRoZSBNUExTIE9BTSB3b3VsZCBiZSBhdCB0aGUgdHJhbnNwb3J0IGxhYmVsIGxheWVyIGFi b3ZlIHRoZSBTRkYgbGFiZWwsIHNvIG1vc3QgYW55IE1QTFMtbGF5ZXIgT0FNIHdvdWxkIGJlIGFw cGxpY2FibGUuIFNvIGhvdyBhYm91dCByZXdvcmRpbmcgdG8gbWFrZSB0aGF0IG1vcmUgY2xlYXI6 DQoNCk9BTSBhdCB0aGUgU0ZDIExheWVyIGlzIGhhbmRsZWQgYnkgU0ZDLWRlZmluZWQgbWVjaGFu aXNtcyBbUkZDODMwMF0uIEhvd2V2ZXIsIE9BTSBtYXkgYmUgcmVxdWlyZWQgYXQgdGhlIE1QTFMg dHJhbnNwb3J0IGxheWVyLiAgSWYgc28sIHRoZW4gc3RhbmRhcmQgTVBMUy1sYXllciBPQU0gbWVj aGFuaXNtcyBtYXkgYmUgdXNlZCBhdCB0aGUgdHJhbnNwb3J0IGxhYmVsIGxheWVyICh0aGUgbGFi ZWxzIGFib3ZlIHRoZSBTRkYgbGFiZWwpLg0KDQpMb29rcyBnb29kIHRvIG1lLCB0aGFuayB5b3Uu DQoNCg0KDQo2LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KSGF2ZSB5b3UgY29uc2lkZXJl ZCB0aGUgdXNlIG9mIEdUU00/DQoNCk5vLCB3ZSBoYWRuJ3QuIENhbiB5b3UgcG9pbnQgbWUgdG8g YW55IGV4YW1wbGVzIG9mIEdUU00gYmVpbmcgdXNlZCBpbiBhbiBNUExTIG9yIFBXIGNvbnRleHQ/ DQoNClllcywgc2VlIGFib3ZlLg0KDQoNCg0KOC4gIFJlZmVyZW5jZXMNCg0KICAgW1JGQzc2NjVd ICBIYWxwZXJuLCBKLiwgRWQuIGFuZCBDLiBQaWduYXRhcm8sIEVkLiwgIlNlcnZpY2UgRnVuY3Rp b24NCiAgICAgICAgICAgICAgQ2hhaW5pbmcgKFNGQykgQXJjaGl0ZWN0dXJlIiwgUkZDIDc2NjUs DQogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM3NjY1LCBPY3RvYmVyIDIwMTUsDQogICAg ICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzc2NjU+Lg0KDQpT SG91bGQgUkZDIDc2NjUgYmUgTm9ybWF0aXZlPyBJdCBkZWZpbmVzIHRoZSAiU0ZGIiB3aGljaCBp cyBxdWl0ZSBjZW50cmFsIHRvDQp1bmRlcnN0YW5kaW5nIHRoaXMgZG9jdW1lbnQuDQoNCkdvb2Qg cG9pbnQuIEl0IHdhcyB0aGVyZSBiZWNhdXNlIDc2NjUgaXMgYW4gSW5mb3JtYXRpb25hbCBSRkMs IGJ1dCBSRkMgODA2NyBkb2VzIGFsbG93IG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIGluZm9ybWF0 aW9uYWwgUkZDcywgc28gSSdsbCBtb3ZlIGl0Lg0KDQoNClRoYW5rIHlvdS4NCg0KDQpPdGhlciBO aXRzIGFuZCBFZGl0b3JpYWxzOg0KDQogICBTRkYgTGFiZWxzIGFyZSBzaW1pbGFyIHRvIG90aGVy IHNlcnZpY2UgbGFiZWxzIGF0IHRoZSBib3R0b20gb2YgYW4NCiAgIE1QTFMgbGFiZWwgc3RhY2sg dGhhdCBkZW5vdGUgdGhlIGNvbnRlbnRzIG9mIHRoZSBNUExTIHBheWxvYWQgYmVpbmcNCiAgIG90 aGVyIHRoYW4gSVAsIHN1Y2ggYXMgYSBsYXllciAyIHBzZXVkb3dpcmUsIGFuIElQIHBhY2tldCB0 aGF0IGlzDQogICByb3V0ZWQgaW4gYSBWUE4gY29udGV4dCB3aXRoIGEgcHJpdmF0ZSBhZGRyZXNz LCBvciBhbiBFdGhlcm5ldA0KICAgdmlydHVhbCBwcml2YXRlIHdpcmUgc2VydmljZS4NCg0KVGhp cyBzYXlzICJiZWluZyBvdGhlciB0aGFuIElQLCBzdWNoIGFzIElQIiwgd2hpY2ggc2VlbXMgdG8g YmUNCnNlbGYtY29udHJhZGljdG9yeSA6LSkNCg0KOi0pDQoNCkhvdyBhYm91dCB3ZSBjaGFuZ2Ug Im90aGVyIHRoYW4gSVAsIiB0byAib3RoZXIgdGhhbiBhIG5vcm1hbGx5IHJvdXRlZCBJUCBwYWNr ZXTigJ0sDQoNClRoYXQgd291bGQgZGlzYW1iaWd1YXRlIGl0Lg0KDQpUaGFua3MgYWdhaW4uDQoN ClRvIG1lLCB0aGUgY29udHJvbCBwbGFuZSAvIGFkdmVydGlzZW1lbnQgd2FzIHRoZSBtb3N0IGlt cG9ydGFudCBvcGVyYXRpb25hbGx5LXJlbGV2YW50IGNvbW1lbnQuDQoNClRoYW5rcywNCg0KQ2Fy bG9zLg0KDQoNClRoYW5rcyBhZ2FpbiwNCkFuZHkNCg0KDQo= --_000_7CB3E446C74542B4A6A031028E1569C3ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <025644502686D8468EE6BAE256B71E9B@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRoYW5rcyBBbmR5ISZuYnNwOw0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+WW91IGNhbiBmaW5kIHNv bWUgcHJvdG9jb2xzIHVzaW5nIEdUU00gYXQmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9yZmM1MDgyL3JlZmVyZW5jZWRieS8iIGNsYXNzPSIiPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzUwODIvcmVmZXJlbmNlZGJ5LzwvYT4sIGluY2x1 ZGluZyZuYnNwO3JmYzY3MjAsIHJmYzczMjUsJm5ic3A7cmZjNzg4NSwgYW5kIG90aGVycy48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRv IG1lLCBzcGVjaWZ5aW5nIHRoZSBUVEwgYmVoYXZpb3IgZWFybHkgb24gaXMgY3JpdGljYWwgdG8g bWFrZSB1c2Ugb2YgaXQgYmVmb3JlIHZhcmlvdXMgaW1wbGVtZW50YXRpb25zIHVzZSBpbmNvbXBh dGlibGUgdmFsdWVzLiBGb3IgZXhhbXBsZSwgZWl0aGVyIHVzaW5nIDI1NSBmb3IgR1RTTSwgb3Ig dXNpbmcgMSBvciBzaW1pbGFyIHRvIGVuc3VyZSB0aGVyZeKAmXMgbm8gbWlzLWZvcndhcmRpbmcs IGFyZSBhcHByb3ByaWF0ZQ0KIHBvc2l0aW9ucy4gQnV0IEkgd291bGQgbGlrZSB0byBoYXZlIHRo aXMgZXhwbGljaXRseSBzdGF0ZWQgd2hpY2hldmVyIHdheS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0iY2Fy ZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB3 b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVh azogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0i d29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJl YWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xv cjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4NClRoYW5rcyw8L2Rpdj4N CjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjog bm9uZTsiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4NCuKAlCBDYXJsb3MgUGlnbmF0 YXJvPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBGZWIgMjIs IDIwMTksIGF0IDExOjI3IFBNLCBBbmRyZXcgRy4gTWFsaXMgJmx0OzxhIGhyZWY9Im1haWx0bzph Z21hbGlzQGdtYWlsLmNvbSIgY2xhc3M9IiI+YWdtYWxpc0BnbWFpbC5jb208L2E+Jmd0OyB3cm90 ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+Q2FybG9zLA0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+TG9va3MgZ29vZCBvbiBhbGwgYnV0 IG9uZSBwb2ludCAtIEkgdGhpbmsgSSBzZWUgd2h5IHlvdSdyZSByZWZlcmVuY2luZyBHVFNNLCZu YnNwO3NpbmNlIHBhY2tldHMgYXQgdGhlIFNGQyBsYXllciB3b3VsZCBnZW5lcmFsbHkgYmUgb25l IGhvcCBhd2F5IGZyb20gZWFjaCBvdGhlciBhdCB0aGF0IGxheWVyLiBJcyB0aGF0IGNvcnJlY3Q/ IEhvd2V2ZXIsIEkgcmVhbGx5IGRvbid0IGhhdmUgc3VmZmljaWVudCBleHBlcmllbmNlIHdpdGgN CiBHVFNNIHRvIGNyYWZ0IHNwZWNpZmljJm5ic3A7dGV4dC4gSWYgeW91IHRoaW5rIGl0J3MgaW1w b3J0YW50IGVub3VnaCB0byBpbmNsdWRlLCBjb3VsZCB5b3UgcHJvcG9zZSBzb21lIHRleHQgZm9y IG1lIHRvIGluY2x1ZGU/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MgYWdhaW4sPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkFuZHk8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNz PSJnbWFpbF9hdHRyIj5PbiBUaHUsIEZlYiAyMSwgMjAxOSBhdCA4OjQxIFBNIENhcmxvcyBQaWdu YXRhcm8gKGNwaWduYXRhKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbSIg Y2xhc3M9IiI+Y3BpZ25hdGFAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4 IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFk ZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJvdmVyZmxvdy13cmFwOiBicmVhay13b3JkOyIg Y2xhc3M9IiI+SGksIEFuZHksDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ T24gRmViIDIxLCAyMDE5LCBhdCAxOjA2IFBNLCBBbmRyZXcgRy4gTWFsaXMgJmx0OzxhIGhyZWY9 Im1haWx0bzphZ21hbGlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmFnbWFs aXNAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9ImdtYWlsLW1fLTkz NjU2NTY2NjkzMzg0MjQxNkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXpl OjEycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2Vp Z2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWlu ZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFj aW5nOjBweDt0ZXh0LWRlY29yYXRpb246bm9uZSIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Q2FybG9zLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+TWFueSB0aGFua3MgZm9yIHlvdXIgcmV2 aWV3ISBJJ20gYWxzbyBpbmNsdWRpbmcgdGhlIFNGQyBXRyBvbiBteSByZXBseS48L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyBmb3IgdGhlIHF1aWNrIHJlc3Bv bnNlLCBhbmQgZm9yIGNvbnNpZGVyaW5nIHRoZSBjb21tZW50cyE8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgZW5qb3llZCByZWFkaW5n IHRoaXMgZG9jdW1lbnQg4oCUIHBsZWFzZSBzZWUgYmVsb3cuPC9kaXY+DQo8YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGRpcj0ibHRyIiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhO2ZvbnQtc2l6ZToxMnB4O2Zv bnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDpub3Jt YWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4 O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHg7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Db21t ZW50cyBpbmxpbmUuPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90 ZSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gV2VkLCBGZWIgMjAsIDIw MTkgYXQgMTA6NTggUE0gQ2FybG9zIFBpZ25hdGFybyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNwaWdu YXRhQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmNwaWduYXRhQGNpc2NvLmNv bTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0 OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KUmV2aWV3ZXI6 IENhcmxvcyBQaWduYXRhcm88YnIgY2xhc3M9IiI+DQpSZXZpZXcgcmVzdWx0OiBIYXMgSXNzdWVz PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUmV2aWV3ZXI6IENhcmxvcyBQaWduYXRhcm88 YnIgY2xhc3M9IiI+DQpSZXZpZXcgUmVzdWx0OiBIYXMgSXNzdWVzPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUg T3BlcmF0aW9uYWwgZGlyZWN0b3JhdGUnczxiciBjbGFzcz0iIj4NCm9uZ29pbmcgZWZmb3J0IHRv IHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiZu YnNwOyBUaGVzZTxiciBjbGFzcz0iIj4NCmNvbW1lbnRzIHdlcmUgd3JpdHRlbiB3aXRoIHRoZSBp bnRlbnQgb2YgaW1wcm92aW5nIHRoZSBvcGVyYXRpb25hbCBhc3BlY3RzIG9mPGJyIGNsYXNzPSIi Pg0KdGhlIElFVEYgZHJhZnRzLiBDb21tZW50cyB0aGF0IGFyZSBub3QgYWRkcmVzc2VkIGluIGxh c3QgY2FsbCBtYXkgYmUgaW5jbHVkZWQ8YnIgY2xhc3M9IiI+DQppbiBBRCByZXZpZXdzIGR1cmlu ZyB0aGUgSUVTRyByZXZpZXcuJm5ic3A7IERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBz aG91bGQ8YnIgY2xhc3M9IiI+DQp0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90 aGVyIGxhc3QgY2FsbCBjb21tZW50cy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGlz IGRvY3VtZW50IGlzIGhpZ2hseSByZWFkYWJsZSwgaW5jbHVkZXMgdmVyeSBjbGVhciB0ZXh0dWFs IGRlc2NyaXB0aW9ucywgYW5kPGJyIGNsYXNzPSIiPg0KaXMgdmVyeSB3ZWxsIG9yZ2FuaXplZC4g RWFzeSB0byByZWFkIGluIGl0cyBzaW1wbGljaXR5LiBIb3dldmVyLCBpdCB3b3VsZDxiciBjbGFz cz0iIj4NCmJlbmVmaXQgZnJvbSBhIG1vcmUgZXhwbGljaXQgY29ubmVjdGlvbiB0byB0aGUgdHJh bnNwb3J0IGVuY2FwIG1lY2hhbmljcyBmcm9tPGJyIGNsYXNzPSIiPg0KUkZDIDgzMDAgKGUuZy4s IFM0LCBTNi4xKS4gU3BlY2lmaWNhbGx5LCBJJ2QgcmVjb21tZW5kIGFkZGluZyBhIEZpZ3VyZSBv ciBhbjxiciBjbGFzcz0iIj4NClNGRiBOU0ggTWFwcGluZyBUYWJsZSBleGFtcGxlLCB0byBkZXBp Y3QgYW5kL29yIGV4ZW1wbGlmeSB0aGUgU0ZGIGZ1bmN0aW9uLjxiciBjbGFzcz0iIj4NCjwvYmxv Y2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPkknbSB0cnlpbmcgdG8gZW52aXNpb24gd2hhdCB3b3VsZCBtYWtlIGEgZ29vZCBmaWd1cmUg aGVyZS4gV2UgY291bGQgYWRkIGFuIGFkZGl0aW9uYWwgbGluZSB0byBUYWJsZSAxIG9mIFJGQyA4 MzAwIGFuZCByZWZlcmVuY2UgdGhhdCB0YWJsZTo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHByZSBjbGFzcz0iZ21haWwtbV8tOTM2 NTY1NjY2OTMzODQyNDE2Z21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7 bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7YnJlYWstYmVmb3JlOnBhZ2UiPiAgICAg ICYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PC9wcmU+DQo8cHJlIGNsYXNzPSJnbWFpbC1tXy05 MzY1NjU2NjY5MzM4NDI0MTZnbWFpbC1uZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNw eDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDticmVhay1iZWZvcmU6cGFnZSI+ICAg ICAgfCBTUEkgIHwgU0kgICB8IE5leHQgSG9wKHMpICAgICAgICAgfCBUcmFuc3BvcnQgRW5jYXBz dWxhdGlvbiB8DQogICAgICAmIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0tLS0tLS0t LS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOzwvcHJlPg0KPHByZSBj bGFzcz0iZ21haWwtbV8tOTM2NTY1NjY2OTMzODQyNDE2Z21haWwtbmV3cGFnZSIgc3R5bGU9ImZv bnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7YnJlYWst YmVmb3JlOnBhZ2UiPiAgICAgIHwgMjUgICB8IDIyMCAgfCBMYWJlbCA1NDY3ICAgICAgICAgIHwg TVBMUyAgICAgICAgICAgICAgICAgICAgfDwvcHJlPg0KPHByZSBjbGFzcz0iZ21haWwtbV8tOTM2 NTY1NjY2OTMzODQyNDE2Z21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7 bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7YnJlYWstYmVmb3JlOnBhZ2UiPiAgICAg ICYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PC9wcmU+DQo8YnIgY2xhc3M9ImdtYWlsLW1fLTkz NjU2NTY2NjkzMzg0MjQxNmdtYWlsLUFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPklzIHRoYXQgd2hhdCB5b3UgaGFkIGluIG1pbmQ/IElmIG5vdCwgSSdt IG9wZW4gdG8gb3RoZXIgc3VnZ2VzdGlvbnMuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPklmIHlvdSB0aGluayBpdCBoZWxwcywgdGhpcyB3b3VsZCBiZSBh IGdvb2QgYWRkaXRpb24uPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBzdHlsZT0iZm9u dC1mYW1pbHk6SGVsdmV0aWNhO2ZvbnQtc2l6ZToxMnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQt dmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9y bWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7 d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHg7dGV4dC1kZWNvcmF0aW9uOm5vbmUi IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9x dW90ZSI+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFw eCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGJyIGNsYXNzPSIi Pg0KJmd0O0Zyb20gYW4gT3BlcmF0aW9uYWwgc3RhbmRwb2ludCwgdGhlIGRvY3VtZW50IHNlZW1z IGxhcmdlbHkgYXBwcm9wcmlhdGUgaW4gdGVybXM8YnIgY2xhc3M9IiI+DQpvZiBkYXRhcGxhbmUg Y29uc2lkZXJhdGlvbnMuIFNvbWUga2V5IGNvbnNpZGVyYXRpb25zIGFyZSBleHBsaWNpdGx5IG91 dCBvZjxiciBjbGFzcz0iIj4NCnNjb3BlOjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtUaGUg bWV0aG9kIHVzZWQgYnkgdGhlIGRvd25zdHJlYW0gcmVjZWl2aW5nIG5vZGUgdG8gYWR2ZXJ0aXNl IFNGRjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtMYWJlbHMgdG8gdGhlIHVwc3RyZWFtIHNl bmRpbmcgbm9kZSBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBkb2N1bWVudC48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpUaGlzIHJlYWxseSBzZWVtcyB0byBtZWFuIHRoYXQsIHdpdGggdGhl IHNpbXBsZSBkZWZpbml0aW9uIGluIHRoaXM8YnIgY2xhc3M9IiI+DQpJbmZvcm1hdGlvbmFsIGRv Y3VtZW50LCBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucyBjYW5ub3QgeWV0IGV4aXN0LiBJ ZjxiciBjbGFzcz0iIj4NCnRoZXJlIGlzIG5vIG1lY2hhbmlzbSB0byBhZHZlcnRpc2UgdGhlIFNG RiBMYWJlbCBvciB0byBtYW5hZ2UgdGhlIHNlbWFudGljcyBvZjxiciBjbGFzcz0iIj4NCnRoaXMg cGFydGljdWxhciBsYWJlbCwgaG93IHdpbGwgaXQga25vdz8gU3RhdGljIGNvbmZpZ3VyYXRpb24s IHdoaWNoIGlzIG5vdDxiciBjbGFzcz0iIj4NCmNvdmVyZWQgYW55d2F5LCBpcyBub3QgaW4gbXkg aHVtYmxlIG9waW5pb24gYSBtYW5hZ2VhYmxlIHNjYWxhYmxlIGFwcHJvYWNoLjxiciBjbGFzcz0i Ij4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPkFjdHVhbGx5LCB3aGlsZSBpdCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0 aGlzIGRvY3VtZW50LCBpdCBpcyB3aXRoaW4gdGhlIHNjb3BlIG9mJm5ic3A7ZHJhZnQtaWV0Zi1i ZXNzLW5zaC1iZ3AtY29udHJvbC1wbGFuZSwgYW5kIHRleHQgaXMgYmVpbmcgYWRkZWQgdG8gdGhl IG5leHQgcmV2aXNpb24gb2YgdGhhdCBkcmFmdCB0byBzaG93IGhvdyBpdCBjYW4gYmUgdXNlZCB0 byBzaWduYWwgdGhlIGVuY2Fwc3VsYXRpb24gZGVmaW5lZA0KIGhlcmUuIFRoaXMgd2FzIHdvcmtl ZCBvdXQgYWZ0ZXIgdGhpcyBkcmFmdCB3YXMgZm9yd2FyZGVkIHRvIHRoZSBJRVNHLCBidXQgd2Ug Y2FuIG5vdyBhZGQgYSByZWZlcmVuY2UgdG8gdGhhdCBkcmFmdCBzZWVpbmcgYXMgd2UnbGwgYmUg ZG9pbmcgYSBwb3N0LWxhc3QtY2FsbCB1cGRhdGUuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgdGhpbmsgdGhhdCB3aWxsIGhlbHAsIGFzIGFuIEluZm9y bWF0aXZlIOKAnG9uZSBlbWJvZGltZW504oCdIHR5cGUgb2YgbGluay48L2Rpdj4NCjxiciBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjEy cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0 Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVu dDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5n OjBweDt0ZXh0LWRlY29yYXRpb246bm9uZSIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7PC9k aXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBw eCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGlu Zy1sZWZ0OjFleCI+DQo8YnIgY2xhc3M9IiI+DQpUaXRsZTogTVBMUyBFbmNhcHN1bGF0aW9uIEZv ciBUaGUgU0ZDIE5TSDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClJGQyA4MzAwIG1ha2Vz IGFuIGV4cGxpY2l0IGRpc3RpbmN0aW9uIGJldHdlZW4gdGhlIHRlcm1zICdlbmNhcHN1bGF0aW9u JyBhbmQ8YnIgY2xhc3M9IiI+DQondHJhbnNwb3J0IGVuY2Fwc3VsYXRpb24nIChzZWUgZS5nLiwg RmlndXJlIDEsIFNlY3Rpb24gMS41IDUuLCBhbmQgU2VjdGlvbiA0IG9mPGJyIGNsYXNzPSIiPg0K UkZDIDgzMDApLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkl0IHNlZW1zIHRvIG1lIHRo YXQgdGhpcyBpcyB0aGUgJnF1b3Q7TVBMUyBUcmFuc3BvcnQgRW5jYXBzdWxhdGlvbiBmb3IgdGhl IFNGQyBOU0gmcXVvdDs8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MsIHdlJ2xsIGZpeCB0 aGF0LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAw LjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6 MWV4Ij4NCjxiciBjbGFzcz0iIj4NCjIuJm5ic3A7IE1QTFMgRW5jYXBzdWxhdGlvbiBVc2luZyBh biBTRkYgTGFiZWw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTaW1pbGFybHksICZxdW90 OzIuIE1QTFMgVHJhbnNwb3J0IEVuY2Fwc3VsYXRpb24gVXNpbmcgYW4gU0ZGIExhYmVsJnF1b3Q7 PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO1RoZSBlbmNhcHN1bGF0 aW9uIGlzIGEgc3RhbmRhcmQgTVBMUyBsYWJlbCBzdGFjayBbUkZDMzAzMl0gd2l0aCBhbjxiciBj bGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtTRkYgTGFiZWwgYXQgdGhlIGJvdHRvbSBvZiB0aGUgc3Rh Y2ssIGZvbGxvd2VkIGJ5IGEgTlNIIGFzIGRlZmluZWQgYnk8YnIgY2xhc3M9IiI+DQombmJzcDsg Jm5ic3A7W1JGQzgzMDBdIGFuZCB0aGUgTlNIIHBheWxvYWQuPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KSW5zdGVhZGYgb2YgJnF1b3Q7TlNIIHBheWxvYWQmcXVvdDsgSSB0aGluayAmcXVv dDtvcmlnbmFsIHBhY2tldCZxdW90OyBpcyBtZWFudC48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5S RkMgODMwMCB1c2VzIGJvdGggJnF1b3Q7cGF5bG9hZCZxdW90OyBhbmQgJnF1b3Q7b3JpZ2luYWwg cGFja2V0L2ZyYW1lJnF1b3Q7LCBidXQgdGhlIGxhdHRlciBtb3JlIHRoYW4gdGhlIGZvcm1lci4g U28gd2UgY2FuIGNoYW5nZSAmcXVvdDtwYXlsb2FkJnF1b3Q7IHRvICZxdW90O29yaWdpbmFsIHBh Y2tldC9mcmFtZSZxdW90Oy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7PC9kaXY+DQo8Ymxv Y2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFl eCI+DQo8YnIgY2xhc3M9IiI+DQpBbHNvLCB0aGlzIGVuY2Fwc3VsYXRpb24gaXMgVW5kZXJkZWZp bmVkOiBXaGF0IGlzIHRoZSB2YWx1ZSBvZiBUVEw/IFRDPzxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PkkndmUgYmVlbiBsb29raW5nIGJhY2sgYXQgb3RoZXIgcmVsYXRlZCBSRkNzIChzdWNoIGFzIFBX IGFuZCBJUCBWUE4gbGFiZWwgZGVmaW5pdGlvbnMpIGFuZCB0aGV5J3JlIGFsc28gbW9zdGx5IHNp bGVudCBvbiB0aGVzZSB2YWx1ZXMuIEkgZGlkIGZpbmQgdGhlIGZvbGxvd2luZyBpbiBSRkMgNjA3 Mzo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPHByZSBjbGFzcz0iZ21haWwtbV8tOTM2NTY1NjY2OTMzODQyNDE2Z21haWwtbmV3cGFn ZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRv bTowcHg7YnJlYWstYmVmb3JlOnBhZ2UiPiAgIFRoZSBzZXR0aW5nIG9mIHRoZSBUVEwgb2YgdGhl IFBXIE1QTFMNCiAgIGxhYmVsIGlzIGEgbWF0dGVyIG9mIGxvY2FsIHBvbGljeSBvbiB0aGUgb3Jp Z2luYXRpbmcgUEUsIGJ1dCBTSE9VTEQNCiAgIGJlIHNldCB0byAyNTUuPC9wcmU+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlJlZ2Fy ZGluZyB0aGUgVEMsIHdlIGNhbiBmb2xsb3cgdGhlIGV4YW1wbGUgb2YgUkZDIDYzOTE6PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxw cmUgY2xhc3M9ImdtYWlsLW1fLTkzNjU2NTY2NjkzMzg0MjQxNmdtYWlsLW5ld3BhZ2UiIHN0eWxl PSJmb250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2Jy ZWFrLWJlZm9yZTpwYWdlIj4gICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGRlZmluZSBhIHVzZSBm b3IgdGhlIFRyYWZmaWMgQ2xhc3MgKFRDKSBmaWVsZA0KICAgWzxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM1NDYyIiB0aXRsZT0iJnF1b3Q7TXVsdGlwcm90b2NvbCBMYWJl bCBTd2l0Y2hpbmcgKE1QTFMpIExhYmVsIFN0YWNrIEVudHJ5OiAmcXVvdDsiIHRhcmdldD0iX2Js YW5rIiBjbGFzcz0iIj5SRkM1NDYyPC9hPl0gKGZvcm1lcmx5IGtub3duIGFzIHRoZSBFeHBlcmlt ZW50YWwgVXNlIChFWFApIGJpdHMNCiAgIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjMzAzMiIgdGl0bGU9IiZxdW90O01QTFMgTGFiZWwgU3RhY2sgRW5jb2RpbmcmcXVv dDsiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5SRkMzMDMyPC9hPl0pIGluIHRoZSBmbG93IGxh YmVsLiAgRnV0dXJlIGRvY3VtZW50cyBtYXkgZGVmaW5lIGEgdXNlIGZvcg0KICAgdGhlc2UgYml0 czsgdGhlcmVmb3JlLCBpbXBsZW1lbnRhdGlvbnMgY29uZm9ybWluZyB0byB0aGlzDQogICBzcGVj aWZpY2F0aW9uIE1VU1Qgc2V0IHRoZSBUQyBmaWVsZCB0byB6ZXJvIGF0IHRoZSBpbmdyZXNzIGFu ZCBNVVNUDQogICBpZ25vcmUgdGhlbSBhdCB0aGUgZWdyZXNzLg0KPC9wcmU+DQo8YnIgY2xhc3M9 ImdtYWlsLW1fLTkzNjU2NTY2NjkzMzg0MjQxNmdtYWlsLUFwcGxlLWludGVyY2hhbmdlLW5ld2xp bmUiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkRvIHlvdSBoYXZlIGFueSBhbHRlcm5hdGl2ZSBz dWdnZXN0aW9ucz88L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+VGhlc2UgdHdvIGFwcHJvYWNoZXMgc291bmRzIGdvb2QgdG8gbWUuIEFuZCBBY2sgdG8gdGhl IG90aGVyIHByZXZpb3VzIHJlc3BvbnNlcy48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIi IHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpu b3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXIt c3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFu c2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDt0ZXh0LWRlY29y YXRpb246bm9uZSIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90 ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9y ZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQo8 YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7TXVjaCBsaWtlIGEgcHNldWRvd2lyZSBsYWJlbCwg YW4gU0ZGIExhYmVsIGlzIGFsbG9jYXRlZCBieSB0aGU8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5i c3A7ZG93bnN0cmVhbSByZWNlaXZlciBvZiB0aGUgTlNIIGZyb20gaXRzIHBlci1wbGF0Zm9ybSBs YWJlbCBzcGFjZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBIFBXIExhYmVsIGlzIG1v cmUgcmVzdHJpY3RpdmUuIFJGQyA4MDc3IHNheXMgaXQgTVVTVCBiZSBhbGxvY2F0ZWQgYXM8YnIg Y2xhc3M9IiI+DQpwZXItcGxhdGZvcm06PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5i c3A7ICZuYnNwO2VncmVzcyBMU1Igb25seS4mbmJzcDsgTm90ZSB0aGF0IHRoZSBQVyBsYWJlbCBt dXN0IGFsd2F5cyBiZSBhdCB0aGUgYm90dG9tPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO29m IHRoZSBwYWNrZXQncyBsYWJlbCBzdGFjaywgYW5kIGxhYmVscyBNVVNUIGJlIGFsbG9jYXRlZCBm cm9tIHRoZTxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtwZXItcGxhdGZvcm0gbGFiZWwgc3Bh Y2UuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSXMgdGhpcyB0aGUgY2FzZSBmb3IgdGhl IFNGRiBMYWJlbCBhcyB3ZWxsPyBJZiBzbywgd2hhdCBpcyB0aGUgaW1wbGljYXRpb24gb2Y8YnIg Y2xhc3M9IiI+DQp0aGUgTVVTVD8gSWYgbm90LCB3aHkgaXMgaXQgZGlmZmVyZW50IHRoYW4gb3Ro ZXIgZXF1aXZhbGVudCBzaW1pbGFyIGxhYmVscz88YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XZSBj YW4gY2hhbmdlIHRoZSB0ZXh0IHRvOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7TXVjaCBsaWtlIGEgcHNldWRvd2lyZSBsYWJl bCwgYW4gU0ZGIExhYmVsIE1VU1QgYmUgYWxsb2NhdGVkIGJ5IHRoZSBkb3duc3RyZWFtIHJlY2Vp dmVyIG9mIHRoZSBOU0ggZnJvbSBpdHMgcGVyLXBsYXRmb3JtIGxhYmVsIHNwYWNlLCBzaW5jZSB0 aGUgbWVhbmluZyBvZiB0aGUgbGFiZWwgaXMgaWRlbnRpY2FsIGluZGVwZW5kZW50IG9mIHdoaWNo IGluY29taW5nIGludGVyZmFjZSBpdCBpcyByZWNlaXZlZCBbUkZDMzAzMV0uPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5UaGF04oCZcyBhIGdyZWF0IGltcHJvdmVtZW50LjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250LXNp emU6MTJweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13 ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQt aW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNw YWNpbmc6MHB4O3RleHQtZGVjb3JhdGlvbjpub25lIiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0 OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGJyIGNsYXNz PSIiPg0KJm5ic3A7ICZuYnNwOzIuJm5ic3A7IFB1c2ggdGhlIFNGRiBMYWJlbCB0byBpZGVudGlm eSB0aGUgZGVzaXJlZCBTRkYgaW4gdGhlIHJlY2VpdmluZzxiciBjbGFzcz0iIj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO01QTFMgbm9kZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpUVEwgdmFsdWU/IDE/IDI/IDI1NSBmb3IgR1RTTT8gR1RTTSBSRkMgNTA4MiBjb3VsZCBiZSB1 c2VkIGhlcmUuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QXMgSSBub3RlZCBhYm92ZSwgMjU1LCBh bHRob3VnaCBJIHVzZWQgUkZDIDYwNzMgYXMgbXkgc291cmNlIHJhdGhlciB0aGFuIDUwODIuIFdl J2xsIGFkZCB0aGF0IGhlcmUgYXMgd2VsbC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlNv dW5kcyBnb29kLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGVzZSBwcm90b2NvbHMgdXNlIDUwODIg aW4gb25lIGZvcm0gb3IgYW5vdGhlcjombmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9yZmM1MDgyL3JlZmVyZW5jZWRieS8iIHRhcmdldD0iX2JsYW5rIiBjbGFz cz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9yZmM1MDgyL3JlZmVyZW5jZWRi eS88L2E+PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBzdHlsZT0iZm9udC1mYW1pbHk6 SGVsdmV0aWNhO2ZvbnQtc2l6ZToxMnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1j YXBzOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQt YWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3Bh Y2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHg7dGV4dC1kZWNvcmF0aW9uOm5vbmUiIGNsYXNzPSIi Pg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHgg MC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0 OjFleCI+DQo8YnIgY2xhc3M9IiI+DQo0LiZuYnNwOyBPcGVyYXRpb25zLCBBZG1pbmlzdHJhdGlv biwgYW5kIE1haW50ZW5hbmNlIChPQU0pIENvbnNpZGVyYXRpb25zPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO09BTSBhdCB0aGUgU0ZDIExheWVyIGlzIGhhbmRsZWQg YnkgU0ZDLWRlZmluZWQgbWVjaGFuaXNtcyBbUkZDODMwMF0uPGJyIGNsYXNzPSIiPg0KJm5ic3A7 ICZuYnNwO0hvd2V2ZXIsIE9BTSBtYXkgYmUgcmVxdWlyZWQgYXQgdGhlIE1QTFMgdHJhbnNwb3J0 IGxheWVyLiZuYnNwOyBJZiBzbyw8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7dGhlbiBzdGFu ZGFyZCBNUExTLWxheWVyIE9BTSBtZWNoYW5pc21zIHN1Y2ggYXMgdGhlIEdlbmVyaWM8YnIgY2xh c3M9IiI+DQombmJzcDsgJm5ic3A7QXNzb2NpYXRlZCBDaGFubmVsIFtSRkM1NTg2XSBsYWJlbCBt YXkgYmUgdXNlZC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpSRkMgNTU4NiBpcyBfbm90 XyBhbiBPQU0gbWVjaGFuaXNtLiBJdCBpcyBhbiBhc3NvY2lhdGVkIGNoYW5uZWwgY3JlYXRpb248 YnIgY2xhc3M9IiI+DQptZWNoYW5pc20sIG92ZXIgd2hpY2ggT0FNIGNvdWxkIGJlIGNhcnJpZWQu PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGh1cywgd2hhdCB0cmFkaXRpb25hbCBNUExT IE9BTSBjYW4gYmUgY2FycmllZCBoZXJlPyBUaGluZ3MgbGlrZSBSRkMgNDM3OSAvIFJGQzxiciBj bGFzcz0iIj4NCjgwMjkgd291bGQgbmVlZCB0aGUgZGVmaW5pdGlvbiBvZiBhbiBTRkYgTGFiZWwg RkVDICh3aGljaCBkb2VzIG5vdCBleGlzdCkuPGJyIGNsYXNzPSIiPg0KV2hpY2ggb3RoZXIgb25l PyBJUC9JQ01QIHNlZW1zIG9mIHZlcnkgbGltaXRlZCB2YWx1ZS48YnIgY2xhc3M9IiI+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5UaGF0J3MgYSBnb29kIHBvaW50IGFib3V0IFJGQyA1NTg2LiBUaGUgaW50ZW50aW9uIGlz IHRoYXQgdGhlIE1QTFMgT0FNIHdvdWxkIGJlIGF0IHRoZSB0cmFuc3BvcnQgbGFiZWwgbGF5ZXIg YWJvdmUgdGhlIFNGRiBsYWJlbCwgc28gbW9zdCBhbnkgTVBMUy1sYXllciBPQU0gd291bGQgYmUg YXBwbGljYWJsZS4gU28gaG93IGFib3V0IHJld29yZGluZyB0byBtYWtlIHRoYXQgbW9yZSBjbGVh cjo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPk9BTSBhdCB0aGUgU0ZDIExheWVyIGlzIGhhbmRsZWQgYnkgU0ZDLWRlZmluZWQgbWVjaGFu aXNtcyBbUkZDODMwMF0uIEhvd2V2ZXIsIE9BTSBtYXkgYmUgcmVxdWlyZWQgYXQgdGhlIE1QTFMg dHJhbnNwb3J0IGxheWVyLiZuYnNwOyBJZiBzbywgdGhlbiBzdGFuZGFyZCBNUExTLWxheWVyIE9B TSBtZWNoYW5pc21zIG1heSBiZSB1c2VkIGF0IHRoZSB0cmFuc3BvcnQgbGFiZWwgbGF5ZXIgKHRo ZSBsYWJlbHMgYWJvdmUgdGhlIFNGRiBsYWJlbCkuPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpMb29rcyBnb29kIHRvIG1lLCB0aGFuayB5b3UuPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJmb250LWZhbWls eTpIZWx2ZXRpY2E7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50 LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4 dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1z cGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDt0ZXh0LWRlY29yYXRpb246bm9uZSIgY2xhc3M9 IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4N CjxkaXYgY2xhc3M9IiI+Jm5ic3A7PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBj bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVy LWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQo8YnIg Y2xhc3M9IiI+DQo2LiZuYnNwOyBTZWN1cml0eSBDb25zaWRlcmF0aW9uczxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCkhhdmUgeW91IGNvbnNpZGVyZWQgdGhlIHVzZSBvZiBHVFNNPzxiciBj bGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPk5vLCB3ZSBoYWRuJ3QuIENhbiB5b3UgcG9pbnQgbWUgdG8gYW55 IGV4YW1wbGVzIG9mIEdUU00gYmVpbmcgdXNlZCBpbiBhbiBNUExTIG9yIFBXIGNvbnRleHQ/PC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpZZXMsIHNlZSBhYm92ZS48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9ImZvbnQtZmFtaWx5Okhl bHZldGljYTtmb250LXNpemU6MTJweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fw czpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFs aWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNl Om5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4O3RleHQtZGVjb3JhdGlvbjpub25lIiBjbGFzcz0iIj4N CjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRp diBjbGFzcz0iIj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIg c3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdi KDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxiciBjbGFzcz0iIj4NCjguJm5ic3A7 IFJlZmVyZW5jZXM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7W1JG Qzc2NjVdJm5ic3A7IEhhbHBlcm4sIEouLCBFZC4gYW5kIEMuIFBpZ25hdGFybywgRWQuLCAmcXVv dDtTZXJ2aWNlIEZ1bmN0aW9uPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENoYWluaW5nIChTRkMpIEFyY2hpdGVjdHVyZSZxdW90 OywgUkZDIDc2NjUsPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IERPSSAxMC4xNzQ4Ny9SRkM3NjY1LCBPY3RvYmVyIDIwMTUsPGJy IGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZsdDs8YSBocmVmPSJodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzc2NjUi IHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LnJm Yy1lZGl0b3Iub3JnL2luZm8vcmZjNzY2NTwvYT4mZ3Q7LjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NClNIb3VsZCBSRkMgNzY2NSBiZSBOb3JtYXRpdmU/IEl0IGRlZmluZXMgdGhlICZxdW90 O1NGRiZxdW90OyB3aGljaCBpcyBxdWl0ZSBjZW50cmFsIHRvPGJyIGNsYXNzPSIiPg0KdW5kZXJz dGFuZGluZyB0aGlzIGRvY3VtZW50LjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkdvb2QgcG9pbnQu IEl0IHdhcyB0aGVyZSBiZWNhdXNlIDc2NjUgaXMgYW4gSW5mb3JtYXRpb25hbCBSRkMsIGJ1dCBS RkMgODA2NyBkb2VzIGFsbG93IG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIGluZm9ybWF0aW9uYWwg UkZDcywgc28gSSdsbCBtb3ZlIGl0LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NClRoYW5rIHlvdS48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtm b250LXNpemU6MTJweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7 Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3 b3JkLXNwYWNpbmc6MHB4O3RleHQtZGVjb3JhdGlvbjpub25lIiBjbGFzcz0iIj4NCjxkaXYgZGly PSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUg Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRl ci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGJy IGNsYXNzPSIiPg0KT3RoZXIgTml0cyBhbmQgRWRpdG9yaWFsczo8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQombmJzcDsgJm5ic3A7U0ZGIExhYmVscyBhcmUgc2ltaWxhciB0byBvdGhlciBz ZXJ2aWNlIGxhYmVscyBhdCB0aGUgYm90dG9tIG9mIGFuPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZu YnNwO01QTFMgbGFiZWwgc3RhY2sgdGhhdCBkZW5vdGUgdGhlIGNvbnRlbnRzIG9mIHRoZSBNUExT IHBheWxvYWQgYmVpbmc8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7b3RoZXIgdGhhbiBJUCwg c3VjaCBhcyBhIGxheWVyIDIgcHNldWRvd2lyZSwgYW4gSVAgcGFja2V0IHRoYXQgaXM8YnIgY2xh c3M9IiI+DQombmJzcDsgJm5ic3A7cm91dGVkIGluIGEgVlBOIGNvbnRleHQgd2l0aCBhIHByaXZh dGUgYWRkcmVzcywgb3IgYW4gRXRoZXJuZXQ8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7dmly dHVhbCBwcml2YXRlIHdpcmUgc2VydmljZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpU aGlzIHNheXMgJnF1b3Q7YmVpbmcgb3RoZXIgdGhhbiBJUCwgc3VjaCBhcyBJUCZxdW90Oywgd2hp Y2ggc2VlbXMgdG8gYmU8YnIgY2xhc3M9IiI+DQpzZWxmLWNvbnRyYWRpY3RvcnkgOi0pPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj46LSk8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PkhvdyBhYm91dCB3ZSBjaGFuZ2UgJnF1b3Q7b3RoZXIgdGhhbiBJUCwmcXVvdDsgdG8gJnF1b3Q7 b3RoZXIgdGhhbiBhIG5vcm1hbGx5IHJvdXRlZCBJUCBwYWNrZXTigJ0sPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQpUaGF0IHdvdWxkIGRpc2FtYmlndWF0ZSBpdC48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyBh Z2Fpbi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPlRvIG1lLCB0aGUgY29udHJvbCBwbGFuZSAvIGFkdmVydGlzZW1lbnQgd2FzIHRoZSBt b3N0IGltcG9ydGFudCBvcGVyYXRpb25hbGx5LXJlbGV2YW50IGNvbW1lbnQuPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MsPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5D YXJsb3MuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxl PSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpub3JtYWw7 Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2lu Zzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06 bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDt0ZXh0LWRlY29yYXRpb246 bm9uZSIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPlRoYW5rcyBhZ2Fpbiw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QW5keTwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_7CB3E446C74542B4A6A031028E1569C3ciscocom_-- From nobody Sun Feb 24 20:54: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 DD8BC130DD3; Sun, 24 Feb 2019 20:54:20 -0800 (PST) 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_HIGH=-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 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 6whIeuaFNvCs; Sun, 24 Feb 2019 20:54:17 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6581200D8; Sun, 24 Feb 2019 20:54:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=51684; q=dns/txt; s=iport; t=1551070456; x=1552280056; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0UwI39Hx+dDATmFOAe1CYQL9rwfYatnKxsdgn7muJkg=; b=fanhHv0h9JHF+jsfqAOBh6azmUQTL1cNq1SzFuSNQ+c7r3ddUuGcJAxu Iyb3EUWa8v9/xcUTpjviO16taT+XHWAy5xlY4OUoG1CuYDyE4rPayNgU5 +xL75tJCud+1lJlL2NO3EINDmvMpZ0H+9XHUZeIjtLOETg2wb6eP4/ahe w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAADQdHNc/5tdJa1bChoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVEFAQEBAQsBgQ1MKmeBAycKg36IGpcRjnGBewsBASOESQI?= =?us-ascii?q?Xg2ciNAkNAQMBAQIBAQJtHAyFSwYjRBIQAgEIEiYBBgMCAgIfERQDDgIEDgW?= =?us-ascii?q?DIAGBDkwDFQ+qUIEvhENBgnQNghkFjEgXgUA/gREnH4JMgldHAQEDAYEyBCa?= =?us-ascii?q?DCzGCJgKKCQMHgX4pg32HG4s3JDMJAoc/gzOENYM9GYFxhVuDQ4Rmgx6LZYR?= =?us-ascii?q?AgS6IJ4JsAhEUgSgfOIFWcBUaSwGCDQEzPoFqBRKBAAEIh1aFP0ExjT6BLoE?= =?us-ascii?q?fAQE?= X-IronPort-AV: E=Sophos;i="5.58,410,1544486400"; d="scan'208,217";a="240491829" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Feb 2019 04:54:14 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x1P4sE5I000580 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Feb 2019 04:54:14 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 24 Feb 2019 23:54:13 -0500 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1395.000; Sun, 24 Feb 2019 23:54:13 -0500 From: "Carlos Pignataro (cpignata)" To: "Joel M. Halpern" CC: "Andrew G. Malis" , mpls , "ops-dir@ietf.org" , "draft-ietf-mpls-sfc-encapsulation.all@ietf.org" , IETF Discussion , "sfc@ietf.org" Thread-Topic: [mpls] Opsdir last call review of draft-ietf-mpls-sfc-encapsulation-02 Thread-Index: AQHUyhBL6QxMzhBFbEuO+4PZE0wBEaXrX0GAgADV+YCAACX5AIAD8MoA Date: Mon, 25 Feb 2019 04:54:13 +0000 Message-ID: <7CA6EE6E-3D6C-4ACF-B9B4-540C57A658E8@cisco.com> References: <155072147698.20210.381511429964485828@ietfa.amsl.com> <6A97863A-DD90-4D62-9607-569386F5F850@cisco.com> <03769b15-8375-a23a-a882-0a183056a8b5@joelhalpern.com> In-Reply-To: <03769b15-8375-a23a-a882-0a183056a8b5@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.102.3) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.70.231.8] Content-Type: multipart/alternative; boundary="_000_7CA6EE6E3D6C4ACFB9B4540C57A658E8ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.158, xch-rtp-018.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [mpls] Opsdir last call review of draft-ietf-mpls-sfc-encapsulation-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: Mon, 25 Feb 2019 04:54:21 -0000 --_000_7CA6EE6E3D6C4ACFB9B4540C57A658E8ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEpvZWwsDQoNCk1heWJlIEkgYW0gbWlzdW5kZXJzdGFuZGluZyBzb21ldGhpbmcuIElzIHRo ZSBTRkYgTGFiZWwsIGluIHRoZSBjb250ZXh0IG9mIE1QTFMgdHJhbnNwb3J0IGVuY2Fwc3VsYXRp b24gZm9yIHRoZSBTRkMgTlNILCBldmVyIGV4cGVjdGVkIHRvIGJlIHVzZWQgZm9yIEZvcndhcmRp bmc/IElzIGl0cyBUVEwgZXZlciBleHBlY3RlZCB0byBiZSBkZWNyZW1lbnRlZCBhbmQgdGhlIHBh Y2tldCBzZW50PyBJZiBzbywgSSBkaWQgbm90IHVuZGVyc3RhbmQgdGhhdCBmcm9tIHRoZSBleGlz dGluZyB0ZXh0LCBzaW5jZSBpdCBpcyBlcXVpdmFsZW50IHRvIGEgUFcgTGFiZWwuIElmIG5vdCwg d2UgY2FuIHRha2UgYWR2YW50YWdlIG9mIFRUTC4NCg0KRWl0aGVyIHdheSBpcyBnb29kLCBJ4oCZ bSBqdXN0IGFza2luZyB0byBtYWtlIHRoaXMgZXhwbGljaXQuDQoNClRoYW5rcywNCg0K4oCUIENh cmxvcyBQaWduYXRhcm8NCg0KT24gRmViIDIzLCAyMDE5LCBhdCAxOjQzIEFNLCBKb2VsIE0uIEhh bHBlcm4gPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PiB3 cm90ZToNCg0KTXkgY29tbWVudCBvbiB0aGlzIG1heSBub3QgaGF2ZSBtYWRlIGl0IHRvIGV2ZXJ5 b25lLiAgSWYgeW91IHJlY2VpdmUgYSBkdXBsaWNhdGUsIEkgYXBvbG9naXplICAoSSByZWNlaXZl ZCBETUFSQyBlcnJvcnMgZnJvbSBzb21ldGhpbmcgYWJvdXQgdHJhbnNsYXRpb25zIGZyb20gdGhl IGRyYWZ0LmFsbCBhZGRyZXNzIHRvIGdtYWlsIGFkZHJlc3Nlcy4pDQoNClNwZWFraW5nIGFzIGEg Y28tYXV0aG9yLi4uDQoNCkl0IGlzIG5vdCBhdCBhbGwgY2xlYXIgdG8gbWUgdGhhdCBHVFNNIGFw cGxpZXMgb3IgaG93IGl0IHdvdWxkIGFwcGx5LiBUaGVyZSBpcyBubyByZXF1aXJlbWVudCB0aGF0 IHN1Y2Nlc3NpdmUgU0ZGIGJlIG9uZSBNUExTIGhvcCBhcGFydC4NCg0KWW91cnMsDQpKb2VsDQoN Ck9uIDIvMjIvMTkgOToyNyBBTSwgQW5kcmV3IEcuIE1hbGlzIHdyb3RlOg0KQ2FybG9zLA0KTG9v a3MgZ29vZCBvbiBhbGwgYnV0IG9uZSBwb2ludCAtIEkgdGhpbmsgSSBzZWUgd2h5IHlvdSdyZSBy ZWZlcmVuY2luZyBHVFNNLCBzaW5jZSBwYWNrZXRzIGF0IHRoZSBTRkMgbGF5ZXIgd291bGQgZ2Vu ZXJhbGx5IGJlIG9uZSBob3AgYXdheSBmcm9tIGVhY2ggb3RoZXIgYXQgdGhhdCBsYXllci4gSXMg dGhhdCBjb3JyZWN0PyBIb3dldmVyLCBJIHJlYWxseSBkb24ndCBoYXZlIHN1ZmZpY2llbnQgZXhw ZXJpZW5jZSB3aXRoIEdUU00gdG8gY3JhZnQgc3BlY2lmaWMgdGV4dC4gSWYgeW91IHRoaW5rIGl0 J3MgaW1wb3J0YW50IGVub3VnaCB0byBpbmNsdWRlLCBjb3VsZCB5b3UgcHJvcG9zZSBzb21lIHRl eHQgZm9yIG1lIHRvIGluY2x1ZGU/DQpUaGFua3MgYWdhaW4sDQpBbmR5DQpPbiBUaHUsIEZlYiAy MSwgMjAxOSBhdCA4OjQxIFBNIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSA8Y3BpZ25hdGFA Y2lzY28uY29tPG1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20+IDxtYWlsdG86Y3BpZ25hdGFAY2lz Y28uY29tPj4gd3JvdGU6DQogICBIaSwgQW5keSwNCiAgIE9uIEZlYiAyMSwgMjAxOSwgYXQgMTow NiBQTSwgQW5kcmV3IEcuIE1hbGlzIDxhZ21hbGlzQGdtYWlsLmNvbTxtYWlsdG86YWdtYWxpc0Bn bWFpbC5jb20+DQogICA8bWFpbHRvOmFnbWFsaXNAZ21haWwuY29tPj4gd3JvdGU6DQoNCiAgIENh cmxvcywNCg0KICAgTWFueSB0aGFua3MgZm9yIHlvdXIgcmV2aWV3ISBJJ20gYWxzbyBpbmNsdWRp bmcgdGhlIFNGQyBXRyBvbiBteQ0KICAgcmVwbHkuDQogICBUaGFua3MgZm9yIHRoZSBxdWljayBy ZXNwb25zZSwgYW5kIGZvciBjb25zaWRlcmluZyB0aGUgY29tbWVudHMhDQogICBJIGVuam95ZWQg cmVhZGluZyB0aGlzIGRvY3VtZW50IOKAlCBwbGVhc2Ugc2VlIGJlbG93Lg0KDQogICBDb21tZW50 cyBpbmxpbmUuDQoNCiAgIE9uIFdlZCwgRmViIDIwLCAyMDE5IGF0IDEwOjU4IFBNIENhcmxvcyBQ aWduYXRhcm8NCiAgIDxjcGlnbmF0YUBjaXNjby5jb208bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNv bT4gPG1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20+PiB3cm90ZToNCg0KICAgICAgIFJldmlld2Vy OiBDYXJsb3MgUGlnbmF0YXJvDQogICAgICAgUmV2aWV3IHJlc3VsdDogSGFzIElzc3Vlcw0KDQog ICAgICAgUmV2aWV3ZXI6IENhcmxvcyBQaWduYXRhcm8NCiAgICAgICBSZXZpZXcgUmVzdWx0OiBI YXMgSXNzdWVzDQoNCiAgICAgICBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0 IG9mIHRoZSBPcGVyYXRpb25hbA0KICAgICAgIGRpcmVjdG9yYXRlJ3MNCiAgICAgICBvbmdvaW5n IGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieQ0K ICAgICAgIHRoZSBJRVNHLiAgVGhlc2UNCiAgICAgICBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gd2l0 aCB0aGUgaW50ZW50IG9mIGltcHJvdmluZyB0aGUNCiAgICAgICBvcGVyYXRpb25hbCBhc3BlY3Rz IG9mDQogICAgICAgdGhlIElFVEYgZHJhZnRzLiBDb21tZW50cyB0aGF0IGFyZSBub3QgYWRkcmVz c2VkIGluIGxhc3QgY2FsbA0KICAgICAgIG1heSBiZSBpbmNsdWRlZA0KICAgICAgIGluIEFEIHJl dmlld3MgZHVyaW5nIHRoZSBJRVNHIHJldmlldy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHDQog ICAgICAgY2hhaXJzIHNob3VsZA0KICAgICAgIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlr ZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQogICAgICAgVGhpcyBkb2N1bWVudCBp cyBoaWdobHkgcmVhZGFibGUsIGluY2x1ZGVzIHZlcnkgY2xlYXIgdGV4dHVhbA0KICAgICAgIGRl c2NyaXB0aW9ucywgYW5kDQogICAgICAgaXMgdmVyeSB3ZWxsIG9yZ2FuaXplZC4gRWFzeSB0byBy ZWFkIGluIGl0cyBzaW1wbGljaXR5Lg0KICAgICAgIEhvd2V2ZXIsIGl0IHdvdWxkDQogICAgICAg YmVuZWZpdCBmcm9tIGEgbW9yZSBleHBsaWNpdCBjb25uZWN0aW9uIHRvIHRoZSB0cmFuc3BvcnQg ZW5jYXANCiAgICAgICBtZWNoYW5pY3MgZnJvbQ0KICAgICAgIFJGQyA4MzAwIChlLmcuLCBTNCwg UzYuMSkuIFNwZWNpZmljYWxseSwgSSdkIHJlY29tbWVuZCBhZGRpbmcNCiAgICAgICBhIEZpZ3Vy ZSBvciBhbg0KICAgICAgIFNGRiBOU0ggTWFwcGluZyBUYWJsZSBleGFtcGxlLCB0byBkZXBpY3Qg YW5kL29yIGV4ZW1wbGlmeSB0aGUNCiAgICAgICBTRkYgZnVuY3Rpb24uDQoNCg0KICAgSSdtIHRy eWluZyB0byBlbnZpc2lvbiB3aGF0IHdvdWxkIG1ha2UgYSBnb29kIGZpZ3VyZSBoZXJlLiBXZQ0K ICAgY291bGQgYWRkIGFuIGFkZGl0aW9uYWwgbGluZSB0byBUYWJsZSAxIG9mIFJGQyA4MzAwIGFu ZCByZWZlcmVuY2UNCiAgIHRoYXQgdGFibGU6DQoNCiAgICAgICAgICArLS0tLS0tKy0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAg ICB8IFNQSSAgfCBTSSAgIHwgTmV4dCBIb3AocykgICAgICAgICB8IFRyYW5zcG9ydCBFbmNhcHN1 bGF0aW9uIHwNCiAgICAgICAgICArLS0tLS0tKy0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICB8IDI1ICAgfCAyMjAgIHwgTGFi ZWwgNTQ2NyAgICAgICAgICB8IE1QTFMgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAr LS0tLS0tKy0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsNCg0KICAgSXMgdGhhdCB3aGF0IHlvdSBoYWQgaW4gbWluZD8gSWYgbm90LCBJJ20gb3Bl biB0byBvdGhlciBzdWdnZXN0aW9ucy4NCiAgIElmIHlvdSB0aGluayBpdCBoZWxwcywgdGhpcyB3 b3VsZCBiZSBhIGdvb2QgYWRkaXRpb24uDQoNCiAgICAgICA+RnJvbSBhbiBPcGVyYXRpb25hbCBz dGFuZHBvaW50LCB0aGUgZG9jdW1lbnQgc2VlbXMgbGFyZ2VseQ0KICAgICAgIGFwcHJvcHJpYXRl IGluIHRlcm1zDQogICAgICAgb2YgZGF0YXBsYW5lIGNvbnNpZGVyYXRpb25zLiBTb21lIGtleSBj b25zaWRlcmF0aW9ucyBhcmUNCiAgICAgICBleHBsaWNpdGx5IG91dCBvZg0KICAgICAgIHNjb3Bl Og0KICAgICAgICAgIFRoZSBtZXRob2QgdXNlZCBieSB0aGUgZG93bnN0cmVhbSByZWNlaXZpbmcg bm9kZSB0bw0KICAgICAgIGFkdmVydGlzZSBTRkYNCiAgICAgICAgICBMYWJlbHMgdG8gdGhlIHVw c3RyZWFtIHNlbmRpbmcgbm9kZSBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhpcw0KICAgICAgIGRvY3Vt ZW50Lg0KDQogICAgICAgVGhpcyByZWFsbHkgc2VlbXMgdG8gbWVhbiB0aGF0LCB3aXRoIHRoZSBz aW1wbGUgZGVmaW5pdGlvbiBpbiB0aGlzDQogICAgICAgSW5mb3JtYXRpb25hbCBkb2N1bWVudCwg aW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMgY2Fubm90DQogICAgICAgeWV0IGV4aXN0LiBJ Zg0KICAgICAgIHRoZXJlIGlzIG5vIG1lY2hhbmlzbSB0byBhZHZlcnRpc2UgdGhlIFNGRiBMYWJl bCBvciB0byBtYW5hZ2UNCiAgICAgICB0aGUgc2VtYW50aWNzIG9mDQogICAgICAgdGhpcyBwYXJ0 aWN1bGFyIGxhYmVsLCBob3cgd2lsbCBpdCBrbm93PyBTdGF0aWMgY29uZmlndXJhdGlvbiwNCiAg ICAgICB3aGljaCBpcyBub3QNCiAgICAgICBjb3ZlcmVkIGFueXdheSwgaXMgbm90IGluIG15IGh1 bWJsZSBvcGluaW9uIGEgbWFuYWdlYWJsZQ0KICAgICAgIHNjYWxhYmxlIGFwcHJvYWNoLg0KDQoN CiAgIEFjdHVhbGx5LCB3aGlsZSBpdCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3Vt ZW50LCBpdCBpcw0KICAgd2l0aGluIHRoZSBzY29wZSBvZiBkcmFmdC1pZXRmLWJlc3MtbnNoLWJn cC1jb250cm9sLXBsYW5lLCBhbmQNCiAgIHRleHQgaXMgYmVpbmcgYWRkZWQgdG8gdGhlIG5leHQg cmV2aXNpb24gb2YgdGhhdCBkcmFmdCB0byBzaG93IGhvdw0KICAgaXQgY2FuIGJlIHVzZWQgdG8g c2lnbmFsIHRoZSBlbmNhcHN1bGF0aW9uIGRlZmluZWQgaGVyZS4gVGhpcyB3YXMNCiAgIHdvcmtl ZCBvdXQgYWZ0ZXIgdGhpcyBkcmFmdCB3YXMgZm9yd2FyZGVkIHRvIHRoZSBJRVNHLCBidXQgd2Ug Y2FuDQogICBub3cgYWRkIGEgcmVmZXJlbmNlIHRvIHRoYXQgZHJhZnQgc2VlaW5nIGFzIHdlJ2xs IGJlIGRvaW5nIGENCiAgIHBvc3QtbGFzdC1jYWxsIHVwZGF0ZS4NCiAgIEkgdGhpbmsgdGhhdCB3 aWxsIGhlbHAsIGFzIGFuIEluZm9ybWF0aXZlIOKAnG9uZSBlbWJvZGltZW504oCdIHR5cGUgb2Yg bGluay4NCg0KICAgICAgIFRpdGxlOiBNUExTIEVuY2Fwc3VsYXRpb24gRm9yIFRoZSBTRkMgTlNI DQoNCiAgICAgICBSRkMgODMwMCBtYWtlcyBhbiBleHBsaWNpdCBkaXN0aW5jdGlvbiBiZXR3ZWVu IHRoZSB0ZXJtcw0KICAgICAgICdlbmNhcHN1bGF0aW9uJyBhbmQNCiAgICAgICAndHJhbnNwb3J0 IGVuY2Fwc3VsYXRpb24nIChzZWUgZS5nLiwgRmlndXJlIDEsIFNlY3Rpb24gMS41IDUuLA0KICAg ICAgIGFuZCBTZWN0aW9uIDQgb2YNCiAgICAgICBSRkMgODMwMCkuDQoNCiAgICAgICBJdCBzZWVt cyB0byBtZSB0aGF0IHRoaXMgaXMgdGhlICJNUExTIFRyYW5zcG9ydCBFbmNhcHN1bGF0aW9uDQog ICAgICAgZm9yIHRoZSBTRkMgTlNIIg0KDQoNCiAgIFRoYW5rcywgd2UnbGwgZml4IHRoYXQuDQoN Cg0KICAgICAgIDIuICBNUExTIEVuY2Fwc3VsYXRpb24gVXNpbmcgYW4gU0ZGIExhYmVsDQoNCiAg ICAgICBTaW1pbGFybHksICIyLiBNUExTIFRyYW5zcG9ydCBFbmNhcHN1bGF0aW9uIFVzaW5nIGFu IFNGRiBMYWJlbCINCg0KICAgICAgICAgIFRoZSBlbmNhcHN1bGF0aW9uIGlzIGEgc3RhbmRhcmQg TVBMUyBsYWJlbCBzdGFjayBbUkZDMzAzMl0NCiAgICAgICB3aXRoIGFuDQogICAgICAgICAgU0ZG IExhYmVsIGF0IHRoZSBib3R0b20gb2YgdGhlIHN0YWNrLCBmb2xsb3dlZCBieSBhIE5TSCBhcw0K ICAgICAgIGRlZmluZWQgYnkNCiAgICAgICAgICBbUkZDODMwMF0gYW5kIHRoZSBOU0ggcGF5bG9h ZC4NCg0KICAgICAgIEluc3RlYWRmIG9mICJOU0ggcGF5bG9hZCIgSSB0aGluayAib3JpZ25hbCBw YWNrZXQiIGlzIG1lYW50Lg0KDQoNCiAgIFJGQyA4MzAwIHVzZXMgYm90aCAicGF5bG9hZCIgYW5k ICJvcmlnaW5hbCBwYWNrZXQvZnJhbWUiLCBidXQgdGhlDQogICBsYXR0ZXIgbW9yZSB0aGFuIHRo ZSBmb3JtZXIuIFNvIHdlIGNhbiBjaGFuZ2UgInBheWxvYWQiIHRvDQogICAib3JpZ2luYWwgcGFj a2V0L2ZyYW1lIi4NCg0KDQogICAgICAgQWxzbywgdGhpcyBlbmNhcHN1bGF0aW9uIGlzIFVuZGVy ZGVmaW5lZDogV2hhdCBpcyB0aGUgdmFsdWUgb2YNCiAgICAgICBUVEw/IFRDPw0KDQoNCiAgIEkn dmUgYmVlbiBsb29raW5nIGJhY2sgYXQgb3RoZXIgcmVsYXRlZCBSRkNzIChzdWNoIGFzIFBXIGFu ZCBJUA0KICAgVlBOIGxhYmVsIGRlZmluaXRpb25zKSBhbmQgdGhleSdyZSBhbHNvIG1vc3RseSBz aWxlbnQgb24gdGhlc2UNCiAgIHZhbHVlcy4gSSBkaWQgZmluZCB0aGUgZm9sbG93aW5nIGluIFJG QyA2MDczOg0KDQogICAgICAgVGhlIHNldHRpbmcgb2YgdGhlIFRUTCBvZiB0aGUgUFcgTVBMUw0K ICAgICAgIGxhYmVsIGlzIGEgbWF0dGVyIG9mIGxvY2FsIHBvbGljeSBvbiB0aGUgb3JpZ2luYXRp bmcgUEUsIGJ1dCBTSE9VTEQNCiAgICAgICBiZSBzZXQgdG8gMjU1Lg0KDQogICBSZWdhcmRpbmcg dGhlIFRDLCB3ZSBjYW4gZm9sbG93IHRoZSBleGFtcGxlIG9mIFJGQyA2MzkxOg0KDQogICAgICAg VGhpcyBkb2N1bWVudCBkb2VzIG5vdCBkZWZpbmUgYSB1c2UgZm9yIHRoZSBUcmFmZmljIENsYXNz IChUQykgZmllbGQNCiAgICAgICBbUkZDNTQ2MiAgPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM1NDYyPl0gKGZvcm1lcmx5IGtub3duIGFzIHRoZSBFeHBlcmltZW50YWwgVXNlIChFWFAp IGJpdHMNCiAgICAgICBbUkZDMzAzMiAgPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMz MDMyPl0pIGluIHRoZSBmbG93IGxhYmVsLiAgRnV0dXJlIGRvY3VtZW50cyBtYXkgZGVmaW5lIGEg dXNlIGZvcg0KICAgICAgIHRoZXNlIGJpdHM7IHRoZXJlZm9yZSwgaW1wbGVtZW50YXRpb25zIGNv bmZvcm1pbmcgdG8gdGhpcw0KICAgICAgIHNwZWNpZmljYXRpb24gTVVTVCBzZXQgdGhlIFRDIGZp ZWxkIHRvIHplcm8gYXQgdGhlIGluZ3Jlc3MgYW5kIE1VU1QNCiAgICAgICBpZ25vcmUgdGhlbSBh dCB0aGUgZWdyZXNzLg0KDQogICBEbyB5b3UgaGF2ZSBhbnkgYWx0ZXJuYXRpdmUgc3VnZ2VzdGlv bnM/DQogICBUaGVzZSB0d28gYXBwcm9hY2hlcyBzb3VuZHMgZ29vZCB0byBtZS4gQW5kIEFjayB0 byB0aGUgb3RoZXINCiAgIHByZXZpb3VzIHJlc3BvbnNlcy4NCg0KICAgICAgICAgIE11Y2ggbGlr ZSBhIHBzZXVkb3dpcmUgbGFiZWwsIGFuIFNGRiBMYWJlbCBpcyBhbGxvY2F0ZWQgYnkgdGhlDQog ICAgICAgICAgZG93bnN0cmVhbSByZWNlaXZlciBvZiB0aGUgTlNIIGZyb20gaXRzIHBlci1wbGF0 Zm9ybSBsYWJlbA0KICAgICAgIHNwYWNlLg0KDQogICAgICAgQSBQVyBMYWJlbCBpcyBtb3JlIHJl c3RyaWN0aXZlLiBSRkMgODA3NyBzYXlzIGl0IE1VU1QgYmUNCiAgICAgICBhbGxvY2F0ZWQgYXMN CiAgICAgICBwZXItcGxhdGZvcm06DQoNCiAgICAgICAgICBlZ3Jlc3MgTFNSIG9ubHkuICBOb3Rl IHRoYXQgdGhlIFBXIGxhYmVsIG11c3QgYWx3YXlzIGJlIGF0DQogICAgICAgdGhlIGJvdHRvbQ0K ICAgICAgICAgIG9mIHRoZSBwYWNrZXQncyBsYWJlbCBzdGFjaywgYW5kIGxhYmVscyBNVVNUIGJl IGFsbG9jYXRlZA0KICAgICAgIGZyb20gdGhlDQogICAgICAgICAgcGVyLXBsYXRmb3JtIGxhYmVs IHNwYWNlLg0KDQogICAgICAgSXMgdGhpcyB0aGUgY2FzZSBmb3IgdGhlIFNGRiBMYWJlbCBhcyB3 ZWxsPyBJZiBzbywgd2hhdCBpcyB0aGUNCiAgICAgICBpbXBsaWNhdGlvbiBvZg0KICAgICAgIHRo ZSBNVVNUPyBJZiBub3QsIHdoeSBpcyBpdCBkaWZmZXJlbnQgdGhhbiBvdGhlciBlcXVpdmFsZW50 DQogICAgICAgc2ltaWxhciBsYWJlbHM/DQoNCg0KICAgV2UgY2FuIGNoYW5nZSB0aGUgdGV4dCB0 bzoNCg0KICAgIE11Y2ggbGlrZSBhIHBzZXVkb3dpcmUgbGFiZWwsIGFuIFNGRiBMYWJlbCBNVVNU IGJlIGFsbG9jYXRlZCBieQ0KICAgdGhlIGRvd25zdHJlYW0gcmVjZWl2ZXIgb2YgdGhlIE5TSCBm cm9tIGl0cyBwZXItcGxhdGZvcm0gbGFiZWwNCiAgIHNwYWNlLCBzaW5jZSB0aGUgbWVhbmluZyBv ZiB0aGUgbGFiZWwgaXMgaWRlbnRpY2FsIGluZGVwZW5kZW50IG9mDQogICB3aGljaCBpbmNvbWlu ZyBpbnRlcmZhY2UgaXQgaXMgcmVjZWl2ZWQgW1JGQzMwMzFdLg0KDQogICBUaGF04oCZcyBhIGdy ZWF0IGltcHJvdmVtZW50Lg0KDQogICAgICAgICAgMi4gIFB1c2ggdGhlIFNGRiBMYWJlbCB0byBp ZGVudGlmeSB0aGUgZGVzaXJlZCBTRkYgaW4gdGhlDQogICAgICAgcmVjZWl2aW5nDQogICAgICAg ICAgICAgIE1QTFMgbm9kZS4NCg0KICAgICAgIFRUTCB2YWx1ZT8gMT8gMj8gMjU1IGZvciBHVFNN PyBHVFNNIFJGQyA1MDgyIGNvdWxkIGJlIHVzZWQgaGVyZS4NCg0KDQogICBBcyBJIG5vdGVkIGFi b3ZlLCAyNTUsIGFsdGhvdWdoIEkgdXNlZCBSRkMgNjA3MyBhcyBteSBzb3VyY2UNCiAgIHJhdGhl ciB0aGFuIDUwODIuIFdlJ2xsIGFkZCB0aGF0IGhlcmUgYXMgd2VsbC4NCg0KICAgU291bmRzIGdv b2QuDQogICBUaGVzZSBwcm90b2NvbHMgdXNlIDUwODIgaW4gb25lIGZvcm0gb3IgYW5vdGhlcjoN CiAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzUwODIvcmVmZXJlbmNlZGJ5 Lw0KDQogICAgICAgNC4gIE9wZXJhdGlvbnMsIEFkbWluaXN0cmF0aW9uLCBhbmQgTWFpbnRlbmFu Y2UgKE9BTSkNCiAgICAgICBDb25zaWRlcmF0aW9ucw0KDQogICAgICAgICAgT0FNIGF0IHRoZSBT RkMgTGF5ZXIgaXMgaGFuZGxlZCBieSBTRkMtZGVmaW5lZCBtZWNoYW5pc21zDQogICAgICAgW1JG QzgzMDBdLg0KICAgICAgICAgIEhvd2V2ZXIsIE9BTSBtYXkgYmUgcmVxdWlyZWQgYXQgdGhlIE1Q TFMgdHJhbnNwb3J0IGxheWVyLiAgICAgICAgIElmIHNvLA0KICAgICAgICAgIHRoZW4gc3RhbmRh cmQgTVBMUy1sYXllciBPQU0gbWVjaGFuaXNtcyBzdWNoIGFzIHRoZSBHZW5lcmljDQogICAgICAg ICAgQXNzb2NpYXRlZCBDaGFubmVsIFtSRkM1NTg2XSBsYWJlbCBtYXkgYmUgdXNlZC4NCg0KICAg ICAgIFJGQyA1NTg2IGlzIF9ub3RfIGFuIE9BTSBtZWNoYW5pc20uIEl0IGlzIGFuIGFzc29jaWF0 ZWQNCiAgICAgICBjaGFubmVsIGNyZWF0aW9uDQogICAgICAgbWVjaGFuaXNtLCBvdmVyIHdoaWNo IE9BTSBjb3VsZCBiZSBjYXJyaWVkLg0KDQogICAgICAgVGh1cywgd2hhdCB0cmFkaXRpb25hbCBN UExTIE9BTSBjYW4gYmUgY2FycmllZCBoZXJlPyBUaGluZ3MNCiAgICAgICBsaWtlIFJGQyA0Mzc5 IC8gUkZDDQogICAgICAgODAyOSB3b3VsZCBuZWVkIHRoZSBkZWZpbml0aW9uIG9mIGFuIFNGRiBM YWJlbCBGRUMgKHdoaWNoIGRvZXMNCiAgICAgICBub3QgZXhpc3QpLg0KICAgICAgIFdoaWNoIG90 aGVyIG9uZT8gSVAvSUNNUCBzZWVtcyBvZiB2ZXJ5IGxpbWl0ZWQgdmFsdWUuDQoNCg0KICAgVGhh dCdzIGEgZ29vZCBwb2ludCBhYm91dCBSRkMgNTU4Ni4gVGhlIGludGVudGlvbiBpcyB0aGF0IHRo ZSBNUExTDQogICBPQU0gd291bGQgYmUgYXQgdGhlIHRyYW5zcG9ydCBsYWJlbCBsYXllciBhYm92 ZSB0aGUgU0ZGIGxhYmVsLCBzbw0KICAgbW9zdCBhbnkgTVBMUy1sYXllciBPQU0gd291bGQgYmUg YXBwbGljYWJsZS4gU28gaG93IGFib3V0DQogICByZXdvcmRpbmcgdG8gbWFrZSB0aGF0IG1vcmUg Y2xlYXI6DQoNCiAgIE9BTSBhdCB0aGUgU0ZDIExheWVyIGlzIGhhbmRsZWQgYnkgU0ZDLWRlZmlu ZWQgbWVjaGFuaXNtcw0KICAgW1JGQzgzMDBdLiBIb3dldmVyLCBPQU0gbWF5IGJlIHJlcXVpcmVk IGF0IHRoZSBNUExTIHRyYW5zcG9ydA0KICAgbGF5ZXIuICBJZiBzbywgdGhlbiBzdGFuZGFyZCBN UExTLWxheWVyIE9BTSBtZWNoYW5pc21zIG1heSBiZSB1c2VkDQogICBhdCB0aGUgdHJhbnNwb3J0 IGxhYmVsIGxheWVyICh0aGUgbGFiZWxzIGFib3ZlIHRoZSBTRkYgbGFiZWwpLg0KICAgTG9va3Mg Z29vZCB0byBtZSwgdGhhbmsgeW91Lg0KDQoNCiAgICAgICA2LiAgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMNCg0KICAgICAgIEhhdmUgeW91IGNvbnNpZGVyZWQgdGhlIHVzZSBvZiBHVFNNPw0KDQoN CiAgIE5vLCB3ZSBoYWRuJ3QuIENhbiB5b3UgcG9pbnQgbWUgdG8gYW55IGV4YW1wbGVzIG9mIEdU U00gYmVpbmcgdXNlZA0KICAgaW4gYW4gTVBMUyBvciBQVyBjb250ZXh0Pw0KICAgWWVzLCBzZWUg YWJvdmUuDQoNCiAgICAgICA4LiAgUmVmZXJlbmNlcw0KDQogICAgICAgICAgW1JGQzc2NjVdICBI YWxwZXJuLCBKLiwgRWQuIGFuZCBDLiBQaWduYXRhcm8sIEVkLiwgIlNlcnZpY2UNCiAgICAgICBG dW5jdGlvbg0KICAgICAgICAgICAgICAgICAgICAgQ2hhaW5pbmcgKFNGQykgQXJjaGl0ZWN0dXJl IiwgUkZDIDc2NjUsDQogICAgICAgICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDNzY2NSwg T2N0b2JlciAyMDE1LA0KICAgICAgICAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0 b3Iub3JnL2luZm8vcmZjNzY2NQ0KICAgICAgIDxodHRwczovL3d3dy4ucmZjLWVkaXRvci5vcmcv aW5mby9yZmM3NjY1Pj4uDQoNCiAgICAgICBTSG91bGQgUkZDIDc2NjUgYmUgTm9ybWF0aXZlPyBJ dCBkZWZpbmVzIHRoZSAiU0ZGIiB3aGljaCBpcw0KICAgICAgIHF1aXRlIGNlbnRyYWwgdG8NCiAg ICAgICB1bmRlcnN0YW5kaW5nIHRoaXMgZG9jdW1lbnQuDQoNCg0KICAgR29vZCBwb2ludC4gSXQg d2FzIHRoZXJlIGJlY2F1c2UgNzY2NSBpcyBhbiBJbmZvcm1hdGlvbmFsIFJGQywgYnV0DQogICBS RkMgODA2NyBkb2VzIGFsbG93IG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIGluZm9ybWF0aW9uYWwg UkZDcywgc28NCiAgIEknbGwgbW92ZSBpdC4NCiAgIFRoYW5rIHlvdS4NCg0KICAgICAgIE90aGVy IE5pdHMgYW5kIEVkaXRvcmlhbHM6DQoNCiAgICAgICAgICBTRkYgTGFiZWxzIGFyZSBzaW1pbGFy IHRvIG90aGVyIHNlcnZpY2UgbGFiZWxzIGF0IHRoZQ0KICAgICAgIGJvdHRvbSBvZiBhbg0KICAg ICAgICAgIE1QTFMgbGFiZWwgc3RhY2sgdGhhdCBkZW5vdGUgdGhlIGNvbnRlbnRzIG9mIHRoZSBN UExTDQogICAgICAgcGF5bG9hZCBiZWluZw0KICAgICAgICAgIG90aGVyIHRoYW4gSVAsIHN1Y2gg YXMgYSBsYXllciAyIHBzZXVkb3dpcmUsIGFuIElQIHBhY2tldA0KICAgICAgIHRoYXQgaXMNCiAg ICAgICAgICByb3V0ZWQgaW4gYSBWUE4gY29udGV4dCB3aXRoIGEgcHJpdmF0ZSBhZGRyZXNzLCBv ciBhbiBFdGhlcm5ldA0KICAgICAgICAgIHZpcnR1YWwgcHJpdmF0ZSB3aXJlIHNlcnZpY2UuDQoN CiAgICAgICBUaGlzIHNheXMgImJlaW5nIG90aGVyIHRoYW4gSVAsIHN1Y2ggYXMgSVAiLCB3aGlj aCBzZWVtcyB0byBiZQ0KICAgICAgIHNlbGYtY29udHJhZGljdG9yeSA6LSkNCg0KICAgOi0pDQoN CiAgIEhvdyBhYm91dCB3ZSBjaGFuZ2UgIm90aGVyIHRoYW4gSVAsIiB0byAib3RoZXIgdGhhbiBh IG5vcm1hbGx5DQogICByb3V0ZWQgSVAgcGFja2V04oCdLA0KICAgVGhhdCB3b3VsZCBkaXNhbWJp Z3VhdGUgaXQuDQogICBUaGFua3MgYWdhaW4uDQogICBUbyBtZSwgdGhlIGNvbnRyb2wgcGxhbmUg LyBhZHZlcnRpc2VtZW50IHdhcyB0aGUgbW9zdCBpbXBvcnRhbnQNCiAgIG9wZXJhdGlvbmFsbHkt cmVsZXZhbnQgY29tbWVudC4NCiAgIFRoYW5rcywNCiAgIENhcmxvcy4NCg0KICAgVGhhbmtzIGFn YWluLA0KICAgQW5keQ0KDQo= --_000_7CA6EE6E3D6C4ACFB9B4540C57A658E8ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpLCBKb2VsLA0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+TWF5YmUgSSBhbSBtaXN1bmRlcnN0YW5k aW5nIHNvbWV0aGluZy4gSXMgdGhlIFNGRiBMYWJlbCwgaW4gdGhlIGNvbnRleHQgb2YmbmJzcDtN UExTIHRyYW5zcG9ydCBlbmNhcHN1bGF0aW9uIGZvciB0aGUgU0ZDIE5TSCwgZXZlciBleHBlY3Rl ZCB0byBiZSB1c2VkIGZvciBGb3J3YXJkaW5nPyBJcyBpdHMgVFRMIGV2ZXIgZXhwZWN0ZWQgdG8g YmUgZGVjcmVtZW50ZWQgYW5kIHRoZSBwYWNrZXQgc2VudD8gSWYgc28sIEkgZGlkIG5vdA0KIHVu ZGVyc3RhbmQgdGhhdCBmcm9tIHRoZSBleGlzdGluZyB0ZXh0LCBzaW5jZSBpdCBpcyBlcXVpdmFs ZW50IHRvIGEgUFcgTGFiZWwuIElmIG5vdCwgd2UgY2FuIHRha2UgYWR2YW50YWdlIG9mIFRUTC48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PkVpdGhlciB3YXkgaXMgZ29vZCwgSeKAmW0ganVzdCBhc2tpbmcgdG8gbWFrZSB0aGlzIGV4cGxp Y2l0LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBkaXI9ImF1dG8iIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjog cmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1u YnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIi Pg0KPGRpdiBkaXI9ImF1dG8iIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQt bmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlv bjogbm9uZTsiPg0KVGhhbmtzLDwvZGl2Pg0KPGRpdiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigw LCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjog bm9uZTsiPg0K4oCUIENhcmxvcyBQaWduYXRhcm88L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPk9uIEZlYiAyMywgMjAxOSwgYXQgMTo0MyBBTSwgSm9lbCBNLiBIYWxw ZXJuICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgY2xhc3M9IiI+am1o QGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1p bnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk15IGNv bW1lbnQgb24gdGhpcyBtYXkgbm90IGhhdmUgbWFkZSBpdCB0byBldmVyeW9uZS4gJm5ic3A7SWYg eW91IHJlY2VpdmUgYSBkdXBsaWNhdGUsIEkgYXBvbG9naXplICZuYnNwOyhJIHJlY2VpdmVkIERN QVJDIGVycm9ycyBmcm9tIHNvbWV0aGluZyBhYm91dCB0cmFuc2xhdGlvbnMgZnJvbSB0aGUgZHJh ZnQuYWxsIGFkZHJlc3MgdG8gZ21haWwgYWRkcmVzc2VzLik8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpTcGVha2luZyBhcyBhIGNvLWF1dGhvci4uLjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCkl0IGlzIG5vdCBhdCBhbGwgY2xlYXIgdG8gbWUgdGhhdCBHVFNNIGFwcGxpZXMgb3Ig aG93IGl0IHdvdWxkIGFwcGx5LiBUaGVyZSBpcyBubyByZXF1aXJlbWVudCB0aGF0IHN1Y2Nlc3Np dmUgU0ZGIGJlIG9uZSBNUExTIGhvcCBhcGFydC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpZb3Vycyw8YnIgY2xhc3M9IiI+DQpKb2VsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K T24gMi8yMi8xOSA5OjI3IEFNLCBBbmRyZXcgRy4gTWFsaXMgd3JvdGU6PGJyIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+Q2FybG9zLDxiciBjbGFzcz0iIj4NCkxv b2tzIGdvb2Qgb24gYWxsIGJ1dCBvbmUgcG9pbnQgLSBJIHRoaW5rIEkgc2VlIHdoeSB5b3UncmUg cmVmZXJlbmNpbmcgR1RTTSwmbmJzcDtzaW5jZSBwYWNrZXRzIGF0IHRoZSBTRkMgbGF5ZXIgd291 bGQgZ2VuZXJhbGx5IGJlIG9uZSBob3AgYXdheSBmcm9tIGVhY2ggb3RoZXIgYXQgdGhhdCBsYXll ci4gSXMgdGhhdCBjb3JyZWN0PyBIb3dldmVyLCBJIHJlYWxseSBkb24ndCBoYXZlIHN1ZmZpY2ll bnQgZXhwZXJpZW5jZSB3aXRoIEdUU00gdG8gY3JhZnQNCiBzcGVjaWZpYyZuYnNwO3RleHQuIElm IHlvdSB0aGluayBpdCdzIGltcG9ydGFudCBlbm91Z2ggdG8gaW5jbHVkZSwgY291bGQgeW91IHBy b3Bvc2Ugc29tZSB0ZXh0IGZvciBtZSB0byBpbmNsdWRlPzxiciBjbGFzcz0iIj4NClRoYW5rcyBh Z2Fpbiw8YnIgY2xhc3M9IiI+DQpBbmR5PGJyIGNsYXNzPSIiPg0KT24gVGh1LCBGZWIgMjEsIDIw MTkgYXQgODo0MSBQTSBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgJmx0OzxhIGhyZWY9Im1h aWx0bzpjcGlnbmF0YUBjaXNjby5jb20iIGNsYXNzPSIiPmNwaWduYXRhQGNpc2NvLmNvbTwvYT4g Jmx0OzxhIGhyZWY9Im1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20iIGNsYXNzPSIiPm1haWx0bzpj cGlnbmF0YUBjaXNjby5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7SGksIEFuZHksPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7T24gRmViIDIxLCAyMDE5LCBhdCAxOjA2IFBN LCBBbmRyZXcgRy4gTWFsaXMgJmx0OzxhIGhyZWY9Im1haWx0bzphZ21hbGlzQGdtYWlsLmNvbSIg Y2xhc3M9IiI+YWdtYWxpc0BnbWFpbC5jb208L2E+PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jmx0OzxhIGhyZWY9Im1haWx0bzphZ21hbGlzQGdtYWlsLmNvbSIgY2xhc3M9IiI+bWFp bHRvOmFnbWFsaXNAZ21haWwuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO0Nhcmxvcyw8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtNYW55IHRoYW5rcyBmb3IgeW91ciByZXZpZXch IEknbSBhbHNvIGluY2x1ZGluZyB0aGUgU0ZDIFdHIG9uIG15PGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7cmVwbHkuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7VGhhbmtzIGZvciB0aGUgcXVpY2sgcmVzcG9uc2UsIGFuZCBmb3IgY29uc2lkZXJp bmcgdGhlIGNvbW1lbnRzITxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO0kgZW5qb3ll ZCByZWFkaW5nIHRoaXMgZG9jdW1lbnQg4oCUIHBsZWFzZSBzZWUgYmVsb3cuPGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Q29tbWVudHMgaW5saW5lLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CiZuYnNwOyZuYnNwOyZuYnNwO09uIFdlZCwgRmViIDIwLCAyMDE5IGF0IDEwOjU4IFBNIENhcmxv cyBQaWduYXRhcm88YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbHQ7PGEgaHJlZj0i bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbSIgY2xhc3M9IiI+Y3BpZ25hdGFAY2lzY28uY29tPC9h PiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbSIgY2xhc3M9IiI+bWFpbHRv OmNwaWduYXRhQGNpc2NvLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtSZXZp ZXdlcjogQ2FybG9zIFBpZ25hdGFybzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO1JldmlldyByZXN1bHQ6IEhhcyBJc3N1ZXM8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtSZXZpZXdlcjogQ2FybG9zIFBpZ25hdGFybzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1JldmlldyBSZXN1bHQ6IEhhcyBJc3N1ZXM8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRo ZSBPcGVyYXRpb25hbDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO2RpcmVjdG9yYXRlJ3M8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElF VEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RoZSBJRVNHLiZuYnNwOyBUaGVzZTxiciBj bGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NvbW1l bnRzIHdlcmUgd3JpdHRlbiB3aXRoIHRoZSBpbnRlbnQgb2YgaW1wcm92aW5nIHRoZTxiciBjbGFz cz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO29wZXJhdGlv bmFsIGFzcGVjdHMgb2Y8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDt0aGUgSUVURiBkcmFmdHMuIENvbW1lbnRzIHRoYXQgYXJlIG5vdCBhZGRy ZXNzZWQgaW4gbGFzdCBjYWxsPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7bWF5IGJlIGluY2x1ZGVkPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aW4gQUQgcmV2aWV3cyBkdXJpbmcgdGhl IElFU0cgcmV2aWV3LiZuYnNwOyBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRzxiciBjbGFzcz0iIj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NoYWlycyBzaG91bGQ8 YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0 cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50 cy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtUaGlzIGRvY3VtZW50IGlzIGhpZ2hseSByZWFkYWJsZSwgaW5jbHVk ZXMgdmVyeSBjbGVhciB0ZXh0dWFsPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZGVzY3JpcHRpb25zLCBhbmQ8YnIgY2xhc3M9IiI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtpcyB2ZXJ5IHdlbGwgb3JnYW5p emVkLiBFYXN5IHRvIHJlYWQgaW4gaXRzIHNpbXBsaWNpdHkuPGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SG93ZXZlciwgaXQgd291bGQ8YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtiZW5l Zml0IGZyb20gYSBtb3JlIGV4cGxpY2l0IGNvbm5lY3Rpb24gdG8gdGhlIHRyYW5zcG9ydCBlbmNh cDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O21lY2hhbmljcyBmcm9tPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7UkZDIDgzMDAgKGUuZy4sIFM0LCBTNi4xKS4gU3BlY2lmaWNhbGx5LCBJ J2QgcmVjb21tZW5kIGFkZGluZzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO2EgRmlndXJlIG9yIGFuPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7U0ZGIE5TSCBNYXBwaW5nIFRhYmxlIGV4 YW1wbGUsIHRvIGRlcGljdCBhbmQvb3IgZXhlbXBsaWZ5IHRoZTxiciBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1NGRiBmdW5jdGlvbi48YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtJ J20gdHJ5aW5nIHRvIGVudmlzaW9uIHdoYXQgd291bGQgbWFrZSBhIGdvb2QgZmlndXJlIGhlcmUu IFdlPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Y291bGQgYWRkIGFuIGFkZGl0aW9u YWwgbGluZSB0byBUYWJsZSAxIG9mIFJGQyA4MzAwIGFuZCByZWZlcmVuY2U8YnIgY2xhc3M9IiI+ DQombmJzcDsmbmJzcDsmbmJzcDt0aGF0IHRhYmxlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLSYj NDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCBTUEkg Jm5ic3A7fCBTSSAmbmJzcDsmbmJzcDt8IE5leHQgSG9wKHMpICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgVHJhbnNwb3J0IEVuY2Fwc3VsYXRpb24gfDxi ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyYjNDM7LS0tLS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0t LS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PGJyIGNsYXNzPSIiPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7fCAyNSAmbmJzcDsmbmJzcDt8IDIyMCAmbmJzcDt8IExhYmVsIDU0NjcgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCBNUExTICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3w8YnIgY2xh c3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmIzQzOy0tLS0tLSYjNDM7LS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0t LS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOzxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO0lzIHRoYXQgd2hhdCB5b3UgaGFkIGluIG1pbmQ/ IElmIG5vdCwgSSdtIG9wZW4gdG8gb3RoZXIgc3VnZ2VzdGlvbnMuPGJyIGNsYXNzPSIiPg0KPC9i bG9ja3F1b3RlPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7SWYgeW91IHRoaW5rIGl0IGhlbHBzLCB0aGlz IHdvdWxkIGJlIGEgZ29vZCBhZGRpdGlvbi48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmZ3Q7RnJvbSBhbiBPcGVyYXRpb25hbCBzdGFuZHBvaW50LCB0aGUg ZG9jdW1lbnQgc2VlbXMgbGFyZ2VseTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO2FwcHJvcHJpYXRlIGluIHRlcm1zPGJyIGNsYXNzPSIiPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7b2YgZGF0YXBsYW5lIGNv bnNpZGVyYXRpb25zLiBTb21lIGtleSBjb25zaWRlcmF0aW9ucyBhcmU8YnIgY2xhc3M9IiI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtleHBsaWNpdGx5IG91dCBv ZjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O3Njb3BlOjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDtUaGUgbWV0aG9kIHVzZWQgYnkgdGhlIGRvd25zdHJlYW0gcmVj ZWl2aW5nIG5vZGUgdG88YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDthZHZlcnRpc2UgU0ZGPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO0xhYmVscyB0byB0aGUgdXBz dHJlYW0gc2VuZGluZyBub2RlIGlzIG91dCBvZiBzY29wZSBvZiB0aGlzPGJyIGNsYXNzPSIiPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZG9jdW1lbnQuPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7VGhpcyByZWFsbHkgc2VlbXMgdG8gbWVhbiB0aGF0LCB3aXRoIHRoZSBzaW1wbGUg ZGVmaW5pdGlvbiBpbiB0aGlzPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7SW5mb3JtYXRpb25hbCBkb2N1bWVudCwgaW50ZXJvcGVyYWJsZSBp bXBsZW1lbnRhdGlvbnMgY2Fubm90PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7eWV0IGV4aXN0LiBJZjxiciBjbGFzcz0iIj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RoZXJlIGlzIG5vIG1lY2hhbmlzbSB0 byBhZHZlcnRpc2UgdGhlIFNGRiBMYWJlbCBvciB0byBtYW5hZ2U8YnIgY2xhc3M9IiI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0aGUgc2VtYW50aWNzIG9mPGJy IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhp cyBwYXJ0aWN1bGFyIGxhYmVsLCBob3cgd2lsbCBpdCBrbm93PyBTdGF0aWMgY29uZmlndXJhdGlv biw8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDt3aGljaCBpcyBub3Q8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtjb3ZlcmVkIGFueXdheSwgaXMgbm90IGluIG15IGh1bWJsZSBvcGluaW9u IGEgbWFuYWdlYWJsZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO3NjYWxhYmxlIGFwcHJvYWNoLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO0FjdHVhbGx5LCB3aGlsZSBpdCBp cyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LCBpdCBpczxiciBjbGFzcz0iIj4N CiZuYnNwOyZuYnNwOyZuYnNwO3dpdGhpbiB0aGUgc2NvcGUgb2YmbmJzcDtkcmFmdC1pZXRmLWJl c3MtbnNoLWJncC1jb250cm9sLXBsYW5lLCBhbmQ8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsm bmJzcDt0ZXh0IGlzIGJlaW5nIGFkZGVkIHRvIHRoZSBuZXh0IHJldmlzaW9uIG9mIHRoYXQgZHJh ZnQgdG8gc2hvdyBob3c8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtpdCBjYW4gYmUg dXNlZCB0byBzaWduYWwgdGhlIGVuY2Fwc3VsYXRpb24gZGVmaW5lZCBoZXJlLiBUaGlzIHdhczxi ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO3dvcmtlZCBvdXQgYWZ0ZXIgdGhpcyBkcmFm dCB3YXMgZm9yd2FyZGVkIHRvIHRoZSBJRVNHLCBidXQgd2UgY2FuPGJyIGNsYXNzPSIiPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7bm93IGFkZCBhIHJlZmVyZW5jZSB0byB0aGF0IGRyYWZ0IHNlZWluZyBh cyB3ZSdsbCBiZSBkb2luZyBhPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7cG9zdC1s YXN0LWNhbGwgdXBkYXRlLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCiZuYnNwOyZuYnNw OyZuYnNwO0kgdGhpbmsgdGhhdCB3aWxsIGhlbHAsIGFzIGFuIEluZm9ybWF0aXZlIOKAnG9uZSBl bWJvZGltZW504oCdIHR5cGUgb2YgbGluay48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtUaXRsZTogTVBMUyBFbmNhcHN1bGF0aW9uIEZvciBUaGUgU0ZDIE5T SDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO1JGQyA4MzAwIG1ha2VzIGFuIGV4cGxpY2l0IGRpc3RpbmN0aW9uIGJl dHdlZW4gdGhlIHRlcm1zPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7J2VuY2Fwc3VsYXRpb24nIGFuZDxiciBjbGFzcz0iIj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyd0cmFuc3BvcnQgZW5jYXBzdWxhdGlv bicgKHNlZSBlLmcuLCBGaWd1cmUgMSwgU2VjdGlvbiAxLjUgNS4sPGJyIGNsYXNzPSIiPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YW5kIFNlY3Rpb24gNCBvZjxi ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1JG QyA4MzAwKS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJdCBzZWVtcyB0byBtZSB0aGF0IHRoaXMgaXMgdGhlICZx dW90O01QTFMgVHJhbnNwb3J0IEVuY2Fwc3VsYXRpb248YnIgY2xhc3M9IiI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtmb3IgdGhlIFNGQyBOU0gmcXVvdDs8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJz cDtUaGFua3MsIHdlJ2xsIGZpeCB0aGF0LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzIu Jm5ic3A7IE1QTFMgRW5jYXBzdWxhdGlvbiBVc2luZyBhbiBTRkYgTGFiZWw8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtTaW1pbGFybHksICZxdW90OzIuIE1QTFMgVHJhbnNwb3J0IEVuY2Fwc3VsYXRpb24gVXNpbmcg YW4gU0ZGIExhYmVsJnF1b3Q7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO1RoZSBlbmNhcHN1 bGF0aW9uIGlzIGEgc3RhbmRhcmQgTVBMUyBsYWJlbCBzdGFjayBbUkZDMzAzMl08YnIgY2xhc3M9 IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt3aXRoIGFuPGJy IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZuYnNwO1NGRiBMYWJlbCBhdCB0aGUgYm90dG9tIG9mIHRoZSBzdGFjaywgZm9sbG93ZWQg YnkgYSBOU0ggYXM8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtkZWZpbmVkIGJ5PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO1tSRkM4MzAwXSBhbmQgdGhlIE5TSCBw YXlsb2FkLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO0luc3RlYWRmIG9mICZxdW90O05TSCBwYXlsb2FkJnF1b3Q7 IEkgdGhpbmsgJnF1b3Q7b3JpZ25hbCBwYWNrZXQmcXVvdDsgaXMgbWVhbnQuPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7UkZDIDgz MDAgdXNlcyBib3RoICZxdW90O3BheWxvYWQmcXVvdDsgYW5kICZxdW90O29yaWdpbmFsIHBhY2tl dC9mcmFtZSZxdW90OywgYnV0IHRoZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO2xh dHRlciBtb3JlIHRoYW4gdGhlIGZvcm1lci4gU28gd2UgY2FuIGNoYW5nZSAmcXVvdDtwYXlsb2Fk JnF1b3Q7IHRvPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7b3JpZ2luYWwg cGFja2V0L2ZyYW1lJnF1b3Q7LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0Fsc28sIHRo aXMgZW5jYXBzdWxhdGlvbiBpcyBVbmRlcmRlZmluZWQ6IFdoYXQgaXMgdGhlIHZhbHVlIG9mPGJy IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VFRM PyBUQz88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsm bmJzcDsmbmJzcDtJJ3ZlIGJlZW4gbG9va2luZyBiYWNrIGF0IG90aGVyIHJlbGF0ZWQgUkZDcyAo c3VjaCBhcyBQVyBhbmQgSVA8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtWUE4gbGFi ZWwgZGVmaW5pdGlvbnMpIGFuZCB0aGV5J3JlIGFsc28gbW9zdGx5IHNpbGVudCBvbiB0aGVzZTxi ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO3ZhbHVlcy4gSSBkaWQgZmluZCB0aGUgZm9s bG93aW5nIGluIFJGQyA2MDczOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoZSBzZXR0aW5nIG9mIHRoZSBUVEwg b2YgdGhlIFBXIE1QTFM8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtsYWJlbCBpcyBhIG1hdHRlciBvZiBsb2NhbCBwb2xpY3kgb24gdGhlIG9y aWdpbmF0aW5nIFBFLCBidXQgU0hPVUxEPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YmUgc2V0IHRvIDI1NS48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtSZWdhcmRpbmcgdGhlIFRDLCB3ZSBjYW4gZm9s bG93IHRoZSBleGFtcGxlIG9mIFJGQyA2MzkxOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoaXMgZG9jdW1lbnQg ZG9lcyBub3QgZGVmaW5lIGEgdXNlIGZvciB0aGUgVHJhZmZpYyBDbGFzcyAoVEMpIGZpZWxkPGJy IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7W1JG QzU0NjIgJm5ic3A7Jmx0OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1 NDYyIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTQ2MjwvYT4mZ3Q7 XSAoZm9ybWVybHkga25vd24gYXMgdGhlIEV4cGVyaW1lbnRhbCBVc2UgKEVYUCkgYml0czxiciBj bGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1tSRkMz MDMyICZuYnNwOyZsdDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzAz MiIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMwMzI8L2E+Jmd0O10p IGluIHRoZSBmbG93IGxhYmVsLiAmbmJzcDtGdXR1cmUgZG9jdW1lbnRzIG1heSBkZWZpbmUgYSB1 c2UgZm9yPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7dGhlc2UgYml0czsgdGhlcmVmb3JlLCBpbXBsZW1lbnRhdGlvbnMgY29uZm9ybWluZyB0 byB0aGlzPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7c3BlY2lmaWNhdGlvbiBNVVNUIHNldCB0aGUgVEMgZmllbGQgdG8gemVybyBhdCB0aGUg aW5ncmVzcyBhbmQgTVVTVDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO2lnbm9yZSB0aGVtIGF0IHRoZSBlZ3Jlc3MuPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7RG8geW91IGhhdmUgYW55IGFsdGVybmF0 aXZlIHN1Z2dlc3Rpb25zPzxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCiZuYnNwOyZuYnNw OyZuYnNwO1RoZXNlIHR3byBhcHByb2FjaGVzIHNvdW5kcyBnb29kIHRvIG1lLiBBbmQgQWNrIHRv IHRoZSBvdGhlcjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO3ByZXZpb3VzIHJlc3Bv bnNlcy48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJm5ic3A7TXVjaCBsaWtlIGEgcHNldWRvd2lyZSBsYWJlbCwgYW4gU0ZGIExhYmVsIGlzIGFs bG9jYXRlZCBieSB0aGU8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7ZG93bnN0cmVhbSByZWNlaXZlciBvZiB0aGUgTlNI IGZyb20gaXRzIHBlci1wbGF0Zm9ybSBsYWJlbDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3NwYWNlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0EgUFcgTGFi ZWwgaXMgbW9yZSByZXN0cmljdGl2ZS4gUkZDIDgwNzcgc2F5cyBpdCBNVVNUIGJlPGJyIGNsYXNz PSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YWxsb2NhdGVk IGFzPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7cGVyLXBsYXRmb3JtOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDtlZ3Jlc3MgTFNSIG9u bHkuJm5ic3A7IE5vdGUgdGhhdCB0aGUgUFcgbGFiZWwgbXVzdCBhbHdheXMgYmUgYXQ8YnIgY2xh c3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0aGUgYm90 dG9tPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZuYnNwO29mIHRoZSBwYWNrZXQncyBsYWJlbCBzdGFjaywgYW5kIGxhYmVscyBN VVNUIGJlIGFsbG9jYXRlZDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO2Zyb20gdGhlPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO3Blci1wbGF0Zm9ybSBsYWJlbCBz cGFjZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtJcyB0aGlzIHRoZSBjYXNlIGZvciB0aGUgU0ZGIExhYmVsIGFz IHdlbGw/IElmIHNvLCB3aGF0IGlzIHRoZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2ltcGxpY2F0aW9uIG9mPGJyIGNsYXNzPSIiPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhlIE1VU1Q/IElmIG5vdCwg d2h5IGlzIGl0IGRpZmZlcmVudCB0aGFuIG90aGVyIGVxdWl2YWxlbnQ8YnIgY2xhc3M9IiI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzaW1pbGFyIGxhYmVscz88 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsm bmJzcDtXZSBjYW4gY2hhbmdlIHRoZSB0ZXh0IHRvOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO011Y2ggbGlrZSBhIHBzZXVkb3dpcmUgbGFiZWws IGFuIFNGRiBMYWJlbCBNVVNUIGJlIGFsbG9jYXRlZCBieTxiciBjbGFzcz0iIj4NCiZuYnNwOyZu YnNwOyZuYnNwO3RoZSBkb3duc3RyZWFtIHJlY2VpdmVyIG9mIHRoZSBOU0ggZnJvbSBpdHMgcGVy LXBsYXRmb3JtIGxhYmVsPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7c3BhY2UsIHNp bmNlIHRoZSBtZWFuaW5nIG9mIHRoZSBsYWJlbCBpcyBpZGVudGljYWwgaW5kZXBlbmRlbnQgb2Y8 YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDt3aGljaCBpbmNvbWluZyBpbnRlcmZhY2Ug aXQgaXMgcmVjZWl2ZWQgW1JGQzMwMzFdLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwv YmxvY2txdW90ZT4NCiZuYnNwOyZuYnNwOyZuYnNwO1RoYXTigJlzIGEgZ3JlYXQgaW1wcm92ZW1l bnQuPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZuYnNwOzIuJm5ic3A7IFB1c2ggdGhlIFNGRiBMYWJlbCB0byBpZGVudGlmeSB0aGUgZGVzaXJl ZCBTRkYgaW4gdGhlPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7cmVjZWl2aW5nPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TVBMUyBub2Rl LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO1RUTCB2YWx1ZT8gMT8gMj8gMjU1IGZvciBHVFNNPyBHVFNNIFJGQyA1 MDgyIGNvdWxkIGJlIHVzZWQgaGVyZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtBcyBJIG5vdGVkIGFib3ZlLCAyNTUsIGFsdGhv dWdoIEkgdXNlZCBSRkMgNjA3MyBhcyBteSBzb3VyY2U8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJz cDsmbmJzcDtyYXRoZXIgdGhhbiA1MDgyLiBXZSdsbCBhZGQgdGhhdCBoZXJlIGFzIHdlbGwuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7U291bmRzIGdvb2QuPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7VGhlc2UgcHJv dG9jb2xzIHVzZSA1MDgyIGluIG9uZSBmb3JtIG9yIGFub3RoZXI6PGJyIGNsYXNzPSIiPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv cmZjNTA4Mi9yZWZlcmVuY2VkYnkvIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9yZmM1MDgyL3JlZmVyZW5jZWRieS88L2E+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7NC4mbmJzcDsgT3BlcmF0aW9ucywgQWRtaW5pc3RyYXRp b24sIGFuZCBNYWludGVuYW5jZSAoT0FNKTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0NvbnNpZGVyYXRpb25zPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZuYnNwO09BTSBhdCB0aGUgU0ZDIExheWVyIGlzIGhhbmRsZWQgYnkgU0ZDLWRlZmluZWQg bWVjaGFuaXNtczxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO1tSRkM4MzAwXS48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7SG93ZXZlciwgT0FNIG1heSBiZSByZXF1 aXJlZCBhdCB0aGUgTVBMUyB0cmFuc3BvcnQgbGF5ZXIuICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0lmIHNvLDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDt0aGVuIHN0YW5kYXJk IE1QTFMtbGF5ZXIgT0FNIG1lY2hhbmlzbXMgc3VjaCBhcyB0aGUgR2VuZXJpYzxiciBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDtBc3NvY2lhdGVkIENoYW5uZWwgW1JGQzU1ODZdIGxhYmVsIG1heSBiZSB1c2VkLjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO1JGQyA1NTg2IGlzIF9ub3RfIGFuIE9BTSBtZWNoYW5pc20uIEl0IGlzIGFuIGFzc29j aWF0ZWQ8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtjaGFubmVsIGNyZWF0aW9uPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bWVjaGFuaXNtLCBvdmVyIHdoaWNoIE9BTSBjb3VsZCBiZSBj YXJyaWVkLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RodXMsIHdoYXQgdHJhZGl0aW9uYWwgTVBMUyBPQU0gY2Fu IGJlIGNhcnJpZWQgaGVyZT8gVGhpbmdzPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bGlrZSBSRkMgNDM3OSAvIFJGQzxiciBjbGFzcz0iIj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzgwMjkgd291bGQgbmVl ZCB0aGUgZGVmaW5pdGlvbiBvZiBhbiBTRkYgTGFiZWwgRkVDICh3aGljaCBkb2VzPGJyIGNsYXNz PSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bm90IGV4aXN0 KS48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtXaGljaCBvdGhlciBvbmU/IElQL0lDTVAgc2VlbXMgb2YgdmVyeSBsaW1pdGVkIHZhbHVlLjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZu YnNwO1RoYXQncyBhIGdvb2QgcG9pbnQgYWJvdXQgUkZDIDU1ODYuIFRoZSBpbnRlbnRpb24gaXMg dGhhdCB0aGUgTVBMUzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO09BTSB3b3VsZCBi ZSBhdCB0aGUgdHJhbnNwb3J0IGxhYmVsIGxheWVyIGFib3ZlIHRoZSBTRkYgbGFiZWwsIHNvPGJy IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7bW9zdCBhbnkgTVBMUy1sYXllciBPQU0gd291 bGQgYmUgYXBwbGljYWJsZS4gU28gaG93IGFib3V0PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7cmV3b3JkaW5nIHRvIG1ha2UgdGhhdCBtb3JlIGNsZWFyOjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO09BTSBhdCB0aGUgU0ZDIExheWVyIGlzIGhh bmRsZWQgYnkgU0ZDLWRlZmluZWQgbWVjaGFuaXNtczxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNw OyZuYnNwO1tSRkM4MzAwXS4gSG93ZXZlciwgT0FNIG1heSBiZSByZXF1aXJlZCBhdCB0aGUgTVBM UyB0cmFuc3BvcnQ8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtsYXllci4mbmJzcDsg SWYgc28sIHRoZW4gc3RhbmRhcmQgTVBMUy1sYXllciBPQU0gbWVjaGFuaXNtcyBtYXkgYmUgdXNl ZDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO2F0IHRoZSB0cmFuc3BvcnQgbGFiZWwg bGF5ZXIgKHRoZSBsYWJlbHMgYWJvdmUgdGhlIFNGRiBsYWJlbCkuPGJyIGNsYXNzPSIiPg0KPC9i bG9ja3F1b3RlPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7TG9va3MgZ29vZCB0byBtZSwgdGhhbmsgeW91 LjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzYuJm5ic3A7IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SGF2 ZSB5b3UgY29uc2lkZXJlZCB0aGUgdXNlIG9mIEdUU00/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Tm8sIHdlIGhhZG4ndC4gQ2Fu IHlvdSBwb2ludCBtZSB0byBhbnkgZXhhbXBsZXMgb2YgR1RTTSBiZWluZyB1c2VkPGJyIGNsYXNz PSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7aW4gYW4gTVBMUyBvciBQVyBjb250ZXh0PzxiciBjbGFz cz0iIj4NCjwvYmxvY2txdW90ZT4NCiZuYnNwOyZuYnNwOyZuYnNwO1llcywgc2VlIGFib3ZlLjxi ciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzguJm5ic3A7IFJl ZmVyZW5jZXM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7W1JGQzc2NjVdJm5ic3A7IEhhbHBl cm4sIEouLCBFZC4gYW5kIEMuIFBpZ25hdGFybywgRWQuLCAmcXVvdDtTZXJ2aWNlPGJyIGNsYXNz PSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7RnVuY3Rpb248 YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ2hhaW5pbmcg KFNGQykgQXJjaGl0ZWN0dXJlJnF1b3Q7LCBSRkMgNzY2NSw8YnIgY2xhc3M9IiI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRE9JIDEwLjE3NDg3L1JGQzc2NjUsIE9jdG9iZXIg MjAxNSw8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0 OzxhIGhyZWY9Imh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzY2NSIgY2xhc3M9 IiI+aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3NjY1PC9hPjxiciBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDs8YSBocmVm PSJodHRwczovL3d3dy4ucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3NjY1IiBjbGFzcz0iIj5odHRw czovL3d3dy4ucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3NjY1PC9hPiZndDsmZ3Q7LjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO1NIb3VsZCBSRkMgNzY2NSBiZSBOb3JtYXRpdmU/IEl0IGRlZmluZXMgdGhlICZxdW90 O1NGRiZxdW90OyB3aGljaCBpczxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO3F1aXRlIGNlbnRyYWwgdG88YnIgY2xhc3M9IiI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt1bmRlcnN0YW5kaW5nIHRoaXMgZG9j dW1lbnQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7R29vZCBwb2ludC4gSXQgd2FzIHRoZXJlIGJlY2F1c2UgNzY2NSBpcyBhbiBJ bmZvcm1hdGlvbmFsIFJGQywgYnV0PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7UkZD IDgwNjcgZG9lcyBhbGxvdyBub3JtYXRpdmUgcmVmZXJlbmNlcyB0byBpbmZvcm1hdGlvbmFsIFJG Q3MsIHNvPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7SSdsbCBtb3ZlIGl0LjxiciBj bGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCiZuYnNwOyZuYnNwOyZuYnNwO1RoYW5rIHlvdS48YnIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtPdGhlciBOaXRzIGFu ZCBFZGl0b3JpYWxzOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDtTRkYgTGFiZWxzIGFyZSBz aW1pbGFyIHRvIG90aGVyIHNlcnZpY2UgbGFiZWxzIGF0IHRoZTxiciBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2JvdHRvbSBvZiBhbjxiciBjbGFz cz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm bmJzcDtNUExTIGxhYmVsIHN0YWNrIHRoYXQgZGVub3RlIHRoZSBjb250ZW50cyBvZiB0aGUgTVBM UzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O3BheWxvYWQgYmVpbmc8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7b3RoZXIgdGhhbiBJUCwgc3VjaCBhcyBhIGxheWVy IDIgcHNldWRvd2lyZSwgYW4gSVAgcGFja2V0PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhhdCBpczxiciBjbGFzcz0iIj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDtyb3V0ZWQgaW4g YSBWUE4gY29udGV4dCB3aXRoIGEgcHJpdmF0ZSBhZGRyZXNzLCBvciBhbiBFdGhlcm5ldDxiciBj bGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDt2aXJ0dWFsIHByaXZhdGUgd2lyZSBzZXJ2aWNlLjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoaXMg c2F5cyAmcXVvdDtiZWluZyBvdGhlciB0aGFuIElQLCBzdWNoIGFzIElQJnF1b3Q7LCB3aGljaCBz ZWVtcyB0byBiZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO3NlbGYtY29udHJhZGljdG9yeSA6LSk8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQombmJzcDsmbmJzcDsmbmJzcDs6LSk8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQom bmJzcDsmbmJzcDsmbmJzcDtIb3cgYWJvdXQgd2UgY2hhbmdlICZxdW90O290aGVyIHRoYW4gSVAs JnF1b3Q7IHRvICZxdW90O290aGVyIHRoYW4gYSBub3JtYWxseTxiciBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwOyZuYnNwO3JvdXRlZCBJUCBwYWNrZXTigJ0sPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1 b3RlPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7VGhhdCB3b3VsZCBkaXNhbWJpZ3VhdGUgaXQuPGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7VGhhbmtzIGFnYWluLjxiciBjbGFzcz0iIj4NCiZu YnNwOyZuYnNwOyZuYnNwO1RvIG1lLCB0aGUgY29udHJvbCBwbGFuZSAvIGFkdmVydGlzZW1lbnQg d2FzIHRoZSBtb3N0IGltcG9ydGFudDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO29w ZXJhdGlvbmFsbHktcmVsZXZhbnQgY29tbWVudC48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsm bmJzcDtUaGFua3MsPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Q2FybG9zLjxiciBj bGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CiZuYnNwOyZuYnNwOyZuYnNwO1RoYW5rcyBhZ2Fpbiw8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJz cDsmbmJzcDtBbmR5PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7CA6EE6E3D6C4ACFB9B4540C57A658E8ciscocom_-- From nobody Mon Feb 25 04:15:07 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 7D742130EEC for ; Mon, 25 Feb 2019 04:15:05 -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, 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 NxccZzs1V9hO for ; Mon, 25 Feb 2019 04:15:01 -0800 (PST) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 801A412D4E6 for ; Mon, 25 Feb 2019 04:15:01 -0800 (PST) Received: by mail-wm1-x32e.google.com with SMTP id e74so7796729wmg.3 for ; Mon, 25 Feb 2019 04:15:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=6eOZbyftF8y7aaItIVwdKNrQTTXjr9dizcR1UccNIiQ=; b=siwGuJymBgzCdipC05VLfgAjXn8oZXBxcqNJO5ibRry4yki2LV2sXvVhi3WAZZoMV9 5tOGMMv/uEbrl5MHDKPeCjm5XjBYbzFUnATTO4e3hujxt7I1VKZxQHQ+awMDP5wJnX6x zzsEE/xhLmV1p3XD7x0CiiqDMW9KKNDpCxM4JqcwvFNvqphMO9fXNc6XpC53tlXF+4Sx CiupdNMVShWC29PMxlc6J3vnt3yvyi0yjRoVN7uzn5rdfw2DYhpdv/OEg3P+dD5Wax06 qmNyVyZZAJ53ACxHkBK0CzSTorPm9pkpk/cibXEpeXYtQdL184kAmr+NBGHCSNL87QNh lUPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=6eOZbyftF8y7aaItIVwdKNrQTTXjr9dizcR1UccNIiQ=; b=F+rejZXKyH0dPS0QNk+Wz6kgBLd/dBE0BKMq+K8S/UlI0ujOJKQqDMtfgrZyOJidjD YeZ27QIe690TyuT+MvwxQrV8FCEt5ZA6iDDnJ8QMVPXtfCJdl3xiQD6p6mn81fjB/l9z SjkyGbuDgavt1ZaPD0j3sPcKWCPpHYNcwxVPGuYtSw2AZv774p399RTUlif8CKfUWHPL J4tWUcbTS+YDjENbQcMu1dY5rZH68aNouydSJrZeg7bJr4rzomRfKQfxUlb7rC9RWZ6W YTbuG4miqJSPlfW/bQakQS5WsRtnI1j0KZTTE5ntkcvGBhxHd4K1c40WucUvvxaoXytK QYgg== X-Gm-Message-State: AHQUAubqPh3pyRvZarB/maxHTuSXrlX9tA2h4wBMrPE0FzLVQVsIpCy3 17S5HKxDRiJ7CTzuYc8zHGHVHRPV X-Google-Smtp-Source: AHgI3IacdJvF/0U3cuLm46TQpzdDnZZoJKGI28f+j/9mvc+uU9YDF+M0u7cLh1HL0sE0k8UeIx0Q8w== X-Received: by 2002:a1c:8086:: with SMTP id b128mr10955482wmd.117.1551096899683; Mon, 25 Feb 2019 04:14:59 -0800 (PST) Received: from [192.168.178.22] ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id u20sm8102180wmj.0.2019.02.25.04.14.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Feb 2019 04:14:58 -0800 (PST) To: "mpls@ietf.org" References: <155062612102.20788.8790340497411514162@ietfa.amsl.com> From: Stewart Bryant Message-ID: <16b6768d-5a63-a6fa-9e69-5f00f6ad5d5d@gmail.com> Date: Mon, 25 Feb 2019 12:14:57 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <155062612102.20788.8790340497411514162@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------9EB1108C21767A70585228C0" Content-Language: en-GB Archived-At: Subject: [mpls] draft-andersson-mpls-spl-terminology-00.txt - please not "Regular" 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 Feb 2019 12:15:05 -0000 This is a multi-part message in MIME format. --------------9EB1108C21767A70585228C0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Loa I see the need for clarification, but  am not a great fan of the term "Regular". It is very much a US expression rather than a global expression in the sense in which you use it.  Indeed I just looked it up in the OED and that says (amongst other definitions): "e. orig. U.S. Normal, average, or standard with reference to a predetermined scale or system of categorization; belonging to the category or class considered to be standard."* * and "f. Chiefly U.S. (colloq.). Of a person: ordinary, normal, unremarkable; (hence, as a general term of mild approbation) unpretentious, unassuming; decent, agreeable, esp. in regular guy."* * The latter I think defines  the usage of the word as you are using it. If it is indeed the latter definition you had in mind, I note that it is colloquial of which the OED says: "2. spec. Of words, phrases, etc.: Belonging to common speech; characteristic of or proper to ordinary conversation, as distinguished from formal or elevated language. (The usual sense.)"* * As we are writing a formal definition it seems odd to use an informal term. "Ordinary" or "Original" or "Short" or "Non-extended" or "Single" or "Short" or "Standard" are perhaps better alternates, but the exact name is something we should reflect upon as a WG. - Stewart --------------9EB1108C21767A70585228C0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Loa

I see the need for clarification, but  am not a great fan of the term "Regular". It is very much a US expression rather than a global expression in the sense in which you use it.  Indeed I just looked it up in the OED and that says (amongst other definitions):

"e. orig. U.S. Normal, average, or standard with reference to a predetermined scale or system of categorization; belonging to the category or class considered to be standard."

and

"f. Chiefly U.S. (colloq.). Of a person: ordinary, normal, unremarkable; (hence, as a general term of mild approbation) unpretentious, unassuming; decent, agreeable, esp. in regular guy."

The latter I think defines  the usage of the word as you are using it. If it is indeed the latter definition you had in mind, I note that it is colloquial of which the OED says:

"2. spec. Of words, phrases, etc.: Belonging to common speech; characteristic of or proper to ordinary conversation, as distinguished from formal or elevated language. (The usual sense.)"

As we are writing a formal definition it seems odd to use an informal term.

"Ordinary" or "Original" or "Short" or "Non-extended" or "Single" or "Short" or "Standard" are perhaps better alternates, but the exact name is something we should reflect upon as a WG.

- Stewart


--------------9EB1108C21767A70585228C0-- From nobody Mon Feb 25 04:33: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 6F339130EE9; Mon, 25 Feb 2019 04:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 0cK4PFIs-6XJ; Mon, 25 Feb 2019 04:32:51 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 20AFB130EEC; Mon, 25 Feb 2019 04:32:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 447Lv6744czKnSN; Mon, 25 Feb 2019 04:32:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1551097971; bh=lzCTTVgnlaQEb/ojim+tQ2J9xDqlQvMn5RQMB5lbHe4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=UGYONqKAhv+7bihth6TrWbglwvKfIN7t2zU+tny5Qvwx+YV0lF23+Y7YbBkDumUI7 AMQvMx4luJwehPYQe5DKmNG2CJ4RRsLlrrZViRxU5aLx5MajOZp83jejZezhuQMTHh WmbRx0qZ1+b3S+R9i9N0iGOv8JoXxj2PpnY+PzOI= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 447Lv54xP7zW036; Mon, 25 Feb 2019 04:32:49 -0800 (PST) To: "Carlos Pignataro (cpignata)" Cc: "Andrew G. Malis" , mpls , "ops-dir@ietf.org" , "draft-ietf-mpls-sfc-encapsulation.all@ietf.org" , IETF Discussion , "sfc@ietf.org" References: <155072147698.20210.381511429964485828@ietfa.amsl.com> <6A97863A-DD90-4D62-9607-569386F5F850@cisco.com> <03769b15-8375-a23a-a882-0a183056a8b5@joelhalpern.com> <7CA6EE6E-3D6C-4ACF-B9B4-540C57A658E8@cisco.com> From: "Joel M. Halpern" Message-ID: <992f87f7-f9bd-b5f5-1bf1-2b1f7e1eed08@joelhalpern.com> Date: Mon, 25 Feb 2019 07:32:48 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <7CA6EE6E-3D6C-4ACF-B9B4-540C57A658E8@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [mpls] Opsdir last call review of draft-ietf-mpls-sfc-encapsulation-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: Mon, 25 Feb 2019 12:32:55 -0000 First, you have a good point that the expected behavior of the MPLS TTL shoudl be specified. Given that we managed to confuse you, it needs to be fixed. As I understand it, the MPLS TTL used for transport between SFF and the NSH TTL used for the SFC SFP are unrelated. The NSH TTL has a value that exceeds the number of expected SFF (with a default of 63.) It is derement at each SFF. The MPLS TTL needs to be set to a value sufficient to get the NSH packet from one SFF to the next. That might be one MPLS hop. It might be several. Presumably therefore the default is whatever the default is for the MPLS network in which it is being used. the important point is that there is no relationship between decrements to the MPLS TTL and decrements to the NSH TTL. As in tunnel mode for IP in IP tunnels, the NSH TTL is only decrement by one for each SFF-SFF hop. Yours, Joel On 2/24/19 11:54 PM, Carlos Pignataro (cpignata) wrote: > Hi, Joel, > > Maybe I am misunderstanding something. Is the SFF Label, in the context > of MPLS transport encapsulation for the SFC NSH, ever expected to be > used for Forwarding? Is its TTL ever expected to be decremented and the > packet sent? If so, I did not understand that from the existing text, > since it is equivalent to a PW Label. If not, we can take advantage of TTL. > > Either way is good, I’m just asking to make this explicit. > > Thanks, > > — Carlos Pignataro > >> On Feb 23, 2019, at 1:43 AM, Joel M. Halpern > > wrote: >> >> My comment on this may not have made it to everyone.  If you receive a >> duplicate, I apologize  (I received DMARC errors from something about >> translations from the draft.all address to gmail addresses.) >> >> Speaking as a co-author... >> >> It is not at all clear to me that GTSM applies or how it would apply. >> There is no requirement that successive SFF be one MPLS hop apart. >> >> Yours, >> Joel >> >> On 2/22/19 9:27 AM, Andrew G. Malis wrote: >>> Carlos, >>> Looks good on all but one point - I think I see why you're >>> referencing GTSM, since packets at the SFC layer would generally be >>> one hop away from each other at that layer. Is that correct? However, >>> I really don't have sufficient experience with GTSM to craft >>> specific text. If you think it's important enough to include, could >>> you propose some text for me to include? >>> Thanks again, >>> Andy >>> On Thu, Feb 21, 2019 at 8:41 PM Carlos Pignataro (cpignata) >>> >>> > wrote: >>>    Hi, Andy, >>>>    On Feb 21, 2019, at 1:06 PM, Andrew G. Malis >>> >>>>    > wrote: >>>> >>>>    Carlos, >>>> >>>>    Many thanks for your review! I'm also including the SFC WG on my >>>>    reply. >>>    Thanks for the quick response, and for considering the comments! >>>    I enjoyed reading this document — please see below. >>>> >>>>    Comments inline. >>>> >>>>    On Wed, Feb 20, 2019 at 10:58 PM Carlos Pignataro >>>>     >>>> > wrote: >>>> >>>>        Reviewer: Carlos Pignataro >>>>        Review result: Has Issues >>>> >>>>        Reviewer: Carlos Pignataro >>>>        Review Result: Has Issues >>>> >>>>        I have reviewed this document as part of the Operational >>>>        directorate's >>>>        ongoing effort to review all IETF documents being processed by >>>>        the IESG.  These >>>>        comments were written with the intent of improving the >>>>        operational aspects of >>>>        the IETF drafts. Comments that are not addressed in last call >>>>        may be included >>>>        in AD reviews during the IESG review.  Document editors and WG >>>>        chairs should >>>>        treat these comments just like any other last call comments. >>>> >>>>        This document is highly readable, includes very clear textual >>>>        descriptions, and >>>>        is very well organized. Easy to read in its simplicity. >>>>        However, it would >>>>        benefit from a more explicit connection to the transport encap >>>>        mechanics from >>>>        RFC 8300 (e.g., S4, S6.1). Specifically, I'd recommend adding >>>>        a Figure or an >>>>        SFF NSH Mapping Table example, to depict and/or exemplify the >>>>        SFF function. >>>> >>>> >>>>    I'm trying to envision what would make a good figure here. We >>>>    could add an additional line to Table 1 of RFC 8300 and reference >>>>    that table: >>>> >>>>           +------+------+---------------------+-------------------------+ >>>>           | SPI  | SI   | Next Hop(s)         | Transport >>>> Encapsulation | >>>>           +------+------+---------------------+-------------------------+ >>>>           | 25   | 220  | Label 5467          | MPLS >>>>                    | >>>>           +------+------+---------------------+-------------------------+ >>>> >>>>    Is that what you had in mind? If not, I'm open to other suggestions. >>>    If you think it helps, this would be a good addition. >>>> >>>>        >From an Operational standpoint, the document seems largely >>>>        appropriate in terms >>>>        of dataplane considerations. Some key considerations are >>>>        explicitly out of >>>>        scope: >>>>           The method used by the downstream receiving node to >>>>        advertise SFF >>>>           Labels to the upstream sending node is out of scope of this >>>>        document. >>>> >>>>        This really seems to mean that, with the simple definition in >>>> this >>>>        Informational document, interoperable implementations cannot >>>>        yet exist. If >>>>        there is no mechanism to advertise the SFF Label or to manage >>>>        the semantics of >>>>        this particular label, how will it know? Static configuration, >>>>        which is not >>>>        covered anyway, is not in my humble opinion a manageable >>>>        scalable approach. >>>> >>>> >>>>    Actually, while it is outside the scope of this document, it is >>>>    within the scope of draft-ietf-bess-nsh-bgp-control-plane, and >>>>    text is being added to the next revision of that draft to show how >>>>    it can be used to signal the encapsulation defined here. This was >>>>    worked out after this draft was forwarded to the IESG, but we can >>>>    now add a reference to that draft seeing as we'll be doing a >>>>    post-last-call update. >>>    I think that will help, as an Informative “one embodiment” type of >>> link. >>>> >>>>        Title: MPLS Encapsulation For The SFC NSH >>>> >>>>        RFC 8300 makes an explicit distinction between the terms >>>>        'encapsulation' and >>>>        'transport encapsulation' (see e.g., Figure 1, Section 1.5 5., >>>>        and Section 4 of >>>>        RFC 8300). >>>> >>>>        It seems to me that this is the "MPLS Transport Encapsulation >>>>        for the SFC NSH" >>>> >>>> >>>>    Thanks, we'll fix that. >>>> >>>> >>>>        2.  MPLS Encapsulation Using an SFF Label >>>> >>>>        Similarly, "2. MPLS Transport Encapsulation Using an SFF Label" >>>> >>>>           The encapsulation is a standard MPLS label stack [RFC3032] >>>>        with an >>>>           SFF Label at the bottom of the stack, followed by a NSH as >>>>        defined by >>>>           [RFC8300] and the NSH payload. >>>> >>>>        Insteadf of "NSH payload" I think "orignal packet" is meant. >>>> >>>> >>>>    RFC 8300 uses both "payload" and "original packet/frame", but the >>>>    latter more than the former. So we can change "payload" to >>>>    "original packet/frame". >>>> >>>> >>>>        Also, this encapsulation is Underdefined: What is the value of >>>>        TTL? TC? >>>> >>>> >>>>    I've been looking back at other related RFCs (such as PW and IP >>>>    VPN label definitions) and they're also mostly silent on these >>>>    values. I did find the following in RFC 6073: >>>> >>>>        The setting of the TTL of the PW MPLS >>>>        label is a matter of local policy on the originating PE, but >>>> SHOULD >>>>        be set to 255. >>>> >>>>    Regarding the TC, we can follow the example of RFC 6391: >>>> >>>>        This document does not define a use for the Traffic Class >>>> (TC) field >>>>        [RFC5462  ] (formerly >>>> known as the Experimental Use (EXP) bits >>>>        [RFC3032  ]) in the flow >>>> label.  Future documents may define a use for >>>>        these bits; therefore, implementations conforming to this >>>>        specification MUST set the TC field to zero at the ingress >>>> and MUST >>>>        ignore them at the egress. >>>> >>>>    Do you have any alternative suggestions? >>>    These two approaches sounds good to me. And Ack to the other >>>    previous responses. >>>> >>>>           Much like a pseudowire label, an SFF Label is allocated by the >>>>           downstream receiver of the NSH from its per-platform label >>>>        space. >>>> >>>>        A PW Label is more restrictive. RFC 8077 says it MUST be >>>>        allocated as >>>>        per-platform: >>>> >>>>           egress LSR only.  Note that the PW label must always be at >>>>        the bottom >>>>           of the packet's label stack, and labels MUST be allocated >>>>        from the >>>>           per-platform label space. >>>> >>>>        Is this the case for the SFF Label as well? If so, what is the >>>>        implication of >>>>        the MUST? If not, why is it different than other equivalent >>>>        similar labels? >>>> >>>> >>>>    We can change the text to: >>>> >>>>     Much like a pseudowire label, an SFF Label MUST be allocated by >>>>    the downstream receiver of the NSH from its per-platform label >>>>    space, since the meaning of the label is identical independent of >>>>    which incoming interface it is received [RFC3031]. >>>> >>>    That’s a great improvement. >>>> >>>>           2.  Push the SFF Label to identify the desired SFF in the >>>>        receiving >>>>               MPLS node. >>>> >>>>        TTL value? 1? 2? 255 for GTSM? GTSM RFC 5082 could be used here. >>>> >>>> >>>>    As I noted above, 255, although I used RFC 6073 as my source >>>>    rather than 5082. We'll add that here as well. >>>> >>>    Sounds good. >>>    These protocols use 5082 in one form or another: >>> https://datatracker.ietf.org/doc/rfc5082/referencedby/ >>>> >>>>        4.  Operations, Administration, and Maintenance (OAM) >>>>        Considerations >>>> >>>>           OAM at the SFC Layer is handled by SFC-defined mechanisms >>>>        [RFC8300]. >>>>           However, OAM may be required at the MPLS transport layer. >>>>         If so, >>>>           then standard MPLS-layer OAM mechanisms such as the Generic >>>>           Associated Channel [RFC5586] label may be used. >>>> >>>>        RFC 5586 is _not_ an OAM mechanism. It is an associated >>>>        channel creation >>>>        mechanism, over which OAM could be carried. >>>> >>>>        Thus, what traditional MPLS OAM can be carried here? Things >>>>        like RFC 4379 / RFC >>>>        8029 would need the definition of an SFF Label FEC (which does >>>>        not exist). >>>>        Which other one? IP/ICMP seems of very limited value. >>>> >>>> >>>>    That's a good point about RFC 5586. The intention is that the MPLS >>>>    OAM would be at the transport label layer above the SFF label, so >>>>    most any MPLS-layer OAM would be applicable. So how about >>>>    rewording to make that more clear: >>>> >>>>    OAM at the SFC Layer is handled by SFC-defined mechanisms >>>>    [RFC8300]. However, OAM may be required at the MPLS transport >>>>    layer.  If so, then standard MPLS-layer OAM mechanisms may be used >>>>    at the transport label layer (the labels above the SFF label). >>>    Looks good to me, thank you. >>>> >>>> >>>>        6.  Security Considerations >>>> >>>>        Have you considered the use of GTSM? >>>> >>>> >>>>    No, we hadn't. Can you point me to any examples of GTSM being used >>>>    in an MPLS or PW context? >>>    Yes, see above. >>>> >>>>        8.  References >>>> >>>>           [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service >>>>        Function >>>>                      Chaining (SFC) Architecture", RFC 7665, >>>>                      DOI 10.17487/RFC7665, October 2015, >>>>                      >>>        >. >>>> >>>>        SHould RFC 7665 be Normative? It defines the "SFF" which is >>>>        quite central to >>>>        understanding this document. >>>> >>>> >>>>    Good point. It was there because 7665 is an Informational RFC, but >>>>    RFC 8067 does allow normative references to informational RFCs, so >>>>    I'll move it. >>>    Thank you. >>>> >>>>        Other Nits and Editorials: >>>> >>>>           SFF Labels are similar to other service labels at the >>>>        bottom of an >>>>           MPLS label stack that denote the contents of the MPLS >>>>        payload being >>>>           other than IP, such as a layer 2 pseudowire, an IP packet >>>>        that is >>>>           routed in a VPN context with a private address, or an Ethernet >>>>           virtual private wire service. >>>> >>>>        This says "being other than IP, such as IP", which seems to be >>>>        self-contradictory :-) >>>> >>>>    :-) >>>> >>>>    How about we change "other than IP," to "other than a normally >>>>    routed IP packet”, >>>    That would disambiguate it. >>>    Thanks again. >>>    To me, the control plane / advertisement was the most important >>>    operationally-relevant comment. >>>    Thanks, >>>    Carlos. >>>> >>>>    Thanks again, >>>>    Andy > From nobody Mon Feb 25 05:01: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 CC85A130EED; Mon, 25 Feb 2019 05:01:39 -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, 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 NqZp6WhOyiUx; Mon, 25 Feb 2019 05:01:38 -0800 (PST) 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 50C46130EF1; Mon, 25 Feb 2019 05:01:38 -0800 (PST) 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 0CE78180158C; Mon, 25 Feb 2019 14:01:35 +0100 (CET) From: Loa Andersson To: "mpls@ietf.org" , "mpls-chairs@ietf.org" Message-ID: Date: Mon, 25 Feb 2019 21:01:27 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] the sleeping beauties 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 Feb 2019 13:01:40 -0000 Working Group, This is something I flagged at the f2f meeting in Bangkok, we have quite a large number of drafts that are dormant, I called the "Sleeping Beauties". I have managed to take out a few drafts from the list, mostly since they have been replaced by or merged into another draft. I'm not convinced that all of these draft should have been dropped, if you find one of your drafts on the list and have an opinion what we should do plese let the wg chairs know. /Loa THe sleeping beauties: draft-alvarez-mpls-ldp-color-lsp draft-ama-mpls-fm-rdi draft-balaji-mpls-csc-te-lsp-splice draft-balaji-mpls-lawful-intercept-thru-label-dis draft-balaji-mpls-li-thru-label-dis-snmp draft-beeram-mpls-rsvp-te-scaling draft-bryant-mpls-rfc6374-over-udp draft-bryant-mpls-sfl-control draft-bryant-mpls-synonymous-flow-labels draft-cheng-mpls-tp-pwe3-dual-homed-protection draft-chen-mpls-ldp-yang-cfg draft-chenpeng-mpls-ldp-ext draft-dai-mpls-rsvp-te-mbb-label-reuse draft-esale-mpls-ldp-node-frr draft-fang-mpls-hsdn-for-hsdc draft-fang-mpls-label-forwarding-no-swap draft-fuxh-mpls-delay-loss-rsvp-te-ext draft-fuxh-mpls-delay-loss-te-framework draft-fuxh-mpls-delay-loss-te-problem-statement draft-gandhi-mpls-te-yang-model draft-hmk-mpls-tp-p2mp-oam-framework draft-iwijnand-mpls-mldp-multi-topology draft-jacob-mpls-ethldp draft-jacquenet-mpls-rd-p2mp-te-requirements draft-keten-mpls-expbit draft-kini-mpls-entropy-label-src-stacked-tunnels draft-kini-spring-mpls-lsp-ping draft-kompella-mpls-larp draft-kompella-mpls-rsvp-ecmp draft-li-mpls-global-label-framework draft-li-mpls-global-label-usecases draft-li-mpls-label-stack-distribution draft-li-mpls-ldp-mt-mib draft-li-mpls-p2mp-te-alt-path draft-li-mpls-path-programming draft-li-mpls-proxy-te-lsp draft-li-mpls-seamless-mpls-mbb draft-liu-mpls-tp-interconnected-ring-protection draft-liu-mpls-tp-p2mp-linear-protection draft-lzj-mpls-receiver-driven-multicast-rsvp-te draft-lzl-mpls-ucase-n-20bit-label-limitation draft-lzj-mpls-receiver-driven-multicast-rsvp-te draft-lzl-mpls-ucase-n-20bit-label-limitation draft-manral-mpls-rfc3811bis draft-mda-mpls-tp-p2mp-oam-framework draft-mpls-big-label-ucase-req draft-nainar-mpls-spring-lsp-ping-sids draft-ncrsht-mpls-unique-and-consistent-label-ldp draft-ncrsht-mpls-unique-and-consistent-label-ldp draft-openconfig-mpls-consolidated-model draft-pdutta-mpls-tldp-hello-reduce draft-pelletier-mpls-ldp-bindings-refresh draft-pignataro-mpls-reserved-labels-lb draft-raszuk-mpls-domain-wide-labels draft-renwei-mpls-big-label draft-saad-mpls-lsp-instant-install-rsvpte draft-turaga-mpls-test-labels draft-vainshtein-mpls-gal-tc-ttl-handling draft-vgovindan-mpls-extended-bfd-disc-tlv draft-wijnands-mpls-mldp-multi-topology draft-villamizar-mpls-multipath-extn draft-wu-mpls-rsvp-te-path-profile draft-xu-mpls-el-capability-signaling-igp draft-xu-mpls-multi-domain-deployment-enhancement draft-xu-mpls-payload-protocol-identifier draft-xu-mpls-service-chaining draft-xu-mpls-spring-islands-connection-over-ip draft-xu-mpls-unified-source-routing-instruction draft-xu-sfc-using-mpls-based-source-routing draft-xu-sfc-using-mpls-spring draft-you-mpls-spring-sfc-oam draft-zhang-mpls-tp-yang-oam draft-zhao-mpls-mldp-protections draft-zheng-mpls-lsp-ping-yang-cfg draft-zlj-mpls-mrsvp-te-frr draft-zzhang-mpls-icmp-bier -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Mon Feb 25 07:36: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 71D98130EE3 for ; Mon, 25 Feb 2019 07:36:43 -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 ky-dBwdeSUXz for ; Mon, 25 Feb 2019 07:36:41 -0800 (PST) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 37DDB1292F1 for ; Mon, 25 Feb 2019 07:36:41 -0800 (PST) Received: by mail-qt1-x835.google.com with SMTP id j36so10921917qta.7 for ; Mon, 25 Feb 2019 07:36:41 -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=dHl5Q3N3VTt17UQz/AxLZab+J+z9u8+tXUZg79bYOhA=; b=r1wGm4oVr+Nc1cNCvzUlPKvRUgIcEnDv//UMaj2ArKbOzP1RiODnreE7pSfnuo8mg6 JDWGaAjk0b94qs3i8ouIsikHQNHWJuouY1c/k9A737ahlHbtwLvobMliU2iizlrSdBqU XrGYCLW2hB+ULVBht1lr64hH4K3ljbaonHI4+6D5JefJaRY7Nz/NRsITkV9B+VVTniFa QQVgqVM+gfmt03u+TBjZqLzXj+YBGYhrvII8/Mw0qDdoaT33DfXk7dWImJ3kVt+9Ei2Z gKwffOn/9ymJ5sII05HZiTSO1ST1UL8wsRXjx1tXyZ9gaFtItXsJr0pdGRQX17QlXp/p k/QQ== 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=dHl5Q3N3VTt17UQz/AxLZab+J+z9u8+tXUZg79bYOhA=; b=b48SNhxSxLOhWrI7aSFqvQUFO2TBJDDVbmAixYFNz/mP+uKyjPWdyVJVthW4+bu1Uz TbuTyXBuBTJO8IZzzd6t2sOMVDnKZnL0dSK/gzWpmrfcYqXtMRYMeYaUb6AkVnN5N5wd qPZaofwMoPR4gxjdavcYnUnpIYLZHfv6OXEbdPb9jC+Z2NOjQr+QAYPcUyIrru9H+Vxv q+VcDpIrsHScUUMjNjpmvqgH10eMXs9xtnZN5qrvKAt3IdVcRYqQTScRVhQnYfKRGE6+ N94f4qsYOwEHt1Z+7O+vfjnORcx540vdXKZxRDBMYIy5AxC+lWuyNxsP2nqTdZo5UcYt qTcg== X-Gm-Message-State: AHQUAubDrkn0J2NOuoZs/pWyzPvnGEU06I4HLrqcJ1iw9d+ZccwL/5sA 5xCbl/FqFR1csSQ8vC1Y/wZQ5KnaidTGNda8DsA= X-Google-Smtp-Source: AHgI3IbllZ1IcfKd5moO6lhhs5gTZBJSWuyejZ3AbkI0NDEQEaa6dSys1A2s8SVvHTUi7RkP55ZWpzmz8byw8lQHVck= X-Received: by 2002:a0c:941b:: with SMTP id h27mr14114232qvh.8.1551109000146; Mon, 25 Feb 2019 07:36:40 -0800 (PST) MIME-Version: 1.0 References: <20190225012311.C02BDB80458@rfc-editor.org> In-Reply-To: <20190225012311.C02BDB80458@rfc-editor.org> From: "Andrew G. Malis" Date: Mon, 25 Feb 2019 10:36:28 -0500 Message-ID: To: RFC Errata System Cc: erosen@cisco.com, arun@force10networks.com, Ross Callon , "BRUNGARD, DEBORAH A (ATTLABS)" , Alvaro Retana , Martin Vigoureux , Loa Andersson , Nicolai Leymann , mpls , markzzzsmith@gmail.com Content-Type: multipart/alternative; boundary="000000000000f634280582b9b455" Archived-At: Subject: Re: [mpls] [Technical Errata Reported] RFC3031 (5643) 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 Feb 2019 15:36:43 -0000 --000000000000f634280582b9b455 Content-Type: text/plain; charset="UTF-8" The submitter does make a good point, LER should probably be defined in the MPLS architecture. I just did a search and the earliest mention of "Label Edge Router" that I could find is in RFC 3811. That said, I think I prefer the definition text from RFC 4221: An LER is an LSR placed at the edge of an MPLS domain, and it passes traffic into and out of the MPLS domain. An ingress LER is responsible for classifying data and assigning it to a suitable LSP or tunnel. This classification is done using Forwarding Equivalence Classes (FECs) that define the common attributes of data (usually packets) that will be treated in the same way. Once data has been classified, it can be handed off to an LSP or tunnel through the Next Hop Label Forwarding Entry (NHLFE). Cheers, Andy On Sun, Feb 24, 2019 at 8:23 PM RFC Errata System wrote: > The following errata report has been submitted for RFC3031, > "Multiprotocol Label Switching Architecture". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5643 > > -------------------------------------- > Type: Technical > Reported by: Mark Smith > > Section: Terminology > > Original Text > ------------- > > > Corrected Text > -------------- > label edge router - a router capable of accepting an unlabelled packet, > and through MPLS processing, may MPLS encapsulate the packet by adding > a label stack. > > Notes > ----- > I am doing some MPLS review. > > The book I'm using said an LER was an (RFC3031) MPLS edge node. I believed > it was any router that could take unlabelled packets and label them, > regardless of where the router was within the MPLS domain. (In other words, > an MPLS router was not an LER if it would not MPLS label unlabelled packets > and forward them.) > > I decided to check RFC3031 for a definition, and discovered there isn't a > definition at all for "label edge router", or a match on any text that > matches "label edge" or "LER". > > RFC6178 clarifies LER processing of IPv4 packets, and the general > description of processing matches my understanding of what an LER is. > > However, it doesn't formally define an "label edge router" either, and I > think an update to RFC3031 should be where "label edge router" is formally > defined. > > 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. > > -------------------------------------- > RFC3031 (draft-ietf-mpls-arch-06) > -------------------------------------- > Title : Multiprotocol Label Switching Architecture > Publication Date : January 2001 > Author(s) : E. Rosen, A. Viswanathan, R. Callon > Category : PROPOSED STANDARD > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --000000000000f634280582b9b455 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The submitter=C2=A0does make a good point, LER should prob= ably be defined in the MPLS architecture. I just did a search and the earli= est mention of "Label Edge Router" that I could find is in RFC 38= 11.=C2=A0

That said, I think I prefer the definition tex= t from RFC 4221:
   An LER is an LSR placed at the edge of an MPLS domain, and it passe=
s
   traffic into and out of the MPLS domain.  An ingress LER is
   responsible for classifying data and assigning it to a suitable LSP
   or tunnel.

   This classification is done using Forwarding Equivalence Classes
   (FECs) that define the common attributes of data (usually packets)
   that will be treated in the same way.  Once data has been classified,
   it can be handed off to an LSP or tunnel through the Next Hop Label
   Forwarding Entry (NHLFE).
Cheers,
Andy


On Sun, Feb 24, 2019 at 8:= 23 PM RFC Errata System <rf= c-editor@rfc-editor.org> wrote:
The following errata report has been submitted for R= FC3031,
"Multiprotocol Label Switching Architecture".

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

--------------------------------------
Type: Technical
Reported by: Mark Smith <markzzzsmith@gmail.com>

Section: Terminology

Original Text
-------------
<missing>

Corrected Text
--------------
label edge router - a router capable of accepting an unlabelled packet,
and through MPLS processing, may MPLS encapsulate the packet by adding
=C2=A0a label stack.

Notes
-----
I am doing some MPLS review.

The book I'm using said an LER was an (RFC3031) MPLS edge node. I belie= ved it was any router that could take unlabelled packets and label them, re= gardless of where the router was within the MPLS domain. (In other words, a= n MPLS router was not an LER if it would not MPLS label unlabelled packets = and forward them.)

I decided to check RFC3031 for a definition, and discovered there isn't= a definition at all for "label edge router", or a match on any t= ext that matches "label edge" or "LER".

RFC6178 clarifies LER processing of IPv4 packets, and the general descripti= on of processing matches my understanding of what an LER is.

However, it doesn't formally define an "label edge router" ei= ther, and I think an update to RFC3031 should be where "label edge rou= ter" is formally defined.

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.

--------------------------------------
RFC3031 (draft-ietf-mpls-arch-06)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Multiprotocol= Label Switching Architecture
Publication Date=C2=A0 =C2=A0 : January 2001
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: E. Rosen, A. Viswanatha= n, R. Callon
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED 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
--000000000000f634280582b9b455-- From nobody Mon Feb 25 08:39: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 7729B130E8E; Mon, 25 Feb 2019 08:39:13 -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 AgcJ_ADC_YzQ; Mon, 25 Feb 2019 08:39:10 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 46BE51277CC; Mon, 25 Feb 2019 08:39:10 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id a17so7988692ljd.4; Mon, 25 Feb 2019 08:39:10 -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=IwAvZ9+WBgeoyyqCl+TmdxaBVCgjsQm3jTd4AJdmk6Y=; b=vdCnOPsLTkdIhoRh/TSLQ70RGK8YvGSxU+EoFGXkSUcnxDiP0bT6+77ZplkXZ1VzhN NTwPsJiWTVXZumczCQZUaNQusTyW0SLPYpJ0NbHWsY3PmOzuKi/LnuRX+iEizYY7R+CJ 9sXB0LfgAzi4HmtTASo63cwEDZ5jUGLdx4VWiziKPV+lwteQX/jeszk0NUY5XbkjAtz8 dcKoc/yI1To4ZBv3R4Bm4GMDZ9jHA4xcqjLp5u/icPRNOYETGOKw7B9O3T0sYXwRPNZ4 +I61kKI4T0WgyAY4NHwe9n06AFaxdoQUFMYFpv69MVD39JIGpuRPwjkxY7/QwqwYHPZf 7qvQ== 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=IwAvZ9+WBgeoyyqCl+TmdxaBVCgjsQm3jTd4AJdmk6Y=; b=Rsqj2qQFz8BdImlmGgucuARslFw5NKSUkLfqmB/Xc8+MxF8D+UjZX2VbcvXRrkTa2c vilKDYBqMUJwOLB4lf9b6BpNKvXzKjjwwI5UnBVbsmPXgAuQBJmaId2gD08I3SBrSPgz j9J8PKMwOc3pJgnObQEVEWsKXrqXbbGQykE/kO1j1OI+kHze/2DqBUoVO/xKQsGSQITu /jF+ARieLpgCcSMoL0e8VB6t3vlJ5SShK9SK4MgBRropAVWy7tm96r3Y1EEzxwAcbKea GmXxH0+m9AJ0dNP1Gl20a51hjk6QNEmxOn4woONTtVZIOrD3bnPgGUleq0awDxHDE5lH +IaA== X-Gm-Message-State: AHQUAuZ9l9fEjIIeasts4+6eHH2/97ube8sIgCzdKT1emNn2sN5aFbXV XHa6p5nzWeWRqWheOydxLD4YVbGOLPR4WGeoE7DZY4k4 X-Google-Smtp-Source: AHgI3IbXbSCg9op76CtlsDVMY7vEodk+J9NOzDJmrk0o844UFMhrnjOcZxq1lk2REEm3gdengCVFefkwIUaA3NRO3M0= X-Received: by 2002:a2e:424f:: with SMTP id p76mr10264132lja.140.1551112748136; Mon, 25 Feb 2019 08:39:08 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Mon, 25 Feb 2019 08:38:57 -0800 Message-ID: To: Loa Andersson Cc: "mpls@ietf.org" , "mpls-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005bfcec0582ba9493" Archived-At: Subject: Re: [mpls] the sleeping beauties 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 Feb 2019 16:39:13 -0000 --0000000000005bfcec0582ba9493 Content-Type: text/plain; charset="UTF-8" Hi Loa, I can update on two entries on the list: - draft-zheng-mpls-lsp-ping-yang-cfg - is in WGAP. If the WG decides to adopt will continue working on the document, to address the comments already received; - draft-zhang-mpls-tp-yang-oam - may be worth asking the WG if there's value in publishing the model. If adopted by the WG, will work on it as well. Regards, Greg draft-zheng-mpls-lsp-ping-yang-cfg On Mon, Feb 25, 2019 at 5:01 AM Loa Andersson wrote: > Working Group, > > This is something I flagged at the f2f meeting in Bangkok, we have > quite a large number of drafts that are dormant, I called the "Sleeping > Beauties". > > I have managed to take out a few drafts from the list, mostly since they > have been replaced by or merged into another draft. > > I'm not convinced that all of these draft should have been dropped, if > you find one of your drafts on the list and have an opinion what we > should do plese let the wg chairs know. > > /Loa > > THe sleeping beauties: > > draft-alvarez-mpls-ldp-color-lsp > draft-ama-mpls-fm-rdi > draft-balaji-mpls-csc-te-lsp-splice > > draft-balaji-mpls-lawful-intercept-thru-label-dis > draft-balaji-mpls-li-thru-label-dis-snmp > draft-beeram-mpls-rsvp-te-scaling > > draft-bryant-mpls-rfc6374-over-udp > draft-bryant-mpls-sfl-control > draft-bryant-mpls-synonymous-flow-labels > > draft-cheng-mpls-tp-pwe3-dual-homed-protection > draft-chen-mpls-ldp-yang-cfg > draft-chenpeng-mpls-ldp-ext > > draft-dai-mpls-rsvp-te-mbb-label-reuse > draft-esale-mpls-ldp-node-frr > draft-fang-mpls-hsdn-for-hsdc > > draft-fang-mpls-label-forwarding-no-swap > draft-fuxh-mpls-delay-loss-rsvp-te-ext > draft-fuxh-mpls-delay-loss-te-framework > > draft-fuxh-mpls-delay-loss-te-problem-statement > draft-gandhi-mpls-te-yang-model > draft-hmk-mpls-tp-p2mp-oam-framework > > draft-iwijnand-mpls-mldp-multi-topology > draft-jacob-mpls-ethldp > draft-jacquenet-mpls-rd-p2mp-te-requirements > > draft-keten-mpls-expbit > draft-kini-mpls-entropy-label-src-stacked-tunnels > draft-kini-spring-mpls-lsp-ping > > draft-kompella-mpls-larp > draft-kompella-mpls-rsvp-ecmp > draft-li-mpls-global-label-framework > > draft-li-mpls-global-label-usecases > draft-li-mpls-label-stack-distribution > draft-li-mpls-ldp-mt-mib > > draft-li-mpls-p2mp-te-alt-path > draft-li-mpls-path-programming > draft-li-mpls-proxy-te-lsp > > draft-li-mpls-seamless-mpls-mbb > draft-liu-mpls-tp-interconnected-ring-protection > draft-liu-mpls-tp-p2mp-linear-protection > > draft-lzj-mpls-receiver-driven-multicast-rsvp-te > draft-lzl-mpls-ucase-n-20bit-label-limitation > draft-lzj-mpls-receiver-driven-multicast-rsvp-te > > draft-lzl-mpls-ucase-n-20bit-label-limitation > draft-manral-mpls-rfc3811bis > draft-mda-mpls-tp-p2mp-oam-framework > > draft-mpls-big-label-ucase-req > draft-nainar-mpls-spring-lsp-ping-sids > draft-ncrsht-mpls-unique-and-consistent-label-ldp > > draft-ncrsht-mpls-unique-and-consistent-label-ldp > draft-openconfig-mpls-consolidated-model > draft-pdutta-mpls-tldp-hello-reduce > > draft-pelletier-mpls-ldp-bindings-refresh > draft-pignataro-mpls-reserved-labels-lb > draft-raszuk-mpls-domain-wide-labels > > draft-renwei-mpls-big-label > draft-saad-mpls-lsp-instant-install-rsvpte > draft-turaga-mpls-test-labels > > draft-vainshtein-mpls-gal-tc-ttl-handling > draft-vgovindan-mpls-extended-bfd-disc-tlv > draft-wijnands-mpls-mldp-multi-topology > > draft-villamizar-mpls-multipath-extn > draft-wu-mpls-rsvp-te-path-profile > draft-xu-mpls-el-capability-signaling-igp > > draft-xu-mpls-multi-domain-deployment-enhancement > draft-xu-mpls-payload-protocol-identifier > draft-xu-mpls-service-chaining > > draft-xu-mpls-spring-islands-connection-over-ip > draft-xu-mpls-unified-source-routing-instruction > draft-xu-sfc-using-mpls-based-source-routing > > draft-xu-sfc-using-mpls-spring > draft-you-mpls-spring-sfc-oam > draft-zhang-mpls-tp-yang-oam > > draft-zhao-mpls-mldp-protections > draft-zheng-mpls-lsp-ping-yang-cfg > draft-zlj-mpls-mrsvp-te-frr > > draft-zzhang-mpls-icmp-bier > > > -- > > > 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 > --0000000000005bfcec0582ba9493 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Loa,
I can update on two entries on the list:
=
  • draft-zheng-mpls-lsp-ping-yang-cfg=C2=A0=C2=A0=C2=A0- is in WG= AP. If the WG decides to adopt will continue working on the document, to ad= dress the comments already received;
  • draft-zhang-mpls-tp-yang-o= am - may be worth asking the WG if there's value in publishing the mode= l. If adopted by the WG, will work on it as well.
Regards,
Greg

draft-zheng-mpls-lsp-ping-yang-cfg=C2=A0= =C2=A0

On Mon, Feb 25, 2019 at 5:01 AM Loa Andersson <loa@pi.nu> wrote:
Working Group,

This is something I flagged at the f2f meeting in Bangkok, we have
quite a large number of drafts that are dormant, I called the "Sleepin= g
Beauties".

I have managed to take out a few drafts from the list, mostly since they have been replaced by or merged into=C2=A0 another draft.

I'm not convinced that all of these draft should have been dropped, if =
you find one of your drafts on the list and have an opinion what we
should do plese let the wg chairs know.

/Loa

THe sleeping beauties:

draft-alvarez-mpls-ldp-color-lsp
draft-ama-mpls-fm-rdi
draft-balaji-mpls-csc-te-lsp-splice

draft-balaji-mpls-lawful-intercept-thru-label-dis
draft-balaji-mpls-li-thru-label-dis-snmp
draft-beeram-mpls-rsvp-te-scaling

draft-bryant-mpls-rfc6374-over-udp
draft-bryant-mpls-sfl-control
draft-bryant-mpls-synonymous-flow-labels

draft-cheng-mpls-tp-pwe3-dual-homed-protection
draft-chen-mpls-ldp-yang-cfg
draft-chenpeng-mpls-ldp-ext

draft-dai-mpls-rsvp-te-mbb-label-reuse
draft-esale-mpls-ldp-node-frr
draft-fang-mpls-hsdn-for-hsdc

draft-fang-mpls-label-forwarding-no-swap
draft-fuxh-mpls-delay-loss-rsvp-te-ext
draft-fuxh-mpls-delay-loss-te-framework

draft-fuxh-mpls-delay-loss-te-problem-statement
draft-gandhi-mpls-te-yang-model
draft-hmk-mpls-tp-p2mp-oam-framework

draft-iwijnand-mpls-mldp-multi-topology
draft-jacob-mpls-ethldp
draft-jacquenet-mpls-rd-p2mp-te-requirements

draft-keten-mpls-expbit
draft-kini-mpls-entropy-label-src-stacked-tunnels
draft-kini-spring-mpls-lsp-ping

draft-kompella-mpls-larp
draft-kompella-mpls-rsvp-ecmp
draft-li-mpls-global-label-framework

draft-li-mpls-global-label-usecases
draft-li-mpls-label-stack-distribution
draft-li-mpls-ldp-mt-mib

draft-li-mpls-p2mp-te-alt-path
draft-li-mpls-path-programming
draft-li-mpls-proxy-te-lsp

draft-li-mpls-seamless-mpls-mbb
draft-liu-mpls-tp-interconnected-ring-protection
draft-liu-mpls-tp-p2mp-linear-protection

draft-lzj-mpls-receiver-driven-multicast-rsvp-te
draft-lzl-mpls-ucase-n-20bit-label-limitation
draft-lzj-mpls-receiver-driven-multicast-rsvp-te

draft-lzl-mpls-ucase-n-20bit-label-limitation
draft-manral-mpls-rfc3811bis
draft-mda-mpls-tp-p2mp-oam-framework

draft-mpls-big-label-ucase-req
draft-nainar-mpls-spring-lsp-ping-sids
draft-ncrsht-mpls-unique-and-consistent-label-ldp

draft-ncrsht-mpls-unique-and-consistent-label-ldp
draft-openconfig-mpls-consolidated-model
draft-pdutta-mpls-tldp-hello-reduce

draft-pelletier-mpls-ldp-bindings-refresh
draft-pignataro-mpls-reserved-labels-lb
draft-raszuk-mpls-domain-wide-labels

draft-renwei-mpls-big-label
draft-saad-mpls-lsp-instant-install-rsvpte
draft-turaga-mpls-test-labels

draft-vainshtein-mpls-gal-tc-ttl-handling
draft-vgovindan-mpls-extended-bfd-disc-tlv
draft-wijnands-mpls-mldp-multi-topology

draft-villamizar-mpls-multipath-extn
draft-wu-mpls-rsvp-te-path-profile
draft-xu-mpls-el-capability-signaling-igp

draft-xu-mpls-multi-domain-deployment-enhancement
draft-xu-mpls-payload-protocol-identifier
draft-xu-mpls-service-chaining

draft-xu-mpls-spring-islands-connection-over-ip
draft-xu-mpls-unified-source-routing-instruction
draft-xu-sfc-using-mpls-based-source-routing

draft-xu-sfc-using-mpls-spring
draft-you-mpls-spring-sfc-oam
draft-zhang-mpls-tp-yang-oam

draft-zhao-mpls-mldp-protections
draft-zheng-mpls-lsp-ping-yang-cfg
draft-zlj-mpls-mrsvp-te-frr

draft-zzhang-mpls-icmp-bier


--


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
--0000000000005bfcec0582ba9493-- From nobody Mon Feb 25 09:56: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 B8603126D00 for ; Mon, 25 Feb 2019 09:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tmtwpPjWWisB for ; Mon, 25 Feb 2019 09:56:02 -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 A07DE130F96 for ; Mon, 25 Feb 2019 09:56:01 -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 x1PHto2j022232; Mon, 25 Feb 2019 17:55:53 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CD58022044; Mon, 25 Feb 2019 17:55:52 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id B613922042; Mon, 25 Feb 2019 17:55:52 +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 x1PHtp0d003532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 25 Feb 2019 17:55:51 GMT Reply-To: From: "Adrian Farrel" To: "'Andrew G. Malis'" , "'RFC Errata System'" Cc: "'mpls'" , , , "'Ross Callon'" , References: <20190225012311.C02BDB80458@rfc-editor.org> In-Reply-To: Date: Mon, 25 Feb 2019 17:55:49 -0000 Organization: Old Dog Consulting Message-ID: <020f01d4cd33$57e13470$07a39d50$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0210_01D4CD33.57E2BB10" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEhmuGpLwxAuTsvFpwZfJXMqOlcDwHWOqFQp0h7GBA= 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-24456.002 X-TM-AS-Result: No--27.080-10.0-31-10 X-imss-scan-details: No--27.080-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24456.002 X-TMASE-Result: 10--27.079900-10.000000 X-TMASE-MatchedRID: 8HTFlOrbAtHxIbpQ8BhdbAArNgt5xpQYIM86Aeo6sYK0Vg+MnSE2GHLu 5dsUmK54ax3Gn44CHApd9WOUcyJ+BKWS/mt9cqrN+z2c4lioPkjFphRdtkn03tilG/maIsZ8YWz +8oXB3KiKQdNLgz0V0r0FsRP+GUXHDpfVsOpEdC8WFB9s82eM27pAJMK7N+JV6h3Xfd5VY/iRGr Qa6VK6LJ/Xz1rC/1g0Tl3cIax9cddByHwYgfuI7umc4/pDEQa2+LidURF+DB2F9m5c2eWD4hJKw XL95d7NYbF7D4Z95WIuj7zbOSWeyTY3tG8cxfkUbMGKOuLn5FWZf5btvM85AfnquioS346p4a8t jcE0lxyYsJvvZx/u9SbtuknoGANV3MzeZlPGOReDaBf8SaPLVFsChor7BLiNlRDMdYEo4UAsX2N vG8rX7RFutGs1bX9ftNB04F+WSPeWHmpvkeKJB82MVs2Rn85UIaLR+2xKRDKY5NBG7YIbVxZMwf jbmc4IVSSiiqZH3chOGs1GGHkHWxPoX8jcWGowkRs1fAcYNHGusS9CiBzL8cnaL1ri/ilXxH1I9 BWhJiA5qDlhAYEFL0mlX2scVfePNuVzoZ6LieX1NV6ZtjddkvwGVtfL479aOoj9DXM40dJb6/Sb nJwGr85B/9LVe+0QGbbQdh/kTL8JG55i6ynXHGOILin78AgWMx981lgKTcNnnK6mXN72m2pHKtk QBynKSQBM7HWranVv16+wngHBFJ9FKCGd++IX2x/FmlC/aoz8Xh935PYSDpd9j+WYn72Gr3Ag3z t3L17dztJjx5lKLsLJ8QWL9W0TGvPKMMIuf6+eAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyKbBVa1r lvjN4QViJlGwPJ1GMBesO78OvHuuFzxTdbEKEZHDD/mqpRC9ahCoy1rFy+uOf62jzUDeg== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] [Technical Errata Reported] RFC3031 (5643) 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 Feb 2019 17:56:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0210_01D4CD33.57E2BB10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 3031 does define =E2=80=9CMPLS edge node=E2=80=9D, =E2=80=9CMPLS egress = node=E2=80=9D, and =E2=80=9CMPLS ingress node=E2=80=9D. Of course, it = also defines =E2=80=9CLSR=E2=80=9D. =20 As Andy says, the first mention of LER is in 3811 and it looks like the = terminology was produced to solidify the definitions in 3031. =20 I don=E2=80=99t think it is an =E2=80=9Cerror=E2=80=9D in 3031 that it = doesn=E2=80=99t define LER. Sure, it would be nice to have all the = definitions in one place, but adding stuff to documents isn=E2=80=99t = what Errata Reports are supposed to be for. =20 Adrian =20 =20 =20 From: mpls On Behalf Of Andrew G. Malis Sent: 25 February 2019 15:36 To: RFC Errata System Cc: mpls ; markzzzsmith@gmail.com; = arun@force10networks.com; Ross Callon ; = erosen@cisco.com Subject: Re: [mpls] [Technical Errata Reported] RFC3031 (5643) =20 The submitter does make a good point, LER should probably be defined in = the MPLS architecture. I just did a search and the earliest mention of = "Label Edge Router" that I could find is in RFC 3811.=20 =20 That said, I think I prefer the definition text from RFC 4221: An LER is an LSR placed at the edge of an MPLS domain, and it passes traffic into and out of the MPLS domain. An ingress LER is responsible for classifying data and assigning it to a suitable LSP or tunnel. =20 This classification is done using Forwarding Equivalence Classes (FECs) that define the common attributes of data (usually packets) that will be treated in the same way. Once data has been classified, it can be handed off to an LSP or tunnel through the Next Hop Label Forwarding Entry (NHLFE). Cheers, Andy =20 =20 On Sun, Feb 24, 2019 at 8:23 PM RFC Errata System = > wrote: The following errata report has been submitted for RFC3031, "Multiprotocol Label Switching Architecture". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5643 -------------------------------------- Type: Technical Reported by: Mark Smith > Section: Terminology Original Text ------------- Corrected Text -------------- label edge router - a router capable of accepting an unlabelled packet, and through MPLS processing, may MPLS encapsulate the packet by adding a label stack.=20 Notes ----- I am doing some MPLS review. The book I'm using said an LER was an (RFC3031) MPLS edge node. I = believed it was any router that could take unlabelled packets and label = them, regardless of where the router was within the MPLS domain. (In = other words, an MPLS router was not an LER if it would not MPLS label = unlabelled packets and forward them.) I decided to check RFC3031 for a definition, and discovered there isn't = a definition at all for "label edge router", or a match on any text that = matches "label edge" or "LER". RFC6178 clarifies LER processing of IPv4 packets, and the general = description of processing matches my understanding of what an LER is.=20 However, it doesn't formally define an "label edge router" either, and I = think an update to RFC3031 should be where "label edge router" is = formally defined. 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 =20 can log in to change the status and edit the report, if necessary.=20 -------------------------------------- RFC3031 (draft-ietf-mpls-arch-06) -------------------------------------- Title : Multiprotocol Label Switching Architecture Publication Date : January 2001 Author(s) : E. Rosen, A. Viswanathan, R. Callon Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG _______________________________________________ mpls mailing list mpls@ietf.org =20 https://www.ietf.org/mailman/listinfo/mpls ------=_NextPart_000_0210_01D4CD33.57E2BB10 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

3031 does define =E2=80=9CMPLS edge = node=E2=80=9D, =E2=80=9CMPLS egress node=E2=80=9D, and =E2=80=9CMPLS = ingress node=E2=80=9D. Of course, it also defines = =E2=80=9CLSR=E2=80=9D.

 

As Andy = says, the first mention of LER is in 3811 and it looks like the = terminology was produced to solidify the definitions in = 3031.

 

I = don=E2=80=99t think it is an =E2=80=9Cerror=E2=80=9D in 3031 that it = doesn=E2=80=99t define LER. Sure, it would be nice to have all the = definitions in one place, but adding stuff to documents isn=E2=80=99t = what Errata Reports are supposed to be for.

 

Adrian

 

 

 

From: mpls <mpls-bounces@ietf.org> On Behalf Of = Andrew G. Malis
Sent: 25 February 2019 15:36
To: = RFC Errata System <rfc-editor@rfc-editor.org>
Cc: mpls = <mpls@ietf.org>; markzzzsmith@gmail.com; arun@force10networks.com; = Ross Callon <rcallon@juniper.net>; = erosen@cisco.com
Subject: Re: [mpls] [Technical Errata = Reported] RFC3031 (5643)

 

The = submitter does make a good point, LER should probably be defined in = the MPLS architecture. I just did a search and the earliest mention of = "Label Edge Router" that I could find is in RFC = 3811. 

 

That said, I think I prefer the definition text from = RFC 4221:

=C2=A0=C2=A0 =
An LER is an LSR placed at the edge of an MPLS domain, and it =
passes
=C2=A0=C2=A0 traffic into and out of the MPLS =
domain.=C2=A0 An ingress LER is
=C2=A0=C2=A0 responsible for classifying data and =
assigning it to a suitable LSP
=C2=A0=C2=A0 or =
tunnel.
 
=C2=A0=C2=A0 This classification is done using =
Forwarding Equivalence Classes
=C2=A0=C2=A0 (FECs) that define the common =
attributes of data (usually packets)
=C2=A0=C2=A0 that will be treated in the same =
way.=C2=A0 Once data has been =
classified,
=C2=A0=C2=A0 it can be handed off to an LSP or =
tunnel through the Next Hop Label
 =C2=A0=C2=A0Forwarding Entry =
(NHLFE).

Cheers,

Andy

 

 

On = Sun, Feb 24, 2019 at 8:23 PM RFC Errata System <rfc-editor@rfc-editor.org&g= t; wrote:

The = following errata report has been submitted for = RFC3031,
"Multiprotocol Label Switching = Architecture".

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

---= -----------------------------------
Type: Technical
Reported by: = Mark Smith <markzzzsmith@gmail.com>

Section: = Terminology

Original = Text
-------------
<missing>

Corrected = Text
--------------
label edge router - a router capable of = accepting an unlabelled packet,
and through MPLS processing, may MPLS = encapsulate the packet by adding
 a label stack. =

Notes
-----
I am doing some MPLS review.

The book = I'm using said an LER was an (RFC3031) MPLS edge node. I believed it was = any router that could take unlabelled packets and label them, regardless = of where the router was within the MPLS domain. (In other words, an MPLS = router was not an LER if it would not MPLS label unlabelled packets and = forward them.)

I decided to check RFC3031 for a definition, and = discovered there isn't a definition at all for "label edge = router", or a match on any text that matches "label edge" = or "LER".

RFC6178 clarifies LER processing of IPv4 = packets, and the general description of processing matches my = understanding of what an LER is.

However, it doesn't formally = define an "label edge router" either, and I think an update to = RFC3031 should be where "label edge router" is formally = defined.

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. =

--------------------------------------
RFC3031 = (draft-ietf-mpls-arch-06)
--------------------------------------
Ti= tle               : = Multiprotocol Label Switching Architecture
Publication Date  =   : January 2001
Author(s)          =  : E. Rosen, A. Viswanathan, R. Callon
Category    =         : PROPOSED STANDARD
Source    =           : Multiprotocol Label = Switching
Area                = : Routing
Stream              : = IETF
Verifying Party     : = IESG

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

------=_NextPart_000_0210_01D4CD33.57E2BB10-- From nobody Mon Feb 25 10:41: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 6766912426A for ; Mon, 25 Feb 2019 10:41:24 -0800 (PST) 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=MUdY2SL0; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BB/5U+kT 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 ZKB5cWq-gU6V for ; Mon, 25 Feb 2019 10:41:21 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8D7130FD4 for ; Mon, 25 Feb 2019 10:41:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22121; q=dns/txt; s=iport; t=1551120080; x=1552329680; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5kRmhP7rSS418HhsWEP1GE+hyPzWguKHnW3bFQUJSdQ=; b=MUdY2SL0kljH1a4efcgp0mE5vlAnNicZtiquJdJ2PdgfBPMQYnsiqA7p TrgI/qYRa7hEug7L7e0fBxY117Y733dAINmDzuh78FpC0PNCoTBlqTWhf eqEodDScjZj7xQiRVrm8iJF5GFc1cFQVOnzsYd+BMxpsXMGZZWTmRSsPh A=; IronPort-PHdr: =?us-ascii?q?9a23=3A6UGK3x0k0jmjY0oAsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxGCt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8TgZdYBUER?= =?us-ascii?q?oMiMEYhQslVceOBEDTJ//xZCt8F8NHBxdo?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABzNXRc/4MNJK1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ0jUANndAQLJwqDfoNHA4RQixCCV4k?= =?us-ascii?q?tiQCFcYEkA1QLAQEYAQoJhEACF4N1IjQJDQEDAQECAQECbRwMhUoBAQEEAQE?= =?us-ascii?q?hHQEBLAsBDwIBCBEBAgEBASgDAgICHwYLFAMGCAIEAQ0FgyABgQ5MAxUBAgy?= =?us-ascii?q?gbgKKFHGBL4J4AQEFhH8NC4ILCIxIF4F/gREnH4JMgUGBFkcBAYIBDQmCVDG?= =?us-ascii?q?CJooOJoFfKYN9gX6FHYtbMwkCjyeDPRIHgXGFW4tHilOBEoVuixMCBAIEBQI?= =?us-ascii?q?NAQEFgUc4gVZwFRohKgGCQQmCEwwMC4NLhRSFP3KBKI1EAYEeAQE?= X-IronPort-AV: E=Sophos;i="5.58,412,1544486400"; d="scan'208,217";a="523982992" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Feb 2019 18:41:19 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x1PIfJ5u003788 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Feb 2019 18:41:19 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 25 Feb 2019 12:41:18 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 25 Feb 2019 12:41:18 -0600 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 25 Feb 2019 13:41:18 -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=5kRmhP7rSS418HhsWEP1GE+hyPzWguKHnW3bFQUJSdQ=; b=BB/5U+kTYktTr2s3Iy4Sjau8b+JI0yJNgz/tDKO2Hj2spUtOAbYSn7UHuSbBZXdz6GmoXZDn5bGEa9abWnHCrZSiXP8chNXzAVa+KPxrvTDDpJnlcx9hYETuECcLDI2RibP9fCGBmUVj7c+LS06tau1RKWkgDufetAf3McogNYg= Received: from BN8PR11MB3683.namprd11.prod.outlook.com (20.178.220.74) by BN8PR11MB3636.namprd11.prod.outlook.com (20.178.219.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Mon, 25 Feb 2019 18:41:16 +0000 Received: from BN8PR11MB3683.namprd11.prod.outlook.com ([fe80::d042:6a6e:589b:b242]) by BN8PR11MB3683.namprd11.prod.outlook.com ([fe80::d042:6a6e:589b:b242%6]) with mapi id 15.20.1643.019; Mon, 25 Feb 2019 18:41:16 +0000 From: "Acee Lindem (acee)" To: "adrian@olddog.co.uk" , "'Andrew G. Malis'" , "'RFC Errata System'" CC: "'Ross Callon'" , "'mpls'" , "erosen@cisco.com" , "markzzzsmith@gmail.com" , "arun@force10networks.com" Thread-Topic: [mpls] [Technical Errata Reported] RFC3031 (5643) Thread-Index: AQHUzKjE4ZLOvs3l9USPv59qnHzK5KXwpm0AgAAm74D//7jggA== Date: Mon, 25 Feb 2019 18:41:16 +0000 Message-ID: References: <20190225012311.C02BDB80458@rfc-editor.org> <020f01d4cd33$57e13470$07a39d50$@olddog.co.uk> In-Reply-To: <020f01d4cd33$57e13470$07a39d50$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com; x-originating-ip: [173.38.117.79] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cce2653e-90f3-4341-04c1-08d69b50d31b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BN8PR11MB3636; x-ms-traffictypediagnostic: BN8PR11MB3636: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCTjhQUjExTUIzNjM2OzIzOmJlaysvMXBsNE4wWnBlQTk4Q2hGcDB2bi9X?= =?utf-8?B?U1h1bzRlRFRuVE1rdHN5NHFVVWFNSnpUcDNWR0Exak5rNkxqb0VvYXUrRDFC?= =?utf-8?B?cHU5emFuK084NVZuRlY1a1hwS2dHajZjYmJ0TERTbC9JQXo1MXJSU1UvOFdK?= =?utf-8?B?YzBsMkFPNUZ1YzlCdURQaEhnT2JhaUFOS1N0Mm5YS3ZRYnJRdVI5aWZHaWxl?= =?utf-8?B?Mmh4blplbHZ0cGtjUHNMSUVoRlc5d3BJRkhXeUNPeG9VcHFkaVFXREdQTFB6?= =?utf-8?B?OHFXN3RDVjdGQ1NCdHhCZ0UvSjgzMlM1Mk1aOUdGNkRuVmVTU09OSkw3Z1lT?= =?utf-8?B?RHJnTmc4SmhSbUl1dVhMcmQ2RHNyZWxSWlN1SStmT0g1R1Y1NVEwU1J2d25T?= =?utf-8?B?MndjS1JTYUEvaW9EUkdaMW92Z2FoK2RxVGlZa3gvbGpaaG9nNVIwTDdrb0c5?= =?utf-8?B?SS9ZWFA5T0VKdXVZeWRZV3pROGQ0aFNVSW5NZ0NJajA0VUJ1ZXBveXlqL0Jr?= =?utf-8?B?cGFKeS9PWXRtaHF6dDViZzdTS04yektWMXZXdGZiWHFVQm5EcksxR2MyMzRt?= =?utf-8?B?MVlFSWRCYytJZnBDOGtNRldRS05vR0xheEFGd2ZWY04zTzdlN2J0N2FVU2lG?= =?utf-8?B?U09lQ0pWcFM0NTBWZ2dUUUViRmlBV2tXOG1DUm8rV1ljb3U2UXRIaWt1U05C?= =?utf-8?B?RDY3a3pRK3FpN2VNTlA0MUIydjZMeFBVamFRaFEzcmQ4RlR6SkR0SlZzKzZn?= =?utf-8?B?dm5iNHRxaGxTdnNOeUxoazJhUnRXaEZ4bHJlYXEyRlFhbzZwRUQ5R3YvY2Vi?= =?utf-8?B?Y1hoV1Y4OVBmeEw2ZFRRazQwdlkrbEZHcW1Sc2R4NEp3SE1SMmowdVlrTUQ1?= =?utf-8?B?dWt4eVNrb2V6dVplUXhtMU50VlFITVgycnc1TEh0RXpEczhUaEpqQmVLQ2wr?= =?utf-8?B?Y2hPOEJhTEJYbEZOek1GYWhtWHRFWk9IT210bnRCYVBwRG9pZXpXZHdMYVNZ?= =?utf-8?B?dXZZWE1hYktUeW12NGNIY2RsZ2NyWXdyanIwMWozaFNBRTlOT0t1TXFZcUtk?= =?utf-8?B?Mll0a2o4TWd3U2pLdXYvYkY5VmloK1ZUNXJJZ1JVY2FmUjJEVlpiTHVyWnN0?= =?utf-8?B?bVZ2V0s0SDhxQUdiTlU4dHRPWUEzeUIwWVFXNnN4TTFTVmg0alNoNDBIVXla?= =?utf-8?B?NEh1K1hpdUV2TFhHYS9ta1NlTTNCMmhvWGg0YkdNemNzWU5tYTVQQVZ6QmxR?= =?utf-8?B?WVMwb0drMXc0d2xrRlcraTVicFAvaE53bFY4WCthUk16b2JOWDJJNjd1QUR4?= =?utf-8?B?SkQwZEVtR3dxVFp0MVEvVnRHTFlBaXdYWmFNNkFRNW1QZW5ycTdCdkQvdVZw?= =?utf-8?B?M0pzZ1cvOWhWQ1AwMXdZNXBJZVhBQUpHdkk0NVYwWVpGRTQ3RHlCQzR2WDJ5?= =?utf-8?B?NXk2TWVPVVI0d3dnVGlUelpRV05WOXNxZlNSYXFheWNTK2gzZ3NUQXp3Y1E0?= =?utf-8?B?WHBqbUtMd0xpR2drMDBwU3l6Yk1SSFgxeng0QjJWT3A2cWVGUjJySlZVeGw2?= =?utf-8?B?bU9ZRWFjaVVubWFmV2xZdldSRmVkNUQ1YXA0dFcrc0pRSWtaMDN5WEltTFRV?= =?utf-8?B?Mmc2QjdYM0p1RTdKNkJLb0lwZ0dKZFpjblpJUHQzaDV4UnI2WEgyaUd0V3lS?= =?utf-8?B?djlQSm9PL0pEWkE4aHR6RWhsM3cvenVFOG1wbXVmeUlaUlFscTNjK2VQL3FQ?= =?utf-8?B?WWtGZzFTVEZBakxvM0l2RGlkTERLL2ZHaVVJc2N4V2ZlMXpWYU83U21nY1kx?= =?utf-8?B?RGxPK3NTcUl2OGU2Rit2Q0ltQ3hvOXRzejFRMFY3V3BiOXlEeVZ3K1IwRFdF?= =?utf-8?Q?mZ8K8SR/9BM=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 095972DF2F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(376002)(366004)(346002)(396003)(199004)(189003)(4326008)(606006)(83716004)(71200400001)(2906002)(66574012)(6506007)(8936002)(102836004)(26005)(82746002)(66066001)(25786009)(186003)(966005)(106356001)(105586002)(53546011)(71190400001)(7736002)(8676002)(81166006)(81156014)(68736007)(33656002)(14444005)(256004)(14454004)(316002)(97736004)(54896002)(6436002)(86362001)(6246003)(478600001)(110136005)(3846002)(476003)(486006)(2501003)(2616005)(5660300002)(36756003)(229853002)(76176011)(6486002)(6512007)(6306002)(236005)(99286004)(11346002)(446003)(53936002)(6116002)(54906003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3636; H:BN8PR11MB3683.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: sC2RvW5Vh+9NVJ8q+3G49GxnsHUpeVXIjy6oHKi6BR/B2ZNubdY/RisPl6aXGEgyftnGvIcJkhaCFQjWUb2c9IoqKwXo5c+06Rbr4sgAwKfL5csz5kC+yy7MyC6PIrZ98kuHT4X1AYxYspBi4Kp+kYwOCt9lhgNOs7X5zV3y3ZaAyy7aCUkIbgOj3I0PbUQgw7t4qTybz1lxX7soIX3itai8TwTioeF2rmNdxgZSI1jx+fq2g6pq1RAcjak6TnnztfGy/y4Yo9NAef1uYCyMmozLa5HakqIbG0fnxvBfACS5c0H91PqiSGFHeGYWMz+LfIoZJYM7uVEfuyQLKgR9FrVAHAYz7/MGAcuN3g9jnfFmdnp4b/SYd463G8LGu7S7ALqBQX7VA+RTzs8R2vhlhr6TLFoN86MeE13CmXabMtc= Content-Type: multipart/alternative; boundary="_000_E896293350A644DBB2D2F9AF55537826ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cce2653e-90f3-4341-04c1-08d69b50d31b X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2019 18:41:16.0235 (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: BN8PR11MB3636 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.22, xch-rcd-012.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [mpls] [Technical Errata Reported] RFC3031 (5643) 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 Feb 2019 18:41:24 -0000 --_000_E896293350A644DBB2D2F9AF55537826ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UHJlY2lzZWx5LCBJIHdhcyBnb2luZyB0byBzYXkgdGhlIHNhbWUgdGhpbmcgYnV0IEnigJltIHN1 cmUgQWRyaWFuIHNhaWQgaXQgYmV0dGVyLg0KQWNlZQ0KDQpGcm9tOiBtcGxzIDxtcGxzLWJvdW5j ZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBBZHJpYW4gRmFycmVsIDxhZHJpYW5Ab2xkZG9nLmNv LnVrPg0KT3JnYW5pemF0aW9uOiBPbGQgRG9nIENvbnN1bHRpbmcNClJlcGx5LVRvOiBBZHJpYW4g RmFycmVsIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPg0KRGF0ZTogTW9uZGF5LCBGZWJydWFyeSAyNSwg MjAxOSBhdCAxMjo1NiBQTQ0KVG86ICInQW5kcmV3IEcuIE1hbGlzJyIgPGFnbWFsaXNAZ21haWwu Y29tPiwgJ1JGQyBFcnJhdGEgU3lzdGVtJyA8cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZz4NCkNj OiBSb3NzIENhbGxvbiA8cmNhbGxvbkBqdW5pcGVyLm5ldD4sICdtcGxzJyA8bXBsc0BpZXRmLm9y Zz4sICJlcm9zZW5AY2lzY28uY29tIiA8ZXJvc2VuQGNpc2NvLmNvbT4sICJtYXJrenp6c21pdGhA Z21haWwuY29tIiA8bWFya3p6enNtaXRoQGdtYWlsLmNvbT4sICJhcnVuQGZvcmNlMTBuZXR3b3Jr cy5jb20iIDxhcnVuQGZvcmNlMTBuZXR3b3Jrcy5jb20+DQpTdWJqZWN0OiBSZTogW21wbHNdIFtU ZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkMzMDMxICg1NjQzKQ0KDQozMDMxIGRvZXMgZGVm aW5lIOKAnE1QTFMgZWRnZSBub2Rl4oCdLCDigJxNUExTIGVncmVzcyBub2Rl4oCdLCBhbmQg4oCc TVBMUyBpbmdyZXNzIG5vZGXigJ0uIE9mIGNvdXJzZSwgaXQgYWxzbyBkZWZpbmVzIOKAnExTUuKA nS4NCg0KQXMgQW5keSBzYXlzLCB0aGUgZmlyc3QgbWVudGlvbiBvZiBMRVIgaXMgaW4gMzgxMSBh bmQgaXQgbG9va3MgbGlrZSB0aGUgdGVybWlub2xvZ3kgd2FzIHByb2R1Y2VkIHRvIHNvbGlkaWZ5 IHRoZSBkZWZpbml0aW9ucyBpbiAzMDMxLg0KDQpJIGRvbuKAmXQgdGhpbmsgaXQgaXMgYW4g4oCc ZXJyb3LigJ0gaW4gMzAzMSB0aGF0IGl0IGRvZXNu4oCZdCBkZWZpbmUgTEVSLiBTdXJlLCBpdCB3 b3VsZCBiZSBuaWNlIHRvIGhhdmUgYWxsIHRoZSBkZWZpbml0aW9ucyBpbiBvbmUgcGxhY2UsIGJ1 dCBhZGRpbmcgc3R1ZmYgdG8gZG9jdW1lbnRzIGlzbuKAmXQgd2hhdCBFcnJhdGEgUmVwb3J0cyBh cmUgc3VwcG9zZWQgdG8gYmUgZm9yLg0KDQpBZHJpYW4NCg0KDQoNCkZyb206IG1wbHMgPG1wbHMt Ym91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEFuZHJldyBHLiBNYWxpcw0KU2VudDogMjUg RmVicnVhcnkgMjAxOSAxNTozNg0KVG86IFJGQyBFcnJhdGEgU3lzdGVtIDxyZmMtZWRpdG9yQHJm Yy1lZGl0b3Iub3JnPg0KQ2M6IG1wbHMgPG1wbHNAaWV0Zi5vcmc+OyBtYXJrenp6c21pdGhAZ21h aWwuY29tOyBhcnVuQGZvcmNlMTBuZXR3b3Jrcy5jb207IFJvc3MgQ2FsbG9uIDxyY2FsbG9uQGp1 bmlwZXIubmV0PjsgZXJvc2VuQGNpc2NvLmNvbQ0KU3ViamVjdDogUmU6IFttcGxzXSBbVGVjaG5p Y2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDMzAzMSAoNTY0MykNCg0KVGhlIHN1Ym1pdHRlciBkb2Vz IG1ha2UgYSBnb29kIHBvaW50LCBMRVIgc2hvdWxkIHByb2JhYmx5IGJlIGRlZmluZWQgaW4gdGhl IE1QTFMgYXJjaGl0ZWN0dXJlLiBJIGp1c3QgZGlkIGEgc2VhcmNoIGFuZCB0aGUgZWFybGllc3Qg bWVudGlvbiBvZiAiTGFiZWwgRWRnZSBSb3V0ZXIiIHRoYXQgSSBjb3VsZCBmaW5kIGlzIGluIFJG QyAzODExLg0KDQpUaGF0IHNhaWQsIEkgdGhpbmsgSSBwcmVmZXIgdGhlIGRlZmluaXRpb24gdGV4 dCBmcm9tIFJGQyA0MjIxOg0KDQogICBBbiBMRVIgaXMgYW4gTFNSIHBsYWNlZCBhdCB0aGUgZWRn ZSBvZiBhbiBNUExTIGRvbWFpbiwgYW5kIGl0IHBhc3Nlcw0KDQogICB0cmFmZmljIGludG8gYW5k IG91dCBvZiB0aGUgTVBMUyBkb21haW4uICBBbiBpbmdyZXNzIExFUiBpcw0KDQogICByZXNwb25z aWJsZSBmb3IgY2xhc3NpZnlpbmcgZGF0YSBhbmQgYXNzaWduaW5nIGl0IHRvIGEgc3VpdGFibGUg TFNQDQoNCiAgIG9yIHR1bm5lbC4NCg0KDQoNCiAgIFRoaXMgY2xhc3NpZmljYXRpb24gaXMgZG9u ZSB1c2luZyBGb3J3YXJkaW5nIEVxdWl2YWxlbmNlIENsYXNzZXMNCg0KICAgKEZFQ3MpIHRoYXQg ZGVmaW5lIHRoZSBjb21tb24gYXR0cmlidXRlcyBvZiBkYXRhICh1c3VhbGx5IHBhY2tldHMpDQoN CiAgIHRoYXQgd2lsbCBiZSB0cmVhdGVkIGluIHRoZSBzYW1lIHdheS4gIE9uY2UgZGF0YSBoYXMg YmVlbiBjbGFzc2lmaWVkLA0KDQogICBpdCBjYW4gYmUgaGFuZGVkIG9mZiB0byBhbiBMU1Agb3Ig dHVubmVsIHRocm91Z2ggdGhlIE5leHQgSG9wIExhYmVsDQoNCiAgIEZvcndhcmRpbmcgRW50cnkg KE5ITEZFKS4NCkNoZWVycywNCkFuZHkNCg0KDQpPbiBTdW4sIEZlYiAyNCwgMjAxOSBhdCA4OjIz IFBNIFJGQyBFcnJhdGEgU3lzdGVtIDxyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPG1haWx0bzpy ZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPj4gd3JvdGU6DQpUaGUgZm9sbG93aW5nIGVycmF0YSBy ZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVkIGZvciBSRkMzMDMxLA0KIk11bHRpcHJvdG9jb2wgTGFi ZWwgU3dpdGNoaW5nIEFyY2hpdGVjdHVyZSIuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0IGJlbG93IGFuZCBhdDoNCmh0 dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhL2VpZDU2NDMNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClR5cGU6IFRlY2huaWNhbA0KUmVwb3J0ZWQgYnk6IE1h cmsgU21pdGggPG1hcmt6enpzbWl0aEBnbWFpbC5jb208bWFpbHRvOm1hcmt6enpzbWl0aEBnbWFp bC5jb20+Pg0KDQpTZWN0aW9uOiBUZXJtaW5vbG9neQ0KDQpPcmlnaW5hbCBUZXh0DQotLS0tLS0t LS0tLS0tDQo8bWlzc2luZz4NCg0KQ29ycmVjdGVkIFRleHQNCi0tLS0tLS0tLS0tLS0tDQpsYWJl bCBlZGdlIHJvdXRlciAtIGEgcm91dGVyIGNhcGFibGUgb2YgYWNjZXB0aW5nIGFuIHVubGFiZWxs ZWQgcGFja2V0LA0KYW5kIHRocm91Z2ggTVBMUyBwcm9jZXNzaW5nLCBtYXkgTVBMUyBlbmNhcHN1 bGF0ZSB0aGUgcGFja2V0IGJ5IGFkZGluZw0KIGEgbGFiZWwgc3RhY2suDQoNCk5vdGVzDQotLS0t LQ0KSSBhbSBkb2luZyBzb21lIE1QTFMgcmV2aWV3Lg0KDQpUaGUgYm9vayBJJ20gdXNpbmcgc2Fp ZCBhbiBMRVIgd2FzIGFuIChSRkMzMDMxKSBNUExTIGVkZ2Ugbm9kZS4gSSBiZWxpZXZlZCBpdCB3 YXMgYW55IHJvdXRlciB0aGF0IGNvdWxkIHRha2UgdW5sYWJlbGxlZCBwYWNrZXRzIGFuZCBsYWJl bCB0aGVtLCByZWdhcmRsZXNzIG9mIHdoZXJlIHRoZSByb3V0ZXIgd2FzIHdpdGhpbiB0aGUgTVBM UyBkb21haW4uIChJbiBvdGhlciB3b3JkcywgYW4gTVBMUyByb3V0ZXIgd2FzIG5vdCBhbiBMRVIg aWYgaXQgd291bGQgbm90IE1QTFMgbGFiZWwgdW5sYWJlbGxlZCBwYWNrZXRzIGFuZCBmb3J3YXJk IHRoZW0uKQ0KDQpJIGRlY2lkZWQgdG8gY2hlY2sgUkZDMzAzMSBmb3IgYSBkZWZpbml0aW9uLCBh bmQgZGlzY292ZXJlZCB0aGVyZSBpc24ndCBhIGRlZmluaXRpb24gYXQgYWxsIGZvciAibGFiZWwg ZWRnZSByb3V0ZXIiLCBvciBhIG1hdGNoIG9uIGFueSB0ZXh0IHRoYXQgbWF0Y2hlcyAibGFiZWwg ZWRnZSIgb3IgIkxFUiIuDQoNClJGQzYxNzggY2xhcmlmaWVzIExFUiBwcm9jZXNzaW5nIG9mIElQ djQgcGFja2V0cywgYW5kIHRoZSBnZW5lcmFsIGRlc2NyaXB0aW9uIG9mIHByb2Nlc3NpbmcgbWF0 Y2hlcyBteSB1bmRlcnN0YW5kaW5nIG9mIHdoYXQgYW4gTEVSIGlzLg0KDQpIb3dldmVyLCBpdCBk b2Vzbid0IGZvcm1hbGx5IGRlZmluZSBhbiAibGFiZWwgZWRnZSByb3V0ZXIiIGVpdGhlciwgYW5k IEkgdGhpbmsgYW4gdXBkYXRlIHRvIFJGQzMwMzEgc2hvdWxkIGJlIHdoZXJlICJsYWJlbCBlZGdl IHJvdXRlciIgaXMgZm9ybWFsbHkgZGVmaW5lZC4NCg0KSW5zdHJ1Y3Rpb25zOg0KLS0tLS0tLS0t LS0tLQ0KVGhpcyBlcnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgIlJlcG9ydGVkIi4gSWYg bmVjZXNzYXJ5LCBwbGVhc2UNCnVzZSAiUmVwbHkgQWxsIiB0byBkaXNjdXNzIHdoZXRoZXIgaXQg c2hvdWxkIGJlIHZlcmlmaWVkIG9yDQpyZWplY3RlZC4gV2hlbiBhIGRlY2lzaW9uIGlzIHJlYWNo ZWQsIHRoZSB2ZXJpZnlpbmcgcGFydHkNCmNhbiBsb2cgaW4gdG8gY2hhbmdlIHRoZSBzdGF0dXMg YW5kIGVkaXQgdGhlIHJlcG9ydCwgaWYgbmVjZXNzYXJ5Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KUkZDMzAzMSAoZHJhZnQtaWV0Zi1tcGxzLWFyY2gtMDYpDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGl0bGUgICAgICAgICAgICAg ICA6IE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIEFyY2hpdGVjdHVyZQ0KUHVibGljYXRp b24gRGF0ZSAgICA6IEphbnVhcnkgMjAwMQ0KQXV0aG9yKHMpICAgICAgICAgICA6IEUuIFJvc2Vu LCBBLiBWaXN3YW5hdGhhbiwgUi4gQ2FsbG9uDQpDYXRlZ29yeSAgICAgICAgICAgIDogUFJPUE9T RUQgU1RBTkRBUkQNClNvdXJjZSAgICAgICAgICAgICAgOiBNdWx0aXByb3RvY29sIExhYmVsIFN3 aXRjaGluZw0KQXJlYSAgICAgICAgICAgICAgICA6IFJvdXRpbmcNClN0cmVhbSAgICAgICAgICAg ICAgOiBJRVRGDQpWZXJpZnlpbmcgUGFydHkgICAgIDogSUVTRw0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNA aWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMNCg== --_000_E896293350A644DBB2D2F9AF55537826ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UHJlY2lzZWx5LCBJIHdhcyBnb2luZyB0byBzYXkgdGhl IHNhbWUgdGhpbmcgYnV0IEnigJltIHN1cmUgQWRyaWFuIHNhaWQgaXQgYmV0dGVyLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWNlZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5tcGxzICZsdDtt cGxzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBBZHJpYW4gRmFycmVsICZsdDth ZHJpYW5Ab2xkZG9nLmNvLnVrJmd0Ozxicj4NCjxiPk9yZ2FuaXphdGlvbjogPC9iPk9sZCBEb2cg Q29uc3VsdGluZzxicj4NCjxiPlJlcGx5LVRvOiA8L2I+QWRyaWFuIEZhcnJlbCAmbHQ7YWRyaWFu QG9sZGRvZy5jby51ayZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBGZWJydWFyeSAyNSwg MjAxOSBhdCAxMjo1NiBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7J0FuZHJldyBHLiBNYWxpcycm cXVvdDsgJmx0O2FnbWFsaXNAZ21haWwuY29tJmd0OywgJ1JGQyBFcnJhdGEgU3lzdGVtJyAmbHQ7 cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZyZndDs8YnI+DQo8Yj5DYzogPC9iPlJvc3MgQ2FsbG9u ICZsdDtyY2FsbG9uQGp1bmlwZXIubmV0Jmd0OywgJ21wbHMnICZsdDttcGxzQGlldGYub3JnJmd0 OywgJnF1b3Q7ZXJvc2VuQGNpc2NvLmNvbSZxdW90OyAmbHQ7ZXJvc2VuQGNpc2NvLmNvbSZndDss ICZxdW90O21hcmt6enpzbWl0aEBnbWFpbC5jb20mcXVvdDsgJmx0O21hcmt6enpzbWl0aEBnbWFp bC5jb20mZ3Q7LCAmcXVvdDthcnVuQGZvcmNlMTBuZXR3b3Jrcy5jb20mcXVvdDsgJmx0O2FydW5A Zm9yY2UxMG5ldHdvcmtzLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFttcGxzXSBb VGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDMzAzMSAoNTY0Myk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4zMDMxIGRvZXMgZGVmaW5lIOKAnE1QTFMg ZWRnZSBub2Rl4oCdLCDigJxNUExTIGVncmVzcyBub2Rl4oCdLCBhbmQg4oCcTVBMUyBpbmdyZXNz IG5vZGXigJ0uIE9mIGNvdXJzZSwgaXQgYWxzbyBkZWZpbmVzIOKAnExTUuKAnS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5BcyBBbmR5IHNheXMsIHRoZSBmaXJzdCBtZW50aW9uIG9mIExFUiBpcyBpbiAzODEx IGFuZCBpdCBsb29rcyBsaWtlIHRoZSB0ZXJtaW5vbG9neSB3YXMgcHJvZHVjZWQgdG8gc29saWRp ZnkgdGhlIGRlZmluaXRpb25zIGluIDMwMzEuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSBkb27igJl0IHRo aW5rIGl0IGlzIGFuIOKAnGVycm9y4oCdIGluIDMwMzEgdGhhdCBpdCBkb2VzbuKAmXQgZGVmaW5l IExFUi4gU3VyZSwgaXQgd291bGQgYmUgbmljZSB0byBoYXZlIGFsbCB0aGUgZGVmaW5pdGlvbnMg aW4gb25lIHBsYWNlLCBidXQgYWRkaW5nIHN0dWZmIHRvIGRvY3VtZW50cyBpc27igJl0IHdoYXQg RXJyYXRhIFJlcG9ydHMgYXJlIHN1cHBvc2VkIHRvIGJlIGZvci48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5B ZHJpYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj5Gcm9tOjwv Yj4gbXBscyAmbHQ7bXBscy1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwv Yj5BbmRyZXcgRy4gTWFsaXM8YnI+DQo8Yj5TZW50OjwvYj4gMjUgRmVicnVhcnkgMjAxOSAxNToz Njxicj4NCjxiPlRvOjwvYj4gUkZDIEVycmF0YSBTeXN0ZW0gJmx0O3JmYy1lZGl0b3JAcmZjLWVk aXRvci5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBtcGxzICZsdDttcGxzQGlldGYub3JnJmd0Ozsg bWFya3p6enNtaXRoQGdtYWlsLmNvbTsgYXJ1bkBmb3JjZTEwbmV0d29ya3MuY29tOyBSb3NzIENh bGxvbiAmbHQ7cmNhbGxvbkBqdW5pcGVyLm5ldCZndDs7IGVyb3NlbkBjaXNjby5jb208YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFttcGxzXSBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZD MzAzMSAoNTY0Myk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIHN1Ym1pdHRlciZuYnNwO2Rv ZXMgbWFrZSBhIGdvb2QgcG9pbnQsIExFUiBzaG91bGQgcHJvYmFibHkgYmUgZGVmaW5lZCBpbiB0 aGUgTVBMUyBhcmNoaXRlY3R1cmUuIEkganVzdCBkaWQgYSBzZWFyY2ggYW5kIHRoZSBlYXJsaWVz dCBtZW50aW9uIG9mICZxdW90O0xhYmVsIEVkZ2UgUm91dGVyJnF1b3Q7IHRoYXQgSSBjb3VsZCBm aW5kIGlzIGluIFJGQyAzODExLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5UaGF0IHNhaWQsIEkgdGhpbmsgSSBwcmVmZXIgdGhlIGRlZmluaXRpb24gdGV4dCBm cm9tIFJGQyA0MjIxOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbjt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgQW4gTEVSIGlzIGFuIExTUiBwbGFjZWQgYXQgdGhlIGVkZ2Ug b2YgYW4gTVBMUyBkb21haW4sIGFuZCBpdCBwYXNzZXM8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IHRyYWZmaWMgaW50byBhbmQgb3V0IG9mIHRoZSBNUExTIGRvbWFpbi4mbmJz cDsgQW4gaW5ncmVzcyBMRVIgaXM8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IHJlc3BvbnNpYmxlIGZvciBjbGFzc2lmeWluZyBkYXRhIGFuZCBhc3NpZ25pbmcgaXQgdG8gYSBz dWl0YWJsZSBMU1A8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG9yIHR1bm5l bC48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBUaGlzIGNsYXNzaWZpY2F0aW9uIGlzIGRvbmUgdXNpbmcgRm9yd2FyZGlu ZyBFcXVpdmFsZW5jZSBDbGFzc2VzPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyAoRkVDcykgdGhhdCBkZWZpbmUgdGhlIGNvbW1vbiBhdHRyaWJ1dGVzIG9mIGRhdGEgKHVzdWFs bHkgcGFja2V0cyk8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRoYXQgd2ls bCBiZSB0cmVhdGVkIGluIHRoZSBzYW1lIHdheS4mbmJzcDsgT25jZSBkYXRhIGhhcyBiZWVuIGNs YXNzaWZpZWQsPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBpdCBjYW4gYmUg aGFuZGVkIG9mZiB0byBhbiBMU1Agb3IgdHVubmVsIHRocm91Z2ggdGhlIE5leHQgSG9wIExhYmVs PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiAmbmJzcDsmbmJzcDtGb3J3YXJkaW5nIEVudHJ5IChO SExGRSkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkFuZHk8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj5PbiBTdW4sIEZlYiAyNCwgMjAxOSBhdCA4OjIzIFBNIFJGQyBFcnJhdGEg U3lzdGVtICZsdDs8YSBocmVmPSJtYWlsdG86cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZyI+cmZj LWVkaXRvckByZmMtZWRpdG9yLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGUgZm9sbG93aW5n IGVycmF0YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVkIGZvciBSRkMzMDMxLDxicj4NCiZxdW90 O011bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIEFyY2hpdGVjdHVyZSZxdW90Oy48YnI+DQo8 YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCllvdSBtYXkg cmV2aWV3IHRoZSByZXBvcnQgYmVsb3cgYW5kIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cu cmZjLWVkaXRvci5vcmcvZXJyYXRhL2VpZDU2NDMiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3 LnJmYy1lZGl0b3Iub3JnL2VycmF0YS9laWQ1NjQzPC9hPjxicj4NCjxicj4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KVHlwZTogVGVjaG5pY2FsPGJyPg0KUmVw b3J0ZWQgYnk6IE1hcmsgU21pdGggJmx0OzxhIGhyZWY9Im1haWx0bzptYXJrenp6c21pdGhAZ21h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFya3p6enNtaXRoQGdtYWlsLmNvbTwvYT4mZ3Q7PGJy Pg0KPGJyPg0KU2VjdGlvbjogVGVybWlub2xvZ3k8YnI+DQo8YnI+DQpPcmlnaW5hbCBUZXh0PGJy Pg0KLS0tLS0tLS0tLS0tLTxicj4NCiZsdDttaXNzaW5nJmd0Ozxicj4NCjxicj4NCkNvcnJlY3Rl ZCBUZXh0PGJyPg0KLS0tLS0tLS0tLS0tLS08YnI+DQpsYWJlbCBlZGdlIHJvdXRlciAtIGEgcm91 dGVyIGNhcGFibGUgb2YgYWNjZXB0aW5nIGFuIHVubGFiZWxsZWQgcGFja2V0LDxicj4NCmFuZCB0 aHJvdWdoIE1QTFMgcHJvY2Vzc2luZywgbWF5IE1QTFMgZW5jYXBzdWxhdGUgdGhlIHBhY2tldCBi eSBhZGRpbmc8YnI+DQombmJzcDthIGxhYmVsIHN0YWNrLiA8YnI+DQo8YnI+DQpOb3Rlczxicj4N Ci0tLS0tPGJyPg0KSSBhbSBkb2luZyBzb21lIE1QTFMgcmV2aWV3Ljxicj4NCjxicj4NClRoZSBi b29rIEknbSB1c2luZyBzYWlkIGFuIExFUiB3YXMgYW4gKFJGQzMwMzEpIE1QTFMgZWRnZSBub2Rl LiBJIGJlbGlldmVkIGl0IHdhcyBhbnkgcm91dGVyIHRoYXQgY291bGQgdGFrZSB1bmxhYmVsbGVk IHBhY2tldHMgYW5kIGxhYmVsIHRoZW0sIHJlZ2FyZGxlc3Mgb2Ygd2hlcmUgdGhlIHJvdXRlciB3 YXMgd2l0aGluIHRoZSBNUExTIGRvbWFpbi4gKEluIG90aGVyIHdvcmRzLCBhbiBNUExTIHJvdXRl ciB3YXMgbm90IGFuIExFUiBpZiBpdCB3b3VsZA0KIG5vdCBNUExTIGxhYmVsIHVubGFiZWxsZWQg cGFja2V0cyBhbmQgZm9yd2FyZCB0aGVtLik8YnI+DQo8YnI+DQpJIGRlY2lkZWQgdG8gY2hlY2sg UkZDMzAzMSBmb3IgYSBkZWZpbml0aW9uLCBhbmQgZGlzY292ZXJlZCB0aGVyZSBpc24ndCBhIGRl ZmluaXRpb24gYXQgYWxsIGZvciAmcXVvdDtsYWJlbCBlZGdlIHJvdXRlciZxdW90Oywgb3IgYSBt YXRjaCBvbiBhbnkgdGV4dCB0aGF0IG1hdGNoZXMgJnF1b3Q7bGFiZWwgZWRnZSZxdW90OyBvciAm cXVvdDtMRVImcXVvdDsuPGJyPg0KPGJyPg0KUkZDNjE3OCBjbGFyaWZpZXMgTEVSIHByb2Nlc3Np bmcgb2YgSVB2NCBwYWNrZXRzLCBhbmQgdGhlIGdlbmVyYWwgZGVzY3JpcHRpb24gb2YgcHJvY2Vz c2luZyBtYXRjaGVzIG15IHVuZGVyc3RhbmRpbmcgb2Ygd2hhdCBhbiBMRVIgaXMuDQo8YnI+DQo8 YnI+DQpIb3dldmVyLCBpdCBkb2Vzbid0IGZvcm1hbGx5IGRlZmluZSBhbiAmcXVvdDtsYWJlbCBl ZGdlIHJvdXRlciZxdW90OyBlaXRoZXIsIGFuZCBJIHRoaW5rIGFuIHVwZGF0ZSB0byBSRkMzMDMx IHNob3VsZCBiZSB3aGVyZSAmcXVvdDtsYWJlbCBlZGdlIHJvdXRlciZxdW90OyBpcyBmb3JtYWxs eSBkZWZpbmVkLjxicj4NCjxicj4NCkluc3RydWN0aW9uczo8YnI+DQotLS0tLS0tLS0tLS0tPGJy Pg0KVGhpcyBlcnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgJnF1b3Q7UmVwb3J0ZWQmcXVv dDsuIElmIG5lY2Vzc2FyeSwgcGxlYXNlPGJyPg0KdXNlICZxdW90O1JlcGx5IEFsbCZxdW90OyB0 byBkaXNjdXNzIHdoZXRoZXIgaXQgc2hvdWxkIGJlIHZlcmlmaWVkIG9yPGJyPg0KcmVqZWN0ZWQu IFdoZW4gYSBkZWNpc2lvbiBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5aW5nIHBhcnR5Jm5ic3A7IDxi cj4NCmNhbiBsb2cgaW4gdG8gY2hhbmdlIHRoZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJlcG9ydCwg aWYgbmVjZXNzYXJ5LiA8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLTxicj4NClJGQzMwMzEgKGRyYWZ0LWlldGYtbXBscy1hcmNoLTA2KTxicj4NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KVGl0bGUmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBNdWx0aXByb3RvY29s IExhYmVsIFN3aXRjaGluZyBBcmNoaXRlY3R1cmU8YnI+DQpQdWJsaWNhdGlvbiBEYXRlJm5ic3A7 ICZuYnNwOyA6IEphbnVhcnkgMjAwMTxicj4NCkF1dGhvcihzKSZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBFLiBSb3NlbiwgQS4gVmlzd2FuYXRoYW4sIFIuIENhbGxv bjxicj4NCkNhdGVnb3J5Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg OiBQUk9QT1NFRCBTVEFOREFSRDxicj4NClNvdXJjZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nPGJy Pg0KQXJlYSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgOiBSb3V0aW5nPGJyPg0KU3RyZWFtJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDogSUVURjxicj4NClZlcmlmeWluZyBQYXJ0eSZuYnNwOyAmbmJz cDsgJm5ic3A7OiBJRVNHPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQptcGxzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8 L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_E896293350A644DBB2D2F9AF55537826ciscocom_-- From nobody Mon Feb 25 22:21:34 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 24C84130E82; Mon, 25 Feb 2019 22:21:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.92.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155116209314.10715.2145543680144926261.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2019 22:21:33 -0800 Archived-At: Subject: [mpls] The MPLS WG has placed draft-nainar-mpls-rfc8287-len-clarification 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: Tue, 26 Feb 2019 06:21:33 -0000 The MPLS WG has placed draft-nainar-mpls-rfc8287-len-clarification in state Candidate for WG Adoption (entered by Loa Andersson) The document is available at https://datatracker.ietf.org/doc/draft-nainar-mpls-rfc8287-len-clarification/ From nobody Mon Feb 25 23:08: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 3DDF7130E7C; Mon, 25 Feb 2019 23:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 RwPCAVDqSCCk; Mon, 25 Feb 2019 23:08:37 -0800 (PST) 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 1C5E8130E78; Mon, 25 Feb 2019 23:08:37 -0800 (PST) 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 90680180157E; Tue, 26 Feb 2019 08:08:34 +0100 (CET) From: Loa Andersson Cc: draft-nainar-mpls-rfc8287-len-clarification@ietf.org, "mpls-chairs@ietf.org" To: "mpls@ietf.org" Message-ID: <98cdd254-2bf8-4bac-ebbc-c8645ab8e0ea@pi.nu> Date: Tue, 26 Feb 2019 15:08:31 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] IPR poll on 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: Tue, 26 Feb 2019 07:08:38 -0000 Working Group, authors, We have started to prepare draft-nainar-mpls-rfc8287-len-clarification for working group adoption, prior to the wgap we need to do an IPR poll. This mail starts this IPR poll. Are you aware of any IPR that applies to draft-nainar-mpls-rfc8287-len-clarification? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There no IPR disclosures against draft-nainar-mpls-rfc8287-len- clarification. 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. /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 Feb 26 00:26:11 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 951C7130E91; Tue, 26 Feb 2019 00:26:09 -0800 (PST) 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, 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, 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 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 c4YAh51dWTzO; Tue, 26 Feb 2019 00:26:08 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69B02130E8C; Tue, 26 Feb 2019 00:26:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8126; q=dns/txt; s=iport; t=1551169567; x=1552379167; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uzsBfIV17H0SXnFHx4MF/29PhKnI/OkElNdoxE+LgTs=; b=i+94ugjCZ05CeeLN9oB8D2GqpqWuDO7BEMWp9YK6c0EoLY5bwNVWAllz L471mxjV/NDlvFjyEAzeTnY119kU6vBAhxObc14M1+nZmPoKatgp+0a3W uk+ilR6+7KiYl9aNC56juL9K0rADHZdu1s16XLBh6PeDHPuW6xN6D+cSs M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAACm93Rc/5NdJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwMBAQEBCwGBDXaBaicKg36oL4VxFIFnCwEBhGwCF4N5IjY?= =?us-ascii?q?HDQEDAQECAQECbSiFSwYjSAMGBQ4CAgEIPwMCAgIZFxQRAgQOBYMggQ9kqyG?= =?us-ascii?q?BL4o7BYxDF4FAP4ERJx+CTIROARECAR0HEYJzMYImAol7gkCDfocbjA4JApJ?= =?us-ascii?q?mEgeBcYVdi0mKBwmPb4JsAhEUgSgmCidlcXAVOyoBgkE+kB9BMY8fgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.58,414,1544486400"; d="scan'208,217";a="439699797" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2019 08:26:05 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x1Q8Q4xq001623 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Feb 2019 08:26:05 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 26 Feb 2019 03:26:04 -0500 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1395.000; Tue, 26 Feb 2019 03:26:04 -0500 From: "Carlos Pignataro (cpignata)" To: Loa Andersson CC: mpls , "draft-nainar-mpls-rfc8287-len-clarification@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: IPR poll on draft-nainar-mpls-rfc8287-len-clarification Thread-Index: AQHUzaIcsVx09DnBPUmXyV6SfrQVqaXyEkeA Date: Tue, 26 Feb 2019 08:26:03 +0000 Message-ID: References: <98cdd254-2bf8-4bac-ebbc-c8645ab8e0ea@pi.nu> In-Reply-To: <98cdd254-2bf8-4bac-ebbc-c8645ab8e0ea@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.102.3) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.66.245.228] Content-Type: multipart/alternative; boundary="_000_EBC0323DDFF74A53AEC403E014973B03ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.158, xch-rtp-018.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [mpls] IPR poll on 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: Tue, 26 Feb 2019 08:26:10 -0000 --_000_EBC0323DDFF74A53AEC403E014973B03ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9hLA0KDQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIG9uIHRoaXMgZG9jdW1lbnQuDQoNClRo YW5rcywNCg0K4oCUIENhcmxvcyBQaWduYXRhcm8NCg0KT24gRmViIDI2LCAyMDE5LCBhdCAzOjA4 IFBNLCBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4+IHdyb3RlOg0K DQpXb3JraW5nIEdyb3VwLCBhdXRob3JzLA0KDQpXZSBoYXZlIHN0YXJ0ZWQgdG8gcHJlcGFyZSBk cmFmdC1uYWluYXItbXBscy1yZmM4Mjg3LWxlbi1jbGFyaWZpY2F0aW9uDQpmb3Igd29ya2luZyBn cm91cCBhZG9wdGlvbiwgcHJpb3IgdG8gdGhlIHdnYXAgd2UgbmVlZCB0byBkbyBhbiBJUFIgcG9s bC4NCg0KVGhpcyBtYWlsIHN0YXJ0cyB0aGlzIElQUiBwb2xsLg0KDQpBcmUgeW91IGF3YXJlIG9m IGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LW5haW5hci1tcGxzLXJmYzgyODctbGVuLWNs YXJpZmljYXRpb24/DQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29t cGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzDQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBh bmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4NCg0KVGhlcmUgbm8gSVBSIGRpc2Nsb3N1cmVzIGFn YWluc3QgZHJhZnQtbmFpbmFyLW1wbHMtcmZjODI4Ny1sZW4tDQpjbGFyaWZpY2F0aW9uLg0KDQpJ ZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVh c2UgcmVzcG9uZCB0bw0KdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlv dSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50DQpJUFIuICpUaGUgcmVzcG9uc2UgbmVlZHMgdG8g YmUgc2VudCB0byB0aGUgTVBMUyBXRyBtYWlsaW5nIGxpc3QuKiBUaGUNCmRvY3VtZW50IHdpbGwg bm90IGFkdmFuY2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbg0K cmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IuDQoNCklmIHlvdSBhcmUg b24gdGhlIE1QTFMgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9y IG9yDQpjb250cmlidXRvciwgdGhlbiBwbGVhc2UgZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYg eW91IGFyZSBhd2FyZSBvZiBhbnkNCklQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2Vk IGluIGNvbmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy4NCg0KDQovTG9hDQptcGxzIHdnIGNvLWNo YWlyDQotLQ0KDQoNCkxvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDog bG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+DQpTZW5pb3IgTVBMUyBFeHBlcnQNCkJyb256ZSBE cmFnb24gQ29uc3VsdGluZyAgICAgICAgICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KDQo= --_000_EBC0323DDFF74A53AEC403E014973B03ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <76395363B555B344B232FEE39BFF8EF6@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkxvYSwNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgb24g dGhpcyBkb2N1bWVudC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAw KTsgY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7 IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7 IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3Jk OyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNl OyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0 LWRlY29yYXRpb246IG5vbmU7Ij4NClRoYW5rcyw8L2Rpdj4NCjxkaXYgc3R5bGU9ImNhcmV0LWNv bG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiPg0KPGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRl Y29yYXRpb246IG5vbmU7Ij4NCuKAlCBDYXJsb3MgUGlnbmF0YXJvPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBGZWIgMjYsIDIwMTksIGF0IDM6MDggUE0sIExv YSBBbmRlcnNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUiIGNsYXNzPSIiPmxvYUBw aS5udTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1u ZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPldvcmtpbmcgR3JvdXAsIGF1 dGhvcnMsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KV2UgaGF2ZSBzdGFydGVkIHRvIHBy ZXBhcmUgZHJhZnQtbmFpbmFyLW1wbHMtcmZjODI4Ny1sZW4tY2xhcmlmaWNhdGlvbjxiciBjbGFz cz0iIj4NCmZvciB3b3JraW5nIGdyb3VwIGFkb3B0aW9uLCBwcmlvciB0byB0aGUgd2dhcCB3ZSBu ZWVkIHRvIGRvIGFuIElQUiBwb2xsLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoaXMg bWFpbCBzdGFydHMgdGhpcyBJUFIgcG9sbC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpB cmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LW5haW5hci1tcGxz LXJmYzgyODctbGVuLWNsYXJpZmljYXRpb24/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K SWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVU RiBJUFIgcnVsZXM8YnIgY2xhc3M9IiI+DQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQg NTM3OCBmb3IgbW9yZSBkZXRhaWxzKS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGVy ZSBubyBJUFIgZGlzY2xvc3VyZXMgYWdhaW5zdCBkcmFmdC1uYWluYXItbXBscy1yZmM4Mjg3LWxl bi08YnIgY2xhc3M9IiI+DQpjbGFyaWZpY2F0aW9uLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCklmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9y IHBsZWFzZSByZXNwb25kIHRvPGJyIGNsYXNzPSIiPg0KdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9m IHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50PGJyIGNsYXNzPSIi Pg0KSVBSLiAqVGhlIHJlc3BvbnNlIG5lZWRzIHRvIGJlIHNlbnQgdG8gdGhlIE1QTFMgV0cgbWFp bGluZyBsaXN0LiogVGhlPGJyIGNsYXNzPSIiPg0KZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0 byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuPGJyIGNsYXNzPSIiPg0K cmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IuPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KSWYgeW91IGFyZSBvbiB0aGUgTVBMUyBXRyBlbWFpbCBsaXN0IGJ1dCBh cmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3I8YnIgY2xhc3M9IiI+DQpjb250cmlidXRvciwg dGhlbiBwbGVhc2UgZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2FyZSBvZiBh bnk8YnIgY2xhc3M9IiI+DQpJUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBj b25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KL0xvYTxiciBjbGFzcz0iIj4NCm1wbHMgd2cgY28tY2hhaXI8YnIgY2xh c3M9IiI+DQotLSA8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpM b2EgQW5kZXJzc29uICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Im1haWx0bzpsb2FA cGkubnUiIGNsYXNzPSIiPmVtYWlsOiBsb2FAcGkubnU8L2E+PGJyIGNsYXNzPSIiPg0KU2VuaW9y IE1QTFMgRXhwZXJ0PGJyIGNsYXNzPSIiPg0KQnJvbnplIERyYWdvbiBDb25zdWx0aW5nICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO3Bob25lOiAmIzQzOzQ2IDczOSA4MSAyMSA2NDxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_EBC0323DDFF74A53AEC403E014973B03ciscocom_-- From nobody Tue Feb 26 00:31: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 1DB42130E98; Tue, 26 Feb 2019 00:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 eFX5TyLbNatp; Tue, 26 Feb 2019 00:30:59 -0800 (PST) Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.2]) (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 9D334130E95; Tue, 26 Feb 2019 00:30:58 -0800 (PST) Received: from [46.226.52.103] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-a.eu-west-1.aws.symcld.net id 85/15-18573-049F47C5; Tue, 26 Feb 2019 08:30:56 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTURzHPbv3blfzxnFq+zUqchJCdpezoJU kFvSAiiLCIpS606ubbNN2r6j9U39YgZY9yRJHNWcPleUzzTRKU0zITEHCXGYZ5ISKXva0dnft 9d/nnO/nnPP7HX40oW5Wamk+X+Qdds6qU4aQy6OSUtmkL2JKXOGE1vh4rIs0TjvLCaNnsFdpH K68RiWRG93uL4qNZaWHldsUuymL3ZSdv5cyt/dVUjnFs/O/dx4nDqJHs4pQCE1iFwGu47VIWq jxKQV4fBUzCy8C55lSVREKppV4NdRXe5USR+BEqPNNByQCuxBUn3xASUE43gS1/R+RLG2Gmms jKpnj4ebZnsBhEi+Co32NAWZwKvT1txESq7ER3IdcAQ7GK6H6Y1GAEZ4DU701CokJrIHh8QsB BozB3faQkDkSJl5MU7JvgtGXl5C8HwXnnparZJ4PAxeKZ/a3wJl3t/010H6OhsZXqVIvgF8gK Pkh1wl4MRR7hyiZtdDzqIuSpW8MjH5tnZGs0O68N8Pz4EZls0qWPlPQ9L5QIXeWBj3l70lZWg BVx8ZIWeon4O0hr+oEii37pzuZl8DFW++UMsfC5UuTRFngx8Lg/vlx8iIiq9AKk8OSaRZtnMX KGuLiWIMhnjWsXMYuX6bn9rOcns9l83hBZA16Lk/QCwW2NGu63s6L9cg/ROk5d2Nb0PiVzA40 l1boIhnyqZiinm3KTi8wc4J5jyPXygsdaB5N64AZ+uTPwhx8Jp+fYbH6J/F3DHSoLoLplmJGy OFsgiVTjnoRS99xjTkJNWnPtvNaDdM65ZewJJlz7X+u+D3PA2i+NpxBQUFB6tAc3mGziP/nPq ShkS6cAemWUItd/POSz1+Ewl9E54QgFSFyfyPtQZTcsGbhzwJFcnTTMeOu6iFnVgK56ofvAK8 pSvg+1Rn5+lnG6e2jI3MHRz3CHO3t6JKWybiG7NcrPHdTepyTGzw2nbl0aXJahaqusJxRvinp Li5d24yP7AwNn4hpuny9xnu1ZOsNInHdh/iEHVGfEmOyUtc/P/HEHTK+L+JklWns3EMdKZg5w 2LCIXC/ACoCaT/KAwAA X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-8.tower-267.messagelabs.com!1551169850!2460993!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 18014 invoked from network); 26 Feb 2019 08:30:55 -0000 Received: from us-west-2b.mta.dlp.protect.symantec.com (HELO EUR02-VE1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-8.tower-267.messagelabs.com with AES256-SHA256 encrypted SMTP; 26 Feb 2019 08:30:55 -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=LFP4iNWupI0w6p8i7TjSHnNqax3gbk653vXufTHghy0=; b=MzJbqRElZce0D73O7eVjCXwl4318Y9PGrUvqivXN3D2m9ZMnxqGFHDADHREfthDVZfMbWrqs9s7YaQzdHMLrTs1SRfE8saamyqNSl7QiwrvCUzsBJJC7Ro+a4gqvoOsWXsf3ketfdQdnwPHQrPi9C6bLFeydp6jNMcFJ/ZI0PtE= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB4129.eurprd03.prod.outlook.com (52.135.147.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.18; Tue, 26 Feb 2019 08:30:48 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::cd69:f7a:ee65:6435]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::cd69:f7a:ee65:6435%5]) with mapi id 15.20.1643.019; Tue, 26 Feb 2019 08:30:48 +0000 From: Alexander Vainshtein To: Loa Andersson , "mpls@ietf.org" CC: "mpls-chairs@ietf.org" , "draft-nainar-mpls-rfc8287-len-clarification@ietf.org" Thread-Topic: [mpls] IPR poll on draft-nainar-mpls-rfc8287-len-clarification Thread-Index: AQHUzaIhWZN50sblok+LoZt2p5GYv6XxvvOQ Date: Tue, 26 Feb 2019 08:30:48 +0000 Message-ID: References: <98cdd254-2bf8-4bac-ebbc-c8645ab8e0ea@pi.nu> In-Reply-To: <98cdd254-2bf8-4bac-ebbc-c8645ab8e0ea@pi.nu> 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: 46c3e79a-f59c-451e-7600-08d69bc4b5ba 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:AM0PR03MB4129; x-ms-traffictypediagnostic: AM0PR03MB4129: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; AM0PR03MB4129; 23:NDP6idoO8IhjfH/0ghOO1BhQT5ekcRkVLjIJXsMHR?= =?us-ascii?Q?8cYLCJXd20Fu0iQ3DynQKWr/sBmMhunpAUdVqWYd5FEWa/yLUElFk2b2reUs?= =?us-ascii?Q?indSJ5ET14N+RQXUcQ86Pzomk26jQAG4Hcnks5SWegpiKv6wNBybz3XRL5xM?= =?us-ascii?Q?DIXcZnzTAWthll8zuo2OZMZD2kqgSD4g/y/W1ZsTLhlxk4i0kFva7RfG6Mc1?= =?us-ascii?Q?ig3Z+jngZtRkHzUTmHdEZSTrLOzPTMqqcv2rGlY2mvUphHTm2qlmv/rA9fKY?= =?us-ascii?Q?FM+bkgNtHVLPKGO8MXNUJuhEwdC934XG+yTqjmpgsSexiDidDAWsCHpDkufL?= =?us-ascii?Q?vSxFZkZFr04aUUL+XaOCuh7N/QEzxYPWZFkXiYuncuLUlLiB5VZPE+Gdz11h?= =?us-ascii?Q?kgTUvQRIu658sHR2g+ZShTns80gLoYI5Iu0AAAN/NtHys+5GaVqhcHCcaDTj?= =?us-ascii?Q?PJo+qJihwNO3MLjhNTa3JZQpIhnCk7n3EMwaukF2rh111peXhQHRa8LHQgXB?= =?us-ascii?Q?K2of9nYjGOnYmPts4sfUd9xno1SRzDirYX+8gkDPOz4o7f+MwaCPwQ/qRTZX?= =?us-ascii?Q?yYKfNJzpo0zFsG5HLS6u/nI33MYYjHYaqlB9YdKJDLv6TSYrv/xp/P/aBRNX?= =?us-ascii?Q?d9D16fkwYQJm8M9YEKFgCwq60whqgn/yPIkX3bEWqxxbOe19h1XVbEgZ5X/W?= =?us-ascii?Q?pG1KR4UYDq8392SH6EZbN1dbvmK+/Ho5hzHpz8RgKmA1TCEgwvyDTeMAC0dV?= =?us-ascii?Q?dilZAoGkd8UNdXWnnxnKTm0KGMIsUhCnrh7rSFOpRimy5VTTztE2PfTCHbDN?= =?us-ascii?Q?y9vj6qhJV+M/lj/aEEV6xU74/eRllA026TMqKq1V/IqLU/qryY1M1H0I0caq?= =?us-ascii?Q?Atpkv3zgw2pdF7P7fHTNGRLoecw9LH5fbPZLRVKdbqeawIYkFG0S4tElXxuc?= =?us-ascii?Q?cEqb50mONRJhg060VKq57JMMnqs5LGWivxoBhdY2a88DsI7O/2MmV3sexl3j?= =?us-ascii?Q?KhftzclaSx2FU0ELrhF39GUFexE85/zBNVjkIb0dYoSbDwea2y0wrk6SYqYB?= =?us-ascii?Q?cqVv/VR5INXwrOewtff1fc7Z8FhN3FH6xSca/0qLN7DS9W6mSGyTAPh3PRD4?= =?us-ascii?Q?SgiDz4eGZiRVMDiCvY44ycrV5Zic6HS1NBNhuHMq+7ro6jG8Y5nZNxJ6y+Dl?= =?us-ascii?Q?nOrRcFp4t0T1+/GiadirVdor/WmgTnQhclct9WS7dD2qbGZRWhijCJ3y3Cn9?= =?us-ascii?Q?//2iGkhWu0ZnVK7QY01ZsHCKDSI6x+N2b0BJhPHnHWOBwAL5FM1hhyApgzma?= =?us-ascii?Q?2bU+WrSd0ZvuMOxzwRkfmYBDZqJmc6DYq9GzxPaiJy/?= x-microsoft-antispam-prvs: x-forefront-prvs: 096029FF66 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(136003)(39860400002)(366004)(376002)(13464003)(189003)(199004)(71190400001)(105586002)(256004)(71200400001)(2906002)(106356001)(6246003)(76176011)(102836004)(99286004)(7696005)(9686003)(66066001)(33656002)(7736002)(54906003)(229853002)(6306002)(6436002)(53936002)(55016002)(8936002)(25786009)(68736007)(97736004)(81166006)(2501003)(486006)(305945005)(86362001)(446003)(3846002)(6116002)(6506007)(5660300002)(53546011)(478600001)(476003)(11346002)(8676002)(81156014)(72206003)(966005)(110136005)(4326008)(14454004)(52536013)(74316002)(186003)(316002)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB4129; H:AM0PR03MB3828.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: 17JB6OEUX155GGYuRLpsvf+YYS2gPc/g4uBTAIHleEQFxBzn8me9iZN59ni6Tso48MhGKwcMO0fKj20MWsqTdzbIi8rwO66GrL561Z7vYRSUvBaAVGThbNWUu0JfoiIY+90qzhIVjg628qiTGmiIaa48ebMxaRsvmv/n3nZxdaAKv2pX2t2lYl1swvQ+WSXObSpgg12zRdgYspH44O5IatnHC8JdrXpH06ufzZYdIH7rGiYLVfHT9Y+JVsI2YQD3UelWzPiiKoGFLNq3YNcZ8CQwUPLdUgSBt1AS5e2L7TitJzNSSko6Jnw0jS80kdKnSyLE1J/8EmIRD49c5b+LDXi/tL1569RA5TNA+8Yi9Oywz8htBrHVXWXr3uCBDM+5JN8FAdfppaYyFbl1xIFeBfZZOLJHGL+7W4gYfleSkC8= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 46c3e79a-f59c-451e-7600-08d69bc4b5ba X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2019 08:30:48.3014 (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: AM0PR03MB4129 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] IPR poll on 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: Tue, 26 Feb 2019 08:31:01 -0000 Loa, I am not aware of any IPR on this document. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: mpls On Behalf Of Loa Andersson Sent: Tuesday, February 26, 2019 9:09 AM To: mpls@ietf.org Cc: mpls-chairs@ietf.org; draft-nainar-mpls-rfc8287-len-clarification@ietf= .org Subject: [mpls] IPR poll on draft-nainar-mpls-rfc8287-len-clarification Working Group, authors, We have started to prepare draft-nainar-mpls-rfc8287-len-clarification for working group adoption, prior to the wgap we need to do an IPR poll. This mail starts this IPR poll. Are you aware of any IPR that applies to draft-nainar-mpls-rfc8287-len-cla= rification? If so, has this IPR been disclosed in compliance with IETF IPR rules (see = RFCs 3979, 4879, 3669 and 5378 for more details). There no IPR disclosures against draft-nainar-mpls-rfc8287-len- clarificat= ion. If you are listed as a document author or contributor please respond to th= is 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 w= ill 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 co= ntributor, then please explicitly respond only if you are aware of any IPR= that has not yet been disclosed in conformance with IETF rules. /Loa mpls wg co-chair --=20 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 __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ From nobody Tue Feb 26 02: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 AE6EE130EC0 for ; Tue, 26 Feb 2019 02:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 lKIIgRap1A-s for ; Tue, 26 Feb 2019 02:34:27 -0800 (PST) Received: from 10.mo177.mail-out.ovh.net (10.mo177.mail-out.ovh.net [46.105.73.133]) (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 66C65130EAA for ; Tue, 26 Feb 2019 02:34:26 -0800 (PST) Received: from player760.ha.ovh.net (unknown [10.109.159.62]) by mo177.mail-out.ovh.net (Postfix) with ESMTP id 5CCABE5BDE for ; Tue, 26 Feb 2019 11:34:24 +0100 (CET) Received: from upperside.fr (aaubervilliers-682-1-54-148.w90-88.abo.wanadoo.fr [90.88.217.148]) (Authenticated sender: michelg@upperside.fr) by player760.ha.ovh.net (Postfix) with ESMTPSA id EBF2731CCFC2 for ; Tue, 26 Feb 2019 10:34:23 +0000 (UTC) From: "Michel Gosse" To: Date: Tue, 26 Feb 2019 11:34:21 +0100 Message-ID: <001b01d4cdbe$d5e1c390$81a54ab0$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01D4CDC7.37A6A0C0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdTNvbSl0UjU6NNgTPWVPH3Pp7UqwQ== Content-Language: fr X-Ovh-Tracer-Id: 1598777867948839002 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedutddrudelgddukecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecu 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: Tue, 26 Feb 2019 10:34:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001C_01D4CDC7.37A6A0C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 21st Edition of the MPLS+SDN+NFV World Congress will be held 9/12 April 2019 in Paris. The European Advanced Networking Test Center (EANTC) will showcase a public multi-vendor interoperability test during the Congress. The achievements of the joint multi-vendor tests include: Ethernet VPNs, Segment Routing, Management, Microwave, Path Computation Element Protocol, NETCONF/YANG, NFV and Advanced Clock Synchronization. More information: https://www.uppersideconferences.com/mpls-sdn-nfv/index.html ------=_NextPart_000_001C_01D4CDC7.37A6A0C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 21st Edition of the = MPLS+SDN+NFV World Congress will be held 9/12 April 2019 in = Paris.

 

The European Advanced Networking Test Center (EANTC) will = showcase a public multi-vendor interoperability test during the = Congress.

The achievements of the joint multi-vendor tests include: = Ethernet VPNs, Segment Routing, Management, Microwave, Path = Computation Element Protocol, NETCONF/YANG, NFV and Advanced = Clock Synchronization.

More = information:

htt= ps://www.uppersideconferences.com/mpls-sdn-nfv/index.html<= /span>

 



 

------=_NextPart_000_001C_01D4CDC7.37A6A0C0-- From nobody Tue Feb 26 02:51:08 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 5C582130EB8 for ; Tue, 26 Feb 2019 02:51:07 -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, SPF_PASS=-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 1-xZ5uOtSch8 for ; Tue, 26 Feb 2019 02:51:04 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00095.outbound.protection.outlook.com [40.107.0.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F2C130E30 for ; Tue, 26 Feb 2019 02:51:04 -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=wP0bVfZRaapAB8U+kEeGvATTOQL+CUTDv6Bk5oFOWLM=; b=bgitfHJtWvTI6BVUiWIGubdLSSQAv8aalLEH5y6LKpCX3SCAw2j3ExzQ9rJ4bmNVDt+L4L9AJXh+EhHlPwPP7Gw1W93pkzmVEcxTCcOFW1Yp9blnYT5C5MIfjqI12QoGRKPNsGZVnmz7aoiYNRMK9FdFVhgqCXc1bo5+F41cibg= Received: from VI1PR07MB4768.eurprd07.prod.outlook.com (20.177.57.155) by VI1PR07MB5597.eurprd07.prod.outlook.com (20.178.11.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.14; Tue, 26 Feb 2019 10:51:02 +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.1665.012; Tue, 26 Feb 2019 10:51:02 +0000 From: tom petch To: "mpls@ietf.org" Thread-Topic: I-D Action: draft-ietf-mpls-base-yang-10.txt Thread-Index: AQHUzcEq4n703luJWkK87ai0GzbcPQ== Date: Tue, 26 Feb 2019 10:51:01 +0000 Message-ID: <04d101d4cdc0$e7a8c7c0$4001a8c0@gateway.2wire.net> References: <155103743287.10983.6512427262984211001@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0166.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9::34) 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: 835cb569-6d49-4a2f-2c6b-08d69bd84c59 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB5597; x-ms-traffictypediagnostic: VI1PR07MB5597: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-forefront-prvs: 096029FF66 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(346002)(376002)(39860400002)(366004)(136003)(396003)(37854004)(13464003)(189003)(199004)(4720700003)(6436002)(6916009)(6346003)(99286004)(97736004)(25786009)(9686003)(6512007)(6306002)(81156014)(81166006)(8676002)(316002)(53936002)(1730700003)(86152003)(50226002)(68736007)(5640700003)(1556002)(256004)(2351001)(106356001)(2906002)(61296003)(105586002)(6246003)(8936002)(44736005)(6486002)(71190400001)(71200400001)(14496001)(386003)(66574012)(229853002)(14454004)(478600001)(2501003)(305945005)(86362001)(6116002)(26005)(3846002)(44716002)(486006)(966005)(62236002)(186003)(81686011)(76176011)(81816011)(52116002)(66066001)(476003)(53546011)(446003)(84392002)(102836004)(7736002)(6506007)(5660300002)(74416001)(7726001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5597; 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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-microsoft-exchange-diagnostics: =?iso-8859-1?Q?1; VI1PR07MB5597; 23:x1CSen0+Xvk2bo+LWaWKrbJxXCmXv03OvQDxgpc?= =?iso-8859-1?Q?HfNcS+gEVM/B1IHdKL0toQpJJESSfcif/NJL4lUOFY+nJu0lrpHSDsNYh8?= =?iso-8859-1?Q?StAdzcWGvakjgKqqZqtpZ506KlG/u6es7/GnuaM8o2KhE21Vunz4CwDWiR?= =?iso-8859-1?Q?cPKgnngwg9r+PJeDZUmnJt9qEmI7zI+lw9JH5w2173ebKafMoOQnw3ffh/?= =?iso-8859-1?Q?UTu1Z4a16FHt0UMHuh8IFcmkW/vITIzBdgcxUzoVyhNqBIAf/j4R6JSX7H?= =?iso-8859-1?Q?ZN4+ny1yCSxq41I+Elph49HXCJBIOVKS8vbtkOds9bpxd84CF3QlqdAe4L?= =?iso-8859-1?Q?8txnQrn1groeRQcmzg2kon6cvBwIfH6ROJ9gqE8CEL5IBOcELQ9aMXgXh3?= =?iso-8859-1?Q?NxbiITfn6FXU0Qy5lxzs9pAwFOMGZUU4/qTwhLbXX9Ia64A5KxkMHQPozz?= =?iso-8859-1?Q?u2E4TE/v6NxSoHXStnhtZFnovXHZS7BwHQXOWeLduJB9vbQtxL8TkgFUuJ?= =?iso-8859-1?Q?LuhnVOo3kmVo8Zlm7bnv7Ac6Jq6WukDg+2nuhU9RAT/Y951S8h5Q90vRgS?= =?iso-8859-1?Q?I9t2un63FcmWdeaKY/6wP2LxMmsilAgz069slGoToqS6z30rkQPQ0YwkTc?= =?iso-8859-1?Q?J1gYgsGF5Zm1upswRyET+yYzi1UndNMnIL4WnwjoS07naTeFlttyF9eI1G?= =?iso-8859-1?Q?TjaoKp9lEVUcNjpyZ3++YBD4dNC59GSW4OnW+1j6wtRQCY2tCRFyiAdcz6?= =?iso-8859-1?Q?WmiqHQl4i0LWZROQUc6wZfWGxyUTxzl3hVc+52RCx02Bb90SnghyEybXGi?= =?iso-8859-1?Q?jbc1TUj+S3H5y/9a52+slreY5uTUlx37cpJ8ARN4yBxyoDi/J6cBJ/9K33?= =?iso-8859-1?Q?aGDtELuxb76GQ0q9BE3V67ncQdkgSVMM5S9Mu1t5vXiq6q1Tirjobpg+2F?= =?iso-8859-1?Q?INk0iVCBZ4/+RAuW+p9+MHCalbJjhq9hVXS7zGYodMohMYnuVhLD3kYFTg?= =?iso-8859-1?Q?u7pmzPgFagaMGSiMAiHSHftHjKSni4n8YzrjM1fm5W33Wxt6fuTVhwvk7p?= =?iso-8859-1?Q?ynuZ8inbs+pQ2jkk3XvfOEYypSh9HkKBgNZNVwR+wKPD3NDtHsmq652nwQ?= =?iso-8859-1?Q?j/4+7V65oivp0+3uGqdE4C4soOI/8yGQ9kj35Giq4bfiN7CHlhGyaLilDp?= =?iso-8859-1?Q?7ZG7jWrmV+E2PmQRWEiadGnF6IhYCT0PNnPhSY6waR0zEkOsmrj5Ko6u6/?= =?iso-8859-1?Q?ZuPT3Ylz6hW6msMdI7jnVEYTFXpAZuX+SA5B2s9nWeLMm9IjqqgZuH5olq?= =?iso-8859-1?Q?wJvB695jScPjU5Aij69AbyYDRQRYqywoZjcUxL6rCgZ6QO7qlRQ2ZqMd/m?= =?iso-8859-1?Q?1rK+3/67qvVxX2t6JVJdAuAYnl4BkkSDKnp7ApJTiVzsCLiQHeIgxgbp0l?= =?iso-8859-1?Q?9SzIb80tNJ3piVSC3ECtYXEuPmCnYQyi787jPfTWwVOr89YRU2ZSO4jDtz?= =?iso-8859-1?Q?cYiBrzK45WbMmwQ+zjTR+eXoKdCbXPezseowhGIfmu/Sq+pTG2bycFQe10?= =?iso-8859-1?Q?ChOMGrOxU2q6O5nttpZ6C63ZYDhMYXCNJBcWIV22JJ3J4XXVDDycu5wYvl?= =?iso-8859-1?Q?xoD4G/ea16VtlYB+gYSC1Ymawl8moCzL/oPZbIbBNF//bmxWzZ6CQJFOIL?= =?iso-8859-1?Q?S8OZC+kE/if3PssDa4qzYDaPNaRFW/2/Yx9/6t3F+qIrN7Yj65xkUQdS1+?= =?iso-8859-1?Q?ZWZ3aSxKwechkGlzVi+L/OwMINZCUtvQGdaaKhTcSairvi5FlkPq7K6+AS?= =?iso-8859-1?Q?a0f8wTv4AoMpkyB0UQ5+g0Xdc8Icw=3D=3D?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: OzolPn8BtrmrQ8kiBuVpM+H19gwE/641JBkUCuBXskZgv5/+tq8g+rpolWT5+9airuf8Fk5hDBNp4C4G3G5OUc5tuIGRqlcM5YJH4IGfZmYqfaR6QpfHSYc9L2Nwe3S1ShAnCMeVrRiJz1gtPFqvAjgb5yHkpcpx9JG5ECo9RklOe+8WM5D1iQEjgVKJVHFsb52L7zwRxJxe4++vcDLwKpBfv7+wKjP2GAYOC7l0A9Wd35NbFDY27D3onM48/X7Y10K1OqEbCAHAyKET1GiwnO5QL9E3ultf9NyBHVR7G5ExAiFDuGYpRT9nuOPgA5w34g+vx3xHukPOLW1f0n+iOKt/o0N0qAIynksGAPdJKW7ZVoX8SU/JXzXHhkKhXfy4H8Wvi+yT/OiAnVYJkxNG8ViJWAGPdWV+FVdBeu2F5yY= Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5AEAE2ED0E5E3340AFC8C0F484E69EA0@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 835cb569-6d49-4a2f-2c6b-08d69bd84c59 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2019 10:51:01.9630 (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: VI1PR07MB5597 Archived-At: Subject: Re: [mpls] I-D Action: draft-ietf-mpls-base-yang-10.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, 26 Feb 2019 10:51:07 -0000 I find the terminology in this I-D unfamiliar. It talks of enum impose-and-forward { enum pop-impose-and-forward { whereas, following RFC3031, I would expect push (and pop). I also puzzled by leaf enabled { type boolean; description " 'true' if mpls encapsulation is enabled on the interface. 'false' if mpls encapsulation is enabled on the interface."; I note a number of augments without any condition which means that they will be added to everything which may be appropriate for mpls-enabled but perhaps not for others. And then there is the complete and utter absence of reference statements in the description clauses which I think should have stopped adoption! In passing, RFC8340 says that it should be an Informative Reference and not a Normative one. Tom Petch ----- Original Message ----- From: Sent: Sunday, February 24, 2019 7:43 PM Subject: I-D Action: draft-ietf-mpls-base-yang-10.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 : A YANG Data Model for MPLS Base > Authors : Tarek Saad > Kamran Raza > Rakesh Gandhi > Xufeng Liu > Vishnu Pavan Beeram > Filename : draft-ietf-mpls-base-yang-10.txt > Pages : 19 > Date : 2019-02-24 > > Abstract: > This document contains a specification of the the MPLS base YANG > model. The MPLS base YANG model serves as a base framework for > configuring and managing an MPLS switching subsystem on an MPLS- > enabled router. It is expected that other MPLS YANG models (e.g. > MPLS LSP Static, LDP or RSVP-TE YANG models) will augment the MPLS > base YANG model. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-base-yang/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-mpls-base-yang-10 > https://datatracker.ietf.org/doc/html/draft-ietf-mpls-base-yang-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-base-yang-10 > > > 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 Feb 26 03:20: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 73871130E0A; Tue, 26 Feb 2019 03:20:36 -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 gDXPpZ_rjMvn; Tue, 26 Feb 2019 03:20:32 -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 40751128D52; Tue, 26 Feb 2019 03:20:32 -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 x1QBK4sg024355; Tue, 26 Feb 2019 11:20:29 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A7CA72203D; Tue, 26 Feb 2019 11:20:29 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 911FB2203B; Tue, 26 Feb 2019 11:20:29 +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 x1QBKSoY008196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Feb 2019 11:20:29 GMT Reply-To: From: "Adrian Farrel" To: "'Loa Andersson'" , Cc: , Date: Tue, 26 Feb 2019 11:20:26 -0000 Organization: Old Dog Consulting Message-ID: <033901d4cdc5$4640f2e0$d2c2d8a0$@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: AdTNxUJnQ9WDFgDvRYi52BMJf0SHhw== 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-24456.006 X-TM-AS-Result: No--14.111-10.0-31-10 X-imss-scan-details: No--14.111-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24456.006 X-TMASE-Result: 10--14.110800-10.000000 X-TMASE-MatchedRID: mW99dfI1akbrVTsiFsFXUu0yyL51qL/Rbv16+gil4jca/zWbQz3vDsRR ZcdK8iLVPoy8Pn2QUB4lStg77z5P8LmvMSppeWbNiUPZPmKZOQk0AKed0u9fB1S+oHmj8upzZFT v8fPT86qdc5dM1EteS4aVT2uqSTCKC1tmyPg2GOwOrlBkQa9qFr4kZYg1dp8s4fGZffm2qCbIU7 MLOn2QZr6tLBAJJgxMcoxNRlsX7B4WiEoVBSOGHWA/V00XWjDtnophrTcsI7YutoY2UtFqGIQbd XsAoVM1SUkludY5bcKqEjHR8FX3BS3F56OiNwp/AP2Bflpd3h+3Tv9y50YCe7t4BAaULwAVN8RG TfW9Fj3DgGiSi1hwZzaa3EyGqiXD350iwCDSh6bzh2yKdnl7WAuK1hIitSIHpcn28zKwP8I5dQU r4gk2wsKSxWoRVwxk+MOUD1zmrJ3DTqNelQn9chzwnpmtY/+rfS0Ip2eEHny+qryzYw2E8Avgps XypsAMDMq3z/Y/gtXfd+P6wwCt84RtqopBKUBlDyT9JHN70wgCi4arQzHkFgcO7yGdwd0upsXP5 8vYLfkCLDuO5cBkxQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [mpls] Pipelining the inevitable adoption poll on 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: Tue, 26 Feb 2019 11:20:36 -0000 Hi, Since Loa is polling for IPR, I suspect an adoption poll is likely to follow. I know this document arises from confusion during interop, and I have some sympathy with people who find RFCs hard to parse. I also understand that the AD rejected fixing this through an Errata Report, and so the only option is to publish an RFC (the motivation here appears to be that consensus is needed for the resolution). IMHO, 8029 is clear on how to set the length of a TLV or sub-TLV. The sub-TLV length includes all of the fields of the sub-TLV, but not any trailing padding. The TLV length includes all of the sub-TLV padding. Thus, the only issue I can see here was that there was confusion about whether fields marked as "Reserved" formed part of the sub-TLVs. The only reason they would be, would be to allow for future extensions, otherwise they would just be padding. Clearly (according to this document) they were intended to be part of the sub-TLVs (for extensions). That is inconsistent with how 8029 is written, but since 8287 uses "Reserved" not "MBZ" it is acceptable if that is really want people want to achieve (i.e., that is the consensus decision that is needed). Doesn't that mean that the *only* text needed is to say... "Fields marked 'Reserved' in sub-TLVs defined in RFC 8287 are an integral part of the sub-TLVs and MUST be accounted in computation of the length of the sub-TLVs."? The current draft seems like a lot of text to make that clarification. Thanks, Adrian -----Original Message----- From: mpls On Behalf Of Loa Andersson Sent: 26 February 2019 07:09 To: mpls@ietf.org Cc: mpls-chairs@ietf.org; draft-nainar-mpls-rfc8287-len-clarification@ietf.org Subject: [mpls] IPR poll on draft-nainar-mpls-rfc8287-len-clarification Working Group, authors, We have started to prepare draft-nainar-mpls-rfc8287-len-clarification for working group adoption, prior to the wgap we need to do an IPR poll. This mail starts this IPR poll. Are you aware of any IPR that applies to draft-nainar-mpls-rfc8287-len-clarification? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There no IPR disclosures against draft-nainar-mpls-rfc8287-len- clarification. 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. /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 From nobody Tue Feb 26 03:55: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 CFB23130EC1; Tue, 26 Feb 2019 03:55:13 -0800 (PST) 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 to4iNFWCgW8b; Tue, 26 Feb 2019 03:55:10 -0800 (PST) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.115]) (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 C03EC126C01; Tue, 26 Feb 2019 03:55:09 -0800 (PST) Received: from [85.158.142.193] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-4.bemta.az-b.eu-central-1.aws.symcld.net id 43/D9-03001-B19257C5; Tue, 26 Feb 2019 11:55:07 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTaUwTQRTHmd3tdjGsjK3Ks0GNNR6gW6lXirf Gg5AYTfxgYmh0CyttLEvttrFqVAweETTeiggpEKqCR6TiETQKKBGqqaISbxFRo2jwIvFGu2zx +DL5zfu//zuSGYbUdNA6RvC4BKfI2/V0D2rsoGlmThfnTknIyppk+rL1Hmm611JHmToLC0jTi dsB2vTAV6aapkoqLf1KJB05VYaS8vdvoueTi1Q20ZLpWaKyVm/Zo3b4SpCnKhBQZ6GO7SgH9W AoXELC6Wcb1PJFg3cSkJ+3l1QujxHszq6hc1AkQ+PJ4D/6uIt741GQG9zX5SBxC4LSqpNIFrR 4GXxtbkJKkh28e3LDhtHw5eFhQmYKD4Hj34+FmGFYbIYfbfPlsAZPgKuNDaTMkXgiFNUojHBf +Bw41mUlcQw8eO7tYsAYSi/cIBXuA69bO1UKD4K8JwVqhfvDLW8uUngutG+5i+S2gAdD5SuzP D7gVgRNZU1hbzxc++APe3VQ31inUpIeRcOliuxwYzvktR8MN46FM76zaiUpSENwdwNStkmF+o JPlLKBBZpfFIenGADl21ooxXCThM2Nu9Q7UHz+P9spLELB+/0qmVncCxoOPKeU+EgoOv+RVng EHCp+Q3bz9epW4t94EVKXo0SL05ZudWXwNjtnTEjgjMYx3FjOmDjewK/iLAbBzaUKosvJh1QD v0IySCszUu1pBlFw+VHo1aUtp66cQ+82p9eifgyh78OOGepO0fS0ZKattPKSdbHTbRekWhTLM Hpgy4eFtF5OIV3wLLXZQ0+3WwYmSt+bHSrLrOTgMyRbuiIFUCJTXdJSSDKVzS9DZ5V8aigxUx R0Mew32YBlg9Ut/inX/Rluof46LYsiIiI0UQ7BmWFz/a+3oRgG6bXsHLlKlE10/enaFhqICA1 0+bUkD+Ti/0q6LLTxxaO1nff31Wgjjjylg+vO/dyLJ/m/v12z4/q1SiZ44MZ77ZyRKW1xh4kL a4noqTmra+/MmO7bFfupYeG7cetyCL8nFb4Nq2SEqzO9s+u9yaN9vmRHh/uj+Xjh+khN9sCdd VHDp3DeeeY7NSOYBehidO7TxqKp8Y5Z1op27td5x2Q9JVl5YzzplPjfGeNNlAcEAAA= X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-10.tower-238.messagelabs.com!1551182103!1895924!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 8065 invoked from network); 26 Feb 2019 11:55:05 -0000 Received: from us-west-2b.mta.dlp.protect.symantec.com (HELO EUR04-VI1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-10.tower-238.messagelabs.com with AES256-SHA256 encrypted SMTP; 26 Feb 2019 11:55:05 -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=7VS765X9TZzcQfV7vWjOdV3SO0AVQT2mnifx9e2FrTw=; b=FTODW78llzFQ20gaQbVNihbGsDt3mmN7dF7Vp6iaOEt43e58ZkEuCtuJ6tvBdC/GHhGjOX/3lmrg7xq9KsgUGtZChaJKf4d/Lpyg8pUdQN52tWU6qJtHtCFUfZ7DQYEM6fcuqNT6HzceXpPXeb5YnvGPVWFQZihmEhdV7hfttOo= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB3668.eurprd03.prod.outlook.com (52.134.81.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.20; Tue, 26 Feb 2019 11:55:01 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::cd69:f7a:ee65:6435]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::cd69:f7a:ee65:6435%5]) with mapi id 15.20.1643.019; Tue, 26 Feb 2019 11:55:01 +0000 From: Alexander Vainshtein To: "adrian@olddog.co.uk" CC: "mpls-chairs@ietf.org" , "draft-nainar-mpls-rfc8287-len-clarification@ietf.org" , 'Loa Andersson' , "mpls@ietf.org" Thread-Topic: [mpls] Pipelining the inevitable adoption poll on draft-nainar-mpls-rfc8287-len-clarification Thread-Index: AdTNxUJnQ9WDFgDvRYi52BMJf0SHhwAAFUPw Date: Tue, 26 Feb 2019 11:55:00 +0000 Message-ID: References: <033901d4cdc5$4640f2e0$d2c2d8a0$@olddog.co.uk> In-Reply-To: <033901d4cdc5$4640f2e0$d2c2d8a0$@olddog.co.uk> 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: e967948b-09d9-4e21-518f-08d69be13cec 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:AM0PR03MB3668; x-ms-traffictypediagnostic: AM0PR03MB3668: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; AM0PR03MB3668; 23:vwOkArT09ZQ42FVzw/9zA1OVCgeHMxxyLVkUpGWfI?= =?us-ascii?Q?Os8LI3lTx5gMi9peWJwEkqVJWp1GXuCRR9ldo76bvBX5k8zE5IIwWYKjEXOd?= =?us-ascii?Q?HWX/FY8G+NRd55W9wJR7w5iztoeq7SfiPN0i9WuOr+UrFZ9NAbzuFkc4ICt2?= =?us-ascii?Q?jN5Q1cTy+/UGl6UgyzElEPcYMtH+k84FN7RQT/+NK/rXOyXKvT41a0JHGkAg?= =?us-ascii?Q?1Zvtu0rQYXLgt037nodlwQWSF7ia1dC88Rl68xwtKgmqV2rVb8C9MkirvxGT?= =?us-ascii?Q?SqUP1sOHxeVOnMOc0CVE5PRDG+jB72pqjiQrFFW8TRnKh+WxPHlOLQOBKCFH?= =?us-ascii?Q?WCwkuJMvreNJrdUuBq+2yY1LKS9jZv8X+5scUddIl+38sS2nEfBlCF5Y1YZN?= =?us-ascii?Q?bRdMwzslMiKgPCBZbZQzIcDjUv1L8/3f49ZaE5Djp2aGvJjW9ErfBSMgU0ni?= =?us-ascii?Q?27dnr5DJWa2fUmr1C14sRgNAllptDihWEn3c+hTYiBr6fPhp6cHv5atJ4fOa?= =?us-ascii?Q?FBoXNuE4SbbK+zd46p1r4igail4N/aDnA6TJj7dYqGinz5/UYK/eNzjd3kYt?= =?us-ascii?Q?RmHIpC4iyffScBKEbQeKwSR7nd7Kh+AjJbl4SlUdkA+F1S8bb91iLkNZDzRP?= =?us-ascii?Q?eXWZuAu7XOFGpP19gtqW2vS/HxGARupKWINZHMQT4tanYJ34e8YaW2AviBmh?= =?us-ascii?Q?MN2IUsd/wfKr18cDj52++Gf2sRLXyJQohf0HbjTfCZXDcK6T817LQ7n+0xQh?= =?us-ascii?Q?JRi2pI82oLG8kIpcKPI3TO+VlMlP+pxhlInzjKs62bDrLasUr7gpG2ASbeXf?= =?us-ascii?Q?DHzxqRagJ/Ley4me6kfU56R2l8xVYqchAbr8RqV7hJZw/2tv8PDsqmNfWSvR?= =?us-ascii?Q?zoBTf0pG+HvlZ6h2Wf+EJ+/JM3ZBj9IIcMi46FweK5rF/vCIOTBcGLjtxGoe?= =?us-ascii?Q?uUIVy3sujIPBjCqthZ19sCCaP1UYiNa188SUH6IWiM73kBt/ZeTk3HV7uQ1N?= =?us-ascii?Q?4kmfFlpPW80x+XyBy8IIiBdEKPgPSSzceSArzeD1haEQJH+pgoFktti9LOit?= =?us-ascii?Q?zAfeHrSc1MN77lMaixG/oHpV52/fz0UHpYoaUzbHU0PaRIpZRPgTDcVl8XXw?= =?us-ascii?Q?HzDTzEXgF5BZr2Os+E8O4VgvZbjryXpeZthsepEohnZuHZHOZIPuOxKYruZ6?= =?us-ascii?Q?qD0QNTIu/neRa+G7RQSl4Vj3U7kaPerdYtJVEfVDZUbJir/Xa9AWVLa+pTzh?= =?us-ascii?Q?VP/Rb9VkMLyYcSysziqr05gDvS3JG6+0TFiKZ1vNU7PevLT2C7qM/pfzvGfG?= =?us-ascii?Q?3UFhN3q9CTMFsoMMbMtI2aWAn190t2Vi4C0ycPy7SY4LwWKS1OHltvtp9iRR?= =?us-ascii?Q?OzkSOK/KdWSGwz1ZfOeQAf3X28NmXt4hnUyRVe3apjTy22YhjyO95LRm+vy7?= =?us-ascii?Q?374fclSJ1oPR5MMsMb5hCljMoCvW4rNzpRa1FIkjZt9gVWA11D2cJPd8QynX?= =?us-ascii?Q?nHgovPGZxb/LtEqz0x5tHjCvTivu332rMM=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 096029FF66 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(396003)(376002)(346002)(39860400002)(13464003)(51444003)(199004)(189003)(486006)(53936002)(478600001)(72206003)(966005)(5660300002)(6436002)(2906002)(33656002)(6116002)(5640700003)(790700001)(3846002)(54896002)(6306002)(55016002)(229853002)(9686003)(14454004)(6916009)(236005)(25786009)(81166006)(7736002)(8676002)(1730700003)(66066001)(81156014)(11346002)(54906003)(476003)(74316002)(4326008)(2351001)(97736004)(106356001)(186003)(105586002)(316002)(256004)(14444005)(71190400001)(606006)(6246003)(26005)(2501003)(52536013)(68736007)(71200400001)(8936002)(76176011)(446003)(7696005)(99286004)(102836004)(86362001)(53546011)(6346003)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB3668; 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: 4RXCLtIjFFcA7NfL8JIbBfT6YzuJTe4g/c2hEQLXxNB1QQsmD6658EwJxI5Sv9l4oa1GXYcQDWUmOXEQt9PX2S/91z5WNyTmJl3oetDnsUlT+Vu+YfhFwRzKGt+U/8Q+ZOubNGR/sjIkle3beh/ge/n7cSKedFVOUQMdUJhQt5x9beT/M8pi3TNd6iWcSMb2+UAYIg/GNH6374ynWEptRYXKZ5LlEN3bwVeT8eRGj7K4tb27pyceZL6JVcCoIiXE8H8T1baTyaDqUS+6mbucQg+tcisj21sjVPDuQ99qx2AMdu2JB96cYKBcSbOmWev/+HBrMZCjSEt85rs3mLF2tsXSAQixUhr1gJ56Y1G9F4nf+n/oe69mTS9r8QRSTpJdAymS6ra1j5fZAf/GSEirxJ9KX6lNNeEq3GnpPrFXtP0= Content-Type: multipart/alternative; boundary="_000_AM0PR03MB3828A9DDF9FCBEECADFCE4359D7B0AM0PR03MB3828eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: e967948b-09d9-4e21-518f-08d69be13cec X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2019 11:55:00.9979 (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: AM0PR03MB3668 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] Pipelining the inevitable adoption poll on 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: Tue, 26 Feb 2019 11:55:14 -0000 --_000_AM0PR03MB3828A9DDF9FCBEECADFCE4359D7B0AM0PR03MB3828eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adrian, Just to make it clear, I have filed the erratum on RFC 8287 (which, I bel= ieve is the singular form while errata is plural) that has been rejected b= y Deborah because "This change requires an update to the RFC, requires con= sensus". I agree that we could make the draft somewhat shorter - but not by much: = the part that looks too long to you takes roughly 2 pages out of 5.5. The added value is that the current version means that the implementer doe= s not have to do any length calculations (that always carry with them the = risk of miscalculations): everything is spelled out in the same way as it = is in RFC 8029. I also think that when the "reserved" field is explicitly defined as follo= wing: Reserved The Reserved field MUST be set to 0 when sent and MUST be ignored on receipt. it is somewhat different to distinguish it from a "true" MBZ field: What's= in a name? And I do not think that this field has been intended for the future sub-TL= Vs since it itself is part of a sub-TLV. The bottom line: I think that the draft is ready for adoption by the WG. I= f the WG, following adoption, requests to make it shorter, we can do that.= Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: mpls On Behalf Of Adrian Farrel Sent: Tuesday, February 26, 2019 1:20 PM To: 'Loa Andersson' ; mpls@ietf.org Cc: mpls-chairs@ietf.org; draft-nainar-mpls-rfc8287-len-clarification@ietf= .org Subject: [mpls] Pipelining the inevitable adoption poll on draft-nainar-mp= ls-rfc8287-len-clarification Hi, Since Loa is polling for IPR, I suspect an adoption poll is likely to foll= ow. I know this document arises from confusion during interop, and I have some= sympathy with people who find RFCs hard to parse. I also understand that = the AD rejected fixing this through an Errata Report, and so the only opti= on is to publish an RFC (the motivation here appears to be that=20consensu= s is needed for the resolution). IMHO, 8029 is clear on how to set the length of a TLV or sub-TLV. The sub-= TLV length includes all of the fields of the sub-TLV, but not any trailing= padding. The TLV length includes all of the sub-TLV padding. Thus, the only issue I can see here was that there was confusion about whe= ther fields marked as "Reserved" formed part of the sub-TLVs. The only rea= son they would be, would be to allow for future extensions, otherwise they= would just be padding. Clearly (according to this document) they were intended to be part of the = sub-TLVs (for extensions). That is inconsistent with how 8029 is written, = but since 8287 uses "Reserved" not "MBZ" it is acceptable if that is reall= y want people want to achieve (i.e., that is the consensus decision that i= s needed). Doesn't that mean that the *only* text needed is to say... "Fields marked 'Reserved' in sub-TLVs defined in RFC 8287 are an integral = part of the sub-TLVs and MUST be accounted in computation of the length of= the sub-TLVs."? The current draft seems like a lot of text to make that clarification. Thanks, Adrian -----Original Message----- From: mpls > On Behalf= Of Loa Andersson Sent: 26 February 2019 07:09 To: mpls@ietf.org Cc: mpls-chairs@ietf.org; draft-nainar-mpls-rfc8287-len-clarification@ietf.org Subject: [mpls] IPR poll on draft-nainar-mpls-rfc8287-len-clarification Working Group, authors, We have started to prepare draft-nainar-mpls-rfc8287-len-clarification for working group adoption, prior to the wgap we need to do an IPR poll. This mail starts this IPR poll. Are you aware of any IPR that applies to draft-nainar-mpls-rfc8287-len-cla= rification? If so, has this IPR been disclosed in compliance with IETF IPR rules (see = RFCs 3979, 4879, 3669 and 5378 for more details). There no IPR disclosures against draft-nainar-mpls-rfc8287-len- clarificat= ion. If you are listed as a document author or contributor please respond to th= is 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 w= ill 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 co= ntributor, then please explicitly respond only if you are aware of any IPR= that has not yet been disclosed in conformance with IETF rules. /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 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_AM0PR03MB3828A9DDF9FCBEECADFCE4359D7B0AM0PR03MB3828eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Adrian,

Just to make it clear, I have filed the errat= um  on RFC 8287 (which, I believe is the singular form while errata is plural) that has been rejected by Deborah because “= This change requires an update to the RFC= , requires consensus”.

 

I agree that we could make the draft somewhat sh= orter  - but not by much: the part that looks too long to you takes r= oughly 2 pages out of 5.5.

The added value is that the current version mean= s that the implementer does not have to do any length calculations (that a= lways carry with them the risk of miscalculations): everything is spelled = out in the same way as it is in RFC 8029.

 

I also think that when the “reserved”= ; field is explicitly defined as following:

<quote>

   Reserved

 

      The Reserved = field MUST be set to 0 when sent and MUST be ignored

=

      on receipt.

<end quote>

it is somewhat different to distinguish it from = a “true” MBZ field: What’s in a name?

 

And I do not think that this field has been inte= nded for the future sub-TLVs since it itself is part of a sub-TLV.

 

The bottom line: I think that the draft is ready= for adoption by the WG. If the WG, following adoption, requests to make i= t shorter, we can do that.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549= 266302

Email:   Alexander.Vainshtein@ecitele.= com

 

 

-----Original Message-----
From: mpls <mpls-bounces@ietf.org> On Behalf Of Adrian Farrel
Sent: Tuesday, February 26, 2019 1:20 PM
To: 'Loa Andersson' <loa@pi.nu>; mpls@ietf.org
Cc: mpls-chairs@ietf.org; draft-nainar-mpls-rfc8287-len-clarification@ietf= .org
Subject: [mpls] Pipelining the inevitable adoption poll on draft-nainar-mp= ls-rfc8287-len-clarification

 

Hi,

 

Since Loa is polling for IPR, I suspect an adopt= ion poll is likely to follow.

 

I know this document arises from confusion durin= g interop, and I have some sympathy with people who find RFCs hard to pars= e. I also understand that the AD rejected fixing this through an Errata Re= port, and so the only option is to publish an RFC (the motivation here appears to be that consensus is needed for th= e resolution).

 

IMHO, 8029 is clear on how to set the length of = a TLV or sub-TLV. The sub-TLV length includes all of the fields of the sub= -TLV, but not any trailing padding. The TLV length includes all of the sub= -TLV padding.

 

Thus, the only issue I can see here was that the= re was confusion about whether fields marked as "Reserved" forme= d part of the sub-TLVs. The only reason they would be, would be to allow f= or future extensions, otherwise they would just be padding.

 

Clearly (according to this document) they were i= ntended to be part of the sub-TLVs (for extensions). That is inconsistent = with how 8029 is written, but since 8287 uses "Reserved" not &qu= ot;MBZ" it is acceptable if that is really want people want to achieve (i.e., that is the consensus decision that is needed).

 

Doesn't that mean that the *only* text needed is= to say...

"Fields marked 'Reserved' in sub-TLVs defin= ed in RFC 8287 are an integral part of the sub-TLVs and MUST be accounted = in computation of the length of the sub-TLVs."?

 

The current draft seems like a lot of text to ma= ke that clarification.

 

Thanks,

Adrian

 

-----Original Message-----

From: mpls <mpls-bounces= @ietf.org> On Behalf Of Loa Andersson

Sent: 26 February 2019 07:09

To: mpls@ietf.org

Cc: mpls-chairs@ietf.org;

draft-nainar-mpls-rfc8287-len-clarification@ietf.org

Subject: [mpls] IPR poll on draft-nainar-mpls-rf= c8287-len-clarification

 

Working Group, authors,

 

We have started to prepare draft-nainar-mpls-rfc= 8287-len-clarification

for working group adoption, prior to the wgap we= need to do an IPR poll.

 

This mail starts this IPR poll.

 

Are you aware of any IPR that applies to draft-n= ainar-mpls-rfc8287-len-clarification?

 

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

 

There no IPR disclosures against draft-nainar-mp= ls-rfc8287-len- clarification.

 

If you are listed as a document author or contri= butor please respond to this email regardless of whether or not you are aw= are of any relevant IPR. *The response needs to be sent to the MPLS WG mai= ling 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 i= f you are aware of any IPR that has not yet been disclosed in conformance = with IETF rules.

 

 

/Loa

  mpls wg co-chair

--

 

 

Loa Andersson      = ;            &= nbsp;     email: loa@pi.nu=

Senior MPLS Expert

Bronze Dragon Consulting    =          phone: +46 739 81 21 = 64

 

_______________________________________________<= o:p>

mpls mailing list

mpls@ietf.org=

https://www.i= etf.org/mailman/listinfo/mpls

 

_______________________________________________<= o:p>

mpls mailing list

mpls@ietf.org=

https://www.i= etf.org/mailman/listinfo/mpls


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_AM0PR03MB3828A9DDF9FCBEECADFCE4359D7B0AM0PR03MB3828eurp_-- From nobody Tue Feb 26 04:39:19 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 B106912F1AC; Tue, 26 Feb 2019 04:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 7pAl-K6EqDjc; Tue, 26 Feb 2019 04:39:16 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED501124C04; Tue, 26 Feb 2019 04:39:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2090; q=dns/txt; s=iport; t=1551184756; x=1552394356; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PTyl2rKW89iZr0fHwHfcu3BGGALCwwQVkHTCKr82IXQ=; b=YfPHH3RK3ZkEUzwlBqVlEsor0nBBbovy4TyN2pN/+wPCaK1v3V0Ef0DA Cy/K67GnNkKwkeWi7OfIg/i6HgSZGAYk5d76ieaANIFZDn3eUbQZCbIdX TENs9dlUrAgixXZ7xW+3i5PXiwpWdyVao231a/XvzZBkBt/nfo4GUlGqY w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAABBMnVc/49dJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAIBAQEBCwGCA4FqJwqDfpVdmFeBZwsBAYRsAheDaiI3Bg0?= =?us-ascii?q?BAwEBAgEBAm0ohUsGIxE3AwYFDgICAQgaAiYCAgIZFxUQAgQBDQWDIIFzq0a?= =?us-ascii?q?BL4o5BYEGiz0XgX+BEScME4JMhE4BEQIBHheCczGCJgKJe4JAlyoJApJmGYF?= =?us-ascii?q?zhV2LSooKCUaSFQIRFIEoNSJlcXAVOyoBgkGQXUExjySBHwEB?= X-IronPort-AV: E=Sophos;i="5.58,415,1544486400"; d="scan'208";a="439857180" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2019 12:39:14 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x1QCdEqL012494 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Feb 2019 12:39:14 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 26 Feb 2019 06:39:13 -0600 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1395.000; Tue, 26 Feb 2019 06:39:13 -0600 From: "Nagendra Kumar Nainar (naikumar)" To: Loa Andersson , "mpls@ietf.org" CC: "draft-nainar-mpls-rfc8287-len-clarification@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: IPR poll on draft-nainar-mpls-rfc8287-len-clarification Thread-Index: AQHUzaIco9u0TJ87CkCWQF43zc3WyaXyFg2A Date: Tue, 26 Feb 2019 12:39:13 +0000 Message-ID: References: <98cdd254-2bf8-4bac-ebbc-c8645ab8e0ea@pi.nu> In-Reply-To: <98cdd254-2bf8-4bac-ebbc-c8645ab8e0ea@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.a.0.180210 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.20.8] Content-Type: text/plain; charset="utf-8" Content-ID: <49B7EA98D4E32C42B0EE514B55911462@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [mpls] IPR poll on 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: Tue, 26 Feb 2019 12:39:18 -0000 SGkgTG9hLA0KDQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIG9uIHRoaXMgZG9jdW1lbnQuDQoN ClJlZ2FyZHMsDQpOYWdlbmRyYQ0KDQrvu79PbiAyLzI2LzE5LCAyOjA4IEFNLCAiTG9hIEFuZGVy c3NvbiIgPGxvYUBwaS5udT4gd3JvdGU6DQoNCiAgICBXb3JraW5nIEdyb3VwLCBhdXRob3JzLA0K ICAgIA0KICAgIFdlIGhhdmUgc3RhcnRlZCB0byBwcmVwYXJlIGRyYWZ0LW5haW5hci1tcGxzLXJm YzgyODctbGVuLWNsYXJpZmljYXRpb24NCiAgICBmb3Igd29ya2luZyBncm91cCBhZG9wdGlvbiwg cHJpb3IgdG8gdGhlIHdnYXAgd2UgbmVlZCB0byBkbyBhbiBJUFIgcG9sbC4NCiAgICANCiAgICBU aGlzIG1haWwgc3RhcnRzIHRoaXMgSVBSIHBvbGwuDQogICAgDQogICAgQXJlIHlvdSBhd2FyZSBv ZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byANCiAgICBkcmFmdC1uYWluYXItbXBscy1yZmM4Mjg3 LWxlbi1jbGFyaWZpY2F0aW9uPw0KICAgIA0KICAgIElmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBk aXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzDQogICAgKHNlZSBSRkNz IDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuDQogICAgDQogICAg VGhlcmUgbm8gSVBSIGRpc2Nsb3N1cmVzIGFnYWluc3QgZHJhZnQtbmFpbmFyLW1wbHMtcmZjODI4 Ny1sZW4tDQogICAgY2xhcmlmaWNhdGlvbi4NCiAgICANCiAgICBJZiB5b3UgYXJlIGxpc3RlZCBh cyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgcmVzcG9uZCB0bw0KICAg IHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9m IGFueSByZWxldmFudA0KICAgIElQUi4gKlRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBzZW50IHRv IHRoZSBNUExTIFdHIG1haWxpbmcgbGlzdC4qIFRoZQ0KICAgIGRvY3VtZW50IHdpbGwgbm90IGFk dmFuY2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbg0KICAgIHJl Y2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9yLg0KICAgIA0KICAgIElmIHlv dSBhcmUgb24gdGhlIE1QTFMgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4g YXV0aG9yIG9yDQogICAgY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9u ZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUgb2YgYW55DQogICAgSVBSIHRoYXQgaGFzIG5vdCB5ZXQg YmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLg0KICAgIA0KICAg IA0KICAgIC9Mb2ENCiAgICAgIG1wbHMgd2cgY28tY2hhaXINCiAgICAtLSANCiAgICANCiAgICAN CiAgICBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBwaS5u dQ0KICAgIFNlbmlvciBNUExTIEV4cGVydA0KICAgIEJyb256ZSBEcmFnb24gQ29uc3VsdGluZyAg ICAgICAgICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KICAgIA0KDQo= From nobody Tue Feb 26 04:55: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 5F60312F295; Tue, 26 Feb 2019 04:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01] 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 oVGNmJwKoN_3; Tue, 26 Feb 2019 04:55:22 -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 444ED124BAA; Tue, 26 Feb 2019 04:55:21 -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 x1QCtH3R027122; Tue, 26 Feb 2019 12:55:17 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 82E902204E; Tue, 26 Feb 2019 12:55:17 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id 6AEFF2204C; Tue, 26 Feb 2019 12:55:17 +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 x1QCtGbr022245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Feb 2019 12:55:16 GMT Reply-To: From: "Adrian Farrel" To: "'Alexander Vainshtein'" Cc: , , "'Loa Andersson'" , References: <033901d4cdc5$4640f2e0$d2c2d8a0$@olddog.co.uk> In-Reply-To: Date: Tue, 26 Feb 2019 12:55:16 -0000 Organization: Old Dog Consulting Message-ID: <036901d4cdd2$860f1a70$922d4f50$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_036A_01D4CDD2.861275D0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIico/ZR4JBtKMannh3QJeRlGrgqgGPDTZtpUpG+rA= 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-24456.007 X-TM-AS-Result: No--31.895-10.0-31-10 X-imss-scan-details: No--31.895-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24456.007 X-TMASE-Result: 10--31.895000-10.000000 X-TMASE-MatchedRID: jFqw+1pFnMzxIbpQ8BhdbGzBijri5+RV7q8FE7Y/iI1QKAQSutQYXIrr VDrdF6YEJLIvfOwAGPbejIKemsMsDUEldmG5s6kZb8JTZf0kEzs0AKed0u9fB3Oy6EBOBW1qSzR sdc8l3B5HS+vshkGLkxcdkIXUbTd4exBmwgbVzYfhuXUWQoMQtySF0LR+PMPIVBS/JDYr37C3DI h4Vmbze+ZjKb6ys7Ociz0NiiC/JRwxk+PbmPwK3EKcYi5Qw/RVVX7TxgU0dK5Zps+y1VXzqUFYU JLQupgqwnPRJvFiqpirJ+c2fCxI6QYFn9rUnd9nM71h0SMVl8L3N59hBwdmny62hjZS0WoYx+Uw 4sIsasvUXduftfjvR3fFOUZuMU76BbvHck2HzvxXq5HtSh5C5MnlJe2gk8vISSUXkvSVAdxjuEJ aB1iHgv37Sl/qiuKeIc0OTKdFkD34LNiDhk5IJn9NanCUA4VeudcAdgVI8xlGvu3Cr8OtFkc5A8 5pTadYuAsML43hVSl9/wjow1SVlyTtChVcJtE4Vo6mn+xXmdVMFWXO7lee9bt4BAaULwAVN8RGT fW9Fj3DgGiSi1hwZ2dlOj9QIwpdxb2ZByTuHA+puD25aEtgtyGZtiDVlw6eN2d3n0B/sI84kr4x 1zfYTWMNA1KnBCuxzzU2+MLrDVRfDKWvP/4QA7U+IyHhkXf1W1DDwVjMhE5ZGhC8KIepNrKZXdc PRJJRRyrOW/EBT3K6Qny7Q2uEd4iceOuNnLyW/Sl5cYQQGW+uiAW0p38/t5b7No0srrTk7KBBZ2 QBUyzQ23n+P5pIMRQjizXtCXfTWYqLLUX2mAueAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDPPeN6H N6d7GlnRC7/pAaFU6baA36eiawgbhiVsIMQK7ebCOc2vNHr5dGVkKe/kiVfXumc4O21pKaxBAu0 XzMcGU0fg84rnFjFhXMjdQIJpg== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] Pipelining the inevitable adoption poll on 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: Tue, 26 Feb 2019 12:55:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_036A_01D4CDD2.861275D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hmmm, I think I am now erring towards agreeing with you having found 8029 ss3.9. That has three trailing MBZ bytes, but still has a length of 4. I'm still not sure that reproducing the figures is necessary, but if you phrase the text as "this figure replaces that figure" it'll work out OK. A From: Alexander Vainshtein Sent: 26 February 2019 11:55 To: adrian@olddog.co.uk Cc: mpls-chairs@ietf.org; draft-nainar-mpls-rfc8287-len-clarification@ietf.org; 'Loa Andersson' ; mpls@ietf.org Subject: RE: [mpls] Pipelining the inevitable adoption poll on draft-nainar-mpls-rfc8287-len-clarification Adrian, Just to make it clear, I have filed the erratum on RFC 8287 (which, I believe is the singular form while errata is plural) that has been rejected by Deborah because "This change requires an update to the RFC, requires consensus". I agree that we could make the draft somewhat shorter - but not by much: the part that looks too long to you takes roughly 2 pages out of 5.5. The added value is that the current version means that the implementer does not have to do any length calculations (that always carry with them the risk of miscalculations): everything is spelled out in the same way as it is in RFC 8029. I also think that when the "reserved" field is explicitly defined as following: Reserved The Reserved field MUST be set to 0 when sent and MUST be ignored on receipt. it is somewhat different to distinguish it from a "true" MBZ field: What's in a name? And I do not think that this field has been intended for the future sub-TLVs since it itself is part of a sub-TLV. The bottom line: I think that the draft is ready for adoption by the WG. If the WG, following adoption, requests to make it shorter, we can do that. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: mpls > On Behalf Of Adrian Farrel Sent: Tuesday, February 26, 2019 1:20 PM To: 'Loa Andersson' >; mpls@ietf.org Cc: mpls-chairs@ietf.org ; draft-nainar-mpls-rfc8287-len-clarification@ietf.org Subject: [mpls] Pipelining the inevitable adoption poll on draft-nainar-mpls-rfc8287-len-clarification Hi, Since Loa is polling for IPR, I suspect an adoption poll is likely to follow. I know this document arises from confusion during interop, and I have some sympathy with people who find RFCs hard to parse. I also understand that the AD rejected fixing this through an Errata Report, and so the only option is to publish an RFC (the motivation here appears to be that consensus is needed for the resolution). IMHO, 8029 is clear on how to set the length of a TLV or sub-TLV. The sub-TLV length includes all of the fields of the sub-TLV, but not any trailing padding. The TLV length includes all of the sub-TLV padding. Thus, the only issue I can see here was that there was confusion about whether fields marked as "Reserved" formed part of the sub-TLVs. The only reason they would be, would be to allow for future extensions, otherwise they would just be padding. Clearly (according to this document) they were intended to be part of the sub-TLVs (for extensions). That is inconsistent with how 8029 is written, but since 8287 uses "Reserved" not "MBZ" it is acceptable if that is really want people want to achieve (i.e., that is the consensus decision that is needed). Doesn't that mean that the *only* text needed is to say... "Fields marked 'Reserved' in sub-TLVs defined in RFC 8287 are an integral part of the sub-TLVs and MUST be accounted in computation of the length of the sub-TLVs."? The current draft seems like a lot of text to make that clarification. Thanks, Adrian -----Original Message----- From: mpls < mpls-bounces@ietf.org> On Behalf Of Loa Andersson Sent: 26 February 2019 07:09 To: mpls@ietf.org Cc: mpls-chairs@ietf.org; draft-nainar-mpls-rfc8287-len-clarification@ietf.org Subject: [mpls] IPR poll on draft-nainar-mpls-rfc8287-len-clarification Working Group, authors, We have started to prepare draft-nainar-mpls-rfc8287-len-clarification for working group adoption, prior to the wgap we need to do an IPR poll. This mail starts this IPR poll. Are you aware of any IPR that applies to draft-nainar-mpls-rfc8287-len-clarification? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There no IPR disclosures against draft-nainar-mpls-rfc8287-len- clarification. 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. /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 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains 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. ___________________________________________________________________________ ------=_NextPart_000_036A_01D4CDD2.861275D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hmmm,

 

 

I think I = am now erring towards agreeing with you having found 8029 ss3.9. That = has three trailing MBZ bytes, but still has a length of = 4.

 

I’m = still not sure that reproducing the figures is necessary, but if you = phrase the text as “this figure replaces that figure” = it’ll work out OK.

 

A

 

From: Alexander Vainshtein = <Alexander.Vainshtein@ecitele.com>
Sent: 26 February = 2019 11:55
To: adrian@olddog.co.uk
Cc: = mpls-chairs@ietf.org; = draft-nainar-mpls-rfc8287-len-clarification@ietf.org; 'Loa Andersson' = <loa@pi.nu>; mpls@ietf.org
Subject: RE: [mpls] = Pipelining the inevitable adoption poll on = draft-nainar-mpls-rfc8287-len-clarification

 

Adrian,

Just to make it clear, I have = filed the erratum  on RFC 8287 (which, I believe is the = singular form while errata is plural) that has been rejected by = Deborah because “This change requires an update to the RFC, requires = consensus”.

 

I agree that we could make the = draft somewhat shorter  - but not by much: the part that looks too = long to you takes roughly 2 pages out of 5.5.

The added value is that the = current version means that the implementer does not have to do any = length calculations (that always carry with them the risk of = miscalculations): everything is spelled out in the same way as it is in = RFC 8029.

 

I also think that when the “reserved” field is = explicitly defined as following:

<quote>

   Reserved

 

      The Reserved field MUST = be set to 0 when sent and MUST be ignored

      on = receipt.

<end quote>

it is somewhat different to = distinguish it from a “true” MBZ field: What’s in a = name?

 

And I do not think that this field has been intended for = the future sub-TLVs since it itself is part of a sub-TLV.<= o:p>

 

The bottom line: I think that the draft is ready for = adoption by the WG. If the WG, following adoption, requests to make it = shorter, we can do that.

 

Regards,

Sasha

 

Office: = +972-39266302

Cell:      = +972-549266302

Email:   Alexander.Vainshtein@eci= tele.com

 

 

-----Original Message-----
From: mpls <mpls-bounces@ietf.org> On = Behalf Of Adrian Farrel
Sent: Tuesday, February 26, 2019 1:20 = PM
To: 'Loa Andersson' <loa@pi.nu>; mpls@ietf.org
Cc: mpls-chairs@ietf.org; draf= t-nainar-mpls-rfc8287-len-clarification@ietf.org
Subject: [mpls] = Pipelining the inevitable adoption poll on = draft-nainar-mpls-rfc8287-len-clarification

 

Hi,

 

Since Loa is polling for IPR, I = suspect an adoption poll is likely to follow.

 

I know this document arises from = confusion during interop, and I have some sympathy with people who find = RFCs hard to parse. I also understand that the AD rejected fixing this = through an Errata Report, and so the only option is to publish an RFC = (the motivation here appears to be that consensus is needed for the = resolution).

 

IMHO, 8029 is clear on how to set the length of a TLV or = sub-TLV. The sub-TLV length includes all of the fields of the sub-TLV, = but not any trailing padding. The TLV length includes all of the sub-TLV = padding.

 

Thus, the only issue I can see here was that there was = confusion about whether fields marked as "Reserved" formed = part of the sub-TLVs. The only reason they would be, would be to allow = for future extensions, otherwise they would just be = padding.

 

Clearly (according to this document) they were intended to = be part of the sub-TLVs (for extensions). That is inconsistent with how = 8029 is written, but since 8287 uses "Reserved" not = "MBZ" it is acceptable if that is really want people want to = achieve (i.e., that is the consensus decision that is = needed).

 

Doesn't that mean that the *only* text needed is to = say...

"Fields marked 'Reserved' in sub-TLVs defined in RFC = 8287 are an integral part of the sub-TLVs and MUST be accounted in = computation of the length of the = sub-TLVs."?

 

The current draft seems like a lot of text to make that = clarification.

 

Thanks,

Adrian

 

-----Original Message-----

From: mpls <mpls-bounces@ietf.org> On Behalf Of Loa Andersson

Sent: 26 February 2019 = 07:09

To: mpls@ietf.org<= o:p>

Cc: mpls-chairs@ietf.org;

draft-nainar-mpls-rfc8287= -len-clarification@ietf.org

Subject: [mpls] IPR poll on = draft-nainar-mpls-rfc8287-len-clarification

 

Working Group, = authors,

 

We have started to prepare = draft-nainar-mpls-rfc8287-len-clarification

for working group adoption, = prior to the wgap we need to do an IPR poll.

 

This mail starts this IPR = poll.

 

Are you aware of any IPR that applies to = draft-nainar-mpls-rfc8287-len-clarification?

 

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

 

There no IPR disclosures against = draft-nainar-mpls-rfc8287-len- clarification.

 

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.

 

 

/Loa

  mpls wg co-chair

--

 

 

Loa = Andersson          &nbs= p;            = ; email: loa@pi.nu=

Senior MPLS = Expert

Bronze Dragon = Consulting          &nb= sp;  phone: +46 739 81 21 64

 

_______________________________________________

mpls mailing = list

mpls@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/mpls

 

_______________________________________________

mpls mailing = list

mpls@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/mpls


________________________________________________________= ___________________

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.
_____________________________________________________________= ______________

------=_NextPart_000_036A_01D4CDD2.861275D0-- From nobody Tue Feb 26 06:33: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 4BB65130E5D; Tue, 26 Feb 2019 06:32:58 -0800 (PST) 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 9BkraXlAdcpx; Tue, 26 Feb 2019 06:32:51 -0800 (PST) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.114]) (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 00C33128CE4; Tue, 26 Feb 2019 06:32:49 -0800 (PST) Received: from [85.158.142.193] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-b.eu-central-1.aws.symcld.net id 79/CF-05904-F0E457C5; Tue, 26 Feb 2019 14:32:47 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCJsWRWlGSWpSXmKPExsViovlDRZffrzT GYOsSYYsfPTeYLW48PMpi8W/uHGaLdZdPsVncWrqS1YHVY8mSn0weKzavZPSYNb2NLYA5ijUz Lym/IoE14/HhJWwFzRcYK/7tXsrcwLhuJ2MXIxcHi8AiZomft++wgDhCAhOZJN7O/80G4dxll Pj3cwNQGScHm4CtxKbVd9lAbBEBfYnuc9PYQYqYBR4ySizZBVEkLJAt8fP+VUaIohyJ+VO6oR qcJJ6fng9mswioStz7NIcJxOYViJV4+ncKE8S2PYwSe5s+sYMkOAWsJY4f/cwCYjMKiEl8P7U GrIFZQFzi1pP5YLaEgIDEkj3nmSFsUYmXj/+xQtQnSdx/upARIq4oMePeHHYIW1bi0vxuqLiv xNWLXUBxDiBbWWLLi1iQGyQEHjNKfJj/F6peS2LX249Q9VISJy4eZYUoOsUvMe/iRSaI5hyJ6 TutIGpkJLYt3c4OUXOUTWLK5+NghwoJJEucmAPxjISAnMSq3ocsEEUXmCWO981lncCoNQvJcx B2nsTazq1ss8ChJChxcuYTFoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6K0SKpKDM9oyQ 3MTNH19DAQNfQ0FjXRNfISC+xSjdJL7VUNzk1r6QoESipl1herFdcmZuck6KXl1qyiRGY6lIK WcR2MF5Ymn6IUZKDSUmUd65TaYwQX1J+SmVGYnFGfFFpTmrxIUYZDg4lCd4KH6CcYFFqempFW mYOMOnCpCU4eJREeC+CpHmLCxJzizPTIVKnGC05Dix6OJeZY8v9Z0ByF4gUYsnLz0uVEuc9DN IgANKQUZoHNw6WGS4xykoJ8zIyMDAI8RSkFuVmlqDKv2IU52BUEuYtAZnCk5lXArf1FdBBTEA HHX5ZDHJQSSJCSqqBsaRr64zOKV/m3pP3cXnTKlgj8qvL73sTu+mOtdYTdAW/rJQNqZx5tH1N a/y8/EUs39exbH2v/U9EvDBrVnagxeHDS4LmGj/Qm7f8bIyCmJKn79pVMXVM+VWrLNmdioKm+ 54+1RWtEr86RmJ5535dNU9bT4YVmcvLrqQoVejEyVzibZqQdq1biaU4I9FQi7moOBEA4jOZgQ cEAAA= X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-4.tower-238.messagelabs.com!1551191559!1911794!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 8728 invoked from network); 26 Feb 2019 14:32:46 -0000 Received: from us-west-2a.mta.dlp.protect.symantec.com (HELO EUR02-AM5-obe.outbound.protection.outlook.com) (52.41.248.36) by server-4.tower-238.messagelabs.com with AES256-SHA256 encrypted SMTP; 26 Feb 2019 14:32:46 -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=zaNsIYnLWzf4Jmb9avUsb3VD9OxNjdI0w5iuo4phZ5k=; b=WiUYCky8XCphdw8NRgDvGTD/1HJHY++LdRJSCKn31jz6F6EpPwnmU7gq32z08NaETmONpFtu1otNN9SYPFo97aCyNpQr4JhF4EDDLRueTb50pBf7oWfBhOROQOIkaN1C/HmyJvEhlwpyMd5oUQPzeJwYDnSQoqicKkYN6KCcPj0= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB4946.eurprd03.prod.outlook.com (20.178.21.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.18; Tue, 26 Feb 2019 14:32:38 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::cd69:f7a:ee65:6435]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::cd69:f7a:ee65:6435%5]) with mapi id 15.20.1643.019; Tue, 26 Feb 2019 14:32:38 +0000 From: Alexander Vainshtein To: "adrian@olddog.co.uk" CC: "mpls-chairs@ietf.org" , "draft-nainar-mpls-rfc8287-len-clarification@ietf.org" , 'Loa Andersson' , "mpls@ietf.org" Thread-Topic: [mpls] Pipelining the inevitable adoption poll on draft-nainar-mpls-rfc8287-len-clarification Thread-Index: AdTNxUJnQ9WDFgDvRYi52BMJf0SHhwAAFUPwAAM7ZwAAAvJlYA== Date: Tue, 26 Feb 2019 14:32:38 +0000 Message-ID: References: <033901d4cdc5$4640f2e0$d2c2d8a0$@olddog.co.uk> <036901d4cdd2$860f1a70$922d4f50$@olddog.co.uk> In-Reply-To: <036901d4cdd2$860f1a70$922d4f50$@olddog.co.uk> 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: 5fc72df1-7347-4979-3fae-08d69bf741c4 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:AM0PR03MB4946; x-ms-traffictypediagnostic: AM0PR03MB4946: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; AM0PR03MB4946; 23:h/CZJNN6E+K9DXwRMzTFDb14ZUle55D8tWzyapJUq?= =?us-ascii?Q?gs3ikUNTClhnldTyqpcNU0Sk27T3Zb22GWT6UolpB/1vYHdHflKelx8NQ+Yx?= =?us-ascii?Q?UyLvXFtzaOsWnG2yUDNG14XnfmVwir4OZoKOalQ5RUznX/oM3dEvLhZ7E9E7?= =?us-ascii?Q?8Gepy0fLerx4aN4HTZ9fWFSITuuom5HGoYo77GRiOw5mfsTQSxPk9xT5Ea1m?= =?us-ascii?Q?+szwh4U/dcMoVTJzHTRoVdVWCZGB2K84zqHPlxDWlzbEmzJ7fU5Iw1c3ZLh9?= =?us-ascii?Q?0N4VEMduESIint+AMEktRWSH1dG9qOCyPAg/H9T9mjyXH79OojmbHy4ydZwf?= =?us-ascii?Q?4fwsdyN2JiQiD25tPLTmo7pF8ZAs9S4uvu705ab4XBLPwX9i29oKqmOKiM7j?= =?us-ascii?Q?w4+hUeqgFmlLC0N/UkwRRLytzajo1dYwQt2XiPdz2wfw5XBLSDLa5HaV4ylR?= =?us-ascii?Q?f4wRSsVupgrr+HrUl7H1VE1no5EnogLlsUwO3LdKXYAHLYbn9zlWdh02n4lK?= =?us-ascii?Q?SQdwhazTDCcDRTauUXD5VktXOMLCnE5dT9G2G9KQeP7eXT9CdEouJpivc0lU?= =?us-ascii?Q?tRTmpDDFURei68eSa1cndNJy2SCbha70b9tcROc88V7vUtKtzopQIIeONePt?= =?us-ascii?Q?nM/mZdbcFmJgOgh90YF2GqbS84KNQJ5U51cS+cUSPSOpRohNLEUhkomCynm9?= =?us-ascii?Q?8YGs5OERGTXgACrOLsHysyoJvJ5aZad6Wk9RhZbLFq62mWePMD8YJPXzqO76?= =?us-ascii?Q?qeLh44BigqbJUVRf+1sW6+2kzM35GITt1iVtnOfRUrQvo1F69MPeCvrtMFoe?= =?us-ascii?Q?zhOcPncguiPiU+7OagPoADFJ75hrWNPi0OAlyrDUq4GSbnGaqQ+FgQlThZut?= =?us-ascii?Q?z29W6T1K8yluq49/Eyu6kMgkHV333ZKPfvBanMlVUMjWL8H6JDWoN+X+A5gs?= =?us-ascii?Q?4+CRqO2eIgJgQ1fqpHThTADDdOEmfmHz0fXcXOs3vJPGzVU21NcrD9+KHOhN?= =?us-ascii?Q?gT5pj62oNPCRyIM9NCrQ8s3Hmr5p4IOXboZtK3d6x/iXR4CNGMLjxZ5x2CPH?= =?us-ascii?Q?swG1+FP4gefNy6MC09fpL+7Xxv4rugBYpy4o1RGXgbPjaPcNQh5Johr33Juj?= =?us-ascii?Q?AlklHEmS1TnghaK8Qx40qLqjqhmsdSg7BcoCfWcOyz45oa4QXU8H8ymMuGUo?= =?us-ascii?Q?1lleX59MtQ9wG5o18L4x4VbgsJDqKIJlknNgEANDTP+vZaVxNaCO/n6usLWM?= =?us-ascii?Q?9OA/8rEi/Difv9U6eUzQ3QK4mj1x3j+2e/2d/8crcySCvSEIZeq+yGkssNEL?= =?us-ascii?Q?IksNPQwDjS30ezx/FQ85Bu9mi56eMmhIk9Btj3UsCsGtF5oS/J9wr0dsCkt9?= =?us-ascii?Q?P9rN2SH0iF24wn9hPdTwf+ERNUnxb/Nwd5ov/t6LW1RppwajYgb1M9QeLnfe?= =?us-ascii?Q?rtxy5zIYMDJLZKfiV+V5xBhfxZvYiMydsQ5E1B/YWDKZ/5uPW/06RHzmuXVU?= =?us-ascii?Q?WNhFcnZ01+b5Q=3D=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 096029FF66 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(376002)(346002)(136003)(396003)(189003)(199004)(13464003)(51444003)(97736004)(186003)(229853002)(26005)(81166006)(606006)(2906002)(68736007)(476003)(486006)(446003)(33656002)(8936002)(11346002)(3846002)(6116002)(790700001)(99286004)(1730700003)(81156014)(8676002)(105586002)(2351001)(106356001)(966005)(72206003)(14454004)(6506007)(6916009)(478600001)(53546011)(102836004)(71200400001)(7696005)(76176011)(53936002)(86362001)(2501003)(54906003)(71190400001)(55016002)(74316002)(7736002)(4326008)(14444005)(256004)(66066001)(5640700003)(316002)(25786009)(6436002)(236005)(54896002)(9686003)(5660300002)(6246003)(6306002)(52536013); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB4946; H:AM0PR03MB3828.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: Ql06q0MZa4PvvtDb3M3JQYXQ2mPa+t08BgiKmc2JVVJ+dsYO7ipdtbu+Uvy0nTHYiaAzg6X9jFL/7AqVaRe+KkjxV07Gkb/Wl2Yi+e8CGgSQa1MHcDeWEReUbuPf1rAFffXs64LPROhQflMs9Of9h3dlDz47dpu3MEBUOe0MUByHPJomhAoxTKJUoFOpyhO8qU1pLSoee33PFh6l3abNCwIYnQ9gISqmSG9bTa7wtF34rWprOs+pLrBq36czbjTHvbnpCpr8xcwAEYQaqZLf2t6hxgLs7abYEMHmTYEJyOMrvc3TEq+GTAa3t5TBLTlpL2CpN0zH7s3FYAX9FUqc2fYcbuEVcIgaZdpt7rKAzvDDSfIrfUIE9/u5VEW2oOr51En/QC9Rmuoo15zkFpAhS9wiYF8U79M4HayWYEolX0U= Content-Type: multipart/alternative; boundary="_000_AM0PR03MB38283D2A1BBAFBBAB5CD0C2E9D7B0AM0PR03MB3828eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5fc72df1-7347-4979-3fae-08d69bf741c4 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2019 14:32:38.0900 (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: AM0PR03MB4946 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [mpls] Pipelining the inevitable adoption poll on 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: Tue, 26 Feb 2019 14:32:58 -0000 --_000_AM0PR03MB38283D2A1BBAFBBAB5CD0C2E9D7B0AM0PR03MB3828eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adrian, I have looked up 8029 again,(that is explicitly defined and I see that in = all the cases when a trailing MBZ field is defined, its length is included= in the explicitly defined length of the sub-TLV. As for adding the text that accompanies the figures: I do not see any issu= e with adding that these figures replace the figures in 8029 (they are in= deed different because they contain explicitly defined length). Hopefully = this can be done after adoption. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Adrian Farrel Sent: Tuesday, February 26, 2019 2:55 PM To: Alexander Vainshtein Cc: mpls-chairs@ietf.org; draft-nainar-mpls-rfc8287-len-clarification@ietf= .org; 'Loa Andersson' ; mpls@ietf.org Subject: RE: [mpls] Pipelining the inevitable adoption poll on draft-naina= r-mpls-rfc8287-len-clarification Hmmm, I think I am now erring towards agreeing with you having found 8029 ss3.9.= That has three trailing MBZ bytes, but still has a length of 4. I'm still not sure that reproducing the figures is necessary, but if you p= hrase the text as "this figure replaces that figure" it'll work out OK. A From: Alexander Vainshtein > Sent: 26 February 2019 11:55 To: adrian@olddog.co.uk Cc: mpls-chairs@ietf.org; draft-nainar-mpls-r= fc8287-len-clarification@ietf.org; 'Loa Andersson' >; mpls@= ietf.org Subject: RE: [mpls] Pipelining the inevitable adoption poll on draft-naina= r-mpls-rfc8287-len-clarification Adrian, Just to make it clear, I have filed the erratum on RFC 8287 (which, I bel= ieve is the singular form while errata is plural) that has been rejected b= y Deborah because "This change requires an update to the RFC, requires con= sensus". I agree that we could make the draft somewhat shorter - but not by much: = the part that looks too long to you takes roughly 2 pages out of 5.5. The added value is that the current version means that the implementer doe= s not have to do any length calculations (that always carry with them the = risk of miscalculations): everything is spelled out in the same way as it = is in RFC 8029. I also think that when the "reserved" field is explicitly defined as follo= wing: Reserved The Reserved field MUST be set to 0 when sent and MUST be ignored on receipt. it is somewhat different to distinguish it from a "true" MBZ field: What's= in a name? And I do not think that this field has been intended for the future sub-TL= Vs since it itself is part of a sub-TLV. The bottom line: I think that the draft is ready for adoption by the WG. I= f the WG, following adoption, requests to make it shorter, we can do that.= Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: mpls > On Behalf= Of Adrian Farrel Sent: Tuesday, February 26, 2019 1:20 PM To: 'Loa Andersson' >; mpls@ietf.org Cc: mpls-chairs@ietf.org; draft-nainar-mpls-r= fc8287-len-clarification@ietf.org Subject: [mpls] Pipelining the inevitable adoption poll on draft-nainar-mp= ls-rfc8287-len-clarification Hi, Since Loa is polling for IPR, I suspect an adoption poll is likely to foll= ow. I know this document arises from confusion during interop, and I have some= sympathy with people who find RFCs hard to parse. I also understand that = the AD rejected fixing this through an Errata Report, and so the only opti= on is to publish an RFC (the motivation here appears to be that consensus = is needed for the resolution). IMHO, 8029 is clear on how to set the length of a TLV or sub-TLV. The sub-= TLV length includes all of the fields of the sub-TLV, but not any trailing= padding. The TLV length includes all of the sub-TLV padding. Thus, the only issue I can see here was that there was confusion about whe= ther fields marked as "Reserved" formed part of the sub-TLVs. The only rea= son they would be, would be to allow for future extensions, otherwise they= would just be padding. Clearly (according to this document) they were intended to be part of the = sub-TLVs (for extensions). That is inconsistent with how 8029 is written, = but since 8287 uses "Reserved" not "MBZ" it is acceptable if that is reall= y want people want to achieve (i.e., that is the consensus decision that i= s needed). Doesn't that mean that the *only* text needed is to say... "Fields marked 'Reserved' in sub-TLVs defined in RFC 8287 are an integral = part of the sub-TLVs and MUST be accounted in computation of the length of= the sub-TLVs."? The current draft seems like a lot of text to make that clarification. Thanks, Adrian -----Original Message----- From: mpls > On Behalf= Of Loa Andersson Sent: 26 February 2019 07:09 To: mpls@ietf.org Cc: mpls-chairs@ietf.org; draft-nainar-mpls-rfc8287-len-clarification@ietf.org Subject: [mpls] IPR poll on draft-nainar-mpls-rfc8287-len-clarification Working Group, authors, We have started to prepare draft-nainar-mpls-rfc8287-len-clarification for working group adoption, prior to the wgap we need to do an IPR poll. This mail starts this IPR poll. Are you aware of any IPR that applies to draft-nainar-mpls-rfc8287-len-cla= rification? If so, has this IPR been disclosed in compliance with IETF IPR rules (see = RFCs 3979, 4879, 3669 and 5378 for more details). There no IPR disclosures against draft-nainar-mpls-rfc8287-len- clarificat= ion. If you are listed as a document author or contributor please respond to th= is 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 w= ill 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 co= ntributor, then please explicitly respond only if you are aware of any IPR= that has not yet been disclosed in conformance with IETF rules. /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 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived 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 inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_AM0PR03MB38283D2A1BBAFBBAB5CD0C2E9D7B0AM0PR03MB3828eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adrian,

I have looked up 8029= again,(that is explicitly defined and I see that in all the cases when a = trailing MBZ field is defined, its length is included in the explicitly defined length of the sub-TLV.<= /p>

 

As for adding the tex= t that accompanies the figures: I do not see any issue with adding  t= hat these figures replace the figures in 8029 (they are indeed different b= ecause they contain explicitly defined length). Hopefully this can be done after adoption.

 

Regards,

Sasha

 

Office: +972-3926= 6302

Cell:  &nbs= p;   +972-549266302

Email:   Al= exander.Vainshtein@ecitele.com

 

From: Adrian Farrel <adrian@olddog.co.uk&= gt;
Sent: Tuesday, February 26, 2019 2:55 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Cc: mpls-chairs@ietf.org; draft-nainar-mpls-rfc8287-len-clarificati= on@ietf.org; 'Loa Andersson' <loa@pi.nu>; mpls@ietf.org
Subject: RE: [mpls] Pipelining the inevitable adoption poll on draf= t-nainar-mpls-rfc8287-len-clarification

 

Hmmm,

 

 

I think I am now erring toward= s agreeing with you having found 8029 ss3.9. That has three trailing MBZ b= ytes, but still has a length of 4.

 

I’m still not sure that = reproducing the figures is necessary, but if you phrase the text as “= ;this figure replaces that figure” it’ll work out OK.

 

A

 

From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Sent: 26 February 2019 11:55
To: adrian@olddog.co.uk<= br> Cc: mpls-chairs@ietf.org; draft-nainar-mpls-rfc8287-len-clarification@ietf.org; 'Loa Andersson' = <loa@pi.nu>; mpls@ietf.org
Subject: RE: [mpls] Pipelining the inevitable adoption poll on draf= t-nainar-mpls-rfc8287-len-clarification

 

Adrian,

Just to make it clear, I have filed the errat= um  on RFC 8287 (which, I believe is the singular form while errata is plural) that has been rejected by Deborah because “= This change requires an update to the RFC= , requires consensus”.

 

I agree that we could make the draft somewhat sh= orter  - but not by much: the part that looks too long to you takes r= oughly 2 pages out of 5.5.

The added value is that the current version mean= s that the implementer does not have to do any length calculations (that a= lways carry with them the risk of miscalculations): everything is spelled = out in the same way as it is in RFC 8029.

 

I also think that when the “reserved”= ; field is explicitly defined as following:

<quote>

   Reserved

 

      The Reserved = field MUST be set to 0 when sent and MUST be ignored

=

      on receipt.

<end quote>

it is somewhat different to distinguish it from = a “true” MBZ field: What’s in a name?

 

And I do not think that this field has been inte= nded for the future sub-TLVs since it itself is part of a sub-TLV.

 

The bottom line: I think that the draft is ready= for adoption by the WG. If the WG, following adoption, requests to make i= t shorter, we can do that.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549= 266302

Email:   Alexander.Vainshtein@ecitele.com

 

 

-----Original Message-----
From: mpls <mpls-bounces@ietf.= org> On Behalf Of Adrian Farrel
Sent: Tuesday, February 26, 2019 1:20 PM
To: 'Loa Andersson' <loa@pi.nu>; mpls@ietf.org
Cc: mpls-chairs@ietf.org; draft-nainar-mpls-rfc8287-len-clarification@ietf.org
Subject: [mpls] Pipelining the inevitable adoption poll on draft-nainar-mp= ls-rfc8287-len-clarification

 

Hi,

 

Since Loa is polling for IPR, I suspect an adopt= ion poll is likely to follow.

 

I know this document arises from confusion durin= g interop, and I have some sympathy with people who find RFCs hard to pars= e. I also understand that the AD rejected fixing this through an Errata Re= port, and so the only option is to publish an RFC (the motivation here appears to be that consensus is needed for th= e resolution).

 

IMHO, 8029 is clear on how to set the length of = a TLV or sub-TLV. The sub-TLV length includes all of the fields of the sub= -TLV, but not any trailing padding. The TLV length includes all of the sub= -TLV padding.

 

Thus, the only issue I can see here was that the= re was confusion about whether fields marked as "Reserved" forme= d part of the sub-TLVs. The only reason they would be, would be to allow f= or future extensions, otherwise they would just be padding.

 

Clearly (according to this document) they were i= ntended to be part of the sub-TLVs (for extensions). That is inconsistent = with how 8029 is written, but since 8287 uses "Reserved" not &qu= ot;MBZ" it is acceptable if that is really want people want to achieve (i.e., that is the consensus decision that is needed).

 

Doesn't that mean that the *only* text needed is= to say...

"Fields marked 'Reserved' in sub-TLVs defin= ed in RFC 8287 are an integral part of the sub-TLVs and MUST be accounted = in computation of the length of the sub-TLVs."?

 

The current draft seems like a lot of text to ma= ke that clarification.

 

Thanks,

Adrian

 

-----Original Message-----

From: mpls <mpls-bounces= @ietf.org> On Behalf Of Loa Andersson

Sent: 26 February 2019 07:09

To: mpls@ietf.org

Cc: mpls-chairs@ietf.org;

draft-nainar-mpls-rfc8287-len-clarification@ietf.org

Subject: [mpls] IPR poll on draft-nainar-mpls-rf= c8287-len-clarification

 

Working Group, authors,

 

We have started to prepare draft-nainar-mpls-rfc= 8287-len-clarification

for working group adoption, prior to the wgap we= need to do an IPR poll.

 

This mail starts this IPR poll.

 

Are you aware of any IPR that applies to draft-n= ainar-mpls-rfc8287-len-clarification?

 

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

 

There no IPR disclosures against draft-nainar-mp= ls-rfc8287-len- clarification.

 

If you are listed as a document author or contri= butor please respond to this email regardless of whether or not you are aw= are of any relevant IPR. *The response needs to be sent to the MPLS WG mai= ling 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 i= f you are aware of any IPR that has not yet been disclosed in conformance = with IETF rules.

 

 

/Loa

  mpls wg co-chair

--

 

 

Loa Andersson      = ;            &= nbsp;     email: loa@pi.nu=

Senior MPLS Expert

Bronze Dragon Consulting    =          phone: +46 739 81 21 = 64

 

_______________________________________________<= o:p>

mpls mailing list

mpls@ietf.org=

https://www.i= etf.org/mailman/listinfo/mpls

 

_______________________________________________<= o:p>

mpls mailing list

mpls@ietf.org=

https://www.i= etf.org/mailman/listinfo/mpls


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived 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 inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_AM0PR03MB38283D2A1BBAFBBAB5CD0C2E9D7B0AM0PR03MB3828eurp_-- From nobody Tue Feb 26 07:11: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 363BD12D7EA; Tue, 26 Feb 2019 07:11:16 -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 KB2SDuhLR_Rc; Tue, 26 Feb 2019 07:11:14 -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 B9187128CB7; Tue, 26 Feb 2019 07:11:12 -0800 (PST) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id x1QFB9wj019585; Tue, 26 Feb 2019 15:11:09 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0F6602203A; Tue, 26 Feb 2019 15:11:09 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id ED8B62203D; Tue, 26 Feb 2019 15:11: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 x1QFB7K5021209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Feb 2019 15:11:08 GMT Reply-To: From: "Adrian Farrel" To: "'Robert Sparks'" , Cc: , , References: <155067766687.31388.18349714938448955572@ietfa.amsl.com> <04c001d4c938$7e3d86e0$7ab894a0$@olddog.co.uk> In-Reply-To: <04c001d4c938$7e3d86e0$7ab894a0$@olddog.co.uk> Date: Tue, 26 Feb 2019 15:11:07 -0000 Organization: Old Dog Consulting Message-ID: <03b801d4cde5$805c6250$811526f0$@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: AQF4uyAuQiUz1zT6JW7t9AabcMIgdgHycLykppqz0xA= 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-24456.007 X-TM-AS-Result: No--1.827-10.0-31-10 X-imss-scan-details: No--1.827-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24456.007 X-TMASE-Result: 10--1.826500-10.000000 X-TMASE-MatchedRID: oTBA/+sdKabxIbpQ8BhdbDPDkSOzeDWWLdLfmiFS7fuCsBeCv8CM/ZrA SHsnChAHd2QT87u7mshnhucj2oZw/Bo6ii/kmFPVkPoFsM336M67atxTbKDEIFfXgfL55invSrb VtmpRMdLnICRLH3OSnjU3TINr6s6sbLfoydCzQDMOrlBkQa9qFsJM5lajW8KVawV8+oOjgHW/3z i6gThtqWT6dMLWZRRFUUErNEX81EB3nyYl4u5Yq43NgkEqAN0RfS0Ip2eEHnwa2S8rkvtFcbDsz p3K5gqDjoczmuoPCq1DHoTAgYx154moSQyCBYrTSe5KpHN17R4k0L68Ij/yq0PRS1Axoykn0nN6 XDQRgqq/s9DvLvr7P0yszgODJXuFIizUmqfqTWsl4nVYwIRGQa1+3JijYrAOMqmhG/M0o4/0MHw zu2JowBZt/2+KOWzz X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [mpls] 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: Tue, 26 Feb 2019 15:11:16 -0000 Hey Robert, Some detailed responses. The revision will be posted when the authors have signed off. Regards, Adrian > The 2nd sentence of the introduction is complex. It should > be easy to simplify. Done > 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) Used RFC 6790. > In that same paragraph, something is wrong at "make use of entropy > label mechanism." Should that be "the entropy label mechanism"? Yes. I have done some gardening. > SRGB is used without expansion. Fixed. > 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. The concept of an SRGB is defined in RFC 8402. I've added a reference to = this at the first use of 'SRGB'. > Section 3.1 is about ostensibly about constructing a FIB entry, but = its > last step is sending a packet. 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. > The first sentence in section 3.2 is more complex than it needs to be. = It > should be easy to simplify. OK > 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): 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. > At the first paragraph on page 9: s/and then process/and then = processes/ Yes From royi.zigler@broadcom.com Tue Feb 26 04:12: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 7D71C130EC0 for ; Tue, 26 Feb 2019 04:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 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_DBL_SPAM=2.5] autolearn=no 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 N61m8zYuYD9A for ; Tue, 26 Feb 2019 04:12:29 -0800 (PST) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 69180130EB9 for ; Tue, 26 Feb 2019 04:12:26 -0800 (PST) Received: by mail-ot1-x330.google.com with SMTP id b3so10865578otp.4 for ; Tue, 26 Feb 2019 04:12:26 -0800 (PST) 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 :cc; bh=bC3qeXr59laHgbEHGec3QZ2p5k7R9w6KoO4bXcuZQxk=; b=CpgFocwEHqOl66P5mYPmwdVgeN5wxnECSj506n0Hv+NpO2rWxO0irObSwFa//s+SEW IeAAWV9+vly4QmWJlVWkntQMjsC1bf1ZnYPYwFIH15rkbr566GEWYFJgAITGKKNwN61D 1V6fIE6Xj18olPoUS9szJ0o0Kv+LxeRbRAkAE= 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=bC3qeXr59laHgbEHGec3QZ2p5k7R9w6KoO4bXcuZQxk=; b=EEFeWTkime/a+Z4irlVJnu3jmEK1UUPcx76gucc0MhOqyZJgJUiZMhANipp3YdeYV7 wimmu3UyOsFvn9nhnL1DYUx23PKkMUXDjWWWHeFTXK+ItorkuqbsTQmMdZJGM84LhDTX Jv1vFqv8zJvhcvi9BKuvSodfX1hFA1U0DInjcu4uTDxrG2cCwlfWeOvby0L6ZFfZC0bM vf4E4zCJK+pZk9kXvmuH4bbkNDBQaJCQ2r/pL7bSWYCWuBRzecrkN19a5U0L+3DlGnNn kqs3J2kTDTomqnOg3LM/lo2GiUhnQtBrTDOCph68bekskhcO90bElORpYG3eIxOL8mEb YaRQ== X-Gm-Message-State: AHQUAubu6DxnVvSsJlAl0q39dPmNk6CjHeixs6zhGV5cuWYxsy47nWE1 J7KIl87re1owsaRUGR+hfX5Hd+SlKNoM2ttXzcVl6A== X-Google-Smtp-Source: AHgI3IZ3QgtCHnNoVzehckB/9f3IlHlr0PtxLgggdNntgFStmqWIlCZQjttWonYkK+/7fjCGCEN2hUx+BypPyb2m+wI= X-Received: by 2002:a9d:51c9:: with SMTP id d9mr15464500oth.94.1551183145271; Tue, 26 Feb 2019 04:12:25 -0800 (PST) MIME-Version: 1.0 References: <0980ce7c-047c-519f-e7d5-98d32b498482@pi.nu> <9419b7d7-87ef-151f-5ed8-b0f78c6e83af@gmail.com> <050301d4c590$445f5d50$cd1e17f0$@com> <9d7a2690-6ef4-438a-6ca8-0548ad2aca0e@pi.nu> <13cb42a8-e298-c3cc-d116-219f144f5357@pi.nu> <886d0aeb-281e-984a-9c9d-645101d4d02b@pi.nu> In-Reply-To: From: Royi Zigler Date: Tue, 26 Feb 2019 14:11:56 +0200 Message-ID: To: "Chengli (Cheng Li)" Cc: Loa Andersson , Greg Mirsky , "mpls@ietf.org" , spring , Weiqiang Cheng , "draft-cheng-spring-mpls-path-segment@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005b315d0582caf888" Archived-At: Subject: Re: [mpls] [spring] to progress draft-cheng-spring-mpls-path-segment 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 Feb 2019 15:17:45 -0000 --0000000000005b315d0582caf888 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 support WG adoption. (Sorry for late reply) On Mon, Feb 25, 2019 at 4:32 AM Chengli (Cheng Li) wrote: > Hi Loa and Greg, > > Yes, you are right. > > The "B->C SubPath" in the first figure needs to be identical to the "B->C > SubPath" in the second. > > Many thanks for your discussion on this, a very interesting question! > > Thanks, > Cheng > > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Saturday, February 23, 2019 4:16 PM > To: Greg Mirsky > Cc: mpls@ietf.org; spring ; Weiqiang Cheng < > chengweiqiang@chinamobile.com>; > draft-cheng-spring-mpls-path-segment@ietf.org > Subject: Re: [mpls] [spring] to progress > draft-cheng-spring-mpls-path-segment > > Greg, > > > > On 2019-02-23 12:31, Greg Mirsky wrote: > > Hi Loa, > > another tunnel with the Path segment from node C is, in my view, very > > close to SPME tunnel. The Path segment from C is needed because Path > > segment from D is not known to the node C, cannot be associated with > > the right SR-tunnel segment, i.e., tunnel B-C. The fate sharing may be > > achieved by using exactly the same SIDs as in the A-D tunnel for the > > B-C segment. And GAL is still BoS on B-C tunnel. Are we getting closer? > > Not sure, you lose me somewhere between the "B", "C", "D", "from" and > "another". > > So let me check I was talking about > > So the stack transporting payload from B-C looks like this: > > +------------+ > ~B->C SubPath~ > +------------+ > |s-PSID(B->C)| > +------------+ > | BSID(C->D) | > +------------+ > |e-PSID(A->D)| > +------------+ > figure 1 > > The "~" at the top means that there might be more than one label that can > be popped or swapped, right? > > So the stack transporting GACh from B-C looks like this: > > +--------------+ > ~ B->C SubPath ~ > +--------------+ > | GAL | > +--------------+ > | GACh info-1 | > +--------------+ > | GACh info-2 | > +--------------+ > figure 2 > > Now my question is the "B->C SubPath" in the first figure identical to th= e > "B->C SubPath" in the second figure? > Now > -- > > > > > > > Regards, > > Greg > > > > On Fri, Feb 22, 2019 at 8:15 PM Loa Andersson > > wrote: > > > > Greg, > > > > We are close, though I hope the rules are that GAL is bottom of > stack, > > and that a packet with a GACh does not carry user payload. > > > > I should have said that "if you want a GACg for the > > > > I don't understand why we need a "new" SR tunnel, the GAL/GACh can > > ride with the GAL as bottom of stack with the label stack for > > Sub-path(B->C), right? If you put it on "another" tunnel, how do > > you guarantee fate sharing? > > > > /Loa > > > > /Loa > > > > On 2019-02-23 11:55, Greg Mirsky wrote: > > > Hi Loa, > > > I think it will be similar to SPME and we'll need to have anothe= r > > > SR-tunnel B-C with its own Path segment allocated by node C. But > GAL > > > will still be BoS. > > > > > > Regards, > > > Greg. > > > > > > On Fri, Feb 22, 2019 at 6:15 PM Loa Andersson > > > > >> wrote: > > > > > > Rakesh, authors, > > > > > > I have not been thinking about this too much. But if you loo= k > > at fig 2 > > > of draft-cheng-spring-mpls-path-segment, and you need a GACh > > between > > > A and D, I'd say that the GAL will be at the bottom of stack= . > > > > > > What if you need the CACh for the sub-path B to C, where wil= l > > the GAL > > > go? > > > > > > /Loa > > > > > > > > > > > > On 2019-02-23 09:25, Rakesh Gandhi wrote: > > > > Hi Greg, > > > > > > > > I am not sure if the question has been answered. I would > think > > > GAL is at > > > > the bottom of the label stack. > > > > > > > > Thanks, > > > > Rakesh > > > > > > > > > > > > On Sat, Feb 16, 2019 at 4:24 PM Greg Mirsky > > > > > > > > > > > > >>> wrote: > > > > > > > > Hi Weiqiang Cheng, > > > > thank you for your expedient response to my questions= . > The > > > document > > > > states that one of the use cases for the Path segment > > is to > > > be used > > > > as a performance, packet loss and/or delay, > > measurement session > > > > identifier. I think that RFC 6374 is the most suitabl= e > > for PM > > > OAM in > > > > SR-MPLS environment. Of course, the type of the > > > encapsulated message > > > > can be identified using the destination UDP port > > number with > > > IP/UDP > > > > encapsulation. But another option is to use G-ACh > > encapsulation. > > > > That would require the use of GAL. And that is how I'= ve > > > arrived at > > > > my original question (I should have explained it > > better, my > > > apologies): > > > > > > > > How the Path segment and GAL are placed relative > > to each > > > other > > > > in the SR-MPLS label stack? > > > > > > > > Regards, > > > > Greg > > > > > > > > On Fri, Feb 15, 2019 at 4:40 PM Weiqiang Cheng > > > > > > > > > > > > > > > > > > > >>> wrote: > > > > > > > > Hi Greg,____ > > > > > > > > Thanks a lot for your comments.____ > > > > > > > > My comments are in-line.____ > > > > > > > > __ __ > > > > > > > > B.R.____ > > > > > > > > Weiqiang Cheng____ > > > > > > > > __ __ > > > > > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:*Greg Mirsky [mailto= :gregimirsky@gmail.com > > > > > = > > > > > > > > > >>>] > > > > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:*2019=E5=B9= =B42=E6=9C=8815=E6=97=A53:37 > > > > *=E6=94=B6=E4=BB=B6=E4=BA=BA:*Alexander Vainshtei= n > > > > *=E6=8A=84=E9=80=81:*spring@ietf..org > > > > > > > > >>; Stewart Bryant; > > > > draft-cheng-spring-mpls-path-segment@ietf.org > > > > > > > > > > > > > > > > > > >>; > > > > mpls@ietf.org > > > > > >>; Loa Andersso= n > > > > *=E4=B8=BB=E9=A2=98:*Re: [spring] to progress > > > > draft-cheng-spring-mpls-path-segment____ > > > > > > > > __ __ > > > > > > > > Dear All,____ > > > > > > > > I concur with all what has been said in support o= f > the > > > adoption > > > > of this draft by SPRING WG. The document is > > well-written, > > > > addresses the real problem in SR-MPLS, and the > > proposed > > > solution > > > > is technically viable.____ > > > > > > > > My comments and questions are entirely for furthe= r > > > discussion:____ > > > > > > > > * would the draft be expanded to demonstrate ho= w > > "the Path > > > > Segment may be used to identify an SR-MPLS > > Policy, its > > > > Candidate-Path (CP) or a SID List (SL)"?____ > > > > > > > > [Weiqiang] Yes, It is necessary and we will add > > some text to > > > > demonstrate this in the future version. ____ > > > > > > > > * as many use cases for the Path Segment are > > related to OAM > > > > operations, it would be helpful to expand on > > the use > > > of GAL > > > > and the Path Segment.____ > > > > > > > > [Weiqiang] It is always helpful to have more use > > cases. > > > However, > > > > The GAL is used today in MPLS-TP LSPs to flag the > > G-Ach > > > and is > > > > used for OAM packets only while the Path segment > > is used for > > > > data packets for the each traffic flow. It is a > > little bit > > > > different. ____ > > > > > > > > Regards,____ > > > > > > > > Greg____ > > > > > > > > __ __ > > > > > > > > On Thu, Feb 14, 2019 at 1:12 AM Alexander > Vainshtein > > > > > > > > > > > > >>> wrote:____ > > > > > > > > +1.____ > > > > > > > > ____ > > > > > > > > I have been following this draft from its -00 > > > revision. The > > > > current revision has resolved most of the > > issues I (and > > > > others) have been raised (e.g., elimination o= f > > excessive > > > > options).____ > > > > > > > > ____ > > > > > > > > From my POV, in its current state the draft > meets > > > two basic > > > > requirements for the WG adoption:____ > > > > > > > > 1.It addresses a real and relevant problem, > namely > > > the MPLS > > > > Flow Identification problem discussed in > > general in > > > RFC 8372 > > > > and > > scoped to > > > SR-MPLS > > > > LSPs in this draft. Specifics of SR-MPLS > > include the > > > need to > > > > provide end-to-end liveness check that is one > > of the > > > > requirements explicitly specified in Section = 2 > > of RFC > > > 8355 > > > > . ____ > > > > > > > > 2.It provides a reasonable (from my POV) > > approach to > > > > solution of this problem.____ > > > > > > > > ____ > > > > > > > > I also concur with Stewart=E2=80=99s comment = about > strong > > > similarity > > > > between the approach taken in this draft for > > SR-MPLS and > > > > generic work in progress on synonymous flow > labels > > > > > > > < > https://tools.ietf.org/html/draft-ietf-mpls-sfl-framework-04> > > > > that has been already adopted as a MPLS WG > > item. To > > > me this > > > > is yet another indication that the draft > should be > > > adopted.____ > > > > > > > > ____ > > > > > > > > My 2c,____ > > > > > > > > Sasha____ > > > > > > > > ____ > > > > > > > > Office: +972-39266302____ > > > > > > > > Cell: +972-549266302____ > > > > > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > > > > > > > > > > > > >>____ > > > > > > > > ____ > > > > > > > > -----Original Message----- > > > > From: spring > > > > spring-bounces@ietf.org>> > > > > > > > > > >>> On Behalf Of Stewart Bryant > > > > Sent: Wednesday, February 13, 2019 12:48 PM > > > > To: Loa Andersson > > > > >>>; > > > > spring@ietf.org > > > > > > > > >>; > > > > draft-cheng-spring-mpls-path-segment@ietf.org > > > > > > > > > > > > > > > > > > >> > > > > Subject: Re: [spring] to progress > > > > draft-cheng-spring-mpls-path-segment____ > > > > > > > > ____ > > > > > > > > I have just read the draft and agree that it > > should be > > > > adopted by the WG. It solves an important > > problem in > > > > instrumenting and protecting an SR path.____ > > > > > > > > ____ > > > > > > > > It should be noted that we needed to do > > something very > > > > similar in mainstream MPLS via the synonymous > > label work > > > > which is already adopted. ____ > > > > > > > > However SL did not address the SR case.. We > > therefore > > > need > > > > this path label work to be progressed.____ > > > > > > > > ____ > > > > > > > > - Stewart____ > > > > > > > > ____ > > > > > > > > On 10/02/2019 08:11, Loa Andersson wrote:____ > > > > > > > > > Working Group,____ > > > > > > > > > ____ > > > > > > > > > I have reviewed > > > draft-cheng-spring-mpls-path-segment and as far as I ____ > > > > > > > > > can see, it is ready for wg adoption.____ > > > > > > > > > ____ > > > > > > > > > There were some comments in Bangkok, but du= e > > to the > > > many collisions ____ > > > > > > > > > between working groups at that meeting I > > couldn't > > > attend the SPRING ____ > > > > > > > > > f2f.____ > > > > > > > > > ____ > > > > > > > > > The minutes are not clear, but as far as I > > > understand, there is ____ > > > > > > > > > nothing that can't be resolved in the wg > > process.____ > > > > > > > > > ____ > > > > > > > > > /Loa____ > > > > > > > > ____ > > > > > > > > > > ___________________________________________________ > > > > > > > > spring mailing list____ > > > > > > > > spring@ietf.org > > > > > > > > >>____ > > > > > > > > https://www..ietf.org/mailman/listinfo/spring____ > > > > > > > > > > > > > > > > > > > > > > > ________________________________________________________________________= ___ > > > > > > > > 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____ > > > > > > > > _______________________________________________ > > > > spring mailing list > > > > spring@ietf.org > > > > > > > > >> > > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > > > > -- > > > > > > > > > Loa Andersson email: loa@pi.nu > > > > > > Senior MPLS Expert > > > Bronze Dragon Consulting phone: +46 739 81 21 64 > > > > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > -- > > > > > > Loa Andersson email: loa@pi.nu loa@pi.nu> > > Senior MPLS Expert > > Bronze Dragon Consulting phone: +46 739 81 21 64 > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > > > -- > > > 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 > --=20 Thanks, RoyiJZ --0000000000005b315d0582caf888 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 support WG adoption.
(Sorry for late= reply)=C2=A0

On Mon, Feb 25, 2019 at 4:32 AM Chengli (Cheng Li) &= lt;chengli13@huawei.com> wro= te:
Hi Loa and G= reg,

Yes, you are right.

The "B->C SubPath" in the first figure needs to be identical t= o the "B->C SubPath" in the second.

Many thanks for your discussion on this, a very interesting question!

Thanks,
Cheng

-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson
Sent: Saturday, February 23, 2019 4:16 PM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: mpls@ietf.org; s= pring <spring@ietf.= org>; Weiqiang Cheng <chengweiqiang@chinamobile.com>; draf= t-cheng-spring-mpls-path-segment@ietf.org
Subject: Re: [mpls] [spring] to progress draft-cheng-spring-mpls-path-segme= nt

Greg,



On 2019-02-23 12:31, Greg Mirsky wrote:
> Hi Loa,
> another tunnel with the Path segment from node C is, in my view, very =
> close to SPME tunnel. The Path segment from C is needed because Path <= br> > segment from D is not known to the node C, cannot be associated with <= br> > the right SR-tunnel segment, i.e., tunnel B-C. The fate sharing may be=
> achieved by using exactly the same SIDs as in the A-D tunnel for the <= br> > B-C segment. And GAL is still BoS on B-C tunnel. Are we getting closer= ?

Not sure, you lose me somewhere between the "B", "C", &= quot;D", "from" and "another".

So let me check I was talking about

So the stack transporting payload from B-C looks like this:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0~B->C SubPath~
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|s-PSID(B->C)|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| BSID(C->D) |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|e-PSID(A->D)|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 figure 1

The "~" at the top means that there might be more than one label = that can be popped or swapped, right?

So the stack transporting GACh from B-C looks like this:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0~ B->C SubPath ~
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0GAL=C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 GACh info-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 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 GACh info-2 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 figure 2

Now my question is the "B->C SubPath" in the first figure iden= tical to the "B->C SubPath" in the second figure?
Now
--



>
> Regards,
> Greg
>
> On Fri, Feb 22, 2019 at 8:15 PM Loa Andersson <loa@pi.nu
> <mailto:loa@pi.nu>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Greg,
>
>=C2=A0 =C2=A0 =C2=A0We are close, though I hope the rules are that GAL = is bottom of stack,
>=C2=A0 =C2=A0 =C2=A0and that a packet with a GACh does not carry user p= ayload.
>
>=C2=A0 =C2=A0 =C2=A0I should have said that "if you want a GACg fo= r the
>
>=C2=A0 =C2=A0 =C2=A0I don't understand why we need a "new"= ; SR tunnel, the GAL/GACh can
>=C2=A0 =C2=A0 =C2=A0ride with the GAL as bottom of stack with the label= stack for
>=C2=A0 =C2=A0 =C2=A0Sub-path(B->C), right? If you put it on "an= other" tunnel, how do
>=C2=A0 =C2=A0 =C2=A0you guarantee fate sharing?
>
>=C2=A0 =C2=A0 =C2=A0/Loa
>
>=C2=A0 =C2=A0 =C2=A0/Loa
>
>=C2=A0 =C2=A0 =C2=A0On 2019-02-23 11:55, Greg Mirsky wrote:
>=C2=A0 =C2=A0 =C2=A0 > Hi Loa,
>=C2=A0 =C2=A0 =C2=A0 > I think it will be similar to SPME and we'= ;ll need to have another
>=C2=A0 =C2=A0 =C2=A0 > SR-tunnel B-C with its own Path segment alloc= ated by node C. But GAL
>=C2=A0 =C2=A0 =C2=A0 > will still be BoS.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Regards,
>=C2=A0 =C2=A0 =C2=A0 > Greg.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On Fri, Feb 22, 2019 at 6:15 PM Loa Andersson= <loa@pi.nu
>=C2=A0 =C2=A0 =C2=A0<mailto:loa@pi.nu>
>=C2=A0 =C2=A0 =C2=A0 > <mailto:loa@pi.nu <mailto:loa@pi.nu>>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Rakesh, authors,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I have not been thinking a= bout this too much. But if you look
>=C2=A0 =C2=A0 =C2=A0at fig 2
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0of draft-cheng-spring-mpls= -path-segment, and you need a GACh
>=C2=A0 =C2=A0 =C2=A0between
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0A and D, I'd say that = the GAL will be at the bottom of stack.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0What if you need the CACh = for the sub-path B to C, where will
>=C2=A0 =C2=A0 =C2=A0the GAL
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0go?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0/Loa
>=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=A0On 2019-02-23 09:25, Rakes= h Gandhi wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Hi Greg,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > I am not sure if the= question has been answered. I would think
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0GAL is at
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > the bottom of the la= bel stack.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Thanks,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Rakesh
>=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 > On Sat, Feb 16, 2019= at 4:24 PM Greg Mirsky
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<gregimirsky@gmail.com <mailto:<= a href=3D"mailto:gregimirsky@gmail.com" target=3D"_blank">gregimirsky@gmail= .com>
>=C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > <mailto:gregimirsky@gmail.com
>=C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com
>=C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com>>>> wrote:
>=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=A0H= i=C2=A0Weiqiang Cheng,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0t= hank you for your expedient response to my questions. The
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0document
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0s= tates that one of the use cases for the Path segment
>=C2=A0 =C2=A0 =C2=A0is to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0be used
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0a= s a performance, packet loss and/or delay,
>=C2=A0 =C2=A0 =C2=A0measurement session
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0i= dentifier. I think that RFC 6374 is the most suitable
>=C2=A0 =C2=A0 =C2=A0for PM
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0OAM in
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0S= R-MPLS environment. Of course, the type of the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0encapsulated=C2=A0message<= br> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0c= an be identified using the destination UDP port
>=C2=A0 =C2=A0 =C2=A0number with
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0IP/UDP
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0e= ncapsulation. But another option is to use G-ACh
>=C2=A0 =C2=A0 =C2=A0encapsulation.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0T= hat would require the use of GAL. And that is how I've
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0arrived at
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0m= y original question (I should have explained it
>=C2=A0 =C2=A0 =C2=A0better, my
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0apologies):
>=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=A0How the Path segment and GAL are placed relative
>=C2=A0 =C2=A0 =C2=A0to each
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0other
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0in the SR-MPLS label stack?
>=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=A0R= egards,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0G= reg
>=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=A0O= n Fri, Feb 15, 2019 at 4:40 PM Weiqiang Cheng
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0&= lt;cheng= weiqiang@chinamobile.com
>=C2=A0 =C2=A0 =C2=A0<mailto:chengweiqiang@chinamobile.com>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:chengweiqiang@chinamobi= le.com
>=C2=A0 =C2=A0 =C2=A0<mailto:chengweiqiang@chinamobile.com>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0&= lt;mailto:chengweiqiang@chinamobile.com
>=C2=A0 =C2=A0 =C2=A0<mailto:chengweiqiang@chinamobile.com>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:chengweiqiang@chinamobi= le.com
>=C2=A0 =C2=A0 =C2=A0<mailto:chengweiqiang@chinamobile.com>>>>= ; wrote:
>=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=A0Hi Greg,____
>=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=A0Thanks a lot for your comments.____
>=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=A0My comments are in-line.____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0__ __
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0B.R.____
>=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=A0Weiqiang Cheng____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0__ __
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0*=E5=8F=91=E4=BB=B6=E4=BA=BA:*Greg Mirsky [mailto:gregimirsky@gmail.com >=C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail..com>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com <m= ailto:gregimirsk= y@gmail.com>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0<mailto:gregimirsky@gmail..com
>=C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com <m= ailto:gregimirsk= y@gmail.com>>>]
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0*=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:*2019=E5=B9=B42=E6=9C=88= 15=E6=97=A53:37
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0*=E6=94=B6=E4=BB=B6=E4=BA=BA:*Alexander Vainshtein
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0*=E6=8A=84=E9=80=81:*spring@ietf..org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>>>; Stewart Bryant;
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > draft-cheng-= spring-mpls-path-segment@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:draft-cheng-spring-mpls-path-seg= ment@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:draft-c= heng-spring-mpls-path-segment@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:draft-cheng-spring-mpls-path-seg= ment@ietf.org>>
>=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<mailto:draft-cheng-spring-mpls-p= ath-segment@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:draft-cheng-spring-mpls-path-seg= ment@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:draft-c= heng-spring-mpls-path-segment@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:draft-cheng-spring-mpls-path-seg= ment@ietf.org>>>;
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > mpls@ietf.org <mailto:mpls@ietf.org> <mailto:mpls@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:mpls@ietf.org>> <mailto:mpls@ietf.org <mailto:mpls@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:mpls@ietf.org <mailto:mpls@ietf.org>>>; Loa= Andersson
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0*=E4=B8=BB=E9=A2=98:*Re: [spring] to progress
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0draft-cheng-spring-mpls-path-segment____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0__ __
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Dear All,____
>=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=A0I concur with all what has been said in support of the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0adoption
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0of this draft by SPRING WG. The document is
>=C2=A0 =C2=A0 =C2=A0well-written,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0addresses the real problem in SR-MPLS, and the
>=C2=A0 =C2=A0 =C2=A0proposed
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0solution
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0is technically viable.____
>=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=A0My comments and questions are entirely for further
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0discussion:____
>=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* would the=C2=A0draft be expanded to demonstrate how >=C2=A0 =C2=A0 =C2=A0"the Path
>=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=A0Segment may be used to identify an SR-MPLS
>=C2=A0 =C2=A0 =C2=A0Policy, its
>=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=A0Candidate-Path (CP) or a SID List (SL)"?___= _
>=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[Weiqiang] Yes, It is necessary and=C2=A0we will add
>=C2=A0 =C2=A0 =C2=A0some text to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0demonstrate this in the future version. ____
>=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* as many use cases for the Path Segment are
>=C2=A0 =C2=A0 =C2=A0related to OAM
>=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=A0operations, it would be helpful to expand on
>=C2=A0 =C2=A0 =C2=A0the use
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0of GAL
>=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=A0and the Path Segment.____
>=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[Weiqiang] It is always helpful to have more use
>=C2=A0 =C2=A0 =C2=A0cases.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0However,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0The GAL is used today in MPLS-TP LSPs to flag the
>=C2=A0 =C2=A0 =C2=A0G-Ach
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0and is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0used for OAM packets only while the Path segment
>=C2=A0 =C2=A0 =C2=A0is used for
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0data packets for the each traffic flow. It is a
>=C2=A0 =C2=A0 =C2=A0little bit
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0different. ____
>=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=A0Regards,____
>=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=A0Greg____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0__ __
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0On Thu, Feb 14, 2019 at 1:12 AM Alexander Vainshtein
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0<Alexander.Vainshtein@ecitele..com
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0<mailto:Alexander.Vainshtein@ecitele.com
>=C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein@ecitele.com>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein= @ecitele.com
>=C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein@ecitele.com>>&= gt;> wrote:____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0+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 =C2=A0____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0I have been following this draft from its -00 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0revision. The
>=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=A0current revision has resolved most of the
>=C2=A0 =C2=A0 =C2=A0issues I (and
>=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=A0others) have been raised (e.g., elimination of >=C2=A0 =C2=A0 =C2=A0excessive
>=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=A0options).____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>=C2=A0 =C2=A0 =C2=A0 >=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 From my POV, in its current state the draft mee= ts
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0two basic
>=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=A0requirements for the WG adoption:____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A01.It addresses a real and relevant problem, name= ly
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the MPLS
>=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=A0Flow Identification problem discussed in
>=C2=A0 =C2=A0 =C2=A0general in
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0RFC 8372
>=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<https://tools.ietf.org/html/rfc837= 2> and
>=C2=A0 =C2=A0 =C2=A0scoped to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0SR-MPLS
>=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=A0LSPs in this draft. Specifics of SR-MPLS
>=C2=A0 =C2=A0 =C2=A0include the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0need to
>=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=A0provide end-to-end liveness check that is one >=C2=A0 =C2=A0 =C2=A0of the
>=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=A0requirements explicitly specified in Section 2 >=C2=A0 =C2=A0 =C2=A0of RFC
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A08355
>=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<https://tools.ietf.org/html/rfc835= 5>. ____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A02.It provides a reasonable (from my POV)
>=C2=A0 =C2=A0 =C2=A0approach to
>=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=A0solution of this problem.____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>=C2=A0 =C2=A0 =C2=A0 >=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=A0I also concur with Stewart=E2=80=99s comment abo= ut strong
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0similarity
>=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=A0between the approach taken in this draft for
>=C2=A0 =C2=A0 =C2=A0SR-MPLS and
>=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=A0generic work in progress on synonymous flow labe= ls
>=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<https://tools.ietf.org/html/draft-ietf-mpls-sfl-framewo= rk-04>
>=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=A0that has been already adopted as a MPLS WG
>=C2=A0 =C2=A0 =C2=A0item.=C2=A0 To
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0me this
>=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=A0is yet another indication that the draft should = be
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0adopted.____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>=C2=A0 =C2=A0 =C2=A0 >=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=A0My 2c,____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Sasha____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>=C2=A0 =C2=A0 =C2=A0 >=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=A0Office: +972-39266302____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-5492663= 02____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Email: Alexander.Vainshtein@ecitele.com
>=C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein@ecitele.com>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein= @ecitele.com
>=C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein@ecitele.com>><= br> >=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<mailto:Alexander.Vainshtein@ecitele.com
>=C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein@ecitele.com>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein= @ecitele.com
>=C2=A0 =C2=A0 =C2=A0<mailto:Alexander.Vainshtein@ecitele.com>>&= gt;____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>=C2=A0 =C2=A0 =C2=A0 >=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-----Original Message-----
>=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=A0From: spring <spring-bounces@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:spring-bounces@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:spring-bounces@ietf.org &= lt;mailto:spri= ng-bounces@ietf.org>>
>=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<mailto:spring-bounces@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:spring-bounces@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:spring-bounces@ietf.org >=C2=A0 =C2=A0 =C2=A0<mailto:spring-bounces@ietf.org>>>> On Behalf = Of 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=A0Sent: Wednesday, February 13, 2019 12:48 PM
>=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=A0To: Loa Andersson <loa@pi..nu
>=C2=A0 =C2=A0 =C2=A0<mailto:loa@pi.nu <mailto:loa@pi.nu>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:loa@pi.nu <mailto:loa@pi.nu>>>>;
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>>&= gt;;
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > draft-cheng-= spring-mpls-path-segment@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:draft-cheng-spring-mpls-path-seg= ment@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:draft-c= heng-spring-mpls-path-segment@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:draft-cheng-spring-mpls-path-seg= ment@ietf.org>>
>=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<mailto:draft-cheng-spring-mpls-p= ath-segment@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:draft-cheng-spring-mpls-path-seg= ment@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:draft-c= heng-spring-mpls-path-segment@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:draft-cheng-spring-mpls-path-seg= ment@ietf.org>>>
>=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=A0Subject: Re: [spring] to progress
>=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=A0draft-cheng-spring-mpls-path-segment____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>=C2=A0 =C2=A0 =C2=A0 >=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=A0I have just read the draft and agree that it
>=C2=A0 =C2=A0 =C2=A0should be
>=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=A0adopted by the WG. It solves an important
>=C2=A0 =C2=A0 =C2=A0problem in
>=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=A0instrumenting and protecting an SR path.____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>=C2=A0 =C2=A0 =C2=A0 >=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=A0It should be noted that we needed to do
>=C2=A0 =C2=A0 =C2=A0something very
>=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=A0similar in mainstream MPLS via the synonymous >=C2=A0 =C2=A0 =C2=A0label work
>=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=A0which is already adopted. ____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0However SL did not address the SR case.. We
>=C2=A0 =C2=A0 =C2=A0therefore
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0need
>=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=A0this path label work to be progressed.____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>=C2=A0 =C2=A0 =C2=A0 >=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- Stewart____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>=C2=A0 =C2=A0 =C2=A0 >=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=A0On 10/02/2019 08:11, Loa Andersson wrote:____ >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> Working Group,____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> ____
>=C2=A0 =C2=A0 =C2=A0 >=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> I have reviewed
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0draft-cheng-spring-mpls-pa= th-segment and as far as I ____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> can see, it is ready for wg adoption.____ >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> ____
>=C2=A0 =C2=A0 =C2=A0 >=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> There were some comments in Bangkok, but du= e
>=C2=A0 =C2=A0 =C2=A0to the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0many collisions ____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> between working groups at that meeting I >=C2=A0 =C2=A0 =C2=A0couldn't
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0attend the SPRING ____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> f2f.____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> ____
>=C2=A0 =C2=A0 =C2=A0 >=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> The minutes are not clear, but as far as I<= br> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0understand, there is ____<= br> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> nothing that can't be resolved in the w= g
>=C2=A0 =C2=A0 =C2=A0process.____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> ____
>=C2=A0 =C2=A0 =C2=A0 >=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> /Loa____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0____________________________________________= _______
>=C2=A0 =C2=A0 =C2=A0 >=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=A0spring mailing list____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>>&= gt;____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > https://www..ietf.org/mailman/listinfo/spring____
>=C2=A0 =C2=A0 =C2=A0<http://ietf.org/mailman/listi= nfo/spring____>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<http= ://ietf.org/mailman/listinfo/spring____>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0____________________________________________= _______________________________
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0This e-mail message is intended for the recipien= t
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0only and
>=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=A0contains information which is
>=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=A0CONFIDENTIAL and which may be proprietary to ECI=
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Telecom. If
>=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=A0you have received this
>=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=A0transmission in error, please inform us by e-mai= l,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0phone or
>=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=A0fax, and then delete the original
>=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=A0and all copies thereof.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0____________________________________________= ___________________________________
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=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_______________________________________________<= br> >=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=A0spring mailing list
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>>&= gt;
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/spring____
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0_= ______________________________________________
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0s= pring mailing list
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:spring@ietf.org <mailto:spring@ietf.org>>&= gt;
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > h= ttps://www.ietf.org/mailman/listinfo/spring
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Loa 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 emai= l: loa@pi.nu
>=C2=A0 =C2=A0 =C2=A0<mailto:loa@pi.nu> <mailto:loa@pi.nu <mailto:loa@pi.nu>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Senior MPLS Expert
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Bronze Dragon Consulting= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > _____________________________________________= __
>=C2=A0 =C2=A0 =C2=A0 > spring mailing list
>=C2=A0 =C2=A0 =C2=A0 > spring@ietf.org <mailto:spring@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mailm= an/listinfo/spring
>=C2=A0 =C2=A0 =C2=A0 >
>
>=C2=A0 =C2=A0 =C2=A0--
>
>
>=C2=A0 =C2=A0 =C2=A0Loa 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 <mailto:loa@pi.nu>
>=C2=A0 =C2=A0 =C2=A0Senior MPLS Expert
>=C2=A0 =C2=A0 =C2=A0Bronze Dragon Consulting=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring >

--


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


--
Thanks,RoyiJZ
--0000000000005b315d0582caf888-- From faisal.iqbal@msn.com Tue Feb 26 10:06: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 DF820124408; Tue, 26 Feb 2019 10:06:21 -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, 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=msn.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 JIl_u2OdAVkj; Tue, 26 Feb 2019 10:06:19 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-oln040092003069.outbound.protection.outlook.com [40.92.3.69]) (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 74522129524; Tue, 26 Feb 2019 10:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=msn.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cGUEhMz2PSqPaD8yW9aY4qKiAf7XKC1863LjwrLHi10=; b=a1Q4aHCNpEAZtkVNaccWLh0lFp4pXjRaYBqk/+NyjTop3BtUWnJnq/fuvNJZ6I3D0V+pwXxyMzHpd4MuPud7wInjW6pTQEvw32jGhrDxGS1z6a0Kw96/CLbpyZ5mrsU/nY3IoSyHUbPUeb4LPpYxItMukAEWAbsbNA0mQZ+68xl0KfI3AsXg551rnQTCK6hr7xzp4XQ2pJGynB+F9Wd92rAfJcalk5WzgSHoa8SUEhvcNFw+CseGCCK7bhh7JUgwvm1b8zdut7YRxxnMiu1oRq5cUC77qzpyndUWQgtKvIKstBfCamuLmU6Ruo0FKQgV7mMlX6sHMnY3yGGkGP0GYw== Received: from CY1NAM02FT025.eop-nam02.prod.protection.outlook.com (10.152.74.56) by CY1NAM02HT097.eop-nam02.prod.protection.outlook.com (10.152.75.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.11; Tue, 26 Feb 2019 18:06:17 +0000 Received: from MN2PR18MB2992.namprd18.prod.outlook.com (10.152.74.52) by CY1NAM02FT025.mail.protection.outlook.com (10.152.75.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.11 via Frontend Transport; Tue, 26 Feb 2019 18:06:17 +0000 Received: from MN2PR18MB2992.namprd18.prod.outlook.com ([fe80::5d:695:123:4041]) by MN2PR18MB2992.namprd18.prod.outlook.com ([fe80::5d:695:123:4041%7]) with mapi id 15.20.1643.019; Tue, 26 Feb 2019 18:06:17 +0000 From: Faisal Iqbal To: Loa Andersson , "mpls@ietf.org" CC: "draft-nainar-mpls-rfc8287-len-clarification@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: IPR poll on draft-nainar-mpls-rfc8287-len-clarification Thread-Index: AQHUzaIaf2vuK0yOPUWtFwJsVaIH0KXyYF8o Date: Tue, 26 Feb 2019 18:06:17 +0000 Message-ID: References: <98cdd254-2bf8-4bac-ebbc-c8645ab8e0ea@pi.nu> In-Reply-To: <98cdd254-2bf8-4bac-ebbc-c8645ab8e0ea@pi.nu> Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:5A5687C8598CC9D3C19FEC0F633E48B458A6AB32F8CC69894898452E56C469E4; UpperCasedChecksum:767FB896069902A053C32961007A30458FB6870C3925D5088B05E8A4DE9E1D80; SizeAsReceived:6981; Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [pRIdP0tJExxbeXbaf3zmMJRRuYEhND5z] x-ms-publictraffictype: Email x-incomingheadercount: 45 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322404)(2017031324274)(2017031323274)(1601125500)(1603101475)(1701031045); SRVR:CY1NAM02HT097; x-ms-traffictypediagnostic: CY1NAM02HT097: x-microsoft-antispam-message-info: iC5ObuNDUOKrQZTECilhcDx16WT+IAb96hAGGENedUJKOadQkK6or4wSYx6AEIuE Content-Type: multipart/alternative; boundary="_000_MN2PR18MB299235603D9FA727EB35E2EA8C7B0MN2PR18MB2992namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 0ab3f270-59c3-4899-2d94-08d69c151ab5 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2019 18:06:17.5050 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1NAM02HT097 Archived-At: Subject: Re: [mpls] IPR poll on 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: Tue, 26 Feb 2019 21:32:59 -0000 --_000_MN2PR18MB299235603D9FA727EB35E2EA8C7B0MN2PR18MB2992namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Loa, I'm not aware of any IPR related to this document. Regards, Faisal ________________________________ From: Loa Andersson Sent: February 26, 2019 12:08 AM To: mpls@ietf.org Cc: draft-nainar-mpls-rfc8287-len-clarification@ietf.org; mpls-chairs@ietf.= org Subject: IPR poll on draft-nainar-mpls-rfc8287-len-clarification Working Group, authors, We have started to prepare draft-nainar-mpls-rfc8287-len-clarification for working group adoption, prior to the wgap we need to do an IPR poll. This mail starts this IPR poll. Are you aware of any IPR that applies to draft-nainar-mpls-rfc8287-len-clarification? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There no IPR disclosures against draft-nainar-mpls-rfc8287-len- clarification. 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. /Loa mpls wg co-chair -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 --_000_MN2PR18MB299235603D9FA727EB35E2EA8C7B0MN2PR18MB2992namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Loa,
I'm not aware of any IPR related to this document.

Regards,
Faisal

From: Loa Andersson <l= oa@pi.nu>
Sent: February 26, 2019 12:08 AM
To: mpls@ietf.org
Cc: draft-nainar-mpls-rfc8287-len-clarification@ietf.org; mpls-chair= s@ietf.org
Subject: IPR poll on draft-nainar-mpls-rfc8287-len-clarification
 
Working Group, authors,

We have started to prepare draft-nainar-mpls-rfc8287-len-clarification
for working group adoption, prior to the wgap we need to do an IPR poll.
This mail starts this IPR poll.

Are you aware of any IPR that applies to
draft-nainar-mpls-rfc8287-len-clarification?

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

There no IPR disclosures against draft-nainar-mpls-rfc8287-len-
clarification.

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.


/Loa
  mpls wg co-chair
--


Loa Andersson          &n= bsp;            = ; email: loa@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting        &nb= sp;    phone: +46 739 81 21 64
--_000_MN2PR18MB299235603D9FA727EB35E2EA8C7B0MN2PR18MB2992namp_-- From nobody Tue Feb 26 19:13:03 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 234B9130DC0; Tue, 26 Feb 2019 19:13:02 -0800 (PST) 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=Wnhtt2bm; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Sw7tjJAW 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 zbsmVnD150OT; Tue, 26 Feb 2019 19:12:59 -0800 (PST) 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 EFC8B1274D0; Tue, 26 Feb 2019 19:12:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14723; q=dns/txt; s=iport; t=1551237179; x=1552446779; h=from:to:cc:subject:date:message-id:mime-version; bh=+ZKXDjm8W52Ox3v5+/ylEDJyA/bMeYzgqj0gJ1vxm5g=; b=Wnhtt2bmLXIqvg9DQRUIsYmg8Svzh6AQkx6HYJyoKtukhVhS+AYT93tO AxfUR3ZdMAFdF6VgxSQXJTJrOClvij8VYIbLUlh/mfsB0NoLrSmaj9uun zx5VZLV6svQ3ol91b7qfTtSfDmzNNO++6TI9tTTUxBwOqfwJJe0aFBQAE 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AFeI3xx/3f5bAef9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/YR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfJq3UeaNpJXh?= =?us-ascii?q?4Bh98RmlkyCcqEIUb6N/XtKSc9GZcKWQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAABH/3Vc/4YNJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDSNQA2d0BAsnhAiDRwOEUIsSgjIlki2FcRS?= =?us-ascii?q?BEANUCwEBGAEKCYRAAheDayI0CQ0BAwEBAgEBAm0cDIVKAQIEAQEhChMBASk?= =?us-ascii?q?DBgUBDQQBCBEDAQIeCgMCBBkMCxQJCgQBDQWDIAGBDkwDFQECDKAeAooUcYE?= =?us-ascii?q?vgngBAQWFCBiCCwMFBYxDF4FAP4ERJwwTgkyDHgEBgS4BEQIBJBEJDQmCVDG?= =?us-ascii?q?CJol9gkCDf4cdjA4JApJmGYFzhV2LSooKCUaSFQIEAgQFAg0BAQWBRzhlcXA?= =?us-ascii?q?VOyoBgkGCHINuhRSFP3KBKJExAQE?= X-IronPort-AV: E=Sophos;i="5.58,417,1544486400"; d="scan'208,217";a="514647021" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2019 03:12:57 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x1R3CvC9001990 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Feb 2019 03:12:57 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 26 Feb 2019 21:12:56 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 26 Feb 2019 21:12:56 -0600 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 26 Feb 2019 22:12:56 -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=+ZKXDjm8W52Ox3v5+/ylEDJyA/bMeYzgqj0gJ1vxm5g=; b=Sw7tjJAWJCAX+dL0LREKuWHd2BseJX1VWHIxo+eMmZ5paMNDJJ9lyD+XtB3Z7iabyLMIesayh+8Oc77lIBEt/28xzUaGHNyxfj5C2GeL1Fn0NEAShEzcCiLzowC7tmUaJIjj7gspjnGzUrfqmvTCLFxeUCUSq1iZGgEmkNOAMOA= Received: from DM6PR11MB3324.namprd11.prod.outlook.com (20.176.122.29) by DM6PR11MB3658.namprd11.prod.outlook.com (20.178.231.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.15; Wed, 27 Feb 2019 03:12:54 +0000 Received: from DM6PR11MB3324.namprd11.prod.outlook.com ([fe80::79f7:3f7b:f4a0:aee3]) by DM6PR11MB3324.namprd11.prod.outlook.com ([fe80::79f7:3f7b:f4a0:aee3%3]) with mapi id 15.20.1643.019; Wed, 27 Feb 2019 03:12:54 +0000 From: "Zafar Ali (zali)" To: "Nagendra Kumar Nainar (naikumar)" , Loa Andersson , "mpls@ietf.org" CC: "mpls-chairs@ietf.org" , "draft-nainar-mpls-rfc8287-len-clarification@ietf.org" , "Zafar Ali (zali)" Thread-Topic: [mpls] IPR poll on draft-nainar-mpls-rfc8287-len-clarification Thread-Index: AQHUzkpU8ChXWYCcxEG/Nx9ybWG1qw== Date: Wed, 27 Feb 2019 03:12:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.3.181015 x-originating-ip: [2001:420:c0c8:1002::1c4] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0a4b4921-bd0a-43fe-dc47-08d69c61776d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:DM6PR11MB3658; x-ms-traffictypediagnostic: DM6PR11MB3658: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtETTZQUjExTUIzNjU4OzIzOjFtY0RnL1BMMkpkYXdYT1hmb1laM3NxTkpI?= =?utf-8?B?cUZaU0lVZnRocisrMTUzS3FPSW53VnNwbTBEc0JrcWNxcHhQUVVXZ2Nwb1FE?= =?utf-8?B?REJlUWNFNDFxOC9xa2wrQmgwWUtxQTROZXZBZkoxSkljR3lVdDh3RzNDNjRB?= =?utf-8?B?bTV1ZmdIMUxHU2N1ZEZnQjA1b01pblBVV1Y0M1NXU04zVVdNcStQSDhpRVFI?= =?utf-8?B?QXVvZ1Bub3c3UUJFM01KbTNOMno2Z2NqTWZVaVhYQ2Y1SVlLeDZpc1B1VE12?= =?utf-8?B?Mk93WS9SSS9mRTZyVkhmR0NjYmpjNlBGNGhwRnpLYVhHclpENm9xTnNWeC9u?= =?utf-8?B?d1Uyek9qcGc1blVhRnIzRDh6dUJBaDlUcEU1dUdVWW13ZzFzM0FtZDZxUUFr?= =?utf-8?B?Tzc4YjAvOU1LTi9JSjBhQnhJQUxtMERxWUZKRXJyeXJHR01QVHdwZjZoYkl0?= =?utf-8?B?QlpiYzBXZUZBczRRc0VFTWl5d04vaCt3TE5xMmpkcVpadTMvcUMvdlU3Z1l0?= =?utf-8?B?VkZhd2pOcnNrZXZlYWNHVlpQOHNoSDVnaUVDMlY3cWk1bTRraGxQNGdjbHQ4?= =?utf-8?B?eWlONEF0ZGRmZWFIRzVvQ295VUhkY0xRNmxBeDg2cnVEWjlORXJxK21YY3pU?= =?utf-8?B?UWJlZGxtK1RjRXJIQUFkSW1MWFVOWEpsZlVvclg4N1d0Z0YwRVlGUFdjR3I4?= =?utf-8?B?K2dNR29xTjdoQ3hqMjBHMi85RURlaFgwaG1WUGNaQWhKNTBPMVhUODRzMlE0?= =?utf-8?B?NVFUdFcycGhQazJIR1ZsSnA2cGJsSWVka1UwcytRdEpMSEY2clFXbHlwd1Jj?= =?utf-8?B?Sll4aXR5Wk9OTUVwR2ZFNngvQnJmbjlsSkU4ci9qaGpHc3lNc2dkOGhBWkR5?= =?utf-8?B?SE1ya1NKZUtwMXlPRk0xZ0dOTFFESWgyUXVBTVpvUlRtT25CVU56VFlNSDhZ?= =?utf-8?B?YU5YYW5zUEtpZkkzY0tZbVlzRXBOQVlMa0F2REpNSzNBMmRpUldvZ0l2MVB2?= =?utf-8?B?UTgvQXdCNHJHazlRTXNVQm1zOUNVVGI2amI1ZHAzQ2VJOEwyem40TXdPQlgx?= =?utf-8?B?SXJXV2NoTiszQzExMDBYc2VKanhYL2syQ1ExK25yblZsUnZmOGNvQm55b2ZM?= =?utf-8?B?YnZlM21ld2VyNkNPajNXeUhGMHdrYWtTZnBhWGlpSmxVV0JnYVd1MW04TXdQ?= =?utf-8?B?L1dzZHRHbzJNaE1HdmRLblAxNVdTQmNSRitNMVN6dGNBK2lBeXYvUDlldEVS?= =?utf-8?B?RGk4K1gzU3JjbkdKMTlTTHpGajlBR3JJTWJCUU9nWTNKWHdHbE5aZi9tdE1C?= =?utf-8?B?MnFTZnd2bmN5MjdhRVJ1VTFiYlVwYVRqRzJXUW5WVEVtMFYrSmhXN0VlU21l?= =?utf-8?B?NDQ4bXg0YWFXbGFDNmNlQ3o5UmxZblVxNEFXOXg0djVjVzhPY1I5TWpHSkcz?= =?utf-8?B?YnZDM1NzN1VseCsrVUpOZm1TSmtGekEzclFBNTYxd3NraU1oMy9PaHJsLzRm?= =?utf-8?B?cG83ajhsT2pWY0poTks2dlBCT0JYcFNPRk42UUFSNDRyTXk0NjB3bS9McXF5?= =?utf-8?B?Rm1JRFFJWU1iNUU3MHFUdHg4OFlwQW1iWE93eGc0RmFMWDgwQzJoTytRcW1n?= =?utf-8?B?Tmx1YnNsdzRXNkdYajBRVzhzQXJhUHBCMEFFakhBclBIR3ZWNjVvZnZtVjF5?= =?utf-8?B?c2F1R0VmVTUwKzN1YThlZ05yNVpUT0gwZzgxT0xVNHA0bnIwMDlMb0JKUzVw?= =?utf-8?B?Smk2T2ZXNy9OQlkxRGdJd1pVRktFZ2lwdUFGNy9tandTcENidmpxNkFUenBC?= =?utf-8?Q?bLdjfsfbGEQNn?= x-microsoft-antispam-prvs: x-forefront-prvs: 0961DF5286 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(376002)(366004)(136003)(346002)(189003)(199004)(102836004)(14454004)(6346003)(53546011)(107886003)(6246003)(7736002)(790700001)(99286004)(6506007)(4326008)(478600001)(6436002)(186003)(86362001)(25786009)(83716004)(71190400001)(71200400001)(54896002)(476003)(6306002)(46003)(36756003)(8676002)(2616005)(68736007)(8936002)(81166006)(81156014)(97736004)(82746002)(6512007)(58126008)(110136005)(6486002)(54906003)(53936002)(966005)(6116002)(486006)(229853002)(256004)(105586002)(606006)(2906002)(5660300002)(316002)(2501003)(106356001)(33656002)(236005); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3658; H:DM6PR11MB3324.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=zali@cisco.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: tXZkpNybXFljId4GYuBcrothKnICcmGztsI0qa36e6lpKKSns1Kbr9nUZnZSHsBe7OlDYD81jp3bccYMZqRYdetPpo9pxA+aj39Sux9toVWi5GMgLauUGKSihnZCYEsg+9uCXW6K4PH6pFxHFjxL1FZZI1yvXYCnw3mY4zLqyepLnE0OG6m+Hd7soQ38OdvvVhurp6Z/N4wfCBiHm+xa/7uwle8o6TWgXrCX5VJgbYfSbmWWPQWZLumWVmW7uTg7o9KpTE7igG+CqKUWDQLsiIQ2TIVYRrsKC3XWsJgTX3VTUG0aHaFx5xfW+PyP1U2Ql8tZOJ1xoor6t47g81H6r2M2Ip4Pjgb7zpnKhCmOjBrDEPx3OfaFmSPjuVbvP8778yf2cFi1vfF/IgDTaOv8YkWOJkAVizlS06nPx8jtQX8= Content-Type: multipart/alternative; boundary="_000_D235D22AA53E41E18275B74FB67CD6D7ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0a4b4921-bd0a-43fe-dc47-08d69c61776d X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2019 03:12:54.7992 (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: DM6PR11MB3658 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.26, xch-aln-016.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [mpls] IPR poll on 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: Wed, 27 Feb 2019 03:13:02 -0000 --_000_D235D22AA53E41E18275B74FB67CD6D7ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9hLCBDaGFpcnMgYW5kIHRoZSBXRywNCg0KSSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiBvbiB0 aGlzIGRvY3VtZW50Lg0KDQpUaGFua3MNCg0KUmVnYXJkcyDigKYgWmFmYXINCg0KDQpGcm9tOiBt cGxzIDxtcGxzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiAiTmFnZW5kcmEgS3VtYXIg TmFpbmFyIChuYWlrdW1hcikiIDxuYWlrdW1hckBjaXNjby5jb20+DQpEYXRlOiBUdWVzZGF5LCBG ZWJydWFyeSAyNiwgMjAxOSBhdCA3OjM5IEFNDQpUbzogTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51 PiwgIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3JnPg0KQ2M6ICJtcGxzLWNoYWlyc0BpZXRm Lm9yZyIgPG1wbHMtY2hhaXJzQGlldGYub3JnPiwgImRyYWZ0LW5haW5hci1tcGxzLXJmYzgyODct bGVuLWNsYXJpZmljYXRpb25AaWV0Zi5vcmciIDxkcmFmdC1uYWluYXItbXBscy1yZmM4Mjg3LWxl bi1jbGFyaWZpY2F0aW9uQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFttcGxzXSBJUFIgcG9sbCBv biBkcmFmdC1uYWluYXItbXBscy1yZmM4Mjg3LWxlbi1jbGFyaWZpY2F0aW9uDQoNCk9uIDIvMjYv MTksIDI6MDggQU0sICJMb2EgQW5kZXJzc29uIiA8bG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+ PiB3cm90ZToNCg0KICAgIFdvcmtpbmcgR3JvdXAsIGF1dGhvcnMsDQoNCiAgICBXZSBoYXZlIHN0 YXJ0ZWQgdG8gcHJlcGFyZSBkcmFmdC1uYWluYXItbXBscy1yZmM4Mjg3LWxlbi1jbGFyaWZpY2F0 aW9uDQogICAgZm9yIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24sIHByaW9yIHRvIHRoZSB3Z2FwIHdl IG5lZWQgdG8gZG8gYW4gSVBSIHBvbGwuDQoNCiAgICBUaGlzIG1haWwgc3RhcnRzIHRoaXMgSVBS IHBvbGwuDQoNCiAgICBBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvDQog ICAgZHJhZnQtbmFpbmFyLW1wbHMtcmZjODI4Ny1sZW4tY2xhcmlmaWNhdGlvbj8NCg0KICAgIElm IHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYg SVBSIHJ1bGVzDQogICAgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1v cmUgZGV0YWlscykuDQoNCiAgICBUaGVyZSBubyBJUFIgZGlzY2xvc3VyZXMgYWdhaW5zdCBkcmFm dC1uYWluYXItbXBscy1yZmM4Mjg3LWxlbi0NCiAgICBjbGFyaWZpY2F0aW9uLg0KDQogICAgSWYg eW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNl IHJlc3BvbmQgdG8NCiAgICB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3Qg eW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQNCiAgICBJUFIuICpUaGUgcmVzcG9uc2UgbmVl ZHMgdG8gYmUgc2VudCB0byB0aGUgTVBMUyBXRyBtYWlsaW5nIGxpc3QuKiBUaGUNCiAgICBkb2N1 bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2Ug aGFzIGJlZW4NCiAgICByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBjb250cmlidXRvci4N Cg0KICAgIElmIHlvdSBhcmUgb24gdGhlIE1QTFMgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBs aXN0ZWQgYXMgYW4gYXV0aG9yIG9yDQogICAgY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxp Y2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUgb2YgYW55DQogICAgSVBSIHRoYXQg aGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVz Lg0KDQoNCiAgICAvTG9hDQogICAgICBtcGxzIHdnIGNvLWNoYWlyDQogICAgLS0NCg0KDQogICAg TG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAcGkubnU8bWFp bHRvOmxvYUBwaS5udT4NCiAgICBTZW5pb3IgTVBMUyBFeHBlcnQNCiAgICBCcm9uemUgRHJhZ29u IENvbnN1bHRpbmcgICAgICAgICAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5n IGxpc3QNCm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0K --_000_D235D22AA53E41E18275B74FB67CD6D7ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <13AD64ADC6EBAE43AD644A3FFF888B62@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxvYSwgQ2hhaXJzIGFuZCB0 aGUgV0csIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBS IG9uIHRoaXMgZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWYiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5SZWdhcmRzIOKApiBaYWZh cg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPm1wbHMgJmx0 O21wbHMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mICZxdW90O05hZ2VuZHJhIEt1 bWFyIE5haW5hciAobmFpa3VtYXIpJnF1b3Q7ICZsdDtuYWlrdW1hckBjaXNjby5jb20mZ3Q7PGJy Pg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIEZlYnJ1YXJ5IDI2LCAyMDE5IGF0IDc6MzkgQU08YnI+ DQo8Yj5UbzogPC9iPkxvYSBBbmRlcnNzb24gJmx0O2xvYUBwaS5udSZndDssICZxdW90O21wbHNA aWV0Zi5vcmcmcXVvdDsgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVv dDttcGxzLWNoYWlyc0BpZXRmLm9yZyZxdW90OyAmbHQ7bXBscy1jaGFpcnNAaWV0Zi5vcmcmZ3Q7 LCAmcXVvdDtkcmFmdC1uYWluYXItbXBscy1yZmM4Mjg3LWxlbi1jbGFyaWZpY2F0aW9uQGlldGYu b3JnJnF1b3Q7ICZsdDtkcmFmdC1uYWluYXItbXBscy1yZmM4Mjg3LWxlbi1jbGFyaWZpY2F0aW9u QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW21wbHNdIElQUiBwb2xsIG9u IGRyYWZ0LW5haW5hci1tcGxzLXJmYzgyODctbGVuLWNsYXJpZmljYXRpb248bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIvMjYv MTksIDI6MDggQU0sICZxdW90O0xvYSBBbmRlcnNzb24mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpsb2FAcGkubnUiPmxvYUBwaS5udTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtXb3JraW5nIEdyb3VwLCBhdXRob3JzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtXZSBoYXZlIHN0YXJ0ZWQgdG8gcHJlcGFyZSBkcmFmdC1uYWluYXItbXBscy1yZmM4 Mjg3LWxlbi1jbGFyaWZpY2F0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtmb3Igd29ya2luZyBncm91 cCBhZG9wdGlvbiwgcHJpb3IgdG8gdGhlIHdnYXAgd2UgbmVlZCB0byBkbyBhbiBJUFIgcG9sbC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhpcyBtYWlsIHN0YXJ0cyB0 aGlzIElQUiBwb2xsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtBcmUg eW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ZHJhZnQtbmFpbmFyLW1wbHMtcmZjODI4Ny1sZW4tY2xhcmlmaWNhdGlvbj88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Ns b3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXM8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyhzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGVyZSBubyBJUFIgZGlzY2xv c3VyZXMgYWdhaW5zdCBkcmFmdC1uYWluYXItbXBscy1yZmM4Mjg3LWxlbi08bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO2NsYXJpZmljYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO0lmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9y IHBsZWFzZSByZXNwb25kIHRvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0aGlzIGVtYWlsIHJlZ2FyZGxl c3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQ8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO0lQUi4gKlRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBzZW50IHRvIHRoZSBN UExTIFdHIG1haWxpbmcgbGlzdC4qIFRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZG9jdW1lbnQgd2ls bCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtyZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBjb250cmli dXRvci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SWYgeW91IGFyZSBv biB0aGUgTVBMUyBXRyBlbWFpbCBsaXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Ig b3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5 IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 SVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJ RVRGIHJ1bGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOy9Mb2E8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO21wbHMgd2cg Y28tY2hhaXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0tIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0xvYSBBbmRlcnNzb24mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtlbWFpbDogPGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5udSI+DQps b2FAcGkubnU8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtTZW5pb3IgTVBMUyBFeHBlcnQ8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO0Jyb256ZSBEcmFnb24gQ29uc3VsdGluZyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwaG9u ZTogJiM0Mzs0NiA3MzkgODEgMjEgNjQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bXBscyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0bzpt cGxzQGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21wbHM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_D235D22AA53E41E18275B74FB67CD6D7ciscocom_-- From nobody Tue Feb 26 23:52:19 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 CF8D3130E79; Tue, 26 Feb 2019 23:52:16 -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, 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 yHD5JVhsCOId; Tue, 26 Feb 2019 23:52:13 -0800 (PST) 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 ADEE9130E6B; Tue, 26 Feb 2019 23:52:10 -0800 (PST) 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 6B91E1801556; Wed, 27 Feb 2019 08:52:07 +0100 (CET) To: "mpls@ietf.org" References: <155124978818.776.4282642464739373697@ietfa.amsl.com> Cc: "mpls-chairs@ietf.org" , Stewart Bryant , draft-andersson-mpls-spl-terminology@ietf.org From: Loa Andersson Message-ID: <152ad984-e4cb-bd12-dd58-ad141a5bdc3d@pi.nu> Date: Wed, 27 Feb 2019 15:52:02 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <155124978818.776.4282642464739373697@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] I-D Action: draft-andersson-mpls-spl-terminology-01.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, 27 Feb 2019 07:52:17 -0000 Working Group, This version - change the name "regular SPL" to "base SPL", following a suggestion in the review by Stewart not to use "regular" - changes the abbreviation "rSPL" to "bSPL", accomodating this name change - fixes one type - add content to the Acknowledgment Section /Loa On 2019-02-27 14:43, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Special Purpose Label terminology > Authors : Loa Andersson > Kireeti Kompella > Adrian Farrel > Filename : draft-andersson-mpls-spl-terminology-01.txt > Pages : 6 > Date : 2019-02-26 > > Abstract: > This document discusses and recommends a terminology that may be used > when MPLS Special Purpose Labels (SPL) are specified and documented. > > Note: The rest of the text in this section is not really part of the > abstract even though the text is placed here. It is working notes. > > Note: At least at the moment it is not the intention to take this > document to an RFC, but it might be polled to become a wg document to > see if the MPLS working group agree on the proposed terminology. > > Note: The changes we propose are minor, but we might have to progress > the document to RFC since there is a proposed change to the "Special- > Purpose Multiprotocol Label Switching (MPLS) Label Values" registry. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-andersson-mpls-spl-terminology/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-andersson-mpls-spl-terminology-01 > https://datatracker.ietf.org/doc/html/draft-andersson-mpls-spl-terminology-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-andersson-mpls-spl-terminology-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Wed Feb 27 00:41:17 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 92923130E8A; Wed, 27 Feb 2019 00:41:15 -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, 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 4t5ogziIwLw8; Wed, 27 Feb 2019 00:41:14 -0800 (PST) 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 23656130EDE; Wed, 27 Feb 2019 00:41:14 -0800 (PST) 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 ED3CC1801556; Wed, 27 Feb 2019 09:41:10 +0100 (CET) From: Loa Andersson To: "mpls@ietf.org" Cc: "mpls-chairs@ietf.org" , draft-nainar-mpls-rfc8287-len-clarification@ietf.org Message-ID: <19124c2d-c53b-5826-e7fa-b16616e7ef01@pi.nu> Date: Wed, 27 Feb 2019 16:41:05 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [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, 27 Feb 2019 08:41:15 -0000 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 Wed Feb 27 01:26: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 D14B1130E9B; Wed, 27 Feb 2019 01:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, 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=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 4coD2EBULUIS; Wed, 27 Feb 2019 01:26:34 -0800 (PST) Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.67]) (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 1DCB3130E8C; Wed, 27 Feb 2019 01:26:33 -0800 (PST) Received: from [46.226.52.199] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-b.eu-west-1.aws.symcld.net id 0A/FC-11025-7C7567C5; Wed, 27 Feb 2019 09:26:31 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0hTYRjHfXfOjkfxyOsx29PQwJVB5plOs2Z ZaBD1oTIqsiLJMz25xTbHziztS0I3UCKL6LKcWk0oy0qJtDJSS9IRpF3NUBtq2kWyhMou0s6O 3b793+f/e//v87w8NME2UmpaKHQIditv1lDB5Py5X2dz9zN3bk1oeD5d3+1tI/WTrnJCf/mxh 9L3VF9QppEr3e4JxUrniQPUWsUWpclqyC/MVhpdxR8I23u28P6XOmUxesCWoCCaxGcJOOyMLU HBNIuPKKB0aIKSD70ITt8uISSKwkug/mIvJelpOAqeXZ9QSBCB7yE43reflIxwHA+T50/6LtA +KAEuNsyS+URwDw0g+bUYOHqu25/D4Czo9QwFSprFeqhtuunXQTgFTjWM+jXC0+GL55JC0gRW Qc9gpV8DxuBuekjIOgLeDEwqZd4A/UNnkFyPhpN95YGyjoJHlaVT9dUw8qM3UGoT8Cy4NpIlj QJ4AMEhl5uSmVgY/uQkZa2G9q42pQzdCIP2q41TQWb42P4ZyUGRMHY4RmZGlfCw5/LUYDnQXj 4+FTQTag55SRnqJOD2yxqiDM1z/jOc05dF4Llw5Wa8XI6GY6XeQKf/v8Kg49QgWYXIGrTAYDf lGR0W3mTmdAkJnE6XyOlSFnIpWn43Z9AKBdwuQXRwOi2/S9SKRZYcc67WKjjqkW9/cm1tQY3o Z0leK5pBKzQRzNKNO7eyoYb83CIjLxq32QvMgtiKImlaA0yUb8/YMLuQJxRuN5l9S/jbBjpEM 42Jk2xGtPEW0ZQnWx6URDef9boIerRl2EWwpDXfKqhVzGYJxRJqLLD+Cfq90I9QlDqcQQEBAW yITbBbTI7//bdIRSNNOLNKSgkxWR1/3nvra0Xha+XuG1FqxcH/tdTFaI93w/Be0TT2MeT1+qa q9NNBHRVJ4Z2Rd8uSmYzIxqfmfUvK69ZXr0m2LUMRoSuKFi/naqjs76nZL2rH151w76t4zt1C oWzB+VUdFXdW70gm4755ujLK+seaa+FJ7KYnc2I2d+VMjL87CJmLbF2VI0R6sGpD6ozxgLTmV y1VRWGZGlI08rpYwi7yvwD83mI2ywMAAA== X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-19.tower-287.messagelabs.com!1551259588!3356968!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 30306 invoked from network); 27 Feb 2019 09:26:30 -0000 Received: from us-west-2a.mta.dlp.protect.symantec.com (HELO EUR01-DB5-obe.outbound.protection.outlook.com) (52.41.248.36) by server-19.tower-287.messagelabs.com with AES256-SHA256 encrypted SMTP; 27 Feb 2019 09:26:30 -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=ZrZ4gFZXSz69zS+pXiAwvypphYZeKKaBXh8FU2JMBwg=; b=m1DC1BvOBrvVRoQhWGNdJF5Uwowz6/0UEseXAvzuc9y6V+JP2nAl9C1SBV/1f0USzeHeTfQSIYDwQkGb2qM9jZJVyw0Hci7J09YdJ8OD+GhXbzuv/3aYr/vIdiZuxj0lbf7YQXF4jfhlJtTyNDF+ObGd18tOYb//6l/sCEbVlLo= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB4306.eurprd03.prod.outlook.com (20.176.215.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.20; Wed, 27 Feb 2019 09:26:26 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::cd69:f7a:ee65:6435]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::cd69:f7a:ee65:6435%5]) with mapi id 15.20.1643.019; Wed, 27 Feb 2019 09:26:26 +0000 From: Alexander Vainshtein To: Loa Andersson CC: "mpls-chairs@ietf.org" , "draft-nainar-mpls-rfc8287-len-clarification@ietf.org" , "mpls@ietf.org" Thread-Topic: [mpls] working group adoption poll Thread-Index: AQHUzng8MvGmuBs8jE6xmpIrjNzLGaXzX+IQ Date: Wed, 27 Feb 2019 09:26:26 +0000 Message-ID: References: <19124c2d-c53b-5826-e7fa-b16616e7ef01@pi.nu> In-Reply-To: <19124c2d-c53b-5826-e7fa-b16616e7ef01@pi.nu> 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: ac7fa8c9-c84d-47f7-a349-08d69c95a5e1 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:AM0PR03MB4306; x-ms-traffictypediagnostic: AM0PR03MB4306: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtBTTBQUjAzTUI0MzA2OzIzOk9OMldtZEJiZWlPSHo5dkZDdVVwSWJYY29y?= =?utf-8?B?QVYyVjJjUkhGWlFjdG1NZ2xBb3FRSEY4TytIblZCTFpGb2xlb0JJQkF6U0ta?= =?utf-8?B?Vi81YUVJa2pIc01kYzJ1dnRpcENhclk2UVpXVFduQ3RvN0xoVk5MVUtYWFhL?= =?utf-8?B?Tyt1WkNIWjF2T2xNZW90TWVqTlJFckczQVBzYUhTUzBvZHBSb0ZPb215b2Ri?= =?utf-8?B?M1ZQaWJQYXhIbnpnTDhjdThyVDN0cmJPTUo5VWhUc2pnS2Q4d3NPVklsWEdB?= =?utf-8?B?UFpGOGJZNElrcDBMWmZhdTB5WEFsMmZLMEdlNVFIYmU1VVJ3U2U1Y1dONVIv?= =?utf-8?B?MCtySWFHZG1SMGlQUDV1TmRUZVZMZVl4cm45VlplZmM2MW93WnBBaHpwREow?= =?utf-8?B?VFU5WGFLK2xFUU81c3cvVVcrOExuN2hZNThyWmtZWm1teGNFTHJJanNHYUJo?= =?utf-8?B?dDRzK1ZOVjZpL2pwTlpHNEl1Vy9XUUNVVHpjTU10a0I3TlZjdmR6TjdaYWc4?= =?utf-8?B?b0MvNHR5OURiejdmVHN1WDE2R2piemEzRFJtTE5aL2RTTDREcDBpcDNkN2o2?= =?utf-8?B?L3hwbWd0aVg5OE9PYStRd2huL09hakp3UVBoc2thQWRFb3BLTWdzQ2lOTlpH?= =?utf-8?B?N0Vzb2hUZVZkNXp5YzlLdEo4Z0JGK0wwQWZYMUJqQjIvaVE2V0hLSEtkb0xY?= =?utf-8?B?cEo4OVI4Unp2TXlqbngvaXpCZE5xS3ZEcHV4Yjl0TVNrellLZWlvUmhrTmF2?= =?utf-8?B?c2ZaOE9aWTYwUEJtMHBwNWVTRXhJS2M3bE5oZnRHM0ZiRFFETEQ0M1pYcVJl?= =?utf-8?B?ajlJTjJNbXUzdEtvaC9UV1FLZWw4YlpTamNSNy9PMDNOYU1keUdvTmJQQkJT?= =?utf-8?B?ZUN4ZkZ6eGE0ZXV2SXB3V25OWXZ3YjdXR0VLeTdMeXBSMW1CbElFRWJ4WGsy?= =?utf-8?B?S3FtRDRydkVndGhUYUhLT2Zma0tXTGxjQWRPMlhJZ09xODRhT0J0Y2dpSnlq?= =?utf-8?B?dy9BUXFSL202bFJDdWZVV1FpRUpCVDVkcnRSbFgwQnlVNGk3NkNtNm1NTlk5?= =?utf-8?B?bVc2QlJrM2tvcVlpZ1UyYkJhK2xqQkRWdHBaeUxOUXk4QjN3S21vVTRpUUhr?= =?utf-8?B?M21OOHI0VW1qMVY5UGZoVmNRYWVvcGZnTXVsak5iNjJLTlphM0d3WFBnSnNz?= =?utf-8?B?QkY4MVVyYmg3OFhNM21hcGJOWnY2SGhqZTduSDVMT3FDTG8vbWlYMGhhNXNF?= =?utf-8?B?dm1pMnlwT09xYkZscVJpNzg3dzZaZlNoT2VXcVRtY3hOT2ZVQTFQV1puSUtV?= =?utf-8?B?ekhDSWNYMnJ5U2ZPcFhZaHArbTJEalhPbnpwYUp3d2Z0d25jWGNBTFdSTkJt?= =?utf-8?B?MENxSWtZbXdTc1FteDgvZnZCVDJwVmswZkZvZUVEUlJHbW4vNVREdmtJenk4?= =?utf-8?B?UGpGbi9PNkZTMDNhVTRUTGJhWFpXUzFXcjV4TFltdjFrczhLMEZlNGxGTkpv?= =?utf-8?B?MWJKcTQ4KzlhODY4V0ZFYVpWUGo2ZnNYbXErN0plZ0NMNnVEN2hPVDUxVE12?= =?utf-8?B?ZGNUZlBIL1NrbmxIR0wrL1RMMEIzaDVZQ2pzYVJNU3AwMmNBV2hsYU1LL3Q3?= =?utf-8?B?dWtqRDRRdEtWZlRBT1lPQ25jaVl1MVZwSDBDdC8ybFIvK2x3RGlhRERtYjBu?= =?utf-8?B?b1pSbWJ4ZjRZeS9PWTZidWZNY2cwbFdCS1kwRThNMkpHOXhFTURYcktQOTgz?= =?utf-8?Q?fv+98xphDQ2zgAksmJvY2Vqtv1sdnIdsXKVrg=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 0961DF5286 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(366004)(39860400002)(376002)(346002)(199004)(189003)(13464003)(81166006)(81156014)(106356001)(33656002)(6116002)(102836004)(305945005)(26005)(3846002)(7736002)(97736004)(99286004)(478600001)(8676002)(7696005)(6916009)(2906002)(53546011)(76176011)(68736007)(72206003)(54906003)(316002)(105586002)(8936002)(25786009)(66066001)(86362001)(486006)(6306002)(55016002)(6436002)(9686003)(4326008)(6506007)(476003)(966005)(5660300002)(14454004)(256004)(6246003)(53936002)(186003)(229853002)(52536013)(11346002)(71200400001)(446003)(71190400001)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB4306; 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: eRAxG3PG7+CiaEZlgUqcEY3ArdzMdb4s8fhgCvnFwk9jkc2smqxhgxMAlRqUtv9StKjQ4kKgXggzLOhGXUNr7urlvH1s4GMOJZZxzIBz23HC82T7QLGSNqU0q+Vo/J1hVggD/U+KAqN0y57UYVEmebQIojVcAno79XbBQIJRQayr6evb/Yuz/rN2By5iXp8nlOtYjv9aXRO67OtKkYy5DKzHyH5suVn5/Y7KooHwu5kvQSS2+13Z6OGl/WA7Hn+xFH5yH7BfXOff/E40qK7Dy40wQdbNqgY9sPrFUQebgLz0+Lfqliwskefo9p7kY+ALGWQDq1UyUwEWaQIyzFkjAyxUCrIxSCPokC/FvKTa19mBaH+zxNqKalrub89A2LT7Uj1R4rdNoznEGdntr8q8HY5njHVJTtJTme1VJNYaf94= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: ac7fa8c9-c84d-47f7-a349-08d69c95a5e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2019 09:26:26.5511 (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: AM0PR03MB4306 X-CFilter-Loop: Reflected 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, 27 Feb 2019 09:26:37 -0000 TG9hZCBhbiBhbGwsClN1cHBvcnQgYXMgYSBjby1hdXRob3IuCgpSZWdhcmRzLApTYXNoYQoKT2Zm aWNlOiArOTcyLTM5MjY2MzAyCkNlbGw6ICAgICAgKzk3Mi01NDkyNjYzMDIKRW1haWw6ICAgQWxl eGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20KCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t CkZyb206IG1wbHMgPG1wbHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIExvYSBBbmRl cnNzb24KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNywgMjAxOSAxMDo0MSBBTQpUbzogbXBs c0BpZXRmLm9yZwpDYzogbXBscy1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LW5haW5hci1tcGxzLXJm YzgyODctbGVuLWNsYXJpZmljYXRpb25AaWV0Zi5vcmcKU3ViamVjdDogW21wbHNdIHdvcmtpbmcg Z3JvdXAgYWRvcHRpb24gcG9sbAoKV29ya2luZyBHcm91cCwKClRoaXMgaXMgdG8gc3RhcnQgYSB0 d28gd2VlayBwb2xsIG9uIGFkb3B0aW5nIGRyYWZ0LW5haW5hci1tcGxzLXJmYzgyODctbGVuLWNs YXJpZmljYXRpb24KYXMgYSBNUExTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuCgpQbGVhc2Ugc2Vu ZCB5b3VyIGNvbW1lbnRzIChzdXBwb3J0L25vdCBzdXBwb3J0KSB0byB0aGUgbXBscyB3b3JraW5n IGdyb3VwIG1haWxpbmcgbGlzdCAobXBsc0BpZXRmLm9yZykuIFBsZWFzZSBnaXZlIGEgdGVjaG5p Y2FsIG1vdGl2YXRpb24gZm9yIHlvdXIgc3VwcG9ydC9ub3Qgc3VwcG9ydCwgZXNwZWNpYWxseSBp ZiB5b3UgdGhpbmsgdGhhdCB0aGUgZG9jdW1lbnQgc2hvdWxkIG5vdCBiZSBhZG9wdGVkIGFzIGEg d29ya2luZyBncm91cCBkb2N1bWVudC4KCldlIGhhdmUgZG9uZSBhbiBJUFIgcG9sbCBmb3IgdGhp cyBkb2N1bWVudC4gQWxsIHRoZSBjby1hdXRob3JzIGFuZCBjb250cmlidXRvcnMgaGF2ZSByZXNw b25kZWQgdG8gdGhlIElQUiBwb2xsIHRoYXQgdGhleSBhcmUgdW5hd2FyZSBvZiBhbnkgSVBScyB0 aGF0IHJlbGF0ZXMgdG8gdGhpcyBkcmFmdC4KClRoZXJlIGFyZSBubyBJUFIgZGlzY2xvc3VyZXMg YWdhaW5zdCB0aGlzIGRvY3VtZW50LgoKVGhlcmUgaGFzIGFsc28gYmVlbiBhIGRpc2N1c3Npb24g b24gYWRkaW5nIHRleHQgYXQgdGhlIGVuZCBvZiBzZWN0aW9uIDQgdGhhdCBzYXlzOgoK4oCcVGhl IEZpZ3VyZXMgaW4gU2VjdGlvbnMgNC4xLCA0LjIsIGFuZCA0LjMgcmVwbGFjZSB0aGUgY29ycmVz cG9uZGluZyBGaWd1cmVzIGluIFJGQyA4MDI5ICBTZWN0aW9ucyA1LjEsIDUuMiwgYW5kIDUuMyBy ZXNwZWN0aXZlbHkuIFRoZSB1cGRhdGVkIGZpZ3VyZXMgY29udGFpbiBleHBsaWNpdGx5IGRlZmlu ZWQgbGVuZ3RoLuKAnQoKVGhlcmUgaGFzIGFsc28gYmVlbiBhbiBhZ3JlZW1lbnQgdG8gYWRkIHRo aXMgYWZ0ZXIgdGhlIGFkb3B0aW9uLgoKVGhlIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gcG9sbCBl bmRzIE1hcmNoIDEwLCAyMDE5LgoKL0xvYQoKbXBscyB3ZyBjby1jaGFpcgotLSAKCgpMb2EgQW5k ZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBwaS5udQpTZW5pb3IgTVBM UyBFeHBlcnQKQnJvbnplIERyYWdvbiBDb25zdWx0aW5nICAgICAgICAgICAgIHBob25lOiArNDYg NzM5IDgxIDIxIDY0CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwptcGxzIG1haWxpbmcgbGlzdAptcGxzQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpUaGlzIGUtbWFpbCBt ZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIGlu Zm9ybWF0aW9uIHdoaWNoIGlzIApDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmll dGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyAKdHJhbnNtaXNz aW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBh bmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIAphbmQgYWxsIGNvcGllcyB0aGVyZW9mLgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18K From nobody Wed Feb 27 01:28: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 0AE67130E8C; Wed, 27 Feb 2019 01:28:40 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] 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 W6Tfm2C5rvFh; Wed, 27 Feb 2019 01:28:38 -0800 (PST) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.5]) (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 A7CF3130E6E; Wed, 27 Feb 2019 01:28:37 -0800 (PST) Received: from [85.158.142.103] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-5.bemta.az-a.eu-central-1.aws.symcld.net id B5/67-12121-348567C5; Wed, 27 Feb 2019 09:28:35 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTURzHPbt382reOk1tP4dGzoJem5oRy9A eFBkoBpU9yOqqN3dhTtudphGRmAozMyhrDa00g9TQsoclhqaFJZU2o0JxNdRSoReWKYV07669 /vue3/dzvr/fOfwoQtmsUFNstoU1mxijRuFNLl80MV+7bkfW7rCRoUj9a9dDUj9VXkbo63o6F frey9XyNWRMVdWkLMZ+tkCxWbZLzpmS0rP3yQ3XusZlGcOq7J8jiUdRq8qKvCkSVxKQay9B4k GJT8qgwXGDkA79CE6dyJdZkRelwFHQUNuvELUfDoKXtydlIkTgBwjOOPNJ0fDFoTB1xSbcpgQ oDGobQyQ+Et4/KyVETeIFYOt/4tY0ToS8iqbpZlYEPcPtbsML74GJnlfuZgjPge+dV91DEFgF vYMX3BowhqrmLkLS/jAyMCWX+CR4M1SBpHow2JxlnpIOAseFoul6HNytFeuUoEPg5nCiOAPgA QSFRV+nMxdDgeO6XNJqePT8oVyCSpTw8syP6VAjuHIbkBQUCJ9LFkhMngLGn465g5Q4GR6VjZ ESPxdqil2kBHUT8LnvHXESLbH/8zi7kEXgRVDfFCqVg+F0kcvT7v6w2fD43CB5EZE1aGWSmUs 1WNIYzqgNDwvThodHaCO0y5av1DGHtIyOzdQmsyaLmRFcHXOQ1/E5acnGFJ2JtTQgYYdSDhCT d9BAYWobCqBkGn86OiFrt3JmUnpKjoHhDXvNmUaWb0OBFKUBOmi74M02s6ls9n7OKCzibxsoH 40fvVS0aT6DSeO5VMnqRBFUa6WrnKA+3H9fTihJU7qJVavonSKKRdSQafoT9HupHShI7UsjDw 8PpU8Ga07jLP/7o0hFIY0vHSum+HAmy59+o8IoMmGU9hFeHMXC/LXUR1H0Wc+m2NIn2o0Vj9c nPF1Vq36wNMKf1hyuiXNedtAd+aGbZlaPH/sYYunbYug7v3ZF90WjM2qu08NaXL/xy4wXjgBd fEt9x4cWOHJPn1OybV4ud+vZTz/528bJ4/3W0jxu4ekN1Y3qwug5OxNsvVtV31YnjHZcstXVZ d35NBQ/yxyvIXkDE76YMPPMLzbVMbnPAwAA X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-18.tower-228.messagelabs.com!1551259711!2617933!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 11678 invoked from network); 27 Feb 2019 09:28:34 -0000 Received: from us-west-2a.mta.dlp.protect.symantec.com (HELO EUR03-VE1-obe.outbound.protection.outlook.com) (52.41.248.36) by server-18.tower-228.messagelabs.com with AES256-SHA256 encrypted SMTP; 27 Feb 2019 09:28:34 -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=NFCc5oSxmufh7HJMhlEKBDLfU9LhJ8Auy4CXz11vxbo=; b=D/WS9oIv2aVsHsSef2uSR5yr+mYKzoqKL3D8arMXhxOsa6zKGCvMBExRuu9cSolowrQYP7elCl9WpzWq+hsjUxcjV4/BzCYlCHrqTawm6UcDjUOZbZqLUqcmqdX2w3cB4aULmCQxRGokAAKUvRuyPFmjvFnM//rdi8RTBMOTI5M= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB5890.eurprd03.prod.outlook.com (10.255.29.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.15; Wed, 27 Feb 2019 09:28:29 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::cd69:f7a:ee65:6435]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::cd69:f7a:ee65:6435%5]) with mapi id 15.20.1643.019; Wed, 27 Feb 2019 09:28:29 +0000 From: Alexander Vainshtein To: Loa Andersson CC: "mpls-chairs@ietf.org" , "draft-nainar-mpls-rfc8287-len-clarification@ietf.org" , "mpls@ietf.org" Thread-Topic: [mpls] working group adoption poll Thread-Index: AQHUzng8MvGmuBs8jE6xmpIrjNzLGaXzX+IQgAAApbA= Date: Wed, 27 Feb 2019 09:28:29 +0000 Message-ID: References: <19124c2d-c53b-5826-e7fa-b16616e7ef01@pi.nu> In-Reply-To: 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: daa7f5d1-791c-4e2c-757b-08d69c95ef1c 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:AM0PR03MB5890; x-ms-traffictypediagnostic: AM0PR03MB5890: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtBTTBQUjAzTUI1ODkwOzIzOnBXUmZ1SGVQbjhUOVJiODJFbk9VR2ptNTNi?= =?utf-8?B?SlV0azZiSWIzYW5MQ25TcXVXalZEc1BqVUVVU0QzKzgvYXYxcGdyZG5ENk81?= =?utf-8?B?cjRxWWUxQ21tOFo5MjlOWTdqZXhqMDlVRmp0SUpQazlZMG5NOEdUQ29Fbks5?= =?utf-8?B?SUxmQlppU29OcHhYZ3c5UTJCYXJBMUFncW85d1RaUVRDd2NvTEFpamJMVm1Q?= =?utf-8?B?U2VEWHpuN3VudHFvcFRNaC9GMlVjQUdDOVNGYVhKM3NEdU82ai9IVUM1ZkRJ?= =?utf-8?B?QVdZYXpPRkhuRkxSUWVTVDZZd1VpZzBqMU02Q3NhdWp4Y01pT0NLbHNwQjlX?= =?utf-8?B?MUVOakMxUVErZ1VJNGpLNU4zL2VheEsxSXJjNDhOMCtsVmN3SXAwaEZ4UDlU?= =?utf-8?B?SGV2eVlsY21EeXJ1RzlSL0dqeXoxUzg3cVd2Q0Z1QldoOFU4SzhiQkpqTjIz?= =?utf-8?B?WTdNNVU2UWNTNXlCcitEbm1Ob3RjWGlrT1N1V1pBdGZmQmFCOVhRQWJsYlVC?= =?utf-8?B?WlBzaXJHS0Uwa1FrRWYxLzF1S21Oc3FONCtYTFJrRFhHZi9lVVNuS3lkN2Zk?= =?utf-8?B?ajk3Sm1kREtJd1NpWEd0SDJwSTJ6MUs2VC9rRFBGbVNmdGllbk45ci9sNlNG?= =?utf-8?B?SXU1SGwwS3VvMWJPZjFVdWtDYkMvb0laMW4xR3gwd2ZWS0VSRjVmcCswVmZZ?= =?utf-8?B?Y1FJdkJPNW5DY3l6OUZvUGNjUjBFV05idzJxdzM1Zy9XendkNHNENFQrL3FB?= =?utf-8?B?NHZYODcvS0x5a21mUjM0cnpSM2toME55ZG9PcG9CM2tWbC81Y3FhM1FCcGpM?= =?utf-8?B?bHlVbk9xTnRuRTZJZmJOaFlWRUdqM2RKbUw3M3l1Q3d3cURrRDFrK25IdVRj?= =?utf-8?B?NElzODBhcWlmTk5MQ3dqSlRXTU5YMTR0N0xTM0J1RzVpQ21UWWxoYWxaZXFx?= =?utf-8?B?UXE5Y0YyVjR2SWdRem9ZZ2ZhTFdudGpPRzJ2NzlwRy9iczBucXEwOEpoWC9I?= =?utf-8?B?dGVWNHFpK3RCRnNUeDZsSDFMZmNGMnN6bXdIMUI1TXRSODdaRm5iekpzTVNm?= =?utf-8?B?eTM3WVBoaG1Td3dFekwwbnlpNFEzWDVtemswcEtTL24wRVJ2ckVTWHF4SGZK?= =?utf-8?B?VVMwSVNJeFJqaUFDQUpBNUM3TTZzSkNYSUpkdWx3bmNDSlYrWHNjeDFIQmEr?= =?utf-8?B?TUR3MHBEck96bUZLREpRNUpXN0lpWTAvZEhIaVhvaTFOM3VHd2lmaDd1MElD?= =?utf-8?B?ek9nWU9mR2pXVGZkakgrWnIxV1RlY2owMUVnN2RlcEYzVjFmZ3RKV0w0R0Vi?= =?utf-8?B?U0RrTkZwRndUWGM1a2NCNk1HVEl2TmxOUXpPNFYxaW9DVVI5Tkw3bGMydzlC?= =?utf-8?B?ZjFmcFJVckloWU9YY1pLR2hxNlNJSkFGcjNuUG1CUm1oVXVrb2NCMGllWkdY?= =?utf-8?B?WnFWRENQb0JsdUg5TU9DMXJkanlxVlNEUkdYNmpzMS9iaUJyQk5yRm1yVGRG?= =?utf-8?B?bXVzUzh0SGtpMzlVd1BwVkRhOVEyQVQwdllZbnVhaXpTNElQcnMzcHlyZHdQ?= =?utf-8?B?UGxtakZYZ2ZRVGppeWJiNmI1OTFFSk9BMVpmOTRNT0dBd21Nc2lWVTFkT1FP?= =?utf-8?B?cVNIVjE4MzlxYlAzZVVUSzJWWHBXcDlpZnQyMy9SSTZ5NGVqNWFld1ZRNTdV?= =?utf-8?B?dFNnekc3enE5bXVmNmV3dnZNTlpnSHpFdVlVWkZHRmRsbjQxVUh0dGo3Q1FO?= =?utf-8?B?Nml0QzJPL2xiRndJT0VFbjdadTZENVpvWGFMU3Z2OUFRZm5kdTBqaEFZYmxP?= =?utf-8?B?U3dWeFpLaUZoMDRmbDRpUlBJN0EybXFRZ2htQlZ3aGtFMFE9PQ==?= x-microsoft-antispam-prvs: x-forefront-prvs: 0961DF5286 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(136003)(39860400002)(396003)(366004)(13464003)(189003)(199004)(446003)(486006)(93156006)(6506007)(8676002)(102836004)(53546011)(2940100002)(81156014)(7696005)(256004)(81166006)(4326008)(6246003)(71190400001)(71200400001)(66066001)(8936002)(76176011)(74316002)(6116002)(3846002)(68736007)(186003)(7736002)(6436002)(99286004)(6916009)(105586002)(2906002)(11346002)(53936002)(86362001)(305945005)(97736004)(52536013)(6306002)(55016002)(33656002)(5660300002)(9686003)(72206003)(106356001)(229853002)(26005)(966005)(25786009)(478600001)(14454004)(316002)(476003)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB5890; H:AM0PR03MB3828.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: YH/6t37Nqrolt7AFRDIXtrL1yU+6pGgetB41Q5kItkWmvcgJT7Q+3ReN6r/FxJHXJsdkk/xtzyQv1vvbK+9EroyjFnbaEwfdmfJauar8dCTXkjrbmn1YD92+L/vAjF56CLn9TrkovpopoKtjeQEN55XtLM/5CIISS46+uhUk8p313JowZNo27gsG98Px7BSPX2MpK5TdIbJxVE6j5elAS3aVyBrcwxb2/XiMEue2jo87TckDkJW31aS0vxbNXO4P8SU/omTno5W6+NAWWYXtOGPRrN6i3AKO0HtHTVFSjlo7hUdd0OdUIwkHrjE8PqN/Yt3e7vIAsKaYK1pnoH0tK1BS0AHqNMhr0GMm9md8fEth8I+DIM3xExLqkVijbyFOxDpByh5NQJN1IuEs0BaVbEv9uiIsZLm+stTsaI/TDMs= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: daa7f5d1-791c-4e2c-757b-08d69c95ef1c X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2019 09:28:29.4293 (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: AM0PR03MB5890 X-CFilter-Loop: Reflected 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, 27 Feb 2019 09:28:40 -0000 TG9hLApNeSBzcGVsbGNoZWNrZXIgZGlkIG5vdCByZWNvZ25pemUgeW91ciBuYW1lIC0gbXkgc2lu Y2VyZSBhcG9sb2dpZXMhCgpSZWdhcmRzLApTYXNoYQoKT2ZmaWNlOiArOTcyLTM5MjY2MzAyCkNl bGw6ICAgICAgKzk3Mi01NDkyNjYzMDIKRW1haWw6ICAgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNp dGVsZS5jb20KCgotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQpGcm9tOiBBbGV4YW5kZXIgVmFp bnNodGVpbiAKU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyNywgMjAxOSAxMToyNiBBTQpUbzog TG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51PgpDYzogbXBscy1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0 LW5haW5hci1tcGxzLXJmYzgyODctbGVuLWNsYXJpZmljYXRpb25AaWV0Zi5vcmc7IG1wbHNAaWV0 Zi5vcmcKU3ViamVjdDogUkU6IFttcGxzXSB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIHBvbGwKCkxv YWQgYW4gYWxsLApTdXBwb3J0IGFzIGEgY28tYXV0aG9yLgoKUmVnYXJkcywKU2FzaGEKCk9mZmlj ZTogKzk3Mi0zOTI2NjMwMgpDZWxsOiAgICAgICs5NzItNTQ5MjY2MzAyCkVtYWlsOiAgIEFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tCgotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQpG cm9tOiBtcGxzIDxtcGxzLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBMb2EgQW5kZXJz c29uClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjcsIDIwMTkgMTA6NDEgQU0KVG86IG1wbHNA aWV0Zi5vcmcKQ2M6IG1wbHMtY2hhaXJzQGlldGYub3JnOyBkcmFmdC1uYWluYXItbXBscy1yZmM4 Mjg3LWxlbi1jbGFyaWZpY2F0aW9uQGlldGYub3JnClN1YmplY3Q6IFttcGxzXSB3b3JraW5nIGdy b3VwIGFkb3B0aW9uIHBvbGwKCldvcmtpbmcgR3JvdXAsCgpUaGlzIGlzIHRvIHN0YXJ0IGEgdHdv IHdlZWsgcG9sbCBvbiBhZG9wdGluZyBkcmFmdC1uYWluYXItbXBscy1yZmM4Mjg3LWxlbi1jbGFy aWZpY2F0aW9uCmFzIGEgTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50LgoKUGxlYXNlIHNlbmQg eW91ciBjb21tZW50cyAoc3VwcG9ydC9ub3Qgc3VwcG9ydCkgdG8gdGhlIG1wbHMgd29ya2luZyBn cm91cCBtYWlsaW5nIGxpc3QgKG1wbHNAaWV0Zi5vcmcpLiBQbGVhc2UgZ2l2ZSBhIHRlY2huaWNh bCBtb3RpdmF0aW9uIGZvciB5b3VyIHN1cHBvcnQvbm90IHN1cHBvcnQsIGVzcGVjaWFsbHkgaWYg eW91IHRoaW5rIHRoYXQgdGhlIGRvY3VtZW50IHNob3VsZCBub3QgYmUgYWRvcHRlZCBhcyBhIHdv cmtpbmcgZ3JvdXAgZG9jdW1lbnQuCgpXZSBoYXZlIGRvbmUgYW4gSVBSIHBvbGwgZm9yIHRoaXMg ZG9jdW1lbnQuIEFsbCB0aGUgY28tYXV0aG9ycyBhbmQgY29udHJpYnV0b3JzIGhhdmUgcmVzcG9u ZGVkIHRvIHRoZSBJUFIgcG9sbCB0aGF0IHRoZXkgYXJlIHVuYXdhcmUgb2YgYW55IElQUnMgdGhh dCByZWxhdGVzIHRvIHRoaXMgZHJhZnQuCgpUaGVyZSBhcmUgbm8gSVBSIGRpc2Nsb3N1cmVzIGFn YWluc3QgdGhpcyBkb2N1bWVudC4KClRoZXJlIGhhcyBhbHNvIGJlZW4gYSBkaXNjdXNzaW9uIG9u IGFkZGluZyB0ZXh0IGF0IHRoZSBlbmQgb2Ygc2VjdGlvbiA0IHRoYXQgc2F5czoKCuKAnFRoZSBG aWd1cmVzIGluIFNlY3Rpb25zIDQuMSwgNC4yLCBhbmQgNC4zIHJlcGxhY2UgdGhlIGNvcnJlc3Bv bmRpbmcgRmlndXJlcyBpbiBSRkMgODAyOSAgU2VjdGlvbnMgNS4xLCA1LjIsIGFuZCA1LjMgcmVz cGVjdGl2ZWx5LiBUaGUgdXBkYXRlZCBmaWd1cmVzIGNvbnRhaW4gZXhwbGljaXRseSBkZWZpbmVk IGxlbmd0aC7igJ0KClRoZXJlIGhhcyBhbHNvIGJlZW4gYW4gYWdyZWVtZW50IHRvIGFkZCB0aGlz IGFmdGVyIHRoZSBhZG9wdGlvbi4KClRoZSB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIHBvbGwgZW5k cyBNYXJjaCAxMCwgMjAxOS4KCi9Mb2EKCm1wbHMgd2cgY28tY2hhaXIKLS0gCgoKTG9hIEFuZGVy c3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAcGkubnUKU2VuaW9yIE1QTFMg RXhwZXJ0CkJyb256ZSBEcmFnb24gQ29uc3VsdGluZyAgICAgICAgICAgICBwaG9uZTogKzQ2IDcz OSA4MSAyMSA2NAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KbXBscyBtYWlsaW5nIGxpc3QKbXBsc0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKVGhpcyBlLW1haWwgbWVz c2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucyBpbmZv cm1hdGlvbiB3aGljaCBpcyAKQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRh cnkgdG8gRUNJIFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgCnRyYW5zbWlzc2lv biBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5k IHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCAKYW5kIGFsbCBjb3BpZXMgdGhlcmVvZi4KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCg== From nobody Wed Feb 27 04:39: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 18C55130EFE; Wed, 27 Feb 2019 04:39:45 -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, 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 mjpCf7_zKfi5; Wed, 27 Feb 2019 04:39:42 -0800 (PST) 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 23584130ED8; Wed, 27 Feb 2019 04:39:42 -0800 (PST) Received: from [10.255.254.4] (unknown [176.126.84.105]) (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 604D01801556; Wed, 27 Feb 2019 13:39:39 +0100 (CET) To: Alexander Vainshtein Cc: "mpls-chairs@ietf.org" , "draft-nainar-mpls-rfc8287-len-clarification@ietf.org" , "mpls@ietf.org" References: <19124c2d-c53b-5826-e7fa-b16616e7ef01@pi.nu> From: Loa Andersson Message-ID: <7a8d9ffd-90e0-8d63-24ee-c9fe6cbd0f5e@pi.nu> Date: Wed, 27 Feb 2019 20:39:34 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 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] 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, 27 Feb 2019 12:39:45 -0000 Sasha, NP - I have the same issue with some spelling checkers. /Loa On 2019-02-27 17:28, Alexander Vainshtein wrote: > Loa, > My spellchecker did not recognize your name - my sincere apologies! > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > > > -----Original Message----- > From: Alexander Vainshtein > Sent: Wednesday, February 27, 2019 11:26 AM > To: Loa Andersson > Cc: mpls-chairs@ietf.org; draft-nainar-mpls-rfc8287-len-clarification@ietf.org; mpls@ietf.org > Subject: RE: [mpls] working group adoption poll > > Load an all, > Support as a co-author. > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > > -----Original Message----- > From: mpls On Behalf Of Loa Andersson > Sent: Wednesday, February 27, 2019 10:41 AM > To: mpls@ietf.org > Cc: mpls-chairs@ietf.org; draft-nainar-mpls-rfc8287-len-clarification@ietf.org > Subject: [mpls] working group adoption poll > > 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 Wed Feb 27 05:23: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 62D12130EC0; Wed, 27 Feb 2019 05:23:29 -0800 (PST) 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_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 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 Qlicfdoe4S9T; Wed, 27 Feb 2019 05:23:27 -0800 (PST) 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 4AABF130EBE; Wed, 27 Feb 2019 05:23:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2058; q=dns/txt; s=iport; t=1551273807; x=1552483407; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2dvucyMANaLMLOPtSUdRWQwjgMxde2JoruQOzzJo1pQ=; b=hLFnddN9Z8OO41zQB64ki1+bbWPmrzcCzabXa9PVPxvzuUsJm66PVO1x pm2GwuCK+k0kOg6sdKpHG1hHPpsZCxwvMLosYArG8L75Hq/aRBSy/KttY /Js16Q1pn21lkkNJoFclAhZb4Qw7S3Fz1SWzgkEAEboOm6xrUDSA7wq5U M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAACjjnZc/5ldJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUgQBAQEBCwGCA4FqJwqDfq4jFIFnCwEBhGwCF4N1IjUIDQE?= =?us-ascii?q?DAQECAQECbSiFSwYjETcDCw4CAgEIGgImAgICGRcVEAIEAQ0FgyCBc6scgS+?= =?us-ascii?q?KLwWBBos9F4F/gREnH4JMhE4BEgEfF4JzMYImAow8ly4JApJoGYFzhV+LSop?= =?us-ascii?q?dkhcCERSBKCECNGVxcBU7KgGCQZBdQTGQDYEfgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.58,419,1544486400"; d="scan'208";a="525426825" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2019 13:23:25 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x1RDNPZZ011854 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Feb 2019 13:23:26 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 27 Feb 2019 07:23:25 -0600 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1395.000; Wed, 27 Feb 2019 07:23:25 -0600 From: "Nagendra Kumar Nainar (naikumar)" To: Loa Andersson , "mpls@ietf.org" CC: "mpls-chairs@ietf.org" , "draft-nainar-mpls-rfc8287-len-clarification@ietf.org" Thread-Topic: working group adoption poll Thread-Index: AQHUzng12E9+RdmILkyw7SrRtAhh1KXzsw+A Date: Wed, 27 Feb 2019 13:23:25 +0000 Message-ID: References: <19124c2d-c53b-5826-e7fa-b16616e7ef01@pi.nu> In-Reply-To: <19124c2d-c53b-5826-e7fa-b16616e7ef01@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.a.0.180210 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.20.8] Content-Type: text/plain; charset="utf-8" Content-ID: <523632293000444DA9B8C01D1B7396EA@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.25, xch-aln-015.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com 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, 27 Feb 2019 13:23:30 -0000 SGkgTG9hLA0KDQpTdXBwb3J0IGFzIGNvLWF1dGhvci4NCg0KUmVnYXJkcywNCk5hZ2VuZHJhDQoN Cu+7v09uIDIvMjcvMTksIDM6NDEgQU0sICJMb2EgQW5kZXJzc29uIiA8bG9hQHBpLm51PiB3cm90 ZToNCg0KICAgIFdvcmtpbmcgR3JvdXAsDQogICAgDQogICAgVGhpcyBpcyB0byBzdGFydCBhIHR3 byB3ZWVrIHBvbGwgb24gYWRvcHRpbmcNCiAgICBkcmFmdC1uYWluYXItbXBscy1yZmM4Mjg3LWxl bi1jbGFyaWZpY2F0aW9uDQogICAgYXMgYSBNUExTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQog ICAgDQogICAgUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyAoc3VwcG9ydC9ub3Qgc3VwcG9ydCkg dG8gdGhlIG1wbHMgd29ya2luZw0KICAgIGdyb3VwIG1haWxpbmcgbGlzdCAobXBsc0BpZXRmLm9y ZykuIFBsZWFzZSBnaXZlIGEgdGVjaG5pY2FsDQogICAgbW90aXZhdGlvbiBmb3IgeW91ciBzdXBw b3J0L25vdCBzdXBwb3J0LCBlc3BlY2lhbGx5IGlmIHlvdSB0aGluayB0aGF0DQogICAgdGhlIGRv Y3VtZW50IHNob3VsZCBub3QgYmUgYWRvcHRlZCBhcyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQu DQogICAgDQogICAgV2UgaGF2ZSBkb25lIGFuIElQUiBwb2xsIGZvciB0aGlzIGRvY3VtZW50LiBB bGwgdGhlIGNvLWF1dGhvcnMgYW5kDQogICAgY29udHJpYnV0b3JzIGhhdmUgcmVzcG9uZGVkIHRv IHRoZSBJUFIgcG9sbCB0aGF0IHRoZXkgYXJlIHVuYXdhcmUgb2YgYW55DQogICAgSVBScyB0aGF0 IHJlbGF0ZXMgdG8gdGhpcyBkcmFmdC4NCiAgICANCiAgICBUaGVyZSBhcmUgbm8gSVBSIGRpc2Ns b3N1cmVzIGFnYWluc3QgdGhpcyBkb2N1bWVudC4NCiAgICANCiAgICBUaGVyZSBoYXMgYWxzbyBi ZWVuIGEgZGlzY3Vzc2lvbiBvbiBhZGRpbmcgdGV4dCBhdCB0aGUgZW5kIG9mIHNlY3Rpb24gNA0K ICAgIHRoYXQgc2F5czoNCiAgICANCiAgICDigJxUaGUgRmlndXJlcyBpbiBTZWN0aW9ucyA0LjEs IDQuMiwgYW5kIDQuMyByZXBsYWNlIHRoZSBjb3JyZXNwb25kaW5nDQogICAgRmlndXJlcyBpbiBS RkMgODAyOSAgU2VjdGlvbnMgNS4xLCA1LjIsIGFuZCA1LjMgcmVzcGVjdGl2ZWx5LiBUaGUNCiAg ICB1cGRhdGVkIGZpZ3VyZXMgY29udGFpbiBleHBsaWNpdGx5IGRlZmluZWQgbGVuZ3RoLuKAnQ0K ICAgIA0KICAgIFRoZXJlIGhhcyBhbHNvIGJlZW4gYW4gYWdyZWVtZW50IHRvIGFkZCB0aGlzIGFm dGVyIHRoZSBhZG9wdGlvbi4NCiAgICANCiAgICBUaGUgd29ya2luZyBncm91cCBhZG9wdGlvbiBw b2xsIGVuZHMgTWFyY2ggMTAsIDIwMTkuDQogICAgDQogICAgL0xvYQ0KICAgIA0KICAgIG1wbHMg d2cgY28tY2hhaXINCiAgICAtLSANCiAgICANCiAgICANCiAgICBMb2EgQW5kZXJzc29uICAgICAg ICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBwaS5udQ0KICAgIFNlbmlvciBNUExTIEV4cGVy dA0KICAgIEJyb256ZSBEcmFnb24gQ29uc3VsdGluZyAgICAgICAgICAgICBwaG9uZTogKzQ2IDcz OSA4MSAyMSA2NA0KICAgIA0KDQo= From nobody Wed Feb 27 06:23: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 ED4AF130DE7; Wed, 27 Feb 2019 06:23: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 VYJgoCeU54Yy; Wed, 27 Feb 2019 06:23:39 -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 E479E1200B3; Wed, 27 Feb 2019 06:23:38 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id y4so19306542qtc.10; Wed, 27 Feb 2019 06:23:38 -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=IbzaZTIkQVq3rvgf84wXmgsaLFM2rNpApZ+WZ6AF+S8=; b=XImtQg+RxD0HYzV+uLUJUIpOMEweLvkAEZ6HD6GE4I4uwaYNqRDya2t5HwtFI4VZPi QrqxuGHKVZxTYfw4PdzTbfNAF0RxSlJ7+/A4h0gJFIAlalia1e+N2PR5KsMBQaBHE2iv BIl/YDny7kBY1lkYi4PtJ1TwpufexBFkXJZ9fjn7up/nnAGn108DyJcSmpfO3E9cNuRy 2zKTY9rmXh3PLgFFQJXFH67KnAqt9bS1ZdlBmBDnvI3c5SFKe71rSX8dKzXJQauQVqvp xMu+aafLEzlcQz9kAbYt3Mz7dVYEEbC5sU6MeehjgGGTvQZ9hbI9D89wDaKL1Qpi3eoK EAtw== 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=IbzaZTIkQVq3rvgf84wXmgsaLFM2rNpApZ+WZ6AF+S8=; b=QkNeTBAyQvmheMAssa26+/fOyH6e2MRlbeH4o8fy61BqUX5cXP4/W1wIxEJ+q2Co/6 lBN6FHk2RrP74+4h94HO7ZhydIetmhBpqUkc0fHElQERngkKvOD/RFI7/AlsyF115j4G oUiQwOgsFJzdMuskkmEhFUy3MgG2gsTLPcx5/5YhycZWPCMSaNo9wyYpSps+wtNYt/J7 LBEmzFDLVGmb7nCbJqSpMlhxbIS63MikUKEwFz2TpaKCbl1iaTNhWZ23ySZaccyBbZpB qKovjXCPodSarWV54k7eyc+feJ0XLwFhocx6v402harF8ATso5uvjPdHuZuTe3eQPf4n QRGQ== X-Gm-Message-State: AHQUAua1NkWbp5yJ0F5p9KooGciZfqdO4JrGM6pEclZ8K+6w7zx6lHqE 6AJvr7j0F8NLcoYt3OcfsaGTpCnac22eBcMHa0Y= X-Google-Smtp-Source: AHgI3IYh1QFWc6GH01Z/a3tULYy42OYAdEUehrUI8oHh+8/DEXER5PfX8Ycfc9mChT4Vqxp9N0AyzyIrwKEb12rNWLU= X-Received: by 2002:ac8:32ef:: with SMTP id a44mr1882090qtb.334.1551277417884; Wed, 27 Feb 2019 06:23:37 -0800 (PST) MIME-Version: 1.0 References: <19124c2d-c53b-5826-e7fa-b16616e7ef01@pi.nu> In-Reply-To: From: "Andrew G. Malis" Date: Wed, 27 Feb 2019 09:23:26 -0500 Message-ID: To: "Nagendra Kumar Nainar (naikumar)" Cc: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "draft-nainar-mpls-rfc8287-len-clarification@ietf.org" Content-Type: multipart/alternative; boundary="00000000000070ef0f0582e0ebfc" 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, 27 Feb 2019 14:23:41 -0000 --00000000000070ef0f0582e0ebfc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Support as a non-author :-), it's important for interoperability. Cheers, Andy On Wed, Feb 27, 2019 at 8:23 AM Nagendra Kumar Nainar (naikumar) < naikumar@cisco.com> wrote: > Hi Loa, > > Support as co-author. > > Regards, > Nagendra > > =EF=BB=BFOn 2/27/19, 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 corres= ponding > 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 > --00000000000070ef0f0582e0ebfc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Support as a non-author :-), it's important for intero= perability.

Cheers,
Andy

<= /div>
O= n Wed, Feb 27, 2019 at 8:23 AM Nagendra Kumar Nainar (naikumar) <naikumar@cisco.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Hi Loa,

Support as co-author.

Regards,
Nagendra

=EF=BB=BFOn 2/27/19, 3:41 AM, "Loa Andersson" <loa@pi.nu> wrote:

=C2=A0 =C2=A0 Working Group,

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

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

=C2=A0 =C2=A0 We have done an IPR poll for this document. All the co-author= s and
=C2=A0 =C2=A0 contributors have responded to the IPR poll that they are una= ware of any
=C2=A0 =C2=A0 IPRs that relates to this draft.

=C2=A0 =C2=A0 There are no IPR disclosures against this document.

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

=C2=A0 =C2=A0 =E2=80=9CThe Figures in Sections 4.1, 4.2, and 4.3 replace th= e corresponding
=C2=A0 =C2=A0 Figures in RFC 8029=C2=A0 Sections 5.1, 5.2, and 5.3 respecti= vely. The
=C2=A0 =C2=A0 updated figures contain explicitly defined length.=E2=80=9D
=C2=A0 =C2=A0 There has also been an agreement to add this after the adopti= on.

=C2=A0 =C2=A0 The working group adoption poll ends March 10, 2019.

=C2=A0 =C2=A0 /Loa

=C2=A0 =C2=A0 mpls wg co-chair
=C2=A0 =C2=A0 --


=C2=A0 =C2=A0 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
=C2=A0 =C2=A0 Senior MPLS Expert
=C2=A0 =C2=A0 Bronze Dragon Consulting=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0phone: +46 739 81 21 64


_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--00000000000070ef0f0582e0ebfc-- From nobody Thu Feb 28 07:37:48 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 4B3E4130EDE; Thu, 28 Feb 2019 07:37:47 -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, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155136826730.28728.13473694901209255604@ietfa.amsl.com> Date: Thu, 28 Feb 2019 07:37:47 -0800 Archived-At: Subject: [mpls] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-mpls-sr-over-ip 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 Feb 2019 15:37:47 -0000 Dear Xiaohu Xu, Stewart Bryant, Adrian Farrel, Syed Hassan, Wim Henderickx, Zhenbin Li: An IPR disclosure that pertains to your Internet-Draft entitled "SR-MPLS over IP" (draft-ietf-mpls-sr-over-ip) 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/3439/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-mpls-sr-over-ip" Thank you IETF Secretariat From nobody Thu Feb 28 07:44: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 C6876130EC5; Thu, 28 Feb 2019 07:44:03 -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 17ZmGblNJzlm; Thu, 28 Feb 2019 07:44:01 -0800 (PST) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 4BEF7130E27; Thu, 28 Feb 2019 07:44:01 -0800 (PST) Received: by mail-ua1-x934.google.com with SMTP id d4so8172515uap.5; Thu, 28 Feb 2019 07:44:01 -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=Uu/B/q2aEwr0Vy1lnT3nB3gfU8wevGGVCWKY3Z/pmxk=; b=nNa3YMNm/XlkeJ+94oBgRN/di2RrT4l4Vt7kp2zMnPjzx+Ya1EBC3iNLNIf2tQC20n H0sRFoeGguCwDJrdbO2Qaz1hE7Ndhh1EJ6PcveZhy+xQzRarbYJij4hVEneWffyILfye MGUcMIvh9Y+1GXueghtJERNaQBoBjEePzZsmz29Xq6UQey9PZ9EpXg2LcqCMVhLfm0wy KbnngUwqqlcey3EKjj7MFZQ+I3JCy7Rh/UmsocnDrXzBjoxHsVNI0VOhtLBWNA74BYPA n/TAD45IX+cNg3vks2wdbFfF4VnMJxJWE45W4v1POn7m8gLQlLJ7MVgBCBPPLWoyLvUy QnWw== 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=Uu/B/q2aEwr0Vy1lnT3nB3gfU8wevGGVCWKY3Z/pmxk=; b=GnH9WM7mKFnIiKgfj4gEuXPnDYQVkuPA/qsTcAtFJ8D+hl0QxWJjCzX/bRgN+nV3Jf SJZQk/DxVt+vo/YGFF7/3JGa2W3+vhg88bj66ND+RbENObHNv4ub2bj7Bw2vhAOYkhbi K1JI3ndVWp5eLOicxL4MKH7A/f2r77588EUkDBY5fP0skCQ0IJ7eJdt6FMTJLaqkbjr+ v5RYslcJu/98URLVrh7QfjIuBXh/iivxpBvQ/P2W5GV5yCiT3L5Dsk0Pz4svbRCxZWwJ B1iZ+bu5tm6CuO1JzDzr9ddruVZCynoWxXlr7irncB/ER3O5zq7Z4aMeZgxp7q5Z7SkJ 1hDA== X-Gm-Message-State: AHQUAuYrsFGEIv2TAKsJZHmqrRfFWr+5JLpsCU2cImkYojXvTKVDXrlh 8tbPgcdTWP8OsQtmS7q6sRlyFj6wcWTL2v6Ssun2PQHcs30= X-Google-Smtp-Source: AHgI3IY840oUo+bJcP64rwSC4XrQmRFyXaztMnNkgza/JB4Il6ZvZKZK+b2FXnZWeCAGefQpyGXRiqtXQaTAB6q+cB4= X-Received: by 2002:a67:db89:: with SMTP id f9mr5169374vsk.143.1551368640143; Thu, 28 Feb 2019 07:44:00 -0800 (PST) MIME-Version: 1.0 References: <155044786665.4047.16182077722084116649@ietfa.amsl.com> <011a01d4c71e$16d9dd30$448d9790$@olddog.co.uk> In-Reply-To: <011a01d4c71e$16d9dd30$448d9790$@olddog.co.uk> From: "Andrew G. Malis" Date: Thu, 28 Feb 2019 10:43:48 -0500 Message-ID: To: Adrian Farrel Cc: Paul Wouters , secdir@ietf.org, mpls , draft-ietf-mpls-sfc-encapsulation.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000b626b60582f628b1" Archived-At: Subject: Re: [mpls] Secdir last call review of draft-ietf-mpls-sfc-encapsulation-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: Thu, 28 Feb 2019 15:44:04 -0000 --000000000000b626b60582f628b1 Content-Type: text/plain; charset="UTF-8" Paul, Thanks for your review! Adrian, I don't think I agree with your statement that the MPLS forwarding plane doesn't offer any security features. As I discuss in the last paragraph in the security considerations in the draft, it's resistant to some classes of attacks such as injecting unexpected packets unless the attacker was an insider or had specific inside knowledge, such as valid SFF labels that would be accepted by a receiving node. But then, it's difficult to defend against any sort of attack on a router by an insider, starting with having access to the physical box and the CLI. While there are no specific NSH security mechanisms, I don't think this draft is the place to have that discussion, as it's an MPLS WG draft. The draft does say that this encapsulation is no more or less secure than carrying the NSH in any other encapsulation. It's up to the SFC WG to figure out NSH security elsewhere. Cheers, Andy On Sun, Feb 17, 2019 at 7:08 PM Adrian Farrel wrote: > Hi Paul, > > Should we make the observation that, since the MPLS forwarding plane does > not offer any security features, if security is required it must be > provided by the SFC layer using some mechanisms inherent in the NSH. We > could/should probably also observe that, as yet, no NSH security mechanisms > have been defined. > > Cheers, > Adrian > > -----Original Message----- > From: ietf On Behalf Of Paul Wouters > Sent: 17 February 2019 23:58 > To: secdir@ietf.org > Cc: mpls@ietf.org; draft-ietf-mpls-sfc-encapsulation.all@ietf.org; > ietf@ietf.org > Subject: Secdir last call review of draft-ietf-mpls-sfc-encapsulation-02 > > Reviewer: Paul Wouters > 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 summary of the review is Ready > > While I'm not familiar with the Service Function Chaining (SFC) > architecture > and the Network Service Header (NSH), the Security Considerations in this > document seem to be correct in pointing out that: > > This document simply > defines one additional transport encapsulation. The NSH was > specially constructed to be agnostic to its transport encapsulation. > As as result, in general this additional encapsulation is no more or > less secure than carrying the NSH in any other encapsulation. > > > --000000000000b626b60582f628b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Paul,

Thanks for your review!

Adrian,

I don't think I agree = with your statement that the MPLS forwarding plane doesn't offer any se= curity features. As I discuss in the last paragraph in the security conside= rations in the draft, it's resistant to some classes of attacks such as= injecting unexpected packets unless the attacker was an insider or had spe= cific inside knowledge, such as valid SFF labels that would be accepted by = a receiving node. But then, it's difficult to defend against any sort o= f attack on a router by an insider, starting with having access to the phys= ical box and the CLI.

While there are no specific = NSH security=C2=A0mechanisms, I don't think this draft is the place to = have that discussion, as it's an MPLS WG draft. The draft does say that= this=C2=A0encapsulation=C2=A0is no more or= less secure than carrying the NSH in any other=C2=A0encapsulation. It's up to the SFC WG to figure out NSH securi= ty elsewhere.

Cheers,
Andy


On Sun, Feb 17, 2019 at 7:08 PM Adrian Farrel <adrian@olddog.co.uk> wrote:
<= /div>
Hi Paul,

Should we make the observation that, since the MPLS forwarding plane does n= ot offer any security features, if security is required it must be provided= by the SFC layer using some mechanisms inherent in the NSH. We could/shoul= d probably also observe that, as yet, no NSH security mechanisms have been = defined.

Cheers,
Adrian

-----Original Message-----
From: ietf <i= etf-bounces@ietf.org> On Behalf Of Paul Wouters
Sent: 17 February 2019 23:58
To: secdir@ietf.org
Cc: mpls@ietf.org; <= a href=3D"mailto:draft-ietf-mpls-sfc-encapsulation.all@ietf.org" target=3D"= _blank">draft-ietf-mpls-sfc-encapsulation.all@ietf.org; ietf@ietf.org
Subject: Secdir last call review of draft-ietf-mpls-sfc-encapsulation-02
Reviewer: Paul Wouters
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.=C2=A0 These comments were written primarily for the benefit of the security area directors.=C2=A0 Document editors and WG chairs should treat<= br> these comments just like any other last call comments.

The summary of the review is Ready

While I'm not familiar with the Service Function Chaining (SFC) archite= cture
and the Network Service Header (NSH), the Security Considerations in this document seem to be correct in pointing out that:

=C2=A0 This document simply
=C2=A0 =C2=A0defines one additional transport encapsulation.=C2=A0 The NSH = was
=C2=A0 =C2=A0specially constructed to be agnostic to its transport encapsul= ation.
=C2=A0 =C2=A0As as result, in general this additional encapsulation is no m= ore or
=C2=A0 =C2=A0less secure than carrying the NSH in any other encapsulation.<= br>

--000000000000b626b60582f628b1-- From nobody Thu Feb 28 18:03: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 23783130EE2; Thu, 28 Feb 2019 18:03:41 -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 R9WY0dxEsArj; Thu, 28 Feb 2019 18:03:39 -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 63990126C15; Thu, 28 Feb 2019 18:03:39 -0800 (PST) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 8D11F647A50118B77E62; Fri, 1 Mar 2019 02:03:37 +0000 (GMT) Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 1 Mar 2019 02:03:36 +0000 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.6]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0415.000; Fri, 1 Mar 2019 10:03:31 +0800 From: Mach Chen To: Loa Andersson , "mpls@ietf.org" CC: "mpls-chairs@ietf.org" , "draft-nainar-mpls-rfc8287-len-clarification@ietf.org" Thread-Topic: [mpls] working group adoption poll Thread-Index: AQHUznhA8NO/nn8sUE28o7wcoQNFgaX2CJQw Date: Fri, 1 Mar 2019 02:03:30 +0000 Message-ID: References: <19124c2d-c53b-5826-e7fa-b16616e7ef01@pi.nu> In-Reply-To: <19124c2d-c53b-5826-e7fa-b16616e7ef01@pi.nu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.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] 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: Fri, 01 Mar 2019 02:03:41 -0000 WWVzL3N1cHBvcnQuDQoNCkJlc3QgcmVnYXJkcywNCk1hY2gNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgTG9hIEFuZGVyc3Nvbg0KPiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI3 LCAyMDE5IDQ6NDEgUE0NCj4gVG86IG1wbHNAaWV0Zi5vcmcNCj4gQ2M6IG1wbHMtY2hhaXJzQGll dGYub3JnOyBkcmFmdC1uYWluYXItbXBscy1yZmM4Mjg3LWxlbi1jbGFyaWZpY2F0aW9uQGlldGYu b3JnDQo+IFN1YmplY3Q6IFttcGxzXSB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIHBvbGwNCj4gDQo+ IFdvcmtpbmcgR3JvdXAsDQo+IA0KPiBUaGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgcG9sbCBv biBhZG9wdGluZyBkcmFmdC1uYWluYXItbXBscy1yZmM4Mjg3LWxlbi0NCj4gY2xhcmlmaWNhdGlv bg0KPiBhcyBhIE1QTFMgd29ya2luZyBncm91cCBkb2N1bWVudC4NCj4gDQo+IFBsZWFzZSBzZW5k IHlvdXIgY29tbWVudHMgKHN1cHBvcnQvbm90IHN1cHBvcnQpIHRvIHRoZSBtcGxzIHdvcmtpbmcN Cj4gZ3JvdXAgbWFpbGluZyBsaXN0IChtcGxzQGlldGYub3JnKS4gUGxlYXNlIGdpdmUgYSB0ZWNo bmljYWwgbW90aXZhdGlvbiBmb3IgeW91cg0KPiBzdXBwb3J0L25vdCBzdXBwb3J0LCBlc3BlY2lh bGx5IGlmIHlvdSB0aGluayB0aGF0IHRoZSBkb2N1bWVudCBzaG91bGQgbm90IGJlDQo+IGFkb3B0 ZWQgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KPiANCj4gV2UgaGF2ZSBkb25lIGFuIElQ UiBwb2xsIGZvciB0aGlzIGRvY3VtZW50LiBBbGwgdGhlIGNvLWF1dGhvcnMgYW5kDQo+IGNvbnRy aWJ1dG9ycyBoYXZlIHJlc3BvbmRlZCB0byB0aGUgSVBSIHBvbGwgdGhhdCB0aGV5IGFyZSB1bmF3 YXJlIG9mIGFueQ0KPiBJUFJzIHRoYXQgcmVsYXRlcyB0byB0aGlzIGRyYWZ0Lg0KPiANCj4gVGhl cmUgYXJlIG5vIElQUiBkaXNjbG9zdXJlcyBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQuDQo+IA0KPiBU aGVyZSBoYXMgYWxzbyBiZWVuIGEgZGlzY3Vzc2lvbiBvbiBhZGRpbmcgdGV4dCBhdCB0aGUgZW5k IG9mIHNlY3Rpb24gNCB0aGF0DQo+IHNheXM6DQo+IA0KPiDigJxUaGUgRmlndXJlcyBpbiBTZWN0 aW9ucyA0LjEsIDQuMiwgYW5kIDQuMyByZXBsYWNlIHRoZSBjb3JyZXNwb25kaW5nIEZpZ3VyZXMN Cj4gaW4gUkZDIDgwMjkgIFNlY3Rpb25zIDUuMSwgNS4yLCBhbmQgNS4zIHJlc3BlY3RpdmVseS4g VGhlIHVwZGF0ZWQgZmlndXJlcw0KPiBjb250YWluIGV4cGxpY2l0bHkgZGVmaW5lZCBsZW5ndGgu 4oCdDQo+IA0KPiBUaGVyZSBoYXMgYWxzbyBiZWVuIGFuIGFncmVlbWVudCB0byBhZGQgdGhpcyBh ZnRlciB0aGUgYWRvcHRpb24uDQo+IA0KPiBUaGUgd29ya2luZyBncm91cCBhZG9wdGlvbiBwb2xs IGVuZHMgTWFyY2ggMTAsIDIwMTkuDQo+IA0KPiAvTG9hDQo+IA0KPiBtcGxzIHdnIGNvLWNoYWly DQo+IC0tDQo+IA0KPiANCj4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVt YWlsOiBsb2FAcGkubnUNCj4gU2VuaW9yIE1QTFMgRXhwZXJ0DQo+IEJyb256ZSBEcmFnb24gQ29u c3VsdGluZyAgICAgICAgICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbXBscyBtYWlsaW5n IGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21wbHMNCg==