From nobody Sat Jan 1 19:22:08 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C35D3A1CF3; Sat, 1 Jan 2022 19:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ozVh-dawGmx; Sat, 1 Jan 2022 19:22:02 -0800 (PST) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 52B663A1CF2; Sat, 1 Jan 2022 19:22:02 -0800 (PST) Received: by mail-pj1-x1036.google.com with SMTP id y16-20020a17090a6c9000b001b13ffaa625so34577955pjj.2; Sat, 01 Jan 2022 19:22:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=LZ+6cxm9K9JnEZ/lGn3cLDDJxOeCRWl2kR1DwxNJbNE=; b=iQpOIjnd5HeOI9LPLhid7LzxcBehHdoGaZVaSZ4kdrLn0xlCRLHH9PVFSSN4cMAvDG 5EffvF0JKfvxfe07qBEiX4PkUcH+hHvsirIP9jZMmQ8QZ6mTyD9qRGoC6TAXfbM8YNqt h7RRxVRNLOVuQ+P0rzSRV1gLtceRv3GtjmeqlTEsxfpgPLAqf6jesAs0vZ3IWTIuNlRk usIyMrgJT8Nok21NOF0x5usz2ApYQSS0CmpWbeR9tjybYEvpqiE50cntnnVfMPzHhE/r fC08L21jjHfeXYPq/2QP6xxJW7N0DRexhdz7CgwifHx+dy9+ufCH150+27ZgseGHn8sc 4PsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=LZ+6cxm9K9JnEZ/lGn3cLDDJxOeCRWl2kR1DwxNJbNE=; b=1hHF2cXk3LBeho4m2O7cU9tp2MQa1pZtMTT/Xk1cGD9/ZX1X0TWO9bG4seEJwqEAdL 5V8z10kubbiENsviXUAc59frAgALzScRgUUNcz6AFCNl+OwEtnzs30Maf1T7+0mrOUc6 tNtl3OfpVadE1ey36TEWrzy88MSArZrkmKFNYwbC4ZuDzKVK/r83NvCgBQzpb+VE7h4r f4hNDrdQJAIbsnKHd2QIzoBvOnHuXUHSkS4u3fXFiR/xiOdTqSVXyaesvGmGanqa214r NW5YUPCzU+oMNLlrJsfWacs/U4NGfcvPB3hyEANqxZ8fedcif8q9QTrT5jTCnyQicIgo +FgA== X-Gm-Message-State: AOAM531MwOPnMXiDC0vHzAzDoG19sMGDTxUphktnZ95gVWTJTEKQVqB7 b/4CcZ/YL1akteIUFW5Egq4= X-Google-Smtp-Source: ABdhPJzuTAJPzzR/I0KHdcpCh+YWyHFasmj6siBTn+cnaklQrHLElU70UFwJbGhZid5E/P0Yf3RrIw== X-Received: by 2002:a17:903:2285:b0:149:1a20:1275 with SMTP id b5-20020a170903228500b001491a201275mr40296876plh.161.1641093717986; Sat, 01 Jan 2022 19:21:57 -0800 (PST) Received: from smtpclient.apple (172-125-79-142.lightspeed.sntcca.sbcglobal.net. [172.125.79.142]) by smtp.gmail.com with ESMTPSA id h191sm29119417pge.55.2022.01.01.19.21.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Jan 2022 19:21:57 -0800 (PST) From: Kireeti Kompella Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_357C2556-04FE-4BF0-8140-0083C1F03B52" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Sat, 1 Jan 2022 19:21:56 -0800 In-Reply-To: Cc: Kireeti Kompella , "draft-kompella-mpls-larp@ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" To: Tarek Saad References: X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [mpls] IPR poll for draft-kompella-mpls-larp 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, 02 Jan 2022 03:22:07 -0000 --Apple-Mail=_357C2556-04FE-4BF0-8140-0083C1F03B52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes, I (a co-author on the draft) am aware of IPR that applies to this = draft.=20 Yes, the IPR has been disclosed in compliance with IETF IPR rules (# = 2660). Kireeti. > On Dec 28, 2021, at 09:02, Tarek Saad wrote: >=20 > Authors, Contributors, WG, > =20 > This email initiates an IPR poll for draft-kompella-mpls-larp in = anticipation of its working group adoption poll. > =20 > Are you aware of any IPR that applies to the draft identified above? > =20 > Please state either: > =20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > =20 > If so, has this IPR been disclosed in compliance with IETF IPR rules = (see RFCs 3669, 5378 and 8179 for more details)? > =20 > If yes to the above, please state either: > =20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > =20 > If you answer no, please provide any additional details you think = appropriate. If you are listed as a document author or contributor = please answer the above by responding to this email regardless of = whether or not you are aware of any relevant IPR.=20 > =20 > This document will not advance to the next stage until a response has = been received from each author. > Note, currently there is one IPR disclosure listed against this = document:https://datatracker.ietf.org/ipr/2660/ = > =20 > If you are on the WG email list or attend WG meetings but are not = listed as an author or contributor, we remind you of your obligations = under the IETF IPR rules which encourages you to notify the IETF if you = are aware of IPR of others on an IETF contribution, or to refrain from = participating in any contribution or discussion related to your = undisclosed IPR. For more information, please see the RFCs listed above = and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty = . > =20 > =20 > **The response needs to be sent to the MPLS WG mailing list.** > =20 > We expect responses from the co-authors: > Kireeti Kompella > Balaji Rajagopalan > Reji Thomas > =20 > The document has no contributors listed. > =20 > Regards > Tarek (MPLS WG co-chair) --Apple-Mail=_357C2556-04FE-4BF0-8140-0083C1F03B52 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yes, = I (a co-author on the draft) am aware of IPR that applies to this = draft. 
Yes, the IPR has been disclosed in compliance = with IETF IPR rules (# 2660).

Kireeti.

On Dec = 28, 2021, at 09:02, Tarek Saad <tsaad.net@gmail.com> wrote:

Authors, Contributors, WG,
 
This email initiates an IPR poll = for draft-kompella-mpls-larp in anticipation of its working = group adoption poll.
 
Are you aware of any IPR that = applies to the draft identified above?
 
Please state either:
 
"No, I'm not aware of any IPR that = applies to this draft"
or
"Yes, I'm aware of IPR that = applies to this draft"
 
If so, has this IPR been disclosed = in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for more = details)?
 
If yes to the above, please state = either:
 
"Yes, the IPR has been disclosed = in compliance with IETF IPR rules"
or
"No, the IPR has not been = disclosed"
 
If you answer no, please provide = any additional details you think appropriate. If you are listed as a = document author or contributor please answer the above by responding to = this email regardless of whether or not you are aware of any relevant = IPR. 
 
This document will not advance to = the next stage until a response has been received from each author.
Note, currently there is one IPR = disclosure listed against this document:https://datatracker.ietf.org/ipr/2660/
 
If you are on the WG email list or = attend WG meetings but are not listed as an author or contributor, we = remind you of your obligations under the IETF IPR rules which encourages = you to notify the IETF if you are aware of IPR of others on an IETF = contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please = see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualPro= perty.
 
 
**The response needs to be sent to = the MPLS WG mailing list.**
 
We expect responses from the = co-authors:
Kireeti Kompella
Balaji Rajagopalan
Reji Thomas
 
The document has no contributors = listed.
 
Regards
Tarek (MPLS WG = co-chair)

= --Apple-Mail=_357C2556-04FE-4BF0-8140-0083C1F03B52-- From nobody Sat Jan 1 21:42:24 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8403E3A1EA9; Sat, 1 Jan 2022 21:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjyfwUrFdfZ7; Sat, 1 Jan 2022 21:42:18 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 EA0BC3A1EA7; Sat, 1 Jan 2022 21:42:17 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id q8so35260574ljp.9; Sat, 01 Jan 2022 21:42:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Urv7z6rGRIHR4c+lHIuNZR3VQ3/qdvGAGmMBcLYPOTU=; b=jvX5piv7RqXOg9uPcbgVsB4qLYhJ3m+WoNU3GhNeUPqL/49/JvyL6NBl6/F0HAB1eh g8jLEMM2CcR/gsgI2O0UUPBWm+gW2cX8eHlpsCtb9QpfUTVf5uk5AY9NbBhI6hMjrbLI 8xuVwbANYzqL5HPXDlCDcsFcsrvUeEP+EPWSw5qIDbbHrcAa598l1h+rsZ/LV2uHucvH E5bhqYKTD4chncsz5XCpzQMKSVUgC92HnbxZPNqZYn4MJnR7C7ySQ2apNYTyp20NhTWh bIVMdprI+yM+YbT1S8073E0yIL029kHgHeiPL3TsInLEvCdJdq6Mm4sbXMffhL0rirBT ridg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Urv7z6rGRIHR4c+lHIuNZR3VQ3/qdvGAGmMBcLYPOTU=; b=4zsvzmvd4aqFiS+DH4keYy3tKdcevpZzTlg8LLKa1ayxOfGWo/ZQyW8Uvufwk4FFKb iIgUJzgoFiZtpp2mpF2BUnrHvHxTQv/jDjKtD0qUgNqtTuUwC6nqK6TNbKveDYC/YL3q oVa4VtrYHh+JXbhkeOBaw9WOGLWad1pWZTt93Tq6eyCMJzHIDv7u+sKeA+i6E2yTzlDj +SCDIx+b0Wv8WkS6ZsG7Hh/QrOEUA/KN9m8AXdbpKJxlvv2KNBhUxT5LIsQK4OdVX9Y/ JX4BYqVsYF0EMVmhM3OPEaRLDfxvK2BAGWe6MhpQfoIIyJw/ZkjyYrGhWAHphZvsQSii B36g== X-Gm-Message-State: AOAM53294RKmKVdCP9lJbsoKz/Eva//bd5eTTAG+y5ygg7wpszAjx+2o QL95UxswytqON5dWIfcTz6EBRc0DCpUAL+nvs+DDdeg= X-Google-Smtp-Source: ABdhPJzMu4jhZXDO5DGl+rTbgURjhmZxJo7J6bkNM8Q4i2WAtZlLzwnldfNY0v4qHkqClqJC3X7uFrB9bOqeoXAT8s4= X-Received: by 2002:a2e:5151:: with SMTP id b17mr34278719lje.213.1641102132183; Sat, 01 Jan 2022 21:42:12 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Reji Thomas Date: Sun, 2 Jan 2022 11:12:01 +0530 Message-ID: To: Tarek Saad Cc: draft-kompella-mpls-larp@ietf.org, mpls@ietf.org, mpls-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000a1070005d492dd6b" Archived-At: Subject: Re: [mpls] IPR poll for draft-kompella-mpls-larp 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, 02 Jan 2022 05:42:23 -0000 --000000000000a1070005d492dd6b Content-Type: text/plain; charset="UTF-8" Hi, I am aware of the IPR that applies to the draft and the same has been disclosed in compliance with IETF IPR rules(#2660) Regards Reji Thomas On Tue, Dec 28, 2021, 10:32 PM Tarek Saad wrote: > Authors, Contributors, WG, > > > > This email initiates an IPR poll for draft-kompella-mpls-larp in > anticipation of its working group adoption poll. > > > > Are you aware of any IPR that applies to the draft identified above? > > > > Please state either: > > > > "No, I'm not aware of any IPR that applies to this draft" > > or > > "Yes, I'm aware of IPR that applies to this draft" > > > > If so, has this IPR been disclosed in compliance with IETF IPR rules (see > RFCs 3669, 5378 and 8179 for more details)? > > > > If yes to the above, please state either: > > > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > > or > > "No, the IPR has not been disclosed" > > > > If you answer no, please provide any additional details you think > appropriate. If you are listed as a document author or contributor please > answer the above by responding to this email regardless of whether or not > you are aware of any relevant IPR. > > > > This document will not advance to the next stage until a response has been > received from each author. > > Note, currently there is one IPR disclosure listed against this document: > https://datatracker.ietf.org/ipr/2660/ > > > > If you are on the WG email list or attend WG meetings but are not listed > as an author or contributor, we remind you of your obligations under the > IETF IPR rules which encourages you to notify the IETF if you are aware of > IPR of others on an IETF contribution, or to refrain from participating in > any contribution or discussion related to your undisclosed IPR. For more > information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > > > > > **The response needs to be sent to the MPLS WG mailing list.** > > > > We expect responses from the co-authors: > > Kireeti Kompella > > Balaji Rajagopalan > > Reji Thomas > > > > The document has no contributors listed. > > > > Regards > > Tarek (MPLS WG co-chair) > --000000000000a1070005d492dd6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I a= m aware of the IPR that applies to the draft and the same has been disclose= d in compliance with IETF IPR rules(#2660)

Regards
Reji Thomas


=
On Tue, Dec 28, 2021, 10:32 PM Tarek Saad <tsa= ad.net@gmail.com> wrote:

Authors, Contributo= rs, WG,

=C2=A0

This email initiate= s an IPR poll for draft-kompella-mpls-larp in anticipation of its working g= roup=C2=A0adoption poll.

=C2=A0

Are you aware of an= y IPR that applies to the draft identified above?

=C2=A0

Please state either= :

=C2=A0

"No, I'm n= ot aware of any IPR that applies to this draft"

or

"Yes, I'm = aware of IPR that applies to this draft"

=C2=A0

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

=C2=A0

If yes to the above= , please state either:

=C2=A0

"Yes, the IPR = has been disclosed in compliance with IETF IPR rules"

or

"No, the IPR h= as not been disclosed"

=C2=A0

If you answer no, p= lease provide any additional details you think appropriate. If you are list= ed as a document author or contributor please answer the above by respondin= g to this email regardless of whether or not you are aware of any relevant IPR.

=C2=A0

This document will = not advance to the next stage until a response has been received from each = author.

Note, currently the= re is one IPR disclosure listed against this document: https://datatracker.ietf.org/= ipr/2660/

=C2=A0

If you are on the W= G email list or attend WG meetings but are not listed as an author or contr= ibutor, we remind you of your obligations under the IETF IPR rules which en= courages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from par= ticipating in any contribution or discussion related to your undisclosed IP= R. For more information, please see the RFCs listed above and http://trac.= tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.=

=C2=A0

=C2=A0

**The response need= s to be sent to the MPLS WG mailing list.**

=C2=A0

We expect responses= from the co-authors:

Kireeti Kompella=

Balaji Rajagopalan<= u>

Reji Thomas<= u>

=C2=A0

The document has no= contributors listed.

=C2=A0

Regards

Tarek (MPLS WG co-c= hair)

--000000000000a1070005d492dd6b-- From nobody Mon Jan 3 06:38:13 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E693A0900 for ; Mon, 3 Jan 2022 06:38:11 -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, CTE_8BIT_MISMATCH=0.001, 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 OEjNro41brm4 for ; Mon, 3 Jan 2022 06:38:06 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E20B43A08FD for ; Mon, 3 Jan 2022 06:38:04 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 499) id 36966358B1; Mon, 3 Jan 2022 06:38:03 -0800 (PST) To: rfc-editor@rfc-editor.org From: RFC Errata System Cc: jamesmrice2020@gmail.com, kireeti.kompella@gmail.com, swallow.ietf@gmail.com, cpignata@cisco.com, naikumar@cisco.com, aldrin.ietf@gmail.com, mach.chen@huawei.com, mpls@ietf.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20220103143803.36966358B1@rfc-editor.org> Date: Mon, 3 Jan 2022 06:38:03 -0800 (PST) Archived-At: Subject: [mpls] [Editorial Errata Reported] RFC8029 (6803) 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, 03 Jan 2022 14:38:12 -0000 The following errata report has been submitted for RFC8029, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6803 -------------------------------------- Type: Editorial Reported by: James M Rice Section: 2070-1721 Original Text ------------- N/A Corrected Text -------------- RFC 8029, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", March 2017 Notes ----- Published the Errata 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. -------------------------------------- RFC8029 (draft-ietf-mpls-rfc4379bis-09) -------------------------------------- Title : Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures Publication Date : March 2017 Author(s) : K. Kompella, G. Swallow, C. Pignataro, Ed., N. Kumar, S. Aldrin, M. Chen Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon Jan 3 07:35:13 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256B13A0A83 for ; Mon, 3 Jan 2022 07:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSefJqkmGT4C for ; Mon, 3 Jan 2022 07:35:05 -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 BD6CC3A0A81 for ; Mon, 3 Jan 2022 07:35:05 -0800 (PST) Received: from [192.168.1.98] (unknown [122.2.110.30]) (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 E6032365AD6; Mon, 3 Jan 2022 16:35:00 +0100 (CET) Message-ID: Date: Mon, 3 Jan 2022 23:34:57 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-CA To: RFC Errata System Cc: mpls@ietf.org, jamesmrice2020@gmail.com References: <20220103143803.36966358B1@rfc-editor.org> From: Loa Andersson In-Reply-To: <20220103143803.36966358B1@rfc-editor.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [mpls] [Editorial Errata Reported] RFC8029 (6803) 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, 03 Jan 2022 15:35:11 -0000 RFC Editor, et.al., This errata confuses me "Section: 2070-1721" seem to take me outside the document. I'm not saying that it is not an errata, only that I don't recognize the information as supplied by the wg. I will need to help sort this out. /Kia On 03/01/2022 22:38, RFC Errata System wrote: > The following errata report has been submitted for RFC8029, > "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6803 > > -------------------------------------- > Type: Editorial > Reported by: James M Rice > > Section: 2070-1721 > > Original Text > ------------- > N/A > > Corrected Text > -------------- > RFC 8029, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", March 2017 > > Notes > ----- > Published the Errata > > 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. > > -------------------------------------- > RFC8029 (draft-ietf-mpls-rfc4379bis-09) > -------------------------------------- > Title : Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures > Publication Date : March 2017 > Author(s) : K. Kompella, G. Swallow, C. Pignataro, Ed., N. Kumar, S. Aldrin, M. Chen > 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 -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Mon Jan 3 07:40:57 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871493A0028 for ; Mon, 3 Jan 2022 07:40:56 -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, SPF_HELO_NONE=0.001, 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 zDWFzdii98UA for ; Mon, 3 Jan 2022 07:40:51 -0800 (PST) Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2DEE3A0C29 for ; Mon, 3 Jan 2022 07:39:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id B3957424B435; Mon, 3 Jan 2022 07:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMtHnlfExm1i; Mon, 3 Jan 2022 07:39:56 -0800 (PST) Received: from smtpclient.apple (2603-8000-9603-b513-c156-6a6c-f038-f03d.res6.spectrum.com [IPv6:2603:8000:9603:b513:c156:6a6c:f038:f03d]) by c8a.amsl.com (Postfix) with ESMTPSA id 617E7424B434; Mon, 3 Jan 2022 07:39:56 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Sandy Ginoza In-Reply-To: Date: Mon, 3 Jan 2022 07:39:54 -0800 Cc: RFC Editor , mpls@ietf.org, jamesmrice2020@gmail.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220103143803.36966358B1@rfc-editor.org> To: Loa Andersson X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [mpls] [Editorial Errata Reported] RFC8029 (6803) 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, 03 Jan 2022 15:40:57 -0000 Hi Loa, I believe this mail is incorrect and it will be deleted. =20 Thanks, Sandy=20 > On Jan 3, 2022, at 7:34 AM, Loa Andersson wrote: >=20 > RFC Editor, et.al., >=20 > This errata confuses me "Section: 2070-1721" seem to take me outside = the document. I'm not saying that it is not an errata, only that I don't = recognize the information as supplied by the wg. >=20 > I will need to help sort this out. >=20 > /Kia >=20 >=20 > On 03/01/2022 22:38, RFC Errata System wrote: >> The following errata report has been submitted for RFC8029, >> "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures". >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid6803 >> -------------------------------------- >> Type: Editorial >> Reported by: James M Rice >> Section: 2070-1721 >> Original Text >> ------------- >> N/A >> Corrected Text >> -------------- >> RFC 8029, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane = Failures", March 2017 >> Notes >> ----- >> Published the Errata >> 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. >> -------------------------------------- >> RFC8029 (draft-ietf-mpls-rfc4379bis-09) >> -------------------------------------- >> Title : Detecting Multiprotocol Label Switched (MPLS) = Data-Plane Failures >> Publication Date : March 2017 >> Author(s) : K. Kompella, G. Swallow, C. Pignataro, Ed., N. = Kumar, S. Aldrin, M. Chen >> 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 >=20 > --=20 > Loa Andersson email: loa@pi.nu > Senior MPLS Expert loa.pi.nu@gmail.com > Bronze Dragon Consulting phone: +46 739 81 21 64 >=20 From nobody Mon Jan 3 08:37:32 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5AD3A07D9 for ; Mon, 3 Jan 2022 08:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=iecc.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 4pHSGVrfuRHG for ; Mon, 3 Jan 2022 08:37:24 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 139653A07D8 for ; Mon, 3 Jan 2022 08:37:23 -0800 (PST) Received: (qmail 86108 invoked from network); 3 Jan 2022 16:37:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=1505a.61d32640.k2201; bh=1+mj3fsDSomnJTQLm/SiKGd3FyWFcI69tSP2DQ6Yw9U=; b=iX8MUoLYY8w0bSDLWr3RE3Dx5sUFFg/1o57Go4IDAowmQiRhsfS5lJC1SB0kulihGef9aDsPqKiiB0EcQD9QPW1tfFr/OIAu3jXnl98Dx3Q9QIkyFss1QvNOMlNVHDi0V8BX3xMPc9whr5rDjPcflFErO5C8ZlC64ALWV4V/6ePgk1blNsZellwoz2R6l9UdEhgWUko8XZ6CRI6kKZ2v9xgWZE16Hj4vDmfewxmULbLYNFUP/nX+rdL5B+j3fm5MnkaPl9MTvUO+5n+UB6LzZz/Co6DJGidlIscJfL+jOkRQbsELjutHeXeSPUCd4DMlEOf52u9q+ZDYVBdIXcOQ7A== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 03 Jan 2022 16:37:19 -0000 Received: by ary.qy (Postfix, from userid 501) id 82415342E24E; Mon, 3 Jan 2022 11:37:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id E6DF7342E230; Mon, 3 Jan 2022 11:37:18 -0500 (EST) Date: 3 Jan 2022 11:37:18 -0500 Message-ID: From: "John R. Levine" To: "Sandy Ginoza" , "Loa Andersson" Cc: "RFC Editor" , mpls@ietf.org X-X-Sender: johnl@ary.qy In-Reply-To: References: <20220103143803.36966358B1@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [mpls] [Editorial Errata Reported] RFC8029 (6803) 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, 03 Jan 2022 16:37:29 -0000 > I believe this mail is incorrect and it will be deleted. The same person submitted several errata, none of which make any sense I can find. R's, John > >> On Jan 3, 2022, at 7:34 AM, Loa Andersson wrote: >> >> RFC Editor, et.al., >> >> This errata confuses me "Section: 2070-1721" seem to take me outside the document. I'm not saying that it is not an errata, only that I don't recognize the information as supplied by the wg. >> >> I will need to help sort this out. >> >> /Kia >> >> >> On 03/01/2022 22:38, RFC Errata System wrote: >>> The following errata report has been submitted for RFC8029, >>> "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures". >>> -------------------------------------- >>> You may review the report below and at: >>> https://www.rfc-editor.org/errata/eid6803 >>> -------------------------------------- >>> Type: Editorial >>> Reported by: James M Rice >>> Section: 2070-1721 >>> Original Text >>> ------------- >>> N/A >>> Corrected Text >>> -------------- >>> RFC 8029, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", March 2017 >>> Notes >>> ----- >>> Published the Errata >>> 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. >>> -------------------------------------- >>> RFC8029 (draft-ietf-mpls-rfc4379bis-09) >>> -------------------------------------- >>> Title : Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures >>> Publication Date : March 2017 >>> Author(s) : K. Kompella, G. Swallow, C. Pignataro, Ed., N. Kumar, S. Aldrin, M. Chen >>> 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 >> >> -- >> Loa Andersson email: loa@pi.nu >> Senior MPLS Expert loa.pi.nu@gmail.com >> Bronze Dragon Consulting phone: +46 739 81 21 64 >> > > Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Jan 3 17:10:14 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F283A135D for ; Mon, 3 Jan 2022 17:10:12 -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, SPF_HELO_NONE=0.001, 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 TXKJIMNfs0BV for ; Mon, 3 Jan 2022 17:10:08 -0800 (PST) Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965C53A1359 for ; Mon, 3 Jan 2022 17:10:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 8073A425A344; Mon, 3 Jan 2022 17:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwXz7xKp3Ehu; Mon, 3 Jan 2022 17:10:08 -0800 (PST) Received: from [192.168.1.16] (cpe-76-95-228-63.socal.res.rr.com [76.95.228.63]) by c8a.amsl.com (Postfix) with ESMTPSA id 373D9424B435; Mon, 3 Jan 2022 17:10:08 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Chris Smiley In-Reply-To: <20220103143803.36966358B1@rfc-editor.org> Date: Mon, 3 Jan 2022 17:10:07 -0800 Cc: RFC Errata System Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220103143803.36966358B1@rfc-editor.org> To: kireeti.kompella@gmail.com, swallow.ietf@gmail.com, cpignata@cisco.com, naikumar@cisco.com, mpls@ietf.org, mach.chen@huawei.com, Sam Aldrin X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [mpls] [Editorial Errata Reported] RFC8029 (6803) 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, 04 Jan 2022 01:10:13 -0000 Greetings, FYI - this report has been deleted as junk. Thank you. RFC Editor/cs > On Jan 3, 2022, at 6:38 AM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC8029, > "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6803 >=20 > -------------------------------------- > Type: Editorial > Reported by: James M Rice >=20 > Section: 2070-1721 >=20 > Original Text > ------------- > N/A >=20 > Corrected Text > -------------- > RFC 8029, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane = Failures", March 2017 >=20 > Notes > ----- > Published the Errata >=20 > 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 >=20 > -------------------------------------- > RFC8029 (draft-ietf-mpls-rfc4379bis-09) > -------------------------------------- > Title : Detecting Multiprotocol Label Switched (MPLS) = Data-Plane Failures > Publication Date : March 2017 > Author(s) : K. Kompella, G. Swallow, C. Pignataro, Ed., N. = Kumar, S. Aldrin, M. Chen > Category : PROPOSED STANDARD > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG >=20 From nobody Mon Jan 3 18:35:37 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8173C3A1490 for ; Mon, 3 Jan 2022 18:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGW1WqoS8iRU for ; Mon, 3 Jan 2022 18:35:31 -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 051683A148F for ; Mon, 3 Jan 2022 18:35:30 -0800 (PST) Received: from [192.168.1.98] (unknown [122.2.110.30]) (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 DDAB2365AE8 for ; Tue, 4 Jan 2022 03:35:26 +0100 (CET) Message-ID: Date: Tue, 4 Jan 2022 10:35:24 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-CA To: "mpls@ietf.org" From: Loa Andersson Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] MPLS Open DT meeting -- Thursday January 6 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, 04 Jan 2022 02:35:36 -0000 MPLS Open DT, This coming Thursday (January 6th) we will have our first Open DT meeting for 2022. The chairs are still working on the agenda, but it will be posted later today. /Loa -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Tue Jan 4 00:01:23 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6193A0BFC; Tue, 4 Jan 2022 00:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=lR3Krxxw; dkim=pass (1024-bit key) header.d=juniper.net header.b=GNNSeHoW 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 gJ1uje1GxOfc; Tue, 4 Jan 2022 00:01:16 -0800 (PST) Received: from mx0b-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 C203B3A0BFB; Tue, 4 Jan 2022 00:01:16 -0800 (PST) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 2045K9xd013104; Tue, 4 Jan 2022 00:01:12 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=IndkFr2R3uMu5RNwQCYpL3XS/yD6pKrQNbnxIr0DZ1U=; b=lR3Krxxw0GIqhI37dI2A+UKFu3hPR27Y5AfWcfK0VJMICreoMiRK1UyQ/SM0s8y5dc1i oir+75nYiwlcs0HBRCK/XB1nF5rki53kHv90VLKmrTko2iRQk4e6zjDE35w1U9f+UNhZ TNgTkdbsW98tI/IIVp/L4RtzbP6+9zqPI1G/rBcGyyLCOAj76ZVhFOxeJeEaAJTUvKBZ +DxG1FdLVPWOG+ohY93YsdjbDWlkLci9HJ+VQPRwXe723MWuqWvssLaIw1ZgrAv8xokn CNnI6W0Hplsws8GkwK8g6d0PDUoOOupHQlikTobGxHNeac/ATX2TbiDFR+szjBKBT68O kA== Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2048.outbound.protection.outlook.com [104.47.66.48]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3dcg0dg67d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 04 Jan 2022 00:01:12 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hY2dw1KKW4fYO1Tm1l2+k57WqDmQ6fatWHRHnn1nhPJcZM1D+hyBWUaOV80oEqN61wAajZk+CkrZdrmLFboa1Qei7IvtLftKCVfW1M+i5ZlYQ2raWTphfAi7fqnbbBmbQ4KqvMzqt0rMojWSZVY89FPTVc0UsHt34YqZ1fRdPyP+HjvdUJPYIIvZMQeTZ/UA1rPAA8dvAzZUYfAZuHmVM17AaGIKwCLYTCvqCSzeWJcZVFiQGO4TVlqi+BglhCYwrft7+KLvJ6aUdwOH2pbmySg6rl4pddNblwIE/BSglGTEfccLxfjjMcR3HixFS7WQqoJJqkkiRMkVbq9ap1VtXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IndkFr2R3uMu5RNwQCYpL3XS/yD6pKrQNbnxIr0DZ1U=; b=A01cLYdvCutQnkjcJvEQMWbZKzHlg5S4D7myuvXFPwDwv+R07vYzAR8Aj8Ju9eREo9yL4lpSIeV4z2g2yFMRYppEC1ztJOvviHjPk30PTlfz2R71oneVPx1FHZZKFOXsUY1HPj8WD1cB+tfbjjA/QA0rw7pHyODby774I/Nvj80PHLClqwqjQWrqBPRf3lp26PyH7TpO5BrQZaHLnNpA8dyrcxOF64dlY8U0wkDpN9T5NbOb9T4gXGG3Uh1cJqBgtE7A3ni9/2h3nDBWEMHnc6B3IU+vTuL3pY1MMtafCNKM/vmZswfwnq6JkaCMcPFTPzH4I9Or7MBupPJ6+O4vPg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IndkFr2R3uMu5RNwQCYpL3XS/yD6pKrQNbnxIr0DZ1U=; b=GNNSeHoW3HU6R2bcmJ/IdmBA1ZpW9keNXKJ7JxD/zVYkrI8DY/JWw1FtLIPCLt44pYk1OHe0I4qBJ5QLHU+HYyy9h7NyRX/6xRVDDP15kNnU8Licpf8gTXtEeyE6EEA7+mjFbNMvhWEG825nAOPOVXSbRoS0xQtongjrSYs9TNU= Received: from CO6PR05MB7729.namprd05.prod.outlook.com (2603:10b6:5:34e::10) by CO1PR05MB7927.namprd05.prod.outlook.com (2603:10b6:303:f7::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4867.4; Tue, 4 Jan 2022 08:01:10 +0000 Received: from CO6PR05MB7729.namprd05.prod.outlook.com ([fe80::d5d3:35f4:ace:2fb8]) by CO6PR05MB7729.namprd05.prod.outlook.com ([fe80::d5d3:35f4:ace:2fb8%9]) with mapi id 15.20.4867.007; Tue, 4 Jan 2022 08:01:10 +0000 From: Balaji Rajagopalan To: Tarek Saad , "draft-kompella-mpls-larp@ietf.org" CC: "mpls@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: IPR poll for draft-kompella-mpls-larp Thread-Index: AQHX/AytU/uzBnIMZkyMHZ88m5MGlaxSiS9J Date: Tue, 4 Jan 2022 08:01:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2022-01-04T07:56:55.1122083Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0e1af433-3a06-4ef2-1869-08d9cf585ebb x-ms-traffictypediagnostic: CO1PR05MB7927:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IGH8pQUTYxJnAlUqbDsv9syFSsNa4ELhyutQCDO6qcbT9ENO0b/5MjRhXKBmoR8bo76WUwYIs3vHcIudkF+qNFRNdBW1+Q9PLmZSeZahcPXHG7KblJds31EhGcpR75Fvfn9C4x6kRzgqv5+EkXq1gmm4QIaRgggkGKxritZpHUlRslmGEmMkf5Nus8qk4OvrRYQ9TesOBKjcgwlq8A5m1SlTEjgVMiY/7YSasCpMD5u1k3B1yb9U0Ybua50GmEpFGpC55gyq+pUIIVeutaV5i9ELdJyFGxpsdy7NgujIQWjtNcUMRM6SygsaJNyj28MNYw3LG+7/ZAsCel/acvnKMZdyvI0YCTLG/7GA8248EfsQZTH9l3kn8eK/vKC19YXC/QwcfgvP9tLf9AHTWhqluAQAfMaoDfXf2DGuiEtzgfjN9ygrx4bQhPVzWAsHqpfoHvK4we2nTwsIq+depUonfdama8z+ZF4hnEaDFvQLPgGrgjuLGES909Grb1uR7Aqo3vwBA5IxG9vmbAefC3OqhQtPn8964KgtOa2lW/CSX84DtCfc/EcTHT++mV52eQUKSFTLEcRrIP3o0wbkylrHTawhf3nttjp7Q4LwIes6NH+j28jgyvR6K9QoCWJGdtMFnxFoP9som9Jp0+9N0wmZs46gJ7nSXmYUX8M7aUFNCoTcp6NavuBTs7fKGsdfnEzxyo0hup79B7X7O5AJAcLfzJvRXxGnEmWN56zV6c9eL9M2yzluUH4GQDa6Ifo5B9piVxBdpHw1Cfpj4HrWA3yngbP9mhawI1hon1Dh55rpwY5YsBszMpD/TSkJx+FFHrqT7kHEi4sRmyzcwAiqpf4PHA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR05MB7729.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(5660300002)(38070700005)(966005)(71200400001)(52536014)(186003)(508600001)(9326002)(6506007)(76116006)(26005)(7696005)(66946007)(9686003)(91956017)(86362001)(33656002)(55016003)(110136005)(122000001)(38100700002)(4326008)(8936002)(53546011)(8676002)(166002)(316002)(66476007)(2906002)(64756008)(66556008)(54906003)(83380400001)(66446008)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?fIDyVFIQlf/WX6d5Ca69JHEc5X6O2KkcpMC+J9F/NOuU8YF82W2NwOQB?= =?Windows-1252?Q?XZLZNiKtZMDidSYwfUE3I/JV3OS6NB/RkBq5YDfLUg/h5zyxU1zIg7tk?= =?Windows-1252?Q?qu29lTDqnfn2/uwHpG2ZrVZFv/iMqht8f0TjQ+/SudzbtQK9eOyEPoqA?= =?Windows-1252?Q?TXwiWM3sSsoNGgAz9TeLc6OYzUYSdsW+aWu6nHWKYpBAQ7qHFKJllgBr?= =?Windows-1252?Q?F6IyuzZEorZ5M2nItoPsLXeAuELvHQayhCDt6/HYJW4uUFfhdaf0pL8J?= =?Windows-1252?Q?T1NRU+ZTeRL60oZCANbcBkp6h6w044ubxEAfZnYghWdGWNObCe27awjD?= =?Windows-1252?Q?jUy3cBPsD4nD29H9dXbc3Tyj0UKX4vDTGasWBeeOIbXSsHggpapGEJdl?= =?Windows-1252?Q?rDQz3BjHsSuWat4JFhNpx0UB0usulSf9oGi3ZJyZ6Y0RvTAiHBK7L1Wv?= =?Windows-1252?Q?5qr+1Qfo2EoqTrFdk+3WxiMFnl83cyCmSJHwCtxHQ4KKZ2rreQsoHFRi?= =?Windows-1252?Q?0RnHdpmEXKDxaOyqfRDfPrIVsHlOEecAODqYCTu44utlQ28yB+/vkPZC?= =?Windows-1252?Q?4MN1FRLvAmQcDNJ/KcPNLi3A6OBL6xvuToKX6b0qOc/H5irVOBLz7+Qx?= =?Windows-1252?Q?zrI0Cr5KMBcG4UOlH1tbI4AqzmQYrmjtlvB3egZZn+PKtr3GU/ZSvLKo?= =?Windows-1252?Q?n0ADR4kmgjBBaLFlbbM/CpBbwXZTerrGpjziFBZ8oL/0jxDBIqU0jsPM?= =?Windows-1252?Q?N4i4LvA7V+kAVBkdCsi/Dtjg+AwpH4ZSaqO1xngFwHrD7e0Rpj7Upd2e?= =?Windows-1252?Q?LWTR0QdAvnfConO530WUA0eFIjLVDzoEm+N/5slb/D3XSMDgU7o1xcZD?= =?Windows-1252?Q?oe4C2cZRKMR8yDCeZFDHc25n5YG07zAc57quqtSpPOJ3uZFwhdzJcZUZ?= =?Windows-1252?Q?Fg9ySaJZdbWPkf8ezCkAIJ7rWHUw8g6+fZ6wvGdzJPBHp6ok9gkmrf0c?= =?Windows-1252?Q?aEJRWQre7KxH/JL/l8bc60DXbdyfoe4k9VU6XeTcSEjg4GlDGIrgfPKG?= =?Windows-1252?Q?p2UXbEBDpBjl665C02Y33uLLc4huw883Dx4k+Jak5XiRfWejxLDpVk0k?= =?Windows-1252?Q?yEL5c0sWvVYQ+7/CaFCWsxlx/jJdHoR4jqe7LTgF2W28ieWqqwf4CRva?= =?Windows-1252?Q?u5sz3YetQWLNkEP8kb58r9fWNj0RX31oL6Do5R8fWpg62zVQzqdLReuJ?= =?Windows-1252?Q?e0PDoA4zupOGTo4fnO1lI2ZOvlcJNv+nBEZNXAV+uj27nJ+wXNkjFehY?= =?Windows-1252?Q?D5B/wMLrv40UGGkLhoLGIrmzfV8TgUyXw8MytcXnm2/frpjyiSUlMN9i?= =?Windows-1252?Q?OUuen83i1VkGs62YS+AJFt4mN0LlV23SydxRatXvHYtJsE/ZGJSYjkCn?= =?Windows-1252?Q?Y81aXGfZswYpbdXm+Ca84El+cStdctewtsE7ISquZa/yCgHhEqTy5Bc2?= =?Windows-1252?Q?7380f1m2WdpnPEZYHIbhogaDuZr6hN3ut8BEzr7LuTrUjfvMRQ8gT3pi?= =?Windows-1252?Q?quT/USdumKLJWwRIRNdoZUayzYnJJNLSDikwy0M4pzMTwNnKbH8zZJWJ?= =?Windows-1252?Q?5d83NLh0Bf+stgqvU0PNfguLDCX/jSwodA9loLBNGsE4woRm8ePZXhyx?= =?Windows-1252?Q?p4O40IooQCZWjW3gmKRQ7CXJyOv/to7J7nujsV9xcY/wGb8EfN11PUTr?= =?Windows-1252?Q?fxwUY7gflbPPplk9yWNg2wsmbL64znbR/aXj60s5?= Content-Type: multipart/alternative; boundary="_000_CO6PR05MB7729C799FED0319E0032A50BAB4A9CO6PR05MB7729namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO6PR05MB7729.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0e1af433-3a06-4ef2-1869-08d9cf585ebb X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2022 08:01:10.1464 (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-CrossTenant-userprincipalname: 4CXHPurm3nI3psw7NNvJp/ZinmDh/KtCgNvZgJ+FHHfjbl+lKB7N0kcK1aYHHA6RpYSXPWi1SngAm/f03nu4jQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB7927 X-Proofpoint-ORIG-GUID: lBpfQxECbE4Tuf2JZf5yzzh8uRM2fPf5 X-Proofpoint-GUID: lBpfQxECbE4Tuf2JZf5yzzh8uRM2fPf5 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-01-04_04,2022-01-01_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 adultscore=0 impostorscore=0 mlxlogscore=827 phishscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 bulkscore=0 mlxscore=0 priorityscore=1501 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2201040053 Archived-At: Subject: Re: [mpls] IPR poll for draft-kompella-mpls-larp 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, 04 Jan 2022 08:01:22 -0000 --_000_CO6PR05MB7729C799FED0319E0032A50BAB4A9CO6PR05MB7729namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I=92m a co-author of the draft. Yes, I am aware of IPR that applies to this draft. Yes, the IPR has been disclosed in compliance with IETF IPR rules. -- Balaji Rajagopalan From: Tarek Saad Date: Tuesday, 28 December 2021 at 10:32 PM To: draft-kompella-mpls-larp@ietf.org Cc: mpls@ietf.org , mpls-chairs@ietf.org Subject: IPR poll for draft-kompella-mpls-larp [External Email. Be cautious of content] Authors, Contributors, WG, This email initiates an IPR poll for draft-kompella-mpls-larp in anticipati= on of its working group adoption poll. Are you aware of any IPR that applies to the draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3669, 5378 and 8179 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the= above by responding to this email regardless of whether or not you are awa= re of any relevant IPR. This document will not advance to the next stage until a response has been = received from each author. Note, currently there is one IPR disclosure listed against this document: h= ttps://datatracker.ietf.org/ipr/2660/ If you are on the WG email list or attend WG meetings but are not listed as= an author or contributor, we remind you of your obligations under the IETF= IPR rules which encourages you to notify the IETF if you are aware of IPR = of others on an IETF contribution, or to refrain from participating in any = contribution or discussion related to your undisclosed IPR. For more inform= ation, please see the RFCs listed above and http://trac.tools.ietf.org/grou= p/iesg/trac/wiki/IntellectualProperty. **The response needs to be sent to the MPLS WG mailing list.** We expect responses from the co-authors: Kireeti Kompella Balaji Rajagopalan Reji Thomas The document has no contributors listed. Regards Tarek (MPLS WG co-chair) Juniper Business Use Only --_000_CO6PR05MB7729C799FED0319E0032A50BAB4A9CO6PR05MB7729namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi,

 

I=92m a co-author of the draft.

 

Yes, I am aware of IPR that applies to this draft.  =

Yes, the IPR has been disclosed in compliance with IETF IPR rules.&= nbsp;

 

--

Balaji Rajagopalan

 

 

From: Tarek Saad= <tsaad.net@gmail.com>
Date: Tuesday, 28 December 2021 at 10:32 PM
To: draft-kompella-mpls-larp@ietf.org <draft-kompella-mpls-larp@i= etf.org>
Cc: mpls@ietf.org <mpls@ietf.org>, mpls-chairs@ietf.org <mp= ls-chairs@ietf.org>
Subject: IPR poll for draft-kompella-mpls-larp

[External Email. Be cautious of content]

 

Authors, Contributors, WG,

 

This email initiates an IPR poll for draft-kompell= a-mpls-larp in anticipation of its working group adoption poll.=

 

Are you aware of any IPR that applies to the draft= identified above?

 

Please state either:

 

"No, I'm not aware of any IPR that applies to= this draft"

or

"Yes, I'm aware of IPR that applies to this d= raft"

 

If so, has this IPR been disclosed in compliance w= ith IETF IPR rules (see RFCs 3669, 5378 and 8179 for more details)?<= span lang=3D"EN-CA" style=3D"font-size:11.0pt">

 

If yes to the above, please state either:

 

"Yes, the IPR has been disclosed in complianc= e with IETF IPR rules"

or

"No, the IPR has not been disclosed"

 

If you answer no, please provide any additional de= tails you think appropriate. If you are listed as a document author or cont= ributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant I= PR.

 

This document will not advance to the next stage u= ntil a response has been received from each author.

Note, currently there is one IPR disclosure listed= against this document: https://da= tatracker.ietf.org/ipr/2660/

 

If you are on the WG email list or attend WG meeti= ngs but are not listed as an author or contributor, we remind you of your o= bligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please se= e the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki= /IntellectualProperty.

 

 

**The response needs to be sent to the MPLS WG mai= ling list.**

 

We expect responses from the co-authors:

Kireeti Kompella

Balaji Rajagopalan

Reji Thomas

 

The document has no contributors listed.

 

Regards

Tarek (MPLS WG co-chair)


Juniper Business Use Only

--_000_CO6PR05MB7729C799FED0319E0032A50BAB4A9CO6PR05MB7729namp_-- From nobody Wed Jan 5 08:45:37 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5173A1132; Wed, 5 Jan 2022 08:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y59qPXu5pdcx; Wed, 5 Jan 2022 08:45:30 -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 5CCA63A1130; Wed, 5 Jan 2022 08:45:23 -0800 (PST) Received: from [192.168.1.98] (unknown [122.2.110.30]) (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 5BA97365B52; Wed, 5 Jan 2022 17:45:19 +0100 (CET) Message-ID: Date: Thu, 6 Jan 2022 00:45:16 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-CA To: "mpls@ietf.org" Cc: "mpls-chairs@ietf.org" , "pals-chairs@ietf.org" , DetNet Chairs From: Loa Andersson Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] Agenda for the Open T meeting 2022-0106 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, 05 Jan 2022 16:45:35 -0000 Open DT, Please find the agenda for the first MPLS 2022 Open DT meeting at: https://trac.ietf.org/trac/mpls/wiki/2022-01-06-agenda /Loa -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Wed Jan 5 17:41:41 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4823A1330 for ; Wed, 5 Jan 2022 17:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amExGlCeu6aB for ; Wed, 5 Jan 2022 17:41:34 -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 347EC3A132E for ; Wed, 5 Jan 2022 17:41:33 -0800 (PST) Received: from [192.168.1.98] (unknown [122.2.110.30]) (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 1A000365B60; Thu, 6 Jan 2022 02:41:25 +0100 (CET) Message-ID: Date: Thu, 6 Jan 2022 09:41:22 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-CA To: Haoyu Song , "mpls@ietf.org" References: <9e553dc9-34d1-44d5-1e33-41e4a3372597@pi.nu> From: Loa Andersson In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [mpls] thought about the ADI name 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, 06 Jan 2022 01:41:40 -0000 Haoyu, This opens up for yet another interesting discussion. The "how many" ADs or ADIs is required in a single packet for the chain processing to be a problem. My guesstimate would be that the very vast majority of packet will have 0, 1 or 2 ADIs set, and the chain argument not very relevant. Why should we design for a corner case? Even if you have many ADIs set you would know from the flag field if there are AD that you are interested in. /Loa On 28/12/2021 01:39, Haoyu Song wrote: > Hi Loa, > > Please see my response inline with [HS]. > > Haoyu > > -----Original Message----- > From: Loa Andersson > Sent: Saturday, December 25, 2021 2:41 AM > To: Haoyu Song ; mpls@ietf.org > Subject: Re: [mpls] thought about the ADI name > > > > On 24/12/2021 01:58, Haoyu Song wrote: >> Hi Loa, >> >> Let me try to explain a bit more. I have examples to back the following claims which I can present in a future meeting. > > If you want to present, you should be specific and ask for a slot at a meeting. >> >> So far all the existing header design follows a chain structure. > > hmmm - do you consider a number of TLVs to be a "chain structure"? > > [HS] Yes. Basically. However, if a "T" is needed to identify a "TLV" structure, this structure has to be treated as 2 "headers" (i.e., using two parser states instead of one). Therefore, TLV is usually used as an inner structure of a header. It's not recommended for the outer header design. > > The header are parsed linearly one by one from the start of the packet, > > or upiu stop when you find what you are looking for, which may not be the last but the first, the last, or anything in between. > [HS] Could you please give an example? > > until you reach a header that is considered the last one concerned by the forwarding plane. > > You know the presence of a specific header only when you reach it. > > No. not true - if you have the flag field (FAI/NAI or ADI. or whatever you want to call them. The flags will tell you, you'll know what you are looking for. > [HS] What I mean is that we just need a single indicator to tell the presence of AD. Beyond that, it's not helpful and even harmful. I have given the reasons. Perhaps you should try to write the pseudo code to verify that. > > In this design, the number of parser states as well as the time for parsing is both linear to the number of headers scanned. > > Can't argue about this, doesn't the fact that you are looking for something specific help? >> >> Now people may think using some extra indicators (i.e., a bitmap with each bit indicating the presence of a header later in the packet) may improve the parsing performance. To this we must ask "in what sense"? >> >> We can consider two possible types of improvements. First is the reduction of parsing states which can help to save the parser resource (i.e., fewer nodes in the parser FSM); second is the reduction of parsing cycles which can help to parse a packet faster (we have a fixed cost for parsing each header, no matter the size of it. E.g, each MPLS label is considered a header, the entire IPv6 header, excluding EHs, is also considered a header). >> >> For the first one, if you start to actually draft the parsing graph, you will find the opposite results. In two different parsing styles, both requires more parser states than a simple header chain. >> >> For the second one, we need to understand that the headers concerned by a forwarding plane need to all be parsed anyway. You can't ignore some headers in the middle because you will need to reconstruct the packet headers at the egress (a process also known as deparsing). So the extra indicator encoding doesn't help to improve the parsing speed either. > > So, I conclude. If we have the flag field and know that there is only one or two action flags set, I will be worse off than if I have a PSD structure that I have no knowledge about? > > [HS] You may just know there is PSD. That's enough. Other information doesn't help on either parser size or parsing speed. On the contrary, the bitmap or catalog forces the AD order and limits the AD extensibility. > > > Now I'm too far off road, and stop here. > >> >> There's a reason why so far all the headers are simply organized as a chain. It's the most efficient and straightforward way. My study is based on current switch ASICs and some NPs. If people don't believe me, then evidence (e.g., pseudo code or parsing graph) needs to be provided. Perhaps there are some different forwarding plane designs which can play magic. We need to learn that before introducing any new mechanism. > > >> >> A caveat is that, an extra indicator for the presence of HBH headers might be useful in some cases. For example, on an LSP path nodes, if there's no HBH headers later in the packet, the parser can stop further parsing immediately which can save some parsing cycles. Even in this case, if the forwarding plane still requires to continue parsing, this mechanism doesn’t help. >> > I a FAI/NAI/ADI that indicates HBH wrse than one that indicate E2E? > > [HS] Since LSP end nodes need to parse all the AD anyway, so an overall indicator for AD is sufficient for that purpose. Beyond that, an HBH indicator can allow the LSP path nodes to avoid continuing parsing when the indicator was found which can shorten the parsing process. > > /Loa > >> In general, we really just need to concern the packet header buffer (aka packet window) size. As long as all the headers concerned by a forwarding plane is within the buffer limit, the parsing cost is a negligible concern for a simple header chain. Other mechanisms are of no help at best and could be harmful at worst. Of course, I'd like to see evidence if people think the other way. >> >> Happy Holidays! >> >> Best regards, >> Haoyu >> >> -----Original Message----- >> From: Loa Andersson >> Sent: Wednesday, December 22, 2021 2:54 PM >> To: Haoyu Song ; mpls@ietf.org >> Subject: Re: [mpls] thought about the ADI name >> >> Haoyu, >> >> OK, I simply don't understand. >> >> If you don't know what action you'll take, what good is it to know where to find the data? >> >> It might be that this is not what you say, but that is what if get from your text below. Sorry if I'm misunderstanding. >> >> /Loa >> >> On 23/12/2021 03:25, Haoyu Song wrote: >>> Hi Loa, >>> >>> In my opinion the ADI should only be used to indicate the presence of AD. E2E or HBH AD could be differentiated because in some case it can help stop further parsing beyond ADI. Other information encoded in it won't help but complicate the parsing process. I strongly suggest any such proposal should give a clear presentation on why it's necessary and how it can help from the view of implementors, otherwise, we may end up with an over complicated design without tangible benefits. >>> >>> Best regards, >>> Haoyu >>> >>> -----Original Message----- >>> From: mpls On Behalf Of Loa Andersson >>> Sent: Sunday, December 19, 2021 8:32 AM >>> To: mpls@ietf.org >>> Subject: [mpls] thought about the ADI name >>> >>> Working Group, >>> >>> The MIAD Requirement Specification use the abbreviation ADI, it stands for Ancillary Data Indicator. Which is all nice and dandy. >>> >>> But isn't it he case that the indicator gives us two things, the action to be performed and where to find the data needed, i.e., an Ancillary Data and Action indication (ADAI?). >>> >>> No I'm not suggesting that we change, but we should be aware, and it would be nice to have it mentioned somewhere. >>> >>> /Loa >> > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Thu Jan 6 06:16:24 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19BB3A0D0C for ; Thu, 6 Jan 2022 06:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOEx1NP9DOTs for ; Thu, 6 Jan 2022 06:16:20 -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 A86663A0D05 for ; Thu, 6 Jan 2022 06:16:20 -0800 (PST) Received: from [192.168.1.98] (unknown [122.2.110.30]) (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 84FF5365B7F; Thu, 6 Jan 2022 15:16:15 +0100 (CET) Message-ID: Date: Thu, 6 Jan 2022 22:16:10 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 From: Loa Andersson Content-Language: en-CA To: John E Drake , "mpls@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] flag fields in John's prposal 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, 06 Jan 2022 14:16:23 -0000 John, In your current text on the wiki you have one paragraph saying: "The NFFs are encoded in a set of one or more LSEs, where each LSE consists of a 1 bit continuation field followed by 19 bits of NFFs, the BoS field, and 11 bits of NFFs" This would give us 30 flags per LSE, however I can't see that it works, unless you have a method to indicate that the entry after the SPL are flag fields, not an LSEs. If you try to do this by using an SPL value for actions depending on ISD and another for actions that depends on PSD, then we have have a very tough fight to fight for allocating 25% of the free labels for this purpose. It seems unlikely that you will get 2 SPLs allocated for this purpose, especially since it is proven that one is sufficient. /Loa -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Thu Jan 6 06:39:17 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9583A099E for ; Thu, 6 Jan 2022 06:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.673 X-Spam-Level: X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=pLA6ixDt; dkim=pass (1024-bit key) header.d=juniper.net header.b=Mx4LxfXS 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 D7iratABcXTZ for ; Thu, 6 Jan 2022 06:39:11 -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 77EE43A0997 for ; Thu, 6 Jan 2022 06:39:11 -0800 (PST) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 205N8VjU021393; Thu, 6 Jan 2022 06:39:11 -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=2IE4cbUzy8Zw0YtpBCzlieXWgCiITLzAZS4vx8L60c0=; b=pLA6ixDtoFxFN+CYkObNOirXBoC7mjmQgQVmKiwlgf5pV9a5uxTAOpmfVWqoIkUAk86H JVSZSbCgJ8vBE5yG62Fd6KV0Ipk2Ih/vtbPQYlRdlw8z/FcAQfhW7mpNZjdB6LIrQEMk 986gs6wh4BHeJQoeOlxy4zfE2QPAQ1hL6mobRrPZ+XZl5sAlBsWVEIcGyJo3RdDRBM3V apORT+mv8GEO+HIhkDV0eX12gYkjPREwoJ4kckz7ekr7JM+3wZ+TmFayVrdPdTC9BZMs laf0mZ8idpffBJO6gbsBSVjeN0cBFHJVpuKMlDe4/1QE5DFfJoyG9ERw9xiJrTm78scv 9g== Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2107.outbound.protection.outlook.com [104.47.70.107]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3ddmr411s0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Jan 2022 06:39:10 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XSRVm8RaLQ2wQx3bkhDtUOsavI0YeD4KeqoE7AHrnwwP6RplVGBYoQcveUlNXXYv8SLviiwZDG7/umZ+KbBBNt9E3kcZkCxwVR2McbnZbdvX7W1tiqdRWsoii/3yKK8i0BrEb+S0vXPP+n+b9vVATAo1PbR1Cq7W9/RyBrsEXpi9qKH+034GgokHby0uuD08+YVYkUNsTsyvaJdtCWDFPdSQ6Ru88zZ8YocdfbfEfzkfF5rHF8ng7MzHXVlCsXjc//HJ6vagANgqsEBll751xFCrg6PwSLpcKSA8RTzkzaszkM4d+FDRJd7AbJccyYgB5YFrKhEUNRWu3aZLtMjVkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2IE4cbUzy8Zw0YtpBCzlieXWgCiITLzAZS4vx8L60c0=; b=KRfBWr6lrgC2VOdhp9KwI3nfhfV8fTTxicLzjl0uUUv4Yp4dnLst9s2la7XnMUJ0UP9QXRnNbILv3s//YYJn0XM8AqIXOIRHfUpDHk4Escq7COUy0ppTd4CbuCuifnV5PQgkjPas7Pw6ORP8sYnaY7W7ZR0gCThrDYk+3IpFbtrr7CPDtnP0XIpAwWlychRPdPdR0FbBS5Ps6Z//19kBovHQn8TIERpPg5P27zNyhyadUnCX55x72tZs55eByHJ9VrsQvbWMW2tjMvQDhk4uaCcQMaaehQZr8Tvd+qVnaO8w98yTi8bIGERPpEiT1A4R3PIQ1uHaw+PuVmfD/39CGQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2IE4cbUzy8Zw0YtpBCzlieXWgCiITLzAZS4vx8L60c0=; b=Mx4LxfXSEZ1vhFJi5RzvCWha6rA27BO8D5Wvyz6PMChA+EL6VCr5yrpL9KCpSWpJRiMF+t4rxK4jX7j2di/ObSoDe0diC81d1aqhclZIWlkeK7kFuoGW44lkAPRudYGgAGS27kRLig9s/OFxTEk79Z0rat73f3OBwcNEIbMmU9E= Received: from BY3PR05MB8081.namprd05.prod.outlook.com (2603:10b6:a03:366::15) by SN6PR05MB5614.namprd05.prod.outlook.com (2603:10b6:805:c3::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4867.6; Thu, 6 Jan 2022 14:39:07 +0000 Received: from BY3PR05MB8081.namprd05.prod.outlook.com ([fe80::304c:2b94:4f26:a581]) by BY3PR05MB8081.namprd05.prod.outlook.com ([fe80::304c:2b94:4f26:a581%3]) with mapi id 15.20.4888.005; Thu, 6 Jan 2022 14:39:07 +0000 From: John E Drake To: Loa Andersson , "mpls@ietf.org" Thread-Topic: flag fields in John's prposal Thread-Index: AQHYAwf7iv+OOnFhBEq/MapVtP9lJKxWCzgw Date: Thu, 6 Jan 2022 14:39:07 +0000 Message-ID: References: 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.6.400.34 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2022-01-06T14:21:06Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=e6f28f98-e475-4e21-8376-9764cbe1b35c; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_enabled: true msip_label_0633b888-ae0d-4341-a75f-06e04137d755_setdate: 2022-01-06T14:39:05Z msip_label_0633b888-ae0d-4341-a75f-06e04137d755_method: Standard msip_label_0633b888-ae0d-4341-a75f-06e04137d755_name: 0633b888-ae0d-4341-a75f-06e04137d755 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_siteid: bea78b3c-4cdb-4130-854a-1d193232e5f4 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_actionid: 7317e549-41a6-4e0f-932d-11410e8bf7c0 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_contentbits: 0 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9a5e60d1-9f4c-48f9-85b2-08d9d1224b84 x-ms-traffictypediagnostic: SN6PR05MB5614:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vaHtl3OpeCaH7aeNI5zSkHTzgniidgGevFm5YX1h/3lelEDd29EaUoQoRWNBnN2Z4a7KZc8WRSXCywJTDe2+27Y+PYDCn8ML9rbs646taGmDVYahFi9IhpnLJJPHQkxn+EPrrPyJ2j93C1iHOkM6jOP/DJPovBwKniyMjqu0kP5pvAqTS8VoZUdk8RIP0MGcMFfJGOOyKQwrE/14+PokhKhXItDMJnk4kM7g2WN5vlCAaaLoc/zqUCE+HYtEz/mwAqfy6SDRcaWtTCpIFC5n80BVIfXIujyb6Fzi8NcVFkA7vJ9x0vTYvK5Hh0y47Y9ho29yFoSwTeCG6TLEEA3ErJD2PR3ip1fwkR2AgbYrDmxSRGLFlE3rUkOWX9U1yPYVsrms4AXid+SEGW43L4YdNcgzf6InGzTelhsZLVuQCB1OuEXgQKJocQaCMIkZVbX7AZOkZWDq2vIxfyWHB13ZbhpTUudlG5cAdXleR7p7hT/rXbYpKxe5JueeeHEsiypm26dr5JEC3HBwrR6ohXANqkVwqi3PmkKO6Mkn6V+9vmDLxzH/mnI9CHmn476m1HLkUhSAZiLm+rD+YczmfnjmduBolfkCtnbyiVPlBdTKrSP60CojDRDn85fE2fB1iG/HM73G1XNhsM0CTBcwWcPO9CiCjKsMOTjeAFoTOGW1GQxLB4mS+9Jioq6kRRJiMIBNR9Z15KCX+UhVP9NoF0cNqg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR05MB8081.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(508600001)(53546011)(71200400001)(186003)(26005)(7696005)(5660300002)(86362001)(6506007)(9686003)(66446008)(8676002)(66574015)(66476007)(83380400001)(8936002)(110136005)(64756008)(122000001)(38100700002)(38070700005)(52536014)(66946007)(55016003)(66556008)(316002)(76116006)(2906002)(33656002)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dkRaaWlxNjB2TEdMNzNwTkZZbVJDZTZjWUlUQmhhZ3RDc0JFeWVva0ZaNTVy?= =?utf-8?B?dGNpbHNvZXAxV2dYN3NTSnYzNTJZZEZ3MTV0WkE0b3MvZUVzQXpCeis4dkJH?= =?utf-8?B?cWZHUzFucHRucHFQMkN2Z1Exa3B0WUliYXk1QTVCaWtIMjFaL2xvcDlhV1Q4?= =?utf-8?B?MW5nM01QZmdDN3Q2N0JQeFcyOTVyaWdSSjNSSHE3K3FncTN1bWtnTHlZdFdX?= =?utf-8?B?WWllTXNlVHp0a3NOeDdEamwweEtKR2s2SXdBRjJHdlFUYnQ1OUVkRVlMUmtr?= =?utf-8?B?dG82dWd2SVhiMVRCcDJNNXRoWlVLN1dPL0pFcmdsaXNqQ1QrUHkxRTlNUjEv?= =?utf-8?B?U1ZFditGRllNcSsrS2piOWwzb29YbHZOUWp1MGhxSDF2UksremFHLzljRytD?= =?utf-8?B?cUNtZHJpVmNPLzMzMGhwaUVScUhnWDJqS3dlLzVWQW5UTEw2bktxdk1LbzlI?= =?utf-8?B?Z0RUN2h4UGszSW94NnB4QWxnWGRPNk4vbkJjZ3JEUGl1aFNQYUhkRUg3TUcv?= =?utf-8?B?RGkraXgvQkJDSTFiWWxxY0VTUjlDN1lkTTg2Y2pPaFp6VDlSWlJXWHc1Yzk4?= =?utf-8?B?Zjd4STg3dlBVYnUvTmZhYTc5VEh5aXVCVEE3c1JxVkJvSC9qWnAzak5CK0to?= =?utf-8?B?TjIxdlVLMVZmdS9jQmF4dUUxOUorN1VHOUJTNytPUXFtT0FDSi9RdW1iKytZ?= =?utf-8?B?QmNhcnVqUHY2S3BERHRwMUVkeFdoQ2U1TXQ4bWRNQzJiRDVWb21TNnlMRWNh?= =?utf-8?B?MllMVG9XMlJzZ2diK1dCdkpXbm80Yk9nQTdXV1kvRE42TnVNQzZuMXFUV3hF?= =?utf-8?B?bWdBNGFDVEJkeFFKd29DbnVYN04vTFp3TWhMdGRHN3ZING5icytSWGt6aXFN?= =?utf-8?B?OG1tVUY1TFpDa2FYRmFrV3Zha2RZQ090WVBMSEtFTTcveTJud2VtQXJmUkEw?= =?utf-8?B?aTIwZkEzUDBIMThHb0ozem9yUXFPVVA4QUk5V2NUZFE5aDVkc1h3Z2JuY2t5?= =?utf-8?B?bWFCeXI4NERMKzgyaHQyMXNJZ1dOMGtLL3pJK1E5R0ZiT3I4bnBwTUJLK0pX?= =?utf-8?B?MzhRTjlPTCsyUENGS3VHRnpsSFNVWFdlV3BvODNWZUdZWWhSR0J1dTYvdmMr?= =?utf-8?B?TWJaWUxNWEVscktWZmJXbFg2WDhuVG1NM2hEQUxCTHVCMzBtV0N1Z0Fsalkv?= =?utf-8?B?NHJtY2VRQlZvazhPVFVDMDVpU291WGtGNFJZQ09CQ2ROVGlNMDMrWXdVV1NS?= =?utf-8?B?c0lZdTlxTUphMVZwczVhSEtva0NkaStuNU5obW13cjB0UHRKZ0ppcjJ5WDJO?= =?utf-8?B?VmdhYXN3UlVZTWJ6YVc4VzV0eXJZMi9OVjAyZ1hmK3hYelQ2SUJsU054R3VR?= =?utf-8?B?eVhxdDRMLy9ON2E3QjB1UnlsaitnTloxSHplMU52TVBjRENxbklFZ3VnQjVs?= =?utf-8?B?eXhGRXEwcm1OOURoMTcwL082Qm1hWVIzZDl6NTN4YWZZS2lkOWJYdjE5aEFn?= =?utf-8?B?QjdwVXVOanMyUVdUUUZ0ZzBnaTBVOGFobklVV1o2ZDJMSlVsSmJ1ei9EbHNM?= =?utf-8?B?TGg5SzFlZExLRVFZOUJPbWdjOTh3cXc3bzV2ZnhibmFDdVBMU0NSRU5LdW9E?= =?utf-8?B?YzlNaDV4OENWcHZZSTRQVk5zOFMwSEJQZkVIc3BDRG9SMHZEMjlPVFpzNFlG?= =?utf-8?B?ZzZ3L3JTMnA0ZzNZLy9WbVZUSVpieFRZanRvTmhoM0RDeG9QejY1THUybjEr?= =?utf-8?B?YVlwWDFRZVNScExqcjZ6L0hjZ1VOZXZLczI2aFlpSnJocEFIL1BRTFVyZS9h?= =?utf-8?B?VzlpSytBdWQvekFQWG5iaTAzaGVLOHBSU0xPRktiWWNUOHVaOFowV0pBSjk5?= =?utf-8?B?cXRLUUFqTloxZjhmblBELzdpblJKaE41azVmZktHY29NUFlFY3pFdHRxbzFQ?= =?utf-8?B?RWVTaGpHMEozMW9LbmdiakU2aTlIeHI1MmRaL3VUUXdkMVFHRnlBclgwTEJD?= =?utf-8?B?UGpsRjFadVpHUUVYWGJFTmlSRnIzb2hKWE9wKy9pbnkydTVRcCtHaFNkYzhC?= =?utf-8?B?T2tGU2lCSlZtRkxUNTRpREdEWSsrZkRQSDFiZVJXeSsvNzh1ZFJ4elJ5L09n?= =?utf-8?B?VVVyRUt4ZnZ1YlYxU3BoSWpVVE5HK29RQjZ5WnlOa05vcTgwV0RhRVNZT3Ay?= =?utf-8?Q?Ard4qO1oZq8ne/S1QHSzfY8=3D?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR05MB8081.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9a5e60d1-9f4c-48f9-85b2-08d9d1224b84 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2022 14:39:07.4299 (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-CrossTenant-userprincipalname: 3tmex8X+Rzj9okcqZNbh6G03Wq3TXwUp9l0Emt+SdgHxDK8VAzi2teqWzw+vrIorfJjUFmQAQcOfIGLpLKxgHw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR05MB5614 X-Proofpoint-GUID: tMinN1zQ4TBj4q6Mso0QjIPmoR9Q_-yQ X-Proofpoint-ORIG-GUID: tMinN1zQ4TBj4q6Mso0QjIPmoR9Q_-yQ X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-01-06_05,2022-01-06_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 phishscore=0 spamscore=0 adultscore=0 impostorscore=0 malwarescore=0 mlxlogscore=999 clxscore=1015 lowpriorityscore=0 bulkscore=0 mlxscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2112160000 definitions=main-2201060102 Archived-At: Subject: Re: [mpls] flag fields in John's prposal 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, 06 Jan 2022 14:39:16 -0000 TG9hLA0KDQpDb21tZW50cyBpbmxpbmUgYmVsb3cuCQ0KDQpZb3VycyBJcnJlc3BlY3RpdmVseSwN Cg0KSm9obg0KDQoNCkp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU+DQo+IFNlbnQ6 IFRodXJzZGF5LCBKYW51YXJ5IDYsIDIwMjIgOToxNiBBTQ0KPiBUbzogSm9obiBFIERyYWtlIDxq ZHJha2VAanVuaXBlci5uZXQ+OyBtcGxzQGlldGYub3JnDQo+IFN1YmplY3Q6IGZsYWcgZmllbGRz IGluIEpvaG4ncyBwcnBvc2FsDQo+IA0KPiBbRXh0ZXJuYWwgRW1haWwuIEJlIGNhdXRpb3VzIG9m IGNvbnRlbnRdDQo+IA0KPiANCj4gSm9obiwNCj4gDQo+IEluIHlvdXIgY3VycmVudCB0ZXh0IG9u IHRoZSB3aWtpIHlvdSBoYXZlIG9uZSBwYXJhZ3JhcGggc2F5aW5nOg0KPiAgICAiVGhlIE5GRnMg YXJlIGVuY29kZWQgaW4gYSBzZXQgb2Ygb25lIG9yIG1vcmUgTFNFcywgd2hlcmUgZWFjaCBMU0UN Cj4gICAgIGNvbnNpc3RzIG9mIGEgMSBiaXQgY29udGludWF0aW9uIGZpZWxkIGZvbGxvd2VkIGJ5 IDE5IGJpdHMgb2YgTkZGcywNCj4gICAgIHRoZSBCb1MgZmllbGQsIGFuZCAxMSBiaXRzIG9mIE5G RnMiDQo+IA0KPiBUaGlzIHdvdWxkIGdpdmUgdXMgMzAgZmxhZ3MgcGVyIExTRSwgaG93ZXZlciBJ IGNhbid0IHNlZSB0aGF0IGl0IHdvcmtzLCB1bmxlc3MgeW91DQo+IGhhdmUgYSBtZXRob2QgdG8g aW5kaWNhdGUgdGhhdCB0aGUgZW50cnkgYWZ0ZXIgdGhlIFNQTCBhcmUgZmxhZyBmaWVsZHMsIG5v dCBhbg0KPiBMU0VzLg0KDQpbSkRdICBUaGUgU1BMIGlkZW50aWZpZXMgd2hhdCBmb2xsb3dzIGFz IGEgbmV0d29yayBhY3Rpb24gbGFiZWwgc3RhY2sgYmxvY2suICBXaGF0IGZvbGxvd3MNCnRoZSBT UEwgaXMgYSBzZXQgb2Ygb25lIG9yIG1vcmUgTFNFcyBjb250YWluaW5nIGZsYWdzLiAgVGhlIGNv bnRpbnVhdGlvbiBmaWVsZCBpcyB1c2VkIHRvICBkZWxpbWl0DQp0aGUgc2V0IG9mIExTRXMgY29u dGFpbmluZyBmbGFncy4gIFdoYXQgZm9sbG93cyB0aGUgc2V0IG9mIExTRXMgY29udGFpbmluZyBm bGFncyBpcyBhIHNldCBvZg0KTFNFcyBjb250YWluaW5nIGluLXN0YWNrIGFuY2lsbGFyeSBkYXRh LiAgDQoNCj4gDQo+IElmIHlvdSB0cnkgdG8gZG8gdGhpcyBieSB1c2luZyBhbiBTUEwgdmFsdWUg Zm9yIGFjdGlvbnMgZGVwZW5kaW5nIG9uIElTRCBhbmQNCj4gYW5vdGhlciBmb3IgYWN0aW9ucyB0 aGF0IGRlcGVuZHMgb24gUFNELCB0aGVuIHdlIGhhdmUgaGF2ZSBhIHZlcnkgdG91Z2ggZmlnaHQN Cj4gdG8gZmlnaHQgZm9yIGFsbG9jYXRpbmcgMjUlIG9mIHRoZSBmcmVlIGxhYmVscyBmb3IgdGhp cyBwdXJwb3NlLg0KDQpbSkRdICBBcyBJIGhhdmUgc2FpZCBiZWZvcmUgdGhlIGRlZmluaXRpb24g b2YgYSBuZXR3b3JrIGFjdGlvbiBpbmNsdWRlcyB3aGV0aGVyIHRoYXQgYWN0aW9uDQpoYXMgYW5j aWxsYXJ5IGRhdGEsIHdoYXQgaXMgdGhhdCBhbmNpbGxhcnkgZGF0YSwgYW5kIGlmIHRoYXQgYW5j aWxsYXJ5IGRhdGEgaXMgaW4tc3RhY2sgb3IgcG9zdC1zdGFjay4NClNvLCB3aGVuIGEgUCByb3V0 ZXIgc2VlcyBhIHBhY2tldCB3aXRoIGEgbmV0d29yayBhY3Rpb25zIGxhYmVsIHN0YWNrIGJsb2Nr LCBiYXNlZCB1cG9uDQp3aGljaCBuZXR3b3JrIGFjdGlvbiBmbGFncyBhcmUgc2V0LCBpdCBrbm93 cyBleGFjdGx5IHRoZSBzdHJ1Y3R1cmUgb2YgdGhlIGluLXN0YWNrIGFuY2lsbGFyeQ0KZGF0YS4g DQoNCj4gDQo+IEl0IHNlZW1zIHVubGlrZWx5IHRoYXQgeW91IHdpbGwgZ2V0IDIgU1BMcyBhbGxv Y2F0ZWQgZm9yIHRoaXMgcHVycG9zZSwgZXNwZWNpYWxseQ0KPiBzaW5jZSBpdCBpcyBwcm92ZW4g dGhhdCBvbmUgaXMgc3VmZmljaWVudC4NCj4gDQo+IC9Mb2ENCj4gLS0NCj4gTG9hIEFuZGVyc3Nv biAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAcGkubnUNCj4gU2VuaW9yIE1QTFMg RXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2EucGkubnVAZ21haWwuY29tDQo+IEJy b256ZSBEcmFnb24gQ29uc3VsdGluZyAgICAgICAgICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2 NA0K From nobody Thu Jan 6 09:28:48 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168943A10F8 for ; Thu, 6 Jan 2022 09:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSN0LD07s6Af for ; Thu, 6 Jan 2022 09:28:40 -0800 (PST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2103.outbound.protection.outlook.com [40.107.92.103]) (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 B88193A118D for ; Thu, 6 Jan 2022 09:28:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ru3cTE8s/tYT0K3gk11y3XW2wJooTlpNFFbXuV2TaUU0cPLK9m7kCXrMdQHHWwvKDP07YYXUFTeQoyL3NdhmdcrvsUbOg633Eedl6wm01ejm2qagGzyvtn3NjW7TCv8CSrD3TflOPrhovC7eg30qq2c1vDQKN2aUSqdIOX00tHRWbSr62LCPWXWU4nCW9K70UDF/30YnYFe/sqSH1r3jN8s9szZPeTYR9BY2YvyuzBbxt8jheYlbP6N9IBoXpi7FPYt6Qyv8JwBhC14f4oNBDH5QPvNvilGRP6ntjiQCMutwZ22BQWXh19jLkVicvw/UPe+8jvZmPFxvpVYWVjVt+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZrI+Ge8IYMzb6ROgxRi3wfRbCyc+w+HzA5vC/7txTyY=; b=k1LbnPOwCwAnXw1OBG/ADgWt9UPBoEpR4ZUyYLzceRzd6gftF1IxSM+y42b0TrCA4KLw4KUebAZJ+oPih5vvmNhxMPX+slVcRUpzLHQf5245wC0FX+9BUoVbcA6pPT/FsiYhmPP72+ZIkQ4VvAj+nnnzqhmGqOzVwR9MPFB2MptrUtU3uBpJAWS/X1+EoJWF68I0sRTBDq0LT91HpaxD+eBR0CIIyKxqfLFibVJJYO5YV05DjcZSaEYPRBqX5+MUdffcSgEj58IyOGksRHc4/B48K+qEjw7vp8oaQ6nie8ye/OAsGIdEzyd+i5twAJtMkK7Np7Hk0mZ9X2e6jlnr6g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZrI+Ge8IYMzb6ROgxRi3wfRbCyc+w+HzA5vC/7txTyY=; b=eZULy2Ftp9bd8f4I2+NLXs1mFeS51VV/Bo03S1jCb7oiiMcGc62ANeUAWtRTHs5p8IrZBZZOXThUyGiydocBA7+Ol8ucY9BAAEjen8oYlmB9QsrWZhj7J/TezaihsoZBtjpXKY2J717Ju+2WejG+zfBd+zhgKgwLxby3F4Sjpn4= Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by CO1PR13MB4773.namprd13.prod.outlook.com (2603:10b6:303:fb::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4867.7; Thu, 6 Jan 2022 17:28:35 +0000 Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::618d:61cf:753e:be55]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::618d:61cf:753e:be55%8]) with mapi id 15.20.4888.004; Thu, 6 Jan 2022 17:28:35 +0000 From: Haoyu Song To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] thought about the ADI name Thread-Index: AQHX9PX47Ak4DxNRp0aIR5NFvLhDUKw+5m6QgAA9QQCAATTxkIACtTEAgAOSMJCADrMXAIABBamQ Date: Thu, 6 Jan 2022 17:28:35 +0000 Message-ID: References: <9e553dc9-34d1-44d5-1e33-41e4a3372597@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 98d593a4-5fb3-4a8c-6973-08d9d139f7e1 x-ms-traffictypediagnostic: CO1PR13MB4773:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FMdH5Kx07ieJemiUrSUttrvK397V5zrC7HX8CUQc6LouGtse19H7aQrXWJU1Z7beHD1u2rIlJp638b+4TE18XTb3tiyLofG0xW2RMpXdt6nlq96UmbBTQqnLrUklRcAUjCeDXk90+lvxdkLkv5iTqaj9IXOg3VDwmf8tWqvwJqked0NTKaYL44u/L6VEwhsb8e7MyHca8/qmSLE1jjrmYfrcPnXOfDeJEpX6vuPupA1iQv9WwwcRFR2tvynBn8KBsWQh2h42sRJEzgATfc4ssCYZB3obNCFAYOTjhTnDjMAAiA0UBVvz2kkj1JbokRQ0Q9l2O/CvRXZ7Opmkdci/jxiSsdVVdHJiVNIj+W92NkxSORh4iqHb2Mp63hmS0doBCszNQSHr84/2aZa27U7cs7DCa3pyqF1kWzNMMJEUUuNjxZO1/hS/8Qwgl9Rc7Bls7/NMsn2WGBHimmIF9qV5C76lX6XRTepYPasi0Fcr8SOI2rsEnK392EHve0Ka6VWfBveDRaflQi8unHuINuTjRkVcCtcqM3V9DFgoFwh3CkcAvjylGi1Gs1eop7HjFetVhBZCItmTsK+RiX+KJJQq0iLsZ/EmhryjfIxSJce4yuqQqZie2QLMV7ypovyzrnBrNozC0Gzq9mpJcAx+c/BAyR/BHYWnlo82ZfT6Is7MNpPm8zDFNJMq350vP4ChKgdQ8fk9hwUrrUgYIxWa75WRmA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(38070700005)(7696005)(53546011)(5660300002)(508600001)(71200400001)(6506007)(122000001)(9686003)(83380400001)(86362001)(44832011)(64756008)(66446008)(38100700002)(186003)(2906002)(76116006)(110136005)(66476007)(66946007)(33656002)(316002)(66556008)(8676002)(52536014)(55016003)(8936002)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bExCMjNrWGRwVm02bEI5ejRmWmthL1JqY2dDaXhGTDRHUk1KaHRMRVlWUnFL?= =?utf-8?B?ZU95cU1OVGlzcGx6WmpCNEFCZTh6c3JxUXozWU1DR1VlVU1lbWw0VGE2MUV1?= =?utf-8?B?ZGltWG9RZS9wV3huNnZtdzQwTWtnOHNuSy93ODRkMlpHRkN5YkNnZjl5cUhq?= =?utf-8?B?UFJuTG5JQWVxTk5BVXVxdFRjR0FTNEJxWk1jSmE3ay9GTVFVUTIrWkpKemlL?= =?utf-8?B?QXkvUlJXSC9wWGJhdTBWdW5zcW5WekVXczFIb05LS3lCbGpETk9UZGozVkND?= =?utf-8?B?RDA0emUwMzVsMWtjemVRVEFRUDRLR05IYlJ3TlhvSjFkVFdnTWhlc0hBWmE1?= =?utf-8?B?TTArejB4eTdROUdGY1FzeUNRWEVPRGlSSnFOL1BEd1QvT3lUaUdmeGVFKzNr?= =?utf-8?B?UGxpMTlRcFhEbTcrbnpwU3dicVMxcVg4SXptNGZOQnMyWHlMZnlsS2o1VUYy?= =?utf-8?B?ZlB5d2dYQUpPMURaaXBQRmpnNWZMeUJZVzN2VEZxTENJKzc5ZFpHYTVsRkpq?= =?utf-8?B?RzNTam80ZUJTd0pKR09FbTE3VklGRm05U2FNYlpFeXRqN3lUclBUSmlLb0Na?= =?utf-8?B?WHRrdUlNZGlFY010dWwvenE5OCtzOFMySk55eE0wRFFiandXQUJreG5GZXhX?= =?utf-8?B?RHlVaWh2Y1ZPMWlBbThsc2FhdE9pckZoMkxJdGRZMERLQ1Vsa2Z5SHd1OWR0?= =?utf-8?B?K20zc0lzeTd4cEJUVWFRK3AyZVVFcVNEbHdPc1VTWHFTOUZuci9taUtUcmx1?= =?utf-8?B?bll5dnBkOUViY0VXUWEvOXBRWlYrUGV1cHFINXN2OGRxV0ZjdDZDVnY2MG1S?= =?utf-8?B?cFllTzVLbmprVitPWWFuRW9qSkFNR2lmVDFlS29kanJSdlNibWhlMitRcTZF?= =?utf-8?B?OGZjT2xyVEZlc0E0ZWNTbExmejB2eVNHZVFyenVhdXByYUlINDdaeGVjbVhE?= =?utf-8?B?TERlZGdwY2Z5WTR0cVExV0l0alVLam9FVHBDcVoyUjBpb2R0c2lFeTJ6MmJ4?= =?utf-8?B?bG1uQWpLNnF3dkZwdHE2dERocTdLZDgzOXRsdkpja052ZUNYYWM0UytBNEtz?= =?utf-8?B?V3d6d2x5UWFwK2RKaGtoMjRkNkpDR0tIWW9HTjhhRUtucGtkaFJ5QW5hZ0wx?= =?utf-8?B?T29rdlF0WnJaMkVmQmxtL29UQ1BsV05Nbkgrc1hQdjlnZ3pGVlFZbnMxamxX?= =?utf-8?B?VXcwZ2VVTi94SFJzZDdnOFJRYXBPOVNRN0VjejVVQkdQNWR2OEJqZzdCSFU2?= =?utf-8?B?eUNhU2tPV0YyZk1JYkg0TTFPZWtmdnhaUGdXUk9LRHg4UlNMcWRzdzVrZFFs?= =?utf-8?B?RmpSeHVzTHRGd1liUkgxM093SmVwcENwZFJnemd6bW9XL2g0SmRxdTM2dWVZ?= =?utf-8?B?TEt4alNvTmdESWh3d2xralZTZDduU2RNRGo1b2xJY2Z0czJXWWhmSDZhajYv?= =?utf-8?B?UWVjM2xwcE5Md0xiR2hETmFHaWlwTmJ6S2g1Wkx0R0RDWVBZdjliSmtYeHM0?= =?utf-8?B?U0RGeXlKS3QrSXRqR1dQRCs5TUl6TldIb0t1bkJ3OFpqSUlBa0ljTjByNVJj?= =?utf-8?B?dzdVT3RkOGF0OWZ4cU1RMUJZdGs0WHh3NndmNnY0OXVhNFlTTTlXVHpGY1gv?= =?utf-8?B?N29keGVWaGdYajMyYnA2T2JKUGk3bjJiRWtUN2lBbW55V0tPNU1keTZBUXBP?= =?utf-8?B?UGxVNk5QQ2pHZWZvYm1aNW42dnUyVEo4Y3dqVm1DUUxaUVkvL3VEVklZdU90?= =?utf-8?B?S0tJM0dIZG8zalV5dnh4WCtoYlRCV3FtSXJmWkRERXRiREdBZ2hScitIK1Rx?= =?utf-8?B?RHZhV1NQS0dGelowNFdNdzNYYVdza3B1aEpFN0ROU1ZoYjRDYWNlNnY1aWMr?= =?utf-8?B?OU1DQURtZmlKWDBCTU1lR3lOR3ZOaFo4c0V1bW9BdEN5bjBidkE1QjRmdzF3?= =?utf-8?B?YmhsZFpxdkNKQUNHbnlIL3pxM25xMldBTERKeWZ1d2pNY3VsbFZGaThRMVF1?= =?utf-8?B?dUVBTFVBNWhUYU1RYlZhbjB3dUVDMForOFdwTjlUSExiV1MzZDh1MnJTZFg4?= =?utf-8?B?UkF0YUtFVnNCYWpQUWNsUG1zNVJiOGVvb21FY1czb0Q0b1FUcEsyOUVIREFF?= =?utf-8?B?VzQzeXZPdi9wd1hSMmo4a1FWMFFQNHJSTHlPZ0wvekh4eU5DM2RodW5uQm5t?= =?utf-8?B?M000QUlTUEo4Nnl1N0hoU3p3d2puVGZLc3BqdUxCclZKZk5pNzNEYmRRNm1P?= =?utf-8?B?TXd2cjI0NVlZMU9SdHBQaitabDNBPT0=?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 98d593a4-5fb3-4a8c-6973-08d9d139f7e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2022 17:28:35.0472 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4iw4rDaLYv988jNULi44wWt2SyjmpNcKMamMIh/d3jxE5fItETghsFJ16cTgxQUxpcPbPGPvrCU9XY7ORH3erw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR13MB4773 Archived-At: Subject: Re: [mpls] thought about the ADI name 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, 06 Jan 2022 17:28:46 -0000 SGkgTG9hLA0KDQpNeSBkZXNpZ24gcHJpbmNpcGxlIGlzIHRvIGtlZXAgdGhpbmdzIHNpbXBsZSB5 ZXQgZmxleGlibGUgYW5kIGV4dGVuc2libGUuIFNvIEkgdGhpbmsgYSBwYWNrZXQgc2hvdWxkIGhh dmUgb25seSBhIHNpbmdsZSBBREkuIFRoZSBzaXplIG9mIEFEcyBpcyBwcmV0dHkgbXVjaCBsaW1p dGVkIGJ5IHRoZSBoZWFkZXIgYnVmZmVyIHNpemUgYW5kIHRoZSBudW1iZXIgb2YgQURzIGNhbiBo YXZlIHNvbWUgcGVyZm9ybWFuY2UgaW1wYWN0IGJ1dCB0aGlzIGhpZ2hseSBkZXBlbmRzIG9uIHRo ZSBoYXJkd2FyZSB0ZWNobm9sb2d5LiBLZWVwaW5nIGFsbCB0aGUgQURzIGluIGEgY2hhaW4gZm9s bG93cyB0aGUgY29tbW9uIGRlc2lnbiBwcmFjdGljZSBmb3IgaGVhZGVycyB1YmlxdWl0b3VzbHkg dXNlZCBzbyBmYXIuIFRoaXMgY292ZXJzIGFsbCB0aGUgcG9zc2libGUgY2FzZXMuIE5vIG5lZWQg dG8gd29ycnkgYWJvdXQgZmxleGliaWxpdHkgYW5kIGV4dGVuc2liaWxpdHkuIA0KDQpGcm9tIHRo ZSBwYXJzZXIgcG9pbnQgb2Ygdmlldywga25vd2luZyB3aGF0IEFEIHlvdSBoYXZlIHVwZnJvbnQg ZG9lc24ndCBoZWxwIGltcHJvdmluZyB0aGUgcGFyc2VyIHBlcmZvcm1hbmNlIGFuZCByZWR1Y2lu ZyB0aGUgcGFyc2VyIGdyYXBoIHNpemUuIE9uIHRoZSBjb250cmFyeSwgaXQgaW50cm9kdWNlcyB1 bm5lY2Vzc2FyeSBjb25zdHJhaW50cy4gSSdsbCBleHBsYWluIHRoaXMgdXNpbmcgcmVhbCBleGFt cGxlcyBpbiBteSBwcmVzZW50YXRpb24uIA0KDQpCZXN0IHJlZ2FyZHMsDQpIYW95dQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51PiAN ClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSA1LCAyMDIyIDU6NDEgUE0NClRvOiBIYW95dSBTb25n IDxoYW95dS5zb25nQGZ1dHVyZXdlaS5jb20+OyBtcGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W21wbHNdIHRob3VnaHQgYWJvdXQgdGhlIEFESSBuYW1lDQoNCkhhb3l1LA0KDQpUaGlzIG9wZW5z IHVwIGZvciB5ZXQgYW5vdGhlciBpbnRlcmVzdGluZyBkaXNjdXNzaW9uLiBUaGUgImhvdyBtYW55 IiBBRHMgb3IgQURJcyBpcyByZXF1aXJlZCBpbiBhIHNpbmdsZSBwYWNrZXQgZm9yIHRoZSBjaGFp biBwcm9jZXNzaW5nIHRvIGJlIGEgcHJvYmxlbS4gTXkgZ3Vlc3N0aW1hdGUgd291bGQgYmUgdGhh dCB0aGUgdmVyeSB2YXN0IG1ham9yaXR5IG9mIHBhY2tldCB3aWxsIGhhdmUgMCwgMSBvciAyIEFE SXMgc2V0LCBhbmQgdGhlIGNoYWluIGFyZ3VtZW50IG5vdCB2ZXJ5IHJlbGV2YW50Lg0KDQpXaHkg c2hvdWxkIHdlIGRlc2lnbiBmb3IgYSBjb3JuZXIgY2FzZT8NCg0KRXZlbiBpZiB5b3UgaGF2ZSBt YW55IEFESXMgc2V0IHlvdSB3b3VsZCBrbm93IGZyb20gdGhlIGZsYWcgZmllbGQgaWYgdGhlcmUg YXJlIEFEIHRoYXQgeW91IGFyZSBpbnRlcmVzdGVkIGluLg0KDQovTG9hDQoNCk9uIDI4LzEyLzIw MjEgMDE6MzksIEhhb3l1IFNvbmcgd3JvdGU6DQo+IEhpIExvYSwNCj4gDQo+IFBsZWFzZSBzZWUg bXkgcmVzcG9uc2UgaW5saW5lIHdpdGggW0hTXS4NCj4gDQo+IEhhb3l1DQo+IA0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU+DQo+ IFNlbnQ6IFNhdHVyZGF5LCBEZWNlbWJlciAyNSwgMjAyMSAyOjQxIEFNDQo+IFRvOiBIYW95dSBT b25nIDxoYW95dS5zb25nQGZ1dHVyZXdlaS5jb20+OyBtcGxzQGlldGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBbbXBsc10gdGhvdWdodCBhYm91dCB0aGUgQURJIG5hbWUNCj4gDQo+IA0KPiANCj4gT24g MjQvMTIvMjAyMSAwMTo1OCwgSGFveXUgU29uZyB3cm90ZToNCj4+IEhpIExvYSwNCj4+DQo+PiBM ZXQgbWUgdHJ5IHRvIGV4cGxhaW4gYSBiaXQgbW9yZS4gSSBoYXZlIGV4YW1wbGVzIHRvIGJhY2sg dGhlIGZvbGxvd2luZyBjbGFpbXMgd2hpY2ggSSBjYW4gcHJlc2VudCBpbiBhIGZ1dHVyZSBtZWV0 aW5nLg0KPiANCj4gSWYgeW91IHdhbnQgdG8gcHJlc2VudCwgeW91IHNob3VsZCBiZSBzcGVjaWZp YyBhbmQgYXNrIGZvciBhIHNsb3QgYXQgYSBtZWV0aW5nLg0KPj4NCj4+IFNvIGZhciBhbGwgdGhl IGV4aXN0aW5nIGhlYWRlciBkZXNpZ24gZm9sbG93cyBhIGNoYWluIHN0cnVjdHVyZS4NCj4gDQo+ IGhtbW0gLSAgZG8geW91IGNvbnNpZGVyIGEgbnVtYmVyIG9mIFRMVnMgdG8gYmUgYSAiY2hhaW4g c3RydWN0dXJlIj8NCj4gDQo+IFtIU10gWWVzLiBCYXNpY2FsbHkuICBIb3dldmVyLCBpZiBhICJU IiBpcyBuZWVkZWQgdG8gaWRlbnRpZnkgYSAiVExWIiBzdHJ1Y3R1cmUsIHRoaXMgc3RydWN0dXJl IGhhcyB0byBiZSB0cmVhdGVkIGFzIDIgImhlYWRlcnMiIChpLmUuLCB1c2luZyB0d28gcGFyc2Vy IHN0YXRlcyBpbnN0ZWFkIG9mIG9uZSkuIFRoZXJlZm9yZSwgVExWIGlzIHVzdWFsbHkgdXNlZCBh cyBhbiBpbm5lciBzdHJ1Y3R1cmUgb2YgYSBoZWFkZXIuIEl0J3Mgbm90IHJlY29tbWVuZGVkIGZv ciB0aGUgb3V0ZXIgaGVhZGVyIGRlc2lnbi4NCj4gDQo+IFRoZSBoZWFkZXIgYXJlIHBhcnNlZCBs aW5lYXJseSBvbmUgYnkgb25lIGZyb20gdGhlIHN0YXJ0IG9mIHRoZSANCj4gcGFja2V0LA0KPiAN Cj4gb3IgdXBpdSBzdG9wIHdoZW4geW91IGZpbmQgd2hhdCB5b3UgYXJlIGxvb2tpbmcgZm9yLCB3 aGljaCBtYXkgbm90IGJlIHRoZSBsYXN0IGJ1dCB0aGUgZmlyc3QsIHRoZSBsYXN0LCBvciBhbnl0 aGluZyBpbiBiZXR3ZWVuLg0KPiBbSFNdIENvdWxkIHlvdSBwbGVhc2UgZ2l2ZSBhbiBleGFtcGxl Pw0KPiANCj4gdW50aWwgeW91IHJlYWNoIGEgaGVhZGVyIHRoYXQgaXMgY29uc2lkZXJlZCB0aGUg bGFzdCBvbmUgY29uY2VybmVkIGJ5IHRoZSBmb3J3YXJkaW5nIHBsYW5lLg0KPiANCj4gWW91IGtu b3cgdGhlIHByZXNlbmNlIG9mIGEgc3BlY2lmaWMgaGVhZGVyIG9ubHkgd2hlbiB5b3UgcmVhY2gg aXQuDQo+IA0KPiBOby4gbm90IHRydWUgLSBpZiB5b3UgaGF2ZSB0aGUgZmxhZyBmaWVsZCAoRkFJ L05BSSBvciBBREkuIG9yIHdoYXRldmVyIHlvdSB3YW50IHRvIGNhbGwgdGhlbS4gVGhlIGZsYWdz IHdpbGwgdGVsbCB5b3UsIHlvdSdsbCBrbm93IHdoYXQgeW91IGFyZSBsb29raW5nIGZvci4NCj4g W0hTXSBXaGF0IEkgbWVhbiBpcyB0aGF0IHdlIGp1c3QgbmVlZCBhIHNpbmdsZSBpbmRpY2F0b3Ig dG8gdGVsbCB0aGUgcHJlc2VuY2Ugb2YgQUQuIEJleW9uZCB0aGF0LCBpdCdzIG5vdCBoZWxwZnVs IGFuZCBldmVuIGhhcm1mdWwuIEkgaGF2ZSBnaXZlbiB0aGUgcmVhc29ucy4gUGVyaGFwcyB5b3Ug c2hvdWxkIHRyeSB0byB3cml0ZSB0aGUgcHNldWRvIGNvZGUgdG8gdmVyaWZ5IHRoYXQuDQo+IA0K PiBJbiB0aGlzIGRlc2lnbiwgdGhlIG51bWJlciBvZiBwYXJzZXIgc3RhdGVzIGFzIHdlbGwgYXMg dGhlIHRpbWUgZm9yIHBhcnNpbmcgaXMgYm90aCBsaW5lYXIgdG8gdGhlIG51bWJlciBvZiBoZWFk ZXJzIHNjYW5uZWQuDQo+IA0KPiBDYW4ndCBhcmd1ZSBhYm91dCB0aGlzLCBkb2Vzbid0IHRoZSBm YWN0IHRoYXQgeW91IGFyZSBsb29raW5nIGZvciBzb21ldGhpbmcgc3BlY2lmaWMgaGVscD8NCj4+ DQo+PiBOb3cgcGVvcGxlIG1heSB0aGluayB1c2luZyBzb21lIGV4dHJhIGluZGljYXRvcnMgKGku ZS4sIGEgYml0bWFwIHdpdGggZWFjaCBiaXQgaW5kaWNhdGluZyB0aGUgcHJlc2VuY2Ugb2YgYSBo ZWFkZXIgbGF0ZXIgaW4gdGhlIHBhY2tldCkgbWF5IGltcHJvdmUgdGhlIHBhcnNpbmcgcGVyZm9y bWFuY2UuIFRvIHRoaXMgd2UgbXVzdCBhc2sgImluIHdoYXQgc2Vuc2UiPw0KPj4NCj4+IFdlIGNh biBjb25zaWRlciB0d28gcG9zc2libGUgdHlwZXMgb2YgaW1wcm92ZW1lbnRzLiBGaXJzdCBpcyB0 aGUgcmVkdWN0aW9uIG9mIHBhcnNpbmcgc3RhdGVzIHdoaWNoIGNhbiBoZWxwIHRvIHNhdmUgdGhl IHBhcnNlciByZXNvdXJjZSAoaS5lLiwgZmV3ZXIgbm9kZXMgaW4gdGhlIHBhcnNlciBGU00pOyBz ZWNvbmQgaXMgdGhlIHJlZHVjdGlvbiBvZiBwYXJzaW5nIGN5Y2xlcyB3aGljaCBjYW4gaGVscCB0 byBwYXJzZSBhIHBhY2tldCBmYXN0ZXIgKHdlIGhhdmUgYSBmaXhlZCBjb3N0IGZvciBwYXJzaW5n IGVhY2ggaGVhZGVyLCBubyBtYXR0ZXIgdGhlIHNpemUgb2YgaXQuIEUuZywgZWFjaCBNUExTIGxh YmVsIGlzIGNvbnNpZGVyZWQgYSBoZWFkZXIsIHRoZSBlbnRpcmUgSVB2NiBoZWFkZXIsIGV4Y2x1 ZGluZyBFSHMsIGlzIGFsc28gY29uc2lkZXJlZCBhIGhlYWRlcikuDQo+Pg0KPj4gRm9yIHRoZSBm aXJzdCBvbmUsIGlmIHlvdSBzdGFydCB0byBhY3R1YWxseSBkcmFmdCB0aGUgcGFyc2luZyBncmFw aCwgeW91IHdpbGwgZmluZCB0aGUgb3Bwb3NpdGUgcmVzdWx0cy4gSW4gdHdvIGRpZmZlcmVudCBw YXJzaW5nIHN0eWxlcywgYm90aCByZXF1aXJlcyBtb3JlIHBhcnNlciBzdGF0ZXMgdGhhbiBhIHNp bXBsZSBoZWFkZXIgY2hhaW4uDQo+Pg0KPj4gRm9yIHRoZSBzZWNvbmQgb25lLCB3ZSBuZWVkIHRv IHVuZGVyc3RhbmQgdGhhdCB0aGUgaGVhZGVycyBjb25jZXJuZWQgYnkgYSBmb3J3YXJkaW5nIHBs YW5lIG5lZWQgdG8gYWxsIGJlIHBhcnNlZCBhbnl3YXkuIFlvdSBjYW4ndCBpZ25vcmUgc29tZSBo ZWFkZXJzIGluIHRoZSBtaWRkbGUgYmVjYXVzZSB5b3Ugd2lsbCBuZWVkIHRvIHJlY29uc3RydWN0 IHRoZSBwYWNrZXQgaGVhZGVycyBhdCB0aGUgZWdyZXNzIChhIHByb2Nlc3MgYWxzbyBrbm93biBh cyBkZXBhcnNpbmcpLiBTbyB0aGUgZXh0cmEgaW5kaWNhdG9yIGVuY29kaW5nIGRvZXNuJ3QgaGVs cCB0byBpbXByb3ZlIHRoZSBwYXJzaW5nIHNwZWVkIGVpdGhlci4NCj4gDQo+IFNvLCBJIGNvbmNs dWRlLiBJZiB3ZSBoYXZlIHRoZSBmbGFnIGZpZWxkIGFuZCBrbm93IHRoYXQgdGhlcmUgaXMgb25s eSBvbmUgb3IgdHdvIGFjdGlvbiBmbGFncyBzZXQsIEkgd2lsbCBiZSB3b3JzZSBvZmYgdGhhbiBp ZiBJIGhhdmUgYSBQU0Qgc3RydWN0dXJlIHRoYXQgSSBoYXZlIG5vIGtub3dsZWRnZSBhYm91dD8N Cj4gDQo+IFtIU10gWW91IG1heSBqdXN0IGtub3cgdGhlcmUgaXMgUFNELiBUaGF0J3MgZW5vdWdo LiBPdGhlciBpbmZvcm1hdGlvbiBkb2Vzbid0IGhlbHAgb24gZWl0aGVyIHBhcnNlciBzaXplIG9y IHBhcnNpbmcgc3BlZWQuIE9uIHRoZSBjb250cmFyeSwgdGhlIGJpdG1hcCBvciBjYXRhbG9nIGZv cmNlcyB0aGUgQUQgb3JkZXIgYW5kIGxpbWl0cyB0aGUgQUQgZXh0ZW5zaWJpbGl0eS4NCj4gDQo+ IA0KPiBOb3cgSSdtIHRvbyBmYXIgb2ZmIHJvYWQsIGFuZCBzdG9wIGhlcmUuDQo+IA0KPj4NCj4+ IFRoZXJlJ3MgYSByZWFzb24gd2h5IHNvIGZhciBhbGwgdGhlIGhlYWRlcnMgYXJlIHNpbXBseSBv cmdhbml6ZWQgYXMgYSBjaGFpbi4gSXQncyB0aGUgbW9zdCBlZmZpY2llbnQgYW5kIHN0cmFpZ2h0 Zm9yd2FyZCB3YXkuIE15IHN0dWR5IGlzIGJhc2VkIG9uIGN1cnJlbnQgc3dpdGNoIEFTSUNzIGFu ZCBzb21lIE5Qcy4gIElmIHBlb3BsZSBkb24ndCBiZWxpZXZlIG1lLCB0aGVuIGV2aWRlbmNlIChl LmcuLCBwc2V1ZG8gY29kZSBvciBwYXJzaW5nIGdyYXBoKSBuZWVkcyB0byBiZSBwcm92aWRlZC4g UGVyaGFwcyB0aGVyZSBhcmUgc29tZSBkaWZmZXJlbnQgZm9yd2FyZGluZyBwbGFuZSBkZXNpZ25z IHdoaWNoIGNhbiBwbGF5IG1hZ2ljLiBXZSBuZWVkIHRvIGxlYXJuIHRoYXQgYmVmb3JlIGludHJv ZHVjaW5nIGFueSBuZXcgbWVjaGFuaXNtLg0KPiANCj4gDQo+Pg0KPj4gQSBjYXZlYXQgaXMgdGhh dCwgYW4gZXh0cmEgaW5kaWNhdG9yIGZvciB0aGUgcHJlc2VuY2Ugb2YgSEJIIGhlYWRlcnMgbWln aHQgYmUgdXNlZnVsIGluIHNvbWUgY2FzZXMuIEZvciBleGFtcGxlLCBvbiBhbiBMU1AgcGF0aCBu b2RlcywgaWYgdGhlcmUncyBubyBIQkggaGVhZGVycyBsYXRlciBpbiB0aGUgcGFja2V0LCB0aGUg cGFyc2VyIGNhbiBzdG9wIGZ1cnRoZXIgcGFyc2luZyBpbW1lZGlhdGVseSB3aGljaCBjYW4gc2F2 ZSBzb21lIHBhcnNpbmcgY3ljbGVzLiAgRXZlbiBpbiB0aGlzIGNhc2UsIGlmIHRoZSBmb3J3YXJk aW5nIHBsYW5lIHN0aWxsIHJlcXVpcmVzIHRvIGNvbnRpbnVlIHBhcnNpbmcsIHRoaXMgbWVjaGFu aXNtIGRvZXNu4oCZdCBoZWxwLg0KPj4NCj4gSSBhIEZBSS9OQUkvQURJIHRoYXQgaW5kaWNhdGVz IEhCSCB3cnNlIHRoYW4gb25lIHRoYXQgaW5kaWNhdGUgRTJFPw0KPiANCj4gW0hTXSBTaW5jZSBM U1AgZW5kIG5vZGVzIG5lZWQgdG8gcGFyc2UgYWxsIHRoZSBBRCBhbnl3YXksIHNvIGFuIG92ZXJh bGwgaW5kaWNhdG9yIGZvciBBRCBpcyBzdWZmaWNpZW50IGZvciB0aGF0IHB1cnBvc2UuIEJleW9u ZCB0aGF0LCBhbiBIQkggaW5kaWNhdG9yIGNhbiBhbGxvdyB0aGUgTFNQIHBhdGggbm9kZXMgdG8g YXZvaWQgY29udGludWluZyBwYXJzaW5nIHdoZW4gdGhlIGluZGljYXRvciB3YXMgZm91bmQgd2hp Y2ggY2FuIHNob3J0ZW4gdGhlIHBhcnNpbmcgcHJvY2Vzcy4NCj4gDQo+IC9Mb2ENCj4gDQo+PiBJ biBnZW5lcmFsLCB3ZSByZWFsbHkganVzdCBuZWVkIHRvIGNvbmNlcm4gdGhlIHBhY2tldCBoZWFk ZXIgYnVmZmVyIChha2EgcGFja2V0IHdpbmRvdykgc2l6ZS4gQXMgbG9uZyBhcyBhbGwgdGhlIGhl YWRlcnMgY29uY2VybmVkIGJ5IGEgZm9yd2FyZGluZyBwbGFuZSBpcyB3aXRoaW4gdGhlIGJ1ZmZl ciBsaW1pdCwgdGhlIHBhcnNpbmcgY29zdCBpcyBhIG5lZ2xpZ2libGUgY29uY2VybiBmb3IgYSBz aW1wbGUgaGVhZGVyIGNoYWluLiBPdGhlciBtZWNoYW5pc21zIGFyZSBvZiBubyBoZWxwIGF0IGJl c3QgYW5kIGNvdWxkIGJlIGhhcm1mdWwgYXQgd29yc3QuIE9mIGNvdXJzZSwgSSdkIGxpa2UgdG8g c2VlIGV2aWRlbmNlIGlmIHBlb3BsZSB0aGluayB0aGUgb3RoZXIgd2F5Lg0KPj4NCj4+IEhhcHB5 IEhvbGlkYXlzIQ0KPj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+IEhhb3l1DQo+Pg0KPj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IExvYSBBbmRlcnNzb24gPGxvYUBwaS5udT4N Cj4+IFNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMjIsIDIwMjEgMjo1NCBQTQ0KPj4gVG86IEhh b3l1IFNvbmcgPGhhb3l1LnNvbmdAZnV0dXJld2VpLmNvbT47IG1wbHNAaWV0Zi5vcmcNCj4+IFN1 YmplY3Q6IFJlOiBbbXBsc10gdGhvdWdodCBhYm91dCB0aGUgQURJIG5hbWUNCj4+DQo+PiBIYW95 dSwNCj4+DQo+PiBPSywgSSBzaW1wbHkgZG9uJ3QgdW5kZXJzdGFuZC4NCj4+DQo+PiBJZiB5b3Ug ZG9uJ3Qga25vdyB3aGF0IGFjdGlvbiB5b3UnbGwgdGFrZSwgd2hhdCBnb29kIGlzIGl0IHRvIGtu b3cgd2hlcmUgdG8gZmluZCB0aGUgZGF0YT8NCj4+DQo+PiBJdCBtaWdodCBiZSB0aGF0IHRoaXMg aXMgbm90IHdoYXQgeW91IHNheSwgYnV0IHRoYXQgaXMgd2hhdCBpZiBnZXQgZnJvbSB5b3VyIHRl eHQgYmVsb3cuIFNvcnJ5IGlmIEknbSBtaXN1bmRlcnN0YW5kaW5nLg0KPj4NCj4+IC9Mb2ENCj4+ DQo+PiBPbiAyMy8xMi8yMDIxIDAzOjI1LCBIYW95dSBTb25nIHdyb3RlOg0KPj4+IEhpIExvYSwN Cj4+Pg0KPj4+IEluIG15IG9waW5pb24gdGhlIEFESSBzaG91bGQgb25seSBiZSB1c2VkIHRvIGlu ZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBBRC4gIEUyRSBvciBIQkggQUQgY291bGQgYmUgZGlmZmVy ZW50aWF0ZWQgYmVjYXVzZSBpbiBzb21lIGNhc2UgaXQgY2FuIGhlbHAgc3RvcCBmdXJ0aGVyIHBh cnNpbmcgYmV5b25kIEFESS4gIE90aGVyIGluZm9ybWF0aW9uIGVuY29kZWQgaW4gaXQgd29uJ3Qg aGVscCBidXQgY29tcGxpY2F0ZSB0aGUgcGFyc2luZyBwcm9jZXNzLiBJIHN0cm9uZ2x5IHN1Z2dl c3QgYW55IHN1Y2ggcHJvcG9zYWwgc2hvdWxkIGdpdmUgYSBjbGVhciBwcmVzZW50YXRpb24gb24g d2h5IGl0J3MgbmVjZXNzYXJ5IGFuZCBob3cgaXQgY2FuIGhlbHAgZnJvbSB0aGUgdmlldyBvZiBp bXBsZW1lbnRvcnMsIG90aGVyd2lzZSwgd2UgbWF5IGVuZCB1cCB3aXRoIGFuIG92ZXIgY29tcGxp Y2F0ZWQgZGVzaWduIHdpdGhvdXQgdGFuZ2libGUgYmVuZWZpdHMuDQo+Pj4NCj4+PiBCZXN0IHJl Z2FyZHMsDQo+Pj4gSGFveXUNCj4+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ Pj4gRnJvbTogbXBscyA8bXBscy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTG9hIEFu ZGVyc3Nvbg0KPj4+IFNlbnQ6IFN1bmRheSwgRGVjZW1iZXIgMTksIDIwMjEgODozMiBBTQ0KPj4+ IFRvOiBtcGxzQGlldGYub3JnDQo+Pj4gU3ViamVjdDogW21wbHNdIHRob3VnaHQgYWJvdXQgdGhl IEFESSBuYW1lDQo+Pj4NCj4+PiBXb3JraW5nIEdyb3VwLA0KPj4+DQo+Pj4gVGhlIE1JQUQgUmVx dWlyZW1lbnQgU3BlY2lmaWNhdGlvbiB1c2UgdGhlIGFiYnJldmlhdGlvbiBBREksIGl0IHN0YW5k cyBmb3IgQW5jaWxsYXJ5IERhdGEgSW5kaWNhdG9yLiBXaGljaCBpcyBhbGwgbmljZSBhbmQgZGFu ZHkuDQo+Pj4NCj4+PiBCdXQgaXNuJ3QgaXQgaGUgY2FzZSAgdGhhdCB0aGUgaW5kaWNhdG9yIGdp dmVzIHVzIHR3byB0aGluZ3MsIHRoZSBhY3Rpb24gdG8gYmUgcGVyZm9ybWVkIGFuZCB3aGVyZSB0 byBmaW5kIHRoZSBkYXRhIG5lZWRlZCwgaS5lLiwgYW4gQW5jaWxsYXJ5IERhdGEgYW5kIEFjdGlv biBpbmRpY2F0aW9uIChBREFJPykuDQo+Pj4NCj4+PiBObyBJJ20gbm90IHN1Z2dlc3RpbmcgdGhh dCB3ZSBjaGFuZ2UsIGJ1dCB3ZSBzaG91bGQgYmUgYXdhcmUsIGFuZCBpdCB3b3VsZCBiZSBuaWNl IHRvIGhhdmUgaXQgbWVudGlvbmVkIHNvbWV3aGVyZS4NCj4+Pg0KPj4+IC9Mb2ENCj4+DQo+IA0K DQotLSANCkxvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQHBp Lm51DQpTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYS5waS5u dUBnbWFpbC5jb20NCkJyb256ZSBEcmFnb24gQ29uc3VsdGluZyAgICAgICAgICAgICBwaG9uZTog KzQ2IDczOSA4MSAyMSA2NA0K From nobody Tue Jan 11 06:04:11 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661C33A1197; Tue, 11 Jan 2022 06:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 aPDa-K-2qaEm; Tue, 11 Jan 2022 06:04:04 -0800 (PST) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 AF3473A1194; Tue, 11 Jan 2022 06:04:04 -0800 (PST) Received: by mail-qv1-xf2c.google.com with SMTP id fq10so18455535qvb.10; Tue, 11 Jan 2022 06:04:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=RKbzq0AUSEHqytHkLegtPBkAb79+RoRMwoOR7BUzFPk=; b=DVisroKSGhtOxnY34MXXEZXLJMenFk0MVPDA2yIo6QNhWUnymYFW6wiBXAh9WeEnOH bREQnNIDbKgZb4Z5uNbv1g4TbwcIqzw1yhdAM1/pbRgzC3TH+jrqSn86RU29DW8oHORH Bt2/waKQI518emsd/J0SmMr4QomHx/DS2yi6RnsUf6kLhawU4KxMzLGewW6aLpl6NEFT JBdCx5GRRac6GRJGM2VrEkZTo4MpF0xN1fPiZ7fDzLc8FCC05hH2nI/8xtwBmoc3bPTb WCE6EmGqeL+z9F9wJUW3wjwKNT23gbbJBPHiu9tQRcF0wcLA3KlyrgHS4fOezipawqpO tshw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=RKbzq0AUSEHqytHkLegtPBkAb79+RoRMwoOR7BUzFPk=; b=Wxz5oDMhiOaiQfGqSSDc2m0YMcqKOWJ3CX2rHqFvmjIFyYTmVRjHYhfckeIIAF33vw 0rIoAJXhllL01O2VRW1Hp8n7e2c3sL05AH0aeKW37p8mQRNXfIZzD+gIhPiyu9pfBMd6 9RhbDlhKXmY8fkbNqb56jt2+zKdw9wDmafd7eTuaSc4oF4n44/GCVTLN2P7ueKiueYDE k/om/52FI3JmafNJ9/6H1uQsNld34GOAQhQwrzQ8I/7TqQx7suFolnGkZa0exoSlugME pPWZgXj+WiAtaV9KMuJeJZQklZPEYjomDn3UDAOZ8woKhNA5k4ykNrtaGqsMLeX6nVl3 W4OQ== X-Gm-Message-State: AOAM533LOz9NvydEpWLwL6Dbq5FizGHMk48jXsleCNDe5MUeiye4O8Ap eZQgikxYb7xNply03kj5aZ4+FuCSpp4= X-Google-Smtp-Source: ABdhPJxbxiK9fQ/cjPEKhQPT0Gv5q3fbIPVFN1WnTMUIRAYmhcmjxSMW4JvWV732+dFmgUF8F9BI7A== X-Received: by 2002:a05:6214:20a4:: with SMTP id 4mr3886505qvd.115.1641909842852; Tue, 11 Jan 2022 06:04:02 -0800 (PST) Received: from DM5PR1901MB2150.namprd19.prod.outlook.com ([2603:1036:4:9e::5]) by smtp.gmail.com with ESMTPSA id w14sm2009694qta.6.2022.01.11.06.04.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jan 2022 06:04:02 -0800 (PST) From: Tarek Saad To: "mpls@ietf.org" , Kireeti Kompella , "bruno.decraene@orange.com" CC: "mpls-chairs@ietf.org" , "pals-chairs@ietf.org" , DetNet Chairs , Loa Andersson Thread-Topic: Agenda for the Open T meeting 2022-0106 Thread-Index: ATk4YTc34UXgRJdlb7RF5YCu3qpO5L2dJbtS X-MS-Exchange-MessageSentRepresentingType: 1 Date: Tue, 11 Jan 2022 14:04:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] Agenda for the Open T meeting 2022-0106 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, 11 Jan 2022 14:04:10 -0000 SGkgYWxsLA0KDQpUaGUgdGVudGF0aXZlIGFnZW5kYSBjb21wb3NlZCBieSBDaGFpcnMgZm9yIHRo aXMgVGh1cnNkYXkncyBNUExTIE9wZW4gRFQgbWVldGluZyBpcyBhdDoNCmh0dHBzOi8vdHJhYy5p ZXRmLm9yZy90cmFjL21wbHMvd2lraS8yMDIyLTAxLTAxMy1hZ2VuZGENCg0KS2lyZWV0aS9CcnVu byB5b3UndmUgYmVlbiBhZGRlZCB0byBnaXZlIHVwZGF0ZXMgYXMgcGVyIGxhc3Qgd2VlaydzIGFj dGlvbiBpdGVtcy4NCg0KUmVnYXJkcywNClRhcmVrIChmb3IgdGhlIENoYWlycykNCg0K77u/T24g MjAyMi0wMS0wNSwgMTE6NDUgQU0sICJMb2EgQW5kZXJzc29uIiA8bG9hQHBpLm51PiB3cm90ZToN Cg0KICAgIE9wZW4gRFQsDQoNCg0KICAgIFBsZWFzZSBmaW5kIHRoZSBhZ2VuZGEgZm9yIHRoZSBm aXJzdCBNUExTIDIwMjIgT3BlbiBEVCBtZWV0aW5nIGF0Og0KDQogICAgaHR0cHM6Ly90cmFjLmll dGYub3JnL3RyYWMvbXBscy93aWtpLzIwMjItMDEtMDYtYWdlbmRhDQoNCiAgICAvTG9hDQoNCg0K ICAgIC0tIA0KICAgIExvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDog bG9hQHBpLm51DQogICAgU2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAg ICBsb2EucGkubnVAZ21haWwuY29tDQogICAgQnJvbnplIERyYWdvbiBDb25zdWx0aW5nICAgICAg ICAgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo= From nobody Thu Jan 13 14:41:29 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578833A02F9; Thu, 13 Jan 2022 14:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.098 X-Spam-Level: X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIrQwRYBnAc5; Thu, 13 Jan 2022 14:41:21 -0800 (PST) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 E73613A02C1; Thu, 13 Jan 2022 14:41:20 -0800 (PST) Received: by mail-ed1-x529.google.com with SMTP id m4so28339710edb.10; Thu, 13 Jan 2022 14:41:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=Subqz+1zLd0wxvPwaavHGiW0HnUyEd24urh8CmTGA7s=; b=mvL1NpAoq3Q7+ReCTbNjebeMngfnYGT8bxFV2xVKdbMTBIiyc2iTxcGzkKe5aYx5oE q5U+JWy7Kvu0i4JBJFp7AcbPhCFckFPyKzIFIHKv/UXw3XzTUWrNvSaz5KxaEpDJJ7x8 8Prr3XCX0aL6uGaztxYUGuIBLBE2Rag7JiBkEuDqcfmqfRrAJO7GwloVw81dt3FtGkFq bOTOTW6UY8eZfgHql0e8FK87wo5b48cVfW94V1rdqhlAfTnd85fLhAgiLB0gR14EvbgR upg+g/c3q3uAa71VXLH7gE88kJnmlEz5HEmZ5sav7PN6+xFgHuTIMMm4quOj5pEeJ0Kn znfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Subqz+1zLd0wxvPwaavHGiW0HnUyEd24urh8CmTGA7s=; b=qufqZShdjJ4HlPJa0Drv3JkNp/fLlsCfN/VxlHwkdU39YviOR6BywdAxul7f5tpTk8 VoDRDzpZ+LKGQMc6+qwny6pVrwJtg/zx5gvN3cJTUpBgNI/erFGmD8l71kYxV7KGKwMy 6xRgOYnf3Jukef8O12qqkik5Ig46CiCqUMpiqf+PB1nfoh65dd1nxWrTHyEOqJ4sKhtJ k9Elj+/rRvxXva1vDW1IuRLqP5+RWKPHyMA+weWFr678tCBQtEp+WNMHpZS+rMiXsiRh RDIJrYBgqbjwR47lG7QEc+QjjUyQyDzmdBNhdqsbB0eAahPn92+V3+UAtBTDQR3l2Hkt l8ZA== X-Gm-Message-State: AOAM532blWmNBfcJlCP0l4TxHZRdsAf+OkyHkJIEMgkPhWORTQdwpIo4 o3/wtYoXJLBamh+NlqYfkNqAL8sBUgZxUUbZey3nspRhr90= X-Google-Smtp-Source: ABdhPJwsamZX8Kk4369nJzAkYwAwdrkRddkkXVTyyfQ7eePuzjNRfiXCcGdY8CNjc1rC726WhqyIqZ6oyd+C7ZnYvII= X-Received: by 2002:a50:9e47:: with SMTP id z65mr6288213ede.328.1642113678037; Thu, 13 Jan 2022 14:41:18 -0800 (PST) MIME-Version: 1.0 From: Greg Mirsky Date: Thu, 13 Jan 2022 14:41:06 -0800 Message-ID: To: mpls , pals@ietf.org, DetNet WG Content-Type: multipart/alternative; boundary="00000000000075d45a05d57e62e7" Archived-At: Subject: [mpls] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id 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, 13 Jan 2022 22:41:22 -0000 --00000000000075d45a05d57e62e7 Content-Type: text/plain; charset="UTF-8" Hi Bruno, et al. Thank you for presenting this work at the MPLS Open DT meeting today. Below please find the summary of my comments and questions with the additional thoughts that came after we've closed the call. I greatly appreciate the consideration and opinions of the authors and the group. - Compatibility with nodes that support only RFC 6790. - If the proposed indicators are used to signal the presence of an ISD, that seems to create a problem for an RFC6790-only node as it might not be able to process the ISD. - If one of the indicators is to be used to signal the presence of the extension, that, similarly to the scenario above, might not be correctly processed by an RFC6790-only node. - Scaling - If the proposed method to signal the ancillary data is used in, for example, a strict explicit routing environment, the Entropy Label is not needed. If that is the case, using the indicators, as described in the draft, seems to waste 20 bits in a label element compared to the mechanism proposed in draft-kompella-mpls-mspl4fa. Regards, Greg --00000000000075d45a05d57e62e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bruno, et al.
Thank you for presen= ting this work at the MPLS Open DT meeting today. Below please find the sum= mary of my comments and questions with the additional thoughts that came af= ter we've closed the call. I greatly appreciate the consideration and o= pinions of the authors and the group.
  • Compatibility with = nodes that support only RFC 6790.
    • If the proposed indicators ar= e used to signal the presence of an ISD, that seems to create a problem for= an RFC6790-only node as it might not be able to process the ISD.
    • I= f one of the indicators is=C2=A0to be used to signal the presence=C2=A0of t= he extension, that, similarly to the scenario above, might not be correctly= processed by an RFC6790-only node.
  • Scaling
    • If the= proposed method to signal the ancillary data is used in, for example, a st= rict explicit routing environment, the Entropy Label is not needed. If that= is the case, using the indicators, as described in the draft, seems to was= te 20 bits in a label element compared to the mechanism proposed in draft-k= ompella-mpls-mspl4fa.
Regards,
Greg
--00000000000075d45a05d57e62e7-- From nobody Mon Jan 17 08:24:43 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61033A1304; Mon, 17 Jan 2022 08:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 Hrk-c-3_bSWG; Mon, 17 Jan 2022 08:24:37 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (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 C0ED03A1308; Mon, 17 Jan 2022 08:24:36 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar23.francetelecom.fr (ESMTP service) with ESMTPS id 4Jcy0g02qmzBrlB; Mon, 17 Jan 2022 17:24:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1642436675; bh=vciGOX2L+DS2FZqScbs+buIv3Ao62MaNnqXtn4/HSVk=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=ITLkK7JhiZ7rjYRYjEzAGMcD4qkl5pazfBI3JiZ/kVHyQ9AQ3wiKL78MzqeZNvWXr UNLVLFof0+n/JFipAESEgicRWR+pYAfIwaeE0mtnUR67Jsp5PTuIpd9lYMbA6r6aV0 q6vpjJtLEYl320uCGQG05FMkWS03rhemDXq9NuAl4TOiRTQWAgFJBBe1dOT4GLppfy 35oPfyPqDJopxzzRq9PGK9y4JkfYoBy0iVLiLcXNaReeOSRlIsJY/5xZpX2oKgmcXc r4u6mx7gWW65pyUtT5lDyBUzUNxHKLJo9CKtwgDhfTDGeqADX+gMAhE3u3n1mK0V9w TA6cNYXNdPQ2Q== From: To: Greg Mirsky CC: mpls , "pals@ietf.org" , DetNet WG Thread-Topic: [mpls] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id Thread-Index: AQHYCM7cnE3AfQJ3YUSADpo0x6GYqaxnZBPQ Date: Mon, 17 Jan 2022 16:24:34 +0000 Message-ID: <11050_1642436674_61E59842_11050_100_1_0d0176823ddd4cb4ad825e3ee88445a3@orange.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-01-17T16:24:32Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_enabled: true msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_setdate: 2022-01-17T16:24:32Z msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_method: Standard msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_name: Orange_restricted_external.2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_siteid: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_actionid: da6d6ab7-59eb-4efc-8714-aea6ac0da889 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_contentbits: 0 x-originating-ip: [10.115.27.52] Content-Type: multipart/alternative; boundary="_000_0d0176823ddd4cb4ad825e3ee88445a3orangecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id 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, 17 Jan 2022 16:24:42 -0000 --_000_0d0176823ddd4cb4ad825e3ee88445a3orangecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, all Greg, thanks for taking the time to read the draft and comment. WG, for context, we are discussing a subset of the draft: the ability to ad= vertise indicator as part of the existing Entropy Label TTL as described in= section 2 of the draft (it's 1 page): https://datatracker.ietf.org/doc/html/draft-decraene-mpls-slid-encoded-entr= opy-label-id-02#section-2 Please see inline [Bruno] Orange Restricted From: mpls On Behalf Of Greg Mirsky Sent: Thursday, January 13, 2022 11:41 PM To: mpls ; pals@ietf.org; DetNet WG Subject: [mpls] Continuing with my comments on draft-decraene-mpls-slid-enc= oded-entropy-label-id Hi Bruno, et al. Thank you for presenting this work at the MPLS Open DT meeting today. Below= please find the summary of my comments and questions with the additional t= houghts that came after we've closed the call. I greatly appreciate the con= sideration and opinions of the authors and the group. * Compatibility with nodes that support only RFC 6790. * If the proposed indicators are used to signal the presence of an I= SD, that seems to create a problem for an RFC6790-only node as it might not= be able to process the ISD. [Bruno] - Draft(*) extends the use of the Entropy Label TTL field which is essentia= lly specified as a Reserved field in RFC 6790. Hence draft is backward comp= atible with RFC 6790. - Draft does not specify ISD so this is out of scope of this draft. That be= en said: - You are right that before sending ISD in a new extension, the capability= for the receiver/egress to support this ISD needs to be known by the sende= r. This is priori required by all ISD solution. - You seemed to assume that ISD are always necessary but IMHO indicators an= d ISD are two different extensions and Indicators may be used without ISD e= xtensions .e.g., cf sections 4, 5, 3 of the draft * If one of the indicators is to be used to signal the presence of t= he extension, that, similarly to the scenario above, might not be correctly= processed by an RFC6790-only node. [Bruno] idem * Scaling * If the proposed method to signal the ancillary data is used in, fo= r example, a strict explicit routing environment, the Entropy Label is not = needed. If that is the case, using the indicators, as described in the draf= t, seems to waste 20 bits in a label element compared to the mechanism prop= osed in draft-kompella-mpls-mspl4fa. [Bruno] And for all other cases, the scaling is very good as we carry indic= ators with zero extra label. So the net benefit is dependent of the relativ= e usage of strict explicit routing traffic vs traffic which can be ECMP. In= my environment, the latter is much more prevalent, hence the net benefit i= s positive. PS : by < draft > I mean section 2 of the draft as this is the scope of the= discussion. Regards, -Bruno Regards, Greg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_0d0176823ddd4cb4ad825e3ee88445a3orangecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg, all

 

Greg, thanks for taking the time to read the draft and comment= .

 

WG, for context, we are discussing a subset of the draft: the = ability to advertise indicator as part of the existing Entropy Label TTL as described in section 2 of the draft (it’s 1 pag= e):

https://datatracker.ietf= .org/doc/html/draft-decraene-mpls-slid-encoded-entropy-label-id-02#section-= 2

 

Please see inline [Bruno]

 

 

Orange Restricted

From: mpls <mpls-bounces@ietf.org> On Behalf Of Greg Mirsky
Sent: Thursday, January 13, 2022 11:41 PM
To: mpls <mpls@ietf.org>; pals@ietf.org; DetNet WG <detnet@= ietf.org>
Subject: [mpls] Continuing with my comments on draft-decraene-mpls-s= lid-encoded-entropy-label-id

 

Hi Bruno, et al.

Thank you for presenting this work at the MPLS Open = DT meeting today. Below please find the summary of my comments and question= s with the additional thoughts that came after we've closed the call. I gre= atly appreciate the consideration and opinions of the authors and the group.

  • Compatibility with nodes that support only RFC 6790.
    • If the proposed indicators are used to signal the presence of an ISD, that = seems to create a problem for an RFC6790-only node as it might not be able = to process the ISD.

[= Bruno]

-= Draft(*) extends the use of the Entropy Label TTL field which is essentially specified as a Reserved field in RFC 6790. Henc= e draft is backward compatible with RFC 6790.

-= Draft does not specify ISD so this is out of scope of this draft. That been said:

-  You are right that before sending ISD in a new extension, the capabi= lity for the receiver/egress to support this ISD needs to be known by the s= ender. This is priori required by all ISD solution.

- You seem= ed to assume that ISD are always necessary but IMHO indicators and ISD are = two different extensions and Indicators may be used without ISD extensions .e.g., cf sections 4, 5, 3 of the draft

    • If one of the indica= tors is to be used to signal the presence of the extension, that,= similarly to the scenario above, might not be correctly processed by an RF= C6790-only node.

[= Bruno] idem

  • Scaling
    • If the proposed method to signal the ancillary data is used in, for example= , a strict explicit routing environment, the Entropy Label is not needed. I= f that is the case, using the indicators, as described in the draft, seems = to waste 20 bits in a label element compared to the mechanism proposed in draft-kompella-mpls-mspl4fa.

[= Bruno] And for all other cases, the scaling is very good as we carry indicators with zero extra label. So the net benefit is d= ependent of the relative usage of strict explicit routing traffic vs traffi= c which can be ECMP. In my environment, the latter is much more prevalent, = hence the net benefit is positive.

PS : by « dr= aft » I mean section 2 of the draft as this is the scope of the = discussion.

Regards,

-Bruno

Regards,

Greg

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_0d0176823ddd4cb4ad825e3ee88445a3orangecom_-- From nobody Tue Jan 18 05:21:00 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C213A113C for ; Tue, 18 Jan 2022 05:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63-qDU_mP8u2 for ; Tue, 18 Jan 2022 05:20:57 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40134.outbound.protection.outlook.com [40.107.4.134]) (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 D33413A113B for ; Tue, 18 Jan 2022 05:20:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aVE8czjCn3niEZlngaKgXX77dX1dtpGeGqe9A97wvFjblZczEM0f6RG+MWID2k5xDg34ujoyEy6IswtMsMjII8ac0MV1y15KLy6HbyKcKUzbO38gH0MGmWkvn6zkTj4Zm2Ax19OYnkD6lE65l124WN98x3001zDjtlKbLxNbnvJvvapdSnSdgeepKC408GNibWUWGsqoZdMrSUebIMC89R947gRCzM+8j9Hkx0XjADP16hRt14JhD1bWMAlT5sIK8UC3Pet9Ub1DyQvIeZ9lrSeuyTe9LMg8hidG/Xe+ZhesT52Fxe7NOzAXIxUq/xQlK6lewYl/X1m5IW4OrZCX9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zGyA5WoL8o/VSs+wM00j7VcS+Sza6862TTnYRNBK+to=; b=H+BnXXy/dmQHSMkSCSY1eivSXH05bl0TwguAr6QPccvZyDQonqloY3n47dsdjVW4MkRiqT/y2ACeSsYbXRqK6Tv284gqxi8FICZLkrriAezRgvbrPZS46bJs59oOoaYpcrqSfRl9GCdtzRENX+2Af/qGrhdu7zGgE3JLb7usgzqZ/xYRxDlKTTzEYYVfU8EjHL0hUSg4a8fMPwbAwS29hfhwf/jJlTp5RUaXmaZR1xYOLsADHNm8pXOeEEK1Xnxl+g6Zv5eP7Wd8rA3VTSBkIpG8QD0X0Cy5Zig0Hx/LdTKjWkq6uQj+qyKXKS8jFePN9M6oWazt4cm0c4AjO3nrZg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zGyA5WoL8o/VSs+wM00j7VcS+Sza6862TTnYRNBK+to=; b=lSWi4tMhVPi9N5blv7K50CS6MNk57ciKex90oadL+rHq23UCOLd4z4kmSTrVDKyxeHKbHmswht4auNZCd5AfRBF+byb33nHixhu2JV/FHtSLKYxKHmMfTjpmctk2GIpljRUjF09CSkZQ3aanBpS1y74XBLw0hOxT7snOe9Nw4uI= Received: from VI1PR0701MB6991.eurprd07.prod.outlook.com (2603:10a6:800:17d::22) by DB7PR07MB4651.eurprd07.prod.outlook.com (2603:10a6:5:2e::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4909.6; Tue, 18 Jan 2022 13:20:54 +0000 Received: from VI1PR0701MB6991.eurprd07.prod.outlook.com ([fe80::8c5e:f395:67c0:a223]) by VI1PR0701MB6991.eurprd07.prod.outlook.com ([fe80::8c5e:f395:67c0:a223%4]) with mapi id 15.20.4909.007; Tue, 18 Jan 2022 13:20:54 +0000 From: "Bocci, Matthew (Nokia - GB)" To: "mpls@ietf.org" Thread-Topic: Recent comments on draft-bocci-mpls-miad-adi-requirements-00 Thread-Index: AQHYDG14jPWsd9LXAUOVIc1obtVwEg== Date: Tue, 18 Jan 2022 13:20:54 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4edfca0e-b6e4-4c36-9ddf-08d9da855b1f x-ms-traffictypediagnostic: DB7PR07MB4651:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SKicVhZwtHiAVmatSLtgy2loTRcqzns4Iio6/P8nfrmA+dK8tSl1mEGVzJV1HOPi49Dy5Fu+g96+ZtDKkYDodknJEcoGWeGMPuArEnQbcdZk4E+824XYk8Tu2F63cZ+ATJFmWGNUMD7ioX1qjGSG31aB/NxnIMM5glpesKjGROSiV6Hp+RwMmXcm+rMA70ZsV1jmKOJCG3xnx9trXWrq1adVwnCDRTcUda+V9jWtqi4CHT86z2z+EHd4cJ67JSxLB0jH/E6TF2nc94l449/12GfIrywHK2qjMf+4KxJhB8bzxs2qRksTwjxh4Jvvyvax67EfCSQGZIV8p0hlXU8LryqT+eLMCRUe8NSEhLMTSkRoxgz4+MVOnXLeEiSg7mfs4BHeQaw4/++RwjUB0xr5ACte8+HEzRWLhGNarZYxKJH8eTiP9CSmJuHhnwizEQXN29Mu/aam2FYo8MSp1t7vCa1mftKoy6wf1ecFlV1MRAH9aSg9F48aarBF8pDiU7d7u8I54ZuAnR4JY7QnCYBMSShOPMek9SZW6cqAmlLynmpcjv8VTyuO/eldVYn0BUpE+j7+7MaaL7A0rHtd6SQtYB/G+Ieb+pPyAbZq/h8Cds7kS03M9DbhXeVGYYuFUmzxnokRWPanz+KJUkXqQ9BgeGSwIBvOUB41qnFgQ/+STxyeOu048OcFfXUkCAAnvF3oWYSucLWnVIYJNyVVBHSGWQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0701MB6991.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(76116006)(66946007)(316002)(6916009)(66556008)(7696005)(6506007)(86362001)(8676002)(8936002)(4744005)(64756008)(9686003)(91956017)(66446008)(66476007)(122000001)(38100700002)(26005)(186003)(5660300002)(33656002)(52536014)(508600001)(38070700005)(82960400001)(2906002)(83380400001)(71200400001)(55016003)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?rugQvAt0uQ5gruYB7/bTsifu6gvXlxEUcWfFRPb8YCTFx27srsIk6bu26fyK?= =?us-ascii?Q?hX38l1homJcS7RO0415vtIBsGOnrGiDWIBLebcZEJGXYFr9+aSzWCpuXpcNR?= =?us-ascii?Q?6N/vZbaOThj67hZtS6GNi+9hkJbrKO8Ympk4JiD5LfFpAC3pEvIV+HnhbsdG?= =?us-ascii?Q?gG5Enb1cgcL3zlgDYHI+RHfGpeqFxwGLwE15HJbbBMwPYWjSqhLz7zDbGU9N?= =?us-ascii?Q?wFiUlE2iTakNe1L6i7bmkN7pVYLlrAxQbFN+ATzRekBvopsO8voNEOr1SCq/?= =?us-ascii?Q?FEShMAcuAyZGHkOqtmsV43FI5PwowxBB0PVYevADQrw4oVFjPNYK5mtpTwk1?= =?us-ascii?Q?6SI5u82ATHR07m6qs7rIfgy/Dzjw6ZO/A3z9kEug9teS6e2qWW2HL31HyjIh?= =?us-ascii?Q?dlSFgeJzOSnWqP/nicH0GlZRtWsPsSsj/hDfFDUcy8LWlnkAujl6F12T2TzX?= =?us-ascii?Q?g0ALDN/p2FhCwAEFDhSW5rjQ9xiVqY0WmSfK4hXdMGo4ge9MpYW2zGhD5sQy?= =?us-ascii?Q?sNx2dWOY1okjemSKBc12j6QOQK+bYIbiLSLkVICFP4tzYqigNXdhhySY4dbZ?= =?us-ascii?Q?IG4lQL4DIXrVy5+ODyfdttz675R0qo/6Y+7/zh8JZ1i0zsvOQcXZwCP01Z5b?= =?us-ascii?Q?F6+mT1Sczv+pRNa5K/7fMfyvJHgEuHcgiM8f1IpeSl/330GoEdUQTfQnbouT?= =?us-ascii?Q?2+YSR2uCekDJIqRBJ2PvBJz7Gyjj3CXNlq11oS2AgCUJ882YetfEMXvInqZ9?= =?us-ascii?Q?ClWCqNxhUfEAf6dYDLF44EHzRyQAwV82MT33BkJY5pThpAPjzxOdNrGRmWuO?= =?us-ascii?Q?x3zfQ1UHmxPTUpQBQA5+aAjmAfU7CS1sfp++JH4KHjAxeJSnLz25iUP8f6Gy?= =?us-ascii?Q?nrjLrj0LUMeaTqXAO54boLoraiF95AbxujCb5Dx5ZX5CZ7800MxJFRnOAgPY?= =?us-ascii?Q?iOV7XTZYb4u9Nd4RQbdHceCmqwtVRUCvO5LzzYX7YnNF83JjMUucNDeWE7Lf?= =?us-ascii?Q?2oAa/xl2V+QX0x5oel9ZMu4l3M9GiWYIgIwOcCKQk9skJGyjIhACXpu+tZ5p?= =?us-ascii?Q?5g2V+khm1O1/CXI81XdGvzp+xo5/EHGj9P3kr0wY8svwUpQvB6DBqz54xQsu?= =?us-ascii?Q?F3uqDDvKN8kjY5IY1/bjiIC3z8S1E9E+Idt8DWlP6aHyfRfpumIMdfKLoXg3?= =?us-ascii?Q?Ze1d5otQ19ohNfAukHB5JgzDzNWGXDftTmgChX+/jjXaFY7/vB/I9/1LyAVs?= =?us-ascii?Q?w6XImX2CMkhivOTFjQaw+OZi8uo5xmQlyvn+9SHlxY9uTE2974aJK4FXM8x7?= =?us-ascii?Q?uquvpEY34JjcnshndkF7C+C+pTnyJBPfeW7Ph2uqI5FiLpEU2H7i9oazVK65?= =?us-ascii?Q?kAVMv61c7BLc7VpfKd68UBNlGYgZK0xn5HEf8oiggQDjZVxYgDXC6t6N1bnq?= =?us-ascii?Q?qbVu1HI9DNeFE8tHIrLtxJZmGEfO/Ge3ICn6KEUwPdnsAyHBb42feiaMJmV1?= =?us-ascii?Q?cu2PYGfYPze2U9KNb6wNFx0MMfnK20UjUquvbCx1Qvf33fvWhRiGYYA0iuAz?= =?us-ascii?Q?UyEai3LleXq0g5YzIXwx1xAE8wCfsjwbCSSV/m+jev4DPPS8Z3G7/A1dpevk?= =?us-ascii?Q?G7qj8MPz09/gXqfl99gB2bc=3D?= Content-Type: multipart/alternative; boundary="_000_VI1PR0701MB6991342F7D6B8631BBA80259EB589VI1PR0701MB6991_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR0701MB6991.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4edfca0e-b6e4-4c36-9ddf-08d9da855b1f X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2022 13:20:54.3002 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 99qmS1twC3TsdR1CsYI5+UhXqq+xWKk/+KOAJ6Y1oZ9XLFRb5pMUVPagriQGS3taSDWIUoT6Dd/zJA43uOAklw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4651 Archived-At: Subject: [mpls] Recent comments on draft-bocci-mpls-miad-adi-requirements-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: Tue, 18 Jan 2022 13:20:58 -0000 --_000_VI1PR0701MB6991342F7D6B8631BBA80259EB589VI1PR0701MB6991_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you to everyone who has reviewed the MIAD requirements draft. Stewart= and I have incorporated comments received by email into the version on the= MPLS GitHub, and provided some initial responses. Please let me know if y= ou have sent comments and we have accidentally missed them. We plan to revise the draft in the next week or so to address these comment= s received so far. Best regards Matthew --_000_VI1PR0701MB6991342F7D6B8631BBA80259EB589VI1PR0701MB6991_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you to everyone who has reviewed the MIAD requ= irements draft. Stewart and I have incorporated comments received by email = into the version on the MPLS GitHub,  and provided some initial respon= ses. Please let me know if you have sent comments and we have accidentally missed them.

 

We plan to revise the draft in the next week or so t= o address these comments received so far.

 

Best regards

 

Matthew

--_000_VI1PR0701MB6991342F7D6B8631BBA80259EB589VI1PR0701MB6991_-- From nobody Wed Jan 19 00:32:28 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1EE3A1350; Wed, 19 Jan 2022 00:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zzSRKHzuoKw; Wed, 19 Jan 2022 00:32:21 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89AF73A1018; Wed, 19 Jan 2022 00:32:21 -0800 (PST) Received: from fraeml740-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JdzLF3XTgz67bS0; Wed, 19 Jan 2022 16:28:21 +0800 (CST) Received: from dggpemm100002.china.huawei.com (7.185.36.179) by fraeml740-chm.china.huawei.com (10.206.15.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 19 Jan 2022 09:32:17 +0100 Received: from dggpemm500002.china.huawei.com (7.185.36.229) by dggpemm100002.china.huawei.com (7.185.36.179) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 19 Jan 2022 16:32:16 +0800 Received: from dggpemm500002.china.huawei.com ([7.185.36.229]) by dggpemm500002.china.huawei.com ([7.185.36.229]) with mapi id 15.01.2308.021; Wed, 19 Jan 2022 16:32:16 +0800 From: Mach Chen To: "mpls@ietf.org" CC: "mpls-chairs@ietf.org" Thread-Topic: MPLS Open DT meeting (January 20) cancelled Thread-Index: AdgNDmw+Q+E2JbZtSd67DBu8u3moTQ== Date: Wed, 19 Jan 2022 08:32:16 +0000 Message-ID: <77586a5382ab4b10a70394b00b7bd2a6@huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.110.46.250] 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 Open DT meeting (January 20) cancelled 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, 19 Jan 2022 08:32:27 -0000 Hi all, Because the chairs will not be available to host the MPLS Open DT meeting o= n this Thursday (January 20), the meeting is cancelled. Best regards, Mach Chen (MPLS WG Secretary) From nobody Thu Jan 20 07:41:10 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3DA3A166D for ; Thu, 20 Jan 2022 07:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=opensourcerouting-org.20210112.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 zbPR_Gm5-hmb for ; Thu, 20 Jan 2022 07:41:03 -0800 (PST) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 5B9AF3A166F for ; Thu, 20 Jan 2022 07:41:02 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id cx27so30603734edb.1 for ; Thu, 20 Jan 2022 07:41:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opensourcerouting-org.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=K3755F97xd+kPKczjQsLzuW8WQcdccfvxprravLc70c=; b=YozNMJFYATts/7cHErHfbN5Z3r9xD6YNbWjjGXruez4qwmuH4fFNpXZn5IToROTk9e +S/I3XAHlFVEIJQjaET6n7z6dqt9TWJC1sF8u9jtFznZwY4yISUyqhGrR6dpxYDepxIE itCM9ug1DQB1BP5u5AoXngqa9Ydc1g7sD4V52y9PNA75Ljy5y/ZuBDCsmpWwGbnv1B7n WIRsCa4oimv8eUU1R/La9UxUUTm8rbchsczm2YMS93Qxf7NOb9ayHYyWEq1fnJ7Ar++M M3DSz3xPe53TvK25+hbSikYy1uks7KEXVLUX2/hp5FoZOyFPzy/zKL9hfIZqE5fbFtsQ IfUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=K3755F97xd+kPKczjQsLzuW8WQcdccfvxprravLc70c=; b=hvGKTfihRbbimydyP3xaA67gj9CKWUPL08VelQ4fCUGYixhoAoLHEm/EfQecetFlGf L0or4RRAWqRwDfLqEpEfZPj3uRUZ3SkxyYycD24jMQoNJjpDk+miEXoQR4WQ7LjZkrdh fFJPMY24u/px5QUwbt3dFJ/BNILhri9jofSLqW6yv+4QjuyOgnIEmgG+FyN4mWr6QS+z dp8tSnHQxX1frZke+/7Pz2XpB5dKbMWp5qrNSvaxz0WM0VYMsMdSq9ubz2QCNQy1Xtia i7iIQgzgO0kQ8nvzz894wIgYKW0Es0WCRJQ54i5jRK+U7oDNZmeNep1+GXSNLfGXGtaF DChw== X-Gm-Message-State: AOAM532+KpiVkYQACV3ScQ6F9E3I5TMKNkR+b1Zal3G8xLhFbs12oKhx LdG2mV4Tveb4+Wlwt6oXRcV/RlOXKjQNaZO3QUrIwCQUofVOFCGq X-Google-Smtp-Source: ABdhPJxbC1Hwe4/h1SyCKqCiicd7FJQkWndimL0nWet808xapnwswtaLMGnZqMKUo9eF4RPid/cFB5bJlAoHPTmgNFA= X-Received: by 2002:a05:6402:5291:: with SMTP id en17mr11897437edb.256.1642693259712; Thu, 20 Jan 2022 07:40:59 -0800 (PST) MIME-Version: 1.0 From: Renato Westphal Date: Thu, 20 Jan 2022 12:40:48 -0300 Message-ID: To: draft-ietf-mpls-ldp-yang.all@ietf.org, mpls@ietf.org Content-Type: multipart/alternative; boundary="00000000000038730f05d605543d" Archived-At: Subject: [mpls] Review of draft-ietf-mpls-ldp-yang-09 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, 20 Jan 2022 15:41:08 -0000 --00000000000038730f05d605543d Content-Type: text/plain; charset="UTF-8" Hi all, I've implemented the ietf-mpls-ldp YANG module recently and I thought it would be a good idea to provide some feedback to the module authors. Overall I think the current module hierarchy is really good, it captures exactly what one should expect from an LDP implementation. I couldn't think of anything that is missing. I also liked the split between a base module and an extended one. I only have a few points/questions to make: 1) I find the "adjacency-flag-base" identity (and the ones derived from it) to be confusing: identity adjacency-flag-base { description "Base type for adjacency flags."; } identity adjacency-flag-active { base adjacency-flag-base; description "This adjacency is configured and actively created."; } identity adjacency-flag-passive { base adjacency-flag-base; description "This adjacency is not configured and passively accepted."; } The way I see it, no adjacency can be explicitly configured -- they are all created dynamically upon receipt of hello packets. Targeted neighbors, on the other hand, can be either configured explicitly or created on demand (upon receipt of hello packets with the 'R' bit set -- "Request Send Targeted Hellos"). So wouldn't it be better to move the active/passive attribute from adjacencies to targeted neighbors? 2) I think the following state leaf is problematic for targeted adjacencies: leaf interface { type if:interface-ref; description "Interface for this adjacency."; } The reason being that it's theoretically possible for one adjacency to receive hello packets from the same targeted neighbor on multiple different interfaces. 3) In some parts of the module tree, there are adjacency lists indexed like this: +--ro ldp:hello-adjacency* [local-address adjacent-address] +--ro ldp:local-address inet:ipv4-address +--ro ldp:adjacent-address inet:ipv4-address One problem is that it's perfectly possible to have two different adjacencies with the same local and adjacent addresses, one being a link adjacency and the other an extended adjacency. Adding an "adjacency-type" key would probably be necessary to guarantee disambiguation in such cases. Also, it'd be good to clarify whether the local-address leaf refers to the hello's source address or to the advertised transport address (when it's present). 4) I wonder if the following leaf is necessary: leaf lsr-id { type rt-types:router-id; description "Specify the value to act as the LDP LSR ID. If this attribute is not specified, LDP uses the router ID as determined by the system."; } Shouldn't the router-id leaf from the ietf-routing module be enough for this purpose? 5) I'd like to know what's the rationale behind the following presence container: container address-families { description "Per-vrf per-af params."; container ipv4 { presence "Present if IPv4 is enabled."; [...] } } Since not having that container explicitly enabled in the configuration won't prevent an LDPv4 neighborship to be formed, wouldn't a regular non-presence container be enough here? The "presence" statement doesn't seem to add any meaning to the existence of the container. Also, the "per-vrf" comment in the description seems unnecessary. 6) I have one question about configuration precedence. Here's an example configuration: "control-plane-protocol": [ { "type": "ietf-mpls-ldp:mpls-ldp", "name": "main", "ietf-mpls-ldp:mpls-ldp": { "global": { [snip] }, "discovery": { "interfaces": { [snip] }, "targeted": { "hello-accept": { "enabled": true }, "address-families": { "ipv4": { "target": [ { "adjacent-address": "1.1.1.1", "enabled": false } ] } } } } } } ] In that configuration, the "1.1.1.1" targeted neighbor is explicitly configured and disabled. Also, the global "hello-accept" setting is enabled. When a hello packet from "1.1.1.1" is received, should a dynamic targeted neighbor be created for it? I think the answer boils down to whether the targeted neighbor configuration applies to dynamic targeted neighbors as well. Also, having the ability to configure custom hello timers for targeted neighbors could be useful for some operators. 7) I think some timer ranges are too restrictive. Example: leaf hello-holdtime { type uint16 { range 15..3600; } [snip] } leaf hello-interval { type uint16 { range 5..1200; } [snip] } While a hello holdtime of 15 seconds is a sane default, I don't think we should prohibit the operator from configuring smaller values. The OSPF and IS-IS modules, for instance, use rt-types:timer-value-seconds16 for leafs like these. 8) A couple of trivial typo fixes: * Page 30: s/On or more flags/One or more flags/ * Page 30: s/extended discoveris/extended discoveries/ * Page 42: s/since the the state/since the state/ * Page 42: s/interface's counters/peer's counters/ * Page 54: s/targettted adjacency/targeted adjacency/ Regards, -- Renato Westphal --00000000000038730f05d605543d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+SGkgYWxsLDxicj48YnI+SSYjMzk7dmUgaW1wbGVtZW50ZWQgdGhlIGll dGYtbXBscy1sZHAgWUFORyBtb2R1bGUgcmVjZW50bHkgYW5kIEkgdGhvdWdodCBpdCB3b3VsZCBi ZSBhIGdvb2QgaWRlYSB0byBwcm92aWRlIHNvbWUgZmVlZGJhY2sgdG8gdGhlIG1vZHVsZSBhdXRo b3JzLjxicj48YnI+T3ZlcmFsbCBJIHRoaW5rIHRoZSBjdXJyZW50IG1vZHVsZSBoaWVyYXJjaHkg aXMgcmVhbGx5IGdvb2QsIGl0IGNhcHR1cmVzIGV4YWN0bHkgd2hhdCBvbmUgc2hvdWxkIGV4cGVj dCBmcm9tIGFuIExEUCBpbXBsZW1lbnRhdGlvbi4gSSBjb3VsZG4mIzM5O3QgdGhpbmsgb2YgYW55 dGhpbmcgdGhhdCBpcyBtaXNzaW5nLiBJIGFsc28gbGlrZWQgdGhlIHNwbGl0IGJldHdlZW4gYSBi YXNlIG1vZHVsZSBhbmQgYW4gZXh0ZW5kZWQgb25lLjxicj48YnI+SSBvbmx5IGhhdmUgYSBmZXcg cG9pbnRzL3F1ZXN0aW9ucyB0byBtYWtlOjxicj48YnI+MSkgSSBmaW5kIHRoZSAmcXVvdDthZGph Y2VuY3ktZmxhZy1iYXNlJnF1b3Q7IGlkZW50aXR5IChhbmQgdGhlIG9uZXMgZGVyaXZlZCBmcm9t IGl0KSB0byBiZSBjb25mdXNpbmc6PGJyPjxicj7CoCBpZGVudGl0eSBhZGphY2VuY3ktZmxhZy1i YXNlIHs8YnI+wqAgwqAgZGVzY3JpcHRpb24gJnF1b3Q7QmFzZSB0eXBlIGZvciBhZGphY2VuY3kg ZmxhZ3MuJnF1b3Q7Ozxicj7CoCB9PGJyPsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgPGJyPsKgIGlkZW50aXR5IGFkamFjZW5j eS1mbGFnLWFjdGl2ZSB7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDxicj7CoCDCoCBiYXNlIGFkamFjZW5jeS1mbGFn LWJhc2U7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgPGJyPsKgIMKgIGRlc2NyaXB0aW9uIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgPGJyPsKgIMKgIMKgICZxdW90O1RoaXMg YWRqYWNlbmN5IGlzIGNvbmZpZ3VyZWQgYW5kIGFjdGl2ZWx5IGNyZWF0ZWQuJnF1b3Q7OyDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDxicj7CoCB9IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgPGJyPsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgPGJyPsKg IGlkZW50aXR5IGFkamFjZW5jeS1mbGFnLXBhc3NpdmUgeyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDxicj7CoCDCoCBi YXNlIGFkamFjZW5jeS1mbGFnLWJhc2U7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgPGJyPsKgIMKgIGRl c2NyaXB0aW9uIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgPGJyPsKg IMKgIMKgICZxdW90O1RoaXMgYWRqYWNlbmN5IGlzIG5vdCBjb25maWd1cmVkIGFuZCBwYXNzaXZl bHkgYWNjZXB0ZWQuJnF1b3Q7OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDxicj7CoCB9PGJyPjxi cj5UaGUgd2F5IEkgc2VlIGl0LCBubyBhZGphY2VuY3kgY2FuIGJlIGV4cGxpY2l0bHkgY29uZmln dXJlZCAtLSB0aGV5IGFyZSBhbGwgY3JlYXRlZCBkeW5hbWljYWxseSB1cG9uIHJlY2VpcHQgb2Yg aGVsbG8gcGFja2V0cy48YnI+PGJyPlRhcmdldGVkIG5laWdoYm9ycywgb24gdGhlIG90aGVyIGhh bmQsIGNhbiBiZSBlaXRoZXIgY29uZmlndXJlZCBleHBsaWNpdGx5IG9yIGNyZWF0ZWQgb24gZGVt YW5kICh1cG9uIHJlY2VpcHQgb2YgaGVsbG8gcGFja2V0cyB3aXRoIHRoZSAmIzM5O1ImIzM5OyBi aXQgc2V0IC0tICZxdW90O1JlcXVlc3QgU2VuZCBUYXJnZXRlZCBIZWxsb3MmcXVvdDspLiBTbyB3 b3VsZG4mIzM5O3QgaXQgYmUgYmV0dGVyIHRvIG1vdmUgdGhlIGFjdGl2ZS9wYXNzaXZlIGF0dHJp YnV0ZSBmcm9tIGFkamFjZW5jaWVzIHRvIHRhcmdldGVkIG5laWdoYm9ycz88YnI+PGJyPjIpIEkg dGhpbmsgdGhlIGZvbGxvd2luZyBzdGF0ZSBsZWFmIGlzIHByb2JsZW1hdGljIGZvciB0YXJnZXRl ZCBhZGphY2VuY2llczo8YnI+PGJyPsKgIGxlYWYgaW50ZXJmYWNlIHs8YnI+wqAgwqAgdHlwZSBp ZjppbnRlcmZhY2UtcmVmOzxicj7CoCDCoCBkZXNjcmlwdGlvbiAmcXVvdDtJbnRlcmZhY2UgZm9y IHRoaXMgYWRqYWNlbmN5LiZxdW90Ozs8YnI+wqAgwqB9PGJyPjxicj5UaGUgcmVhc29uIGJlaW5n IHRoYXQgaXQmIzM5O3MgdGhlb3JldGljYWxseSBwb3NzaWJsZSBmb3Igb25lIGFkamFjZW5jeSB0 byByZWNlaXZlIGhlbGxvIHBhY2tldHMgZnJvbSB0aGUgc2FtZSB0YXJnZXRlZCBuZWlnaGJvciBv biBtdWx0aXBsZSBkaWZmZXJlbnQgaW50ZXJmYWNlcy48YnI+PGJyPjMpIEluIHNvbWUgcGFydHMg b2YgdGhlIG1vZHVsZSB0cmVlLCB0aGVyZSBhcmUgYWRqYWNlbmN5IGxpc3RzIGluZGV4ZWQgbGlr ZSB0aGlzOjxicj48YnI+wqAgKy0tcm8gbGRwOmhlbGxvLWFkamFjZW5jeSogW2xvY2FsLWFkZHJl c3MgYWRqYWNlbnQtYWRkcmVzc108YnI+wqAgwqAgwqArLS1ybyBsZHA6bG9jYWwtYWRkcmVzcyDC oCDCoCDCoCBpbmV0OmlwdjQtYWRkcmVzczxicj7CoCDCoCDCoCstLXJvIGxkcDphZGphY2VudC1h ZGRyZXNzIMKgIMKgaW5ldDppcHY0LWFkZHJlc3M8YnI+PGJyPk9uZSBwcm9ibGVtIGlzIHRoYXQg aXQmIzM5O3MgcGVyZmVjdGx5IHBvc3NpYmxlIHRvIGhhdmUgdHdvIGRpZmZlcmVudCBhZGphY2Vu Y2llcyB3aXRoIHRoZSBzYW1lIGxvY2FsIGFuZCBhZGphY2VudCBhZGRyZXNzZXMsIG9uZSBiZWlu ZyBhIGxpbmsgYWRqYWNlbmN5IGFuZCB0aGUgb3RoZXIgYW4gZXh0ZW5kZWQgYWRqYWNlbmN5LiBB ZGRpbmcgYW4gJnF1b3Q7YWRqYWNlbmN5LXR5cGUmcXVvdDsga2V5IHdvdWxkIHByb2JhYmx5IGJl IG5lY2Vzc2FyeSB0byBndWFyYW50ZWUgZGlzYW1iaWd1YXRpb24gaW4gc3VjaCBjYXNlcy48YnI+ PGJyPkFsc28sIGl0JiMzOTtkIGJlIGdvb2QgdG8gY2xhcmlmeSB3aGV0aGVyIHRoZSBsb2NhbC1h ZGRyZXNzIGxlYWYgcmVmZXJzIHRvIHRoZSBoZWxsbyYjMzk7cyBzb3VyY2UgYWRkcmVzcyBvciB0 byB0aGUgYWR2ZXJ0aXNlZCB0cmFuc3BvcnQgYWRkcmVzcyAod2hlbiBpdCYjMzk7cyBwcmVzZW50 KS48YnI+PGJyPjQpIEkgd29uZGVyIGlmIHRoZSBmb2xsb3dpbmcgbGVhZiBpcyBuZWNlc3Nhcnk6 PGJyPjxicj7CoCBsZWFmIGxzci1pZCB7PGJyPsKgIMKgIHR5cGUgcnQtdHlwZXM6cm91dGVyLWlk Ozxicj7CoCDCoCBkZXNjcmlwdGlvbjxicj7CoCDCoCDCoCAmcXVvdDtTcGVjaWZ5IHRoZSB2YWx1 ZSB0byBhY3QgYXMgdGhlIExEUCBMU1IgSUQuPGJyPsKgIMKgIMKgIMKgSWYgdGhpcyBhdHRyaWJ1 dGUgaXMgbm90IHNwZWNpZmllZCwgTERQIHVzZXMgdGhlIHJvdXRlcjxicj7CoCDCoCDCoCDCoElE IGFzIGRldGVybWluZWQgYnkgdGhlIHN5c3RlbS4mcXVvdDs7PGJyPsKgIH08YnI+PGJyPlNob3Vs ZG4mIzM5O3QgdGhlIHJvdXRlci1pZCBsZWFmIGZyb20gdGhlIGlldGYtcm91dGluZyBtb2R1bGUg YmUgZW5vdWdoIGZvciB0aGlzIHB1cnBvc2U/PGJyPjxicj41KSBJJiMzOTtkIGxpa2UgdG8ga25v dyB3aGF0JiMzOTtzIHRoZSByYXRpb25hbGUgYmVoaW5kIHRoZSBmb2xsb3dpbmcgcHJlc2VuY2Ug Y29udGFpbmVyOjxicj48YnI+wqAgY29udGFpbmVyIGFkZHJlc3MtZmFtaWxpZXMgezxicj7CoCDC oCBkZXNjcmlwdGlvbjxicj7CoCDCoCDCoCAmcXVvdDtQZXItdnJmIHBlci1hZiBwYXJhbXMuJnF1 b3Q7Ozxicj7CoCDCoCBjb250YWluZXIgaXB2NCB7PGJyPsKgIMKgIMKgIHByZXNlbmNlPGJyPsKg IMKgIMKgIMKgICZxdW90O1ByZXNlbnQgaWYgSVB2NCBpcyBlbmFibGVkLiZxdW90Ozs8YnI+wqAg wqAgwqAgWy4uLl08YnI+wqAgwqAgfTxicj7CoCB9PGJyPjxicj5TaW5jZSBub3QgaGF2aW5nIHRo YXQgY29udGFpbmVyIGV4cGxpY2l0bHkgZW5hYmxlZCBpbiB0aGUgY29uZmlndXJhdGlvbiB3b24m IzM5O3QgcHJldmVudCBhbiBMRFB2NCBuZWlnaGJvcnNoaXAgdG8gYmUgZm9ybWVkLCB3b3VsZG4m IzM5O3QgYSByZWd1bGFyIG5vbi1wcmVzZW5jZSBjb250YWluZXIgYmUgZW5vdWdoIGhlcmU/IFRo ZSAmcXVvdDtwcmVzZW5jZSZxdW90OyBzdGF0ZW1lbnQgZG9lc24mIzM5O3Qgc2VlbSB0byBhZGQg YW55IG1lYW5pbmcgdG8gdGhlIGV4aXN0ZW5jZSBvZiB0aGUgY29udGFpbmVyLjxicj48YnI+QWxz bywgdGhlICZxdW90O3Blci12cmYmcXVvdDsgY29tbWVudCBpbiB0aGUgZGVzY3JpcHRpb24gc2Vl bXMgdW5uZWNlc3NhcnkuPGJyPjxicj42KSBJIGhhdmUgb25lIHF1ZXN0aW9uIGFib3V0IGNvbmZp Z3VyYXRpb24gcHJlY2VkZW5jZS4gSGVyZSYjMzk7cyBhbiBleGFtcGxlIGNvbmZpZ3VyYXRpb246 PGJyPjxicj7CoCDCoCDCoCAmcXVvdDtjb250cm9sLXBsYW5lLXByb3RvY29sJnF1b3Q7OiBbPGJy PsKgIMKgIMKgIMKgIHs8YnI+wqAgwqAgwqAgwqAgwqAgJnF1b3Q7dHlwZSZxdW90OzogJnF1b3Q7 aWV0Zi1tcGxzLWxkcDptcGxzLWxkcCZxdW90Oyw8YnI+wqAgwqAgwqAgwqAgwqAgJnF1b3Q7bmFt ZSZxdW90OzogJnF1b3Q7bWFpbiZxdW90Oyw8YnI+wqAgwqAgwqAgwqAgwqAgJnF1b3Q7aWV0Zi1t cGxzLWxkcDptcGxzLWxkcCZxdW90Ozogezxicj7CoCDCoCDCoCDCoCDCoCDCoCAmcXVvdDtnbG9i YWwmcXVvdDs6IHs8YnI+wqAgwqAgwqAgwqAgwqAgwqAgwqAgW3NuaXBdPGJyPsKgIMKgIMKgIMKg IMKgIMKgIH0sPGJyPsKgIMKgIMKgIMKgIMKgIMKgICZxdW90O2Rpc2NvdmVyeSZxdW90Ozogezxi cj7CoCDCoCDCoCDCoCDCoCDCoCDCoCAmcXVvdDtpbnRlcmZhY2VzJnF1b3Q7OiB7PGJyPsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIFtzbmlwXTxicj7CoCDCoCDCoCDCoCDCoCDCoCDCoCB9LDxicj7C oCDCoCDCoCDCoCDCoCDCoCDCoCAmcXVvdDt0YXJnZXRlZCZxdW90Ozogezxicj7CoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCAmcXVvdDtoZWxsby1hY2NlcHQmcXVvdDs6IHs8YnI+wqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgJnF1b3Q7ZW5hYmxlZCZxdW90OzogdHJ1ZTxicj7CoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB9LDxicj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmcXVvdDthZGRyZXNzLWZh bWlsaWVzJnF1b3Q7OiB7PGJyPsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZxdW90O2lwdjQm cXVvdDs6IHs8YnI+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJnF1b3Q7dGFyZ2V0JnF1 b3Q7OiBbPGJyPsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHs8YnI+wqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJnF1b3Q7YWRqYWNlbnQtYWRkcmVzcyZxdW90Ozog JnF1b3Q7MS4xLjEuMSZxdW90Oyw8YnI+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgJnF1b3Q7ZW5hYmxlZCZxdW90OzogZmFsc2U8YnI+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgfTxicj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBdPGJyPsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIH08YnI+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfTxicj7CoCDC oCDCoCDCoCDCoCDCoCDCoCB9PGJyPsKgIMKgIMKgIMKgIMKgIMKgIH08YnI+wqAgwqAgwqAgwqAg wqAgfTxicj7CoCDCoCDCoCDCoCB9PGJyPsKgIMKgIMKgIF08YnI+PGJyPkluIHRoYXQgY29uZmln dXJhdGlvbiwgdGhlICZxdW90OzEuMS4xLjEmcXVvdDsgdGFyZ2V0ZWQgbmVpZ2hib3IgaXMgZXhw bGljaXRseSBjb25maWd1cmVkIGFuZCBkaXNhYmxlZC4gQWxzbywgdGhlIGdsb2JhbCAmcXVvdDto ZWxsby1hY2NlcHQmcXVvdDsgc2V0dGluZyBpcyBlbmFibGVkLjxicj48YnI+V2hlbiBhIGhlbGxv IHBhY2tldCBmcm9tICZxdW90OzEuMS4xLjEmcXVvdDsgaXMgcmVjZWl2ZWQsIHNob3VsZCBhIGR5 bmFtaWMgdGFyZ2V0ZWQgbmVpZ2hib3IgYmUgY3JlYXRlZCBmb3IgaXQ/IEkgdGhpbmsgdGhlIGFu c3dlciBib2lscyBkb3duIHRvIHdoZXRoZXIgdGhlIHRhcmdldGVkIG5laWdoYm9yIGNvbmZpZ3Vy YXRpb24gYXBwbGllcyB0byBkeW5hbWljIHRhcmdldGVkIG5laWdoYm9ycyBhcyB3ZWxsLjxicj48 YnI+QWxzbywgaGF2aW5nIHRoZSBhYmlsaXR5IHRvIGNvbmZpZ3VyZSBjdXN0b20gaGVsbG8gdGlt ZXJzIGZvciB0YXJnZXRlZCBuZWlnaGJvcnMgY291bGQgYmUgdXNlZnVsIGZvciBzb21lIG9wZXJh dG9ycy48YnI+PGJyPjcpIEkgdGhpbmsgc29tZSB0aW1lciByYW5nZXMgYXJlIHRvbyByZXN0cmlj dGl2ZS4gRXhhbXBsZTo8YnI+PGJyPsKgIGxlYWYgaGVsbG8taG9sZHRpbWUgezxicj7CoCDCoCB0 eXBlIHVpbnQxNiB7PGJyPsKgIMKgIMKgIHJhbmdlIDE1Li4zNjAwOzxicj7CoCDCoCB9PGJyPsKg IMKgIFtzbmlwXTxicj7CoCB9PGJyPsKgIGxlYWYgaGVsbG8taW50ZXJ2YWwgezxicj7CoCDCoCB0 eXBlIHVpbnQxNiB7PGJyPsKgIMKgIMKgIHJhbmdlIDUuLjEyMDA7PGJyPsKgIMKgIH08YnI+wqAg wqAgW3NuaXBdPGJyPsKgIH08YnI+PGJyPldoaWxlIGEgaGVsbG8gaG9sZHRpbWUgb2YgMTUgc2Vj b25kcyBpcyBhIHNhbmUgZGVmYXVsdCwgSSBkb24mIzM5O3QgdGhpbmsgd2Ugc2hvdWxkIHByb2hp Yml0IHRoZSBvcGVyYXRvciBmcm9tIGNvbmZpZ3VyaW5nIHNtYWxsZXIgdmFsdWVzLjxicj48YnI+ VGhlIE9TUEYgYW5kIElTLUlTIG1vZHVsZXMsIGZvciBpbnN0YW5jZSwgdXNlIHJ0LXR5cGVzOnRp bWVyLXZhbHVlLXNlY29uZHMxNiBmb3IgbGVhZnMgbGlrZSB0aGVzZS48YnI+PGJyPjgpIEEgY291 cGxlIG9mIHRyaXZpYWwgdHlwbyBmaXhlczo8YnI+wqAgKiBQYWdlIDMwOiBzL09uIG9yIG1vcmUg ZmxhZ3MvT25lIG9yIG1vcmUgZmxhZ3MvPGJyPsKgICogUGFnZSAzMDogcy9leHRlbmRlZCBkaXNj b3ZlcmlzL2V4dGVuZGVkIGRpc2NvdmVyaWVzLzxicj7CoCAqIFBhZ2UgNDI6IHMvc2luY2UgdGhl IHRoZSBzdGF0ZS9zaW5jZSB0aGUgc3RhdGUvPGJyPsKgICogUGFnZSA0Mjogcy9pbnRlcmZhY2Um IzM5O3MgY291bnRlcnMvcGVlciYjMzk7cyBjb3VudGVycy88YnI+wqAgKiBQYWdlIDU0OiBzL3Rh cmdldHR0ZWQgYWRqYWNlbmN5L3RhcmdldGVkIGFkamFjZW5jeS88YnI+PGJyPlJlZ2FyZHMsPGJy Pi0tIDxicj5SZW5hdG8gV2VzdHBoYWw8L2Rpdj4NCg== --00000000000038730f05d605543d-- From nobody Thu Jan 20 08:24:54 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B708A3A17CD; Thu, 20 Jan 2022 08:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1k-3qVK_WU_V; Thu, 20 Jan 2022 08:24:50 -0800 (PST) Received: from mailgw1.uni-kl.de (mailgw1.uni-kl.de [IPv6:2001:638:208:120::220]) (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 DB72B3A17D4; Thu, 20 Jan 2022 08:24:44 -0800 (PST) Received: from mail.fg-networking.de (mail.fg-networking.de [IPv6:2001:638:208:cd01::23]) by mailgw1.uni-kl.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 20KGOd9S184736 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 Jan 2022 17:24:39 +0100 Received: from login.fg-networking.de (login.fg-networking.de [131.246.197.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.fg-networking.de (Postfix) with ESMTPS id 80DC32009B; Thu, 20 Jan 2022 17:24:30 +0100 (CET) Received: by login.fg-networking.de (Postfix, from userid 11002) id 11E54173; Thu, 20 Jan 2022 17:24:30 +0100 (CET) Date: Thu, 20 Jan 2022 17:24:30 +0100 From: Erik Auerswald To: Renato Westphal Cc: draft-ietf-mpls-ldp-yang.all@ietf.org, mpls@ietf.org Message-ID: <20220120162429.GE83846@fg-networking.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [mpls] Review of draft-ietf-mpls-ldp-yang-09 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, 20 Jan 2022 16:24:53 -0000 Hello Renato, On Thu, Jan 20, 2022 at 12:40:48PM -0300, Renato Westphal wrote: > [...] > 4) I wonder if the following leaf is necessary: > > leaf lsr-id { > type rt-types:router-id; > description > "Specify the value to act as the LDP LSR ID. > If this attribute is not specified, LDP uses the router > ID as determined by the system."; > } > > Shouldn't the router-id leaf from the ietf-routing module be enough for > this purpose? Many currently available routers allow to configure per-protocol and (if applicable) per-process router-id values. I would not like if implementing YANG based management would lose this capability. > [...] Best regards, Erik Auerswald -- Dipl.-Inform. Erik Auerswald Gesellschaft fr Fundamental Generic Networking mbH Geschftsfhrung: Volker Bauer, Jrg Mayer Gerichtsstand: Amtsgericht Kaiserslautern - HRB: 3630 From nobody Thu Jan 20 15:09:33 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFBB3A25A4; Thu, 20 Jan 2022 15:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=h8scqCKQ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=C93ofWwf 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 gy7v8Zw30uOR; Thu, 20 Jan 2022 15:09:26 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C9F3A25A3; Thu, 20 Jan 2022 15:09:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=61825; q=dns/txt; s=iport; t=1642720165; x=1643929765; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=PU0w/d4EoLFFrsWrGiTg1orZ7UQwSiFxtrlwMnxyO50=; b=h8scqCKQIWS5kkQAUQx1I+eJDEycZpuwQi4SyyX+DBWbzh4R/Ho+VSPu zJUPqIjySfNydF/ZpA+TsC/tw8wDWPDuZZ8XYbC9wfJYHYdNK2+f0m6zW WGyGrsp1+F+YLWqACtkfNu7ok+O3yFT5iITpo7LzJAuFmgET+dR6vgCcU k=; IronPort-PHdr: =?us-ascii?q?A9a23=3ACEJJHxzfIyHmq7vXCzPZngc9DxPP8534PQ8Qv?= =?us-ascii?q?5wgjb8GMqGu5I/rM0GX4/JxxETIUoPW57Mh6aLWvqnsVHZG7cOHt3YPI5BJX?= =?us-ascii?q?gUO3MMRmQFoCcWZCEr9efjtaSFyHMlLWFJ/uX+hNk0AE8flbFqUqXq3vlYv?= IronPort-Data: =?us-ascii?q?A9a23=3AgqNqMaDR66i3qhVW//Xhw5YqxClBgxIJ4kV8j?= =?us-ascii?q?S/XYbTApDN202cCz2VOCG2BM/aNMzDwLdFyPY218hgB7ZGBnIRlOVdlrnsFo?= =?us-ascii?q?1CmBibm6XV1Fqp7Vs+rBpWroHlPsoNOOrEsEOhuFiWG/k73auC6xZVB/fjgq?= =?us-ascii?q?oTUWbas1h9ZHWeIeA954f5Ss7ZRbrxA2LBVMCvV0T/GmPAzDXf+s9JC3s343?= =?us-ascii?q?IrYwP9nlKyaVDr1JTXSb9gT1LPVvyF94J7yuciMw3XErol8RoZWRs7Zx72/u?= =?us-ascii?q?2je5RpoVJWuk63wdQsBRbu60Qqm0yUNHfP9xEkZ4HVvjc7XN9JEAatToy+An?= =?us-ascii?q?dFvwf1GtIe7TkEiOaikdOE1AkYATHkuYfMfkFPACT3l2SCJ9GXDa3/36/RjE?= =?us-ascii?q?E9wOpcXks57G2hA6bkZJSwDKxWbg/nzxL6jD/hlgMtlJc3vFIISpn8myivWZ?= =?us-ascii?q?d48TJbKX6Li4sdV2iw3m9pFEOzZetYYbzUpaw7PCyCjkH9/5IkWhuykgDz0d?= =?us-ascii?q?CdV7QzTrqss6G+Vxwt0uIUB+eH9IrSiLfi5VG7Bzo4ew1nEPw=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AoACnpqMr2q2YZsBcT23155DYdb4zR+YMi2?= =?us-ascii?q?TDiHoRdfUFSKKlfp6V88jzjSWE9Ar5K0tQ5uxoWZPwD080kKQU3WB/B8bbYO?= =?us-ascii?q?CLghrMEGgm1/qe/9SCIVy+ygc+79YaT0EWMrSZZjIW4beYkWuF+pQbsaO6Gc?= =?us-ascii?q?uT9IDjJgJWPHhXgtZbnmFE42igYylLbTgDIaB8OIuX58JBqTblU28QdN6HCn?= =?us-ascii?q?4MWPWGj8HXlbr9CCR2RyIP2U2rt3eF+bT6Gx+X0lM1SDVU24ov9mDDjkjQ+r?= =?us-ascii?q?ijifem0RXRvlWjrKi+2eGRiOerNvb8zvT9GQ+czTpAo74RHYFqiQpF5d1HLm?= =?us-ascii?q?xayeUk7S1QZ/iboEmhAF1d6SGdqjUIlgxesEMLDTSj8CbeSQuTfkNhNyMJv/?= =?us-ascii?q?MrTvOSgXBQzO1UweZF2XmUuIFQCg6FlCPh58LQXxUvjUasp2E++NRjwkC3fL?= =?us-ascii?q?FuI4O5l7Zvtn+90a1wax7S+cQiCq1jHcvc7PFZfReTaG3YpHBmxJipUm4oFh?= =?us-ascii?q?mLT0AesojNugIm00xR3g8d3ogSj30A/JUyR91N4PnFKL1hkPVLQtUNZaxwCe?= =?us-ascii?q?8dSY+8C3DLQxjLLGWOSG6XWJ0vKjbIsdr68b817OaldNgBy4Yzgo3IVBdCuW?= =?us-ascii?q?s7ayvVeIWzNV1wg1nwqUmGLEHQI/Bllu5EU+fHNcjW2AW4OSQTr/c=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BeEwB46ulh/51dJa1RCR4BAQsSDII?= =?us-ascii?q?PC4EhMVYHd1o3MYRIg0cDhTmFDl2CJQOBE4l6hSeKaoEugSUDVAMIAQEBDQE?= =?us-ascii?q?BNQwEAQGBcIMVAheDQAIlNAkOAQIEAQEBEgEBBQEBAQIBBgSBCROFaA2GQgE?= =?us-ascii?q?BAQEDEhEKEwEBMAgPAgEGAhEDAQIhAQkCAgIfER0IAgQBEiKCYgGCDlcDLgE?= =?us-ascii?q?OkiWPNgGBOgKKH3qBMYEBgggBAQYEBIFKQYMCDQuCNwMGgTqDDoJ+VEoBAYc?= =?us-ascii?q?HJxyBSUSBFCgMEIIwNz6CIUIBAQIBgTFMBgeCazeCLpB4gS8dCQRDCAIEAlA?= =?us-ascii?q?rSAIVBAEJKx+SLkeDHYlGP4NBiW+RcWsKg0WKfI5dhXgFLqd0lkQgjGqDTZA?= =?us-ascii?q?rKggLDYRsAgQCBAUCDgEBBoFhO4FZcBU7KgGCPlEZD44gg3GEWTuFSnQCATU?= =?us-ascii?q?CAwMBCgEBAwmQOgEB?= X-IronPort-AV: E=Sophos;i="5.88,303,1635206400"; d="scan'208,217";a="970708461" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Jan 2022 23:09:24 +0000 Received: from mail.cisco.com (xbe-aln-002.cisco.com [173.36.7.17]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 20KN9OPF001085 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 20 Jan 2022 23:09:24 GMT Received: from xfe-aln-001.cisco.com (173.37.135.121) by xbe-aln-002.cisco.com (173.36.7.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 20 Jan 2022 17:09:24 -0600 Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 20 Jan 2022 17:09:23 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Thu, 20 Jan 2022 18:09:23 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mOvgXoXcAUpkGoL+8Sggev4RUIp1xDHD36rD0QtWGNuxVFR6b4UozDfpHedR9zP8qZ39thRTTQ2D1zyzMBtXgkBFntxjwVdc0ZPTKWIJbl0zjK11miQh73KZJE8FSBmgigDgBdhriSch+z2PxYVPcUp0hw2/5Uth3F+r/XkksQXuk6RE1bzlWK7cK6G/5Hd3BT8iPrlQKBo+O0l3GAKitv9YS4UtNFCIdWA3Khzs1HSxUpKqlP7Y1iKN1839+/WrNGK6YzJCC8/bGFCKvnVLfgoYyoWXyoNNn3CM+FAR645JrvsH3Kn0l6rUZUAgf2wYPC9cuAiKzSG6kajHQal0FQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PU0w/d4EoLFFrsWrGiTg1orZ7UQwSiFxtrlwMnxyO50=; b=W3JErDva1PsMlKero7pCI/22a9z6+H3Bmp8NnAFb3pm52wTuYB9ZR4+6KD40uxdqYP6C0kBsNYjZtGMfF96KY/sW8RhW5ZkK863TQAZ4LVTArhAhetN9MPq2DEHOyCvV1BP0+gsQUDio4iJXsqXXxnSXtEV1skQPuR3lbNhc/GN/0eXrru5sAn/EaSeqWKD84xzDpzaZGVD+LWf/Z0GieAp0iEnyeTGEZUHCsQvB8KKquH+Tfi+g2loNsSiCNE84decd/DXIBnMY/ErkgOu/TmPw0wmgWlNKq8tgXh1JI5AUNmPZgsVOCHv75R0P7jytXrdXHK7lBTRFwKCz6BIO4w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PU0w/d4EoLFFrsWrGiTg1orZ7UQwSiFxtrlwMnxyO50=; b=C93ofWwfMcLGgR7cxihrWxhs2Dwwck8IXH7lEzYuoUWgnAQxfANBnlonqgQHdF1ZHW/5Lxhd2Oc2LWl1KuYQh6++eMepU0ByYDGljlczCyYJt8T3IfVavimd86OfxM3DggzAT8lH1ab+WSoVmL1LHEbU55jLfxDZ8DuufVniNrk= Received: from BL0PR11MB3155.namprd11.prod.outlook.com (2603:10b6:208:68::10) by BL3PR11MB5716.namprd11.prod.outlook.com (2603:10b6:208:353::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4909.7; Thu, 20 Jan 2022 23:09:21 +0000 Received: from BL0PR11MB3155.namprd11.prod.outlook.com ([fe80::49d:4e1c:b62a:de9e]) by BL0PR11MB3155.namprd11.prod.outlook.com ([fe80::49d:4e1c:b62a:de9e%4]) with mapi id 15.20.4888.016; Thu, 20 Jan 2022 23:09:21 +0000 From: "Rajiv Asati (rajiva)" To: Renato Westphal , "draft-ietf-mpls-ldp-yang.all@ietf.org" , "mpls@ietf.org" Thread-Topic: Review of draft-ietf-mpls-ldp-yang-09 Thread-Index: AQHYDhQrUZaOfnMZ30KPpmTU93+QFKxsNYgA Date: Thu, 20 Jan 2022 23:09:21 +0000 Message-ID: <66F8F012-E804-49CE-8890-4941CC10AB61@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.57.22011101 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5bebe4e1-e305-4afb-a050-08d9dc69e47d x-ms-traffictypediagnostic: BL3PR11MB5716:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xLnsDaEyRaebJFE8m5JKKiKTqZLqz/ia3jdXJAbVAx05XdMrdxt4FsGvse2EvN0u0KqJxdHTbU0HlJfrtBYlApa93tKZw2NLcWIk/LrjWt13W5TgITXgdf4D+BZLNcvFRvlBDZOAjO6sOJvmcetlCS5E27JBy+YXhzy3OPxJuSteIoMx8NhVPhAzRUgz4Z83cyiab+WT1Bn0uSz+AnPRBuGbQ1maX6PuTmeHe1dBM4F6YZeOxKYz7w15SxsBu86NI284vxTA1JMaL2oaKfHhDdhDgrVGlZrFXfqBFjTd2Ju1BXkRYlSXd+Q96CAepb7TyOj5ThFelYoFumKSedm3ESHR3MTWYzgco3NHX44O0IRXwBSnhnqd57pPI8c+BqBz+fuHIfbIyLvgtKc6AzXPjB2/wan50T9LpYEqM/vK4fFXvVxE1PUlMeFey8uzflJFtcYqL/U/4RnDqeVtimxvBfq1teAlSE2R/y+DCuaM19+vqgFKYPOWgQhMxvGh8CTHQCyr1LUUoAi76eGfPERSbga/zsDVo5NehA9lPSkoBoIwmnYbXyQnmqkwsSQ441qPpYNiw7IrzknWvJnVeyfcrwL8m4dfZoqNmLM/aPKGSTSGDVCe1ev9pWrS/v2MuVHuq3Q5/gRETOm0j1KGMwQ0/id2JKjPR4Pod4fnVNjhDi1ZFKxmPxNsGpXXuglOmSqRVX4hySQmDAmDeab56FNxX0ZjkKWb2Tjt9T/ODycehz9OoRYvlMkKNonzA1sPGWMKVgfBUkmC0ROcmfj2w/FTkAjbB8A71WoFNhGudOPZJGmw6L9t/DLtQlJCzabq+ONA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3155.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(8936002)(2906002)(38100700002)(66556008)(166002)(66574015)(66476007)(76116006)(66446008)(9326002)(8676002)(508600001)(86362001)(66946007)(5660300002)(64756008)(71200400001)(53546011)(83380400001)(6506007)(316002)(6486002)(2616005)(966005)(33656002)(186003)(36756003)(122000001)(110136005)(38070700005)(6512007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bnpVaFF3ZDdtNmVlZzFGZDd2RmxmSG1EeU5uWCtyckVMUEo4V0VWMVV4UUJk?= =?utf-8?B?TUtDZGhML1lKSzdaZFBlSks0V1RZblF1eUgrN1NSUFBrc0hPN3JyNERCUHRp?= =?utf-8?B?UzdwbUNpVGk3czIwT1kzZ0ttT3FDTXk3cmlNRVpYNEFEYlFZNEN0amFoUFRu?= =?utf-8?B?WUlHK2FFQlhwQ1pNdXVDamZweDYyc01ScDJiUVJaZFhCQ01UTHZIRm9Sc2xR?= =?utf-8?B?SHYwMW0wNnJvRXpXTDlxOGMvZUg2MzJTOVBrd1dLTlpPZVJiWllydEFLYUZG?= =?utf-8?B?S1c5KzBGZG1TbzZ2WlNqUlZHTDYwSmdUQUZ5NHg4b1A4cnpyeSt6ZHpjcWVi?= =?utf-8?B?S0tBTWRjWkYrWjRrejVpb29mNlpZVHlVZDRpNWVvdjFHS0xvVGhtUEZLNHpK?= =?utf-8?B?ZjVWR0JNMXRrZDFkVU40cmRQWDd2M3BLMFZqRldtKy9sOExsdytnUGxlS3Vh?= =?utf-8?B?bkoyV1hDZ0NZaFY0eXhYbGVhRU9GVkpGWERQalErU0hzUmhzTStNRW4yeW1z?= =?utf-8?B?MFVXN0UxOEwrVGJEUmdqUUJyY0F6blBSOWplekx1TTRpZ2RiY0o5VVVrYk1w?= =?utf-8?B?bmpEMkp2UFUrTk1ucnZVNFZFZEJ1RnJlKytDVC9XSjVnNlBzT2JnRzdLa1dT?= =?utf-8?B?Nk44L2I3dWtBNCtKb1B2TUUzOEVzMWJ2R1EvZG8wNzFPQ0tsZk84MG42ZWhr?= =?utf-8?B?VjZHbHlWaXdieDI0SjZ6WWtwcWI5TjRycnhnWFVtcmFCbU15Nk5qS29OOHA0?= =?utf-8?B?bFB2TndGZFJNM1luMnNLSE13YmxHbGpEUlEvVG0wdWtjMkNuaFI3Zk9vTnJB?= =?utf-8?B?K0QvcVlWQkdtTkhDalpxbmpWQWpsaFNLa3crUkFLRzRHVktZUVN2cGhZOUE1?= =?utf-8?B?ZE1RaU5xcmFBZzM4ZkpubWV2dmt5UWlqbmQwam9SV1VZMUx0MWQzcWQ3QnRh?= =?utf-8?B?L2EzaHFpdXExTXNKUVFucVJKR0tpRmxpRlJzSWtNdmRvT210amF6TVdjSnpt?= =?utf-8?B?UUUwKzR3Q2lvOXpseXBBb1h2bDVmRE4xSkw4Ny80YzhYZFBDaVh0ZWtqZSt2?= =?utf-8?B?MFVLTTZmaFRTR2xkYm8yRks3WjZNc25PMEVrOU5DbFJOc3NweWZxMFVKSWps?= =?utf-8?B?TGFsemthK3dxVGU1TWVMaWxsR05jR255ODltZnNHaXhaNnVxSnJRVkNQckQz?= =?utf-8?B?dGxLenhpakpKV0VsMlhkNlA3T1JiMnZhN2QvdlNqY2NYN3M5ZURudUZzcjcw?= =?utf-8?B?UWh2dzV3N09wNlpJL2N0N0JhNENhckJNZytSaTdiZngyY0ZTWTB0aU5EQ2Nu?= =?utf-8?B?clR1RVVwY3I2VWlCVTdzODJPS0NrRzkrejczZVAvMzNSdko0STBPMzR4RVpT?= =?utf-8?B?QzdwdWxYVE5salBiTW5sMW5KWjdXdDBHUU1BM2c5Z1pKN1JNeW9tZnVIbHRI?= =?utf-8?B?Y0VCMUExZElGaUUvdGROYXduTjBtVDB0SENKR056RmNpUlFkZlBFTlFUcWU3?= =?utf-8?B?SW51dFRFaE9XczgzZkNJSzNrU2RaM3pQMVFWaGZ6S0ZGNzQwdDRXRExDNm5v?= =?utf-8?B?QnpoZkxCdTBrS3QvRHEySHc0UGVRY01WNUUxMmkxRXpBUXpBODljVWVsRXBO?= =?utf-8?B?YWY5QUliQTJmQlZRSXU1RkphbnJhUy9SM1BweFBIS0g3aUNMZExWRDl1ZGxO?= =?utf-8?B?QWJiTkllajdzWTkxa09BMDRINUR2aEo5Y0FVdGxnZFJ6cWZaeUJCdWQvaVNy?= =?utf-8?B?YzZBN3prVHVrMXhUMGxjcnhqNkJjbFZNdGZFVFcySkFzcUgzTEV5UThTWXRM?= =?utf-8?B?MDZGNDlUdlNsNWFrSmRqY1JkczZRQmd1a215TlA0QU9oOWRFREszVzFrSWo4?= =?utf-8?B?aW9DQ1Q1OGwxZjlpSHI2U3NCeUNUN0w5Rkt1SG9zcXZqbExrdDB0TjJjMEM3?= =?utf-8?B?SS95aEFnOWUzMEc3WDFKN0xQWlpLanNUbmU5ZkdqY0IwQ3hScjZJZDBrbSt1?= =?utf-8?B?SUJFMnJzVHdiOGRGS1RFRWlNTkhWaTJhSmVvdVBkS1NhSS82aUsxWi9vd3Qy?= =?utf-8?B?SXFjVE1YMGFLa283dHFnVjNUV3VWNTBOcEY1bEk5ZDArTzdjc3Rzb2pMS1lZ?= =?utf-8?B?ZDJoeHM5TDlBSmkySmQ3OU5tdEJ6YkVOK3VEOW1yQjNMMklvRXBQODI5MUxk?= =?utf-8?B?OU5BK0tXYW94c05UMU15aGVFYXBlcWhYdUdqQTljcmNJVGVRS3A0eW5VdmN0?= =?utf-8?B?ZTJiU2V1bEhGek1ubVp4Q2ZnM0l4OUpvMjNlVWdOeWp2bXJQMjk3S0NDZnBB?= =?utf-8?Q?JC/OxGVKLUdNCWxZvT?= Content-Type: multipart/alternative; boundary="_000_66F8F012E80449CE88904941CC10AB61ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3155.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5bebe4e1-e305-4afb-a050-08d9dc69e47d X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2022 23:09:21.1344 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yOJ194yVLo4B3Vz34VZHyTiqpF/+nW4s7ELQgphwUN1CeBB6B0H+c/cFwjmWIqBCBlaguu1QY7I+ND5F5piFPA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR11MB5716 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.17, xbe-aln-002.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [mpls] Review of draft-ietf-mpls-ldp-yang-09 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, 20 Jan 2022 23:09:31 -0000 --_000_66F8F012E80449CE88904941CC10AB61ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmVuYXRvLA0KDQpUaGFua3MgZm9yIHRoZSBmZWVkYmFjayB0byB0aGUgV0cgZG9jdW1lbnQu IFRoaXMgcmVhbGx5IGhlbHBzIHVzIHRvIGJ1aWxkIGEgc29saWQgc3BlYy4NCg0KMS4gWW91IGFy ZSByaWdodCBhYm91dCBhZGphY2VuY3kgY29uZmlndXJhdGlvbiAoUlcpIGFuZCBhZGphY2VuY3kg c3RhdGUgKFJPKS4gVGhlIHNwZWMgd2VsbCBjb3ZlcnMgYWxsIG9mIHRob3NlLg0KDQpUaGUgZmxh ZyB5b3UgcmVmZXJyZWQgdG8gaXMgZGVmaW5lZCBhcyBSZWFkT25seSAoUk8pIGZvciBvcGVyYXRp b25hbCBzdGF0ZSwgZXhhY3RseSBhcyB5b3UgcG9pbnRlZCBvdXQsIHRvIGNhcHR1cmUgdGhlIG5l aWdoYm9yIGJlaW5nIGFjdGl2ZSBvciBwYXNzaXZlLiBOb3QgZm9yIGNvbmZpZy4gSGVsbG8tYWRq YWNlbmNpZXMgYmVsb3cgaXMgYSBjb250YWluZXIsIGJ0dywgdGhhdCBpbmNsdWRlcyBib3RoIHR4 IGFuZCByeCBhZGphY2VuY2llcy4NCg0KICAgICAgICAgIHwgIHwgICAgIHwgIHwgICstLXJvIGhl bGxvLWFkamFjZW5jaWVzDQogICAgICAgICAgfCAgfCAgICAgfCAgfCAgfCAgKy0tcm8gaGVsbG8t YWRqYWNlbmN5KiBbYWRqYWNlbnQtYWRkcmVzc10NCg0KICAgICAgICAgIHwgICAgICAgIHwgIHwg ICAgICstLXJvIGZsYWcqICAgICAgICAgICAgICAgaWRlbnRpdHlyZWYNCjwgPg0KDQogICAgICAg ICBjb250YWluZXIgaGVsbG8tYWRqYWNlbmNpZXMgew0KICAgICAgICAgICAgICAg4oCmDQogICAg ICAgICAgICAgdXNlcyBsZHA6YWRqYWNlbmN5LXN0YXRlLWF0dHJpYnV0ZXM7DQoNCkNvbmZpZyAo UlcpIGZvciB0YXJnZXRlZCBuZWlnaGJvciBjb3ZlcnMgd2hhdCB5b3Ugc3VnZ2VzdGVkIHdlbGwg LQ0KICAgICAgICAgIHwgICstLXJ3IHRhcmdldGVkDQogICAgICAgICAgfCAgICAgKy0tcncgaGVs bG8taG9sZHRpbWU/ICAgICB1aW50MTYNCiAgICAgICAgICB8ICAgICArLS1ydyBoZWxsby1pbnRl cnZhbD8gICAgIHVpbnQxNg0KICAgICAgICAgIHwgICAgICstLXJ3IGhlbGxvLWFjY2VwdA0KICAg ICAgICAgIHwgICAgIHwgICstLXJ3IGVuYWJsZWQ/ICAgICAgICAgICAgICAgICBib29sZWFuDQog ICAgICAgICAgfCAgICAgfCAgKy0tcncgbGRwLWV4dDpuZWlnaGJvci1saXN0PyAgIG5laWdoYm9y LWxpc3QtcmVmDQoNCg0KDQoNCjIuICBUYXJnZXRlZCBuZWlnaGJvciBpcyBub3QgYm91bmQgdG8g YW4gaW50ZXJmYWNlIChwZXIgUkZDNTAzNiksIHNvIHRoYXQgaW50ZXJmYWNlIGxlYWYgeW91IHJl ZmVycmVkIHRvIGlzIGFjdHVhbGx5IG5vdCBwYXJ0IG9mIHRhcmdldGVkIGRpc2NvdmVyeSBjb250 YWluZXIsIHJhdGhlciBiYXNpYyBkaXNjb3ZlcnkgY29udGFpbmVyICh3aGljaCBpbmRlZWQgYWxs b3dzIGZvciBvbmUgb3IgbW9yZSBpbnRlcmZhY2VzIHBlciBuZWlnaGJvcikuDQoNCiAgICAgICAg IGNvbnRhaW5lciBoZWxsby1hZGphY2VuY2llcyB7DQogICAgICAgICAgIGNvbmZpZyBmYWxzZTsN CiAgICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICAiQ29udGFpbmluZyBhIGxpc3Qg b2YgSGVsbG8gYWRqYWNlbmNpZXMuIjsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg LiAuIC4gLiAuIC4NCiAgICAgICAgICAgICBsZWFmIGludGVyZmFjZSB7DQogICAgICAgICAgICAg ICB0eXBlIGlmOmludGVyZmFjZS1yZWY7DQogICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiSW50 ZXJmYWNlIGZvciB0aGlzIGFkamFjZW5jeS4iOw0KDQoNCg0KMy4gWW91IGFyZSByaWdodCB0aGF0 IGEgbmVpZ2hib3IgY2FuIGJlIGRpc2NvdmVyZWQgdmlhIGJvdGggYmFzaWMgYW5kIGV4dGVuZGVk IGRpc2NvdmVyeS4gV2hhdCB5b3UgcG9pbnQgb3V0IGlzIHdlbGwgY292ZXJlZCBpbiB0aGUgdHJl ZSBpbiB0d28gZGlzdGluY3QgcGxhY2VzIOKAkyBvbmUgZm9yIGJhc2ljIGFuZCB0aGUgb3RoZXIg Zm9yIGV4dGVuZGVkL3RhcmdldGVkLiBQbHMgc2VlIHNlY3Rpb24gNi4xIGFuZCBmaWd1cmUgNS4N Cg0KICAgICAgICAgKy0tcncgZGlzY292ZXJ5DQogICAgICAgICAgICArLS1ydyBpbnRlcmZhY2Vz DQogICAgICAgICAgICB8ICArLS1ydyBpbnRlcmZhY2UqIFtpbnRlcmZhY2VdDQogICAgICAgICAg ICB8ICAgICArLS1ydyBhZGRyZXNzLWZhbWlsaWVzDQogICAgICAgICAgICB8ICAgICAgICArLS1y dyBpcHY0DQogICAgICAgICAgICB8ICAgICAgICAgICArLS1ybyBoZWxsby1hZGphY2VuY2llcw0K ICAgICAgICAgICAgfCAgICAgICAgICAgICAgKy0tcm8gaGVsbG8tYWRqYWNlbmNpZXMqIFthZGph Y2VudC1hZGRyZXNzXQ0KICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgKy0tcm8gYWRqYWNl bnQtYWRkcmVzcw0KICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgLiAuIC4gLg0KICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgLiAuIC4gLg0KICAgICAgICAgICAgKy0tcncg dGFyZ2V0ZWQNCiAgICAgICAgICAgICAgICstLXJ3IGFkZHJlc3MtZmFtaWxpZXMNCiAgICAgICAg ICAgICAgICAgICstLXJ3IGlwdjQNCiAgICAgICAgICAgICAgICAgICAgICstLXJvIGhlbGxvLWFk amFjZW5jaWVzDQogICAgICAgICAgICAgICAgICAgICAgICArLS1ybyBoZWxsby1hZGphY2VuY2ll cyoNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICBbbG9jYWwtYWRk cmVzcyBhZGphY2VudC1hZGRyZXNzXQ0KICAgICAgICAgICAgICAgICAgICAgICAgKy0tcm8gbG9j YWwtYWRkcmVzcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tcm8gYWRqYWNlbnQtYWRk cmVzcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLiAuIC4gLg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLiAuIC4gLg0KDQoNCg0KDQpBbHNvLCBwYWdlIzUyIGNsYXJpZmll cyB0aGUgZm9sbG93aW5nIGZvciBsb2NhbC1hZGRyZXNzIC0NCg0KICAgICAgICAgICAgICAgICAg IGxlYWYgbG9jYWwtYWRkcmVzcyB7DQogICAgICAgICAgICAgICAgICAgICB0eXBlIGluZXQ6aXB2 NC1hZGRyZXNzOw0KICAgICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAg ICAgICAgICAgICAgIlRoZSBsb2NhbCBhZGRyZXNzIHVzZWQgYXMgdGhlIHNvdXJjZSBhZGRyZXNz IHRvDQogICAgICAgICAgICAgICAgICAgICAgICBzZW5kIHRhcmdldGVkIEhlbGxvIG1lc3NhZ2Vz Lg0KICAgICAgICAgICAgICAgICAgICAgICAgSWYgdGhlIHZhbHVlIGlzIG5vdCBzcGVjaWZpZWQs IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgdHJhbnNwb3J0LWFkZHJlc3MgaXMgdXNlZCBh cyB0aGUgc291cmNlDQogICAgICAgICAgICAgICAgICAgICAgICBhZGRyZXNzLiI7DQoNCg0KNC4g R29vZCBwb2ludCBhYm91dCBhIGdvb2Qg4oCcZGVwbG95bWVudOKAnSBwcmFjdGljZSBmb3IgZGlm ZmVyZW50IHByb3RvY29scyB0byBsZXZlcmFnZSB0aGUgc2FtZSByb3V0ZXItaWQuIEhvd2V2ZXIs IExEUCBwcm90b2NvbCAoUkZDNTAzNikgc3BlY2lmaWVzIExTUi1JRCBhbmQgYWxsb3dzIGl0IHRv IGJlIGRpZmZlcmVudCwgaWYvYXMgbmVlZGVkIChpbmRlcGVuZGVudCBvZiB0aGF0LCBvbmUgY2Fu IGNob29zZSBkaWZmZXJlbnQgTFNSIElEIGZvciBkaWZmZXJlbnQgVlJGcyBvbiBhIG5vZGUpLg0K DQpUaGFua2Z1bGx5LCB0aGUgdGVhbSBhZ3JlZWQgdG8ga2VlcCB0aGUgZGVmYXVsdCBhbG9uZyB0 aGUgbGluZSBvZiB3aGF0IHlvdSBwb2ludGVkLg0KDQoNCjUuIFdlbGwsIHRoaW5rIG9mIElQdjYt b25seSBub2RlLCB3aGljaCB1bmZvcnR1bmF0ZWx5IG5lZWRzIHRvIGhhdmUgSVB2NCBmb3IgT09C IG1hbmFnZW1lbnQgYWNjZXNzLiBUaGF0IHdvdWxkIHJlc3VsdCBpbiBMRFAgSVB2NCBBRkkgYmVp bmcgZW5hYmxlZCBieSBkZWZhdWx0LCBhbmQgaGVuY2UsIHdvdWxkIG5lZWQgdG8gYmUgZXhwbGlj aXRseSBkaXNhYmxlZCB2aWEgdGhpcyBjb250YWluZXIuDQoNCkkgd2lsbCBsZXQgbXkgY28tYXV0 aG9ycyBhZGQgZnVydGhlciBjbGFyaWZpY2F0aW9uLg0KDQo2LiBZZXMsIGl0IGRvZXMgYXBwbHku DQpBbmQgIHRoYXQgY29uZmlndXJhdGlvbiB3aWxsIGFsbG93IGZvciB0aGUgdGFyZ2V0ZWQgYWRq YWNlbmN5IHRvIGJlIGNyZWF0ZWQgZm9yIDEuMS4xLjEsIGJ1dCBwZWVyaW5nIHJlbGF0aW9uc2hp cCB3aWxsIGJlIGRlbmllZC4gIElmIHRoZSBpbnRlbnQgaXMgdG8gbm90IGxldCB0aGUgdGFyZ2V0 ZWQgYWRqYWNlbmN5IGJlIGNyZWF0ZWQsIHRoZW4gcG9saWN5IGNvdWxkIGJlIGNyZWF0ZWQgdG8g ZGVueSAxLjEuMS4xLg0KDQpXcnQgY3VzdG9tIGhlbGxvL2hvbGQgdGltZXJzIHBlciB0YXJnZXRl ZCBuZWlnaGJvcnMsIEFGQUlLLCBSRkM1MDM2IGRvZXNu4oCZdCBzcGVjaWZ5IHRoYXQsIG5vciBk byBhbnkgb2YgdGhlIGltcGxlbWVudGF0aW9ucy4NCk9ubHkgY3VzdG9tIGhlbGxvL2hvbGQgdGlt ZXJzIGdsb2JhbCBjb25maWcuDQoNCg0KNy4gQUZBSUssIHRoaXMgaXMgYmVjYXVzZSBvZiBSRkM1 MDM2IHRoYXQgc3BlY2lmaWVzIDVzIHRvIGJlIHRoZSBsb3dlc3QgaGVsbG8gaW50ZXJ2YWwuICDw n5iKDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjNTAzNiNzZWN0 aW9uLTMuNS4yDQoNCg0KOC4gVGhhbmtzIGZvciByZXZpZXdpbmcgc28gZGlsaWdlbnRseSBhbmQg cG9pbnRpbmcgdGhlc2UgdHlwb3Mgb3V0Lg0KVGhhbmtmdWxseSwgb3VyIGFtYXppbmcgUkZDIEVk aXRvciB0ZWFtIGhhcyBmaXhlZCBhbGwgb2YgdGhlbSAoSSBqdXN0IGNoZWNrZWQgdGhlaXIgdmVy c2lvbikgZXhjZXB0IGludGVyZmFjZeKAmXMgY291bnRlcnMgKHdpdGhpbiB0aGUgc3RhdGlzdGlj cyBjb250YWluZXIpLCB3aGljaCBJIGJlbGlldmUgaXMgY29ycmVjdCAoc2luY2UgaXQgaXMgYWJv dXQgdGhlIG5vZGUsIG5vdCBhYm91dCB0aGUgcGVlcikuDQoNCi0tDQpDaGVlcnMsDQpSYWppdiBB c2F0aQ0KQ1RPLCBDWCBBUEpDDQoNCuKAnEZvY3VzIG9uIHdoYXQgd2UgY2FuIGRvIHdpdGggd2hh dCB3ZSBoYXZlLCBub3QgdGhlIG90aGVyIHdheSBhcm91bmQu4oCdDQoNCg0KRnJvbTogUmVuYXRv IFdlc3RwaGFsIDxyZW5hdG9Ab3BlbnNvdXJjZXJvdXRpbmcub3JnPg0KRGF0ZTogVGh1cnNkYXks IEphbnVhcnkgMjAsIDIwMjIgYXQgMTA6NDEgQU0NClRvOiAiZHJhZnQtaWV0Zi1tcGxzLWxkcC15 YW5nLmFsbEBpZXRmLm9yZyIgPGRyYWZ0LWlldGYtbXBscy1sZHAteWFuZy5hbGxAaWV0Zi5vcmc+ LCAibXBsc0BpZXRmLm9yZyIgPG1wbHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZXZpZXcgb2YgZHJh ZnQtaWV0Zi1tcGxzLWxkcC15YW5nLTA5DQpSZXNlbnQtRnJvbTogPGFsaWFzLWJvdW5jZXNAaWV0 Zi5vcmc+DQpSZXNlbnQtVG86IEhpbWFuc2h1IFNoYWggPGhzaGFoQGNpZW5hLmNvbT4sIDxzZXNh bGVAanVuaXBlci5uZXQ+LCBSYWppdiBBc2F0aSA8cmFqaXZhQGNpc2NvLmNvbT4sIDxza3JhemFA Y2lzY28uY29tPiwgPHRzYWFkLm5ldEBnbWFpbC5jb20+LCBKb2huIFNjdWRkZXIgPGpnc0BqdW5p cGVyLm5ldD4sIDxqZXNjaWEuY2hlbnhpYUBodWF3ZWkuY29tPiwgPHh1ZmVuZy5saXUuaWV0ZkBn bWFpbC5jb20+LCAiTi5MZXltYW5uQHRlbGVrb20uZGUiIDxuLmxleW1hbm5AdGVsZWtvbS5kZT4s IEFsdmFybyBSZXRhbmEgPGFyZXRhbmEuaWV0ZkBnbWFpbC5jb20+LCA8bWFydGluLnZpZ291cmV1 eEBub2tpYS5jb20+LCBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU+LCAnTWFjaCBDaGVuJyA8bWFj aC5jaGVuQGh1YXdlaS5jb20+LCBERUJPUkFIIEJSVU5HQVJEIDxkYjM1NDZAYXR0LmNvbT4NClJl c2VudC1EYXRlOiBUaHVyc2RheSwgSmFudWFyeSAyMCwgMjAyMiBhdCAxMDo0MSBBTQ0KDQpIaSBh bGwsDQoNCkkndmUgaW1wbGVtZW50ZWQgdGhlIGlldGYtbXBscy1sZHAgWUFORyBtb2R1bGUgcmVj ZW50bHkgYW5kIEkgdGhvdWdodCBpdCB3b3VsZCBiZSBhIGdvb2QgaWRlYSB0byBwcm92aWRlIHNv bWUgZmVlZGJhY2sgdG8gdGhlIG1vZHVsZSBhdXRob3JzLg0KDQpPdmVyYWxsIEkgdGhpbmsgdGhl IGN1cnJlbnQgbW9kdWxlIGhpZXJhcmNoeSBpcyByZWFsbHkgZ29vZCwgaXQgY2FwdHVyZXMgZXhh Y3RseSB3aGF0IG9uZSBzaG91bGQgZXhwZWN0IGZyb20gYW4gTERQIGltcGxlbWVudGF0aW9uLiBJ IGNvdWxkbid0IHRoaW5rIG9mIGFueXRoaW5nIHRoYXQgaXMgbWlzc2luZy4gSSBhbHNvIGxpa2Vk IHRoZSBzcGxpdCBiZXR3ZWVuIGEgYmFzZSBtb2R1bGUgYW5kIGFuIGV4dGVuZGVkIG9uZS4NCg0K SSBvbmx5IGhhdmUgYSBmZXcgcG9pbnRzL3F1ZXN0aW9ucyB0byBtYWtlOg0KDQoxKSBJIGZpbmQg dGhlICJhZGphY2VuY3ktZmxhZy1iYXNlIiBpZGVudGl0eSAoYW5kIHRoZSBvbmVzIGRlcml2ZWQg ZnJvbSBpdCkgdG8gYmUgY29uZnVzaW5nOg0KDQogIGlkZW50aXR5IGFkamFjZW5jeS1mbGFnLWJh c2Ugew0KICAgIGRlc2NyaXB0aW9uICJCYXNlIHR5cGUgZm9yIGFkamFjZW5jeSBmbGFncy4iOw0K ICB9DQoNCiAgaWRlbnRpdHkgYWRqYWNlbmN5LWZsYWctYWN0aXZlIHsNCiAgICBiYXNlIGFkamFj ZW5jeS1mbGFnLWJhc2U7DQogICAgZGVzY3JpcHRpb24NCiAgICAgICJUaGlzIGFkamFjZW5jeSBp cyBjb25maWd1cmVkIGFuZCBhY3RpdmVseSBjcmVhdGVkLiI7DQogIH0NCg0KICBpZGVudGl0eSBh ZGphY2VuY3ktZmxhZy1wYXNzaXZlIHsNCiAgICBiYXNlIGFkamFjZW5jeS1mbGFnLWJhc2U7DQog ICAgZGVzY3JpcHRpb24NCiAgICAgICJUaGlzIGFkamFjZW5jeSBpcyBub3QgY29uZmlndXJlZCBh bmQgcGFzc2l2ZWx5IGFjY2VwdGVkLiI7DQogIH0NCg0KVGhlIHdheSBJIHNlZSBpdCwgbm8gYWRq YWNlbmN5IGNhbiBiZSBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgLS0gdGhleSBhcmUgYWxsIGNyZWF0 ZWQgZHluYW1pY2FsbHkgdXBvbiByZWNlaXB0IG9mIGhlbGxvIHBhY2tldHMuDQoNClRhcmdldGVk IG5laWdoYm9ycywgb24gdGhlIG90aGVyIGhhbmQsIGNhbiBiZSBlaXRoZXIgY29uZmlndXJlZCBl eHBsaWNpdGx5IG9yIGNyZWF0ZWQgb24gZGVtYW5kICh1cG9uIHJlY2VpcHQgb2YgaGVsbG8gcGFj a2V0cyB3aXRoIHRoZSAnUicgYml0IHNldCAtLSAiUmVxdWVzdCBTZW5kIFRhcmdldGVkIEhlbGxv cyIpLiBTbyB3b3VsZG4ndCBpdCBiZSBiZXR0ZXIgdG8gbW92ZSB0aGUgYWN0aXZlL3Bhc3NpdmUg YXR0cmlidXRlIGZyb20gYWRqYWNlbmNpZXMgdG8gdGFyZ2V0ZWQgbmVpZ2hib3JzPw0KDQoyKSBJ IHRoaW5rIHRoZSBmb2xsb3dpbmcgc3RhdGUgbGVhZiBpcyBwcm9ibGVtYXRpYyBmb3IgdGFyZ2V0 ZWQgYWRqYWNlbmNpZXM6DQoNCiAgbGVhZiBpbnRlcmZhY2Ugew0KICAgIHR5cGUgaWY6aW50ZXJm YWNlLXJlZjsNCiAgICBkZXNjcmlwdGlvbiAiSW50ZXJmYWNlIGZvciB0aGlzIGFkamFjZW5jeS4i Ow0KICAgfQ0KDQpUaGUgcmVhc29uIGJlaW5nIHRoYXQgaXQncyB0aGVvcmV0aWNhbGx5IHBvc3Np YmxlIGZvciBvbmUgYWRqYWNlbmN5IHRvIHJlY2VpdmUgaGVsbG8gcGFja2V0cyBmcm9tIHRoZSBz YW1lIHRhcmdldGVkIG5laWdoYm9yIG9uIG11bHRpcGxlIGRpZmZlcmVudCBpbnRlcmZhY2VzLg0K DQozKSBJbiBzb21lIHBhcnRzIG9mIHRoZSBtb2R1bGUgdHJlZSwgdGhlcmUgYXJlIGFkamFjZW5j eSBsaXN0cyBpbmRleGVkIGxpa2UgdGhpczoNCg0KICArLS1ybyBsZHA6aGVsbG8tYWRqYWNlbmN5 KiBbbG9jYWwtYWRkcmVzcyBhZGphY2VudC1hZGRyZXNzXQ0KICAgICArLS1ybyBsZHA6bG9jYWwt YWRkcmVzcyAgICAgICBpbmV0OmlwdjQtYWRkcmVzcw0KICAgICArLS1ybyBsZHA6YWRqYWNlbnQt YWRkcmVzcyAgICBpbmV0OmlwdjQtYWRkcmVzcw0KDQpPbmUgcHJvYmxlbSBpcyB0aGF0IGl0J3Mg cGVyZmVjdGx5IHBvc3NpYmxlIHRvIGhhdmUgdHdvIGRpZmZlcmVudCBhZGphY2VuY2llcyB3aXRo IHRoZSBzYW1lIGxvY2FsIGFuZCBhZGphY2VudCBhZGRyZXNzZXMsIG9uZSBiZWluZyBhIGxpbmsg YWRqYWNlbmN5IGFuZCB0aGUgb3RoZXIgYW4gZXh0ZW5kZWQgYWRqYWNlbmN5LiBBZGRpbmcgYW4g ImFkamFjZW5jeS10eXBlIiBrZXkgd291bGQgcHJvYmFibHkgYmUgbmVjZXNzYXJ5IHRvIGd1YXJh bnRlZSBkaXNhbWJpZ3VhdGlvbiBpbiBzdWNoIGNhc2VzLg0KDQpBbHNvLCBpdCdkIGJlIGdvb2Qg dG8gY2xhcmlmeSB3aGV0aGVyIHRoZSBsb2NhbC1hZGRyZXNzIGxlYWYgcmVmZXJzIHRvIHRoZSBo ZWxsbydzIHNvdXJjZSBhZGRyZXNzIG9yIHRvIHRoZSBhZHZlcnRpc2VkIHRyYW5zcG9ydCBhZGRy ZXNzICh3aGVuIGl0J3MgcHJlc2VudCkuDQoNCjQpIEkgd29uZGVyIGlmIHRoZSBmb2xsb3dpbmcg bGVhZiBpcyBuZWNlc3Nhcnk6DQoNCiAgbGVhZiBsc3ItaWQgew0KICAgIHR5cGUgcnQtdHlwZXM6 cm91dGVyLWlkOw0KICAgIGRlc2NyaXB0aW9uDQogICAgICAiU3BlY2lmeSB0aGUgdmFsdWUgdG8g YWN0IGFzIHRoZSBMRFAgTFNSIElELg0KICAgICAgIElmIHRoaXMgYXR0cmlidXRlIGlzIG5vdCBz cGVjaWZpZWQsIExEUCB1c2VzIHRoZSByb3V0ZXINCiAgICAgICBJRCBhcyBkZXRlcm1pbmVkIGJ5 IHRoZSBzeXN0ZW0uIjsNCiAgfQ0KDQpTaG91bGRuJ3QgdGhlIHJvdXRlci1pZCBsZWFmIGZyb20g dGhlIGlldGYtcm91dGluZyBtb2R1bGUgYmUgZW5vdWdoIGZvciB0aGlzIHB1cnBvc2U/DQoNCjUp IEknZCBsaWtlIHRvIGtub3cgd2hhdCdzIHRoZSByYXRpb25hbGUgYmVoaW5kIHRoZSBmb2xsb3dp bmcgcHJlc2VuY2UgY29udGFpbmVyOg0KDQogIGNvbnRhaW5lciBhZGRyZXNzLWZhbWlsaWVzIHsN CiAgICBkZXNjcmlwdGlvbg0KICAgICAgIlBlci12cmYgcGVyLWFmIHBhcmFtcy4iOw0KICAgIGNv bnRhaW5lciBpcHY0IHsNCiAgICAgIHByZXNlbmNlDQogICAgICAgICJQcmVzZW50IGlmIElQdjQg aXMgZW5hYmxlZC4iOw0KICAgICAgWy4uLl0NCiAgICB9DQogIH0NCg0KU2luY2Ugbm90IGhhdmlu ZyB0aGF0IGNvbnRhaW5lciBleHBsaWNpdGx5IGVuYWJsZWQgaW4gdGhlIGNvbmZpZ3VyYXRpb24g d29uJ3QgcHJldmVudCBhbiBMRFB2NCBuZWlnaGJvcnNoaXAgdG8gYmUgZm9ybWVkLCB3b3VsZG4n dCBhIHJlZ3VsYXIgbm9uLXByZXNlbmNlIGNvbnRhaW5lciBiZSBlbm91Z2ggaGVyZT8gVGhlICJw cmVzZW5jZSIgc3RhdGVtZW50IGRvZXNuJ3Qgc2VlbSB0byBhZGQgYW55IG1lYW5pbmcgdG8gdGhl IGV4aXN0ZW5jZSBvZiB0aGUgY29udGFpbmVyLg0KDQpBbHNvLCB0aGUgInBlci12cmYiIGNvbW1l bnQgaW4gdGhlIGRlc2NyaXB0aW9uIHNlZW1zIHVubmVjZXNzYXJ5Lg0KDQo2KSBJIGhhdmUgb25l IHF1ZXN0aW9uIGFib3V0IGNvbmZpZ3VyYXRpb24gcHJlY2VkZW5jZS4gSGVyZSdzIGFuIGV4YW1w bGUgY29uZmlndXJhdGlvbjoNCg0KICAgICAgImNvbnRyb2wtcGxhbmUtcHJvdG9jb2wiOiBbDQog ICAgICAgIHsNCiAgICAgICAgICAidHlwZSI6ICJpZXRmLW1wbHMtbGRwOm1wbHMtbGRwIiwNCiAg ICAgICAgICAibmFtZSI6ICJtYWluIiwNCiAgICAgICAgICAiaWV0Zi1tcGxzLWxkcDptcGxzLWxk cCI6IHsNCiAgICAgICAgICAgICJnbG9iYWwiOiB7DQogICAgICAgICAgICAgIFtzbmlwXQ0KICAg ICAgICAgICAgfSwNCiAgICAgICAgICAgICJkaXNjb3ZlcnkiOiB7DQogICAgICAgICAgICAgICJp bnRlcmZhY2VzIjogew0KICAgICAgICAgICAgICAgIFtzbmlwXQ0KICAgICAgICAgICAgICB9LA0K ICAgICAgICAgICAgICAidGFyZ2V0ZWQiOiB7DQogICAgICAgICAgICAgICAgImhlbGxvLWFjY2Vw dCI6IHsNCiAgICAgICAgICAgICAgICAgICJlbmFibGVkIjogdHJ1ZQ0KICAgICAgICAgICAgICAg IH0sDQogICAgICAgICAgICAgICAgImFkZHJlc3MtZmFtaWxpZXMiOiB7DQogICAgICAgICAgICAg ICAgICAiaXB2NCI6IHsNCiAgICAgICAgICAgICAgICAgICAgInRhcmdldCI6IFsNCiAgICAgICAg ICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAiYWRqYWNlbnQtYWRkcmVz cyI6ICIxLjEuMS4xIiwNCiAgICAgICAgICAgICAgICAgICAgICAgICJlbmFibGVkIjogZmFsc2UN CiAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgICAgIF0NCiAgICAgICAg ICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgIH0NCiAgICAgICAg ICAgIH0NCiAgICAgICAgICB9DQogICAgICAgIH0NCiAgICAgIF0NCg0KSW4gdGhhdCBjb25maWd1 cmF0aW9uLCB0aGUgIjEuMS4xLjEiIHRhcmdldGVkIG5laWdoYm9yIGlzIGV4cGxpY2l0bHkgY29u ZmlndXJlZCBhbmQgZGlzYWJsZWQuIEFsc28sIHRoZSBnbG9iYWwgImhlbGxvLWFjY2VwdCIgc2V0 dGluZyBpcyBlbmFibGVkLg0KDQpXaGVuIGEgaGVsbG8gcGFja2V0IGZyb20gIjEuMS4xLjEiIGlz IHJlY2VpdmVkLCBzaG91bGQgYSBkeW5hbWljIHRhcmdldGVkIG5laWdoYm9yIGJlIGNyZWF0ZWQg Zm9yIGl0PyBJIHRoaW5rIHRoZSBhbnN3ZXIgYm9pbHMgZG93biB0byB3aGV0aGVyIHRoZSB0YXJn ZXRlZCBuZWlnaGJvciBjb25maWd1cmF0aW9uIGFwcGxpZXMgdG8gZHluYW1pYyB0YXJnZXRlZCBu ZWlnaGJvcnMgYXMgd2VsbC4NCg0KQWxzbywgaGF2aW5nIHRoZSBhYmlsaXR5IHRvIGNvbmZpZ3Vy ZSBjdXN0b20gaGVsbG8gdGltZXJzIGZvciB0YXJnZXRlZCBuZWlnaGJvcnMgY291bGQgYmUgdXNl ZnVsIGZvciBzb21lIG9wZXJhdG9ycy4NCg0KNykgSSB0aGluayBzb21lIHRpbWVyIHJhbmdlcyBh cmUgdG9vIHJlc3RyaWN0aXZlLiBFeGFtcGxlOg0KDQogIGxlYWYgaGVsbG8taG9sZHRpbWUgew0K ICAgIHR5cGUgdWludDE2IHsNCiAgICAgIHJhbmdlIDE1Li4zNjAwOw0KICAgIH0NCiAgICBbc25p cF0NCiAgfQ0KICBsZWFmIGhlbGxvLWludGVydmFsIHsNCiAgICB0eXBlIHVpbnQxNiB7DQogICAg ICByYW5nZSA1Li4xMjAwOw0KICAgIH0NCiAgICBbc25pcF0NCiAgfQ0KDQpXaGlsZSBhIGhlbGxv IGhvbGR0aW1lIG9mIDE1IHNlY29uZHMgaXMgYSBzYW5lIGRlZmF1bHQsIEkgZG9uJ3QgdGhpbmsg d2Ugc2hvdWxkIHByb2hpYml0IHRoZSBvcGVyYXRvciBmcm9tIGNvbmZpZ3VyaW5nIHNtYWxsZXIg dmFsdWVzLg0KDQpUaGUgT1NQRiBhbmQgSVMtSVMgbW9kdWxlcywgZm9yIGluc3RhbmNlLCB1c2Ug cnQtdHlwZXM6dGltZXItdmFsdWUtc2Vjb25kczE2IGZvciBsZWFmcyBsaWtlIHRoZXNlLg0KDQo4 KSBBIGNvdXBsZSBvZiB0cml2aWFsIHR5cG8gZml4ZXM6DQogICogUGFnZSAzMDogcy9PbiBvciBt b3JlIGZsYWdzL09uZSBvciBtb3JlIGZsYWdzLw0KICAqIFBhZ2UgMzA6IHMvZXh0ZW5kZWQgZGlz Y292ZXJpcy9leHRlbmRlZCBkaXNjb3Zlcmllcy8NCiAgKiBQYWdlIDQyOiBzL3NpbmNlIHRoZSB0 aGUgc3RhdGUvc2luY2UgdGhlIHN0YXRlLw0KICAqIFBhZ2UgNDI6IHMvaW50ZXJmYWNlJ3MgY291 bnRlcnMvcGVlcidzIGNvdW50ZXJzLw0KICAqIFBhZ2UgNTQ6IHMvdGFyZ2V0dHRlZCBhZGphY2Vu Y3kvdGFyZ2V0ZWQgYWRqYWNlbmN5Lw0KDQpSZWdhcmRzLA0KLS0NClJlbmF0byBXZXN0cGhhbA0K --_000_66F8F012E80449CE88904941CC10AB61ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkOw0KCXBhbm9z ZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj MDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0 eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUmVuYXRvLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGFua3MgZm9yIHRoZSBmZWVkYmFjayB0byB0aGUgV0cgZG9jdW1lbnQuIFRoaXMgcmVhbGx5IGhl bHBzIHVzIHRvIGJ1aWxkIGEgc29saWQgc3BlYy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4g WW91IGFyZSByaWdodCBhYm91dCBhZGphY2VuY3kgY29uZmlndXJhdGlvbiAoUlcpIGFuZCBhZGph Y2VuY3kgc3RhdGUgKFJPKS4gVGhlIHNwZWMgd2VsbCBjb3ZlcnMgYWxsIG9mIHRob3NlLg0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBmbGFnIHlvdSByZWZlcnJlZCB0byBpcyBkZWZpbmVk IGFzIFJlYWRPbmx5IChSTykgZm9yIG9wZXJhdGlvbmFsIHN0YXRlLCBleGFjdGx5IGFzIHlvdSBw b2ludGVkIG91dCwgdG8gY2FwdHVyZSB0aGUgbmVpZ2hib3IgYmVpbmcgYWN0aXZlIG9yIHBhc3Np dmUuIE5vdCBmb3IgY29uZmlnLiBIZWxsby1hZGphY2VuY2llcyBiZWxvdyBpcyBhIGNvbnRhaW5l ciwgYnR3LCB0aGF0IGluY2x1ZGVzIGJvdGggdHgNCiBhbmQgcnggYWRqYWNlbmNpZXMuIDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgKy0tcm8gaGVsbG8tYWRqYWNlbmNpZXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsg fCZuYnNwOyArLS1ybyBoZWxsby1hZGphY2VuY3kqIFthZGphY2VudC1hZGRyZXNzXTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyArLS1ybyBmbGFnKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZGVudGl0eXJl ZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDsgJmd0Ozxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbnRhaW5lciBoZWxsby1hZGph Y2VuY2llcyB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigKY8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVzZXMgbGRwOmFkamFjZW5jeS1zdGF0ZS1hdHRyaWJ1dGVzOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29uZmlnIChSVykgZm9yIHRhcmdldGVkIG5l aWdoYm9yIGNvdmVycyB3aGF0IHlvdSBzdWdnZXN0ZWQgd2VsbCAtPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgKy0tcncgdGFy Z2V0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKy0tcncgaGVsbG8taG9sZHRp bWU/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQxNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyArLS1ydyBoZWxsby1pbnRlcnZhbD8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg dWludDE2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICstLXJ3IGhlbGxvLWFjY2Vw dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICstLXJ3IGVuYWJsZWQ/ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJvb2xlYW48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyArLS1ydyBsZHAtZXh0Om5laWdoYm9yLWxp c3Q/Jm5ic3A7Jm5ic3A7IG5laWdoYm9yLWxpc3QtcmVmPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiAmbmJzcDtUYXJnZXRlZCBuZWlnaGJvciBpcyBu b3QgYm91bmQgdG8gYW4gaW50ZXJmYWNlIChwZXIgUkZDNTAzNiksIHNvIHRoYXQgaW50ZXJmYWNl IGxlYWYgeW91IHJlZmVycmVkIHRvIGlzIGFjdHVhbGx5IG5vdCBwYXJ0IG9mIHRhcmdldGVkIGRp c2NvdmVyeSBjb250YWluZXIsIHJhdGhlciBiYXNpYyBkaXNjb3ZlcnkgY29udGFpbmVyICh3aGlj aCBpbmRlZWQgYWxsb3dzIGZvciBvbmUgb3IgbW9yZSBpbnRlcmZhY2VzDQogcGVyIG5laWdoYm9y KS4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29udGFpbmVyIGhlbGxv LWFkamFjZW5jaWVzIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbmZpZyBmYWxzZTs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRl c2NyaXB0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtDb250YWluaW5nIGEgbGlz dCBvZiBIZWxsbyBhZGphY2VuY2llcy4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4gLiAuIC4gLiAuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGxlYWYgaW50ZXJmYWNlIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHR5cGUgaWY6aW50ZXJmYWNlLXJlZjs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGRlc2NyaXB0aW9uICZxdW90O0ludGVyZmFjZSBmb3IgdGhpcyBhZGphY2VuY3kuJnF1 b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjMuIFlvdSBhcmUgcmlnaHQgdGhhdCBhIG5laWdoYm9yIGNhbiBiZSBkaXNjb3Zl cmVkIHZpYSBib3RoIGJhc2ljIGFuZCBleHRlbmRlZCBkaXNjb3ZlcnkuIFdoYXQgeW91IHBvaW50 IG91dCBpcyB3ZWxsIGNvdmVyZWQgaW4gdGhlIHRyZWUgaW4gdHdvIGRpc3RpbmN0IHBsYWNlcyDi gJMgb25lIGZvciBiYXNpYyBhbmQgdGhlIG90aGVyIGZvciBleHRlbmRlZC90YXJnZXRlZC4gUGxz IHNlZSBzZWN0aW9uIDYuMSBhbmQNCiBmaWd1cmUgNS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyArLS1ydyBkaXNjb3Zlcnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICstLXJ3IGlu dGVyZmFjZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgKy0tcncgaW50ZXJmYWNlKiBbaW50 ZXJmYWNlXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyArLS1y dyBhZGRyZXNzLWZhbWlsaWVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICstLXJ3IGlwdjQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgKy0tcm8gaGVsbG8tYWRqYWNlbmNpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgKy0tcm8gaGVsbG8tYWRqYWNlbmNpZXMqIFthZGphY2VudC1hZGRyZXNzXTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyArLS1ybyBhZGphY2VudC1hZGRyZXNzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4gLiAuIC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgLiAuIC4gLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKy0tcncgdGFyZ2V0 ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICstLXJ3IGFkZHJlc3MtZmFt aWxpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOystLXJ3IGlwdjQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICstLXJvIGhlbGxvLWFkamFjZW5jaWVzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyArLS1ybyBoZWxsby1hZGphY2VuY2llcyo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW2xvY2FsLWFkZHJlc3MgYWRqYWNlbnQtYWRkcmVzc108 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICstLXJvIGxvY2FsLWFkZHJlc3M8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOystLXJvIGFk amFjZW50LWFkZHJlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4gLiAuIC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4gLiAuIC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsc28sIHBh Z2UjNTIgY2xhcmlmaWVzIHRoZSBmb2xsb3dpbmcgZm9yIGxvY2FsLWFkZHJlc3MgLTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgbG9jYWwtYWRkcmVzcyB7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB0eXBlIGluZXQ6aXB2NC1hZGRyZXNzOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVz Y3JpcHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O1RoZSBsb2NhbCBhZGRy ZXNzIHVzZWQgYXMgdGhlIHNvdXJjZSBhZGRyZXNzIHRvPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBzZW5kIHRhcmdldGVkIEhlbGxvIG1lc3NhZ2VzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgSWYgdGhlIHZhbHVlIGlzIG5vdCBzcGVjaWZpZWQsIHRoZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHJhbnNwb3J0LWFkZHJlc3MgaXMgdXNlZCBh cyB0aGUgc291cmNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhZGRyZXNzLiZx dW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NC4gR29vZCBwb2ludCBhYm91dCBhIGdvb2Qg4oCcZGVw bG95bWVudOKAnSBwcmFjdGljZSBmb3IgZGlmZmVyZW50IHByb3RvY29scyB0byBsZXZlcmFnZSB0 aGUgc2FtZSByb3V0ZXItaWQuIEhvd2V2ZXIsIExEUCBwcm90b2NvbCAoUkZDNTAzNikgc3BlY2lm aWVzIExTUi1JRCBhbmQgYWxsb3dzIGl0IHRvIGJlIGRpZmZlcmVudCwgaWYvYXMgbmVlZGVkIChp bmRlcGVuZGVudCBvZiB0aGF0LCBvbmUgY2FuIGNob29zZSBkaWZmZXJlbnQNCiBMU1IgSUQgZm9y IGRpZmZlcmVudCBWUkZzIG9uIGEgbm9kZSkuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFu a2Z1bGx5LCB0aGUgdGVhbSBhZ3JlZWQgdG8ga2VlcCB0aGUgZGVmYXVsdCBhbG9uZyB0aGUgbGlu ZSBvZiB3aGF0IHlvdSBwb2ludGVkLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj41LiBXZWxsLCB0aGluayBv ZiBJUHY2LW9ubHkgbm9kZSwgd2hpY2ggdW5mb3J0dW5hdGVseSBuZWVkcyB0byBoYXZlIElQdjQg Zm9yIE9PQiBtYW5hZ2VtZW50IGFjY2Vzcy4gVGhhdCB3b3VsZCByZXN1bHQgaW4gTERQIElQdjQg QUZJIGJlaW5nIGVuYWJsZWQgYnkgZGVmYXVsdCwgYW5kIGhlbmNlLCB3b3VsZCBuZWVkIHRvIGJl IGV4cGxpY2l0bHkgZGlzYWJsZWQgdmlhIHRoaXMgY29udGFpbmVyLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIHdpbGwgbGV0IG15IGNvLWF1dGhvcnMgYWRkIGZ1cnRoZXIgY2xhcmlmaWNhdGlv bi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVu dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjYuIFll cywgaXQgZG9lcyBhcHBseS4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B bmQgJm5ic3A7dGhhdCBjb25maWd1cmF0aW9uIHdpbGwgYWxsb3cgZm9yIHRoZSB0YXJnZXRlZCBh ZGphY2VuY3kgdG8gYmUgY3JlYXRlZCBmb3IgMS4xLjEuMSwgYnV0IHBlZXJpbmcgcmVsYXRpb25z aGlwIHdpbGwgYmUgZGVuaWVkLiAmbmJzcDtJZiB0aGUgaW50ZW50IGlzIHRvIG5vdCBsZXQgdGhl IHRhcmdldGVkIGFkamFjZW5jeSBiZSBjcmVhdGVkLCB0aGVuIHBvbGljeSBjb3VsZCBiZSBjcmVh dGVkIHRvIGRlbnkgMS4xLjEuMS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V3J0IGN1c3RvbSBo ZWxsby9ob2xkIHRpbWVycyBwZXIgdGFyZ2V0ZWQgbmVpZ2hib3JzLCBBRkFJSywgUkZDNTAzNiBk b2VzbuKAmXQgc3BlY2lmeSB0aGF0LCBub3IgZG8gYW55IG9mIHRoZSBpbXBsZW1lbnRhdGlvbnMu DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9ubHkgY3VzdG9tIGhlbGxv L2hvbGQgdGltZXJzIGdsb2JhbCBjb25maWcuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjcuIEFGQUlLLCB0aGlzIGlz IGJlY2F1c2Ugb2YgUkZDNTAzNiB0aGF0IHNwZWNpZmllcyA1cyB0byBiZSB0aGUgbG93ZXN0IGhl bGxvIGludGVydmFsLiAmbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXBwbGUg Q29sb3IgRW1vamkmcXVvdDsiPiYjMTI4NTIyOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9yZmM1MDM2 I3NlY3Rpb24tMy41LjIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZj NTAzNiNzZWN0aW9uLTMuNS4yPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjguIFRoYW5rcyBmb3IgcmV2aWV3aW5n IHNvIGRpbGlnZW50bHkgYW5kIHBvaW50aW5nIHRoZXNlIHR5cG9zIG91dC4NCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtmdWxseSwgb3VyIGFtYXppbmcgUkZDIEVk aXRvciB0ZWFtIGhhcyBmaXhlZCBhbGwgb2YgdGhlbSAoSSBqdXN0IGNoZWNrZWQgdGhlaXIgdmVy c2lvbikgZXhjZXB0IGludGVyZmFjZeKAmXMgY291bnRlcnMgKHdpdGhpbiB0aGUgc3RhdGlzdGlj cyBjb250YWluZXIpLCB3aGljaCBJIGJlbGlldmUgaXMgY29ycmVjdCAoc2luY2UgaXQgaXMgYWJv dXQgdGhlIG5vZGUsIG5vdCBhYm91dCB0aGUgcGVlcikuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+LS0mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+UmFqaXYgQXNhdGk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtjb2xvcjpibGFjayI+Q1RPLCBDWCBBUEpDPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxpPjx1PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTotd2Via2l0LXN0YW5kYXJkO2NvbG9yOmJs YWNrIj7igJxGb2N1cyBvbiB3aGF0IHdlIGNhbiBkbyB3aXRoIHdoYXQgd2UgaGF2ZSwgbm90IHRo ZSBvdGhlciB3YXkgYXJvdW5kLuKAnTwvc3Bhbj48L3U+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5SZW5h dG8gV2VzdHBoYWwgJmx0O3JlbmF0b0BvcGVuc291cmNlcm91dGluZy5vcmcmZ3Q7PGJyPg0KPGI+ RGF0ZTogPC9iPlRodXJzZGF5LCBKYW51YXJ5IDIwLCAyMDIyIGF0IDEwOjQxIEFNPGJyPg0KPGI+ VG86IDwvYj4mcXVvdDtkcmFmdC1pZXRmLW1wbHMtbGRwLXlhbmcuYWxsQGlldGYub3JnJnF1b3Q7 ICZsdDtkcmFmdC1pZXRmLW1wbHMtbGRwLXlhbmcuYWxsQGlldGYub3JnJmd0OywgJnF1b3Q7bXBs c0BpZXRmLm9yZyZxdW90OyAmbHQ7bXBsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8 L2I+UmV2aWV3IG9mIGRyYWZ0LWlldGYtbXBscy1sZHAteWFuZy0wOTxicj4NCjxiPlJlc2VudC1G cm9tOiA8L2I+Jmx0O2FsaWFzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+UmVzZW50LVRv OiA8L2I+SGltYW5zaHUgU2hhaCAmbHQ7aHNoYWhAY2llbmEuY29tJmd0OywgJmx0O3Nlc2FsZUBq dW5pcGVyLm5ldCZndDssIFJhaml2IEFzYXRpICZsdDtyYWppdmFAY2lzY28uY29tJmd0OywgJmx0 O3NrcmF6YUBjaXNjby5jb20mZ3Q7LCAmbHQ7dHNhYWQubmV0QGdtYWlsLmNvbSZndDssIEpvaG4g U2N1ZGRlciAmbHQ7amdzQGp1bmlwZXIubmV0Jmd0OywgJmx0O2plc2NpYS5jaGVueGlhQGh1YXdl aS5jb20mZ3Q7LCAmbHQ7eHVmZW5nLmxpdS5pZXRmQGdtYWlsLmNvbSZndDssICZxdW90O04uTGV5 bWFubkB0ZWxla29tLmRlJnF1b3Q7DQogJmx0O24ubGV5bWFubkB0ZWxla29tLmRlJmd0OywgQWx2 YXJvIFJldGFuYSAmbHQ7YXJldGFuYS5pZXRmQGdtYWlsLmNvbSZndDssICZsdDttYXJ0aW4udmln b3VyZXV4QG5va2lhLmNvbSZndDssIExvYSBBbmRlcnNzb24gJmx0O2xvYUBwaS5udSZndDssICdN YWNoIENoZW4nICZsdDttYWNoLmNoZW5AaHVhd2VpLmNvbSZndDssIERFQk9SQUggQlJVTkdBUkQg Jmx0O2RiMzU0NkBhdHQuY29tJmd0Ozxicj4NCjxiPlJlc2VudC1EYXRlOiA8L2I+VGh1cnNkYXks IEphbnVhcnkgMjAsIDIwMjIgYXQgMTA6NDEgQU08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SGkgYWxsLDxicj4NCjxicj4NCkkndmUgaW1wbGVt ZW50ZWQgdGhlIGlldGYtbXBscy1sZHAgWUFORyBtb2R1bGUgcmVjZW50bHkgYW5kIEkgdGhvdWdo dCBpdCB3b3VsZCBiZSBhIGdvb2QgaWRlYSB0byBwcm92aWRlIHNvbWUgZmVlZGJhY2sgdG8gdGhl IG1vZHVsZSBhdXRob3JzLjxicj4NCjxicj4NCk92ZXJhbGwgSSB0aGluayB0aGUgY3VycmVudCBt b2R1bGUgaGllcmFyY2h5IGlzIHJlYWxseSBnb29kLCBpdCBjYXB0dXJlcyBleGFjdGx5IHdoYXQg b25lIHNob3VsZCBleHBlY3QgZnJvbSBhbiBMRFAgaW1wbGVtZW50YXRpb24uIEkgY291bGRuJ3Qg dGhpbmsgb2YgYW55dGhpbmcgdGhhdCBpcyBtaXNzaW5nLiBJIGFsc28gbGlrZWQgdGhlIHNwbGl0 IGJldHdlZW4gYSBiYXNlIG1vZHVsZSBhbmQgYW4gZXh0ZW5kZWQgb25lLjxicj4NCjxicj4NCkkg b25seSBoYXZlIGEgZmV3IHBvaW50cy9xdWVzdGlvbnMgdG8gbWFrZTo8YnI+DQo8YnI+DQoxKSBJ IGZpbmQgdGhlICZxdW90O2FkamFjZW5jeS1mbGFnLWJhc2UmcXVvdDsgaWRlbnRpdHkgKGFuZCB0 aGUgb25lcyBkZXJpdmVkIGZyb20gaXQpIHRvIGJlIGNvbmZ1c2luZzo8YnI+DQo8YnI+DQombmJz cDsgaWRlbnRpdHkgYWRqYWNlbmN5LWZsYWctYmFzZSB7PGJyPg0KJm5ic3A7ICZuYnNwOyBkZXNj cmlwdGlvbiAmcXVvdDtCYXNlIHR5cGUgZm9yIGFkamFjZW5jeSBmbGFncy4mcXVvdDs7PGJyPg0K Jm5ic3A7IH08YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZuYnNwOyBpZGVudGl0eSBh ZGphY2VuY3ktZmxhZy1hY3RpdmUgeyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KPGJyPg0KJm5ic3A7ICZuYnNwOyBiYXNl IGFkamFjZW5jeS1mbGFnLWJhc2U7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0K Jm5ic3A7ICZuYnNwOyBkZXNjcmlwdGlvbiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtUaGlzIGFkamFjZW5jeSBpcyBjb25maWd1cmVkIGFuZCBh Y3RpdmVseSBjcmVhdGVkLiZxdW90OzsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs8YnI+DQombmJzcDsgfSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4N CiZuYnNwOyBpZGVudGl0eSBhZGphY2VuY3ktZmxhZy1wYXNzaXZlIHsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQom bmJzcDsgJm5ic3A7IGJhc2UgYWRqYWNlbmN5LWZsYWctYmFzZTsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDs8YnI+DQombmJzcDsgJm5ic3A7IGRlc2NyaXB0aW9uICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O1RoaXMgYWRqYWNlbmN5IGlz IG5vdCBjb25maWd1cmVkIGFuZCBwYXNzaXZlbHkgYWNjZXB0ZWQuJnF1b3Q7OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOzxicj4NCiZuYnNwOyB9PGJyPg0KPGJyPg0KVGhlIHdheSBJIHNlZSBpdCwgbm8gYWRq YWNlbmN5IGNhbiBiZSBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgLS0gdGhleSBhcmUgYWxsIGNyZWF0 ZWQgZHluYW1pY2FsbHkgdXBvbiByZWNlaXB0IG9mIGhlbGxvIHBhY2tldHMuPGJyPg0KPGJyPg0K VGFyZ2V0ZWQgbmVpZ2hib3JzLCBvbiB0aGUgb3RoZXIgaGFuZCwgY2FuIGJlIGVpdGhlciBjb25m aWd1cmVkIGV4cGxpY2l0bHkgb3IgY3JlYXRlZCBvbiBkZW1hbmQgKHVwb24gcmVjZWlwdCBvZiBo ZWxsbyBwYWNrZXRzIHdpdGggdGhlICdSJyBiaXQgc2V0IC0tICZxdW90O1JlcXVlc3QgU2VuZCBU YXJnZXRlZCBIZWxsb3MmcXVvdDspLiBTbyB3b3VsZG4ndCBpdCBiZSBiZXR0ZXIgdG8gbW92ZSB0 aGUgYWN0aXZlL3Bhc3NpdmUgYXR0cmlidXRlIGZyb20gYWRqYWNlbmNpZXMNCiB0byB0YXJnZXRl ZCBuZWlnaGJvcnM/PGJyPg0KPGJyPg0KMikgSSB0aGluayB0aGUgZm9sbG93aW5nIHN0YXRlIGxl YWYgaXMgcHJvYmxlbWF0aWMgZm9yIHRhcmdldGVkIGFkamFjZW5jaWVzOjxicj4NCjxicj4NCiZu YnNwOyBsZWFmIGludGVyZmFjZSB7PGJyPg0KJm5ic3A7ICZuYnNwOyB0eXBlIGlmOmludGVyZmFj ZS1yZWY7PGJyPg0KJm5ic3A7ICZuYnNwOyBkZXNjcmlwdGlvbiAmcXVvdDtJbnRlcmZhY2UgZm9y IHRoaXMgYWRqYWNlbmN5LiZxdW90Ozs8YnI+DQombmJzcDsgJm5ic3A7fTxicj4NCjxicj4NClRo ZSByZWFzb24gYmVpbmcgdGhhdCBpdCdzIHRoZW9yZXRpY2FsbHkgcG9zc2libGUgZm9yIG9uZSBh ZGphY2VuY3kgdG8gcmVjZWl2ZSBoZWxsbyBwYWNrZXRzIGZyb20gdGhlIHNhbWUgdGFyZ2V0ZWQg bmVpZ2hib3Igb24gbXVsdGlwbGUgZGlmZmVyZW50IGludGVyZmFjZXMuPGJyPg0KPGJyPg0KMykg SW4gc29tZSBwYXJ0cyBvZiB0aGUgbW9kdWxlIHRyZWUsIHRoZXJlIGFyZSBhZGphY2VuY3kgbGlz dHMgaW5kZXhlZCBsaWtlIHRoaXM6PGJyPg0KPGJyPg0KJm5ic3A7ICstLXJvIGxkcDpoZWxsby1h ZGphY2VuY3kqIFtsb2NhbC1hZGRyZXNzIGFkamFjZW50LWFkZHJlc3NdPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsrLS1ybyBsZHA6bG9jYWwtYWRkcmVzcyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBp bmV0OmlwdjQtYWRkcmVzczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Ky0tcm8gbGRwOmFkamFj ZW50LWFkZHJlc3MgJm5ic3A7ICZuYnNwO2luZXQ6aXB2NC1hZGRyZXNzPGJyPg0KPGJyPg0KT25l IHByb2JsZW0gaXMgdGhhdCBpdCdzIHBlcmZlY3RseSBwb3NzaWJsZSB0byBoYXZlIHR3byBkaWZm ZXJlbnQgYWRqYWNlbmNpZXMgd2l0aCB0aGUgc2FtZSBsb2NhbCBhbmQgYWRqYWNlbnQgYWRkcmVz c2VzLCBvbmUgYmVpbmcgYSBsaW5rIGFkamFjZW5jeSBhbmQgdGhlIG90aGVyIGFuIGV4dGVuZGVk IGFkamFjZW5jeS4gQWRkaW5nIGFuICZxdW90O2FkamFjZW5jeS10eXBlJnF1b3Q7IGtleSB3b3Vs ZCBwcm9iYWJseSBiZSBuZWNlc3NhcnkgdG8gZ3VhcmFudGVlDQogZGlzYW1iaWd1YXRpb24gaW4g c3VjaCBjYXNlcy48YnI+DQo8YnI+DQpBbHNvLCBpdCdkIGJlIGdvb2QgdG8gY2xhcmlmeSB3aGV0 aGVyIHRoZSBsb2NhbC1hZGRyZXNzIGxlYWYgcmVmZXJzIHRvIHRoZSBoZWxsbydzIHNvdXJjZSBh ZGRyZXNzIG9yIHRvIHRoZSBhZHZlcnRpc2VkIHRyYW5zcG9ydCBhZGRyZXNzICh3aGVuIGl0J3Mg cHJlc2VudCkuPGJyPg0KPGJyPg0KNCkgSSB3b25kZXIgaWYgdGhlIGZvbGxvd2luZyBsZWFmIGlz IG5lY2Vzc2FyeTo8YnI+DQo8YnI+DQombmJzcDsgbGVhZiBsc3ItaWQgezxicj4NCiZuYnNwOyAm bmJzcDsgdHlwZSBydC10eXBlczpyb3V0ZXItaWQ7PGJyPg0KJm5ic3A7ICZuYnNwOyBkZXNjcmlw dGlvbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O1NwZWNpZnkgdGhlIHZhbHVlIHRv IGFjdCBhcyB0aGUgTERQIExTUiBJRC48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJ ZiB0aGlzIGF0dHJpYnV0ZSBpcyBub3Qgc3BlY2lmaWVkLCBMRFAgdXNlcyB0aGUgcm91dGVyPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SUQgYXMgZGV0ZXJtaW5lZCBieSB0aGUgc3lz dGVtLiZxdW90Ozs8YnI+DQombmJzcDsgfTxicj4NCjxicj4NClNob3VsZG4ndCB0aGUgcm91dGVy LWlkIGxlYWYgZnJvbSB0aGUgaWV0Zi1yb3V0aW5nIG1vZHVsZSBiZSBlbm91Z2ggZm9yIHRoaXMg cHVycG9zZT88YnI+DQo8YnI+DQo1KSBJJ2QgbGlrZSB0byBrbm93IHdoYXQncyB0aGUgcmF0aW9u YWxlIGJlaGluZCB0aGUgZm9sbG93aW5nIHByZXNlbmNlIGNvbnRhaW5lcjo8YnI+DQo8YnI+DQom bmJzcDsgY29udGFpbmVyIGFkZHJlc3MtZmFtaWxpZXMgezxicj4NCiZuYnNwOyAmbmJzcDsgZGVz Y3JpcHRpb248YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtQZXItdnJmIHBlci1hZiBw YXJhbXMuJnF1b3Q7Ozxicj4NCiZuYnNwOyAmbmJzcDsgY29udGFpbmVyIGlwdjQgezxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7IHByZXNlbmNlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZxdW90O1ByZXNlbnQgaWYgSVB2NCBpcyBlbmFibGVkLiZxdW90Ozs8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyBbLi4uXTxicj4NCiZuYnNwOyAmbmJzcDsgfTxicj4NCiZuYnNwOyB9PGJy Pg0KPGJyPg0KU2luY2Ugbm90IGhhdmluZyB0aGF0IGNvbnRhaW5lciBleHBsaWNpdGx5IGVuYWJs ZWQgaW4gdGhlIGNvbmZpZ3VyYXRpb24gd29uJ3QgcHJldmVudCBhbiBMRFB2NCBuZWlnaGJvcnNo aXAgdG8gYmUgZm9ybWVkLCB3b3VsZG4ndCBhIHJlZ3VsYXIgbm9uLXByZXNlbmNlIGNvbnRhaW5l ciBiZSBlbm91Z2ggaGVyZT8gVGhlICZxdW90O3ByZXNlbmNlJnF1b3Q7IHN0YXRlbWVudCBkb2Vz bid0IHNlZW0gdG8gYWRkIGFueSBtZWFuaW5nIHRvIHRoZSBleGlzdGVuY2Ugb2YNCiB0aGUgY29u dGFpbmVyLjxicj4NCjxicj4NCkFsc28sIHRoZSAmcXVvdDtwZXItdnJmJnF1b3Q7IGNvbW1lbnQg aW4gdGhlIGRlc2NyaXB0aW9uIHNlZW1zIHVubmVjZXNzYXJ5Ljxicj4NCjxicj4NCjYpIEkgaGF2 ZSBvbmUgcXVlc3Rpb24gYWJvdXQgY29uZmlndXJhdGlvbiBwcmVjZWRlbmNlLiBIZXJlJ3MgYW4g ZXhhbXBsZSBjb25maWd1cmF0aW9uOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZx dW90O2NvbnRyb2wtcGxhbmUtcHJvdG9jb2wmcXVvdDs6IFs8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgezxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1 b3Q7dHlwZSZxdW90OzogJnF1b3Q7aWV0Zi1tcGxzLWxkcDptcGxzLWxkcCZxdW90Oyw8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O25hbWUmcXVvdDs6ICZxdW90 O21haW4mcXVvdDssPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVv dDtpZXRmLW1wbHMtbGRwOm1wbHMtbGRwJnF1b3Q7OiB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7Z2xvYmFsJnF1b3Q7OiB7PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFtzbmlwXTxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IH0sPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7ZGlzY292ZXJ5JnF1b3Q7OiB7 PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZx dW90O2ludGVyZmFjZXMmcXVvdDs6IHs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFtzbmlwXTxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB9LDxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDt0YXJnZXRlZCZxdW90Ozogezxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJnF1b3Q7aGVsbG8tYWNjZXB0JnF1b3Q7OiB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7ZW5hYmxlZCZx dW90OzogdHJ1ZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfSw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O2FkZHJlc3MtZmFtaWxpZXMmcXVvdDs6IHs8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmcXVvdDtpcHY0JnF1b3Q7OiB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O3Rhcmdl dCZxdW90OzogWzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgezxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZxdW90O2FkamFjZW50LWFkZHJlc3MmcXVvdDs6ICZxdW90OzEuMS4xLjEm cXVvdDssPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7ZW5hYmxlZCZxdW90 OzogZmFsc2U8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IH08YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgXTxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IH08YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IH08YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IH08YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IH08YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IF08 YnI+DQo8YnI+DQpJbiB0aGF0IGNvbmZpZ3VyYXRpb24sIHRoZSAmcXVvdDsxLjEuMS4xJnF1b3Q7 IHRhcmdldGVkIG5laWdoYm9yIGlzIGV4cGxpY2l0bHkgY29uZmlndXJlZCBhbmQgZGlzYWJsZWQu IEFsc28sIHRoZSBnbG9iYWwgJnF1b3Q7aGVsbG8tYWNjZXB0JnF1b3Q7IHNldHRpbmcgaXMgZW5h YmxlZC48YnI+DQo8YnI+DQpXaGVuIGEgaGVsbG8gcGFja2V0IGZyb20gJnF1b3Q7MS4xLjEuMSZx dW90OyBpcyByZWNlaXZlZCwgc2hvdWxkIGEgZHluYW1pYyB0YXJnZXRlZCBuZWlnaGJvciBiZSBj cmVhdGVkIGZvciBpdD8gSSB0aGluayB0aGUgYW5zd2VyIGJvaWxzIGRvd24gdG8gd2hldGhlciB0 aGUgdGFyZ2V0ZWQgbmVpZ2hib3IgY29uZmlndXJhdGlvbiBhcHBsaWVzIHRvIGR5bmFtaWMgdGFy Z2V0ZWQgbmVpZ2hib3JzIGFzIHdlbGwuPGJyPg0KPGJyPg0KQWxzbywgaGF2aW5nIHRoZSBhYmls aXR5IHRvIGNvbmZpZ3VyZSBjdXN0b20gaGVsbG8gdGltZXJzIGZvciB0YXJnZXRlZCBuZWlnaGJv cnMgY291bGQgYmUgdXNlZnVsIGZvciBzb21lIG9wZXJhdG9ycy48YnI+DQo8YnI+DQo3KSBJIHRo aW5rIHNvbWUgdGltZXIgcmFuZ2VzIGFyZSB0b28gcmVzdHJpY3RpdmUuIEV4YW1wbGU6PGJyPg0K PGJyPg0KJm5ic3A7IGxlYWYgaGVsbG8taG9sZHRpbWUgezxicj4NCiZuYnNwOyAmbmJzcDsgdHlw ZSB1aW50MTYgezxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHJhbmdlIDE1Li4zNjAwOzxicj4N CiZuYnNwOyAmbmJzcDsgfTxicj4NCiZuYnNwOyAmbmJzcDsgW3NuaXBdPGJyPg0KJm5ic3A7IH08 YnI+DQombmJzcDsgbGVhZiBoZWxsby1pbnRlcnZhbCB7PGJyPg0KJm5ic3A7ICZuYnNwOyB0eXBl IHVpbnQxNiB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgcmFuZ2UgNS4uMTIwMDs8YnI+DQom bmJzcDsgJm5ic3A7IH08YnI+DQombmJzcDsgJm5ic3A7IFtzbmlwXTxicj4NCiZuYnNwOyB9PGJy Pg0KPGJyPg0KV2hpbGUgYSBoZWxsbyBob2xkdGltZSBvZiAxNSBzZWNvbmRzIGlzIGEgc2FuZSBk ZWZhdWx0LCBJIGRvbid0IHRoaW5rIHdlIHNob3VsZCBwcm9oaWJpdCB0aGUgb3BlcmF0b3IgZnJv bSBjb25maWd1cmluZyBzbWFsbGVyIHZhbHVlcy48YnI+DQo8YnI+DQpUaGUgT1NQRiBhbmQgSVMt SVMgbW9kdWxlcywgZm9yIGluc3RhbmNlLCB1c2UgcnQtdHlwZXM6dGltZXItdmFsdWUtc2Vjb25k czE2IGZvciBsZWFmcyBsaWtlIHRoZXNlLjxicj4NCjxicj4NCjgpIEEgY291cGxlIG9mIHRyaXZp YWwgdHlwbyBmaXhlczo8YnI+DQombmJzcDsgKiBQYWdlIDMwOiBzL09uIG9yIG1vcmUgZmxhZ3Mv T25lIG9yIG1vcmUgZmxhZ3MvPGJyPg0KJm5ic3A7ICogUGFnZSAzMDogcy9leHRlbmRlZCBkaXNj b3ZlcmlzL2V4dGVuZGVkIGRpc2NvdmVyaWVzLzxicj4NCiZuYnNwOyAqIFBhZ2UgNDI6IHMvc2lu Y2UgdGhlIHRoZSBzdGF0ZS9zaW5jZSB0aGUgc3RhdGUvPGJyPg0KJm5ic3A7ICogUGFnZSA0Mjog cy9pbnRlcmZhY2UncyBjb3VudGVycy9wZWVyJ3MgY291bnRlcnMvPGJyPg0KJm5ic3A7ICogUGFn ZSA1NDogcy90YXJnZXR0dGVkIGFkamFjZW5jeS90YXJnZXRlZCBhZGphY2VuY3kvPGJyPg0KPGJy Pg0KUmVnYXJkcyw8YnI+DQotLSA8YnI+DQpSZW5hdG8gV2VzdHBoYWw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_66F8F012E80449CE88904941CC10AB61ciscocom_-- From nobody Thu Jan 20 17:09:49 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1703A0E61; Thu, 20 Jan 2022 17:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLSjH2lWIKJx; Thu, 20 Jan 2022 17:09:09 -0800 (PST) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450: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 6213A3A0E5A; Thu, 20 Jan 2022 17:09:09 -0800 (PST) Received: by mail-ed1-x52f.google.com with SMTP id l5so19096876edv.3; Thu, 20 Jan 2022 17:09:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LERU9JebwkDVPZMB3o2q3xjHUQJ+2OAtqmdWfuJhbJE=; b=CG4MfoGOVDOMLaKfEdx0nR2a69JLIHctkyMBGdIeWCe8zh8GUQD+XbnJCgJDBuUzxd KcdAFpL9QROlC9AQyrPr89XPznSjX/gidZivJYBoPSQoZ3rFbhdH+RzX8AYhG+/k6jE/ v9Sdd1E7/hwTky/NYEBX9Mxoysyl94x6FrxdprhcbJs50qM8IEbpo3NVTJyjDNHqrlGU zwiXHM9jgAhxmycY4+CHw0wtVaZnrnfNyz4BREq3mFBWpXo0UuiQmV26BZFBRDPUtdWd AuasTb4O8ddQd/SOKNfF6jylTvOENn8eirScsZGqdzt1gZy4zEdhR+b4MyZYl2ia+HKG 94ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LERU9JebwkDVPZMB3o2q3xjHUQJ+2OAtqmdWfuJhbJE=; b=6Hv2I50pPpelg9c2OPNQUGsvNUVXHIQC0GQOlcoByWgCXGLPqpZ/k+7UxLOijzaSWo 1Zgd6rGoJ/qyOPubUlJiKhf7pjdjNrRMUqSEnqmfh1+KQPty7Eod8SsijqaeMGPG+5lZ lbvTdDWSQqR/CIFod3jMz+EGQoutPGTZA4EbzlnRDbylM4hZXOTs8xc32WjncXXvJ6WP yyvETkoFQ0JDqMcLhL5u05Q8be4eR44pV0rf4SUwiRMm93ybtgOCcKauIyFDPJROE5IL 6Elh/5zSnCZzMZiFJuqEvNWSh7LkIU/747r8ywJhmKB9TIOLIuzoB+bE0gk0oTJLPH9W gnWw== X-Gm-Message-State: AOAM533sz6sUffB4g+6GKEHGGxtQr/pagCz5B6p6t1IGNaSwDxllI9l9 tHp3hn7dJtAve7eHgRYyOlHgFt16pePXmk7hy37iDTByrLY= X-Google-Smtp-Source: ABdhPJwswqFozV/zIfD8nAiHo0uIQ2IcRuBLNzy6Yt45mFQSDUggHVVcpVB7hT3fPF7/Jax1mnmC/ILEiuLKbAFFmNI= X-Received: by 2002:a17:906:2802:: with SMTP id r2mr1419765ejc.172.1642727346570; Thu, 20 Jan 2022 17:09:06 -0800 (PST) MIME-Version: 1.0 References: <11050_1642436674_61E59842_11050_100_1_0d0176823ddd4cb4ad825e3ee88445a3@orange.com> In-Reply-To: <11050_1642436674_61E59842_11050_100_1_0d0176823ddd4cb4ad825e3ee88445a3@orange.com> From: Greg Mirsky Date: Thu, 20 Jan 2022 17:08:55 -0800 Message-ID: To: bruno.decraene@orange.com Cc: mpls , "pals@ietf.org" , DetNet WG Content-Type: multipart/alternative; boundary="000000000000f4893f05d60d43a8" Archived-At: Subject: Re: [mpls] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id 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, 21 Jan 2022 01:09:15 -0000 --000000000000f4893f05d60d43a8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bruno, thank you for your kind consideration of my comments. Please find follow-up notes in-line below under the GIM>> tag. Regards, Greg On Mon, Jan 17, 2022 at 8:24 AM wrote: > Hi Greg, all > > > > Greg, thanks for taking the time to read the draft and comment. > > > > WG, for context, we are discussing a subset of the draft: the ability to > advertise indicator as part of the existing Entropy Label TTL as describe= d > in section 2 of the draft (it=E2=80=99s 1 page): > > > https://datatracker.ietf.org/doc/html/draft-decraene-mpls-slid-encoded-en= tropy-label-id-02#section-2 > > > > Please see inline [Bruno] > > > > > > Orange Restricted > > *From:* mpls *On Behalf Of *Greg Mirsky > *Sent:* Thursday, January 13, 2022 11:41 PM > *To:* mpls ; pals@ietf.org; DetNet WG > *Subject:* [mpls] Continuing with my comments on > draft-decraene-mpls-slid-encoded-entropy-label-id > > > > Hi Bruno, et al. > > Thank you for presenting this work at the MPLS Open DT meeting today. > Below please find the summary of my comments and questions with the > additional thoughts that came after we've closed the call. I greatly > appreciate the consideration and opinions of the authors and the group. > > - Compatibility with nodes that support only RFC 6790. > > > - If the proposed indicators are used to signal the presence of an > ISD, that seems to create a problem for an RFC6790-only node as it = might > not be able to process the ISD. > > [Bruno] > > - Draft(*) extends the use of the Entropy Label TTL field which is > essentially specified as a Reserved field in RFC 6790. Hence draft is > backward compatible with RFC 6790. > GIM>> I agree, that if the mechanism is limited to re-use of the TTL field of the label element that includes the entropy label, then there are no possible issues. But then, how useful is a mechanism that allows for only seven indicators of processing instructions? Of course, if the model does not support a combination of instructions, then the new field might be viewed not as a set of flags but as a scalar with each value defining a different processing type. - Draft does not specify ISD so this is out of scope of this draft. That > been said: > > - You are right that before sending ISD in a new extension, the > capability for the receiver/egress to support this ISD needs to be known = by > the sender. This is priori required by all ISD solution. > > - You seemed to assume that ISD are always necessary but IMHO indicators > and ISD are two different extensions and Indicators may be used without I= SD > extensions .e.g., cf sections 4, 5, 3 of the draft > GIM>> I agree, that in some scenarios the ability to signal processing in a label stack is sufficient and useful. Though, having a method of doing a subset of what can be done with Ancillary Data and Action indication seems like an unnecessary overlap. > > - If one of the indicators is to be used to signal the presence of the > extension, that, similarly to the scenario above, might not be corr= ectly > processed by an RFC6790-only node. > > [Bruno] idem > > - Scaling > > > - If the proposed method to signal the ancillary data is used in, for > example, a strict explicit routing environment, the Entropy Label i= s not > needed. If that is the case, using the indicators, as described in = the > draft, seems to waste 20 bits in a label element compared to the me= chanism > proposed in draft-kompella-mpls-mspl4fa. > > [Bruno] And for all other cases, the scaling is very good as we carry > indicators with zero extra label. So the net benefit is dependent of the > relative usage of strict explicit routing traffic vs traffic which can be > ECMP. In my environment, the latter is much more prevalent, hence the net > benefit is positive. > GIM>> I agree that there are cases and scenarios when seven indicators can solve the operator's immediate problems. Though I believe that a future-proof solution is preferable. PS : by =C2=AB draft =C2=BB I mean section 2 of the draft as this is the sc= ope of the > discussion. > > Regards, > > -Bruno > > Regards, > > Greg > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --000000000000f4893f05d60d43a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bruno,
thank you = for your kind consideration of my comments. Please find=C2=A0follow-up note= s in-line below under the GIM>> tag.

Regards= ,
Greg

On Mon, Jan 17, 2022 at 8:24 AM <bruno.decraene@orange.com> wrote:

Hi Greg, all

=C2=A0

Greg, thanks for taking the time to read the draft a= nd comment.

=C2=A0

WG, for context, we are discussing a subset of the d= raft: the ability to advertise indicator as part of the existing Entropy Label TTL as described in section 2 of the draft (it=E2=80=99s 1 p= age):

https://datatracker.ietf.org/doc/html/draft-decraene-mpls-slid-encoded-= entropy-label-id-02#section-2

=C2=A0

Please see inline [Bruno]

=C2=A0

=C2=A0

Orange Restricted

From: mpls <mpls-bounces@ietf.org&g= t; On Behalf Of Greg Mirsky
Sent: Thursday, January 13, 2022 11:41 PM
To: mpls <mpls= @ietf.org>; pals@= ietf.org; DetNet WG <detnet@ietf.org>
Subject: [mpls] Continuing with my comments on draft-decraene-mpls-s= lid-encoded-entropy-label-id

=C2=A0

Hi Bruno, et al.

Thank you for presenting this work at the MPLS Open = DT meeting today. Below please find the summary of my comments and question= s with the additional thoughts that came after we've closed the call. I= greatly appreciate the consideration and opinions of the authors and the group.

  • Compatibility with nodes that support only RFC 6790.
      • If the proposed indicators are used to signal the presence of an ISD, that = seems to create a problem for an RFC6790-only node as it might not be able = to process the ISD.

    [Bruno]

    - Draft(*) extends the use of the Entropy Label TTL field which is essentially specified as a Reserved field in RFC 6790. Henc= e draft is backward compatible with RFC 6790.

<= /div>
GIM>> I agree, that if the mechani= sm is limited to re-use of the TTL field=C2=A0of the label element that inc= ludes the entropy label, then there are no possible issues. But then, how u= seful is a mechanism that allows for only seven indicators of processing in= structions? Of course, if the model does not support a combination of instr= uctions, then the new field might be viewed not as a set of flags but as a = scalar with each value defining a different processing type.

=

- Draft does not specify ISD so this is out of scope of this draft. That been said:

= -=C2=A0 You are right that before sending ISD in a new extension, the capabi= lity for the receiver/egress to support this ISD needs to be known by the s= ender. This is priori required by all ISD solution.

= - You seemed to assume that ISD are always necessary but IMHO indicators an= d ISD are two different extensions and Indicators may be used without ISD extensions .e.g., cf sections 4, 5, 3 of the draft=

GIM>> I agr= ee, that in some scenarios the ability to signal processing in a label stac= k is sufficient and useful. Though, having a method of doing a subset of wh= at can be done with Ancillary Data and Action indication seems like an unne= cessary overlap.

    • If one of the indicators is=C2=A0to be used to signal = the presence=C2=A0of the extension, that, similarly to the scenario above, = might not be correctly processed by an RFC6790-only node.

[Bruno] idem

  • Scaling
    • If the proposed method to signal the ancillary data is used in, for example= , a strict explicit routing environment, the Entropy Label is not needed. I= f that is the case, using the indicators, as described in the draft, seems = to waste 20 bits in a label element compared to the mechanism proposed in draft-kompella-mpls-mspl4fa.<= u>

[Bruno] And for all other cases, the scaling is very good as we carry indicators with zero extra label. So the net benefit is d= ependent of the relative usage of strict explicit routing traffic vs traffi= c which can be ECMP. In my environment, the latter is much more prevalent, = hence the net benefit is positive.

=
GIM>> I agree that there are cases and scenar= ios when seven indicators can solve the operator's=C2=A0immediate probl= ems. Though I believe that a future-proof solution is preferable.

PS=C2=A0: by =C2=AB=C2=A0draft=C2=A0=C2=BB I mean se= ction 2 of the draft as this is the scope of the discussion.<= /span>

Regards,

-Bruno

Regards,

Greg

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--000000000000f4893f05d60d43a8-- From nobody Fri Jan 21 01:57:40 2022 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 8D7013A1858; Fri, 21 Jan 2022 01:57:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.43.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mpls@ietf.org Message-ID: <164275905838.27474.18375438751478121194@ietfa.amsl.com> Date: Fri, 21 Jan 2022 01:57:38 -0800 Archived-At: Subject: [mpls] I-D Action: draft-ietf-mpls-sfl-control-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2022 09:57:39 -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 Simple Control Protocol for MPLS SFLs Authors : Stewart Bryant George Swallow Siva Sivabalan Filename : draft-ietf-mpls-sfl-control-02.txt Pages : 14 Date : 2022-01-21 Abstract: In RFC 8957 the concept of MPLS synonymos flow labels (SFL) was introduced. This document describes a simple control protocol that runs over an associated control header to request, withdraw, and extend the lifetime of such labels. It is not the only control protocol that might be used to support SFL, but it has the benefit of being able to be used without modifying of the existing MPLS control protocols. The existence of this design is not intended to restrict the ability to enhance an existing MPLS control protocol to add a similar capability. A Querier MUST wait a configured time (suggested wait of 60 seconds) before re-attempting a Withdraw request. No more than three Withdraw requests SHOULD be made. These restrictions are to prevent overloading the control plane of the actioning router. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-sfl-control/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-mpls-sfl-control-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-sfl-control-02 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Fri Jan 21 09:57:53 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2403A1122; Fri, 21 Jan 2022 09:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 3ivPqKUE1mlW; Fri, 21 Jan 2022 09:57:46 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (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 2005C3A111D; Fri, 21 Jan 2022 09:57:46 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr21.francetelecom.fr (ESMTP service) with ESMTPS id 4JgRtH2Myqz5wG5; Fri, 21 Jan 2022 18:57:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1642787863; bh=GyJBqwgDdQC8knh2gXN27HYolUUii/n053KRCNCPO44=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=j/hIsnNRoGL9rTWh4eLzm/t8zv0VmqoK9mbevBwCZnQfOFyz9fPyze8NEM56JpFU0 vnEvBvBEavhKooFn91uir9zARePCXE7SeaRg010YT+b44T4FKi/2na+fM1Dxwgzl+2 7K+VAp9Mh3tuLqCtpGj9ArJ1ABeLHfEsYLUTAFsYTcvhgw6rCcLyVl/401lylazyAd aQA1FL63lqjV81LipRTBbzimo3QQLr1YIZKzy2lRUpKw4VBlY20R2ftvQOzEsYRZk4 Ogh6yQx+LWICtGGQdcpEKLjoBr3c3O7yuo0st/J8ZgIGtpNV3fRqUa/2pDUGZLfyi1 MXFAGF1hBF51w== From: To: Greg Mirsky CC: mpls , "pals@ietf.org" , DetNet WG Thread-Topic: [mpls] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id Thread-Index: AQHYDmN+oYnDer1AoUKTsPwHicZfiaxtvF+g Date: Fri, 21 Jan 2022 17:57:42 +0000 Message-ID: <6217_1642787863_61EAF417_6217_204_1_8dd254d74cdc46e58328d6889c6984a2@orange.com> References: <11050_1642436674_61E59842_11050_100_1_0d0176823ddd4cb4ad825e3ee88445a3@orange.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-01-21T17:57:40Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_enabled: true msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_setdate: 2022-01-21T17:57:40Z msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_method: Standard msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_name: Orange_restricted_external.2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_siteid: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_actionid: d07052b2-4406-4d15-b93d-e3af3892ebbc msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_contentbits: 0 x-originating-ip: [10.115.27.50] Content-Type: multipart/alternative; boundary="_000_8dd254d74cdc46e58328d6889c6984a2orangecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id 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, 21 Jan 2022 17:57:52 -0000 --_000_8dd254d74cdc46e58328d6889c6984a2orangecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Thank you for the follow up. Please see inline [Bruno2] Orange Restricted From: Greg Mirsky Sent: Friday, January 21, 2022 2:09 AM To: DECRAENE Bruno INNOV/NET Cc: mpls ; pals@ietf.org; DetNet WG Subject: Re: [mpls] Continuing with my comments on draft-decraene-mpls-slid= -encoded-entropy-label-id Hi Bruno, thank you for your kind consideration of my comments. Please find follow-up= notes in-line below under the GIM>> tag. Regards, Greg On Mon, Jan 17, 2022 at 8:24 AM > wrote: Hi Greg, all Greg, thanks for taking the time to read the draft and comment. WG, for context, we are discussing a subset of the draft: the ability to ad= vertise indicator as part of the existing Entropy Label TTL as described in= section 2 of the draft (it's 1 page): https://datatracker.ietf.org/doc/html/draft-decraene-mpls-slid-encoded-entr= opy-label-id-02#section-2 Please see inline [Bruno] Orange Restricted From: mpls > On Behalf = Of Greg Mirsky Sent: Thursday, January 13, 2022 11:41 PM To: mpls >; pals@ietf.org; DetNet WG > Subject: [mpls] Continuing with my comments on draft-decraene-mpls-slid-enc= oded-entropy-label-id Hi Bruno, et al. Thank you for presenting this work at the MPLS Open DT meeting today. Below= please find the summary of my comments and questions with the additional t= houghts that came after we've closed the call. I greatly appreciate the con= sideration and opinions of the authors and the group. * Compatibility with nodes that support only RFC 6790. * If the proposed indicators are used to signal the presence of an I= SD, that seems to create a problem for an RFC6790-only node as it might not= be able to process the ISD. [Bruno] - Draft(*) extends the use of the Entropy Label TTL field which is essentia= lly specified as a Reserved field in RFC 6790. Hence draft is backward comp= atible with RFC 6790. GIM>> I agree, that if the mechanism is limited to re-use of the TTL field = of the label element that includes the entropy label, then there are no pos= sible issues. But then, how useful is a mechanism that allows for only seve= n indicators of processing instructions? Of course, if the model does not s= upport a combination of instructions, then the new field might be viewed no= t as a set of flags but as a scalar with each value defining a different pr= ocessing type. [Bruno2] Thank you for acknowledging that it would work. In terms of possib= le usages, the draft lists 3 ones in sections 3, 4 and 5. - Draft does not specify ISD so this is out of scope of this draft. That be= en said: - You are right that before sending ISD in a new extension, the capability= for the receiver/egress to support this ISD needs to be known by the sende= r. This is priori required by all ISD solution. - You seemed to assume that ISD are always necessary but IMHO indicators an= d ISD are two different extensions and Indicators may be used without ISD e= xtensions .e.g., cf sections 4, 5, 3 of the draft GIM>> I agree, that in some scenarios the ability to signal processing in a= label stack is sufficient and useful. Though, having a method of doing a s= ubset of what can be done with Ancillary Data and Action indication seems l= ike an unnecessary overlap. [Bruno2] Thank you for the agreement. If one/a use case wants to advertise = more data, it's possible to extend the proposal (actually one should be pub= lished shortly) * If one of the indicators is to be used to signal the presence of t= he extension, that, similarly to the scenario above, might not be correctly= processed by an RFC6790-only node. [Bruno] idem * Scaling * If the proposed method to signal the ancillary data is used in, fo= r example, a strict explicit routing environment, the Entropy Label is not = needed. If that is the case, using the indicators, as described in the draf= t, seems to waste 20 bits in a label element compared to the mechanism prop= osed in draft-kompella-mpls-mspl4fa. [Bruno] And for all other cases, the scaling is very good as we carry indic= ators with zero extra label. So the net benefit is dependent of the relativ= e usage of strict explicit routing traffic vs traffic which can be ECMP. In= my environment, the latter is much more prevalent, hence the net benefit i= s positive. GIM>> I agree that there are cases and scenarios when seven indicators can = solve the operator's immediate problems. Though I believe that a future-pro= of solution is preferable. [Bruno2] If needed, I believe that this proposal may be extended for the us= e cases that would require more. I see no reason for such extension to not = be equally future-proof. Regards, --Bruno PS : by < draft > I mean section 2 of the draft as this is the scope of the= discussion. Regards, -Bruno Regards, Greg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_8dd254d74cdc46e58328d6889c6984a2orangecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,=

 

Thank you for the follow up. Please see inline [Bruno2]

 

 

Orange Restricted

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Friday, January 21, 2022 2:09 AM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>
Cc: mpls <mpls@ietf.org>; pals@ietf.org; DetNet WG <detnet@= ietf.org>
Subject: Re: [mpls] Continuing with my comments on draft-decraene-mp= ls-slid-encoded-entropy-label-id

 

Hi Bruno,

thank you for your kind consideration of my comments= . Please find follow-up notes in-line below under the GIM>> tag.=

 

Regards,

Greg

 

On Mon, Jan 17, 2022 at 8:24 AM <bruno.decraene@orange.com> wrote:<= /o:p>

Hi Greg, all

 

Greg, thanks for taking the = time to read the draft and comment.

 

WG, for context, we are disc= ussing a subset of the draft: the ability to advertise indicator as part of the existing Entropy Label TTL as described in sectio= n 2 of the draft (it’s 1 page):

https://datatracker.ietf.org/doc/html/draft-dec= raene-mpls-slid-encoded-entropy-label-id-02#section-2=

 

Please see inline [Bruno]

 

 

Orange Restricted

From: mpls <mpls-bounces@ietf.org> On Behalf Of Greg Mirsky
Sent: Thursday, January 13, 2022 11:41 PM
To: mpls <mpls= @ietf.org>; pals@ietf.org; DetNe= t WG <detnet@ietf.o= rg>
Subject: [mpls] Continuing with my comments on draft-decraene-mpls-s= lid-encoded-entropy-label-id

 

Hi Bruno, et al.

Thank you for presenting this work at the MPLS Open DT meeting tod= ay. Below please find the summary of my comments and questions with the add= itional thoughts that came after we've closed the call. I greatly appreciate the consideration and opinions of th= e authors and the group.

  • Compatibility with nodes that support only RFC 6790.
    • If the proposed indicators are used to signal the presence of an ISD, that = seems to create a problem for an RFC6790-only node as it might not be able = to process the ISD.

[Bruno]

- Draft(*) extends the use o= f the Entropy Label TTL field which is essentially specified as a Reserved field in RFC 6790. Hence draft is backward compati= ble with RFC 6790.

GIM>> I agree, that if the mechanism is limite= d to re-use of the TTL field of the label element that includes the en= tropy label, then there are no possible issues. But then, how useful is a m= echanism that allows for only seven indicators of processing instructions? Of course, if the model does not support a com= bination of instructions, then the new field might be viewed not as a set o= f flags but as a scalar with each value defining a different processing typ= e.

[Bruno2] Thank you for acknowledging that it would work. In te= rms of possible usages, the draft lists 3 ones in sections 3, 4 and 5.

 

- Draft does not specify ISD= so this is out of scope of this draft. That been said:

-  You are right that before sen= ding ISD in a new extension, the capability for the receiver/egress to supp= ort this ISD needs to be known by the sender. This is priori required by all ISD solution.

- You seemed to assume that ISD are a= lways necessary but IMHO indicators and ISD are two different extensions an= d Indicators may be used without ISD extensions .e.g., cf sections 4, 5, 3 of the draft

GIM>> I agree, that in some scenarios the abil= ity to signal processing in a label stack is sufficient and useful. Though,= having a method of doing a subset of what can be done with Ancillary Data = and Action indication seems like an unnecessary overlap.

[Bruno2] Thank= you for the agreement. If one/a use case wants to advertise more data, it’s possible to extend= the proposal (actually one should be published shortly)

    • If one of the indica= tors is to be used to signal the presence of the extension, that,= similarly to the scenario above, might not be correctly processed by an RF= C6790-only node.

[Bruno] idem

  • Scaling
    • If the proposed method to signal the ancillary data is used in, for example= , a strict explicit routing environment, the Entropy Label is not needed. I= f that is the case, using the indicators, as described in the draft, seems = to waste 20 bits in a label element compared to the mechanism proposed in draft-kompella-mpls-mspl4fa.

[Bruno] And for all other ca= ses, the scaling is very good as we carry indicators with zero extra label. So the net benefit is dependent of the relative usa= ge of strict explicit routing traffic vs traffic which can be ECMP. In my e= nvironment, the latter is much more prevalent, hence the net benefit is pos= itive.

GIM>> I agree that there are cases and scenari= os when seven indicators can solve the operator's immediate problems. = Though I believe that a future-proof solution is preferable.

[Bruno2] If ne= eded, I believe that this proposal may be extended for the use cases that w= ould require more. I see no reason for such extension to not be equally future-proof.

 

Regards,<= /o:p>

--Bruno

 

PS : by « dr= aft » I mean section 2 of the draft as this is the scope of the = discussion.

Regards,

-Bruno

Regards,

Greg

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_8dd254d74cdc46e58328d6889c6984a2orangecom_-- From nobody Sat Jan 22 13:34:28 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECDE3A1399; Sat, 22 Jan 2022 13:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4UgVuLHYivz; Sat, 22 Jan 2022 13:34:15 -0800 (PST) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 D05673A1382; Sat, 22 Jan 2022 13:34:14 -0800 (PST) Received: by mail-ej1-x633.google.com with SMTP id m4so10282713ejb.9; Sat, 22 Jan 2022 13:34:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Yjsv+i7TmRYg5qQSH6qnrChmlUE+CPHlTO6iToune0I=; b=ltdzhJ1KK+Gw0o13elp94o2yY1mfBN6JTQs/9ZcQLjK/8VwN9SBF40oU0Kt0sVBzGd gn3/4nb/zLNs3pG27zlrj8F8+5w/8J4PhNXWP2QWS0xhVjIDCG8rtzfrukwdxJVQ+gy7 3wHrlnottuIom9ENoPPDNuGE2eJcp7mKP0c12N5HuuVQLQIs5bWQ87WBRoDcVAM98xWj bOPy1dERQ1IJ6ZBvpxag4sQq1rialOwvKhPkPvYK2F4OiJTjU0fHToCqmS169NAmymUx YUp5WEr/BAe3Iy7zbmf3LXHm2cq43+FGvDp4oyENRxo6P2n+sHB5AKAlFRMJz0rp6mTU nMDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Yjsv+i7TmRYg5qQSH6qnrChmlUE+CPHlTO6iToune0I=; b=EE4RBHrdDeQl+0q/fU17ZD3ST/gjvA+ROfCjZ4JRdqf2snG0aGAPAvr7x0l6q0cdGi 3tS9JdbdDHR6yT26xVFQleOaw/wjsqOYSesnhoJESy+j5pR1khjbbxGcGvQYEcQLrdNz s9PfuLNO65oc7jtD/qJ0KYGdMQzXA0z8JHu56SCB34VJ06wihj4zBA6kDWrj013GSFgB q8FRrAWP2V6P8D0oCQ8fpR2jNleQPdhqGbeBNOCwrQApWDFOKbZ/UY1J0ZkKbTAx0EVo bUOov8JKj1zmgUut9gCAsotkAWxHe31l65D6qT7jKfa7nfrsz5R+bicrSSRtjgqxJiBo sMWA== X-Gm-Message-State: AOAM533F6iWWJu01/N5UXviMdPHuqI4vqfOZzvymNehKCTEQENBy8vy7 kTWewTw0MjabODsqKU/xCyyUTLx0dTHoODCP/7fKf1ty X-Google-Smtp-Source: ABdhPJzm3/f7rZbYVoNoD8zlI11in/I4/Z39ZTi4f6yg+9AykMAC3gsoQbgM4gXwQl14Tc0NrAU/42MYePo2TOP+eEc= X-Received: by 2002:a17:906:2802:: with SMTP id r2mr7994877ejc.172.1642887252031; Sat, 22 Jan 2022 13:34:12 -0800 (PST) MIME-Version: 1.0 References: <11050_1642436674_61E59842_11050_100_1_0d0176823ddd4cb4ad825e3ee88445a3@orange.com> <6217_1642787863_61EAF417_6217_204_1_8dd254d74cdc46e58328d6889c6984a2@orange.com> In-Reply-To: <6217_1642787863_61EAF417_6217_204_1_8dd254d74cdc46e58328d6889c6984a2@orange.com> From: Greg Mirsky Date: Sat, 22 Jan 2022 13:34:00 -0800 Message-ID: To: Bruno Decraene Cc: mpls , "pals@ietf.org" , DetNet WG Content-Type: multipart/alternative; boundary="000000000000103d1305d6327fc7" Archived-At: Subject: Re: [mpls] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id 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, 22 Jan 2022 21:34:21 -0000 --000000000000103d1305d6327fc7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bruno, thank you for your detailed response to my notes. I am looking forward to the new version of the draft and continued discussion. Regards, Greg On Fri, Jan 21, 2022 at 9:57 AM wrote: > Hi Greg, > > > > Thank you for the follow up. Please see inline [Bruno2] > > > > > > Orange Restricted > > *From:* Greg Mirsky > *Sent:* Friday, January 21, 2022 2:09 AM > *To:* DECRAENE Bruno INNOV/NET > *Cc:* mpls ; pals@ietf.org; DetNet WG > *Subject:* Re: [mpls] Continuing with my comments on > draft-decraene-mpls-slid-encoded-entropy-label-id > > > > Hi Bruno, > > thank you for your kind consideration of my comments. Please > find follow-up notes in-line below under the GIM>> tag. > > > > Regards, > > Greg > > > > On Mon, Jan 17, 2022 at 8:24 AM wrote: > > Hi Greg, all > > > > Greg, thanks for taking the time to read the draft and comment. > > > > WG, for context, we are discussing a subset of the draft: the ability to > advertise indicator as part of the existing Entropy Label TTL as describe= d > in section 2 of the draft (it=E2=80=99s 1 page): > > > https://datatracker.ietf.org/doc/html/draft-decraene-mpls-slid-encoded-en= tropy-label-id-02#section-2 > > > > Please see inline [Bruno] > > > > > > Orange Restricted > > *From:* mpls *On Behalf Of *Greg Mirsky > *Sent:* Thursday, January 13, 2022 11:41 PM > *To:* mpls ; pals@ietf.org; DetNet WG > *Subject:* [mpls] Continuing with my comments on > draft-decraene-mpls-slid-encoded-entropy-label-id > > > > Hi Bruno, et al. > > Thank you for presenting this work at the MPLS Open DT meeting today. > Below please find the summary of my comments and questions with the > additional thoughts that came after we've closed the call. I greatly > appreciate the consideration and opinions of the authors and the group. > > - Compatibility with nodes that support only RFC 6790. > > > - If the proposed indicators are used to signal the presence of an > ISD, that seems to create a problem for an RFC6790-only node as it = might > not be able to process the ISD. > > [Bruno] > > - Draft(*) extends the use of the Entropy Label TTL field which is > essentially specified as a Reserved field in RFC 6790. Hence draft is > backward compatible with RFC 6790. > > GIM>> I agree, that if the mechanism is limited to re-use of the TTL > field of the label element that includes the entropy label, then there ar= e > no possible issues. But then, how useful is a mechanism that allows for > only seven indicators of processing instructions? Of course, if the model > does not support a combination of instructions, then the new field might = be > viewed not as a set of flags but as a scalar with each value defining a > different processing type. > > [Bruno2] Thank you for acknowledging that it would work. In terms of > possible usages, the draft lists 3 ones in sections 3, 4 and 5. > > > > - Draft does not specify ISD so this is out of scope of this draft. That > been said: > > - You are right that before sending ISD in a new extension, the > capability for the receiver/egress to support this ISD needs to be known = by > the sender. This is priori required by all ISD solution. > > - You seemed to assume that ISD are always necessary but IMHO indicators > and ISD are two different extensions and Indicators may be used without I= SD > extensions .e.g., cf sections 4, 5, 3 of the draft > > GIM>> I agree, that in some scenarios the ability to signal processing in > a label stack is sufficient and useful. Though, having a method of doing = a > subset of what can be done with Ancillary Data and Action indication seem= s > like an unnecessary overlap. > > [Bruno2] Thank you for the agreement. If one/a use case wants to > advertise more data, it=E2=80=99s possible to extend the proposal (actual= ly one > should be published shortly) > > > - If one of the indicators is to be used to signal the presence of the > extension, that, similarly to the scenario above, might not be corr= ectly > processed by an RFC6790-only node. > > [Bruno] idem > > - Scaling > > > - If the proposed method to signal the ancillary data is used in, for > example, a strict explicit routing environment, the Entropy Label i= s not > needed. If that is the case, using the indicators, as described in = the > draft, seems to waste 20 bits in a label element compared to the me= chanism > proposed in draft-kompella-mpls-mspl4fa. > > [Bruno] And for all other cases, the scaling is very good as we carry > indicators with zero extra label. So the net benefit is dependent of the > relative usage of strict explicit routing traffic vs traffic which can be > ECMP. In my environment, the latter is much more prevalent, hence the net > benefit is positive. > > GIM>> I agree that there are cases and scenarios when seven indicators ca= n > solve the operator's immediate problems. Though I believe that a > future-proof solution is preferable. > > [Bruno2] If needed, I believe that this proposal may be extended for the > use cases that would require more. I see no reason for such extension to > not be equally future-proof. > > > > Regards, > > --Bruno > > > > PS : by =C2=AB draft =C2=BB I mean section 2 of the draft as this is the = scope of > the discussion. > > Regards, > > -Bruno > > Regards, > > Greg > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --000000000000103d1305d6327fc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bruno,
thank you for your detailed response to my n= otes. I am looking forward=C2=A0to the new version of the draft and continu= ed discussion.

Regards,
Greg
=
On Fri= , Jan 21, 2022 at 9:57 AM <= bruno.decraene@orange.com> wrote:

Hi Greg,

=C2=A0

Thank you for the follow up. Please see inline [Brun= o2]

=C2=A0

=C2=A0

Orange Restricted

From: Greg Mirsky <gregimirsky@gmail.co= m>
Sent: Friday, January 21, 2022 2:09 AM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>
Cc: mpls <mpls= @ietf.org>; pals@= ietf.org; DetNet WG <detnet@ietf.org>
Subject: Re: [mpls] Continuing with my comments on draft-decraene-mp= ls-slid-encoded-entropy-label-id

=C2=A0

Hi Bruno,

thank you for your kind consideration of my comments= . Please find=C2=A0follow-up notes in-line below under the GIM>> tag.=

=C2=A0

Regards,

Greg

=C2=A0

On Mon, Jan 17, 2022 at 8:24 AM <bruno.decraene@orange.com> wrote:

Hi Greg, all

=C2=A0

Greg, thanks for taking the time to read the draft a= nd comment.

=C2=A0

WG, for context, we are discussing a subset of the d= raft: the ability to advertise indicator as part of the existing Entropy Label TTL as described in sectio= n 2 of the draft (it=E2=80=99s 1 page):

https://datatracker.ietf.org/doc/html/draft-decraene-mpls-slid-encoded-= entropy-label-id-02#section-2

=C2=A0

Please see inline [Bruno]

=C2=A0

=C2=A0

Orange Restricted

From: mpls <mpls-bounces@ietf.org> On Behalf Of Greg Mirsky
Sent: Thursday, January 13, 2022 11:41 PM
To: mpls <mpls= @ietf.org>; pals@ietf.org; DetNe= t WG <detnet@ietf.o= rg>
Subject: [mpls] Continuing with my comments on draft-decraene-mpls-s= lid-encoded-entropy-label-id

=C2=A0

Hi Bruno, et al.

Thank you for presenting this work at the MPLS Open = DT meeting today. Below please find the summary of my comments and question= s with the additional thoughts that came after we've closed the call. I greatly appreciate the consideration and opinions of th= e authors and the group.

  • Compatibility with nodes that support only RFC 6790.
      • If the proposed indicators are used to signal the presence of an ISD, that = seems to create a problem for an RFC6790-only node as it might not be able = to process the ISD.

    [Bruno]

    - Draft(*) extends the use of the Entropy Label TTL = field which is essentially specified as a Reserved field in RFC 6790. Hence draft is backward compati= ble with RFC 6790.

GIM>> I agree, that if the mechanism is limite= d to re-use of the TTL field=C2=A0of the label element that includes the en= tropy label, then there are no possible issues. But then, how useful is a m= echanism that allows for only seven indicators of processing instructions? Of course, if the model does not support a com= bination of instructions, then the new field might be viewed not as a set o= f flags but as a scalar with each value defining a different processing typ= e.

[Bruno2] Thank you for acknowledging that it would w= ork. In terms of possible usages, the draft lists 3 ones in sections 3, 4 and 5.

=C2=A0

- Draft does not specify ISD so this is out of scope= of this draft. That been said:

= -=C2=A0 You are right that before sending ISD in a new extension, the capab= ility for the receiver/egress to support this ISD needs to be known by the = sender. This is priori required by all ISD solution.

= - You seemed to assume that ISD are always necessary but IMHO indicators an= d ISD are two different extensions and Indicators may be used without ISD e= xtensions .e.g., cf sections 4, 5, 3 of the draft

GIM>> I agree, that in some scenarios the abil= ity to signal processing in a label stack is sufficient and useful. Though,= having a method of doing a subset of what can be done with Ancillary Data = and Action indication seems like an unnecessary overlap.

[Bruno2] Thank you for the agreement. If one/a use case wants to advertise more data, it=E2=80=99s possible to exte= nd the proposal (actually one should be published shortly)=

    • If one of the indicators is=C2=A0to be used to signal = the presence=C2=A0of the extension, that, similarly to the scenario above, = might not be correctly processed by an RFC6790-only node.

[Bruno] idem

  • Scaling
    • If the proposed method to signal the ancillary data is used in, for example= , a strict explicit routing environment, the Entropy Label is not needed. I= f that is the case, using the indicators, as described in the draft, seems = to waste 20 bits in a label element compared to the mechanism proposed in draft-kompella-mpls-mspl4fa.<= u>

[Bruno] And for all other cases, the scaling is very= good as we carry indicators with zero extra label. So the net benefit is dependent of the relative usa= ge of strict explicit routing traffic vs traffic which can be ECMP. In my e= nvironment, the latter is much more prevalent, hence the net benefit is pos= itive.

GIM>> I agree that there are cases and scenari= os when seven indicators can solve the operator's=C2=A0immediate proble= ms. Though I believe that a future-proof solution is preferable.<= /u>

[Bruno2] If needed, I believe that this proposal may= be extended for the use cases that would require more. I see no reason for= such extension to not be equally future-proof.

=C2=A0

Regards,

--Bruno

=C2=A0

PS=C2=A0: by =C2=AB=C2=A0draft=C2=A0=C2=BB I mean se= ction 2 of the draft as this is the scope of the discussion.<= u>

Regards,

-Bruno

Regards,

Greg

______________________________________________________________________=
___________________________________________________
=C2=A0
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les me=
ssages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
=C2=A0
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
u>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--000000000000103d1305d6327fc7-- From nobody Mon Jan 24 13:27:32 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED1F3A0E81 for ; Mon, 24 Jan 2022 13:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=opensourcerouting-org.20210112.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 vaBq5MqhD5ox for ; Mon, 24 Jan 2022 13:27:25 -0800 (PST) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 1C2C83A0E7A for ; Mon, 24 Jan 2022 13:27:24 -0800 (PST) Received: by mail-ej1-x635.google.com with SMTP id a8so25037632ejc.8 for ; Mon, 24 Jan 2022 13:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opensourcerouting-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AGd6VL2aXSW+DjMllLeZL3/O9+F4DMKa+YPaEkfB1m4=; b=SKcM7rWN/cS//CLq/Vfx9YcWn9yFRkpBaGEs3GlS7h4Ly7mEkQVmUAgQP95V2uHsFS b+FPR29KpIC31O6/6dc2Pvus+nIYsPIDXQ8+DFONdVPZmFVB2FAKljNIzOhVUAGDmooP i6YYbUUUet5e4uHd+/fIYRtAQI6+NXL/1lhPyFLnx1zUkuwu+KccJOQ0fkapsO3dsyAi sQT2tvS/7mY+hCFKwxsV8MgCBbNM5lZjMPzqhol/2yNvauqPljTC9L0TCo/LpK0m0cAN dGcW+ZUgmmYXGg33KLI+awckoX6pPU3uMlpOX0bf2Bf4Clhu1xKHkkVsTO7PWw8zngyD ukFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AGd6VL2aXSW+DjMllLeZL3/O9+F4DMKa+YPaEkfB1m4=; b=0FkGzFV+1eR9GbNUhEbyeBo+RDFkEmQphUYyi7r9Swc2ijpGFymSksEYlBzJjcsIzz gY3KpeQLyMJZPTgAXFp4HrLaqNpsksZD5er5msSMcQptrXuin1gO3bE4MycfEbDxcWmz Ngrb/7af3lqZVnDYIchkFt4K3A+8ZxW38DbcaideKlICssaGxT+UIGUVZBiKtlWSEzWF eOhIZ87vUoveDP4ZhmLBAMXCwuhOZ6CsFZN1V9kIlw5sE6Gu0a1W1oiFr/91HVxKS78N I5ZtDGRQUb+NN9LlewLxFjsTu7Xpnvl88Q5YPdLkGyRytQhKBMkorr7pb/jeW2fFmsGV xqZQ== X-Gm-Message-State: AOAM532ZPH2/6wCKs1FXTgiYlnuEWx/IBZ82zuucV1Iqi0Igs7VMWAWl 3/h/usZS+gQPASTNVfgiTI/J3wHdLh0l+DV2INDh0h25YcRg3b+v X-Google-Smtp-Source: ABdhPJy7aFDxXbxzZ370296CfQLvX0w5ILRmifcv1IkBmevts6P/nP93KPLkLTdU9UTz+GQIRFEHPf8BzSbEgECCfII= X-Received: by 2002:a17:907:1609:: with SMTP id hb9mr5766981ejc.203.1643059642599; Mon, 24 Jan 2022 13:27:22 -0800 (PST) MIME-Version: 1.0 References: <20220120162429.GE83846@fg-networking.de> In-Reply-To: <20220120162429.GE83846@fg-networking.de> From: Renato Westphal Date: Mon, 24 Jan 2022 18:27:11 -0300 Message-ID: To: Erik Auerswald Cc: draft-ietf-mpls-ldp-yang.all@ietf.org, mpls@ietf.org Content-Type: multipart/alternative; boundary="00000000000057a22505d65aa262" Archived-At: Subject: Re: [mpls] Review of draft-ietf-mpls-ldp-yang-09 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, 24 Jan 2022 21:27:30 -0000 --00000000000057a22505d65aa262 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Em qui., 20 de jan. de 2022 =C3=A0s 13:24, Erik Auerswald < auerswald@fg-networking.de> escreveu: > Hello Renato, > > On Thu, Jan 20, 2022 at 12:40:48PM -0300, Renato Westphal wrote: > > [...] > > 4) I wonder if the following leaf is necessary: > > > > leaf lsr-id { > > type rt-types:router-id; > > description > > "Specify the value to act as the LDP LSR ID. > > If this attribute is not specified, LDP uses the router > > ID as determined by the system."; > > } > > > > Shouldn't the router-id leaf from the ietf-routing module be enough for > > this purpose? > > Many currently available routers allow to configure per-protocol and > (if applicable) per-process router-id values. I would not like if > implementing YANG based management would lose this capability. > Indeed. It seems however that most IGP models lack a router-id leaf. The OSPF module is an exception, where there's an explicit-router-id leaf guarded by a feature of the same name. It would be necessary to check previous discussions to understand the reason behind this. My suggestion to remove the lsr-id field was mostly in the vein of maintaining the LDP module consistent with the IGP modules (even though LDP isn't exactly an IGP). Regards, --=20 Renato Westphal --00000000000057a22505d65aa262 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
Em qui., 20 de jan. de 2022 =C3=A0s 1= 3:24, Erik Auerswald <auer= swald@fg-networking.de> escreveu:
Hello Renato,

On Thu, Jan 20, 2022 at 12:40:48PM -0300, Renato Westphal wrote:
> [...]
> 4) I wonder if the following leaf is necessary:
>
>=C2=A0 =C2=A0leaf lsr-id {
>=C2=A0 =C2=A0 =C2=A0type rt-types:router-id;
>=C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"Specify the value to act as the LDP LS= R ID.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 If this attribute is not specified, LDP use= s the router
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ID as determined by the system.";
>=C2=A0 =C2=A0}
>
> Shouldn't the router-id leaf from the ietf-routing module be enoug= h for
> this purpose?

Many currently available routers allow to configure per-protocol and
(if applicable) per-process router-id values.=C2=A0 I would not like if
implementing YANG based management would lose this capability.

Indeed. It seems however that most IGP models lack = a router-id leaf. The OSPF module is an exception, where there's an exp= licit-router-id leaf guarded by a feature of the same name. It would be nec= essary to check previous discussions to understand the reason behind this.<= br>
My suggestion to remove the lsr-id field was mostly in the vein of m= aintaining the LDP module consistent with the IGP modules (even though LDP = isn't exactly an IGP).

Regards,=C2=A0
--
Renato Westphal
--00000000000057a22505d65aa262-- From nobody Mon Jan 24 13:59:34 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CE13A1132 for ; Mon, 24 Jan 2022 13:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=opensourcerouting-org.20210112.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 U_TaX9qW60H3 for ; Mon, 24 Jan 2022 13:59:26 -0800 (PST) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1F753A1134 for ; Mon, 24 Jan 2022 13:59:25 -0800 (PST) Received: by mail-ej1-x631.google.com with SMTP id o12so25304112eju.13 for ; Mon, 24 Jan 2022 13:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opensourcerouting-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q6XcEvPmwtqf3nQGKKdp7tULTnDp9uPnZj5GaZRV6nY=; b=Vtm4igZKvTlCs3B+/atkxp0LdjavX0ZDU8RSY2OvUpbJ+XIEtI0bwIpwiqBnt1Ea9r RaHJQPPNpTeD9CD/eANKW0BxXENuZXRto2j+Lyhu4N9YxH0N9n6iEAlopUAXa1aFpesP RMCepdmGU6ODti3lK+4ksLBoo5/vIOa+Lk3qKHCP9pDHqOAE94kfNzJAxuIgHGLs5Z4D vLCUP0PvGeAn8k1FCyGXDY5aFwGystGltVhuQZ05L4gDhfkXvR1BQy5472oWW2AckWHW kQ5fHLJ8MurcM5ybTTZviX9tmsypwjLokQWXqH8aGTEwT88cBgL2chgg92SV2XQB7mmn AO0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q6XcEvPmwtqf3nQGKKdp7tULTnDp9uPnZj5GaZRV6nY=; b=4KDmcfSTR42oyS4Z9fowaE7oTBblxLl3vF/03e7TuBPHUyYyQs5ipUqOMocum2RjBA FNhSyXyjfsxj6b50mKZtvdHQSxYK4uboWsslLz36Ud4u0Wyi+xV3usBvcqZKWx0dn2w6 NowFpUexUtHyeZbPYJtCQ/uyVq6Sd0leGWA9VEQ5ikc9Iat4QRVPrK+vkJCoey95qWdO wBjF+uGdxXi9ZDie18WNt7AQFXoX5iNyrYv3cQwXRz0j7T+PqSfL5FpWF+YkCvkgZpd3 x8IGwAfzl5XjhPixk1jsWvZpem+fKsTAd8YRBcTEduQ+UEkR36UvrpKUl3Zr/TL9jHmz UhSw== X-Gm-Message-State: AOAM532SgwXhqDPV1fEb9oOmCYzUNt6+O2ZTuhqq6GlmqAhMNosP9+jA t0wB4FNtc29YMkjLhaNCqikSQ+KrRm82NoJKZ9AEEA== X-Google-Smtp-Source: ABdhPJzT+ie1Hot6qP5XdgjdFy/OGJYC/Gix1rCSzTsynOt4JMyrzezFB8eJvEoVNMpthX8CDJ3sLRfveCEWs07X82w= X-Received: by 2002:a17:907:7244:: with SMTP id ds4mr6084200ejc.208.1643061563142; Mon, 24 Jan 2022 13:59:23 -0800 (PST) MIME-Version: 1.0 References: <66F8F012-E804-49CE-8890-4941CC10AB61@cisco.com> In-Reply-To: <66F8F012-E804-49CE-8890-4941CC10AB61@cisco.com> From: Renato Westphal Date: Mon, 24 Jan 2022 18:59:11 -0300 Message-ID: To: "Rajiv Asati (rajiva)" Cc: "draft-ietf-mpls-ldp-yang.all@ietf.org" , "mpls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d0da7405d65b144e" Archived-At: Subject: Re: [mpls] Review of draft-ietf-mpls-ldp-yang-09 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, 24 Jan 2022 21:59:32 -0000 --000000000000d0da7405d65b144e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for taking the time to answer my questions Rajiv. Please see my comments inline. Em qui., 20 de jan. de 2022 =C3=A0s 20:09, Rajiv Asati (rajiva) escreveu: > Hi Renato, > > > > Thanks for the feedback to the WG document. This really helps us to build > a solid spec. > > > > 1. You are right about adjacency configuration (RW) and adjacency state > (RO). The spec well covers all of those. > > > > The flag you referred to is defined as ReadOnly (RO) for operational > state, exactly as you pointed out, to capture the neighbor being active o= r > passive. Not for config. Hello-adjacencies below is a container, btw, tha= t > includes both tx and rx adjacencies. > > > > | | | | +--ro hello-adjacencies > > | | | | | +--ro hello-adjacency* [adjacent-address] > > > > | | | +--ro flag* identityref > > < > > > > > container hello-adjacencies { > > =E2=80=A6 > > uses ldp:adjacency-state-attributes; > > > > Config (RW) for targeted neighbor covers what you suggested well - > > | +--rw targeted > > | +--rw hello-holdtime? uint16 > > | +--rw hello-interval? uint16 > > | +--rw hello-accept > > | | +--rw enabled? boolean > > | | +--rw ldp-ext:neighbor-list? neighbor-list-ref > Ack. If I understood correctly, an active adjacency means that hello messages are both being sent and received, whereas a passive adjacency is only receiving but not sending hellos (can only happen for targeted adjacencies). While a find the adjacency-flag descriptions a bit confusing, the distinction between active and passive adjacencies makes sense. > 2. Targeted neighbor is not bound to an interface (per RFC5036), so that > interface leaf you referred to is actually not part of targeted discovery > container, rather basic discovery container (which indeed allows for one = or > more interfaces per neighbor). > > > > container hello-adjacencies { > > config false; > > description > > "Containing a list of Hello adjacencies."; > > . . . . . . > > leaf interface { > > type if:interface-ref; > > description "Interface for this adjacency."; > That leaf lies indirectly under the peer list: /ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-m= pls-ldp:mpls-ldp/peers/peer/address-families/ipv4/hello-adjacencies/hello-a= djacency/interface That means it's present for both basic and extended adjacencies as far as I understand it. > 3. You are right that a neighbor can be discovered via both basic and > extended discovery. What you point out is well covered in the tree in two > distinct places =E2=80=93 one for basic and the other for extended/target= ed. Pls > see section 6.1 and figure 5. > > > > +--rw discovery > > +--rw interfaces > > | +--rw interface* [interface] > > | +--rw address-families > > | +--rw ipv4 > > | +--ro hello-adjacencies > > | +--ro hello-adjacencies* [adjacent-address] > > | +--ro adjacent-address > > | . . . . > > | . . . . > > +--rw targeted > > +--rw address-families > > +--rw ipv4 > > +--ro hello-adjacencies > > +--ro hello-adjacencies* > > | [local-address adjacent-addres= s] > > +--ro local-address > > +--ro adjacent-address > > . . . . > > . . . . > The problem is that there's also a hello-adjacency list within the peer list. There interface and targeted adjacencies are displayed together, and their keys might collide and overlap one another. > Also, page#52 clarifies the following for local-address - > > > > leaf local-address { > > type inet:ipv4-address; > > description > > "The local address used as the source address to > > send targeted Hello messages. > > If the value is not specified, the > > transport-address is used as the source > > address."; > That's the description of the local-address configuration leaf for targeted neighbors. In my previous comment, I was referring to the local-address state leaf from lines 1167 and 1276. Upon further thought, I think those leafs descriptions are actually fine. It should only make sense to display the IP source address as the transport address would be the same for all adjacencies. > 4. Good point about a good =E2=80=9Cdeployment=E2=80=9D practice for diff= erent protocols > to leverage the same router-id. However, LDP protocol (RFC5036) specifies > LSR-ID and allows it to be different, if/as needed (independent of that, > one can choose different LSR ID for different VRFs on a node). > > > > Thankfully, the team agreed to keep the default along the line of what yo= u > pointed. > > > Ack, thanks for the clarification. The fact that RFC5036 doesn't mandate the LSR-ID to use the Router-ID (for the first four bytes) is a good argument to preserve the lsr-id leaf. Regarding your second point, I think one should be able to use YANG schema mount to set different ietf-routing's Router-IDs for different VRFs. If it wasn't for that, all IGP models would need to have a router-id leaf as well (which they don't). > 5. Well, think of IPv6-only node, which unfortunately needs to have IPv4 > for OOB management access. That would result in LDP IPv4 AFI being enable= d > by default, and hence, would need to be explicitly disabled via this > container. > > > > I will let my co-authors add further clarification. > > I think that makes sense for the ipv4 presence container within "global/address-families". For LDP neighbors, I can see no use for an "ipv4" presence container (instead of a regular container). > 6. Yes, it does apply. > > And that configuration will allow for the targeted adjacency to be > created for 1.1.1.1, but peering relationship will be denied. If the > intent is to not let the targeted adjacency be created, then policy could > be created to deny 1.1.1.1. > Ack. Thanks for the clarification! > Wrt custom hello/hold timers per targeted neighbors, AFAIK, RFC5036 > doesn=E2=80=99t specify that, nor do any of the implementations. > > Only custom hello/hold timers global config. > Ack. > 7. AFAIK, this is because of RFC5036 that specifies 5s to be the lowest > hello interval. =F0=9F=98=8A > > > > https://datatracker.ietf.org/doc/html/rfc5036#section-3.5.2 > I couldn't find in that RFC section any reference to a minimum allowed hello interval. Could you precise which excerpt you're using as a reference= ? For what it's worth, I've seen numerous vendors supporting smaller hello interval and holdtime values. Also, maybe it would be a good idea to support infinite hold-time values (0xffff) as they are specified by RFC 5036. It doesn't seem like they are widely implemented though. > 8. Thanks for reviewing so diligently and pointing these typos out. > > Thankfully, our amazing RFC Editor team has fixed all of them (I just > checked their version) except interface=E2=80=99s counters (within the st= atistics > container), which I believe is correct (since it is about the node, not > about the peer). > I was referring to the statistics container within the peer-state-derived grouping [1]. There I think "interface=E2=80=99s counters" was a copy and p= aste error. I'm happy to know the other typos were already fixed :) [1] Full path to be precise: /ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-m= pls-ldp:mpls-ldp/peers/peer/statistics Regards, --=20 Renato Westphal --000000000000d0da7405d65b144e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for taking the time to answer m= y questions Rajiv. Please see my comments inline.

Em qui., 20 de jan. = de 2022 =C3=A0s 20:09, Rajiv Asati (rajiva) <rajiva@cisco.com> escreveu:

Hi Renato,

=C2=A0

Thanks for the feedback to the WG document. This rea= lly helps us to build a solid spec.

=C2=A0

1. You are right about adjacency configuration (RW) = and adjacency state (RO). The spec well covers all of those.

=C2=A0

The flag you referred to is defined as ReadOnly (RO)= for operational state, exactly as you pointed out, to capture the neighbor= being active or passive. Not for config. Hello-adjacencies below is a cont= ainer, btw, that includes both tx and rx adjacencies.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro hello-adjace= ncies

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro hell= o-adjacency* [adjacent-address]

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2= =A0=C2=A0 +--ro flag*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identityref

< >

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= container hello-adjacencies {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=A6

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 uses ldp:adjacency-state-attributes;=

=C2=A0

Config (RW) for targeted neighbor covers what you su= ggested well -

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0 +--rw targeted

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--rw hello-holdtime?=C2=A0=C2=A0=C2=A0=C2= =A0 uint16

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--rw hello-interval?=C2=A0=C2=A0=C2=A0=C2= =A0 uint16

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--rw hello-accept

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--rw enabled?=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 boolean

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--rw ldp-ext:neighbor-list?=C2=A0= =C2=A0 neighbor-list-ref


=
Ack. If I understood correctly, an active adjacency means that hello m= essages are both being sent and received, whereas a passive adjacency is on= ly receiving but not sending hellos (can only happen for targeted adjacenci= es).

While a find the adjacency-flag descriptions a bit confusing,= the distinction between active and passive adjacencies makes sense.
= =C2=A0

2.=C2=A0 Targeted neighbor is not bound to an interf= ace (per RFC5036), so that interface leaf you referred to is actually not p= art of targeted discovery container, rather basic discovery container (whic= h indeed allows for one or more interfaces per neighbor).

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= container hello-adjacencies {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 config false;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 description

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 "Containing a list of Hello adjacencies."= ;;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 . . . . . .=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 leaf interface {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type if:interface-ref;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description "Interface for this a= djacency.";


That lea= f lies indirectly under the peer list: /ietf-routing:routing/control-plane-= protocols/control-plane-protocol/ietf-mpls-ldp:mpls-ldp/peers/peer/address-= families/ipv4/hello-adjacencies/hello-adjacency/interface

That = means it's present for both basic and extended adjacencies as far as I = understand it.
=C2=A0

3. You are right that a neighbor can be discovered v= ia both basic and extended discovery. What you point out is well covered in= the tree in two distinct places =E2=80=93 one for basic and the other for = extended/targeted. Pls see section 6.1 and figure 5.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +--rw discovery

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--rw interfaces

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0 +--rw interface* [interface]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--rw address-families<= u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw ipv4

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 +--ro hello-adjacencies

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +--ro hello-adjacencies* [adjacent-address]=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro adjacent-address=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 . . . .=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 . . . .=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--rw targeted

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw address-families

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+--rw ipv4=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-= -ro hello-adjacencies

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 +--ro hello-adjacencies*

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [local-address adjacent-addre= ss]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 +--ro local-address

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0+--ro adjacent-address

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 . . . .

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 problem is that there's a= lso a hello-adjacency list within the peer list. There interface and target= ed adjacencies are displayed together, and their keys might collide and ove= rlap one another.
=C2=A0=C2=A0

Also, page#52 clarifies the following for local-addr= ess -

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf local-add= ress {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ty= pe inet:ipv4-address;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 de= scription

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=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 local address used as the source address 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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 send targeted Hello messages.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 If the value is not specified, 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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 transport-address is used as the source

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 address.";

=C2= =A0
That's the description of the local-address configuration= leaf for targeted neighbors. In my previous comment, I was referring to th= e local-address state leaf from lines 1167 and 1276.

Upon further th= ought, I think those leafs descriptions are actually fine. It should only m= ake sense to display the IP source address as the transport address would b= e the same for all adjacencies.
=C2=A0

4. Good point about a good =E2=80=9Cdeployment=E2=80= =9D practice for different protocols to leverage the same router-id. Howeve= r, LDP protocol (RFC5036) specifies LSR-ID and allows it to be different, i= f/as needed (independent of that, one can choose different LSR ID for different VRFs on a node).

=C2=A0

Thankfully, the team agreed to keep the default alon= g the line of what you pointed. =C2=A0


=C2=A0<= /div>
Ack, thanks for the clarification.

The fact that RFC5036 d= oesn't mandate the LSR-ID to use the Router-ID (for the first four byte= s) is a good argument to preserve the lsr-id leaf. Regarding your second po= int, I think one should be able to use YANG schema mount to set different i= etf-routing's Router-IDs for different VRFs. If it wasn't for that,= all IGP models would need to have a router-id leaf as well (which they don= 't).
=C2=A0

5. Well, think of IPv6-only node, which unfortunatel= y needs to have IPv4 for OOB management access. That would result in LDP IP= v4 AFI being enabled by default, and hence, would need to be explicitly dis= abled via this container.

=C2=A0

I will let my co-authors add further clarification.<= u>


I think that makes sense for the ipv4 presence con= tainer within "global/address-families". For LDP neighbors, I can= see no use for an "ipv4" presence container (instead of a regula= r container).
=C2=A0

6. Yes, it does apply.

And =C2=A0that configuration will allow for the targ= eted adjacency to be created for 1.1.1.1, but peering relationship will be = denied.=C2=A0 If the intent is to not let the targeted adjacency be created= , then policy could be created to deny 1.1.1.1.


Ack. Thanks for the clarification!
=C2= =A0

Wrt custom hello/hold timers per targeted neighbors,= AFAIK, RFC5036 doesn=E2=80=99t specify that, nor do any of the implementat= ions.

Only custom hello/hold timers global config.


Ack.
=C2=A0

7. AFAIK, this is because of RFC5036 that specifies = 5s to be the lowest hello interval. =C2=A0=F0=9F=98=8A

=C2=A0

https://datatracker.ietf.org/doc/html= /rfc5036#section-3.5.2


= I couldn't find in that RFC section any reference to a minimum allowed = hello interval. Could you precise which excerpt you're using as a refer= ence?

For what it's worth, I've seen numerous vendors suppor= ting smaller hello interval and holdtime values.

Also, maybe it woul= d be a good idea to support infinite hold-time values (0xffff) as they are = specified by RFC 5036. It doesn't seem like they are widely implemented= though.
=C2=A0

8. Thanks for reviewing so diligently and pointing t= hese typos out.

Thankfully, our amazing RFC Editor team has fixed al= l of them (I just checked their version) except interface=E2=80=99s counter= s (within the statistics container), which I believe is correct (since it i= s about the node, not about the peer).

I was referring to the statistics container within the peer-sta= te-derived grouping [1]. There I think "interface=E2=80=99s counters&q= uot; was a copy and paste error.

I'm happy to know the other typ= os were already fixed :)

[1] Full path to be precise: /ietf-routing:= routing/control-plane-protocols/control-plane-protocol/ietf-mpls-ldp:mpls-l= dp/peers/peer/statistics

Regards,
-= -
Renato Westphal
--000000000000d0da7405d65b144e-- From nobody Tue Jan 25 05:01:56 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAD53A0EE6; Tue, 25 Jan 2022 05:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQ1T4c0nv7X4; Tue, 25 Jan 2022 05:01:50 -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 C97173A0EF2; Tue, 25 Jan 2022 05:01:48 -0800 (PST) Received: from [192.168.1.98] (unknown [112.206.242.125]) (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 0AD7F365F9C; Tue, 25 Jan 2022 14:01:44 +0100 (CET) Message-ID: Date: Tue, 25 Jan 2022 21:01:40 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-CA To: "mpls@ietf.org" Cc: "mpls-chairs@ietf.org" From: Loa Andersson Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] Where did the wg chair go? 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, 25 Jan 2022 13:01:55 -0000 Working Group / Open DT, I#m now almost recovered from an infection by the Omicron variant of the Corona virus. It has been two tough weeks, but I'm now ready to start working again. We will have an Open DT meeting on Thursday. I will try to get the agenda out in reasonable time, but probably just before the meeting starts. If you have items to be discussed plz let me know. Also if you hsve documents that you suspect has fallen between the chairs, please notify my. /Loa -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Tue Jan 25 18:11:23 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E9A3A1BC7; Tue, 25 Jan 2022 18:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3j3_87H3mR9; Tue, 25 Jan 2022 18:11:11 -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 8D00F3A1BC5; Tue, 25 Jan 2022 18:11:10 -0800 (PST) Received: from [192.168.1.98] (unknown [112.206.242.125]) (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 5B43A365FBD; Wed, 26 Jan 2022 03:11:06 +0100 (CET) Message-ID: <7de9f8f4-c60a-f867-1cf5-b2f0ad939c54@pi.nu> Date: Wed, 26 Jan 2022 10:11:03 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-CA To: Greg Mirsky , Bruno Decraene Cc: mpls , DetNet WG , "pals@ietf.org" References: <11050_1642436674_61E59842_11050_100_1_0d0176823ddd4cb4ad825e3ee88445a3@orange.com> <6217_1642787863_61EAF417_6217_204_1_8dd254d74cdc46e58328d6889c6984a2@orange.com> From: Loa Andersson In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [mpls] [Detnet] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id 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, 26 Jan 2022 02:11:16 -0000 Bruno, Greg, wg, The Open DT are working on a method for Indicators and Ancillary data, based mostly on draft-kompella-mpls-mspl4fa and draft-bocci-mpls-miad-adi-requirements. why is it obvious that the "SPRING version" should not be part of that solution? Kireeti, BTW draft-kompella-mpls-mspl4fa has expired, plz revive. /Loa On 23/01/2022 05:34, Greg Mirsky wrote: > Hi Bruno, > thank you for your detailed response to my notes. I am looking > forward to the new version of the draft and continued discussion. > > Regards, > Greg > > On Fri, Jan 21, 2022 at 9:57 AM > wrote: > > Hi Greg,____ > > __ __ > > Thank you for the follow up. Please see inline [Bruno2]____ > > __ __ > > __ __ > > Orange Restricted____ > > *From:*Greg Mirsky > > *Sent:* Friday, January 21, 2022 2:09 AM > *To:* DECRAENE Bruno INNOV/NET > > *Cc:* mpls >; pals@ietf.org > ; DetNet WG > > *Subject:* Re: [mpls] Continuing with my comments on > draft-decraene-mpls-slid-encoded-entropy-label-id____ > > __ __ > > Hi Bruno,____ > > thank you for your kind consideration of my comments. Please > find follow-up notes in-line below under the GIM>> tag.____ > > __ __ > > Regards,____ > > Greg____ > > __ __ > > On Mon, Jan 17, 2022 at 8:24 AM > wrote:____ > > Hi Greg, all____ > > ____ > > Greg, thanks for taking the time to read the draft and comment.____ > > ____ > > WG, for context, we are discussing a subset of the draft: the > ability to advertise indicator as part of the existing Entropy > Label TTL as described in section 2 of the draft (it’s 1 page):____ > > https://datatracker.ietf.org/doc/html/draft-decraene-mpls-slid-encoded-entropy-label-id-02#section-2 > ____ > > ____ > > Please see inline [Bruno]____ > > ____ > > ____ > > Orange Restricted____ > > *From:* mpls > *On Behalf Of *Greg Mirsky > *Sent:* Thursday, January 13, 2022 11:41 PM > *To:* mpls >; pals@ietf.org > ; DetNet WG > > *Subject:* [mpls] Continuing with my comments on > draft-decraene-mpls-slid-encoded-entropy-label-id____ > > ____ > > Hi Bruno, et al.____ > > Thank you for presenting this work at the MPLS Open DT meeting > today. Below please find the summary of my comments and > questions with the additional thoughts that came after we've > closed the call. I greatly appreciate the consideration and > opinions of the authors and the group.____ > > * Compatibility with nodes that support only RFC 6790.____ > > o If the proposed indicators are used to signal the > presence of an ISD, that seems to create a problem for > an RFC6790-only node as it might not be able to process > the ISD.____ > > [Bruno]____ > > - Draft(*) extends the use of the Entropy Label TTL field which > is essentially specified as a Reserved field in RFC 6790. Hence > draft is backward compatible with RFC 6790.____ > > GIM>> I agree, that if the mechanism is limited to re-use of the TTL > field of the label element that includes the entropy label, then > there are no possible issues. But then, how useful is a mechanism > that allows for only seven indicators of processing instructions? Of > course, if the model does not support a combination of instructions, > then the new field might be viewed not as a set of flags but as a > scalar with each value defining a different processing type.____ > > [Bruno2] Thank you for acknowledging that it would work. In terms of > possible usages, the draft lists 3 ones in sections 3, 4 and 5. ____ > > __ __ > > - Draft does not specify ISD so this is out of scope of this > draft. That been said:____ > > -  You are right that before sending ISD in a new extension, the > capability for the receiver/egress to support this ISD needs to > be known by the sender. This is priori required by all ISD > solution.____ > > - You seemed to assume that ISD are always necessary but IMHO > indicators and ISD are two different extensions and Indicators > may be used without ISD extensions .e.g., cf sections 4, 5, 3 of > the draft____ > > GIM>> I agree, that in some scenarios the ability to signal > processing in a label stack is sufficient and useful. Though, having > a method of doing a subset of what can be done with Ancillary Data > and Action indication seems like an unnecessary overlap.____ > > [Bruno2] Thank you for the agreement. If one/a use case wants to > advertise more data, it’s possible to extend the proposal (actually > one should be published shortly)____ > > o If one of the indicators is to be used to signal the > presence of the extension, that, similarly to the > scenario above, might not be correctly processed by an > RFC6790-only node.____ > > [Bruno] idem ____ > > * Scaling____ > > o If the proposed method to signal the ancillary data is > used in, for example, a strict explicit routing > environment, the Entropy Label is not needed. If that is > the case, using the indicators, as described in the > draft, seems to waste 20 bits in a label element > compared to the mechanism proposed in > draft-kompella-mpls-mspl4fa.____ > > [Bruno] And for all other cases, the scaling is very good as we > carry indicators with zero extra label. So the net benefit is > dependent of the relative usage of strict explicit routing > traffic vs traffic which can be ECMP. In my environment, the > latter is much more prevalent, hence the net benefit is > positive.____ > > GIM>> I agree that there are cases and scenarios when seven > indicators can solve the operator's immediate problems. Though I > believe that a future-proof solution is preferable.____ > > [Bruno2] If needed, I believe that this proposal may be extended for > the use cases that would require more. I see no reason for such > extension to not be equally future-proof.____ > > __ __ > > Regards,____ > > --Bruno____ > > __ __ > > PS : by « draft » I mean section 2 of the draft as this is the > scope of the discussion.____ > > Regards,____ > > -Bruno____ > > Regards,____ > > Greg____ > > _____________________________________________________________________________________________________________________________ > > __ __ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc____ > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler____ > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,____ > > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.____ > > __ __ > > This message and its attachments may contain confidential or privileged information that may be protected by law;____ > > they should not be distributed, used or copied without authorisation.____ > > If you have received this email in error, please notify the sender and delete this message and its attachments.____ > > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.____ > > Thank you.____ > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Wed Jan 26 19:46:53 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E3A3A08D6; Wed, 26 Jan 2022 19:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7xpeZAYNUEN; Wed, 26 Jan 2022 19:46:46 -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 6A4C63A08CD; Wed, 26 Jan 2022 19:46:44 -0800 (PST) Received: from [192.168.1.98] (unknown [112.206.242.125]) (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 02F10365FE9; Thu, 27 Jan 2022 04:46:40 +0100 (CET) Message-ID: <4cebb7c0-8a18-13ad-a824-2f8788d7bf7d@pi.nu> Date: Thu, 27 Jan 2022 11:46:37 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Content-Language: en-CA To: "mpls@ietf.org" Cc: "mpls-chairs@ietf.org" , "pals-chairs@ietf.org" , DetNet Chairs From: Loa Andersson Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] agenda for the Open DT meeting 2022-01-27 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, 27 Jan 2022 03:46:51 -0000 Open DT, Please find the agenda for todays meeting at: https://trac.ietf.org/trac/mpls/wiki/2022-01-27-agenda /Loa -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Thu Jan 27 01:58:39 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9E13A1C7C; Thu, 27 Jan 2022 01:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 XoiHK4907iGZ; Thu, 27 Jan 2022 01:58:32 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (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 B63163A1C7B; Thu, 27 Jan 2022 01:58:31 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar23.francetelecom.fr (ESMTP service) with ESMTPS id 4JkwyZ1lDdzBsBK; Thu, 27 Jan 2022 10:58:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1643277510; bh=fPMga0xXj7u7Ga6oivyKdfi5G4+QzNSwURaBEg3/9M8=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=dxgcIMVy69etBgPy8asEY4B0vF0638DHCpp6t2kCMxL7X4IfHVd/9u2kdifbXtm68 WAbs7U/7/F/95vI4bl0YZ+Tp9PjK0mxRjEqjTUJOw88z0IWwmMcNTL0E8D4JUAN3rj W2obsPXEO2EpJiePf7H8tXuGLPvgkirxrLV5t98tS5RmGOQRY3zHnPaMDefGNVSrJb DyF2Cml8cNUV9GzB0Sh6xqzQRz513tMjCtzZ5MlKMTq46dxHKQEe/E4prE9eoUch7c 4SkHqZyrT/Vd9C2+kWGblVkrY9WUlZWGJ7hjowu9KNyPC4vUFVoM1WuuvAmJSCfWw8 MUWLpg/ipn7bw== From: To: Loa Andersson , Greg Mirsky CC: mpls , DetNet WG , "pals@ietf.org" Thread-Topic: [Detnet] [mpls] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id Thread-Index: AQHYEln4sWKwqr8hR0OAf/SOiUzheKx2oucA Date: Thu, 27 Jan 2022 09:58:29 +0000 Message-ID: <7549_1643277510_61F26CC6_7549_417_3_d5c7f361d8f44fb291e28d13b7d877a3@orange.com> References: <11050_1642436674_61E59842_11050_100_1_0d0176823ddd4cb4ad825e3ee88445a3@orange.com> <6217_1642787863_61EAF417_6217_204_1_8dd254d74cdc46e58328d6889c6984a2@orange.com> <7de9f8f4-c60a-f867-1cf5-b2f0ad939c54@pi.nu> In-Reply-To: <7de9f8f4-c60a-f867-1cf5-b2f0ad939c54@pi.nu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-01-27T09:58:28Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_enabled: true msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_setdate: 2022-01-27T09:58:28Z msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_method: Standard msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_name: Orange_restricted_external.2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_siteid: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_actionid: 605bcc89-81bf-448b-a217-083a6ed86f13 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_contentbits: 0 x-originating-ip: [10.115.27.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] [Detnet] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id 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, 27 Jan 2022 09:58:37 -0000 TG9hLA0KDQo+IEZyb206IExvYSBBbmRlcnNzb24gPGxvYUBwaS5udT4NCj4gU2VudDogV2VkbmVz ZGF5LCBKYW51YXJ5IDI2LCAyMDIyIDM6MTEgQU0NCj4gDQo+IEJydW5vLCBHcmVnLCB3ZywNCj4g DQo+IFRoZSBPcGVuIERUIGFyZSB3b3JraW5nIG9uIGEgbWV0aG9kIGZvciBJbmRpY2F0b3JzIGFu ZCBBbmNpbGxhcnkgZGF0YSwNCj4gYmFzZWQgbW9zdGx5IG9uIGRyYWZ0LWtvbXBlbGxhLW1wbHMt bXNwbDRmYSBhbmQNCj4gZHJhZnQtYm9jY2ktbXBscy1taWFkLWFkaS1yZXF1aXJlbWVudHMuDQoN CkFyZSB5b3Ugc2F5aW5nIHRoYXQgdGhlIHNvbHV0aW9uIChkcmFmdC1rb21wZWxsYS1tcGxzLW1z cGw0ZmEpIGhhcyBiZWVuIHNlbGVjdGVkIGFuZCBhbGwgb3RoZXJzIGRpc3JlZ2FyZGVkPw0KDQog DQo+IHdoeSBpcyBpdCBvYnZpb3VzIHRoYXQgdGhlICJTUFJJTkcgdmVyc2lvbiIgc2hvdWxkIG5v dCBiZSBwYXJ0IG9mIHRoYXQNCj4gc29sdXRpb24/DQoNCldoYXQgIlNQUklORyB2ZXJzaW9uIiBh cmUgeW91IHJlZmVycmluZyB0bz8NCg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL2RyYWZ0LWRlY3JhZW5lLW1wbHMtc2xpZC1lbmNvZGVkLWVudHJvcHktbGFiZWwtaWQN CmFuZCANCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtamFncy1t cGxzLWV4dC1oZHItZW50cm9weS1sYmwNCg0KQXJlIHRhcmdldGluZyB0aGUgTVBMUyBXRyBhbmQg YXJlIG5vdCBzcGVjaWZpYyB0byBTUFJJTkcgYXMgZmFyIGFzIEkgY2FuIHJlbWVtYmVyLg0KDQot LUJydW5vDQogDQo+IEtpcmVldGksDQo+IA0KPiBCVFcgZHJhZnQta29tcGVsbGEtbXBscy1tc3Bs NGZhIGhhcyBleHBpcmVkLCBwbHogcmV2aXZlLg0KPiANCj4gDQo+IC9Mb2ENCj4gDQo+IE9uIDIz LzAxLzIwMjIgMDU6MzQsIEdyZWcgTWlyc2t5IHdyb3RlOg0KPiA+IEhpIEJydW5vLA0KPiA+IHRo YW5rIHlvdSBmb3IgeW91ciBkZXRhaWxlZCByZXNwb25zZSB0byBteSBub3Rlcy4gSSBhbSBsb29r aW5nDQo+ID4gZm9yd2FyZMKgdG8gdGhlIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBhbmQgY29u dGludWVkIGRpc2N1c3Npb24uDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+IEdyZWcNCj4gPg0KPiA+ IE9uIEZyaSwgSmFuIDIxLCAyMDIyIGF0IDk6NTcgQU0gPGJydW5vLmRlY3JhZW5lQG9yYW5nZS5j b20NCj4gPiA8bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+PiB3cm90ZToNCj4gPg0K PiA+ICAgICBIaSBHcmVnLF9fX18NCj4gPg0KPiA+ICAgICBfXyBfXw0KPiA+DQo+ID4gICAgIFRo YW5rIHlvdSBmb3IgdGhlIGZvbGxvdyB1cC4gUGxlYXNlIHNlZSBpbmxpbmUgW0JydW5vMl1fX19f DQo+ID4NCj4gPiAgICAgX18gX18NCj4gPg0KPiA+ICAgICBfXyBfXw0KPiA+DQo+ID4gICAgIE9y YW5nZSBSZXN0cmljdGVkX19fXw0KPiA+DQo+ID4gICAgICpGcm9tOipHcmVnIE1pcnNreSA8Z3Jl Z2ltaXJza3lAZ21haWwuY29tDQo+ID4gICAgIDxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29t Pj4NCj4gPiAgICAgKlNlbnQ6KiBGcmlkYXksIEphbnVhcnkgMjEsIDIwMjIgMjowOSBBTQ0KPiA+ ICAgICAqVG86KiBERUNSQUVORSBCcnVubyBJTk5PVi9ORVQgPGJydW5vLmRlY3JhZW5lQG9yYW5n ZS5jb20NCj4gPiAgICAgPG1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPj4NCj4gPiAg ICAgKkNjOiogbXBscyA8bXBsc0BpZXRmLm9yZyA8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+PjsgcGFs c0BpZXRmLm9yZw0KPiA+ICAgICA8bWFpbHRvOnBhbHNAaWV0Zi5vcmc+OyBEZXROZXQgV0cgPGRl dG5ldEBpZXRmLm9yZw0KPiA+ICAgICA8bWFpbHRvOmRldG5ldEBpZXRmLm9yZz4+DQo+ID4gICAg ICpTdWJqZWN0OiogUmU6IFttcGxzXSBDb250aW51aW5nIHdpdGggbXkgY29tbWVudHMgb24NCj4g PiAgICAgZHJhZnQtZGVjcmFlbmUtbXBscy1zbGlkLWVuY29kZWQtZW50cm9weS1sYWJlbC1pZF9f X18NCj4gPg0KPiA+ICAgICBfXyBfXw0KPiA+DQo+ID4gICAgIEhpIEJydW5vLF9fX18NCj4gPg0K PiA+ICAgICB0aGFuayB5b3UgZm9yIHlvdXIga2luZCBjb25zaWRlcmF0aW9uIG9mIG15IGNvbW1l bnRzLiBQbGVhc2UNCj4gPiAgICAgZmluZMKgZm9sbG93LXVwIG5vdGVzIGluLWxpbmUgYmVsb3cg dW5kZXIgdGhlIEdJTT4+IHRhZy5fX19fDQo+ID4NCj4gPiAgICAgX18gX18NCj4gPg0KPiA+ICAg ICBSZWdhcmRzLF9fX18NCj4gPg0KPiA+ICAgICBHcmVnX19fXw0KPiA+DQo+ID4gICAgIF9fIF9f DQo+ID4NCj4gPiAgICAgT24gTW9uLCBKYW4gMTcsIDIwMjIgYXQgODoyNCBBTSA8YnJ1bm8uZGVj cmFlbmVAb3JhbmdlLmNvbQ0KPiA+ICAgICA8bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5j b20+PiB3cm90ZTpfX19fDQo+ID4NCj4gPiAgICAgICAgIEhpIEdyZWcsIGFsbF9fX18NCj4gPg0K PiA+ICAgICAgICAgX19fXw0KPiA+DQo+ID4gICAgICAgICBHcmVnLCB0aGFua3MgZm9yIHRha2lu ZyB0aGUgdGltZSB0byByZWFkIHRoZSBkcmFmdCBhbmQgY29tbWVudC5fX19fDQo+ID4NCj4gPiAg ICAgICAgIF9fX18NCj4gPg0KPiA+ICAgICAgICAgV0csIGZvciBjb250ZXh0LCB3ZSBhcmUgZGlz Y3Vzc2luZyBhIHN1YnNldCBvZiB0aGUgZHJhZnQ6IHRoZQ0KPiA+ICAgICAgICAgYWJpbGl0eSB0 byBhZHZlcnRpc2UgaW5kaWNhdG9yIGFzIHBhcnQgb2YgdGhlIGV4aXN0aW5nIEVudHJvcHkNCj4g PiAgICAgICAgIExhYmVsIFRUTCBhcyBkZXNjcmliZWQgaW4gc2VjdGlvbiAyIG9mIHRoZSBkcmFm dCAoaXTigJlzIDEgcGFnZSk6X19fXw0KPiA+DQo+ID4gICAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWRlY3JhZW5lLW1wbHMtc2xpZC1lbmNvZGVkLQ0K PiBlbnRyb3B5LWxhYmVsLWlkLTAyI3NlY3Rpb24tMg0KPiA+ICAgICAgICAgPGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtZGVjcmFlbmUtbXBscy1zbGlkLWVuY29k ZWQtDQo+IGVudHJvcHktbGFiZWwtaWQtMDIjc2VjdGlvbi0yPl9fX18NCj4gPg0KPiA+ICAgICAg ICAgX19fXw0KPiA+DQo+ID4gICAgICAgICBQbGVhc2Ugc2VlIGlubGluZSBbQnJ1bm9dX19fXw0K PiA+DQo+ID4gICAgICAgICBfX19fDQo+ID4NCj4gPiAgICAgICAgIF9fX18NCj4gPg0KPiA+ICAg ICAgICAgT3JhbmdlIFJlc3RyaWN0ZWRfX19fDQo+ID4NCj4gPiAgICAgICAgICpGcm9tOiogbXBs cyA8bXBscy1ib3VuY2VzQGlldGYub3JnDQo+ID4gICAgICAgICA8bWFpbHRvOm1wbHMtYm91bmNl c0BpZXRmLm9yZz4+ICpPbiBCZWhhbGYgT2YgKkdyZWcgTWlyc2t5DQo+ID4gICAgICAgICAqU2Vu dDoqIFRodXJzZGF5LCBKYW51YXJ5IDEzLCAyMDIyIDExOjQxIFBNDQo+ID4gICAgICAgICAqVG86 KiBtcGxzIDxtcGxzQGlldGYub3JnIDxtYWlsdG86bXBsc0BpZXRmLm9yZz4+OyBwYWxzQGlldGYu b3JnDQo+ID4gICAgICAgICA8bWFpbHRvOnBhbHNAaWV0Zi5vcmc+OyBEZXROZXQgV0cgPGRldG5l dEBpZXRmLm9yZw0KPiA+ICAgICAgICAgPG1haWx0bzpkZXRuZXRAaWV0Zi5vcmc+Pg0KPiA+ICAg ICAgICAgKlN1YmplY3Q6KiBbbXBsc10gQ29udGludWluZyB3aXRoIG15IGNvbW1lbnRzIG9uDQo+ ID4gICAgICAgICBkcmFmdC1kZWNyYWVuZS1tcGxzLXNsaWQtZW5jb2RlZC1lbnRyb3B5LWxhYmVs LWlkX19fXw0KPiA+DQo+ID4gICAgICAgICBfX19fDQo+ID4NCj4gPiAgICAgICAgIEhpIEJydW5v LCBldCBhbC5fX19fDQo+ID4NCj4gPiAgICAgICAgIFRoYW5rIHlvdSBmb3IgcHJlc2VudGluZyB0 aGlzIHdvcmsgYXQgdGhlIE1QTFMgT3BlbiBEVCBtZWV0aW5nDQo+ID4gICAgICAgICB0b2RheS4g QmVsb3cgcGxlYXNlIGZpbmQgdGhlIHN1bW1hcnkgb2YgbXkgY29tbWVudHMgYW5kDQo+ID4gICAg ICAgICBxdWVzdGlvbnMgd2l0aCB0aGUgYWRkaXRpb25hbCB0aG91Z2h0cyB0aGF0IGNhbWUgYWZ0 ZXIgd2UndmUNCj4gPiAgICAgICAgIGNsb3NlZCB0aGUgY2FsbC4gSSBncmVhdGx5IGFwcHJlY2lh dGUgdGhlIGNvbnNpZGVyYXRpb24gYW5kDQo+ID4gICAgICAgICBvcGluaW9ucyBvZiB0aGUgYXV0 aG9ycyBhbmQgdGhlIGdyb3VwLl9fX18NCj4gPg0KPiA+ICAgICAgICAgICAqIENvbXBhdGliaWxp dHkgd2l0aCBub2RlcyB0aGF0IHN1cHBvcnQgb25seSBSRkMgNjc5MC5fX19fDQo+ID4NCj4gPiAg ICAgICAgICAgICAgIG8gSWYgdGhlIHByb3Bvc2VkIGluZGljYXRvcnMgYXJlIHVzZWQgdG8gc2ln bmFsIHRoZQ0KPiA+ICAgICAgICAgICAgICAgICBwcmVzZW5jZSBvZiBhbiBJU0QsIHRoYXQgc2Vl bXMgdG8gY3JlYXRlIGEgcHJvYmxlbSBmb3INCj4gPiAgICAgICAgICAgICAgICAgYW4gUkZDNjc5 MC1vbmx5IG5vZGUgYXMgaXQgbWlnaHQgbm90IGJlIGFibGUgdG8gcHJvY2Vzcw0KPiA+ICAgICAg ICAgICAgICAgICB0aGUgSVNELl9fX18NCj4gPg0KPiA+ICAgICAgICAgW0JydW5vXV9fX18NCj4g Pg0KPiA+ICAgICAgICAgLSBEcmFmdCgqKSBleHRlbmRzIHRoZSB1c2Ugb2YgdGhlIEVudHJvcHkg TGFiZWwgVFRMIGZpZWxkIHdoaWNoDQo+ID4gICAgICAgICBpcyBlc3NlbnRpYWxseSBzcGVjaWZp ZWQgYXMgYSBSZXNlcnZlZCBmaWVsZCBpbiBSRkMgNjc5MC4gSGVuY2UNCj4gPiAgICAgICAgIGRy YWZ0IGlzIGJhY2t3YXJkIGNvbXBhdGlibGUgd2l0aCBSRkMgNjc5MC5fX19fDQo+ID4NCj4gPiAg ICAgR0lNPj4gSSBhZ3JlZSwgdGhhdCBpZiB0aGUgbWVjaGFuaXNtIGlzIGxpbWl0ZWQgdG8gcmUt dXNlIG9mIHRoZSBUVEwNCj4gPiAgICAgZmllbGTCoG9mIHRoZSBsYWJlbCBlbGVtZW50IHRoYXQg aW5jbHVkZXMgdGhlIGVudHJvcHkgbGFiZWwsIHRoZW4NCj4gPiAgICAgdGhlcmUgYXJlIG5vIHBv c3NpYmxlIGlzc3Vlcy4gQnV0IHRoZW4sIGhvdyB1c2VmdWwgaXMgYSBtZWNoYW5pc20NCj4gPiAg ICAgdGhhdCBhbGxvd3MgZm9yIG9ubHkgc2V2ZW4gaW5kaWNhdG9ycyBvZiBwcm9jZXNzaW5nIGlu c3RydWN0aW9ucz8gT2YNCj4gPiAgICAgY291cnNlLCBpZiB0aGUgbW9kZWwgZG9lcyBub3Qgc3Vw cG9ydCBhIGNvbWJpbmF0aW9uIG9mIGluc3RydWN0aW9ucywNCj4gPiAgICAgdGhlbiB0aGUgbmV3 IGZpZWxkIG1pZ2h0IGJlIHZpZXdlZCBub3QgYXMgYSBzZXQgb2YgZmxhZ3MgYnV0IGFzIGENCj4g PiAgICAgc2NhbGFyIHdpdGggZWFjaCB2YWx1ZSBkZWZpbmluZyBhIGRpZmZlcmVudCBwcm9jZXNz aW5nIHR5cGUuX19fXw0KPiA+DQo+ID4gICAgIFtCcnVubzJdIFRoYW5rIHlvdSBmb3IgYWNrbm93 bGVkZ2luZyB0aGF0IGl0IHdvdWxkIHdvcmsuIEluIHRlcm1zIG9mDQo+ID4gICAgIHBvc3NpYmxl IHVzYWdlcywgdGhlIGRyYWZ0IGxpc3RzIDMgb25lcyBpbiBzZWN0aW9ucyAzLCA0IGFuZCA1LiBf X19fDQo+ID4NCj4gPiAgICAgX18gX18NCj4gPg0KPiA+ICAgICAgICAgLSBEcmFmdCBkb2VzIG5v dCBzcGVjaWZ5IElTRCBzbyB0aGlzIGlzIG91dCBvZiBzY29wZSBvZiB0aGlzDQo+ID4gICAgICAg ICBkcmFmdC4gVGhhdCBiZWVuIHNhaWQ6X19fXw0KPiA+DQo+ID4gICAgICAgICAtwqAgWW91IGFy ZSByaWdodCB0aGF0IGJlZm9yZSBzZW5kaW5nIElTRCBpbiBhIG5ldyBleHRlbnNpb24sIHRoZQ0K PiA+ICAgICAgICAgY2FwYWJpbGl0eSBmb3IgdGhlIHJlY2VpdmVyL2VncmVzcyB0byBzdXBwb3J0 IHRoaXMgSVNEIG5lZWRzIHRvDQo+ID4gICAgICAgICBiZSBrbm93biBieSB0aGUgc2VuZGVyLiBU aGlzIGlzIHByaW9yaSByZXF1aXJlZCBieSBhbGwgSVNEDQo+ID4gICAgICAgICBzb2x1dGlvbi5f X19fDQo+ID4NCj4gPiAgICAgICAgIC0gWW91IHNlZW1lZCB0byBhc3N1bWUgdGhhdCBJU0QgYXJl IGFsd2F5cyBuZWNlc3NhcnkgYnV0IElNSE8NCj4gPiAgICAgICAgIGluZGljYXRvcnMgYW5kIElT RCBhcmUgdHdvIGRpZmZlcmVudCBleHRlbnNpb25zIGFuZCBJbmRpY2F0b3JzDQo+ID4gICAgICAg ICBtYXkgYmUgdXNlZCB3aXRob3V0IElTRCBleHRlbnNpb25zIC5lLmcuLCBjZiBzZWN0aW9ucyA0 LCA1LCAzIG9mDQo+ID4gICAgICAgICB0aGUgZHJhZnRfX19fDQo+ID4NCj4gPiAgICAgR0lNPj4g SSBhZ3JlZSwgdGhhdCBpbiBzb21lIHNjZW5hcmlvcyB0aGUgYWJpbGl0eSB0byBzaWduYWwNCj4g PiAgICAgcHJvY2Vzc2luZyBpbiBhIGxhYmVsIHN0YWNrIGlzIHN1ZmZpY2llbnQgYW5kIHVzZWZ1 bC4gVGhvdWdoLCBoYXZpbmcNCj4gPiAgICAgYSBtZXRob2Qgb2YgZG9pbmcgYSBzdWJzZXQgb2Yg d2hhdCBjYW4gYmUgZG9uZSB3aXRoIEFuY2lsbGFyeSBEYXRhDQo+ID4gICAgIGFuZCBBY3Rpb24g aW5kaWNhdGlvbiBzZWVtcyBsaWtlIGFuIHVubmVjZXNzYXJ5IG92ZXJsYXAuX19fXw0KPiA+DQo+ ID4gICAgIFtCcnVubzJdIFRoYW5rIHlvdSBmb3IgdGhlIGFncmVlbWVudC4gSWYgb25lL2EgdXNl IGNhc2Ugd2FudHMgdG8NCj4gPiAgICAgYWR2ZXJ0aXNlIG1vcmUgZGF0YSwgaXTigJlzIHBvc3Np YmxlIHRvIGV4dGVuZCB0aGUgcHJvcG9zYWwgKGFjdHVhbGx5DQo+ID4gICAgIG9uZSBzaG91bGQg YmUgcHVibGlzaGVkIHNob3J0bHkpX19fXw0KPiA+DQo+ID4gICAgICAgICAgICAgICBvIElmIG9u ZSBvZiB0aGUgaW5kaWNhdG9ycyBpc8KgdG8gYmUgdXNlZCB0byBzaWduYWwgdGhlDQo+ID4gICAg ICAgICAgICAgICAgIHByZXNlbmNlwqBvZiB0aGUgZXh0ZW5zaW9uLCB0aGF0LCBzaW1pbGFybHkg dG8gdGhlDQo+ID4gICAgICAgICAgICAgICAgIHNjZW5hcmlvIGFib3ZlLCBtaWdodCBub3QgYmUg Y29ycmVjdGx5IHByb2Nlc3NlZCBieSBhbg0KPiA+ICAgICAgICAgICAgICAgICBSRkM2NzkwLW9u bHkgbm9kZS5fX19fDQo+ID4NCj4gPiAgICAgICAgIFtCcnVub10gaWRlbSBfX19fDQo+ID4NCj4g PiAgICAgICAgICAgKiBTY2FsaW5nX19fXw0KPiA+DQo+ID4gICAgICAgICAgICAgICBvIElmIHRo ZSBwcm9wb3NlZCBtZXRob2QgdG8gc2lnbmFsIHRoZSBhbmNpbGxhcnkgZGF0YSBpcw0KPiA+ICAg ICAgICAgICAgICAgICB1c2VkIGluLCBmb3IgZXhhbXBsZSwgYSBzdHJpY3QgZXhwbGljaXQgcm91 dGluZw0KPiA+ICAgICAgICAgICAgICAgICBlbnZpcm9ubWVudCwgdGhlIEVudHJvcHkgTGFiZWwg aXMgbm90IG5lZWRlZC4gSWYgdGhhdCBpcw0KPiA+ICAgICAgICAgICAgICAgICB0aGUgY2FzZSwg dXNpbmcgdGhlIGluZGljYXRvcnMsIGFzIGRlc2NyaWJlZCBpbiB0aGUNCj4gPiAgICAgICAgICAg ICAgICAgZHJhZnQsIHNlZW1zIHRvIHdhc3RlIDIwIGJpdHMgaW4gYSBsYWJlbCBlbGVtZW50DQo+ ID4gICAgICAgICAgICAgICAgIGNvbXBhcmVkIHRvIHRoZSBtZWNoYW5pc20gcHJvcG9zZWQgaW4N Cj4gPiAgICAgICAgICAgICAgICAgZHJhZnQta29tcGVsbGEtbXBscy1tc3BsNGZhLl9fX18NCj4g Pg0KPiA+ICAgICAgICAgW0JydW5vXSBBbmQgZm9yIGFsbCBvdGhlciBjYXNlcywgdGhlIHNjYWxp bmcgaXMgdmVyeSBnb29kIGFzIHdlDQo+ID4gICAgICAgICBjYXJyeSBpbmRpY2F0b3JzIHdpdGgg emVybyBleHRyYSBsYWJlbC4gU28gdGhlIG5ldCBiZW5lZml0IGlzDQo+ID4gICAgICAgICBkZXBl bmRlbnQgb2YgdGhlIHJlbGF0aXZlIHVzYWdlIG9mIHN0cmljdCBleHBsaWNpdCByb3V0aW5nDQo+ ID4gICAgICAgICB0cmFmZmljIHZzIHRyYWZmaWMgd2hpY2ggY2FuIGJlIEVDTVAuIEluIG15IGVu dmlyb25tZW50LCB0aGUNCj4gPiAgICAgICAgIGxhdHRlciBpcyBtdWNoIG1vcmUgcHJldmFsZW50 LCBoZW5jZSB0aGUgbmV0IGJlbmVmaXQgaXMNCj4gPiAgICAgICAgIHBvc2l0aXZlLl9fX18NCj4g Pg0KPiA+ICAgICBHSU0+PiBJIGFncmVlIHRoYXQgdGhlcmUgYXJlIGNhc2VzIGFuZCBzY2VuYXJp b3Mgd2hlbiBzZXZlbg0KPiA+ICAgICBpbmRpY2F0b3JzIGNhbiBzb2x2ZSB0aGUgb3BlcmF0b3In c8KgaW1tZWRpYXRlIHByb2JsZW1zLiBUaG91Z2ggSQ0KPiA+ICAgICBiZWxpZXZlIHRoYXQgYSBm dXR1cmUtcHJvb2Ygc29sdXRpb24gaXMgcHJlZmVyYWJsZS5fX19fDQo+ID4NCj4gPiAgICAgW0Jy dW5vMl0gSWYgbmVlZGVkLCBJIGJlbGlldmUgdGhhdCB0aGlzIHByb3Bvc2FsIG1heSBiZSBleHRl bmRlZCBmb3INCj4gPiAgICAgdGhlIHVzZSBjYXNlcyB0aGF0IHdvdWxkIHJlcXVpcmUgbW9yZS4g SSBzZWUgbm8gcmVhc29uIGZvciBzdWNoDQo+ID4gICAgIGV4dGVuc2lvbiB0byBub3QgYmUgZXF1 YWxseSBmdXR1cmUtcHJvb2YuX19fXw0KPiA+DQo+ID4gICAgIF9fIF9fDQo+ID4NCj4gPiAgICAg UmVnYXJkcyxfX19fDQo+ID4NCj4gPiAgICAgLS1CcnVub19fX18NCj4gPg0KPiA+ICAgICAgICAg X18gX18NCj4gPg0KPiA+ICAgICAgICAgUFPCoDogYnkgwqvCoGRyYWZ0wqDCuyBJIG1lYW4gc2Vj dGlvbiAyIG9mIHRoZSBkcmFmdCBhcyB0aGlzIGlzIHRoZQ0KPiA+ICAgICAgICAgc2NvcGUgb2Yg dGhlIGRpc2N1c3Npb24uX19fXw0KPiA+DQo+ID4gICAgICAgICBSZWdhcmRzLF9fX18NCj4gPg0K PiA+ICAgICAgICAgLUJydW5vX19fXw0KPiA+DQo+ID4gICAgICAgICBSZWdhcmRzLF9fX18NCj4g Pg0KPiA+ICAgICAgICAgR3JlZ19fX18NCj4gPg0KPiA+DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ DQo+ID4gICAgICAgICBfXyAgX18NCj4gPg0KPiA+ICAgICAgICAgQ2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zDQo+IGNvbmZp ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jX19fXw0KPiA+DQo+ ID4gICAgICAgICBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1 dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UNCj4gY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2 ZXVpbGxleiBsZSBzaWduYWxlcl9fX18NCj4gPg0KPiA+ICAgICAgICAgYSBsJ2V4cGVkaXRldXIg ZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2Vz DQo+IGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbixfX19fDQo+ ID4NCj4gPiAgICAgICAgIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91DQo+IGZhbHNpZmllLiBNZXJjaS5fX19f DQo+ID4NCj4gPiAgICAgICAgIF9fICBfXw0KPiA+DQo+ID4gICAgICAgICBUaGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl ZA0KPiBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3O19fX18NCj4gPg0K PiA+ICAgICAgICAgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGll ZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uX19fXw0KPiA+DQo+ID4gICAgICAgICBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZQ0KPiB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy5fX19fDQo+ID4N Cj4gPiAgICAgICAgIEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZQ0KPiBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZh bHNpZmllZC5fX19fDQo+ID4NCj4gPiAgICAgICAgIFRoYW5rIHlvdS5fX19fDQo+ID4NCj4gPg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+DQo+ID4gICAgIENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2lu dGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0KPiBjb25maWRlbnRpZWxsZXMg b3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KPiA+ICAgICBwYXMgZXRyZSBkaWZm dXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6 IHJlY3UgY2UNCj4gbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KPiA+ ICAgICBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMNCj4gZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLA0KPiA+ICAgICBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0 ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdQ0KPiBmYWxzaWZpZS4gTWVy Y2kuDQo+ID4NCj4gPiAgICAgVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQNCj4gaW5mb3JtYXRpb24gdGhhdCBtYXkg YmUgcHJvdGVjdGVkIGJ5IGxhdzsNCj4gPiAgICAgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1 dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+ID4gICAgIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVsZXRlDQo+IHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiA+ ICAgICBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt ZXNzYWdlcyB0aGF0IGhhdmUgYmVlbg0KPiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu DQo+ID4gICAgIFRoYW5rIHlvdS4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBkZXRuZXQgbWFpbGluZyBsaXN0DQo+ID4g ZGV0bmV0QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kZXRuZXQNCj4gDQo+IC0tDQo+IExvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAg ICBlbWFpbDogbG9hQHBpLm51DQo+IFNlbmlvciBNUExTIEV4cGVydCAgICAgICAgICAgICAgICAg ICAgICAgICAgbG9hLnBpLm51QGdtYWlsLmNvbQ0KPiBCcm9uemUgRHJhZ29uIENvbnN1bHRpbmcg ICAgICAgICAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCg0KT3JhbmdlIFJlc3RyaWN0ZWQN CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRl bmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBu ZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2Fu cyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwg dmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kg cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2Fi aWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1l cmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5 IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRo b3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3Qg bGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBm YWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Thu Jan 27 02:03:21 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5043A1C9D; Thu, 27 Jan 2022 02:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 H4nyOGLVkhja; Thu, 27 Jan 2022 02:03:14 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (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 D8F8D3A1C9C; Thu, 27 Jan 2022 02:03:13 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar21.francetelecom.fr (ESMTP service) with ESMTPS id 4Jkx400bbsz7tjY; Thu, 27 Jan 2022 11:03:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1643277792; bh=UfBwzr4ED3h5SCBo5vK1Pdpug1AwX4jkitrBEh8VwUM=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=qD/cPZ/ceerV0vxsCf3Zwq9cSN3EF0Kbx5ajmZxERRi2cGfs9kqBWujqPxPybUF4T EoplkgF229MIAR/XAFw+idAmwVxS5GFVw5N5xKD4G4/Y/TrvKIsKnl19ItkQdWUNgF ny4jhOowLq9JdcxQQDErvzlKmZYUnda/f3ZbcHC2sjnyuIs32xtV5TiWiNblcd9XEt Jepgd+0HFt+qMy1El5JxLwXUBe+x9DxkTjPWf8xF79+LktnMeT5z1O0C9oDNkbN1AG 46mUN/pdpyQvGEuUjJXOVxW0PsTP1v8XyLwhvXj4m1WZmxYoKsWlAQrttBT0OdIK58 KiWVgiRjGf9mg== From: To: Greg Mirsky CC: mpls , "pals@ietf.org" , DetNet WG Thread-Topic: [mpls] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id Thread-Index: AQHYD9fNvXaTx7DxH0SsAQ12A7ZUTax2qT1w Date: Thu, 27 Jan 2022 10:03:11 +0000 Message-ID: <18452_1643277791_61F26DDF_18452_180_1_7c771241ef0842148864a7af02deb0f4@orange.com> References: <11050_1642436674_61E59842_11050_100_1_0d0176823ddd4cb4ad825e3ee88445a3@orange.com> <6217_1642787863_61EAF417_6217_204_1_8dd254d74cdc46e58328d6889c6984a2@orange.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-01-27T10:03:09Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_enabled: true msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_setdate: 2022-01-27T10:03:09Z msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_method: Standard msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_name: Orange_restricted_external.2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_siteid: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_actionid: 1c8c0373-b4f0-4565-8040-38860a3865af msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_contentbits: 0 x-originating-ip: [10.115.27.50] Content-Type: multipart/alternative; boundary="_000_7c771241ef0842148864a7af02deb0f4orangecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id 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, 27 Jan 2022 10:03:19 -0000 --_000_7c771241ef0842148864a7af02deb0f4orangecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Thank you for the useful discussion (at least to me) on indicators within t= he stack as proposed by section 2 of draft-decraene-mpls-slid-encoded-entro= py-label-id The extension that I've been referring to encode data has just been publish= ed: https://datatracker.ietf.org/doc/html/draft-jags-mpls-ext-hdr-entropy-l= bl Review is equally welcomed. Regards, --Bruno Orange Restricted From: Greg Mirsky Sent: Saturday, January 22, 2022 10:34 PM To: DECRAENE Bruno INNOV/NET Cc: mpls ; pals@ietf.org; DetNet WG Subject: Re: [mpls] Continuing with my comments on draft-decraene-mpls-slid= -encoded-entropy-label-id Hi Bruno, thank you for your detailed response to my notes. I am looking forward to t= he new version of the draft and continued discussion. Regards, Greg On Fri, Jan 21, 2022 at 9:57 AM > wrote: Hi Greg, Thank you for the follow up. Please see inline [Bruno2] Orange Restricted From: Greg Mirsky > Sent: Friday, January 21, 2022 2:09 AM To: DECRAENE Bruno INNOV/NET > Cc: mpls >; pals@ietf.org; DetNet WG > Subject: Re: [mpls] Continuing with my comments on draft-decraene-mpls-slid= -encoded-entropy-label-id Hi Bruno, thank you for your kind consideration of my comments. Please find follow-up= notes in-line below under the GIM>> tag. Regards, Greg On Mon, Jan 17, 2022 at 8:24 AM > wrote: Hi Greg, all Greg, thanks for taking the time to read the draft and comment. WG, for context, we are discussing a subset of the draft: the ability to ad= vertise indicator as part of the existing Entropy Label TTL as described in= section 2 of the draft (it's 1 page): https://datatracker.ietf.org/doc/html/draft-decraene-mpls-slid-encoded-entr= opy-label-id-02#section-2 Please see inline [Bruno] Orange Restricted From: mpls > On Behalf = Of Greg Mirsky Sent: Thursday, January 13, 2022 11:41 PM To: mpls >; pals@ietf.org; DetNet WG > Subject: [mpls] Continuing with my comments on draft-decraene-mpls-slid-enc= oded-entropy-label-id Hi Bruno, et al. Thank you for presenting this work at the MPLS Open DT meeting today. Below= please find the summary of my comments and questions with the additional t= houghts that came after we've closed the call. I greatly appreciate the con= sideration and opinions of the authors and the group. * Compatibility with nodes that support only RFC 6790. * If the proposed indicators are used to signal the presence of an I= SD, that seems to create a problem for an RFC6790-only node as it might not= be able to process the ISD. [Bruno] - Draft(*) extends the use of the Entropy Label TTL field which is essentia= lly specified as a Reserved field in RFC 6790. Hence draft is backward comp= atible with RFC 6790. GIM>> I agree, that if the mechanism is limited to re-use of the TTL field = of the label element that includes the entropy label, then there are no pos= sible issues. But then, how useful is a mechanism that allows for only seve= n indicators of processing instructions? Of course, if the model does not s= upport a combination of instructions, then the new field might be viewed no= t as a set of flags but as a scalar with each value defining a different pr= ocessing type. [Bruno2] Thank you for acknowledging that it would work. In terms of possib= le usages, the draft lists 3 ones in sections 3, 4 and 5. - Draft does not specify ISD so this is out of scope of this draft. That be= en said: - You are right that before sending ISD in a new extension, the capability= for the receiver/egress to support this ISD needs to be known by the sende= r. This is priori required by all ISD solution. - You seemed to assume that ISD are always necessary but IMHO indicators an= d ISD are two different extensions and Indicators may be used without ISD e= xtensions .e.g., cf sections 4, 5, 3 of the draft GIM>> I agree, that in some scenarios the ability to signal processing in a= label stack is sufficient and useful. Though, having a method of doing a s= ubset of what can be done with Ancillary Data and Action indication seems l= ike an unnecessary overlap. [Bruno2] Thank you for the agreement. If one/a use case wants to advertise = more data, it's possible to extend the proposal (actually one should be pub= lished shortly) * If one of the indicators is to be used to signal the presence of t= he extension, that, similarly to the scenario above, might not be correctly= processed by an RFC6790-only node. [Bruno] idem * Scaling * If the proposed method to signal the ancillary data is used in, fo= r example, a strict explicit routing environment, the Entropy Label is not = needed. If that is the case, using the indicators, as described in the draf= t, seems to waste 20 bits in a label element compared to the mechanism prop= osed in draft-kompella-mpls-mspl4fa. [Bruno] And for all other cases, the scaling is very good as we carry indic= ators with zero extra label. So the net benefit is dependent of the relativ= e usage of strict explicit routing traffic vs traffic which can be ECMP. In= my environment, the latter is much more prevalent, hence the net benefit i= s positive. GIM>> I agree that there are cases and scenarios when seven indicators can = solve the operator's immediate problems. Though I believe that a future-pro= of solution is preferable. [Bruno2] If needed, I believe that this proposal may be extended for the us= e cases that would require more. I see no reason for such extension to not = be equally future-proof. Regards, --Bruno PS : by < draft > I mean section 2 of the draft as this is the scope of the= discussion. Regards, -Bruno Regards, Greg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_7c771241ef0842148864a7af02deb0f4orangecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,=

 

Thank you for the useful discussion (at least to me) on indica= tors within the stack as proposed by section 2 of draft-decraene-mpls-slid-encoded-entropy-label-id

The extension that I’ve been referring to encode data ha= s just been published: https://datatracker.ietf.org/doc/html/draft-jags-mpls-ext-hdr-entropy-lbl=

 

Review is equally welcomed.

 

Regards,

--Bruno

 

 

Orange Restricted

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Saturday, January 22, 2022 10:34 PM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>
Cc: mpls <mpls@ietf.org>; pals@ietf.org; DetNet WG <detnet@= ietf.org>
Subject: Re: [mpls] Continuing with my comments on draft-decraene-mp= ls-slid-encoded-entropy-label-id

 

Hi Bruno,

thank you for your detailed response to my notes. I = am looking forward to the new version of the draft and continued discu= ssion.

 

Regards,

Greg

 

Hi Greg,

 

Thank you for the follow up.= Please see inline [Bruno2]

 

 

Orange Restricted

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Friday, January 21, 2022 2:09 AM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>
Cc: mpls <mpls= @ietf.org>; pals@ietf.org; DetNe= t WG <detnet@ietf.o= rg>
Subject: Re: [mpls] Continuing with my comments on draft-decraene-mp= ls-slid-encoded-entropy-label-id

 

Hi Bruno,

thank you for your kind consideration of my comments. Please find&= nbsp;follow-up notes in-line below under the GIM>> tag.

 

Regards,

Greg

 

On Mon, Jan 17, 2022 at 8:24 AM <bruno.decraene@orange.com> wrote:

Hi Greg, all

 

Greg, thanks for taking the = time to read the draft and comment.

 

WG, for context, we are disc= ussing a subset of the draft: the ability to advertise indicator as part of the existing Entropy Label TTL as described in sectio= n 2 of the draft (it’s 1 page):

https://datatracker.ietf.org/doc/html/draft-dec= raene-mpls-slid-encoded-entropy-label-id-02#section-2=

 

Please see inline [Bruno]

 

 

Orange Restricted

From: mpls <mpls-bounces@ietf.org> On Behalf Of Greg Mirsky
Sent: Thursday, January 13, 2022 11:41 PM
To: mpls <mpls= @ietf.org>; pals@ietf.org; DetNe= t WG <detnet@ietf.o= rg>
Subject: [mpls] Continuing with my comments on draft-decraene-mpls-s= lid-encoded-entropy-label-id

 

Hi Bruno, et al.

Thank you for presenting this work at the MPLS Open DT meeting tod= ay. Below please find the summary of my comments and questions with the add= itional thoughts that came after we've closed the call. I greatly appreciate the consideration and opinions of th= e authors and the group.

  • Compatibility with nodes that support only RFC 6790.
    • If the proposed indicators are used to signal the presence of an ISD, that = seems to create a problem for an RFC6790-only node as it might not be able = to process the ISD.

[Bruno]

- Draft(*) extends the use o= f the Entropy Label TTL field which is essentially specified as a Reserved field in RFC 6790. Hence draft is backward compati= ble with RFC 6790.

GIM>> I agree, that if the mechanism is limited to re-use of= the TTL field of the label element that includes the entropy label, t= hen there are no possible issues. But then, how useful is a mechanism that allows for only seven indicators of processing = instructions? Of course, if the model does not support a combination of ins= tructions, then the new field might be viewed not as a set of flags but as = a scalar with each value defining a different processing type.

[Bruno2] Thank you for ackno= wledging that it would work. In terms of possible usages, the draft lists 3 ones in sections 3, 4 and 5. <= /p>

 

- Draft does not specify ISD= so this is out of scope of this draft. That been said:

-  You are right that before sen= ding ISD in a new extension, the capability for the receiver/egress to supp= ort this ISD needs to be known by the sender. This is priori required by all ISD solution.

- You seemed to assume that ISD are a= lways necessary but IMHO indicators and ISD are two different extensions an= d Indicators may be used without ISD extensions .e.g., cf sections 4, 5, 3 of the draft

GIM>> I agree, that in some scenarios the ability to signal = processing in a label stack is sufficient and useful. Though, having a meth= od of doing a subset of what can be done with Ancillary Data and Action indication seems like an unnecessary overlap.

[Bruno2] Thank you for the a= greement. If one/a use case wants to advertise more data, it’s possible to extend the proposal (actually one should be p= ublished shortly)

    • If one of the indica= tors is to be used to signal the presence of the extension, that,= similarly to the scenario above, might not be correctly processed by an RF= C6790-only node.

[Bruno] idem

  • Scaling
    • If the proposed method to signal the ancillary data is used in, for example= , a strict explicit routing environment, the Entropy Label is not needed. I= f that is the case, using the indicators, as described in the draft, seems = to waste 20 bits in a label element compared to the mechanism proposed in draft-kompella-mpls-mspl4fa.

[Bruno] And for all other ca= ses, the scaling is very good as we carry indicators with zero extra label. So the net benefit is dependent of the relative usa= ge of strict explicit routing traffic vs traffic which can be ECMP. In my e= nvironment, the latter is much more prevalent, hence the net benefit is pos= itive.

GIM>> I agree that there are cases and scenarios when seven = indicators can solve the operator's immediate problems. Though I belie= ve that a future-proof solution is preferable.

[Bruno2] If needed, I believ= e that this proposal may be extended for the use cases that would require more. I see no reason for such extension to not be equa= lly future-proof.

 

Regards,

--Bruno

 

PS : by « dr= aft » I mean section 2 of the draft as this is the scope of the = discussion.

Regards,

-Bruno

Regards,

Greg

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_7c771241ef0842148864a7af02deb0f4orangecom_-- From nobody Thu Jan 27 06:45:11 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998E43A0FF5; Thu, 27 Jan 2022 06:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.611 X-Spam-Level: X-Spam-Status: No, score=-7.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIKk7cfdACSq; Thu, 27 Jan 2022 06:44:59 -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 7334D3A0F5E; Thu, 27 Jan 2022 06:44:55 -0800 (PST) Received: from [192.168.1.98] (unknown [112.206.242.125]) (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 887EC36600E; Thu, 27 Jan 2022 15:44:51 +0100 (CET) Message-ID: <69744e7b-3c9c-6f4f-df85-c8bdcb219422@pi.nu> Date: Thu, 27 Jan 2022 22:44:48 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Content-Language: en-CA To: bruno.decraene@orange.com, Greg Mirsky Cc: mpls , DetNet WG , "pals@ietf.org" References: <11050_1642436674_61E59842_11050_100_1_0d0176823ddd4cb4ad825e3ee88445a3@orange.com> <6217_1642787863_61EAF417_6217_204_1_8dd254d74cdc46e58328d6889c6984a2@orange.com> <7de9f8f4-c60a-f867-1cf5-b2f0ad939c54@pi.nu> <7549_1643277510_61F26CC6_7549_417_3_d5c7f361d8f44fb291e28d13b7d877a3@orange.com> From: Loa Andersson In-Reply-To: <7549_1643277510_61F26CC6_7549_417_3_d5c7f361d8f44fb291e28d13b7d877a3@orange.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [mpls] [Pals] [Detnet] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id 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, 27 Jan 2022 14:45:09 -0000 Bruno, et.al, My apologies. Going back and reading my mail, I can understand why you understand it as you do. If I received a similar mail I probably would have done the same. No document has yet been picked as the solution. It is way to early to do so, as a matter of fact I don't think we ever will. What I see we need to do now is consolidate, usecase-, requirement- and framework, and based on that start merging solutions documents, with the intent to in the end converge (if possible) on one single document. /Loa On 27/01/2022 17:58, bruno.decraene@orange.com wrote: > Loa, > >> From: Loa Andersson >> Sent: Wednesday, January 26, 2022 3:11 AM >> >> Bruno, Greg, wg, >> >> The Open DT are working on a method for Indicators and Ancillary data, >> based mostly on draft-kompella-mpls-mspl4fa and >> draft-bocci-mpls-miad-adi-requirements. > > Are you saying that the solution (draft-kompella-mpls-mspl4fa) has been selected and all others disregarded? > > >> why is it obvious that the "SPRING version" should not be part of that >> solution? > > What "SPRING version" are you referring to? > > > https://datatracker.ietf.org/doc/html/draft-decraene-mpls-slid-encoded-entropy-label-id > and > https://datatracker.ietf.org/doc/html/draft-jags-mpls-ext-hdr-entropy-lbl > > Are targeting the MPLS WG and are not specific to SPRING as far as I can remember. > > --Bruno > >> Kireeti, >> >> BTW draft-kompella-mpls-mspl4fa has expired, plz revive. >> >> >> /Loa >> >> On 23/01/2022 05:34, Greg Mirsky wrote: >>> Hi Bruno, >>> thank you for your detailed response to my notes. I am looking >>> forward to the new version of the draft and continued discussion. >>> >>> Regards, >>> Greg >>> >>> On Fri, Jan 21, 2022 at 9:57 AM >> > wrote: >>> >>> Hi Greg,____ >>> >>> __ __ >>> >>> Thank you for the follow up. Please see inline [Bruno2]____ >>> >>> __ __ >>> >>> __ __ >>> >>> Orange Restricted____ >>> >>> *From:*Greg Mirsky >> > >>> *Sent:* Friday, January 21, 2022 2:09 AM >>> *To:* DECRAENE Bruno INNOV/NET >> > >>> *Cc:* mpls >; pals@ietf.org >>> ; DetNet WG >> > >>> *Subject:* Re: [mpls] Continuing with my comments on >>> draft-decraene-mpls-slid-encoded-entropy-label-id____ >>> >>> __ __ >>> >>> Hi Bruno,____ >>> >>> thank you for your kind consideration of my comments. Please >>> find follow-up notes in-line below under the GIM>> tag.____ >>> >>> __ __ >>> >>> Regards,____ >>> >>> Greg____ >>> >>> __ __ >>> >>> On Mon, Jan 17, 2022 at 8:24 AM >> > wrote:____ >>> >>> Hi Greg, all____ >>> >>> ____ >>> >>> Greg, thanks for taking the time to read the draft and comment.____ >>> >>> ____ >>> >>> WG, for context, we are discussing a subset of the draft: the >>> ability to advertise indicator as part of the existing Entropy >>> Label TTL as described in section 2 of the draft (it’s 1 page):____ >>> >>> https://datatracker.ietf.org/doc/html/draft-decraene-mpls-slid-encoded- >> entropy-label-id-02#section-2 >>> > entropy-label-id-02#section-2>____ >>> >>> ____ >>> >>> Please see inline [Bruno]____ >>> >>> ____ >>> >>> ____ >>> >>> Orange Restricted____ >>> >>> *From:* mpls >> > *On Behalf Of *Greg Mirsky >>> *Sent:* Thursday, January 13, 2022 11:41 PM >>> *To:* mpls >; pals@ietf.org >>> ; DetNet WG >> > >>> *Subject:* [mpls] Continuing with my comments on >>> draft-decraene-mpls-slid-encoded-entropy-label-id____ >>> >>> ____ >>> >>> Hi Bruno, et al.____ >>> >>> Thank you for presenting this work at the MPLS Open DT meeting >>> today. Below please find the summary of my comments and >>> questions with the additional thoughts that came after we've >>> closed the call. I greatly appreciate the consideration and >>> opinions of the authors and the group.____ >>> >>> * Compatibility with nodes that support only RFC 6790.____ >>> >>> o If the proposed indicators are used to signal the >>> presence of an ISD, that seems to create a problem for >>> an RFC6790-only node as it might not be able to process >>> the ISD.____ >>> >>> [Bruno]____ >>> >>> - Draft(*) extends the use of the Entropy Label TTL field which >>> is essentially specified as a Reserved field in RFC 6790. Hence >>> draft is backward compatible with RFC 6790.____ >>> >>> GIM>> I agree, that if the mechanism is limited to re-use of the TTL >>> field of the label element that includes the entropy label, then >>> there are no possible issues. But then, how useful is a mechanism >>> that allows for only seven indicators of processing instructions? Of >>> course, if the model does not support a combination of instructions, >>> then the new field might be viewed not as a set of flags but as a >>> scalar with each value defining a different processing type.____ >>> >>> [Bruno2] Thank you for acknowledging that it would work. In terms of >>> possible usages, the draft lists 3 ones in sections 3, 4 and 5. ____ >>> >>> __ __ >>> >>> - Draft does not specify ISD so this is out of scope of this >>> draft. That been said:____ >>> >>> -  You are right that before sending ISD in a new extension, the >>> capability for the receiver/egress to support this ISD needs to >>> be known by the sender. This is priori required by all ISD >>> solution.____ >>> >>> - You seemed to assume that ISD are always necessary but IMHO >>> indicators and ISD are two different extensions and Indicators >>> may be used without ISD extensions .e.g., cf sections 4, 5, 3 of >>> the draft____ >>> >>> GIM>> I agree, that in some scenarios the ability to signal >>> processing in a label stack is sufficient and useful. Though, having >>> a method of doing a subset of what can be done with Ancillary Data >>> and Action indication seems like an unnecessary overlap.____ >>> >>> [Bruno2] Thank you for the agreement. If one/a use case wants to >>> advertise more data, it’s possible to extend the proposal (actually >>> one should be published shortly)____ >>> >>> o If one of the indicators is to be used to signal the >>> presence of the extension, that, similarly to the >>> scenario above, might not be correctly processed by an >>> RFC6790-only node.____ >>> >>> [Bruno] idem ____ >>> >>> * Scaling____ >>> >>> o If the proposed method to signal the ancillary data is >>> used in, for example, a strict explicit routing >>> environment, the Entropy Label is not needed. If that is >>> the case, using the indicators, as described in the >>> draft, seems to waste 20 bits in a label element >>> compared to the mechanism proposed in >>> draft-kompella-mpls-mspl4fa.____ >>> >>> [Bruno] And for all other cases, the scaling is very good as we >>> carry indicators with zero extra label. So the net benefit is >>> dependent of the relative usage of strict explicit routing >>> traffic vs traffic which can be ECMP. In my environment, the >>> latter is much more prevalent, hence the net benefit is >>> positive.____ >>> >>> GIM>> I agree that there are cases and scenarios when seven >>> indicators can solve the operator's immediate problems. Though I >>> believe that a future-proof solution is preferable.____ >>> >>> [Bruno2] If needed, I believe that this proposal may be extended for >>> the use cases that would require more. I see no reason for such >>> extension to not be equally future-proof.____ >>> >>> __ __ >>> >>> Regards,____ >>> >>> --Bruno____ >>> >>> __ __ >>> >>> PS : by « draft » I mean section 2 of the draft as this is the >>> scope of the discussion.____ >>> >>> Regards,____ >>> >>> -Bruno____ >>> >>> Regards,____ >>> >>> Greg____ >>> >>> >> ______________________________________________________________________ >> _______________________________________________________ >>> >>> __ __ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc____ >>> >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu >> ce message par erreur, veuillez le signaler____ >>> >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration,____ >>> >>> Orange decline toute responsabilite si ce message a ete altere, deforme ou >> falsifie. Merci.____ >>> >>> __ __ >>> >>> This message and its attachments may contain confidential or privileged >> information that may be protected by law;____ >>> >>> they should not be distributed, used or copied without authorisation.____ >>> >>> If you have received this email in error, please notify the sender and delete >> this message and its attachments.____ >>> >>> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified.____ >>> >>> Thank you.____ >>> >>> >> ______________________________________________________________________ >> ___________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce >> message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, deforme ou >> falsifie. Merci. >>> >>> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and delete >> this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have been >> modified, changed or falsified. >>> Thank you. >>> >>> >>> _______________________________________________ >>> detnet mailing list >>> detnet@ietf.org >>> https://www.ietf.org/mailman/listinfo/detnet >> >> -- >> Loa Andersson email: loa@pi.nu >> Senior MPLS Expert loa.pi.nu@gmail.com >> Bronze Dragon Consulting phone: +46 739 81 21 64 > > Orange Restricted > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Thu Jan 27 11:14:33 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2883A0DE3; Thu, 27 Jan 2022 11:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meMSW3HWO4k4; Thu, 27 Jan 2022 11:14:26 -0800 (PST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2118.outbound.protection.outlook.com [40.107.220.118]) (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 D811A3A0DDE; Thu, 27 Jan 2022 11:14:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CETtnG50R4nz03BJOzgCVBiJLbYpE46J4Pn/NL218FXWeS1tQrQ7T+kMacWDZrm5iHAFXiR/LEFWqzo41Ukcq4ZiSJsc2g4lo3K8+C8XppKQhjSrG/qy0wHrOUEoR3GQxWMsyGCvMFyqngoh5+mSNAHye1hab2htwYH464EUGzuxdBUsiOpYE9JJJAE5jG+YgJ8Gp/78kGVibXK3IdjloAqVM+n8YL5kwhgzwzuUnnfs/aMRCO3FrOHzkm/F3gcrNmGhzZEG9zPVbB+XMt3nStopqbJPGMjNlcq7b7iMHDcajYcdJoqGk4wHIcKoAmG/TB+SFwT7+ffjWotNI+DfhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FSLfXGbth6u5qtGeZ5Nh2+2swzmXncYYeQra9zmT3k0=; b=FpqG4vetwOqW7/qDOroTgNhoXzw9jWUdyHxfWUyEqAQsyKOINjieBvJQwXbtX17ZWe1RmDKuvxi1MjKIl4wXcJAh6L9fwANXnxtYziO0+DPqiIenaZ+pDAD/rxOnn8RTK/jFxtW84wtBhWaoauT6jHwt7JR+zV7zBw0Fd1iXqxFGhNoVWQnd6TP6FbfluRaeYY4BUzVWdb+DcoOIch6+KVZJg/gBjjVgyNoWGOTxR+2lOTNLQjVLpUbXnvaEdXA414hvscjZ5eW4k0LrLx9Ir+sVSuTsTw5odovm3lavfSqLQNb4jJOeEcYLRey2UdXhjvDXs8e2cwjJBkv6Hldevg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FSLfXGbth6u5qtGeZ5Nh2+2swzmXncYYeQra9zmT3k0=; b=lQmKT+CQ6TSFIQ2ic0GM8xvZevVWAHjwHonUkSuprCi99DiVqMima7ts+J+LZ9ILiO5QEwYc7YwZEMyb2GLkVkRGO8Z+qHYkiv/WK/91zcKVIy1kc31TwSNGBfCcwZR0SGU3RkkZl7+79242C9/2m2qbT7roUUJ1Tp2Fw5e29Nk= Received: from PH0PR13MB4795.namprd13.prod.outlook.com (2603:10b6:510:92::15) by PH0PR13MB5976.namprd13.prod.outlook.com (2603:10b6:510:16f::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.8; Thu, 27 Jan 2022 19:14:21 +0000 Received: from PH0PR13MB4795.namprd13.prod.outlook.com ([fe80::e59d:61b0:e122:be76]) by PH0PR13MB4795.namprd13.prod.outlook.com ([fe80::e59d:61b0:e122:be76%4]) with mapi id 15.20.4951.005; Thu, 27 Jan 2022 19:14:21 +0000 From: Haoyu Song To: Loa Andersson , "mpls@ietf.org" CC: "pals-chairs@ietf.org" , "mpls-chairs@ietf.org" , DetNet Chairs Thread-Topic: [mpls] agenda for the Open DT meeting 2022-01-27 Thread-Index: AQHYEzCPTuWBEgAfakuMM8ay/jkcBqx3PVGA Date: Thu, 27 Jan 2022 19:14:21 +0000 Message-ID: References: <4cebb7c0-8a18-13ad-a824-2f8788d7bf7d@pi.nu> In-Reply-To: <4cebb7c0-8a18-13ad-a824-2f8788d7bf7d@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3d606742-9e91-4380-f20c-08d9e1c93955 x-ms-traffictypediagnostic: PH0PR13MB5976:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0+GLH+hc7oFKpsx+c6yVrPomanV6UcnZ/PIQWYiDe4sbqM4GojbSyXHriYP/52ETmtqOfZ5gLLuf+vckRyAtQ6numZmrBFWQgUsoJPmY1GjksSXC4ngolIk66uTCxgoqEKOC1H7AUbgLOPDB4VzXnkkR8EOo08yL9aXu/0nFUM00Hp43G8GuPLnaiua8tXdmA/gAwYFdsrOhkQksNyX5xRYLkFBKWOiW4Ipx6sreDO4uIR+QSGT39bx6tQTOchsak9+w/RmyJihUbYUh9OR4xmEuvgsiQcUhV02oTLLBjxr5E/TLsPKhJjXdZ3Q4qt4qHFkR/ciUbDr16/wBZwy7c3LpmgFgpuV4zizu5P0MsR8mVKNkwUYSHtjyeTJGG/DaBl70X9FJ4JDkLd5PV/3PyMqsNLIwuET7y4LG4qhYRg9fc/CjDhQvHzmlmbUA1b7oPSBzpdiocVMoR3GD3NVMONX7Kfit7pZJ+uzuBNLD8+zovMBV4xZlFtJs8KYG5OwXaPKtodEkWeRtwrmFsrpwCV+QBbS/Vmap6JygYKaHdwg3uI0FISAzywqOiqqjgQlIGlTWAx02Oj7mdD5dPUKKgkz7K1ZYMSLQUjTNVMQTMIjsqAJ7yUmnf0wZ85Spre7ZFaJ4mcsx3jafv1WTQWmxM6cQz1xB3LYFqX6Wi/KvvuGECYj2pBCtX3zmZ7hrTDHUNwViy5O9ZYT1fRjCoyhZgY/Gj0gRF3TD+LI3yZ0ExBqIRNEioUVPZIiTYH/jUCxlOAkyOsZtGHSI0H+XEcHHe3oRwiMeWg/ersAP//nlZiY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR13MB4795.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(316002)(4326008)(5660300002)(9686003)(66556008)(64756008)(26005)(53546011)(186003)(33656002)(55016003)(66946007)(8936002)(6506007)(2906002)(7696005)(52536014)(44832011)(66446008)(66476007)(8676002)(83380400001)(45080400002)(71200400001)(76116006)(54906003)(966005)(508600001)(38100700002)(38070700005)(122000001)(110136005)(86362001)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?2fN8q7KBY9MYlWdXn6xXZYT1r0dGfiBT9Sr1p6GsnDr90c29ALlWX6pNi0Rc?= =?us-ascii?Q?EmWVYXD+vdWpxQkEnsakxoc0IXZEbN70BmyRYTS4v6cZEWZBJSu7/7HJ99uu?= =?us-ascii?Q?iJ+u5+EXSbayVSOmzFbkom0E5lq09Cu0xb+PniSP3fD2JYbdX1BgiDoUqdXc?= =?us-ascii?Q?iOkDSNsrrnYuZ+TndTncu+8P4XRmIlJsQB/XM9VqBGp2hsh8KTe1yUYIIWrO?= =?us-ascii?Q?hh+Jvm7DpKL9HAhTlyMcjnWRnvS1IeLIL2uHenlHayv65qceCpDMJsW15hXJ?= =?us-ascii?Q?sm/I+UyL71ff6IYHMzRN6bIebWIR3WeKnFfeApKn0FlwAJeeIVXGOI/mU+I/?= =?us-ascii?Q?35qsB/0dy1hGm7iA9EGcoCK8eTMLTMK6hXyvvD8/4VGTpfqldhDur2LKQqom?= =?us-ascii?Q?8+CKVaEUtBuWzDjPaQqty3WwnadPtCyk3XQ2bGv9V3GgX3Q8DCdxcm0hpKmG?= =?us-ascii?Q?FIc3cKoBVnPXP45rLXqQjyWQJiRHN6RJ2Y3zpJV4t5pLLrU7mymZO5wJJs5+?= =?us-ascii?Q?wvSB6Qq1HU1Uu5LshKCcepu8lKXYyQdRUaPsPmCycjQD9dHFfEFOzxkwHPIG?= =?us-ascii?Q?f5I2OHmTDI/HY8pe+w8MbIckb5Rhbc9uKLSwbZ446FeUIBXikFYQ87ZHKpUI?= =?us-ascii?Q?F5QLBzCELf3popxgVCfaOVkR1uyVqdIgSK/+1w6ExLz8PLAwPNh372NmS8aG?= =?us-ascii?Q?9oBHIvJEy2t+X5cA8RUlTZh8co1JBlP1NY+qBy2R3yLKO0UzUdHpoWpwEO+c?= =?us-ascii?Q?S8zdVQ9obX1iYWayy5lbWRtmMDnwpdZGuh7Y6J2Ny81KmUWR6olOFPRgJjxu?= =?us-ascii?Q?tA6CJlr61e6ETVCe6Sr3cvMQIeVIPLZgNSCn42Wom5alNvCAIN6940yMsDW+?= =?us-ascii?Q?jMtYuyzVGiuaDW4r94pj7OysSN1ByRCj6s9R9QN0xpwW3qElWM/93LoQ9c5B?= =?us-ascii?Q?/a62f/r92LI6c26xJCvpwQ4jJd+7tFiERNi1N0GzCCuB1+nBq+un36tsln3l?= =?us-ascii?Q?t12eQ0F+s410/LtPTFv8NZ+OvUjkATPELGNwTZ77SXhU6aJMCWFwzem/u0Lj?= =?us-ascii?Q?orYMCLi49BZg0DUvZ1v5yjKwcxTCOXz8WS0rMHqj/zq3skpmrS2DuZd9NGht?= =?us-ascii?Q?/3JPX59nBb8CKiMTgZnAbhPMMshGJx7Gjs1iAvOJG8pJ9Ri5QgXO6cw+Qt8G?= =?us-ascii?Q?BXW+VU0mGQsjU3nHdSNaCfV0cxFMeJ2xdnGjUev+QXcTC4t3Bf1Tma5JZl4k?= =?us-ascii?Q?isUwqfL9b/17WsNtY12z7PL7yLF7RE+e2Qb3qocSareGEV4XxLTL8gIU/RoL?= =?us-ascii?Q?vkoHgzC89f4PqL703jkKpbk5wFDBENsWbxb9iESLMPimRw3N3XNZq3h+T/TN?= =?us-ascii?Q?usRrN9q2IqH0xIEjnUDy7J8LVvncNb46Bcm3gUoSMUBVqehKMEpDZXDIhEWx?= =?us-ascii?Q?Qd0XDQKXIsLXV0nc9c4fZIVeHeYMHYQScqZOoVsY4ixrs9FA23+njKvWuyUb?= =?us-ascii?Q?bWQnqwgNFqZpYBuEXKMa36iQHXQYyydUN1eoYtZIKfLvKpe+YxIV0bLhT0ok?= =?us-ascii?Q?rm4VXSi0WCUYUy5r0lEe6w7mb0o3JtmfmTsDcs42SsYVyDRB2v+/CIOLJ8ML?= =?us-ascii?Q?tw=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR13MB4795.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3d606742-9e91-4380-f20c-08d9e1c93955 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2022 19:14:21.4996 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YtdiHLw9bWDAP5Kcdh9xudMFW3f9/M4XQthapy+MGf+u6xueWTyQT6LHTAnX8nz/9wdtmQIWjD3GYqyFJDEytg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR13MB5976 Archived-At: Subject: Re: [mpls] agenda for the Open DT meeting 2022-01-27 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, 27 Jan 2022 19:14:31 -0000 Dear all, I have uploaded my slides presented today to the wiki under today's agenda. https://trac.ietf.org/trac/mpls/wiki/2022-01-27-agenda#no1 I'll be happy to continue the discussion in the email list or future meetin= gs.=20 Best regards, Haoyu=20 -----Original Message----- From: mpls On Behalf Of Loa Andersson Sent: Wednesday, January 26, 2022 7:47 PM To: mpls@ietf.org Cc: pals-chairs@ietf.org; mpls-chairs@ietf.org; DetNet Chairs Subject: [mpls] agenda for the Open DT meeting 2022-01-27 Open DT, Please find the agenda for todays meeting at: https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftrac.ie= tf.org%2Ftrac%2Fmpls%2Fwiki%2F2022-01-27-agenda&data=3D04%7C01%7Chaoyu.= song%40futurewei.com%7C8c9a5e64bb154caba12c08d9e147aeff%7C0fee8ff2a3b240189= c753a1d5591fedc%7C1%7C0%7C637788520289438290%7CUnknown%7CTWFpbGZsb3d8eyJWIj= oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sda= ta=3Dl2VMj6aauafq%2BlOxkBy8XLT3UJCNsnqbPMQJhsrrlRQ%3D&reserved=3D0 /Loa --=20 Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fmpls&data=3D04%7C01%7Chaoyu.song%40futurew= ei.com%7C8c9a5e64bb154caba12c08d9e147aeff%7C0fee8ff2a3b240189c753a1d5591fed= c%7C1%7C0%7C637788520289438290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi= LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3Dyhk%2FNBG= KZN%2FjJbKUE7FVUdLTsdcN268s9cMJ7eX5%2Bew%3D&reserved=3D0 From nobody Fri Jan 28 05:54:48 2022 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 983353A1475; Fri, 28 Jan 2022 05:54:40 -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: 7.43.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mpls@ietf.org Message-ID: <164337808047.29163.16895647978570577218@ietfa.amsl.com> Date: Fri, 28 Jan 2022 05:54:40 -0800 Archived-At: Subject: [mpls] I-D Action: draft-nainar-mpls-lsp-ping-yang-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 13:54:41 -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 : YANG Data Model for MPLS LSP Ping Authors : Nagendra Kumar Nainar Carlos Pignataro Madhan Sankaranarayanan Walker Zheng Filename : draft-nainar-mpls-lsp-ping-yang-02.txt Pages : 38 Date : 2022-01-28 Abstract: This document describes the YANG data model for Multi-Protocol Label Switching (MPLS) LSP Ping. The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8342. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-nainar-mpls-lsp-ping-yang/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-nainar-mpls-lsp-ping-yang-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-nainar-mpls-lsp-ping-yang-02 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Sat Jan 29 16:07:46 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EB13A16A7; Sat, 29 Jan 2022 16:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.097 X-Spam-Level: X-Spam-Status: No, score=-6.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAfggGlX_PDy; Sat, 29 Jan 2022 16:07:40 -0800 (PST) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 D33FD3A16A5; Sat, 29 Jan 2022 16:07:39 -0800 (PST) Received: by mail-ej1-x634.google.com with SMTP id m4so29916042ejb.9; Sat, 29 Jan 2022 16:07:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aWRNJYPBHyxVeT5HmrNoCg1F/ncI5TE4w5PRpEu0XRM=; b=gf11ksCoa2e4jzbAzHvk3fHcY3Ocnakg7b4p5bghE4VffezGCUnrKAjufhcinB2M3i 1DQNETJJ8dq6uiQN/0teq2Dg+Lh4YBb+3GMgruenGWOaV3D/4Tvw+HydwhKwF5OSf3/8 hvf+sAb9xEbvhX5VyzNV6ikWqoGRfXijYCO5yvuMEqcwmrNrdF9hXNBXcaSTBAciLA8A PBv63nAvGbutNrnlCxUDsswBcL6Pd6FMSDviRTZXDIhcnqP4nxHE3XZt5SNNg/9rW1L9 LBqD4Db8Wtigsd1hvrqZytSX3L7RgHlLZ2WAclSGwCXnYRXtFB0d9b5GSDuRKg50Oop/ LjjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aWRNJYPBHyxVeT5HmrNoCg1F/ncI5TE4w5PRpEu0XRM=; b=pcS7IkREtb32rzsgtqOzi4A1KrSx07vrrRIqGw3YUbt35mFnnZBdmUbbL7J4vsI/rw pnMacXEeAbLIdo2JwzrSh7ZN47RYFJTcOWh0p94QMtpLvUDM1PFV0AkapTTKasJywIlI 1SjUFlULZBYGPVtRhYOrNWGgtPko17EMz3XT2y5y2q9UgcSW3S3XrIEba+N/7VYyqXqg GDRAc1IVbSrAx/6ZEZD5MhK2F8D/2pzzFE4D4uzzOP+Ner/6fdxX1Womo9D5HDzTT5JD VKDhXCcNLaMHv7Ls0Fmdw9wcoQPdk8w+twwH1AbT5KZSI2ueUbKZhzq2oPGclMovNyTQ oLtA== X-Gm-Message-State: AOAM531uA+vE1UFXUIIbz8Cd/Oep0uIrYIbR4HGsvGkSgSaruvuFLZFm 1BJPicuVhzfsd98zC+KvCtF2lj5nzH3DkrUrpafVcPE2Spw= X-Google-Smtp-Source: ABdhPJxEEHi+aOvcPXDh4Dfu9AJTu2jyV4hWaYzN8r8ZT5S7FQTVJHFaKwBoLWfeNISxS0bUPqv97MRpNURo14yaNB8= X-Received: by 2002:a17:907:6e16:: with SMTP id sd22mr8385279ejc.172.1643501257222; Sat, 29 Jan 2022 16:07:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Sat, 29 Jan 2022 16:07:26 -0800 Message-ID: To: Loa Andersson Cc: "mpls@ietf.org" , "mpls-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009ff1a905d6c1745c" Archived-At: Subject: Re: [mpls] Where did the wg chair go? 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, 30 Jan 2022 00:07:45 -0000 --0000000000009ff1a905d6c1745c Content-Type: text/plain; charset="UTF-8" Hi Loa, sorry to hear you've been affected by the Omicron. Get well and stay safe. I think we're waiting for your decision on the WG AP of draft-mirsky-mpls-p2mp-bfd . A Healthy, Happy, and Prosperous New Year, the Year of the Water Tiger, to All! Regards, Greg On Tue, Jan 25, 2022 at 5:02 AM Loa Andersson wrote: > Working Group / Open DT, > > I#m now almost recovered from an infection by the Omicron variant of the > Corona virus. It has been two tough weeks, but I'm now ready to start > working again. > > We will have an Open DT meeting on Thursday. > > I will try to get the agenda out in reasonable time, but probably just > before the meeting starts. If you have items to be discussed plz let me > know. > > Also if you hsve documents that you suspect has fallen between the > chairs, please notify my. > > /Loa > -- > > Loa Andersson email: loa@pi.nu > Senior MPLS Expert loa.pi.nu@gmail.com > Bronze Dragon Consulting phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --0000000000009ff1a905d6c1745c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Loa,
sorry to hea= r you've been affected by the Omicron. Get well and stay safe.

I think we're waiting for your decision on the WG AP o= f=C2=A0draft-mirsky-mpls-p2mp-bfd.

A=C2=A0 Healt= hy, Happy, and Prosperous New Year, the Year of the Water Tiger, to All!

Regards,
Greg
=

= On Tue, Jan 25, 2022 at 5:02 AM Loa Andersson <loa@pi.nu> wrote:
Working Group / Open DT,

I#m now almost recovered from an infection by the Omicron variant of the Corona virus. It has been two tough weeks, but I'm now ready to start <= br> working again.

We will have an Open DT meeting on Thursday.

I will try to get the agenda out in reasonable time, but probably just
before the meeting starts. If you have items to be discussed plz let me know.

Also if you hsve documents that you suspect has fallen between the
chairs, please notify my.

/Loa
--

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=C2=A0 =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.pi.nu@gmail.com
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
--0000000000009ff1a905d6c1745c-- From nobody Mon Jan 31 03:27:34 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6463A2D30 for ; Mon, 31 Jan 2022 03:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQHJOCEhIQmb for ; Mon, 31 Jan 2022 03:27:28 -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 A69FA3A2D71 for ; Mon, 31 Jan 2022 03:27:13 -0800 (PST) Received: from [192.168.1.98] (unknown [112.206.242.125]) (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 22B913660A2; Mon, 31 Jan 2022 12:27:09 +0100 (CET) Message-ID: <5cd6a374-d677-15c5-c721-77614de00c7f@pi.nu> Date: Mon, 31 Jan 2022 19:26:33 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Content-Language: en-CA To: "mpls@ietf.org" , Haoyu Song From: Loa Andersson Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] Question on avoiding TLVs 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, 31 Jan 2022 11:27:33 -0000 Haoyu, In the slides you uploaded to the "We should try the best to avoid TLV style and variable sized header". MPLS is full of TLVs (LDP, RSVP/TE, LSP Ping, the OAM) are you suggesting we'd change this? Given your advice above what should we do? /Loa -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Mon Jan 31 07:39:29 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01AA13A08B6; Mon, 31 Jan 2022 07:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.098 X-Spam-Level: X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 3ql41nQ-D6nY; Mon, 31 Jan 2022 07:39:22 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (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 BBDBF3A08B3; Mon, 31 Jan 2022 07:39:18 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr26.francetelecom.fr (ESMTP service) with ESMTPS id 4JnXKw2HTTz103N; Mon, 31 Jan 2022 16:39:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1643643556; bh=jRFEMroAv4RMvPCog6EYCvDtRJDZKc5Lni+4XAvSk6o=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=h4q3UO70CVt6JEIqSlO2AHkbNCOKhPD4mxjfcibgWA5RALRs0b1gvW1OKTWbOUKN3 vXM8eCNHph8hzOdQA0Z+F2mR1SOrPkfezfLsFtKgUIym5aomZ9SMhRL5wCT1+jqMNw sbQXSNRYgnHPy8OSZLe4ssknV/pv43rRF3mHlaKugMdgtvI+fUXM9dyozZIkOE5qrL Cmv5VWOI+Oa1LK9AXUQu+/xyGXiljsQ8cdIYRYXq42hgaKiQEtTSWHO7IXvQ7WLpeg 7NQxmcS/6BEn6VfZ05uVNPlgBrlcRqEcyj8cwMH96XS6MJYUYw34H3XagOUIRQauaM MKnN6LtSO2lbQ== From: To: mpls , DetNet WG , "pals@ietf.org" CC: "draft-jags-mpls-ext-hdr-entropy-lbl@ietf.org" Thread-Topic: draft-jags-mpls-ext-hdr-entropy-lbl-00 Thread-Index: AdgThPQiwEtGuhGXQqCZhc8rIBv3FwAC464PAMn60dA= Date: Mon, 31 Jan 2022 15:39:15 +0000 Message-ID: <1301_1643643556_61F802A4_1301_421_1_c41f150d9b98444790c42923b95f05b5@orange.com> References: <18200_1643292207_61F2A62E_18200_48_39_7d4b44ce4415491f984174e9946c7c68@orange.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-01-31T15:39:14Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_enabled: true msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_setdate: 2022-01-31T15:39:14Z msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_method: Standard msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_name: Orange_restricted_external.2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_siteid: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_actionid: 1bf3af1d-8615-42dc-959d-befad6e3c534 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_contentbits: 0 x-originating-ip: [10.115.26.50] Content-Type: multipart/alternative; boundary="_000_c41f150d9b98444790c42923b95f05b5orangecom_" MIME-Version: 1.0 Archived-At: Subject: [mpls] draft-jags-mpls-ext-hdr-entropy-lbl-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: Mon, 31 Jan 2022 15:39:27 -0000 --_000_c41f150d9b98444790c42923b95f05b5orangecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, 1) As previously presented and discussed, section 2 of draft-decraene-mpls-= slid-encoded-entropy-label-id [1] proposes to use the unused bits of the En= tropy Label TTL field to carry indicators in the stack. This provides the following benefits: - Faster deployment with incremental benefit. (as most/all egress LER alre= ady support ELI so won't drop the packet) - Assuming EL used, no extra labels added in the stack (ECMP is largely use= d and EL helps, so a chance that EL be already present) - Save a special purpose label (and related routing extensions to signal it= s support in LDP, RSVP-TE, BGP, IS-IS, OSPF, BGP-LS) 2) Indicators are useful for different use cases, yet new uses cases may re= quire additional data. draft-jags-mpls-ext-hdr-entropy-lbl [2] builds on top of the above indicato= rs to signal the presence of In-Stack (IS) and Bottom of Stack (BOS) MPLS E= xtension Header (MEH) in an MPLS label stack. Specifically, it defines MPLS Extension Header encoding formats to carry ad= ditional data in the MPLS label stack that can influence forwarding decisio= n and to carry additional data (such as IOAM) after the Bottom of the MPLS = label stack. Comments welcomed. Thanks, Bruno (on behalf of the authors) [1] https://datatracker.ietf.org/doc/html/draft-decraene-mpls-slid-encoded-= entropy-label-id#section-2 [2] https://datatracker.ietf.org/doc/html/draft-jags-mpls-ext-hdr-entropy-l= bl -----Original Message----- From: internet-drafts@ietf.org > Sent: Wednesday, January 26, 2022 5:21 PM To: DECRAENE Bruno INNOV/NET >; Jaganbabu Rajamanickam >; Jisu Bhattacharya >; Ra= kesh Gandhi >; Royi Zigler > Subject: New Version Notification for draft-jags-mpls-ext-hdr-entropy-lbl-0= 0.txt A new version of I-D, draft-jags-mpls-ext-hdr-entropy-lbl-00.txt has been successfully submitted by Jaganbabu Rajamanickam and posted to the IETF repository. Name: draft-jags-mpls-ext-hdr-entropy-lbl Revision: 00 Title: MPLS Extension Header Encodings Using Entropy Label Document date: 2022-01-26 Group: Individual Submission Pages: 24 URL: https://www.ietf.org/archive/id/draft-jags-mpls-ext-hdr-ent= ropy-lbl-00.txt Status: https://datatracker.ietf.org/doc/draft-jags-mpls-ext-hdr-en= tropy-lbl/ Html: https://www.ietf.org/archive/id/draft-jags-mpls-ext-hdr-ent= ropy-lbl-00.html Htmlized: https://datatracker.ietf.org/doc/html/draft-jags-mpls-ext-h= dr-entropy-lbl Abstract: This document uses the Multiprotocol Label Switching (MPLS) Entropy Label (EL) extensions defined in draft-decraene-mpls-slid-encoded- entropy-label-id to indicate the presence of MPLS Extension Header (MEH) in an MPLS label stack. It defines different MPLS Extension Header encoding formats to carry additional data in the MPLS label stack that can influence forwarding decision and to carry additional data after the Bottom of the MPLS label stack. The IETF Secretariat ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. Orange Restricted ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_c41f150d9b98444790c42923b95f05b5orangecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

1) As previously presented and discussed, section 2 of draft-decraene-mpls-= slid-encoded-entropy-label-id [1] proposes to use the unused bits of the En= tropy Label TTL field to carry indicators in the stack.
This provides the following benefits:
- Faster deployment with incremental benefit.  (as most/all egress LER= already support ELI so won’t drop the packet)
- Assuming EL used, no extra labels added in the stack (ECMP is largely use= d and EL helps, so a chance that EL be already present)
- Save a special purpose label (and related routing extensions to signal it= s support  in LDP, RSVP-TE, BGP, IS-IS, OSPF, BGP-LS)


2) Indicators are useful for different use cases, yet new uses cases may re= quire additional data.
draft-jags-mpls-ext-hdr-entropy-lbl [2] builds on top of the above indicato= rs to signal the presence of In-Stack (IS) and Bottom of Stack (BOS) MPLS E= xtension Header (MEH) in an MPLS label stack.
Specifically, it defines MPLS Extension Header encoding formats to carry ad= ditional data in the MPLS label stack that can influence forwarding decisio= n and to carry additional data (such as IOAM) after the Bottom of the MPLS = label stack.

Comments welcomed.

Thanks,
Bruno (on behalf of the authors)

<= span lang=3D"EN-CA" style=3D"mso-ansi-language:EN-CA">

[1] https://datatracker.ietf.org/doc/html/draft-decraene-mpls-slid-encoded-entr= opy-label-id#section-2
[2] https://datatracker.ietf.org/doc/html/draft-jags-mpls-ext-hdr-entropy-lbl


-----Original Message-----
From:
internet-drafts@ietf.org<= /a> <internet-drafts@ietf.or= g>
Sent: Wednesday, January 26, 2022 5:21 PM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>; Jaganbabu Rajamanickam <jrajaman@cisco.com>; Jisu Bhattacharya &= lt;jisu@cisco.com>; Rakesh Gandhi <rgandhi@cisco.com>; Royi Zigler <royi.zi= gler@broadcom.com>
Subject: New Version Notification for draft-jags-mpls-ext-hdr-entropy-lbl-0= 0.txt


A new version of I-D, draft-jags-mpls-ext-hdr-entropy-lbl-00.txt
has been successfully submitted by Jaganbabu Rajamanickam and posted to the=
IETF repository.

Name:           draft-jag= s-mpls-ext-hdr-entropy-lbl
Revision:       00
Title:          MPLS Extension= Header Encodings Using Entropy Label
Document date:  2022-01-26
Group:          Individual Sub= mission
Pages:          24
URL:            https://www.ietf.org/archive/id/draft-jags-mpls-ext-hdr-entropy-lbl-00.txt<= /a>
Status:        
https://datatracker.ietf.org/doc/draft-jags-mpls-ext-hdr-entropy-lbl/ Html:           https://www.ietf.org/archive/id/draft-jags-mpls-ext-hdr-entropy-lbl-00.html=
Htmlized:       https://datatracker.ietf.org/doc/html/draft-jags-mpls-ext-hdr-entropy-lbl


Abstract:
   This document uses the Multiprotocol Label Switching (MPLS) En= tropy
   Label (EL) extensions defined in draft-decraene-mpls-slid-enco= ded-
   entropy-label-id to indicate the presence of MPLS Extension He= ader
   (MEH) in an MPLS label stack.  It defines different MPLS = Extension
   Header encoding formats to carry additional data in the MPLS l= abel
   stack that can influence forwarding decision and to carry addi= tional
   data after the Bottom of the MPLS label stack.

            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       


The IETF Secretariat


___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

 

Orange Restricted

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_c41f150d9b98444790c42923b95f05b5orangecom_-- From nobody Mon Jan 31 07:49:18 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6603A0125; Mon, 31 Jan 2022 07:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 MkCCAnYnUCpj; Mon, 31 Jan 2022 07:49:11 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (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 6D8143A0123; Mon, 31 Jan 2022 07:49:11 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr22.francetelecom.fr (ESMTP service) with ESMTPS id 4JnXYK4JbCzygc; Mon, 31 Jan 2022 16:49:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1643644149; bh=PAYhs9yBstMAcaTJ5Y1qgvo85JfuJUcqVF+ZzQMdTEE=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=iF1Raez30giOnxZvuXJBskRsh7TcDWfhx7t0dz0NYbHtP4I94SQLVKwInbIQCzFBA Al0SFd5d0RWTlvVx8h0tY5Cg0O39F3d4YOba6mr8D89OgBinPQwKYYJJgQj3lTl/Sp +3g/YgZJ/QIbAFhdjJ0FoXJuGO3VrEzzsK3hTX+h8/qheNvAHdP0GlvZH5D2t9G+s1 mIPRYVmt5TFNIV+ZBVgDaNTMvdNV+5QRp+9ya6IZhRpRejBp9UXnhPt7zfH+sHq8FN W65vah8srhXuguQROPPConqB6fvtynU8t6TUJ2jBq7vhUedI11TLYNpAvNQklN1COn Xq7JJkdW4bRxQ== From: To: Tarek Saad , "mpls@ietf.org" CC: "mpls-chairs@ietf.org" , "pals-chairs@ietf.org" , DetNet Chairs , Loa Andersson Thread-Topic: Agenda for the Open T meeting 2022-0113 Thread-Index: AdgWuhTL+5dY3LNuQjCSClQG1/eVEw== Date: Mon, 31 Jan 2022 15:49:09 +0000 Message-ID: <18967_1643644149_61F804F5_18967_287_3_92cffa12b40b41c49ca578110111cc70@orange.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-01-31T15:49:07Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_enabled: true msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_setdate: 2022-01-31T15:49:07Z msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_method: Standard msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_name: Orange_restricted_external.2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_siteid: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_actionid: 3e91f6f8-4fb7-4eb9-9d5f-b797927dc23e msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_contentbits: 0 x-originating-ip: [10.115.26.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] Agenda for the Open T meeting 2022-0113 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, 31 Jan 2022 15:49:17 -0000 RGVhciBhbGwsDQoNCj4gRnJvbTogVGFyZWsgU2FhZCA8dHNhYWQubmV0QGdtYWlsLmNvbT4NCj4g U2VudDogVHVlc2RheSwgSmFudWFyeSAxMSwgMjAyMiAzOjA0IFBNDQo+IA0KPiBIaSBhbGwsDQo+ IA0KPiBUaGUgdGVudGF0aXZlIGFnZW5kYSBjb21wb3NlZCBieSBDaGFpcnMgZm9yIHRoaXMgVGh1 cnNkYXkncyBNUExTIE9wZW4gRFQNCj4gbWVldGluZyBpcyBhdDoNCj4gaHR0cHM6Ly90cmFjLmll dGYub3JnL3RyYWMvbXBscy93aWtpLzIwMjItMDEtMDEzLWFnZW5kYQ0KPiANCj4gS2lyZWV0aS9C cnVubyB5b3UndmUgYmVlbiBhZGRlZCB0byBnaXZlIHVwZGF0ZXMgYXMgcGVyIGxhc3Qgd2Vlaydz IGFjdGlvbiBpdGVtcy4NCg0KRllJLCBJJ3ZlIHVwbG9hZGVkLCBhcyBhdHRhY2htZW50LCBteSBz bGlkZXMgcHJlc2VudGVkIGR1cmluZyB0aGF0IG1lZXRpbmcuDQpodHRwczovL3RyYWMuaWV0Zi5v cmcvdHJhYy9tcGxzL3dpa2kvMjAyMi0wMS0wMTMtYWdlbmRhI25vMQ0KDQpSZWdhcmRzLA0KLS1C cnVubyANCg0KPiBSZWdhcmRzLA0KPiBUYXJlayAoZm9yIHRoZSBDaGFpcnMpDQo+IA0KPiDvu79P biAyMDIyLTAxLTA1LCAxMTo0NSBBTSwgIkxvYSBBbmRlcnNzb24iIDxsb2FAcGkubnU+IHdyb3Rl Og0KPiANCj4gICAgIE9wZW4gRFQsDQo+IA0KPiANCj4gICAgIFBsZWFzZSBmaW5kIHRoZSBhZ2Vu ZGEgZm9yIHRoZSBmaXJzdCBNUExTIDIwMjIgT3BlbiBEVCBtZWV0aW5nIGF0Og0KPiANCj4gICAg IGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL21wbHMvd2lraS8yMDIyLTAxLTA2LWFnZW5kYQ0K PiANCj4gICAgIC9Mb2ENCj4gDQo+IA0KPiAgICAgLS0NCj4gICAgIExvYSBBbmRlcnNzb24gICAg ICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQHBpLm51DQo+ICAgICBTZW5pb3IgTVBMUyBF eHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYS5waS5udUBnbWFpbC5jb20NCj4gICAg IEJyb256ZSBEcmFnb24gQ29uc3VsdGluZyAgICAgICAgICAgICBwaG9uZTogKzQ2IDczOSA4MSAy MSA2NA0KDQpPcmFuZ2UgUmVzdHJpY3RlZA0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRp ZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNl cywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJl Y3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRp dGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVz c2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVy ZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlv biB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJp YnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkg YmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBi ZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Mon Jan 31 08:46:34 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6073A0CFB for ; Mon, 31 Jan 2022 08:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.09 X-Spam-Level: X-Spam-Status: No, score=-7.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXZU3JXOOSMR for ; Mon, 31 Jan 2022 08:46:27 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1anam02on2118.outbound.protection.outlook.com [40.107.96.118]) (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 DBACE3A0CFA for ; Mon, 31 Jan 2022 08:46:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Fbq19+VynBgiFr/QnfucLnNFW2rPg2XR/e6fCbVJhiur8k2yhh7LR8gM+Ab4wwXA2/FRI90wcOKyCgx2aFXKlujwpSJ5HFJi0DXVKWLy6PumxKAjuvbn4rg5NZeaCnBtLRB8GoxKBF4Mjk/7ZA2nhjhGD8HhC1I7MD9IdtGdK02i6N4q5kbawDBmJt/Aw50wKYQm7ZoGWDC0kxxNA/Iqs9bQUmdJtwZV+DxRJRssU43VCe3jLxica2qDspqktNRfKrXLUsm4PyEUwN74Bnx8UEIMR9HppPjMMK7LkKhf6xx/kCZI97kH8waEzxQ4odYB8PRgUe7q1qmzQFOK59E7cw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4Lf6iMaPer9gSaX8TZNoPTKulsKbfSojW3N/aEq9ZbQ=; b=l07m6VN9yhB6aUJtp7ZwYsNVNTljrKY37a+rAWFDswcEMUIbkHlOhhoI64mMduDsMjxDZrHCd0ApwJK64cdVAa4AYJ2bfqeiA+NFFQgAXOogp7OnXuM/kYYSdtWaJtj9SeQ2mgUnHVr4+HM/+aWBRvw8DHBL+dcqOFZD81/bEJ4FAdWPqDxbmSzdRWgpvDWoipMGKaF62yWGu7o3qOyyvQxhJW0oACFYKljTfA0ZYKHBOr7307mZHppvqCZc9p7akQwkINyU+duWnfp3QPT2Ka3P6KwvzWYYfBQnCdWN+1sBEI2cAhVJWwPjZ1u6nMcUJybvJhgjh7tYWp/zyDNHnA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4Lf6iMaPer9gSaX8TZNoPTKulsKbfSojW3N/aEq9ZbQ=; b=rkAA5/1eGtwkynf5aYh5PPpwLVX18jGvq4/e4YsJJ8FCfHVeO1Rv/wXmoFJ/eNdgL6mxwOh0EG6Forbi0NqFQkbWtT8apARVR9gw+w5PJqTisn85pChboHO5Cy0JjdkkFOb2QhlKvvRycmS1o/Rz/JPDho9ec0XwOuCsDwzwXSA= Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by MN2PR13MB3119.namprd13.prod.outlook.com (2603:10b6:208:139::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.11; Mon, 31 Jan 2022 16:46:25 +0000 Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264%6]) with mapi id 15.20.4951.011; Mon, 31 Jan 2022 16:46:25 +0000 From: Haoyu Song To: Loa Andersson , "mpls@ietf.org" Thread-Topic: Question on avoiding TLVs Thread-Index: AQHYFpWCXPZU/LYjpkyDkzjBq91GR6x9U/ng Date: Mon, 31 Jan 2022 16:46:24 +0000 Message-ID: References: <5cd6a374-d677-15c5-c721-77614de00c7f@pi.nu> In-Reply-To: <5cd6a374-d677-15c5-c721-77614de00c7f@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7f45fe65-6f5f-4b45-c3c5-08d9e4d9382f x-ms-traffictypediagnostic: MN2PR13MB3119:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Z88nGnZzj7+aqwZj3FXBFYunFfHmDksU7x2kdVgW0YIL3XI84CBB25GFQiO3VxbbQFKHs0+4Eds+0qkdM+MyVUzyBVizQf0PAoLzuOY+1BXDilUOtSEpz9OtZ9EQhPKFU81j1UeTqxnqOOLrVx6GNWrB6oPZCDKGakc+kZ6/1QUUrhTjxAdfd0mvInstDIsfADSP05yzvfJfoEmS2RPRqmjHKiSvPCeJ3KtYLoKn3+mUYO+G3Xp6eIkqu2EADg99Cg83KQMIM/cqoaES/rpXA07IN79UqSInw+2cbTRs8xgpQawulCSvkn0p6KmykCQYgyok2Jf5FtmDXQ+F0DBzv6Cu6L3epPF2BjyZYeVVx1Z2BMl9YTv8AtpVLymxdYuEt3lIfkJT2M04JBiDBuh35B97RZqlPYyQQFcovr0B41xTqT6deLfNGNFF4NcnsucFBiFP1TOgYqWTqq/F0A289ESmHwSOAlyQKWKKjc5IN/CWvZAy3Tmz7celZJk778fnAfaR0DT16//Qu5vf4v4Sl434dmTbjQypBgHGJ2swqg/cxH7SLdQu06k0WxZlRg8Wt+sDw4d3URUo0Jd+neTQSo2OIuapTNbDiZLaU4zvwx2wy1H8Qjn4AxWntg1Lmd4KepGXLjQdWuul0/UTDaxuhUlMXca5dHF1f0BrNX6LOmBrLYeT40pNnha+QALZoFkBBPkHonrl4+VDmdJVenahhw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(26005)(186003)(83380400001)(2906002)(53546011)(33656002)(7696005)(6506007)(71200400001)(508600001)(3480700007)(316002)(110136005)(122000001)(76116006)(38070700005)(38100700002)(55016003)(44832011)(52536014)(86362001)(9686003)(64756008)(66446008)(66476007)(5660300002)(8676002)(66946007)(8936002)(66556008)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Q0VaNktPN3ZRVmM1RldFTk05MFlWSDN6dVkydHc4azlsbm9BMGtaUVV3NW04?= =?utf-8?B?RURuUmFMYVJaRU9MN3Fidnd3NTVscFg3b0tJMUkrVkRwS25idVRIdlpvSita?= =?utf-8?B?MjNQdHVEOUlBMzRMbzJnZ2FhM3BZTk1YSC9rbmxZKzBDM2hpVDdnRXdGditQ?= =?utf-8?B?WWhMMHNMbWp5OWNVQmQwdXJEeTViakZnU1pia0E2ejUrZ3E2RzhtbG9rcDg0?= =?utf-8?B?UnRSNy9PTDZwQkk0c240aTFoWlVEd1JJL0hwM0JnaWVzSndJZ0xVcy9Id1FV?= =?utf-8?B?YTl0bGoyemU1dFdrV3JLVkhSS2VsYUQ1Skg4UTdleWoyaHZrOW95OEtwWFVS?= =?utf-8?B?alVoVnFOV005NEw3YzUzV3NwcGhQZDBOYmRTNDlZdS8vc2Y4ZjkrSU5QNzZs?= =?utf-8?B?NUsrNDFiT3QvdkRIM1luM2JoYzZpT3pKODEyT2thWS9HcC9rQWlOc3E2YjRx?= =?utf-8?B?c3RaR2F4cU9xR1Jla3c2dVhBZ2FvTWFLUGFHNzFZck5IaURLNyt2V1c0RVNr?= =?utf-8?B?QU1QZ3RpT1RXWFp2TnlLd2NJazFwTllleGhHZFZQSEY4aVJ1b3lWRktQME5v?= =?utf-8?B?YitMV1BNRVB1OTZPMG5NTzdIcTA2ZEZwZ0V5bWovSDQvM1B3Qm1DUDhmK1lX?= =?utf-8?B?VFlOVlVLMnRPaHlaQ3dkUVFGMFdYc0FqN3EzY3JyMlhFbDRndE1BZ0c4eEp2?= =?utf-8?B?SitqUWZyQ21wS3JibGI0SnhRUHBCRWp1VTlpK2tVRzJmRUh0QzVNUm9OcEl4?= =?utf-8?B?cTRLdktoc0pHYzFDajA3ZzJhZ3B6dVp4all2SEJyVXl6Q1RtZ1Z5RmJvMnRu?= =?utf-8?B?K0MyY21VSVlZRVZHZGd4aDN5VUI1eitLdHpKWVhzc1l5NHRHK2tBSmVHbDY4?= =?utf-8?B?OWlIQXdoSC9WaDFCMlVpS3ZtbGpZUFNFN093ZVU3STl4SFJuNDRzSFJzV2tn?= =?utf-8?B?YzZYYTVBc1hBQm1pb2d5SWdXMThzZFc0Z2p4cVZPamhxekhqWGpwcnJUOEg0?= =?utf-8?B?dHJNY29raTRQckllS0RNbms5bnN5Wlg4VW03SXNkSEwrSzNhdG14Q1pxbkZx?= =?utf-8?B?T0F1OVJJbE84MnlCQnJWVnR2Z1FCb3pwa1M3eWRjQU45Z25OYmxvTmdldE5m?= =?utf-8?B?aEYxOVlxTzZmZVllRHFrT25CRDRzQkdmQTdKdC84UjZ4bEQzL1ppUUR4ZTFu?= =?utf-8?B?VUhMVVovbUNwUENXb1V4L0k0QTREaVJDNEdIL0orVGNFWXh6Nk16RWdLSWJO?= =?utf-8?B?NkQ4L24wY0dUd1B5RG96MDhzU0hsY1cxdExKeE5Vdk5OeElVVzVBdWFvL3Z4?= =?utf-8?B?ZUpFM3VKMVpBUDdOZFRKeDF1NjY2eWt0Rm5TTkI4MFRFb2RPbm1xR29oZkFa?= =?utf-8?B?eDNPZ1VGQkY1UE04eG5VdU1YRTFyS2s3L1drek15S0VWTHI0MjJQbUM3a0M5?= =?utf-8?B?Z0JTYmV1YlVIQjJpa3l5TWJzNTFHYm1lSzZSc25CU203UlQza0VXQ0dpKzJR?= =?utf-8?B?cDkrQ2RtU05MWUMrMldLMk9uQTZ5czVOdHdnMnI4ZU9EeFNZL1VHdnh2N0pw?= =?utf-8?B?WXhrSHg5cEQzSEZZOTRnZkdrMVc5VzVRSm00ZTlUZ3JiRExCaVhwY0xJQzAv?= =?utf-8?B?R3RZTTV0NUVUQmNsYzFkOEVnQVFpdm0xelVVV3JQRHB3RTJqNVYrVU0vaCsy?= =?utf-8?B?QWhiem1KdjFydnYwMjFwVHZOSmhHSFRFckxyVnYxZW0xSDBpUnBJSy9Pcmt1?= =?utf-8?B?bStpbjVldXExMGhBSWtIaUkwWFZhQUQ4bVR5M3VSdVdpNDNEZkN4aXBWZHh5?= =?utf-8?B?dkpTNzJWcW5ES1ZlUU14MlFPUHZRdlRFODQ0M2Y4dEZOQ3VvdktzM0ZhL0wz?= =?utf-8?B?TGZlaWU3ZHczQk9wK2dMSm9sTDNhVVV0Q0lDWXNZbk1JSGJNOXZSeWFXY0JF?= =?utf-8?B?MnE4OE8yVDFIQUx1dmhFaGdQL0h5eXRXYUR6T3p0TGRidTBWY0J4UkdjT1Za?= =?utf-8?B?enBuZWtzT2U2d3Y4anlMTFdUaS9rQnB1akdNeDdxY0xFcWV6Z0xWSmszaU1r?= =?utf-8?B?R2hxR2xoemhGNE5IUkhQaE5GS2RyUnlaa25jTWtQRlIvUlVQendNQkNidHVx?= =?utf-8?B?dm5ZR3RwMmJQUU1LNXpPYkRrOUpieFg2LzFuYmgvY3RZS0xqeUV2U2g2WDhz?= =?utf-8?B?dVE9PQ==?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7f45fe65-6f5f-4b45-c3c5-08d9e4d9382f X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2022 16:46:24.8826 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zH3ZpmaqOLBwZFTCdP638jwO0ZFw+wL92nhLRG/e0EFWpQSBdy58pDdvZzwq3bVvJ1dzNsvqgB4kKmhhcwBDvg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3119 Archived-At: Subject: Re: [mpls] Question on avoiding TLVs 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, 31 Jan 2022 16:46:33 -0000 SGkgTG9hLA0KDQpVc3VhbGx5IFRMViBpcyB1c2VkIGFzIGEgc3Vic3RydWN0dXJlIGluIGEgaGVh ZGVyLiBGb3Igc3ViIGZpZWxkcyBpbiBhIGhlYWRlciwgdXN1YWxseSB3ZSBkb24ndCBoYXZlIG90 aGVyIGNob2ljZXMgdGhhbiB1c2luZyBUTFYuICBCdXQgZm9yIGVhY2ggaGVhZGVyLCB0aGUgdHlw ZSBvZiBpdCBpcyBiZXR0ZXIgdG8gYmUgaW5kaWNhdGVkIGJ5IHRoZSBwcmV2aW91cyBoZWFkZXIg dG8gc2F2ZSBhIHBhcnNpbmcgc3RhdGUuIA0KU28gYWxsIHdoYXQgSSBzYXkgaXM6IGFzIGEgcHJp bmNpcGxlLCB3aGVuIGRlc2lnbmluZyBhIGhlYWRlciwgdHJ5IG5vdCB0byBlbWJlZCBpdHMgdHlw ZSBpbiB0aGUgaGVhZGVyIGl0c2VsZi4gSW5zdGVhZCwgYmVmb3JlIHdlIGdldCB0byB0aGlzIGhl YWRlciwgd2Ugc2hvdWxkIGFscmVhZHkga25vdyBpdHMgdHlwZS4NCg0KTW9yZW92ZXIsIFRMViBv cHRpb25zIGluIGEgaGVhZGVyIGFsc28gaW5jcmVhc2VzIHRoZSBwYXJzaW5nIGNvc3QuIEVhY2gg Zml4ZWQgc2l6ZSBUTFYgbmVlZHMgdHdvIHN0YXRlcy4gRWFjaCB2YXJpYWJsZSBzaXplIFRMViBu ZWVkcyBtdWx0aXBsZSBzdGF0ZXMgZGVwZW5kaW5nIG9uIHRoZSBzaXplIG9mIHRoZSBvcHRpb24u IFNvIGFub3RoZXIgYWR2aWNlIGlzOiBpZiBpdCBpcyBtZWFudCB0byBiZSBwcm9jZXNzZWQgaW4g aGFyZHdhcmUsIHRoZW4gd2Ugc2hvdWxkIHRyeSB0byBsaW1pdCB0aGUgdXNlIG9mIFRMViwgYW5k IGVzcGVjaWFsbHkgdmFyaWFibGUgc2l6ZWQgVExWLCB1bmxlc3MgYWJzb2x1dGVseSBuZWNlc3Nh cnkuDQoNCkJlc3QsDQpIYW95dQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog TG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51PiANClNlbnQ6IE1vbmRheSwgSmFudWFyeSAzMSwgMjAy MiAzOjI3IEFNDQpUbzogbXBsc0BpZXRmLm9yZzsgSGFveXUgU29uZyA8aGFveXUuc29uZ0BmdXR1 cmV3ZWkuY29tPg0KU3ViamVjdDogUXVlc3Rpb24gb24gYXZvaWRpbmcgVExWcw0KDQpIYW95dSwN Cg0KSW4gdGhlIHNsaWRlcyB5b3UgdXBsb2FkZWQgdG8gdGhlICJXZSBzaG91bGQgdHJ5IHRoZSBi ZXN0IHRvIGF2b2lkIFRMViBzdHlsZSBhbmQgdmFyaWFibGUgc2l6ZWQgaGVhZGVyIi4NCg0KTVBM UyBpcyBmdWxsIG9mIFRMVnMgKExEUCwgUlNWUC9URSwgTFNQIFBpbmcsIHRoZSBPQU0pIGFyZSB5 b3Ugc3VnZ2VzdGluZyB3ZSdkIGNoYW5nZSB0aGlzPw0KDQpHaXZlbiB5b3VyIGFkdmljZSBhYm92 ZSB3aGF0IHNob3VsZCB3ZSBkbz8NCg0KL0xvYQ0KLS0gDQpMb2EgQW5kZXJzc29uICAgICAgICAg ICAgICAgICAgICAgICAgZW1haWw6IGxvYUBwaS5udQ0KU2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAg ICAgICAgICAgICAgICAgICAgICBsb2EucGkubnVAZ21haWwuY29tDQpCcm9uemUgRHJhZ29uIENv bnN1bHRpbmcgICAgICAgICAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCg== From nobody Mon Jan 31 09:03:40 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E693A0DA7 for ; Mon, 31 Jan 2022 09:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 5ndBdyACKFZ3 for ; Mon, 31 Jan 2022 09:03:32 -0800 (PST) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 99FA03A0D9D for ; Mon, 31 Jan 2022 09:03:32 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id i186so10908316pfe.0 for ; Mon, 31 Jan 2022 09:03:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+Z2fYw+C/V0+Dfo01dll8cScBFdyQylMZGqCAOCNQx4=; b=Ve5957oU4DI/JVdgOMqFFo8QxuooRys5bOwISjaGy4/eOSLFg7hCGZuFOXQ5ZIjUTH MyHY9ej/I2nXCfciq+h6nmZMYEFV6gD3yg6X4H7skzn4A/NwVOkLnXpNfA7jFXZxjf8c kAi3YeFV5aRsTQL35lQBEc/a3/UzJtnLpB4IKVZM+FsjoQJ8+SVGueSiG1eP5AjEcl/f 6IdKqHYjaMdYnm3vbv6fBA5GBpwXbmUUJD/cHgijhd7KJyI4QCfRnC37UUnfVLJUTZD2 +HqZM+b3TJXKcepXUu4+SIvbkMn8ak8alinKj0nM0vIdSs/5jlMj4Tz1uhu761fGtVWI ZeoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=+Z2fYw+C/V0+Dfo01dll8cScBFdyQylMZGqCAOCNQx4=; b=WrIZCK6X0OOa3pheT3H58bTP0huDvC6+2MzTN2xJsdNyADewdcFH/8+Q6/uJQIRfzE 7ZGaF3fEaStL5kZyRzaxOF5QeEB634PUIUtVpH6rzmRSdUayb2yvjSa2IPdhL8t/ub1P ecYb+lfGm2M8NB+OxO+Z+gFHWDgsw9E96dXmQd5OglpFeoER40tkX8V4pKwEQRG7+ZxC OzdAYMU3YV5CDFV1UqBQEBq5L++i26i2+qVBlecx62viF3SYmiivDpMvPtD/qDToELbt f8YGYasOUJDCQjnglRjxxzrX6ncBiCZSpEa27dEk+K3SQp1gfHGoRn3/+Qn/DWyxkyzj o4Ag== X-Gm-Message-State: AOAM530C8nbdEgf3T/4rpqemav15NhP1GXaOlh78p6i2MrK4lFbTFtJi 0lcLUp/Jw3AHH6yDbQDvBB2J4CBn39E= X-Google-Smtp-Source: ABdhPJzkP9TPalWHb7sVNlsO6w3jo/7+qSuBGaodSOD+P/5W6IU33vlLU4aWJKlPs0HbyBZySS8ZAQ== X-Received: by 2002:a63:81c7:: with SMTP id t190mr17555378pgd.575.1643648610536; Mon, 31 Jan 2022 09:03:30 -0800 (PST) Received: from smtpclient.apple (c-67-169-103-239.hsd1.ca.comcast.net. [67.169.103.239]) by smtp.gmail.com with ESMTPSA id j11sm11918987pjf.53.2022.01.31.09.03.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Jan 2022 09:03:30 -0800 (PST) Sender: Tony Li Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) From: Tony Li In-Reply-To: Date: Mon, 31 Jan 2022 09:03:27 -0800 Cc: Loa Andersson , "mpls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3BD86173-D24E-4669-91AD-B8C1E349D344@tony.li> References: <5cd6a374-d677-15c5-c721-77614de00c7f@pi.nu> To: Haoyu Song X-Mailer: Apple Mail (2.3693.40.0.1.81) Archived-At: Subject: Re: [mpls] Question on avoiding TLVs 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, 31 Jan 2022 17:03:38 -0000 Haoyu, Loa, I think the important point here is that the parsing discussion is = focused on the forwarding plane. TLVs are pervasive in the control = plane, where parsing is not a significant cost. Tony > On Jan 31, 2022, at 8:46 AM, Haoyu Song = wrote: >=20 > Hi Loa, >=20 > Usually TLV is used as a substructure in a header. For sub fields in a = header, usually we don't have other choices than using TLV. But for = each header, the type of it is better to be indicated by the previous = header to save a parsing state.=20 > So all what I say is: as a principle, when designing a header, try not = to embed its type in the header itself. Instead, before we get to this = header, we should already know its type. >=20 > Moreover, TLV options in a header also increases the parsing cost. = Each fixed size TLV needs two states. Each variable size TLV needs = multiple states depending on the size of the option. So another advice = is: if it is meant to be processed in hardware, then we should try to = limit the use of TLV, and especially variable sized TLV, unless = absolutely necessary. >=20 > Best, > Haoyu >=20 > -----Original Message----- > From: Loa Andersson =20 > Sent: Monday, January 31, 2022 3:27 AM > To: mpls@ietf.org; Haoyu Song > Subject: Question on avoiding TLVs >=20 > Haoyu, >=20 > In the slides you uploaded to the "We should try the best to avoid TLV = style and variable sized header". >=20 > MPLS is full of TLVs (LDP, RSVP/TE, LSP Ping, the OAM) are you = suggesting we'd change this? >=20 > Given your advice above what should we do? >=20 > /Loa > --=20 > Loa Andersson email: loa@pi.nu > Senior MPLS Expert loa.pi.nu@gmail.com > Bronze Dragon Consulting phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Mon Jan 31 09:25:38 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2823A0EDB for ; Mon, 31 Jan 2022 09:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCcTm5TCwGos for ; Mon, 31 Jan 2022 09:25:32 -0800 (PST) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2115.outbound.protection.outlook.com [40.107.236.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 4F5653A0ED8 for ; Mon, 31 Jan 2022 09:25:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UuXyR86NO00Y8tkp4OQadLs0gEyLC6ch6Z6StAiFSrHxpkjfZnxZqPLG4bXQv4mPJqwI7iDrm17lHHJcWoYc0llpVCOGyuo4ijhnwX8+QPjJY9TQRbgJ/Bw+9yRWIZJtdBc9TaRCFeP0lsiv+npfAzsMBQeZmCmIm3314jDma8NjlybYh3g39sweq+vH24Qz22B68auP5T7/YDNDTdjsbtW7QjSo8OfSCjJEuGwZUZYNb9wkpu7dgb3LYWUJ6fYgfGYjUJVhRzpcVhn19rrSgAcY+HZEN1qDkvKUMojE/SHVhnaTQFAS0V5X4iVI+F+r/uzCQY5qyvMv700fsO0/lQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=V7efKrbRot3YAA253uNLxGy7qk6gHd03I8t53YGnb30=; b=OdHnKBnjXKHkrr9bVcpJCXKHY7dv8t6yKh0DFjP2Bqw2RhAJnyhZnMeKwx4dQb9RBVcrbMc0Q5O6+WgRgmFK3OUwnv31J9xp+1oKd1QQDSNzP4hkP/8idl7QiTT+K7xNt5yWnBMSHd7HE0Ufn08V86scgHj8FTBsvqzFXJrm7uVzO35bnjyO4M7fyQD7aDILxnum4FAv0pbFtrf4zP4OT8DgUiVLYQv/FtLSIRvC1aMICy8ur/N8UOEDdDuti9FPFpbXRh6W3Pet8f+tBZH7gsMS5A2H5+Ap/klYxxgQEgXPARCrv7SEnVMmnHpm366i0UOMl/LpgxtLd/ft6zHLgg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=V7efKrbRot3YAA253uNLxGy7qk6gHd03I8t53YGnb30=; b=uG48waOVnmLyKlP1KJGPQUzz73OZf5Kesm6RsraGvSb/AzBmACfISgOJHtLrgKsAfSsnCWf+qRacJ9a0qX7wV5x1htcY4b1SHSbe9NZRyfejNxY+lSZkpSYp3PTR+8gsbCYgJHLquD9Mejy472YX01fP3jJb2LixfNjvUPambmU= Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by DM6PR13MB2586.namprd13.prod.outlook.com (2603:10b6:5:13e::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.7; Mon, 31 Jan 2022 17:25:26 +0000 Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264%6]) with mapi id 15.20.4951.011; Mon, 31 Jan 2022 17:25:26 +0000 From: Haoyu Song To: Tony Li CC: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] Question on avoiding TLVs Thread-Index: AQHYFpWCXPZU/LYjpkyDkzjBq91GR6x9U/nggAAHyYCAAASS8A== Date: Mon, 31 Jan 2022 17:25:26 +0000 Message-ID: References: <5cd6a374-d677-15c5-c721-77614de00c7f@pi.nu> <3BD86173-D24E-4669-91AD-B8C1E349D344@tony.li> In-Reply-To: <3BD86173-D24E-4669-91AD-B8C1E349D344@tony.li> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e4abc2f2-b5c8-482c-9681-08d9e4deabf3 x-ms-traffictypediagnostic: DM6PR13MB2586:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rKGuPJCM1eqxylr57snNyx1Px/vTrMlq2ltBt0LUjqwfx61MqnMAAtlFPX+iAvwbxfGATiD1mSw2s2KDXdwfKYTkU/TeG9ACOY8Wcr9rMYsWtCK4UIT+pEzOKGwflbvwlbr0biNRM0EmaNOE/JMU85eArqddeCx7KNYfb8PhsSjUXkiUJeyTYdPgwuT9S9TIAM2LxzoH0gKBrjtOTnIa7WJCEmdhb9D5fuI2qMWdRB22CnfMlun5RmksSrdfkfv2y0KrCjL1McBVIgzsO3hjyXc39NaEmhfqiQTNnPU65O2xFLb+32HReKiL3bef7alF5m3AWiEUmHM3lC0ycq11KEn4lpzv+zPRQMbF8+eyjC1MpepK+EoyT1G8zZ2k1LxcJk3r5Ix8b7fLz6/hhXm4eCNqvdlPQd9aHf5dpLyHqZLH4tYZ3Rlxgvou2/NaHRROCGjvrViDrYFEakj8OvKH7l3LoAJAP61AD+DmPDd9RMrli5jj3Dv9CVH/iWoRB+Pmf5cgUy13ARCULs+kR46YWO82rVrm0/gZ/Lc/lzMUdBw+kzSScQcXyhxl+1JY4R6J0q3X4MqTXlRdOm+R3AE6nMW+d9iGhq+Ga1uuRvvVFH9XE7hsN2ImAnGEwif2nOmj7aMK5FqMCOPQjedIYBntx4/n+yHe4sTPZqkWPyftgM4hMPekuBh5tuMMuO4Dz1jU+60RzEfHZylP6BiMI+Fr4Zu2oFzpXlbGEmTqiO6N7EPowcrqjR9LEa5+tUoZK3CFztmKe5FMZnatXhi35ZYvXecZo9AelHcK+Ijai659VwxtmpJVbQLVO404KIaaJlOgKuF4xGFyD6NOcd0vPeCOlw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(186003)(508600001)(83380400001)(8676002)(8936002)(66476007)(76116006)(66556008)(64756008)(66446008)(66946007)(2906002)(6506007)(7696005)(33656002)(86362001)(53546011)(26005)(9686003)(71200400001)(122000001)(55016003)(45080400002)(54906003)(44832011)(38100700002)(38070700005)(966005)(52536014)(316002)(6916009)(4326008)(5660300002)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?nk+JspCnbyPNlQNhJ46YHaKfBtd3viLiRAppUjPKY7nd7Q8mfnfAQOuDqgIT?= =?us-ascii?Q?k6MKEnTU5KyseIvey/DB0tBD+KJ10homc39onx+hOMnBg+avncILeGfPNzWL?= =?us-ascii?Q?qDi1Yl7bSGgS3Ck1oO6l08fqSQs60lgrUbaZkjPj5ANesBMQZZWVjWtNFcD2?= =?us-ascii?Q?eCm3Aqt6tgKJgVtzjY3TY4GwMbTSHbZFcFJLzJ6LLHeO1GyTtZusIOPIyMwg?= =?us-ascii?Q?Aj/MNrXzHEx42VgKTEg1WT3zDlGe4+X+bkGYs1/Xo/dCwVEizgofQqnyi89V?= =?us-ascii?Q?L03F8ysEhf8QipPTTnfQYmohvS32t0deR1aR7Q2NOD3lPfwv9ScufdVE5ewG?= =?us-ascii?Q?+ZSRDVIDAd1IDoYV5MmKmJ52PLb3fvMnHzl93EEGHx8t4mju5P4XiSDCdq+z?= =?us-ascii?Q?0QQNd2MdW+IXm8e3M3jASeRO40N9Vdzcgcs3oPBZUEDdUrJxNLL4Y2kMKR2s?= =?us-ascii?Q?JYh56crxHMpIvJ4zHNDD+aqihatlTWv7OOjIRs6AlzvTyi/HrXkj1En5HMXw?= =?us-ascii?Q?WkpFrda5CJyMXp3RPAuvQ4CH4JMN2vRHGCfealTYx2exAiAUM8s9tQ2ssExs?= =?us-ascii?Q?+OsfAEfScZwDEATOCAHmbebTkCk+vAp45aZ0RNSHh7vsSBDGva3CmXrjrH0Q?= =?us-ascii?Q?8jKbe1fCRthKKHM6mlAF7Yi0csboInWMuNC/SywyuzUpcwH5PRNdcCn+hxNK?= =?us-ascii?Q?vsqj919BUjDRQBLy1tQC7SPW+0OSk6Frjtlr4scTHqKgInW22sCoSiT9fxVg?= =?us-ascii?Q?S82NNOOe96MTTEMXgZNv3ziagFNrtpQCy0HOMfEXuR2e0fXCaHRubfbLu/19?= =?us-ascii?Q?wLe3QBb4h3cQRPJ/NANxRmR7rDe2yRoUoqCdwAhVf1Y3q+AEL7vadw3h0o2n?= =?us-ascii?Q?e8u+k4TAttHREg5N0zfnPp1ijSRBFLT59XFiMh58rIAQiEaLkqYcK4obzG8m?= =?us-ascii?Q?ho4F2pdoghGRzILeieivGS6baZYZJtqt+mYXcRsD5T4XGx6ig6TeomdeoZwB?= =?us-ascii?Q?AIx7C700jGjj13QeiiLawuZ9KcyMgmRtZKbSaj8IX4UlDtqoPGC5enPa2wRp?= =?us-ascii?Q?/V1ihCuVy9MwGiUQNbwQZ7ZyM89iByZdIrCb5PliUZ3iV3mQA5XeXaOMailt?= =?us-ascii?Q?nGUrQO6vKM5Hewko67Lw7MynKms9sc24tJXeRZ9tvjlIAdlcG8s9Q3aU2WMq?= =?us-ascii?Q?wLdlRY3tVM8O9XQYAmGO+eY8owv61Q5Pi4GgL1QCtRC2YgLFa3Ibq7eGEzIt?= =?us-ascii?Q?UVO7HX4lD5KuNug3/9t1YdV5kyj8sesxqPQHnuukreNgfrMsGG0xokXi0K5C?= =?us-ascii?Q?LBtGnaPbXqhx+qY8heuGcpuP6eFJU3PGIwJesm13pQCHFgQ4VVepyiA4cOYN?= =?us-ascii?Q?gSH/u/XQmZaY6q2KxTbMHGKqnuYasT6oDsUQxqqDYOObiPICKQCs1HPUn/Ns?= =?us-ascii?Q?2ntOddPUdAIpugxoldyJTczhAKoqLDhihQ5fKH2rrNkTKCni1I7X6ExhYBJi?= =?us-ascii?Q?HNoQepOiazuZyxNG9vzbOfLd/Ce8LEehv2df0sVUjjCavVKWa75/IIKGh5Ni?= =?us-ascii?Q?hsEnidqyQRdp8XwPtzHfChP4JwMAekemhsnhcVBoIvtAuKFZXkIrl/lon54M?= =?us-ascii?Q?pw=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e4abc2f2-b5c8-482c-9681-08d9e4deabf3 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2022 17:25:26.7126 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: SAF7T7yR1EaB2a23HLha3BM8nBm7URR6Nh6kBKloaAv33qpqb804LGMNWYsnWYAWob0Sz3WziyFzKX///qXg9g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR13MB2586 Archived-At: Subject: Re: [mpls] Question on avoiding TLVs 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, 31 Jan 2022 17:25:37 -0000 Hi Tony, Yes you are right. Here we are discussing the headers designed for data pla= ne fast path processing.=20 Most of the TLVs designed before are for control plane to use.=20 But as you see, some current work for supposed fast path processing also su= ggests to use TLV options (e.g., in IPv6 EH) due to the lack of options. We= need to be careful here, because for the parser point of view, each TLV op= tions equals to at least 2 headers. Now for MPLS EH, all I suggest is to avoid the issue because we are still a= t the early stages and have the opportunity to avoid some costly mistakes.= =20 Best, Haoyu -----Original Message----- From: Tony Li On Behalf Of Tony Li Sent: Monday, January 31, 2022 9:03 AM To: Haoyu Song Cc: Loa Andersson ; mpls@ietf.org Subject: Re: [mpls] Question on avoiding TLVs Haoyu, Loa, I think the important point here is that the parsing discussion is focused = on the forwarding plane. TLVs are pervasive in the control plane, where pa= rsing is not a significant cost. Tony > On Jan 31, 2022, at 8:46 AM, Haoyu Song wrote: >=20 > Hi Loa, >=20 > Usually TLV is used as a substructure in a header. For sub fields in a he= ader, usually we don't have other choices than using TLV. But for each hea= der, the type of it is better to be indicated by the previous header to sav= e a parsing state.=20 > So all what I say is: as a principle, when designing a header, try not to= embed its type in the header itself. Instead, before we get to this header= , we should already know its type. >=20 > Moreover, TLV options in a header also increases the parsing cost. Each f= ixed size TLV needs two states. Each variable size TLV needs multiple state= s depending on the size of the option. So another advice is: if it is meant= to be processed in hardware, then we should try to limit the use of TLV, a= nd especially variable sized TLV, unless absolutely necessary. >=20 > Best, > Haoyu >=20 > -----Original Message----- > From: Loa Andersson =20 > Sent: Monday, January 31, 2022 3:27 AM > To: mpls@ietf.org; Haoyu Song > Subject: Question on avoiding TLVs >=20 > Haoyu, >=20 > In the slides you uploaded to the "We should try the best to avoid TLV st= yle and variable sized header". >=20 > MPLS is full of TLVs (LDP, RSVP/TE, LSP Ping, the OAM) are you suggesting= we'd change this? >=20 > Given your advice above what should we do? >=20 > /Loa > --=20 > Loa Andersson email: loa@pi.nu > Senior MPLS Expert loa.pi.nu@gmail.com > Bronze Dragon Consulting phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fmpls&data=3D04%7C01%7Chaoyu.song%40futur= ewei.com%7C232fd182783044649c3e08d9e4db9be9%7C0fee8ff2a3b240189c753a1d5591f= edc%7C1%7C1%7C637792454153079557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD= AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DW6r3NyE= sUEcQzpreWqQR5ad4I%2FYRVA%2FJ3QaVqDZRkuo%3D&reserved=3D0 From nobody Mon Jan 31 09:39:48 2022 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 C75F53A1036; Mon, 31 Jan 2022 09:39:46 -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: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Loa Andersson , The IESG , draft-ietf-mpls-lsp-ping-ospfv3-codepoint@ietf.org, loa@pi.nu, martin.vigoureux@nokia.com, mpls-chairs@ietf.org, mpls@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <164365078679.9642.12219682729780720746@ietfa.amsl.com> Date: Mon, 31 Jan 2022 09:39:46 -0800 Archived-At: Subject: [mpls] Protocol Action: 'OSPFv3 CodePoint for MPLS LSP Ping' to Proposed Standard (draft-ietf-mpls-lsp-ping-ospfv3-codepoint-06.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2022 17:39:47 -0000 The IESG has approved the following document: - 'OSPFv3 CodePoint for MPLS LSP Ping' (draft-ietf-mpls-lsp-ping-ospfv3-codepoint-06.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Alvaro Retana, John Scudder and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-ospfv3-codepoint/ Technical Summary: This document proposes the code point to be used in the Segment ID Sub-TLV and Downstream Detailed Mapping TLV when the IGP is OSPFv3. This document also updates RFC8287 by clarifying that the existing "OSPF" code point is to be used only to indicate OSPFv2, and by defining the behavior when the Segment ID Sub-TLV indicates the use of IPv6. Working Group Summary: The progress of this document was smooth and it is generally understood within the working group that the document is needed. Document Quality: There are existing implementations of the protocol, using the early allocations. Personnel: Loa Andersson is the Document Shepherd. Martin Vigoureux is the Responsible Area Director From nobody Mon Jan 31 12:00:41 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1894A3A15AD for ; Mon, 31 Jan 2022 12:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxdsipT38b_r for ; Mon, 31 Jan 2022 12:00:25 -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 4C8043A164B for ; Mon, 31 Jan 2022 12:00:20 -0800 (PST) Received: from [192.168.1.98] (unknown [112.206.242.125]) (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 E63553660B5; Mon, 31 Jan 2022 21:00:16 +0100 (CET) Message-ID: <5ee2960d-ad6d-2aa4-268d-88861d17e201@pi.nu> Date: Tue, 1 Feb 2022 04:00:13 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Content-Language: en-CA To: Haoyu Song , Tony Li Cc: "mpls@ietf.org" References: <5cd6a374-d677-15c5-c721-77614de00c7f@pi.nu> <3BD86173-D24E-4669-91AD-B8C1E349D344@tony.li> From: Loa Andersson In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] Question on avoiding TLVs 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, 31 Jan 2022 20:00:40 -0000 Haoyu, Tony, I appreciate the difference in TLVs for the forwarding plane and for the control plane. So looking at the forwarding exactly what should not be TLV encoded? Can you give examples? /Loa On 01/02/2022 01:25, Haoyu Song wrote: > Hi Tony, > > Yes you are right. Here we are discussing the headers designed for data plane fast path processing. > Most of the TLVs designed before are for control plane to use. > But as you see, some current work for supposed fast path processing also suggests to use TLV options (e.g., in IPv6 EH) due to the lack of options. We need to be careful here, because for the parser point of view, each TLV options equals to at least 2 headers. > Now for MPLS EH, all I suggest is to avoid the issue because we are still at the early stages and have the opportunity to avoid some costly mistakes. > > Best, > Haoyu > > -----Original Message----- > From: Tony Li On Behalf Of Tony Li > Sent: Monday, January 31, 2022 9:03 AM > To: Haoyu Song > Cc: Loa Andersson ; mpls@ietf.org > Subject: Re: [mpls] Question on avoiding TLVs > > > Haoyu, Loa, > > I think the important point here is that the parsing discussion is focused on the forwarding plane. TLVs are pervasive in the control plane, where parsing is not a significant cost. > > Tony > > >> On Jan 31, 2022, at 8:46 AM, Haoyu Song wrote: >> >> Hi Loa, >> >> Usually TLV is used as a substructure in a header. For sub fields in a header, usually we don't have other choices than using TLV. But for each header, the type of it is better to be indicated by the previous header to save a parsing state. >> So all what I say is: as a principle, when designing a header, try not to embed its type in the header itself. Instead, before we get to this header, we should already know its type. >> >> Moreover, TLV options in a header also increases the parsing cost. Each fixed size TLV needs two states. Each variable size TLV needs multiple states depending on the size of the option. So another advice is: if it is meant to be processed in hardware, then we should try to limit the use of TLV, and especially variable sized TLV, unless absolutely necessary. >> >> Best, >> Haoyu >> >> -----Original Message----- >> From: Loa Andersson >> Sent: Monday, January 31, 2022 3:27 AM >> To: mpls@ietf.org; Haoyu Song >> Subject: Question on avoiding TLVs >> >> Haoyu, >> >> In the slides you uploaded to the "We should try the best to avoid TLV style and variable sized header". >> >> MPLS is full of TLVs (LDP, RSVP/TE, LSP Ping, the OAM) are you suggesting we'd change this? >> >> Given your advice above what should we do? >> >> /Loa >> -- >> Loa Andersson email: loa@pi.nu >> Senior MPLS Expert loa.pi.nu@gmail.com >> Bronze Dragon Consulting phone: +46 739 81 21 64 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=04%7C01%7Chaoyu.song%40futurewei.com%7C232fd182783044649c3e08d9e4db9be9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637792454153079557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=W6r3NyEsUEcQzpreWqQR5ad4I%2FYRVA%2FJ3QaVqDZRkuo%3D&reserved=0 > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Mon Jan 31 12:21:36 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C25D3A1638; Mon, 31 Jan 2022 12:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXQoN27DZXhA; Mon, 31 Jan 2022 12:21:29 -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 C9D053A1634; Mon, 31 Jan 2022 12:21:28 -0800 (PST) Received: from [192.168.1.98] (unknown [112.206.242.125]) (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 DF4CC3660B5; Mon, 31 Jan 2022 21:21:24 +0100 (CET) Message-ID: Date: Tue, 1 Feb 2022 04:21:21 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Content-Language: en-CA To: "mpls@ietf.org" Cc: "mpls-chairs@ietf.org" , "pals-chairs@ietf.org" , DetNet Chairs From: Loa Andersson Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] Agenda for the MPLS Open DT 2022-02-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2022 20:21:33 -0000 Open DT, Please find the agenda for the meeting on Thursday at https://trac.ietf.org/trac/mpls/wiki/2022-02-03-agenda I opted to only put the discussions on the requirement specification on the agenda. In the event there are other things we need to discuss please send me a note. /Loa -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Mon Jan 31 12:22:16 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566BB3A0CAA for ; Mon, 31 Jan 2022 12:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYk7seU2oyzw for ; Mon, 31 Jan 2022 12:22:10 -0800 (PST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2129.outbound.protection.outlook.com [40.107.223.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DAD43A1638 for ; Mon, 31 Jan 2022 12:22:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J4C47TUHgNjqrGzQfLqr0bb5u76VrVQWMoap92otWEGTxjzJawJa8sHuvA4RYILvqVBPiWT4nP4z904nLMeJ2i+BuK2pJ4I+btmOUSwTFKSD33ZjZdiXzzqVSLyZp6B3pBf6Qk4AQNVU1GWzM25tAkvjjQ9h91BcdDW7KPbWgEz5RX/7HXEZY6yrprtsNUllKJh/BCd3OR5i/yS3IeHdyVB4ydipzhD7QAaYGwHlxHvlsKULsqLlVEeI8GWWuF7lwVeuqXlY5YNgjw3MuV86hsMw9m5+89xetWZNDf3BdCQAhj3qlriHFE9ytcTyYD5iYYHT0RSqto5ZYA5fxXbKXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8k59VDBjZOZFLRtVug4/UJ4Rr98eXMFy0T5VC1HQ4Jk=; b=Z38oon9268ywU59iOOkjqnqa5zqL82DgjrOSvfTjXAE4c4GVZqQ/0t5e0/bcbRGf9MojDq2Kz5eSRqo52kongn7Pt9S13RvU43QH4WV/o4QrLkQINVkHw2Wa9kaI5vVtBkL1mmVcVTrzRRmaPQgR06AShMPl7usKyHRkOEKOFB0e568B2Bul9htWTnAwDS8Luoehxp731YxTDoTPlu74HMUxutBNXhRVSU5zBZgDIl01eeKoNbfH/yWy2kh4mlwDF7Edk2FPsN8/m4hfBDoA2kKvJBdmTDfL7fV+XbRExkfngIyskq+ZbfAvULWC9QocQM6NYhg9KHAxx0IQwrtRdA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8k59VDBjZOZFLRtVug4/UJ4Rr98eXMFy0T5VC1HQ4Jk=; b=Hil5w1vdyu/2m/VIapkNzGxD1W60rbFn1TDbXX++s/gIx0+fJmZlCHMreJs+YXlXTNN+I98B+mqE2VmWBKXjAjjueBghGrU1zdq5i9EbGXo0XeL96bHjiwqMOFuaVj3wla0/J4aKByMpeAmz4ND+RaHwAn5x0x4kWRoaHU17WV0= Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by MWHPR13MB1024.namprd13.prod.outlook.com (2603:10b6:300:15::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.11; Mon, 31 Jan 2022 20:22:05 +0000 Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264%6]) with mapi id 15.20.4951.011; Mon, 31 Jan 2022 20:22:05 +0000 From: Haoyu Song To: Loa Andersson , Tony Li CC: "mpls@ietf.org" Thread-Topic: [mpls] Question on avoiding TLVs Thread-Index: AQHYFpWCXPZU/LYjpkyDkzjBq91GR6x9U/nggAAHyYCAAASS8IAALNGAgAAB5AA= Date: Mon, 31 Jan 2022 20:22:05 +0000 Message-ID: References: <5cd6a374-d677-15c5-c721-77614de00c7f@pi.nu> <3BD86173-D24E-4669-91AD-B8C1E349D344@tony.li> <5ee2960d-ad6d-2aa4-268d-88861d17e201@pi.nu> In-Reply-To: <5ee2960d-ad6d-2aa4-268d-88861d17e201@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 87773c26-9129-40b4-2993-08d9e4f75927 x-ms-traffictypediagnostic: MWHPR13MB1024:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DsDO8iH6+/fTp/qkx18fk5P/O6iEwzqocJFHqZlrMiOLe6AdqHS1K8mXQWCddspDjTEa7RST92A2m4522bNwKZvCQCzSHbLnj0HgSW/WutVAgPe80zDMLfTwNFAo67r7rcrMaIP26AZrfMGLgMcGDwNfnOOv3DtSKe619nASyJdayUNRRGn5IiQm9KrcZAQv1bFhX3O25NL34BK/gUhvEpP/Afc0ckSMrnofx13GyrKd4OGUmxnhUz78eRHlPHbqKGDWlkikl02R5dMkJsk5QaKTmUlTxjR/PJWJuhfhtAz/TBcGGGeWaCwFkQLqXjIflll40Jdm+e2bhau01EFlidaepYmbPHyLKSEah3BEeNnTo40iL4+Bp+l1OeKndbFpPfFZhLCQBDocAGxSTrfb4gSGnRudRorVx0iOKffUt3T3CZNFHznpPCVdQ+8qsMIkUDAWuE1ELyfybKCxK6iAplXcwg5uNj8V16DLBJ/0agA9ZIQbaLcGDGNzOM6L1hgShqW5aohfNNZn50hYRPe1bcYA/MXc3ciKSwZVjIuo+8WuMTE/bkcDptFlf97dsk64iioukATdr6Q/8icckKqkYw6/xeFM8IDurYewejZ4cxfXYmZ7rOUsbZoAtKBv34qQC+eczxVCC9IGSegJHPWRgquTzzj6BMK3J2pcOa0N9ACIc4JY0VqbN8KTtxToE739mzVTdP2WLb5MmMjJGNZapHIejaaaqrLlBc+XNkP7rusCx3v46Sda9y0RXNJCqj9a0udOdCRTiAaA1OfDFuNSxI8fCPoLMwzIANu9FVcXarOyUi1aMEG95gYvH3BCt0BB5MVqZY/uiGubFvS33WmFLg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(966005)(508600001)(71200400001)(64756008)(66476007)(9686003)(316002)(86362001)(8936002)(6506007)(4326008)(8676002)(7696005)(53546011)(38070700005)(66946007)(66446008)(110136005)(66556008)(76116006)(52536014)(45080400002)(5660300002)(186003)(38100700002)(122000001)(26005)(2906002)(83380400001)(55016003)(33656002)(44832011)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?lB59hUR9Jolx5MsqG24hoUjIZBL/YXgDuU/PWqttQ248gr928r59pVgDhXq4?= =?us-ascii?Q?AbrJPWMidwcViEWG5/qR7SllnhgPfy71x28Wnc9egczPnXV7EE0xG3qHUR4I?= =?us-ascii?Q?lLaEebZeT0tptwrh8VCHEuckku/xUa1viAZEJOkdNSWx7M3Y5OYgf7VbzaUD?= =?us-ascii?Q?/ZRPqYP6ByvsQg9HApMehfwYtFqr6btPNSBpZdzh4ZEoT4tNQQf8Gj38OqsZ?= =?us-ascii?Q?BdW/MPNUamLDZrf13C4w9N8TToBAdeFAdltQFBV1aT3K12Dt0chaTlOCiWk8?= =?us-ascii?Q?exYLrZ+QXKkwuH+Ht1gmMjGaSkpPyG34+rOmi2VWUBTJRft+diuHkSJ4Osas?= =?us-ascii?Q?/9blzaTCYU6zSUvyJP3bpjm3X5vM5Ya+lmrNeEjY9BZNfzrIiIMQKC1vMUP5?= =?us-ascii?Q?lWiuSncAh1MGmPe8FWCeJjzWghgaMzHr0I+otvSgnnzQeQxNlRSB4tYmuHpd?= =?us-ascii?Q?Ns46zHx8a/OQJCc0vVju/iqD30X5H/Hp9E90yhiiBgyx0ocPCOOPelTIcbBr?= =?us-ascii?Q?0znaNYHBa9h/q1Xb/Ee7uuoQesTBMLiXye8B6qRbnS21Lhpr0A2vp4LT8Ll1?= =?us-ascii?Q?XiqOw+I1P5OFcKafxN0ktLKbo+6hNVdFe+KuoWLhmHBciXhT2WeVtPDnLxKR?= =?us-ascii?Q?TE32Bj7wrpXeoEoicKpyVIFEaFoE4wI6nyHsCwsy9tHYqdmjScnzuDnNwTIK?= =?us-ascii?Q?BWDbtZHiUSs5EYrNAVIAihbm4xQdXyywOIXd+wyucOGKUSEdZLlhRa8/xHPl?= =?us-ascii?Q?ktiErVzv05N5E6vEQ6g90N+Ko0Ig8lvDEr2l846kONcYWJzGWQDSDjodwDf5?= =?us-ascii?Q?JhYibA2UcyRWpAm8n1tCONyJEF0D9NAt7eM8NL32zCbkcQQ0wiH14MJUmCVo?= =?us-ascii?Q?RNhTDUkyFgCyX4Rb92Ijjxq63nqLMXbl9V2qEePEi6JYY3tuTq+w4CXXqNFY?= =?us-ascii?Q?FHvCSGEyOd33AqkjNA1MTARGN4JUuHujY1TL1vWvp71zDCQL0S9rhjpke/Sr?= =?us-ascii?Q?WM/Zrhib1batZThSNPQ0xMxBji5hn0PC1AkxGl4EMAGsmpG/sMADPAx3kZBF?= =?us-ascii?Q?entxBrw3BhW+sK1AYaR6PqTbPpA7tLKlp+DxueK+12Oanf1Qd6q1r0Ny7Ukm?= =?us-ascii?Q?scYZS0QD23kcisqQtq+w7X+Stob7quWgiMm3HXPWy2VO5oPMwtZk5Y32jMvv?= =?us-ascii?Q?vNhNFUSbAdkf7BFuiJ6CQPj25VBoMiaF+NjNcliNNM8/Oq7suiIpRgzkE6e2?= =?us-ascii?Q?xH4F1RE0GLeOOoh0J0uGzRS22tb49CPEZSvmecaGVYEY0NFIir47i2vSYPfl?= =?us-ascii?Q?OppQwd6X5dcMnUK63qxbygFAGnJ5jS4IM49AVWpyHGv0AQxShu6N1jmfWYLV?= =?us-ascii?Q?aOUEJ1doAOi7ykicluCxb16QdHhmCV7js5T5hx4qZIL87oqU62YyDkG3vlkL?= =?us-ascii?Q?C8Bz8c3j1Qqp4yilYR8/EY+hrMooWCvYlEfVi9RHV+eyyaGf84hintzC0+GZ?= =?us-ascii?Q?EL3If3Fx90RsSkjnqWEVKRGar2/y6mwNwmcMz1dcwB76gkOjYxzCl/faSDf6?= =?us-ascii?Q?uTZaX3zbkzQApfW9QvUHmX9L+SmmlDiJOH6NeKm7VmmVyZFOn+WrIPa2v+Oo?= =?us-ascii?Q?2A=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 87773c26-9129-40b4-2993-08d9e4f75927 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2022 20:22:05.1711 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: N4GxJ3cbSDZmIkTsiruNQ0/i/wtaY/rhWXiUUvIzcRG/zxwlELi7Rr1YZpghrsFbHKGNfoTHMJM/A9P1im2QqA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR13MB1024 Archived-At: Subject: Re: [mpls] Question on avoiding TLVs 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, 31 Jan 2022 20:22:15 -0000 Hi Loa, When designing new headers, it's good enough to simply organize them in a c= hain, which means the current header would include a field (in some cases, such a field is no= t needed. For example, in an MPLS label stack, as long as the BoS is not se= t, you know the next header is still a label) to tell what's the next heade= r, so the parser directly know the format of the next header.=20 IPv6 EH follows such a structure, our proposed MPLS EH also follows such a = structure.=20 One current issue is that people tend to add variable sized TLV sub structu= res into EH to support fast path functions. This needs to be done very care= fully, otherwise, it will never fly (for example IPv4 options). Haoyu =20 -----Original Message----- From: Loa Andersson =20 Sent: Monday, January 31, 2022 12:00 PM To: Haoyu Song ; Tony Li Cc: mpls@ietf.org Subject: Re: [mpls] Question on avoiding TLVs Haoyu, Tony, I appreciate the difference in TLVs for the forwarding plane and for the co= ntrol plane. So looking at the forwarding exactly what should not be TLV encoded? Can you give examples? /Loa On 01/02/2022 01:25, Haoyu Song wrote: > Hi Tony, >=20 > Yes you are right. Here we are discussing the headers designed for data p= lane fast path processing. > Most of the TLVs designed before are for control plane to use. > But as you see, some current work for supposed fast path processing also = suggests to use TLV options (e.g., in IPv6 EH) due to the lack of options. = We need to be careful here, because for the parser point of view, each TLV = options equals to at least 2 headers. > Now for MPLS EH, all I suggest is to avoid the issue because we are still= at the early stages and have the opportunity to avoid some costly mistakes= . >=20 > Best, > Haoyu >=20 > -----Original Message----- > From: Tony Li On Behalf Of Tony Li > Sent: Monday, January 31, 2022 9:03 AM > To: Haoyu Song > Cc: Loa Andersson ; mpls@ietf.org > Subject: Re: [mpls] Question on avoiding TLVs >=20 >=20 > Haoyu, Loa, >=20 > I think the important point here is that the parsing discussion is focuse= d on the forwarding plane. TLVs are pervasive in the control plane, where = parsing is not a significant cost. >=20 > Tony >=20 >=20 >> On Jan 31, 2022, at 8:46 AM, Haoyu Song wrote= : >> >> Hi Loa, >> >> Usually TLV is used as a substructure in a header. For sub fields in a h= eader, usually we don't have other choices than using TLV. But for each he= ader, the type of it is better to be indicated by the previous header to sa= ve a parsing state. >> So all what I say is: as a principle, when designing a header, try not t= o embed its type in the header itself. Instead, before we get to this heade= r, we should already know its type. >> >> Moreover, TLV options in a header also increases the parsing cost. Each = fixed size TLV needs two states. Each variable size TLV needs multiple stat= es depending on the size of the option. So another advice is: if it is mean= t to be processed in hardware, then we should try to limit the use of TLV, = and especially variable sized TLV, unless absolutely necessary. >> >> Best, >> Haoyu >> >> -----Original Message----- >> From: Loa Andersson >> Sent: Monday, January 31, 2022 3:27 AM >> To: mpls@ietf.org; Haoyu Song >> Subject: Question on avoiding TLVs >> >> Haoyu, >> >> In the slides you uploaded to the "We should try the best to avoid TLV s= tyle and variable sized header". >> >> MPLS is full of TLVs (LDP, RSVP/TE, LSP Ping, the OAM) are you suggestin= g we'd change this? >> >> Given your advice above what should we do? >> >> /Loa >> --=20 >> Loa Andersson email: loa@pi.nu >> Senior MPLS Expert loa.pi.nu@gmail.com >> Bronze Dragon Consulting phone: +46 739 81 21 64 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww >> .ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=3D04%7C01%7Chaoyu.song%4 >> 0futurewei.com%7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b240189 >> c753a1d5591fedc%7C1%7C1%7C637792560238419199%7CUnknown%7CTWFpbGZsb3d8 >> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C >> 3000&sdata=3Do%2F9wFBtO2sn8Y9y7KSMoRDqDBlA9F2Jz7VL6n9rwqPE%3D&r >> eserved=3D0 >=20 --=20 Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Mon Jan 31 12:38:56 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E893A16FE for ; Mon, 31 Jan 2022 12:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuVp3VkylqwY for ; Mon, 31 Jan 2022 12:38:48 -0800 (PST) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450: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 9026C3A16FB for ; Mon, 31 Jan 2022 12:38:48 -0800 (PST) Received: by mail-ej1-x62c.google.com with SMTP id ah7so46620550ejc.4 for ; Mon, 31 Jan 2022 12:38:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UN72sEsOe70QedliI3tYGn119W89RSZ8Id7OR4GwSTU=; b=gwAefcHBns9K9+HnsOXxHw0fr/VMaGFVpjD3Mpt/8eOAX996eOOpA8pYoEe1lcItmk u+3sGeMMkMtI2aUgi9YLogcJNsnln47vlG3545SgSeJZjnhWoAQDthOW9h8U2XHRvIro eT+kybuQioKACGcxrEZBE9qTWaT2UhHIPanCviPoMCmbosZR0948Fs8KG8sM02Q2w3jd 5JxM5mCvCmpTAjxTOcI2mg3SxMGQCBMD6KtNl7lJ8xTyC8Ouq3WQJ816/mKeOQSGMCZV dCxyAwysTeXpO+F93adw7qTuNqiFCFNMhyJmaI+zJ1H8j+AQ+UCQaefds61kXDQzM3Ry OpCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UN72sEsOe70QedliI3tYGn119W89RSZ8Id7OR4GwSTU=; b=XKHZnU82ejI8mj7HhnavGqTn/SekAH55TxSQELVjoQpcTcdE5PG4XF2ihzG9vKo5Vx c55j9ze1RRuhfCxjm5Ct9Qogur4pjYgOOR57820yopvGz5QA95uJWEUqc0RiUjmmHIEq IdzfWzWBXCbvXL9Nvv7H9lJrUEOFCkYVzgPgVYiEzQ1n+eP5wuh9CnUn24p0623ePUdM jv5+MtsoxHe5OHATJncEewnVPIjCOPhateYeW4HVYsVZf+HqA/Hr6/ZGPGz6dPk6qs6j UDXQPO1hUizDWSlQMxTazMoPCPBEiVDNt4mczKfkxdmPsyFgupwNetsxat6jcIr9uTbG Zb4w== X-Gm-Message-State: AOAM533rbL+hsseH2YUXmYAEuv50ZksYWmUs3U5MJGutgH8kP0hlLRtn MSTZRskJJUa3Lu2YUaBwt5ARVthdPxFsWM+TybJukUt3 X-Google-Smtp-Source: ABdhPJxP0dD6YpKyPFXlmEm/iaTRslIHhEguJwWubACMZ6FAjz7iv1YPpS9/j93iDyQela7EbxFsG/ctzGxCxkrGaGM= X-Received: by 2002:a17:907:234f:: with SMTP id we15mr13431507ejb.235.1643661525832; Mon, 31 Jan 2022 12:38:45 -0800 (PST) MIME-Version: 1.0 References: <5cd6a374-d677-15c5-c721-77614de00c7f@pi.nu> <3BD86173-D24E-4669-91AD-B8C1E349D344@tony.li> <5ee2960d-ad6d-2aa4-268d-88861d17e201@pi.nu> In-Reply-To: From: Greg Mirsky Date: Mon, 31 Jan 2022 12:38:34 -0800 Message-ID: To: Haoyu Song Cc: Loa Andersson , Tony Li , "mpls@ietf.org" Content-Type: multipart/alternative; boundary="00000000000060d55605d6e6c5a9" Archived-At: Subject: Re: [mpls] Question on avoiding TLVs 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, 31 Jan 2022 20:38:54 -0000 --00000000000060d55605d6e6c5a9 Content-Type: text/plain; charset="UTF-8" Hi Haoyu, could you please clarify for me if your recommendation for avoiding using the TLV construct is for all scenarios considered, i.e., ISD and PSD, or for one of them? I agree that the random order of appearance of variable-size data has a performance impact. On the other hand, if the order of TLVs is deterministic, they are flexible and the performance cost of parsing is much lower. So, perhaps, the recommendation could be refined suggesting the use of ordered TLVs. What are your thoughts? Regards, Greg On Mon, Jan 31, 2022 at 12:22 PM Haoyu Song wrote: > Hi Loa, > > When designing new headers, it's good enough to simply organize them in a > chain, which means > the current header would include a field (in some cases, such a field is > not needed. For example, in an MPLS label stack, as long as the BoS is not > set, you know the next header is still a label) to tell what's the next > header, so the parser directly know the format of the next header. > IPv6 EH follows such a structure, our proposed MPLS EH also follows such a > structure. > One current issue is that people tend to add variable sized TLV sub > structures into EH to support fast path functions. This needs to be done > very carefully, otherwise, it will never fly (for example IPv4 options). > > Haoyu > > > > -----Original Message----- > From: Loa Andersson > Sent: Monday, January 31, 2022 12:00 PM > To: Haoyu Song ; Tony Li > Cc: mpls@ietf.org > Subject: Re: [mpls] Question on avoiding TLVs > > Haoyu, Tony, > > I appreciate the difference in TLVs for the forwarding plane and for the > control plane. > > So looking at the forwarding exactly what should not be TLV encoded? > > Can you give examples? > > /Loa > > On 01/02/2022 01:25, Haoyu Song wrote: > > Hi Tony, > > > > Yes you are right. Here we are discussing the headers designed for data > plane fast path processing. > > Most of the TLVs designed before are for control plane to use. > > But as you see, some current work for supposed fast path processing also > suggests to use TLV options (e.g., in IPv6 EH) due to the lack of options. > We need to be careful here, because for the parser point of view, each TLV > options equals to at least 2 headers. > > Now for MPLS EH, all I suggest is to avoid the issue because we are > still at the early stages and have the opportunity to avoid some costly > mistakes. > > > > Best, > > Haoyu > > > > -----Original Message----- > > From: Tony Li On Behalf Of Tony Li > > Sent: Monday, January 31, 2022 9:03 AM > > To: Haoyu Song > > Cc: Loa Andersson ; mpls@ietf.org > > Subject: Re: [mpls] Question on avoiding TLVs > > > > > > Haoyu, Loa, > > > > I think the important point here is that the parsing discussion is > focused on the forwarding plane. TLVs are pervasive in the control plane, > where parsing is not a significant cost. > > > > Tony > > > > > >> On Jan 31, 2022, at 8:46 AM, Haoyu Song > wrote: > >> > >> Hi Loa, > >> > >> Usually TLV is used as a substructure in a header. For sub fields in a > header, usually we don't have other choices than using TLV. But for each > header, the type of it is better to be indicated by the previous header to > save a parsing state. > >> So all what I say is: as a principle, when designing a header, try not > to embed its type in the header itself. Instead, before we get to this > header, we should already know its type. > >> > >> Moreover, TLV options in a header also increases the parsing cost. Each > fixed size TLV needs two states. Each variable size TLV needs multiple > states depending on the size of the option. So another advice is: if it is > meant to be processed in hardware, then we should try to limit the use of > TLV, and especially variable sized TLV, unless absolutely necessary. > >> > >> Best, > >> Haoyu > >> > >> -----Original Message----- > >> From: Loa Andersson > >> Sent: Monday, January 31, 2022 3:27 AM > >> To: mpls@ietf.org; Haoyu Song > >> Subject: Question on avoiding TLVs > >> > >> Haoyu, > >> > >> In the slides you uploaded to the "We should try the best to avoid TLV > style and variable sized header". > >> > >> MPLS is full of TLVs (LDP, RSVP/TE, LSP Ping, the OAM) are you > suggesting we'd change this? > >> > >> Given your advice above what should we do? > >> > >> /Loa > >> -- > >> Loa Andersson email: loa@pi.nu > >> Senior MPLS Expert loa.pi.nu@gmail.com > >> Bronze Dragon Consulting phone: +46 739 81 21 64 > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > >> .ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=04%7C01%7Chaoyu.song%4 > >> 0futurewei.com%7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b240189 > >> c753a1d5591fedc%7C1%7C1%7C637792560238419199%7CUnknown%7CTWFpbGZsb3d8 > >> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C > >> 3000&sdata=o%2F9wFBtO2sn8Y9y7KSMoRDqDBlA9F2Jz7VL6n9rwqPE%3D&r > >> eserved=0 > > > > -- > Loa Andersson email: loa@pi.nu > Senior MPLS Expert loa.pi.nu@gmail.com > Bronze Dragon Consulting phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --00000000000060d55605d6e6c5a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Haoyu,
could you please clarify for me if your reco= mmendation for avoiding using the TLV construct is for all scenarios consid= ered, i.e., ISD and PSD, or for one of them? I agree that the random order = of appearance of variable-size data has a performance impact. On the other = hand, if the order of TLVs is deterministic, they are flexible and the perf= ormance cost of parsing is much lower. So, perhaps, the recommendation coul= d be refined suggesting the use of ordered TLVs.
What are your th= oughts?

Regards,
Greg

Hi Loa,

When designing new headers, it's good enough to simply organize them in= a chain, which means
the current header would include a field (in some cases, such a field is no= t needed. For example, in an MPLS label stack, as long as the BoS is not se= t, you know the next header is still a label) to tell what's the next h= eader, so the parser directly know the format of the next header.
IPv6 EH follows such a structure, our proposed MPLS EH also follows such a = structure.
One current issue is that people tend to add variable sized TLV sub structu= res into EH to support fast path functions. This needs to be done very care= fully, otherwise, it will never fly=C2=A0 (for example IPv4 options).

Haoyu



-----Original Message-----
From: Loa Andersson <loa@= pi.nu>
Sent: Monday, January 31, 2022 12:00 PM
To: Haoyu Song <haoyu.song@futurewei.com>; Tony Li <tony.li@tony.li>
Cc: mpls@ietf.org Subject: Re: [mpls] Question on avoiding TLVs

Haoyu, Tony,

I appreciate the difference in TLVs for the forwarding plane and for the co= ntrol plane.

So looking at the forwarding exactly what should not be TLV encoded?

Can you give examples?

/Loa

On 01/02/2022 01:25, Haoyu Song wrote:
> Hi Tony,
>
> Yes you are right. Here we are discussing the headers designed for dat= a plane fast path processing.
> Most of the TLVs designed before are for control plane to use.
> But as you see, some current work for supposed fast path processing al= so suggests to use TLV options (e.g., in IPv6 EH) due to the lack of option= s. We need to be careful here, because for the parser point of view, each T= LV options equals to at least 2 headers.
> Now for MPLS EH, all I suggest is to avoid the issue because we are st= ill at the early stages and have the opportunity to avoid some costly mista= kes.
>
> Best,
> Haoyu
>
> -----Original Message-----
> From: Tony Li <tony1athome@gmail.com> On Behalf Of Tony Li
> Sent: Monday, January 31, 2022 9:03 AM
> To: Haoyu Song <haoyu.song@futurewei.com>
> Cc: Loa Andersson <l= oa@pi.nu>; mpls@i= etf.org
> Subject: Re: [mpls] Question on avoiding TLVs
>
>
> Haoyu, Loa,
>
> I think the important point here is that the parsing discussion is foc= used on the forwarding plane.=C2=A0 TLVs are pervasive in the control plane= , where parsing is not a significant cost.
>
> Tony
>
>
>> On Jan 31, 2022, at 8:46 AM, Haoyu Song <haoyu.song@futurewei.com> wr= ote:
>>
>> Hi Loa,
>>
>> Usually TLV is used as a substructure in a header. For sub fields = in a header, usually we don't have other choices than using TLV.=C2=A0 = But for each header, the type of it is better to be indicated by the previo= us header to save a parsing state.
>> So all what I say is: as a principle, when designing a header, try= not to embed its type in the header itself. Instead, before we get to this= header, we should already know its type.
>>
>> Moreover, TLV options in a header also increases the parsing cost.= Each fixed size TLV needs two states. Each variable size TLV needs multipl= e states depending on the size of the option. So another advice is: if it i= s meant to be processed in hardware, then we should try to limit the use of= TLV, and especially variable sized TLV, unless absolutely necessary.
>>
>> Best,
>> Haoyu
>>
>> -----Original Message-----
>> From: Loa Andersson <loa@pi.nu>
>> Sent: Monday, January 31, 2022 3:27 AM
>> To: mpls@ietf.o= rg; Haoyu Song <haoyu.song@futurewei.com>
>> Subject: Question on avoiding TLVs
>>
>> Haoyu,
>>
>> In the slides you uploaded to the "We should try the best to = avoid TLV style and variable sized header".
>>
>> MPLS is full of TLVs (LDP, RSVP/TE, LSP Ping, the OAM) are you sug= gesting we'd change this?
>>
>> Given your advice above what should we do?
>>
>> /Loa
>> --
>> 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=C2=A0 =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.pi.nu@gmail.com
>> 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://nam11.safeli= nks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww
>> .= ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=3D04%7C01%7Chaoyu.son= g%4
>> 0futurewei.com%7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b240= 189
>> c753a1d5591fedc%7C1%7C1%7C637792560238419199%7CUnknown%7CTWFpbGZsb= 3d8
>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D= %7C
>> 3000&amp;sdata=3Do%2F9wFBtO2sn8Y9y7KSMoRDqDBlA9F2Jz7VL6n9rwqPE= %3D&amp;r
>> eserved=3D0
>

--
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=C2=A0 =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.pi.nu@gmail.com
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
--00000000000060d55605d6e6c5a9-- From nobody Mon Jan 31 12:45:32 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3E83A172F for ; Mon, 31 Jan 2022 12:45:30 -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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1BgM_mptm4I for ; Mon, 31 Jan 2022 12:45:25 -0800 (PST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2102.outbound.protection.outlook.com [40.107.223.102]) (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 4C8D93A172A for ; Mon, 31 Jan 2022 12:45:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J/zwsEYcEWm7vaX6U3wSDc5TAQ3kD1zauLZbeMpnuJ+rC0yz/wJD3tqA1MzjV/iv7efH//nMklf54iYDTFKHqqDKsDfDQFZSartaHiVzpFo4A+oGzlp11kbhbQ/nNDqEkYPqO6xXgbwJJ5bborWwny2iTFbAWOsTjKw68INSxDpzSRYKkUwLUXkPBv/GquGrYBsYljpmShlBgrdnhkNb/xwHU6SFVP9JGf+3l60xgrq2yfBccbVQGrW+V+KU85AVQYWNLu/oyVhGgl4bZc9KjAFzUTrecRZgxnddW45Ob9YXyifTUojIcIZR8TJY4iTfvkWROQFuBHUMU2bnmttgoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=31WbWNmbmY5qyni2zA6X3EkQmm3ud0YrM7h301/MSEI=; b=akq0jQ2qyhMH7W+KSNR/SLys3xaCt8ROicfBvH6MLzYv878bwZ9i1EvyJYhLNpdlknGxaU9UQYrvStbnefY4v/6zAcLd584ODqdWP8sOf/4zkJAd5Hnif234p0m8rHEZ2uix6roOkm+Cg8Wxt+EcosqTobhGOOO+KApXHDOsXXMBG7utjVZ3ytje2vfRAu+pxdERxRhkT7BcO9XFnTEyticn9r1GohzDEno0t9PehOnxUezrkEbWhTX5ad9m2KVgRtVIu/csvx7kx8rr9AVQviAKNWjLlNOt0PsVnyCRWGHIR1CMeRBNEY3qtphuWQFTxqXUdfwfZ3U6VHEZygv6Qg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=31WbWNmbmY5qyni2zA6X3EkQmm3ud0YrM7h301/MSEI=; b=p2vIrb1aMdiux/4i1DNdmfWwYY9/OGe8BGoTA1Z5Dw4Mewgd+9aJnV2xygB/x9agN3uNBnThSk1Mk5OwDKoUKOvwJyrccuWeKjoJxH0LLak/3y4ZzsEB1tsL50Q+s1Ke/zSTFdoJldQR/V/yEi05sPXyHt48Ix4RJ+/5QRTwVS0= Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by MN2PR13MB3695.namprd13.prod.outlook.com (2603:10b6:208:1e4::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.6; Mon, 31 Jan 2022 20:45:22 +0000 Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264%6]) with mapi id 15.20.4951.011; Mon, 31 Jan 2022 20:45:22 +0000 From: Haoyu Song To: Greg Mirsky CC: Loa Andersson , Tony Li , "mpls@ietf.org" Thread-Topic: [mpls] Question on avoiding TLVs Thread-Index: AQHYFpWCXPZU/LYjpkyDkzjBq91GR6x9U/nggAAHyYCAAASS8IAALNGAgAAB5ACAAAjTAIAAAKZw Date: Mon, 31 Jan 2022 20:45:22 +0000 Message-ID: References: <5cd6a374-d677-15c5-c721-77614de00c7f@pi.nu> <3BD86173-D24E-4669-91AD-B8C1E349D344@tony.li> <5ee2960d-ad6d-2aa4-268d-88861d17e201@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e1e1a8b7-9e7e-487a-dfc0-08d9e4fa9a20 x-ms-traffictypediagnostic: MN2PR13MB3695:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /oCx4GYjAUQQOJ8GS6BqFxm3hAEkxzNnBI0eThcUugeFdcDcxQ3y/XsavnF6fl9t8xGBNUN/E5vccYiI5Jip5aZIX0W2Ey1frjUKev4+G5o1m1yG+ZPx5hcOQHwOvyLrn+dUycFKiwEge9MONRMT+7OlNEU981Hwc5sGP74Lg+yW6iQCEGuhFG5OefdXmZtEwU3rqkYCA09rOCG0s8DbvtMc0ViWq316vVCr9FsyoSI0lKvEwjCxL/NQncQg2WAKL417iRIq3a8g90uAj/pDESSEtKF2o38PIMN5G5OnPHxzUk/Z/a/sXG84hXKQn9enOgE6vZgty9RFYNZJid3NJjwpu2/HbZCXYkf1lsW3VvlwBHVi1Pz3cWLP9+yEddx3va6K5bL7/uJlB7yWdtZzCbfWYc+QskST/n5goqfelfwTvK53N2PVwE9yeWY7D0Y4/Fjd12s5oR7sHK/uvr5NjsVKSXwe942pYnpMBVUWyAsFkY3f1gEixugMmRTC1sg8EfQgi4IsdkfPU8xclOXslY27ImBxoAv3R3vBdaV6s/sTGLENtKO6tKYN3q3nuLN/mineKZHKLsAuQjtC2mZ0YwH+TO2rMzYnnaEQ/eIBK+7vd1cQ8sva0SZ+Y9WyLFjBQOCUWhWPx2hdRJuTBrVB7Tg6kkLW8LLHrPfK3yVem7SCRGfjeLaNhWsM4aKFzWIsEofOYyE325H4ZJxZ4E3SNfVhvi0Ip7k51ZDOcqPg8ZVoPBc2NjWBSo++xHvqaSOFcwm1pgI7UpVWsUk0h9ugkT9Wv4J/rKvA56WT5avvLXSsd1znhrhicqeKGQPseFFox1OJe74YYBwRyd9ZB9WO1g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(38100700002)(66446008)(66556008)(966005)(66946007)(52536014)(9326002)(33656002)(6916009)(54906003)(508600001)(66476007)(316002)(166002)(45080400002)(6506007)(2906002)(38070700005)(83380400001)(55016003)(53546011)(71200400001)(86362001)(122000001)(7696005)(44832011)(9686003)(4326008)(76116006)(64756008)(8676002)(8936002)(26005)(5660300002)(186003)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?DUOSb3VUzBVgiSqNEYMaROFTj+tN5p5Qxq6rbDWnABSBWSV2Ergvu7NIK0s4?= =?us-ascii?Q?QWnJVbj7LSspCN8YXkWsyaFRYOGDXWurgT6rVFhec/WJibJ+GGnUQMTtTeU/?= =?us-ascii?Q?tdoetgFPoHgMmMWfyOUlRzGbhCPe09HBCVjnUcFI/myfYBUfaDdbGk2iYdEm?= =?us-ascii?Q?SvVsqz2lrv3Cx6MReSpfI9r6fWFociqW7X1Ncv6R12yNUmYkkMWGnJCLQ4qG?= =?us-ascii?Q?UxYF7ZivzIe5yvjDT/NpJM9CEI5WvPDLaq+wTssRl8svY74G/7emxpiWog3Z?= =?us-ascii?Q?ezZniwqW4vpLkYB/v+yWmAZteDbwwXSVAMy94PXv+R0sI5VhUv012AyjkULJ?= =?us-ascii?Q?TG/zbJFpLQYj2wp84iFdn7zLaQwMZTtzAFa9s9hefgIf3lZMcd1Gg2MLD0O7?= =?us-ascii?Q?KjwDwx+3oMR4IkBjMglJ/R83PyRxFGqPtfSHrauyU/pSrZ+IgjNHH14CGJV/?= =?us-ascii?Q?zlXaWi73EgA8ndfGWFenGNgrgG1mb35NRPWl4Llr7vxY73LzGd4JcwN4rjSS?= =?us-ascii?Q?NmEepcyqKScAtwlldD5lOu6agCkA1FJvHpFnCtj32WQuCVGIBNMT6WD58fiD?= =?us-ascii?Q?Pcuv2vEqBaqlr+wrsu7qHm1XwLBQW4vkCO7yAk+edfaMsFBqxUdkTuKeNNdJ?= =?us-ascii?Q?ZCOIVw3MjNkcduumZwk8heGvV4enVOQ40AQ30m3QRD8Di5SpUMhZ+n0xD1V3?= =?us-ascii?Q?y2TVzDFtM4oVYK1sdGltgRKbUPye8NVmULkwpEUjq6vHy5xzP/BoyRVdZbZh?= =?us-ascii?Q?YMflgC3ZvageX/WjCgZlhYkKPRnRRWWLzACW2gInjHdQf/Q/BKt2913sQ53f?= =?us-ascii?Q?hHTnPVPXC8sJMfy7W/Iu4E1fciMnv+H/IuPR6NfevIoe06M51jCyhqzWH+Vn?= =?us-ascii?Q?hlQE2qsbZSTvTNZ9xcjEnPurRidT9QeUqZeo163qiew41m8Uz/j7bI14grpJ?= =?us-ascii?Q?YnJBJUuuejIdv2Q59syQ7YaEs9wZJkMibikp9A8/LCPfx2dK5MAMKz+KBUWb?= =?us-ascii?Q?WgReAOfjyLYl6v0h8bYds4vkfX9d+YFFJIeS2K2l19HmDn3nEoYkFsJuJSD8?= =?us-ascii?Q?cxcK9U1yiGte5uOZAs3Z2C93gQJzEZ3+TEDH/lqKehdG1RSRtHD2Eh1cpq4C?= =?us-ascii?Q?9XbkbhhjtIM7lzOkHza4p+AM0EQuAcy0m5J3tP9s7wghHnCKazvPDODq3gYu?= =?us-ascii?Q?CD69hcvy4BCIC0T8TXgBfYPW1HeUYAT6iwxRB/YzmrFcAEAtBJrY6TYs9aQu?= =?us-ascii?Q?6le1Su/RVhW1r5FQEoaALCazK28FDVjENUH/TwKFAIckQEZrTvgL09wP9ygW?= =?us-ascii?Q?JJmUnjEff4SkeDuPneLrmjeGeGCxOo0TQjHkfiK3tGq+pJ7oE5ZtzxqoLbCB?= =?us-ascii?Q?UpOs0sycTGWL8P7Zyu3tI5BArC2KVp3q8T59eTHVpavOxR6ynFpyFF405nV/?= =?us-ascii?Q?fo8jsKydG5gpO1RIxPG8JBBvnWWrTr87+aEaI+eANzQkTvlRcYFNExhYcwXm?= =?us-ascii?Q?Y4+S1XtDoDmLWf9HqPThytFXxzLienUdx97vwbkTt7R2BJydEz9A03tKHgGn?= =?us-ascii?Q?icubRHR2iMjiBRwb7CPtYxvuxqfpgxMOalWBZSPiqxt3lKJy4WZ0S0y9HFWg?= =?us-ascii?Q?UA=3D=3D?= Content-Type: multipart/alternative; boundary="_000_BY3PR13MB47878F6B6146E77929686E099A259BY3PR13MB4787namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e1e1a8b7-9e7e-487a-dfc0-08d9e4fa9a20 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2022 20:45:22.6720 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 45I6Kz/Lv9XgsmRX9q8gNdf1jpchZlsayOLlfw0xa1ugYPoP0oCRdJIQF4m5/PNTV0GvVEnoFoM9Ubhq7uVkyw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3695 Archived-At: Subject: Re: [mpls] Question on avoiding TLVs 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, 31 Jan 2022 20:45:31 -0000 --_000_BY3PR13MB47878F6B6146E77929686E099A259BY3PR13MB4787namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, The question is how to enforce the TLV orders? 1. People keep inventing new TLV options, some future options may have h= igher priority 2. If what you means is to provide a catalog in advance to list the TLVs= in order. Then strictly speaking, you don't need the T in the TLV option a= ny more. But as my last presentation shows, such a design shows no benefit = in terms of parser size and performance. Haoyu From: Greg Mirsky Sent: Monday, January 31, 2022 12:39 PM To: Haoyu Song Cc: Loa Andersson ; Tony Li ; mpls@ietf.org Subject: Re: [mpls] Question on avoiding TLVs Hi Haoyu, could you please clarify for me if your recommendation for avoiding using t= he TLV construct is for all scenarios considered, i.e., ISD and PSD, or for= one of them? I agree that the random order of appearance of variable-size = data has a performance impact. On the other hand, if the order of TLVs is d= eterministic, they are flexible and the performance cost of parsing is much= lower. So, perhaps, the recommendation could be refined suggesting the use= of ordered TLVs. What are your thoughts? Regards, Greg On Mon, Jan 31, 2022 at 12:22 PM Haoyu Song > wrote: Hi Loa, When designing new headers, it's good enough to simply organize them in a c= hain, which means the current header would include a field (in some cases, such a field is no= t needed. For example, in an MPLS label stack, as long as the BoS is not se= t, you know the next header is still a label) to tell what's the next heade= r, so the parser directly know the format of the next header. IPv6 EH follows such a structure, our proposed MPLS EH also follows such a = structure. One current issue is that people tend to add variable sized TLV sub structu= res into EH to support fast path functions. This needs to be done very care= fully, otherwise, it will never fly (for example IPv4 options). Haoyu -----Original Message----- From: Loa Andersson > Sent: Monday, January 31, 2022 12:00 PM To: Haoyu Song >;= Tony Li > Cc: mpls@ietf.org Subject: Re: [mpls] Question on avoiding TLVs Haoyu, Tony, I appreciate the difference in TLVs for the forwarding plane and for the co= ntrol plane. So looking at the forwarding exactly what should not be TLV encoded? Can you give examples? /Loa On 01/02/2022 01:25, Haoyu Song wrote: > Hi Tony, > > Yes you are right. Here we are discussing the headers designed for data p= lane fast path processing. > Most of the TLVs designed before are for control plane to use. > But as you see, some current work for supposed fast path processing also = suggests to use TLV options (e.g., in IPv6 EH) due to the lack of options. = We need to be careful here, because for the parser point of view, each TLV = options equals to at least 2 headers. > Now for MPLS EH, all I suggest is to avoid the issue because we are still= at the early stages and have the opportunity to avoid some costly mistakes= . > > Best, > Haoyu > > -----Original Message----- > From: Tony Li > On Be= half Of Tony Li > Sent: Monday, January 31, 2022 9:03 AM > To: Haoyu Song = > > Cc: Loa Andersson >; mpls@ietf.org > Subject: Re: [mpls] Question on avoiding TLVs > > > Haoyu, Loa, > > I think the important point here is that the parsing discussion is focuse= d on the forwarding plane. TLVs are pervasive in the control plane, where = parsing is not a significant cost. > > Tony > > >> On Jan 31, 2022, at 8:46 AM, Haoyu Song > wrote: >> >> Hi Loa, >> >> Usually TLV is used as a substructure in a header. For sub fields in a h= eader, usually we don't have other choices than using TLV. But for each he= ader, the type of it is better to be indicated by the previous header to sa= ve a parsing state. >> So all what I say is: as a principle, when designing a header, try not t= o embed its type in the header itself. Instead, before we get to this heade= r, we should already know its type. >> >> Moreover, TLV options in a header also increases the parsing cost. Each = fixed size TLV needs two states. Each variable size TLV needs multiple stat= es depending on the size of the option. So another advice is: if it is mean= t to be processed in hardware, then we should try to limit the use of TLV, = and especially variable sized TLV, unless absolutely necessary. >> >> Best, >> Haoyu >> >> -----Original Message----- >> From: Loa Andersson > >> Sent: Monday, January 31, 2022 3:27 AM >> To: mpls@ietf.org; Haoyu Song > >> Subject: Question on avoiding TLVs >> >> Haoyu, >> >> In the slides you uploaded to the "We should try the best to avoid TLV s= tyle and variable sized header". >> >> MPLS is full of TLVs (LDP, RSVP/TE, LSP Ping, the OAM) are you suggestin= g we'd change this? >> >> Given your advice above what should we do? >> >> /Loa >> -- >> Loa Andersson email: loa@pi.nu >> Senior MPLS Expert loa.pi.nu@gmail.com >> Bronze Dragon Consulting phone: +46 739 81 21 64 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww >> .ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=3D04%7C= 01%7Chaoyu.song%4 >> 0futurewei.com%7Cfde3747555a34d294db408d9e4f44eba%7C= 0fee8ff2a3b240189 >> c753a1d5591fedc%7C1%7C1%7C637792560238419199%7CUnknown%7CTWFpbGZsb3d8 >> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C >> 3000&sdata=3Do%2F9wFBtO2sn8Y9y7KSMoRDqDBlA9F2Jz7VL6n9rwqPE%3D&r >> eserved=3D0 > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_BY3PR13MB47878F6B6146E77929686E099A259BY3PR13MB4787namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

The question is how to enforce the TLV orders?<= /o:p>

  1. People keep inventing new TLV options, some future options may have h= igher priority
  2. If what you means is to provide a catal= og in advance to list the TLVs in order. Then strictly speaking, you don= 217;t need the T in the TLV option any more. But as my last presentation shows, such a design shows no benefit in terms of parser size and performa= nce.

 

Haoyu

From: Greg Mirsky <gregimirsky@gmail.com&g= t;
Sent: Monday, January 31, 2022 12:39 PM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Loa Andersson <loa@pi.nu>; Tony Li <tony.li@tony.li>= ; mpls@ietf.org
Subject: Re: [mpls] Question on avoiding TLVs

 

Hi Haoyu,

could you please clarify for me if your recommendati= on for avoiding using the TLV construct is for all scenarios considered, i.= e., ISD and PSD, or for one of them? I agree that the random order of appea= rance of variable-size data has a performance impact. On the other hand, if the order of TLVs is determinist= ic, they are flexible and the performance cost of parsing is much lower. So= , perhaps, the recommendation could be refined suggesting the use of ordere= d TLVs.

What are your thoughts?

 

Regards,

Greg

 

On Mon, Jan 31, 2022 at 12:22 PM Haoyu Song <haoyu.song@futurewei.com> wr= ote:

Hi Loa,

When designing new headers, it's good enough to simply organize them in a c= hain, which means
the current header would include a field (in some cases, such a field is no= t needed. For example, in an MPLS label stack, as long as the BoS is not se= t, you know the next header is still a label) to tell what's the next heade= r, so the parser directly know the format of the next header.
IPv6 EH follows such a structure, our proposed MPLS EH also follows such a = structure.
One current issue is that people tend to add variable sized TLV sub structu= res into EH to support fast path functions. This needs to be done very care= fully, otherwise, it will never fly  (for example IPv4 options).

Haoyu



-----Original Message-----
From: Loa Andersson <loa@= pi.nu>
Sent: Monday, January 31, 2022 12:00 PM
To: Haoyu Song <haoyu.song@futurewei.com>; Tony Li <tony.li@tony.li>
Cc: mpls@ietf.org Subject: Re: [mpls] Question on avoiding TLVs

Haoyu, Tony,

I appreciate the difference in TLVs for the forwarding plane and for the co= ntrol plane.

So looking at the forwarding exactly what should not be TLV encoded?

Can you give examples?

/Loa

On 01/02/2022 01:25, Haoyu Song wrote:
> Hi Tony,
>
> Yes you are right. Here we are discussing the headers designed for dat= a plane fast path processing.
> Most of the TLVs designed before are for control plane to use.
> But as you see, some current work for supposed fast path processing al= so suggests to use TLV options (e.g., in IPv6 EH) due to the lack of option= s. We need to be careful here, because for the parser point of view, each T= LV options equals to at least 2 headers.
> Now for MPLS EH, all I suggest is to avoid the issue because we are st= ill at the early stages and have the opportunity to avoid some costly mista= kes.
>
> Best,
> Haoyu
>
> -----Original Message-----
> From: Tony Li <tony1athome@gmail.com> On Behalf Of Tony Li
> Sent: Monday, January 31, 2022 9:03 AM
> To: Haoyu Song <haoyu.song@futurewei.com>
> Cc: Loa Andersson <l= oa@pi.nu>; mpls@ietf.org
> Subject: Re: [mpls] Question on avoiding TLVs
>
>
> Haoyu, Loa,
>
> I think the important point here is that the parsing discussion is foc= used on the forwarding plane.  TLVs are pervasive in the control plane= , where parsing is not a significant cost.
>
> Tony
>
>
>> On Jan 31, 2022, at 8:46 AM, Haoyu Song <haoyu.song@futurewei.com> wr= ote:
>>
>> Hi Loa,
>>
>> Usually TLV is used as a substructure in a header. For sub fields = in a header, usually we don't have other choices than using TLV.  But = for each header, the type of it is better to be indicated by the previous h= eader to save a parsing state.
>> So all what I say is: as a principle, when designing a header, try= not to embed its type in the header itself. Instead, before we get to this= header, we should already know its type.
>>
>> Moreover, TLV options in a header also increases the parsing cost.= Each fixed size TLV needs two states. Each variable size TLV needs multipl= e states depending on the size of the option. So another advice is: if it i= s meant to be processed in hardware, then we should try to limit the use of TLV, and especially variable sized TLV, = unless absolutely necessary.
>>
>> Best,
>> Haoyu
>>
>> -----Original Message-----
>> From: Loa Andersson <loa@pi.nu>
>> Sent: Monday, January 31, 2022 3:27 AM
>> To: mpls@ietf.o= rg; Haoyu Song <haoyu.song@futurewei.com>
>> Subject: Question on avoiding TLVs
>>
>> Haoyu,
>>
>> In the slides you uploaded to the "We should try the best to = avoid TLV style and variable sized header".
>>
>> MPLS is full of TLVs (LDP, RSVP/TE, LSP Ping, the OAM) are you sug= gesting we'd change this?
>>
>> Given your advice above what should we do?
>>
>> /Loa
>> --
>> Loa Andersson              &nbs= p;         email: loa@pi.nu
>> Senior MPLS Expert             =             loa.pi.nu@gmail.com
>> Bronze Dragon Consulting            =  phone: +46 739 81 21 64
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>>
https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww=
>> .ietf.o= rg%2Fmailman%2Flistinfo%2Fmpls&amp;data=3D04%7C01%7Chaoyu.song%4 >> 0futurewei.com%7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b240189 >> c753a1d5591fedc%7C1%7C1%7C637792560238419199%7CUnknown%7CTWFpbGZsb= 3d8
>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D= %7C
>> 3000&amp;sdata=3Do%2F9wFBtO2sn8Y9y7KSMoRDqDBlA9F2Jz7VL6n9rwqPE= %3D&amp;r
>> eserved=3D0
>

--
Loa Andersson                 =       email: loa@pi.nu
Senior MPLS Expert                &= nbsp;         loa.pi.nu@gmail.com
Bronze Dragon Consulting             pho= ne: +46 739 81 21 64

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

--_000_BY3PR13MB47878F6B6146E77929686E099A259BY3PR13MB4787namp_-- From nobody Mon Jan 31 13:00:13 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C799C3A17D3 for ; Mon, 31 Jan 2022 13:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=LSv+1D9f; dkim=pass (1024-bit key) header.d=juniper.net header.b=LR9Fg88l 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 E2o73vfSCtL1 for ; Mon, 31 Jan 2022 13:00:04 -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 C0B9D3A17D8 for ; Mon, 31 Jan 2022 13:00:01 -0800 (PST) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 20VK3iog015354; Mon, 31 Jan 2022 12:59:59 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=+NsLSX3m3I/c7+yrI61JpPXXjcl8uper3T0fIjjaD4E=; b=LSv+1D9f/sfFerhqRjTCr1i84JXw0oPZE3eeh+ilzG3WMo5rWAlh9hvkjGQ1LFumeiUq OzQUVDc3qFBR9jHk0Oog6TJMPxQBUvUTEJ0JQeIfgzKPZOx9I+CNGaq+cjo/7UB/kkNq KGfgmTU4337lGtwf+axQW+dd1YjqdKW3QTfRujMP+DymKOR9y4wS85MTDTB1YHdE9LtM dVFRyQ98l+xRxTuSpHfXaDYTLKm3vbJPOG5yR0qKRAS9Vd3VHpQdz4NCQIkcBhFeHlAx upxtNolYTiCB69xLai9gwAfCKtQu0wZxL1UkzxyQFw8GzQ7rYJDWdeVnal/8AAve0iFB Ng== Received: from nam04-dm6-obe.outbound.protection.outlook.com (mail-dm6nam08lp2044.outbound.protection.outlook.com [104.47.73.44]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3dxcq0sd59-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 31 Jan 2022 12:59:59 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VM9795hSBDwSKweaoR+XIcXDjLWIZau97wUMc19ZgMgIP0ltesd32H/wJ53gJ8mnViBFYPwWVN/cyY9kBbQ0rXWrOgzN4wrZADLAWZqYCtBYjF06R0GJlKePhdniJNehnIFSB+otjgzRALJkjGR7OWhRgm2NSvVVvmUwZmf+6VWiLrGixGBY9AmhdXsHylZbeyE/fBA0btBVrONaHKLRa55o69H34FOhRAX6ji8//7VLet0a0pX99e6ZCaNAqVHCUO5CtnFInA+2Gq2MnAhELZkUn7leacY/lpP9TYcISJytk4JPdQBU5AVjixHDxzt3EnKWHmNe0pXf0Z0w730mcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+NsLSX3m3I/c7+yrI61JpPXXjcl8uper3T0fIjjaD4E=; b=GAvrNz+sVnBxKmRJz+id6YZOaAWgX/3y/oZS3oqQKjtPNqKxsk+Wyh4iJagDVVr9kQxHsKMI83ew9GgJ3V1kNoiPEznpK6Bqy962b4cRlS++squsiA9CwKm6w6lseFSVKkAm7MnLFeEfkwuo4xwDfG5LAXguhCvXELuh3TUTSkkUlVUZ5rTgrvwUflso4bQRG3glWufcO8nmT8VDkyiM7B4p/as6/0qTLRd2fvtyDM4OBDseeTM50Bw4jIR4pHfB3ZQZ0gHsLguclFsAK1m7xYGpa6uqnpDbEdpb02mKYq8OupOQBuDyMDhCDO7E+84l285iUdhyaaKfyyNfN2Y5Bg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+NsLSX3m3I/c7+yrI61JpPXXjcl8uper3T0fIjjaD4E=; b=LR9Fg88l/vn8eJl6oUkVgeO92kuX/1aLP86akLmPM30xalJ0siW7zGNXdUYmOJjK9sgX2K6orp25eQ8ptimsqrOyjJQkfVuHYrYEvvXtGORvkO4x8x/uacImvKZSbQ+0T6IFQhIh6Vmr0Q/n7VxXbMP+SQW0sf/b5oN4ICYo+MA= Received: from BY3PR05MB8081.namprd05.prod.outlook.com (2603:10b6:a03:366::15) by DM5PR05MB3146.namprd05.prod.outlook.com (2603:10b6:3:c8::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.11; Mon, 31 Jan 2022 20:59:56 +0000 Received: from BY3PR05MB8081.namprd05.prod.outlook.com ([fe80::304c:2b94:4f26:a581]) by BY3PR05MB8081.namprd05.prod.outlook.com ([fe80::304c:2b94:4f26:a581%3]) with mapi id 15.20.4951.011; Mon, 31 Jan 2022 20:59:56 +0000 From: John E Drake To: Greg Mirsky , "mpls@ietf.org" Thread-Topic: [mpls] Question on avoiding TLVs Thread-Index: AQHYFsJaZXkwECE6qEqD6XWN+2qzHqx9W2iAgAAGJQCAACs/gIAABhyAgAAEmwCAAANDUA== Date: Mon, 31 Jan 2022 20:59:56 +0000 Message-ID: References: <5cd6a374-d677-15c5-c721-77614de00c7f@pi.nu> <3BD86173-D24E-4669-91AD-B8C1E349D344@tony.li> <5ee2960d-ad6d-2aa4-268d-88861d17e201@pi.nu> 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.6.400.34 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2022-01-31T20:50:14Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=92202340-ce3e-432d-b6e9-83adb9fd40a0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_enabled: true msip_label_0633b888-ae0d-4341-a75f-06e04137d755_setdate: 2022-01-31T20:59:51Z msip_label_0633b888-ae0d-4341-a75f-06e04137d755_method: Standard msip_label_0633b888-ae0d-4341-a75f-06e04137d755_name: 0633b888-ae0d-4341-a75f-06e04137d755 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_siteid: bea78b3c-4cdb-4130-854a-1d193232e5f4 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_actionid: d9c68d08-ce36-49f6-ac07-2daef113206c msip_label_0633b888-ae0d-4341-a75f-06e04137d755_contentbits: 0 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f854085a-7a35-4e05-00be-08d9e4fca2ca x-ms-traffictypediagnostic: DM5PR05MB3146:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eQQO1EVhRt5Vzm3dmUny07V5h1Z8lvp/+orTeyJ3kAuf/b5euPjXDXSMPOQrWZTeXojvlKnoBwveclM+PlNBXJtGXIqToXn+wKQCNxrK6ReqBgKWszqZYiRtYB97QahkM1z7CO+hO3LZrxxGHAGXdCwJYn2bzCX+80IMg4u2pl7rJBoF2UwyX7JQ8/+fMU/qW10u45WPxtC/ioeeQ+kt6E4Fbe657DwFPU+NI6jipOd1MVFuhyvqGuAicRSMZrIjbCCqLxw7NqIcT+e18jjsX6PU1sR9B3rCv+mw5dc4f+9S3YvIUAbtv3ggaayOZbvTTvmIgm99xgIrEEIr0hCW6vMM2UA1iyQS5JoOw9MMzbsl3VURv51S0Dk5KhY0KQIJEsXBZp7XUb8ia0PDcPjxTi4WOr/uYHL6oJbfPWL4Y8fijJtzl0sQJEETY1Dc3Dctaz4skkQeKeYQ2ujZBea6eeG1q+zYTI2tRGogVZy8JSJY364R0+iPuffip1ZWP/sNqLiTU4Nji6iOcxLYGoCMLgYReKazfTAZnTBhQLj7g6KccN3qhftid/SgJ0ll6VQXkgqpDsHNIBYG8ymL/Jfs9Sk2T/TLgbY0TN1GPFWJGlWZHSGsBqENwKLf5WS8YM7DRzniDTyaOI3YRsWXBN9M5Ln1Tv3tZG2zfLlXMno8yO4GNQrgCe7ZIo8kJ8IJp/qtGwkigUNIyf90re9iAlCS/EJwKdJkg0Rjnrc96G3psb2IH8K78fuqKuViha1FOMNV08HXfr2mHRPFNDikZbrT08BZuW9XemIFBQEw8rwx+OM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR05MB8081.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(71200400001)(45080400002)(166002)(38070700005)(6506007)(7696005)(53546011)(55016003)(9686003)(66574015)(26005)(186003)(38100700002)(66476007)(83380400001)(122000001)(86362001)(33656002)(966005)(316002)(5660300002)(110136005)(2906002)(4326008)(76116006)(66556008)(8676002)(508600001)(66946007)(64756008)(66446008)(8936002)(52536014)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Gfm46DhIuwC6DjT8yGCeSrKLKSQ/ZLxnf5aJQuTOuhkwdPG/wag6p/wn1j4c?= =?us-ascii?Q?4Oj7qbp0g8tAdVSdoU39CI3fbPmZZFzbSSMzcLxHuypFcGzBH8VuXURJM181?= =?us-ascii?Q?wmAHGgnvSeD5tFGGzz8n8U7pBapdgrAvDILtRqKtFH6iYEHo7YzV3zPgCLDN?= =?us-ascii?Q?M5MPn5L5QlV7XwHjhHLGjZPn0/kWYJDSy3OIfzChBl2Vgl4n+M3d6f+tQyve?= =?us-ascii?Q?PQl0/6Cir2SoC2Z6RxuF3gLPcAMQxiE0GOufXsb1s2flvPqENwSB7XdptPYe?= =?us-ascii?Q?A9iqpi/6j2A/fRWcUZ+s8HHbBz9hAooUDtMfV2h3x+Q1WfOSTcH+Q6nr6h+q?= =?us-ascii?Q?/9a2BWdTQhHHaOYj+fRCzlKNcscEJw3rlDjOsADplQ3xVdtz0PAf37K1B+fA?= =?us-ascii?Q?6QlpssISSLtnkKLAKApOZRgDXAIg4Esffc0xYboQqglsCRhj3hwqMD+1Sbs/?= =?us-ascii?Q?sr57RRsJLg3kBzOR6stPm5/kX88a7bbJqcfp/g8cUT5oalA2+pNJ8Tbap14T?= =?us-ascii?Q?HFxnfefjKl3QCKml9+67EwsBAax4w7Vi6BprR9fVXz8Ezd1IF/QSrxix+PPf?= =?us-ascii?Q?F3QJ6U9Jf5xPa6gsDcDtQXmM0X9U+GbPMat9i0G8QA40hozEcVCx98KkVEXq?= =?us-ascii?Q?0qBQtez5PvhXy7aaH+oQZERVydhDw7GpCZluDCve0oSn+cMgcjeKF7COxeK0?= =?us-ascii?Q?gdicJSFlnd9n6sObHuoiF1OihAabhE+givXjsfomRwjqfjW3zduV6N1p6tD6?= =?us-ascii?Q?bltB6nlpFmgdFv5eL9eVM5uZnJKLlJODtrdZ//fkm4mNprGt+sFbUOXQG+jc?= =?us-ascii?Q?u/BucWS8JcjpiMg0qw1py5Sf6LZrCDTKSpy55XWGyiwfJBZ4ijmkZo/72Vjc?= =?us-ascii?Q?hhdn7Vif1YNwlSI4brVe+RgREXtZgTngZUY8klInDs5MajRSPuvqHwwmiHEk?= =?us-ascii?Q?/GLuW4d6YFVA189UOOusdU1tfwkA7nOmXrtWCiWUaUGQ8hFJuMAZfVGI0Dv6?= =?us-ascii?Q?ehCYcn/rqDhTQ9XBldTwYwVGeyfpUb3/IQAm/8P1wr11vAbQiHDQdT6x5BLY?= =?us-ascii?Q?SuDS9DZoj3kn2VJb1kvlb9QICNTdaE/jzzBqbgv24R/lgb2253OOcb0RJIKT?= =?us-ascii?Q?OM5quCU5XRC/LGbIDFjxek/Bj5eZfYNAItbBCaHoi0TPUGDjPxXRZaYToz1c?= =?us-ascii?Q?nADaeb01+/Kba3SOqIdUkgvpiH/G3MVCZ+lXHdmWPToP91sbN0Sz/Wg4NIFF?= =?us-ascii?Q?k1V8tplrTPpY/wlsxuzYvttU38ogS0Mi+gF4btCA+BC8XsqdTJqFdWgKiFcM?= =?us-ascii?Q?KfHhOps1WwROzuDcoHbZLy8jHJpDZg7MVFgwNjQFkmD0ZnQgeiAGLAo7O0wY?= =?us-ascii?Q?zA0hW1oc1+BhApRuvtt9pcCE3U5galzMzEUkFxGTHMD7o4/Xb+4rInQP2f6p?= =?us-ascii?Q?mTLtZR8KjMflJ38od3AtzoCUtF2Ge7quAL6+k9tLhvw0vD34z247oci/2Wkk?= =?us-ascii?Q?zEDNbAy52WuXIishoy9GwTVLrHizGXr6CHQMFBjUnThKUt/u0ZcsGCKeG1Kk?= =?us-ascii?Q?6/EmNdTweQ+SEsyfaPWhZFMD0lQDaGrV6E73vfUSFcCpGGoc4OlCIhVMAqTI?= =?us-ascii?Q?CQ=3D=3D?= Content-Type: multipart/alternative; boundary="_000_BY3PR05MB808172A681892C3862907153C7259BY3PR05MB8081namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR05MB8081.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f854085a-7a35-4e05-00be-08d9e4fca2ca X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2022 20:59:56.2268 (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-CrossTenant-userprincipalname: vQ09gVzghezVMp3kcMlW2jbff5B73fU2ceGLl4fub1rUeFJWxcUmUUCjxmZKuy0qgHw870Y3ih9uvZ1sUL3tFQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3146 X-Proofpoint-GUID: CS3iL1VKxJxiHRsOCEMlqiTpf90E2Wu3 X-Proofpoint-ORIG-GUID: CS3iL1VKxJxiHRsOCEMlqiTpf90E2Wu3 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-01-31_07,2022-01-31_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 clxscore=1011 mlxscore=0 suspectscore=0 priorityscore=1501 mlxlogscore=999 lowpriorityscore=0 impostorscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2201310134 Archived-At: Subject: Re: [mpls] Question on avoiding TLVs 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, 31 Jan 2022 21:00:11 -0000 --_000_BY3PR05MB808172A681892C3862907153C7259BY3PR05MB8081namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, In the proposal from Adrian and me, for every network action that is defin= ed, we will define its bit position in the network action flags, whether it= has ancillary data, if so what is that ancillary data, and whether that an= cillary data is in-stack or post-stack. When a P router receives a packet,= then based upon which network action flags are set, it will know the forma= t of the in-stack and post-stack ancillary data, because we stipulate that = it must be in the same order as the network actions whose flags are set. Yours Irrespectively, John Juniper Business Use Only From: mpls On Behalf Of Greg Mirsky Sent: Monday, January 31, 2022 3:39 PM To: Haoyu Song Cc: mpls@ietf.org Subject: Re: [mpls] Question on avoiding TLVs [External Email. Be cautious of content] Hi Haoyu, could you please clarify for me if your recommendation for avoiding using t= he TLV construct is for all scenarios considered, i.e., ISD and PSD, or for= one of them? I agree that the random order of appearance of variable-size = data has a performance impact. On the other hand, if the order of TLVs is d= eterministic, they are flexible and the performance cost of parsing is much= lower. So, perhaps, the recommendation could be refined suggesting the use= of ordered TLVs. What are your thoughts? Regards, Greg On Mon, Jan 31, 2022 at 12:22 PM Haoyu Song > wrote: Hi Loa, When designing new headers, it's good enough to simply organize them in a c= hain, which means the current header would include a field (in some cases, such a field is no= t needed. For example, in an MPLS label stack, as long as the BoS is not se= t, you know the next header is still a label) to tell what's the next heade= r, so the parser directly know the format of the next header. IPv6 EH follows such a structure, our proposed MPLS EH also follows such a = structure. One current issue is that people tend to add variable sized TLV sub structu= res into EH to support fast path functions. This needs to be done very care= fully, otherwise, it will never fly (for example IPv4 options). Haoyu -----Original Message----- From: Loa Andersson > Sent: Monday, January 31, 2022 12:00 PM To: Haoyu Song >;= Tony Li > Cc: mpls@ietf.org Subject: Re: [mpls] Question on avoiding TLVs Haoyu, Tony, I appreciate the difference in TLVs for the forwarding plane and for the co= ntrol plane. So looking at the forwarding exactly what should not be TLV encoded? Can you give examples? /Loa On 01/02/2022 01:25, Haoyu Song wrote: > Hi Tony, > > Yes you are right. Here we are discussing the headers designed for data p= lane fast path processing. > Most of the TLVs designed before are for control plane to use. > But as you see, some current work for supposed fast path processing also = suggests to use TLV options (e.g., in IPv6 EH) due to the lack of options. = We need to be careful here, because for the parser point of view, each TLV = options equals to at least 2 headers. > Now for MPLS EH, all I suggest is to avoid the issue because we are still= at the early stages and have the opportunity to avoid some costly mistakes= . > > Best, > Haoyu > > -----Original Message----- > From: Tony Li > On Be= half Of Tony Li > Sent: Monday, January 31, 2022 9:03 AM > To: Haoyu Song = > > Cc: Loa Andersson >; mpls@ietf.org > Subject: Re: [mpls] Question on avoiding TLVs > > > Haoyu, Loa, > > I think the important point here is that the parsing discussion is focuse= d on the forwarding plane. TLVs are pervasive in the control plane, where = parsing is not a significant cost. > > Tony > > >> On Jan 31, 2022, at 8:46 AM, Haoyu Song > wrote: >> >> Hi Loa, >> >> Usually TLV is used as a substructure in a header. For sub fields in a h= eader, usually we don't have other choices than using TLV. But for each he= ader, the type of it is better to be indicated by the previous header to sa= ve a parsing state. >> So all what I say is: as a principle, when designing a header, try not t= o embed its type in the header itself. Instead, before we get to this heade= r, we should already know its type. >> >> Moreover, TLV options in a header also increases the parsing cost. Each = fixed size TLV needs two states. Each variable size TLV needs multiple stat= es depending on the size of the option. So another advice is: if it is mean= t to be processed in hardware, then we should try to limit the use of TLV, = and especially variable sized TLV, unless absolutely necessary. >> >> Best, >> Haoyu >> >> -----Original Message----- >> From: Loa Andersson > >> Sent: Monday, January 31, 2022 3:27 AM >> To: mpls@ietf.org; Haoyu Song > >> Subject: Question on avoiding TLVs >> >> Haoyu, >> >> In the slides you uploaded to the "We should try the best to avoid TLV s= tyle and variable sized header". >> >> MPLS is full of TLVs (LDP, RSVP/TE, LSP Ping, the OAM) are you suggestin= g we'd change this? >> >> Given your advice above what should we do? >> >> /Loa >> -- >> Loa Andersson email: loa@pi.nu >> Senior MPLS Expert loa.pi.nu@gmail.com >> Bronze Dragon Consulting phone: +46 739 81 21 64 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww<= https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?= url=3Dhttps*3A*2F*2Fwww__;JSUl!!NEt6yMaO-gk!UQBwBfuS1f7lCEKzXcTXsGHzfpNTha6= 7nwZC7ZdjiEp7nqm_cA-hkTzTQyKJxHY$> >> .ietf.org%2Fmailman%2F= listinfo%2Fmpls&data=3D04%7C01%7Chaoyu.song%4 >> 0futurewei.com%7= Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b240189 >> c753a1d5591fedc%7C1%7C1%7C637792560238419199%7CUnknown%7CTWFpbGZsb3d8 >> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C >> 3000&sdata=3Do%2F9wFBtO2sn8Y9y7KSMoRDqDBlA9F2Jz7VL6n9rwqPE%3D&r >> eserved=3D0 > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_BY3PR05MB808172A681892C3862907153C7259BY3PR05MB8081namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greg,

 

In the proposal from Adrian and me,  for every = network action that is defined, we will define its bit position in the netw= ork action flags, whether it has ancillary data, if so what is that ancilla= ry data, and whether that ancillary data is in-stack or post-stack.  When a P router receives a packet, then b= ased upon which network action flags are set, it will know the format of th= e in-stack and post-stack ancillary data, because we stipulate that it must= be in the same order as the network actions whose flags are set.

 

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: mpls <mpls-bounces@ietf.org> O= n Behalf Of Greg Mirsky
Sent: Monday, January 31, 2022 3:39 PM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: mpls@ietf.org
Subject: Re: [mpls] Question on avoiding TLVs

 

<= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

 

Hi Haoyu,

could you please clarify for me if your recommendati= on for avoiding using the TLV construct is for all scenarios considered, i.= e., ISD and PSD, or for one of them? I agree that the random order of appea= rance of variable-size data has a performance impact. On the other hand, if the order of TLVs is determinist= ic, they are flexible and the performance cost of parsing is much lower. So= , perhaps, the recommendation could be refined suggesting the use of ordere= d TLVs.

What are your thoughts?

 

Regards,

Greg

 

On Mon, Jan 31, 2022 at 12:22 PM Haoyu Song <haoyu.song@futurewei.com> wr= ote:

Hi Loa,

When designing new headers, it's good enough to simply organize them in a c= hain, which means
the current header would include a field (in some cases, such a field is no= t needed. For example, in an MPLS label stack, as long as the BoS is not se= t, you know the next header is still a label) to tell what's the next heade= r, so the parser directly know the format of the next header.
IPv6 EH follows such a structure, our proposed MPLS EH also follows such a = structure.
One current issue is that people tend to add variable sized TLV sub structu= res into EH to support fast path functions. This needs to be done very care= fully, otherwise, it will never fly  (for example IPv4 options).

Haoyu



-----Original Message-----
From: Loa Andersson <loa@= pi.nu>
Sent: Monday, January 31, 2022 12:00 PM
To: Haoyu Song <haoyu.song@futurewei.com>; Tony Li <tony.li@tony.li>
Cc: mpls@ietf.org Subject: Re: [mpls] Question on avoiding TLVs

Haoyu, Tony,

I appreciate the difference in TLVs for the forwarding plane and for the co= ntrol plane.

So looking at the forwarding exactly what should not be TLV encoded?

Can you give examples?

/Loa

On 01/02/2022 01:25, Haoyu Song wrote:
> Hi Tony,
>
> Yes you are right. Here we are discussing the headers designed for dat= a plane fast path processing.
> Most of the TLVs designed before are for control plane to use.
> But as you see, some current work for supposed fast path processing al= so suggests to use TLV options (e.g., in IPv6 EH) due to the lack of option= s. We need to be careful here, because for the parser point of view, each T= LV options equals to at least 2 headers.
> Now for MPLS EH, all I suggest is to avoid the issue because we are st= ill at the early stages and have the opportunity to avoid some costly mista= kes.
>
> Best,
> Haoyu
>
> -----Original Message-----
> From: Tony Li <tony1athome@gmail.com> On Behalf Of Tony Li
> Sent: Monday, January 31, 2022 9:03 AM
> To: Haoyu Song <haoyu.song@futurewei.com>
> Cc: Loa Andersson <l= oa@pi.nu>; mpls@ietf.org
> Subject: Re: [mpls] Question on avoiding TLVs
>
>
> Haoyu, Loa,
>
> I think the important point here is that the parsing discussion is foc= used on the forwarding plane.  TLVs are pervasive in the control plane= , where parsing is not a significant cost.
>
> Tony
>
>
>> On Jan 31, 2022, at 8:46 AM, Haoyu Song <haoyu.song@futurewei.com> wr= ote:
>>
>> Hi Loa,
>>
>> Usually TLV is used as a substructure in a header. For sub fields = in a header, usually we don't have other choices than using TLV.  But = for each header, the type of it is better to be indicated by the previous h= eader to save a parsing state.
>> So all what I say is: as a principle, when designing a header, try= not to embed its type in the header itself. Instead, before we get to this= header, we should already know its type.
>>
>> Moreover, TLV options in a header also increases the parsing cost.= Each fixed size TLV needs two states. Each variable size TLV needs multipl= e states depending on the size of the option. So another advice is: if it i= s meant to be processed in hardware, then we should try to limit the use of TLV, and especially variable sized TLV, = unless absolutely necessary.
>>
>> Best,
>> Haoyu
>>
>> -----Original Message-----
>> From: Loa Andersson <loa@pi.nu>
>> Sent: Monday, January 31, 2022 3:27 AM
>> To: mpls@ietf.o= rg; Haoyu Song <haoyu.song@futurewei.com>
>> Subject: Question on avoiding TLVs
>>
>> Haoyu,
>>
>> In the slides you uploaded to the "We should try the best to = avoid TLV style and variable sized header".
>>
>> MPLS is full of TLVs (LDP, RSVP/TE, LSP Ping, the OAM) are you sug= gesting we'd change this?
>>
>> Given your advice above what should we do?
>>
>> /Loa
>> --
>> Loa Andersson              &nbs= p;         email: loa@pi.nu
>> Senior MPLS Expert             =             loa.pi.nu@gmail.com
>> Bronze Dragon Consulting            =  phone: +46 739 81 21 64
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>>
https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww=
>> .ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=3D04%7C= 01%7Chaoyu.song%4
>> 0futurewei.com%7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b240189 >> c753a1d5591fedc%7C1%7C1%7C637792560238419199%7CUnknown%7CTWFpbGZsb= 3d8
>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D= %7C
>> 3000&amp;sdata=3Do%2F9wFBtO2sn8Y9y7KSMoRDqDBlA9F2Jz7VL6n9rwqPE= %3D&amp;r
>> eserved=3D0
>

--
Loa Andersson                 =       email: loa@pi.nu
Senior MPLS Expert                &= nbsp;         loa.pi.nu@gmail.com
Bronze Dragon Consulting             pho= ne: +46 739 81 21 64

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

--_000_BY3PR05MB808172A681892C3862907153C7259BY3PR05MB8081namp_-- From nobody Mon Jan 31 13:02:18 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7724D3A1345 for ; Mon, 31 Jan 2022 13:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.997 X-Spam-Level: X-Spam-Status: No, score=-6.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRZbxaeqkIBw for ; Mon, 31 Jan 2022 13:02:11 -0800 (PST) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 1BFE73A17E7 for ; Mon, 31 Jan 2022 13:02:11 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id p7so29338594edc.12 for ; Mon, 31 Jan 2022 13:02:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0D3D7wIcxQAzqT/pyg4UghBg6n83AGvEVMfmMKtMzPU=; b=FWDBLkhUDztCX+xoYuS/jlJRTAEpBfa2Nj4gQzA3zznC70rbI8CgyDA7Crd4nXQOFf iaA1qA5p1zWQbPTKHWxG68nqUdNgcTAF80KuYKqvbSCKMWXrHz6tbZYxY0Zt0h9DX9gv 4ucwRkhCHCdJi2x+2Jb5jrkSyWCzi8Hw54CbuCRlLvqzTKeWiDmGLADcsvVrusohIez3 SmBScCUcPHvsmcBIfnAozmHQGOPq7v6sqoWDuBHMK8JcTUj6Q0EfEuHPV+1vK4s4BhD8 64eO5oZnM0cNFevI/F92NMzm4zC/4eC4o7IQ2zPVxzFZUEIIlAsZchAnCoy+X2Bpd90Z VhHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0D3D7wIcxQAzqT/pyg4UghBg6n83AGvEVMfmMKtMzPU=; b=T+PP7/CmTeYxBZGrq3e9dd4kMl1FzH9Do1w0YwndmYyjGBkMsyAV2ovQF1byB0YAqW 2iD9M2KlBmA2noB0l/12/J0nxnPKvBabQhGuEVR26BwyjJdwr10g8n/+Z8ZmSxYooR8s WwJIDDUsBss7YOJML1woUq27qARDROtkigKzhLb95oib2xccYz30Ox/1amkZiode5TnT vV0he9j4COjbkr/rP7q6tRHY7PRzk4792/vqcV2RBdoE0UcK2e7FCQQvAHvzQf8gHdh4 08bZgcNWR7SFymot/4AP7P0MZ+cJwAEjme5WIsWyXi0DtkM6TAmMo2w6jk8DnZHzsSaX 9YaA== X-Gm-Message-State: AOAM533SXAJzHKqR5lSe8DEhN0HnDl0Lbiq0aCJJO/JfgtTmao/n0CEX NUXdwxD1fPMXryr59LGjX0TEj/o1qbFbW1snw2aMNaBM X-Google-Smtp-Source: ABdhPJwYsG5RSE+4SpVEnODbphtdvwD749p1VkgLbFgQZNFVHoqb3xTyb2haj2MeNGYVAoKsUCzPOcHR05CBcKUiyKo= X-Received: by 2002:a05:6402:2689:: with SMTP id w9mr22445756edd.68.1643662928415; Mon, 31 Jan 2022 13:02:08 -0800 (PST) MIME-Version: 1.0 References: <5cd6a374-d677-15c5-c721-77614de00c7f@pi.nu> <3BD86173-D24E-4669-91AD-B8C1E349D344@tony.li> <5ee2960d-ad6d-2aa4-268d-88861d17e201@pi.nu> In-Reply-To: From: Greg Mirsky Date: Mon, 31 Jan 2022 13:01:57 -0800 Message-ID: To: Haoyu Song Cc: Loa Andersson , Tony Li , "mpls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000fa8ecf05d6e71848" Archived-At: Subject: Re: [mpls] Question on avoiding TLVs 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, 31 Jan 2022 21:02:17 -0000 --000000000000fa8ecf05d6e71848 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Haoyu, I think that an ordered list of TLVs has some benefits. For example, consider an IP address. It can be identified by a single code point of a variable-length TLV or by two code points for each address family. Also, you could have missed my question about the use case, ISD vs. PSD, you are considering when suggesting not to use a TLV. Personally, I see fewer issues using TLV in PSD. Regards, Greg On Mon, Jan 31, 2022 at 12:45 PM Haoyu Song wrote: > Hi Greg, > > > > The question is how to enforce the TLV orders? > > 1. People keep inventing new TLV options, some future options may have > higher priority > 2. If what you means is to provide a catalog in advance to list the > TLVs in order. Then strictly speaking, you don=E2=80=99t need the T in= the TLV > option any more. But as my last presentation shows, such a design show= s no > benefit in terms of parser size and performance. > > > > Haoyu > > *From:* Greg Mirsky > *Sent:* Monday, January 31, 2022 12:39 PM > *To:* Haoyu Song > *Cc:* Loa Andersson ; Tony Li ; mpls@ietf.org > *Subject:* Re: [mpls] Question on avoiding TLVs > > > > Hi Haoyu, > > could you please clarify for me if your recommendation for avoiding using > the TLV construct is for all scenarios considered, i.e., ISD and PSD, or > for one of them? I agree that the random order of appearance of > variable-size data has a performance impact. On the other hand, if the > order of TLVs is deterministic, they are flexible and the performance cos= t > of parsing is much lower. So, perhaps, the recommendation could be refine= d > suggesting the use of ordered TLVs. > > What are your thoughts? > > > > Regards, > > Greg > > > > On Mon, Jan 31, 2022 at 12:22 PM Haoyu Song > wrote: > > Hi Loa, > > When designing new headers, it's good enough to simply organize them in a > chain, which means > the current header would include a field (in some cases, such a field is > not needed. For example, in an MPLS label stack, as long as the BoS is no= t > set, you know the next header is still a label) to tell what's the next > header, so the parser directly know the format of the next header. > IPv6 EH follows such a structure, our proposed MPLS EH also follows such = a > structure. > One current issue is that people tend to add variable sized TLV sub > structures into EH to support fast path functions. This needs to be done > very carefully, otherwise, it will never fly (for example IPv4 options). > > Haoyu > > > > -----Original Message----- > From: Loa Andersson > Sent: Monday, January 31, 2022 12:00 PM > To: Haoyu Song ; Tony Li > Cc: mpls@ietf.org > Subject: Re: [mpls] Question on avoiding TLVs > > Haoyu, Tony, > > I appreciate the difference in TLVs for the forwarding plane and for the > control plane. > > So looking at the forwarding exactly what should not be TLV encoded? > > Can you give examples? > > /Loa > > On 01/02/2022 01:25, Haoyu Song wrote: > > Hi Tony, > > > > Yes you are right. Here we are discussing the headers designed for data > plane fast path processing. > > Most of the TLVs designed before are for control plane to use. > > But as you see, some current work for supposed fast path processing als= o > suggests to use TLV options (e.g., in IPv6 EH) due to the lack of options= . > We need to be careful here, because for the parser point of view, each TL= V > options equals to at least 2 headers. > > Now for MPLS EH, all I suggest is to avoid the issue because we are > still at the early stages and have the opportunity to avoid some costly > mistakes. > > > > Best, > > Haoyu > > > > -----Original Message----- > > From: Tony Li On Behalf Of Tony Li > > Sent: Monday, January 31, 2022 9:03 AM > > To: Haoyu Song > > Cc: Loa Andersson ; mpls@ietf.org > > Subject: Re: [mpls] Question on avoiding TLVs > > > > > > Haoyu, Loa, > > > > I think the important point here is that the parsing discussion is > focused on the forwarding plane. TLVs are pervasive in the control plane= , > where parsing is not a significant cost. > > > > Tony > > > > > >> On Jan 31, 2022, at 8:46 AM, Haoyu Song > wrote: > >> > >> Hi Loa, > >> > >> Usually TLV is used as a substructure in a header. For sub fields in a > header, usually we don't have other choices than using TLV. But for each > header, the type of it is better to be indicated by the previous header t= o > save a parsing state. > >> So all what I say is: as a principle, when designing a header, try not > to embed its type in the header itself. Instead, before we get to this > header, we should already know its type. > >> > >> Moreover, TLV options in a header also increases the parsing cost. Eac= h > fixed size TLV needs two states. Each variable size TLV needs multiple > states depending on the size of the option. So another advice is: if it i= s > meant to be processed in hardware, then we should try to limit the use of > TLV, and especially variable sized TLV, unless absolutely necessary. > >> > >> Best, > >> Haoyu > >> > >> -----Original Message----- > >> From: Loa Andersson > >> Sent: Monday, January 31, 2022 3:27 AM > >> To: mpls@ietf.org; Haoyu Song > >> Subject: Question on avoiding TLVs > >> > >> Haoyu, > >> > >> In the slides you uploaded to the "We should try the best to avoid TLV > style and variable sized header". > >> > >> MPLS is full of TLVs (LDP, RSVP/TE, LSP Ping, the OAM) are you > suggesting we'd change this? > >> > >> Given your advice above what should we do? > >> > >> /Loa > >> -- > >> Loa Andersson email: loa@pi.nu > >> Senior MPLS Expert loa.pi.nu@gmail.com > >> Bronze Dragon Consulting phone: +46 739 81 21 64 > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w > >> .ietf.org > > %2Fmailman%2Flistinfo%2Fmpls&data=3D04%7C01%7Chaoyu.song%4 > >> 0futurewei.com > > %7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b240189 > >> c753a1d5591fedc%7C1%7C1%7C637792560238419199%7CUnknown%7CTWFpbGZsb3d8 > >> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C > >> 3000&sdata=3Do%2F9wFBtO2sn8Y9y7KSMoRDqDBlA9F2Jz7VL6n9rwqPE%3D&= r > >> eserved=3D0 > > > > -- > Loa Andersson email: loa@pi.nu > Senior MPLS Expert loa.pi.nu@gmail.com > Bronze Dragon Consulting phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > --000000000000fa8ecf05d6e71848 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Haoyu,
I think that an ordered list of TLVs has som= e benefits. For example, consider an IP address. It can be identified by a = single code point of a variable-length TLV or by two code points for each a= ddress family.
Also, you could have missed my question about the = use case, ISD vs. PSD, you are considering when suggesting not to use a TLV= . Personally, I see fewer issues using TLV in PSD.

Regards,
Greg

Hi Greg,

=C2=A0

The question is how to enforce the TLV orders?

  1. People keep inventing new TLV options, some future options may ha= ve higher priority
  2. If what you means is to prov= ide a catalog in advance to list the TLVs in order. Then strictly speaking,= you don=E2=80=99t need the T in the TLV option any more. But as my last pr= esentation shows, such a design shows no benefit in terms of parser size and performa= nce.

=C2=A0

Haoyu

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Monday, January 31, 2022 12:39 PM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Loa Andersson <loa@pi.nu>; Tony Li <tony.li@tony.li>; mpls@ietf.org
Subject: Re: [mpls] Question on avoiding TLVs

=C2=A0

Hi Haoyu,

could you please clarify for me if your recommendati= on for avoiding using the TLV construct is for all scenarios considered, i.= e., ISD and PSD, or for one of them? I agree that the random order of appea= rance of variable-size data has a performance impact. On the other hand, if the order of TLVs is determinist= ic, they are flexible and the performance cost of parsing is much lower. So= , perhaps, the recommendation could be refined suggesting the use of ordere= d TLVs.

What are your thoughts?

=C2=A0

Regards,

Greg

=C2=A0

On Mon, Jan 31, 2022 at 12:22 PM Haoyu Song <haoyu.song@future= wei.com> wrote:

Hi Loa,

When designing new headers, it's good enough to simply organize them in= a chain, which means
the current header would include a field (in some cases, such a field is no= t needed. For example, in an MPLS label stack, as long as the BoS is not se= t, you know the next header is still a label) to tell what's the next h= eader, so the parser directly know the format of the next header.
IPv6 EH follows such a structure, our proposed MPLS EH also follows such a = structure.
One current issue is that people tend to add variable sized TLV sub structu= res into EH to support fast path functions. This needs to be done very care= fully, otherwise, it will never fly=C2=A0 (for example IPv4 options).

Haoyu



-----Original Message-----
From: Loa Andersson <loa@= pi.nu>
Sent: Monday, January 31, 2022 12:00 PM
To: Haoyu Song <haoyu.song@futurewei.com>; Tony Li <tony.li@tony.li>
Cc: mpls@ietf.org Subject: Re: [mpls] Question on avoiding TLVs

Haoyu, Tony,

I appreciate the difference in TLVs for the forwarding plane and for the co= ntrol plane.

So looking at the forwarding exactly what should not be TLV encoded?

Can you give examples?

/Loa

On 01/02/2022 01:25, Haoyu Song wrote:
> Hi Tony,
>
> Yes you are right. Here we are discussing the headers designed for dat= a plane fast path processing.
> Most of the TLVs designed before are for control plane to use.
> But as you see, some current work for supposed fast path processing al= so suggests to use TLV options (e.g., in IPv6 EH) due to the lack of option= s. We need to be careful here, because for the parser point of view, each T= LV options equals to at least 2 headers.
> Now for MPLS EH, all I suggest is to avoid the issue because we are st= ill at the early stages and have the opportunity to avoid some costly mista= kes.
>
> Best,
> Haoyu
>
> -----Original Message-----
> From: Tony Li <tony1athome@gmail.com> On Behalf Of Tony Li
> Sent: Monday, January 31, 2022 9:03 AM
> To: Haoyu Song <haoyu.song@futurewei.com>
> Cc: Loa Andersson <l= oa@pi.nu>; mpls@ietf.org
> Subject: Re: [mpls] Question on avoiding TLVs
>
>
> Haoyu, Loa,
>
> I think the important point here is that the parsing discussion is foc= used on the forwarding plane.=C2=A0 TLVs are pervasive in the control plane= , where parsing is not a significant cost.
>
> Tony
>
>
>> On Jan 31, 2022, at 8:46 AM, Haoyu Song <haoyu.song@futurewei.com> wr= ote:
>>
>> Hi Loa,
>>
>> Usually TLV is used as a substructure in a header. For sub fields = in a header, usually we don't have other choices than using TLV.=C2=A0 = But for each header, the type of it is better to be indicated by the previo= us header to save a parsing state.
>> So all what I say is: as a principle, when designing a header, try= not to embed its type in the header itself. Instead, before we get to this= header, we should already know its type.
>>
>> Moreover, TLV options in a header also increases the parsing cost.= Each fixed size TLV needs two states. Each variable size TLV needs multipl= e states depending on the size of the option. So another advice is: if it i= s meant to be processed in hardware, then we should try to limit the use of TLV, and especially variable sized TLV, = unless absolutely necessary.
>>
>> Best,
>> Haoyu
>>
>> -----Original Message-----
>> From: Loa Andersson <loa@pi.nu>
>> Sent: Monday, January 31, 2022 3:27 AM
>> To: mpls@ietf.o= rg; Haoyu Song <haoyu.song@futurewei.com>
>> Subject: Question on avoiding TLVs
>>
>> Haoyu,
>>
>> In the slides you uploaded to the "We should try the best to = avoid TLV style and variable sized header".
>>
>> MPLS is full of TLVs (LDP, RSVP/TE, LSP Ping, the OAM) are you sug= gesting we'd change this?
>>
>> Given your advice above what should we do?
>>
>> /Loa
>> --
>> 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=C2=A0 =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.pi.nu@gmail.com
>> 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://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww=
>> .ietf.o= rg%2Fmailman%2Flistinfo%2Fmpls&amp;data=3D04%7C01%7Chaoyu.song%4 >> 0futurewei.com%7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b240189 >> c753a1d5591fedc%7C1%7C1%7C637792560238419199%7CUnknown%7CTWFpbGZsb= 3d8
>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D= %7C
>> 3000&amp;sdata=3Do%2F9wFBtO2sn8Y9y7KSMoRDqDBlA9F2Jz7VL6n9rwqPE= %3D&amp;r
>> eserved=3D0
>

--
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=C2=A0 =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.pi.nu@gmail.com
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

--000000000000fa8ecf05d6e71848-- From nobody Mon Jan 31 13:11:46 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D616A3A1839 for ; Mon, 31 Jan 2022 13:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] 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 Hrn51zzwj1pf for ; Mon, 31 Jan 2022 13:11:38 -0800 (PST) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 318F83A1837 for ; Mon, 31 Jan 2022 13:11:38 -0800 (PST) Received: by mail-ej1-x632.google.com with SMTP id d10so47020349eje.10 for ; Mon, 31 Jan 2022 13:11:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EcsHiY8jQOofoVRpMXf3F4S4ByIxbR5jJWM41EMhhXM=; b=YqeGEXeC6NsaN1VX1nplPWutHTzYvK1qEnPtfTdVH0zI2x1lAAGNZ0Z07VABW7mjB3 JQH5o064aEh1to2QX5wf1aSUSeW4X2hapM0J4k3nSc58KH93pY0IIVkn6sXLyxWcVepo vE6Jtw6v5SmEmdxNkH9ETgw4+yJezmm3LaAED9+V39WMC1KD2V4GzeGbkquLF8BjPtWZ bJ8ifi+3yZmAoX2ggnFzLRx3RfKIWh9OOcmegllmRREb3nWpXLiC85ZnF3crWDdC8WuF k0GNktqUr1RfuUrjXkGHcVNkH/tyHlmyuzlXIUMRrUtoa9IKWM9KRD9NXUr33pb3MOjv 2Eew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EcsHiY8jQOofoVRpMXf3F4S4ByIxbR5jJWM41EMhhXM=; b=sups+1mqvQuyC8QZoqIrRoEKK2IdQFHO3QjD8rhCLRBasG+QWf0miqxNqkcS2+6vyK EzCXxkcNLdimNLdFajS6GOx04iFBLG+ydtlg4QS7eo/TanlTzZD2IV98zyHeVMnLqVFB W7jOKy8Gg2UOD323jnmSB3Cd+1Q5+SHY0Ci378+JSzHn0Wjd61gVJa072QKq9lBeLjDL 3Wl5ZZdVuilQJ0KmQHP87E1Zb+QJjEys2nNy2/ZgLRIJpqq9FwlfL2fBLHfm1X8GKqKd xfACdQFTkM1lG+YHbdxvFum61ZNUBQEVvHe7cRUQS2Fqsfw+JKk0QySNnDSGHS/I/rhx lAVw== X-Gm-Message-State: AOAM531IjPkYZSKiVcjguqgJ5oWpYAC3Egc5vNsUf/sHxYxoCLHXLNGE VEKglcn6ErrFOVdchtbv9/OwKQsIToCZEAn4miGfSZmX X-Google-Smtp-Source: ABdhPJxuc0WRh0R5L9+OpiiAQ9BYMpUMbv9T+xafK6Tmzz1n4yw/0cmEZkpgJpSBchjhcqKGIRR1sYfkknd/K1yFz8I= X-Received: by 2002:a17:907:6e16:: with SMTP id sd22mr15039884ejc.172.1643663495353; Mon, 31 Jan 2022 13:11:35 -0800 (PST) MIME-Version: 1.0 References: <5cd6a374-d677-15c5-c721-77614de00c7f@pi.nu> <3BD86173-D24E-4669-91AD-B8C1E349D344@tony.li> <5ee2960d-ad6d-2aa4-268d-88861d17e201@pi.nu> In-Reply-To: From: Greg Mirsky Date: Mon, 31 Jan 2022 13:11:24 -0800 Message-ID: To: John E Drake Cc: "mpls@ietf.org" , "adrian@olddog.co.uk" Content-Type: multipart/alternative; boundary="000000000000c55c1a05d6e73aa6" Archived-At: Subject: Re: [mpls] Question on avoiding TLVs 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, 31 Jan 2022 21:11:44 -0000 --000000000000c55c1a05d6e73aa6 Content-Type: text/plain; charset="UTF-8" Hi John, thank you for the clarification. I agree that the strict order of indicators (actions and ancillary data) defines the order of ancillary data. The question, as I understand it, is how the P node accesses the ancillary data. If not using a TLV, I imagine, the node must know the format of all defined indicated ancillary data elements. On the other hand, TLV encoding of ancillary data allows relax that requirement and the node can support only some, ones that it advertises while it can easily skip over others. Regards, Greg On Mon, Jan 31, 2022 at 1:00 PM John E Drake wrote: > Greg, > > > > In the proposal from Adrian and me, for every network action that is > defined, we will define its bit position in the network action flags, > whether it has ancillary data, if so what is that ancillary data, and > whether that ancillary data is in-stack or post-stack. When a P router > receives a packet, then based upon which network action flags are set, it > will know the format of the in-stack and post-stack ancillary data, because > we stipulate that it must be in the same order as the network actions whose > flags are set. > > > > Yours Irrespectively, > > > > John > > > > > > Juniper Business Use Only > > *From:* mpls *On Behalf Of * Greg Mirsky > *Sent:* Monday, January 31, 2022 3:39 PM > *To:* Haoyu Song > *Cc:* mpls@ietf.org > *Subject:* Re: [mpls] Question on avoiding TLVs > > > > *[External Email. Be cautious of content]* > > > > Hi Haoyu, > > could you please clarify for me if your recommendation for avoiding using > the TLV construct is for all scenarios considered, i.e., ISD and PSD, or > for one of them? I agree that the random order of appearance of > variable-size data has a performance impact. On the other hand, if the > order of TLVs is deterministic, they are flexible and the performance cost > of parsing is much lower. So, perhaps, the recommendation could be refined > suggesting the use of ordered TLVs. > > What are your thoughts? > > > > Regards, > > Greg > > > > On Mon, Jan 31, 2022 at 12:22 PM Haoyu Song > wrote: > > Hi Loa, > > When designing new headers, it's good enough to simply organize them in a > chain, which means > the current header would include a field (in some cases, such a field is > not needed. For example, in an MPLS label stack, as long as the BoS is not > set, you know the next header is still a label) to tell what's the next > header, so the parser directly know the format of the next header. > IPv6 EH follows such a structure, our proposed MPLS EH also follows such a > structure. > One current issue is that people tend to add variable sized TLV sub > structures into EH to support fast path functions. This needs to be done > very carefully, otherwise, it will never fly (for example IPv4 options). > > Haoyu > > > > -----Original Message----- > From: Loa Andersson > Sent: Monday, January 31, 2022 12:00 PM > To: Haoyu Song ; Tony Li > Cc: mpls@ietf.org > Subject: Re: [mpls] Question on avoiding TLVs > > Haoyu, Tony, > > I appreciate the difference in TLVs for the forwarding plane and for the > control plane. > > So looking at the forwarding exactly what should not be TLV encoded? > > Can you give examples? > > /Loa > > On 01/02/2022 01:25, Haoyu Song wrote: > > Hi Tony, > > > > Yes you are right. Here we are discussing the headers designed for data > plane fast path processing. > > Most of the TLVs designed before are for control plane to use. > > But as you see, some current work for supposed fast path processing also > suggests to use TLV options (e.g., in IPv6 EH) due to the lack of options. > We need to be careful here, because for the parser point of view, each TLV > options equals to at least 2 headers. > > Now for MPLS EH, all I suggest is to avoid the issue because we are > still at the early stages and have the opportunity to avoid some costly > mistakes. > > > > Best, > > Haoyu > > > > -----Original Message----- > > From: Tony Li On Behalf Of Tony Li > > Sent: Monday, January 31, 2022 9:03 AM > > To: Haoyu Song > > Cc: Loa Andersson ; mpls@ietf.org > > Subject: Re: [mpls] Question on avoiding TLVs > > > > > > Haoyu, Loa, > > > > I think the important point here is that the parsing discussion is > focused on the forwarding plane. TLVs are pervasive in the control plane, > where parsing is not a significant cost. > > > > Tony > > > > > >> On Jan 31, 2022, at 8:46 AM, Haoyu Song > wrote: > >> > >> Hi Loa, > >> > >> Usually TLV is used as a substructure in a header. For sub fields in a > header, usually we don't have other choices than using TLV. But for each > header, the type of it is better to be indicated by the previous header to > save a parsing state. > >> So all what I say is: as a principle, when designing a header, try not > to embed its type in the header itself. Instead, before we get to this > header, we should already know its type. > >> > >> Moreover, TLV options in a header also increases the parsing cost. Each > fixed size TLV needs two states. Each variable size TLV needs multiple > states depending on the size of the option. So another advice is: if it is > meant to be processed in hardware, then we should try to limit the use of > TLV, and especially variable sized TLV, unless absolutely necessary. > >> > >> Best, > >> Haoyu > >> > >> -----Original Message----- > >> From: Loa Andersson > >> Sent: Monday, January 31, 2022 3:27 AM > >> To: mpls@ietf.org; Haoyu Song > >> Subject: Question on avoiding TLVs > >> > >> Haoyu, > >> > >> In the slides you uploaded to the "We should try the best to avoid TLV > style and variable sized header". > >> > >> MPLS is full of TLVs (LDP, RSVP/TE, LSP Ping, the OAM) are you > suggesting we'd change this? > >> > >> Given your advice above what should we do? > >> > >> /Loa > >> -- > >> Loa Andersson email: loa@pi.nu > >> Senior MPLS Expert loa.pi.nu@gmail.com > >> Bronze Dragon Consulting phone: +46 739 81 21 64 > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > >> .ietf.org > > %2Fmailman%2Flistinfo%2Fmpls&data=04%7C01%7Chaoyu.song%4 > >> 0futurewei.com > > %7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b240189 > >> c753a1d5591fedc%7C1%7C1%7C637792560238419199%7CUnknown%7CTWFpbGZsb3d8 > >> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C > >> 3000&sdata=o%2F9wFBtO2sn8Y9y7KSMoRDqDBlA9F2Jz7VL6n9rwqPE%3D&r > >> eserved=0 > > > > -- > Loa Andersson email: loa@pi.nu > Senior MPLS Expert loa.pi.nu@gmail.com > Bronze Dragon Consulting phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > --000000000000c55c1a05d6e73aa6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John,
thank you for the clarification. I agree that= the strict order of indicators (actions and ancillary data) defines the or= der of ancillary data. The question, as I understand it, is how the P node = accesses the ancillary data. If not using a TLV, I imagine, the node must k= now the format of all defined indicated ancillary data elements. On the oth= er hand, TLV encoding of ancillary data allows relax that requirement and t= he node can support=C2=A0only some, ones that it advertises while it can ea= sily skip over others.

Regards,
Greg

On Mon, Jan 31, 2022 at 1:00 PM John E Drake <jdrake@juniper.net> wrote:

Greg,

=C2=A0

In the proposal from Adrian and me,=C2=A0 for every = network action that is defined, we will define its bit position in the netw= ork action flags, whether it has ancillary data, if so what is that ancilla= ry data, and whether that ancillary data is in-stack or post-stack.=C2=A0 When a P router receives a packet, then b= ased upon which network action flags are set, it will know the format of th= e in-stack and post-stack ancillary data, because we stipulate that it must= be in the same order as the network actions whose flags are set.

=C2=A0

Yours Irrespectively,

=C2=A0

John

=C2=A0

=C2=A0

Juniper Business Use Only<= u>

From: mpls <mpls-bounces@ietf.org> On Behalf Of = Greg Mirsky
Sent: Monday, January 31, 2022 3:39 PM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: mpls@ietf.org=
Subject: Re: [mpls] Question on avoiding TLVs

=C2=A0

[External Email. Be cautious of content]

=C2=A0

Hi Haoyu,

could you please clarify for me if your recommendati= on for avoiding using the TLV construct is for all scenarios considered, i.= e., ISD and PSD, or for one of them? I agree that the random order of appea= rance of variable-size data has a performance impact. On the other hand, if the order of TLVs is determinist= ic, they are flexible and the performance cost of parsing is much lower. So= , perhaps, the recommendation could be refined suggesting the use of ordere= d TLVs.

What are your thoughts?

=C2=A0

Regards,

Greg

=C2=A0

On Mon, Jan 31, 2022 at 12:22 PM Haoyu Song <haoyu.song@future= wei.com> wrote:

Hi Loa,

When designing new headers, it's good enough to simply organize them in= a chain, which means
the current header would include a field (in some cases, such a field is no= t needed. For example, in an MPLS label stack, as long as the BoS is not se= t, you know the next header is still a label) to tell what's the next h= eader, so the parser directly know the format of the next header.
IPv6 EH follows such a structure, our proposed MPLS EH also follows such a = structure.
One current issue is that people tend to add variable sized TLV sub structu= res into EH to support fast path functions. This needs to be done very care= fully, otherwise, it will never fly=C2=A0 (for example IPv4 options).

Haoyu



-----Original Message-----
From: Loa Andersson <loa@= pi.nu>
Sent: Monday, January 31, 2022 12:00 PM
To: Haoyu Song <haoyu.song@futurewei.com>; Tony Li <tony.li@tony.li>
Cc: mpls@ietf.org Subject: Re: [mpls] Question on avoiding TLVs

Haoyu, Tony,

I appreciate the difference in TLVs for the forwarding plane and for the co= ntrol plane.

So looking at the forwarding exactly what should not be TLV encoded?

Can you give examples?

/Loa

On 01/02/2022 01:25, Haoyu Song wrote:
> Hi Tony,
>
> Yes you are right. Here we are discussing the headers designed for dat= a plane fast path processing.
> Most of the TLVs designed before are for control plane to use.
> But as you see, some current work for supposed fast path processing al= so suggests to use TLV options (e.g., in IPv6 EH) due to the lack of option= s. We need to be careful here, because for the parser point of view, each T= LV options equals to at least 2 headers.
> Now for MPLS EH, all I suggest is to avoid the issue because we are st= ill at the early stages and have the opportunity to avoid some costly mista= kes.
>
> Best,
> Haoyu
>
> -----Original Message-----
> From: Tony Li <tony1athome@gmail.com> On Behalf Of Tony Li
> Sent: Monday, January 31, 2022 9:03 AM
> To: Haoyu Song <haoyu.song@futurewei.com>
> Cc: Loa Andersson <l= oa@pi.nu>; mpls@ietf.org
> Subject: Re: [mpls] Question on avoiding TLVs
>
>
> Haoyu, Loa,
>
> I think the important point here is that the parsing discussion is foc= used on the forwarding plane.=C2=A0 TLVs are pervasive in the control plane= , where parsing is not a significant cost.
>
> Tony
>
>
>> On Jan 31, 2022, at 8:46 AM, Haoyu Song <haoyu.song@futurewei.com> wr= ote:
>>
>> Hi Loa,
>>
>> Usually TLV is used as a substructure in a header. For sub fields = in a header, usually we don't have other choices than using TLV.=C2=A0 = But for each header, the type of it is better to be indicated by the previo= us header to save a parsing state.
>> So all what I say is: as a principle, when designing a header, try= not to embed its type in the header itself. Instead, before we get to this= header, we should already know its type.
>>
>> Moreover, TLV options in a header also increases the parsing cost.= Each fixed size TLV needs two states. Each variable size TLV needs multipl= e states depending on the size of the option. So another advice is: if it i= s meant to be processed in hardware, then we should try to limit the use of TLV, and especially variable sized TLV, = unless absolutely necessary.
>>
>> Best,
>> Haoyu
>>
>> -----Original Message-----
>> From: Loa Andersson <loa@pi.nu>
>> Sent: Monday, January 31, 2022 3:27 AM
>> To: mpls@ietf.o= rg; Haoyu Song <haoyu.song@futurewei.com>
>> Subject: Question on avoiding TLVs
>>
>> Haoyu,
>>
>> In the slides you uploaded to the "We should try the best to = avoid TLV style and variable sized header".
>>
>> MPLS is full of TLVs (LDP, RSVP/TE, LSP Ping, the OAM) are you sug= gesting we'd change this?
>>
>> Given your advice above what should we do?
>>
>> /Loa
>> --
>> 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=C2=A0 =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.pi.nu@gmail.com
>> 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://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww=
>> .ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=3D04%7C= 01%7Chaoyu.song%4
>> 0futurewei.com%7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b240189 >> c753a1d5591fedc%7C1%7C1%7C637792560238419199%7CUnknown%7CTWFpbGZsb= 3d8
>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D= %7C
>> 3000&amp;sdata=3Do%2F9wFBtO2sn8Y9y7KSMoRDqDBlA9F2Jz7VL6n9rwqPE= %3D&amp;r
>> eserved=3D0
>

--
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=C2=A0 =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.pi.nu@gmail.com
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

--000000000000c55c1a05d6e73aa6-- From nobody Mon Jan 31 13:14:29 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D133A1866 for ; Mon, 31 Jan 2022 13:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4H80ujPfUr9F for ; Mon, 31 Jan 2022 13:14:18 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2124.outbound.protection.outlook.com [40.107.243.124]) (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 72B623A1849 for ; Mon, 31 Jan 2022 13:14:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WOeEJ6GRSDIkpkGZhDgKNFt1YzK5oPk175jXGCBbWg6bjI2KJ3e09btKIJHtnWFEOYJIUzU9x8690O/iDASSEPVDbgJZbB3odp4NjtvXba4YoF/CgKtH4AhqXoFXhbZw9fdL+CLyguwqFwUJln89WW+/KzoQW5n85g6WUJm5Rr4XAYacurbw8GNF55CJhAnQmd/HXGofLb4z3GCN4jq/UxGZf6rjb5biazEYis8f0UhY9u+PNZ3lKUaQCayulyyIzNK0GA5tfwOpc0P9A4ZIukM2mQ3yJKGESjUPllHStqCB2LYE8rRfGn5GSIVA9ef9z31/QjaAv8IChQ0hfUqDOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YlX8n/DZNfDL79+SS2FSBchhUIbJiHrf9lQn6q3P1zQ=; b=B41+rzkf4MWVyR7SQunGna6eiMsMgIu3yWMp0pRxd5cfECCEnjcOMwDwEg3u2LxhoC/jr95saR5/xUUOAKKBumBay2ejhw12oCpQEWIpHiRSob3aECIw/sGZcEZFu4KKcuKmOgvYke+/oXmaUliS0JFcJVLVaK2NiqXG7oEnwi5LjIbdBeTzFq2cyvoBmBmqA7tEN7dJNWFUaJ4xsDZDf2JzjbabDFS4wcqa1COxFybjthUoKUGSGXUumrARrSlqcmedvJbBOia+sLR+9Zy7rk9e6PMJKEU69MdWe/pZ0RCO8xFqdahGANLLnrpwSALObUqtMFW/NahtRNexBFRrZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YlX8n/DZNfDL79+SS2FSBchhUIbJiHrf9lQn6q3P1zQ=; b=n5AiPH6HwmPsU7C3o0P2PCERV5EyH5Stg94N3kdTwPex6MGDB2FzvVyXluEdlZh5VTitPbD3B67jwMqoldsPJJPhgx0QQqKe5qi6Qd3LC/e0KchTMYog09YvYUWSBFjYBbmZxmuQlpOC86RGPC+sZeWZzh8o8zw4VEr3fx+zVEE= Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by SA0PR13MB4000.namprd13.prod.outlook.com (2603:10b6:806:9a::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.6; Mon, 31 Jan 2022 21:14:13 +0000 Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::e07d:da86:9082:d264%6]) with mapi id 15.20.4951.011; Mon, 31 Jan 2022 21:14:13 +0000 From: Haoyu Song To: Greg Mirsky CC: Loa Andersson , Tony Li , "mpls@ietf.org" Thread-Topic: [mpls] Question on avoiding TLVs Thread-Index: AQHYFpWCXPZU/LYjpkyDkzjBq91GR6x9U/nggAAHyYCAAASS8IAALNGAgAAB5ACAAAjTAIAAAKZwgAAF44CAAAFVUA== Date: Mon, 31 Jan 2022 21:14:13 +0000 Message-ID: References: <5cd6a374-d677-15c5-c721-77614de00c7f@pi.nu> <3BD86173-D24E-4669-91AD-B8C1E349D344@tony.li> <5ee2960d-ad6d-2aa4-268d-88861d17e201@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 829f2f69-13af-47ea-cb94-08d9e4fea1c2 x-ms-traffictypediagnostic: SA0PR13MB4000:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3t0u2eyTRq2v//aUUdYS1fh16Eec3pot962cKPR03Bwd2ib/HjYqyIDk6o08LFzpoK8WxKSNooyktUdKxUtzsj3MncxI/c1gHpaCDHPgn+U6ZMRclG+39SOiX2Hq0s2ktt7HPXHv68jSOgNV4UnkiSxh/DJSukUORRDX+mwUS/UIGsVtvAiKgEjWT4fIoUtVyGZqKJv8z+ZzGSQzCtpF4wx2JxP5MkBLeGwtskPKdugsUJSlsztqWV13yggBx+Gxzr0Y1ZQVFnkAeHZlKW+pFfaxt+WQ1ECdK5T8WMAvD5a7DmOKy7G89qdhtQGfcPl3CSt5/Y+F7k85jiImB+KVzxnkl1qGwdj1H5BRe+3h5CPwt2jrvtlprUUge6df2f32R6Yldkh9LaU8og8xexXxsGSsf5e4KVjpUrnEwTksEqHlPR8qDf8B6uE/q7mNwbr6DaVchxWV+V905I8jYWSOWKUPrPZKxft77ZMQwRQRZhhhqcQ5Hd1akLxhP6z1SdT6BdbBRn12zQyHcLvjBjoyhCr4t0p7GkMX0kgTaeG1UJ5TprXjTnzr7OCwKeq0i5X0tLoK4gBbP4bVqvsgbgynArcn9s/M7Ghc26aDcCUmB8cFpZZ3k3NkWqmYVv2+MHR4PddIaTZH+eGRNXq5liPOKXXalFwl2IqGduxQWFDjEJq/oyEiBj6fg/irlwxGBIvxNMjyQTI/vLsF+A14EpOXe2zVWRHZBHtWjwXDqXZdf2NhcEiJ8YJ0HS6vuBo4JKNXtg7OOgJkAG8X3dWgdbr4fAkE9AkKLHJTNS9k1GmD//Gb5Mk96u3Es6eSYbOQNn9cBhaG6d9Q9xdBuWdBHu3FnA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(26005)(186003)(83380400001)(66946007)(38070700005)(316002)(6506007)(76116006)(7696005)(2906002)(6916009)(54906003)(55016003)(33656002)(86362001)(71200400001)(5660300002)(53546011)(44832011)(9686003)(38100700002)(166002)(508600001)(45080400002)(66556008)(66476007)(66446008)(64756008)(4326008)(8936002)(8676002)(52536014)(9326002)(966005)(122000001)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?BhVStgG0qreugXNke7rvL9UjPfQ48GOhnc8cb9kxbNeNxABTvvVsggF1ps7r?= =?us-ascii?Q?Snfpv63ELbi39us/SfqCoW+rxI46iH4wBAgRQa6a4IFOi40VTbaEiensHq54?= =?us-ascii?Q?zPF+aZkaHUmzxsTtHKC3TQ3rcXOM05cPHT27rq3RgdWeublz32pI6xsKcX1B?= =?us-ascii?Q?2XS02EF/bm0docM6PFWkNc9lsAGFlRC+zogR2VhPPYNT2ZSwvBBUCP87Lhzj?= =?us-ascii?Q?yR31N8KnP58VcRnnoMumGbVJaMU2/fL240y3WyA6v1Tz98U9hHtCUrKZxqTo?= =?us-ascii?Q?h5jSwVLWO+Hl//VCHq8DnP98kYr32d6c6OIDgmhfsZB22+Wg661xZnYDdXFg?= =?us-ascii?Q?FYjVwlfkVD8GfUjzVadxqbjY5noba1ZdmltlXrpgWCcWMS65rvQekMJiePM/?= =?us-ascii?Q?v5Et9AQPb/DHjK2WH4U20R/4LAixWpZvU4u7g8m7vWZ1VPuFIeU7k6TClVfJ?= =?us-ascii?Q?WSqaiPOjRGqGM1gvLmCwO9Aj94mstQ9Z2Cbq/wwSPi3czE9Ujgy4+MahpJSc?= =?us-ascii?Q?Sja5VHeviuH/5k0US682GVtWKKZi4Ul1CjIjpFkSOODws7Unt6R4Yg193UA4?= =?us-ascii?Q?/XZRcqPH76HNqKK5o5C1LkO7K0YySM/Hc16+g09IZcYw26i6esAHW6Ylr/KY?= =?us-ascii?Q?YBYbRJDeT00O/nNjLaA3gyp8s9QEvuwuIf6RlV3lslYP1sxwq9YZwNMukh6V?= =?us-ascii?Q?O1NIz1UqUW8bC/52G2VhJWOPkqy1dkfeUnq9mSGe+m4vJIYblph+XOfO4eVt?= =?us-ascii?Q?ERmtfSddm2Twld+4BVY0KRd988RrJGfdikcyURMroUHmq/y8AAqzYdZDPDVO?= =?us-ascii?Q?essuzNIwk/YPipMVLcu5UYAX4wvlQMDO7jeytGeyDGxkTYHo5scQqR/b3Dd7?= =?us-ascii?Q?gEbxFMxMPhBFubJsWs1BQk2F7k5TpojHHpZCDIE2AgI//NzIQvTPT+xjPrGW?= =?us-ascii?Q?sZ/qbtEg5QjcWM7rH27gtAfFU+JNXxI4VzG/CqKITyLjZJcL6Sg2JL8syCp7?= =?us-ascii?Q?NUgwRaDyLB8BDlGsA5cXNBMgYPpr5YdQ1+Mon0g19avLEjwGXF+NEfv1zLLy?= =?us-ascii?Q?FFKDv8EfYfWgWTVTZ5hW976ROrw9Jon5WLhRTIOG/VlnFr9r+ONEU3jR5eHf?= =?us-ascii?Q?1ql/5TTzVhYzeSw6Ad5RQjLbeWDEpKhnLpBnB4hPVl9ftnbH5mrP9AxzahR3?= =?us-ascii?Q?OeWnHlsEeWKVxiECfeEwqf75tM+KOKg98H9nB6lurRBKxBYKaOWFEjcdV4WZ?= =?us-ascii?Q?EdF4qYGUHUkNoIKAGBM9+9ZOgDf04t60k9UU3j2tUuu3+/UwG3Wyb7Af/GfP?= =?us-ascii?Q?Qsn8Q/+LJkilQLk4B5N1xH4OeJeXBmmPOJZ76PkIUCela32llJWWqU62EXsx?= =?us-ascii?Q?dHmv4QJ6H0QNwtMuo5bg1mOA1i0mtgSUFxIzKJoHZJO1brGb6lnWhmzntj+r?= =?us-ascii?Q?cwKeGMS40zrOuZNG6+YwltkHZz7ohht6V24Z43vhe7GlxZ+LYawxt6SYPCcI?= =?us-ascii?Q?XMoBhwq2cjZKs6rlWujjinAY16JP/RSvdCBUETdPfIGjy+Jt0C838f85jXTa?= =?us-ascii?Q?RG1LMp9Fm+MMYrfL14nu5PHF3uio6pPyYr1ECeYuQA/xsXZIh5UizwyubOr8?= =?us-ascii?Q?FQ=3D=3D?= Content-Type: multipart/alternative; boundary="_000_BY3PR13MB478763E9E6652D67EDB8002A9A259BY3PR13MB4787namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 829f2f69-13af-47ea-cb94-08d9e4fea1c2 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2022 21:14:13.4328 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZudWww9jfQVn8T/r6y5kFEd6eTOk2RUSlFazYEx0jYM6S43KC77TQZi2uVo/0jed6R4b3oQGFZNSOmSNUzn03A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR13MB4000 Archived-At: Subject: Re: [mpls] Question on avoiding TLVs 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, 31 Jan 2022 21:14:28 -0000 --_000_BY3PR13MB478763E9E6652D67EDB8002A9A259BY3PR13MB4787namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, In a parser, IP address family is not identified by the version number, but= by a field in the previous L2 header (e.g., EtherType). As long as the parser needs to parse the TLVs, it doesn't matter where they= are (ISD or PSD). The cost is the same. In essence, the catalog bitmap is like to gather all the Ts together and th= en list the LVs later according to the T's order. Again, there's no benefit= s in terms of parser size and performance but limitations on extensiblity b= ased on my analysis. Haoyu From: Greg Mirsky Sent: Monday, January 31, 2022 1:02 PM To: Haoyu Song Cc: Loa Andersson ; Tony Li ; mpls@ietf.org Subject: Re: [mpls] Question on avoiding TLVs Hi Haoyu, I think that an ordered list of TLVs has some benefits. For example, consid= er an IP address. It can be identified by a single code point of a variable= -length TLV or by two code points for each address family. Also, you could have missed my question about the use case, ISD vs. PSD, yo= u are considering when suggesting not to use a TLV. Personally, I see fewer= issues using TLV in PSD. Regards, Greg On Mon, Jan 31, 2022 at 12:45 PM Haoyu Song > wrote: Hi Greg, The question is how to enforce the TLV orders? 1. People keep inventing new TLV options, some future options may have h= igher priority 2. If what you means is to provide a catalog in advance to list the TLVs= in order. Then strictly speaking, you don't need the T in the TLV option a= ny more. But as my last presentation shows, such a design shows no benefit = in terms of parser size and performance. Haoyu From: Greg Mirsky > Sent: Monday, January 31, 2022 12:39 PM To: Haoyu Song > Cc: Loa Andersson >; Tony Li >; mpls@ietf.org Subject: Re: [mpls] Question on avoiding TLVs Hi Haoyu, could you please clarify for me if your recommendation for avoiding using t= he TLV construct is for all scenarios considered, i.e., ISD and PSD, or for= one of them? I agree that the random order of appearance of variable-size = data has a performance impact. On the other hand, if the order of TLVs is d= eterministic, they are flexible and the performance cost of parsing is much= lower. So, perhaps, the recommendation could be refined suggesting the use= of ordered TLVs. What are your thoughts? Regards, Greg On Mon, Jan 31, 2022 at 12:22 PM Haoyu Song > wrote: Hi Loa, When designing new headers, it's good enough to simply organize them in a c= hain, which means the current header would include a field (in some cases, such a field is no= t needed. For example, in an MPLS label stack, as long as the BoS is not se= t, you know the next header is still a label) to tell what's the next heade= r, so the parser directly know the format of the next header. IPv6 EH follows such a structure, our proposed MPLS EH also follows such a = structure. One current issue is that people tend to add variable sized TLV sub structu= res into EH to support fast path functions. This needs to be done very care= fully, otherwise, it will never fly (for example IPv4 options). Haoyu -----Original Message----- From: Loa Andersson > Sent: Monday, January 31, 2022 12:00 PM To: Haoyu Song >;= Tony Li > Cc: mpls@ietf.org Subject: Re: [mpls] Question on avoiding TLVs Haoyu, Tony, I appreciate the difference in TLVs for the forwarding plane and for the co= ntrol plane. So looking at the forwarding exactly what should not be TLV encoded? Can you give examples? /Loa On 01/02/2022 01:25, Haoyu Song wrote: > Hi Tony, > > Yes you are right. Here we are discussing the headers designed for data p= lane fast path processing. > Most of the TLVs designed before are for control plane to use. > But as you see, some current work for supposed fast path processing also = suggests to use TLV options (e.g., in IPv6 EH) due to the lack of options. = We need to be careful here, because for the parser point of view, each TLV = options equals to at least 2 headers. > Now for MPLS EH, all I suggest is to avoid the issue because we are still= at the early stages and have the opportunity to avoid some costly mistakes= . > > Best, > Haoyu > > -----Original Message----- > From: Tony Li > On Be= half Of Tony Li > Sent: Monday, January 31, 2022 9:03 AM > To: Haoyu Song = > > Cc: Loa Andersson >; mpls@ietf.org > Subject: Re: [mpls] Question on avoiding TLVs > > > Haoyu, Loa, > > I think the important point here is that the parsing discussion is focuse= d on the forwarding plane. TLVs are pervasive in the control plane, where = parsing is not a significant cost. > > Tony > > >> On Jan 31, 2022, at 8:46 AM, Haoyu Song > wrote: >> >> Hi Loa, >> >> Usually TLV is used as a substructure in a header. For sub fields in a h= eader, usually we don't have other choices than using TLV. But for each he= ader, the type of it is better to be indicated by the previous header to sa= ve a parsing state. >> So all what I say is: as a principle, when designing a header, try not t= o embed its type in the header itself. Instead, before we get to this heade= r, we should already know its type. >> >> Moreover, TLV options in a header also increases the parsing cost. Each = fixed size TLV needs two states. Each variable size TLV needs multiple stat= es depending on the size of the option. So another advice is: if it is mean= t to be processed in hardware, then we should try to limit the use of TLV, = and especially variable sized TLV, unless absolutely necessary. >> >> Best, >> Haoyu >> >> -----Original Message----- >> From: Loa Andersson > >> Sent: Monday, January 31, 2022 3:27 AM >> To: mpls@ietf.org; Haoyu Song > >> Subject: Question on avoiding TLVs >> >> Haoyu, >> >> In the slides you uploaded to the "We should try the best to avoid TLV s= tyle and variable sized header". >> >> MPLS is full of TLVs (LDP, RSVP/TE, LSP Ping, the OAM) are you suggestin= g we'd change this? >> >> Given your advice above what should we do? >> >> /Loa >> -- >> Loa Andersson email: loa@pi.nu >> Senior MPLS Expert loa.pi.nu@gmail.com >> Bronze Dragon Consulting phone: +46 739 81 21 64 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww >> .ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=3D04%7C01= %7Chaoyu.song%4 >> 0futurewei.com%7Cfde3747555a34d294db408d9e4f44eba%= 7C0fee8ff2a3b240189 >> c753a1d5591fedc%7C1%7C1%7C637792560238419199%7CUnknown%7CTWFpbGZsb3d8 >> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C >> 3000&sdata=3Do%2F9wFBtO2sn8Y9y7KSMoRDqDBlA9F2Jz7VL6n9rwqPE%3D&r >> eserved=3D0 > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_BY3PR13MB478763E9E6652D67EDB8002A9A259BY3PR13MB4787namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

In a parser, IP address family is not identified by = the version number, but by a field in the previous L2 header (e.g., EtherTy= pe).

As long as the parser needs to parse the TLVs, it do= esn’t matter where they are (ISD or PSD). The cost is the same.<= /o:p>

 

In essence, the catalog bitmap is like to gather all= the Ts together and then list the LVs later according to the T’s ord= er. Again, there’s no benefits in terms of parser size and performanc= e but limitations on extensiblity based on my analysis.

 

Haoyu

 

From: Greg Mirsky <gregimirsky@gmail.com&g= t;
Sent: Monday, January 31, 2022 1:02 PM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Loa Andersson <loa@pi.nu>; Tony Li <tony.li@tony.li>= ; mpls@ietf.org
Subject: Re: [mpls] Question on avoiding TLVs

 

Hi Haoyu,

I think that an ordered list of TLVs has some benefi= ts. For example, consider an IP address. It can be identified by a single c= ode point of a variable-length TLV or by two code points for each address f= amily.

Also, you could have missed my question about the us= e case, ISD vs. PSD, you are considering when suggesting not to use a TLV. = Personally, I see fewer issues using TLV in PSD.

 

Regards,

Greg

 

Hi Greg,

 

The question is how to enforce the TLV orders?

  1. People keep inventing new TLV options, some future options may have higher = priority
  2. If what you means is to provide a catalog in advance to list the TLVs in or= der. Then strictly speaking, you don’t need the T in the TLV option a= ny more. But as my last presentation shows, such a design shows no benefit = in terms of parser size and performance.

 

Haoyu

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Monday, January 31, 2022 12:39 PM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Loa Andersson <loa@pi.nu>; Tony Li <tony.li@tony.li>; mpls@ietf.org
Subject: Re: [mpls] Question on avoiding TLVs

 

Hi Haoyu,

could you please clarify for me if your recommendation for avoidin= g using the TLV construct is for all scenarios considered, i.e., ISD and PS= D, or for one of them? I agree that the random order of appearance of variable-size data has a performance imp= act. On the other hand, if the order of TLVs is deterministic, they are fle= xible and the performance cost of parsing is much lower. So, perhaps, the r= ecommendation could be refined suggesting the use of ordered TLVs.

What are your thoughts?

 

Regards,

Greg

 

On Mon, Jan 31, 2022 at 12:22 PM Haoyu Song <haoyu.song@futurewei.com>= ; wrote:

Hi Loa,

When designing new headers, it's good enough to simply organize them in a c= hain, which means
the current header would include a field (in some cases, such a field is no= t needed. For example, in an MPLS label stack, as long as the BoS is not se= t, you know the next header is still a label) to tell what's the next heade= r, so the parser directly know the format of the next header.
IPv6 EH follows such a structure, our proposed MPLS EH also follows such a = structure.
One current issue is that people tend to add variable sized TLV sub structu= res into EH to support fast path functions. This needs to be done very care= fully, otherwise, it will never fly  (for example IPv4 options).

Haoyu



-----Original Message-----
From: Loa Andersson <loa@= pi.nu>
Sent: Monday, January 31, 2022 12:00 PM
To: Haoyu Song <haoyu.song@futurewei.com>; Tony Li <tony.li@tony.li>
Cc: mpls@ietf.org Subject: Re: [mpls] Question on avoiding TLVs

Haoyu, Tony,

I appreciate the difference in TLVs for the forwarding plane and for the co= ntrol plane.

So looking at the forwarding exactly what should not be TLV encoded?

Can you give examples?

/Loa

On 01/02/2022 01:25, Haoyu Song wrote:
> Hi Tony,
>
> Yes you are right. Here we are discussing the headers designed for dat= a plane fast path processing.
> Most of the TLVs designed before are for control plane to use.
> But as you see, some current work for supposed fast path processing al= so suggests to use TLV options (e.g., in IPv6 EH) due to the lack of option= s. We need to be careful here, because for the parser point of view, each T= LV options equals to at least 2 headers.
> Now for MPLS EH, all I suggest is to avoid the issue because we are st= ill at the early stages and have the opportunity to avoid some costly mista= kes.
>
> Best,
> Haoyu
>
> -----Original Message-----
> From: Tony Li <tony1athome@gmail.com> On Behalf Of Tony Li
> Sent: Monday, January 31, 2022 9:03 AM
> To: Haoyu Song <haoyu.song@futurewei.com>
> Cc: Loa Andersson <l= oa@pi.nu>; mpls@ietf.org
> Subject: Re: [mpls] Question on avoiding TLVs
>
>
> Haoyu, Loa,
>
> I think the important point here is that the parsing discussion is foc= used on the forwarding plane.  TLVs are pervasive in the control plane= , where parsing is not a significant cost.
>
> Tony
>
>
>> On Jan 31, 2022, at 8:46 AM, Haoyu Song <haoyu.song@futurewei.com> wr= ote:
>>
>> Hi Loa,
>>
>> Usually TLV is used as a substructure in a header. For sub fields = in a header, usually we don't have other choices than using TLV.  But = for each header, the type of it is better to be indicated by the previous h= eader to save a parsing state.
>> So all what I say is: as a principle, when designing a header, try= not to embed its type in the header itself. Instead, before we get to this= header, we should already know its type.
>>
>> Moreover, TLV options in a header also increases the parsing cost.= Each fixed size TLV needs two states. Each variable size TLV needs multipl= e states depending on the size of the option. So another advice is: if it i= s meant to be processed in hardware, then we should try to limit the use of TLV, and especially variable sized TLV, = unless absolutely necessary.
>>
>> Best,
>> Haoyu
>>
>> -----Original Message-----
>> From: Loa Andersson <loa@pi.nu>
>> Sent: Monday, January 31, 2022 3:27 AM
>> To: mpls@ietf.o= rg; Haoyu Song <haoyu.song@futurewei.com>
>> Subject: Question on avoiding TLVs
>>
>> Haoyu,
>>
>> In the slides you uploaded to the "We should try the best to = avoid TLV style and variable sized header".
>>
>> MPLS is full of TLVs (LDP, RSVP/TE, LSP Ping, the OAM) are you sug= gesting we'd change this?
>>
>> Given your advice above what should we do?
>>
>> /Loa
>> --
>> Loa Andersson              &nbs= p;         email: loa@pi.nu
>> Senior MPLS Expert             =             loa.pi.nu@gmail.com
>> Bronze Dragon Consulting            =  phone: +46 739 81 21 64
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>>
https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww=
>> .ietf.org= %2Fmailman%2Flistinfo%2Fmpls&amp;data=3D04%7C01%7Chaoyu.song%4
>> 0futurewei.com%7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b240189 >> c753a1d5591fedc%7C1%7C1%7C637792560238419199%7CUnknown%7CTWFpbGZsb= 3d8
>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D= %7C
>> 3000&amp;sdata=3Do%2F9wFBtO2sn8Y9y7KSMoRDqDBlA9F2Jz7VL6n9rwqPE= %3D&amp;r
>> eserved=3D0
>

--
Loa Andersson                 =       email: loa@pi.nu
Senior MPLS Expert                &= nbsp;         loa.pi.nu@gmail.com
Bronze Dragon Consulting             pho= ne: +46 739 81 21 64

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

--_000_BY3PR13MB478763E9E6652D67EDB8002A9A259BY3PR13MB4787namp_-- From nobody Mon Jan 31 13:27:48 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F553A18B3 for ; Mon, 31 Jan 2022 13:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=dDgQakXF; dkim=pass (1024-bit key) header.d=juniper.net header.b=cGRbKgpL 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 YGInALIEcUOp for ; Mon, 31 Jan 2022 13:27:41 -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 7F8423A18B1 for ; Mon, 31 Jan 2022 13:27:41 -0800 (PST) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 20VIH4Jj005105; Mon, 31 Jan 2022 13:27:40 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=2F6LiqfXLyPJJgircCBwzjuL0jIF+AfhdYAATQDAaSU=; b=dDgQakXFjA9ni8lo4RIWwr+nmlMlXrjp3KtUK3iszSmYHHBkopRyGl5ocnZNm7vk2EPP /TsWyH/JiJeP6sXfX9hNQ0otmQQMrNiZdii47TPp0HfvZR3qEcUrggLE2YJXLMCzgQsr rXzH08z9qaimDs1Q5eiBKQs4y0l+ES72FjZ2RwXm/V9ttJuMKleUWdbKRn+Cxf13iW3N oqs+yZiuVgm+qnFmwiTYuxQpyDSHfnM1gNJ/CIM5JZOsCT287d/XqV8ZY+yyfXrQKiJJ XlczqdvdhFsClZPXfZSLxyoe7GmtyrSbfdm1nuDWlNu0XY+hG7g5f5zjPqzDLD+e0nbC MQ== Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2173.outbound.protection.outlook.com [104.47.58.173]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3dxaw39w5v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 31 Jan 2022 13:27:39 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H5cWP0NKJkjY7ElJNynATEy+M3E4dAQOwLUVoyHG3GF7Tl6zdrbhhrde6KNCr4tH6oS0pr4Wj0loZm0FGQHXfGACJHBvha3c7zd0P26SYeV7Rls5GgYURWLDUCWPmiRYWFajoGZ5M5yruVrJvcXHsDXfHGVT2lIftRyBes9/F14s0mANLvj5s2xVTDcsAkrFnUVi5KIuNd9IAde5U/agBnHYxIdZA1hdKNvgy8AGlB9sjmLdM4F/Wmft+aZjeSK7ckhgUBti0wo5DDqPSXQe386KlIist8lafyWM2CjMlQAm7YYh5W35+vsfnMzBAzER61d45/8aFfieVUefI1Ewpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2F6LiqfXLyPJJgircCBwzjuL0jIF+AfhdYAATQDAaSU=; b=eBZupXHEf6YVtkMOVjEACTgDeI0R9K9oynt7hsBOzp9tekLGsVQvFIzsciy6+B30rbu9ldEzdK35k9c2qFEuwKBy5SjxxgeIWX5HlKgObPWj3eEzPtsOwGeRLfrQ74gUqnza1Da4go3syjdCH/P4cFdI2hqSUaXq/Ouzgc7GBY+M9U6bIMzBkqRuR/VDViq/S0ODZtjxhgaB15waWDUR6OW8Tf40Wtkp3sYm93nOexIKXFcf7dIimXsDn3bq0Cxzd3FJdAxspFe424N4SIJycgQXGTl0n3w+KRM4dKdhp0cQN6UbgctAgj66Mrj2hl5NBGRwX81RjEwlZCPl8pn7aA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2F6LiqfXLyPJJgircCBwzjuL0jIF+AfhdYAATQDAaSU=; b=cGRbKgpL2LT0gM9l/d0fGHOATGmIiFKjS9j7YlHWm15iC8G7TbxKfdeIDuQu7aOpUam9iy5QcBQM9K5P4aFTnxSfj/DFD+CRInGKf1pUDxyhrUFVt1iXvMNdEe6+gcHStmrszgrFhOFsYntl0RL9XXbwBNyxER6MeEyodyx5xVA= Received: from BY3PR05MB8081.namprd05.prod.outlook.com (2603:10b6:a03:366::15) by BY3PR05MB7874.namprd05.prod.outlook.com (2603:10b6:a03:367::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.5; Mon, 31 Jan 2022 21:27:37 +0000 Received: from BY3PR05MB8081.namprd05.prod.outlook.com ([fe80::304c:2b94:4f26:a581]) by BY3PR05MB8081.namprd05.prod.outlook.com ([fe80::304c:2b94:4f26:a581%3]) with mapi id 15.20.4951.011; Mon, 31 Jan 2022 21:27:37 +0000 From: John E Drake To: Greg Mirsky CC: "mpls@ietf.org" , "adrian@olddog.co.uk" Thread-Topic: [mpls] Question on avoiding TLVs Thread-Index: AQHYFsJaZXkwECE6qEqD6XWN+2qzHqx9W2iAgAAGJQCAACs/gIAABhyAgAAEmwCAAANDUIAABekAgAADNRA= Date: Mon, 31 Jan 2022 21:27:37 +0000 Message-ID: References: <5cd6a374-d677-15c5-c721-77614de00c7f@pi.nu> <3BD86173-D24E-4669-91AD-B8C1E349D344@tony.li> <5ee2960d-ad6d-2aa4-268d-88861d17e201@pi.nu> 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.6.400.34 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2022-01-31T21:22:52Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=57ac358f-eca7-4de8-a6bd-8dcbd501f553; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_enabled: true msip_label_0633b888-ae0d-4341-a75f-06e04137d755_setdate: 2022-01-31T21:27:35Z msip_label_0633b888-ae0d-4341-a75f-06e04137d755_method: Standard msip_label_0633b888-ae0d-4341-a75f-06e04137d755_name: 0633b888-ae0d-4341-a75f-06e04137d755 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_siteid: bea78b3c-4cdb-4130-854a-1d193232e5f4 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_actionid: b808a182-4de6-48e0-a17c-684437d9b431 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_contentbits: 0 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e0ce54bd-18bd-4af8-85c2-08d9e50080c5 x-ms-traffictypediagnostic: BY3PR05MB7874:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UZyRDH/4OyVnsJ9seTHyqoMLgkJAFKRh0YhBMmvAROIIAzdNpZsuwT5btFhFiuKpUtWHfOAtovMgJO6DBQC2jcrZZiVzHWbUy4VQP9bLAYamL8jftmIIG5M+oKtO5bZY/UPtS90FJ8mjMCXyBfyMJRljl7HZQmPnAz6FRW6mMDJXDB1xZW76rLW+fBaq3m+8+VbsX+eHFmvkP5bJ22TahS6VjHSJqagownIxize1kil86tIanaVf3ij/CfxcEgbtjdn9HCG3XVkC2XKeMWnTdtD/Q+L7a80ZpA0PotD88eO7bjkEAfH41C/oP4WvvfF20rdxeg9vt3jm2inKlSTreqU077xEPs3XLLqGQUbdkKz14NIXgwxnse32xpam0zF3zmLpA+22ovDuyZ0mQn6pxYgi+rRE3Ih7xkEe/LAD0zE/j3VeCKGtXxub6CzUl5NLK1sm/KBmmuUz2qp2OHghCMoHG8bjMC650XJxPJBYLoX3dnCqMdms7bccpGIu0fBs0MgqImKqV2j6/CpEB9pkYDMHRdkP6b5kC9WYzkD2HqMrF78bycgwh8TRhBb5Qzg1N5/T+16d9iAsKnEGgt1/hGzNw3vG/VjtWiI7iNBmAeW1P8Ox1MPcdbS9n3B2lfEUGKabcqMXZP8D19X45mebBjCDDFKEu/ddcp9M96ImQIszPhTHe9SJUYvz6KUrim9VXagY1PmHR3KUZMemd8mj/v+JOjSYSHeGsphgrc/FMVvI5aheVco5WMjmnYez7mbRulsZCKoIz0OeO6KRDQfJYmWu+h4wFwG8tVea31fcrjMSCtrKCtohhpdTMOLdx9RM7PPEFCXKpKpOorF1nuU8EA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR05MB8081.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(166002)(38100700002)(66574015)(122000001)(45080400002)(508600001)(52536014)(966005)(4326008)(66556008)(66476007)(66446008)(64756008)(8936002)(8676002)(66946007)(6506007)(54906003)(6916009)(2906002)(7696005)(26005)(186003)(83380400001)(76116006)(71200400001)(5660300002)(53546011)(9686003)(33656002)(55016003)(38070700005)(86362001)(316002)(20210929001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?5ihCqrwU/sOJgh2ArELVh37NUEJuUbgC+FaS1lgUYf/6WUKhVNoLWJ8Z+VMv?= =?us-ascii?Q?wI5vA/kygDqgLTn9EC1H0+EYihXS3n5xLLxueKjHt3kztuASGAigENMPXI2Y?= =?us-ascii?Q?gm52BjD77T5d2MhxuvR6ERIaXmo6WJzjCISZhT3RXcjCrTECPzDgRNDgn3qJ?= =?us-ascii?Q?1rAl7Y1CQ6FK7LnE592gAiRNSKGRwl1hgdOx3NlBHwgg7bCiDawQyYCnqJx9?= =?us-ascii?Q?N9f0rg/5L97rLfjUxanKlr56UHeNp3ruIflFeSKJOPeDzL9FseBf0Nx/Kgqm?= =?us-ascii?Q?quQpFrclbHFrVpfQjBwJL6pAa6OUhO3v/DqfpVbrflJlak8GHRg6ylgcxgpr?= =?us-ascii?Q?Kp2IpMPn47uMKuKargiMYKmfr+u5UEdbSOjQmNO7cIXkvvWqoe5PgwpFKYP3?= =?us-ascii?Q?W3PSxq1kD7yu7qzY4JBmFOe0Q25LVL7sTIiz2ZNdNQAByqugKLgAe07mXW6M?= =?us-ascii?Q?GR7N7LOXbfMSQ3UoUkER3tf6CfVvKa500cRbU0xFm5FvBDZJ123HseaPgwRl?= =?us-ascii?Q?FdBpwOZ3tFzsy8j0GRyosVKiTMMWGj+f4ltYupkxhOffYNXWbxVUqzbTgOiy?= =?us-ascii?Q?pDkKkmHTekNR7obYGWSjmghBNFykpXLBNvnyq5mtXNhEh/AbyQApXcnxcqn0?= =?us-ascii?Q?KlBjHcLEsSPnz1kppIDAh55w0W4R2tg7HoBeIoLm3te8Jxi5f9Zyc4g24v8a?= =?us-ascii?Q?3nCcnM1FJ4fUSnBUi+P45USCLr/vpN7rkFMuvTM7PHlJDOmwXm0yPsy66161?= =?us-ascii?Q?6wRufVZRPfhZVkAD9QJ96bOJ381d+C/pvs0LG4q43HeasTMtAHlM7KcCpLhb?= =?us-ascii?Q?hKmuEPuKseq37jnp8a1boBGyFgDI0ASQwXfNSgYLcZoO6IOId6IWcIAM79Ro?= =?us-ascii?Q?JeslxvnjuNlGe/cFtm93bZSiIkMGa6SbBLjU5y1H6H8CGi+cSmOg5c2udG1H?= =?us-ascii?Q?FH+Te/Un6GdsN0VgdKBMRDn9e0hIw4T6wIimR7c/dDjc3/4fktUmxSDR0lJ3?= =?us-ascii?Q?5WWcj8kvGtK4kYLjpg+M6xTWCD5TaIl8z9nZL0f2bcpFmeScNiSh0C7xAfLa?= =?us-ascii?Q?kTrewV5JgWv9kIJPCLtBPHmGRCg9umpQVXyS+YmArKn8DmMlRZgn3QzidOY5?= =?us-ascii?Q?3ieucq5G6URf/lxkqAVX/Sa8eszOy6fVG9zJEsb1W/ElBpgpnwzzU7kz9l01?= =?us-ascii?Q?LC9JtRl8uMFZ6Z4WWjICPhLLk1Jkgpetwc2FqeFnOb84HLH0CcEQOayPEz4s?= =?us-ascii?Q?wk/+NeIjXWycaZw6jObi2Ws27TNNf583CV0hJi2MteYpcPnCwWk+NWI9XLaY?= =?us-ascii?Q?vO1YD8P8rfKFnGElkbHWtY60oR/AfNsetWZEblSRDs1/C2WEZ/kqYhnDgNsk?= =?us-ascii?Q?aPqBhjkNzqRHy/KtekAHZiWyCSodLVg5vhmFpKJgSGOtyk03xYo180RCEmjM?= =?us-ascii?Q?XA/Gxzm4MZVlxlhHXCJYLhcTrX8UPbPtAx43xkRtzb+2P6lkp+XJcgIWSjdQ?= =?us-ascii?Q?Rz2d9Rq1CL5rrOQVvomxvswTfQzxvw2F6UoDW/FvaorQU8F8RLgRo4VfjXIx?= =?us-ascii?Q?Q2nRZWKlzntUut7sd8EAzggVSSTrexiYczwgRBihOBL+WRwpIgMfPs4goPc6?= =?us-ascii?Q?qw=3D=3D?= Content-Type: multipart/alternative; boundary="_000_BY3PR05MB8081B56FC311B6DED679BD04C7259BY3PR05MB8081namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR05MB8081.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e0ce54bd-18bd-4af8-85c2-08d9e50080c5 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2022 21:27:37.1887 (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-CrossTenant-userprincipalname: 4NaG0dmCJuZF4uPKKdIz7t94xyy5iXsY3i825TtwbvNDx5GxzADLfA8eB+1vnid5u+LiOCHSTNxn07lGOzMX6g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY3PR05MB7874 X-Proofpoint-GUID: LdJnwMGPtK5c0bl_Vu4cCEROiaQLZu-A X-Proofpoint-ORIG-GUID: LdJnwMGPtK5c0bl_Vu4cCEROiaQLZu-A X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-01-31_07,2022-01-31_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 mlxlogscore=999 bulkscore=0 clxscore=1015 malwarescore=0 priorityscore=1501 phishscore=0 spamscore=0 adultscore=0 lowpriorityscore=0 impostorscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2201310136 Archived-At: Subject: Re: [mpls] Question on avoiding TLVs 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, 31 Jan 2022 21:27:47 -0000 --_000_BY3PR05MB8081B56FC311B6DED679BD04C7259BY3PR05MB8081namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, I think what we said was that a given P router needs to understand all of t= he network actions up to a given bit position in the network actions flags = but it does not have necessarily support all of them. This allows it to sk= ip over the in-stack and post-stack ancillary data for network actions it d= oes not support. Yours Irrespectively, John Juniper Business Use Only From: Greg Mirsky Sent: Monday, January 31, 2022 4:11 PM To: John E Drake Cc: mpls@ietf.org; adrian@olddog.co.uk Subject: Re: [mpls] Question on avoiding TLVs [External Email. Be cautious of content] Hi John, thank you for the clarification. I agree that the strict order of indicator= s (actions and ancillary data) defines the order of ancillary data. The que= stion, as I understand it, is how the P node accesses the ancillary data. I= f not using a TLV, I imagine, the node must know the format of all defined = indicated ancillary data elements. On the other hand, TLV encoding of ancil= lary data allows relax that requirement and the node can support only some,= ones that it advertises while it can easily skip over others. Regards, Greg On Mon, Jan 31, 2022 at 1:00 PM John E Drake > wrote: Greg, In the proposal from Adrian and me, for every network action that is defin= ed, we will define its bit position in the network action flags, whether it= has ancillary data, if so what is that ancillary data, and whether that an= cillary data is in-stack or post-stack. When a P router receives a packet,= then based upon which network action flags are set, it will know the forma= t of the in-stack and post-stack ancillary data, because we stipulate that = it must be in the same order as the network actions whose flags are set. Yours Irrespectively, John Juniper Business Use Only From: mpls > On Behalf = Of Greg Mirsky Sent: Monday, January 31, 2022 3:39 PM To: Haoyu Song > Cc: mpls@ietf.org Subject: Re: [mpls] Question on avoiding TLVs [External Email. Be cautious of content] Hi Haoyu, could you please clarify for me if your recommendation for avoiding using t= he TLV construct is for all scenarios considered, i.e., ISD and PSD, or for= one of them? I agree that the random order of appearance of variable-size = data has a performance impact. On the other hand, if the order of TLVs is d= eterministic, they are flexible and the performance cost of parsing is much= lower. So, perhaps, the recommendation could be refined suggesting the use= of ordered TLVs. What are your thoughts? Regards, Greg On Mon, Jan 31, 2022 at 12:22 PM Haoyu Song > wrote: Hi Loa, When designing new headers, it's good enough to simply organize them in a c= hain, which means the current header would include a field (in some cases, such a field is no= t needed. For example, in an MPLS label stack, as long as the BoS is not se= t, you know the next header is still a label) to tell what's the next heade= r, so the parser directly know the format of the next header. IPv6 EH follows such a structure, our proposed MPLS EH also follows such a = structure. One current issue is that people tend to add variable sized TLV sub structu= res into EH to support fast path functions. This needs to be done very care= fully, otherwise, it will never fly (for example IPv4 options). Haoyu -----Original Message----- From: Loa Andersson > Sent: Monday, January 31, 2022 12:00 PM To: Haoyu Song >;= Tony Li > Cc: mpls@ietf.org Subject: Re: [mpls] Question on avoiding TLVs Haoyu, Tony, I appreciate the difference in TLVs for the forwarding plane and for the co= ntrol plane. So looking at the forwarding exactly what should not be TLV encoded? Can you give examples? /Loa On 01/02/2022 01:25, Haoyu Song wrote: > Hi Tony, > > Yes you are right. Here we are discussing the headers designed for data p= lane fast path processing. > Most of the TLVs designed before are for control plane to use. > But as you see, some current work for supposed fast path processing also = suggests to use TLV options (e.g., in IPv6 EH) due to the lack of options. = We need to be careful here, because for the parser point of view, each TLV = options equals to at least 2 headers. > Now for MPLS EH, all I suggest is to avoid the issue because we are still= at the early stages and have the opportunity to avoid some costly mistakes= . > > Best, > Haoyu > > -----Original Message----- > From: Tony Li > On Be= half Of Tony Li > Sent: Monday, January 31, 2022 9:03 AM > To: Haoyu Song = > > Cc: Loa Andersson >; mpls@ietf.org > Subject: Re: [mpls] Question on avoiding TLVs > > > Haoyu, Loa, > > I think the important point here is that the parsing discussion is focuse= d on the forwarding plane. TLVs are pervasive in the control plane, where = parsing is not a significant cost. > > Tony > > >> On Jan 31, 2022, at 8:46 AM, Haoyu Song > wrote: >> >> Hi Loa, >> >> Usually TLV is used as a substructure in a header. For sub fields in a h= eader, usually we don't have other choices than using TLV. But for each he= ader, the type of it is better to be indicated by the previous header to sa= ve a parsing state. >> So all what I say is: as a principle, when designing a header, try not t= o embed its type in the header itself. Instead, before we get to this heade= r, we should already know its type. >> >> Moreover, TLV options in a header also increases the parsing cost. Each = fixed size TLV needs two states. Each variable size TLV needs multiple stat= es depending on the size of the option. So another advice is: if it is mean= t to be processed in hardware, then we should try to limit the use of TLV, = and especially variable sized TLV, unless absolutely necessary. >> >> Best, >> Haoyu >> >> -----Original Message----- >> From: Loa Andersson > >> Sent: Monday, January 31, 2022 3:27 AM >> To: mpls@ietf.org; Haoyu Song > >> Subject: Question on avoiding TLVs >> >> Haoyu, >> >> In the slides you uploaded to the "We should try the best to avoid TLV s= tyle and variable sized header". >> >> MPLS is full of TLVs (LDP, RSVP/TE, LSP Ping, the OAM) are you suggestin= g we'd change this? >> >> Given your advice above what should we do? >> >> /Loa >> -- >> Loa Andersson email: loa@pi.nu >> Senior MPLS Expert loa.pi.nu@gmail.com >> Bronze Dragon Consulting phone: +46 739 81 21 64 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww<= https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?= url=3Dhttps*3A*2F*2Fwww__;JSUl!!NEt6yMaO-gk!UQBwBfuS1f7lCEKzXcTXsGHzfpNTha6= 7nwZC7ZdjiEp7nqm_cA-hkTzTQyKJxHY$> >> .ietf.org%2Fmailman%2F= listinfo%2Fmpls&data=3D04%7C01%7Chaoyu.song%4 >> 0futurewei.com%7= Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b240189 >> c753a1d5591fedc%7C1%7C1%7C637792560238419199%7CUnknown%7CTWFpbGZsb3d8 >> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C >> 3000&sdata=3Do%2F9wFBtO2sn8Y9y7KSMoRDqDBlA9F2Jz7VL6n9rwqPE%3D&r >> eserved=3D0 > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_BY3PR05MB8081B56FC311B6DED679BD04C7259BY3PR05MB8081namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greg,

 

I think what we said was that a given P router needs= to understand all of the network actions up to a given bit position in the= network actions flags but it does not have necessarily support all of them= .  This allows it to skip over the in-stack and post-stack ancillary data for network actions it does not sup= port.

 

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: Greg Mirsky <gregimirsky@gmail.com&g= t;
Sent: Monday, January 31, 2022 4:11 PM
To: John E Drake <jdrake@juniper.net>
Cc: mpls@ietf.org; adrian@olddog.co.uk
Subject: Re: [mpls] Question on avoiding TLVs

 

<= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

 

Hi John,

thank you for the clarification. I agree that the st= rict order of indicators (actions and ancillary data) defines the order of = ancillary data. The question, as I understand it, is how the P node accesse= s the ancillary data. If not using a TLV, I imagine, the node must know the format of all defined indicated a= ncillary data elements. On the other hand, TLV encoding of ancillary data a= llows relax that requirement and the node can support only some, ones = that it advertises while it can easily skip over others.

 

Regards,

Greg

 

On Mon, Jan 31, 2022 at 1:00 PM John E Drake <jdrake@juniper.net> wrote:

Greg,

 

In the proposal from Adrian and me,  for every network action= that is defined, we will define its bit position in the network action fla= gs, whether it has ancillary data, if so what is that ancillary data, and whether that ancillary data is in-stack o= r post-stack.  When a P router receives a packet, then based upon whic= h network action flags are set, it will know the format of the in-stack and= post-stack ancillary data, because we stipulate that it must be in the same order as the network actions whose f= lags are set.

 

Yours Irrespectively,

 

John

 

 

Juniper Business Use Only

From: mpls <mpls-bounces@ietf.org> On Behalf Of Greg Mirsky
Sent: Monday, January 31, 2022 3:39 PM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: mpls@ietf.org=
Subject: Re: [mpls] Question on avoiding TLVs

 

[External Email. Be cautious of content]=

 

Hi Haoyu,

could you please clarify for me if your recommendation for avoidin= g using the TLV construct is for all scenarios considered, i.e., ISD and PS= D, or for one of them? I agree that the random order of appearance of variable-size data has a performance imp= act. On the other hand, if the order of TLVs is deterministic, they are fle= xible and the performance cost of parsing is much lower. So, perhaps, the r= ecommendation could be refined suggesting the use of ordered TLVs.

What are your thoughts?

 

Regards,

Greg

 

On Mon, Jan 31, 2022 at 12:22 PM Haoyu Song <haoyu.song@futurewei.com>= ; wrote:

Hi Loa,

When designing new headers, it's good enough to simply organize them in a c= hain, which means
the current header would include a field (in some cases, such a field is no= t needed. For example, in an MPLS label stack, as long as the BoS is not se= t, you know the next header is still a label) to tell what's the next heade= r, so the parser directly know the format of the next header.
IPv6 EH follows such a structure, our proposed MPLS EH also follows such a = structure.
One current issue is that people tend to add variable sized TLV sub structu= res into EH to support fast path functions. This needs to be done very care= fully, otherwise, it will never fly  (for example IPv4 options).

Haoyu



-----Original Message-----
From: Loa Andersson <loa@= pi.nu>
Sent: Monday, January 31, 2022 12:00 PM
To: Haoyu Song <haoyu.song@futurewei.com>; Tony Li <tony.li@tony.li>
Cc: mpls@ietf.org Subject: Re: [mpls] Question on avoiding TLVs

Haoyu, Tony,

I appreciate the difference in TLVs for the forwarding plane and for the co= ntrol plane.

So looking at the forwarding exactly what should not be TLV encoded?

Can you give examples?

/Loa

On 01/02/2022 01:25, Haoyu Song wrote:
> Hi Tony,
>
> Yes you are right. Here we are discussing the headers designed for dat= a plane fast path processing.
> Most of the TLVs designed before are for control plane to use.
> But as you see, some current work for supposed fast path processing al= so suggests to use TLV options (e.g., in IPv6 EH) due to the lack of option= s. We need to be careful here, because for the parser point of view, each T= LV options equals to at least 2 headers.
> Now for MPLS EH, all I suggest is to avoid the issue because we are st= ill at the early stages and have the opportunity to avoid some costly mista= kes.
>
> Best,
> Haoyu
>
> -----Original Message-----
> From: Tony Li <tony1athome@gmail.com> On Behalf Of Tony Li
> Sent: Monday, January 31, 2022 9:03 AM
> To: Haoyu Song <haoyu.song@futurewei.com>
> Cc: Loa Andersson <l= oa@pi.nu>; mpls@ietf.org
> Subject: Re: [mpls] Question on avoiding TLVs
>
>
> Haoyu, Loa,
>
> I think the important point here is that the parsing discussion is foc= used on the forwarding plane.  TLVs are pervasive in the control plane= , where parsing is not a significant cost.
>
> Tony
>
>
>> On Jan 31, 2022, at 8:46 AM, Haoyu Song <haoyu.song@futurewei.com> wr= ote:
>>
>> Hi Loa,
>>
>> Usually TLV is used as a substructure in a header. For sub fields = in a header, usually we don't have other choices than using TLV.  But = for each header, the type of it is better to be indicated by the previous h= eader to save a parsing state.
>> So all what I say is: as a principle, when designing a header, try= not to embed its type in the header itself. Instead, before we get to this= header, we should already know its type.
>>
>> Moreover, TLV options in a header also increases the parsing cost.= Each fixed size TLV needs two states. Each variable size TLV needs multipl= e states depending on the size of the option. So another advice is: if it i= s meant to be processed in hardware, then we should try to limit the use of TLV, and especially variable sized TLV, = unless absolutely necessary.
>>
>> Best,
>> Haoyu
>>
>> -----Original Message-----
>> From: Loa Andersson <loa@pi.nu>
>> Sent: Monday, January 31, 2022 3:27 AM
>> To: mpls@ietf.o= rg; Haoyu Song <haoyu.song@futurewei.com>
>> Subject: Question on avoiding TLVs
>>
>> Haoyu,
>>
>> In the slides you uploaded to the "We should try the best to = avoid TLV style and variable sized header".
>>
>> MPLS is full of TLVs (LDP, RSVP/TE, LSP Ping, the OAM) are you sug= gesting we'd change this?
>>
>> Given your advice above what should we do?
>>
>> /Loa
>> --
>> Loa Andersson              &nbs= p;         email: loa@pi.nu
>> Senior MPLS Expert             =             loa.pi.nu@gmail.com
>> Bronze Dragon Consulting            =  phone: +46 739 81 21 64
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>>
https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww=
>> .ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=3D04%7C= 01%7Chaoyu.song%4
>> 0futurewei.com%7Cfde3747555a34d294db408d9e4f44eba%7C0fee8ff2a3b240189 >> c753a1d5591fedc%7C1%7C1%7C637792560238419199%7CUnknown%7CTWFpbGZsb= 3d8
>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D= %7C
>> 3000&amp;sdata=3Do%2F9wFBtO2sn8Y9y7KSMoRDqDBlA9F2Jz7VL6n9rwqPE= %3D&amp;r
>> eserved=3D0
>

--
Loa Andersson                 =       email: loa@pi.nu
Senior MPLS Expert                &= nbsp;         loa.pi.nu@gmail.com
Bronze Dragon Consulting             pho= ne: +46 739 81 21 64

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

--_000_BY3PR05MB8081B56FC311B6DED679BD04C7259BY3PR05MB8081namp_-- From nobody Mon Jan 31 15:26:11 2022 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4C73A1C9E for ; Mon, 31 Jan 2022 15:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIXELuFgSNYQ for ; Mon, 31 Jan 2022 15:26:03 -0800 (PST) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450: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 67DAE3A1C9B for ; Mon, 31 Jan 2022 15:26:03 -0800 (PST) Received: by mail-ej1-x62c.google.com with SMTP id d10so48007452eje.10 for ; Mon, 31 Jan 2022 15:26:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M5kUFWhVIlXSTx0Jlog0+cFcUrHjujpwXSKKONourhc=; b=aUmx9oAFRTSTpQDv/nhVQpklQHCO16OYho6jpT0oxqX1Binv4NmvP8EQcuLACzW21W ip/AYadCJ5SCioTkFpiP1oL3zdTwasw1sbrMCzNnITwkmhZ2DAywWDUyRS7mumussyvq 8/RmBR5fGzw5fnsxk/wK4bzyyJZeBEVh2tz3VXbwkacyMJvw3rTtxZpEEtpdf5/NiW7x Eo3vPhej92v7FwF/8FlemT4QEISHuTU76xMrRH1OZDuv2OzTOB0xZl47XU9hRQ0MhK01 kVEyi+Tb+sASVwrbdXfVJvgHCz7b0urPbtiVtZISqwND01k9mAVcUBbKYKBmugSbxymi m0/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M5kUFWhVIlXSTx0Jlog0+cFcUrHjujpwXSKKONourhc=; b=VU7HjmsvI/1Je5bjJWahgPMPnmh7a5rWa8gyfgn3fRnJhWSHwlld+nQiXV5c+3QOIk C+v8kUg9Oea+oe64BxhWkxafRmCXuP04Blj8peSJQq7oxua1jRB732LRn9nWiY4RFUWp vclbg6wv04/SEDv51BN/HFiLDlGTkO46lrch+20hTDJrDAjzpxLPiYogr7d5K0Lfht9D 56jSJehFAcfYVc6l8tVPheAmUze64biOppxsKaPYd0xK09cqtVih9wjkyRVW3GW0Ompx t2uD6Gpn2x1cDUMJrjTMmWo91gGAn4qc50gm25FtKxrby4FCn0KGc7Tka5L5Zw4buHvu L19Q== X-Gm-Message-State: AOAM5301EIHxIPAHcd19V7fpMYbVdd73EFfymrpKCyvBp4QG87E4f5YG OicKvl+K6SKlg0/56fCPIHgJa8gsml9ev6qXYvI= X-Google-Smtp-Source: ABdhPJxlcWYnQtSDuv6FACK1YHni2XM7eL+F2O73GdQX9ls89l8cWKIBoZ8dCNifhzN7dmx/A2B2sdADosO96kevSd4= X-Received: by 2002:a17:907:d1c:: with SMTP id gn28mr19343767ejc.59.1643671560390; Mon, 31 Jan 2022 15:26:00 -0800 (PST) MIME-Version: 1.0 References: <5cd6a374-d677-15c5-c721-77614de00c7f@pi.nu> <3BD86173-D24E-4669-91AD-B8C1E349D344@tony.li> <5ee2960d-ad6d-2aa4-268d-88861d17e201@pi.nu> In-Reply-To: From: Greg Mirsky Date: Mon, 31 Jan 2022 15:25:48 -0800 Message-ID: To: Haoyu Song Cc: Loa Andersson , Tony Li , "mpls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007c0f1405d6e91b1c" Archived-At: Subject: Re: [mpls] Question on avoiding TLVs 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, 31 Jan 2022 23:26:09 -0000 --0000000000007c0f1405d6e91b1c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Haoyu, thank you for correcting the terminology. Indeed, it would be LV construct. RE: the example of communicating an IP address in ancillary data. I cannot see how the EtherType of an MPLS packet can be used to deduce the address family in the ancillary data block. Regards, Greg On Mon, Jan 31, 2022 at 1:14 PM Haoyu Song wrote= : > Hi Greg, > > > > In a parser, IP address family is not identified by the version number, > but by a field in the previous L2 header (e.g., EtherType). > > As long as the parser needs to parse the TLVs, it doesn=E2=80=99t matter = where > they are (ISD or PSD). The cost is the same. > > > > In essence, the catalog bitmap is like to gather all the Ts together and > then list the LVs later according to the T=E2=80=99s order. Again, there= =E2=80=99s no > benefits in terms of parser size and performance but limitations on > extensiblity based on my analysis. > > > > Haoyu > > > > *From:* Greg Mirsky > *Sent:* Monday, January 31, 2022 1:02 PM > *To:* Haoyu Song > *Cc:* Loa Andersson ; Tony Li ; mpls@ietf.org > *Subject:* Re: [mpls] Question on avoiding TLVs > > > > Hi Haoyu, > > I think that an ordered list of TLVs has some benefits. For example, > consider an IP address. It can be identified by a single code point of a > variable-length TLV or by two code points for each address family. > > Also, you could have missed my question about the use case, ISD vs. PSD, > you are considering when suggesting not to use a TLV. Personally, I see > fewer issues using TLV in PSD. > > > > Regards, > > Greg > > > > On Mon, Jan 31, 2022 at 12:45 PM Haoyu Song > wrote: > > Hi Greg, > > > > The question is how to enforce the TLV orders? > > 1. People keep inventing new TLV options, some future options may have > higher priority > 2. If what you means is to provide a catalog in advance to list the > TLVs in order. Then strictly speaking, you don=E2=80=99t need the T in= the TLV > option any more. But as my last presentation shows, such a design show= s no > benefit in terms of parser size and performance. > > > > Haoyu > > *From:* Greg Mirsky > *Sent:* Monday, January 31, 2022 12:39 PM > *To:* Haoyu Song > *Cc:* Loa Andersson <